点击蓝字，关注我们
据此提出 AI 提效分级框架（L1/L2/L3） 与 AI Native 组织 两大理念，打破产研测运维职能边界，以 BuilderAgent 实现需求到上线的全流程闭环，让提效结果”可复制、可持续”。
01
1.1 发现问题
自全面接入 AI 以来，整个研发周期的各个环节包括产品、设计、研发、测试、运维等都在积极利用 AI 工具进行提效，但回头盘点发现，结论有点反直觉：团队里每个人都感觉效率有明显提升，但需求从提出到上线的整体周期并没有等比的显著缩短。
为什么？
古法需求从提出到交付全流程如下：需求洞察→ 需求提出 → 需求评审 → 方案设计 → 开发实现 → 测试验收 → 监控建设 → 上线发布 → 容量评估 → 数据回收与复盘迭代。分析核心环节，发现当前该流程存在以下四大痛点
痛点一：需求拆解到独立角色，协作成本高
-
各角色串行依赖，空等耗时
-
各角色信息不对称，沟通耗时
痛点二：各阶段信息局部维护，信息传递损耗大，易出错
-
各角色文档无显式关联约束，靠人工维护信息一致性，效率低
-
各角色文档独立维护，一次变化需人工多次逐层传播，易出错
痛点三：历史项目知识散落各地，沉淀效率低
-
历史需求/知识散落在各角色文档/对话/线下讨论中，个体获取知识效率低
-
关键经验留在个体手里，无法高效形成团队经验并在组织复用
痛点四：传统开发周期长，需求吞吐慢
-
传统开发包括开发->联调->测试等多个阶段，周期长&成本高
-
项目开发成本高，需求阶段必须开展充分研讨论证，整体需求交付周期被进一步拉长
AI能力分散地嵌入在单点环节，尚未形成从需求发现到需求优化的完整闭环，我们得到的只是”更快的局部”，而不是”更短的整体”。
1.2 数据印证
查询业界数据与研究，发现结论高度一致，而且能从两个视角直观感知。
视角一：即使在”研发环节内部”，写代码也只是一小部分。
视角二：把镜头拉到”需求 idea→上线”整条流程，编码占比更小——大头是等待与交接。
核心度量是流动效率（Flow Efficiency）= 真正干活时间 ÷ 总交付周期：
两组数据相互独立，却拼出同一条因果链：单点AI 优化了”一小段里的一小部分”，撬不动占 80%+ 的流程性等待与交接。
02
基于上述问题，结合AI当前实际能力、业务差异化的具体场景，我们构思了两个核心理念
1. AI提效分级框架（L1 / L2 / L3）
2. 流程精简与 AI Native 组织
2.1 AI提效分级框架（L1 / L2 / L3）
三级的本质区别：Context归属，而非能力高低；选择的核心依据是——这个需求的完成，依赖多少”人类独有、AI当前不具备”的context。
2.2 流程精简与 AI Native 组织
围绕 AI 重新设计流程与组织，而不是把 AI 缝进旧流程里。传统模式里，PM 管需求、UE 管设计、RD 管开发、QA 管测试、OP管运维，各自对自己那一段负责，中间靠交接文档拉齐——这些交接、对齐、返工、排期，才是周期里最重的开销。
我们推动的转变是：模糊 PM/UE/RD/QA/OP 的职能边界，让他们以 Builder 的新角色对同一个业务结果共同负责，共享同一份 Context 和交付物。AI Native 组织不取消专业角色，而是打破职能边界，隐性知识显性化，持续沉淀能力，专家协同保障平稳落地。
03
基于 AI Native 的两个核心理念，参考 SDD 和 AI-DLC 思想，我们协同 QA/OP 共建 BuilderAgent，打破职能边界，全流程线上化，每次全流程需求交付都是一次沉淀&进化，AI+专家机制保障全流程稳定落地。
3.1 七个环节
1. 需求发布
把模糊的需求信号收敛成一份人和 AI 都能消费的结构化契约，是全链路的单一事实源。以模板固定 Spec 的必填字段（目标、边界、验收标准、依赖的 Context 归属）；AI 基于历史案例、知识库与已沉淀的 Skill 自动起草初稿，人只补其中的隐性判断（战略取舍、用户/体验直觉）。验收标准必须写成”可被 QA 自动判定”的形式——这是后续 QA 能否走 L3 的前提，也是本环节最硬的一条约束。
2. 方案设计
在实现之前确定技术路径与关键取舍，替代古法中”拉一轮评审会”。AI 依据 Spec 生成带判断的候选方案（含取舍理由与代价对比）；Builder 只在关键决策点 review；一旦有变更，直接在 Spec/workspace 上就地改，最终生成一份可执行的方案骨架。
3. 开发实现
把方案变成可运行产物。Builder 与 AI 在同一个（沙箱化的）workspace 内编码、配置、自测，共享同一份 Spec 上下文，无需把上下文”搬运”到别的工具；人负责异常与边界兜底。每一次人工补位（人替 AI 改了什么、为什么改）都被记录，作为后续能力沉淀的原料。
4. 自动测试
判定产物是否达到 Spec 定义的标准。验收标准直接取自 Spec；系统自动CR、生成并执行用例，规则明确的用例走 L3 自动跑并产出报告；测试资产可复用、可回归。验收未过则进入修复闭环。
5. 发布上线
把验收通过的产物安全放量。以灰度策略 + 指标监控 + 回滚预案为骨架，规则清晰时自动执行；重大变更经”发车机制”人审。
6. 数据反馈
形成效果结论，并产出下一轮需求信号，闭合反哺回路。指标口径在系统内已定义，自动采集与对比；把效果异常或新机会点转化为新的需求信号。数据回收不是终点，而是下一轮的起点。
7. 持续进化
随着需求的持续迭代，把每次专家的补位与决策沉淀为组织能力，让提效可复制、不依赖个别熟手，同类型需求周期越来越短，同人力吞吐越来越多
3.2 五个关键构件
五个构件不是五个独立工具，而是围绕”同一份上下文”咬合的一组齿轮。
1. Spec 工具
根据业务特点，开发Spec工具，基于代码与历史知识，反复追问需求方，把”需求澄清一次做对”落成可被人和 AI 同时消费的结构化契约——包含目标、需求描述、边界、验收标准等。
2. 沙箱与workspace
业务维度构建 workspace，结合沙箱能力，可基于沙箱模板快速拉起一个包含且仅包含该业务相关的代码库、skills、知识、工具等完备的独立的开发部署环境，为人人都是builder的目标提供坚实基础
3. Builder 协同，从”交接”到”共担”
模糊各角色边界，面对L3/部分L2需求，Builder个人可在BuilderAgent完成全生命周期；L1和复杂的L2，则各 Builder 对同一业务结果共同负责，PM 不再”写完 PRD 就甩给 RD”，而是和 RD 在同一个 workspace产出Spec文档，RD可基于Spec文档继续后续流程；QA 的验收标准前移进 Spec，而不是等提测才登场。
4. QA 自动化
协同QA共建Spec工具、建设AICR/用例生成/用例执行/E2E测试/测试报告生成等能力，形成”Spec 定标准 → QA 自动验 → 结果回流 Spec”的小闭环
5. 智能运维
协同OP共建智能运维工具，把上线后的系统运行纳入 BuilderAgent 中。智能运维持续获取 Spec、workspace、QA 报告、发布变更、历史故障和运行知识，结合实时指标、日志、链路与流量数据，主动完成异常感知、问题分析、风险处置和结果反哺，让系统从“出现告警后等人处理”转向“持续感知、主动分析、分级处置”。
3.3 缺陷修复的重新开发闭环
验收或上线后发现问题，不能就地打个补丁了事——那样验收标准不会更新，同类缺陷会反复出现。BuilderAgent把”修复”设计成一条回流 Spec 的闭环。
闭环机制：
1. 触发：QA 自动化验收未通过，或上线后数据回收/智能运维监控发现问题。
2. 缺陷归因：定位问题出在哪一层——是需求理解（Spec）、方案取舍，还是实现细节。这一步决定修复的分级。
3. 回流 Spec：把缺陷转化为新的验收标准或边界补充写回 Spec。这是整条闭环最关键的一步，下面单独论证。
4. 重新修复：按缺陷层级定级修复（ L2/L3）；若根因在需求理解，则回到 Spec/方案层（L1/L2）重做。
5. QA 回归验证：复用原用例 + 新增针对该缺陷的用例做回归，确保修复不引入新问题；通过则重新发车，否则回到第 4 步再循环。
6. 沉淀：把缺陷模式与新增用例沉淀为规则/用例库。
为什么必须回流 Spec，而不是就地打补丁：就地打补丁只修好了”这一个 case”，验收标准原地不动，下次同类需求进来，QA 还是拦不住，于是缺陷复发、返工重来。
3.4 知识 / Skill 自动沉淀与更新机制
随着需求的持续迭代，把每次人工补位沉淀为组织能力，让提效可复制、不依赖个别熟手，同类型需求周期越来越短，同人力吞吐越来越多，L1 逐步演进为 L2/L3。
沉淀机制：
1. 触发：一次交付完成或一次缺陷修复完成，自动启动沉淀，而不是靠人工事后补写文档。
2. 抽取：从本次开发中抽取可复用信号——专家补位的 diff、Spec 的增量变更、新增的缺陷用例、方案决策及其理由。
3. 生成 / 更新：由 AI 把上述信号归类，生成或更新对应资产（已存在的资产做增量更新而非新建，避免碎片化）。
-
Skill——可复用的操作SOP和参考
-
规则——约束与最佳实践
-
验收模板——可复用的 QA 标准
-
知识——沉淀的系统架构/业务知识及相关索引
4. 回流复用：下一轮 Spec 澄清与 workspace 拉起时自动加载相关资产，让同类需求少依赖熟手——这正是”提效可复制”的机制来源。
04
4.1 登录改版实验需求
4.2 导航栏Hover优化需求
05
回到最初的问题：每个人都在用 AI 提效，为什么整体交付周期没有显著缩短？因为真正影响效率的，不只是单点任务的执行速度，更是角色之间的等待、交接、信息损耗与重复返工。只有围绕 AI 重新设计流程和协作方式，才能从“更快的局部”走向“更短的整体”。
这正是 AI Native 组织的核心：以业务结果为目标，打破职能边界，隐性知识显性化，持续沉淀能力，专家协同保障平稳落地。
现阶段的实践只是起点，未来，我们将持续推动 AI 从局部辅助走向全链路协同，让共享 Context 贯穿需求、研发、测试、上线与运维，让每一次交付都能转化为可复用的知识、规则和 Skill，更多需求将从 L1 逐步演进到 L2、L3。随着重复执行、流程衔接与反馈闭环逐步由 AI 承担，团队也将把更多精力投入业务判断、体验取舍和技术创新。AI Native 不是简单引入更多工具，而是持续更新人与 AI 的协作方式，让组织在交付业务价值的同时，具备不断学习、自我完善和加速进化的能力。
END
推荐阅读
面向 Coding Agent 的多仓库 Git Worktree
图灵平台：万亿级轨迹数据的秒级检索实战
让 Agent 按工程标准交付：AI Coding 下的质量关卡实践
AI 写代码越来越快，质量谁来守？网盘主端 FE 的 AICR 准入实践
协作的逆向演进：从 Agent 逻辑重构团队管理
