我们做技术的这几年大概都经历过从“AI 写代码就是个玩具”到“AI 写代码真能顶一个人用”的心理转变。尤其是 Claude Code 这类 agent 型编程工具出现之后身边的讨论风向又变了一次以前大家问“AI 能不能写”现在大家问的是“AI 写的代码能不能直接上生产”。这个问题背后其实藏着一个更尖锐的争议——既然 AI 能把活干完大半那我们对生产代码的标准是不是可以适当“放水”了最近 Claude Code 负责人 Boris Cherny 公开答复了一位架构师的来信核心观点非常明确AI 时代生产代码的标准不降反升应该更高而不是放水。这封信和答复在开发者社区里引起了不小的讨论。我个人的看法是这个观点不仅不偏激反而踩中了 AI 辅助编程最核心的命门——工具效率翻倍的同时质量把关的难度也在翻倍。今天这篇文章我就从 Boris 这次公开答复切入结合我自己用 Claude Code 写生产代码的实际经历把“为什么 AI 时代标准要更高”这件事拆开讲透再聊聊到底怎么落地这个标准。1. 一次关于“AI 写代码要不要放水”的公开答复为什么值得认真看1.1 事件背景与 Boris Cherny 的核心态度先说清楚这件事的来龙去脉。有一位架构师给 Claude Code 团队写了一封公开信大意是现在 AI 编程工具已经很强了很多基础代码、样板代码、CRUD 接口都能自动生成那我们是不是可以适当降低对代码风格、注释、命名、异常处理这些方面的要求毕竟 AI 生成的代码整体质量已经比很多初级工程师写得好了再拿过去那套严格标准去卡是不是有点不合时宜Boris Cherny 的答复没有绕弯子。他的核心态度是恰恰相反AI 让代码产出速度变快了但生产环境对代码质量的要求只会更高不会更低。理由是AI 生成的代码一旦上线它的影响范围、维护成本、故障恢复难度并不会因为“这是 AI 写的”就降低半分。你不可能跟线上事故说“这锅是 AI 的”线上系统不认这个。这个答复之所以值得认真看是因为 Boris 不是站在“AI 厂商”立场上无脑吹自家产品而是站在“生产代码最终要为人服务”这个底线上说话。他承认 Claude Code 很强但同时也强调工具越强使用工具的人需要具备的判断力就越重要。1.2 为什么“放水”这个想法很有迷惑性说句公道话那位架构师的提议也不是完全没有道理。我自己用 Claude Code 写代码的时候确实能感觉到 AI 生成的代码在“基础质量”上是过关的缩进对、命名规范、注释也写得很像样甚至比你团队里某些不爱写注释的同事强得多。这种情况下你很容易产生一种错觉——既然面子工程都做到了里子应该也没问题吧但问题恰恰出在这里。AI 生成的代码表面上的“规范性”和实际上的“正确性”是两码事。它可以把代码写得像一篇满分作文但业务逻辑对不对、边界条件有没有覆盖、异常路径有没有处理、性能和并发有没有隐患这些都不是靠“看着规整”能判断的。如果你因为“看起来不错”就放松标准等于把质量判断完全交给了一个不具备业务上下文、也没有线上事故记忆的工具。用一个生活化的类比来说AI 相当于一个厨艺很熟练的帮厨切菜漂亮、摆盘规整但菜单没有明确告诉他“客人花生过敏”他很可能就把花生酱放进去了。你作为主厨不能因为帮厨刀工好就取消试菜环节。生产代码同理AI 可以帮你把“写”这个过程加速但“什么能上桌”这件事必须由人来把关而且把关标准还得比以前更严。1.3 这类讨论对普通开发者的实际意义可能有人会觉得这是架构师和 AI 团队负责人之间的高层对话跟我一个写业务代码的有什么关系关系非常大。因为“生产代码标准”这种事从来不是某个人的事而是整个团队协作的基准线。Boris 这次答复等于给所有正在用或者准备用 AI 编程工具的团队提了个醒别把 AI 当成降低标准的借口而应该把它当成倒逼标准升级的催化剂。具体到个人开发者身上这个讨论的实际意义在于你的竞争力不再体现在“能写出多少行代码”上而是体现在“能不能判断 AI 写的代码到底行不行”上。以前大家拼的是码力以后拼的是判断力、审查力、设计力。标准不降反升实际上是把“会写代码”的门槛拉高了同时把“会用好 AI 写代码”的门槛也拉高了。2. 为什么 AI 时代代码标准不降反升从三个角度看“更高”的含义2.1 从代码生成成本看AI 把“写”变便宜了但“对”变得更贵先说一个最基本的成本逻辑。在没有 AI 的年代写一万行业务代码一个中级工程师大概要花一到两周这个时间成本本身就是一道隐形质量门槛——你不会轻易让一个人花两周时间去写一堆没经过思考的代码你会逼他先想清楚再动手。AI 出现之后这一万行代码可能半天就生成完了。看起来效率提升了十倍但注意“写”的成本降下来了“验证”的成本却一点没降。代码上线之前你仍然要做 code review、跑单测、做集成测试、测性能、检查依赖安全这些环节的成本不会因为代码是 AI 生成的就自动消失。Boris 说的“标准更高”其实指的就是这个意思既然写代码变便宜了那你就应该把省下来的时间投入到验证环节去把那些以前“来不及细查”的地方查得更细。而不是反过来觉得“快了就可以随便点”。生产代码的质量不是由“写”决定的是由“验”决定的。AI 加速了前半段后半段的压力反而更大了。2.2 从错误模式看AI 代码的 bug 是“自信的错误”比人类粗心更隐蔽我在实际使用 Claude Code 的过程中有一个非常深刻的感受AI 犯错的模式和人类完全不一样。人类写代码犯错通常是粗心、遗漏、看错需求错误往往比较“直白”review 的时候一眼就能看出来。AI 犯错是“一本正经地胡说八道”——它能把代码写得逻辑自洽、注释完整、风格统一但业务语义是错的。举个我真实踩过的例子。有一次让 Claude Code 写一个订单超时自动关闭的功能它非常流畅地生成了整个定时任务模块包括查询超时订单、更新状态、记录日志代码结构干净得像教科书。但我仔细一看发现它的时间判断条件写错了它用的是“订单创建时间 30 分钟 当前时间”作为超时条件而正确的业务逻辑应该是“订单支付时间 30 分钟 当前时间”。订单从创建到支付中间有十几分钟的时间窗口按它的写法所有未支付订单都会在创建后 30 分钟被强制关闭哪怕用户已经进入了支付流程。这种错误如果只看代码风格、命名规范、注释完整性是绝对发现不了的。它要求 review 的人真正理解业务语义并且在脑子里从“业务正确性”的角度重新推演一遍。这种审查成本远比看代码“规不规范”要高。这就是为什么标准不能降——AI 的错误模式决定了你只能用更严格的验证手段才能兜住它。2.3 从协作角度看AI 生成代码的长尾维护成本决定标准底线还有一个很多人忽略的角度代码是写给机器执行的但更是写给下一个维护者看的。AI 生成代码有个特点它没有“记忆”不会记得自己上周给另一个模块留下了什么坑。你今天让它生成一个功能它不会主动考虑“这个功能会不会和三个月前那个模块有冲突”除非你明确告诉它。这就意味着AI 生成的代码本质上是一个“没有长期记忆的新人”写出来的。它最大的问题不是写得不好而是它对系统的整体理解是碎片化的。这种代码一旦进入生产环境后续的维护成本会非常可观下一个接手的人不仅要理解业务还要花时间理解“AI 当时为什么这么写”——而 AI 自己是没法回答这个问题的。所以生产代码的标准在 AI 时代提高本质上是因为长尾维护成本变高了。你不能让 AI 生成的代码像“空降兵”一样只管今天上线不管明天维护。你必须通过更严格的标准比如强制补充设计文档、强制标注关键决策理由、强制对复杂逻辑写注释来弥补 AI“没有记忆”这个缺陷。这些标准以前是“加分项”现在应该是“必选项”。3. AI 辅助编程时代的代码质量防线让 Claude Code 产出可上生产环境的代码3.1 明确“完成”的定义给 AI 划清验收边界聊完理念说说实操。我用 Claude Code 写生产代码这一年多总结下来最重要的一条经验就是在使用 AI 之前你必须先定义清楚什么叫“完成”。没有明确验收边界的 AI 编程基本等于开盲盒。什么叫明确的验收边界举个例子如果你让 Claude Code “写一个用户注册接口”这个描述是模糊的。AI 会给你生成一个能跑的接口但它不知道你的注册流程里要不要手机号验证、要不要密码强度校验、要不要防重复提交、要不要做风控、接口返回格式遵循什么规范。这些信息你不给它它就默认“能跑就行”。我现在的做法是在让 Claude Code 干活之前先写一份 checklist明确列出这个任务的验收标准。比如功能范围本次只做注册接口不做登录、不做找回密码。入参校验手机号格式、密码长度、验证码有效性缺一不可。异常处理重复手机号、验证码错误、数据库超时每种情况都有明确返回码。边界场景并发注册同一手机号时不能出现重复用户。性能要求单接口响应时间 P95 小于 300ms。你会发现当你把 checklist 写清楚之后Claude Code 生成的代码质量会有质的提升。因为它本质上是一个“超级执行者”你给它的约束越明确它的执行力越能兑现。反过来你给的约束越模糊它就只能靠“猜”来补全猜错的概率自然就高。3.2 强制人工审查读 AI 代码比写 AI 代码更重要第二道防线是强制人工审查。可能有人觉得既然 AI 能写代码那我是不是可以跳过 code review 直接上线我的回答是绝对不行而且 AI 时代的 code review 比以前更重要只是重点变了。以前 code review 重点看的是“代码怎么写”——变量命名、函数拆分、设计模式、性能优化。现在 AI 时代的 code review 重点应该是“代码为什么这么写”——业务逻辑是否匹配、边界条件是否覆盖、异常路径是否处理、对现有系统的影响是否评估。我自己的审查流程是三层递进。第一层静态审查看整体结构合不合理有没有明显的样式问题、重复代码、坏味道。第二层语义审查带着业务需求逐行推演模拟各种输入看输出是否符合预期。第三层系统性审查想清楚这段代码上线之后会对哪些现有模块产生什么影响会不会有并发问题、数据一致性问题、权限绕过问题。这三层审查里第一层可以做得快一点因为 AI 本来就不太会犯风格错误。第二层和第三层是绝对不能省略的它们是兜住 AI“一本正经胡说八道”那类错误的关键。一个可行的建议是让 Claude Code 生成代码之后你把它当作一个刚入职的同事交上来的代码来审带着怀疑去看而不是带着欣赏去看。3.3 用自动化测试当“第二双眼睛”质量门槛前移第三道防线是自动化测试。如果说人工审查是“主观题”那自动化测试就是“客观题”。AI 生成的代码如果能在测试这一关被拦住那是最好的结果因为测试的反馈是确定性的——跑不过就是跑不过不需要讨论。我在项目里对 AI 生成的代码有一个硬性要求凡是 AI 新增或修改的功能必须同步生成或更新对应的单元测试和集成测试。这不是为了凑覆盖率而是用测试用例来反向约束 AI 的思考过程。当你在 prompt 里告诉它“写完功能后请为它编写测试用例覆盖正常流程、异常流程、边界条件”时它在生成业务代码时的认真程度会明显提高——因为它知道自己的代码接下来要被人“出题考”。实际体验下来这一步对生产代码质量提升的效果是最明显的。很多 AI 写的隐藏 bug在人工 review 的时候未必能一眼看出来但只要你补上测试用例跑一遍测试问题就现出原形了。边界条件、空值处理、并发场景、异常分支这些恰恰是 AI 最容易偷懒的地方也是自动化测试最容易抓住的地方。4. 实操过程中踩过的坑与排查实录4.1 典型问题速查AI 代码最常见的四类问题用 AI 写生产代码这一年多我总结出 AI 代码最常见的四类问题在这里直接列个表方便大家对号入座问题类型典型表现隐蔽程度排查难度业务语义错误逻辑自洽但不符合真实业务规则高高边界条件遗漏空值、超长、并发、重复提交等场景未处理中中隐含依赖未声明使用环境变量、外部服务、内置函数但未显式配置高中性能隐患循环里查库、大量对象拷贝、死循环风险低底业务语义错误是 AI 代码最危险的问题因为它从代码本身看不出来必须结合业务需求文档逐条核对。边界条件遗漏是 AI 的“习惯性偷懒”它默认输入都是正常的。隐含依赖未声明这个问题在 Claude Code 这类 agent 型工具里尤其常见它可能默认你的环境里已经有了某个服务但实际生产环境根本没有配置。性能隐患相对好排查但随着代码量的增加人工发现效率很低最好依赖性能测试工具。4.2 看见“看起来对”的代码如何快速定位 AI 幻觉“看起来对”的代码是最折磨人的。我自己的排查经验是不要被代码的表面完整性迷惑而是要主动去寻找“AI 最容易撒谎”的四个位置。第一个位置是时间相关逻辑。AI 对“当前时间”“超时时间”“时区转换”这些概念非常容易出错尤其是设计到“相对时间”计算时它经常搞错基准点。第二个位置是并发控制。AI 默认写出来的代码是单线程思维的它不太容易主动考虑“多个请求同时操作同一份数据”的情况所以锁、事务、幂等这些机制经常被遗漏。第三个位置是第三方 SDK 的版本兼容性。AI 的训练数据是有时间截点的它很可能引用了一个已经废弃的方法或参数。第四个位置是数据一致性尤其是跨服务调用时的“先更新还是先调用”问题AI 常常选择一种看似合理但实际有风险的方式。我建议的排查方法是“反向验证”不要顺着 AI 的代码从头看到尾而是先从结果出发问自己“这段代码最终要达到什么业务效果”然后倒推回去看它的每一步是否真的指向这个结果。这种反向思维比顺着代码读更容易发现 AI 的逻辑漏洞。4.3 建立自己的 AI 编程工作流一个可复用的检查清单如果说上面讲的是“道”这一节讲讲“术”。我在项目里沉淀了一套 AI 编程工作流每次让 Claude Code 干活都走这套流程踩坑概率大幅下降。这套流程分六个步骤需求澄清把业务需求复述一遍明确边界条件、异常场景、非功能指标。验收标准预定义先写测试用例或验收 checklist再开始生成代码。生成代码把需求、验收标准、技术约束一并放入 prompt让 AI 一次性生成。三层审查静态审查、语义审查、系统性审查逐层推进。测试验证跑单元测试、集成测试、手动验证边界场景。归档记录把关键决策、踩坑点、维护注意项写进代码仓库的文档。这个流程看起来很简单但每一步都有细节。比如第一步需求澄清很多人会省略直接告诉 AI“帮我写个 XX 功能”这是最大的错误。你花十分钟把需求讲清楚AI 生成代码的质量可能提升百分之五十。再比如第六步归档记录这一步最容易被忽略但对长期维护价值最大——因为 AI 没有记忆归档记录就是你替它记住“为什么当时要这么写”的唯一方式。在实际操作中我还发现一个非常有效的小技巧让 Claude Code 在生成代码时为每个非显而易见的决策写注释。你可以直接在 prompt 里加一句“对于任何不是最直接答案的代码选择请用注释说明为什么这样做”。这句话看起来简单但效果出奇地好它逼着 AI 暴露自己的思考路径也让你在 review 的时候能快速定位到它的每一个“自作主张”。5. AI 时代一个更严格的代码评审流程有多重要前面说了很多关于标准和防线的内容这一章我想专门聊聊代码评审Code Review这个话题因为它是把“标准更高”落到实处的关键环节。Boris Cherny 在答复里虽然没有大篇幅讲流程但“标准更高”这四个字最终必须通过评审流程来兑现。AI 时代的 code review我认为要做三个观念转变。第一从“看代码好坏”转向“看决策依据”。以前评审时关注的是“这段代码写得漂不漂亮”现在更核心的问题是“为什么这么写有什么依据有没有考虑过替代方案”你需要让 AI 把决策过程暴露出来然后你去评估这个决策是否合理。第二从“单次审查”转向“持续追踪”。AI 生成的代码往往不是一次成型而是经过多轮迭代。每一轮迭代都可能引入新的错误。所以评审不能只做一次而是要在每一轮修改之后都重新过一遍。我见过不少开发者在第一版代码上投入了大量审查精力但 AI 修改后只做“diff 审查”结果新引入的 bug 就被漏掉了。第三从“人 review 代码”转向“人和工具共同 review”。Claude Code 自己也提供了一些审查能力比如让 AI 自己检查自己的代码找潜在问题。虽然它对自己的问题不可能完全客观但作为一种“第二意见”还是有价值的。我有时候会让 Claude Code 先生成代码然后让它自己扮演一个严厉的架构师来审查这段代码——这听起来有点绕但确实能发现一些它自动生成时没注意到的问题。这三个转变落地之后你会发现 code review 的节奏变慢了但效率反而变高了。因为很多问题在早期阶段就被拦截不需要等到测试阶段、上线阶段再返工。回头看 Boris 说的“标准更高”其实最直接的体现就在这里——你不是花了更多时间在“挑错”上而是花更多时间在“理解”和“验证”上。6. 对团队管理者的建议别让 AI 变成质量失控的加速器最后想聊聊团队管理层面的事情。如果你是一个技术团队的 leader你可能会面临一个非常现实的场景团队里有人开始用 AI 编程而且产出速度明显变快这时候你该怎么办是鼓励大家全面铺开还是限制使用我的建议是全面铺开但必须同步建立质量护栏。第一步定标准。把“AI 生成代码必须满足什么条件才能合入主干”用文字明确下来。这个标准不一定要很复杂但必须清清楚楚必须通过测试、必须经过人工 review、必须有设计说明、必须处理边界条件、禁止直接提交未经审查的 AI 代码。第二步建流程。把 code review 从“可选环节”变成“强制环节”并且明确 review 的深度要求。因为 AI 代码的隐蔽错误多所以 review 不能走过场。可以考虑对 AI 生成的代码实行“双人审查”一个人看业务语义一个人看技术实现。第三步留记录。所有 AI 生成的代码建议在 commit message 或 PR 描述里标注出来。这样做的目的不是“标记 AI 写的代码就低人一等”而是为了让后续维护者在排查问题时有一个心理预期——这段代码可能包含 AI 特有的认知盲区需要多留一个心眼。第四步做复盘。我建议团队每隔一段时间做一次 AI 编程质量复盘把过去一个周期里 AI 代码引发的 bug、踩过的坑、总结出的经验整理成文档沉淀成团队的“AI 编程避坑指南”。这个东西越攒越值钱它是团队在 AI 时代独有的知识资产。说到底AI 编程工具本身没有善恶关键在于使用它的人、流程、标准。Boris Cherny 表态说标准应该更高我觉得这对团队管理者来说是一个很好的提醒AI 管不住自己但你可以管住 AI 的输入和输出。把标准提高流程做严AI 才能真正成为团队的加速器而不是隐患制造机。我个人在实际操作中最深的体会是AI 编程工具最大的价值不是帮你把活干完而是帮你把活干得比以前更细。以前你觉得边界条件差不多就行现在你可以拿省下来的时间把每个边界都测一遍以前你觉得注释写不写无所谓现在你可以让 AI 把注释写到能当文档用的程度。标准变高不是负担反而是 AI 给我们的一个机会——一个把过去没时间做得更好的事做好的机会。如果你正在用 Claude Code 或者其他 AI 编程工具我建议你从今天起做一件事挑一个最近要做的功能按照我上面说的验收清单流程走一遍。你会发现当标准明确之后AI 的表现会让你惊喜。这不仅是工具的改变更是工作方式的改变。