Skill: inksnowhailong/tvs-deep-interview (version 1.0.0)

--- name: tvs-deep-interview description: 深度需求访谈 Skill。通过苏格拉底式单问题追问、拓扑确认、歧义评分和显式审批闸门，把模糊想法整理成可验证规格。适用于用户说深度访谈、先问我、帮我梳理、不要假设、避免做错方向，或需求复杂到直接实现容易返工的场景。必须优先使用当前 Agent 工具自己的提问、选择、确认能力。 --- # 深度需求访谈 深度需求访谈用于把模糊想法整理成清晰、可验证、可执行的规格。 核心原则： ```text AI 可以构建很多东西，真正困难的是弄清楚到底该构建什么。 ``` 本 Skill 采用“深度访谈 -> 规格结晶 -> 待审批 -> 显式批准后执行”的闸门流程。访谈阶段只澄清需求和生成规格，不能直接修改代码、提交、推送、部署或委派实现。 ## 适用与不适用 当出现以下情况时使用： - 用户只有一个模糊想法，需要先被访谈。 - 用户说“深度访谈”“问我问题”“先帮我梳理”“不要假设”。 - 用户希望避免“这不是我要的”式返工。 - 任务足够复杂，直接编码会把时间浪费在范围探索上。 - 用户希望在执行前获得清晰规格、验收标准和风险提示。 不适用场景： - 用户已经给出文件路径、函数名、明确验收标准和执行意图。 - 用户只是要一个单点小修或明确改动。 - 用户只想头脑风暴多个方案，此时应走计划/架构分析，而不是访谈闸门。 - 用户已有 PRD 或计划文件，并明确要求执行它。 如果用户说“别问了，直接做”，但需求仍然模糊，应停止访谈并输出“待审批规格草案/风险说明”，不能直接变更代码。 ## 提问工具适配 必须优先使用当前 Agent 环境提供的原生提问工具。不要为了统一格式而放弃工具能力，也不要伪装自己使用了不存在的工具。 适配顺序： 1. 当前环境有结构化提问/确认工具时，优先调用该工具。 - Cursor：优先使用 `AskQuestion` 收集单选、多选、确认类回答；开放文本问题可用普通聊天提问。 - Claude Code 类工具：如果有 `AskUserQuestion`、计划确认、审批按钮或原生交互工具，优先使用这些能力。 - Cline / Roo / Continue / 其他 IDE Agent：如果提供选择框、确认框、表单或审批面板，优先使用。 2. 当前环境没有结构化提问工具，但支持对话时，用“文本提问协议”。 3. 当前环境只支持终端或非交互输入时，也使用文本提问协议，并明确回复格式。 结构化工具使用规则： - 每轮只能提出一个真正的问题。 - 选项必须与当前上下文相关，并允许“其他/补充”路径。 - 确认类问题必须提供“确认 / 调整 / 暂缓”这类选择。 - 如果工具不支持自由文本，问题正文里说明用户可在聊天里补充。 文本提问协议： ```text DEEP-INTERVIEW QUESTION 轮次：Round {n} 目标组件：{component} 本轮瞄准：{weakest_dimension} 为什么现在问这个：{one_sentence_reason} 当前歧义：{ambiguity_percent}% 问题： {one_question} 回复格式： {单选 / 多选 / 文本 / 确认 的明确说明} ``` ## 核心规则 - 一次只问一个关键问题，禁止批量提问。 - 每轮必须瞄准最弱清晰度维度。 - 问题要暴露假设，而不是收集功能清单。 - 棕地项目必须先读代码/搜索证据，再问用户确认；不要问代码已经能回答的问题。 - 每轮回答后都要重新评分，并透明展示分数。 - 多组件需求必须逐组件评分和轮换提问，不能因为一个组件清楚就忽略兄弟组件。 - 上下文过大时，先压缩成提示安全摘要，再进入评分、提问和规格生成。 - 歧义低于阈值且用户明确批准前，不得进入执行。 - 允许用户提前退出，但必须说明剩余歧义和返工风险。 ## 初始化 1. 解析用户初始想法。 2. 判断类型： - 绿地：新产品、新功能或没有明显现有代码依赖。 - 棕地：要修改、扩展或接入现有项目。 3. 棕地项目先收集事实： - 当前工具能搜索/读取代码时，先查看目录、相关文件、配置、相似实现。 - Cursor 可用时，优先用 `rg`、`ReadFile`、`SemanticSearch` 或 `explore` 子 Agent。 - 其他 Agent 工具按自身能力使用搜索、文件读取、代码索引、MCP 或 IDE 上下文。 - 没有代码访问能力时，明确说明限制并请用户提供片段。 4. 如果初始上下文很长，先生成提示安全摘要，保留目标、约束、已知决定、不确定点、文件/符号引用和明确非目标。 5. 设置默认阈值： - 标准模式：歧义 ≤ 20% 才可进入规格完成态。 - 快速模式：歧义 ≤ 30%。 - 深度模式：歧义 ≤ 10%。 启动时向用户说明： ```text 开始深度需求访谈。我会一次只问一个问题，通过歧义评分判断需求是否足够清晰。 在歧义低于阈值并获得你明确批准前，我不会执行实现。 你的初始想法：{summary} 项目类型：绿地 / 棕地 当前歧义：100% ``` ## Round 0：拓扑确认 Round 0 在任何歧义评分前执行一次。目标是锁定用户需求的“形状”，避免后续访谈只围绕描述最多的部分钻深，而漏掉其他独立结果。 1. 从初始想法和棕地证据中枚举顶层组件： - 顶层组件可以是独立成功/失败的工作流、界面、集成、能力或交付物。 - 优先 1 到 6 个。超过 6 个时合并同类项并说明原因。 - 不要把字段、按钮、实现步骤当成顶层组件，除非用户明确把它们作为独立结果。 2. 用当前工具的提问能力询问用户确认： ```text Round 0 | 拓扑确认 | 暂不评分 我把这个需求理解为 {N} 个顶层组件： 1. {component}: {one_sentence_description} 2. ... 这个拓扑对吗？需要新增、删除、合并、拆分或暂缓哪个组件吗？ ``` 3. 用户确认后锁定拓扑： - 进行中：本轮要继续澄清的组件。 - 已暂缓：用户明确暂缓的组件。 - evidence：初始提示词或代码证据来源。 ## 访谈循环 重复执行，直到歧义低于阈值，或用户选择提前退出。 ### 生成下一问 构造问题时使用： - 初始想法或提示安全摘要。 - 已锁定拓扑。 - 过往 Q&A 的精简摘要。 - 每个进行中组件的当前分数和缺口。 - 棕地代码证据，必须压缩为路径、符号、模式，不要倾倒大段源码。 - 已使用的挑战模式。 提问策略： - 找出“进行中组件 + 清晰度维度”中最低分的一项。 - 多个组件同样薄弱时轮换组件，避免一直追问同一组件。 - 先用一句话说明为什么这项是当前瓶颈。 - 问题必须针对该组件和该维度。 - 如果核心名词在变化，优先问本体问题：“这个东西到底是什么？” 问题类型参考： | 维度 | 问法 | 示例 | |---|---|---| | 目标清晰度 | 到底要发生什么 | “当你说管理任务时，用户第一步具体做什么？” | | 约束清晰度 | 边界是什么 | “这必须离线可用，还是默认联网？” | | 成功标准 | 如何证明完成 | “如果我给你看成品，什么结果会让你说这就是我要的？” | | 上下文清晰度 | 如何接入现有系统 | “我看到现有鉴权在 `src/auth/`，这次要扩展它还是刻意另建一套？” | | 本体稳定性 | 核心概念是什么 | “你前面提到工作流、收件箱、计划器，哪个才是核心实体？” | ### 提问 使用当前环境自己的提问工具。呈现内容必须包含： ```text Round {n} | 组件：{target_component} | 瞄准：{weakest_dimension} | 歧义：{ambiguity}% 为什么问这个：{reason} {one_question} ``` ### 歧义评分 用户回答后，对每个进行中组件分别评分，再汇总整体歧义。 维度分数：0.0 到 1.0。 - 目标清晰度：目标能否一句话说清，关键实体和动作是否稳定。 - 约束清晰度：边界、非目标、限制、依赖是否清楚。 - 成功标准清晰度：能否写出可验证的验收条件。 - 上下文清晰度：仅棕地项目使用，是否理解现有系统到足以安全修改。 计算公式： ```text 绿地歧义 = 1 - (目标 * 0.40 + 约束 * 0.30 + 成功标准 * 0.30) 棕地歧义 = 1 - (目标 * 0.35 + 约束 * 0.25 + 成功标准 * 0.25 + 上下文 * 0.15) ``` 评分输出必须包含： - 每个维度的分数、理由和缺口。 - 当前最弱组件。 - 当前最弱维度。 - 下一轮为何应该瞄准它。 - 如果多组件并行，说明轮换逻辑。 ### 本体稳定性 每轮提取关键实体： - name：实体名。 - type：核心领域 / 支撑对象 / 外部系统 / 视图或容器。 - fields：已明确的关键属性。 - relationships：实体关系。 从第二轮开始比较上一轮： - stable：名称和概念都稳定。 - changed：名称变化但类型和字段高度重合，视为同一概念重命名。 - new：新出现实体。 - removed：消失实体。 - stability_ratio = (stable + changed) / 当前实体总数。 如果核心实体持续变化，应优先进入本体式提问，不要继续追功能细节。 ### 进度报告 每轮回答后向用户报告： ```text Round {n} 完成 清晰度： - 目标：{score}，缺口：{gap} - 约束：{score}，缺口：{gap} - 成功标准：{score}，缺口：{gap} - 上下文：{score}，缺口：{gap} 当前歧义：{ambiguity}% 拓扑：当前瞄准 {component}；进行中 {count}；已暂缓 {count} 本体：{entity_count} 个实体；稳定率 {stability_ratio} 下一轮目标：{component} / {dimension}，原因：{reason} ``` ### 软限制 - 第 3 轮后，如果用户说“够了”“就这样”，允许提前退出，但必须展示剩余歧义和风险。 - 第 10 轮给软提醒：继续访谈、生成当前规格，还是暂缓。 - 第 20 轮硬上限：停止继续追问，生成当前清晰度规格并标记风险。 - 若连续 3 轮歧义变化小于 5%，进入本体模式重新确认核心概念。 ## 挑战模式 挑战模式是提问视角切换，不是另起实现 Agent。 - Round 4+：反方模式。挑战核心假设，例如“如果这个约束不存在，会怎样？” - Round 6+：简化模式。追问最小可用版本，例如“保留价值所需的最小版本是什么？” - Round 8+ 且歧义仍高于 30%：本体模式。追问“这到底是什么？哪个实体是核心？” 每个模式只使用一次，使用后回到正常苏格拉底式提问。 ## 规格结晶 当歧义低于阈值，或用户选择提前退出/达到硬上限时，生成规格。 不要直接实现。规格状态必须是“待审批”。 规格结构： ```markdown # 深度访谈规格：{title} ## 元信息 - 轮次：{round_count} - 项目类型：绿地 / 棕地 - 最终歧义：{ambiguity}% - 阈值：{threshold}% - 状态：通过阈值 / 提前退出 / 达到轮次上限 ## 清晰度拆解 | 维度 | 分数 | 权重 | 加权 | |---|---:|---:|---:| | 目标 | {score} | {weight} | {weighted} | | 约束 | {score} | {weight} | {weighted} | | 成功标准 | {score} | {weight} | {weighted} | | 上下文 | {score} | {weight} | {weighted} | ## 拓扑 | 组件 | 状态 | 描述 | 覆盖/暂缓说明 | |---|---|---|---| | {component} | 进行中/已暂缓 | {description} | {coverage_or_deferral} | ## 目标 {覆盖所有进行中组件的清晰目标陈述} ## 约束 - {constraint} ## 非目标 - {non_goal} ## 验收标准 - [ ] {testable_criterion} ## 已暴露并解决的假设 | 假设 | 如何追问 | 结论 | |---|---|---| | {assumption} | {challenge} | {resolution} | ## 技术/项目上下文 {棕地项目写代码证据；绿地项目写技术选择和约束} ## 关键实体 | 实体 | 类型 | 字段 | 关系 | |---|---|---|---| | {entity} | {type} | {fields} | {relationships} | ## 本体收敛 说明实体如何在各轮中稳定下来。 ## 待确认问题 - {open_question} ## 访谈记录 折叠或摘要列出每轮 Q/A、歧义和关键决定。 ``` 如果当前工具允许写文件，并且项目允许保存规划文档，可以写入合适的规格路径；否则直接在对话中输出规格。不要把规格写到随机业务目录。 ## 执行桥接 规格完成后，必须询问用户下一步。优先使用当前工具的原生确认/选择能力。 可选项： 1. 继续完善规格。 2. 进入计划/架构评审。 3. 明确批准执行。 4. 暂停，保留规格。 在用户明确选择执行前，禁止： - 修改源码。 - 运行会改变项目状态的命令。 - 提交、推送、发 PR。 - 调用执行型 Agent 或实现型 Skill。 如果用户批准执行，把规格作为上下文交给当前工具合适的执行流程。不要由深度访谈 Skill 自己直接实现。 ## 好例子 瞄准最弱维度： ```text 分数：目标 0.9，约束 0.4，成功标准 0.7 下一问瞄准约束，因为它是最低分： “你说要支持移动端，这指响应式 Web、PWA，还是原生 App？是否有必须支持的设备或系统版本？” ``` 先读代码再问： ```text 我看到现有鉴权集中在 `src/auth/`，使用 JWT 中间件。这个新能力应该扩展现有鉴权路径，还是需要刻意独立出来？ ``` 反方模式： ```text 你提到必须支撑 1 万并发。假设第一版只需要 100 并发，架构会完全不同吗？这个数字是测量结果还是预设假设？ ``` ## 坏例子 批量提问： ```text 目标用户是谁？技术栈是什么？鉴权怎么做？部署在哪？ ``` 为什么坏：四个问题一起问，会得到浅答案，无法准确评分。 问代码已经能回答的问题： ```text 你的项目用什么数据库？ ``` 为什么坏：如果当前工具能读代码，应先自己查证。 高歧义直接执行： ```text 歧义还有 45%，但已经问了 5 轮，开始写代码吧。 ``` 为什么坏：歧义闸门就是为了防止这种返工。 ## 完成检查清单 - [ ] 已完成 Round 0 拓扑确认。 - [ ] 每轮只问一个问题。 - [ ] 每轮都说明最弱组件/维度和提问原因。 - [ ] 棕地问题先收集代码证据，再向用户确认。 - [ ] 每轮都显示歧义评分。 - [ ] 多组件需求已轮换覆盖。 - [ ] 挑战模式按轮次使用，且每种最多一次。 - [ ] 规格包含目标、约束、非目标、验收标准、拓扑、关键实体和待确认问题。 - [ ] 规格为待审批状态。 - [ ] 未经用户明确批准，没有执行实现。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)