基础盘
PingCode／TAPD／ONES 已把「需求 ↔ 任务 ↔ 缺陷 ↔ 代码提交」关联做成标配。需求—产物追溯是刚需不是创新点——必须做全，做到了也拿不到差异分。
产品方案
H5 项目智能化产研协同平台 · 问题定义 · 产品定位 · 功能框架 · 业务流程 · 版本规划 · 验收口径。
01 / 问题定义痛的不是环节效率，是环节之间
题面主体是持续产出 H5 活动页的跨部门产研组织。两个行业特征绕不开：需求高频变更（上线前改文案改玩法是常态），产物链条长（一条需求依次物化为原型、UI、代码，每次形态转换都是一次信息重述）。
业务口头提需求→产品 Excel 台账→产品画原型→设计出 UI→研发写代码→群里喊话验收
核心矛盾
六个环节内部各有工具，环节之间只有「人」。需求在 Excel、原型在产品电脑、UI 在设计工具、代码在仓库——四类产物分属四个孤岛，无任何结构化关联。于是 H5 业务的变更频率是天级，而链路的变更传播能力是人肉级：变更不是例外事件，却被当作例外处理。
| # | 问题 | 根因（连问两层） | 影响 | 优先级 |
|---|---|---|---|---|
| 1 | 变更无法同步波及原型／UI／代码，过程不可追溯 | 四类产物四个孤岛、无结构化关联 → 需求以 Excel 行或口头存在，本身不是可被引用的对象 → 从未建立「需求是资产、产物是其派生」的数据模型 | 每次变更平均 1–2 个角色漏同步，单次返工 0.5–2 人日；按每项目 5 次变更估算，返工占研发周期 20–30% | P0 · 题眼 |
| 2 | 交接靠口头与群消息，确认无凭据、版本不一致 | 确认行为没有系统载体 → Excel 与群只能记录内容，不能记录「谁在何时对哪个版本表态」 | 验收争议无法仲裁；「我以为是这版」类错配每项目 2–3 次 | P0 |
| 3 | 三类产物人工独立完成，环节等待长 | 每环节从零造产物 → 上游产物不是机器可消费的结构，AI 与工具无从接力 | 六环节串行等待占周期 40%+ | P1 |
| 4 | 角色职责与权限不清，流转无闭环 | 流程未定义（谁能改需求、谁必须确认、驳回走哪）→ 组织依赖熟人默契而非流程契约 | 变更无主、验收标准漂移；新人协作成本高 | P1 |
竞品扫描的三条结论
缺口 一
上述工具对原型稿、UI 稿的关联多为链接级挂载，不理解产物内容，回答不了「这个需求变了会波及哪张稿的哪部分」。变更影响的语义级传播是空档。
缺口 二
AI 生成已成大路货，但它们是单点生成器——无多角色审批门禁、无版本追溯。「AI 能生成」已被证明，「AI 生成物如何进入多角色确认秩序」没人做透。
另一个对手是现状本身：Excel + 微信群 + 口头确认。用户已在用「免费但无结构」的方案凑合，因此迁移成本必须低。
02 / 用户与目标枢纽层最痛，末端层背锅
| 层 | 角色 | 位置 | 核心诉求 |
|---|---|---|---|
| 发起层 | 业务 / 运营 | 需求源头 + 最终验收 | 提了有回音，改了能落地，随时知道进度 |
| 枢纽层 | 产品经理 最痛 | 需求翻译 + 变更广播中心 | 从「人肉路由器」解放，变更影响自动算 |
| 生产层 | UI 设计师 | 原型下游、代码上游 | 拿到的需求是最新版；改稿有明确边界与依据 |
| 生产层 | 前端研发 | 链条末端，承受全部上游误差 | 需求冻结可信；变更有 diff、有排期重估 |
P1 · 主 PERSONA
陈倩 ｜ 产品经理
同时跟 4–6 个 H5 项目，每天在业务群、设计群、开发群之间转发消息。变更靠她逐个私聊通知，漏一个人就返工一片；出问题时无法证明「当时确认过」。
「我不怕改需求，我怕改完之后没人知道自己该改什么。」
P2 · 受害最深
老段 ｜ 前端研发
按上周确认的 UI 稿开发，周四被告知主视觉上周三已改版。返工没有依据可追（谁改的、何时改的、基于哪版改），背最多的锅。
「别跟我说『就改一点点』，先告诉我改的是哪一版上的哪一点。」
指标
| 类型 | 指标 | 目标 | 为什么是它 |
|---|---|---|---|
| 北极星 | 变更闭环时长 一次变更从提出到全部受影响环节确认更新的时长 | 2–3 天 → ≤ 4 小时 | 直接度量「天级变更 vs 人肉级传播」的差距被压掉多少 |
| 护栏 1 | 版本一致率（验收时实现与最新确认版一致比例） | ≥ 95% | 防止「传播快了但改错版」 |
| 护栏 2 | 确认覆盖率（关键交接点留有凭据化确认的比例） | 100% | 防止为省事跳过确认门 |
03 / 产品定位需求是资产，产物是它的派生
定位陈述
对于依赖口头沟通和 Excel 台账协作的 H5 产研团队，ProdFlow 是一个以需求版本为单一真源的智能产研协同平台：需求—原型—UI—代码—用例全程关联，AI 先产草稿人只放行，变更沿血缘可视传播并定向驱动协同更新。不同于把六个工具串起来的拼接方案、也不同于把追溯做成日志列表的研发管理工具，我们用产物血缘图谱和变更单解决跨角色一致性问题。
支柱 一
单一真源
需求版本是唯一权威。原型、UI、代码、用例都是它的派生产物，显式建边、可被引用、可被计算波及。
支柱 二
AI 生产，人工放行
AI 承担每环节的第一遍生产与影响计算，但未经人工 diff 放行不生效、不挂入血缘。
支柱 三
变更即传播
变更不是通知，是沿血缘的一次可视传播：点亮波及节点、标注影响等级、由人勾选范围后定向派发。
04 / 功能框架六个一级模块，覆盖六个环节
| 模块 | 环节 | 关键功能 |
|---|---|---|
| 1 项目工作台 | 横切 | 概览与里程碑 · 按角色聚合的我的待办（待评审／待放行／待验收／变更任务）· 协作动态 · 风险提醒 · 指标仪表盘 · 角色视角切换 |
| 2 需求中心 | ①② | AI Excel 台账一键导入并批量结构化 · 表单与自然语言双入口 · AI 字段抽取带置信度、逐字段可改、可重解析（失败降级空白表单）· 多角色评审 · 确认基线与版本记录 · AI 插单影响预估 |
| 3 AI 生产中心 | ③④⑤ | 同一需求上下文驱动三条生产线：原型线 · UI 线 · 代码线，各自「草稿 → 结构编辑 → 预览 → 版本」；三线状态总览；每线内嵌「AI 草稿 → 人工 diff 放行」工位 |
| 4 协作评审中心 | 横切回路 | 四类产物预览评审 · 新旧 diff 视图内完成通过或驳回 · 锚定位置评论与标注、意见一键转任务 · 阶段确认与责任记录（可回放） |
| 5 变更追溯中心 ★ 差异化核心 | 横切 | 产物血缘图谱主视图（需求为根、显式建边、节点钻取）· AI 变更冲击波：沿血缘计算波及节点 + 影响等级（红＝必改／黄＝需评估）+ 逐节点理由 · 更新范围由人勾选后定向派发 · 回滚至历史基线 · 变更时间线可回放 · AI 通知稿（发送前可编辑） |
| 6 测试与验收交付 | ⑥ | AI 验收用例生成（由需求条款派生、回指条款）· 功能与多端检查 · 缺陷登记与回归 · 验收确认 → 发布包、交付清单、项目归档 |
平台支撑带（横切能力，非独立页面）：AI 能力 8 项（逐项定义可感知／可控／可恢复与失败降级）· 角色权限矩阵 · 版本治理（基线／产物版本／diff／回滚／审计）· 集成能力（标注为 V2 接口预留）。
页面地图（9 屏）
| 页面 | 主要跳往 |
|---|---|
| 项目工作台 | 需求中心、评审放行、血缘图谱、验收中心 |
| 需求中心 · 列表 | 台账导入、需求详情 |
| 台账导入 · AI 结构化 | 需求中心 |
| 需求详情 · 基线 | AI 生产中心、血缘图谱 |
| AI 生产中心 | 评审放行、需求详情 |
| 评审与放行（diff） | AI 生产中心、血缘图谱、工作台 |
| 血缘图谱 · 变更冲击波 hero | 评审放行、变更中心 |
| 变更追溯中心 | 血缘图谱、需求详情 |
| 验收交付中心 | 需求详情、工作台 |
05 / 业务流程四步主链，变更是第三步
把需求接进来→让 AI 先干一遍→变更来了看得见→验收收口
泳道与判断节点见 04 章手绘架构图；AI 在流程中占一条独立泳道——产草稿、算影响，但不做决定。
- 把需求接进来：台账导入或表单提交 → AI 结构化（字段带置信度、逐字段可改）→ 多角色评审 → 确认基线，生成版本 v1。
【判断】解析失败 → 转人工空白表单，链不断。评审不通过 → 驳回 → 修改中 → 重新提交。 - 让 AI 先干一遍：基线触发三条生产线 → AI 草稿（分步进度可见、带草稿水印）→ diff 评审 → 放行后挂入血缘，旧版本标「已过时」。
【判断】草稿失败 → 工位转人工。评审驳回 → 意见自动生成一条定向待办。 - 变更来了看得见（题眼）：提交变更单 → AI 冲击波沿血缘点亮波及节点（红／黄 + 逐节点理由）→ 人勾选更新范围（可剔除误报）→ 仅对勾选节点定向派发 → 逐项重审 → 形成新基线 → 波纹熄灭、时间线归档。
【判断】影响分析失败 → 直连节点全标「待人工评估」，可手动勾选派发。【异常出口】变更取消或回滚至历史基线，回滚事件写入时间线。 - 验收收口：AI 由条款派生用例 → 执行、缺陷登记与回归 → 验收确认 → 发布包与交付清单 → 归档。
【判断】验收不通过 → 缺陷修复 → 回归；再否 → 拒收 → 回退实现中。
为什么第三步是心脏
前两步任何工具都能做，第四步是标准测试管理。只有第三步回答了题面必答题眼——「展示需求变更后的协同更新过程」。变更冲击波把这个过程从「产品经理挨个私聊」变成一次屏幕上看得见的传播：谁被波及、为什么被波及、改的是哪一版上的哪一点，全部有据可查。
06 / 版本规划状态机即验收清单
V1 · 端到端六环节全通（本次交付范围）
| 范围 | 取舍依据 |
|---|---|
| ★ 血缘图谱 + 变更冲击波 + 变更闭环 | 题眼必须在 V1；同时喂交互设计、功能完整与 AI 创新三处评分，排期最高优先 |
| 六环节主链：需求中心 · 三条生产线 · 评审回路 · 验收交付 | 六环节可点可演是硬要求；评审回路是「审核确认」机制的落点 |
| 开场镜头：台账导入 AI 结构化 | 直击题面 Excel 痛点，也是 AI 应用能力的第一份证据 |
| 工作台：概览、待办、协作动态、角色切换 | 角色职责与权限是题面硬要求；角色切换替代登录 |
| 版本治理：基线／产物版本／回滚／时间线／责任记录 | 版本管理与变更追溯是题面五大机制之二 |
| 风险与指标：风险提醒、指标仪表盘、插单预估、AI 通知稿 | 价值主张在产品内可度量；插单直接回答题面「临时新增」 |
V1.5 · 增强不改主链
| 功能 | 为什么排在 V1 之后 |
|---|---|
| 多项目并行与组合视图 | 演示只需单项目讲透闭环，多项目不新增机制证明力 |
| 批量评审与批量派发 | 效率优化，依赖真实使用量才有价值 |
| 用例库与覆盖率视图 | V1 已有用例—条款回指闭环，深化属测试管理专业化 |
| 通知渠道扩展与提醒偏好 | V1 站内通知已闭环，渠道扩展是触达问题非机制问题 |
V2 · 真实集成（Demo 内标注接口预留）
Git 仓库集成（commit 回链需求）· 设计工具源文件同步 · CI 真实构建状态 · IM 消息渠道 · 制品库 · 真实 AI 模型在线推理。共同理由：这些是工程题不是产品题——机制在 V1 已用确定性 fixture 完整验证，提前投入不增加产品说服力。
排期总则
- P0 先行：血缘图谱与冲击波 → 台账导入 → 六环节主链 → 评审回路与版本治理 → 验收闭环。
- 状态机即验收清单：四组状态机的每个状态都必须可确定性触发，这是 UI 状态矩阵与 QA 的输入。
- 升级不破坏契约：V1.5 与 V2 不改一级模块命名与对象模型，只做能力增量。
07 / 验收口径可确定性触发的验收条件
| 类别 | Given / When / Then |
|---|---|
| 需求接入 | 点击「导入台账」并确认后，展示解析进度并列出批量结构化需求，每条带字段置信度标注 |
| AI 解析失败态被触发时，展示失败说明并提供「转人工空白表单」入口（可恢复） | |
| 待评审需求点击「确认基线」后状态变为已确认，生成版本记录 v1 | |
| 血缘与冲击波 题眼 | 已确认需求打开血缘图谱，展示需求为根、原型／UI／代码／用例／验收为派生的关联图，节点可点开详情 |
| 修改一条验收条款并保存后，血缘图上受影响节点按红／黄等级依次点亮，每个节点附影响理由 | |
| 剔除一个误报节点并确认范围后，系统仅对勾选节点生成定向任务并派发到对应角色工位（可控） | |
| AI 影响分析失败态被触发时，直连节点全部标记「待人工评估」，且可手动勾选派发（可恢复） | |
| AI 生产与放行 | 点击「生成草稿」后展示分步生成进度，产出带草稿水印的版本（可感知） |
| 在新旧 diff 视图点击「放行」后版本变为已确认、挂入血缘，旧版本标记为已过时 | |
| 填写意见并驳回后版本变为修改中，意见生成一条定向待办任务 | |
| 版本与追溯 | 打开变更时间线可回放从提出到新基线的全部节点，含操作人与时间 |
| 选择「回滚至历史基线」并确认后，需求与关联产物恢复至所选基线，时间线记录回滚事件 | |
| 预览 AI 通知稿并编辑发送后，发送记录写入变更时间线 | |
| 角色与验收 | 以设计师角色进入工作台，仅展示该角色的待评审／待放行／变更任务聚合 |
| 点击「生成验收用例」产出可编辑清单且每条回指需求条款；缺陷修复后标记回归通过，需求变为已完成并生成归档记录 | |
| 边界 | 项目内有进行中基线时提交临时新增需求，展示冲击摘要且不阻断提交 |
| 新项目无需求时，需求中心展示空态引导与「导入台账」入口 |