沃克森1. 当生成速度远远跑在治理能力前面：项目是怎么走到 25 万行的
说实话，接到这个项目时，我心里是没底的。一个从零开始的产品，所有代码都来自 AI 工具，没有一行是人工手工敲出来的，半年不到积到了 25 万行。听起来很爽，但真到了第 10 万行左右，团队里的每个人——包括 AI 工具本身——都开始明显感觉到一种“窒息感”。不是生成不了代码，而是生成出来的东西没人看得过来、改不动、不敢动。
先交代一下背景。这个项目的本质是一个带数据采集和处理能力的中台服务，早期为了抢时间，团队决定全面转向 AI 编码：需求拆解后丢给 Claude Code、Cursor 等工具生成模块，再由人来集成和验证。前 3 万行的时候非常顺利，几次大的功能模块，AI 在几小时内就能产出可编译、能跑通的实现。但过了某个临界点之后，问题的性质变了。
这个临界点不是行数，而是“依赖关系”的密度。3 万行的时候，模块之间彼此独立，改一个服务不影响另一个；到了 15 万行以上，光是一个订单状态的流转，就有六七个模块在订阅同一套事件。AI 每次生成的代码在自己的局部范围内看是完全正确的，但放到全局，它根本“看不见”旁边模块的约定。这个问题，行数越滚越大，就越发难解。
所以这个标题里那句话，我是举双手同意的：真正难的不是生成，而是治理。生成是能力问题——工具够不够强、模型够不够聪明；治理是系统问题——代码能不能被持续理解、修改、演进和信任。能力问题可以用更好的模型、更大的上下文解决；系统问题没有银弹，只能靠机制。
这个项目给我最大的教训是：治理必须在第一天就设计，不能在失控之后再补。失控之后再补，就像在已经建好的高楼上重新打地基，代价远远超出想象。接下来的内容，我会把 25 万行过程中实际踩过的坑、做过的治理决策和最终沉淀下来的机制，一条条摊开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从“能跑”到“能维护”：一致性治理是第一块硬骨头
2.1 AI 的“创意”过剩：同一件事有五种写法
25 万行代码里，我做过一次抽样统计（用脚本粗扫）：同样的“从 Redis 读取缓存并处理空值”的逻辑，全库有 5 种主流写法；同样的日期时间格式化，有 7 种。为什么？因为每次丢给 AI 一个新的子任务，它在没有明确约束的前提下，会从自己的训练分布里“自由发挥”，而训练分布里各种风格的代码都有。上周 A 模型生成的代码用 ZonedDateTime，这周 B 模型生成的同功能代码用 Instant，再下周上下文一换，又变成 LocalDateTime。单看任何一段都挺优雅，放到一起就是灾难。
这件事对维护的影响是坏的。人还能靠记忆和经验来做判断，AI 没有长期记忆，它每次进上下文看到的都是“局部真相”。如果全库的写入路径、错误处理、日志格式、事务边界都是随机的，AI 后续生成的新代码也只能继续随机。一致性不是审美问题，在 AI 编码项目里，它直接决定了整个代码库是否具备“可被 AI 继续理解”的基础。
2.2 用架构决策记录把“风格”变成“硬约束”
我们的做法是：把一致性要求从人的口头约定，变成机器可读、AI 可提示的硬约束。具体落地了三样东西。
一是架构决策记录库。每定下一个关键技术选型，就写一条 ADR，存在仓库的 docs/adr/ 目录下。比如事件消息的 payload 必须包含 event_id、occurred_at、version 三个字段；所有外部 API 调用必须经过统一的 HTTP 客户端；所有缓存键必须遵循 业务域:实体:ID 格式。这些条目不是为了给人看的，而是为了让 AI 在生成代码时，通