输入
在 Codex 对话中描述困惑、目标、已有方案和已知限制。
返回项目01 02 03 04 CHAPTER 01 01 02 03 CHAPTER 02 04 05 06 07 CHAPTER 03 08 09 10
SKILL · 按需调用不是 Agent
基于专业辩论的深度需求挖掘 Skill
Know Yourself
把模糊、冲突或过早方案化的诉求，转成证据明确、边界清楚、可供下一角色接手的需求包。
Skill 处理
按探索层级单问深挖，区分证据状态，再用多专业视角检验关键前提。
输出
包含事实、愿望、假设、推断、未知项、冲突处理、验收边界与后续实施提示。
Markdown 需求交接包边界
不写生产代码，不把未验证推断包装成事实，也不会脱离用户确认自行运行。
第一章：先找到真正的问题
先判断是否需要深挖，再决定探索深度与覆盖范围。
从方案退回问题
需求一旦被过早写成解决方案，目标与动机就很容易被遮住。
- 设计重点
- 先复述已知事实，再把方案语言改写为待验证的问题。
- 阶段交付
- 问题陈述与首轮证据缺口。
选择探索层级
简单问题不需要长访谈，高风险决策也不能只做快速确认。
- 设计重点
- 依据复杂度、影响范围与可逆性选择问题预算。
- 阶段交付
- 探索级别、预计轮次与退出条件。
建立探索地图
只围绕一个视角提问，会遗漏角色冲突与真实约束。
- 设计重点
- 覆盖用户场景、业务目标、技术条件、风险与验收。
- 阶段交付
- 可追踪的探索维度清单。
第二章：用证据与专业辩论深挖
保持单问节奏，把不同可信度的信息分开，并让关键假设接受挑战。
一次只问一个关键问题
一次抛出多个问题会让回答变浅，也难以判断哪条证据支撑了结论。
- 设计重点
- 每轮选择信息增益最高的问题，并解释提问目的。
- 阶段交付
- 逐轮问答记录与维度进度。
建立证据状态台账
不同可信度的信息混写后，团队会把假设误当成需求事实。
- 设计重点
- 为每条主张标注类别、来源、可信度和下一验证动作。
- 阶段交付
- 可追溯的 evidence-ledger.md。
启动专业视角辩论
单一视角容易产生确认偏误，尤其是在方案已经很具体时。
- 设计重点
- 让用户、业务、技术与风险视角分别支持或挑战前提。
- 阶段交付
- 前提辩论记录与待决项。
显式处理冲突
冲突被隐藏后，只会在设计或开发阶段以返工形式重新出现。
- 设计重点
- 定位冲突来源，选择补证、取舍、降级或保留未知。
- 阶段交付
- 冲突决策、责任人与复核条件。
第三章：把探索结果变成交接材料
从过程记录收敛到可审阅、可实施、可回退的需求包。
沉淀分维度记录
仅保留聊天记录，会迫使下一角色重新理解全部上下文。
- 设计重点
- 让每个维度都有结论、证据、未知项、风险与修改历史。
- 阶段交付
- 结构化 dimension records。
组装需求交接包
交接物必须让设计、研发或另一个 Agent 能够直接继续工作。
- 设计重点
- 把问题、范围、用户、规则、验收、风险与开放项组织成目录。
- 阶段交付
- 一组可版本管理的 Markdown 文件。
通过实施前门禁
交付文档完整不代表关键不确定性已经降到可实施水平。
- 设计重点
- 检查证据覆盖、冲突状态、边界、责任人与停止条件。
- 阶段交付
- 可实施、补证或暂停三种明确结论。
- 能力边界
- Skill 到此结束，后续生产实现由新的执行任务承接。
FINAL DELIVERY
最终交付是 Markdown 需求交接包
包含事实、愿望、假设、推断、未知项、冲突处理、验收边界与后续实施提示。
如何调用
在 Codex 中提出一个尚未厘清的问题，并要求先使用 Know Yourself 完成需求探索与交接。
明确边界
不写生产代码，不把未验证推断包装成事实，也不会脱离用户确认自行运行。