锤子、壳与人：AI时代工程能力的三体问题
导读： 上一篇文章里，我尝试论证了一个判断：当AI把实现成本压到接近于零，架构师的核心竞争力将从广度转向深度——问题定义、业务抽象、多目标权衡、迁移设计、决策推动。但文章留下了一个未闭合的问题：这些深度判断如何持续地、系统地生效？如果判断力只留在人的脑子里，它就既不可扩展也不可积累。本文尝试回答这个问题——并补上上一篇文章没来得及展开的另一面：当判断力被编码成机器可执行的规则后，人自己会不会在舒适中缓慢退化？
一、判断力的交付问题
上一篇文章的核心结论可以压缩成一句话：当构建变得几乎免费，"决定构建什么"就成了唯一的战场。
这个判断我依然坚持。但几个月来持续的观察和实践让我意识到，它隐含了一个被我自己跳过的环节：判断力本身也需要被交付。
一位资深架构师对系统边界的理解、对业务规则的洞察、对风险拐点的预判——这些深度能力如果只存在于他的经验和直觉中，就面临几个结构性的问题：
不可扩展。 他能同时深度参与的系统有上限。他不在场的时候，他的判断力也不在场。
不可积累。 他离职了，他调岗了，他老了，判断力就跟着走了。组织没有从中沉淀出可复用的东西。
不可校准。 直觉无法被量化地验证。他觉得自己判断力在进步，但没人知道是不是真的——包括他自己。
这不是新问题。传统软件工程里，架构师解决它的方式是写文档、画图、做技术评审。这些做法的本质是把隐性知识显性化。但过去这种显性化的粒度很粗——一份架构设计文档描述的是目标和原则，不是可执行的规则。最终的执行仍然依赖每一个开发者对文档的理解和自觉遵守。
AI时代把这个问题推到了极端。当一个系统的大部分代码由Agent自主生成、每天数百个PR自动合并、人类工程师甚至不再逐行审查——你的深度判断必须以一种更精确、更刚性、更可执行的方式被"交付"给系统。
它需要一个载体。
二、Harness：判断力的运行时形态
2026年初，AI工程圈涌现出一个概念：Harness Engineering。
Nate B Jones的一项研究给出了一个有力的数据：同一个模型，换一套运行环境（Harness），编程基准的成功率从42%跳到78%。模型没换，数据没换，提示词也没换，只是改了模型外面包裹的那层"壳"。
这层壳包括什么？目前行业实践大致收敛为三个支柱：
上下文工程。 为Agent的每一个决策点构建正确的信息环境——它需要看到什么文件、什么历史、什么工具定义。OpenAI的Codex团队在仓库根目录放置AGENTS.md文件，控制在60行以内，充当"目录"而非"百科全书"；同时接入了完整的可观测性栈（日志、指标、链路追踪），让Agent可以自己查报错、看性能数据、定位问题所在。
架构约束。 通过确定性的linter、类型检查、结构化测试来机械执行架构规则。不是在prompt里写"请遵守分层架构"，而是违反了就CI挂掉。约束解空间反而让Agent更有生产力——当它可以选择任何方向时，大量token被浪费在探索死胡同上；当边界清晰时，它反而更快收敛到正确答案。
熵管理。 定期启动Agent扫描技术债、过时文档、架构漂移。AI生成的代码积累到一定程度，风格会走样、文档会过时、架构会漂移——就像不打扫的房子再好的装修也会变成垃圾场。
这三根支柱，换一个角度理解，本质上就是架构师深度判断力的运行时形态。
我来做一个映射。
| 架构师的深度能力 | Harness中的落地形态 |
|---|---|
| 问题定义 | AGENTS.md + 上下文工程——确保Agent看到的是正确的问题空间 |
| 业务抽象 | 分层架构 + linter规则——把抽象边界的判断编码成硬约束 |
| 多目标权衡 | CI限速 + 工具精简——把权衡结果固化为可执行的选择 |
| 迁移设计 | 熵管理 + 垃圾回收——持续校正系统漂移 |
| 决策推动与责任承担 | 没有直接对应物 |
前四条都可以被不同程度地编码。第五条不能。
这个"不能"不是技术限制，而是本质性的——责任是一种社会行为，它需要一个人在其他人面前说"这个决策是我做的，我来承担后果"。这不是能力问题，是治理结构问题。
所以完整的图景是：Harness能够承载大约80%的深度判断力的执行，但最核心的那20%——关于"这个需求该不该做"和"我愿意为什么样的决策承担后果"——永远需要人直接在场。
三、三体系统
把前面的讨论整合起来，AI时代的工程能力结构可以理解为一个三体系统。
模型（Model）提供能力。 它是引擎，算力持续增长，能覆盖越来越多的实现层面。但引擎自己不知道往哪开。
壳（Harness）提供约束。 它是操作系统，把人的深度判断编码成可执行的规则体系，约束和引导Agent的行为。但操作系统自己不会产生新的判断——它只能执行已经被编码进去的那些。
人（Human）提供判断。 方向、责任、对本质复杂性的穿透力。但人的判断力不是静态资产——它会因为使用方式的不同而增长或退化。
三者之间的依赖关系是这样的：
人的深度判断 → 编码为 Harness → 驱动 Agent 执行 → 产出新的系统状态
↑ ↓
└──── 新的失败模式 / 新的本质复杂性 ←─────────────────┘
这是一个持续运转的循环。循环健康的时候，每一轮都让系统更强——人的判断被Harness固化，Agent在Harness内高效执行，新的问题暴露出来驱动新一轮的深度思考。
但这个循环也有可能变成一个反向的死亡螺旋。
四、慢坍塌
上一篇文章里我提到了"自动化悖论"：AI接管了99%的常规操作后，剩下1%需要人类接管的瞬间恰恰是最危险的。这个判断不仅适用于单次决策，也适用于整个能力的长期演化。
想象这样一个场景：
一个架构师团队建立了成熟的Harness系统。Agent能够自主完成80%的开发工作，CI自动运行，PR自动合并，工程师的角色变成了"Harness调参师"。日常工作中，他们只需要微调规则、审查少量的边界case。系统运转良好。
然后某一天，出了一个问题——Agent生成了一段涉及跨域数据一致性的代码，Harness里没有覆盖到这个场景，bug溜进了生产环境。
这本该是一个架构师能够快速诊断的问题。但此时：
- 负责这块的架构师已经半年没有深入看过相关的实现代码了，他对这个子系统的理解停留在半年前的状态
- Harness的熵管理Agent一直在"维护"系统，但它的维护是基于已有规则的，规则本身的盲区它发现不了
- 系统的代码量已经比半年前翻了三倍，其中大部分是Agent生成的——即使他想重新理解，成本也已经高得离谱
这不是一个虚构的场景。类似的事情在每一个高度自动化的系统中都会发生——核电、航空、金融交易。自动化消除了日常操作中的摩擦，也消除了人通过日常操作维持的对系统的手感。
这就是"慢坍塌"：不是突然的崩溃，而是人的深度判断力以一种不可见的方式持续退化，直到某个临界点被触发，暴露出退化的程度。
更危险的是，慢坍塌在发生的时候往往还伴随着一种表面繁荣：PR合并量在增长，代码覆盖率在提高，Agent的自动化率在上升。所有数字都在变好，只有人的能力在变差——而人的能力恰恰是唯一不在任何dashboard上的指标。
前面说了Harness能承载大约80%的深度判断力。但这个80%不是固定的——它的质量取决于人的判断力水平。如果人的判断力退化了，Harness的质量会跟着退化，但退化的过程可能滞后数月甚至数年才在系统产出上显现。
这就是为什么"给人的Harness"不是一个锦上添花的想法，而是整个循环能不能持续运转的前提条件。
五、给人的 Harness
Agent的Harness解决的是"能力够但方向乱"的问题。给人的Harness要解决的是相反的问题："方向清楚但能力可能退化"。
它不是一个系统，而是一套嵌套的机制，核心目的是确保人的深度判断力在与Agent协作的过程中持续增长，而不是在舒适中消融。
5.1 成长轨道的重新设计
传统的工程师成长路径是围绕"实现能力"设计的：从写简单模块开始，逐步承担更复杂的系统，最终做架构决策。这条路径的底层假设是：实现能力是架构能力的前提——你必须先"做得够多"才能"想得够深"。
这个假设正在被动摇。当Agent能写出比大多数mid-level工程师更好的实现代码时，"做得够多"不再是"想得够深"的必经之路。
但"想得够深"本身仍然需要一条成长路径，只是路径的入口不同了。
我设想的新轨道大致是这样：
| 阶段 | 核心角色 | 训练重点 |
|---|---|---|
| 第一阶段 | Agent输出的阅读者和判断者 | 读懂Agent的产出，判断对错，理解决策链 |
| 第二阶段 | Agent失败的诊断者和修复者 | 定位Agent犯错的原因，补充Harness规则 |
| 第三阶段 | Harness的设计者 | 设计新的约束规则和架构边界 |
| 第四阶段 | 系统架构和人机分工的设计者 | 决定什么交给Agent，什么必须人来承担 |
注意第一阶段不是"学写代码"，而是"学读Agent的代码"。起点变了。
但这里有一个关键的前提：每一个阶段的训练都必须包含"无Agent"的强制环节。 不是为了回到过去的工作方式，而是为了校准——确保人的理解是真实的，而不是在Agent辅助下产生的幻觉。
5.2 三个具体的机制
机制一：无Agent检查点。
每2-3个月，要求工程师在没有Agent辅助的情况下完成一个任务。不需要很大，但必须覆盖当前阶段的核心能力。
这不是考核，是校准。就像飞行员的模拟器训练——95%的飞行时间是自动驾驶，但定期必须手动降落，保持手感。检查点的目的不是证明人比Agent强，而是让人知道自己真实的理解深度在哪里，盲区在哪里。
机制二：错误日志的个人化。
不只记录Agent的错误，也记录人的错误：你审查过但后来被证明有问题的PR、你设计但被Agent绕过的Harness规则、你在无Agent检查点上的表现趋势。
传统绩效评估的反馈周期是以季度或年为单位的。个人化的错误日志可以把反馈周期缩短到天——每一次"我本来应该发现但没发现"的记录，都是一个学习信号。
机制三：反向教学。
要求每个人向更初级的人解释Harness规则的设计原因和Agent的决策逻辑。如果你讲不清楚"这条规则为什么存在"，说明你只是记住了它，没有理解它。
费曼说过，如果你不能向一个大一学生解释清楚，说明你自己也没真懂。在Agent时代，这个标准变成了：如果你不能向一个刚接触这个系统的人解释清楚"Agent为什么会犯这个错"和"这条规则防住了什么"，你对系统的理解就还停留在表面。
5.3 什么不是给人的Harness
有两件事容易混淆但必须区分：
给人的Harness不是"学会用Agent"的培训。 工具培训三个月就过时了。核心不是学会用工具，而是培养在什么场景下该信任Agent的产出、什么场景下不该信任、什么场景下必须亲自介入的判断力。
给人的Harness不是让初级工程师"更早当架构师"。 深度判断力不等于头衔。一个两年经验的工程师可以在特定的狭窄领域做出准确的判断，但这不等于他能承担一个系统的整体架构决策。成长轨道的加速不等于跳过阶段。
六、完整的循环
回到第三节的三体图，加入"给人的Harness"之后，完整的循环变成：
人的深度判断 → 编码为 Agent的 Harness → 驱动 Agent 执行 → 产出新的系统状态
↑ ↑ ↓
│ │ 新的失败模式
│ │ ↓
└─── 给人的 Harness（校准 + 反馈）←───── 暴露能力盲区 ───┘
三个子系统各自运转，又互相依赖：
- Agent的Harness需要人来设计和迭代
- 人的判断力需要持续的校准机制来维持
- 校准机制又依赖于Agent的实际产出来暴露问题
这不再是一个"人设计、机器执行"的单向关系，而是一个持续协同演化的系统。
每一轮循环，系统和人都应该比上一轮更强。这才是健康的状态。
七、可以明天就做的三件事
和上一篇文章一样，理论最终要落到可操作的动作上。以下三件事不需要组织变革，不需要新工具，个人就能开始。
不需要完美，60行以内。写清楚：这个系统的核心边界在哪里，什么是绝对不能违反的规则，常见的坑是什么。你会发现，写这份文档的过程本身就在逼你把隐性知识显性化——很多你以为自己清楚的约束，写到纸上才发现描述不清楚。写不清楚就说明理解还不够深。
第二，给自己设一个"无Agent日"。
每月选一天，关掉所有AI辅助工具，用手写的方式完成当天的工作。不需要刻意选困难任务，正常的日常工作就行。目的是感受：在剥离了AI辅助之后，你的真实速度和理解力在哪里。这个感受本身就是最好的校准信号。
第三，开始记录你的"判断日志"。
不是记录你做了什么，而是记录你判断了什么：这个需求该不该做、这个边界该划在哪里、这个风险能不能接受、这个决策的后果谁来承担。每周回顾一次，看自己的判断有没有在被AI辅助的舒适感中变得模糊。
结语
上一篇文章的结论是：在AI让一切变得更"容易"的时代，刻意选择"不容易"，本身就是一种竞争力。
这篇想补的是："不容易"不能只靠意志力来维持，它需要被设计成系统。
锤子（AI）越来越强，壳（Harness）越来越精密，但人——这个三体系统中唯一能产生新判断的组成部分——如果不在系统的设计中被显式地保护和校准，就会成为第一个无声退化的变量。
Harness Engineering不只是给Agent设计约束体系。它应该包含第三个维度：给人的约束和校准体系——确保人在赋能Agent的过程中不是在消耗自己，而是在持续增长。
Brooks说没有银弹。四十年后这句话依然成立。但现在我们有了一把足够好的锤子，也开始学会给它配一副好壳。剩下的问题是最古老的那个：握锤子的人，还知道自己往哪砸吗？
这个问题，没有工具能替你回答。