从让AI写代码到为AI设计系统（Joel Spolsky 风格）

发表于 | 分类于

从让AI写代码到为AI设计系统

副标题：Joel Spolsky 风格——老司机聊天，幽默比喻，可读性优先

一、我有个朋友，他让 AI 写了三万行代码

我有个朋友——咱们叫他老王吧——上个月兴冲冲地跟我说：“哥们儿，我用 Claude 三天写了三万行代码，整个后端全出来了！”

我说：“恭喜你，你现在有三万行你不理解的代码了。”

老王愣了一下，然后说：“不是，我看了的，大部分都挺合理的。”

“大部分，”我重复了一下这个词，“你知道软件工程里最恐怖的词是什么吗？不是’deadline’，不是’legacy code’，甚至不是’我们重写吧’——是大部分能跑。大部分能跑意味着你不知道哪部分不能跑，而且你永远会在周五下午五点半、你老婆等你吃火锅的时候发现那部分。”

老王后来怎么样了呢？两周之后他跟我说，他花了整整十天时间 debug 一个“AI 觉得挺合理但其实完全错误”的权限校验逻辑。那个逻辑看起来无懈可击——变量命名规范，注释写得比他自己写的都好，甚至还加了单元测试。唯一的问题是：它默认所有管理员都能删除其他管理员的账号。

这就是 2026 年软件工程的真实写照：AI 能写出看起来完美的代码，但“看起来完美”和“真的完美”之间的距离，恰好就是一个资深工程师存在的意义。

二、真正的变化：你的工作不再是写代码了

让我先说一个可能会让你不舒服的事实：写代码这件事，正在变得越来越不重要。

别急着关掉这篇文章。我没说工程师不重要了。我说的是，“写代码”这个动作——就是那个你坐在那里、手指噼里啪啦敲键盘、把脑子里的逻辑变成 Python 或者 TypeScript 的过程——它在整个软件工程价值链里的占比正在急剧缩小。

这就像汽车出现之后，“驾驭马匹”这项技能变得不那么重要了，但“知道去哪里”变得更重要了。GPS 出现之后，“知道去哪里”也不那么重要了，但“决定要不要去”依然只有你自己能定。

过去二十年，我们软件工程师的日常是这样的：产品经理给你一个需求，你在脑子里把它翻译成数据结构和算法，然后花几天写代码实现它。中间你会查 Stack Overflow（或者现在查 AI），遇到几个 bug，骂几句脏话，最后提交 PR。

现在呢？你完全可以把“写代码”这一步交给 AI。但问题来了：交给 AI 之前和之后的那些事，突然变得比以往任何时候都重要。

交给 AI 之前，你需要：

  • 把模糊的需求变成精确的约束
  • 决定系统的边界在哪里
  • 定义什么是“对的”，什么是“错的”
  • 把你脑子里那些“不言自明”的规则写出来

交给 AI 之后，你需要：

  • 验证输出是否真的符合意图
  • 发现 AI 过度设计的部分
  • 识别那些“看起来对但其实不对”的逻辑
  • 确保新代码和现有系统的其余部分和谐共处

你发现了吗？真正的变化不是“AI 取代了工程师”，而是工程师的工作重心从“中间”移到了“两头”——从“执行”移到了“定义”和“验证”。

这就是我今天想聊的核心话题：Harness Engineering。

三、什么是 Harness Engineering？别被名字吓到

每次有人发明一个新术语，我的第一反应都是翻白眼。这个行业最不缺的就是 buzzword。但 Harness Engineering 这个概念确实抓住了一些真实的东西，所以我忍住了。

Harness 这个词在英文里有“马具”的意思——就是套在马身上的那套东西，让马知道往哪儿走、什么时候停、拉多重的东西。马本身力大无穷（这就是 AI），但没有 harness，它要么在原地吃草，要么一路狂奔把你的马车拉到悬崖底下去。

Harness Engineering，简单来说，就是为 AI 设计工作环境的工程学。

它的核心思想是：把隐性知识显性化，把经验变成环境。

让我举个具体例子。假设你是一个有五年经验的后端工程师，你在某电商公司工作。当你写一个新的 API endpoint 的时候，你脑子里同时在想这些事：

  1. 这个接口需要做权限校验（因为去年有个实习生忘了加，被安全团队追杀了一周）
  2. 返回数据要分页（因为有一次不分页直接把数据库搞挂了）
  3. 参数校验要在 controller 层做，不要到 service 层才报错（因为这是团队规范，三个月前才统一的）
  4. 如果涉及金额，用 decimal 不要用 float（这个不用解释吧？）
  5. 错误返回要用统一的 error code 格式（因为前端同事已经骂了无数次了）
  6. 超过 500ms 的查询要加缓存（这是 SRE 团队的红线）

这些知识在哪里？在你脑子里。 它们分散在你过去五年踩过的坑、参加过的 code review、读过的 postmortem、和同事吵过的架里。

现在你让 AI 写这个 endpoint。AI 不知道这些。它写出来的代码可能在语法上完美，在 GPT-5 的 benchmark 上得分 99.9%，但是用 float 存了金额，没加分页，错误格式和其他接口不一致。

Harness Engineering 就是把这些“脑子里的知识”变成“系统里的约束”。 不是写一份文档扔在 Confluence 上吃灰，不是在 Slack 里 @all 说“大家注意啊”——而是变成代码模板、lint 规则、CI/CD 检查、架构约束、测试断言、Prompt 上下文。让 AI 工作的时候，这些约束自动生效，就像马具一样。

这就是 Harness Engineering 的精髓：你不再是写代码的人，你是设计“AI在其中写代码的那个系统”的人。

四、从手工作坊到工厂模式——但这次人往上走了

软件工程的历史就是一部不断“往上走”的历史。

最早期，程序员要用机器码直接跟硬件对话。后来有了汇编语言，你不用记 10110000 01100001 了，写 MOV AL, 61h 就行。再后来有了 C 语言，你不用管寄存器了。再后来有了 Python，你连内存都不用管了。每一次抽象层的提升，都有人喊“程序员要失业了”，结果每一次，程序员不但没失业，反而变得更值钱了——因为他们在更高的层次上创造价值。

AI 辅助编程，本质上就是这个过程的最新一步。它把“把逻辑翻译成代码”这个动作自动化了，就像编译器把高级语言翻译成机器码一样。

但这一次有个重要的不同。

过去的每一次抽象提升，新工具都是确定性的：编译器不会“发挥”，它不会觉得你的代码太简单然后自作主张给你加个设计模式。但 AI 是概率性的——它会“创造”，它会“发挥”，它会在你没要求的时候给你来一个策略模式套工厂模式再套观察者模式的三层嵌套。

这就引出了一个全新的问题：如何约束一个有“创造力”的工具？

答案就是 Harness Engineering。你要做的不再是告诉机器“怎么做”（How），而是定义“做什么”和“不做什么”（What & What Not）。你从工匠变成了工厂设计师。

工匠亲手打造每一件作品；工厂设计师设计流水线、质检标准、原材料规格。作品的质量不再取决于工匠今天手抖没抖，而是取决于流水线设计得好不好。

这不是“人被降级了”，恰恰相反——这是人被升级了。你从一个一天能写 500 行代码的人，变成了一个一天能让 AI 正确地写 50000 行代码的人。前提是你的 harness 设计得足够好。

五、AI 的原罪：过度设计

好了，现在让我聊聊 AI 最让人头疼的毛病。不是幻觉（hallucination），不是上下文长度限制，而是一个更隐蔽、更危险的问题：过度设计。

我管这个叫“AI 架构师综合征”。

你让 AI 写一个简单的用户注册功能。你期望的是什么？一个表单，一个接口，做个参数校验，存数据库，发个验证邮件，完事。

AI 给你的是什么？一个完整的事件驱动架构，包含用户注册事件发布、消息队列消费、通知服务解耦、策略模式处理不同注册渠道、工厂模式创建不同类型用户、外加一个你永远用不到的插件系统。

它还会跟你解释：“这样做的好处是扩展性强，未来如果你需要支持多种注册方式，只需要添加一个新的策略类就行了。”

听起来很有道理对吧？但问题是：你是个五人团队的创业公司，你的注册方式就一种——手机号注册，而且你连下个月能不能发出工资都不确定。

这就是 AI 在设计阶段最常犯的错误：它默认你需要的是“最佳实践”，而不是“最适合你现在情况的实践”。 它读过太多架构书、太多设计模式教程、太多“如何构建可扩展系统”的博客文章。它就像一个刚毕业的计算机硕士，满脑子都是理论上的“正确做法”，但不知道在现实世界里，“正确做法”往往意味着“过度做法”。

我在 Fog Creek 的时候就见过太多这种事了——不过那时候干这事的是人类。每个新来的工程师都恨不得把 Gang of Four 的 23 个设计模式全用上，好证明自己不是白学的。AI 现在做的，本质上就是这件事的超大规模版本。

过度设计的真正代价是什么？不是多写了几行代码——代码是 AI 写的，它不在乎。真正的代价是：

  1. 认知负担增加了。 你现在不但要理解业务逻辑，还要理解 AI 给你加的那些你不需要的抽象层。
  2. bug 的藏身之处增多了。 每多一层抽象，就多一个 bug 可以躲的地方。
  3. 调试变得更难了。 一个简单的“用户注册失败”，你现在要在事件总线、消息队列、策略工厂之间来回找问题。
  4. 修改成本上升了。 讽刺的是，那些为了“方便未来修改”而添加的抽象层，恰恰让现在的修改变得更困难。

YAGNI——You Ain’t Gonna Need It。这个原则在 AI 时代不但没有过时，反而变得比以往任何时候都重要。因为 AI 不会帮你判断 YAGNI，它默认 YAGNI（You Are Gonna Need It）。

六、人类 Review 的真正价值：做减法

好，这就引出了一个至关重要的观点：在 AI 时代，人类 review 的核心价值不是添加东西，而是删除东西。

让我说得更直白一点：你最重要的工作，是对 AI 说“不”。

传统的 code review 是什么样的？看代码，找 bug，提建议，可能加个优化。reviewer 的价值主要体现在“发现代码里缺了什么”——缺了边界检查、缺了错误处理、缺了测试用例。

但当你 review AI 写的代码时，画风完全不一样了。AI 不会忘记写错误处理（它读过所有关于错误处理的文章），它不会忘记写测试（它知道测试的重要性），它甚至不会忘记写注释（虽然注释可能废话连篇）。AI 写的代码的问题不是“缺了什么”，而是“多了什么”。

所以，review AI 代码的时候，你要训练自己问这些问题：

  • 这个抽象层是必要的吗？ 如果去掉它，直接把逻辑写在调用方，会怎么样？
  • 这个接口需要这么通用吗？ 现在只有一个实现的接口，不是“好的设计”，是浪费。
  • 这个配置项需要这么灵活吗？ 如果一个配置项在整个生命周期内只会有一个值，那它就应该是一个常量。
  • 这个错误处理是真的需要，还是 AI 在“以防万一”？ 有些 catch 块捕获的是永远不会发生的异常。
  • 这段代码真的需要这个依赖吗？ AI 特别喜欢引入第三方库来做三行代码就能解决的事情。

我管这个叫“减法 Review”（Subtractive Review）。

传统 review 是加法——你在代码上添加你的智慧。
AI 时代的 review 是减法——你从代码里删除 AI 的过度热情。

最好的代码不是你能想到的最多的代码，而是你能去掉的最少代码之后还能工作的那版。 这句话来自圣-埃克苏佩里——对，就是写《小王子》的那哥们。他原话说的是设计，但放在代码上一样成立。

一个优秀的 Harness Engineer，最重要的能力就是知道什么时候说“这太多了，删掉”。

七、系统原语：AI 时代的“地基”

好了，到了本文最硬核的部分了。咱们聊聊系统原语（System Primitives）。

什么是系统原语？它是你系统里最基础、最底层、最频繁被复用的构建块。就像乐高积木里那些基本形状——2x4 的方块、1x1 的圆钮、那个带轮子的底座。你用这些基本形状可以搭出恐龙、城堡、飞机。搭出来的东西千变万化，但基本形状就那么几种。

在软件系统里，系统原语可能是：

  • 你的错误处理模式。 所有错误都怎么表示？怎么传播？怎么报告？
  • 你的数据访问层。 怎么读数据库？怎么处理事务？怎么做缓存？
  • 你的认证授权模型。 谁能做什么？怎么检查？在哪个层检查？
  • 你的 API 契约。 请求和响应长什么样？分页怎么做？排序怎么传？
  • 你的事件/消息模式。 组件之间怎么通信？同步还是异步？
  • 你的配置管理。 配置从哪来？怎么覆盖？怎么验证？

这些原语之所以重要，是因为它们有一个可怕的属性：它们会被 AI 放大。

好的原语被放大了？恭喜你，AI 会基于这些好的原语写出大量一致的、高质量的代码。

差的原语被放大了？恭喜你，AI 会基于这些差的原语写出大量一致的、高质量的垃圾。

让我举个血淋淋的例子。

假设你的系统里有两种错误处理模式。一半代码用 throw new Error(message) 然后在外层 catch；另一半代码用 Result<T, E> 模式，返回一个包含成功或失败信息的对象。两种都能用，但不一致。

现在你让 AI 在这个系统里写新代码。AI 看到了两种模式，它怎么选？看心情——或者更准确地说，看它在上下文窗口里最近看到的是哪种。于是你的系统里就有了第三种模式：AI 在一个函数里混用了两种（在某些路径抛异常，在另些路径返回 Result），创造了一种全新的、前所未有的混乱。

原语的质量决定了 AI 输出的质量上限。 这就像印刷术——如果你的活字模板是歪的，你印出来的每一页都是歪的，而且你印得越快，浪费的纸就越多。

所以在 AI 时代，设计好你的系统原语，是回报率最高的工程投资。 没有之一。

八、好的原语 vs 假抽象：如何分辨

说到这里，有人可能会说：“那我把所有东西都抽象一下不就好了？”

不。这就是一个巨大的陷阱。我管它叫“假抽象”（Fake Abstraction），它是好的原语的邪恶双胞胎。

好的原语和假抽象表面上看起来一模一样——它们都是“把某个模式提取出来，让大家复用”。但它们有一个根本的区别：

好的原语简化了决策。 你用了它之后，需要想的事情变少了。
假抽象转移了复杂性。 你用了它之后，需要想的事情没变少，只是换了个地方想。

来，我给你举几个例子你就明白了。

好的原语：统一的 HTTP 响应格式

1
2
3
4
5
interface ApiResponse<T> {
  success: boolean;
  data: T | null;
  error: { code: string; message: string } | null;
}

为什么这是好的原语？因为用了它之后，你（和 AI）在写任何接口的时候，不需要思考“返回值长什么样”这个问题。决策被消除了。前端同事也不需要猜每个接口的返回格式。所有人都知道，success 为 true 就看 data，为 false 就看 error。完事。

假抽象：通用事件总线

1
2
3
4
5
class EventBus {
  emit(event: string, payload: any): void;
  on(event: string, handler: (payload: any) => void): void;
  off(event: string, handler: (payload: any) => void): void;
}

为什么这是假抽象？因为它没有消除任何决策。你现在需要决定：事件叫什么名字？payload 的格式是什么？谁负责监听？监听的顺序重要吗？如果 handler 抛异常了怎么办？事件是同步还是异步？这个组件应该直接调用那个组件还是通过事件总线？

你“解决了”组件之间的耦合问题，但创造了十个新问题。而且这些新问题更难调试，因为你在代码里 grep 不到谁在调用谁——一切都隐藏在字符串类型的事件名后面。

判断一个抽象是“好的原语”还是“假抽象”的简单方法：问自己“用了它之后，我做决策的次数是变多了还是变少了？”

如果变少了——好原语，留着。
如果变多了或者没变——假抽象，删掉。
如果你需要写一篇文档来解释怎么正确使用它——那一定是假抽象。好的原语不需要说明书。

回到 AI 的话题：好的原语让 AI 更容易做对。 当系统里的错误处理只有一种方式，AI 不需要“选择”，它只会用那一种，而那一种是对的。

假抽象让 AI 更容易做错。 当系统里有一个万能事件总线，AI 会把所有它拿不准的通信都扔到事件总线上——因为那看起来像是“这个系统里推荐的做法”。

九、验证循环比更强的模型更重要

这可能是我今天说的最反直觉的一句话了：提升你工程效率的最好方式，不是用更强的 AI 模型，而是建立更好的验证循环。

我知道，这听起来不够性感。“我们升级到了 GPT-6！”听起来比“我们改进了 CI pipeline！”激动人心多了。但数据不会骗人。

让我用一个思想实验来说明。

场景 A：超强模型，弱验证
你用宇宙最强的 AI 模型，它生成代码的正确率是 95%。但你没有好的测试、没有严格的 lint 规则、没有类型检查。那 5% 的错误代码会怎么样？它悄悄混入代码库，直到某天在生产环境里爆炸。

场景 B：普通模型，强验证
你用一个普通的 AI 模型，正确率只有 80%。但你有完善的类型系统、全面的集成测试、严格的 lint 规则、自动化的安全扫描。那 20% 的错误代码会怎么样？它在 CI 阶段就被拦住了，AI 根据错误信息自动修正，最后合入代码库的正确率可能是 99%。

场景 B 的结果更好。 而且好很多。

这就是验证循环的魔力。验证循环不是“一次性检查”，而是一个反馈环：AI 生成 → 自动验证 → 发现问题 → AI 修正 → 再次验证 → 通过。这个循环每多转一圈，最终输出的质量就提升一大截。

更关键的是：验证循环是可累积的。 你今天加的一条 lint 规则，从今以后每一次 AI 生成的代码都会受到这条规则的约束。你今天写的一个集成测试，从今以后每一次代码变更都会被这个测试验证。这是复利效应。

而更强的模型呢？它是一次性收益。GPT-5 比 GPT-4 强，好，所有人都能用 GPT-5，你没有竞争优势。但你花两个月构建的那套定制化验证循环？那是你独有的。

我见过太多团队把预算花在“买更贵的 AI 订阅”上，却不愿意花时间建立基本的自动化验证。这就像买了一辆法拉利，但是不愿意花钱修路——你的法拉利在坑坑洼洼的土路上跑得还不如一辆在高速公路上的丰田卡罗拉。

实用建议： 在你考虑升级 AI 模型之前，先检查这个清单：

  1. ✅ 你的项目有类型检查吗？（TypeScript、mypy、etc.）
  2. ✅ 你有自动化测试吗？覆盖了关键路径吗？
  3. ✅ 你有 lint 规则来执行团队规范吗？
  4. ✅ 你的 CI 会在合并前自动跑这些检查吗？
  5. ✅ AI 生成的代码能自动被这些检查拦截吗？
  6. ✅ 失败的检查能自动反馈给 AI 让它修正吗？

如果上面有任何一项的答案是“否”，那你的下一步不是升级模型，而是补上这个缺口。

十、每个 Bug 都是一份没写出来的 Spec

在 Harness Engineering 的世界观里，bug 有了一个全新的含义。

传统观念里，bug 是错误、是失败、是需要修复的东西。修完了事，最多写个 postmortem 走个形式。

但在 AI 时代，每一个 bug 都在告诉你：你的系统里有一条规则没有被显性化。

让我解释一下这句话。

还记得老王的那个权限校验 bug 吗？管理员可以删除其他管理员。这个 bug 为什么会出现？因为“管理员不能删除其他管理员”这条规则，只存在于老王的脑子里。它没有被写在任何文档里，没有被编码成任何测试，没有被表达为任何约束。

对于 AI 来说，一条没有被显性化的规则，就等于不存在。

所以，当你发现一个 AI 产生的 bug 时，正确的反应不是：

  • ❌ “这个 AI 真笨”
  • ❌ “我来修一下这个 bug”
  • ❌ “下次 prompt 写清楚一点”

正确的反应是：

“这个 bug 暴露了哪条隐性规则？我怎么把这条规则变成系统约束，让这类 bug 永远不再出现？”

具体来说：

  1. 写一个测试来捕获这个具体的 bug（回归测试）
  2. 抽象出规则，看这个 bug 是否是某一类问题的具体表现
  3. 把规则编码成约束——可能是一个 lint 规则、一个架构限制、一个代码模板里的校验逻辑
  4. 更新 AI 的上下文——把这条规则加入到 AI 在工作时能看到的知识库中

这就是 Harness Engineering 的核心循环：Bug → 发现隐性规则 → 显性化 → 变成约束 → AI 下次自动遵守。

每走一遍这个循环，你的系统就强化一点。假以时日，你的系统会变得越来越健壮——不是因为 AI 变聪明了，而是因为你的 harness 变完善了。

我把这个叫做“Spec 挖矿”（Spec Mining）。每个 bug 都是一座小金矿，里面藏着一条你以前不知道自己知道的规则。你的工作就是把它挖出来，提炼成约束，铸造成原语。

最优秀的团队不是 bug 最少的团队，而是从每个 bug 里提取出最多 spec 的团队。

十一、从“写代码的人”到“划边界的人”

好了，聊了这么多，让我们总结一下工程师角色的变化。

过去，你是一个代码作者（Code Writer）。你的核心技能是：理解需求 → 设计方案 → 编写代码 → 调试测试。你的产出是代码行。你的效率用 LOC/day（虽然大家都说这不是好指标但暗地里都在数）来衡量。

现在，你正在变成一个边界定义者（Boundary Definer）。你的核心技能是：

  1. 定义系统的边界。 什么该做，什么不该做？哪些变化是允许的，哪些是不允许的？系统的不变量是什么？
  2. 设计验证策略。 怎么知道 AI 的输出是对的？什么样的测试能最有效地捕获错误？
  3. 管理复杂度预算。 系统能承受多少复杂度？哪些地方值得投入复杂度，哪些地方应该保持简单？
  4. 维护系统原语。 确保基础构建块的质量，因为它们决定了 AI 输出的质量上限。
  5. 提炼隐性知识。 把团队的经验、教训、最佳实践变成机器可执行的约束。

注意，这些技能没有一项是全新的。它们一直都是优秀工程师的核心技能。不同的是，在 AI 时代，这些技能从“锦上添花”变成了“核心竞争力”。

过去，一个工程师可以靠“写代码速度快”吃饭。现在，写代码速度快的人是 AI。你需要靠的是“定义什么代码该写”。

这就像照相机发明之后，画家不是失业了——他们进化了。他们不再需要追求“画得像照片一样真实”，因为照相机做这事更快更准。他们转向了抽象、表达、概念——那些照相机做不到的事。印象派、立体派、超现实主义，全是照相机发明之后出现的。

同理，AI 写代码之后，工程师不是失业了——我们进化了。我们不再需要追求“写代码写得又快又好”，因为 AI 做这事更快（虽然“好”还有待讨论）。我们转向了架构设计、约束定义、质量保证——那些 AI 做不到（或者做不好）的事。

十二、别被口号吓到：如何保持冷静

每隔几个月，科技媒体就会放出一个吓人的标题。

“AI 将在两年内取代所有程序员！”
“某 CEO 宣布公司将完全由 AI 写代码！”
“大模型已经能够独立完成复杂的软件项目！”

我在这个行业待了二十多年，这种标题看过无数了。只是把“AI”换成了以前的关键词而已：

  • 2000 年：“外包将在五年内取代所有美国程序员！”
  • 2005 年：“Rails/Django 这样的框架将让 90% 的程序员失业！”
  • 2010 年：“云计算意味着你不再需要运维工程师！”
  • 2015 年：“No-code/Low-code 将消灭大部分开发者岗位！”
  • 2020 年：“Copilot 出来了，初级程序员完蛋了！”

结果呢？2026 年了，程序员比以往任何时候都多，工资比以往任何时候都高（好吧，这取决于你在哪个市场），软件行业比以往任何时候都大。

为什么？因为这些预言犯了一个经典错误：它们高估了技术的替代效应，低估了技术的创造效应。

AI 确实让写代码变简单了。但写代码变简单之后发生了什么？更多的人开始构建软件，更多的需求被提出来，更多的系统需要被设计、集成、维护、升级。需求的增长速度远远超过了效率提升的速度。

这就像洗衣机的发明。洗衣机让洗衣服变简单了，但人们没有因此少洗衣服——他们开始洗更多的衣服，换衣服的频率更高了，对干净的标准更高了。洗衣机创造的需求比它消灭的劳动力多得多。

所以，当你看到“AI 取代程序员”的标题时，深呼吸，然后问自己：

  1. 这个说法的前提是什么？ 通常前提是“软件需求是固定的”，但现实是软件需求在快速增长。
  2. 这个说法忽略了什么？ 通常忽略了维护、集成、安全、合规、性能优化这些“不够性感但超级重要”的工作。
  3. 历史上类似的预言实现了吗？ 通常没有。
  4. 说这话的人有什么动机？ VC 要炒热度、媒体要流量、CEO 要股价。Take it with a grain of salt。

你不需要恐慌，但你需要进化。恐慌让你做出愚蠢的决定（比如花三个月全职学 prompt engineering），进化让你做出聪明的决定（比如花三个月构建你团队的 Harness Engineering 体系）。

十三、一个普通团队的实用工作流

理论讲够了，让我们来点实际的。假设你是一个 5-15 人的普通开发团队，没有 Google 的资源，也没有硅谷的光环。你怎么在日常工作中实践 Harness Engineering？

下面是我推荐的“AI 协作操作系统”，一共六个层次，从下到上：

第一层：原语层（花一周搞定）

把你系统里最基础的模式统一了。不需要一步到位，先挑最高频的三五个：

  • 统一 API 响应格式
  • 统一错误处理模式
  • 统一数据库访问方式
  • 统一认证鉴权检查方式
  • 统一日志格式

把这些写成代码模板或者基础库。AI 在生成新代码时，可以参考这些模板。

第二层：约束层（花一到两周持续完善）

把团队规范变成自动化检查：

  • ESLint / Pylint / Clippy 规则，覆盖你们的编码规范
  • 类型检查要严格开启（strict: true，别偷懒）
  • 自定义 lint 规则，覆盖业务特有的约束（比如“金额字段必须用 Decimal 类型”）
  • git hooks 或 CI checks，确保这些规则在每次提交时都跑

第三层：验证层（持续投入）

建立多层次的自动化验证：

  • 单元测试：覆盖核心业务逻辑
  • 集成测试：覆盖关键用户流程
  • 契约测试：确保 API 契约不被意外破坏
  • 安全扫描：自动检测常见安全问题
  • 性能基线：关键路径的响应时间不能超过阈值

第四层：上下文层（花几天搭建，持续维护）

让 AI 在工作时能获取到足够的上下文：

  • 项目级的 AI 配置文件（比如 .cursorrules、.github/copilot-instructions.md），描述项目的技术栈、架构决策、核心规范
  • 关键模块的架构决策记录（ADR），解释“为什么这样做”而不是“怎么做”
  • 常见错误模式的列表（“AI 在这个项目里容易犯的错”）
  • 核心原语的使用示例

第五层：反馈层（日常实践）

建立从 bug 到 spec 的转化机制：

  • 每个 AI 产生的 bug，都要做 root cause analysis：“这个 bug 暴露了什么隐性规则？”
  • 每条新发现的隐性规则，都要变成约束层或上下文层的一部分
  • 定期回顾：哪类 bug 最频繁？对应的原语或约束是否需要改进？

第六层：度量层（每月回顾）

跟踪你的 Harness Engineering 效果：

  • AI 生成的代码的首次通过率（First Pass Rate）：有多少 AI 生成的代码能一次通过所有自动化检查？
  • Review 中的“减法率”：review 中有多少反馈是“删掉这个”vs“加上这个”？
  • Bug 到 Spec 的转化率：发现的 bug 中有多少被转化成了系统约束？
  • 原语覆盖率：系统中有多少模式被统一的原语覆盖了？

你不需要一开始就追求完美。从第一层开始，每周改进一点，三个月后你的团队就会和大部分团队拉开显著差距。

十四、真正的竞争优势：谁最快把经验变成系统

让我以一个在这个行业干了多年的老家伙的身份，给你一个最终的判断：

在 AI 时代，真正的竞争优势不再是“谁有最好的工程师”，而是“谁能最快地把组织经验变成 AI 可执行的系统”。

为什么？因为 AI 模型是公开的——你能用 Claude，你的竞争对手也能用。AI 的基础能力是一个公共资源，它不构成差异化优势。

真正的差异在于：你的组织有什么独特的知识？你的团队踩过什么独特的坑？你的业务有什么独特的约束？这些东西，是 AI 在公开数据里学不到的。

而 Harness Engineering 就是把这些独特的东西系统化的方法。

想象两个竞争对手，A 公司和 B 公司。

A 公司有一群顶级工程师，每个人脑子里都有丰富的经验。但这些经验只存在于个人的大脑中。当 AI 来了，这些工程师各自指导 AI 干活，效果参差不齐——取决于每个人的 prompt 写得好不好、当天心情怎么样、有没有忘记提到某个重要约束。

B 公司的工程师水平参差不齐，但他们花了六个月时间做了一件事：把组织里积累的所有经验、规范、约束，系统化地编码成了原语、lint 规则、测试、CI 检查、AI 上下文。现在，即使是团队里最新来的工程师，配合 AI，也能产出接近最高水准的代码——因为那些“老司机的智慧”已经被嵌入到了系统里。

B 公司赢了。 不是因为他们的 AI 更强，不是因为他们的工程师更厉害，而是因为他们的 harness 更完善。

这就是 Harness Engineering 的终极价值：它把组织的集体智慧从“人脑里的隐性知识”变成了“系统里的显性约束”，让每一个人（和每一个 AI agent）都能站在整个组织的经验之上工作。

十五、最后一个比喻

我想用一个比喻结束这篇文章。

你有没有观察过高速公路？高速公路上的车速很快——比普通公路快得多。但高速公路的事故率反而更低。为什么？

因为高速公路有极其完善的约束系统：

  • 车道标线告诉你在哪里开
  • 护栏防止你冲出路面
  • 限速标志告诉你多快是安全的
  • 出入口的设计减少了交叉冲突
  • 路面的纹理和坡度引导雨水排走
  • 甚至连路边的反光标也是一种约束——它在夜间标示出道路的边界

这些约束不是在“限制”驾驶员——它们是在“解放”驾驶员。正因为有这些约束，驾驶员才能放心地开到 120 码。如果是一条没有标线、没有护栏、没有限速的土路，你连 40 码都不敢开。

Harness Engineering 就是为 AI 修高速公路。

AI 是一辆动力无限的车。但如果你让它在一条没有标线的土路上跑，它要么翻车，要么走错方向。

你的工作，不是去教 AI 怎么开车——它已经会了，可能比你还溜。你的工作是修路。画标线。立护栏。设计合理的出入口。确保路面质量过关。

路修好了，AI 自然跑得又快又稳。路修得烂，再好的 AI 也只能在泥地里打转。

所以，别再纠结“AI 会不会取代我”了。问自己一个更有价值的问题：

“我修的这条路，够不够好？”

写到最后我想起了我那个朋友老王。上周他又给我发消息了，说他花了一个月时间重构了项目，统一了错误处理和 API 格式，加了 200 多条 lint 规则和一套集成测试。然后让 AI 在这个新框架里重写了之前那个权限模块。

“这次怎么样？”我问。

“AI 写了 800 行代码，CI 全过了，一个 bug 都没有。”

“恭喜你，”我说，“你终于不是在让 AI 写代码了。你是在为 AI 设计系统。”

老王在消息那头沉默了几秒，然后回了我一个字：

“懂。”