企业官网建设流程全解析

最近我所在的团队发生了一件挺有意思的事：早上打开 PR 列表，发现十几个 PR 的作者头像都是同一个机器人。代码照常 review、CI 照常跑、合并照常进行。然后我点开一个一千多行的改动，扫了一下核心逻辑，基本挑不出毛病。说实话，那一瞬间我脑子里第一反应不是“这代码行不行”，而是“以后我还能干什么”。

后来我在技术圈子里也看到了类似的分享——某头部科技公司内部有相当比例的代码 PR 是由 Agent 接管提交的。结合我自己这一年多在 AI 编程工具和 Agent 流程上的实践，我越来越确定一件事：Agent 真正改变的不是“自动补全”这种小打小闹，而是“从需求描述到可合并 PR”的这一整条流水线。

这篇东西我打算认真聊一下：Agent 到底是什么级别的“写代码”、它凭什么能扛起 70% 的 PR 量、剩下 30% 为什么必须留给人，以及如果你想在自己团队里把这条路走通，从哪里开始最靠谱。

1. “Agent 接管 PR”到底在说什么：不是自动生成，是自动闭环

先说一个最常见的误解。很多人一听“Agent 接管了 70% 的代码 PR”，第一反应是“一个机器人直接往仓库里推代码”。如果真这么干，任何正经点的工程团队都不敢放它进生产环境。实际上，像 Uber 这类公司里 Agent 参与 PR 的方式，是端到端地接管一个小型任务的完整开发循环：从接收任务描述、定位相关代码、形成改动方案、逐文件实现修改、跑测试、处理报错、到最后提交一个格式规范、描述清晰、可 review 的 PR。整个过程中，人只负责两件事：给出足够清晰的任务描述，以及做最终代码评审。

这一点如果不看清楚，后面所有讨论都没有意义。因为只有理解了“Agent 完成的是闭环而不是片段”，你才会明白为什么它能顶掉 70% 的 PR，而不仅仅是一个“高级自动补全工具”。

为了更直观一点，我拿自己团队的实践来拆解。我们用的 Agent 工作流大概是这样一条链路：

• 需求来源：一张写得比较规范的 ticket（含背景、改动范围、验收标准）
• 预处理：Agent 拉取最新的目标分支，定位相关模块，做代码检索和影响面分析
• 实现阶段：Agent 自主完成文件修改，不是一次生成一大坨，而是增量 diff，每步可回退
• 自验证阶段：跑单测、跑 lint、跑构建，报错了自己读日志、改代码、再跑，直到通过
• 提交阶段：生成 PR，标题、描述、测试结果、改动摘要都由 Agent 自己写完
• 人工 review：工程师只做逻辑层面的评审，而不是帮它改缩进和拼写

说句实话，这套链路里的每一步，拆开看都不是什么“黑科技”。但串起来之后，效率和原来的工作方式完全不是一个量级。

那“70%”又意味着什么？它不是指 70% 的代码行数是 Agent 写的，也不是 70% 的 PR 完全没人碰过。更接近的真实含义是：团队里大约 70% 的、类型偏向机械和常规的编码任务，可以做到“人只负责描述和评审，Agent 负责从实现到提交”，而整个过程不需要人写一行代码。这个数字之所以能发生，核心就在于它切入的是那些重复度高、规则清晰、上下文边界明确的任务——这种任务过去吃掉的是工程师大量的日常时间，但它们的复杂度和创造性需求，恰恰没有高到必须由人来逐行手写。

2. Agent 能“自己写代码”的底气：一个建立在工具链上的执行体，而不是一个聊天机器人

很多人以为 Agent 写代码，就是像跟 ChatGPT 聊天一样说一句“帮我写个订单模块”然后哗啦啦出来几十个文件。这是对 Agent 能力边界的严重低估，也是高估。

真实的 Agent 不是一个聊天窗口，而是一个能操作系统、能执行命令、能读文件、能自己查资料、循环迭代的执行体。它生来就不是为了“聊天”，而是为了“干活”。我更喜欢用一句话来描述它：Agent 是给大模型装上了手和脚，让它不再只是“嘴上说说”。

2.1 Agent 的真正技术底座：模型 + 记忆 + 工具调用

一个能提交 PR 的 Agent，至少包含这几层：

• 大模型决策层：负责理解任务、拆解步骤、判断下一步动作
• 代码上下文感知层：通过检索和索引，找到改哪个文件、影响哪些调用方
• 工具执行层：调用终端命令、读写文件、跑测试、操作 git，而不是光靠模型“脑补”
• 自省和反馈层：看测试日志、看 lint 报错，把错误信息回灌进模型，再生成修补代码

你往深了看，模型本身只是“大脑”，真正让 Agent 达到可用级别的，是工具执行层和反馈层。没有这两个层，模型生成的代码即便逻辑正确，也无法保证和现有代码库的风格、依赖、接口完全对齐，更不可能做到跑通测试。

2.2 为什么大模型写代码“看着像那么回事”，可一跑就废

这就是为什么很多人自己用 AI 编程工具觉得“生成的代码质量不稳定”——因为他们只用了模型的单向生成能力，而没有给它一个“自己验证自己”的闭环。人写代码写错了会 review、会跑测试、会修 bug。一个没有工具调用能力的裸模型写错了，只会再给你生成一个“看起来更正确”的错误代码。

Agent 却不一样。它写完代码后是真实地执行测试命令的，测试挂了它真的会看到 stack trace，然后返回头去改代码再跑一遍。底层逻辑和一个人写代码时的“调试循环”是一样的：写代码 → 跑测试 → 看报错 → 改代码 → 再跑。这个循环一旦跑通，Agent 的可用性就完全上了一个台阶，因为它在交付之前已经替你把低级错误都挡掉了一轮。

2.3 工程化接入才是“70%”的关键

我在自己团队里做 Agent 落地时，一个特别深的感受是：模型能力只决定这个 Agent 能干到 60 分还是 70 分，而工程化接入决定它是停在 demo 阶段还是能真正每天合并几十个 PR。

工程化接入包括什么？包括代码索引的实时更新、任务来源和分支策略的对齐、可重复的本地/远程测试环境、PR 描述模板的规范化、CI 状态回传机制……这一大堆东西听起来不酷，但没有它们，Agent 就是一个个孤岛，无法嵌入到团队现有的协作节奏里。

3. 从 0 到 70% 的实操路径：我是怎么把 Agent 从玩具变成生产力工具的

接上个话题，光讲原理不够，接下来聊聊落地路线。我们团队大概花了小半年时间，把 Agent 参与 PR 的比例从 0 推到了差不多一半以上，中间踩了不少坑。我把这条路径重新梳理了一遍，去掉我们自己绕的弯路，总结成四个阶段，你可以把它当成一个可参考的实施蓝图。

3.1 第一阶段：挑对第一批“试验田”任务

这个阶段的目的不是追求量大，而是积累信任。我们的经验是，永远不要一开始就让 Agent 去碰核心业务链路或者架构调整类的任务，那相当于让刚拿到驾照的人直接上赛道。

真正适合第一批交给 Agent 的任务有几个特征：

• 边界明确：比如“给某个接口补全参数校验”“把某个模块的报错信息统一成 JSON 格式”
• 有现成的测试基座：改动后能通过跑测试来验证
• 有例可循：仓库里有大量相似的历史 PR 可以参考

我们团队当时挑的是“日志规范统一”和“死代码清理”这一类任务，风险极低，但涉及的文件数量多，非常适合 Agent。这类任务跑顺了几十个，大家就会对 Agent 逐渐建立信任。

3.2 第二阶段：把任务描述从“人话”改造成“机器可执行的规格”

这是我觉得目前整个 Agent 开发里最反直觉、也最容易被低估的一环。

你以为 Agent 最大的瓶颈是“它写代码写得不够好”？不是。我们遇到的最大瓶颈，是人描述任务的时候太含糊了。习惯了跟人沟通，我们默认对方能理解“把这个接口的报错处理优化一下”这种模糊表述。但 Agent 不会猜，它只会根据字面意思去执行。你给它一句模糊的话，它就会给你一个“看起来像在干活但很可能跑偏”的结果。

后来我们总结出一套“任务规范化”模板，现在团队里凡是准备交给 Agent 的 ticket，必须包含这几部分：

• 背景：这段代码现在为什么长这样，要解决什么问题
• 改动范围：明确是新增、修改还是重构，涉及哪些模块/文件（至少给个大致方向）
• 验收标准：哪些测试必须过、哪种行为不允许出现、输出格式是什么
• 反面约束：哪些事情不允许做（比如不要动公共接口签名、不要连带重构）

一开始大家觉得写这么细太费劲了，但跑了一段时间后发现，写清楚 ticket 的人，自己反而对需求理解得更透彻了。而且在 Agent 把大部分实现工作接走之后，人的精力反而被逼着集中到了真正需要脑子的地方：任务的定义、方案的取舍、边界的约束。

3.3 第三阶段：搭建“局部闭环”的验证环境

在 Agent 提交 PR 之前，至少要让它先在一个沙盒环境里完成自我验证，否则它提交上来的东西大概率被 CI 红灯打回去，来回折腾，效率反而更低。

我们的做法是给 Agent 的准备了一个隔离的执行环境，可以是一个容器、一台开发机，或者一套可本地复现的测试流水线。Agent 在环境里按顺序执行这些动作：

1. 拉取目标分支的最新代码
2. 按任务描述生成改动 diff
3. 执行 lint 和格式化检查
4. 跑受影响的单测和集成测试
5. 有失败就自己看日志、修复、重新跑，循环最多 N 次（我们限制是 5 次）
6. 全部通过了，才生成 PR 提交到远端

这个“先自测再提交”的环节非常关键。很多 Agent 的早期实现没有这一步，提交上来的 PR 三天两头被 CI 打回来，reviewer 的耐心都被磨没了。加上这个闭环之后，PR 的“一次通过率”提升非常明显，大家也就越来越愿意让 Agent 多干点活。

3.4 第四阶段：钉死 PR 的“描述规范”，让 review 成本降下来

这点看起来像是细枝末节，但实际体验下来对于推广 Agent 写 PR 至关重要。如果 Agent 提交的 PR 描述写得乱七八糟，reviewer 看不懂它改了什么、为什么要这么改、测试结果如何，那么再好用的工具也会被团队用脚投票淘汰。

我们给 Agent 的 PR 模板固定了这几块内容：

• 改动概览：一句话说清楚做了什么事
• 关联任务：对应哪个 ticket
• 关键文件列表：每个文件为什么被修改
• 测试验证：跑了哪些测试、结果如何、覆盖率有没有变化
• 风险与回滚方案：哪些地方需要 review 特别注意

一个写得清楚的 PR 描述，本身就是对 review 体验的尊重。这套规范和上一步的沙盒验证加起来，是我们 Agent PR 合并率能稳定提升的两个隐形功臣。

4. 为什么不是 100%：Agent 的边界、风险与必须人工把关的环节

聊完怎么把比例推上去，再来说说那个同样重要的问题：为什么到 70% 就差不多了，剩下 30% 留给人才是对的？不是做不到 90%，而是某些东西一旦让 Agent 碰，成本和风险可能会反噬你省下的那点时间。

4.1 Agent 不擅长“未知边界的探索”

Agent 适合在给定路径上走得又稳又快，但不太擅长在一片模糊地带里替你做出权衡决策。比如跨模块的大型架构调整、需要和多个团队对齐接口语义的改动、牵一发动全身的重构，这类任务里“正确方案”往往不只取决于代码本身，还取决于团队约定、历史包袱和未来方向。这些隐性的组织知识，Agent 再强也难凭空感知。

4.2 Agent 的“错误”可能看起来很合理

这类问题是最让我警惕的。Agent 写出来的代码如果错了，往往错得很“合理”——从语法到风格完全挑不出毛病，但业务逻辑上就是不对。这种错误比明显的手误更难发现，因为它要求 reviewer 对业务本身有足够的理解，而不能只看代码“好不好看”。

所以在这种背景下，我对 review 策略的建议非常坚定：人只看方案和结果，机器只查规则和测试，而不是让人逐行替 Agent 做陪跑式的 review。人工 review 的核心是：方案是否匹配需求、边界情况是否被遗漏、有没有滥用依赖、改动是否过度。一旦你发现自己在一个 Agent 生成的 PR 里逐行检查缩进和命名，那说明你的工具链没配置好——这些本该由格式化和 lint 自动拦住。

4.3 哪些类型的改动必须留给人（我的分类清单）

为了让这个判断更可执行，我把自己目前实践中的“人和 Agent 分工清单”整理成了表格，你可以直接用：

这个表不是死规定，不同团队的技术栈和测试基座会改变每个任务的适合度。但总体的原则就是：新代码和机械规整交给 Agent，架构与风险判断留给人。

4.4 “人机对抗”的另一个隐蔽风险：团队能力退化

最后说一个比较长远的问题。如果 Agent 接管了大部分“从需求到实现”的过程，初级工程师从哪里获得写代码的“肌肉记忆”和调试的直觉？这个问题在引进 Agent 之前，我和团队讨论过很多次。它不会立刻暴露，但过个一年半载，你可能会发现团队里很多新人写不了超过 50 行的独立函数——他们太习惯于让 Agent 代劳、自己只做 review 了。

所以我们现在有意识地保留一部分任务不给 Agent，专门留给新人做“刻意练习”。不是反技术，是反“无意识依赖”。这一点不知道对别人有没有用，但至少在我们团队里，已经成了一个默认的轮换机制。

5. 人在新协作模式里的角色升级：从手写代码到定义问题

回到开头那个让我脊背发凉的问题：“以后我还能干什么？”

这段时间想下来，我的答案变了：不是“我还能干什么”，而是“我需要会干的事情变了”。70% 的 PR 由 Agent 接管之后，工程师的核心技能正在从“把方案写出来”往前移——移到了“把问题定义清楚”上。

一个很直观的现象是，我们团队现在对 ticket 的要求比以前严苛了一个数量级。过去一个 ticket 写个标题加三行描述，开发会自己去脑补细节。现在不行了，因为读 ticket 的不只有人，还有 Agent。你写得越模糊，Agent 跑偏得越远，返工成本远超你自己多花十分钟把边界写清楚。

所以在我看来，未来的工程师日常会慢慢变成这样：

• 花更多时间去理解和拆解业务需求，去跟产品经理对齐细节
• 把拆解结果写成 Agent 能执行的规格说明
• 在 Agent 完成初稿后做高质量的方案级 review
• 处理 Agent 搞不定的极端场景和跨模块整合

说白了，工程师的产出物从“代码”变成了“定义”和“判断”。代码量反而可能没那么重要了。这个过程对老工程师更友好——因为经验和判断力恰好是时间熬出来的东西；对新人更苛刻——因为靠刷代码量往上爬的路，会越来越窄。

另外聊一个很多团队都会关心的实际问题：引入 Agent 之后，产出怎么衡量？以前大家用 commit 数量、代码行数、PR 数量来衡量开发产出。Agent 大量参与之后，这些传统指标基本失效了——Agent 一小时能提交的 PR 比人一个月都多，但你不能说这个工程师一个月的产出快顶上一百个人。我们现在更倾向用这几个指标来评估：

• 成功合并率：Agent 提交的 PR 有多少最终被合并
• 返工率：一个 PR 平均回退/修改几轮
• review 时长：每个 PR 花在人工评审上的时间
• 缺陷逃逸率：上线后有没有引入线上问题

这些指标更接近“工程质量”而不是“生产数量”，它们也反过来驱动我们持续去优化 Agent 的训练/提示词/流程。

6. 想在自己团队里做 Agent 落地？给你几条我踩过坑后的实在建议

这部分与其说是方法论，不如说是避坑指南。我自己从 0 到现在跑通这条链路，绕了不少弯路，有些弯路完全是“我以为”和“实际上”之间的差距。

6.1 先从“已存在的仓库模式”里抄作业，不要一上来就上新技术栈

Agent 在陌生代码库里生成代码，跟一个新人入职第一天被丢进老项目是一模一样的：最大的障碍不是不会写代码，而是“不知道这个项目里有哪些约定俗成的东西”。比如这个团队是喜欢函数式风格还是面向对象？错误处理是返回 error code 还是抛异常？命名是 snake_case 还是 camelCase？仓库里已有的注释风格、logger 的用法、异常类型的选择……这些都是大模型的“隐形知识盲区”。

所以我的建议是：在 Agent 开始的阶段，尽量从代码库里提取足够多的“模式示例”喂给它，或者让它先检索一个最相似的历史 PR 作为参考。甚至可以人为在需求描述里直接塞一两个类似文件的路径，让 Agent 照着写——效果立竿见影。

6.2 测试基座就是你 Agent 的天花板

这一点再怎么强调都不为过。你有一个能快速、稳定运行的测试套件，Agent 的成功率就高；你没有测试，或者测试跑起来要半小时且经常 flaky，那 Agent 就是在裸奔。

我们团队的经验：在引入 Agent 的早期，先花时间把 CI 的稳定性和速度解决好。不是追求 100% 覆盖率，而是追求“在 Agent 改动影响范围内，有能快速反馈的测试”。哪怕只有几个关键路径的集成测试，也比一个测试都没有强很多。

6.3 质检和策略要前置到“Agent 执行之前”，而不是事后补救

我们一开始犯最大的错误就是：让 Agent 直接产出 PR，再由人来 code review。看起来流程没毛病，但实际问题很大——Agent 会用自己的“自信文风”把所有问题包装得很合理，reviewer 如果没有特别警惕，很容易就放过去了。

后来我们把流程改成“策略前置”：在 Agent 开始执行之前，就把这几点规则注入到它的约束里：

• 不许修改与任务无关的代码
• 不引入新的第三方依赖（除非任务里明确要求）
• 不改动公共 API 签名
• 逻辑复杂度有限制，超过阈值的函数要拆解
• 所有新增代码必须有对应测试

这些约束写在 Agent 的系统提示词里，配合工具层面的拦截（比如 git diff 检查），比事后 review 再来找问题高效得多。

6.4 人性化预期管理：团队里的接受度要靠“让大家更轻松”来建立

最后这点也算是我个人的一个观察吧。Agent 落地最大的阻力，往往不来自技术，而来自团队的情绪。大家天然会担心“我的活是不是要被抢了”。但真正跑起来之后，大多数人会很快感受到：Agent 接走的不是“我的核心价值”，而是“我本来就烦的那些琐碎活”。

所以在推行过程中，我的建议是别急着喊口号、定指标，先把几个体验最好的用例做出来，让大家亲眼看到 Agent 把一个平时要两小时的改日志任务的 PR 在十分钟内提交上来，而且测试全绿。用结果说话，比推任何制度都管用。

写到最后的一些个人体会

从这一路实践里，我自己收获最大的一点，其实不是“学会了怎么用 Agent 写代码”，而是对“软件开发里什么东西最值钱”有了新的理解。以前我觉得写代码是最核心的能力，现在我觉得定义任务、做出取舍、守住质量边界，才是更不可替代的部分。Agent 把执行层变得极其廉价之后，判断力反而成了稀缺品。

如果你所在的团队还没有开始尝试，我建议不妨找一两个低风险的模块先试点起来。不需要一上来就上一整套复杂的框架，哪怕只是在 CI 里加一个“由 Agent 自动生成 PR”的 workflow，先跑通一个最简单的闭环，你就能感受到这条路到底值不值得继续深入。真正走过一遍之后你会发现，回到没有 Agent 的工作方式，就像习惯了自动驾驶辅助之后再去开一辆没有任何助力的老车——能开，但总觉得哪里不得劲。