从让 AI 写代码到为 AI 设计系统
去年我看到一件很有意思的事。一个朋友的团队刚接入了最新的代码生成模型，生产力据说提升了三倍。但三个月后，他们的代码库变成了一团不可维护的意大利面。Bug 数量翻了五倍，每次修一个地方就冒出两个新问题。他们困惑极了——AI 明明写得又快又好，怎么整个系统反而更烂了？
我听完想了很久。后来意识到，这可能是我们这个行业正在经历的最重要的转型信号之一。
问题不在 AI 写的代码质量——事实上那些代码单独看都挺漂亮的。问题在于没有人为 AI 设计一个它能正确工作的环境。就好比你雇了一个打字速度极快的实习生，但你没告诉他公司的代码规范、架构约定、以及哪些地方绝对不能碰。他打得越快，灾难来得越快。
这就是我想聊的：软件工程正在发生的真正变化，不是“AI 取代程序员”，而是工程师的核心工作从“写代码”变成了“设计让 AI 能正确工作的系统”。
让我先说说我观察到的一个规律。
每当一种新的生产力工具出现，人们总会经历同样的三个阶段。第一阶段是兴奋：哇，太快了！第二阶段是混乱：怎么到处都是问题？第三阶段是觉醒：哦，原来我需要换一种方式来使用这个工具。
打印机刚普及的时候，人们以为任何人都能做出漂亮的排版。结果满大街都是用 Comic Sans 写的通知单和用十种字体堆成的传单。后来人们才意识到，打印机放大的不是设计能力，而是设计决策——好的设计决策被放大成好的输出，坏的设计决策被放大成灾难。
AI 写代码这件事，一模一样。
当你让 AI 在一个设计良好的系统里写代码，它会产出惊人的成果。当你让它在一个没有约束的真空里写代码，它会以极高的效率制造混乱。AI 放大的不是代码能力，而是系统设计决策。
这就引出了一个有点反直觉的结论：AI 越强大，系统设计就越重要。不是“不那么重要了”，而是“比以前任何时候都重要”。
我最近开始用一个词来描述这种新的工程实践：Harness Engineering——“驾驭工程”。
Harness 这个词用得很准确。你不是在“使用”AI，你是在“驾驭”它。就像驾驭一匹马——马有自己的力量和速度，但如果没有缰绳和方向，那股力量可能会把你摔下悬崖。
Harness Engineering 的核心，说白了就一件事：把隐性知识变成显性知识，把个人经验变成环境约束。
这话听起来很抽象，让我举个具体的例子。
假设你的团队有一条不成文的规矩：所有 API 的错误处理都要遵循一个特定的模式——先记日志，再包装错误信息，最后返回统一格式的响应。这条规矩存在于每个资深工程师的脑子里。新人来了，靠 code review 慢慢学会。大家都觉得这是“常识”。
但 AI 不知道这条“常识”。
你让它写一个新的 API endpoint，它可能写出完全不同的错误处理方式——也许技术上完全正确，甚至在某些方面更“优雅”——但它和你系统里其他几百个 endpoint 的风格完全不一致。积累几十个这样的不一致，你的代码库就开始分裂了。
Harness Engineering 要求你把这种隐性知识写出来。不是写在 wiki 里让人去读（人都不一定会读，何况 AI），而是编码进系统本身——变成模板、变成 linter 规则、变成测试用例、变成 AI 的 system prompt。让 AI 不可能不遵循它。
你可能会说：这不就是写文档和定规范吗？我们一直在做啊。
是的，但有个关键区别。以前你定规范，目的是让人理解和遵守。人是有判断力的，即使规范写得不够清晰，一个有经验的工程师也能“猜到”你的意思。但 AI 是字面意义上的“照章办事”。你说“保持简单”，它理解的“简单”和你理解的可能完全不同。
所以 Harness Engineering 的第一步，往往是一个痛苦但必要的过程：你必须把所有那些“大家都知道”的东西，用机器能理解的精确语言表达出来。 这个过程会迫使你重新审视很多从未被质疑过的假设，经常会发现那些“大家都知道”的东西，其实大家理解得都不一样。
说来讽刺——AI 写代码这件事，反而帮助人类工程师更深刻地理解了自己的系统。
有些人听到这里会紧张：这是不是说程序员要失业了？
完全不是。实际上发生的事情更有意思：软件工程正在从“手艺”模式走向“工厂”模式，而人类在这个过程中是向上走，不是向外走。
让我解释一下这个比喻。
手艺模式是什么？就是一个熟练的工匠，从头到尾把一件东西做出来。他选材料、定尺寸、做切割、组装、打磨。每个步骤都需要他的判断和技能。这就是传统的软件工程——一个程序员拿到需求，设计方案，写代码，调试，部署。
工厂模式呢？不是说取消了工匠。而是把工匠的知识“编码”进了生产流程。流水线上的每个环节都内嵌了工匠的经验——这个模具的角度、那个焊接的温度、这个检测的标准。有了这些，普通工人（在我们的语境里就是 AI）也能产出高质量的东西。
但谁在设计这些流程？谁在决定模具的角度？谁在制定检测的标准？
是工匠。他们从“做东西的人”变成了“设计做东西的方式的人”。他们不是被取代了，他们是升级了。
软件工程也一样。以前你一天写 200 行代码。现在 AI 一天写 2000 行。但那 2000 行代码的质量，完全取决于你设计的系统原语、约束边界、和验证流程。你的杠杆率提高了十倍——你的每一个设计决策，影响的代码量是以前的十倍。
这其实比以前的工作更难，也更有价值。
说实话，如果你仔细观察，最顶尖的工程师一直都在做这件事。他们最大的贡献从来不是自己写的那些代码，而是他们设计的那些架构、接口、约定——那些让其他所有人（现在包括 AI）都能写出好代码的东西。Harness Engineering 只是让这个趋势更加显性化了。
好了，现在让我聊聊一个很实际的问题：AI 在“设计”这个环节上的一个严重缺陷。
我观察到一个反复出现的模式。你给 AI 一个任务，比如“设计一个用户通知系统”。它会给你一个非常完整、非常“工程化”的方案：抽象工厂模式、策略模式、观察者模式、一个消息队列、一个配置中心、一个可插拔的模板引擎……
看起来很专业，对吧？问题是：你的实际需求可能只是给用户发个邮件。
AI 有一种系统性的“过度设计”倾向。 它在训练数据里见过太多复杂系统，对复杂性有一种本能的偏好。它不会“偷懒”——但在软件工程里，“偷懒”其实是一种美德。能用三行代码解决的问题，就不应该用一个框架。
这不是说 AI 不聪明。恰恰相反，这是因为 AI太聪明了——它能想到所有可能的扩展场景、所有潜在的需求变化、所有“如果未来需要 XXX”的情况。然后它会预防性地为所有这些可能性做设计。
但正如我们在 YC 反复告诉创业者的：不要解决你还没有的问题。 软件工程也是一样。那些“未来可能需要”的灵活性，在当下就是纯粹的复杂性负担。每一层不必要的抽象都是一笔技术债务，而且是那种最隐蔽的技术债务——因为它看起来很“干净”、很“架构化”。
这就是为什么人类审查在 AI 时代不是变得不重要了，而是变得至关重要了。
但这里有个微妙的地方。人类审查 AI 代码，最重要的工作不是“添加”——不是去补充 AI 遗漏的功能，不是去添加更多的边界情况处理。最重要的工作是做减法。
你知道米开朗基罗怎么说雕塑的吗？他说雕塑就是把多余的石头去掉，大卫一直就在那块大理石里面。对 AI 生成的代码做审查，本质上就是雕塑——你要把所有不该存在的东西去掉。
我见过一个很有经验的 tech lead 审查 AI 代码。他的修改记录几乎全是删除。删掉不必要的抽象层。删掉“以防万一”的配置选项。删掉只被使用一次的接口定义。删掉那些看起来很优雅但增加了理解成本的设计模式。
他说了一句很精辟的话：“AI 写代码像一个刚毕业的名校优等生——技术上什么都会，但还没学会不做什么。”
“不做什么”这件事，可能是软件工程中最难学也最有价值的技能。它需要经验，需要对业务的深刻理解，需要判断力——哪些复杂性是值得承担的，哪些只是看起来很专业但实际上在添乱。
说实话，这个能力连很多人类工程师都不具备。但至少人类可以通过犯错来学习。AI 不会——它没有“维护自己三年前写的烂代码”的痛苦记忆。所以它不会自然地发展出对不必要复杂性的厌恶感。
这就是人类审查的核心价值：做减法，而不是做加法。 你的工作不是让 AI 的输出“更完整”，而是让它“更精简”。不是问“还缺什么”，而是问“哪些可以去掉”。
这是一种全新的 code review 心态。以前 review 是在找 bug、找遗漏。现在 review 更多是在找“过度”——过度设计、过度抽象、过度防御。
现在让我谈谈一个我认为被严重低估的概念：系统原语（System Primitives）。
什么是系统原语？就是你系统里最基础的构建块——你的数据模型定义方式、你的 API 设计规范、你的错误处理模式、你的日志格式、你的鉴权流程。这些东西就像建筑的地基和承重结构。
为什么它们在 AI 时代变得特别重要？因为AI 会放大一切——好的和坏的。
想象一下。你定义了一个设计良好的数据库模型模式。AI 每次生成新的数据模型时，都会遵循这个模式。一百个模型，全部一致，全部清晰。数据迁移和查询都变得可预测和可维护。好的原语被放大了一百倍。
反过来。你的数据库模型没有清晰的规范，AI 第一次写了一个风格，第二次写了另一个，第三次又来一个。一百个模型，一百种风格。你的数据层变成了一个考古遗址，每一层代表一个不同的“文明”。坏的原语——或者说缺失的原语——也被放大了一百倍。
你的系统原语就是 AI 编程的倍增器。 好的原语，AI 会生成海量一致的高质量代码。坏的原语，AI 会高效地把混乱铺满整个代码库。
让我再展开说说这个逻辑。以前，一个工程师一天写 200 行代码。即使他的风格有点飘忽不定，影响也是有限的——200 行的不一致性，人还能兜得住。但现在 AI 一天写 2000 行。如果这 2000 行代码风格不一致、模式不统一，你很快就会失去对代码库的控制。
所以在 AI 时代，系统原语是你最重要的杠杆点。你投入一小时来打磨一个好的原语，可能意味着 AI 在接下来的几个月里生成的代码都是高质量的。反过来，你偷懒跳过了这一步，可能意味着几个月后你面对的是一个无法维护的代码库。
这就是为什么我说，在 Harness Engineering 的世界里，设计一个好的错误处理模式，可能比写一百个 API 更有价值。
但什么是“好的”原语？这个问题比看起来要难。
让我先说说什么是假原语——或者说“假抽象”。
假抽象是那些看起来很像原语，但实际上并没有简化任何东西的东西。最常见的假抽象就是“为了抽象而抽象”——把一个只用一次的操作包装成一个通用接口，然后那个接口永远只有一个实现。
比如，你可能定义了一个INotificationService接口，然后只有一个EmailNotificationService实现。你跟自己说“未来可能会有短信通知、推送通知”。但如果“未来”在三年后都没有来，你这三年来一直在维护一个毫无价值的抽象层。
好的原语和假抽象的区别在于一个简单的测试：它是否真的减少了你需要思考的东西？
一个好的数据库查询模式，让你不用每次都思考连接池、超时、重试。它确实减少了认知负担。一个好的 API 响应格式，让前端不用每次都猜返回值的结构。它确实减少了沟通成本。
但一个“通用消息处理框架”如果只处理一种消息，它没有减少任何东西——反而增加了一层你需要理解的东西。
在 AI 时代，区分真假原语变得更加关键。因为 AI 会忠实地使用你给它的任何原语——不管是真的还是假的。假原语不会被 AI“识破”。它会认真地、勤勉地使用你那个毫无必要的抽象层，在整个代码库里铺满间接引用和多余的接口。
所以在设计系统原语时，有一个我觉得非常实用的原则：如果你不能在一句话里解释清楚这个原语解决了什么问题，它可能就不是一个好的原语。
好的原语应该是显而易见的。当你看到它的时候，你的反应应该是“这当然应该是这样”，而不是“哦，这很巧妙”。巧妙的设计通常意味着有人在炫技，而炫技和好的工程是对立的。
让我列几个我见过的好原语的例子：
一个统一的 API 响应结构：成功就是{data: ...}，失败就是{error: {code: ..., message: ...}}。简单到几乎无聊。但这个“无聊”的约定意味着整个系统的错误处理都是一致的，AI 每次生成新 API 时都自然遵循这个模式。
一个标准化的数据库迁移流程：每次修改数据库结构，都生成一个带时间戳的迁移文件，包含up和down两个方法。这个模式存在了几十年，“无聊”到了极点。但它让数据库变更变得可追溯、可回滚、可自动化——对 AI 来说尤其友好，因为每次迁移都遵循完全相同的模板。
一个明确的目录结构约定：/routes放路由，/services放业务逻辑，/models放数据模型。不需要任何文档解释——结构本身就是文档。AI 看到这个结构，就知道新代码应该放在哪里。
注意到共同点了吗？好的原语都很无聊。 它们不展示任何人的聪明才智。它们只是让事情变得可预测。而可预测性，在 AI 时代，就是最大的价值。
因为 AI 最擅长的就是在给定规则下执行。规则越清晰、越一致，AI 的输出就越好。好的原语就是最好的规则。
让我接着说一个我觉得很多人还没充分意识到的真相：验证循环比更强的模型重要得多。
这句话值得反复咀嚼。
现在业界有一种迷思：AI 生成的代码不够好？等下一代模型就好了。GPT-6、Claude-5、Gemini-4——总有一个足够强大的模型能解决所有问题。
这是一种非常危险的想法。
原因很简单：再强大的模型也无法保证每次输出都是正确的。这不是当前技术的局限，这是这类系统的本质特征。语言模型是概率性的——它给你的是“最可能正确”的答案，而不是“保证正确”的答案。在某些领域，“最可能正确”就够了。但在软件工程里，一个“几乎正确”的程序就是一个错误的程序。代码要么能跑，要么不能。
所以，与其等待一个“足够完美”的模型（它永远不会来），不如投资建设验证循环——让 AI 的每一次输出都经过自动化的检查。
什么是验证循环？就是 AI 生成代码后，自动触发的一系列检查：
类型检查通过了吗？Lint 规则通过了吗？单元测试通过了吗？集成测试通过了吗？和现有代码的接口兼容吗？符合我们的架构规范吗？
如果任何一个检查失败，AI 会得到反馈，然后重新生成。这个循环可以跑很多轮——直到所有检查都通过。
这里的关键洞察是：一个中等能力的模型加上一个好的验证循环，几乎总是比一个超强模型裸奔要好。
为什么？因为验证循环能捕获的错误类型远远超过模型能力的提升。一个 GPT-6 裸奔可能 95% 的时候给你正确答案。但那 5% 的错误分散在代码库的各个角落，你没有任何系统性的方式来发现它们。而一个 GPT-4 加上完善的验证循环，可能能捕获 99% 的错误——因为检查是确定性的、全面的、不会遗漏的。
这就像自动驾驶。你可以投入所有资源来训练一个“完美”的驾驶模型。但更有效的策略是：一个不错的驾驶模型，加上车道保持系统、碰撞预警、自动刹车——多层验证和保护。没有哪个单独的组件是完美的，但它们组合在一起，比任何单独的“完美模型”都安全。
我见过的最高效的 AI 编程团队，都不是在用最先进的模型。他们用的是最成熟的验证体系。他们的 CI/CD 管道里有几十个自动化检查，AI 生成的每一行代码都要通过所有检查才能合并。模型的选择反而是次要的——因为验证循环会兜住大部分错误。
所以如果你问我，团队应该把时间花在哪里——是研究最新的模型，还是完善验证循环——我的回答毫不犹豫：投资验证循环。 模型会不断升级，但好的验证体系是永恒的基础设施。每一个你今天写的测试，明天还会继续保护你的代码。
说到验证循环，让我分享一个我特别喜欢的观察：每一个 bug 都在揭示一条未被写下的规格说明。
这句话不是我说的，但我觉得它非常深刻。尤其在 AI 编程的语境下。
想想看。AI 写了一段代码，出了一个 bug。这个 bug 是怎么来的？不是因为 AI“不小心”——AI 没有“不小心”这回事。它是在忠实地执行它理解到的规则。bug 的出现，说明 AI 理解的规则和你期望的规则之间有差距。
而那个差距，就是一条你以为是“显而易见”但从未明确表达的规格说明。
举个例子。AI 生成了一个用户注册的函数。一切都好，除了一件事：它没有检查邮箱格式。你可能觉得“检查邮箱格式”是常识。但你从未在任何地方明确规定“所有用户输入都必须经过格式验证”。AI 不会假设没有被明确要求的事情。
当你修复这个 bug 时，你不应该只是加一个邮箱验证。你应该退后一步，问自己：这个 bug 揭示了什么未被写下的规则？ 在这个例子里，答案可能是“所有用户输入都必须经过格式验证”。把这条规则写进你的系统规范。然后 AI 在未来处理所有用户输入时，都会自动包含格式验证。
一个 bug 修复了一个 bug。一条规则修复了一类 bug。
这是一种完全不同的 debug 心态。传统的 debug 是“找到问题，修复问题”。Harness Engineering 的 debug 是“找到问题，发现它揭示的隐性规则，把规则显性化”。每一个 bug 都是一次学习机会——不是学习“这段代码怎么修”，而是学习“我的系统规范里还缺什么”。
我见过一些团队维护一个“规则日志”——每次 AI 的 bug 被修复时，都记录下这个 bug 揭示的规则。几个月后，这个日志变成了一份非常有价值的文档：它是团队隐性知识的明确化，是系统边界条件的完整目录。而且这份文档是“活”的——它在持续增长，每个 bug 都让它更完整。
这就是 Harness Engineering 最优雅的地方：它把失败转化为系统改进。不是“AI 又犯错了”，而是“我们又发现了一条需要明确的规则”。失败不是挫折，而是进步的信号。
聊了这么多概念，让我说说更宏观的视角：人类工程师的角色到底在怎样变化。
传统的比喻是：程序员是“码农”——写代码的人。更好的比喻可能是“工匠”——设计并制作软件的人。但在 AI 时代，我觉得最准确的比喻是：“边界定义者”。
什么意思？
软件系统归根结底就是一系列的边界。数据的边界：什么样的数据是合法的，什么不是。行为的边界：系统在这种情况下应该怎么做，在那种情况下应该怎么做。安全的边界：谁能访问什么，不能访问什么。性能的边界：响应时间不能超过多少，内存不能用超过多少。
以前，工程师既定义这些边界，又在边界内填充实现。现在，AI 越来越能处理“填充”的部分。但“定义边界”这件事——决定什么应该存在，什么不应该存在，什么是正确的行为，什么是不可接受的——这依然是、而且越来越是人类的工作。
因为定义边界需要理解业务。需要知道用户真正想要什么（而不是他们说他们想要什么）。需要在矛盾的需求之间做权衡。需要判断什么复杂性值得承担，什么可以省略。这些都是 AI 目前做不到的事情——不是因为技术限制，而是因为这些判断需要对“什么是重要的”有一种深层的、基于经验的直觉。
所以，如果你是一个工程师，想知道自己在 AI 时代的价值在哪里，答案就是：你定义边界的能力。
你能多准确地定义出“正确”的含义？你能多清晰地划定系统的责任范围？你能多精确地表达出“这个可以简化，那个不能”的判断？
这些能力不是通过刷 LeetCode 培养的。它们是通过多年的工程实践、通过维护大型系统、通过在生产环境里经历各种灾难培养出来的。AI 可能会让“写代码”这个技能的价值下降，但“定义边界”这个技能的价值只会上升。
这也解释了为什么经验丰富的工程师在 AI 时代反而更值钱了。他们脑子里的那些“隐性知识”——那些“说不清但就是知道”的东西——正是 AI 最需要被告知的东西。一个有二十年经验的工程师，他的价值不在于他能写多快的代码，而在于他知道哪些代码不该写。
好了，让我换个话题聊聊情绪管理。因为我觉得很多程序员现在过得很焦虑，这种焦虑是没有必要的。
每隔几个月就有一个新的爆炸性标题：“AI 将在 X 年内取代所有程序员！”“这个新模型可以独立完成整个项目！”“编程已死！”
我理解这种标题为什么会让人焦虑。但让我告诉你一些经验：任何说“X 已死”的人，通常对 X 没有深入的理解。
编程没有死。就像电子表格没有杀死会计师，ATM 机没有杀死银行柜员（实际上柜员数量在 ATM 普及后反而增加了），AI 也不会杀死程序员。
但工作的内容确实在变。这是关键——你需要适应变化，但不需要恐惧变化。
让我给你一个简单的思维框架来处理每一个炒作口号。
第一，问自己：“这个 demo 是在理想条件下跑的，还是在真实生产环境里跑的？” 绝大多数令人震惊的 demo 都是精心挑选的最佳案例。在真实环境里——有遗留代码、有奇怪的业务逻辑、有不合理的性能要求、有十七个微服务互相调用——情况完全不同。
第二，问自己：“这个能力是 AI 独立完成的，还是有人在背后做了大量设计和引导工作？” 我见过很多“AI 独立完成整个项目”的案例，仔细一看，有个资深工程师花了三天设计系统架构、定义接口、编写测试用例、设置验证流程。AI 完成了编码部分——但那只是整个工程工作的一部分。
第三，问自己：“这个变化是淘汰了人，还是改变了人的工作内容？” 通常是后者。Excel 没有让人失业，它让人从手动计算转向了数据分析。AI 也不会让程序员失业，它让程序员从写代码转向设计系统。
所以当你看到下一个“编程已死”的标题时，深呼吸。然后去完善你的系统原语。
说了很多理念，现在让我聊聊实操。一个普通团队，明天就可以开始做的事情是什么？
我见过很多团队被 Harness Engineering 这类概念搞得很困惑——觉得要做的事情太多了，不知道从哪里开始。所以让我给一个非常务实的“工作流操作系统”。
第一步：审计你的隐性知识。
花一周时间，让团队里每个人写下他们在 code review 时经常给出的反馈。“不要这样处理错误”、“这个地方应该加日志”、“这种命名不符合我们的规范”——把所有这些收集起来。你会发现很多重复的主题。这些重复出现的主题，就是你最重要的未被文档化的规则。
第二步：把最高频的规则变成机器可执行的约束。
不是写成文档——文档没人读，AI 也不一定会遵循。而是变成 lint 规则、变成测试用例、变成代码模板、变成 AI 的 system prompt。你要确保这些规则是不可能被忽略的。
比如，如果你的团队规定所有 API 都必须返回统一格式的响应，那就写一个中间件来强制执行，写一个测试来验证，写一个模板让 AI 生成新 API 时自动使用。三重保障。
第三步：建立验证循环。
从最简单的开始：类型检查和 lint。然后逐步添加：单元测试、集成测试、架构合规检查。不需要一次到位——任何一个验证检查都比没有好。
关键是要让验证循环自动触发。不要依赖人记得去跑测试。AI 每次生成代码，验证循环就应该自动启动。如果检查失败，AI 自动收到反馈并重试。人类只需要在验证循环无法自动解决的问题上介入。
第四步：维护“规则日志”。
每次你发现 AI 犯了一个你认为“不应该犯”的错误，问自己：是哪条规则没被明确？把这条规则记录下来，然后决定如何将它编码进系统。这个日志会越来越长，你的系统也会越来越健壮。
第五步：定期回顾和精简。
每个月回头看看你的规则和原语。有没有过度设计的？有没有互相矛盾的？有没有已经不再需要的？规则系统也需要“做减法”——不然它本身也会变成不可维护的技术债务。
这五步不需要一次全部实施。你可以先做第一步和第二步，运行两周，看看效果，然后再添加后面的步骤。关键是开始做——不完美的开始永远好过完美的计划。
最后让我说说我觉得这一切意味着什么——从更长远的视角。
在接下来的几年里，AI 模型会继续快速进步。更大的上下文窗口、更强的推理能力、更好的代码生成质量。这些进步是不可避免的，而且速度可能超出大多数人的预期。
但有一件事不会因此改变：AI 的输出质量永远受限于输入它的系统设计质量。 再强的模型，在一个混乱的系统里也只会产出更多的混乱。再弱的模型，在一个设计精良的系统里也能产出可用的代码。
这意味着什么？
这意味着真正的竞争优势不是谁用了最新的模型，而是谁最快地把组织经验转化为 AI 可执行的系统。
想想看。两个公司，用同样的 AI 模型。公司 A 有二十年的行业经验，但这些经验全在老员工的脑子里，从来没有被系统化。公司 B 只有五年经验，但他们花了大量时间把每一条学到的教训都编码进了他们的系统原语、验证循环、和 AI 工作流。
哪个公司的 AI 编程效率更高？
毫无疑问是公司 B。因为 AI 不能读你员工的脑子。它只能使用被明确表达出来的知识。二十年的隐性经验，如果不被显性化，对 AI 来说就是零。五年的经验，如果被完整地编码进系统，对 AI 来说就是一座金矿。
这就是 Harness Engineering 的终极意义：它是把组织智慧从人的脑子里解放出来，编码进系统本身的过程。
这个过程并不容易。它需要你坦诚地面对很多从未被质疑过的假设。它需要你承认很多“常识”其实并不是常识。它需要你投入时间去做那些看起来“不是在写代码”的工作——定义规范、设计模板、建设验证流程。
但这些工作的杠杆率是惊人的。一个好的系统原语可以影响 AI 生成的上万行代码。一个好的验证循环可以在每天的每一分钟捕获错误。一条被明确表达的规则可以永远防止一类 bug。
我们正处在软件工程历史上一个独特的转折点。AI 不会取代工程师——它会让工程师的工作变得更加有趣、更加有价值、也更加困难。因为设计系统比写代码难得多。
但说实话？设计系统也比写代码有趣得多。
如果你只记住这篇文章的一件事，我希望是这个：
别再问“AI 能不能写代码”了。 当然能，而且只会越来越好。真正值得问的问题是：“我给 AI 搭建的系统，值不值得它在里面高效运转？”
因为到最后，决定输出质量的不是 AI 的能力上限，而是你为它定义的系统边界。你的原语越好，AI 越强大。你的验证越严密，你就越能信任 AI 的输出。你把越多的隐性知识变成显性规则，AI 就越像你团队里一个真正可靠的成员。
工程师的价值不会消失。它只是从“我能写什么代码”变成了“我能设计什么系统”。
而这，才是我们这个行业真正令人兴奋的地方。