企业官网建设流程全解析

上个月，我们组把 vibe coding 从"个人玩具"正式推到了生产环境。前期 Demo 阶段人人都说好用：丢一个需求进去，Agent 刷刷刷把代码写出来，测试一跑，绿了，大家欢呼。可一进生产代码库，画风突变——改了一个接口签名，它不知道同步修改调用方；说好的编码规范，它我行我素；明明只让改配置文件，它顺手把整个模块重构了一遍。生产级 Coding Agent 的"最后一公里"，不是把代码准确率从 99% 推到 99.9%，而是把"看起来在干活"变成"交付了能安心上线的代码"。

我想把这轮真实调优过程记录下来，不是讲概念，而是讲我们怎么从基线评估开始，把一次通过率从 32% 拉到 78%，越界修改率从 41% 压到 10% 上下。如果你也在搞 coding agent 落地，或者正被 AI 生成的代码弄得又爱又恨，这篇文章应该能让你少踩不少坑。

1. 什么是"最后一公里"——从 Demo 能跑到生产能交付之间的距离

1.1 你以为的 Vibe Coding 和实际生产要求之间的落差

Vibe coding 这个词相信大家都不陌生了。简单说，它就是你用自然语言描述意图，AI 帮你把代码写出来，你不断给它反馈"这里不对、那里改一下"，两个人像打乒乓球一样把功能磨出来。今年这一波命令行编码智能体彻底带火了它——只要体验过 Codex CLI 这类登录式命令行 Agent，你就会明白为什么大家说"一句命令就是一种全栈开发的感觉"。从 OpenAI 的 Codex 到各种开源的 PID coding agent，各家 vibe coding 工具链已经非常热闹，嵌入式 vibe coding、后端微服务、数据管道，哪里都能 vibe 一下。

但我们要正视一个词：生产级。Vibe coding 在个人项目里是完美的，因为没有人给你 review，没有人要求你兼容历史接口，也没有 KPI 盯着你线上事故率。可一旦落到生产代码库，标准就完全不同了。Demo 里能跑的代码，和生产里能交付的代码，中间隔着一条说长不长、说短不短的路，我姑且叫它"最后一公里"。

这"最后一公里"包含这么几件事：AI 生成的代码能不能通过编译这只是最基础的；它有没有遵守仓库里隐性的架构约定？改了一个接口，调用方怎么办？新增的依赖有没有引入兼容性风险？测试是不是为了凑覆盖率而写的假测试？这些才是生产环境的真实问题。一个 Agent 在 demo 仓库里像天才，在生产仓库里像刚入职还看不懂代码的实习生，这不是能力问题，是"它不知道的东西太多了"。

1.2 为什么 Coding Agent 在真实仓库里"翻车"：一个典型失败案例拆解

我举个我们踩过的真实例子，你能立刻理解"最后一公里"为什么难。

某次需求是给订单支付回调加超时重试。我们当时的 Agent 接到 prompt 后，很兴奋地写了一个崭新的RetryPolicy抽象类，还配了一个RetryExecutor。Review 的时候问题全冒出来了：仓库里已经有一个被全组用了两年的RetryTemplate，Agent 压根不知道；它新写的抽象类和现有类概念重叠，还改了订单回调入口的接口签名；更离谱的是，它顺手重构了回调模块里的 YAML 配置结构，理由是"顺便保持一致"。

这种翻车不是模型笨，而是典型的上下文盲区。真实仓库的体量不是一次 prompt 能装下的，Agent 看不到某个工具类在哪儿，看不到三个月前架构决策，看不到代码规范里写着"禁止在错误处理里静默吞掉异常"。你光靠一句"请你注意代码质量"是救不回来的。

我把这类问题归纳成四个根因：上下文漂移（它以为在写新代码，其实仓库里已有替代方案）、规则盲区（规范文件它没读或读了没执行）、依赖未知（跨模块改动牵一发动全身）、验证缺失（它不会自己编译，也不会主动跑测试）。后面所有调优动作，基本都在跟这四个根因搏斗。

1.3 目标设定：我们把"效果调优"定义为哪三个可量化指标

调优之前，我们先把"效果"这个词翻译成三个能吵架能对账的指标，否则后面全是感觉。

越界修改率这个指标很少人关注，但我觉得它是生产环境最要命的。一个 Agent 如果技术很强但总爱顺手改别人家代码，它在 review 阶段造成的心智负担，比它省下来的工作量还大。后面所有的调优，本质上都是围绕这三个指标展开的，任何改动如果只提升指标 A 却破坏了指标 C，我们都会重新评估。

2. 调优前的"体检"——给 Coding Agent 做一次端到端基线评估

2.1 建立评测集：从真实工单里抽样本而不是自己编题目

任何调优，第一步永远是先量出基线。我们做的第一件事，是从过去三个月的工单系统里抽了 36 个已交付需求，构成一个评测集。为什么不用自己编的样本？因为自己出题很容易出成"AI 的舒适区题"，你描述得越干净，Agent 答得越顺，但真实工单的描述永远是啰嗦、模糊、还夹着历史背景的。

我们按任务类型配比：bug 修复 40%、新功能开发 30%、重构 20%、测试补全 10%。每个样本不光有需求文字，还包含三个关键信息：关联的模块路径、期望产出的大致文件列表（从真实合入的提交记录里捞的）、以及验收标准。这样评测的时候，不只看 Agent 能不能写出代码，还要看它写的是不是我们"真正想要的那份代码"。

这里有个容易忽略的点：评测集一旦建立，就要当作"宪法"一样保护。AI 跑同一个评测集太多次会记住题目，后期分数虚高。我们的做法是每两周跑一次全集，每次跑完都对部分样本做变形处理——换一个入口描述、换一个边界条件，确保它不是靠背题拿分。

2.2 失败模式分类：不是所有 bad output 都一样

评测集跑完之后，我们不是只看一个通过率，而是把每一次失败都按模式做归类。不分类的失败数据是没法指导调优的——你只知道"低"，不知道"低在哪"。

这里分享我们当时用的失败模式分类表：

第一轮跑完，我们把所有失败样本按这 8 类打标。有个结果很扎心但也很有指导意义："上下文缺失"和"过度修改"加起来占了 61%，单纯"模型写不出代码"只占不到 10%。也就是说，大模型能力在偏中型生产仓库里基本够用，瓶颈在于它"知不知道该用哪些信息"、"有没有约束住自己的手"。

2.3 基线数据长什么样：我用一张表看清楚主要矛盾

打标完成后，基线数据长这样：

这张表直接告诉我们：别急着骂模型，也别急着换更强但更贵的模型。当时市面上确实有一些新模型，但我们预判纯靠换模型解决不了"上下文缺失"这类结构性问题——模型再聪明，它不知道仓库里有个RetryTemplate就是不知道。真正值得投入的是"上下文工程"和"约束工程"两条线，下面两章就是我们把这两条线从想法落到实践的全过程。

3. 让 Agent 读懂你的仓库——上下文工程是效果提升的最大杠杆

3.1 从"把整个 repo 塞进去"到"按图索骥"

第一个动手点，是 Agent 到底怎么获取仓库信息。

一开始我们图省事，直接把整个仓库路径告诉 Agent，让它自己去读。结果就是 token 爆炸，而且它真的会去读一些无关紧要的文件——谁让它是按关键词扫的呢。后来我们换成了"按图索骥"模式，效果差别非常大。

我们的做法是三层：第一层，在任务描述里显式给出"三组文件"：相关入口文件、需要参考的历史变更（用git log -- <path>找到相似改动的提交记录）、仓库里已有的同类实现。第二层，让 Agent 遇到不清楚的符号时，先用rg/grep搜全局引用，再用git log -S 'SymbolName' --oneline看这个符号的前世今生。第三层，启用代码索引服务，把调用关系喂给 Agent，而不是让它自己去猜函数之间的静态关系。

这一步最反直觉的收获是：给的上下文不是越多越好。我们试过把某个模块的全部源码一股脑塞进 prompt，结果一次通过率不升反降，因为 Agent 被 8000 行无关代码"带偏"了。生产场景下的上下文工程，核心是"精准投喂"，让它在关键文件上花注意力，而不是让它变成一台阅读理解机器。

3.2 规则文件怎么写才有效：AGENTS.md/项目规范文件的经验

上下文工程里性价比最高的一件事，是把仓库规范写成 Agent 能读的规则文件。

我们一开始把规范散在各处：架构文档在 wiki，代码规范在 README，提交规范在流水线配置里。Agent 根本不读。后来我们统一在仓库根目录建了一个AGENTS.md，并且按 Agent 实际会用到的程度组织内容。这是它早期版本的一段核心内容：

# AGENTS.md 你正在修改的仓库：order-service（Go 微服务） - 根目录：/services/order - 核心包：pkg/order（领域逻辑）、internal/adapter（基础设施） - 主入口：cmd/server/main.go 架构约束： 1. 领域逻辑只允许依赖 interface，禁止直接 import 具体 DB 实现 2. 新增对外接口必须走 internal/adapter，禁止在 handler 里写业务逻辑 3. 已存在的通用能力先复用 pkg/common（RetryTemplate、Logger、Metrics），不要新建同名抽象 4. 修改公共接口时必须先运行 grep 查询所有调用方，并在 PR 描述里列出影响面 编码规范（强制）： - 错误必须向外抛，禁止在非边界处吞掉 error - 日志使用 pkg/common/logger 的 Logger，禁止裸用 fmt.Println - 函数建议不超过 80 行，超过则拆解 - 所有参数校验集中在入口层校验 禁止事项： - 禁止修改数据库迁移文件（migrations/），这是 CI 单独管理的还原点 - 禁止扩大接口可见性（unexported 保持 unexported） - 禁止新增第三方依赖，除非在任务里明确授权

这份文件上线后，规范违反类问题直接下降了六成。经验就是规则要"具象"，要给出正例和反例，要指明路径，要写"禁止"而不是"请尽量"。还有一点：规则文件不能太长。我们第二版写了 200 行，结果 Agent 开始选择性忽略后半部分；后来压回 60 行以内，并把细分成模块级的短规则文件，效果反而更好。规则不是给人类看的说明书，是给模型划重点的记忆卡片，重点一旦太多，就等于没有重点。

3.3 依赖与接口感知：处理跨模块调用时最容易忽略的问题

如果说规则文件解决了"静态规范"，那么"动态调用关系"是另一个大头。

真实生产仓库里，改一个接口签名，调用方可能有 20 处。Agent 写代码时只盯着当前文件，一改完 API，编译期报错就是一大片。我们的解法是把它变成 Agent 的强制动作，而不是期望它自觉。

我们在系统提示词里加了一条硬性规则：修改任何公共函数、类型、接口时，必须分三步来——先运行grep -rn "函数名" --include="*.go" .列出全部调用方；接着评估每个调用方是否需要同步改动；最后在提交说明里附上"影响面清单"。这条规则看着简单，实际上把一次通过率从 32% 拉到了 51%，因为它逼着 Agent 在动手前先"看全局"。

这一步需要承认：Agent 本身没有"全局记忆"，它只有"检索能力"。你要做的不是让它记住整个仓库，而是给它一把尺子，让它每次动手前先量一遍。只要这个动作变成流程的一部分，跨模块事故就会大幅减少。

3.4 一个生产案例：从修改一个 API 引发的连锁失败中学到的事

讲一个完整的案例，看看这些动作是怎么串起来的。

当时需求是把退款接口的RefundRequest.Amount从string改成int64（按分存储），顺带处理历史兼容。第一版 Agent 收到 prompt 后，只改了types.go里的定义，调用了这个字段的 12 个地方全部爆红，编译直接失败。它甚至没意识到有 12 个调用方，因为这种跨模块的信息它看不见。

我们在评测集里把这个场景单独标记出来，然后针对这类任务设计了一套"两阶段提交"指令：

阶段一（分析）：不要写任何代码。先搜索 Amount 字段的全部引用点，列出： - 字段定义文件及行号 - 所有引用点及各自的使用方式（赋值、读取、类型转换） - 需要同步修改的文件清单 阶段二（实现）：基于阶段一的分析结果动手修改。 修改完成后，重新编译并运行相关单测，输出：变更文件列表、尚未处理的影响点、可能的兼容性风险。

这个模式推广到所有"涉及公共类型变更"的任务后，这类跨模块任务的通过率从 18% 涨到 62%。说白了，生产级调优的很多功夫，是在把"让 AI 一次想清楚"变成"让 AI 分阶段、边查证边实施"。

4. 提示词与指令调优：如何把"人话需求"翻译成"Agent 听得懂的工程任务"

4.1 需求拆解：把大而全的 prompt 拆成 任务+约束+验收 三段

很多人写 prompt 就是一整段流水账，Agent 也给你一整段流水账的输出。我们调优后发现，效果最稳定的 prompt 结构是固定的三段式：任务背景、硬性约束、验收标准。

这里给一个我们当时沉淀出来的通用模板，也是 bugfix 类任务的标准 prompt：

【任务背景】 线上工单 #482：当订单支付回调超时且已经重试 3 次后，系统仍然会重复发送退款通知。 - 根因初步定位在 pkg/notify/notifier.go 的 SendRefundNotice 方法，缺少对 retry 次数的检查 - 已确认仓库 pkg/common/retry.go 中的 RetryTemplate 承担重试逻辑 【硬性约束】 - 只允许修改 pkg/notify 目录下的文件，禁止改动支付状态机的任何代码 - 必须使用 pkg/common/retry.go 已有的 RetryTemplate，禁止新建 retry 抽象 - 错误处理遵循：外部边界打日志并返回 error，内部逻辑禁止吞错 - 不新增第三方依赖 【验收标准】 1. 新增单测覆盖"重试超过 3 次不再发送通知"的边界条件 2. go test ./pkg/notify/... 全部通过 3. 输出变更文件列表及影响模块 4. 若发现根因定位有误，先说明新的定位和依据，再动手

为什么三段式有效？因为 Agent 是概率模型，prompt 里的信息密度一旦失衡，它就会自己"猜重点"——你给了 200 字背景，它可能认为背景比约束重要。三段式本质上是把优先级事先排好：任务背景给它方向，硬性约束给它护栏，验收标准给它自检清单。

4.2 约束表达：文件路径、编码规范、禁止事项要具体到什么程度

约束这一块，我最想分享的是"具体到什么程度"的经验。

抽象的"代码质量要高"是没有信息量的，Agent 不知道你的标准。而"新增代码必须遵循以下 4 条"就有信息量得多。我们的排序经验是：路径约束大于行为约束大于风格约束。路径约束是最强的一种约束，你直接框定"只能改这些文件"，它想越界都难。行为约束次之，像"禁止修改迁移文件"这种能挡住很多事故。风格约束就是锦上添花，优先级最低。

但约束也不是越多越好。我们做过一轮测试，当单次任务的约束条件超过 5 条时，一次通过率开始明显下降。模型的注意力是有限的，你堆 10 条"必须"，它记不住、也执行不全，最后全都没守住。所以我们的做法是：全局性约束全部写进AGENTS.md让它在系统层面生效，任务级 prompt 只保留与本次需求强相关的 3-5 条。

还有个细节：禁止事项一定要放在正面任务之后。如果你一开始就说"不要这样做"，Agent 很容易惦记着禁忌词，反而容易触发。先讲要做什么，再讲不能做什么，成功率明显更高。这个小规律大家可以在自己的样本上验证，我实测下来非常稳定。

4.3 让 Agent 自检：强制生成"变更影响清单"的奇效

这一招是我个人认为整轮调优里性价比最高的：要求 Agent 在提交代码之前，先生成一份"变更影响清单"。

最开始我们只是觉得这能方便 review，后来发现它真正厉害的地方在于——它逼着 Agent 重新读了一遍自己的代码。Agent 在生成代码时是逐 token 推理的，它并不天然知道自己到底动了哪些文件。让它回头统计一次 diff，等于是强迫它"自省"。一旦它思考"我这个改动会影响 xx 模块吗"，很多隐藏问题就在这一步暴露了。

我们的模板要求输出以下几项：

变更影响清单（提交代码前必须填写）： - 本次修改的文件列表（含新增/修改/删除） - 每个文件的核心改动点，不超过 3 条 - 影响的模块或调用方（可运行 grep 验证） - 自测结果：编译是否通过、单测命令及输出 - 潜在风险（如涉及历史兼容、并发、性能）

加了这步之后，代码里"改了 A 忘了 B"类的失误少了非常多。review 阶段也能直接拿这份清单去对照 diff，省掉一半的审查时间。一份好的影响清单，其实比代码本身更能体现 Agent 有没有真正理解任务。

4.4 迭代技巧：我常用的 prompt 模板库如何沉淀

整个调优过程里，prompt 不是写一次就完事的，它需要像代码一样迭代和版本管理。

我们建了一个prompts/目录，按任务类型分四套模板：bugfix、feature、refactor、test。每次调优如果改了模板，必须更新模板文件最上面的版本号和变更说明。比如某次我们给 feature 模板加了"接口变更必须列影响面"这条，版本从v2升到v3，备注里写清楚改动原因和效果数据（通过率从 46% 涨到 53%）。

这套沉淀的价值有两个：一是新人接入成本低，不用从零琢磨怎么和 Agent 说话；二是我们调优时能对照版本历史判断，到底是模型升级带来的提升，还是 prompt 改动带来的提升。团队里如果几个人同时做 Agent 调优，prompt 库也天然成了协作载体——改 prompt 要像改代码一样 review，别一个人偷偷改完就说"效果变好了，你信我"。

5. 生产级护栏：不是让它写得快，而是让它错得少

5.1 门禁与审查：把 Agent 输出接入人工 review 的最小闭环

调优进行到中后期，我们意识到一件事：再调优，也不能让 Agent 直接合入生产代码。生产级的涵义是"责任有人担、风险有兜底"，所以 Agent 的输出必须走一套最小的门禁闭环。

我们执行的流程是这样的：任务在工单系统里登记 → Agent 按模板产出 PR（必须带影响清单）→ 流水线先跑静态检查、编译、单测 → 人工 review 重点核查影响清单与实际 diff 是否一致 → 通过后合入。整套流程里，人工 review 是不可省略的一环，但它的任务被大幅简化了：人不再需要从零看 diff，而是先看 Agent 声称的影响范围，再抽查它有没有偷偷改别的地方。

这套闭环对团队的另一个价值是，它给了大家一个"安全感受"。vibe coding 最让人不安的不可控感，恰恰是门禁解决的。只要知道 Agent 写的东西会经过 check、有影响清单可对照，团队就敢把越来越多的任务交过去。信任不是靠口号建立的，是靠流程建立的。

5.2 自动校验：编译/静态检查/测试用例在流水线中的强制顺序

门禁不能只有人，自动化校验的顺序也很讲究。

我们的流水线顺序是：lint（最快，几秒内出结果）→ 编译 → 单测 → 影响面回归。为什么 lint 放最前？因为它最便宜，能把格式类、静态检查类问题第一时间暴露，让 Agent 在最短时间得到反馈。如果你一上来就编译，编译失败的信息会淹没 lint 的提示，Agent 改完编译错误，下一轮才发现风格问题，来回折腾多一轮。

更重要的一点是：把 CI 的失败信息回传给 Agent。我们做了一个小工具，Agent 提交 PR 后，如果流水线失败，工具会自动把失败日志（哪一行编译报错、哪个测试断言失败）拼接成新的 prompt，让 Agent 自己修复再重新提交。这一步等于把"人来回打回"变成了"机器打回后 Agent 自行 debug"。加上自动反馈之后，一次修复率从 35% 涨到了 68%，效果非常显著。

你会发现，这里 Agent 的定位其实变成了"开着辅助驾驶但注意力还在方向盘上"——让它自己跑，但一旦偏离轨道，机器和人都有能力把它拉回来。

5.3 回归策略：如何防止调优 A 问题导致 B 问题回归

调优最大的隐形风险是顾此失彼。你为了压"过度修改"加了很强的路径约束，结果 Agent 放不开手脚，需求理解出问题了；你为了让 Agent 更谨慎，让它生成更多分析文本，结果它 token 消耗翻倍，偶尔还废话连篇把重点淹了。

我们应对回归问题的办法非常朴素：每次调优后，跑一遍基线评测集（那 36 个样本），对比三个指标的变化。调优 A 问题如果带来 B 指标下降超过 5 个百分点，这个改动就会被标记为"待验证"而不是直接采用。后面积累下来的，都是净收益为正的改动。

我们还会做小规模的 A/B：同一个任务样本，分别用 prompt v2 和 v3 跑，生成结果丢到评审群，让大家盲评。复盘时发现，人的主观感受往往和客观指标不一致——有人觉得 Agent "更聪明了"，实际上通过率没变化，只是它写出来的代码"看起来更专业"了。所以，感知归感知，数据归数据，两套系统要并行看，不要只凭感觉做决策。

5.4 安全边界：不让 Agent 碰哪些代码（权限与风险控制）

最后是安全边界，这条是我们坚持得最彻底的原则：Agent 的能力可以很强，但权限必须有边界。

具体做了三件事。第一，目录级权限：Agent 的开发环境只挂载它被授权的工作目录，密钥文件、生产配置、CI 脚本等目录直接不可见——不可见，就不存在"误改"问题。第二，命令黑名单：禁止它在沙箱里执行git push、生产环境操作、删除命令这类高危动作，这些操作一律回到人的手里。第三，变更分级：涉及数据库迁移、公共 API 签名、依赖升级的"高影响变更"，Agent 只允许产出方案和 diff，合入决定必须由人来拍板。

有同事问过我：这样限制，Agent 是不是就"没那么能打"了？我的回答是：生产环境要的不是最能打的 Agent，而是最不容易出事的 Agent。能力可以慢慢开放，信任是攒出来的，不是赌出来的。

6. 效果度量与持续优化：从"感觉变好了"到"数据证明变好了"

6.1 埋点与日志：记录 Agent 每次交互的关键信号

调优最后要回答的问题不是"你觉得它变好了吗"，而是"数据说它变好了吗"。所以我们给 Agent 的每次交互都建立了结构化日志。

我们记录的关键字段包括：任务类型（bugfix、feature、refactor、test）、任务所用上下文字符数、Agent 首轮耗时、是否触发自动修复、修复轮次、最终是否合入、人工 review 的评论条数、越界修改的文件数。这些字段存进一张表，每天自动汇总。

这份日志后来帮我们发现了很多直觉上看不出来的规律。比如：上下文越长，通过率不是单调上升的，在某个阈值之后就明显下降；再比如：同样是 bugfix 任务，带"根因定位"分析前置的任务，比直接让 Agent 改的任务，最终 review 评论数少 40%。没有日志，这些规律会永远停留在"感觉"层面，一旦有争论就谁也说服不了谁。

6.2 周报复盘：我们每周看哪几张表的实践

我们把数据聚合成了三张核心表，每周五下午固定过一遍。

第一张是一次通过率趋势图，按周看整体走向，掉头的地方一定对应某次调优或某个模型切换。第二张是失败模式占比表，用来判断当周调优重点：如果"上下文缺失"涨了，说明上一轮加的规则可能干扰了它的检索；如果"过度修改"涨了，说明约束松动。第三张是平均 diff 规模与 review 耗时表，越界修改率和人工负担都在这张表里体现。

这个周复盘的习惯坚持了两个月后，整个团队对 Agent 的认知完全变了。大家不再说"AI 写的代码不太行"这种空话，而是能明确指出"上下文缺失类的失败占比高，应该在任务模板里补充相似历史变更的参考"。之前是调优主导一切，后来变成了数据主导调优。这两者的区别，就是靠日志和复盘一点点磨出来的。

6.3 灰度推广：如何在团队里渐进上线而不引起反感

最后聊聊推广问题，这一步经常被忽略，但它比技术调优还难。

我们没有一上来就让全组都切到 Agent 工作流，而是选了一个正在从零开发的新模块作为试点。新模块没有历史包袱，Agent 出错的心理成本低，大家更愿意试。同时我们明确一条规则：Agent 产出的代码，人工 review 不能省。这既是在保质量，也是在告诉团队"我没有拿你们的线上稳定性开玩笑"。

第二个阶段，我们鼓励大家把"脏活累活"丢给 Agent——补单测、改注释、做格式化、迁移老配置。这些任务风险低、判定标准清晰，Agent 不容易翻车，团队能快速建立对它的信任。等大家发现"让它做这些破事确实好用"之后，再循序渐进地开放新功能开发和 bugfix 类任务。

还有一个体会：抵触情绪一般来自"被替代"的恐惧，而不是 Agent 本身。我们花了一个下午做了一次内部分享，把 Agent 当前的能力边界、失败案例、人工兜底的流程全部摊开讲清楚。结果发现，大家抵触的其实是"不确定性"，而不是"用 AI"。当你知道它的上限、下限和你在流程里的位置，合作就开始了。

最后再说一个我自己的土判断标准吧。调优到什么样算到位？我个人的体会是：当你把 Agent 写代码当成团队里一个刚转正、能力中上但偶尔有主见的同事时，你就已经跨过最后一公里了。它不需要无所不能，只需要可控、可预测、可追溯。我们跑了两个多月，最终把一次通过率稳定在 78% 左右，越界修改率压到 10% 上下，review 耗时不升反降。这个数字在绝对值上不算惊艳，但放在生产代码库的语境下，已经足够让团队愿意把更多任务交给它。如果你也要做类似的落地，我的建议是从评测集和失败分类开始，先把"感觉"翻译成"指标"，后面每一步都会踏实很多。