Vibe Coding 这个概念火起来之后我周围不少同事都玩得很嗨。拿着一个需求描述往对话里一贴Agent 唰唰唰把代码给你生成出来跑通 Demo 那叫一个爽。但这种快乐基本止步于个人项目和原型验证。一旦进入生产环境尤其是华为这种代码规范严格、依赖关系复杂、历史包袱沉重的仓库里Coding Agent 的表现经常让人血压升高。网上那堆教程教你怎么写 prompt、怎么选模型但真正最后一公里的工程化调优——怎么让 Agent 在真实业务代码里稳定产出可合入的代码——极少有人系统聊过。这篇文章我结合自己在华为生态里做代码库改造和 Agent 落地的实操经历把这层窗户纸捅破。适合那些已经玩过 Vibe Coding想在团队或公司层面把 Coding Agent 真正用起来但被效果不稳定、Review 成本高、Agent 频繁幻觉折磨的人。我会从生产级代码库的特殊性、需求拆解方式、上下文工程、验证闭环这几个维度展开全部是踩过坑之后沉淀下来的东西。1. 生产环境的最后一公里到底卡在哪——不是模型不行是使用方式不行很多人觉得 Agent 效果差是模型智力不够换更强的大模型就行。但我在华为的代码仓库里实测下来模型能力只是底座真正的瓶颈在三个地方上下文利用效率、任务边界清晰度、验证闭环完整度。这三个问题不解决换再强的模型都白搭。1.1 个人项目与生产代码库的隐性差异先看一张我整理过的对比表这是我在多个项目里总结出来的实感差异维度个人项目 / Demo华为生产级代码库代码规模几百到几千行百万行起步跨多个子系统依赖关系简单、线性网状依赖存在循环依赖和隐藏约束编码规范几乎没有CI 强制检查命名、注释、异常处理都有清单历史沉淀短少技术债多年演进存在大量为什么这么写的隐性知识验证手段本地跑通即可单测、静态扫描、构建、回归测试层层把关错误容忍度高能改极低一行错误代码可能引发线上事故个人项目里Agent 生成个函数逻辑正确你就算完事。但生产环境里函数对了不代表能合入。命名风格是否符合现有模块惯例、异常分支是否覆盖完整、性能是不是在可接受范围、有没有修改到别人正在维护的边界——这些因素没有一个会被大模型自动关心。1.2 华为场景下的特有挑战规范与历史约束华为代码库有几个特别考验 Agent 的点。一是审查极其严格不只是格式化层面包括注释的完整度、防御式编程的落实程度、不同模块的专属规则比如通信设备里的可靠性要求、终端里的功耗约束。二是老代码的历史味道很多模块最初的设计决策已经没人记得了只存在于代码注释的只言片语和老员工的脑子里。三是多语言混杂C/C、Java、Python、JavaScript 甚至脚本语言混合调用Agent 很容易在跨语言边界上出岔子。我举个具体例子。有一次我让 Agent 修改一段底层 C 模块的日志打印逻辑它非常贴心地做了两件事把日志级别从 ERROR 调成了 INFO顺手把一个变量名重命名成了更现代的风格。单看代码没问题但在生产环境里前者会直接刷爆日志存储后者会让团队其他人基于旧变量名写的脚本全部失效。这种事在个人项目里根本不会发生但它就是生产环境 Vibe Coding 的日常。所以说最后一公里的问题本质上是如何让 Agent 在不确定的、充满历史约束的环境中只改该改的不改不该改的。这需要一套方法论来兜底。2. 需求拆解是效果调优的第一战场——把Vibe翻译成任务清单Vibe Coding 的英文原意里带着一股随性凭感觉写代码。这个感觉在个人项目里没问题但生产环境对感觉零容忍。你没法跟 Agent 说大概就是把这个功能优化一下它给你返回的也只能是一堆大概能用的代码。我调优的第一步是把 Vibe 翻译成结构化任务描述。2.1 为什么大模型需要任务工程而不是提示词技巧提示词工程聚焦于怎么把话说清楚任务工程的核心是把一件模糊的事拆成一系列边界明确的子任务每个子任务有独立的验收标准。我在实际使用中发现后者的效率提升是碾压级的。原因很容易理解大模型的注意力是有限的你给它一个模糊的全局目标它会把注意力分散到所有可能的方向但你给它五个具体的、按顺序执行的子任务它能逐点突破每个点都能做得更精准。一个对比就能说明问题。之前有同事直接把 JIRA 上的需求描述粘贴给 Agent修复登录模块的并发问题。结果 Agent 输出了一堆看起来合理的代码有的改了状态管理有的改了数据库连接有的改了前端超时设置横跨四五个文件但没有一个真正解决了并发导致的重复提交问题。为什么因为 Agent 根本不知道你说的并发问题具体指什么现象它只能猜测。2.2 我常用的任务描述模板与拆分实例经过反复试错我现在固定用下面这个结构来给 Agent 派活目标一句话描述最终要达成的状态可验证背景这段代码所在模块的业务含义哪怕是三句话也极其关键边界明确哪些不能动文件列表、函数范围、依赖版本交付物清单具体要产出哪些文件层面的改动验收标准列出你会在 Review 时检查的关键点拿一个真实案例拆解。我需要在某个网管系统里增加一个设备使能状态的缓存刷新接口。如果直接丢给 Agent它很可能给出一个全新的大方案设计一个新缓存框架。但我按任务工程拆完后它是这样工作的目标新增一个 REST 接口 /v1/device/refresh触发指定设备缓存条目刷新。 背景device_cache 模块已有 15 年历史原设计是懒加载 定时刷新无主动刷新机制。 现在因为设备状态变更频繁网管侧需要主动失效缓存。 边界 - 只允许修改 device_api.py 和 device_cache.py - 不得改动已存在的 CacheEntry 数据结构 - 不得引入新的第三方依赖 交付物清单 1. device_api.py 新增一个 POST 接口 2. device_cache.py 新增 refresh_cache_for(device_id) 函数复用现有的 _load_from_database() 3. 在接口层增加权限校验复用 getUserRole() 方法 4. 为 refresh_cache_for 添加两个单元测试用例 验收标准 - 接口只允许 POST非 POST 请求返回 405 - refresh_cache_for 对不存在的 device_id 不抛异常记录 warning 日志 - 单测能覆盖缓存存在时更新和缓存不存在时回源两个分支 - 所有新增函数必须包含 docstring 和参数说明这套描述扔进去之后Agent 产出的第一版代码Review 通过率直接从原来的 20% 飙到了 60% 以上。剩下的 40% 主要是细节偏差但不再是方向性错误。这个体验差异你自己跑一次就能感受到。2.3 任务拆解粒度太大失控太小低效拆分粒度也是个需要摸索的东西。我试过把一整块功能涉及十几个文件一次性交给 Agent结果是它在文件 A 里改得好好的到了文件 E 就开始放飞自我把前面的逻辑假设全忘了。我也试过把一个极其简单的函数重命名拆成单独一个任务结果发现 Agent 来回上下文切换的时间浪费严重而且容易因为缺少全局视角而破坏调用关系。我的经验值是一个任务涉及的文件数量控制在 2~5 个之间任务描述里必须包含一个全局性的导引信息比如本任务所涉及的模块在整个系统中的位置是 X主要负责 Y。这样 Agent 既不会因为范围太大而注意力涣散也不会因为视野太窄而失去上下文。像上面那个例子我只拆了两个文件但背景信息里给了模块的历史沿革和位置说明效果比把一堆小任务分开给 Agent 要好得多。3. 仓库级上下文工程——让 Agent 真正看得懂老代码的潜规则如果说任务拆解解决的是做什么的问题上下文工程解决的就是在什么约束下做的问题。生产级代码库里约束条件比逻辑本身还重要。同一个功能放在新项目和放在华为这种十几年的老仓库里写法可能完全不同。Agent 如果不理解这些约束聪明反而成为最大的风险。3.1 一次聪明反被聪明误的典型案例我印象最深的一次翻车是让 Agent 优化一段网络协议解析代码的异常处理。这段代码在传统 C 语言里用的是笨重的 if-else 错误码检查现代程序员看了都想重构。Agent 一上来就给人家用异常机制重写了一遍还贴心得补上了 RAII 资源管理。逻辑上完全正确甚至可以说优雅。但我把这段代码贴在评审群里被一个老专家劈头盖脸批评了一顿这个模块运行在资源受限的嵌入式环境异常机制的 code size 会膨胀实时性指标会掉而且整个团队都习惯了用错误码的方式排查问题。这就是典型的没有读懂历史约束的案例。Agent 的能力越强它越倾向用最新潮的方式解决问题但生产代码库往往需要的是在旧框架内小幅演进。避免这种翻车靠的不是换更强的模型而是喂正确的上下文。3.2 上下文分层注入先导文档、风格锚点、负面约束我摸索出一套三层上下文方法效果稳定第一层先导文档概览信息。不要只把目标代码文件贴给 Agent还要给它所在模块的说明文档、架构文档片段、甚至 CHANGELOG。目的不是让它读完整本百科全书而是让它建立这个模块经历过什么、有哪些变化趋势的认知。我实测发现给 Agent 看近一年的 CHANGELOG 能显著降低重造轮子的行为——它会发现这个功能可能以前做过或者有类似实现可以参考。第二层风格锚点风格锚定。生产代码最大的特征是有既有风格。这比规范文档更细比如错误是返回错误码还是抛异常、结构体命名带不带下划线、函数注释用哪种格式、日志用哪个级别的频率。我在任务里会直接贴一段现有的同类代码作为参考样式然后告诉 Agent请在风格上严格对齐这个文件里已存在的代码不要自创风格。这一招非常管用Agent 在模仿范例时的一致性表现远远好过它理解抽象规范时的表现。第三层负面约束边界声明。这一步最容易被忽视。我通常给 Agent 做三件事明确不要重构即使你发现了潜在问题也不要顺手修改。明确不要扩展只处理描述的任务不要给旁边发现的 bug 打补丁。明确不要假设如果遇到你没有十足把握的依赖关系请在代码里加 TODO 注释并描述问题而不是替你做一个决定。这层约束我放在 prompt 的最后一段离任务越近的位置权重越高实践证明对抗过度自信效果很好。3.3 上下文篇幅的平衡信息太多反而稀释注意力这里有个反直觉的发现上下文不是给得越多越好。我有段时间觉得既然 Agent 上下文窗口大128K 甚至更大那就把整个仓库的关键文档全扔给它吧让它自己找。结果效果很差它经常被无关信息带偏甚至开始引用那个模块文档里的废案。后来我稳定在一个 够用就好 的策略核心文件相关代码片段 模块级 README 或架构说明 风格参考片段 负面约束全部加起来控制在几千 token 以内。窗口再大也不该浪费在可能有用的信息上而应该聚焦在确定有用的信息上。对了如果代码库特别大直接贴文件全文也是个坑。Agent 很容易被长文件里的 90% 无关逻辑干扰在剩下的 10% 上出错。这时候我建议你手动截取相关函数和它周边调用的函数片段再配上一句这段代码是从文件中截取的上下文已经在任务描述里给出。这个小小的人工裁剪动作效果好得出奇。4. 验证闭环把 Agent 的输出当需要质疑的提案而不是可用的答案前面解决了让它做对的问题这一步要解决的是别信它。Coding Agent 最大的风险不是能力不足而是你的信任惯性。我自己吃过这个亏后来总结出来一套固定的验证闭环流程现在每个 Agent 生成的任务都会走这条路。4.1 测试先行在任务描述里逼Agent 自带验证方案我在任务拆解阶段就要求 Agent 输出测试用例作为交付物并且明确要求先写测试再写实现。这个策略的根本逻辑是如果 Agent 能写出测试证明它真的理解需求如果写不出来说明它在凭感觉生成代码。有了测试用例验证闭环就有一个客观的锚点而不只是靠肉眼 Review。具体操作上我会在 prompt 里明确要求为每个新增函数写单元测试覆盖正常路径和两个异常路径。测试风格与仓库中现有测试风格保持一致参考 xxx 测试文件。如果某个分支逻辑无法测试需要用注释解释原因。当 Agent 给你输出一段代码加一堆测试时你的 Review 重点就从代码对不对变成了测试测的是什么。这比空对空看代码容易得多而且效率高得多。4.2 静态扫描与构建验证让工具链当裁判代码出来后不管看哪一行多顺眼都必须过一遍仓库的静态扫描和构建流程。华为体系的代码规范检查非常严格从命名、缩进到注释格式、异常处理都有硬性门槛。Agent 生成 100 行代码大概率有十几行不合规。你与其自己在 Review 里一个个找不如直接甩给 CI 跑一遍让违规清单告诉你改哪里。这也让我养成了一个习惯不在 Editor 里跟 Agent 的输出纠缠先把输出推到验证环境里用工具链的输出作为第一轮的评审意见。这里有一个容易被忽视的点让 Agent 自己解释它写的代码。我每次拿回 Agent 的输出会要求它把代码里的核心函数逐一解释一遍请解释你新增的 refresh_cache_for 的参数、返回值和异常处理策略。这个做法的价值在于它能强迫 Agent 重新审视自己的逻辑同时给你提供一个判断它到底有没有想清楚的接口。很多逻辑漏洞在解释环节会暴露因为它在试图自圆其说时会发现本来就说不圆。4.3 错误定位与回滚预案Agent 出 Bug 时的处理套路Agent 写的代码合入之后出了 Bug这个场景无法完全避免但可以提前做好准备。我在生产环境里用的套路是每次 Agent 的改动不管多小都必须独立成一条提交记录commit message 里带明显前缀比如[agent]。这看起来是小事但一旦出问题你能瞬间定位到哪个提交是 Agent 产生的不用在一堆手工提交里翻。代码里凡是 Agent不敢确定的地方我让它写清楚的 TODO 注释。这些 TODO 是最好的后续跟踪点如果一段 Agent 代码里一个 TODO 都没有我可以基本判断它对自己写的每行都有信心——但结论往往不是它真的那么强而是它在假装知道。有 TODO 反而是健康信号。还有一次印象深刻的排查Agent 给一个数据处理模块加了缓存后线上出现偶发数据不一致。我第一反应是缓存失效逻辑有问题结果追了半天发现是它顺手改了排序算法的稳定性把一个稳定排序换成了不稳定排序。修的过程其实不难难就难在你心里要有根弦Agent 的改动范围再小也要假设它可能在你看不见的地方动了手脚。有了这个心理预期排查链路自然就清晰了。5. 组织配套与灰度落地——把个人技巧升级成团队产能Vibe Coding 调优做到最后你会发现单点的 prompt 技巧和上下文管理只是基础。真正要让大家都能稳定用起来需要解决工程管理层面的配套问题。我在团队里推行这套方法时踩了不少坑这里挑几个核心经验分享。这一节的方法不含代码但非常重要。5.1 代码评审模式要变从审代码到审变更意图传统代码评审里你盯的是这段代码有没有问题。但 Agent 参与的生产力场景下最重要的是评审Agent 是否忠实执行了变更意图。我把评审流程拆成了四步先看任务描述评审人先读原来的任务描述搞清楚需求到底是什么。只看 diff不看全文件避免被 Agent 写的无关风格改动分散注意力。检查超出范围的改动凡是 diff 里出现了任务描述里没有涉及的文件或函数全部打回。这是 Agent 最常犯的错。抽查测试用例与实现逻辑的一致性确保测试不是花架子。这个流程改动看起来很简单但团队执行起来之后Review 效率提高得非常明显。原因在于它把评审的重心从代码质量转移到了变更意图的一致性上而 Agent 产物的一切问题本质上都源于意图漂移。5.2 Prompt 资产的沉淀把调优经验变成可复用的模板我一开始把调好的 prompt 存在个人笔记里后来发现团队成员各有各的写法质量参差不齐。后来我们建立了一个轻量级的Prompt 资产库维护两类东西任务描述模板按场景分类新增接口、修复 bug、重构函数、补充测试每个模板都包含目标、背景、边界、交付物、验收标准五个部分且每个部分都有填充示例。领域约束清单把华为系代码里常见的坑写进去比如不可重入的函数不要加异步、嵌入式环境不要引入异常机制、跨模块调用前必须确认接口文档。这些约束会作为任务描述的领域前缀让 Agent 在生成代码之前先读到。这个资产库运行了几个月后团队里新人对 Agent 产物的 Review 通过率从最初的不到 30% 稳定在了 70% 左右。所谓效果调优最后沉淀下来的一定是流程和模板而不是玄学灵感。5.3 灰度策略从低风险模块起步逐步扩大战线最后两条关于落地的建议。一是不要在核心业务模块上第一天就全面铺开 Agent你会在 Review 和返工中耗尽信心。我建议从三类低风险场景起步独立的工具函数、纯新增的接口不修改现有逻辑、文档和测试代码的生成。这几个场景即使 Agent 出错损失也可控。等团队在这个小舞台上摸清了 Agent 的脾气和调优套路再逐步扩大范围。二是给 Agent 改代码设定必选项。比如必须在生成代码前先输出它对任务理解的摘要以及列出它计划修改的文件列表。这个先给计划、后给代码的做法能挡住一大批不靠谱输出——因为 Agent 在给出计划的时候你就能看出它有没有读懂需求不用等它写完全部代码再发现方向错了。这个技巧我用了几百次几乎是最有效的一个拦截手段。把整个调优过程拉通来看Vibe Coding 在生产级的落地没有任何魔法可言。它是一套关于约束、拆解、验证、管理的工程方法。模型能力会继续涨上下文窗口会继续扩但这些方法论会始终有效。因为生产级代码库的复杂性不会消失它只会从靠人肉记忆消化逐步转变成靠工程体系与 Agent 协同消化。最后分享一个我自己的体会不要追求 Agent 一次生成就能直接合入。那不是效率那是运气。真正的效率来自你建好了一套让 Agent 快速迭代、快速纠错的系统和心态。每次 Agent 的输出不完美时别急着否定它能力回到任务描述和上下文工程里找原因——九成情况下是你自己的输入设计有问题。