用 AI 编程工具写代码的五个实战原则：从能用到好用的距离

原创。五个经过实战验证的 AI 编程原则，帮你把 AI 从"代码生成器"变成真正的"编程搭档"。

AI 编程工具已经不再是新鲜事了。Cursor、Claude Code、GitHub Copilot、Windsurf——这些工具每天都在产生海量代码。但一个有趣的现象是：同样用 AI 写代码，有人产出的代码质量稳定、可维护，有人却越写越乱，最后不得不重写。

差距不在工具本身，而在使用方式。

这篇文章分享五个我在实际项目中验证过的原则。它们不复杂，但每一条都能显著改变你跟 AI 协作的方式。

原则一：把 AI 当实习生，不要当外包

很多人用 AI 的方式是：丢一段需求描述过去，等它生成代码，复制粘贴，完事。

这相当于把 AI 当成外包团队——"我要一个登录功能，你做完给我"。问题是，外包团队至少会问你几个问题，AI 不会。它只会根据你给出的信息尽可能推测，然后给出一个"看起来对"的方案。

更好的方式是把 AI 当成一个聪明的实习生。实习生能写代码，但需要指导、需要上下文、需要反馈。

具体做法：

• 给 AI 看现有的代码结构，让它理解你的项目风格
• 明确告诉它边界条件："这个函数要处理空输入"、"这里必须用事务"
• 生成完后要求它解释关键决策："为什么选这个算法？"
• 不满意的地方直接说："这里太复杂了，简化一下"

我常用的一个技巧是，在让 AI 写新功能之前，先让它读相关的现有代码。比如："看一下 src/auth/login.ts 里的登录逻辑，然后帮我写一个密码重置功能，保持同样的错误处理风格。"

这样生成的代码风格一致，而且 AI 会复用你项目里已有的工具函数，而不是重新造轮子。

原则二：小步快跑，不要一次生成太多

AI 能一次生成几百行代码，但这不意味着你应该让它这么做。

代码量越大，出错的概率越高。而且一旦出错，你很难定位问题出在哪一段。更糟的是，大量代码会让你产生"已经做完了"的错觉，跳过仔细审查的步骤。

我的做法是：

把大任务拆成 3-5 个步骤，每一步让 AI 只做一件事。

比如实现一个 API 端点：

1. 先写路由和参数校验
2. 再写数据库查询逻辑
3. 然后加错误处理
4. 最后写测试

每完成一步，我检查一遍，确认没问题再进入下一步。这样每步的代码量控制在 20-50 行，审查起来很轻松。

一个小技巧：在 Cursor 或 Claude Code 里，用 "@" 引用具体的文件和函数，让 AI 的上下文保持聚焦。不要让它同时处理整个代码库。

原则三：要求 AI 写测试，而且先写测试

这可能是提升代码质量最有效的单一技巧。

当你让 AI "先写测试，再写实现"时，神奇的事情会发生：

• AI 被迫先理解需求边界，而不是直接跳实现
• 测试用例会暴露需求描述中的模糊之处
• 实现代码自然会更符合测试预期
• 你得到了一份可以运行的回归测试

具体操作：

不要只说"写个测试"。要具体："给这个函数写三个测试：正常输入、空数组输入、超大数组的性能测试。"

如果 AI 写的测试太简单——只测了 happy path——要求它补充边界情况："再加两个测试：网络超时的情况、并发请求的情况。"

测试不只是为了验证正确性，更是一个沟通工具。测试用例描述了你期望的行为，AI 根据测试来写实现，相当于用代码来沟通需求。

原则四：让 AI 解释，不要只让 AI 写

AI 生成的代码不一定是最优的。有时候它选了一个复杂的方案，因为训练数据里这种方案更常见。有时候它遗漏了性能考量，因为提示里没提。

养成一个习惯：每次 AI 生成完代码，问它三个问题：

1. "这个方案的时间/空间复杂度是多少？"
2. "有什么边界情况没处理吗？"
3. "如果数据量扩大 100 倍，这个方案还适用吗？"

这些问题会迫使 AI 从"生成模式"切换到"分析模式"。很多时候你会发现，AI 自己也会意识到方案有问题，然后给出改进版本。

另一个有用的技巧是让 AI 对比不同方案："用 Map 和用 Set 实现这个功能，各有什么优缺点？"

这种对比能帮你做出更 informed 的决策，而不是盲目接受 AI 的第一个建议。

原则五：保持代码的"可 AI 维护性"

这是最容易被忽视的一点。

AI 生成的代码本身没问题，但如果你的代码库结构混乱，AI 很快就会开始"瞎猜"。它找不到工具函数的位置，看不懂业务逻辑的分布，最后只能硬编码或者重复实现。

让代码对 AI 友好，其实跟让代码对人友好是一回事：

• 文件和函数命名要直白。processData() 对 AI 来说毫无意义，validateUserInput() 就清楚多了。
• 一个文件只做一件事。AI 读代码时上下文窗口有限，文件越小，它越容易理解全貌。
• 关键逻辑加注释。不是加"这是什么"，而是加"为什么这样"。AI 读注释后，生成相关代码时会更贴合你的设计意图。
• 保持一致的代码风格。AI 会模仿它看到的模式。如果项目里既有 async/await 又有 Promise.then()，AI 就会随机选择，导致风格混乱。

一个实用的检查方法：把你的代码库丢给 AI，问它"这个项目的代码结构是怎样的？主要模块有哪些？"如果 AI 的回答跟你的实际结构相差甚远，说明代码的组织方式需要改进。

一个完整的实战示例

让我用一个具体例子展示这五个原则如何一起工作。

假设我要实现一个功能：从 API 获取用户列表，按活跃度排序，缓存 5 分钟。

步骤 1：给上下文

"看一下 src/utils/api.ts 里的请求封装和 src/cache/redis.ts 里的缓存工具。我要在 src/users/ 下实现一个获取活跃用户列表的功能，用这些现有工具。"

步骤 2：先写测试

"基于上面的需求，先写三个测试：正常返回、缓存命中、API 超时。"

步骤 3：小步实现

"先写获取用户列表的基础逻辑，不加缓存。"

"现在加上 Redis 缓存，TTL 300 秒。"

"最后加上按活跃度排序。"

步骤 4：要求解释

"这个缓存方案在并发场景下会有问题吗？如果有，怎么解决？"

步骤 5：检查可维护性

"如果三个月后我要把 Redis 换成 Memcached，这个实现需要改多少地方？"

按照这个流程走下来，你得到的代码不仅功能正确，而且结构清晰、有测试覆盖、考虑了边界情况、容易维护。

最后的话

AI 编程工具不是魔法。它不会自动让你变成更好的程序员，就像计算器不会自动让你变成更好的数学家。

但如果你能把它当成一个能力很强的搭档——给它上下文、拆小任务、要求测试、追问原理、保持代码整洁——它确实能帮你做到以前做不到的事。

关键是，好的结果来自好的协作方式，而不是更好的模型。

模型会越来越强，但使用方式决定了你能从中获得多少价值。这五个原则不需要你换工具，只需要换习惯。而习惯，是每个人都可以从今天开始改变的。