当AI越来越能干，我们该如何重新摆位？

能力下放，验证上收——这是AI时代工程师的生存法则

最近读到一期BestBlogs的早报，三篇精讲从不同维度探讨了同一个问题：当模型越来越能干，人和验证该怎么重新摆位？ 读完后我发现，这不是一个遥远的哲学问题，而是每个工程师现在就得面对的现实。

代码正在变得廉价

先讲一个让我坐立不安的发现。

有位工程师最近做了一项亲测：20天时间，让AI提交了70万行代码，10个项目同时并行。不是IDE补全那种"AI占70%我占30%"的协作，而是把整个任务整包交出去——让模型自己读地形、定方案、写实现、跑验证、修bug全套跑完。他只做一件事：在关键节点拽方向。

他把这套方法论称为Harness：人定方向，模型推进。

这不是在讲AI有多强，而是在揭示一个残酷事实：代码本身正在变得非常便宜。当改别人代码的成本降到接近零时，"要不要改"和"动手改"之间的心理门槛就消失了——这正在重写团队协作的不成文契约。

但这里有个陷阱：代码变便宜了，质量问题却变贵了。

因为大模型是概率生成器。每吐一个token都是在词表上按概率挑一个，自由空间越大跑偏概率越大。典型翻车场景：洋洋洒洒500行代码方向全错，或者修一个bug顺手"优化"了你不想动的部分。他还给这类产物起了个名字叫best-practice slop——看似专业、语言完整、结构漂亮，但不贴业务地形、不解决真实问题的平均套路。

另一个被反复纠正的直觉是：真正要节约的不是token，是上下文。省token是成本问题，省上下文是质量问题。注意力机制让长上下文里中间的信息最容易被遗忘，多轮对话还会叠加"新旧方案分不清""自动总结有损压缩"等问题。常见悲剧是AI在第15轮把第5轮已经修好的逻辑改回去。

校准式自主：一个更聪明的定位

面对这种现实，行业里主流的讨论框架是什么？

过去一年，大家喜欢引用Steve Yegge的单轴自主性阶梯——从"只能建议"到"完全自主"——给团队打个"你有多AI-native"的分数。但有人发现，几乎所有关于自主性的争论都在把两个本应分开的问题搅在一起。

于是他做了个关键动作：把自主性拆成两条轴。

代理轴回答的是：单个agent能离你多远自己干活？低是只建议等决定，中是限定范围边干边汇报，高是朝着目标自己试错、自己找路。

编排轴回答的是：你协调多个agent的能力有多强？低是一个agent一个线程，中是几个agent各自隔离并发，高是一个orchestrator接住任务队列、把它变成连续工作，只在失败时才叫人。

两条轴交叉，得到从Assist到Managed-by-exception的六级。作者强调这其实对应三个时代：先学会让一个agent在限定范围里干活，再学会同时跑多个，最后才到把队列交给orchestrator持续产出。

这里有个深刻判断：高自主性不是把人踢出循环，而是把人的角色从逐步执行转为决定方向。Anthropic对约40万场Claude Code会话的分析恰好印证了这一点——人做约70%的规划，模型做约80%的执行。

落点是一个叫校准式自主的概念：每一个动作该用哪一级，取决于有什么样的验证能让那一级站得住脚。这不是哲学思辨，而是工程师每天要问的问题。书中还列了四种反模式：把自主性当勋章、用"许可"给高风险动作洗白、上下文不清就让agent冲、验证只看结果不看过程。

一个工程案例：代码清理任务中的"人定方向"

光讲理论不够，来看一个真实的工程场景。

某个团队在维护一个大型桌面软件，产品线经历过多次调整，代码仓库里沉淀了大量历史遗留——早期产品的业务逻辑、已废弃平台的适配代码、不再使用的资源文件，全都混在一起。团队面临一个任务：清理不再使用的代码和资源，但不能影响当前产品的正常构建和升级。

这个任务如果直接丢给AI"帮我删掉没用的代码"，结果将是灾难性的。AI不知道哪些"看起来没用"的宏下面藏着仍在运行的业务逻辑，不知道当前产品只支持64位Windows 10及以上系统，更不知道团队的首要目标是保证一个关键升级顺利进行。

于是团队在AI动手之前，先建立了一套完整的约束系统。

第一层：确认边界——哪些不能碰。

团队逐个确认了几个关键问题：哪些产品宏下的代码需要保留？是否需要保留其他操作系统平台的适配代码？是否只保留64位版本代码？是否只保留Win10及以上系统的兼容代码？是否需要删除多余的脚本、皮肤等资源文件？

这些问题本质上是在给AI划定活动范围。就像一个建筑工人在拆墙之前，工程师先用粉笔标出了承重墙的位置——粉笔线之内，随你拆；粉笔线之外，一砖不动。

第二层：确认优先级——先做什么，后做什么。

团队把清理工作分了三个批次。第一批：人工梳理出的已确认不在当前产品上使用的功能列表，风险最低，直接删除。第二批：AI辅助生成的"疑似无用代码"清单，需要人工确认后才能执行，风险中等。第三批：资源、脚本等非核心代码的清理。

这里还插入了一条关键原则：不影响关键升级的优先级可以放低。 这是在告诉AI，当前的首要目标是保证升级顺利，代码清理是锦上添花。AI不知道什么是业务优先级，人必须给它注入这个判断。

第三层：确认验证标准——怎么算做对了。

团队定了几条硬性要求：每次删除后必须评估改动依赖度，依赖度过大时需要暂停、降低风险后再继续；所有改动必须通过回归测试；分批提交，每批附带删除理由说明。

至此，一个模糊的"清理代码"需求，被转化成了AI可以安全执行的任务清单。把约束条件整理出来，大概是这样的：

text

【目标】清理当前产品中不再使用的代码和资源，保证关键升级不受影响
【范围】
  - 删除已确认不再使用的业务功能代码
  - 删除已废弃平台的适配代码
  - 删除不再使用的资源文件
  - 保留当前产品仍在使用的所有代码路径
【停止条件】
  - 改动依赖度过大时暂停，降低风险后再继续
  - 任何影响关键升级的操作立即停止
【执行顺序】
  - 第一批：低风险删除（人工已确认无用的功能列表）
  - 第二批：中风险删除（AI出的疑似无用代码清单，人工确认后执行）
  - 第三批：非核心代码及资源清理
【证据要求】
  - 每次删除后提供改动依赖度评估
  - 回归测试通过
  - 分批提交，每批附带删除理由说明

这个案例揭示了"人定方向"的真正含义：它不是一句口号，而是一套三层约束系统。

这套约束系统的本质，是在AI动手之前就把"不可为"和"必须验证"的事情说清楚。人在这个过程中的角色非常清晰：利用自己的业务知识做出判断，然后把判断结果转化为AI能执行的边界条件。人和AI的分工不是"人做全部，AI打下手"，而是人做判断，AI做执行；人建约束，AI在约束内推进。

验证是真正的瓶颈

理解了"校准式自主"，就会发现验证才是瓶颈。

前文提到的那位工程师其实已经把校准式自主落地成了一套可操作的清单：

spec：在任务边界反复和模型对齐目标，把判断标准沉淀成契约。包含目标、范围、停止条件、证据、预算。

checkpoint：这是人和模型唯一的接触点，既是验收位，也是把笔记回喂spec的回流点。

五层safety net：他甚至说自己一行代码都不看，只盯证据链。

他给的最小混沌单元配方是：配spec、codemap、new-chat三件套——小到可检查，大到可自治。

这种姿态说白了就是：把不该人盯的部分交给流水线，把必须人盯的接缝收紧。能力越往下放，验证和契约就越要往上收。

这个逻辑在大规模系统中同样成立

有趣的是，同样的工程姿态在系统架构层面也能看到。

OpenAI每周要为9亿用户提供低延迟语音AI。核心矛盾是：WebRTC是为稳定IP和端口的服务器设计的，而Kubernetes把这些地址当成可抛弃的——Pod随时可能被赶走，端口会耗尽，状态会粘在已经不存在的实例上。

他们的解法是把协议栈按是否有状态拆两半：边缘放无状态relay，只做协议感知的包路由；后方放有状态transceiver，持有重状态。把这两半缝起来的关键一招，是用ICE ufrag（一个协议自带字段）当路由键——relay从新会话的第一个STUN包读出ufrag就能转发，热路径完全不查库。

relay之所以敢无状态，是因为它把验证压到了协议自带字段上。这和"验证决定自主级别""checkpoint是唯一接触点"是同一种工程姿态——只不过压在了网络协议层。

把不该有状态的部分降到最低，验证只压在必须守住的接缝上。这就是可校验、可恢复、可随时拽回方向的自主性。

个人的几点思考

读完这些内容，我有几个感触：

第一，AI时代的核心竞争力正在转移。 过去工程师的价值体现在"能写出多少代码"，现在价值体现在"能定多准的方向"和"能建多可靠的验证"。这不是说技术不重要了，而是技术的内涵变了——从执行能力转向判断能力和架构能力。

第二，团队协作的规则需要重新制定。 当AI让改别人代码的成本降到接近零，传统的代码所有权、评审流程、协作礼仪都在失效。有篇速览提到一个程序员用AI重写了同事维护三年的代码，结果同事没感谢反而找了领导。这件事的教训是：技术上正确不等于做法正确，跳过了"达成共识"这一步就会付出代价。

第三，保持怀疑精神。 校准式自主这套框架虽然漂亮，但假设了验证体系本身是可靠的。在实践中验证也可能出错——尤其是当验证规则由模型自动生成或由经验不足的工程师制定时。未来真正的挑战或许是"如何验证验证本身"。

第四，从现在开始实践。 不需要等到公司推行新流程。明天就可以在项目里用spec/checkpoint/new-chat三件套，从一个小任务开始训练自己"人定方向、模型推进"的肌肉记忆。

AI不会取代工程师，但会用AI的工程师会取代不会用的。而这个"会用"的含义，正在从"会写prompt"快速进化到"会定方向、会建验证、会把控系统级取舍"。

当我们不再纠结于"要不要让AI更自主"，而是专注于"什么样的验证配得上这一级自主"，我们就真正开始驾驭这头猛兽了。

思考题：你在工作中遇到过哪些"看似专业但不贴业务地形"的best-practice slop？或者你有没有尝试过给AI设定类似的约束系统？欢迎留言分享。