代码工作流的”完成”是明确的——测试通过、构建成功、三方审查 APPROVED。产品方案的”完成”是模糊的——怎么判断一份竞品分析”够了”？
问题
PraestoClaw 的工作流引擎一开始只服务于代码链路：/实现、/测试、/修复、各种 /审查。它们有一个共同特点——产出物是确定性的。代码要么能跑要么不能，测试要么绿要么红，审查有标准化 checklist。
但产品上线不是从写代码开始的。在那之前有大量模糊的前置工作：市场定位、竞品分析、用户研究、产品设计、盈利模型。这些工作也需要多 agent 协作，也容易失控，但它们的性质和代码工作流完全不同。
我们需要一种新的工作流来处理”想清楚”这件事。
代码工作流 vs 产品方案工作流
| 维度 | 代码工作流 | 产品方案工作流 |
|---|---|---|
| 产出物 | 代码 + 测试 | 文档 + 线框图 |
| 质量标准 | 测试通过、构建成功 | 结构完整、逻辑自洽 |
| ”完成”的判定 | 自动化门禁 | 人工+清单 |
| 迭代方式 | 修复→重跑测试 | 补充→重新审查 |
| 典型失败 | 编译错误、测试失败 | 遗漏场景、假设未验证 |
最大的差异在于门禁。代码工作流的门禁可以是一个 npm run test，但产品方案没有自动化测试。你不能 assert(竞品分析.深度 > 阈值)。
设计：/产品方案 工作流
最终设计是一条 6 节点的串行链路，加上架构师可行性审查和人工审批：
战略定位 → 竞品分析 → 用户研究 → 产品设计 → 宣传运营 + 盈利模型 → MVP 设计 + 线框图 → 架构师可行性审查 → plan-ready-checklist → 人工确认三个关键设计决策：
1. 用户研究必须区分事实和假设
产品方案中最危险的错误是把假设当事实。Agent 特别擅长写出看起来很有说服力的用户画像——但那些数据是从哪来的？
我们要求用户研究节点的输出必须分三层：
- 已知事实：有数据来源的信息（竞品公开数据、行业报告）
- 推断判断：基于事实推导的结论（标注推导过程）
- 待验证假设：需要上线后验证的假设（标注验证方法）
这不是审查标准，而是输出格式要求——写进了 agent 的 prompt 里。
2. 线框图作为产出物纳入工作流
产品方案不只是文字。页面长什么样、交互怎么走，这些在方案阶段就应该有具体形态。
我们让产品 agent 输出 HTML 线框图（不是设计稿，是低保真结构图），然后由截图 agent 自动逐页截图并发到群聊。这样人类可以直接看到”这个方案落地后大概长什么样”，而不是在脑子里从文字想象。
架构师的可行性审查也会检查：线框图是否覆盖了 MVP 的所有页面和模块。
3. 边界：只做方案，不做设计
最初的版本想把视觉设计（配色方案、风格板）也塞进来。讨论后砍掉了。
理由很简单：产品方案的目标是”想清楚要做什么”，视觉设计是”想清楚长什么样”。两个问题的协作模式、参与者、评审标准都不同。混在一起会让工作流变成一个什么都管但什么都管不好的庞然大物。
一个工作流只解决一个问题。
节点粒度：超时炸掉的不只是一个节点
这是最痛的教训，也是最实用的。
第一版设计中，产品 agent 的工作只分了两个大节点：
# v1：两个大节点- id: strategy-and-research prompt: "完成战略定位、竞品分析、用户研究"
- id: design-and-planning prompt: "完成产品设计、宣传运营、盈利模型、MVP 设计、线框图"问题是什么？Agent 节点有超时限制。当一个大节点在做到”用户研究”时超时了，前面已经完成的”战略定位”和”竞品分析”也一起丢失，重跑要从头来。
超时的爆炸半径（blast radius）等于节点的粒度。
拆成 6 个小节点后：
# v2：六个小节点- id: strategy # 战略定位- id: competitor # 竞品分析- id: user-research # 用户研究- id: product-design # 产品设计- id: biz-model # 宣传运营 + 盈利模型- id: mvp-wireframe # MVP 设计 + 线框图超时只影响当前节点。前面完成的节点有持久化的产出物，不需要重跑。
这个原则不只适用于产品方案工作流。回头看代码工作流，同样的问题也存在——只是代码节点通常执行更快，超时概率更低，所以没有那么疼。
规则：如果一个节点超时会导致其他已完成工作的返工，这个节点就太大了。
plan-ready-checklist：模糊产出的硬门禁
产品方案没有 npm run test，但不代表不能有门禁。我们设计了一个 plan-ready-checklist，由架构师在可行性审查阶段检查：
- 战略定位有明确的差异化点
- 竞品分析覆盖直接竞品和间接竞品
- 用户研究区分了事实/推断/假设
- 产品设计覆盖核心用户旅程
- 盈利模型有盈亏平衡点计算
- MVP 设计有明确的功能范围
- 线框图覆盖 MVP 页面/模块清单
不是自动化的，但是结构化的。未通过的项目会触发对齐循环——和代码审查的修复循环逻辑一样。
回头看
/产品方案 工作流上线的时间点（2026-04-15）距离工作流引擎本身的建设（2026-04-09）只有 6 天。但这 6 天里，工作流引擎从”代码协作工具”变成了”通用协作工具”。
关键转变：
- 不是所有产出物都能自动化验证——接受这一点，设计结构化但非自动化的门禁
- 节点粒度是超时恢复的核心参数——不只是”好的实践”，是”少返工的唯一办法”
- 工作流的边界要克制——一个工作流解决一个问题，不要贪
下一步可能是把这个模式推广到更多非代码场景：设计审查工作流、内容发布工作流、合规检查工作流。但那是下一次进化的事了。