explore-unknowns

探索未知

地图不是疆域。提示词、计划和上下文窗口是地图；代码库、领域和用户的真实意图才是疆域。两者之间的差距就是未知——在编写代码前发现一个未知，可能只需几分钟就能解决；而在三个 PR 之后才发现，同一个未知就会让这三个 PR 付出代价。

这项技能是一场引导式对话：四象限漫步。你与用户一起绘制任务的四象限地图，每个阶段填写一个象限，最后用户带着完整的地图离开。地图就是交付物；实现是另一项任务，只有在地图移交后才开始。

每个阶段都遵循两项原则：

• 回应胜过想象。 如果能提供具体内容让用户回应——比如渲染后的选项、可点击的模拟界面、决策表——就不要让用户描述他们想要什么。回应能提取用户拥有、却无法在没有提示时表达的知识。
• 每份产出都要为回复做好准备。 在每份产出末尾预先拟好用户的下一条消息：提供可选的采纳／跳过按钮、共鸣复选框、决策表、可复制并经过完善的提示词等，让用户几乎不用输入，就能将回应作为下一条消息发出。

四象限漫步

按顺序逐一进行五个阶段。进入某个阶段时，先阅读该阶段的参考文件并遵循其中的说明。 随着进展说明当前所在的象限——用户应始终清楚自己在地图上的位置——并在开启下一阶段前完成当前阶段。

1. 已知的已知 — 扫视疆域，然后从已确定的内容开始。
2. 已知的未知 — 找出你能明确提出的问题；逐一解决。
3. 未知的已知 — 提取尚无人言明的品味和隐性背景。
4. 未知的未知 — 扫视疆域，排查潜在隐患。
5. 移交地图 — 完整的四象限地图，是这场漫步唯一的完成条件。

当用户开始构建、评审或合并漫步中规划的内容时，请阅读漫步之后——地图不会在规划结束后失效。

偏好检查点——主动提出代替用户作答

统计用户在整个流程中回答的问题数量，而不是轮次或在项目领域中找到的答案。大约回答五六个问题后，如果他们的偏好已形成清晰模式且仍有问题待答，就暂停访谈，进入此检查点。如果模式仍不明确，就继续提出有针对性的问题，等模式清晰后再提出；不要为了凑数而凭空编造问题。

1. 列出你根据他们的回答推断出的偏好，并邀请他们纠正。询问由你代替他们回答符合这些偏好的问题是否有帮助：确认或修改这些偏好并选择授权，或者继续自己回答。这会替代下一个访谈问题。
2. 等待明确授权。仅确认偏好并不代表同意委托；沉默也不代表同意。如果他们只确认偏好，就再询问一次是否授权代答；如果仍未得到答复，就默认继续访谈。如果他们拒绝，就继续，不要反复提出。
3. 一旦获得授权，就在委托范围内回答那些答案能从已确认偏好中明确得出的问题。如果偏好相互冲突，或出现超出委托范围的新权衡，就询问用户。先调查项目领域中缺失的事实；只有无法据此解决时才提问。偏好不能替代关于项目领域的事实。
4. 每次代答时都要披露：问题 → 答案 → 偏好及理由，并标注为已由 Agent 代为回答。可以分批处理较少的问题；绝不能把不同问题合并成一个未披露的决定。将每条记录连同该归属信息一并记入路线图，不能让人误以为是用户亲自回答的。邀请用户纠正，但不要求他们逐条批准每个答案。
5. 立即遵从纠正和撤回。更正会更新偏好摘要，并重新开启因此失效的决定。撤回授权后，停止后续代答；除非用户要求重新审议，否则保留先前答案的归属标注。授权仅在本次流程中有效，不代表获准实施，也不能跳过其余象限。

完成条件：用户已选择是否授权代答；如果已授权，则已将确认的偏好和授权范围与路线图的决策记录一同记下。

规则

• 按顺序逐个阶段走完各象限，并说明当前所在象限。流程以路线图交到用户手中为结束——没有路线图，就不算完成。
• 阶段安排流程顺序，但绝不延迟披露信息。任何对正在进行的决策有实质影响的发现，都要在获得时立即披露，然后归入路线图中对应的象限——绝不能为了等到该阶段的预定环节而暂缓披露。
• 不得在用户看不到的情况下关闭事项。路线图记录为已关闭的任何问题或判断事项，都必须先展示给用户——包括项目领域中已有答案的事项。
• 将事项作为决定关闭，而不是仅作讨论。每个已解决的未知事项都要归结为一条决定及其理由，并采用可原样写入规格说明的既定表述。构建者之后在没有监督的情况下自行作出的每个选择，都是本流程遗漏的未知事项——让实施者继续自行决定的路线图是不完整的。
• 关于项目领域的说法必须引用实际阅读过的真实文件；虚构数据必须明确标注。捏造具体内容会摧毁路线图的可信度。
• HTML 成品必须是独立的单文件：使用内联 CSS/JS，不发起外部请求，并使用看似可信的虚构数据，而不是 lorem ipsum。
• 每到需要用户回应的阶段边界都要停下。切勿基于未经确认的猜测贸然进入实施——实施是单独的任务，只有在交付路线图后才开始。