AI 编程火了，但产研团队真正缺的是 Agent Loop

公众号名称：叶小钗

作者名称：叶小钗

发布时间：2026-07-09 09:00

当下，几乎所有的产研团队都正在使用或准备使用 AI 了；但是团队人员使用 AI 的姿势却五花八门，很少有完全统一的。

有的人用 AI 查资料、写文档、整理会议纪要，有的人用 AI 生成代码、补单元测试、分析程序日志，也有人用 Claude Code、Codex 这类工具，去编写核心业务的完整需求代码。

从表面上看，AI 现在正在快速渗透进产研的交付流程，但在团队的实际运转中，往往会看到一个很明显的现象：同样在用 AI，不同的人使用后的效果差异非常大：

有的人已经重度使用 AI，并能让 AI 高比例参与核心工作的实现，代码质量得到了很好的提升，而且返工频率并没有明显变差；
有的人却对使用 AI 畏手畏脚，只敢在边缘业务和边缘功能上使用，一遇到复杂任务就容易让 AI 出现理解偏差，返工此时也明显变得更多。

基于上面的现象，很容易形成一个结论：**会用 AI 的人更强，不会用的人更弱；**但，懂行的同学会知道，这句话看起来好像没什么大问题，但是它没有触及问题的本质。

所以今天真正的问题是：少数人其实已经形成了一套自己沉淀后的 AI 工作方法，但这套方法还没有成为团队能力。

AI 效果两极分化

很多人对 AI 的期待容易产生偏差，总觉得团队使用 AI 后，整体能力就会大幅提升，而且 AI 还能帮团队快速补齐短板，他们产生这种错觉是有原因的：

因为随着模型的能力越来越强，工具越来越成熟，过去很多需要资深工程师完成的工作，现在似乎普通成员 + AI 的形式也可以胜任。

但是真实情况往往和期待有不小的差距。AI 并不会自动拉齐团队能力，它往往最先放大的反而是团队原本就存在的能力差异。

因为 AI 能发挥多大的功效，其实很依赖于使用 AI 的人的能力高低：

一个 AI 用的好的人，不会把一个模糊的大需求直接丢给 AI，然后向 AI 许愿。他会先把需求拆解成几个相对明确的问题喂给 AI，让 AI 帮他来完善，比如：

这个需求的业务边界是什么？
有哪些角色和状态？
可能影响哪些系统和模块？
哪些规则需要补充？
哪些风险需要提前确认？
哪些部分可以让 AI 先做，哪些必须人工判断？

他也会给 AI 补充上下文，他知道 AI 不了解自己的真实业务，不了解系统的历史，不了解团队制定的规范，更不了解项目之前都踩过哪些坑。

所以他会主动告知 AI 下面这些事情：

当前项目的背景；
关键业务规则；
接口和数据约束；
历史兼容要求；
团队编码规范；
验收和测试标准。

以上这些还只是基础，更为重要的是，他会对 AI 的产物进行验证。

他不会因为 AI 给出了一段能运行的代码，就默认这些代码全部是正确的。他会通过各种测试、Code Review、模拟真实场景跑业务等手段去检查和验证 AI 的产物。

但是对于那些刚开始使用 AI 的成员来说，情况可能完全不同：

他不知道怎么把一个需求拆解成多个问题让 AI 帮他去完善。
他不知道哪些内容需要提供给 AI 以便 AI 能够获取足够的上下文。
也不知道应该如何去验收 AI 输出的代码或文档成果。

当他经历了几次让 AI 执行复杂任务但是都无法输出理想结果的时候，他就会得出结论：AI 好像也没那么有用、不知道 AI 该怎么用或者越用越慌，比如以下问题：

不知道大家有没有这个感觉，就是现在用 ai 完成的项目需求，做完之后，想要完整将这个项目脱稿说出来很难，但是项目确实是做出来了，也没啥问题；

我现在卡在，东西是我做的，但是简历上不知道怎么写，有点像之前把同事项目当自己项目的错觉

于是乎，团队里会逐渐出现一种分化：

一部分人因为 AI 的赋能变得越来越强；另一部分人确因为没有方法，没有路径，没有正反馈，始终只能停留在浅层使用；还有一部分越用自己能力越弱。

这时的 AI，并没有变成团队能力，反而变成了少数人的个人武器。

个人高手 VS 团队下限

很多团队，最初在用 AI 给团队赋能的时候，第一反应是培养几个特别会用 AI 的人。

这些当然是有价值的，但是就算一个团队已经有了几个 AI 高手，也并不意味着这个团队已经形成了真正的 AI 组织能力。

因为高手有一天会离开（并且这批人挺容易离职的），你的真实业务会变得越来越复杂，或者团队有新鲜血液的加入，以上种种，都可能让这些能力断掉：

所以，真正值得团队去建设的，是那些可以留下的东西，是把团队里的高手解决一个又一个的问题时使用的方式逐步沉淀下来。

高手的价值的精髓在于他脑子里的方法论：

如何理解一个需求；
如何拆解任务；
如何发现遗漏；
如何补充上下文；
如何做技术方案；
如何识别风险；
如何验证结果；
如何把一次经验变成下一次的规则。

这些内容，抽象一下就是独属于团队的核心资产：

需求模板；
项目规则；
技术规范；
评审检查清单；
领域知识库；
常见风险清单；
可复用的 Skills；
阶段化工作流；
自动化质量门禁；
真实项目案例。

只有这样，新人才不需要从零摸索，普通成员也不需要完全依赖个人经验。

每个人都可以沿着一条更加稳定的路径去和 AI 共同完成工作：先补齐需求边界，再分析影响范围，在进入技术方案和开发阶段，最后通过 Code Reivew，测试，发布完成验证…

这个也是我理解的 AI 原生团队：团队里不可能每个人都成为高手，但是团队的下限能够被提升到一个更高的质量。

高手当然还是重要的，他们负责处理更加复杂的问题，定义更新的规范和准则。但是团队不能每次遇到问题的时候，都等待高手的出现。

把优秀的个人能力变成团队能力，才是 AI 原生组织真正的价值。

多 Agent 到底是什么

当我们在谈论各个角色 Agent 时，很容易被人问到一个问题：这些 Agent 到底是什么？一个 Prompt，一个 Skill，还是一个完整的系统？

在我看来，他们更可能是一类角色化 AI 的工作能力。

以产品经理 Agent 为例，这里的重点是先搞清楚：产品经理这个角色最值得复用的工作技能，到底是什么？

比如，产品经理角色最值得沉淀的是这些内容：

检查需求是否完整；
补齐用户故事和异常流程；
找出遗漏的权限、状态和验收条件；
输出待确认问题；
把零散想法转成结构化需求输入。

架构师 Agent 呢？这个角色最值得沉淀的是下面这些内容：

分析影响范围；
识别依赖系统；
推演不同方案的风险；
补充性能、安全、兼容、灰度和回滚约束；
把隐性技术规则显式化。

以上这些能力在落地的不同阶段会有不同的形态：起初，它可能只是一个用完就丢的 Prompt。比如：

请以互联网医院产品经理的视角，检查这份需求是否缺少角色、异常流程、权限、状态流转和验收标准。

如果我们往前一步，它可能会变成一个可复用的提示词面板。模板经过不同场景的迭代，它又可能会升级成一个 Skill，也就是一个更加稳定的角色化的工作单元：

固定输入；
固定上下文；
固定检查框架；
固定输出格式；
固定人工确认动作；
固定质量反馈方式。

举个例子：一个需求完整性检查 的 Skill 可能是这样的：

输入是 PRD、原型、历史需求和领域规则。
检查的是角色、主流程、异常流程、权限、状态、验收、埋点和后台配置。
输出的是遗漏项、待澄清问题和建议补充内容。
最后交给团队里的产品负责人和技术负责人共同对以上内容做确认。

当这个工作单元在多个真实项目中反复使用并被验证有效时，团队再把它接入组织里的知识库、项目管理工具，甚至演进成能够自动读取历史需求、自动回写评审结论，此时它才会逐步演化成一个更完整的 Agent 工作流，甚至成为一个 Agent 系统。

所以，Agent 的建设顺序也就出来了：思考团队里哪一类高价值工作，最值得先被标准化、复用和验证？

错误的加速 ≠ 效率

现在很多产研容易形成的一个错误观念，把代码生成更快直接等同于研发效率更高。

但一个完整的产研体系，并不是只有写代码这一个环节。一条标准的交付链路通常是下面这样：

需求 -> 方案 -> 架构 -> 开发 -> 测试 -> 上线

这个链路有一个非常现实的规律，越在靠前位置发生的偏差，越会在后面被逐步放大；越晚发现问题，返工成本就越高：

如果一个需求在设计阶段没有想清楚边界，到了开发阶段就会不断去补充和完善需求。

如果方案阶段没有梳理影响范围，开发到一半可能才发现当前功能还涉及另一个服务，一张历史数据表，一个外部的三方接口，甚至可能是一套权限模型。

所以，即使开发 Agent 很强，也并不代表团队的效率就一定会得到提升。

如果研发的方向本身都是错的，那么 AI 只会更快地执行错误方案。举个很实际的例子，假如我只对 AI 说：

帮我设计一个互联网医院的科室管理模块

AI 可能会很快给出一个看起来很专业的传统医院模型：

一级科室；
二级科室；
多层级组织树；
医生，药师，护士角色；
复杂的隶属关系；
排班和线下管理逻辑。

这些设计从传统医院角度看，似乎没问题。

但互联网医院未必需要这一套。很多互联网医院的组织结构其实更加扁平，真正需要关注的可能是：

医生归属；
服务类型；
问诊场景；
线上运营配置；
审方规则；
处方和履约链路。

AI 给你的方案是错的，但是 AI 本身做错了吗？其实并没有，它只是在你没有提供足够信息时，按照它最常见，最通用的经验去帮你做了补全。

AI 不会知道那些你没有告诉它的事情

这也是为什么，我觉得团队在引入 AI 时，一定不能只盯着开发和测试。相反，团队的负责人更应该优先让 AI 去参与产研的上游环节：

需求完整性检查；
业务边界梳理；
技术方案推演；
影响范围分析；
风险预审；
验收与测试设计。

上游已经把 做什么、为什么做、做到什么程度 讲清楚了，下游 Agent 才能走在正确的路上。

组织资产

绝大部分人开始用 AI 时，最关注的是提示词。

这个很好理解，因为提示词是最容易让你看到 AI 使用效果的入口。

但是一个团队开始在真实的项目中使用 AI 时，很快就会发现一个现象：一版提示词在当下有效，并不代表次次都有效。

换一个项目，或者换一套业务规则，亦或是换一个模型，最终都可能会获得完全不同的结果。

那些真正能够影响 AI 是否能稳定参与研发和交付的，其实是它背后的组织资产是否足够完整。

这些组织资产我认为可以分成五类：

1. 规格

规格解决的是：我们到底要做什么。

它的目的是为了让你把目标，角色，业务规则，边界条件，验收标准和待确认问题全部整理清楚。

这样，人和 AI 才能基于同一套事实进行协作。

2.上下文

上下文解决的是： AI 是否理解了真实世界和真实业务。

它包括行业规则，业务背景，历史系统，接口契约，数据口径，权限模型，合规要求，团队规范，过去的经验教训等等。

没有这些内容，AI 往往就会按照默认常识去理解你的问题。

但在真实世界里，你所在的行业和项目，恰恰有很多不符合默认常识的特殊规则。

3.角色化 AI 工作单元

在产研团队里，不同角色有不同的思考框架。

产品经理关注需求完成性，架构师关注影响范围和约束，测试关注边界和覆盖，技术负责人关注风险，治理和质量。

只有把这些框架显示化。团队才不会完全依赖于那些高手的个人经验。

4.工作流

工作流解决的是：AI 在什么时候参与，输入是什么，输出是什么，谁来确认，又如何做交接。

复杂的任务不应该通过一句话全部丢给 AI。更加合理的方式是：

需求澄清 → 原型设计 → 技术方案 → 风险检查 → 人工评审 → 开发实现 → 自动验证 → 复盘沉淀

这样每一步都有边界，后一个环节 AI 可以读取前一个环节已经确认的产物，而不是让 AI 反复从零猜测。

5. 质量门禁

AI 可以自动生成，但是不能自证正确。

所以各类测试，Code Review，静态扫描，安全检查，灰度，监控，回滚预案，这些环节和步骤，不能因为 AI 的引入而被跳过。

恰恰相反，正因为 AI 输出更快，质量门禁反而更加重要。

团队不应该要求成员无条件相信 AI , 反而更要让大家知道，AI 的输出可以也需要被验证，被控制，被追溯。

个人的一版优秀提示词可以带来一次成功，但是组织资产才能带来更加稳定的复用。

实践建议

很多团队推进 AI 落地时，容易走两个极端。

一种是一上来就想全面推广，搞个大而全：统一工具，统一模型，统一框架。做知识库，做平台，做多 Agent 编排。

另外一种呢，则是完全放任：大家各自用一点工具，各自积累一点经验，但是完全没有任何团队沉淀。

我觉得更加务实的方式，是先选一个真实的场景，用 30 天跑通一个角色化 AI 工作单元。

第一周，不要选 大 Agent，先选一个明确的任务。例如：

需求完整性检查；
架构影响范围分析；
代码 Review 辅助；
测试点补全；
发布风险检查。

第二周，定义最小能力包。这里至少要明确六件事：

AI 扮演什么角色；
AI 解决什么固定问题；
AI 需要哪些上下文；
AI 输出什么内容；
谁来确认输出；
怎么判断它是否有效。

第三周，在真实任务中重复使用。不要只拿 demo 去做验证。

我们需要至少在两到三个真实项目任务里跑完所有流程和步骤并且记录如下内容：

AI 输出是什么；
人工修改了多少；
它发现了哪些遗漏；
是否减少了返工；
是否节省了时间；
哪些地方反而增加了成本。

第四周，再决定下一步怎么演化。

如果输出结果不稳定，那我们就继续补全更多的上下文，不断去优化模板。

如果任务单一且输出稳定，那我们就可以沉淀成团队使用的 Skill。

如果多个环节需要协作，那么我们可以考虑升级成工作流。

如果未来需要自动读取文档，代码仓，项目管理工具，并自动调用多个系统完成整条工作链路，此时再去考虑是否有必要做成一个 Agent 系统。

上面这个顺序至关重要：

先验证一个角色能力，再沉淀为 Skill，再编排成工作流，最后才考虑 Agent 系统

千万不要把做系统当成起点，系统只是能力成熟之后的一种承载形态。

结语：从个人提效，到组织能力

最后回归几天前关于 AI 原生组织的分享，当时我们总结出了一个公式：

AI 原生组织 = 员工AI能力 + 机制流程匹配 + 组织评价匹配 + AI操作系统

而产研领域也是走得最靠前的，市场上关于产研领域的 AI 操作系统都出来了：

我知道各位看着吃力，我用之前CEO数字分身的结构给大家展示下阉割版：

今天我们具体介绍了在研发团队 AI 原生组织的实践经验：

这件事也没大家想的那么难，很多组织追求 AI 原生的逻辑都是类似的：

第一，用自动化脚本替代人肉流转
第二，用提示词处理非结构化信息
第三，用定时任务跑数据指标
第四，做一套飞轮系统出来，让AI更聪明；

站在团队的角度，又一般会分为三个阶段：

散乱阶段，零星使用；
Copilot 阶段，以人为主，个人提效明显，但组织不明显；
Native 阶段，工作流程以 AI 为核心构建，组织效率提升明显；

对应的是四层问题递归，大家自己去感受就行，反正每一层的问题解决了，第二层的问题自然就出现了：

对课题感兴趣的同学，可以了解我们的产品：

内容效果不满意？点此反馈