「AI 可以替你做一切，唯独不能替你坐牢。」这句名梗是全文的地基：智能体可以大规模生成生产代码，但它不承担代码的社会责任——线上出事、需要审计时，站出来的仍然是 Code Owner。作者 tison1096 是多个 Apache 项目的 PMC 成员，这篇长文是大半年高强度智能体编程后的质量方法论：智能体负责生产，人负责把「似是而非（plausible）」的代码变成「可信（convincing）」的代码。
责任落在谁头上
《程序员修炼之道》开篇的寓言「我的源码被猫吃了」讲的就是这件事：源码只有一份又丢了且没备份，是你的责任；推给猫无济于事。书中论责任的一段，如今读来像预言：
责任意味着你对某事积极认同。你保证事情能够搞定，并为之做出承诺，但你不必直接掌握事情的每个方面。除了个人尽力做好，你必须分析超出你控制范围的风险情况。……不要把问题归咎于别人或其他什么事情上，也不要寻找借口。不要把所有问题都归咎于供应商、编程语言、管理或是同事。（《程序员修炼之道》，转引自原文）
把「智能体」插进「供应商、编程语言、管理、同事」这个列表毫无违和感。线上出了问题，说「这是 AI 写的 BUG」撇不清你作为 Code Owner 的责任。这是全文一切措施的前提。
智能体的三个长处
作者概括为：上下文更长、比人有耐心、可以异步工作。三者在同一件事上叠加：实现一个新功能，过去是 Code Owner 自己搜索调研、做原型、再比较，一周到一个月；现在是智能体出调研报告，人选定几个方向让它并发实验，再对产出反复拷打迭代，选出两三个完善原型，一个下午到一天走完。
过程中还有三笔附赠的收入。其一，只要需求说得清，智能体能按字面拟合到位，从前因编码成本而糊弄过去的技术债，现在可以按实际需要实施完再做取舍。其二，智能体擅长且不厌其烦地写测试，行为测试和性能测试用例可以不耗额外精力地白拿一套。其三，设计和实验都在智能体可触及的上下文里完成，事后翻找当时的决策，它能快速回忆——所谓「智能体没有长期记忆，聊到后面忘了前面」，多半是对它的完美期待；人的短期记忆差得多，多轮对话后忘了会话最初要干嘛的，往往是人自己。Git History 和 Issue/PR 都在本地，人不耐烦翻，智能体读文件、调命令就行。
人的价值：理解并重构
智能体力有未逮之处，就是人的切入点。作者给出的操作化定义：为了有信心承担交付后的责任，人必须理解智能体生产的代码——而理解的手段是重构。
类比是把智能体代码当作刚离职同事留下的代码：天书难读、一句话交接、逐行逆向工程。但条件其实更好：这些代码按你的意图生成，最高层抽象上你知道它该解决什么问题；而且「同事」没走，还在你身边不厌其烦地回答并代为调整。资深程序员接手他人代码的第一件事就是走读梳理、大刀阔斧重构——在外部行为不变的前提下，把代码改成自己好理解的形态。对智能体代码同理：重构到你能流畅说明程序实现了什么、给定条件下行为如何、限界上下文怎么划、继续迭代从哪入手。
场景一：部署运维，信任是分级建立的
ScopeDB SaaS 平台的部署运维已被智能体接管——尚非无人值守，作者保持清醒做最终兜底，但已敢在发出部署指令后切窗口忙别的。这份信任靠三件提前做好的工作挣来：
- IaC 全套逐行确认过。整个技术栈是作者自己设计实现的，每个资源归哪个服务所有、被哪个框架管理，心里有数。智能体执行偏差时，知道怎么指挥排查、紧急时执行什么回滚。
- 授权范围与标准动作经过设计。放手让智能体接管 GitOps 后出过 Force Push 导致 Terraform 死锁的事故；每个这类典型错误，都沉淀成规则指导它走安全路径。滚动发版、元数据升级、节点扩缩容等常规动作，总结成不断迭代的 SOP 照章办事。
- 完全授权只给跑过的流程。合并 GitOps 变更和线上操作，都是作者手动跑过、或全程监督智能体跑过、确认执行的就是同一套流程之后才放权。实际执行的大多是「上次做过的方案，版本号变了或参数微调」；偶有偏差，让智能体回归上次上线的经验即可自动恢复。
值得单独记下的警告：信任绑定模型。换一个模型，约束和提示信息可能都要重新建立——对某个模型的指令遵循水平调好的 SOP，不是模型无关的资产。
场景二：前端的折衷
前端所见即所得、部署无状态，作者在没精力钻研框架选型与组件设计的前提下走了折衷路：后端定义前端（先保证后端数据与业务逻辑正确，前端以当前模型的智力「对个七七八八」）；要求智能体说明前端逻辑的整体设计，说得清就大体可信；再让掌握 Computer Use 的模型直接录屏演示要上线功能的完整流程。结果是除了选型 SvelteKit 和仔细设计鉴权流程外，其余「看起来差不多 OK 就行」。作者明说这不是最佳实践，而是个人前端经验与精力不足下的妥协；有充足时间，同样应该把经验具体化成模块划分与命名准则，换取更深的掌控。
场景三：基础库开发，结构即控制
基础软件/库里代码本身就是交付物，必须深入到设计与实现才能确定接口语义、边界行为和性能。作者从 Apache Asyncband（Incubating）迭代出一套项目结构，已复用于 datasketches-rust、hashcrew、cache2 等仓库：
- 核心开发区是项目同名 crate 加三个平级目录——集成测试（tests-integration）、性能测试（benchmarks）、示例（examples）。测试各自占顶层目录、作为 local-only crate 存在，既解决发版时的循环依赖，也让发布的 crate 尽量不沾仅测试用的依赖；examples 独立是为了让跳到仓库主页的用户容易发现。
- 机械动作全部封装进 xtask，以
cargo x lint --fix这样的命令调用。AGENTS.md 里只需一句：
Use cargo x as the source of truth for repository workflows. Read cargo x —help and the relevant subcommand’s —help before running build, test, lint, or formatting commands.
此后格式化与测试文档回归，智能体就能像调用 Hook 一样每次执行。
- 文档按读者分工：
| 文件 | 面向 | 只写什么 |
|---|---|---|
| README.md | 跳到仓库首页的用户 | 项目定位与典型用法，附跳转链接；不讲内部细节与开发指南 |
| AGENTS.md | 开发本项目的智能体 | cargo x 使用指南、基础风格与文档指南；过多时分散到 CONTRIBUTING.md / STYLES.md 再引用 |
| CHANGELOG.md | 升级的下游用户 | 版本间实际看到的变更；需在 AGENTS.md 说明它是面向下游的，同周期变更要合并 |
- 项目特化技能（SKILL）：Asyncband 针对 ASF 发版合规与流程建了 license-audit 和 release 两个技能；ScopeDB 内核针对数据库开发守则建了 review 和 checklist。
收益是双向的：作者对「每个目录下出现什么改动意味着做了什么」心里有数，Review 时可折叠目录先看想看的部分；指挥智能体时，它在相同目录下按图索骥参考过往做法，产出的 diff 风格高度一致。落地到新仓库的方式也成熟：让智能体参考已实施的项目结合当前项目特点做一轮迁移，出一份详细的取舍报告——看完报告、微调、收敛。
Review 与交付：写代码便宜，交流昂贵
关于 Review PR，作者的立场有两条递进的默认假设。第一，默认所有 PR 都有 AI 辅助成分——用了很正常，Reviewer 不必对着几千行 diff 误以为都是作者慢慢写的而产生情感亏欠。第二，不得不假设很多 PR 是纯智能体生成、甚至发现问题到分析到实现全程自闭环。生成得好，正常合并感谢；有问题，且对方首次沟通后的回复明显「人机」、改也改不对时，不必继续跟「作者」沟通——自己知道怎么改又有时间，就带着 AI 上手改完合并；否则把问题或阶段性总结回复上去，等自己有空或别人接手。这与「先合并贡献再自己 follow up」没有本质区别；智能体编码时代写代码是 cheap 的，交流是昂贵的。
责任逻辑同样适用于社区治理：自主智能体提交的 PR，负责的人是最终合并代码的你。作者举了 DataSketches 的实例——一个今年六月才开始活跃的账号全网扫描 ASF 项目，用 fuzzing 和白盒分析提修复 PR；PMC 成员问是否该提名它做 Committer，作者的判断是「但凡表现出一点人性早提名了」，最终建议尝试联系智能体背后的人，看他是真有理解还是完全放手。作者沿用多年的选拔标准一句话：
The candidate should be a real human spending time on the project, taking actions bravely with caution.
重点是敢于决策、同时谨慎、知道何时求助——前沿智能体在模棱两可的取舍上做不可靠判断，你说什么它都「你说得对」。顺带：真人开发者也有这样的，Good First Issue 问一步做一步、遇抉择就摆烂求助的，有指导的那个时间自己早解完了。至于在 PR Template 里给智能体「投毒」，大可不必——假定所有贡献都是智能体提交的，已经够了。
交付把关：自我批评与两个魔术字
发布前的把关，作者发现一个效果不错的提示词，思路是让智能体从最新 main 切一个 draft PR 自我批评：作为基础库发出去一定有人骂，他会觉得哪里不好用、哪里写得 AI Slop、哪里测试多余、接口错误、人体工学不当、文档缺失、场景不兼容——全部考虑一遍，做成一个 PR 优化；并且每个小动作单独提交、commit message 写清为什么；同时明令不要过度优化、不许再产出 false positive 的 commits。如果重新组织，作者会强调两点：第一性原理——站在用户角度自顶向下审视与设计；消融实验——消除多余的测试与 AI Slop 代码。这两个词是长时间 prompt 之后发现的「魔术字」：提起第一性原理，前沿模型几乎都会激活自顶向下的审视、避免陷入局部细节；消融实验能驱动智能体并发执行多轮消除中间概念的实验，有效砍掉不必要的中间层。
再仔细一些的质量保证是用户旅程测试。两个实例：DataSketches 的 BloomFilter 原有 invert 方法（反转每个 bit 位），与智能体 Battle 几轮使用场景、对比其他语言生态、溯源接口加入的历史之后，确认没有单独使用的需要，唯一有价值的是做差集的辅助——于是删掉 invert，换成实际有用的 difference。ScopeDB 的用户界面，让智能体录屏报告，发现登录界面带着和注册界面一样的「注册动机」可选框——指挥智能体结合友商常规做法重新给出注册登录流程设计，作者挑一个实现。
这些手段殊途同归：把智能体生成的似是而非（plausible）变成可信（convincing）。人在循环里的价值，就是确保最终交付的代码可靠——以及记得换模型之后，把建立过的信任重新校一遍。