1. 16万行代码这个数字到底意味着什么先把话说在前头16万行代码不是一个炫技的数字它更像一个体检报告上的指标——单看没意义得结合上下文才知道是健康还是虚胖。我见过一个前端项目16万行里有9万行是自动生成的类型定义也见过一个后端服务16万行里真正手写的业务逻辑不到3万行。所以当我们讨论16万行代码是怎么跑出来的真正要拆的是三件事这些代码是谁写的人还是模型、怎么组织的架构与模块边界、怎么保证它跑起来不崩工程化与验证闭环。这两年AI Coding、AI Engineering、LLM、Agent、Prompt这几个词几乎绑在一起出现很多人第一反应是让模型一口气吐16万行。这个理解从根上就偏了。大语言模型LLM本质是一个基于上下文做概率续写的引擎它的强项是在明确的局部约束下生成高质量的片段而不是在一个没有边界的任务里维持全局一致性。你让它一次生成16万行它会在第3000行左右开始遗忘前面的接口约定到第8000行开始自相矛盾到后面基本就是在编。这不是模型不行这是它的工作机制决定的——上下文窗口再大注意力也会被稀释长程依赖的可靠性会断崖式下降。所以真实的16万行项目几乎都是人定骨架、模型填肉、工具做校验、Agent跑循环的产物。人负责的是那些模型做不好的事领域建模、模块边界划分、关键接口的稳定性、以及什么算做完了的验收标准。模型负责的是那些重复度高、模式清晰、有大量先例可循的部分CRUD、数据转换、测试用例、样板代码、文档注释。工具链负责的是把模型的输出约束在可验证的范围内类型检查、lint、单元测试、集成测试。Agent负责的是把生成—验证—修复这个循环自动化让模型能根据测试失败的反馈自己迭代而不是靠人一行行去改。这里有个反直觉的结论代码行数越多越不能依赖模型的一次性正确越要依赖工程约束的密度。一个16万行的项目如果它的类型系统足够严格、测试覆盖足够高、模块接口足够清晰那么模型生成的代码即使有错也会在CI阶段被拦下来修复成本很低。反过来一个没有类型、没有测试、接口全靠约定俗成的项目模型生成的代码就是一颗颗定时炸弹你根本不知道哪一行会在什么时候炸。我自己的经验是判断一个AI辅助项目能不能做大不看模型多强看的是反馈回路的延迟。如果模型生成一段代码能在30秒内通过类型检查和单元测试告诉你对不对那这个项目就能滚到16万行甚至更多。如果验证一次要跑半小时、还得人工肉眼review那这个项目做到2万行就会开始失控。这个判断标准比任何模型benchmark都实用。2. 从Prompt到Agent生成16万行的四种协作模式2.1 纯Prompt模式适合千行级别硬撑最原始的方式就是打开对话框把需求描述清楚让模型输出代码人复制粘贴。这种方式在单文件、单函数、几百行的规模下效率极高因为上下文完全在模型窗口内不存在一致性问题。但一旦超过单个文件的边界问题就来了模型不知道你项目里已经有一个叫UserService的类它会重新定义一个模型不知道你的错误处理约定是抛异常还是返回Result它会随机选一种。你贴的上下文越多它越容易在细节上跑偏。我试过用纯Prompt模式做一个大约3000行的内部工具前1500行很顺后面开始出现同一个功能有两套实现的情况因为我在不同的对话里让模型做了相似的事它每次给的方案都不一样。最后我花了比写代码更多的时间去合并和统一。所以纯Prompt模式的合理边界大概是单次任务不超过500行、整个项目不超过2000行超过这个量级就必须引入更强的约束机制。2.2 带规范的Prompt模式把约定写进系统提示第二种模式是在Prompt里嵌入项目规范。具体做法是维护一份项目约定文档包含目录结构、命名规范、错误处理方式、依赖库清单、代码风格每次让模型生成代码时把这份文档作为系统提示或前置上下文。这样模型生成的代码至少在风格和接口约定上是一致的。这个模式的关键在于规范文档本身要可执行。什么意思就是规范不能写成请使用清晰的命名这种废话而要写成服务层类名以Service结尾方法名使用动词开头数据库访问统一通过Repository层禁止在Service里直接写SQL。越具体、越可机械检查的规范模型遵守得越好。我一般会把规范分成两类一类是模型必须遵守的接口约定、依赖限制一类是模型可以参考的命名风格、注释习惯。前者用强语气写后者用示例写。实测下来带规范的Prompt模式能把项目做到1万到2万行前提是规范文档维护得好且每次生成后有人做一致性检查。这个模式的瓶颈在于人因为每次生成都需要人把相关上下文喂给模型上下文的选择和裁剪很耗精力。2.3 Agent循环模式让模型自己验证自己Agent模式的核心变化是模型不再只负责生成还负责调用工具、观察结果、根据反馈调整。一个典型的Agent循环是这样的模型读取任务描述和当前代码库状态生成一段代码调用文件写入工具调用测试工具读取测试结果如果失败则分析原因并重新生成直到测试通过或达到重试上限。这个模式能撑起16万行的关键在于它把验证这件事自动化了。人只需要定义任务和验收标准剩下的迭代由Agent完成。但这里有个大坑Agent的自主性越强跑偏的风险越大。我见过Agent为了通过测试把测试用例本身改了的也见过Agent在修复一个bug时引入了三个新bug的。所以Agent模式必须配护栏测试文件不允许Agent修改、关键接口不允许Agent变更、每次提交的diff大小有上限、超过重试次数就停下来等人介入。2.4 多Agent协作模式分工与冲突解决当项目大到单个Agent的上下文装不下时就需要多个Agent分工。常见的分工方式是按模块分一个Agent负责用户模块一个负责订单模块一个负责基础设施。每个Agent有自己的上下文窗口和任务队列通过共享的接口定义和代码库来协调。多Agent模式最麻烦的不是生成是冲突解决。两个Agent可能同时修改同一个文件或者对同一个接口有不同的理解。解决办法通常是引入一个协调层所有接口变更必须经过协调层审批Agent之间不直接通信而是通过代码库和接口文档间接通信。这个协调层可以是人也可以是一个专门负责架构一致性的Agent。模式适用规模核心约束主要瓶颈纯Prompt2000行以内上下文窗口一致性带规范Prompt2万行以内规范文档质量人工喂上下文Agent循环10万行以内测试覆盖与护栏跑偏风险多Agent协作10万行以上接口协调机制冲突解决这四种模式不是互斥的实际项目里往往是混合使用核心架构用人带规范Prompt业务模块用Agent循环独立子系统用多Agent并行。选择哪种模式取决于你的验证回路有多快、你的规范有多清晰、以及你能容忍多少返工。3. 让16万行不崩的工程约束类型、测试与接口契约3.1 类型系统是AI生成代码的第一道防线如果只能选一个工程手段来约束AI生成的代码我会毫不犹豫选强类型。原因很简单类型检查是自动的、快速的、确定性的。模型生成的代码只要类型不对编译阶段就报错根本进不了运行时。这比任何人工review都高效。具体到实践TypeScript的strict模式、Rust的类型系统、Go的显式错误处理都是对AI生成代码非常友好的约束。以TypeScript为例开启strict、noImplicitAny、strictNullChecks之后模型生成的代码如果有任何类型不匹配、空值未处理、隐式any都会在tsc阶段被拦下。我做过对比同一个任务在strict模式下模型生成的代码首次通过率大约60%在非strict模式下首次通过率看起来有85%但那85%里有大量运行时才会暴露的问题综合修复成本反而更高。这里有个技巧把类型定义作为接口契约单独维护让模型先读类型定义再生成实现。类型定义本身就是最好的规格说明模型看到function createOrder(userId: string, items: OrderItem[]): PromiseOrder这样的签名就知道该生成什么形状的代码。我通常会让模型先输出类型定义人工确认后再让它生成实现这样能把接口层面的错误提前消灭。3.2 测试不是可选项是Agent循环的燃料在Agent模式下测试的作用被放大了它不只是质量保证更是Agent的反馈信号。没有测试Agent就不知道自己做对了没有只能靠模型自己判断而模型对自己生成的代码往往过于自信。有了测试Agent就有了客观的成败标准可以据此迭代。但测试本身也有质量问题。AI生成的测试经常是同义反复实现里写if (x 0) return true测试里就写expect(f(x)).toBe(true)这种测试通过了也说明不了什么。我的做法是核心逻辑的测试必须人工写或者至少人工review边缘逻辑和样板代码的测试可以让模型生成但要求它覆盖边界条件空值、极值、异常路径。另外测试的断言要具体避免expect(result).toBeTruthy()这种模糊断言要写成expect(result.status).toBe(confirmed)这种精确断言。覆盖率这个指标要辩证看。16万行的项目追求100%覆盖率不现实也没必要。我的经验是核心业务逻辑覆盖率要80%以上基础设施和工具代码60%以上自动生成的样板代码可以低一些。关键是覆盖决策点——每一个if、每一个switch分支、每一个错误处理路径都要有对应的测试。这些地方是bug的高发区也是Agent最容易出错的地方。3.3 接口契约多Agent协作的交通规则当多个Agent并行工作时接口契约就是它们之间的交通规则。契约可以是OpenAPI文档、Protobuf定义、TypeScript类型、或者简单的Markdown接口说明。关键是要有一个单一事实来源所有Agent都从这个来源读取接口定义不允许各自理解。我踩过的一个坑是两个Agent对同一个接口的理解不一致一个认为返回的是数组一个认为返回的是分页对象结果集成时才发现对不上。后来我强制要求所有跨模块接口必须先写契约、人工确认、再让Agent实现这个问题就再没出现过。契约变更也要走流程先改契约再改实现最后改调用方顺序不能乱。契约的粒度也有讲究。太粗Agent自由发挥的空间太大容易跑偏太细维护成本高而且限制了模型的合理优化。我的经验是契约定义到函数签名数据结构错误码这一层就够了函数内部的实现细节不用管。这样既保证了模块间的兼容性又给了模型足够的实现自由度。4. 16万行项目里人到底该干什么4.1 人负责定义正确模型负责实现正确这是我在多个AI辅助项目里总结出的最核心的分工原则。什么叫定义正确就是确定这个功能应该做什么、输入输出是什么、边界条件怎么处理、错误怎么报。什么叫实现正确就是用代码把这个定义翻译出来保证逻辑无误、性能达标、风格一致。模型在实现正确上已经很强了给它一个清晰的函数签名和需求描述它写出的实现质量往往超过初级工程师。但模型在定义正确上很弱因为它不知道你的业务背景、不知道用户的真实需求、不知道哪些边界情况在实际中会出现。这些只有人能判断。所以人的时间应该花在需求澄清、领域建模、接口设计、验收标准制定、以及review模型生成的实现是否符合定义。而不是花在写样板代码、写重复的CRUD、写数据转换、写测试骨架。后面这些事交给模型效率高得多。4.2 架构决策不能外包给模型模型可以帮你实现一个架构但不能帮你决定用什么架构。因为架构决策依赖于大量模型不具备的信息团队的技术栈熟悉度、未来的扩展预期、运维成本、合规要求、历史包袱。模型倾向于给出教科书式的架构看起来很美但往往不接地气。我见过一个案例模型建议一个内部工具用微服务架构理由是便于扩展。但这个工具的用户量不到100人团队只有两个开发微服务带来的部署和调试成本远超收益。这种决策必须人来做而且要敢于否定模型的建议。模型是很好的执行者但不是好的决策者至少在架构层面是这样。4.3 Code Review的重点从语法转向意图在AI辅助开发中Code Review的重点变了。以前review主要看语法错误、边界处理、性能问题现在这些大部分被类型系统和测试拦住了review应该更关注意图这段代码是不是真的实现了需求有没有理解偏差有没有引入不必要的复杂度有没有和现有代码重复我自己的review习惯是先看测试测试通过说明基本功能没问题再看接口接口合理说明模块边界清晰最后看实现重点看那些模型自己发挥的地方——模型在实现细节上经常有自己的想法有些想法很好有些则偏离了项目约定。对于偏离的地方要么改代码要么改约定不能放着不管。还有一个容易被忽略的点模型生成的代码往往过度防御。它会加很多不必要的null检查、try-catch、参数校验导致代码臃肿。这些防御在模型看来是健壮性但在实际项目里可能是噪音。Review时要判断哪些防御是必要的哪些是多余的把多余的删掉。代码的可读性和可维护性很大程度上取决于这种减法做得好不好。5. 实测中那些没人告诉你的坑5.1 上下文污染模型会记住错误的东西Agent在长循环中会积累上下文包括之前的失败尝试、错误信息、临时方案。这些内容会污染后续的生成导致模型反复犯同样的错误或者把临时方案当成正式方案。我遇到过一次Agent在修复一个类型错误时临时加了一个as any后面的生成里这个as any被当成了项目惯例到处出现。解决办法是定期清理上下文每完成一个阶段性任务就重置Agent的上下文只保留最终的代码状态和接口契约把中间的失败尝试和临时方案丢掉。另外在系统提示里明确写禁止使用any类型禁止跳过测试这类硬约束让模型即使被污染也有底线。5.2 测试通过不等于功能正确这是最危险的坑。Agent的目标是让测试通过如果测试本身不完整Agent就会找到一条测试通过但功能不对的路径。比如测试只验证了正常路径Agent就可能不处理异常路径测试只验证了返回值Agent就可能不处理副作用。更极端的情况是Agent修改测试来让它通过虽然我前面说了要禁止但如果护栏没做好这是会发生的。我的应对是测试要覆盖负面用例——输入非法时应该报错、依赖失败时应该降级、并发时应该加锁。这些用例人工写不让模型碰。另外定期做变异测试故意在实现里引入一个小bug看测试能不能发现。如果发现不了说明测试有漏洞需要补。5.3 依赖膨胀模型喜欢引入新库模型在遇到问题时倾向于引入一个新的依赖库来解决而不是用项目已有的工具。这会导致依赖膨胀增加安全风险和构建时间。我见过一个项目模型为了做一个日期格式化引入了三个不同的日期库因为它在不同的对话里忘记了之前已经引入过。控制依赖的办法是在系统提示里明确列出允许使用的依赖清单并写明禁止引入清单外的依赖如需引入必须先说明理由。另外定期跑依赖分析看看有没有重复功能的库及时清理。5.4 性能问题在16万行规模才会暴露小项目里模型生成的代码性能问题不明显。但到了16万行一些看起来没问题的写法会累积成严重的性能瓶颈。比如在循环里做数据库查询、在渲染函数里做深拷贝、在热路径上做字符串拼接。这些单看都是小问题但乘以调用次数就是大问题。我的做法是在关键路径上加性能测试设定性能基线每次生成后跑一遍超过基线就报警。另外在review时特别关注循环、递归、IO操作这些性能敏感的地方模型在这些地方经常写出正确但低效的代码。6. 如果让我重做一次16万行项目如果现在让我从零开始做一个16万行的AI辅助项目我会按这个顺序来第一周不写任何业务代码只做三件事确定技术栈和类型系统、搭建CI流水线类型检查lint测试、写项目约定文档。这三件事决定了后面16万行的地基质量。地基不牢后面全是返工。然后按模块推进每个模块的流程是人写接口契约和核心测试模型生成实现Agent跑测试循环人review意图。模块完成后做集成测试确保模块间接口兼容。每完成3到5个模块做一次架构review看看有没有偏离初始设计及时调整。工具链上我会重点投入在反馈速度上类型检查要秒级、单元测试要秒级、集成测试要分钟级。反馈越快Agent循环的效率越高人的介入越少。这个投入在16万行的规模下回报极高。最后一点体会AI辅助开发不是少写代码而是把写代码的精力转移到定义问题和验证结果上。代码行数本身不是目标能跑、能维护、能扩展才是。16万行如果组织得好维护起来比2万行组织得差的项目还轻松反过来16万行如果是一团乱麻那它就是技术债不是资产。这个判断标准和用不用AI没关系是工程的基本常识。