发现你的未知项
概述
用户对任务的描述（他们的提示、上下文、参考资料）与实际工作（代码库、约束条件、现实情况）之间的差距正是未知项的藏身之处。当智能体遇到未知项时，它会猜测用户的意图。本技能的工作就是消除猜测：帮助用户在实施之前、期间和之后发现并命名他们的未知项，迭代进行——而不是一次性的事前计划。
这是一个工具箱，而非固定的流水线。先诊断，然后只应用适合的技术。不要在琐碎的任务上运行所有技术。
四种未知项
在选择技术之前，请对缺失的内容进行分类：
- 已知已知项 —— 提示中已经陈述的内容。
- 已知未知项 —— 用户知道他们还没有决定这个。
- 未知已知项 —— 太明显以致于没有写出来，但用户看到后能识别出来（通常是视觉/UX方面的品味）。
- 未知未知项 —— 从未考虑过；用户不知道自己不知道什么。
第 0 步 — 诊断
在做任何事情之前，确定哪些未知项占主导地位，并据此选择技术：
- 不熟悉的领域或不熟悉的代码库角落 → 盲点扫描（未知未知项）。
- 难以描述，“看到就知道” → 原型（未知已知项）。
- 方向明确，细节模糊 → 访谈用户 + 起草计划（已知未知项）。
始终提供关于用户是谁以及他们已知什么内容的上下文——它能让下面的每一项技术都更加精准。
交接给其他技能
将此技能用作发现层，而不是整个工作流程。在命名未知项后，选择最小的后续技能来解决下一个不确定性。
| 未知项或下一步需求 | 交接给 | 使用场景 |
|---|---|---|
| 用户未完全表达意图 | interview-me | 一次问一个问题，直到底层需求明确。 |
| 计划需要压力测试 | grill-me 或 grill-with-docs | 对假设进行压力测试；当需要捕获ADR或术语表更新时，使用文档变体。 |
| 缺少外部事实 | research 或 source-driven-development | 在决策前收集一手证据。 |
| 用户看到才能知道 | prototype | 在承诺实现之前，使用假数据展示具体选项。 |
| 工作需要正式规范 | spec-driven-development | 将发现的约束和决策转化为PRD/规范。 |
| 工作体量过大无法直接执行 | planning-and-task-breakdown 或 writing-plans | 将对齐的规范分解为有序的、可验证的片段。 |
| 接口边界不清晰 | api-and-interface-design 或 design-an-interface | 决定API、模块或类型契约。 |
| 代码库结构不确定 | codebase-design 或 improve-codebase-architecture | 找到正确的模块边界、抽象或重构方向。 |
| UI行为或视觉质量不确定 | frontend-ui-engineering | 将选定的原型或偏好转化为生产级别的UI工作。 |
| 存在Bug但原因不明 | systematic-debugging 或 diagnosing-bugs | 重现、隔离、假设、检测并修复。 |
| 实施涉及独立任务 | subagent-driven-development 或 dispatching-parallel-agents | 仅在任务不共享状态或顺序依赖时拆分工作。 |
| 工作看似完成 | verification-before-completion、requesting-code-review 或 code-review | 验证证据，然后在声称完成或合并之前进行审查。 |
在交接之前，总结：
- 现在已知什么。
- 仍然未知什么。
- 哪个决策会改变实施方式。
- 哪个工件应该继续推进：原型、规范、计划、实施说明或验收报告。
按阶段划分的技术
每项技术都有一个触发条件和可以直接发送的提示模板。请调整括号部分。
探索（发现未知项）
1. 盲点扫描 —— 进入不熟悉领域的第一步。
我正在添加[X]，但我几乎不了解这个代码库中的[Y]模块。做一个盲点扫描——找出我的“未知未知项”并解释它们，这样我才能给你写一个更好的提示。
2. 原型 —— 当无法描述时，展示它。使用假数据，无需后端。
在接触真实应用之前，制作一个HTML文件，用假数据模拟[接口]。给我4个完全不同的设计方向，这样我可以看看哪个感觉对。
3. 访谈用户 —— 挤出剩余的模糊点。
一次问我一个问题。锁定模糊区域，优先提出那些答案会改变架构的问题。
规划（对齐意图）
4. 展示参考资料 —— 最好的参考资料是源代码，而不是截图。
[路径/库]实现了我们想要的[行为]。阅读它，然后在[我们的技术栈]中重新实现相同的语义。
5. 起草计划 —— 首先浮现最可能改变的决策。
编写一个HTML实施计划，但把最可能调整的决策放在最上面：数据模型更改、新的类型接口、任何用户可见的内容。把机械性的重构放在最后——那些我相信你。
实施（捕获在中间出现的未知项）
6. 随附注释 —— 开始一个新的会话，将规范/原型输入其中，然后：
维护一个 implementation-notes.md。如果某个边界情况迫使你偏离计划，选择保守的选项，在“偏差”部分记录下来，然后继续。
交付（对齐他人，验证你理解正确）
7. 交接说明
将原型、规范和实施说明打包成一个文档，我可以直接扔到聊天中用于批准。在顶部放一个演示GIF。
8. 验收测验 —— 作者的硬性规则：通过后才能合并。
我想确保我完全理解这次更改。制作一个HTML报告，包含变更的上下文、直觉以及完成的内容——然后在底部放一个我必须通过的测验。
操作规则
- 每当你即将猜测用户的意图时，停下来，改用相应的技术。
- 串联工件：原型 → 规范 → 实施说明 → 验收报告；每一步都是下一步的输入，这样新的会话不会丢失上下文。
- 对于小任务，
盲点扫描 + 起草计划 + 验收测验已经能捕获大部分价值。不要过度执行。