前言

AI 已经能极其高效地帮我们搞定业务代码了。

这个结论经过反复验证，基本上没什么悬念。

但问题也随之而来：越是这样，越容易陷入失控状态——想到哪写到哪，总盼着 AI 一口气把活儿全干了。

业务代码和 demo 最大的不同在于，业务从来不是孤立的。

它牵扯着一连串的业务流程、历史包袱、数据状态、权限边界、团队规范、上线风险和长期维护的成本。

所以，用 AI 写业务代码，真正的重点从来不是怎么让它多写，而是怎么让它在受控的范围内写对。

下面这些实践经验，一部分来自我自己的经历，另一部分来自和不少同行深入交流后的思考。希望能帮到大家。

一、先理业务流程，再让 AI 写代码

经常会看到有人用 AI 写业务代码时，很笼统地把需求扔过去，比如“帮我实现订单退款功能”。结果 AI 做出来的东西往往不尽如人意，然后就开始上火，甚至跟 AI 争执。

原因很简单：AI 生成代码时，通常会默认很多业务假设。

比如在退款流程里，它可能默认订单只存在“已支付”和“已退款”两种状态——它根本不了解真实的业务流程和场景。

这些假设一旦和真实业务不一致，代码生成得越多，后面改起来就越痛苦，哪怕中间 review 也会让人头大。

更好的方式是：先自己把业务流程理清楚。

写代码之前，至少要搞清楚：

• 这个功能涉及哪些角色？
• 每个角色能做什么？
• 主流程是什么？
• 异常流程有哪些？
• 数据状态如何流转？
• 哪些地方需要权限校验？
• 哪些地方需要事务？
• 哪些地方可能失败？
• 失败后如何补偿？
• 哪些逻辑是历史兼容？
• 哪些规则未来可能变化？

这一步，其实也可以让 AI 来协助，但不能完全交给它。可以提前让 AI 帮忙整理成资料，但真实性的判断必须由我们亲自把关。

二、先输出流程图、时序图

在让 AI 写代码之前，最好先让它输出结构化的材料，比如：

• Mermaid 流程图
• Mermaid 时序图
• 状态流转图
• 数据结构草案
• 接口设计草案
• 异常路径说明
• 落地步骤拆分

举个例子，可以先让 AI 输出一个业务流程图：

flowchart TDA[用户发起退款申请] --> B{订单是否可退款}B -- 否 --> C[返回不可退款原因]B -- 是 --> D[创建退款申请]D --> E[冻结相关金额或资源]E --> F[调用支付渠道退款]F --> G{渠道退款是否成功}G -- 成功 --> H[更新订单和退款状态]G -- 失败 --> I[记录失败原因并进入重试或人工处理]H --> J[通知用户]

再输出一个时序图：

sequenceDiagramparticipant User as 用户participant API as 业务服务participant DB as 数据库participant Pay as 支付渠道participant MQ as 消息队列User->>API: 提交退款申请API->>DB: 校验订单状态DB-->>API: 返回订单信息API->>DB: 创建退款单API->>Pay: 发起退款Pay-->>API: 返回退款结果API->>DB: 更新退款状态API->>MQ: 发送退款通知事件API-->>User: 返回处理结果

别小看这些 mermaid。首先，它们能强迫我们先思考清楚业务；同时，这些文本化的 mermaid 也能让 AI 更轻松地理解业务流程，一石二鸟。

如果流程图都没搞明白就直接让 AI 写代码，那大概率是无序与混乱的熵增。

三、务必先出方案，再做落地

流程图解决的是“看清楚业务”，而方案解决的是“想明白怎么做”。前者帮我们降低沟通成本——沟通成本在 AI 语境下约等于 token；后者决定后续落地是否稳定、可控。

正确的顺序应该是：

flowchart TDA[需求理解] --> B[业务流程梳理]B --> C[方案设计]C --> D[风险点确认]D --> E[任务拆分]E --> F[小步编码]F --> G[测试验证]G --> H[Code Review]H --> I[上线与回滚方案]

尤其是复杂业务，应该先让 AI 输出一版方案，而不是直接生成实现。

一个比较好用的提示词是：

先不要写代码。请先基于下面的需求，输出一份技术方案，包括：1. 业务流程2. 涉及的模块3. 数据结构变化4. 接口设计5. 状态流转6. 异常场景7. 权限和安全点8. 测试用例9. 分阶段落地步骤10. 可能的风险和回滚方案确认方案后，再开始分步骤实现。

细心的人应该已经发现了，这个提示词本身就包含了业务流程的梳理。

这样做的好处是，AI 会先进入设计模式或计划模式，而不是直接进入 Coding 模式。在 AI 的加持下，我们再也不必担心代码写慢了，所以更应该沉下心来把业务理清楚——哪怕起步慢一点，至少是在正确的方向上冲刺。

四、不要一股脑让 AI 写太多

AI 一次性写太多代码，看起来确实很爽，但实际上风险相当高。

如果只是自己写个 MVP 玩玩，让 AI 跑几个小时甚至几天倒也无所谓；但在公司写业务代码，还是得慎重。

常见的问题包括：

• 改动范围过大，难以 review
• 混入不必要的重构
• 生成了不存在的 API
• 破坏了原有抽象边界
• 引入重复逻辑
• 测试跟不上
• 出问题时不知道是哪一段导致的
• 回滚成本高

更好的做法是：小步快跑，分阶段生成。

像“帮我完整实现订单退款功能”这种提示词，就不要再用了。这种提示词看似直接，实则范围太大。AI 很容易在不了解业务约束、现有代码结构、历史方案和边界条件的情况下，直接自由发挥。

更好的方式，是先指定参考资料，再结合现有代码，让 AI 按步骤推进：

第一步：请参考《订单退款需求文档》和《退款流程设计方案》，结合现有订单相关代码，只分析当前订单状态和退款状态的设计，告诉我需要重点查看和可能修改哪些文件，不要写代码。

第二步：请参考《订单退款需求文档》和《退款单数据结构设计方案》，结合现有数据表结构和迁移脚本风格，只新增退款单相关的数据结构和迁移脚本，不要改业务逻辑。

第三步：请参考《订单退款接口设计文档》和前面确认过的退款单数据结构，结合现有订单接口代码风格，只实现退款申请接口，先不要接入支付渠道。

第四步：请参考现有订单模块的单元测试写法，以及《订单退款测试用例文档》，结合刚刚新增的退款申请接口，补充对应的单元测试。

第五步：请参考《支付渠道接入文档》和《退款失败重试方案》，结合现有支付模块代码，只接入退款相关的支付渠道逻辑，并处理失败重试场景。

第六步：请参考《订单退款需求文档》《退款流程设计方案》和本次所有代码变更，结合现有订单、支付、退款相关代码，检查整个 diff，指出潜在风险、遗漏场景和需要人工重点 Review 的地方。

粒度越小、边界越清晰、参考越丰富，质量控制就越轻松。别追求一次性生成完整功能，要追求每一步都可理解、可验证、可回滚。

五、必须通过 Git 控制过程

Git 一定是必选项。也许未来会有更好的控制载体，但就目前而言，Git 是最好的选择，没有之一。

AI 生成代码的速度实在太快了，如果没有版本控制，很容易出现这些问题：忘了改过哪些文件、不知道某个 bug 是什么时候引入的、想回滚但回不干净、多个方案混在一起、临时实验污染主分支……然后又得抓耳挠腮，跟 AI 干瞪眼。

所以，在让 AI 大量修改代码之前，一定要保证 git status 是干净的。每完成一个独立步骤，就做一次原子化提交。

所谓原子化提交，就是一个 commit 只做一件事。比如：

feat(refund): add refund order modelfeat(refund): implement refund apply APItest(refund): add refund application testsfix(refund): handle duplicate refund requestrefactor(order): extract refundable status check

如果觉得英文比较难理解，用中文 commit 信息也可以，形式不重要，能看懂最重要。

千万不要把这些东西混成一个巨大的提交，比如 feat: update refund logic。这种提交对 review、排查和回滚都很不友好。

当然，让 AI 自己提交代码，并不意味着可以完全放任它随意提交。恰恰相反，越是依赖 AI 参与开发，越要把每一步改动控制在足够小、足够清晰、足够可验证的范围内。每一个 commit 最好都对应一个明确的小任务——要么是新增数据结构，要么是补充接口逻辑，要么是增加测试用例，要么是修复某个边界问题。不要让多个目标混在同一个提交里。

因为你需要随时能回答：这个改动解决了什么问题？它会不会影响其他逻辑？万一出了问题，回滚起来方不方便？

六、worktree 是个好东西

git worktree 非常适合 AI 编码场景。它让你可以在同一个仓库下，同时 checkout 多个工作目录。

这样一来，你可以让不同方案彼此隔离，而不是都堆在一个目录里；同时开发多个互不影响的需求，也不受分支束缚。

例如：

git worktree add ../project-refund -b feat/refundgit worktree add ../project-coupon -b feat/coupon

你可以在一个 worktree 里实现方案 A，在另一个 worktree 里尝试方案 B。

这样做有几个好处：

1. 更安全：AI 想怎么改都在独立目录里，不会污染当前工作区。
2. 方便对比方案：可以让两个 worktree 同时做一个需求，两个方案可以分别跑测试、看 diff、做 benchmark。
3. 方便丢弃失败尝试：如果某个方案很糟糕，可以直接删除 worktree 和分支。
4. 减少上下文混乱：不同任务、不同分支、不同改动互不干扰。
5. 适合多 Agent 并行探索：如果你使用多个 AI coding agent，worktree 可以天然隔离它们的修改范围。

常见流程可以是：

git statusgit worktree add ../project-feature-x -b feat/feature-x-aicd ../project-feature-x# 让 AI 在这里修改代码# 跑测试# review diff# 满意后再合并回主开发分支

现在 Codex、Claude Code 等工具都已经内置支持 worktree，可以抓紧用起来——只有用过才知道有多爽。

七、AGENTS.md 和 CLAUDE.md 非常重要

这也是 AI 编程里让人非常头疼的上下文问题。常见的解决方案是 AGENTS.md 和 CLAUDE.md。

它们的作用是告诉 AI：项目是什么、技术栈是什么、目录结构如何、如何启动项目、如何运行测试、代码风格是什么、哪些文件不能随便改、提交规范是什么、常见业务概念是什么、常见坑有哪些、修改代码前需要先做什么、完成后需要检查什么。

一个好的 AGENTS.md 或 CLAUDE.md，就像是给 AI 的员工手册和绩效指南。

例如可以包含：

# Project Guidelines## Tech Stack- Backend: Node.js + NestJS- Database: PostgreSQL- ORM: Prisma- Test: Vitest## Commands- Install: pnpm install- Dev: pnpm dev- Test: pnpm test- Lint: pnpm lint- Typecheck: pnpm typecheck## Rules- Do not modify database schema without migration.- Do not change public API response format without updating docs and tests.- Always add tests for business logic changes.- Keep commits atomic.- Prefer existing utilities over creating new helpers.- Do not introduce new dependencies without explanation.## Workflow1. Understand the requirement first.2. Propose a plan before editing files.3. Make small changes.4. Run relevant tests.5. Summarize changed files and risks.

这些信息不能太复杂，追求言简意赅。至少得让 AI 知道项目的基本边界和平时开发的注意事项。

八、规则文件要持续维护，但不能无限膨胀

AGENTS.md 和 CLAUDE.md 不是一次性写完就结束了。在使用 AI 的过程中，你会不断发现：AI 经常误改某些文件、忘记跑测试、用错包管理器、新建重复工具函数、忽略业务边界、写错错误码、破坏接口返回格式……这些问题都应该沉淀进规则文件。

但这就引出了另一个问题：规则文件很容易越写越长，最后变成一堆没人读、AI 也抓不住重点的杂乱笔记。因为提示词过载会稀释上下文权重，导致 AI 难以识别真正高优先级的约束。

所以维护规则文件要注意几个原则。

1. 只写高频、稳定、重要的规则

不要把所有细枝末节都写进去。适合写进去的是：经常发生的问题、一旦发生影响很大的问题、项目长期稳定的约定、新人和 AI 都容易踩的坑。不适合写进去的是：一次性的临时需求、某个人的个人偏好、已经废弃的历史说明、过度细节的实现过程。

判断标准很简单：这条规则未来半年内是否仍然适用？如果答案是否定的，就没必要写进去了。

2. 把规则写成可执行的指令，不要写散文

AI 更容易遵守明确指令，而不是长篇解释。

不推荐：“我们项目比较重视测试，所以大家在写代码的时候最好注意一下测试相关的问题。”

推荐：

- Any business logic change must include or update tests.- Before finishing, run `pnpm test` for affected packages.- If tests are not run, explain why in the final summary.

规则要尽量具体：做什么、不做什么、什么时候做、用什么命令做、例外情况怎么处理。

3. 分层组织，不要堆成一大坨

规则文件可以按优先级和主题拆分。例如：

# AGENTS.md## Non-negotiable Rules## Project Commands## Architecture## Coding Style## Testing## Git Workflow## Security## Common Pitfalls

最重要的规则放前面，因为 AI 的上下文有限，越靠前越容易被注意到。

可以使用这种结构：

## Non-negotiable Rules- Never commit secrets.- Never change public API response formats without tests.- Never modify generated files manually.- Always keep changes small and reviewable.

4. 用反例记录常见问题

有些规则只写正向说明不够，最好加上一两个反例。例如：

## API ResponseUse the existing response wrapper:Good:return success(data)Bad:return { code: 0, data, message: 'ok' }

AI 极其擅长模仿已有模式。给它明确的 Good / Bad 示例，比抽象描述更有效。

5. 定期清理过期内容

规则文件需要维护，不是只增不减。建议每隔一段时间检查一次：哪些规则已经过期？哪些命令已经变了？哪些目录结构已经调整？哪些限制已经不再适用？哪些内容可以合并？哪些内容应该删除？一个好的规则文件应该是高密度的，而不是空有长度。我们的目标也不是要写成百科全书，而是让 AI 在最短时间内能够抓住最重要的约束。

6. 把经验沉淀成原则，避免流水账

不推荐这样写：“2025-01-03：AI 修改 refund.ts 时忘记处理 duplicate request。2025-01-08：AI 又忘记处理 duplicate request。”

推荐沉淀成规则：

## IdempotencyFor payment, refund, order creation, and webhook handling:- Always consider idempotency.- Use existing idempotency keys where a vailable.- Add tests for duplicate requests.

经验一定要抽象成可复用的规则，否则规则文件会变成流水账，臃肿又没有营养。

九、让 AI 参与 review，而不是只参与 coding

AI 不应该只用来写代码，也应该用来检查代码。

在每一轮修改后，可以让 AI 做几类 review：

请 review 当前 diff，重点检查：1. 是否偏离需求2. 是否有多余改动3. 是否破坏现有架构4. 是否缺少异常处理5. 是否存在权限问题6. 是否有性能风险7. 是否需要补充测试8. 是否可以拆成更小的 commit

也可以让 AI 从业务角度检查：

请不要关注代码风格，只从业务正确性角度 review 当前实现。重点看状态流转、异常场景、幂等、并发、权限和数据一致性。

还可以让 AI 从上线风险角度检查：

请从上线风险角度评估当前改动：1. 可能影响哪些已有功能？2. 哪些地方需要灰度？3. 是否需要数据迁移？4. 是否有回滚方案？5. 应该重点观察哪些日志和指标？

写代码只是 AI 的一部分价值。让 AI 帮我们审查方案、审查 diff、补测试、找风险，也许比写代码本身更有价值。

最后

AI 确实可以提高产出速度，但不能代替我们承担责任——这话也许更应该发给老板们看。

业务代码上线后，真正承担后果的还是开发者和团队：

• 数据错了
• 订单状态乱了
• 权限穿透了
• 性能崩了
• 线上事故了

这些问题，AI 可不会负责。哪怕我们喊破嗓子说是 AI 搞坏的，老板也只会觉得是我们不会用 AI——最终背锅的，还是我们。