1. 16万行代码背后的真实工作量拆解先把一个概念摆正16万行代码不是一个“项目规模”的炫耀数字而是一个协作吞吐量的度量。我参与过的一个中型业务系统最终统计下来有效代码大约在15万到17万行之间浮动前后端加基础设施脚本全算上。这个量级放在今天单靠人肉手写一个十人团队按每人每天有效产出80到120行来算需要大约四到六个月还不算返工和联调。但实际交付周期被压缩到了七周左右这里面AI Coding承担了相当大比例的初稿生成和重复性改写。你要理解的第一件事是16万行不是一次性写出来的它是“生成—筛选—重构—沉淀”四步循环滚出来的。很多人对AI Coding的误解在于以为把需求丢给LLM它就能吐出可用的代码。真实情况是LLM产出的代码里大概只有30%到40%能直接进入主干剩下的要么逻辑有偏差要么边界条件缺失要么风格和现有代码库不兼容。所以真正的工作量不在“写”而在“审”和“改”。我拿一个具体模块举例。当时有一个数据同步任务需要从三个上游系统拉取数据做字段映射、清洗、去重再写入下游。纯手写的话这个模块大概800到1000行。用Agent辅助之后第一轮Prompt生成的代码大约1200行但里面有重复的异常处理逻辑、硬编码的字段映射表、以及一个明显的并发安全问题。经过三轮迭代修改最终稳定在950行左右。也就是说AI帮你省掉的是从0到0.6的过程从0.6到1的那段路还是得自己走。这里就引出一个关键认知AI Coding改变的不是代码的总行数而是单位行数的边际成本。以前写一行代码要思考语法、查文档、调试现在这些被压缩了但“判断这行代码该不该存在”的成本反而上升了。因为生成太快很容易堆出一堆看似能用实则冗余的代码。16万行里我估计至少有2万行是后期清理掉的“AI冗余”。1.1 为什么是16万行而不是6万行有人会问既然AI能生成为什么不把代码写得更精简答案在于业务复杂度不会因为工具变强而降低。16万行对应的是大约40个核心业务实体、120多个API端点、以及一套完整的权限和审计体系。这些代码量是由领域模型决定的不是由编写方式决定的。AI能帮你更快地铺开但铺开的面积还是那么大。另一个原因是防御性代码的比例在上升。LLM生成的代码往往对异常路径考虑不足所以人工补全的部分大量集中在参数校验、超时处理、重试逻辑、日志埋点上。这些代码不产生业务价值但缺了系统就不稳。我统计过在一个典型的AI辅助模块里防御性代码能占到总行数的35%左右比纯手写时代高了将近10个百分点。1.2 16万行代码的构成分布为了让你有个直观感受我把这个项目的代码按类型拆一下代码类型行数占比主要来源人工介入程度业务逻辑约42%Agent生成初稿人工重构高数据模型与ORM约15%LLM批量生成中API接口层约12%Prompt模板生成低测试代码约18%Agent自动生成人工补边界中配置与脚本约8%手写为主低工具函数与中间件约5%混合高这张表的核心信息是测试代码占了将近五分之一。这在纯手写时代是不可想象的因为没人愿意花那么多时间写测试。但Agent生成测试的成本极低所以测试覆盖率从原来的40%左右拉到了75%以上。这也是16万行里“含水量”最低的一部分。2. AI Engineering视角下的核心工具链选型聊完工作量得说说用什么工具把这16万行“跑”出来。这里我不讲具体品牌讲的是工具链的层次结构。一个完整的AI Coding工作流至少包含四层模型层、Agent层、Prompt层、以及工程集成层。每一层的选型逻辑都不一样。模型层是基础。你需要一个在代码任务上表现稳定的LLM。选型时不要只看benchmark分数要看它在长上下文下的指令遵循能力。我试过用同一个Prompt在不同模型上跑短上下文时差异不大但一旦把整个代码库的上下文塞进去有些模型就开始“忘记”前面的约束条件。所以模型层的关键指标是在8K到32K token的上下文窗口内能否稳定保持对编码规范的遵循。Agent层是调度中枢。Agent和LLM的区别在于LLM是“你问它答”Agent是“你给目标它自己拆步骤”。在16万行代码的项目里Agent主要承担三类任务批量生成CRUD代码、自动补全测试用例、以及跨文件的引用更新。Agent框架的选择要看它是否支持工具调用和状态管理。没有状态管理的Agent每轮对话都是重新开始效率极低。Prompt层是最容易被低估的。很多人觉得Prompt就是“把需求说清楚”但实际上在工程化场景下Prompt需要模板化、版本化、可测试。我维护了一套大约30个Prompt模板覆盖了从“生成数据模型”到“写集成测试”的常见场景。每个模板都有明确的输入变量和输出格式约束。这套模板的迭代次数比代码本身还多。工程集成层决定了AI产出能否顺畅进入现有流程。这里的关键是代码审查自动化。Agent生成的代码不能直接合入主干必须先过静态检查、格式校验、以及一轮人工Review。我把这个过程做成了一个流水线Agent提交PR自动触发lint和单元测试通过后再分配给人工审查。没有这层16万行代码会变成一团乱麻。2.1 Agent与LLM在编码任务中的分工边界这里要澄清一个常见混淆Agent和LLM不是替代关系是分工关系。LLM负责“生成内容”Agent负责“决定生成什么、什么时候生成、生成后怎么处理”。举个实际例子。我需要给一个订单模块添加“批量导出”功能。如果只用LLM我的操作是手动打开相关文件把上下文复制给LLM让它生成代码再手动粘贴回去。如果用Agent我的操作是告诉Agent“给订单模块添加批量导出导出格式为CSV需要包含分页”Agent会自动定位相关文件、读取现有代码风格、生成代码、运行测试、并在失败时自动重试。但Agent不是万能的。它在跨模块重构和复杂业务逻辑上仍然容易出错。我的经验是Agent适合处理“局部、明确、有先例”的任务LLM适合处理“需要创造力、需要解释、需要权衡”的任务。两者配合才能把16万行的吞吐量撑起来。2.2 Prompt Engineering在大型项目中的落地方式Prompt Engineering这个词被说烂了但在16万行代码的尺度上它的含义很具体把编码规范、架构约束、命名习惯全部编码进Prompt模板。我举一个真实的模板片段。在生成任何数据访问层代码时Prompt里会强制包含以下约束所有数据库操作必须使用参数化查询禁止字符串拼接查询结果必须映射到明确的DTO禁止返回原始Row对象分页查询必须包含总数统计且总数统计和明细查询必须在同一事务内异常必须包装为项目自定义的DataAccessException并保留原始cause这些约束不是写在文档里让人去记而是直接写进Prompt让LLM在生成时就必须遵守。实测下来这样做能把数据访问层的Review时间减少大约60%。因为大部分低级错误在生成阶段就被规避了。但Prompt不是越长越好。我踩过一个坑早期为了让LLM“充分理解”项目我把整个架构文档塞进Prompt结果LLM开始“过度设计”生成一堆项目里根本不存在的抽象层。后来我把Prompt长度控制在2000 token以内只保留最关键的约束和示例产出反而更稳定。Prompt的长度应该和任务的确定性成正比任务越确定Prompt越短任务越开放Prompt才需要更多上下文。3. 从需求到代码的完整实操流程这一部分讲具体怎么操作。我把16万行代码的生成过程拆成五个阶段每个阶段都有明确的输入、输出和验收标准。3.1 第一阶段领域建模与接口定义这个阶段几乎不用Agent主要靠人工加LLM辅助。核心任务是把业务需求翻译成数据模型和API契约。具体做法是先用自然语言写出核心实体和它们之间的关系然后让LLM帮你检查是否有遗漏的边界情况。比如我写“订单包含多个商品每个商品有数量和单价”LLM会提醒你“是否需要记录商品快照因为商品价格可能变动”。这种提醒很有价值能避免后期大改。这个阶段的产出是一份接口定义文件通常是OpenAPI规范或者TypeScript类型定义。这份文件是后续所有代码生成的“宪法”Agent和LLM都基于它来生成实现。接口定义的质量直接决定了后面16万行的返工率。我的经验是在这个阶段多花一天后面能省三天。3.2 第二阶段Agent批量生成骨架代码有了接口定义就可以让Agent批量生成骨架代码了。这里的“骨架”指的是Controller层、Service层、Repository层的空实现以及对应的DTO和异常类。操作方式是把接口定义文件拆成多个小片段每个片段对应一个模块然后逐个喂给Agent。不要一次性把整个接口定义丢进去那样Agent会“迷路”。我通常按业务域拆分每个业务域大约5到8个接口Agent一次处理一个业务域。生成出来的骨架代码需要人工过一遍主要检查三件事命名是否符合项目规范、依赖注入方式是否正确、异常处理是否统一。这三件事如果不在骨架阶段修正后面填充逻辑时会放大十倍。这个阶段的速度非常快。一个包含20个接口的业务域Agent大约15分钟能生成完骨架人工审查大约30分钟。纯手写的话同样的工作量需要两天。3.3 第三阶段Prompt驱动的逻辑填充骨架有了接下来是填充业务逻辑。这是最耗时的阶段也是LLM和Agent配合最紧密的阶段。我的做法是把每个Service方法拆成一个独立的Prompt任务。Prompt里包含方法签名、输入输出说明、业务规则、以及一个“参考实现”从项目里找一个类似的已完成方法作为示例。LLM基于这些信息生成方法体。这里有个关键技巧参考实现的选择比Prompt的措辞更重要。如果你给LLM的参考实现本身写得烂它生成的代码也会跟着烂。所以我通常会花时间挑选“模范代码”作为参考确保风格统一。生成出来的方法体不能直接用必须经过一轮逻辑审查。审查的重点是边界条件是否覆盖、事务边界是否正确、日志是否充分。我统计过大约有25%的方法体需要重写40%需要小改只有35%能直接通过。这个比例随着Prompt模板的成熟会逐渐改善但永远不会到100%。3.4 第四阶段测试代码的自动化生成测试代码是AI Coding最能发挥优势的地方。因为测试的逻辑相对固定给定输入断言输出。LLM非常擅长这种模式。我的流程是每完成一个Service方法立刻让Agent生成对应的单元测试。Agent会自动识别方法的参数类型、返回值类型、以及可能抛出的异常然后生成覆盖正常路径和异常路径的测试用例。但Agent生成的测试有一个通病断言太弱。它经常只断言“结果不为空”而不去检查具体的字段值。所以人工需要补强断言。我的做法是在Prompt里明确要求“每个断言必须检查至少三个具体字段”这样能显著提升测试的有效性。集成测试则更需要人工介入。因为集成测试涉及数据库、消息队列、外部服务Agent很难理解这些依赖的交互方式。我的做法是人工写好集成测试的骨架和关键断言让Agent补充数据准备和清理的代码。这样既能保证测试的有效性又能利用Agent的速度。3.5 第五阶段代码审查与重构沉淀最后一个阶段是把所有生成代码整合起来做一轮全局审查和重构。这个阶段基本不用Agent全靠人工加静态分析工具。审查的重点是跨模块的重复代码、不一致的命名、以及遗漏的异常处理。AI生成代码的一个典型问题是“局部正确但全局不一致”。比如A模块用findByIdB模块用getById功能一样但命名不同。这种问题在单个模块内看不出来只有全局扫描才能发现。重构的原则是能合并的合并能抽象的抽象但不能为了抽象而抽象。我见过一些团队用AI生成代码后又用AI去“优化”代码结果搞出一堆过度设计的抽象层。16万行代码里真正需要抽象的地方可能只有20%剩下的80%保持直白反而更好维护。4. 常见问题与排查技巧实录这一部分是我在实际操作中踩过的坑和总结的排查方法。AI Coding的坑和传统编码的坑不一样很多问题只有在规模化之后才会暴露。4.1 LLM返回结果不稳定的典型场景最常见的问题是同一个Prompt两次生成的结果差异很大。这在需要批量生成相似代码时特别致命。比如你要生成20个类似的Repository类结果发现有的用了注解有的用了XML配置有的干脆手写SQL。排查思路是先检查Prompt里是否有模糊表述。比如“使用合适的查询方式”就是模糊表述LLM每次理解都不一样。改成“使用JPA Criteria API构建查询”就稳定了。其次检查温度参数。代码生成任务建议把温度调到0.2以下牺牲一点多样性换取稳定性。还有一个隐蔽的原因是上下文污染。如果你在同一个会话里先让LLM生成了A模块的代码再让它生成B模块它可能会把A模块的风格带到B模块。解决办法是每个模块开一个新的会话或者在Prompt里明确重置上下文。4.2 Agent执行中断与错误恢复Agent在执行多步任务时经常会在中间某一步失败然后整个任务就挂掉了。比如Agent在生成代码后尝试运行测试测试失败Agent就不知道该怎么办了。我的处理方式是给Agent配置重试策略和降级策略。重试策略是如果测试失败让Agent分析失败原因并尝试修复最多重试三次。降级策略是如果三次都失败Agent把当前状态和失败原因记录下来转交人工处理而不是继续死循环。这里有个细节Agent的重试不能是简单的“再生成一遍”而应该是“基于失败信息重新生成”。所以Prompt里要包含上一次的失败日志。我试过让Agent在重试时带上错误堆栈修复成功率能从20%提升到55%左右。4.3 代码风格漂移的预防与修正AI生成代码最大的长期风险是风格漂移。项目初期大家还注意统一风格但随着生成量增加不同模块的风格会逐渐分化。有的模块用camelCase有的用snake_case有的用try-catch包裹一切有的完全不做异常处理。预防手段是在CI流水线里加风格检查。我用的是Checkstyle加自定义规则任何不符合项目规范的代码直接拒绝合入。同时在Prompt模板里嵌入风格示例让LLM在生成时就对齐风格。修正手段是定期做代码格式化。我每个月会跑一次全量格式化把漂移的风格拉回来。格式化工具建议用项目统一的配置不要依赖IDE的默认设置。4.4 常见问题速查表问题现象可能原因排查动作解决方式生成代码无法编译上下文缺失或版本不匹配检查Prompt中的依赖版本补充依赖声明重新生成测试通过但线上报错边界条件未覆盖检查测试用例的输入范围补充边界测试修复逻辑Agent反复重试同一错误错误信息未反馈给Agent检查Agent日志在重试Prompt中加入错误详情代码风格不一致Prompt未包含风格约束对比不同模块的生成结果统一Prompt模板加CI检查生成速度突然变慢上下文过长或API限流检查token用量和调用频率拆分任务增加间隔4.5 几个只有踩过才知道的实操心得第一个心得不要用AI生成核心算法。LLM在实现排序、加密、并发控制这类逻辑时经常写出“看起来对但实际有bug”的代码。这类代码必须人工写或者至少人工逐行审查。我试过让LLM写一个带超时的重试逻辑结果它把超时判断放在了重试之后完全反了。第二个心得保留生成记录。每次Agent生成的代码我都会把Prompt、生成结果、修改记录存下来。这样做有两个好处一是出问题时可以回溯二是可以分析哪些Prompt模板效果好哪些需要改进。这个记录本身就是一笔资产。第三个心得人工审查不能省。我见过一些团队为了追求速度让AI生成的代码直接上线结果出了一堆低级bug。AI Coding的正确姿势是“AI生成人负责”。审查的时间可能占整个流程的30%但这30%决定了另外70%是否有效。第四个心得从小模块开始试点。不要一上来就用AI生成整个项目。先选一个独立的、边界清晰的模块试水跑通整个流程积累经验后再扩大范围。我当初就是先拿一个配置管理模块试的只有500行代码但把Prompt模板、Agent配置、审查流程都跑了一遍后面才敢铺开到16万行。5. 规模化AI Coding的工程化建议当你从几千行扩展到十几万行时一些在小规模下不明显的问题会变成瓶颈。这一部分讲的是规模化之后的工程化应对。5.1 上下文管理策略LLM的上下文窗口是有限的而16万行代码远超任何模型的窗口大小。所以你必须决定每次生成时给LLM看多少代码。我的策略是“三层上下文”第一层是全局约束包括编码规范、架构原则、命名约定这部分每次都带大约500 token。第二层是模块上下文包括当前模块的接口定义和相邻模块的调用关系大约1500 token。第三层是局部上下文包括当前文件的已有代码和参考实现大约2000 token。三层加起来控制在4000 token以内。这样做的好处是LLM始终在“知道全局、了解局部”的状态下生成既不会跑偏也不会因为上下文过长而丢失重点。5.2 代码库索引与检索增强当代码库大到一定程度Agent需要能够“找到”相关代码。这就需要代码库索引。我用的是基于向量化的检索方案把代码库拆成函数级别的片段每个片段生成一个向量存进向量数据库。Agent在生成代码前先检索最相关的片段作为上下文。这个方案的关键是检索的准确性。如果检索出来的片段不相关反而会干扰LLM。所以我加了重排序步骤先检索出20个候选片段再用一个轻量模型重排序选出最相关的5个。实测下来这样能把生成代码的首次通过率提升大约15%。5.3 质量门禁与自动化验收规模化之后人工审查会成为瓶颈。所以必须建立自动化质量门禁。我的门禁包含四层第一层是编译检查第二层是静态分析第三层是单元测试第四层是集成测试。任何一层不通过代码就不能合入。这四层门禁里静态分析最重要。因为AI生成的代码经常有“能跑但不好”的问题比如未使用的变量、过长的函数、重复的代码块。静态分析能在人工审查之前把这些低级问题过滤掉让人工专注于逻辑正确性。5.4 团队协作与规范统一AI Coding不是一个人的事。当团队里每个人都在用AI生成代码时规范的统一就变得至关重要。我的做法是把Prompt模板、代码规范、审查清单全部纳入版本控制任何人修改都要走PR流程。这样能保证所有人的生成行为是一致的。另外我建议定期做Prompt Review。就像代码Review一样把大家用的Prompt拿出来互相看找出模糊的、有歧义的、效果不好的表述统一改进。这个习惯能让整个团队的AI Coding效率持续提升。6. 关于16万行代码的一些个人体会最后说几句实在的。16万行代码这个数字本身没有意义有意义的是它背后的工程能力。AI Coding把编码的门槛降低了但把工程的门槛提高了。以前你只需要会写代码现在你需要会设计Prompt、会配置Agent、会建立质量门禁、会管理上下文。这些能力在传统编码时代也存在但没这么突出。我最大的体会是AI Coding不会让代码质量自动下降但会让质量差的人暴露得更快。因为生成速度快问题积累得也快。如果你没有一套严格的审查和验收机制16万行代码会在两周内变成一团乱麻。但如果你有这套机制AI Coding就是实实在在的杠杆能把交付速度提升两到三倍。还有一个体会是关于学习曲线的。我刚开始用AI生成代码时觉得效率提升不明显因为大部分时间花在修改生成结果上。但用了大约两个月后Prompt模板成熟了审查流程顺了效率才开始显现。所以如果你刚开始尝试不要因为前期的低效就放弃。这个工具需要时间磨合磨合好了回报很大。至于后续怎么扩展我的建议是先把当前项目的Prompt模板和审查流程沉淀成文档然后在新项目里复用。不要每次都从零开始。另外可以尝试把一些重复性最高的模块做成“生成流水线”从接口定义到测试代码全自动跑通人工只做最终验收。这样能把AI Coding的杠杆效应再放大一层。
