AI编程不是工具差，是你的工作流不对

按层级选择模型与聊天优先规划

最近听到最多的评论通常是这样的："我试过[某某当红 agent]，它给的答案垃圾透了。AI 被高估了。"

我的回应是："不是的。你让你的水管工造房子，还忘了给建筑图纸。" 🦄

Agent 不是问题——问题在于你的设置。下面是真正有效的工作流。这些都不复杂，但我花了比想象中更长的时间才学会。

1. 挑选符合任务的模型。规范胜过直觉。🪛

Haiku 是短跑健将。它绝对可以尝试你的分布式系统架构——只是答案不是你能用的那种。你的工作是把模型和工作匹配起来。

如果问题定义得很清楚——清晰的规范、验收标准、枚举的边界情况——那 Sonnet 就足够了。你会花更多时间审查，但能省真金白银。你也会更快发现自己的坏规范，这本身就是一份礼物。

如果功能是一团乱麻，而你又无法（或不愿）拆解它，那也没问题。把整个东西丢给 Opus。你不一定要分解每个子问题，但你必须定义整体解决方案。"让它工作"不是有效的需求——这是一个 agent 无法理解的绝望祈祷。

一个规范优秀的便宜模型永远胜过一个模糊其辞的昂贵模型，每次都是这样。

2. 在聊天中规划。最后才动代码库。🪞

在一行代码进入代码库之前，我会花上好几个小时来讨论问题。AI 是我的橡皮鸭兼研究助手，还带点态度——是的，我这样设置是因为那些讨人厌的恭维分散了我的注意力，我的目标是：一个坚实的游戏计划。

用什么语言？不重要。我能读懂所有的（我可能不会）。包管理器？我更不在乎——在根目录扔个 Makefile，命令无论如何都是一样的。时间表？有时候，但答案通常是"昨天就该做"。真正重要的是：

有意义的技术栈

测试场景——正常、反面、错误、边界、奇怪、已知的

显式的非目标（你不会构建的东西，这样它们就不会偷偷被构建）

跳过这些直接上来说"给我造个东西"？你确实会得到一个东西。只是不会是你的东西。

3. 单一真相来源。停止复制指令。🪧

AGENTS.md、copilot-instructions、CLAUDE.md、GEMINI.md——选一个。我用 AGENTS.md 作为真相来源，然后从其他文件中添加单行 markdown 链接指向它。这样你只用管理一个文件，而不是四个。

如果一条规则处处为真——对于你这个操作者，或跨越整个项目——那它就不应该在技能里。技能在被触发时才会被调用。指令每次都被加载。知道你实际上需要什么，并据此使用。如果你想深入了解这个概念，我写过另一篇完全专门讨论这个的文章。

模型应该在工作时维护 AGENTS.md——你不需要单独的 MEMORY.md 来搅混水。当它一次又一次违反同一条规则时，不要再加一条到堆里。改掉那一条。如果你问，你的 agent 知道它确切地在哪里绊倒了，它已经知道怎么修复它。

4. 为 agent 而写。不是为受众。🪶

如果不管约束，模型会像一份详细的入职文档一样写你的指令。章节标题。友好的引言。"本文档概述..."。为一个永远不会出现的人类读者精心打磨的文章。

指令每次都要加载到上下文中。每个单词都要花费 token，吞噬清晰度。所以要为真实的受众优化：你的 agent。

只为 AI 消费而编辑——没有人类友好的框架，没有叙述流。

保留每一个有意义的细节。压缩文字，永远不要丢掉意图。

去掉重复。如果两条规则用不同方式说同样的东西，合并它们。

消除歧义。"尽量"和"考虑"是噪音——说清楚要求。

删除任何可从合理的代码编辑中推断出来的东西。如果 grep 能回答它，就删掉。

一份精细的入职文档是对你每次发送的 prompt 的税收。在写的时候付一次，不是每次都付。

💡 专业提示：这些指令应该是一个技能，因为 agent 只在更新 AGENTS.md 时使用它们。

5. 技能不是魔法。显式调用它们。🪄

技能被设计成自动调用的——是的。理论上...或者如果描述足够接近 prompt，而且星期二行星对齐。如果你需要一个技能被使用，那就在 prompt 中明确说出来。否则你就是在赌博。

而且请停止因为名字听起来有趣就从市场安装每个技能。如果你不知道它确切的名字，就删掉它（记得备份）。用技能构建器来记录你实际运行的工作流。剩下的别管。你进去垃圾，就出来垃圾。

6. 本地安装 MCP。全局会拖累每个 prompt。🪺

全局启用 20 个 MCP 对你很方便，对你的 agent 来说是个上下文污染噩梦。每个连接的 MCP 就算什么都不做也会吃掉 token。

问题很简单：我是不是处处、一直都用这个？如果是，那全局没问题。如果不是——而诚实的答案通常是不是——那就只在它真正有用的五个项目里装。符号链接和绝对路径可以处理重复。只要确保 agent 有权限访问目录。

7. 别审查。要测试。然后再测试一遍。🩻

我停止了逐行审查 AI 写的代码。我做得不好，做得很慢，看到第三个文件眼睛就开始呆滞。答案是测试它——大量、频繁、而且在它停止运行的瞬间就开始。不是三天后当你打开一个 PR 的时候。

单元测试。集成测试。E2E。性能。无障碍 (A11y)。Sonar。Semgrep。等等。然后自动化，用 GitHub Actions 运行。让模型覆盖正向路径、反向路径、错误路径、边界情况，以及你在规划阶段定义的验收标准。（你定义了，对吧？）把你在测试中发现的任何东西显式地加进去，这样就不会再发生。

编辑：感谢 @txdesk 指出自动化测试是不够的。我的测试总是包括手动验证，无论我在构建什么。你需要一个离 AI 很远的手动验证循环来证明它有效。

然后在模型间交叉检查。让 Codex 审查 Claude。让 Copilot 审查 Codex。每个模型都有不同的盲点和不同的执念——在可控的剂量中相互对抗运行它们就是审查。一个 LLM 是单点故障。三个是法定人数。

8. 禁止快捷方式。临时永远都不是临时。🪤

在我个人项目的 AGENTS.md 文件中：向后兼容性是严格禁止的。快速修复被禁止。临时解决方案在任何时刻都不是可行的方案。如果模型想贴上创可贴，它就得为那个选择辩护。它不能，因为我的规则说不能。

现在记住，这是个人项目规则，对实时生产代码来说很苛刻。如果你在运行每日生产、有真实用户的系统，那你可能应该取消"不向后兼容"规则。但对于你自己的项目？停止让模型在你的代码库中四处抛洒技术债，像在撒纸屑一样。

9. 清除上下文。别在破损的东西上继续迭代。🪦

如果你已经告诉模型同样的东西三次，它仍然搞错了，那就假设你的对话被污染了。太多错误的方向已经烤进去了。打开一个新的聊天。用你学到的东西重新开始。

一个清洁的上下文配合更锐利的 prompt 胜过六轮"不！我已经说过了..."

10. 教训。从来都不是 agent 的问题。🧭

Agent 没问题。工具没问题。有问题的是把一个价值数千美元的推理系统当成魔法八球——每次答案出错就摇得更用力，希望第十五轮是对的。不会是的。

选择正确的模型。先规划。单一真相源。无情地测试。跨模型交叉检查。禁止快捷方式。清理你的技能文件夹和你的 MCP。当事情出错时清除上下文，重新开始。

这个设置？它有效。自己试试。

🛡️ 幕后 🎭

这篇文章是我写的。Claude 在结构检查和讽刺校准上帮了忙，这样我就不会不小心变成个混蛋。观点、规则和 AGENTS.md 哲学都是我的——在整整一年的让 AI 驾驶和残酷分析所有崩溃过程中硬化而成的。

有些评论可能只对已登录的访客可见。登录以查看所有评论。

要采取进一步行动，你可以考虑屏蔽此人和/或举报滥用。