企业官网建设流程全解析

get-shit-done 的 Socratic 式想法探索工作流：从模糊灵感到 GSD 工件的完整落地指南

【免费下载链接】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

导读

在 get-shit-done（GSD）这套面向 Claude Code 的 meta-prompting、上下文工程与规范驱动开发体系中，explore是专门负责"想法尚未成型"阶段的苏格拉底式（Socratic）头脑风暴工作流。它以提问代替追问、以对话代替审问，引导开发者把模糊的直觉打磨成可执行的方向，再按类型路由到笔记、待办、种子、研究问题、需求、阶段、Spike、Sketch 等 GSD 工件。读完本文，你将掌握 explore 工作流的六步执行链路、一次一问的提问纪律、中途研究触发机制、八种输出类型的结晶与落盘规则，以及仓库源码与测试对这层契约的约束方式。

一、explore 工作流是什么

工作流定义文件 get-shit-done/workflows/explore.md 的开篇 purpose 写得很直白：

Socratic ideation workflow. Guides the developer through exploring an idea via probing questions, offers mid-conversation research when useful, then routes crystallized outputs to GSD artifacts.

它解决的问题很具体：在项目尚未立项、需求尚未清晰之前，开发者心里往往只有一个"大概方向"。直接进入 plan-phase 或 execute-phase 会迫使下游阶段去猜测，而"猜测的代价是复利增长的"。explore 正是这条流水线最前端的沉淀器——它允许对话先于计划、理解先于承诺（commit）。

命令入口与触发方式

explore 工作流本身不直接被调用，而是通过命令层 commands/gsd/explore.md 触发。该命令的 frontmatter 定义了：

name: gsd:explore description: Socratic ideation and idea routing — think through ideas before committing to plans allowed-tools: - Read - Write - Bash - Grep - Glob - Agent - AskUserQuestion

使用方式有两种：

• /gsd:explore—— 不带主题，由工作流开场询问"你在想什么"；
• /gsd:explore authentication strategy—— 携带主题参数，开场直接进入该主题的探索。

命令的execution_context会加载workflows/explore.md，也就是说每次执行命令，Agent 都会以该工作流为执行剧本。允许工具清单里值得注意的是AskUserQuestion（结构化提问交互）与Agent（中途研究需要 spawn 子代理），这两者分别对应工作流中"提问"与"研究"两个核心动作。

前置必读

工作流规定了两条必读参考：

• get-shit-done/references/questioning.md —— 提问哲学与方法论；
• get-shit-done/references/domain-probes.md —— 领域感知探测模式。

同时在可用子代理类型上，工作流明确只允许一种：

• gsd-phase-researcher—— 负责研究特定问题并返回简明结论，不得回退到 general-purpose。

这体现了 GSD 的设计原则：每个环节使用职责单一、名字精确的 subagent，避免泛化代理带来的行为不可控。

二、六步执行链路全解

工作流的 process 部分定义了完整的六步流程。下面逐步拆解，并补充仓库源码与测试给出的约束。

Step 1：开场对话

如果提供了主题，Agent 先确认主题再开始探索：

## Explore: {topic} Let's think through this together. I'll ask questions to help clarify the idea before we commit to any artifacts.

如果没有主题，则直接询问：

## Explore What's on your mind? This could be a feature idea, an architectural question, a problem you're trying to solve, or something you're not sure about yet.

注意措辞里刻意放开边界：功能点子、架构疑问、待解决问题、甚至"自己都还没想清楚的东西"都算有效输入。开场的目标不是收集需求，而是让开发者先倾倒出自己的心智模型。

Step 2：苏格拉底式对话（2～5 轮）

这是工作流的灵魂环节，原则由questioning.md提供，对话规则如下：

• 一次只问一个问题（绝不抛出问题列表）；
• 提问应探测：约束（constraints）、权衡（tradeoffs）、用户（users）、范围（scope）、依赖（dependencies）、风险（risks）；
• 当话题触及已知领域时，上下文相关地使用领域专用探测（domain-specific probes）；
• 留意信号词：当开发者说出 "or" / "versus" / "tradeoff" 时，通常意味着存在值得深挖的优先级冲突；
• 前进之前先复述听到的内容（reflect back），确认理解无误。

工作流特别强调：对话要自然，不要公式化。避免僵硬的固定序列，跟随开发者的能量走——如果他对某个方面很兴奋，就往那个方向深入。

这一点被测试 tests/explore-command.test.cjs 明确锁定：测试断言工作流文档必须包含 "one question at a time" 字样，即"一次一问"不是建议而是契约。

Step 3：中途研究提议（2～3 轮之后）

当对话暴露出事实性问题、技术对比、或存在未知可以通过研究解决时，Agent 提议做一次快速研究：

This touches on [specific question]. Want me to do a quick research pass before we continue? This would take ~30 seconds and might surface useful context. [Yes, research this] / [No, let's keep exploring]

如果同意，则 spawn 研究子代理：

Agent( prompt="Quick research: {specific_question}. Return 3-5 key findings, no more than 200 words.", subagent_type="gsd-phase-researcher" )

这里有两个值得注意的工程细节。第一，研究预算被显式约束：3～5 条关键发现、不超过 200 词，防止研究喧宾夺主。第二，工作流包含一条ORCHESTRATOR RULE —— CODEX RUNTIME：调用Agent()之后必须立即停止当前任务，不得再读文件、改代码或跑测试，等待子代理返回结果。这条规则防止了重复工作、冲突编辑和上下文浪费。

同时工作流也给出反方向约束：如果话题不需要研究，直接跳过此步，不要硬塞（"Don't force it."）。

Step 4：输出结晶（3～6 轮之后）

当对话达成自然结论、或开发者示意准备就绪时，Agent 分析对话内容，从下表中选择至多 4 个输出建议：

呈现建议时使用模板：

Based on our conversation, I'd suggest capturing: 1. **Note:** "Authentication strategy decisions" — your reasoning about JWT vs sessions 2. **Todo:** "Evaluate Passport.js vs custom middleware" — the comparison you want to do 3. **Seed:** "OAuth2 provider support" — trigger: when user management phase starts Create these? You can select specific ones or modify them. [Create all] / [Let me pick] / [Skip — just exploring]

最关键的约束是：未经用户显式选择，绝不写任何工件（Never write artifacts without explicit user selection）。这条同样被测试锁定——explore-command.test.cjs断言文档包含 "explicit user selection" 或 "Never write artifacts without"。

从类型上可以看到 GSD 的工件设计分层：Note 承接"值得记住的决策"，Todo 承接"明确的行动项"，Seed 承接"带触发条件的未来想法"，Research question 承接"需要深入调查的开放问题"，Requirement/New phase 则把对话成果升级为项目级资产，而 Spike 与 Sketch 是两个专门的子命令——分别对应"可行性不确定"（这个 API 能工作吗？）与"设计方向不明"（这东西应该长什么样？）两类典型情形。Spike 命令定义在 commands/gsd/spike.md，Sketch 命令定义在 commands/gsd/sketch.md。

Step 5：写入选定输出

对每个被选中的输出，按其类型写入文件：

• Notes：创建.planning/notes/{slug}.md，frontmatter 含 title、date、context；
• Todos：创建.planning/todos/pending/{slug}.md，frontmatter 含 title、date、priority；
• Seeds：创建.planning/seeds/{slug}.md，frontmatter 含 title、trigger_condition、planted_date；
• Research questions：追加到.planning/research/questions.md；
• Requirements：追加到.planning/REQUIREMENTS.md，使用下一个可用的 REQ ID；
• Phases：通过 SlashCommand 使用现有的/gsd-add-phase命令。

如果commit_docs配置开启，则提交：

gsd-sdk query commit "docs: capture exploration — {topic_slug}" --files {file_list}

注意提交动作是有条件的：是否执行提交完全取决于commit_docs配置，这同样被测试断言（工作流文档必须包含 "commit_docs"）。

Step 6：收尾

## Exploration Complete **Topic:** {topic} **Outputs:** {count} artifact(s) created {list of created files} Continue exploring with `/gsd:explore` or start working with `/gsd:progress --next`.

收尾模板把"继续探索"与"开始干活"两个下一步路径都呈现给开发者，形成一个可循环的闭环：想法可以继续细化，也可以直接进入进度跟踪与执行。

三、底层支撑一：questioning.md 的提问方法论

get-shit-done/references/questioning.md 为对话提供了完整的哲学与方法论，explore 工作流在 Step 2 中明确要求按其原则引导对话。

定位：思考伙伴，而非面试官

文件开篇的核心论断是：项目初始化是"梦境提取"，不是需求收集。你不是在跟用户谈判合同，而是在协作思考。用户往往只有一个模糊的想法，你的工作是帮他把想法磨锋利——让问题促使他产生"哦，我还没想过这个"或"对，这正是我的意思"的反应。

提问目标

到提问结束时，你需要具备足够的清晰度去产出下游各阶段可执行的输入：

• Research 需要：研究什么领域、用户已知什么、存在哪些未知；
• Requirements 需要：足够清晰的愿景以界定 v1 功能范围；
• Roadmap 需要：足够清晰的愿景以分解阶段、定义"完成"的样子；
• plan-phase 需要：可拆解为任务的具体需求、实现选择的上下文；
• execute-phase 需要：可验证的成功标准、需求背后的"为什么"。

模糊的愿景会迫使每个下游阶段去猜，成本复利增长。

提问六法

• 开放式开场：让用户先倾倒心智模型，不要用结构打断；
• 跟随能量：用户强调了什么就深挖什么，什么让他兴奋、什么点燃了这个问题；
• 挑战模糊：绝不接受含糊答案——"好用"指什么？"用户"指谁？"简单"指多简单？
• 把抽象变具体："带我走一遍使用流程""这实际长什么样？"
• 澄清歧义："你说 Z，是指 A 还是 B？""你提到 X——多说一点"；
• 知道何时停止：当理解了要什么、为什么、给谁、完成长什么样，就提议前进。

问题类型参考

• 动机（为什么存在）："是什么促使你想到这个？""你现在的做法里什么会被它替代？""如果它已经存在了你会做什么？"
• 具体性（它到底是什么）："带我走一遍使用流程""你说 X——那实际上是什么样？""给个例子"
• 澄清（用户的意思）："你说 Z，是指 A 还是 B？""你提到 X——跟我说说"
• 成功（怎么知道它在工作）："你怎么知道它在工作？""完成长什么样？"

AskUserQuestion 的正确用法

用结构化选项帮助用户思考，是提问环节的重要工具：

好的选项是：对用户可能意思的解释、用来确认/否认的具体例子、能暴露优先级的具象选择。

坏的选项包括：泛化分类（"技术 / 业务 / 其他"）、预设答案的诱导选项、选项过多（2～4 个为佳）、超过 12 字符的 header（硬限制，校验会拒绝）。

文档给了两个典型案例：用户说"它应该很快"时，header 用 "Fast"，问题问 "Fast how?"，选项给 ["Sub-second response", "Handles large datasets", "Quick to build", "Let me explain"]；用户说"对现有工具不满意"时，header 用 "Frustration"，问 "What specifically frustrates you?"，选项给 ["Too many clicks", "Missing features", "Unreliable", "Let me explain"]。

还有一条对用户友好的技巧：想要对选项做微调时，可以选 "Other" 并按编号引用，例如#1 but for finger joints only或#2 with pagination disabled，避免重打完整选项文本。

自由输入规则：一旦用户选择 "Other" 且其回复表明想用自己的话描述（如 "let me describe it"、"I'll explain"），必须立刻停止使用 AskUserQuestion，改用纯文本追问，等待用户在普通输入框回复，处理完自由输入后再恢复 AskUserQuestion。

反模式清单

• 清单式走动——不管用户说了什么，机械地遍历所有领域；
• 罐头问题——脱离上下文地问"你的核心价值是什么？""哪些超出范围？"；
• 公司腔——"你的成功标准是什么？""你的干系人是谁？"；
• 审问——不基于回答追问，只顾连续发问；
• 赶进度——为尽快"干正事"而压缩提问；
• 浅层接受——接受含糊答案而不深挖；
• 过早约束——在理解想法之前先问技术栈；
• 用户技能——永远不要问用户的技术经验，Claude 负责构建。

四、底层支撑二：domain-probes.md 的领域探测模式

get-shit-done/references/domain-probes.md 是共享参考，explore 与 discuss-phase 等流程共用。当用户提到某个技术领域时，用这些探测提出有洞察力的追问。原则是不要当清单跑，而是根据上下文挑选 2～3 条最相关的，目标是浮出用户可能还没考虑到的隐藏假设与权衡。

认证（Authentication）

实时更新（Real-Time Updates）

仪表盘（Dashboard）

API 设计（API Design）

数据库（Database）

搜索（Search）

文件上传与存储（File Upload/Storage）

缓存（Caching）

测试（Testing）

部署（Deployment）

这些探测表的价值在于：它们把领域专家的提问直觉编码成了可复用的模式，使得 explore 对话能在 2～3 轮内就触及该领域最关键的隐藏权衡，而不是停留在表面。

五、输出工件与 GSD 工件体系的关系

explore 的八种输出类型并非孤立设计，而是嵌入在 GSD 完整的工件分类体系中。参考 get-shit-done/references/artifact-types.md 可以看到，核心工件包括ROADMAP.md、STATE.md、REQUIREMENTS.md、CONTEXT.md（每阶段）、PLAN.md、SUMMARY.md、HANDOFF.json 等，扩展工件则包括 DISCUSSION-LOG.md、USER-PROFILE.md、SPIKE/DESIGN.md、Sketch 系列等。

explore 的 Note/Todo/Seed/Research question 属于探索期的轻量产物，而 Requirement、New phase、Spike、Sketch 则直接与核心/扩展工件体系衔接：

• Requirement追加进REQUIREMENTS.md，后续被discuss-phase、plan-phase及 CONTEXT.md 生成消费；
• New phase追加进ROADMAP.md，由plan-phase、discuss-phase、execute-phase消费；
• Spike路由到/gsd:spike，产出.planning/spikes/NNN-name/下的 README 与 MANIFEST，由 spike-wrap-up 整理；
• Sketch路由到/gsd:sketch，产出.planning/sketches/NNN-name/下的 README、index.html 与 MANIFEST。

也就是说，explore 是整个工件生命周期的入口之一：它把对话中结晶出来的信息，按照既定的形状（shape）、生命周期（lifecycle）、位置（location）与消费机制（consumption）写入系统，确保"被写下的工件都有人读"。

六、测试与契约验证：工作流如何被锁定

explore 工作流不是一篇松散的建议文档，而是被测试 tests/explore-command.test.cjs 严格约束的产品契约。测试覆盖的断言包括：

• commands/gsd/explore.md存在，且 frontmatter 必须包含name: gsd:explore、description:、allowed-tools:；
• workflows/explore.md存在，且必须引用questioning.md与domain-probes.md；
• 工作流必须记录全部六类输出类型（Note、Todo、Seed、Research question、Requirement、New phase）——这正是文档中"输出类型表"存在的意义；
• 工作流必须体现"一次只问一个问题"原则（断言包含 "one question at a time"）；
• 工作流必须要求用户显式确认后才能写工件（断言 "explicit user selection"）；
• 工作流必须尊重commit_docs配置（断言包含 "commit_docs"）；
• 命令必须通过execution_context引用workflows/explore.md。

这些测试属于典型的"文本即产品"（source-text-is-the-product）类型——因为运行时加载的正是这些 Markdown 文件本身，所以测试文本内容就是在测试部署后的契约。这意味着任何人修改 explore 工作流时，如果破坏了上述任一原则，测试套件会立即失败。

七、成功标准与使用建议

工作流在结尾定义了成功标准，可作为每次探索的自检清单：

• 苏格拉底式对话遵循 questioning.md 原则；
• 一次只问一个问题，不批量提问；
• 研究是上下文相关的提议，而非强行插入；
• 从对话中提议至多 4 个输出；
• 用户显式选择要创建哪些输出；
• 文件写入正确的目标位置；
• 提交动作遵守 commit_docs 配置。

结合前文，给实际使用者的几点建议：

1. 把 explore 当作立项前的默认入口：当想法只有一句话时，不要急着/gsd:new-project或进入 plan-phase，先/gsd:explore走完 3～6 轮对话，让愿景在提问中成型；
2. 信任一次一问的纪律：批量问题会让对话变成问卷，反而损失"跟随能量"所需的自然感；单问、深挖、复述确认，是让想法快速锋利的关键；
3. 善用中途研究但不滥用：事实性问题、技术选型对比适合触发gsd-phase-researcher（3～5 条发现、200 词内），纯思路探讨则不必打断节奏；
4. 结晶时克制：每次至多提议 4 个输出，且必须等用户显式选择后再写文件，避免把探索会话变成工件制造机；
5. 理解输出类型的语义边界：Note 记决策、Todo 记行动、Seed 记带触发条件的未来想法、Research question 记待深挖的开放问题，选错类型会污染下游消费方。

结语

explore 工作流是 GSD 体系中最靠前、也最容易被低估的一环。它把"想法探索"从不可控的闲聊提升为有纪律、有契约、有落点的工程过程：用questioning.md保证提问质量，用domain-probes.md注入领域直觉，用gsd-phase-researcher按需补足事实，最后用八种输出类型把对话成果安全地路由进 GSD 的工件体系。配合 tests/explore-command.test.cjs 的契约锁定，这套流程可以稳定地在"先想清楚，再动手干"和"想不清楚就不硬干"之间保持平衡——这正是 spec-driven development 起点处最需要的护栏。

【免费下载链接】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