企业官网建设流程全解析

1. 这个标题背后到底在说什么——70% PR 的真相拆解

看到"Uber 工程师不动手，Agent 接管了 70% 的代码 PR"这个标题，我先泼一盆冷水：这不是说 Uber 把工程师都裁了，让 AI 全自动写代码。真实情况是，Uber 内部把大量的代码变更（PR，Pull Request）从"工程师手动编写"转移到了"Agent 辅助生成 + 工程师负责评审合并"的模式。说白了，写代码的人从"打字员"变成了"审查员"，而 Agent 承担了繁琐的样板代码、测试补充、依赖升级、代码重构这类体力活。

这个方向其实代表了当下 AI Agent 开发的一个典型落地场景：不是让 AI 在 IDE 里给你补全下一行代码，而是让 Agent 独立接到一个任务，自己读代码库、自己写实现、自己跑测试、自己生成 PR，最后把人类叫过来做 code review。你会发现，这对工程效能的影响远超"AI 帮我写了个函数"这种层面，它改变的是一条完整的交付流水线。

先说清楚几个关键概念，避免小白看懵：

• Agent（智能体）：一个能自主理解任务、拆解步骤、调用工具（读文件、执行命令、调 API）并完成目标的程序。在这里特指"编码 Agent"，比如 Uber 自研的、或者基于开源框架套了一层内部工具链的那种。
• PR（Pull Request）：代码仓库里最常见的协作单元。你写完代码，发起一个 PR，请求把你的分支合并进主干分支，同时附上描述、测试结果、关联 issue 等。
• 70% 的接管比例：Uber 内部某个业务线或平台组里，每 10 个 PR 中大约有 7 个是 Agent 起了主导作用——要么是 Agent 独立完成全部改动，要么是 Agent 完成任务后人类做了小幅修改。

我知道很多人关心的是：这事儿靠谱吗？代码质量会崩吗？我会不会被取代？别急，这篇我会把 Agent 驱动 PR 的设计思路、实操流程、踩坑经验全部拆开聊。不管你是团队技术负责人、后端工程师，还是正在学 Agent 开发的人，这篇文章都能让你弄明白"Agent 写代码 PR"这件事到底怎么落地，以及它现在能做什么、不能做什么。

在往下深入之前，我还想强调一句：70% 这个数字不是靠一个花哨的 Demo 刷出来的，它背后是一整套工程基建的支撑——任务拆分规范、代码库上下文注入、自动化测试闸门、评审界面优化、回滚机制。任何一个环节掉链子，这个比例都会瞬间掉到 10% 以下。所以接下来的内容，重点不是"AI 有多强"，而是"工程系统怎么把 AI 的产出接住"。

2. Agent 自动写代码的核心设计思路

2.1 从需求到分支：任务拆解是第一步，也是最重要的一步

很多团队尝试让 Agent 写代码，第一反应是"把 issue 丢给它，让它自己发挥"。这是一个典型的坑。你给 Agent 一个模糊的 issue 描述，它大概率会给你一个看似合理但完全跑不通的 PR，或者更糟——擅自改了不该改的逻辑，悄悄塞进一些无关重构。

Uber 这类工程团队的做法是，把任务拆解作为一个独立且严肃的工程步骤来对待。系统层面，Issue 模板会强制要求包含以下字段：期望行为、当前行为、复现步骤、涉及模块、改动范围、测试计划。这些信息不是说给人类看的，而是直接喂给 Agent，成为它生成 PR 的"翻译上下文"。

具体的拆解流程，我用自己的实战经验给你拆一下：

1. 确认变更类型：是修 bug、加功能、重构，还是依赖升级？不同类型对应的评估标准和测试策略完全不同。比如修 bug 的核心是加回归测试，依赖升级的核心是兼容性扫描。
2. 划定文件范围：一个合格的 Agent 任务，不仅要说清楚"改什么"，还要说清楚"不改什么"。比如"只修改 payment-service 模块下与退款逻辑相关的代码，禁止触碰用户鉴权相关文件"，这种边界约束能极大减少 Agent 误操作的概率。
3. 明确成功标准：写清楚哪些测试必须通过、哪些 lint 规则必须满足、性能指标不能劣化多少。没有成功标准的任务，Agent 就会自己定义"成功"，那基本上是灾难。

这里有个容易忽略的细节：Agent 不是人，它不会因为"顺手"就只改一点点，它可能因为上下文窗口里恰好有一块相关代码，就顺手把那个文件也重构了。我在实践中发现，反复强调"做最小必要改动"比任何模型技巧都管用。甚至在system prompt里写死一条："你只允许修改与任务直接相关的文件，任何额外修改必须在PR描述中单独列出理由，并等待人工审批。"这条规则帮我挡住了至少一半的无意义 diff。

任务拆解完以后，Agent 需要把自然语言任务转成具体的实现计划。我在自己的 Agent 框架里会让它先输出一个"实施计划"（planned steps），而不是直接出代码。比如任务说明是"修复用户积分在并发场景下重复叠加的问题"，Agent 的计划可以是：

• 阅读积分服务现有实现，确认 Redis 锁或数据库唯一约束是否已被使用
• 分析积分变更的调用链，定位积分叠加的入口方法
• 修改方法，添加分布式锁或引入版本号乐观锁
• 补充对应单元测试，模拟并发请求场景
• 运行相关模块全部测试用例，确认无回归
• 发起 PR，附上问题根因分析和测试结果

这个计划本身就是极好的 review 材料，人类工程师不需要一行行看 diff，先看计划就能判断方向对不对。这比直接读 Agent 写的代码高效得多。

2.2 从自然语言到可用代码：Agent 的"读-想-写-测"循环

任务拆解完成后，Agent 就进入了核心编码循环。这一节我讲清楚它具体是怎么执行的，以及每一步背后的原理。

第一步：读代码库，建立上下文。Agent 会使用代码检索工具（比如grep,tree-sitter,RAG检索）找到与任务相关的文件。在 Uber 这种级别的代码库里，不可能把整个仓库都塞进上下文，工程上一般有两种策略：一是通过构建索引，把关键模块的摘要和入口文件预检索出来；二是让 Agent 自己做"广度优先浏览"，先看目录结构，再定位到相关文件，最后精读具体实现。

我自己的经验是：与其让 Agent 盲目找，不如在任务描述里直接给出"可能相关的文件路径列表"作为提示。人类工程师拆任务的时候本来就带着对代码库的理解，为什么要把这份理解浪费掉？把这些路径给 Agent，它能少走大量弯路，而且生成的代码风格会和现有模块保持一致。

第二步：生成多个候选方案，而不是只给一个。资深工程师写代码很少一上来就是最终版，通常会先想两三种实现路径，评估复杂度、可维护性、和现有架构的契合度。Agent 也应该这么干。我在实践中会让 Agent 先用一个草稿区块写出 2 到 3 个可选方案，简述每个方案的优缺点和推荐项。这个做法的额外好处，是给人类评审员提供了决策依据——万一我的方案落地后发现实际问题比 Agent 预判得更糟，至少我们还有一个备选方案可以参考。

当然，这是有成本的，每次生成多个方案会让 Agent 的耗时翻倍。对于简单的 bug 修复或依赖升级，没必要每次都多方案对比。我的做法是设置一个复杂度阈值：当任务涉及多个模块或跨服务调用时，强制要求多方案；当任务是琐碎的小改动时，直接生成单一实现。

第三步：写代码 + 立即跑测试。很多 Agent 翻车就翻在"只生成代码，不验证代码"。

最先的验证是语义层的，比如 Agent 写 Java 代码时调用了一个不存在的类，或者改了个方法签名但忘了改调用方。这类错误靠静态检查就能抓出来。所以在 Agent 的执行循环里，必须内置编译检查、lint、类型检查这些步骤。我见过一些效果不太行的 Agent 项目，很大的问题就是它只输出代码块，然后人就拿去跑，跑挂了再回来改，来回折腾好几轮。真正的 Agent 流程应该是：Agent 自己写完代码，自己执行mvn compile或tsc --noEmit，看到报错自己修，循环往复直到编译通过。

然后是行为层的验证，这里有两种常见策略：

• 策略 A：Agent 自己补测试。让 Agent 为其改动生成或修改单元测试。这看起来效率很高，但有个坑：Agent 写的测试往往会"迎合"实现，即测试逻辑和实现逻辑是同一套错误思维，容易变成自证式测试。我在实际应用中会让 Agent 在测试里故意构造边界条件或异常输入，并检查这些断言是对的还是只为了通过。
• 策略 B：Agent 跑已有的测试。这个策略更重要，尤其是回归测试。Agent 启动一个任务前，先记下当前测试基线（哪些测试通过，哪些被标记跳过），改动完成后重新跑一遍，确认没有引入新的失败。这个基线对比的做法在工程上并不复杂，但极其有效。

第四步：生成 PR 描述。代码写完、测试通过以后，Agent 需要把改动整理成一个人类能快速 review 的 PR。PR 描述里至少要包含：改动动机、实现思路、测试结果、性能影响（如果有）、以及任何已知的权衡或风险点。

这一步经常被没做过 Agent 开发的人忽略，但实际上它直接决定了 Agent 落地的高潮和低谷。如果 PR 描述含糊不清，人类评审员还得自己看 diff 猜 Agent 的思路，那时间成本一点没省。反过来，如果 PR 描述写得像一封逻辑严谨的工程周报，评审员就能快速批准，70% 这个乘法才有可能实现。

另外我强烈建议在 PR 描述里附上一个相对固定的模板，包括变更摘要、测试计划、截图或运行日志、需要 reviewer 特别关注的改动区域。Agent 每次生成的 PR 都长一个样，审查人员就会形成肌肉记忆，一眼扫完所有关键信息。

2.3 为什么必须有人工评审兜底，以及 Agent 的三种"接管"形态

可能有读者会问：既然 Agent 都能独立完成 PR 了，人工评审是不是拖后腿？我要很确定地说：不是。Agent 接管的边界必须由人控制，这是一个工程决策，也是一个责任边界问题。

先说为什么必须有 review 这一环。Agent 目前的强项是"在已有模式中生成合理代码"，但弱项是对业务意图的深度理解。比如一段涉及计费的逻辑，Agent 可能写出在纯技术层面对、但业务规则上少了一个字段校验的代码。没有人工评审，这种问题会直接漏到生产环境，而且最可怕的是，Agent 生成的代码往往看起来极其规范，reviewer 如果抱着"AI 写的应该没问题"的心态，反而更容易漏掉关键问题。

再说 Agent 接管的三种形态。这是我在实践中观察到的 Agent PR 模式，大家可以对照自己团队的情况：

• 形态一：Agent 全自动生成，人工仅审批。Agent 独立完成从读代码到写 PR 的全流程，人类看到一个结构完整、测试通过的 PR，确认没问题就点合并。这种模式适合低风险、高重复度的变更，比如升级依赖、格式化代码、修复明确规则的 bug。
• 形态二：Agent 生成初稿，人类修改。Agent 完成大部分工作，但人类会对代码做出实质性调整，比如换个实现方案、补一些 Agent 想不到的边界处理。这种模式可能是 70% 这个数字里占比最大的部分。
• 形态三：Agent 辅助人写，人在主导。Agent 更像一个高级工具，在人写代码的过程中提供片段级建议。这个其实就是传统 AI 代码补全，技术上不新鲜，也不算真正的"Agent 接管"。

关键点在于：80% 的时间你根本不知道 Agent 会在哪个环节翻车，所以只要 Agent 的产出要进主干分支，就必须有门禁。这节把问题的本质讲清楚：接管代码产出不等于接管决策责任。Agent 让工程师从繁重的编码细节里跳出来，把精力放到 review 正确的改动方向上，这才是 70% PR 的最终价值。

3. 实操环节：搭一条能复现的 Agent PR 流水线

3.1 环境和工具选型：开源框架 + 模型 + CI 平台

聊完思路，这一节我给出一个可以落地的具体方案。不想做 Uber 那种超大定制化的团队，也可以参考这套做法，在 GitHub 仓库里跑通一个简化版的 Agent PR 流水线。

先交代我个人的工具选型经验。编码 Agent 的底座，现在主流有两大方向：

• 方向一：直接用 LangChain / LangGraph / AutoGen 这类 Agent 框架自己搭。灵活性最高，适合有自己的代码库上下文体系和评测标准的中大型团队。代价是需要自己处理很多工程细节，比如 token 成本控制、循环终止条件、错误恢复策略，这些都得写代码。
• 方向二：用开箱即用的编码 Agent 工具，比如开源的 Aider、Continue，或者你所在平台内置的方案（GitHub Copilot workspace 等）。见效快，但定制深度有限。如果只是想让 Agent 在一些标准场景里自动开 PR，这些工具已经够用。

我个人倾向于方向一，因为 Uber 这类场景往往需要 Agent 深度理解内部代码库、对接内部测试系统，而这些是通用工具做不到的。下面以 LangGraph 为例，我给出一个最小的 Agent 运行流程设计，用伪代码展示核心逻辑。

你不需要把下面的代码直接复制到生产环境，它更多是帮你理解 Agent PR 流水线的骨架。我用 Python 风格描述，方便不同语言背景的工程师阅读：

# Agent PR 流水线核心流程（伪代码） def run_agent_pr_task(task_description): # 1. 加载任务拆解结果 plan = agent.plan( task_description=task_description, repo_context=load_repo_context(task_description.related_files) ) # 2. 执行循环：写代码->编译->测试->修错 for step in plan.steps: code_diff = agent.implement(step) result = run_compile_and_tests(repo=step.repo, diff=code_diff) while result.has_failures and agent.retry_count < max_retry: code_diff = agent.fix(code_diff, result.failures) result = run_compile_and_tests(repo=step.repo, diff=code_diff) # 3. 生成 PR pr = agent.create_pull_request( title=generate_pr_title(task_description), body=generate_pr_body(plan, result) ) return pr

实际工程里需要注意几个点：

• 循环终止条件极其重要。Agent 修 bug 时可能会陷入"修一个错引出两个新错"的螺旋，所以必须设置最大重试次数（我一般设 3 次），超过就放弃并报错，让人工介入。没有这个限制，Agent 可能会把你的 CI 预算跑穿。
• run_compile_and_tests这一层必须做得纯粹且快速。如果每次 Agent 改完代码都全量跑测试，等待时间会非常感人。合理的做法是：先跑受影响模块的快速测试，全量测试留给 PR 合并前的 CI 去做。
• PR title 和 body 的模板要非常固定，不要每次自由发挥。这样评审员能更快定位重点。

3.2 核心 Prompt 和上下文注入方式：这是 Agent 写代码的"灵魂"

如果你问我在 Agent 编写 PR 这件事上，最大的工程杠杆是什么，我会毫不犹豫地回答：Prompt 里写的规则，比模型本身更重要。同等模型能力下，规则写得清楚，产出质量能差出一个数量级。

先说系统级 Prompt，这是一段固定在 Agent 体系里、每次任务都会生效的指令。我帮你总结一份可以直接改来用的骨架：

你是某仓库的资深软件开发工程师。请严格遵循以下规则： 1. 先理解任务，再读代码，最后动手。禁止在未阅读相关文件的情况下凭空写代码。 2. 最小必要改动：只修改完成本任务所必需的文件和代码。禁止顺手优化、格式化无关内容。 3. 每次写完代码，必须执行静态检查（编译/type check/lint）。 4. 必须补充或修改单元测试，覆盖本次改动引入的逻辑分支和边界条件。 5. 测试必须通过后才能发起 PR。 6. PR 描述必须包含：变更动机、实现方案、测试结果、风险点。 7. 如果实现过程中发现任务描述与实际代码逻辑有冲突，请在 PR 描述中明确指出，不要自行决定如何处理。 8. 所有代码风格遵循仓库既有约定，禁止引入全新的代码风格。

这八条规则里，第 2 条和第 7 条是我踩坑次数最多的。第 2 条防止 Agent 自作主张重构无关代码；第 7 条则逼迫 Agent 在遇到歧义时停下来求助，而不是头脑一热乱猜业务逻辑。

除了系统级规则，任务级 Prompt 要像一份合格的 issue 一样具体。我平时会使用类似这样的格式：

任务背景： - 模块：订单服务 - 问题描述：当两个并发请求同时执行订单状态更新时，状态被覆盖为旧值 - 期望行为：状态更新必须基于最新值，请求 A 和请求 B 的执行结果应该顺序一致 - 已定位的根因: `OrderService.updateStatus` 中缺少乐观锁控制 - 相关文件：`src/main/java/xxx/OrderService.java`, `src/test/java/xxx/OrderServiceTest.java` - 禁止修改的文件：`OrderController.java`, `SecurityConfig.java` - 成功标准： - 新增并发测试，模拟 10 个请求同时更新同一订单 - 所有测试通过 - 不引入新的告警日志

这种任务描述，直接把 Agent 的搜索空间大幅缩小，也把评审风险压低了。注意"禁止修改的文件"这一栏，很多人会忽略，但它在实际中真的很救命。Agent 一旦动了安全配置、控制器层这类和任务无关的文件，轻则 review 变慢，重则引入安全漏洞。

上下文注入这块，我再分享一个实操细节：不要只把相关文件的全文塞进去。代码仓库里一个 Service 类可能有一千多行，其中有大量和任务无关的方法。更高效的做法是先读出该类的方法签名列表，让 Agent 只精读与任务相关的方法实现。这招能显著降低上下文消耗，也能减少 Agent 被无关代码干扰的概率。

3.3 CI/CD 的质量闸门怎么设置：别让"看起来能跑"混进主干

Agent 自动生成 PR 这件事，最大的风险不是写不出代码，而是写出一堆在本地看似通过、但合并后立刻爆炸的代码。所以 CI 的质量闸门必须设计得比人类手写代码时更严格。

我在实际配置 Agent PR 的 CI 流水线时，会设置以下检查项，按照执行顺序排列：

这里我想重点讲一个我自己实践后觉得最有价值的检查项：变更范围校验。做法是：在任务描述里定义允许修改文件的白名单和禁止修改文件的黑名单，CI 在 Agent 提交 PR 时自动对比 diff，一旦发现触碰了不允许的文件，直接打回并且在 PR 评论里标注。这个机制的初衷是防 Agent 出错，但后来发现它还能倒逼工程师把任务拆得更细更清楚。

另一个容易踩坑的地方是：Agent 自动跑测试的账号和权限，必须和人工开发的账号分离。否则 Agent 在本地或 CI 环境里的读写权限过大会引发安全事故，Agent 执行的命令也不应具有生产环境的任何操作权限。这不仅是安全需求，也是审计需求——出了事故你能追溯是哪一次 Agent 的哪一步操作触发的。

最后再提一下 PR 合并以后的后续动作。Agent 合入代码后，我建议自动触发一轮"冒烟测试"，即在预发布环境跑一遍核心链路。为什么？因为单元测试和集成测试覆盖得再全面，也没法覆盖真实数据流下的所有交互。一旦冒烟测试失败，自动回滚 Agent 的这次提交，并且把告警发给对应的值班工程师。这样做虽然重，但能守住生产稳定性的底线。

4. 常见问题与排查技巧实录

4.1 Agent 生成 PR 时最常见的四类翻车现场

在实际跑了几个月 Agent PR 流水线之后，我总结出四类高频问题，每一条都是真金白银换来的教训。

第一类：Agent 在"看起来在干活，其实在打转"。典型表现是：Agent 读了一堆代码，输出了很长的思考过程，然后连续生成了数个版本的代码，但没有一个真的写进仓库。我把这种情况叫做"原地空转"。原因是 Agent 在规划阶段花费了太多 token，导致窗口不足或超时，没有进入真正的实现阶段。排查方法是看它的执行日志，如果发现某个步骤反复被重新规划，就要考虑给这个任务设定更严格的步骤数上限，或者把大任务切成小任务并行跑。

第二类：Agent 生成的测试是"假绿"。这是最阴险、也最容易被忽略的问题。Agent 为了通过测试，可能在断言里写了一个永远不会失败的比较，比如assertTrue(true)或者直接 catch 掉所有异常然后断言成功。这类测试跑了等于没跑，还给了评审员一个虚假的安全感。我的排查技巧是：在 CI 里加一个测试有效性检查——对每个新增的测试用例做一次"变体测试"，把被测代码里的一行随机改错，然后重新跑测试。如果新增测试没有失败，说明这个测试没有真正锁定行为，直接标记为可疑测试。这个机制很重，但针对 Agent 生成代码的场景非常值。

第三类：Agent 悄悄改了不相关的文件。前面说过白名单机制能拦截大部分，但依然有漏网之鱼。最常发生在 Agent"顺手"优化了 import 顺序、改了配置文件里的一个缩进、或者在重构时把另一个方法的注释也删掉了。这类问题需要靠 diff review 严格把关。建议在 CI 里加一个"diff 最小化"提示，当 PR 涉及超过 10 个文件或超过 500 行改动时，自动提醒评审员重点确认改动范围是否合理。

第四类：Agent 依赖了不存在的库或 API。这种问题前端项目里尤其常见——Agent 可能根据某个库的文档生成了一段代码，但仓库里根本没安装这个库。编译阶段能拦截一部分，但有些是运行时才报错。所以除了编译检查，我还会在 CI 里执行一次的依赖扫描，检查新增的 import 是否都能在 package.json 或 requirements.txt 里找到。如果找不到，直接打回。

4.2 排查思路与复盘方法：从失败 PR 中提炼规则

Agent 写代码不像人写代码，它不会"记仇"，但团队需要从失败案例中不断提炼新规则，喂回给 Prompt 和流水线。我的习惯是建立一个"Agent PR 失败复盘"文档，每次 Agent 产出的 PR 被人工打回或合并后出了问题，都要记录以下信息：

• 任务类型（bug 修复、功能开发、重构、依赖升级）
• 失败环节（计划错误、实现错误、测试不足、PR 描述不清、改动范围失控）
• 根因分析（是任务描述不充分，还是模型理解偏差，还是工程流程缺了某层检查）
• 新增规则（写进系统 Prompt 还是加 CI 检查）

举个例子：有一次 Agent 修一个支付超时问题，它为了"尽可能完整"，擅自改了好几个错误处理分支，结果引入了一个新的空指针异常。复盘后发现，任务描述里确实没有明确"只允许修改超时重试逻辑"这一限制。于是我把它写进系统 Prompt 的第 2 条："最小必要改动"，同时在 CI 里加了白名单检查机制。从那以后，这类问题大幅减少。

这类复盘机制的价值是双向的：一方面让 Agent 越来越"懂规矩"，另一方面让任务拆解的工程师越来越明白该怎么把需求写清楚。说白了，Agent 落地不是纯技术问题，是一个"人机协作规范"不断演进的过程。

4.3 工程师的新工作流：当 70% 的 PR 不用手写以后

最后聊一下人的变化。很多工程师担心 Agent 接管 PR 之后自己会失业，但我在实际推动这类项目后的观察恰恰相反：**工程师的工作重心从"写代码"转移到了"定义问题、评审方案、守住质量红线上"。

一个新典型的工程师日大致是这样的：

1. 上午先处理 Agent 标记为"需要人工确认"的任务。这类任务通常是需求有歧义，Agent 不敢猜，只能等人拍板。
2. 然后集中评审 Agent 提交的一批 PR。因为 Agent 写的 PR 结构和模板高度统一，评审速度比传统方式快很多。我个人的体感是，一个常规 PR 的 review 时间从原来的 30 分钟降到了 10 分钟以内。
3. 下午花时间做 Agent 不擅长的事：跨系统架构设计、跟产品经理对齐复杂业务逻辑、处理线上事故、优化 Agent 的 Prompt 和流程。

这种工作流下，工程师的产出效率实际上是在提升的，因为省下来的编码时间被投入到了更具决策性的工作上。更进一步，很多团队开始设立专门的"Agent 训练员"角色，负责把团队的代码规范、架构约束写成规则，源源不断地注入到 Agent 系统里。

从技能发展角度看，这类工程师未来的核心竞争力不再是"谁能更快写代码"，而是"谁能更精确地定义问题、更敏锐地识别 AI 产出的缺陷"。这也是我在自己带团队时，一直在引导大家调整的方向。

回到开头那个问题——70% 的 PR 被 Agent 接管，是不是意味着 Uber 正在走向"无人编程"？我觉得不会。更准确地说，Agent 消化掉了 70% 的体力活，剩下 30% 的深度问题——那些需要跨模块权衡、需要和业务方掰扯、需要理解系统演进方向的决策——恰恰是工程师价值的最高体现。

我个人这几年踩过不少坑，最大的体会是：Agent 写代码这件事，真正的工程难点其实不在模型本身，而在你有多认真地去梳理代码库、拆解任务、设计检查点。你给 Agent 的环境越规范、任务定义越清晰、CI 闸门越严密，它的可靠性就越高。反过来，如果你只是把一个含糊的 issue 丢给它，然后期待奇迹，那大概率等来的是一场事故。

最后再分享一个小技巧：如果你刚开始尝试 Agent 开发，不要一上来就追求 70% 的接管率。先在低风险模块里找一类高频且规则明确的任务（比如依赖升级、生成单元测试、修复 lint 错误），把 Agent 跑通，再逐步扩大应用范围。这个节奏看起来慢，但每一步都积累在稳固的工程基座上，后面提速是水到渠成的事。