让 AI 带着镣铐跳舞

原载于我的独立博客： https://lutaonan.com/blog/ai-coding-principle/

最近临时在帮朋友做一些外包，基本上代码都是 AI 写的，我想如果不是有 AI, 我大概不会帮这个忙，因为即使这些活不难，我还是要写很多代码。但现在，我可以一个人同时做 2-3 个项目。

在这个过程中，更加让我确定了对于程序员来说，软件开发的范式已经彻底彻底改变了。生成代码再也不是程序员「应该」做的事情，而是应该被放手给 AI 做的事。

这也让我对判断一个程序员的能力从代码能力转变成了使用 AI 的能力，我想，如果我现在要为团队招程序员，我会在面试时着重了解这个人如何使用 AI 完成一个需求。

对于程序员来说，「使用 AI 的能力」包含很多维度，这些维度综合起来，才决定 AI 是否真正能成为程序员的杠杆：

对业务的理解

软件是为解决用户的需求而生的，对业务充分理解，才能给 AI 足够的业务场景上下文，才能让 AI 写出覆盖边界条件的代码。

对业务的理解同时决定了程序员是否可以做好数据库建模。在接我朋友的外包项目时，我发现我人工干预最多的就是数据库建模。只要我思考好建模，AI 就能基于这个数据库模型编写任何接口。

对技术栈的理解

如果能让 AI 限定在特定的技术栈中，你会发现 AI 更能稳定发挥，更可控。让 AI 「带着镣铐跳舞」。无论用什么技术栈，重点都是给 AI 一条稳定的轨道。比如我在所有项目的 AGENT.md 中都会列出非常细节的选型，例如 CC Mate 的 https://github.com/djyde/ccmate/blob/main/CLAUDE.md

当 AI 知道技术栈后，通过 context7 这样的 MCP, 它能在生成代码时，找到对应的文档作为上下文，生成出更不容易出错的代码。换句话说，确定好技术栈，让 AI 成为这个技术栈的专家为你编写代码。

因此，在这个层面，程序员的「使用 AI 的能力」意味着，这个程序员知道什么样的场景适合什么样的技术栈，也侧面反映了这个程序员对技术社区是否保持敏锐的嗅觉。这是我认为 AI 时代程序员的一种硬实力。

对架构的理解

在《代码之外》听友线下见面会中，有听友提问，在 vibe coding 的时候，AI 只能做些一次性的软件，多次迭代后就会变成灾难。我的回答是，这是因为没有给 AI 提供一个你设计好的工程架构，让他在这个架构中行动。在这个新的时代，程序员应该以架构师的角度来工作。

我在 AI coding 一个项目前，我的脑海里会大概有一个工程架构的设计，比如，通用工具应该被统一放到一个什么文件，前端页面应该如何组织，接口应该遵循什么样的规范，错误处理应该怎么做等等。只要架构设计好，写在 AGENT.md 中，AI 自然会按照你的设计去做，而不是让 AI 天马行空地发挥。

不仅是在启动这个项目前要做好架构的思考，在维护的过程中，你指挥 AI 完成一个新的需求时，就应该思考完成这个需求的时候，将会有什么代码被写在哪一个地方。这个场景也适合使用各个 AI coding agent 的 Plan Mode 来完成，当 AI 告诉你它将要如何行动时，适当二次确认它要如何组织新的代码。

做到以上三个理解，我相信程序员可以游刃有余地使用 AI. 但我曾经在很多场合接触一些在一线写代码的程序员，发现他们对 AI 的接受程度是如此地低。很大程度上，我认为是一个缺乏以上三个理解的程序员，很难对 AI 建立信任关系，合作关系。

和我合作的一位程序员，在共同完成一个需求的时候，我在他旁边观察了一下他如何使用 AI, 结果只是非常浅地使用 auto complete. 我问他，为什么不尝试让 AI 完整地完成这个需求，他表示他认为 AI 不能胜任这个任务。

我说：

1. 我的后端接口已经写好了，而且有了 openapi 的 YAML 文件（ AI 生成的）
2. 你知道这个需求涉及前端的哪个页面，在前端项目中，也有对数据请求层进行封装（ AI 一定能知道怎么写数据请求）

满足了这两个条件，你只需要把接口文档给 AI, 然后告诉 AI 这次的需求，再告诉 AI 一点提示，大概是在哪个文件中修改。以现在旗舰模型的能力，AI 大概率能一次性完成。

他将信将疑，我直接在他电脑上给他演示这个操作，果然，AI 直接完美地完成了这个需求，不到 2 分钟。

而同时我也在思考，到底 AI 时代是否还需要程序员，或说需要怎样的程序员，好像渐渐有了答案。