分享从一个判断出发：Coding Agent 写代码已经很快，但需求从提出到上线的整体周期没有同步缩短，原因在于流程里的大量环节是为"人的局限"设计的。团队沿着这个判断，把需求评审、技术方案、编码、审查、部署重新组织为九个阶段，用一份结构化 Spec 在 Agent 之间传递信息，用一台状态机串联全流程，人只在三个关键节点介入。
杨帅老师在分享中总结："当 AI 让某个环节变得多余，这个环节就该消失；当 AI 能承接执行层的工作，人就该把精力放到判断和创造上。"
Coding Agent 的编码能力，这一年有目共睹。但一个需求从有人提出到真正上线，周期仍然按天甚至按周计算，环节之间依旧靠人一棒一棒传递。在每个环节里单点加入 AI，各环节都省一点时间，整体交付速度却提升有限。团队因此换了一个问法：做一个需求，真的需要这么多环节、开这么多会吗？这些环节，有多少只是因为人才存在？
目前需求仍然排给具体的开发负责人，再由开发搭配一个 Agent 完成。以"帖子列表加载太慢，需要优化一下"这一最普通的需求为例：
开发会把需求翻译成两步：先让用户服务提供批量查询接口，再把帖子服务中的单查改为批量调用，最后把两个仓库一起交给 AI 执行。在这个过程中，开发承担的是"翻译官"的角色，把 AI 看不到的系统背景补给它，再把"列表慢"转成可执行的具体任务。
这里值得追问的是：这个翻译，只有人能做吗？
一个需求从用户反馈到上线，要经过七八道环节、七八双手，每个人按自己的理解转述一遍。用户说"操作太麻烦"，运营整理成"简化流程"，到产品手里变成"减少点击步骤"，三个人，三种说法。
对抗这种衰减，传统做法是开会：需求评审会、接口对齐会、联调周。很多会议开一下午，主要目的只有一个，确认大家说的是不是同一件事。
团队用一个问题重新审视这些习以为常的环节：这个环节，是因为人的局限而存在，还是问题本身需要它？
一个人很难同时精通前端和后端
AI 一次改完两端，协议对齐成为系统内部的事，对齐会本身不再需要
传递链条太长，理解偏差只能靠人对齐
Agent 之间通过一份结构化 Spec 流转必要信息，为对齐而开的会随之消失
双方开发节奏不同，只能人等人
前后端在同一条流水线里由 Agent 交付，串行等待消失
由此得出一个区分：在每个环节里插入 AI，是加法，各环节各省一点；让一部分环节整体由 AI 接管，整条流程的效率则是乘数。后文所有设计，都围绕后一种做法展开。
重建后的流程可以概括为：九个阶段由多个 Agent 接力完成，阶段之间靠一份 Spec 传递信息，用一台状态机串联，人只在需求评审、技术方案、验收上线三处介入。
以一个真实需求为例。产品在平台上只写了一句话："新建任务时，增加关联策略多选"，没有 PRD。
整个过程中，人在三个位置各确认一次，每次只花几分钟。流程并不总是这么顺利：评估不适合端到端、审查四轮仍不通过、Agent 发现缺少资料时，流程都会停下来，把决定交给人。
人工节点设得这么少，是踩坑踩出来的。人介入得太多，就等于没有自动化，所以节点要少，每一个都要放在真正需要人判断的地方。
动手的事大多交给 Agent，人负责在关键位置做判断：
在"看异常"上，团队遇到过一个典型案例。一个运营管理后台要做"标签拆分"，需求描述清晰。AI 改了前端展示，改了后端接口和存储，编译、单测、代码审查全部通过。
到最后验收时，人发现了一个问题：系统之外还有一个定时任务，同样会往这张表写数据、调用这个接口。接口改了，这个任务也得同步修改，但它没有被改到。这类问题 Linter 查不出，单测也测不出，AI 在系统内改得都对，系统之外的东西它看不到。
发现之后让 AI 修复，这个问题同时沉淀为一条仓库知识。下一次再改这个接口，Agent 就知道仓库之外还有关联的任务需要一并修改。
这个案例说明了人在审查环节的位置：有了端到端交付和质量门之后，人审交付物不必再盯着实现细节，要看的是意图，以及有没有系统之外、AI 看不到的东西尚未改到。
九个 Agent 之间怎么传递信息，才不会再玩成一场传话游戏？团队的做法是传接力棒，这根接力棒是一份结构化的 Spec。
Spec 包含精炼后的需求描述、逐条验收标准、技术方案（要改哪些文件、按什么步骤改）、需要人拍板的问题与答案，以及本次注入的知识卡。它在流程推进中逐步补全，每个 Agent 读取自己关注的部分，并把需要留给后续环节的信息写入对应字段。
两点配套设计：
有的团队会把整条流程交给一个 Agent 一路跑下去。边界清楚的编码任务，单个长循环非常合适。但研发流程很长，中间还要停下来等产品回答、等技术负责人确认，这时两种做法的差异就显现出来：
随步数持续膨胀，被强制压缩，信息丢失，后段注意力容易跑偏
每个 Agent 高内聚，只拿自己需要的字段，长度恒定
等待挂在会话里，进程一退即丢；几十个需求同时在等，平台无法统一查进度、催办
等人记成库里的一条状态，挂一周回来照样知道从哪接着做
只能干等
上下文状态入库，下个月重新启动
一个 Agent 包办全流程，调优互相牵扯
需求评审 Agent 可交给产品经理打磨，开发 Agent 可交给技术负责人注入开发 Skill 与团队规范，互不影响
因此，研发流程的自然形态是一台状态机。
这三样与具体业务关系不大，换一个场景也能复用。
工作流跑不到生产环境里，就只是一个 demo。这一部分是团队投入最多的地方。
开发 Agent 一次运行就是几十分钟，要克隆仓库、改代码、跑测试、推 MR，放在本机会占满 CPU，也可能把系统卡死。团队把 Agent 与平台拆开：
Agent 运行在云开发机上，无界面运行，按负载横向扩容，与平台之间只通过 MCP 和 HTTP 交互：领任务、报心跳、报进度、读详情、交结果。需求走到哪一步、谁领的、做到哪了，全部记在数据库里，这是唯一的真相，管理端上人看到的进度、答复追问、确认验收，读的也是同一份记录。
几个关键设计：一个需求只会被一个 Agent 领走，进度由 Agent 主动上报，调用工具凭一次性凭证。Agent 本身不存状态，所以它停了，平台仍能查到它做到了哪里。
Agent 本质上是进程，随时可能死。思路类似游戏存档：中间状态全部记下，挂了从最近的存档点继续，不必从头重来。研发流程很长，每次从头跑成本太高。团队遇到并处理了三类故障，外加一个人工入口：
恢复不等于重跑。"修复中"崩溃后，重放的是代码审查而不是修复：修复可能已经提交，重新审查才能知道代码当前的真实状态。
需求说清楚了吗
AI 在提问前先用自己的话复述需求，让人确认有无理解偏差。追问不走清单，顺着上一轮回答往下挖。放行前四件事必须明确：做什么、为谁做、规则是什么、怎么验收
照着方案能直接写吗
步骤按依赖排序：先建表，再写接口，再写逻辑，最后是调用方。单步改动超过 5 个文件就拆分，让每一步足够原子化；方案 Agent 用更强的模型，编码 Agent 因颗粒度小，用不着那么贵的模型。方案完成后让 AI 假设自己过度自信，再找一遍茬，把不确定的事尽量往前暴露
有没有多写、乱改
简单优先，三行重复的代码好过一个过早的抽象。范围纪律：只改方案里列出的文件，范围外发现的问题记录在变更摘要的"发现但不碰"里。AI 看到不合规范的旧代码会"顺手"修改，而每一处顺手都可能成为隐藏的 Bug
有没有要命的问题
Bug、崩溃、越权、数据错误必须修；风格偏好只提建议，不卡合并。以技术方案作为意图，逐条到代码里找证据。设六条安全硬底线，命中即打回
前两道门防的是模糊，后两道门防的是过度。每道门都在把问题往前移：AI 开发消耗的是部门成本，越早发现，修复越便宜。
审查门的分级也被问到过，是否意味着降低了质量标准。团队的回答是没有降，只是分级：该拦的一条不放，不该拦的不卡合并。这与 Google 代码评审规范的原则一致，变更确实提升了代码健康度，就不因不完美而阻塞。人还保留验收和上线两道关。
六条安全底线包括：用户维度的操作是否从登录态获取 UID 而非信任入参、新增接口是否接入鉴权、SQL 是否参数化、敏感信息是否进入代码与日志、外部入参是否在协议边界校验、资源访问是否校验归属。
质量门挡住的是坏结果，还有一类问题更隐蔽：系统没坏，但一直在空转。
这些护栏没有一条是让 AI 变聪明，它们的作用是在 AI 犯糊涂时，让系统及时停下来。自动化最难的一步，是知道什么时候该停，把决定交还给人。系统自己运行时之所以让人放心，也在于它出任何问题都会停下并 @ 人。
流程跑稳之后，瓶颈转移到了上下文与知识：AI 能做多少事，取决于给了它多少团队业务知识。
团队按需求类型做了一次盘点。最里面一圈，AI 能端到端完成，约占安全中心整体需求的近三成；最外面一圈，是基础设施够不着的部分，如无法接入的外部系统与配置系统，需要等基础设施补齐；真正值得关注的是中间一圈，AI 做到一半卡住，需要人补充。典型的情况是 AI 开发到一半停下来问："这个新接口我查不到背景资料，它依赖的服务配置，到底该从哪里读？"
数据印证了这一点：没有走完全程的需求中，因 AI 生成失败的不到 5%，34.7% 卡在需求补料和仓库关联上。补上上下文，AI 就能继续做，中间这一圈最有机会向外推。
知识的消费者从人变成 Agent，生产、形态、分发、维护都要随之改变：
靠人自觉写文档，或靠管理手段推动
流程节点自动沉淀，人只做纠偏。人在节点上补背景、做决策，这些补充本身就成为知识
长文档，人能读懂
结构化卡片，上下文足够小、足够精确，人机共读
用的时候再搜
动手之前就已注入。Agent 往往不知道自己不知道什么，不会主动去搜
只进不出
有进有出，到期退场。人能判断过期文档可能有误，Agent 会当真
传统知识库追求存得全，给 Agent 用的知识体系追求喂得准、淘汰得掉。
图中是平台里的一张真实卡片，来自一次代码审查：一个图片接口需要同时返回 base64 与二进制，审查发现，若二进制分支再编码一次，JPEG 属于有损编码，两份结果会对不上。这条意见最终沉淀成卡片。卡片包含三个要素：
注入方式上，团队一开始让 Agent 自己查，结果它几乎不查。现在改为平台在调用前，按仓库和阶段召回，单次最多 8 张，在 Agent 动手之前直接注入。
这是整场分享中杨帅特别强调的一个教训。
按直觉，知识越攒越多，注入的命中率应该越来越高。这里的命中率，是 Agent 回传的实际引用知识数与平台注入知识数之比。实际数据是：9 月注入近两千条，为历史最多，命中率却降到 16.9%，历史最低，离 60% 的目标差得很远。
就像塞满的书架，书越多，要找的那一本反而越难找。
复盘的结论是两端不平衡：自动沉淀的生产端太强，同一件事被反复记录；提纯与取用的治理端太弱，召回只看相关，不看质量。注入越多，噪声越多，反而把 Agent 带偏。需要补上的是四件事：
这四项目前仍在补建中，尚无可对外公布的效果数据。杨帅的建议是，做知识库的团队，第一天就把它们做进去，不要像他们一样等规模上来了再回头补。
团队不按"省了几个人"计算，AI 替代的是人手上那些没有价值的事。可核算的指标是需求吞吐：剔除纯策略配置类需求之后，部门需求吞吐提升约 30%。打个比方，同样 20 个人，原来一个月做 100 个需求，现在能做 130 个。人力没有减，节省下来的精力投入架构、底层优化和团队 AI 基建。
月度走势可以分为三段：
另外两个数字：提交到平台的需求中，走完全程的占 48.5%，目标是 60%；AI 交付，责任不转移，上线质量仍由对应仓库的技术负责人把关。
需要注意的是，这几个比例的分母不同："近三成"是安全中心整体需求中 AI 能端到端承接的比例，48.5% 是提交到平台的需求中走完全程的比例，30% 是剔除策略配置类需求后的吞吐提升。
团队判断一个需求能否交给 AI 的依据只有一条：所有相关仓库的改动契约，现在能不能一次定清楚。上下文能拿全，工作量再大也能做（曾有一个需求，AI 评审预估三天，实际一小时内完成）；上下文拿不全，再小的需求也要交给人。
走端到端：上下文能拿全
交给人：上下文拿不全
这一边界是动态的，知识补上一块，能力圈就大一圈。
开发周期从天压缩到小时，验证仍要等人有空，验收成为新的瓶颈。团队有两个尝试：
这里存在效率与质量的取舍。左移只适用于可容忍小问题的内部场景，约占三成需求，To C 这类用户零容忍的场景仍需严格测试。
如果希望在自己的团队中借鉴这套做法，杨帅给出三点：
回到开头的问题：AI 能承接更多工作以后，研发流程要不要变？团队这半年的答案是，要变，而且要重建。让 Agent 接住整个需求，需要交代清楚背景，把流程接起来，还要明确它在哪里停下，等人判断。
这套做法有清晰的适用范围：目前覆盖的主要是内部管理后台、配置与查询类需求，对外的 C 端、安全核心判定逻辑、架构重构仍由人主导；知识体系的治理刚刚起步，验收环节正在成为新的瓶颈。但沿着"哪些环节是为人的局限而存在"这个问题往下追问，得到的是一种可以迁移的思路，而不限于某个团队的某套工具。
这个环节就该消失。
杨帅（danteyang），腾讯 PCG 社交安全中心高级后台开发工程师，部门 AI Agent 专项负责人。2018 年加入腾讯，长期负责 QQ 社交安全领域的后台研发。近年聚焦 Agent 工程化与 AI 原生研发，主导搭建安全中心 AI 端到端研发平台，以多 Agent 接力与状态机编排，把需求评审、技术方案、编码、代码审查、测试部署串成一条流水线，并牵头建设部门的 AI 知识体系。
分
享
有
礼
END
我是「智能时代软件研发」，专注 AI 工程落地的现场观察与技术拆解。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。