瑶瑶宝先说一个不那么让人舒服的判断：AI 编程工具确实让很多小团队的生产速度上来了，但代码质量并没有跟着自动变好，甚至更容易崩了。我带过的几个“草台班子”风格项目，都出现过同一种情况——AI 写代码又快又像样，代码量在两周内翻了一倍，结果月底改 bug 的时间也翻了一倍。原因不是 AI 太弱，而是我们把 AI 当成了“手速很快、不需要管理”的外包，却没有给它一套和代码质量相关的规则。
如果你所在的团队是三五个人的小开发组，或者你是一个人带 AI 写业务系统的独立开发者，这篇内容会比较适用。我会把这两年实际踩过的坑、试过确实有效的办法、以及最后沉淀下来的流程模板摊开讲。核心思路不是让你去买更贵的 AI 工具，而是怎么用比较轻的机制，让 AI 生成的代码从“看起来能跑”变成“长期敢改”。
1. 为什么很多团队用上AI以后，代码反而越来越没法维护了
1.1 生成速度比评审速度快了一个数量级
以前一个功能需要手写一两天，代码评审的时间可以跟上开发节奏，哪怕没有评审，至少代码是写代码的人自己一行行敲出来的，哪里有隐患他心里多少有数。
AI 介入以后，这个平衡被打破了。一个任务给到 Cursor 或者类似的编程助手，五到十分钟就能生成几百行代码。哪怕团队里有严格的代码审查，一个人逐行去看几百行 AI 代码，算上理解上下文、跑测试验证逻辑，最快也要半小时以上。当每天涌入上千行新代码时，评审速度就完全跟不上了。
更麻烦的是草台班子通常没有专职的技术负责人去卡质量。大家觉得“AI 写的应该差不离”，于是代码直接合并进主干，越积越多。这些代码最初的正确性没人验证，后来维护时更没人敢动。AI 没有放大开发速度的好处，反而放大了技术债的生产速度。我见过一个小组两周生成了八千行代码，第三周排查线上问题时，有一千多行被注释掉不敢删也不敢改，因为没人说得清那些逻辑原本在支撑什么。
1.2 AI擅长生成“看起来很专业”的平均数代码
仔细看 AI 生成的代码，你会发现一个特点：结构规整、命名合理、注释也齐全，非常接近主流仓库里的“标准答案”。但问题的另一面是，它本质是在生成“看起来合理的平均数”，而不是基于你的业务推导出来的确定性方案。
举例来说，如果让你手写一个带缓存的用户详情接口，你会先想：缓存失效怎么处理？分布式环境下有没有并发穿透？用户删除以后缓存要不要同步清掉？但 AI 生成时，它会默认给你一个最典型的缓存读写模板，在大多数正常场景下没问题，却未必覆盖这些边界。更要命的是，这类代码看起来非常专业，审查者会不自觉地降低警惕，把注意力从逻辑正确性移到代码风格上，于是真正有风险的边界条件反而被放过了。
所以我会说，AI 输出的是“高置信度垃圾”的概率比想象中高。它最大的危险不是写错，而是错得很自信，让人看不出哪里需要质疑。
1.3 草台班子最缺的不是写代码的能力，而是对“质量”的定义
很多小团队对质量的理解停留在“能编译”“能跑通”“演示不出 bug”。这在过去人手写代码的时代勉强够用，因为人写代码慢，逻辑出错的边界也有迹可循。可当代码由 AI 大批量生成时，如果没有明确的质量定义，等于让 AI 用训练数据里的平均审美替你做技术决策。
我在帮团队搭流程时，最先做的一件事往往不是引入测试框架，而是坐下来一起回答一个问题：什么样算“完成”？这个 PR 要满足哪些条件才能合并？要跑哪些测试？边界条件要列到什么程度？新增代码超过多少行必须拆？没有这个基准，后面上再多的工具也只会沦为形式。
因此草台班子提升 AI 代码质量的第一步，不是学提示词技巧，而是先建立一套把“质量”讲清楚的最小规范。有了标准，AI 才有依据，人也才有复核的抓手。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先给AI立规矩：把“项目宪法”写进规则文件里
2.1 需求prompt只定义了“做什么”，没定义“做到什么样”
大多数人让 AI 写代码是这么沟通的：“帮我写一个订单导出功能，支持筛选日期范围。”这个 prompt 只定义了做什么，完全没有指出异常处理、性能上限、日志规范、权限校验这些“做到什么样”的要求。AI 收到的信息越少，就越会按自己的平均经验补全，而这些补全经常不符合项目里的实际约定。
我之前在一个项目里遇到的问题是：不同的对话让 AI 写同一类接口，它每次都用了不同的返回结构。有的返回 {code, message, data}，有的直接返回数组，有的嵌套了一层 result。前端对接时差点暴走。问题的根源不是 AI 能力不稳定，而是我们没有在它开工前把项目的统一规范传进上下文。
草台班子必须明白一个基本事实：AI 没有记忆力，每次新对话都像新人入职。你不能指望它主动理解项目约定，必须把关键规则变成显性文件，让它每开一个任务就先读到这些规则。
2.2 一份可以直接抄的“项目宪法”示例
我习惯在项目根目录放一个文件叫 AI_GUIDE.md，内容刻意控制篇幅，太长 AI 会“选择性失明”。只选真正影响正确性和可维护性的强制项，一般不超过十二条。
下面是我常用的模板，你可以按自己的技术栈删改：
markdown复制# AI_GUIDE.md
这是 AI 在本仓库写代码时必须遵守的规则，优先级高于一般需求描述。
1. 动工前先说明实现方案，涉及数据库变更时必须给出迁移语句，不得直接改表结构。
2. 只改动与本次需求直接相关的文件，禁止顺手重构无关代码。
3. 新增函数超过 40 行时必须拆分，拆分后每个函数只做一件事。
4. 所有外部输入先做校验，再进入业务逻辑，禁止信任前端传来的数据。
5. catch 块里禁止只记录日志后继续跑，必须明确说明要如何降级或终止。
6. 除纯查询外，多个写操作必须放同一个事务里，禁止拆成多条无事务命令。
7. 禁止自行发明轮子，优先复用项目 src/utils 下的已有函数。
8. 并发场景要考虑竞态条件，更新操作必须使用原子条件或显式锁。
9. 涉及文件句柄、网络连接、数据库连接时，使用上下文管理器或确保 finally 释放。
10. 新增逻辑必须用测试覆盖核心路径，测试不能 mock 掉被测对象自身的关键状态。
如果需求涉及的钱、库存、权限、数据删除等高风险领域，动工前先向用户请求确认。
这份文件并不长，但每一条都是真实项目里能直接拦住重大事故的硬约束。你在实际使用中可以根据项目特点扩展，比如规定 API 错误码格式、禁止在业务代码里使用裸 SQL 等。规则条目宁少勿多，最怕列了三十条，AI 记不住，最后一条都不执行。
2.3 不同的AI编程工具，规则文件放在哪里
把规则写出来之后，还要确保 AI 每次都能读到。不同工具的加载机制不太一样，我列一个当前比较常见的对应关系，方便你按自己的工具链放置：
| 工具 | 规则文件位置 | 备注 |
|---|---|---|
| Cursor | .cursor/rules/*.mdc 或项目根目录 .cursorrules |
新版本推荐用 .cursor/rules 目录管理 |
| GitHub Copilot | .github/copilot-instructions.md |
写在仓库里，Copilot 会自动读取 |
| Claude Code | CLAUDE.md |
放在项目根目录或子目录 |
| 各类支持 AGENTS 约定的 Coding Agent | AGENTS.md |
很多开源 agent 支持此约定 |
| 通用场景 | 在每次 prompt 中直接粘贴 AI_GUIDE.md 内容 |
不依赖具体工具 |
如果你们团队用多个工具，我的建议是维护一份 AI_GUIDE.md 作为唯一事实来源，再通过脚本生成不同类型工具的规则文件，避免同一份规则在不同地方出现多个版本。
还有一个容易被忽略的细节：规则文件不要只写给 AI 看，也应该在团队 Code Review 时作为检查依据。人看代码时对照着“项目宪法”一条条过，很容易发现 AI 是否越界。
3. 解锁AI工作流的关键一步：验收链要前置到写代码之前
3.1 把“完成定义”从形容词改成一条条可勾选的检查项
草台班子最常见的评审方式是“我看一眼，感觉没问题”。这不是评审，是走过场。AI 生成的代码尤其需要一套可勾选的验收清单，否则人review时很容易被代码量淹没，最后草草点了合并。
我通常会给 PR Description 设计一个固定模板，要求 AI 在提交时逐项填写：
- 本次改动涉及的模块和文件清单；
- 输入校验、异常处理分别覆盖了哪些场景；
- 数据库写入是否使用了事务，并发更新是否加了锁或条件约束；
- 涉及资源释放的代码路径是否做了 finally 或 with 处理；
- 单元测试覆盖了哪个核心行为，测试命令是什么；
- 这次改动没有动哪些约定/数据结构，有无对现有接口的破坏。
为什么这个清单有用？因为它逼 AI 在写代码时就把“完成”具体化。如果 AI 发现某一条做不到，比如没有测试，它会在说明里坦白，而不是假装一切正常。人对 AI 生成内容的审查也会更有方向，不用从头到尾做无差别阅读。
3.2 先让AI写测试用例再写实现，比直接要代码可靠得多
有一个习惯我试下来非常值钱：让 AI 正式生成实现之前，先让它列出准备覆盖的测试用例。
比如一个典型的 prompt：
text复制先不要写实现。
请阅读相关模块代码，列出完成这个功能需要覆盖的测试用例，分为正常路径、边界路径、异常路径三类。
每个用例都要写清楚：输入数据、执行动作、期望结果、断言什么。
我确认以后，你再开始写实现和测试代码。
这样做有三个好处。第一，AI 在动手前会先思考业务行为的边界，而不是直接跳到代码细节；第二，你可以在它写代码前纠正那些想当然的假设，避免白写几百行；第三，测试用例本身就是验收标准，后续实现跑不跑得过一眼便知。
我碰过很多次这样的情况：让 AI 先想测试时，它列出的异常路径里居然漏了“库存不足”“用户不存在”“重复提交”这类业务上最关键的场景。在我补充需求后，它生成的实现会明显更谨慎。这是提升 AI 代码质量投入产出比最高的一个动作。
3.3 用“行为基线测试”锁住重构，防止AI顺手改丢业务逻辑
AI 做重构时的最大风险不是代码写不出来，而是它会在重构过程中“很自然地”把旧逻辑改丢。这种丢失在测试覆盖率低的项目里几乎无法发现，只有功能上线后用户反馈才暴露。
防止这类问题，我倾向于在重构任何高风险模块前，先补一批行为基线的测试。所谓行为基线，就是用固定输入跑一遍现有代码，把输出结果或状态变化记录下来，存成快照；重构完成后再用同样输入跑一遍，对比两次结果是否一致。如果某个输出对不上，说明这次重构已经改变了行为，不管表面多正确都必须停下来重新审视。
举例来说，一个订单折扣计算函数要改结构，重构前把几十种历史订单输入输出存成 fixture，重构后跑一遍 diff。只要有快照差异，AI 就可以对照差异点快速定位改哪儿了。这个做法比让 AI“小心一点别改逻辑”靠谱得多，因为它把“不要改坏”变成了机器可检查的约束。
4. 搭一条草台班子也养得起的质量流水线
4.1 让第二个AI去审第一个AI写的代码，效果立竿见影
很多时候，AI 写完代码后同一个会话里让它自查，效果很差——它会维护自己刚才的产出，很难跳出来挑自己的毛病。正确做法是：开一个全新的对话，或者启动另一个 agent，只给它 diff 内容和相关上下文，让它以“挑刺方”的角色做代码审查，而且明确禁止它改代码。
我在实际项目中用的审查 prompt 是这样：
text复制你是一名代码审查者，只做审查，不提供修改后的代码，也不要提代码风格建议。
请审查下面这段 PR diff，按优先级检查以下几点：
1. 是否存在“先读旧值、再判断、再写入”这种可能产生竞态条件的写法；
2. catch 到异常后是否吞掉错误继续运行；
3. 文件、连接、锁等资源是否一定会在所有路径上释放；
4. 边界条件下是否会出现越界、空指针、除零或类型异常；
5. 测试是否覆盖了核心行为，断言是否真的有意义，而不是 mock 一切后的假绿。
对每个问题，按“文件:行号 / 问题描述 / 严重程度 / 建议修法”输出。
如果没发现问题，直接回答“未发现必须修改的问题”，不要写客套话。
这套 prompt 没有让 AI 关注命名、格式、注释风格，因为这些都有更便宜的静态工具去查。需要 AI 判断的，是逻辑和边界上的真问题。实际用下来，第二个 AI 常常能发现第一个 AI 没太注意的边界条件和错误处理遗漏。
4.2 AI审查的输出要分级，不然人会选择性忽略
AI 代码审查工具最喜欢犯的毛病是噪音太多。今天说“这个函数可以更简洁”，明天说“建议加注释”，所有问题混在一起，人看了几天以后就对这些提示彻底免疫，真正严重的问题也会被当作提示忽略掉。
所以我要求审查结果严格区分等级：
| 等级 | 含义 | 处理方式 |
|---|---|---|
| P0 | 可能导致数据错误、崩溃或安全风险 | 必须修复后才能合并 |
| P1 | 特定边界条件下可能出现问题 | 应该修复或补充测试后合并 |
| P2 | 可维护性建议，不影响本次功能 | 可以记录到 backlog，不阻塞合并 |
| P3 | 风格类意见 | 直接忽略，交给 Linter 处理 |
只有 P0 和 P1 需要人类立刻介入。P2 和 P3 不要塞进 PR 评论，否则会把真正需要关注的问题淹没。草台班子人少，注意力是最稀缺的资源，不能浪费在格式和可选优化上。
4.3 在CI里装上三道廉价但可靠的闸门
AI 审查属于“软性质量检查”，最终真正卡住代码的还需要一个硬性 CI 流水线。这里不会推荐一上来就上完整的 DevOps 全家桶，草台班子只需要三道闸：
第一道是静态检查，挡住格式和明显的坏味道；第二道是类型检查或编译，挡住定义不一致和接口破坏；第三道是关键路径的自动化测试，挡住行为回归。
下面是一份简化到能直接抄的 GitHub Actions 示例，语言可以换成你们自己的技术栈：
yaml复制name: quality-gate
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Install dependencies
run: |
pip install -r requirements-dev.txt
- name: Lint and static check
run: |
ruff check src tests
- name: Type check
run: |
mypy src
- name: Run tests
run: |
pytest -q
如果你用 JavaScript 技术栈，把依赖安装换成 npm ci，静态检查换成 eslint，类型检查换成 tsc --noEmit，测试换成 npm test 即可，思路完全一样。
这类流水线要设置成分支合并的硬门槛，CI 不通过就不允许合并到主干。这里有一个容易被忽略的细节：它不应该只服务多人协作。哪怕只有一个人开发，一旦你在主干上直接让 AI 修改代码，AI 产生一个很难察觉的逻辑错误，没有 CI 卡住就会直接进入生产环境。有了 CI，本地提交前跑一下，至少能把类型不一致、基础逻辑回归这类问题挡在一开始。
4.4 质量不是靠自觉，而是靠闸门
草台班子过去习惯靠“大家自觉一点”维持质量，但任何一个人用 AI 赶进度时都有可能想“先提交再说”。质量机制里最容易被忽视的一点是：如果你只是把检查工具配好，但允许人绕过它，那它就不叫闸门，只能叫良好愿望。
所以一定要在分支设置里开启 PR 必须通过 CI 才能合并的规则。GitHub、GitLab、Gitea 这些平台都支持这类保护。没有这个强制动作，再漂亮的流水线也只会成为摆设。我见过不只一个团队，CI 里全是绿灯，但成员因为着急，直接把代码推到了主干，结果流水线根本来不及发挥作用。
5. AI负责写，人负责管：定好边界才能不被Agent带偏
5.1 AI是一个特别勤快但没有常识的新员工
我把 AI 编程 Agent 比作一个特别勤快的新员工：你说“把这个模块整理一下”，它可能在一个小时内把整个项目的文件结构调整了，顺带升级了几个依赖版本。这恰恰是 AI Agent 在工作流里最容易出问题的点——它没有边界意识，也没有“哪些事不该做”的直觉。
所以我在给 AI 派任务时，要求每条任务必须包含三样东西：明确的目标、可验证的完成条件、不能触碰的边界。示例：
text复制目标：重构 src/payment/helper.py 中的金额计算函数，保持外部 API 不变。
完成条件：原有单元测试全部通过，新增两个精度边界测试。
边界：只允许修改 src/payment/helper.py 和 tests/test_payment_helper.py，不得改动其他目录。
如果重构过程中发现此文件被其他模块直接 import，请停止并汇报，不要自行扩大范围。
没有边界限制，AI 会本能地做“顺手改进”，这些改进往往超过需求范围，导致 diff 膨胀，让人更难 review。
5.2 不同风险的任务，放权程度应该不同
草台班子可以按下面这张表来分配 AI 的自主权，避免一刀切：
| 任务类型 | 典型例子 | 放权程度 | 人要做的事 |
|---|---|---|---|
| 低风险、确定性高 | 补注释、格式化、批量重命名局部变量 | 高，AI可放手做 | 看 diff 摘要 |
| 低风险、业务沾边 | 写独立工具函数、单元测试 | 中，AI做完自检 | 抽查边界条件 |
| 高风险、规则清晰 | 支付回调、库存扣减、权限校验 | 低，AI先写方案和测试再实现 | 逐条核对方案 |
| 高上下文、混乱模块 | 老模块逻辑梳理、跨模块改造 | 极低，人类先定义行为再让AI动手 | 全程参与 |
这个表格看起来简单，但能省掉很多 AI Agent 失控后的返工。越靠近资金、权限、数据安全的任务，越要在流程上多设检查点。代码里的钱和权限问题，不应该让 AI 用一次自由发挥来赌。
5.3 人不需要逐行review，但要学会做小批量抽查
草台班子的人手很少，要求每个人把 AI 生成的几千行代码逐行看完不现实。我的建议是把审查拆成两个动作：机器做全量检查和 AI 做逻辑初筛，人只做小批量的重点抽查。
为了让抽查可行，就得控制单次提交的规模。我一般限令 AI 的单个 PR 不超过 400 行变更，超过就主动拆分成多个提交。一个巨型 PR 里如果混着两个不相干功能的改动，人几乎没有能力把问题找全。相反，每个 PR 只有一两百行时，哪怕只花十分钟通读 diff，也能看出逻辑上的基本问题。
配合提交聚合，还有一个实用技巧