先建立一个能够每周产生产品判断的三人工作单元。两周结束时，三人能够共同解释：哪个用户遇到了什么问题、有什么证据、比较过哪些解法、验证改变了什么判断、下一步由谁做什么。
上一版的政企优先、SKU 收敛、R3 门槛、品牌与90天计划保留为历史提案。它们没有获得 Jack 认可，本轮不将其作为三人小组必须执行的前提。已有项目事实、产品资料和运行记录仍可按需使用。
首轮同时推进一个发现问题。通过后再安排一个小规模交付切片；交付进行时，发现工作围绕下一项不确定性展开，数量服从实际人力。
| 角色 | 对结果的主要责任 | 每轮牵头动作 | 必须共同参与 |
|---|---|---|---|
| 产品经理 | 问题是否值得解决，目标和范围是否清楚 | 选择问题、组织用户接触、汇总业务证据、记录取舍 | 现场观察、方案比较、验证复盘 |
| 设计师 | 用户是否理解，流程能否完成 | 还原现有任务流、制作低成本原型、观察操作障碍 | 问题定义、方案发散、技术边界讨论 |
| 工程师 | 现有系统能否支持，成本和失败方式是什么 | 查版本/API/数据，做关键技术验证，提出更小的实现路径 | 用户接触、问题定义、原型比较 |
三个人从第一次看问题就参与。工程师可以提出产品方案，设计师可以质疑需求价值，产品经理必须了解实现约束。
如果现有三位同事岗位名称不同，按上述三类责任映射；一人可以兼任职责，但仍要有人明确负责价值、体验和可行性三个角度。此表不代表必须新增三个岗位。
Jack 暂作为发起人：约束首轮问题范围、可投入时间和需要升级处理的决策。在没有指定日常决策负责人前，不假设 Jack 同时承担产品经理岗位。
销售、交付、营养师、财务和测试按具体问题提供事实或专业评审，不必每次全员参会。
| 步骤 | 三人一起做什么 | 留下什么 | 何时进入下一步 |
|---|---|---|---|
| 选问题 | 从一条反馈、一次现场故障或一个用户行为开始，明确服务对象和受阻任务 | 一句话问题、来源、要改善的结果 | 能说清用户现在怎样处理，缺什么证据 |
| 看事实 | 看同一场实际操作或同一份脱敏记录；区分客户原话和团队解释 | 现有流程、失败点、反例 | 对事实一致；对成因可保留不同解释 |
| 比方案 | 三人先独立写候选，再共同比较至少三种不同办法 | 方案差异和最危险假设 | 明确先检验哪个假设，为什么 |
| 做验证 | 选能回答关键问题的最小方法：操作观察、原型任务、数据核对或技术试验 | 方法、样本、事先标准、实际结果 | 有行为或技术证据；意见反馈单独标明 |
| 做决定 | 决定继续、修改、补证或停止，指定下一负责人 | 一条决策与依据 | 进入开发时才展开需求与验收；补证项不假装已完成 |
分歧处理：把争论写成可验证的问题。例如“用户看不懂”可以用无提示操作观察验证；“接口已经支持”必须回读实际版本和响应。价值与优先级由指定产品决策负责人裁决；设计与工程负责人分别对自己的证据负责。付款、身份、数据等硬约束不能被多数表决跳过。
以下使用工作日D1—D10；起点是三位成员及投入时间确定后的第一个工作日，不将本稿日期当成已经启动。
| 时间 | 产品经理 | 设计师 | 工程师 | 共同成果 |
|---|---|---|---|---|
| D1 | 带来三条候选问题和原始来源 | 标注涉及的用户任务 | 标注系统依赖及可观察性 | 30分钟选定一个问题与负责人 |
| D2—D3 | 协调已有客户/同事提供真实经历 | 主持操作观察，记录停顿与误解 | 同场观察，核对后台和设备条件 | 一张现状流程与证据记录 |
| D4 | 提出业务/服务方案 | 提出流程/交互方案 | 提出现有配置或技术方案 | 45分钟比较至少三种解法 |
| D5 | 写清实验决策标准 | 做能验证关键动作的原型 | 检查数据来源，做必要技术小试验 | 一个可执行实验 |
| D6—D8 | 记录参与者背景和业务反馈 | 观察任务完成，不提示答案 | 记录技术结果和异常 | 真实观察结果；不足处明确记缺口 |
| D9 | 汇总价值与优先级建议 | 汇总体验问题及修订建议 | 汇总可行性、代价和依赖 | 三人共同写出判断 |
| D10 | 记录决定及下一负责人 | 确定体验切片 | 确定技术切片与验证方式 | 30分钟决定继续、调整或停止 |
容量建议：每人每周先预留3—5小时发现时间，包含观察和小试验，不包含正式研发。共同会议控制在约2小时以内，其余异步准备或现场验证。若只能每人投入1小时，则延长周期或缩小验证问题，不承诺同样产出。
真实用户接触由具备联系权限的同事安排。暂时无法接触用户时，可以做历史回放和内部演练，但本轮结果只证明流程/技术可行性，用户价值仍待验证。
从现有材料选择了三个容易找到工作现场的入口。下表是候选，不是新产品方向或已下达任务。
| 候选问题 | 为什么适合三人共同做 | 先取什么证据 |
|---|---|---|
| 用餐者看完膳食记录，能否理解记录并决定下一餐怎么选？ | 产品判断行为价值，设计观察理解与选择，工程核查饮食数据及现有页面 | 现有食动日历/膳食记录、实际版本、用户操作 |
| 食堂工作人员发现扣费或退款差异，能否找到原因和下一步处理人？ | 产品理解业务损失，设计梳理查账路径，工程核对订单/账户状态 | 一个已脱敏真实异常及其处理记录 |
| 售前拿到客户需求，能否在一次协作中判断已有能力与待评估项？ | 产品确认业务范围，设计呈现选项，工程判定真实复用条件 | 最近一单需求原文、现有功能和修改记录 |
建议先考虑第一个候选，因为已有食动日历、膳食记录和下一餐决策的资料入口，便于取样。最终选择以“能否接触实际用户、拿到真实流程、两周内完成验证”为依据；已有执行中的需求继续沿用原负责人和任务编号。
以第一个候选示范三种解法：A保持现有页面，增加人工讲解；B调整记录的标签、解释及层级；C增加基于已有供餐选项的下一餐提示。三人比较哪些问题可通过内容和交互解决、哪些需要数据能力。尚未选择C，也未授权开发。
首轮验证问题可收敛为：用户能否无提示找到指定一餐、正确解释记录的范围、找到可以进一步操作的入口。小样本只用于发现问题，不用于推断总体转化率或健康效果。
保留一个工作项与一个文档，已有任务直接复用编号。每人更新自己负责的部分，日常不再重复制作三份报告。
| 字段 | 填写要求 |
|---|---|
| 问题 | 谁在什么情境下完成什么任务时受阻 |
| 证据 | 原文/操作/版本及日期；事实与解释分开 |
| 候选方案 | 至少三种解法、代价、关键假设 |
| 本轮验证 | 方法、负责人、时间、事先判据、实际结果 |
| 决定与下一步 | 继续/调整/补证/停止，依据、下一负责人、检查日期 |
附在同一记录上的内容只有原型、技术核对和原始证据链接。人名未定时标“待分配”，不录成正式任务指派。
三人对同一问题负责，Codex辅助整理材料、比较方案和记录变化。AI生成的三种角色观点属于分析建议，不算三位同事已经讨论或签字。
| 工作 | 使用的本地能力 | 人的责任 |
|---|---|---|
| 整理反馈与候选问题 | analyze-feature-requests | 核实来源、选择本轮问题 |
| 从价值、体验、技术发散 | brainstorm-ideas-existing | 各自提出方案并挑战假设 |
| 找最危险假设并排序 | identify-assumptions-existing、prioritize-assumptions | 确定优先验证什么 |
| 设计最小实验 | brainstorm-experiments-existing | 确定样本、判据与执行条件 |
| 连接结果、问题、方案和实验 | opportunity-solution-tree | 保持树与真实证据同步 |
这些Skill按阶段调用即可，不要求每次跑满13个。OST首轮只画“一个结果—一个问题—三种方案—一个实验”。
三位同事可分别给Codex这样的输入：
先评价这套协作是否跑通：三人是否接触了同一份真实证据；是否比较三种解法；是否在验证前写下判据；是否记录反例；是否共同形成一次有依据的取舍。
再评价业务发现：用户问题、体验障碍、数据和技术条件分别得到什么新证据。如果仅完成内部演练，则继续补用户证据。如果方向成立且依赖可关闭，再把选定方案写成可执行Use Case、小范围需求与验收标准，交回已有研发流程。
连续完成两轮后，才根据容量固定每周节奏。市场选择、SKU、品牌和长期资源投入应作为后续三人协作需要支持的决策，单独使用相应证据讨论。
规划已形成；三人身份、可投入时间、首题选择和启动日留待实际组队时确定。这些信息不影响先讨论协作方式。