菜单
场景驱动开发（Scenario-Driven Development）。动手之前，先想清楚三层：场景是什么、用户真正需要什么、我在这个场景里是什么角色。 适用于：启动新项目、从零设计功能、方向不明确需要先想清楚、产出的东西"逻辑没错但不对味"、不知道是给谁用的、需求模糊但被要求马上动手、做完了用户说"不是我要的"。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："SDD一下"、"想想场景"、"设身处地想想"、"这个是给谁用的"、"用户会怎么用"、"先别急着做，想想为什么"、"需求不太清楚"、"总觉得哪里不对"、"做之前先想想"。 不适用于：已有明确方向和清晰用户画像、只需执行的场景。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Agent 记忆与工作流增强套件。包含 8 个模块：记忆系统（memory-deposit、retrieval-enhance、noise-reduction）+ 工作流（hdd、sdd、save-game、load-game、project-skill-pairing）。当用户说"安装 ClaWiser"、"初始化 ClaWiser"、"运行 ClaWiser"时触发。
Hypothesis-Driven Development (HDD) — 假设驱动开发方法论。当任务涉及不确定性时激活：诊断问题根因、排查 bug、方案选型、架构变更、或任何"试了几次都不对"的场景。 也适用于：用户不确定该怎么做、反复尝试没有进展、需要在多个方案之间做选择、怀疑某个假设但没有验证、或者问题的根因不明确时。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："用 HDD"、"先验证一下"、"这个问题到底是怎么回事"、"为什么不 work"、"搞不定"、"试了好几次都不行"、"不确定该用哪个方案"、"帮我排查一下"、"按 TDD 方式"、"先别急着改，想想为什么"。 不适用于：指令明确、结果确定的简单编辑（改文案、加 import）。
记忆系统搭建与健康检查（Memory Deposit）。检查并补齐 6 层记忆系统，确保 workspace 的记忆配置完整。缺什么补什么，已完成则报告状态。可反复执行。 适用于：首次安装后初始化记忆系统、怀疑记忆功能不完整、想知道当前记忆系统的健康状态、或发现 agent 的记忆行为异常（忘事、不记录、记录格式混乱）。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："检查记忆系统"、"memory deposit"、"记忆配置"、"记忆力怎么样"、"为什么老忘事"、"记忆系统健康吗"、"初始化记忆"、"补一下记忆配置"。
对话数据降噪（Noise Reduction）。诊断当前环境的噪声模式，编写降噪规则，验证降噪效果。 适用于：首次搭建降噪流程、新增聊天渠道后更新规则、记忆召回质量下降的排查——如果向量搜索搜不到应该搜到的内容，可能是对话数据里噪声太多、搜索结果不相关、记忆库里垃圾信息太多。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："降噪"、"清洗对话"、"noise reduction"、"信噪比"、"记忆力不行"、"搜不到东西"、"找不到过去的内容"、"搜索结果不相关"、"记忆乱七八糟"、"为什么搜出来的都不是我要的"、"对话记录太杂了"。
项目读档（Load Game）。从 HANDOFF.md 恢复项目上下文，对比计划与实际，识别偏差并调整。 适用于：Compaction 后恢复项目状态、接手别人/子 agent 的项目、Cron 定时检查、跨天/跨周恢复工作、或任何"上次做到哪了"的场景。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："读档"、"load game"、"恢复项目"、"review 进度"、"检查计划"、"上次聊到哪了"、"继续之前的项目"、"我们之前做到哪一步了"、"这个项目什么进度"、"把之前的上下文恢复一下"。 Agent 也应在 compaction 后、或被要求继续某个之前的项目时主动激活。
项目与 Skill 的双向绑定（Project-Skill Pairing）。新建 Skill 时挂靠项目，新建项目时关联 Skill，确保不出现孤悬的 skill 或缺少 skill 支撑的项目。 适用于：新建项目或 skill 后需要建立关联、发现 skill 没有归属项目、发现项目缺少配套 skill、整理项目结构时检查完整性。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："建个项目"、"初始化项目"、"新建 skill"、"project init"、"查缺补漏"、"项目结构"、"这个 skill 属于哪个项目"、"项目里缺什么 skill"、"整理一下项目和 skill 的关系"。 Agent 也应在创建或修改 Skill 后自动检查项目归属。
| name | sdd |
| description | 场景驱动开发（Scenario-Driven Development）。动手之前，先想清楚三层：场景是什么、用户真正需要什么、我在这个场景里是什么角色。 适用于：启动新项目、从零设计功能、方向不明确需要先想清楚、产出的东西"逻辑没错但不对味"、不知道是给谁用的、需求模糊但被要求马上动手、做完了用户说"不是我要的"。 当用户表达类似意图时触发——不限于特定措辞。常见表达举例："SDD一下"、"想想场景"、"设身处地想想"、"这个是给谁用的"、"用户会怎么用"、"先别急着做，想想为什么"、"需求不太清楚"、"总觉得哪里不对"、"做之前先想想"。 不适用于：已有明确方向和清晰用户画像、只需执行的场景。 |
| version | 0.3.0 |
| author | MindCode |
| tags | ["methodology","scenario-driven","clawiser"] |
先回答"谁在什么场景下怎么用"，再回答"怎么实现"。
常见错误：收到需求 → 直接开干 / 做技术方案 / 列功能清单。 正确顺序：收到需求 → 场景 → 需求 → 世界模型 → 判断依据 → 分步计划 → 然后才动手。
不管你做的是不是"产品"，这个思路都管用。写论文要先想清楚给谁看、论点是什么；做学习计划要先想清楚目标是什么、怎么判断有没有效；做方案要先想清楚对方在什么处境下看到这个方案。
对每一个场景，依次回答三个问题。顺序不能乱，后一层从前一层推导。
这件事发生在什么情境下？
不是"用户要一个什么功能"，而是描述真实的情境——谁、在什么时候、面对什么状况。场景要具体到一个画面。
检验标准：读完场景，一个不了解这件事的人能想象出"此刻发生了什么"吗？能 → 够了。
在这个场景下，用户真正需要的是什么？
需求不是解决方案。写需求时先否定一遍："不是 XXX，那是解决方案"。然后追问：他真正在问的问题是什么？
这一步的目的是把"我要一个 XX 功能"还原成"我面对的真正问题是什么"。方案可以有很多种，但问题只有一个。
在这个场景和需求下，我（agent）是什么？
这是 SDD 最关键的一层。世界模型定义了 agent 在这个场景中的身份，直接决定架构怎么设计。包含四个维度：
角色定位——我是什么，不是什么。同一个任务，"我是流水线工人"和"我是编辑"会推导出完全不同的架构。
能力构成——我有什么资源，哪个才是核心能力。工具和手段不是目的——要区分"我能做什么"和"我最该做什么"。
价值观——什么对我来说比什么更重要。当两个目标冲突时（比如覆盖率 vs 精准度），价值观决定取舍。
世界观——我对这个领域的基本认知。比如"信息服从幂律分布"这样的认知，会直接影响你设计全量扫描还是抽样处理。
因为它直接推导出架构。
没有世界模型时，架构是从技术习惯推导的——"我会做什么就做什么"。有了世界模型，架构从角色和价值观推导——"我应该做什么就做什么"。
同一个需求，不同的世界模型会推导出截然不同的技术方案。如果你发现技术方案和世界模型矛盾，说明技术方案错了，不是世界模型错了。
世界模型是架构的锚。
每个场景定义可验证的质量标准。标准要具体到能回答"怎么验"——不能验证的标准等于没有标准。
基于场景反推步骤：
不是按技术模块拆步骤，是按用户价值拆。
| 陷阱 | 表现 | 纠正 |
|---|---|---|
| 技术驱动 | "先做抓取，再做评分，再做推送" | 倒过来：推送什么样 → 需要什么评分 → 需要什么数据 |
| 功能堆砌 | 第一步就塞满功能 | 砍到只剩场景 1 能跑通的最小集 |
| 跳过场景 | 直接写任务列表 | 先写"用户每天看到什么" |
| 跳过世界模型 | 场景写完直接做技术方案 | 先回答"我在这个场景里是什么角色" |
| 假设未验 | "用 XX API 做搜索" → 没查过能不能用 | 每个关键假设走 HDD 验证 |
| 架构违反世界模型 | 世界模型说"覆盖率是约束"但方案在砍数量 | 回头检查世界模型，重新推导 |
完成 SDD 后，应产生：
memory/projects/<project>/）
关键检查点：技术架构必须从世界模型推导出来，不能反过来。
技术选型、架构设计在场景理清楚之后再做。
hdd（关键假设需要 HDD 验证）project-skill-pairing（product-plan.md 存入项目结构）