以目标作为一次产研交付的主线
选择： 每次交付从明确目标开始，再按六个阶段组织输入、产物、Agent 任务、评审和推进条件。
取舍： 开放式 Coding Agent 可以处理任意任务，但产研交付需要明确范围、阶段产物和验收责任，不能只依赖一次对话或任务执行。
公司项目 · 8 周跑通 MVP
AI 产研协同交付平台
目标驱动的产研协同与交付平台
面向产研交付场景的目标驱动平台：每次交付从明确目标开始，按六个阶段组织产物、Agent 任务、评审和版本。
我的工作：产品定义 · 流程/对象模型 · 交互设计 · 原型实现
从交付目标到 AI 变更评审。
用三个关键界面走完 AI 产研协同交付平台的主链路：先定义目标，再按阶段产出可评审产物，最后由人确认 AI 变更与版本。
正在加载界面… 
正在加载界面… 
正在加载界面… 01 / 03
交付与验证
8 周从需求沟通跑通 MVP，覆盖研发、产品、UI、测试与 Agent 等角色；协同 10 人团队，经历 6 轮以上管理层与产研评审。
- 8 周跑通 MVP
- 从需求沟通到六阶段产研交付链路形成可运行验证
- 10 人 · 6 轮以上评审
- 覆盖研发、产品、UI、测试、Agent 与管理层评审
8 周跑通 MVP，经历 6 轮以上管理层与产研评审。
项目覆盖 10 人协作团队，以及研发、产品、UI、测试、Agent 等角色；从需求沟通到可运行 MVP 的结论均经过跨角色评审。
项目性质
这是我入职北京中数智汇后参与推进的公司项目。我负责产品定义、对象模型、交互设计和原型实现，8 周从需求沟通跑通 MVP；项目覆盖 10 人协作团队和研发、产品、UI、测试、Agent 等角色，经历 6 轮以上管理层与产研评审。在线演示只使用模拟数据，不含公司或客户真实信息及内部代码。
关键产品决策
文档和原型独立管理
选择： 原始需求、PRD、原型和后续阶段产物分别保存，并记录版本和所属阶段。
取舍： 跨角色交接需要可以直接检查的产物，不能只依赖对话记录或一次性提示词。
AI 变更必须经过人工评审
选择： 先展示差异、受影响批注和未保存改动，由负责人决定放弃、迁移批注或应用到新版本。
取舍： 产品文档和设计产物会影响后续开发，AI 不能直接覆盖人工决策和已有讨论。
Agent 运行完成，不等于交付完成
选择： Agent 任务记录执行过程，产物、评审和阶段状态记录最终结论。
取舍： Agent 跑完任务后，仍需要有人检查产物并决定是否进入下一阶段。
从问题到交付
开放式 Agent 能执行任务，但不会自动定义一次交付如何被验收。
真实产研流程中的需求、设计、代码、测试、评审和上线分散在不同工具与对话里。只记录 Agent 是否运行完成，无法说明阶段责任、交付产物和推进条件是否满足。
核心问题：开放式执行能力与可验收交付之间缺少稳定结构。
先固定目标、阶段产物和人工决策点，再让 Agent 进入流程。
我把 Target 定义为一次交付的入口，用六个 Stage 组织输入、产物、Agent 任务、评审与版本。Agent 负责生成和修改，人负责确认范围、处理批注并决定是否推进。
关键取舍：不重做 Coding Agent，而是在外部建立交付结构与人工审核。
用 8 周跑通从需求沟通到 MVP 的完整链路。
项目协同 10 人团队，覆盖研发、产品、UI、测试与 Agent 等角色；MVP 串联六个产研阶段，并经过 6 轮以上管理层与产研评审。
当前可核验：8 周交付周期、10 人协作团队、6 轮以上评审与六阶段 MVP。
项目背景与实现范围
对象模型
- 交付目标
- 每次产研交付从一个目标开始，统一记录所属项目、当前状态和阶段进度。
- 产研阶段
- 按产品设计、研发设计、Agent Coding、研发自测、QA 测试和上线六个阶段推进。
- 阶段产物
- 原始需求、PRD、原型、技术设计和测试结果分别保存，并记录版本。
- Agent 任务
- 记录 Agent 的任务、运行状态和人工接管点，不用聊天记录代替交付结果。
- 评审 / 批注
- AI 变更先展示差异和受影响批注，由负责人确认后再生成新版本。
- 版本
- 保留产物版本、未解决批注和变更记录，方便回看和处理分歧。