discover-unknowns-zh

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）	行为变化、验证证据、剩余风险、评审理解缺口

工作流

1. 说明起点

   • 提炼用户想要什么、已经知道什么、还不知道什么。
   • 只有当用户经验水平会影响问题或质量标准时，才询问用户经验。
   • 检索必要的代码、工件和外部资料，让判断落在真实上下文上。

2. 做盲点扫描

   • 列出可能的未知的未知：隐藏集成、数据模型约束、UX 预期、性能陷阱、安全问题、迁移风险、历史实现、测试缺口和评审反对点。
   • 说明每个盲点为什么重要，以及最低成本的验证方式。
   • 优先使用代码搜索、现有测试、文档、日志、截图或小实验，避免凭空猜测。
   • 直接用“盲点扫描”和“未知的未知”这两个词，能更好地触发正确行为。

3. 选择最低成本工件

   • 范围或策略不确定时，用头脑风暴。它还能防止范围定得过窄或过宽。
   • 用户需要“看到才知道”时，用原型暴露未知的已知，例如视觉品味、交互手感、文案或流程形状。在实现阶段才发现这些代价相对较高——规格小改可能导致代码大改，且回滚更难。
   • 某个答案可能改变架构、数据模型、API、UX、灰度或风险策略时，用访谈。
   • 用户描述不清但能指出代码、文档、截图、示例或历史方案时，用参考物。源码是最强参考物。
   • 任务已经因高风险或用户显式 opt-in 进入完整流程时，用实施计划；不要因为下一步会触碰生产代码或多文件改动就自动创建实施计划。

4. 让计划保留转向空间

   • 计划开头先放用户最可能调整的决策：数据模型、类型/接口、UX 流程、安全边界、灰度和兼容性。
   • 机械重构和显然的编辑放最后。
   • 明确 agent 可以自行决定什么，哪些必须回到用户审阅。

5. 记录实现中的发现

   • 对较大的任务，在工作区保留临时 implementation-notes.md（或 .html），除非用户另有要求。
   • 记录偏离计划的地方、发现的边界情况、保守选择和暂缓问题。
   • 如果新发现推翻原计划，暂停并修订计划，不要强行按旧路径推进。

6. 实现后闭环

   • 当评审者、干系人或未来维护者需要快速理解变化时，产出说明文档。它能加速那些和你起点同样有未知项的评审者的理解，也能让专家更快确认你已考虑到他们预判的常见失败点。
   • 包含改了什么、为什么这么做、关键决策、已解决的未知项、已知风险、验证证据和如何评估结果。
   • 对大改或隐性行为变化，用测验检查用户或评审者是否真正理解。把通过测验当作合并闸门，不是走过场。

决策规则

• 小修小改、明确 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 收敛决策或形成规格。