关于 AI Coding 的一些个人技巧

之前写了一篇 《尽职编程：AI Coding 时代的个体产出差异的来源》 引发了大家很多讨论，但那篇文章只写了工作态度，没有太多可以指导工作实践的技巧。所以我打算再分享下一些更具实操性内容。

网上关于 AI Coding 最多的讨论都集中在工具和模型，但我认为这种讨论就如同过去人工编程讨论用什么 IDE 和语言一样，没有太大意义。我发现自己现在似乎从来不在乎用的工具和模型是什么，我用过 cursor，windsurf，devin，codex，claude code，没有太大的感觉他们有什么本质的差异。在今年 Opus 4.5 发布之后，我认为连模型的差异也越来越小了。我承认他们各自有各自的特点，但这就好比不同品牌的车一样，作为驾驶员，应该掌握的是开不同车用不同的开法，而不是专门限制自己非法拉利不开。我认为，在合理的使用方式下，用不同工具和各家最新一代的模型不会对自己的产出产生太大的质量差异，如果有，那么说明你并没有非常好的驾驭不同工具和模型的特点，全在任凭它们自我发挥，这样当然会导致你的产出有巨大的波动。举个例子，如果某个模型特别喜欢过度设计，最后你的产出过度设计了，你不能说因为我的模型喜欢过度设计所以我的产出过度设计了，你只要简单跟模型提一句不要过度设计，再喜欢过度设计的模型也会按照你的指令不过度设计。模型是模型，人是人，正确的 AI Coding 方式应该是产出质量跟操控者走而不是跟着工具和模型走。

下面是我自己总结的一些通用的 AI Coding 技巧，不代表一定是最佳实践，仅作为抛砖引玉。

质量远高于速度

我一直很想问网上一些 AI Coding 效率极高的大 V 的一句话是，「哥们，你有正经工作吗？」。就我的上班经验来看，如果你在一家中国大公司工作，你的犯大错的机会可能只有一次，如果你在一家外企，老外对人宽容一点，可能犯大错机会有三次，如果你在一家创业公司，可能因为用户量和犯错成本不大，犯大错机会会有四五六次。

我相信绝大部分人 AI Coding 的目的都是为了完成工作，毕竟 token 成本摆在那里，只要是一份正经工作，它对错误的容忍程度就不会高。如果一个人并行开三个以上窗口编程，每天烧大量 token 产出几千上万行代码，配置了各种自动化的 MCP，Skill，CLI，网上流行什么新潮思想就采用什么思想，我很难信任这样的人工作会不犯错，事实上我这两年已经见到不少这么做的人翻车了。但是这些翻车的人如果把自己的工作方法分享到网上，可能不仅没人会批评，反而会得到大量嘉奖，甚至认为这些人适应 AI 新工作方式适应的好。

我日常最大的工作并行读只有 3 了，再多我脑子已经忙不过来去检查每个 Agent 的工作成果了。即便如此，我也完全不觉得自己干活比别人慢，所以我很好奇什么牛逼的公司会需要更快的编程速度，以及他们的产品质量到底如何。

很少有公司会因为你干活稍微比别人慢一点而开除你，但是经常因为某个人搞出大事故而开除人。就一份工作而言，尽量不要搞到被开除肯定还是第一要务。

不要过度使用 Skill

之前有一阵子出现了 Skill 热，什么玩意都整一个 Skill，甚至认为 Skill 用的好就能大大提升产出质量。我对 Skill 使用有一条原则是，「只有模型和巴菲特都不知道的知识，才用 Skill」。比如巴菲特不知道 x.com 的 API ，巴菲特也不知道如何快速自动化调用浏览器，这些你装 Skill 会极大改进 AI 工作的效率。但是巴菲特很知道批判性思维，很知道实现一个东西之前得多问几遍问题，也知道如何正确提问，你不能装一个 「巴菲特 Skill」然后指望模型按照巴菲特的脑回路来运行，这种做法有几个缺点：

1. 不是每个任务都需要按照巴菲特的思考来运行的，Overthinking 本来就已经是模型的一个天生缺点了，加上 Skill 会极大放大这个缺点
2. Skill 装多了，你不知道什么是模型的内置思考，什么是 Skill 的引导，什么又是你自己的引导
3. 大多数人装之前不会完整阅读完 Skill，而你不知道 Skill 会干嘛，你就很难预期每次会话模型会产生什么回复，这是在黑盒编程

我日常的 Skill 很简单，一个 Lark Skill & CLI 来帮助我利用 Lark 的能力解决办公的协同问题，一个 ego-browser Skill 帮我自动化浏览器任务，然后就没有任何其他 Skill 了。我每次和模型对话，都能清楚预期对面的反应，这样我就能驾驭我的模型了，我想要模型批判性思考的时候，它就批判性思考，我想要它别多想给我使劲干它就使劲干。我们是一个人，不是机器，况且连机器现在都能学习，如果你觉得某个人的思维方式很好，你应该学习这个人思想，然后操控模型，而不是去 github 找一个这个人的 Skill 装到你机器上。

少命令，多提问

假如你要实现一个需求是，用户注册后发一封邮件，有几种提示词：

• 提示词 A: /register 接口下调用 resend 接口发一封注册邮件
• 提示词 B: 注册后发一封邮件
• 提示词 C: 我想要实现发注册邮件的功能，有哪些实现方法？

你可能会觉得，注册后发邮件这个功能多简单，怎么问不都能实现吗？都能实现没错，但是我敢说无论用不用AI大部分人都实现不好这个需求。因为你要考虑：

1. resend 接口挂了咋办，注册的接口是返回成功还是失败？
2. 如果返回失败，不代表用户注册也失败了吗，有必要这么严格吗？
3. 不管返回什么，resend 失败得重试，我又要怎么去重试？总不能这个接口同步等待重试吧？

提示词 A 的问题在于，你是一个「精确命令」，大部分模型真的会按照你的命令做，这样模型也不会深度思考，你也不会深度思考你的需求本身的复杂性，结果就是落下了一个隐患在代码里。

提示词 B 的问题在于，你是一个「模糊命令」，模型不一定会来给你方案选择，而是自己一股脑闷头实现了，它可能实现对，也可能实现错，不仅你和模型都没有深度思考，你如果不 review 代码认真点，你甚至都不一定知道它最后是用什么方法实现的，纯黑盒了。

而提示词 C ，因为是一个问句，而且我特地加了一个魔法词「哪些」，所以模型会深度思考不同方案，比如简单实现，或者发一个注册消息，让consumer来幂等消费这个事件直到成功。最关键的是，最后拍板的人是你，而不是模型。这才叫真正的驾驭模型。

控制设计而不是代码

如果我要实现一个几百行代码量以上的改动，我都会让 AI 先生成一份 Lark 的设计文档，为什么我要强调是 Lark 文档是因为它是富文本文档，有丰富的工具集。我之前公司只能用 Jira，那倒霉玩意生成的文档根本不可读。如果你公司不用 Lark，你也可以让它生成 HTML 文档。AI 会画一些架构图/流程图，能够比命令行窗口的文字更能帮助你理解它的设计。你理解了设计，才能提出比 AI 自己的思考更有价值的见解，从而优化设计或者简化设计。

另外，设计文档也能帮 review 你代码的能快速理解你的实现。至于代码本身，现在的模型能力很难出现设计文档是对的，代码是错的的情况，所以取决于你这个 PR 的重要性我觉得是否 review 已经没有那么重要了。

选择性向后兼容

现在很多模型有一个习惯是，喜欢写向后兼容的代码，这个代价就是为了兼容让代码变得很脏很复杂。模型并不知道你们生产环境的部署顺序，也不知道这个产品是否已经上线有真实用户，更不知道这个产品是否允许停机维护。但是你知道这些上下文，所以你需要根据实际情况做取舍，如果允许破坏兼容性，那就让模型写最优解的代码，而不要管是否兼容，这样对项目的长期维护有很大好处。

善用 AI Review

现在的代码生产速度，人力 Review 已经不太现实了，所以很多人都会用 AI Review 来替代人工 Review。在大部分情况下确实有很好的效果，但是，我 100% 反对那种一个 Agent 写代码，一个 Agent Review 产出意见，第一个 Agent 再根据 Review 意见写代码的 Loop 编程。

这里有一个关键问题是，如果 Review Agent 共享了 Coding Agent 的上下文，它 Review 的意见就不客观了，如果它不共享，它的上下文就不充分了。且不说还有一部分上下文存在于使用者自己的脑子里。让 AI 自己循环工作，最终产生的结果是不确定的，甚至可能偏离了你当初最早让 Agent 干的活的意图。我更倾向于，AI Review，人工检查 Review 意见，摘取部分让 Coding Agent 修改，再反复。虽然速度会慢，但正如上文所述，编程速度的问题早就已经解决了，现在的问题是质量，特别是如果质量提升，我们人类还得明确知道哪些质量提升。

保持勤奋

上面说了这么多，难道每一条在每一次对话里我自己都能做到吗？完全不能。我发现比模型更喜欢偷懒的是人。

大部分需求，AI 可以 10 分钟就完成，也可以和它反复对话十几轮花几个小时完成，目前的工作方式没有公司能来审核你的勤奋度，完全靠个人意识。如果你今天想早点下班，你就可以偷懒一点，让 AI 快速把活干完了。而就算你今天加班干到很晚，可能产出质量也就是从 80 分提升到 90 分，有这个必要吗？这可能会是未来会改变我们工作方式的很大一个话题，就目前这个过渡阶段，我们能做的只有时刻提醒自己，保持勤奋，至少在重要的事情上保持勤奋，这其实比上面所有奇技淫巧都重要。