| name | discover-unknowns-zh |
| description | Chinese workflow for surfacing systematic fact, evidence, context, and blind-spot gaps before, during, and after agentic work. Use when the user explicitly asks for a blind-spot scan, unknown unknowns, prototypes, reference mapping, implementation notes, explainers, or quizzes; when phrases like "I'll know it when I see it" or "teach me this domain" expose unstated assumptions; or when safe progress is blocked by evidence gaps that require multiple low-cost probes. Do not use merely because work is complex, high-risk, long-running, or spans multiple files. |
发现未知项
何时使用
当任务命中以下任一信号时启动本 skill：
- 系统性缺口：安全推进需要多次低成本调查才能补齐事实、证据、上下文或盲点。
- 用户原话：“我看到才知道”“教我这个领域”“做盲点扫描”“未知的未知”“先别动代码”。
- 工件请求：盲点扫描、访谈、原型、参考物映射、实施计划、实现记录、说明文档、变更测验。
- 假设风险：任务若不先澄清未知项，会迫使 agent 做大量未言明假设。
复杂、高风险、多文件或长周期本身不是触发条件。任务很窄、未知项很少，或事实可由一次直接检索获得时，跳过本 skill，回到最短适用闭环。
概览
使用这个 skill，把系统性事实、证据和盲点缺口拆成一组低成本调查工件，在真正修改生产代码前暴露假设和判断差异。
把用户提示、计划、skills 和上下文视为“地图”。把真实代码库、用户、约束、质量标准和评审过程视为“领地”。地图和领地之间的差距，就是需要持续发现和管理的未知项。
未知项分类
把不确定性分成四类：
- 已知的已知：用户在提示里已经说清楚的——想要什么。
- 已知的未知：用户还没想明白，但知道自己没想明白。
- 未知的已知：太显而易见、用户绝不会写进提示，但看到示例就能认出来的——品味、判断、是否对味。
- 未知的未知：用户压根没考虑过的——缺失的概念、隐藏约束、失败模式、历史方案、质量标准，以及“自己是否知道好的标准长什么样”。
目标是在动手前缩小代价最高的几类。若任务很窄、未知项很少，保持轻量，不要制造流程负担。
阶段速查
| 阶段 | 优先工件 | 主要暴露 |
|---|
| 动手前 | 盲点扫描（unknowns.md）、头脑风暴、原型（prototype.html）、访谈、参考物、实施计划（implementation-plan.html） | 未知的未知、未知的已知、已知的未知、可变决策 |
| 动手中 | 实现记录（implementation-notes.md） | 偏离计划、边界情况、保守选择、暂缓问题 |
| 动手后 | 说明文档（explainer.html）、测验（quiz.html） | 行为变化、验证证据、剩余风险、评审理解缺口 |
工作流
-
说明起点
- 提炼用户想要什么、已经知道什么、还不知道什么。
- 只有当用户经验水平会影响问题或质量标准时，才询问用户经验。
- 检索必要的代码、工件和外部资料，让判断落在真实上下文上。
-
做盲点扫描
- 列出可能的未知的未知：隐藏集成、数据模型约束、UX 预期、性能陷阱、安全问题、迁移风险、历史实现、测试缺口和评审反对点。
- 说明每个盲点为什么重要，以及最低成本的验证方式。
- 优先使用代码搜索、现有测试、文档、日志、截图或小实验，避免凭空猜测。
- 直接用“盲点扫描”和“未知的未知”这两个词，能更好地触发正确行为。
-
选择最低成本工件
- 范围或策略不确定时，用头脑风暴。它还能防止范围定得过窄或过宽。
- 用户需要“看到才知道”时，用原型暴露未知的已知，例如视觉品味、交互手感、文案或流程形状。在实现阶段才发现这些代价相对较高——规格小改可能导致代码大改，且回滚更难。
- 某个答案可能改变架构、数据模型、API、UX、灰度或风险策略时，用访谈。
- 用户描述不清但能指出代码、文档、截图、示例或历史方案时，用参考物。源码是最强参考物。
- 任务已经因高风险或用户显式 opt-in 进入完整流程时，用实施计划；不要因为下一步会触碰生产代码或多文件改动就自动创建实施计划。
-
让计划保留转向空间
- 计划开头先放用户最可能调整的决策：数据模型、类型/接口、UX 流程、安全边界、灰度和兼容性。
- 机械重构和显然的编辑放最后。
- 明确 agent 可以自行决定什么，哪些必须回到用户审阅。
-
记录实现中的发现
- 对较大的任务，在工作区保留临时
implementation-notes.md（或 .html），除非用户另有要求。
- 记录偏离计划的地方、发现的边界情况、保守选择和暂缓问题。
- 如果新发现推翻原计划，暂停并修订计划，不要强行按旧路径推进。
-
实现后闭环
- 当评审者、干系人或未来维护者需要快速理解变化时，产出说明文档。它能加速那些和你起点同样有未知项的评审者的理解，也能让专家更快确认你已考虑到他们预判的常见失败点。
- 包含改了什么、为什么这么做、关键决策、已解决的未知项、已知风险、验证证据和如何评估结果。
- 对大改或隐性行为变化，用测验检查用户或评审者是否真正理解。把通过测验当作合并闸门，不是走过场。
决策规则
- 小修小改、明确 bug、机械替换：不用本 skill，直接走最小实现闭环。
- 用户显式请求盲点/未知项工件，或安全推进被系统性事实、证据、上下文缺口阻塞时：使用本 skill。
- 任务对用户或 agent 陌生且一次直接检索不足以补齐证据时，先做盲点扫描。
- 用户不知道某领域“好的标准”长什么样时，先让 agent 教你这个领域，而不是让它生成一堆变体让你挑。
- 用户表达“我看到就知道”时，先做原型再实现。
- 单个答案暴露高风险边界时进入
brainstorming；排除高风险后仍阻塞实现的用户决策交给 grilling。
- 有强参考物（尤其是源码）时，先读参考物再设计新模式。
- 实现中暴露重大未知项时，更新工件链路，不要隐藏假设。
- 长周期任务跑回来结果不对时，多花时间定义未知项或重写计划让 agent 能即兴处理，而不是直接重试。
- 任务简单时，只使用最小有用步骤，不做仪式化流程。
- 当已知的未知已清空，或剩余未知项都有低成本检查路径且不会改变关键架构、数据、API、UX 或安全边界时，退出本 skill，返回
skills/using-superpowers/SKILL.md 重新路由；不要用固定的后续 skill 枚举代替路由器。
工件
只在工件能降低风险或加速评审时创建。需要用户做反应的工件（原型、计划、说明、测验）优先用单文件自包含 HTML：好分享、好截图、能直接丢进 Slack 或评审线程，且上下文丰富又不至于淹没提示。
unknowns.md：未知项分类表、问题、检查方式和决策。prototype.html：用于品味、布局或流程反馈的低成本原型，用假数据、不接后端。implementation-plan.html（或 .md）：围绕可变决策组织的可审阅计划。implementation-notes.md（或 .html）：实现过程中的偏离和发现记录。explainer.html（或 .md）：面向评审者的总结，含 demo、决策、未知项、验证证据和剩余风险。quiz.html（或 .md）：变更理解测验，用户必须通过后才能合并。
优先遵循仓库自己的 scratch 或计划文件位置约定。若没有约定，把临时工件放在当前任务工作区的 .unknowns/<task-slug>/ 下，避免多任务撞名。除非用户要求，不要提交这些临时文件。
提示模式
当需要起草提示词、工件模板、访谈问题、实现记录、说明文档或测验时，读取 references/prompt-patterns.md。
协作
当主要风险来自缺失上下文时，先使用本 skill。未知项澄清后返回 skills/using-superpowers/SKILL.md 重新路由，再由更窄的 process skill 管理实现和验证。
本 skill 负责可调查的事实缺口、证据缺口和盲点发现。能从代码、文档、日志或工具获得的事实由 agent 直接检索；不要把它们转问用户。
当剩余缺口涉及高回滚成本的架构/服务边界、公共契约兼容、安全边界、持久数据迁移或不可逆外部副作用时，高风险类别直接交给 skills/brainstorming/SKILL.md。排除这些高风险后，仍会实质改变结果的用户决策交给 skills/grilling/SKILL.md。不要重复访谈：本 skill 找证据，后续 skill 收敛决策或形成规格。
