实践案例｜从多维表需求到 MR 与上线

本案例由作者 kms9 根据内部 Skill 仓库交付实践整理。公开版本删除了真实组织、人员、平台、日期和任务标识；人物与角色采用代称，部分事件经过合并和顺序调整，以保留方法与失败边界，不还原某个内部系统的逐项事实。

这不是一份“全自动研发已经成熟”的效果声明。案例用于展示：边界明确的小需求可以怎样进入分析、代码修改、MR、审核、测试和部署；复杂需求为什么仍需人工完成业务建模、产品判断和架构拆解。

为什么把这个案例放进本书

本书的主线是：

发现 → 重构 → 构建 → 评估 → 治理 → 采用 → 复用

“澄川工业”案例用一套可控的模拟流程材料展示完整方法。本实践案例补充另一种视角：内部 AI 建设不会沿着章节顺序整齐发生。需求可能在一句话中混合业务目标、产品概念和工程修改；Agent 能写出代码，却不能替组织定义新的业务对象；自动化越快，人工审核、责任分配和失败恢复越重要。

这个案例最值得学习的不是使用了哪一个编排平台，而是团队怎样把以下环节接成一条受控责任链：

业务反馈
→ 信息澄清
→ 复杂度判断
→ Skill / Agent 执行
→ 代码变更
→ MR 与人工审核
→ 自动化测试
→ 环境观察
→ 线上发布
→ 失败回流

1. 案例背景

案例中的团队维护一个 Skill 仓库，业务和技术同学可以提出新增、修改或修复需求。仓库主要由一名维护者负责。

业务人员不直接进入代码托管平台，也不需要学习 Agent 编排工具。他们继续在日常使用的协作多维表中提交反馈。一个自部署的任务编排平台定期拉取表格记录，分析需求，必要时向提交人发回补充问题；达到实施条件后，系统修改代码并提交 MR，由维护者审核。

审核通过后，变更进入测试环境和自动化测试。观察一至两天后，再决定是否部署线上。审核不通过或测试失败时，任务不会被当作“重新提一个需求”，而是保存原任务和失败原因，从当前阶段继续修复。

为了让案例可以公开阅读，下面统一使用以下泛化名称：

案例称呼	实际承担的职责
协作多维表	需求入口、任务状态、提交人和反馈记录
编排平台	拉取任务、调用 Skill、协调 Agent、保存状态
Skill 仓库	可复用的业务规则、操作流程和工程能力
代码托管平台	分支、MR、Review 和版本历史
CI / 测试环境	自动化检查、集成验证和上线前观察

2. 最初要解决的不是“做一个 Agent”

如果把目标写成“建设一个能自动开发 Skill 的 Agent”，团队很容易把注意力放在模型、框架和多 Agent 调度上。但真实问题更具体：

在不改变业务人员反馈习惯的前提下，怎样减少维护者在机械分析、局部改动、反复沟通和测试操作上的投入，同时保证需求没有被模型擅自补全，代码没有绕过人工责任和发布条件？

这个表述包含三个约束：

1. **入口不迁移。**业务人员继续使用熟悉的表格，而不是被迫进入新的 Agent 工作台。
2. **自动化有边界。**模型可以分析和实现，但不能替提交人提供业务事实，也不能替维护者承担最终代码责任。
3. **完成状态是业务状态。**生成代码不算完成，只有审核、测试、环境验证和发布达到约定状态，任务才结束。

3. 案例运行流程

提交人在多维表填写需求
        ↓
编排平台自动拉取任务
        ↓
分析需求完整度、可信度和影响范围
        ↓
信息是否充分？
  ├─ 否：向提交人发送具体问题，等待补充
  └─ 是：判断需求复杂度
        ↓
是否属于边界明确的小需求？
  ├─ 否：进入业务建模、方案设计和任务拆分
  └─ 是：创建分支，修改代码并提交 MR
        ↓
AI 检查 + 维护者人工 Review
        ↓
审核是否通过？
  ├─ 否：记录问题，根据反馈继续修复
  └─ 是：进入测试环境
        ↓
自动化测试与验收
        ↓
上线前观察
        ↓
部署线上，或回退并继续修复

3.1 一个可恢复的任务状态

这条流程不应只存在于聊天记录里。任务需要稳定状态，才能在失败后继续。

submitted
→ analyzing
→ needs_information
→ ready_for_implementation
→ coding
→ waiting_for_review
→ changes_requested
→ testing
→ staging
→ deployed

旁路状态包括：

blocked
rejected
cancelled
unknown

unknown 不能被简化成普通失败。例如部署请求已经发出，但系统没有拿到确定结果时，不能直接再次发布；应先查询环境状态，确认第一次动作是否发生，再决定恢复方式。

4. 人、AI 与确定性系统怎样分工

“Agent 自主完成需求”不是这套流程的准确描述。更准确的责任分配如下。

环节	AI / Skill	人	确定性系统
需求接收	提取目标、约束、未知项	提交人提供业务事实	多维表保存原始记录和责任人
信息澄清	生成具体、可回答的问题	提交人补充；维护者判断是否足够	消息发送、状态等待和超时记录
影响分析	搜索仓库、识别模块、列出风险	维护者确认业务影响和修改边界	代码索引、权限和分支隔离
代码实现	修改代码、补充测试、生成说明	维护者处理架构与业务判断	Git 分支、提交和 MR
质量检查	AI Review、规则检查、失败分类	维护者完成最终 Review	CI、静态检查和自动化测试
发布	生成发布摘要和观察项	发布责任人批准	测试环境、部署系统和回滚机制
异常处理	提出修复、执行低风险重试	人处理模糊、高风险或不可逆问题	保存 checkpoint、审计和恢复状态

这里的“人在环中”不是让人检查每一步。人的介入应集中在：

• 缺少业务事实；
• 出现新的业务概念；
• 架构或数据模型需要决定；
• 代码和发布责任必须确认；
• 自动化测试无法证明业务正确；
• 出现高风险、不可逆或状态未知的动作。

5. 为什么一个小需求可以一次通过

一个已经完成的需求是：

上传 Skill 时，允许填写一个飞书文档链接，作为该 Skill 的使用说明。

它能够较顺利地进入自动交付，原因不是模型“更聪明”，而是任务契约相对完整。

判断维度	这个需求的特征
业务对象	Skill 已经存在
变更性质	为现有对象增加一个说明属性
输入输出	输入文档链接，输出可保存、展示或读取的说明
改动范围	局部 Schema、接口和页面
权限	基本沿用已有上传权限
数据迁移	没有或很轻
回滚	容易撤销
验收	可检查字段是否填写、保存、返回和展示
自动化测试	可以构造稳定断言

系统因此可以把任务拆成相对确定的工程动作：

定位 Skill 上传模型
→ 增加字段
→ 修改接口契约
→ 修改上传界面
→ 补充校验与测试
→ 提交 MR

即使模型第一次实现不完全正确，Review 反馈也容易转成具体修改。

6. 为什么 Skill Package 长期无法通过

另一个需求是“在 Skill Hub 中增加 Skill Package 概念”。它表面上像新增一个功能，实际上同时提出了一组尚未决定的问题：

• Package 是发布单位、安装单位、目录分组，还是依赖集合？
• 一个 Skill 能否属于多个 Package？
• Package 是否有独立版本？
• Skill 和 Package 的版本、依赖与兼容怎样计算？
• 安装、更新、回滚和卸载的最小单位是什么？
• Package 由谁创建、谁可以发布、谁能看到？
• 现有 Skill 如何迁移？
• API、页面、搜索和权限是否都要改变？
• 删除 Package 时如何处理其中 Skill？
• 怎样判断“功能完成”，哪些行为必须自动测试？

这些问题没有答案时，Agent 只能自行选择一种产品语义。代码可能能够编译，甚至页面能够展示，但实现的是模型猜测的产品，而不是组织已经决定的业务系统。

因此，这类需求反复无法通过，不应被归结为“Agent 的代码能力不够”。它首先属于：

业务建模
+ 产品设计
+ 架构决策
+ 数据迁移
+ 权限治理
+ 工程实现

把它直接送入“生成代码并提交 MR”的流水线，相当于跳过第 5—7 章，要求模型在一次运行中同时完成 discovery、对象建模、方案选择和工程交付。

7. 从失败中形成两条需求车道

7.1 快车道：自动交付

适合以下任务：

• 已有对象增加局部属性；
• 已知模式内增加一个 Skill；
• 边界明确的 Bug；
• 文案、配置和模板调整；
• 接口契约清楚的局部修改；
• 不改变权限、数据模型和用户主流程；
• 有确定性验收和自动化测试方法。

快车道输出的是代码和可部署版本：

结构化需求
→ 自动影响分析
→ 自动编码
→ AI Review
→ 人工 Review
→ 自动测试
→ 环境观察
→ 发布

7.2 探索车道：先建模，后编码

出现以下任一信号时，不应直接生成正式代码：

• 引入新的业务对象或业务术语；
• 改变对象之间的关系；
• 跨多个模块、仓库或团队；
• 改变数据结构或需要历史迁移；
• 改变角色权限；
• 产生新的不可逆动作；
• 影响多个用户角色和主流程；
• 验收标准无法写成稳定示例；
• 多个合理方案仍未作出取舍。

探索车道的第一批产物不是 MR，而是：

问题定义
→ As-Is / To-Be
→ 业务对象与关系
→ 方案选项和取舍
→ 数据、权限与影响范围
→ 验收标准
→ 子任务拆分
→ 测试计划

这些内容通过人工评审后，再拆成多个能够进入快车道的小任务。

8. 需求完整度不是一个模糊“可信度分数”

当前实践中会判断需求可信度和信息是否足够。为了避免这个判断变成模型的主观总分，可以把它拆成几项可核对的问题。

检查项	必须回答的问题
业务目标	为什么要改，影响哪个任务或结果？
当前行为	现在系统怎样工作，问题发生在哪里？
目标行为	改完以后，谁在什么条件下看到什么变化？
输入样例	系统会收到什么数据、事件或用户操作？
输出样例	应产生什么字段、页面、状态或副作用？
验收标准	怎样判断完成、失败和不应发生？
影响范围	涉及哪些对象、模块、用户和历史数据？
非目标	本次明确不解决什么？
权限与风险	是否涉及写入、删除、外发和不可逆动作？
参考材料	是否有文档、截图、历史案例或现有接口？

缺少的信息不一定都要通过一次追问补齐。对低风险小需求，可以使用已有模式和默认值；对引入新概念的需求，缺少对象定义本身就是停止自动编码的条件。

9. Agent 自省不能替代独立质量系统

讨论中有人把“发现输出不对、再修改”称为 Agent 自省。生产流程需要更严格的表达：

执行
→ 独立质量检查
→ 失败分类
→ 自动修复或人工介入
→ 从 checkpoint 恢复

同一个 Agent 声称“我已经检查过”不能作为独立证据。至少需要分别检查四个方面：

1. **需求检查：**有没有实现被确认的目标，而不是补全了另一个需求？
2. **代码检查：**代码结构、接口、权限和兼容是否符合仓库约定？
3. **测试检查：**确定性行为、回归和失败路径是否通过？
4. **业务验收：**提交人或业务负责人是否接受最终行为？

MR 被拒绝、测试失败和上线回退都应进入失败 taxonomy，而不是只保留最终成功版本。

失败类型	示例	主要修复方向
REQ-MISSING	需求缺少目标或输入样例	返回提交人补充
REQ-MODEL	新对象或关系未定义	进入探索车道
IMPACT-MISS	漏掉接口、页面或迁移影响	扩展影响分析与仓库索引
CODE-DEFECT	实现错误、空指针、并发问题	修复代码和单元测试
CONTRACT-BREAK	API 或数据结构破坏兼容	明确版本与迁移策略
TEST-FAIL	自动化测试或回归失败	定位节点并修复
REVIEW-REJECT	设计或业务语义不被接受	回到契约或方案评审
DEPLOY-UNKNOWN	发布结果无法确认	查询状态，禁止盲目重试
PRODUCTION-ROLLBACK	上线后出现不可接受问题	回滚、复盘并加入回归样本

10. 持续运行仍不能直接证明什么

案例设置了一段持续运行过程，用于展示需要记录哪些数据。由于公开版本经过脱敏和教学重构，它仍不能直接支持以下主张：

• 已经实现全自动研发；
• 适用于所有 Skill 或产品需求；
• 已经达到稳定生产级成功率；
• 明确降低了总体研发成本；
• 已经形成跨团队组织能力。

要判断采用与净价值，还需要持续记录：

指标	定义
首轮信息完整率	提交后无需追问即可判断的需求比例
信息补充率	需要向提交人发回问题的比例
快车道占比	可以直接进入自动实施的需求比例
首次 MR 通过率	首个 MR 无需实质修改即通过的比例
平均修复轮数	从首个 MR 到审核通过的迭代次数
自动化测试通过率	进入测试后满足全部检查条件的比例
人工介入时间	维护者用于判断、修改和异常处理的时间
提交到上线周期	从需求提交到生产部署的端到端时间
放弃或暂停率	因价值、信息或风险不足停止的比例
上线回滚率	部署后需要回滚的比例
重复提交者	多次独立完成该流程的使用者数量

这些指标要按需求类型分组。把局部字段改动和新产品概念放在同一个平均通过率中，会掩盖真正的适用边界。

11. 单一维护者是下一阶段的主要风险

当前流程的主要瓶颈可能不再是生成代码，而是所有关键决定仍集中在一名维护者：

• 需求是否完整；
• 是快车道还是探索车道；
• 架构选择是否合理；
• MR 是否通过；
• 测试失败怎样处理；
• 是否上线；
• Skill 怎样维护和退役。

自动化越快，进入审核队列的工作越多。如果这些责任没有扩散，系统只会把瓶颈从编码转移到维护者。

下一阶段应逐步定义：

角色	主要责任
业务 Owner	目标行为、验收和业务事实
Skill Owner	Skill 的适用范围、版本和失败样本
技术 Reviewer	架构、代码和兼容性
评估负责人	数据集、回归和发布条件
发布 Owner	环境、部署、回滚和观察
风险 Owner	权限、敏感数据和高风险动作

一个人可以暂时承担多个角色，但每次任务应明确“以哪个责任身份作出什么决定”，不能一直写成“原维护者审核”。

12. 什么时候才算组织能力

把 Skill 仓库放在公司 Git 平台上，不等于已经形成组织能力。至少要满足：

• 核心 Skill 有明确 Owner 和适用范围；
• 需求分流规则能够被第二名维护者使用；
• Skill 有版本、正负触发样本和回归集；
• MR、测试、发布和失败恢复有稳定的检查条件；
• 第二团队可以独立准备本地配置和业务语义；
• 原维护者的介入时间随着复用下降；
• 不适用场景、暂停和退役机制明确；
• 失败记录和回归样本与成功模板一同被保留。

达到这些条件后，这套实践才从“一个人使用 Agent 提升维护效率”升级为“组织可以持续经营的 AI 交付能力”。

13. 与本书章节的连接

本书章节	本案例展示的问题
第 5 章	为什么“做知识库”“增加 Package”还不是可实施场景
第 6 章	业务入口不迁移时，人、AI 和系统怎样重新分工
第 7 章	需求怎样进入任务契约、状态机、工具和 checkpoint
第 8 章	为什么 AI Review 不能替代独立检查和环境结果
第 9 章	运行时间、登录和提交数量为何不能直接证明净价值
第 10 章	单一维护者、Owner、版本和第二团队复用怎样决定资产化
配套实践旁注	按第 5—10 章组织本案例的教学插入点
练习册扩展	将经验转成可直接填写的分流、状态、质量检查和指标模板

14. 本案例的六条结论

1. **业务入口可以保持不变。**Agent 不必成为用户的新工作台，表格可以继续作为控制面。
2. **简单工程任务与复杂产品任务必须分流。**是否引入新对象、关系、权限和迁移，是比代码行数更重要的复杂度信号。
3. **需求完整度要拆成契约。**不能用一个模糊可信度分数代替目标、输入、输出、验收和风险。
4. **Agent 自省不能替代独立 Review、测试和发布检查。**同一个执行者不能同时成为唯一裁判。
5. **失败后从 checkpoint 恢复比重新运行整条 Agent 更重要。**状态未知时尤其不能盲目重试。
6. 个人维护的 Skill 仓库只有经过 Owner、版本、评估和第二团队复用，才会成为组织能力。

证据边界与后续更新

本案例来自内部实践整理，公开版本不附原始任务数据集、仓库日志或可识别的组织信息。将本案例方法迁移到真实项目时，应另外保存：

• 脱敏需求样本及分流结果；
• 首次 MR 通过率和修复轮数；
• 自动化测试与上线回滚记录；
• 维护者人工介入时间；
• 第二维护者或第二团队复用测试；
• 复杂需求从建模到拆分的完整 Decision Record。

这些记录属于实际项目证据，不能由本案例替代。本案例用于说明方法和边界，不用于宣称某个组织的成功率、生产效果或经济收益。