这场分享，我会从一个很荒诞的画面讲起#

如果你在 2023 年初路过我的电脑屏幕，大概会看到一个很荒诞的场景：

我在 ChatGPT 的对话框里写代码，复制到编辑器，运行，报错，再把错误信息贴回去，等它改，再复制，再运行，再报错。

现在回头看，这根本不是什么高级工作流，本质上还是“人肉搬运 + 人肉调试”。只是以前去 CSDN、去 StackOverflow 找答案，现在换成了一个聊天窗口而已。

但就是从那个时候起，我已经隐隐感觉到：这东西会改变一切。

后来我一路从补全、IDE、SpecDriven、CLI、浏览器自动化，踩到 MultiAgent 和全流程接管。中间也不是没怀疑过自己。

大学参加 HackWeek 的时候，评委批评我的文档“AI 味太浓”，潜台词就是：你不能太依赖 AI。

我后来想了很久，最后得出的结论很直接：

他们不是比我更有经验，他们只是比我更难改变。

所以今天这场分享，我不是想做工具测评，也不是想讲“哪个产品最强”。我更想讲清楚一个更底层的问题：

为什么今天很多人会觉得 AI 一会儿像神，一会儿像神经病；以及如果不想继续靠运气写代码，一条更稳的 AI Native 工程路线到底长什么样。

Important

如果正文是项目主线版，这篇就是分享版。

它不会展开到正文那种密度，但它会尽量保留整本书最关键的判断顺序，也会保留这套方法为什么对我有用的真实出发点。

先承认一件事：好的教程其实并不少#

这两年我看过不少写得很用心的资料。

有些资料特别适合当“企业 AI Coding 能力地图”来看。比如 Trae 官方教程，会把 Context Engineering、Skills、Spec、Rules、MCP、智能体这些模块拆得很清楚，也会配很多企业场景里的实战案例。这样的材料很有价值，因为它们能让人快速知道：现在这条赛道上到底有哪些关键模块、哪些模块已经有人认真踩过坑。

举个很直接的例子：

• 如果现在在公司里推动 AI Coding，但脑子里只有一个模糊想法，连 Rules、Skills、Spec、MCP 这些模块分别是干什么的都还没理顺，那这类官方手册会很适合先拿来搭认知框架。
• 如果已经知道想把 AI 接进企业研发流程，但不知道“业务上下文怎么管”“团队规范怎么沉淀”“哪些能力适合做成 Skill”，这类材料也会比零散博客更系统。

也有一些资料特别适合当“单工具深度教程”来看。像 《Claude Code 完全教程》 这种内容，从安装、命令、技巧、思路到 Agent 原理一路铺开，资料密度很高，对想把一个具体工具迅速用熟的人其实很有帮助。

这种教程的典型价值也很具体：

• 如果已经决定主力用 Claude Code，那它能帮你快速补齐安装、命令、权限、MCP、日常使用技巧这些“立刻能上手”的东西。
• 如果当前的真实目标只是“先把一个工具用熟，再去做自己的工作流”，那这种单工具教程通常比一本大而全的书更短平快。

所以问题从来不是“外面没有好教程”。

真正的问题是，这些教程大多在解决另一类问题：

• 告诉你现在有哪些工具、有哪些模块、有哪些技巧
• 告诉你某一个工具怎么安装、怎么用、怎么配、怎么进阶
• 告诉你某个能力模块在企业里可以怎么落

这些东西当然重要，但它们往往更像：

• 工具手册
• 技巧清单
• 能力地图
• 模块化资料库

它们很适合拿来查、拿来补、拿来快速入门，也很适合已经知道自己要学什么的人去定向深挖。

但如果读者现在处在另一种状态：

• 觉得 AI 很强，但自己用起来总不对劲
• 工具听过一堆，但脑子里没有一条顺的主线
• 知道 Prompt、Context、Spec、MCP、Agent 这些词，却不知道该先学什么、后学什么、学会什么算真的会

那很多教程读起来就会有一种共同的问题：

信息很多，模块很多，例子也很多，但不一定能自然长成一条适合学习和判断的路径。

我觉得这不是这些教程不够好，而是它们本来就不是为了解这个问题设计的。

所以这本书，包括这场分享，真正想补上的空白不是“再推荐一些工具”，而是另一件事：

把这些分散的工具、模块、技巧和工程概念，重新组织成一条从认知冷启动到项目生命周期的学习路径。

我今天不想先回答“哪个工具最强”，我想先打掉两层旧脑回路#

第一层旧脑回路是：

AI 很笨，主要是模型还不够强。

第二层旧脑回路是：

找到一个最强工具，这事基本就成了。

这两层想法都不完全错，但都只说到了表面。

更接近真实工程的问题其实是：

• 很多人的工作流还停在补全时代。
• 很多人的工具观还停在“找本命工具”的时代。
• 很多人的协作方式还停在“多写一点 Prompt 试试看”的时代。

所以这场分享真正的起点，不该是“推荐 10 个工具”，而应该是先把 Part 1 真正想回答的三个问题讲清楚。

如果把 Part 1 压成一条线，它其实只是在回答三个问题#

如果想展开看

• 第 1 章 为什么很多人觉得 AI 很笨
• 第 2 章 工具不是信仰
• 第 3 章 从 Prompt 到控制面

第一个问题：为什么范式已经变了#

第 1 章最重要的价值，不是盘点模型年份，也不是炫最新产品名，而是先把一件事讲透:

AI 编程已经不是“更聪明的自动补全”，而是在往“可执行的代理式工程系统”迁移。

这个变化不是一句空话，它至少发生在三个维度上。

这里最值得分享的，不是“未来很酷”，而是一个非常现实的代价变化。

以前大家觉得 AI 不好用，很多时候是因为它真的只能“会说”。你问它，它答；你复制，运行，报错，再贴回去，继续问。那套工作流本质上还是“人肉 glue code”。

但一旦模型开始能读文件、改文件、跑命令、看测试、接浏览器、接日志、接外部系统，问题就不再是“它能不能写几行代码”，而变成了:

你到底有没有把它放进一条能执行、能验证、能收敛的工程链路里。

举个很简单的对比例子。

同样是“给后台补一个用户认证”：

• 在补全时代，更像是你先写一半，再让 AI 续几行，然后自己去补中间件、改路由、跑测试、看报错。
• 到了代理式工程里，才开始出现另一种可能：AI 先读项目结构，找现有路由入口，补认证模块，跑测试，读取失败输出，再继续修，直到把这条链跑通。

这两种体验的差别，不是“模型更会写了”这么简单，而是它开始具备了最小执行闭环。

这也是为什么第 1 章最后要把读者的角色往外拽一步:

不是只做“写代码的人”，而是开始变成“定义目标与约束、让系统稳定交付的人”。

第二个问题：工具为什么不能再按“谁最强”来问#

第 2 章最重要的价值，是把工具从“信仰对象”拉回“岗位系统”。

我现在越来越不相信“本命工具”这种说法。不是因为工具没差别，而是因为差别恰恰太大了，已经大到不该再用同一把尺子量。

更有用的问法是:

• 谁负责 IDE 里高频写码
• 谁负责终端里跑长任务
• 谁负责 GitHub 上的异步委派
• 谁负责 review
• 谁负责 SpecDriven 这类前置对齐

如果压成一张分享里能讲清楚的表，大概就是这样:

这里最关键的一句不是“工具很多”，而是:

工具不是单选题，而是岗位分工题。

一旦把工具看成岗位，很多混乱会立刻消失。

比如:

• GitHub Copilot 更像通用底座，不一定是所有场景的终点。
• Native IDE 的优势是交互路径短，不代表它天然就是平台底座。
• 真正拿来跑长任务、跨文件改造、自动化执行，我现在依然更信 CLI。
• Web / 云端 Agent 我会用，但更偏向后台委派、review 和低风险任务。

说到底，工程上真正重要的不是“谁功能最多”，而是谁的岗位最清晰、噪声最低、长期成本最可控。

如果换成一个更接地气的场景，比如“给现有 SaaS 后台加一个团队成员管理模块”，岗位分工往往会更像这样：

• 用 SpecDriven 工具先把需求、边界和验收口径压清楚。
• 用 GitHub Copilot 这种平台型工具串 IDE、GitHub 和 review 流程。
• 用 Cursor 或 Trae 这类 Native IDE 高强度改页面、调组件、看 diff。
• 用 Codex 或 Claude Code 这类 CLI Agent 跑跨文件改造、补测试、修脚本、查日志。
• 用云端 Agent 或 review agent 先扫一遍 PR、issue 或低风险杂活。

一旦这样理解，工具就不再是“选一个最强的”，而是“给这次任务排班”。

第三个问题：这些能力和工具，最后为什么一定会收束成控制面#

第 3 章真正做的，不是再塞几个新名词，而是把前两篇文章的线收成一张图。

如果把前三篇文章压成一句话，那大概就是：

• 第 1 篇回答：为什么范式变了
• 第 2 篇回答：现在有哪些岗位和武器
• 第 3 篇回答：这些东西到底该怎么在脑子里串成一个控制面

这也是为什么我现在越来越不爱听那种单点神话。

什么“神 Prompt” 什么“万能 MCP” 什么“换一个最强 IDE”

这些说法都太像单点神话了。真实工程不是靠单点赢的，而是靠控制面把东西组织起来。

真正过时的不是 Prompt，而是盲打式 prompting#

很多人现在一提 Prompt Engineering，语气像在聊什么上古遗迹。

我不太认这个判断。

真正过时的，不是 Prompt，而是那种没有结构、没有边界、没有验证、纯靠聊天框反复试错的盲打式 prompting。

Prompt 这一层真正解决的问题一直都没变:

• 这次到底要干什么
• 边界在哪里
• 成功标准是什么
• 输出应该长什么样

所以 Prompt 不会死，它永远是入口层。

但它也永远不是全部。

因为一旦任务开始变长、变复杂、变成跨文件、跨工具、跨验证链路的真实工程问题，光靠 Prompt 很快就会撞墙。

还是拿“团队成员管理页面”举例。

如果只有 Prompt，你大概只能说：

给我做一个团队成员管理页面，支持搜索、分页和邀请成员。

这句话当然不是完全没用，但它太像一句愿望，不像一个工程任务。它没有告诉 AI 应该沿用哪条实现路径、不要碰什么边界、做到什么算完成。

Context 真正要解决的，不是“多喂一点”，而是“正确分发”#

我现在越来越警惕一种伪进步:

以为 AI 乱写，是因为上下文给得还不够多。

于是开始把整个仓库、整份 PRD、十几张设计稿、几千字规则文档一股脑塞进去，最后把 token 和噪声一起点燃。

但真实情况往往不是“没给 Context”，而是:

• 给得太乱
• 给得太旧
• 给得不分主次
• 给了很多材料，但没有告诉模型谁才是 source of truth

所以 Context Engineering 真正该做的，不是堆料，而是控制信息分发。

也就是说，要想清楚:

• 哪些材料应该常驻
• 哪些材料应该按需检索
• 哪些旧材料应该明确排除
• 哪些规则应该升级成 AGENTS.md、Skill、Spec、Checklist，而不是继续靠人肉复制粘贴

如果用一句更短的话收束，那就是:

Context 不是让 AI 什么都知道，而是让它在当前时刻知道足够对、足够新、足够权威的东西。

同一个页面任务，如果进入 Context 这一层，思路就会完全不同。

这时候你更关心的是：

• 当前项目里哪一个成员列表页面最值得参考
• 邀请成员接口的正式契约在哪
• 设计稿里当前生效的是哪个 frame，不是哪个旧版本
• 仓库里哪份 AGENTS.md、哪套组件约束才是 source of truth

也就是说，Context 不是“再加 1000 字说明”，而是把真正相关的资料精准喂进去，把旧页面、旧 spec、废弃写法先挡在外面。

Harness 解决的不是“再装一个工具”，而是“how loop 能不能闭环”#

当 Prompt 和 Context 都有了，真正更扎心的问题就来了:

它到底怎么跑起来？ 怎么知道自己做对了？ 做错了怎么收口？ 同类错误下次还会不会继续重演？

这时候就踩到 Harness 的边界了。

我现在更愿意把 Harness 理解成一个 how loop。

它不只是工具大全，不只是 CLI、MCP、hooks、Playwright、CI 的名单，而是:

让 agent 能独立跑，又不至于脱缰的那整套执行壳。

如果把它压成四层能力，其实会更清楚:

这也是为什么我现在很认同一个很朴素的判断标准:

如果同一类错误已经出现了三次，团队还在靠口头提醒，而不是把它升级成规则、检查、Skill、hook 或 checklist，那多半还没有真正进入 Harness Engineering。

同样还是这个页面任务，如果走到 Harness 这一层，问题又会进一步变化：

• 页面能不能自己跑起来，而不是只看静态代码
• Playwright 能不能把“邀请成员成功”这条路径走一遍
• 日志里有没有真实报错
• 截图对比能不能发现按钮样式和设计稿跑偏了
• 测试失败之后，AI 能不能继续读取结果再修，而不是停在“我觉得差不多”

到了这里，AI 才不是只会生成代码，而是真的开始参与一个可观察、可验证、可收敛的执行闭环。

所以到这里，Part 1 其实已经不是三篇散装文章，而是一条完整的分享主线:

• 范式变了，所以 AI 不再只是补全
• 工具分化了，所以不能再迷信单工具神话
• 控制面长出来了，所以真正要学的是 Prompt、Context、Harness 怎么协同

也正因为 Part 1 讲清楚了，后面的内容才不再只是目录#

如果 Part 1 只停在“概念很好懂”，那后面的 Part 2 到 Part 5 很容易又被读回工具图鉴。

但一旦把 Part 1 这条线立住，后面的结构就会变得很自然:

• 先定盘
• 再开发
• 再交付
• 最后治理放大

也就是说，后面不是“再讲一些高级玩法”，而是在回答:

当你真的想让一个项目稳定往前推，这套控制面该怎么一路落到真实工程里。

如果把整本书压缩成一条开发工作流，它其实是这么往前走的#

这里我不想讲某一个完整项目怎么做完，因为这篇分享本来就不是项目复盘。

更适合分享的方式，是直接拿一个足够常见的需求切片来看：

例如，团队现在接到一个新需求：要在一个 SaaS 后台里做一条“邀请成员 -> 发邮件 -> 刷新成员列表 -> 记录审计日志”的功能链。

这个需求不重要在业务名词上，而重要在于它几乎天然会逼出软件开发工作流里的所有关键环节：

• 需求收敛和验收怎么定
• 技术栈和边界怎么选
• 前后端和契约怎么推进
• 测试、日志、Playwright、发布怎么接进来
• 成本、记忆、Swarm、反脆弱怎么治理

如果把整本书压成一条工作流，它其实就是围着这种需求一路往前推。

后面几个词先翻成人话

• 技术边界：这个功能到底放前端做、后端做，还是交给定时任务 / 消息队列做，不要什么都混着做。
• 仓库边界：哪些目录能改，哪些目录不要碰，别让 AI 顺手改到不该改的地方。
• 契约：前后端共用的一份接口说明，别一边这么写、一边那么返。
• 闭环：不是“写完就算完”，而是写完之后还能自己跑、自己测、自己发现问题。
• 治理：为了不失控做的日常工作，比如控成本、清理旧信息、定规则、分角色。

第一步：先定盘，不要一上来就让 AI 开写#

AI 一提速，最先被放大的往往不是代码生成能力，而是产品判断能力。

因为目标一旦不清楚，返工也会一起提速。

所以 Part 2 为什么要先讲 PRD、需求收敛、范围裁剪、验收标准、技术栈、仓库结构、系统设计、规范资产，不是因为这些话题传统，而是因为:

没有这些前置动作，后面所有“AI 很强”的表演最后都会变成 debug 和返工。

比如刚才这条“邀请成员 -> 发邮件 -> 刷新列表 -> 审计”的需求，如果不先定盘，AI 很容易一步到位给你做出：

• 邀请弹窗
• 角色管理
• 站内通知
• 邮件通知
• 批量邀请
• 权限组
• 成员标签
• 审计日志
• 导出报表

看起来特别勤奋，实际上第一版可能只需要：

• 邀请链路
• 一种通知方式
• 成员列表刷新
• 基础审计留痕

所以定盘阶段真正该用的东西，不是“更强模型”，而是这些：

• 用 OpenSpec、Spec Kit 或 Kiro 先把 spec -> design -> tasks 压出来
• 用 AGENTS.md、Rules、SOP 先把“哪些目录能改、哪些别碰、命名怎么写、哪些事不能乱做”写清楚
• 如果需求带设计稿，就用 Figma MCP 或截图输入先把设计信息拉进来
• 如果任务会横跨前端、后端、异步任务，先定清楚“哪一层负责什么”，不要让 AI 自己猜

再具体一点，技术栈怎么选也不是靠信仰，而是靠需求约束：

• 如果团队主要就是 Web 开发，大多数时候先把这三层定清楚就够了：前端页面、后端 API、数据库。
• 如果前端本来就是 React / Next.js 或 Vue / Nuxt，就沿用现有栈，不要为了 AI 硬切框架。
• 如果后端本来是 TypeScript 栈，NestJS、Express 这类都可以；如果是 Java / Go / Python 团队，也一样能套这套工作流，关键不是框架名，而是分工清不清楚。
• 如果这个需求会发邮件、发通知、跑异步任务，那就尽早把 Redis + queue 这类任务层考虑进去，不要全塞进同步请求里。
• 如果前后端要长期一起迭代，那就尽量有一份共享的接口说明，比如 OpenAPI，别让前端和后端各写各的。

换句话说，定盘阶段的核心不是“先写”，而是先把“什么要做、做到哪、用什么底板、哪些不做”钉死。

这一步的人话版

别急着让 AI 开写，先把三件事讲明白：

• 这一版到底做什么，不做什么
• 前端、后端、异步任务分别负责什么
• AI 这次能改哪些地方，不能乱碰哪些地方

第二步：主干开发不是“让 AI 把前后端写出来”，而是让项目在真实工作流里长出来#

Part 3 的重点，不是把开发重新讲成一遍 CRUD 教程，而是把这些问题真正摊开:

• 任务怎么拆，哪些能并行，哪些不能乱并行
• 后端底座怎么稳住，数据库、接口说明、服务层、实时链路怎么一起长出来
• 前端为什么不能只是堆页面，而要先讲清哪些状态只属于这个页面、哪些要放全局
• 调试、自洽陷阱、测试、回滚、审计、熔断为什么要在开发中就上场
• 设计稿、文档、任务系统、数据库、日志、知识库这些外部信息，怎么正确接进 AI 工作流

这一步如果压成一句话，大概就是:

开发阶段真正难的，不是让 AI 开始写，而是让它越写越稳，而不是越写越像黑盒面条代码。

比如还是刚才那条“邀请成员”需求，真正落到开发里时，我更关心的是一条像下面这样的工作流，而不是一句“请给我完整代码”：

1. 用 OpenSpec 或 issue/task 把功能切成几段： 邀请接口、邮件任务、成员列表刷新、审计留痕、前端入口页。
2. 后端 agent 先改 schema / contract / service / task： 比如改表、写 service、补接口说明，再把“发邮件”放进异步任务。
3. 前端 agent 再接着改页面： 在 Cursor 或 Trae 里根据设计稿和现有组件树补页面、弹窗、表格刷新和 toast，而不是再发明一套 UI。
4. 用 Codex 或 Claude Code 跑跨文件改造、补测试、查日志、收口脚本。
5. 用 GitHub Copilot 这类平台型工具把 IDE、PR、review 串起来。

这时候，开发真正容易翻车的点也会变得特别具体。

后端上，问题往往不是“它会不会写接口”，而是：

• 它有没有沿用现有 service 层模式
• 有没有乱发明返回结构
• OpenAPI 合同和真实实现有没有漂移
• 异步发邮件任务和主请求状态有没有打架

前端上也一样。难点通常不是“它能不能生成一个页面”，而是：

• 它到底是在复用现有组件，还是又堆了一层新的 div 树
• 它有没有把“页面自己的状态”和“全局共享状态”写乱
• 它是不是把旧页面的废弃写法又抄回来了
• 它到底是在按设计稿落地，还是在按自己的审美乱发挥

再往深一点，开发中的 Context 输入也不能全靠嘴说：

• 设计稿可以通过 Figma MCP 或截图输入给到 agent
• 数据库、日志、任务系统、知识库可以通过 MCP、CLI 或检索接进来
• 仓库规则则应该沉淀在 AGENTS.md、Rules、Skills 里，而不是每次重新讲一遍

所以 Part 3 真正讲的，不是“AI 会不会写代码”，而是“人到底怎么把任务、上下文、验证和规则一起组织起来”。

这一步的人话版

开发阶段真正难的，不是“让 AI 写出来”，而是：

• 别让它写歪
• 别让它乱改
• 别让它写完之后没人知道对不对

第三步：从“会生成代码”走到“会交付项目”，中间隔着一整层闭环#

这也是 Part 4 为什么必须存在。

很多项目前面看起来都很顺，一到联调、验收、发布就露馅。原因也不复杂:

生成代码和交付项目，根本不是一回事。

所以 CLI、Harness、Playwright、MCP、跨端宿主、联调和发布，这些东西放在 Part 4，不是为了炫技，而是因为没有这一层，项目就永远只停留在“看起来差不多快做完了”。

真正值钱的是:

• agent 能不能真正跑流程
• 能不能看页面、看日志、看运行结果
• 能不能自己做一轮验证
• 能不能在失败后继续收口

举个最常见的交付场景。

代码看着都对，页面也能打开，但真正联调时才发现“邀请成员成功”之后：

• toast 没弹
• 列表没刷新
• 邮件根本没发出去
• 后端日志里多打一条 warning
• 审计日志还漏了一条记录

这类问题如果没有交付闭环，最后还是只能靠人肉一点点找。

所以这一阶段真正该上的东西很具体：

• 用 CLI 把高价值任务拉回终端： 比如 pnpm lint、pnpm test、pnpm build、迁移脚本、日志查询、发布检查。
• 用 Harness 把执行环境、验证方式和失败收敛串起来： 比如一个任务一个 worktree，失败后自动把测试输出、diff、日志再喂回 agent。
• 用 Playwright 把 UI 和流程验证拉进来： 让 agent 真正去点按钮、截图、比对、回放，而不是只看静态代码猜页面有没有对。
• 用 MCP 或 CLI 把外部系统接进来： 比如查数据库、查文档、查 issue、查日志，不再只靠“你描述一下发生了什么”。

也就是说，Part 4 不是“再讲一些高级工具”，而是在讲：没有交付闭环，前面那些生成能力都很容易停在半空。

这一步的人话版

交付阶段讲的不是“再多写一点代码”，而是：

• 这东西到底跑没跑起来
• 页面和流程到底通不通
• 出问题时 AI 自己能不能先查出一轮结果

第四步：项目一旦做大，难点就会从“写出来”切到“管得住”#

这就是 Part 5 讨论的那些东西为什么一点都不虚。

因为当项目真的做起来之后，问题一定会自然抬升到这些层面:

• 成本治理
• 共享记忆与 Context 治理
• Swarm 编排
• 反脆弱设计
• 角色升级

而且这里最容易踩的坑，就是把这些东西理解成“规模大了以后再说”。

其实不是。

它们只是到后面才被系统化，但很多种子在前面早就埋下去了。

比如:

• 成本治理从工具和模型分层的那一刻就开始了
• 共享记忆从你怎么写 AGENTS.md、怎么治理旧文档就开始了
• Swarm 不是突然多开几个窗口，而是任务拆分和上下文治理走到一定程度后的自然升级
• 反脆弱不是保证永不出错，而是让系统在错误里收敛

这里如果还是不落例子，也很容易变成空话。

成本治理，不是最后看账单，而是从任务分层开始#

最典型的错误是：什么任务都上最贵模型，什么 agent 都带满上下文，什么小活都让主力执行器来做。

更合理的做法通常是：

• 架构判断、复杂改造、关键 review 才用前沿大模型
• 搜索、铺量、子任务、信息整理交给便宜模型或轻量 agent
• 不要让每个任务都背着整个仓库和十几份旧文档跑

所以成本治理本质上是调度问题，不是抠门问题。

共享记忆和上下文管理，不是记得越多越好#

很常见的翻车方式是：

• 仓库里老 spec 没归档
• 旧路径还留着
• AGENTS.md 越写越长
• 旧范例被引用得比新实现还多

结果 agent 不是“没看到规则”，而是看到了太多互相打架的规则。

所以这一阶段真正要做的，是把：

• 项目级记忆
• 任务级 Context
• 决策日志
• 归档材料

分开治理，而不是全部堆成一个大垃圾场。

Swarm 编排，不是多开几个窗口，而是角色设计#

多 Agent 最容易被误解成“同时开 5 个模型一起冲”。

但真实可用的做法更像：

• 一个 PM / spec agent 先做需求收敛和任务拆解
• 一个架构 agent 看边界、合同和方案
• 一个实现 agent 改代码
• 一个测试 / review agent 跑验证和扫风险
• 一个发布 agent 收 changelog、检查 release checklist

如果没有编排层，这些 agent 只会互相污染上下文，最后变成高成本混乱。

反脆弱设计，不是追求永不犯错，而是犯错之后系统变得更稳#

比如同一类错误已经连续出现三次：

• 老是引用旧路径
• 老是乱写返回结构
• 老是把废弃组件当标准组件

这时候最差的做法，是继续靠人提醒。

更好的做法是把它升级成：

• Rule
• Checklist
• Hook
• Skill
• Test
• Review gate

这才是“越失败越会收敛”，也是 Part 5 真正想讲的工程味道。

Part 5 的一句人话

这一部分讲的其实就是四件事：

• 钱别乱烧
• 旧信息别继续害人
• 多个 agent 别互相打架
• 同一个错别反复犯

如果这真是一场 30 到 40 分钟的分享，我会这样分配时间#

如果时间更短，比如只给 15 分钟，那我会只讲三句话：

• AI 编程最大的问题，很多时候不是模型不够强，而是工作流还停在补全时代。
• 真正该学的，不是单点神话，而是把工具按岗位组织起来，再把 Prompt、Context、Harness 组织成控制面。
• 当项目复杂度继续上升，决定上限的就不再是生成速度，而是产品判断、验证闭环和治理能力。

如果听众只想带走一个最小起步动作，我会建议这样做#

别急着换工具，也别急着上多 Agent。

先拿手上一个真实需求，最小闭环地重做一遍:

1. 先写清楚这次到底要完成什么，范围和验收标准是什么。
2. 再把真正权威的上下文整理出来，过期资料、旧样例和噪音先剔掉。
3. 选一个主执行器，不要让多个 Agent 在同一个任务里打架。
4. 给这次任务补上基本验证入口，比如测试、日志、截图、命令、检查脚本。
5. 如果某类错误反复出现，就把它升级成规则、Skill、Checklist 或 hook，而不是继续口头提醒。

很多团队迟迟进不了 AI Native 工程，不是因为不会用最新工具，而是因为这五步一直没有认真做。

最后#

如果要用一句更不客气的话收尾，那就是:

AI 时代最危险的，不是模型偶尔犯错，而是人类还在用旧脑回路指挥一个已经进入新阶段的系统。

所以这场分享真正想立住的，不是哪款产品最强，而是这条线：

先看清范式为什么变了，再看清工具为什么应该按岗位分工，接着理解 Prompt、Context、Harness 为什么会收束成控制面，最后才进入项目定盘、主干开发、交付闭环和治理放大。

只要这条线立住了，整本书后面的内容就不会再像散装知识，而会更像一套真正能推进真实项目的工程路线。