1. 16万行代码这个数字背后到底藏着什么先把场景摆出来。一个中等规模的业务系统前端、后端、移动端、脚本、配置、测试用例全算上代码行数落在十几万这个量级是非常正常的事情。但16万行这个数字之所以值得拿出来说不是因为它大而是因为它背后对应着一个很现实的问题这么多代码到底是怎么被生产出来的传统认知里代码是一行一行敲出来的。一个熟练工程师一天的有效产出算上调试、重构、写测试、改bug净新增代码能稳定在100到300行已经算不错。按200行算16万行需要800个工作日差不多是3到4个人干一整年。这是手写时代的账。而现在大家讨论的AI Coding、LLM、Agent本质上是在重新算这笔账。不是简单地让AI帮你写几行而是把整个生产流程拆开看哪些环节可以交给模型哪些环节必须人来兜底哪些环节需要人和模型来回协作。16万行代码跑出来这个跑字用得很妙——它暗示的不是敲而是运转是一套流程在自动或半自动地推进。我先把结论放在前面16万行代码不是靠一个超级Prompt一次性生成的也不是靠某个Agent全自动跑完的。它是一套人定架构、模型填肉、工具做校验、人做决策的流水线产物。这套流水线里LLM负责生成和理解Agent负责编排多步任务Prompt负责把人的意图翻译成模型能执行的指令而人负责所有模型做不了的判断。下面我会把这套流水线拆成几个部分讲清楚为什么单纯堆Prompt行不通、Agent到底在编排什么、代码质量在AI参与下会怎么变化、以及一套可复现的实操流程长什么样。适合正在用或准备用AI辅助开发的工程师也适合想搞清楚AI Coding到底靠不靠谱的技术管理者。2. 为什么一个超级Prompt生成整个项目是个幻觉2.1 上下文窗口不是无限大的很多人对LLM的第一个误解是以为只要Prompt写得够好模型就能一次性吐出整个项目。这个想法在Demo阶段能骗过自己——生成一个待办清单应用、一个博客首页确实可以。但一旦项目规模上去第一个撞上的墙就是上下文窗口。模型的上下文窗口再大也是有限的。16万行代码按平均每行40个字符算大概是640万字符换算成token量级在百万以上。即便用上目前主流的长上下文模型把整个代码库塞进去也不现实更别说还要留出空间给指令、示例和输出。而且上下文越长模型对中间部分的注意力越容易衰减这在业界已经是被反复验证的现象——开头和结尾的信息记得牢中间的内容容易被忽略。所以正确的做法不是把整个项目喂给模型而是按需检索、分块处理。每次只把当前任务相关的文件、函数、接口定义喂进去让模型在有限的上下文里做高质量的局部生成。这就需要一套检索机制把代码库切分成可管理的块根据任务动态组装上下文。这也是为什么现在很多AI Coding工具都在做代码索引和语义检索——不是为了炫技是因为不这么做根本跑不动。2.2 单次生成的代码无法保证一致性第二个误解是以为模型生成的代码天然自洽。实际上如果你让模型分十次生成十个模块每次它都可能用不同的命名风格、不同的错误处理方式、不同的目录结构。第一次它可能用getUserById第二次可能用fetchUser第三次可能用queryUserInfo。单看每个函数都没问题拼在一起就是一锅粥。这就是为什么架构约束必须先于代码生成。在让模型动手之前人需要先把几件事定死目录结构、命名规范、接口契约、错误处理约定、依赖注入方式。这些约束要么写进Prompt作为系统指令要么做成配置文件让工具自动注入要么通过代码模板强制。没有这层约束模型生成得越快后面收拾烂摊子的成本越高。我自己的做法是维护一份conventions.md里面写清楚这个项目里什么该怎么做。每次调用模型时把这份约定作为系统提示的一部分。看起来是多了一步但它省下的是后面无数次这个命名不对这个异常没处理的返工。2.3 Prompt Engineering的边界在哪里Prompt Engineering这个词被炒得很热但它的能力边界其实很清楚。它能做的是把模糊的意图翻译成清晰的指令把隐式的期望显式化把复杂的任务拆解成模型能一步步执行的步骤。它做不到的是让模型拥有它没有的知识让模型突破上下文限制让模型在没有反馈的情况下自我纠错。所以你会看到真正跑通大规模AI Coding的团队Prompt只是其中一环。他们还会做Few-shot示例库给模型看几个标准答案、输出格式约束强制模型按JSON或特定结构返回、多轮校验生成后让另一个模型或规则引擎检查、人工审核卡点关键代码必须人过目。Prompt是入口不是全部。提示如果你现在还在靠把需求描述得尽量详细来提升生成质量可以试试换个思路——把需求拆成接口定义输入输出示例边界条件错误处理要求四段分别喂给模型。实测下来这种结构化输入的生成质量比一大段自然语言描述稳定得多。3. Agent在16万行代码的生产线上到底干了什么3.1 Agent和LLM的区别一个负责想一个负责做先把概念理清楚。LLM是大脑它擅长理解和生成但它本身不会行动——它不会去读文件、不会去跑测试、不会去调用API。Agent是手脚大脑的组合它在LLM的基础上加了一层执行循环观察当前状态、决定下一步动作、执行动作、观察结果、再决定下一步。举个具体的例子。你让LLM修复这个bug它可能给你一段看起来合理的代码但这段代码能不能跑、有没有引入新问题它不知道。你让Agent修复这个bug它会先去读相关文件、定位问题、生成修复方案、修改代码、跑测试、看测试结果、如果失败就再调整。这是一个闭环LLM只是这个闭环里的一个环节。在16万行代码的生产线上Agent的价值就在于把那些重复的、多步的、需要根据中间结果调整的任务自动化。比如批量重构、批量补测试、批量改接口调用方式。这些任务单靠LLM做不了因为需要读文件、改文件、验证结果单靠脚本也做不了因为需要理解代码语义。Agent正好卡在中间。3.2 多智能体协作为什么一个Agent不够用单个Agent能处理的任务复杂度是有限的。当任务涉及多个关注点——比如既要保证功能正确又要保证性能还要保证安全——一个Agent很容易顾此失彼。这时候就出现了多智能体协作的模式。常见的分工方式是这样的一个规划Agent负责把大任务拆成小任务一个编码Agent负责写代码一个审查Agent负责检查代码质量一个测试Agent负责生成和运行测试。它们之间通过共享的状态或消息传递来协作。规划Agent拆完任务后编码Agent领任务、写代码写完交给审查Agent审查不通过就打回重写通过了再交给测试Agent。这种模式听起来很美好但实操中有个坑Agent之间的通信成本很高。每个Agent都要消耗token都要花时间而且它们之间可能产生误解。我见过一些项目多智能体跑一圈下来token消耗是单Agent的五六倍但质量提升并不明显。所以我的建议是先从单Agent人工卡点开始确认瓶颈确实在需要多角色协作上再上多智能体。不要为了架构好看而架构。3.3 Agent的执行终止与错误处理热词里有一条agent execution terminated due to error这其实是Agent落地时最常见的问题之一。Agent在执行多步任务时任何一步出错都可能导致整个流程中断。而Agent的错误处理能力远不如人类工程师。常见的错误类型有几类工具调用失败比如文件不存在、API超时、输出格式错误模型返回的内容不符合预期结构、逻辑死循环Agent反复尝试同一个失败的操作、上下文溢出多轮交互后上下文超限。每一种都需要不同的处理策略。我的做法是给Agent设三层保护第一层是重试机制对于工具调用失败这类瞬时错误自动重试2到3次第二层是回退策略如果某个操作连续失败就跳过它并记录继续执行后续步骤最后统一报告第三层是人工介入卡点当Agent连续失败超过阈值或者遇到它明确标记为不确定的情况就暂停并通知人。这三层保护下来Agent的可用性会高很多。注意不要给Agent设置无限重试。我踩过这个坑一个Agent因为某个文件路径写错反复重试了几十次烧掉大量token不说还把日志刷爆了。重试次数一定要有上限超过就停。4. AI参与下代码质量到底会不会下降4.1 质量下降的真实原因不是AI本身AI Coding会不会让代码质量下降这个问题我的答案是会但原因不在AI在于使用方式。同样一把刀厨师用是工具乱挥就是凶器。质量下降通常发生在几种情况下。第一种是无审查直接合并模型生成什么就提交什么没人看。第二种是缺乏测试覆盖模型生成的代码没有对应的测试出了问题发现不了。第三种是架构约束缺失前面说过模型各写各的拼起来不一致。第四种是过度依赖工程师不再理解代码在做什么只负责复制粘贴一旦出问题完全无法排查。反过来如果使用方式正确AI参与反而可能提升质量。因为模型可以不知疲倦地生成测试用例、可以做静态检查、可以按照统一规范生成代码这些都是人类容易偷懒的地方。4.2 用生成-审查-测试三道关把质量兜住我现在的流程是这样的三道关缺一不可。第一道关是生成阶段的结构化约束。不是让模型自由发挥而是给它明确的模板和规范。比如生成一个API接口必须包含路由定义、参数校验、业务逻辑、错误处理、日志记录、单元测试。这六部分缺一不可模型必须按这个结构输出。第二道关是审查阶段的多重检查。代码生成后先过静态检查工具lint、类型检查再过安全扫描检查是否有硬编码密钥、SQL注入风险等最后过人工审查。人工审查不是逐行看而是看关键逻辑、看边界处理、看是否符合架构约定。第三道关是测试阶段的自动化验证。每个生成的模块必须有对应的测试测试要覆盖正常路径和异常路径。测试跑不过的代码不允许合并。这一步是最后的安全网也是最有效的一道。这三道关下来代码质量不会比纯手写差某些方面甚至更好——因为测试覆盖率往往比手写时更高。4.3 密钥泄露这类低级错误为什么反而更容易发生热词里有一条使用llm时如何防止密钥等鉴权信息泄露这个问题在AI Coding场景下确实更突出。原因很简单模型在生成代码时可能会顺手把示例里的密钥写进代码或者把密钥硬编码在配置里。而人在审查时如果只看逻辑不看细节很容易漏掉。我见过最离谱的一次是模型在生成数据库连接代码时把示例里的password: your_password_here直接留在了代码里而审查的人以为那只是个占位符没改就提交了。结果这个占位符被部署到了测试环境虽然测试环境的库是空的但这个习惯一旦养成迟早出事。防范措施有几条第一所有密钥必须走环境变量或密钥管理服务代码里不允许出现任何形式的硬编码。这条要写进Prompt的系统指令里让模型从一开始就不生成硬编码。第二提交前用工具扫描比如用gitleaks或类似的工具做pre-commit检查发现疑似密钥就阻断提交。第三审查清单里明确列出检查是否有硬编码敏感信息这一项人工审查时必须过一遍。5. 一套可复现的16万行代码生产流程5.1 阶段一架构与约定先行在写第一行代码之前先把这几件事做完。确定技术栈和目录结构。用什么语言、什么框架、什么数据库、什么部署方式这些定下来之后目录结构基本就确定了。比如一个典型的后端项目可能是src/controllers、src/services、src/models、src/utils、tests/这样的结构。编写约定文档。这份文档要覆盖命名规范变量、函数、类、文件、错误处理方式异常类型、错误码、日志格式、接口契约请求响应格式、状态码约定、依赖管理什么情况下允许引入新依赖。这份文档是后续所有Prompt的基础。定义接口契约。在生成具体实现之前先把模块之间的接口定下来。比如用户模块对外暴露哪些方法、每个方法的输入输出是什么、会抛出哪些异常。接口定好了各个模块就可以并行生成不用担心对不上。这一步看起来慢但它决定了后面能不能快。我自己的经验是架构和约定阶段花的时间大概占总时间的15%到20%但它能省下后面至少30%的返工时间。5.2 阶段二分模块生成与即时验证架构定好之后进入生成阶段。这个阶段的核心原则是小步快跑生成一块验证一块。具体做法是把项目拆成若干个模块每个模块再拆成若干个任务。每个任务对应一次或几次模型调用。每次调用时把相关的约定文档、接口定义、示例代码一起喂进去。生成完成后立即跑静态检查和单元测试通过了才进入下一个任务。这里有个关键细节示例代码的质量决定了生成代码的质量。如果你给模型的示例是混乱的、不一致的模型就会模仿这种混乱。所以每次生成新模块之前先确保已有的代码是干净的、符合约定的。模型会看着现有代码来生成新代码现有代码就是它的参照系。我一般会维护一个examples/目录里面放几个标准模块的完整实现作为模型生成时的参考。这几个标准模块是我手工打磨过的代表了项目里最好的写法。模型照着这个写出来的东西基本不会跑偏。5.3 阶段三批量重构与测试补齐当项目积累到一定规模会出现一些需要批量处理的任务。比如统一改某个接口的调用方式、给所有模块补测试、把某个旧模式替换成新模式。这些任务单靠人工做很枯燥靠脚本做又不够智能正好是Agent的用武之地。以给所有模块补测试为例。Agent的工作流程是扫描所有源文件识别出没有对应测试的模块逐个生成测试用例运行测试如果失败就分析原因并调整直到测试通过。这个过程可以完全自动化人只需要在最后审查一遍测试质量。但这里有个坑Agent生成的测试可能只覆盖正常路径不覆盖异常路径。所以我在Prompt里会明确要求必须包含至少一个异常路径的测试并且在审查时重点看异常处理部分。另外Agent可能会生成为了通过而通过的测试比如断言写得很宽松这种也要在审查时识别出来。5.4 阶段四人工审查与最终把关无论前面自动化程度多高最后一道关必须是人。人工审查的重点不是逐行看代码而是看这几件事关键业务逻辑是否正确、边界条件是否处理、错误处理是否合理、是否符合架构约定、是否有安全隐患。我一般会把审查分成两轮。第一轮是逻辑审查看代码在做什么是否符合需求。第二轮是质量审查看代码写得怎么样是否有更好的写法。两轮分开做比混在一起做效率高因为关注点不同切换成本低。审查时我会用一份清单确保不遗漏。清单大概长这样检查项关注点常见问题业务逻辑是否符合需求边界条件遗漏错误处理异常是否捕获吞异常、日志缺失安全是否有硬编码密钥密钥写死在代码里性能是否有明显低效N1查询、无索引查询一致性是否符合约定命名风格不统一测试覆盖是否充分只测正常路径这份清单不是摆设每次审查都过一遍能挡掉大部分低级问题。6. 实操中那些文档不会写的经验6.1 模型不是越强越好合适最重要很多人一上来就用最强的模型觉得贵有贵的道理。但实际上不同任务对模型能力的要求差别很大。生成一个简单的CRUD接口用中等模型就够了做复杂的架构设计或疑难bug排查才需要上最强模型。全部用最强模型成本会高得离谱而且速度慢。我的做法是按任务分级。简单任务生成模板代码、写简单测试、改命名用轻量模型中等任务实现业务逻辑、写复杂测试、做代码审查用中等模型复杂任务架构设计、疑难排查、跨模块重构用最强模型。这样搭配下来成本能降一半以上质量基本不受影响。6.2 Prompt要版本化管理Prompt不是写完就完了它需要迭代。每次发现生成质量不好就要回头改Prompt。但如果Prompt散落在各个地方改起来很乱。所以我把所有Prompt都放在一个目录里用版本管理工具管理每次修改都有记录。更重要的是Prompt要跟代码一起测试。我建了一个小的测试集里面是若干个输入-期望输出的样例。每次改完Prompt就跑一遍测试集看生成质量有没有下降。这跟单元测试的思路是一样的只不过测的是Prompt而不是代码。6.3 上下文组装是个技术活前面说过不能把整个代码库喂给模型。那每次该喂什么这是个需要设计的问题。我的做法是分三层第一层是固定层包括约定文档、接口定义、示例代码每次都带第二层是相关层根据当前任务检索相关的源文件动态组装第三层是任务层当前任务的具体描述和要求。这三层的比例大概是2:5:3。固定层保证一致性相关层提供上下文任务层明确目标。组装的时候要注意相关层的内容要按相关性排序最相关的放前面因为模型对开头的内容注意力更集中。6.4 别指望Agent一次跑对Agent跑多步任务时第一次就完全正确的概率很低。我的经验是第一次能跑对60%到70%就算不错了。剩下的30%到40%要么是中间某步出错要么是最终结果不符合预期。所以一定要有跑-看-调的循环不能跑一次就完事。我一般会让Agent跑完后输出一份执行报告包括做了哪些操作、每步的结果、遇到的问题、不确定的地方。这份报告是我判断下一步怎么调的依据。如果问题出在Prompt上就改Prompt如果出在工具上就修工具如果出在任务拆解上就重新拆。6.5 人的价值在于判断不在于敲键盘最后说一个心态上的转变。AI Coding普及之后工程师的核心价值不再是能写多少代码而是能做出多少正确的判断。判断架构该怎么设计、判断生成的代码能不能用、判断哪里需要人工介入、判断质量是否达标。这些判断模型替代不了。所以与其焦虑AI会不会取代我不如把精力放在提升判断力上。多读优秀的开源代码多思考架构设计的取舍多总结踩过的坑。这些积累才是AI时代真正的护城河。16万行代码跑出来跑的不是代码本身跑的是一套人和模型协作的流程。流程设计得好产出就高、质量就稳流程设计得差产出越多、麻烦越大。这个道理跟传统软件工程其实是一样的只不过现在多了一个叫LLM的强力工具以及围绕它的一整套Agent和Prompt工程实践。把工具用好把流程理顺把判断做对剩下的就是执行了。