Spotify 的内部编程代理 Honk 是目前文档记录最完整的 AI 编程案例。它不仅是一个能写代码的 AI，而且还是一套完整的工程系统——从 prompt 设计到验证机制，从工具限制到代码库标准化。
这些机制不是为 Honk 专门发明的，而是从日常编程实践中提炼出来的。无论你用哪个 AI 工具，都可以考虑借鉴一下。
启示一：验证优先，而不是生成优先
Honk 的核心原则是：只有通过测试的代码才能提交 PR。
传统的 AI 编程流程是：AI 生成代码 -> 人工审查 -> 合并。Honk 的流程是：AI 生成代码 -> 自动跑测试 -> 失败就重试 -> 测试通过才提交 PR。
也就是说，当你拿到 Honk 的 PR 时，CI 已经跑过了。你不需要担心“这个代码能不能跑”，而只需要关心“这个代码是不是我想要的”。
日常： 让 AI 写完代码后，先跑测试再看结果。不要只看代码“看起来对不对”，要跑一下看看“实际对不对”。
启示二：限制工具数量
Honk 只给 AI 提供了三个工具：
- 验证工具——跑构建、lint、测试
- Git 工具——只能做有限的 Git 操作（不能 force push）
- Bash 工具——只能跑白名单里的命令
没有代码搜索，没有文档查询，没有网络访问。Spotify 发现：工具越少，AI 越不容易出错。
日常： 不要给 AI 太多工具权限，只给它必要的，AI 在受限环境下反而更可靠。
启示三：一次只做一件事
Honk 的经验：不要在一个 prompt 里让 AI 做多件事。
比如，把 API 从 v1 迁移到 v2，同时重构错误处理，顺便加个日志——这种 prompt，AI 很容易搞砸。因为上下文窗口有限，任务越多，AI 越容易忘记前面的要求。
日常： 把大任务拆成小任务。每个 prompt 只做一件事。做完一个再做下一个。
启示四：给 AI 明确的验证标准
Honk 的 prompt 不是让代码更好，而是让这个测试通过。
AI 需要一个可验证的目标，这样才能迭代——跑一次测试、看错误、修代码、再跑测试。如果没有明确的标准，AI 不知道自己做得对不对。
日常： 写 prompt 时，告诉 AI怎么验证这个代码是对的。
启示五：用例子说话
Honk 的 prompt 里总是包含具体的代码例子。
不是“把这个 Java 8 的代码改成 Java 17”，而是“把这个 Optional.get() 改成 Optional.orElseThrow()，就像这个例子一样”。例子比描述更准确。
日常： 写 prompt 时，给 AI 一个“之前/之后”的例子。AI 会模仿例子的模式，而不是猜测你的意图。
启示六：告诉 AI 什么时候不该行动
Honk 的 prompt 里会明确说：如果遇到这种情况，不要动。
因为 AI 很积极——你给它一个任务，它会想尽办法完成。但如果遇到不适合的任务（比如目标仓库的 Java 版本不支持新特性），AI 可能会硬来，进而导致错误。
日常： 在 prompt 里加一句：如果遇到 xxx 情况，停下来告诉我。这比 AI 偷偷搞砸要好。
启示七：让 AI 反馈 prompt 的问题
Honk 有一个做法：session 结束后，问 AI “这个 prompt 缺了什么”。
AI 在执行过程中会发现 prompt 的模糊之处、遗漏的信息、不合理的假设。让它反馈，可以帮你改进下一个 prompt。
日常： 写完 prompt 后，问 AI：如果让你执行这个任务，你会遇到什么问题？AI 的回答会帮你发现 prompt 的漏洞。
结语
Honk 的成功不是因为模型更强，而是因为工程做得更好。
验证优先、限制工具、一次一事、明确标准、给例子、设边界、让 AI 反馈——这些机制不依赖任何特定的 AI 工具。它们是从实践中提炼出来的通用方法。
AI 写代码的速度已经不是问题。问题变成了：你有没有让 AI 写出可靠代码的工程能力。
