AI能写80%代码，但架构决策和质量守门必须由人掌控

1. 先别急着庆祝AI 把代码量打下来却没有把复杂度一并降下来GitHub Copilot、Cursor、Claude Code 一个接一个出来之后我身边的讨论明显分成了两派。一派觉得程序员终将失业另一派觉得 AI 只会写玩具代码。我的真实感受是这两种说法都不太准。AI 写代码的能力现在已经到了什么程度呢单论“把一段需求翻译成可运行代码”这件事它在绝大多数场景里比大部分初级工程师都更快甚至更稳。不少团队已经实现了“工程师下需求、AI 生成代码、人工走查合入”的流程我自己的不少日常工作也是这么跑的。但恰恰是这个流程让我意识到一个反直觉的现象AI 能写 80% 的代码并不意味着系统能自动拥有 80% 的质量。剩余的 20%也就是决定系统走向的架构决策和决定系统下限的质量守门必须是你本人而且只能是你本人。这篇开篇词我想认真聊一聊为什么代码可以交给 AI决策和质量的判断权必须攥在自己手里。1.1 代码生成器与架构师的边界前者负责“长出来”后者负责“长对方向”当我说“AI 能写 80% 代码”时并不是夸张。在目前主流工具的辅助下常规 CRUD 接口、数据模型定义、配置文件初始化、消息队列消费者、基础单元测试甚至前端页面的列表与表单都可以用自然语言快速生成。如果你愿意多花一点时间维护项目级的提示词库把团队的代码规范、脚手架模板、常见坑位写成规则喂给 AI生成出来的代码质量会更高甚至可以直接跑通。我刚接触这类工具的时候也有过一段“月更十万行”的兴奋期后来才慢慢发现真正带来麻烦的从来不是“没代码”而是“产出失衡”。代码量的增长会带来一个复杂度幻觉项目文件越来越多接口越来越丰富看起来进度飞起但代码之间的依赖关系、调用协议、约束条件并没有因为代码是 AI 生成的就自动清晰。用个生活化的比喻AI 生成代码就像一块任你揉捏又能自我复制的水泥你给它一个模子它就能快速成型。但模子是自己设计的还是随手捡的直接决定了这堆水泥是一堵合格的墙还是挡在通道上的障碍物。架构决策就是你手中的模子它决定了模块与模块之间怎么划分、依赖往哪个方向流、数据如何流转、失败时如何降级、上线后如何观测。没有这些约束的 AI 生成代码本质上是在没有图纸的情况下快速浇筑。你可能觉得自己在做工程其实只是在用更高的加速度制造一座更结实的违章建筑。1.2 进度越快风险窗口越长为什么“代码多了”反而更危险还有一个很容易被忽略的副作用AI 写出的代码因为行数多、功能全往往会让团队过早进入“好像可以上线了”的错觉进而提前把系统暴露在更复杂的流量环境里。过去一个功能从开发到上线中间会经过编译、人工测试、代码 review 等很多次“人类触达”每次触达都是一次检查机会。现在 AI 把这条流程压扁了工程师可以把同样的功能在半天内写完但代码的检查机会却不会自动变多。如果质量门禁没有同步加强那“AI 写得快”就会变成“劣质代码上线快”。我见过一个很典型的项目刚升级的初级工程师用 AI 一口气生成了一整套订单服务接口、数据库、缓存、消息队列全都有demo 跑得顺顺当当。等真正上了生产环境才发现订单状态流转的所有判断都散落在 controller 里没有领域模型层幂等逻辑靠数据库唯一索引事务边界完全依赖框架默认行为。更麻烦的是AI 生成的代码给所有接口都返回了 200业务异常全部藏在日志里。系统上线第三天下午的调用量一上来整个服务被慢 SQL 拖垮而大家连问题出在哪都看不出来。这个故事我们太熟悉了AI 写了 80% 的代码但那 80% 只是一个没有架构约束条件的“顺滑表面”。真正让系统在真实流量、真实需求、真实业务规则下稳定运行的那 20%恰恰不是 AI 能替你完成的。它不是写不出来而是写出来了你也不敢用因为你没有足够理由去相信一个没有经历过权衡的模型能够替你承担架构层面的风险。2. 架构决策为什么必须由人拍板而不是让大模型替你补全先直接说结论架构决策不是“写码”而是“妥协的艺术”。在架构层面每个决定本质上是多个目标之间的权衡进度、成本、可维护性、性能、扩展性、团队熟练度。AI 擅长在给定目标函数里生成唯一解但它很难自己做目标排序更不可能替你做“这个季度先把扩展性放一放优先保证数据一致性”这种取舍。我至今没看到哪个大模型敢于明确告诉你“这个决策我推荐 A但如果你下季度要做多租户你应该选择 B因为 A 会让租户隔离变得很难。”就算它真把这段话说出来也往往是从某个常见案例里学来的套路而不是基于你项目里具体的业务部署环境。2.1 架构决策的本质一段带着权衡与责任的“单选答案”你以为架构决策是“画出几张架构图”就结束了吗不是它真正的输出其实是“在多个正确方案里选出一个在当前约束下最不坏的那个”并为这个选择承担后果。系统需要扩展性但扩展性往往带来复杂度系统需要快速上线但快速上线常常要牺牲一部分设计完备性系统需要单点权威存储但高可用又要求分布式副本。架构决策就是在这些互相拉扯的目标之间让步。模型可以告诉你“这里有一个 trade-off”但它很难为“放弃 A 选择 B”这个行为负责。你可以追问一个架构师半个月前为什么决定引入消息队列但很难去追责一个模型的回答。这并非模型智能不够而是它的训练目标天然不具备“决策责任”的概念它生成“下一个最像样的 token”而不是生成“基于你的企业利益做出的最终选择”。所以如果你把架构决策交给 AI你省下的是在会上被反复追问“你想清楚没有”的尴尬失去的却是对风险的控制力。拿盖楼来类比审图师和施工队的区别就在这。AI 是施工队里最能干的工人你给它图纸它能把墙砌得又快又直但它不会在图纸出问题时停下来问你“这里承重墙位置不对要不要改”。它只负责执行不负责判断图纸能不能支撑整栋楼。架构决策就是你手中的图纸系统未来一年怎么演化、哪些地方值得押注这些都要有人做出明确选择并承担后果。2.2 大模型永远读不到的两块拼图隐性上下文与历史包袱我承认把整个项目的代码库、需求文档、会议纪要都丢给 AI 之后它能给出比大多数开发都完整得多的上下文推断。但即便这样仍有大量信息不会进入任何文件中团队里最熟悉支付系统的那位同事下个月要转岗这个服务的数据量在某个营销节点当晚会翻五十倍公司合规部门要求所有用户 ID 必须脱敏存储去年底刚因为合同纠纷换过一次数据供应商……这些信息要么没有被写成文档要么根本无法被模型感知。真正做过架构决策的人都知道最后拍板往往不是靠纯技术推导而是靠对组织和业务的长期理解。这也是为什么即便未来大模型能读更多上下文、能做更长时间的推理我依然倾向把“最终决策权”保留在人类手里。模型的推断可以帮你列选项、帮你做预判但它无法理解那些只存在于人脑中的“潜台词”。另一个不容忽视的因素是历史包袱。架构决策总是背着过去的债现有系统的技术债、团队技术栈的偏好、组织分工的边界、核心业务人员和运营人员嘴里的隐性规则。这些信息分散在会议纪要、PR 讨论、告警群里从来不会完整地出现在 prompt 里。你在 AI 面前输入“帮我设计订单系统的模块划分”它只能给你一套教科书式拓扑图。可你要处理的是无数个已经存在的坑、人和流程。这些上下文才是架构决策里最值钱的部分。2.3 实操让 AI 做调研员让人做决策者那么在实践里AI 能在架构决策中起到什么作用我自己的操作方式可以拆成三层。第一层技术调研和方案对比放心交给 AI。比如“我们在低峰期每秒只有 200 个写入请求缓存层用 Redis 还是本地内存够用”这种问题可以让 AI 快速给出对比甚至生成压测脚本非常高效。第二层模块边界和数据流设计让 AI 参与讨论但必须由人主持。你可以让 AI 先给出几个拆分的候选方案然后你逐个追问为什么会这样拆、依赖方向是什么、未来哪个点最容易变化。这能帮你补盲但不要直接采用输出。第三层演进路径与战略取舍必须要由对业务和团队负责人来拍板。例如“今年先保证快上线还是先把多租户隔离做完”这种问题的答案不是从代码里长出来的而是从商业目标和风险偏好里长出来的。记住一个原则AI 可以帮你把事情想全但它不能替你决定“这件事值得不值得冒风险”。3. 质量守门AI 把“写出代码”的门槛拉低了却把“让代码合格”的权重抬高了再来看质量这一端。过去写代码本身是一个天然的筛选过程一个人要经历语法、编译、调试、单测、代码评审代码才有机会进主线。现在 AI 帮你把“写出代码”这层筛子直接拆掉了但被拆掉的还有初级工程师们原本可以通过反复犯错建立起来的质量直觉。当 AI 负责生成代码人类负责审查和验收质量守门就成了最后的关卡。为什么质量标准并不完全是刚性的除了单元测试覆盖率这种客观指标之外还有大量主观的、上下文相关的判断。比如“这段代码的命名是否准确表达了业务含义”“把这个逻辑放在 service 层还是 domain 层是否更合理”“异常是应该抛出去给上层处理还是在这里兜底”这几个问题没有对错只有在具体场景里是否合适。AI 能给你生成一个合理概率非常高的解法但它没法理解代码在真实使用时会怎样被调用、被修改。3.1 我在 review AI 生成的代码时踩到频率最高的几个坑先列一下我在实际工作中反复见到的几类问题给读这篇文章的朋友提个醒。第一个是边界情况缺失。AI 非常擅长处理正常路径参数合法、资源充足、依赖可用。可一旦碰到网络超时、幂等重试、数据竞争、部分失败这类“坏天气”它生成的代码经常出现逻辑空洞。我发现过不止一次AI 生成的订单处理流程在数据库更新失败后直接抛异常根本没有补偿逻辑。第二个是安全校验偏弱。AI 更容易默认相信输入是安全的文件上传接口只做了前端格式限制、内部接口不做鉴权、SQL 拼接没走参数化这些我都亲眼见过。它不是故意留漏洞而是模型在训练数据里没有把“安全防护”当成默认职责只有你把需求写得很明确它才会在上下文里做更多约束。第三个是代码风格和项目规范脱节。AI 生成的代码总有它自己的“平均审美”命名规范、错误处理粒度、日志输出格式常常和团队已有代码不一致。在大型项目里如果每个模块都由 AI 生成且没有统一规则约束“代码割裂感”会在一段时间后集中爆发每个文件都能跑但整个项目看起来像是十几个人的拼盘。第四个是过度设计。AI 会把问题想得很复杂为一个简单的列表查询引入缓存、消息队列、分布式锁全套组件。代码行数上去了维护成本也上去了。这种问题比缺代码更隐蔽因为表面看起来项目“很完善”实际上每多一个组件就多一个故障点。3.2 质量守门到底在守什么很多人以为质量守门就是修 bug、跑测试、看覆盖率其实它守的是一整套“长期能力”可读性、可维护性、可扩展性、安全性、可观测性。对于 AI 生成的代码你尤其要关心“可演进性”也就是这段代码在下一次需求变化时是容易被修改还是像焊死的铁板一样牵一发动全身。我给团队定的标准是这样的不管代码是不是 AI 写的人在 review就得保证它符合团队既定的架构边界、满足可观测性要求、对异常路径有明确处理、有足够的可测试性。这四条必须人工把关因为它们是语义层面的判断不是格式层面的检查。静态检查工具能抓出未使用的变量但抓不出“这个服务不该直接读订单库”这类架构越界问题。更现实的问题是你根本无法预估 AI 生成出来的代码会在哪里翻车。因为 AI 生成的代码没有原本的思维过程你很难顺着上下文去排查更容易盲目相信它。我见过 AI 写的 SQL 条件没考虑索引导致全表扫描见过 AI 给文件上传接口生成了前端白名单但后端完全没有二次校验也见过 AI 补全的并发工具类用错锁粒度把一个应当并行的批量任务几乎完全串行。这些问题如果出现在人工代码里你还能顺着写代码的人的逻辑去排查但换成 AI 生成你面对的是一段“没有来路”的结果只能靠质量守门兜底。因此我强烈建议把 AI 当实习生而不是当专家。你是要验收它交付的代码是否达到可上线标准的那个人。你不仅要有代码级的能力还要有上下文级别的批判性思维这段逻辑符不符合业务规则有没有异常分支数据安全边界有没有守住性能上会不会有坑如果你自己都不知道答案那就先不要放 AI 进去否则它会把一次大规模的质量事故变成一次成本只需要几分钱的“试错”。3.3 建立人机配合的质量守门流程实操层面我会推荐一个很朴素但很有效的流程让 AI 负责“生产”和“初筛”让人负责“验收”和“裁决”。具体来说开发同学可以把 AI 生成的代码放进 CI 流水线先跑静态检查、单元测试、安全扫描、圈复杂度检查。AI 可以帮你快速生成测试用例和静态规则但真正决定“这条代码能不能被合入”的仍然是会看业务上下文的人。我给团队设计过一条规则所有 AI 生成的、涉及资金流转、用户隐私、并发控制的代码必须经过至少两位资深工程师的回归式 review而列表查询、配置读取这类低风险代码可以做轻度 review。规则可以因团队而异但核心思路一致——把人的审查精力集中投放到被 AI 放大过的风险区域。还有一个值得投入的方向是“架构护栏”。不需要依赖某个大模型你可以在 CI 里加入架构测试规则禁止 controller 直接调用 repository、禁止非网关服务访问外网、禁止在 service 层引入具体某个数据库实现等。这些规则相当于给 AI 生成的代码画了一条物理边界它再能写出了这条线也会被你拦下来。这个思路比“肉眼盯代码”可靠得多也容易在团队里复制。4. 把 AI 当杠杆还是当对手工程师的核心能力正在迁移最后我想聊一个更大的话题当 AI 能写 80% 的代码之后工程师的价值锚点到底在哪里。过去几年一名工程师的报价基本跟“能写多快”挂钩现在这个挂钩关系正在断裂。AI 让生成代码的产能变成了一种公共资源你能写快别人也能写快。真正稀有的变成了“在同样快的产出里谁能保证架构不被拉垮、质量不被稀释”。我见过不少焦虑的开发者说“AI 要取代程序员了”但我更认同另一个说法AI 会取代那个只会写代码的“程序员”也会成就那个会用 AI 来放大判断力的“架构师”。判断力和责任就是这中间的分水岭。4.1 被拉平的是产能不是判断力为什么判断力越来越值钱因为代码生产成本趋近于零之后整个生产过程的瓶颈从“写得出来”变成了“想得清楚”和“扛得住”。你让 AI 生成一百个订单服务接口很容易但你能不能准确分辨这 100 个接口里哪些真需要消息队列哪些用同步调用更省事你让 AI 生成一个数据库分片方案很容易但你能不能预判半年后查询模式的变化决定要不要在今天就预留分片键这些判断不是模型写代码写得好就能替代的而恰恰是系统在真实世界里能不能活下来的关键。从另一个角度说AI 也正在把原来“被写码淹没”的时间还给你。你可能比以前多出 30% 的时间来思考架构、梳理逻辑、做复盘而不是加班调一个换行符。这是好事前提是你真的把时间花在决策和质量上。如果省下来的时间只是用来生成更多没被审查的代码那只是在加速系统腐化。4.2 如何在 AI 时代训练自己的架构与质量肌肉如果你想实打实地培养这两项能力我有几个具体建议。一是写架构决策记录ADR哪怕只有两三行也要写。把“当时为什么选 A 而不是 B”记下来过三个月再去复盘你会发现自己对取舍的理解在快速加深。这个习惯成本很低但对建立架构直觉非常有效。二是主动 review 别人的 AI 代码尤其是高风险模块。看别人 AI 生成的代码是最好的边界测试样本因为它的不合理之处往往很明显。你不需要改它只需要在心里跑一遍这里如果并发量上来了会怎样如果下游依赖挂了会怎样时间久了你的风险嗅觉会被练出来。三是让 AI 先出方案你不急着接受也不急着否定而是先问它“你这个方案在什么条件下会崩”。这种追问会逼你建立自己的架构判断。很多时候你会发现自己比想象中更了解系统的软肋。四是把你过去踩过的线上故障做成清单回头去核对 AI 生成的代码是不是又踩了同样的坑。AI 不会记住你上个季度因为缓存穿透发生的故障只有你会。这份清单就是你的专属质量守门武器。4.3 这个系列接下来会写什么这篇开篇词之后我计划沿着“AI 辅助开发下的人类关键决策”持续更新包括如何为 AI 搭建项目级上下文、如何用质量门禁拦截 AI 生成的坏味道、如何在团队里建立 AI 评估制度、以及如何把你积累的架构经验沉淀成能被 AI 理解的规则库。如果你现在也开始依赖 AI 写代码我强烈建议你从今天起做一件事在每一次生成之前先写下你期望它遵守的两条约束在每次合并之后回头检查那段代码有没有悄悄破坏你设定的边界。这个动作看起来不起眼但它会帮你慢慢建立 AI 时代最稀缺的肌肉——拥有最终判断力的习惯。架构决策和质量守门这件事可以借力但永远别交出去。