能力下放验证上收——这是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设定类似的约束系统欢迎留言分享。