好的探索工作坊不是开长会，而是用议程把决策、风险与非目标逼到台面上
项目失败很少因为「不会写代码」，更多是探索阶段大家以为对齐了：预算理解不同、成功指标各说各话、必须有的集成拖到开发第二个月才出现。可上线把 Discover 定义为可交付的阶段——工作坊是其中的高频工具：在设计与开发大举投入前，用结构化议程换来场景、约束、优先级与书面非目标。无论是品牌站、B2B 产品、AI 功能还是 Web3 外壳，议程骨架相似，深挖题不同。下文给出可复制的探索工作坊议程模板、角色与时间盒、必出文档，以及如何避免变成需求倾倒会。适合代理主创、甲方产品与业务负责人直接改时间表使用。
会前 72 小时：没有预读就不要开会
发给双方的预读包：业务一页纸（用户、收入/效率假设、截止压力）、现有资产清单（品牌、域名、后台、数据）、约束（合规、地域、技术栈偏好）、决策人名单。甲方准备 5–10 个真实用户问题或工单样例；代理准备竞品与风险初稿。确认与会者：能拍板范围的人必须在场至少关键决策段，否则议程改成「只收集、不冻结」。时间盒与会议室/视频规则写进邀请，禁止「顺路再拉十个人旁听却不发言」。
角色：谁主持、谁记录、谁有否决权
主持（代理侧资深）控时间与冲突；记录（可轮换）只抓决策与开放问题，不记流水账；甲方产品/业务 Owner 对优先级有否决与拍板；技术主答可行性；设计主答体验风险。明确「议题停车场」：跑题想法进列表，会后处理。禁止所有人同时改同一份幻灯——主文档一份，实时共享，散会 24 小时内整理为正式纪要。
半天版议程（启动与范围粗对齐）
0:00–0:20 目标与成功指标草案（可量化）。0:20–0:50 用户与关键场景（最多 3 条主路径）。0:50–1:20 约束与非目标（明确不做）。1:20–1:50 信息架构/系统边界草图。1:50–2:20 风险与依赖（第三方、内容、法务）。2:20–2:50 优先级与版本切片（MVP vs 后置）。2:50–3:00 决策清单确认与下一步。中间短休一次。半天版适合已有简报的品牌站或小迭代；复杂 AI/多端产品请用一天或两天。
一天版：加上旅程与验收口径
上午在半天骨架上加深用户旅程与痛点证据（数据或访谈摘录，禁止纯想象人设）。下午：内容/数据来源表、集成清单与环境假设、体验原则（可访问性、多语言、性能预算意向）、验收与上线门禁草案（含「谁点头算上线」）。若含 AI，单列风险红线与评测集责任人；若含 Web3，单列钱包与合规叙述边界；若含 App，单列商店与推送责任。一天结束必须有「待确认问题」编号表，而不是「大家再想想」。
两天版：共创方案选项与商业约束
第 1 天对齐问题空间；第 2 天早上方案选项（至少 2 个：保守/进取），下午对照预算、工期、团队产能做选择，并草签范围边界。创业伙伴或股权换开发类合作（可上线 Startup Partnership）须在第 2 天把商务假设与交付节奏分开讨论，避免技术范围被未谈拢的股权条款绑架。两天版产出应接近可写 SOW 的材料，而不是更多便利贴。
必须带出会场的六份产物
1）成功指标与反指标；2）场景卡（用户、触发、步骤、失败态）；3）范围内外列表；4）依赖与风险寄存器；5）决策日志（决定/日期/人）；6）后续两周计划（谁交付原型/技术spike/内容）。可选：粗日历与角色 RACI。没有书面非目标的工作坊，等于鼓励范围蠕变。纪要里用原话记录争议，避免主持者美化成「已一致」。
常见翻车：倾倒会、设计评审冒充探索、没有冻结点
倾倒会：每人讲二十分钟部门诉求，无优先级框架——用强制「只保留三个 MVP 场景」打断。设计评审冒充探索：还没定问题就盯视觉——主持拉回指标与场景。没有冻结点：会开完继续加需求——在纪要写「变更走正式变更单，影响工期与费用」。远程工作坊更要限制幻灯页数，改用协作文档与计时器；跨中英与会者时，决策句双语书写，避免翻译歧义进合同。
工作坊之后：如何接上设计与开发
24 小时内发出纪要与开放问题；72 小时内甲方书面确认或提出异议。确认后进入 design：旅程细化、线框、若需要则技术 spike 并行。build 不开始于「再开一次对准会」，而开始于已签字的范围与验收草案。可上线流程是探索→设计→开发→上线；工作坊是探索的加速器，不是跳过合同与报价的仪式。若你需要主持与双语文档模板，可带着现有简报来找可上线，把议程直接改成你的项目日历。
可执行清单
- 1会前预读包、决策人档期与样例问题/工单就绪
- 2按项目复杂度选择半天/一天/两天议程并公开时间盒
- 3产出六件套：指标、场景卡、范围内外、风险、决策日志、两周计划
- 4书面非目标与变更控制语句写入纪要
- 524h 纪要 / 72h 确认后进入设计，不以「再对齐」替代签字范围
核心要点
- 探索工作坊议程模板的价值是逼出决策与非目标，而不是填满日程表。
- 会前预读与会后确认节奏，比现场氛围更能决定项目是否少返工。
- 复杂度升级议程时长；AI/多端/链上议题要有专属决策段，避免被一般需求淹没。
常见问题
- 甲方只能派执行层参加怎么办？
- 改为收集型工作坊，明确「不冻结范围」；另约 30–45 分钟决策人评审决策日志。避免假装已对齐却在报价后被上层推翻。
- 已经有详细 RFP，还要开探索工作坊吗？
- 要，但可缩到半天：焦点放在矛盾需求、验收口径、依赖与非目标。RFP 很少记录「做什么会毁掉项目」的反指标。
- 远程与线下哪种更好？
- 有高冲突优先级或多部门政治时优先线下；信息收集与跨国时区可用远程，但要更短时间盒与更强书面化。混合式时决策段尽量同步在场。