Requirements-育师

Requirements

【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done

Validated

（暂无 —— 交付验证）

Active

[需求 1]
[需求 2]

Out of Scope

[排除项 1] —— [原因]

在绿场（greenfield）项目里，所有 Active 需求在"交付并验证"之前都只是**假设**；在棕场（brownfield）项目里，则要先通过 `/gsd:map-codebase` 生成代码库地图，从现有代码反推 Validated 需求。 ## 三、六条提问原则：如何组织一场高效的对话 指南给出了六条可操作原则，它们共同构成提问节奏的底层逻辑： 1. **开放开始（Start open）**——让用户倾倒心理模型，不要用结构化问题打断。在实际工作流中，[workflows/new-project.md](https://link.gitcode.com/i/ee945b373939eb646dcf07e4f924cde6) 的 Deep Questioning 环节正是以一句自由文本开场："What do you want to build?"（你想构建什么？），等待回应后再追问。 2. **跟随能量（Follow energy）**——用户强调什么就深入什么。什么让他们兴奋？什么问题引发了这一切？ 3. **挑战模糊（Challenge vagueness）**——绝不接受模糊回答。"好"意味着什么？"用户"指谁？"简单"是怎么个简单法？ 4. **让抽象具体（Make the abstract concrete）**——请用户"带我走一遍使用这个"、"那实际看起来是什么样？" 5. **澄清歧义（Clarify ambiguity）**——"你说 Z 时，是指 A 还是 B？" 6. **知道何时停止（Know when to stop）**——当你理解他们想要什么、为什么想要、给谁用、完成是什么样时，提议继续。 这六条原则被 [workflows/new-project.md](https://link.gitcode.com/i/ee945b373939eb646dcf07e4f924cde6) 的 Deep Questioning 步骤直接引用为提问技术： > 挑战模糊、让抽象具体、显性化假设（Surface assumptions）、寻找边界（Find edges）、揭示动机（Reveal motivation）。 需要特别指出，该工作流还支持一种可选的 `workflow.research_before_questions` 配置模式（默认关闭）：开启后，在追问某个主题领域之前，先做一次简短的最佳实践网络搜索，然后在提问时自然地引用发现（例如"这类项目大多使用 X —— 你也是这么想的，还是另有打算？"），让提问更有依据且不破坏对话流动感。 ## 四、四类问题：动机、具体性、澄清与成功 指南把这些问句作为**灵感来源而非核对清单**，强调选择与当前话题相关的问法： | 问题类型 | 目的 | 例句 | |---|---|---| | **动机（Motivation）** | 追问"为什么存在" | "什么引发了这一切？""你今天在做什么会被这个替代？""如果这个已经存在，你会做什么？" | | **具体性（Concreteness）** | 追问"它实际是什么" | "带我走一遍使用这个""你说 X —— 那实际看起来是什么样？""给我一个例子" | | **澄清（Clarification）** | 追问"他们什么意思" | "你说 Z 时，是指 A 还是 B？""你提到了 X —— 跟我多说说那个" | | **成功（Success）** | 追问"你怎么知道它在工作" | "你怎么知道这个在工作？""完成是什么样子？" | 这四类问题与 [workflows/explore.md](https://link.gitcode.com/i/7aae9d4a1e021c70aa860adeb34cdac9) 的 Socratic 对话环节是相通的：该工作流规定每次只问一个问题（绝不同时抛一长串问题），并监听"或 / 与之相对 / 权衡"这类信号——它们往往意味着存在值得展开的对立优先级，同时把听到的内容复述回去以确认理解。整个探索会话被控制在 2-5 轮苏格拉底式交换内。 ## 五、用 AskUserQuestion 帮助思考：选项设计是门手艺 Claude Code 的 AskUserQuestion 工具是 GSD 提问流程的核心交互载体。指南把它定位为"**通过呈现具体选项供用户反应来帮助思考**"的手段，而不是给用户做选择题的考卷。 ### 5.1 好选项与坏选项 **好选项**应当具备以下三种形态之一： - 对用户可能含义的解读； - 用于确认或否认的具体例子； - 能揭示优先级的具体选择。 **坏选项**则要避免： - 泛泛的类别（如"技术""业务""其他"）； - 预设了答案的引导性选项； - 选项过多（**2-4 个是理想数量**）； - 超过 12 个字符的 header（**硬限制——校验会拒绝**）。 仓库中 [gate-prompts.md](https://link.gitcode.com/i/1024ffcf4cc0d2d89f320343af9105f3) 把这些约束固化为通用规则：`header` 必须不超过 12 个字符、每次提问最多 4 个选项（超过则用两步流程）、始终处理"Other"自由输入分支；[autonomous-smart-discuss.md](https://link.gitcode.com/i/2cca25e7ba67a862a9034ff2991e163e) 进一步指出 AskUserQuestion 会自动追加"Other"选项，因此显式选项通常控制在 4 个以内（最多 6 个）。 ### 5.2 两个可复用的工作示例 指南给出的第一个示例针对模糊回答： ```json { "header": "快", "question": "快是指？", "options": ["亚秒响应", "处理大数据集", "快速构建", "让我解释"] }

第二个示例针对跟随话题（用户提到"对当前工具感到沮丧"）：

{ "header": "沮丧", "question": "具体什么让你沮丧？", "options": ["点击太多", "缺少功能", "不可靠", "让我解释"] }

注意两个例子里都保留了"让我解释"这样一个通往自由文本的出口——它决定了 AskUserQuestion 与自由文本对话之间的切换逻辑（见下一节）。header 的 12 字符硬限制也贯穿了所有 GSD 交互：测试 tests/feat-2527-settings-layers.test.cjs 专门断言设置工作流使用的 header 都做了缩写以符合 12 字符上限。

5.3 给用户的选项微调技巧

想对某个选项做小幅修改的用户，不必重新敲入完整选项文本。指南提供了一条引用式语法：用户选择"Other"后用编号引用原选项即可，例如#1 但仅用于指关节或#2 禁用分页。这条约定既减少了用户的输入负担，又让修改意图精确可解析。

六、自由格式规则：什么时候必须停止使用 AskUserQuestion

这是提问流程中最容易被忽略、却最容易毁掉对话氛围的一条规则：当用户想自由解释时，立即停止使用 AskUserQuestion。

判断信号是：用户选择了"Other"，且其回应表明他们想用自己的话描述——例如"让我描述一下""我来解释""别的"，或任何不是"选择/微调现有选项"的开放式回复。此时你必须：

用纯文本提出追问——不再通过 AskUserQuestion；
等待用户在正常提示符下输入；
仅在处理完他们的自由格式回应之后，才恢复 AskUserQuestion。

同一条规则也适用于：如果你自己主动包含了一个暗示自由格式的选项（如"让我解释"或"详细描述"）且用户选中了它。

指南给出了正反例对照：

错误：用户说"让我描述一下" → 继续用AskUserQuestion("什么功能？", ["功能 A", "功能 B", "详细描述"])
正确：用户说"让我描述一下" → 直接用纯文本回应"请讲 —— 你在想什么？"

GSD 交互设计中这条规则被反复强调。例如 workflows/new-project.md 的配置问卷就遵循了同样的精神：当用户需要表达默认值之外的偏好（"Configure fresh"）而非简单选择时，流程会切到自由输入或编号列表。另外，对非 Claude 运行时（OpenAI Codex、Gemini CLI 等），该工作流提供了TEXT_MODE兜底：将每个 AskUserQuestion 调用替换为纯文本编号列表，请用户输入选项编号；而 VS Code Copilot 则使用等价的vscode_askquestions（见 commands/gsd/new-project.md 的 runtime_note）。

七、上下文清单：四件事，作为背景而不是对话结构

指南提供了一个背景清单，用于在对话进行中于脑内自查，而不是当作必须逐条执行的对话骨架。若发现缺口，就把问题自然地织入对话，切勿突然切换到"清单模式"：

他们在构建什么（具体到足以向陌生人解释）；
为什么它需要存在（驱动它的问题或渴望）；
给谁用的（即使只是他们自己）；
"完成"是什么样子（可观察的结果）。

只有这四件事。如果用户主动提供了更多信息，就把它捕获进上下文。对照仓库可以看到，这四项恰好映射到 PROJECT.md 模板的核心区块：What This Is（构建什么）、Core Value（为什么存在、什么最重要）、Requirements 的Active/Out of Scope（给谁用、边界）、以及验证阶段的可观察产出。

八、决策门控：清晰到能写 PROJECT.md 时就提议继续

提问阶段需要一个明确的"出口"。指南规定：当你能写出清晰的 PROJECT.md 时，就提议继续，用 AskUserQuestion 呈现二元选择：

{ "header": "准备好了？", "question": "我想我理解你想要什么了。准备创建 PROJECT.md 吗？", "options": [ { "label": "创建 PROJECT.md", "description": "让我们继续" }, { "label": "继续探索", "description": "我想分享更多 / 再问我" } ] }

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考