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