Kent 如何在不读代码的情况下交付功能

Kent C. Dodds 在自己 SaaS 上的真实交付闭环：十五条原则，讲如何发布你没读过的、由 agent 编写的代码，附完整直播录像。AI agent 几分钟就能实现一个功能。难的是之后的事：在你自己没读过代码——而且越来越多情况下没人读过——的前提下，把它交付给真实用户。

9 月 30 日，Kent C. Dodds 在 MEGA 直播里花了九十分钟，完整演示了他在自己的 SaaS Kody 上是怎么做的。不是演示仓库，是他的产品、他的交付闭环、他的关卡。本期 Drop 把那场直播变成了你能搬回自己技术栈的东西：录像，以及支撑它的十五条原则——这些原则不依赖任何特定工具。

一张图看懂这个闭环

Kent 跑的是一条链，每一环的存在都是为了让下一环在没人读 diff 的情况下依然可信：

意图 —— 一个目标，和 agent 反复讨论，直到上下文对齐
原语 —— 有文档记录的构建块，每一次改动都据此分类
实现 —— 由 agent 完成，在它自己的上下文里
审查 —— 由不同的 agent 和 CI 完成，在它们各自的上下文里
关卡 —— 测试、预览环境、风险分级
开关 —— feature flag 和实验受众，让发布可回滚
生产反馈 —— 可观测性、附带成本的发布通知
清理 —— 定时 agent，在实现者离场后负责删除、迁移并执行原则

这条链里没有“阅读”这一环。八个环节中有六个是验证。

附赠文件：verification-stack-checklist.md —— 一页 Markdown 清单：Kent 在代码触达用户前跑的所有关卡、审查者、开关和清理任务——拿去改成适合你自己仓库的版本。（3 KB）

verification-stack-checklist.md // gates, reviewers, flags, cleanup

十五条原则

信任

1. 你信任代码，是因为你能验证它，而不是因为你写了它。 你从来不是因为代码是自己敲的才信任它，而是因为你能检查它。Agent 写得比你读得快，这条原则不会变——它只是抬高了验证、关卡和回滚的重要性，同时把“作者身份”的价值压到几乎为零。

2. 不理解软件是干什么用的，就做不出好软件。 脱离产品背景的流程是空壳。过去这活儿可以外包出去：PM 懂用户，你接 ticket。现在接 ticket 的是 agent。人的工作变成了理解用户、痛点和意图。

3. 面对用户反馈，要找的是核心问题，不是他们建议的方案。 用户提出的方案有时有用，但多数是噪音。找到底下的痛点。早期阶段，对每一条反馈都要认真琢磨，但不必承诺去实现——同时留住那些在你所解决的问题领域里报告真实问题的用户。

上下文

4. 先对齐共享上下文，再要求动手实现。 把你已知的东西都喂给 agent——包括那些你已经有答案的问题。如果它理解错了，你就在一行代码写出来之前抓到了错位。先锁定意图，再说“去实现”。

5. 不断往抽象阶梯的上方爬。 Tab 补全 → 一边看代码一边对话 → 由对话直接完成编辑 → agent 管理 agent。有用的动作永远是向上。要反复问自己：我现在做的这件事，agent 能不能做？ 能，就交出去。如果它还不能稳定地做，就把它做到稳定。

6. 持久的知识活在仓库里，不在某个 agent 的记忆里。 一个全新的、没有任何对话历史的 agent 也应该能做出好结果。愿景、不变量、决策记录、贡献规则、系统结构——全都放在仓库里。目标是 agent 无关性：换模型、换 harness，产品的大脑不丢。

7. 用摩擦日志让项目自我修复。 Agent 会默默绕过各种痛苦——启动慢、脚本坏、文档缺失——而且从不抱怨。要指示它们把摩擦记下来。一个定时清理 agent 负责修掉底层问题，之后每一次运行都更便宜。

原语

8. 原语是阻止 agent 造垃圾的方式。 把构建块——auth、UI 界面、存储、计费——写清楚，并强制每一次改动自我归类：复用、组合、扩展，或者（很少）新增一个原语。与其一次性倒出所有文档，不如渐进式地发现；每个新 agent 都是新来的员工，信息过载只会让它糊涂。按改动触及哪些原语把工作评为低/中/高风险，agent 自然会倾向于最小的安全改动。

交付

9. 优先选择双向门；做不到时就用功能开关。 先问一个决策有多容易撤回。发布一个用户依赖的公共原语，这是单向门。功能开关和“实验性，可能出问题”的受众群体，能把许多单向门变成双向门——发布、学习、撤回，不用发道歉邮件。

10. Agent 不会删代码。清理必须是有意为之。 Agent 只会加兜底逻辑，把遗留路径永远留着；没人付钱让它删。用清理 issue 跟踪迁移，写清楚你凭什么判断删除是安全的。给未使用的路径加上埋点。定期跑一个“遗留清道夫”，安全的东西直接删，不安全的加上埋点——测试和文档同理。

11. 先用手工硬做，再自动化，最后做成确定性的。 手动做那些痛苦的工作，做到足够久，直到你理解真正的问题。然后：人工 → Agent → 把可重复的部分做成确定性软件。Agent 感受不到你的痛苦，所以除非你明确要求，它不会把工作沉淀成耐用的软件。任何 Agent 都能调用的软件，胜过困在某个厂商围墙花园里的自动化。

验证

12. 把实现者和审查者分开——不同的上下文窗口。 绝不能让构建这个改动的 Agent 成为唯一的审查者。独立的 AI 审查者和 CI，各自在自己的上下文里，能抓到作者上下文里被合理化掉的东西。告诉实现者：审查意见是要验证的建议，不是命令。先手动使用审查者，再自动化这个循环，以此建立信任。

13. Agent 写的测试不足以作为关卡。 同一个 Agent 写了功能又写了测试？CI 变绿是个弱信号。敢不读 diff 就发布，靠的是层层叠加：强力的 AI 审查、CI、Agent 能实际操作的预览环境、功能开关，以及你真正测试过的灾难恢复。测试很重要。光有测试不够。

经济账

14. 用创造的价值衡量花费，而不是标价。 并行 Agent 花的是真金白银。先砍成本：摩擦日志、更好的文档、确定性的软件包。如果还是要花钱，确保交付的东西价值高于成本——并且把成本和难度写进发布通知里，让自己保持诚实。

15. 你独特的价值不再是实现代码。 杠杆效应才是这一切的理由——不是“永远交付更多”。把实现外包出去，让注意力留给判断、产品方向、艰难的取舍，以及那些塞不进工单的长对话。写代码不再是人类独有的价值主张。想象、判断和在乎仍然是。

这在 MEGA 中的位置

本次分享是第 3 周——产品——的缩影。Kent 的这一周把上面的循环拿来，让你在自己的仓库上搭建它：记录原语、分离审查者、让门禁在空 diff 上失败、在你的改动上通过，还有标志位，以及让一切保持诚实的清理 agent。第 2 周和 Angie 一起构建循环所依赖的 agent；第 4 周和 John 一起把它变成一座工厂。

延伸阅读

I was wrong about MCPs - Kody 的能力层，也就是原则 8 作为架构的样子
Don't make the agent remember how to do its job - 原则 11 的实践：流程变成包
Towards Autonomous Product Development - 同一个循环，在云端用协调者和工作者运行
Kody，开源：github.com/kentcdodds/kody

附赠文件：verification-stack-checklist.md — 一页 Markdown 清单：Kent 在任何东西到达用户之前运行的门禁、审查者、标志位和清理任务——把它改造成适合你的仓库。（3 KB）

verification-stack-checklist.md // gates, reviewers, flags, cleanup