如何真正委托你的 AI Coding Assistant（大多数人不这么做）

Source: Dev.to

六个月前，我使用 AI 编码工具的方式是错误的。我把它们当成搜索引擎——提问、得到答案、继续。输出还算可以，但生产力提升几乎没有，可能只快了 10 %。绝对不是大家所说的那场革命。

当我不再让 AI 回答 问题，而是让它 承担 任务时，情况才发生了转变。

提问与委托的区别

提问：
"How do I write a rate limiter in Express?"

委托：

I need a rate limiter for our auth endpoints. We're using Redis, the window is 15 minutes, limit is 5 attempts per IP. We have existing middleware in /middleware/auth.js — match that pattern. Return a 429 with a JSON body that includes retry_after. Write the implementation and the tests.

第一个提示会给你一个通用的代码片段。第二个提示则会得到几乎可以直接合并的代码。

真正委托的关键要素

• 具体的输入和输出 —— 不是“写一个函数”，而是“写一个接受 X、返回 Y、处理 Z 边界情况的函数”。
• 匹配已有的模式 —— 指向代码库中的真实文件。
• “完成” 的标准 —— 如果你想要测试，说明；如果需要错误处理，描述格式。

仍然无法委托的内容

• 架构决策 —— AI 可以提供架构建议，但它不会对矛盾的需求提出质疑。它不了解你团队的部署约束、事故历史或仅存在于你脑中的遗留变通方案。
• 需求模糊的任何事 —— 如果你写不出清晰的规格，AI 也无法据此执行。模糊的提示只会暴露模糊的思考。
• 对 AI 生成代码的代码审查 —— 让 AI 审查自己的输出是循环的。它能发现风格问题，却抓不住逻辑错误。逻辑审查必须由你来完成。

我实际使用的工作流

对于任何非平凡的功能：

1. 编写 5 句简明的英文规格说明。它做什么？输入输出是什么？有哪些失败情况？
2. 将该规格 连同上下文（相关文件、要匹配的模式）一起喂给 AI。
3. 像代码审查一样阅读输出，而不是把它当作礼物。
4. 让 AI 修复具体问题——不要要求完整重写，只要纠正即可。
5. 自己编写集成测试（这很快，而且能迫使你思考契约）。

我已经完全不再使用 AI 处理 计费、认证流程和迁移 相关的任何内容。错误的代价太高，审查负担与自己手写相当。

那些让人不舒服的数字

如果 AI 负责了你 60 % 的敲键工作，却需要你花 80 % 的常规审查时间，那么实际收益比 hype 说的要小得多。真正的杠杆在于以下任务：

• 规格明确
• 风险低
• 代码库中已有相同模式

这仍然是一大块工作，但它是一个具体的列表，而不是“一切都交给 AI”。

从这些工具中获益最大的开发者，是那些在 AI 出现之前就已经擅长编写规格的人。该技能可以直接迁移。

每天都在使用 AI 工具进行构建。这里分享的大部分内容来源于对不起作用的尝试以及对原因的分析。如果对你有帮助，请留下来。