AI Coding 不会让代码变烂，但甩锅会——质量底线与工程实践

1. 先把结论放在前面AI Coding 不会让代码变烂甩锅才会最近后台收到不少留言问的还是同一个问题AI Coding 来了代码质量会不会断崖式下降。我上一篇聊过效率红利这次“再续”一篇想认真回答一下这个焦虑。我的结论一句话AI Coding 本身不会让代码质量下降真正让质量崩掉的是把 AI 当成“写代码的甩锅对象”该你做的判断、评审、设计全都不做了。先说个真实场景。我接手过一个用 AI 辅助开发跑了一个季度的业务模块表面上看功能都在测试一跑全绿。但打开代码库那种“一眼假”的痕迹非常明显三个地方各写了一套重复的日期处理逻辑有人用DateTime有人用时间戳字符串还有人自己拼了个YYYYMMDD格式传给前端。没有抽象、没有统一约定谁生成完能跑就直接合并了。这不是 AI 的锅是使用方式出了问题。AI 是按概率补全文本的工具它不知道你的项目规范、不知道你前任留下的技术债、更不知道三个月后谁来接手。你不给它边界它就默认按“通用互联网风格”来写这当然跟你团队标准对不上。我通常把代码质量拆成三层来看正确性、结构质量、演进能力。AI 生成的代码大多能过第一层现在能跑第二层开始看人比如有没有人做评审、有没有约束第三层基本完全靠人的设计决策。很多人说“AI 让代码质量下降”其实指的是第二层和第三层崩了。你让一个经验不足的开发者用 AI 副本快速堆功能又没有评审机制兜底那不就是把预制菜端上私房菜馆还怪食材不好吗锅和火候在人不在食材。1.1 质量下降的焦虑到底在焦虑什么把网上那些吐槽归类其实就四类一是“复制粘贴式开发”AI 给什么用什么跑通了就不管了二是代码风格混乱同一套业务里混着三四种写法维护靠猜三是过度设计或设计不足该抽象的不抽象不该抽象的硬上框架四是测试越来越少因为 AI 生成代码太快人的注意力都放在“怎么让它多写点”而不是“怎么验证它写对了”。这四类问题AI 出现之前就有。只不过 AI 把生产代码的速度从“一天一个接口”拉到了“一小时三个接口”问题暴露的速度也跟着翻倍。以前一个月积累下来的技术债现在三天就能堆出来。所以我的判断是AI Coding 是放大器不是源头。你原有流程强它帮你放大强你原有流程弱它帮你放大混乱。1.2 我在团队里坚持的几条 AI Coding 底线这三条底线从一开始就写在团队 PR 模板里新人也照着执行第一条核心逻辑和关键架构决策必须由人来做。AI 可以帮你写订单状态机、写缓存策略、写查询逻辑但“这里为什么用状态机而不是简单 if”“为什么缓存放 Redis 而不是本地内存”这类决策人要自己想清楚。AI 擅长重写不擅长权衡更不擅长背锅。第二条所有 AI 生成的代码必须走评审。注意是“所有”包括看起来无关痛痒的几行工具函数。因为 AI 生成的代码常常在边界条件上偷懒比如没处理 null、没考虑并发、错误分支静默吞掉。这些坑不评审根本发现不了。第三条任何改动都要有测试或至少一组明确的手工验证用例兜底。AI 生成得快不代表逻辑一定是你要的。没有验证合并就是盲人骑瞎马。这三条不是限制生产力恰恰是保护生产力省下来的时间应该花在设计和技术难点上而不是陪你熬夜修 AI 留下的糊涂账。2. 代码生成规范示例从“说人话”到“靠谱输出”网上关于 AI Coding 的争论里最高频的一个词是“不可控”。但就我这大半年的实践来看大部分“不可控”都源于你给 AI 的信息不够结构化。今天就把我这半年一直在用的代码生成规范拿出来附上正反示例可以直接抄。2.1 一句话需求为什么会翻车先说个反面教材。你让新来的实习生写个登录接口他通常会说“登录接口嘛账号密码校验成功返回 token”。但如果你让他直接上手改订单模块的登录逻辑他大概率会问token 存哪密码加密算法是什么失败锁定策略有没有接口返回结构跟我们现有项目的统一格式对齐吗AI 也一样。你扔一句“写个登录接口”它只能按训练语料里最常见的模板输出完全没有你的上下文。所以你会拿到一个看起来头头是道、接进项目却漏洞百出的“通用登录”。更麻烦的是因为它看着太“标准”了你反而容易放松警惕直接合并。等压测发现并发登录把数据库打崩了你才想起原来没告诉它要做防刷和幂等。2.2 一套可以直接复制粘贴的代码生成规范模板我把写 Prompt 这件事类比成给你的项目写“可验收的需求单”。下面这套模板是我经过几十次迭代后沉淀下来的版本任何角色、任何语言都能套用【任务】 用一句话说明你要解决什么问题。 【背景】 说明这段代码将用在哪个模块依赖哪些现有能力比如已有工具函数、数据库表、消息队列有没有需要兼容的旧逻辑。 【输入输出】 明确输入是什么类型、输出是什么类型。如果是函数写清楚签名如果是接口写清楚请求和响应的字段结构。 【约束条件】 这块必须写包括不允许引入新的第三方依赖、性能要求如超时小于200ms、并发场景、是否要兼容旧版本字段、命名风格要求。 【验收标准】 列出哪些场景必须通过例如空值输入时的行为、重复调用时的幂等性、异常分支的日志输出。 【示例】 如果有类似的业务样例贴一个真实数据当例子让 AI 照着风格写。别小看这个模板它解决的是一个很本质的问题把“模糊愿望”翻译成“可验证的约束”。AI 模型的基本任务是根据上下文补全最可能的文本你给的上下文约束越清晰它输出的代码才越可能贴着你的项目走。你只给它情绪它只能还你套路。2.3 两个真实生成的对比演示第一个例子是个简单函数把订单金额从“不含税”改为“含税”税率为 13%。不规范的问法是“写个含税价格计算函数”。AI 大概率会给你一个price * 1.13这样笼统的实现没考虑保留几位小数、没有说明输入是分还是元、也没有处理税率为 0 的情况。你接了后面做对账才发现金额全差一分钱。用模板改写后的 Prompt 核心部分长这样任务是把[金额元]转换为[含税金额元]税率固定 13%背景是订单结算模块金额输入来自后端 Decimal输入输出都是 decimal 类型约束是保留 2 位小数、不能修改入参对象、不加新依赖验收标准是金额为 0 时返回 0税率为 0 时返回原值示例金额 100 元期望输出 113.00。生成结果直接符合规范评审几乎不用改。第二个例子是复杂业务订单超时自动关闭。普通问法“写个订单超时关单任务”AI 给的通常是遍历订单表查超时记录然后挨个更新状态。这段代码在小规模下确实能跑但量一上来就露馅没有考虑分页批量处理、没有幂等、关单操作没加状态校验用户刚支付成功也被关掉。而用模板描述清楚背景里有订单表、状态机、消息队列后AI 会主动给出“状态校验 分页处理 幂等更新”的实现思路你确认后再生成返工率会低非常多。这两个例子说明同一件事提升 AI 输出的质量功夫在写出 Prompt 之前。2.4 让规范在团队里落地而不是躺在文档里很多团队把 AI 使用规范文档写完就吃灰了。我的做法是直接把规范做成代码库里的一个文件比如AI_DEV.md也有团队叫 AGENTS.md 或 CLAUDE.md放在仓库根目录所有辅助编码工具都能自动读取。规范文件里只写团队约定、目录结构、命名规则、禁止事项。这样不用每次对话都重复一遍AI 只要进入项目就能感知到上下文。其次我用 PR 描述绑定“AI 参与信息”。合并请求里专门留一个区块要求填写用的什么 Prompt、AI 承担了哪部分、人改了什么。这既方便 reviewer 审查也能让团队慢慢积累出“什么样的生成结果容易踩坑”的经验库。最后是评审顺序我建议按四层过滤先对照约束完整性再看正确性再读可读性最后看测试覆盖。经过这样几轮团队对 AI 代码的信任度能建立在一个可控的基准上。3. 实操从单兵作战到多智能体协助开发如果你已经把单条 Prompt 玩明白了下一步就是流程。这条工作流我跑了半年多从个人开发到小团队协作收益最明显的不是“代码写得快”而是“返工率明显下降”。3.1 我日常在跑的一条 AI Coding 工作流完整链条是需求拆分 → 写规约 → 先出方案 → 生成代码 → 自测 → 评审 → 修复 → 测试 → 合并。关键在两步其他都是常规动作。第一步是拆分。把一个大需求按“一个函数、一个接口、一个状态流转”粒度拆成小任务。这不是为了让 AI 写得更快而是因为任务粒度越粗模型输出质量越不稳定。一个完整的登录接口设计涉及鉴权、加密、防刷、session 管理你让 AI 一口气写完它只能给你一个“看起来都覆盖但每个点都不扎实”的实现。反过来把每个子问题拆开特别是把“防刷策略”单独拎出来写约束AI 的表现会好很多。第二步是先出方案再写代码。我会先在 Prompt 里要求 AI 列出实现方案和关键决策点而不是直接让它输出代码。有点像写技术方案评审先对齐思路再动手实现。比如让它写一个分布式锁工具它如果先列出“基于 Redis SETNX、超时时间、可重入处理”的要点你三分钟就能判断方案行不行。如果思路偏了直接纠正根本不用看代码。自测环节我建议别省。生成代码后第一时间跑一遍静态检查和单测发现问题直接丢回给同一个对话上下文让它基于测试失败信息继续改。这样比人工抄一遍再改要高效得多。3.2 多智能体AI Agent协作分工明确比数量更重要最近“多智能体协助开发”这个概念很火看到有人一下子拉起五六个 Agent规划、编码、审查、测试各角色齐全。看起来很美但实际操作会有一个巨大问题上下文开销。每个 Agent 都有自己的上下文窗口跨 Agent 协议一复杂协作效率反而下降。我实测下来最稳的组合是两个 Agent实现者 审查者。实现者负责按规约写代码审查者拿着设计好的 Checklist 去挑毛病。这个组合尤其适合代码审查这个环节因为人类看代码难免带上“自己写的舍不得骂”的心理Agent 审查者能机械地、不客气地挑出所有不符合规范的地方。多智能体协助开发也要立规矩否则就是各写各的。我建议至少明确三件事一是角色边界实现者不负责架构决策审查者不负责改代码二是交接协议Agent A 必须在产出里附上“实现说明、关键假设、已知风险”否则审查者拒绝接收三是终止条件比如修复轮次最多 3 轮超过必须升级给人处理。加上多智能体的决策权分配所有 Agent 的最终产出都必须经过人的确认机器只有建议权。这样既能享受并行协作的速度又不会让开发方向失控。3.3 用 AI Coding 笔试来筛选工具和人都适用“AI Coding 笔试”这个东西最近也很热。我理解它有两层含义一些公司在新招聘中加了一场“考察候选人使用 AI 能力”的笔试另一层是开发者在挑选 AI 编码工具时用它做横向评测。不管哪一层题目的设计逻辑是相通的。我的建议是别出“调库题”别出“背诵题”要出一道中等复杂度的业务题然后考四件事第一候选人能不能把模糊需求拆成可执行的实现步骤第二能不能写出上面那种结构化 Prompt 让 AI 生成靠谱代码第三能不能看懂 AI 生成的代码并指出其中的边界隐患第四给一个需求变更看候选人能不能有效地引导 AI 做修改而不是把代码全部推翻重来。评分维度建议按这个表格来维度考察点权重建议正确性功能是否满足题目要求30%约束符合度是否遵守题目给出的限制条件20%可读性生成代码是否结构清晰、命名规范15%变更成本收到新需求后修改是否局部化20%验证覆盖是否给出合理的测试用例验证15%这套题能筛出一个关键能力把 AI 当成能听懂话的协作对象而不是许愿池。而那些只会背 Prompt 模板、看不懂代码就敢合并的选手一到“指出 AI 代码里三个隐患”这种环节就原形毕露了。4. 常见问题与排查技巧实录工具用多了翻车是常态。这里把我踩过的高频坑整理成一份可直接照抄的排查手册。4.1 高频问题速查表常见现象根本原因第一反应生成代码调用了不存在的库或 API模型对较冷门的库名产生了幻觉先检查 import 和依赖声明同一段逻辑反复出现多份实现任务没有指定复用路径在背景中写明已有工具函数小功能被“升级”成重型设计没有加“不引入新依赖”约束检查是否引入状态管理/ORM长对话后期突然忘记前面约定上下文窗口太长导致注意力漂移关键约定在多轮后重复一遍测试总是“看起来很全”但漏关键分支AI 输出从概率出发只覆盖常见场景用验收标准里的边界用例逐条核对生成代码风格和项目规范不一致模型没读过项目里的风格文档在 AI_DEV.md 里写明规范并让工具读取4.2 几个典型的翻车现场与修复过程翻车现场一幻觉依赖。有一次让 AI 写一段 CSV 高性能解析它生成了对一个新库的调用。我扫了一眼以为是第三方工具库没细看就跑了测试运行时报包不存在排查才发现这是模型“编”出来的 API。从那之后我养成了一个习惯AI 生成的代码只要遇到不认识的模块先查依赖再往下看。这个习惯至少帮我挡了七八次类似的坑。翻车现场二过度设计。一个几十行的页面筛选功能AI 直接给引了一个状态管理库。在没有约束条件提示的情况下模型按“通用大型项目最佳实践”来发挥这已经算常规操作了。修复方法很简单在约束里加一条“禁止新增依赖”并明确“优先使用项目已有的 useState / 自定义 Hook”效果立竿见影。翻车现场三上下文丢失。有次让 AI 分三步实现一个数据迁移脚本第一步约定好目标表结构第三步生成时它却自己“发明”了新表结构。原因就是多轮对话后它逐渐忘了前面的约定。我的办法是在每一步 Prompt 末尾都把目标表结构再贴一遍宁可我多打几行字也别让它瞎猜。4.3 一些只有踩过坑才会懂的习惯最后分享三个小习惯算是我这套 AI Coding 实践里最值钱的部分。第一个习惯生成代码合并前先跑格式化。AI 生成的代码从语法上往往没问题但缩进、换行、导入顺序经常不符合团队风格。别指望它自觉直接跑一遍格式化工具省得 review 时满屏都是格式噪音。第二个习惯在 Prompt 末尾加一句“请指出你输出中你认为最可能出错的部分”。这一招可以迫使模型对输出做一遍元评估实测下来非常有效。它会自己告诉你“这段代码没有处理并发场景”或“边界值需要验证”等于白嫖了一次自查。第三个习惯把 AI 的产出当成“实习生初稿”而不是“参考答案”。实习生初稿你会怎么处理先看思路对不对再看细节漏没漏最后才会考虑合并。这套心理模型帮我保持了正确的锚定AI 负责速度人负责标准。最后再聊点个人体会。AI Coding 用到现在我对它的定位越来越清晰它像一个记性好、手速快但没有项目判断力的老同学你问它任何问题它都能答上来一段但答得对不对、适不适合你的项目只有你自己把关。我见过最快翻车的团队是把 AI 当成不拿工资的正式员工而真正受益的团队是把它当成一个需要清晰文档、明确验收标准、时刻有人 review 的协作者。代码质量下降这件事别让 AI 背锅流程认领了才是正事。