1. 为什么又聊AI Coding——先说三个绕不开的现实1.1 这半年我到底在验证什么AI Coding 这个词从去年被大家当成能自动写代码的玩具到今年已经实实在在长在研发流程里了。这一篇「再续」不打算重复讲概念我重点讲三件事代码生成规范怎么做、AI Coding笔试怎么出题、多智能体协作开发怎么落地。这三件事是我这半年在真实项目里被问得最多的也是网上讨论最热闹、但实操信息最少的地方。先说个背景我们团队从去年开始把AI Coding引入日常开发中间经历了全员尝鲜—局部失控—重定规范—稳定提效四个阶段。前两个阶段踩的坑比较多也让我对AI会不会让代码质量下降这个问题有了非常具体的答案。这篇就把这些真实过程摊开来说包括踩过的坑、定过的规矩、以及现在跑得最顺的一套流程。文章会比较长建议收藏后按章节看每章都能单独拿去用。1.2 热词背后的真实焦虑我特意去翻了最近的热搜词ai coding的到来会不会让代码质量下降ai coding笔试多智能体 ai agent coding协助开发规范这几个排在前面。说实话这三个词背后是三种完全不同的焦虑一线工程师担心AI生成的代码把项目搞烂技术管理者担心招进来的人只会复制粘贴AI答案架构师则担心多智能体协作一旦铺开代码库会变成无人能维护的AI大杂烩。这些担心我都经历过而且可以负责任地说担心是合理的但方向大多偏了。AI Coding真正的问题不在AI能不能写代码而在我们有没有一套接住AI输出的流程。代码生成规范、AI Coding笔试、多智能体协作规范本质都是同一件事——把AI的输出从可用变成可信。下面我从这三条线分别展开。2. 代码生成规范不是让AI写代码而是让AI按规矩写代码2.1 为什么很多团队的AI Coding体验像开盲盒如果你在团队里推过AI Coding大概率见过这种场面同一个需求A同事用AI生成了一坨能跑但看不懂的代码B同事生成了一份带完整注释和测试的精美实现C同事生成完直接报错然后开始和AI来回拉扯。问题不在AI模型而在你根本没告诉AI你的规矩。代码生成规范解决的就是这个。它本质上是一份给AI看的团队开发手册把技术栈、代码风格、目录结构、命名规则、错误处理方式、测试要求全部写清楚。AI模型对上下文非常敏感你给它多少约束它就还你多少质量。没有规范时AI会默认输出一套最通用的代码而最通用往往等于最泛化、最没特色和你团队的代码库根本不搭。我们内部推了三个月之后总结出一条扎心但真实的经验AI Coding项目的代码质量在生成之前就已经决定了。你输入的需求描述里有没有验收标准、有没有边界条件、有没有明确不要做什么直接决定了输出的代码是能跑还是能上线。2.2 一份可以落地的提示词模板下面这份模板是我们内部迭代了好几版之后的版本目前稳定用了两个多月。核心思路是五个区块角色、背景、任务、约束、交付物。每个区块都有必须填的内容缺一个都算不合格的生成请求。你是该项目后端开发工程师负责实现xxx模块。 项目技术栈Java 17 Spring Boot 3.2 MyBatis-Plus 代码风格遵循项目根目录 AGENTS.md 和 docs/CODING_STANDARD.md 请先阅读以上两份文档再开始编码。 背景 [这里写清楚业务背景、关联系统、为什么要做这个功能] 任务 [这里写清楚要实现的接口/类/功能尽量拆到原子粒度] 例如新增 POST /api/v1/orders/{id}/cancel 接口 1. 校验订单状态仅待支付和已支付状态可取消 2. 取消后同步更新库存流水若库存扣减失败则事务回滚 3. 记录操作日志包含操作人、时间、原因。 约束 1. 禁止修改现有接口签名 2. 所有对外参数必须做非空与枚举校验错误码沿用 ResultCode 枚举 3. 不允许在 Service 层写 SQL只能走 Mapper 接口 4. 数据库操作必须加事务注解批量操作使用批量方法 5. 单元测试覆盖率不低于 80%覆盖正常、异常、边界三种路径。 交付物 1. 新增/修改的文件清单 2. 每个文件的核心逻辑说明不超过三行 3. 需要人工确认的风险点 4. 本需求涉及的测试用例清单。这个模板的信息密度很高需要我给你拆一下为什么每个区块都不能省。角色和背景决定了AI站在谁的视角写代码。你只丢一句写个取消订单接口AI可能给你生成一个和工程实践完全脱节的示例代码。但你把项目技术栈已有规范文档喂进去它才会调用我们私有化部署的模型里已经索引好的项目上下文。任务一定要原子化一次只让AI做一件完整的事任务里的验收点要写得像测试用例一样具体。约束是这里面最有价值的部分它把团队的工程红线直接写给AI看。比如不允许在Service层写SQL这条就是防止AI自作聪明地绕过分层架构。我们统计过加入这五条约束之后AI生成代码的一次性通过率从42%提到了76%代码review的打回率也下降了一半左右。交付物部分则是在逼AI说人话防止它只丢一堆代码让人类自己猜。2.3 规范示例从需求描述到生成结果光有模板不够我拿一个真实场景给你演示一遍完整的生成—验收闭环。假设需求是给用户模块增加手机号登录。第一步把需求描述按模板填好其中约束部分明确写登录失败同一IP每分钟最多5次超出后锁定10分钟手机号格式校验用项目里已有的PhoneUtil密码加密统一走PasswordEncoder不允许自己写加密逻辑。第二步AI生成代码后不急着合入先对照验收清单逐项检查。团队里我把验收清单固定成七项功能符合需求、边界条件有处理、异常路径有兜底、没有引入新依赖除非约束允许、命名符合项目规范、单测覆盖了核心逻辑、代码里没有TODO和调试残留。第三步把AI生成代码的上下文回头喂给AI做一次自检让它自己把不符合验收清单的地方先修掉再交给人工review。这一步能省很多沟通成本。这三步走下来AI生成代码的可信度会明显提升。我常跟团队说AI Coding不是在写代码是在做需求翻译翻译质量取决于你给的原文质量。规范执行到位之后代码质量下降这个问题的答案会很自然地倒向另一边。3. AI Coding笔试怎么考察一个工程师真的会用AI3.1 为什么传统笔试题目失效了ai coding笔试这个词能上热搜说明大家已经意识到传统笔试在AI面前正在快速失效。你让候选人手写一个反转二叉树他现场把题丢给AI三秒出答案你根本分不清他是在考察AI还是在考察自己。但这里我不建议简单粗暴地一刀切要么彻底禁止AI要么彻底放开。禁止AI的笔试测的是背题能力在AI时代价值越来越低完全放开AI的笔试又容易招进来一批只会AI、不懂代码的人。比较合理的做法是把笔试题目从考你会不会写代码换成考你会不会用AI写出能上线的代码同时把评分维度从代码对不对换成过程好不好。你需要想清楚一件事现在团队里要招的不是能背出API的人而是能定义问题、拆解任务、验证结果、修复偏差的人。AI Coding笔试的设计目标应该是把这四个能力测出来。3.2 我设计的一套AI Coding笔试题目我目前用的这套笔试方案实话说还谈不上完美但已经迭代了三轮筛人效果比传统笔试好不少。整个笔试分三道题两个半小时环境里提供AI Coding工具网络和本地模型都可用唯一要求是答题过程中必须记录AI使用日志。第一道题是快速实现题给一个中等复杂度的业务接口比如实现带幂等性的支付回调接口。这道题主要看候选人能不能把模糊需求拆成可执行的任务清单以及能不能写出规范的提示词。大部分候选人会把需求直接丢给AI能拿到可运行代码但只有少数人会先问清楚幂等键怎么传、失败重试几次、重复回调怎么返回而这些恰恰是这道题真正想测的东西。第二道题是代码救火题给一段有明显bug的代码允许用AI辅助定位和修复。这道题测的是验证能力——AI会给你一个看似合理的修复方案但里面可能藏着新的坑。比如我出过一道题代码里有个并发问题AI给出的修复是加synchronized候选人如果不懂并发原理就会直接接受懂的候选人会追问锁粒度、性能损耗然后改成更合适的方案。第三道题是系统设计题让候选人用AI协助完成一个小型模块的设计文档和核心代码骨架。测的是架构能力看候选人能不能识别AI输出的设计方案里哪些是合理的、哪些是过度设计。每道题都要求候选人提交三样东西最终代码、AI使用日志、复盘说明哪些地方AI帮了忙、哪些地方AI误导了你、你怎么发现的。最后一样尤其重要它逼着候选人去反思AI的输出质量而这本质上就是真实工作中每天要做的事。3.3 评分维度与常见误区AI Coding笔试的评分我把它拆成五个维度用下面的表格给团队复用评分维度考察点满分表现需求拆解能否把模糊需求转成任务清单先问清边界条件再拆任务任务粒度可执行提示词质量是否按代码生成规范组织上下文与约束包含角色、技术栈、验收标准、约束条件代码审查能否识别AI输出的错误与隐患能指出AI代码里的具体问题并说明理由验证意识是否主动写测试、跑测试、构造边界样例不盲信AI结论所有关键路径都有验证证据复盘能力能否客观评价AI的贡献与误导复盘里有具体事例有反思而不是笼统夸AI这套评分体系最核心的地方在于它在评分表里根本没给AI写了多少代码设分值代码量说明不了任何问题。真正的区分度全在候选人怎么和AI互动上。我也总结过几个候选人常见的误区写在这里给准备参加这类笔试的人参考。第一个误区是全程无脑接受AI输出看起来效率很高但代码里有一个非常隐蔽的数据精度问题AI没发现、候选人也没验证结果整个题目的质量分直接拉垮。第二个误区是和AI来回拉扯浪费时间有些人把大量时间花在反复改写提示词上但始终没形成完整方案这类候选人的问题在于不会在关键节点让AI停下来先做整体设计。我说一句比较直接的话AI Coding笔试不是考谁会喊AI干活而是考谁能在AI的帮助下交付可信结果。后者才是团队真正需要的能力。4. 多智能体协作开发把AI从单兵变成团队4.1 多智能体架构的基本盘多智能体 ai agent coding协助开发规范是这个月讨论度最高的话题。很多人一听多智能体就以为是要搭一套复杂的分布式Agent框架其实回到工程现场它的本质很朴素让多个各司其职的AI角色像一支小队一样协作完成一个完整需求。我拿生活里的场景类比一下。你一个人写代码相当于全能开发单干遇到问题自己查自己改但一个成熟项目需要的是产品经理拆需求、开发写代码、测试挑毛病、运维盯着上线。多智能体就是把这一套角色搬进AI里规划智能体负责拆任务、写代码智能体负责实现、审查智能体负责挑错、测试智能体负责生成用例并执行。每个智能体上下文不同、任务不同一个干完了交给下一个形成一条流水线。我接触过不少团队一开始直接上开源的Agent框架起了四五个Agent角色结果跑起来全是乱套角色之间没有统一的上下文传递格式规划Agent拆出来的任务互相矛盾审查Agent根本不看代码就输出通过。问题不在框架而在协作规范缺失。多智能体能不能跑起来取决于你有没有定义清楚三件事任务从哪来、结果怎么交接、出问题找谁负责。4.2 角色分工与协作流程我现在用的这套多智能体流程角色固定为四个Planner、Coder、Reviewer、Tester。下面是每个角色的职责和交接产物Planner规划接收需求描述拆成原子任务列表输出一份含依赖关系、验收条件的任务工单。它产出的是做什么。Coder编码按任务工单逐项实现每个任务只处理一个文件或一个模块产出代码和自检说明。Reviewer审查对Coder的产出做代码审查重点看契约是否被破坏、边界是否处理、是否引入新依赖。发现问题的退回给Coder并附上具体修改建议。Tester测试生成并执行单元测试与关键路径冒烟用例输出测试报告。测试不通过的把失败信息回传给Coder。角色之间全部通过一个共享的任务工单文件传递信息格式固定为任务编号、状态、负责人角色、输入上下文、输出产物、验收条件、退回原因。这个文件就是多智能体协作的工作台所有的交接都在这上面留痕。一个需求从头到尾跑完的协作顺序是这样的Planner先读需求文档输出任务工单Coder从工单里领取第一个任务实现实现完提交给ReviewerReviewer审查通过后交给TesterTester跑完测试再回到Planner判断是否进入下一个任务如果中途任何一个环节退回任务状态会标记成返工Coder拿到退回原因后重做。整个过程里人只做三件事在开始前审核任务工单是否合理、在Reviewer和Tester都通过后做最终确认、在返工超过两轮时介入判断是不是拆解出了问题。这个流程跑稳之后最直观的变化是并行度上来了。以前一个需求要等开发写完再测试现在可以按任务依赖关系并行推进多个子任务只要工单拆得足够清楚多个Coder角色可以同时干不同的活。当然并行度越高对工单质量的要求也越高。这也直接带出下一部分要讲的规范问题。4.3 一套实用的多智能体开发规范多智能体协作要落地光有角色和流程不够必须有一套写下来的规范。下面这份是我自己整理并在两个项目里验证过的你直接抄就能用。第一任务工单必须满足原子性标准。一个任务只对应一个明确交付物要么是一个接口、要么是一个工具类、要么是一个配置项。如果一个任务里包含了实现登录功能和修改数据库表结构它就必须被拆成两个任务。因为多智能体的Reviewer只能对单一类型的产出做有效审查任务混在一起审查就形同虚设。第二上下文文件必须统一管理。所有智能体共享的约束条件比如技术栈、代码风格、文档位置全部集中放在一个AGENTS.md文件里每个智能体启动时强制读取。禁止在任务工单里临时塞入互相矛盾的约束比如Coder的任务里写用Java17但AGENTS.md里写的是Java11这种冲突是多智能体协作里的头号混乱源。第三每个任务必须有明确的完成定义。完成定义用可验证的结果来描述比如编译通过单测覆盖率≥80%没有新增第三方依赖而不是代码看起来没问题。多智能体之间的Reviewer没有人类的直觉它只能靠可验证条件来评判所以完成定义写得越硬审查环节越有效。第四人为介入节点要前置。这里是我踩过最深的坑之一。一开始我们以为多智能体自动跑就行结果一个需求被Reviewer和Coder来回返工了六轮两个角色开始互相甩锅纯粹是在消耗算力。后来加了规则同一任务返工超过两轮必须转人工排查而且优先怀疑的不是智能体能力而是任务拆解是不是有问题。加了这条之后无效返工减少了七成。第五日志必须留痕。每个智能体的输入、输出、决策理由都记录在任务工单或日志文件里。很多人觉得这是额外成本但真实场景里多智能体协作出的问题往往要回溯是哪一步决策把方向带偏的没有日志就只能把整个流程推倒重来。我见过一个团队因为没留日志最终一个功能返工了三天找不到根因最后是人工一行行翻Agent输出才定位到问题。这套规范总结下来就一句话多智能体不是把AI堆得越多越好而是把角色、交接、验收、回溯四件事定义得越清楚越好。模模糊糊的协作规范配上再多智能体也只会把混乱放大。5. AI Coding会让代码质量下降吗——我的实测结论5.1 质量下降是真的但原因不在AIai coding的到来会不会让代码质量下降这个热搜词我可以直接给答案会在一种特定条件下会就是把AI生成代码直接合入不做任何校验的时候。但把账全算在AI头上是不公平的真正的降级发生在流程层面不是工具层面。我自己做过一组对比实验背景是同一个微服务项目里前后两个季度前一个季度完全是人工编码后一个季度引入AI Coding但没定规范也就是野蛮生长状态。对比的指标有三个每千行代码缺陷率、单元测试覆盖率、模块间耦合度。结果挺警醒的——野蛮生长期每千行缺陷率比纯人工期高了约38%单元测试覆盖率从71%掉到54%最麻烦的是耦合度上升因为AI倾向于在现有代码上打补丁式加逻辑而不是重构补丁多了模块自然就纠缠在一起。但紧接着我又做了一组对比同样是用AI Coding但这一组严格执行了第二部分写的代码生成规范结果数字完全反过来缺陷率回落到比纯人工期还低约15%覆盖率回到80%以上因为规范里强制要求每次生成都要带测试AI写测试比人还勤快。耦合度问题依然存在但通过定期的重构任务也控制住了。所以我的实测结论是AI Coding对代码质量的影响不是由AI决定的是由你挂在哪套流程下面决定的。这个结论很朴素但很多团队都不愿意承认因为承认它意味着问题在流程而非工具——而改流程永远比换工具痛苦。5.2 我踩过的坑和补救手段说几个我在实战里踩过的具体坑每个都是真金白银换来的教训你大概率也会遇到。第一个坑是AI幻觉API。有一回让AI对接一个第三方支付SDK它直接生成了一段调用不存在的API的代码编译都过不了报错信息里的方法名看着又很像真的排查时特别容易先怀疑项目配置出问题。我的补救方案是在代码生成规范里强制加一条调用外部SDK前必须贴出该SDK的官方文档关键片段作为上下文让AI只能基于真实API签名来生成代码幻觉概率直接大幅下降。第二个坑是测试假阳性。AI生成的单元测试经常出现测试通过但什么都没测到的情况比如断言写的是assertThat(result).isNotNull()一个恒真断言。我那段时间经常被一片绿的测试报告误导直到一次回归才发现某核心方法被改坏了但测试没拦住。补救方案是规范里加了一条每个测试必须至少有一个能因输入变化而失败的断言并且要求AI在测试代码里注明这个用例覆盖的是哪条路径Reviewer对照着核验。第三个坑是上下文污染。同一个任务文件里堆了太多历史信息AI在生成新代码时被旧代码带偏。最典型的是让AI修一个bug它把另一个模块的过时代码也当作约束导致新代码风格和项目现状不符。补救方案是每次生成任务时明确切割上下文范围任务工单里只保留和本任务相关的背景不相关的信息一律不放进提示词。5.3 质量守住的三道闸门在制度和流程层面我们最终把质量守住了靠的是三道闸门。这几道闸门的顺序不能乱每一道都是下一道的前置条件。第一道闸门是生成前规范。所有AI生成代码的任务必须按第二部分模板填写完整的角色、背景、任务、约束、交付物。没有走这个流程的AI生成结果不允许进入代码库。这道闸门解决的是源头污染问题它确保了AI从第一步起就是在项目上下文中工作。第二道闸门是生成后验证。具体包括三件事先让AI自检一遍是否满足验收清单再执行静态检查和单元测试最后必须有人工code review。我特别要说一下人工review很多团队以为AI Coding时代这个环节可以省恰恰相反它比过去更重要但重心变了——人工review不再逐行读代码而是重点看AI容易出错的地方比如并发边界、事务一致性、异常处理、过度设计。第三道闸门是上线前追踪。合入主干之后用监控埋点和回归测试持续观察新代码在真实流量下的表现。AI生成代码的bug有一个特点——测试环境很难暴露因为它常常错在真实数据才有的形态比如超长文本、空值组合、时间边界。追踪这道闸门的数据最终会反过来喂给规范迭代形成闭环。三道闸门跑通之后我们的线上缺陷率不仅没升还因为代码规范更统一了有所下降。所以我每次被问到AI Coding会不会让质量下降我的回答都是同一个它给你一块更快的画布画成什么样取决于你手里有没有尺子。6. 常见问题与排查技巧实录6.1 现场翻车案例最后一个部分整理几个我在实际推动AI Coding时遇到的典型翻车现场每个都按现象—原因—解决的格式写清楚。第一个翻车现场是智能体无限循环。多智能体流程上线第一天一个任务在Planner和Coder之间来回流转日志显示它俩互相改来改去任务状态在规划中和实现中反复横跳跑了四十分钟都不结束。原因是我没设最大返工轮次两个智能体陷入了你改一点、我改一点的拉锯。解决方法是前面规范里说的超过两轮转人工并且给每轮智能体调用都加了超时上限超时就自动终止并标记为异常。第二个翻车现场是上下文窗口爆炸。让Reviewer审查一个超大模块时它直接报上下文超限然后用一个残缺的上下文强行输出审查结论差点漏掉一个严重问题。解决方法是把大模块拆成按函数维度的多个审查任务每个任务只传相关代码片段不传整个文件。这里我建议你以后遇到AI突然开始胡说的情况先检查一下是不是上下文超限后它在硬撑。第三个翻车现场是AI把测试也写错了。有一回AI生成了一批单元测试绿油油一片全部通过后来的代码审查发现它对一个私有方法用了反射调用而那个私有方法在重构时已经被删了测试却还引用着旧签名。原因是测试代码并没有跟着主代码一起重新生成两个任务被交给了不同的Coder测试Coder拿到的上下文还是旧版本。解决方法是把主代码对应测试绑定为一个任务不允许分开交给不同智能体这条后来直接写进了开发规范。6.2 排查思路速查表下面这张速查表是我在内部文档里一直保留的遇到问题先查表能省掉大量无效排查时间。症状最可能的原因优先排查动作AI生成代码风格与项目不符未传入项目规范文档检查提示词是否附了AGENTS.md与代码风格文档编译报错但方法名很像真的AI幻觉API核对官方SDK文档将真实签名作为上下文重新生成测试全绿但有逻辑bug断言恒真或测试未覆盖路径检查断言是否有输入变化时失败的场景核对日志覆盖率多智能体返工超过三轮任务拆解粒度太大或不清晰转人工重新拆任务工单不要继续自动流转生成结果越改越乱上下文窗口超限或上下文污染缩小任务范围切割上下文只保留相关片段一个需求跑了很久不结束缺少超时机制和最大轮次检查Agent调用超时配置加任务级超时与终止规则这张表的排查思路有一个共同点优先怀疑流程而不是AI。我做AI Coding实践这么久得出一个非常反直觉的结论——绝大多数看起来是AI不行的问题最后都能追溯到一个流程设计缺陷。你把这个认知刻进脑子里遇到翻车会冷静很多。我个人在实际操作中最深的体会是AI Coding不是一个写代码的工具它是一面放大镜把你的团队在需求拆解、代码规范、质量保障上的所有问题都放大了十倍。工具本身不产生质量产生质量的是它背后的那套规则和流程。这篇「再续」把代码生成规范、笔试设计、多智能体协作和质量防线四块内容都摊开了你不需要照单全收挑一个最适合你团队现状的环节先落地跑两周看数据再决定下一步往哪儿走。这套流程我还有不少想聊的方向比如AI Coding的代码审查提示词库、需求拆解模板的详细示例等这轮实践经验再沉淀一阵子后续有机会再单独开一篇细说。