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-doneGSD这套面向 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} Lets think through this together. Ill ask questions to help clarify the idea before we commit to any artifacts.如果没有主题则直接询问## Explore Whats on your mind? This could be a feature idea, an architectural question, a problem youre trying to solve, or something youre not sure about yet.注意措辞里刻意放开边界功能点子、架构疑问、待解决问题、甚至自己都还没想清楚的东西都算有效输入。开场的目标不是收集需求而是让开发者先倾倒出自己的心智模型。Step 2苏格拉底式对话25 轮这是工作流的灵魂环节原则由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中途研究提议23 轮之后当对话暴露出事实性问题、技术对比、或存在未知可以通过研究解决时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, lets keep exploring]如果同意则 spawn 研究子代理Agent( promptQuick research: {specific_question}. Return 3-5 key findings, no more than 200 words., subagent_typegsd-phase-researcher )这里有两个值得注意的工程细节。第一研究预算被显式约束35 条关键发现、不超过 200 词防止研究喧宾夺主。第二工作流包含一条ORCHESTRATOR RULE —— CODEX RUNTIME调用Agent()之后必须立即停止当前任务不得再读文件、改代码或跑测试等待子代理返回结果。这条规则防止了重复工作、冲突编辑和上下文浪费。同时工作流也给出反方向约束如果话题不需要研究直接跳过此步不要硬塞Dont force it.。Step 4输出结晶36 轮之后当对话达成自然结论、或开发者示意准备就绪时Agent 分析对话内容从下表中选择至多 4 个输出建议TypeDestinationWhen to suggestNote.planning/notes/{slug}.mdObservations, context, decisions worth rememberingTodo.planning/todos/pending/{slug}.mdConcrete actionable tasks identifiedSeed.planning/seeds/{slug}.mdForward-looking ideas with trigger conditionsResearch question.planning/research/questions.md(append)Open questions that need deeper investigationRequirementREQUIREMENTS.md(append)Clear requirements that emerged from discussionNew phaseROADMAP.md(append)Scope large enough to warrant its own phaseSpike/gsd:spike(invoke)Feasibility uncertainty surfaced — will this API work?, can we do X?Sketch/gsd:sketch(invoke)Design direction unclear — what should this look like?, how should this feel?呈现建议时使用模板Based on our conversation, Id 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.mdSketch 命令定义在 commands/gsd/sketch.md。Step 5写入选定输出对每个被选中的输出按其类型写入文件Notes创建.planning/notes/{slug}.mdfrontmatter 含 title、date、contextTodos创建.planning/todos/pending/{slug}.mdfrontmatter 含 title、date、prioritySeeds创建.planning/seeds/{slug}.mdfrontmatter 含 title、trigger_condition、planted_dateResearch questions追加到.planning/research/questions.mdRequirements追加到.planning/REQUIREMENTS.md使用下一个可用的 REQ IDPhases通过 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 的正确用法用结构化选项帮助用户思考是提问环节的重要工具好的选项是对用户可能意思的解释、用来确认/否认的具体例子、能暴露优先级的具象选择。坏的选项包括泛化分类技术 / 业务 / 其他、预设答案的诱导选项、选项过多24 个为佳、超过 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、Ill explain必须立刻停止使用 AskUserQuestion改用纯文本追问等待用户在普通输入框回复处理完自由输入后再恢复 AskUserQuestion。反模式清单清单式走动——不管用户说了什么机械地遍历所有领域罐头问题——脱离上下文地问你的核心价值是什么哪些超出范围公司腔——你的成功标准是什么你的干系人是谁审问——不基于回答追问只顾连续发问赶进度——为尽快干正事而压缩提问浅层接受——接受含糊答案而不深挖过早约束——在理解想法之前先问技术栈用户技能——永远不要问用户的技术经验Claude 负责构建。四、底层支撑二domain-probes.md 的领域探测模式get-shit-done/references/domain-probes.md 是共享参考explore 与 discuss-phase 等流程共用。当用户提到某个技术领域时用这些探测提出有洞察力的追问。原则是不要当清单跑而是根据上下文挑选 23 条最相关的目标是浮出用户可能还没考虑到的隐藏假设与权衡。认证Authentication用户提到Agent 用领域知识探测login / authOAuth哪些提供商、JWT 还是 session需要社交登录还是仅邮箱/密码users / accounts需要 MFA 吗密码重置流程邮箱验证sessions会话时长与刷新策略服务端会话还是无状态 tokenroles / permissionsRBAC、ABAC 还是简单角色检查需要多少种角色API keys密钥轮换策略每把密钥的作用域权限按密钥限流实时更新Real-Time Updates用户提到Agent 用领域知识探测real-time / live updatesWebSockets、SSE 还是轮询哪些必须实时 vs 允许最终一致notifications推送通知浏览器/移动端、仅应用内、还是两者都要持久化与已读回执collaboration / multiplayer冲突解决策略OT 还是 CRDT预期并发用户数chat / messaging消息历史与搜索输入指示器已读回执streaming重连策略断连时是排队还是丢弃仪表盘Dashboard用户提到Agent 用领域知识探测dashboard数据源有哪些多少种视图charts / graphs交互式还是静态支持钻取吗可导出 CSV/PDF 吗metrics / KPIs刷新策略——实时、周期轮询还是按需可接受的过期程度admin panel基于角色的可见性除查看外还有哪些操作编辑、删除、审批mobile / responsive简化移动视图还是完全一致图表支持触控交互吗API 设计API Design用户提到Agent 用领域知识探测APIREST、GraphQL 还是 RPC 风格仅内部还是对外公开endpoints / routes版本化策略URL 路径、header、query 参数破坏性变更政策pagination基于游标还是 offset预期结果集规模稳定排序保证rate limiting按用户、按 IP 还是按 API key突发额度如何向客户端传达限制errors结构化错误格式错误码 vs 消息生产环境错误包含多少细节数据库Database用户提到Agent 用领域知识探测database / storageSQL 还是 NoSQL驱动选择的因素——关系完整性、灵活性、规模ORM / queriesORM哪个还是原生查询查询构建器作为中间方案migrations迁移工具回滚策略数据迁移 vs 结构迁移如何处理seeding / test data开发用种子数据逼真的假数据还是最小化 fixturesscale / performance读写比只读副本连接池策略搜索Search用户提到Agent 用领域知识探测search全文还是精确匹配专用搜索引擎还是数据库级filtering / facets分面过滤多少过滤维度组合过滤AND/ORautocomplete / typeahead防抖策略最小字符阈值结果排序indexing索引大小与更新频率实时索引还是批量可接受的索引延迟fuzzy / typo tolerance模糊匹配同义词支持语言相关的词干化文件上传与存储File Upload/Storage用户提到Agent 用领域知识探测upload / file upload本地文件系统还是云S3、GCS、Azure Blob直传还是经服务器images / media处理管线——缩放、压缩、缩略图生成格式转换size limits最大文件大小每用户最大总存储超限时怎么办CDN用 CDN 分发吗更新文件的缓存失效访问控制用签名 URLdocuments / attachments病毒扫描预览生成上传文件版本管理缓存Caching用户提到Agent 用领域知识探测caching / performance缓存在哪——浏览器、CDN、应用层、数据库查询缓存invalidation失效策略——TTL、事件驱动还是手动cache-aside vs write-throughstale data可接受的过期窗口stale-while-revalidate 模式Redis / Memcached缓存拓扑——单节点还是集群需要持久化还是纯缓存CDN / edge静态资源边缘缓存边缘动态内容缓存键策略测试Testing用户提到Agent 用领域知识探测testing / tests单元、集成、E2E 的配比测试投入重点在哪mocking / stubs模拟外部服务还是用 test containers数据库模拟策略CI / pipeline测试进 CI 吗并行执行PR 时测试还是 push 时测试coverage覆盖率目标作为门禁还是参考关注哪些指标行、分支、函数E2E / browser testingPlaywright、Cypress 还是其他有头还是无头视觉回归测试部署Deployment用户提到Agent 用领域知识探测deploy / hosting容器、serverless 还是传统 VM/VPS托管平台还是自托管CI/CD / pipelineGitHub Actions、GitLab CI 还是其他合并到 main 时部署还是手动触发environments多少环境dev、staging、prod环境一致性策略rollback回滚策略蓝绿、金丝雀还是即时回滚数据库回滚的考量secrets / config密钥管理——环境变量、vault 还是平台原生按环境的配置策略这些探测表的价值在于它们把领域专家的提问直觉编码成了可复用的模式使得 explore 对话能在 23 轮内就触及该领域最关键的隐藏权衡而不是停留在表面。五、输出工件与 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 配置。结合前文给实际使用者的几点建议把 explore 当作立项前的默认入口当想法只有一句话时不要急着/gsd:new-project或进入 plan-phase先/gsd:explore走完 36 轮对话让愿景在提问中成型信任一次一问的纪律批量问题会让对话变成问卷反而损失跟随能量所需的自然感单问、深挖、复述确认是让想法快速锋利的关键善用中途研究但不滥用事实性问题、技术选型对比适合触发gsd-phase-researcher35 条发现、200 词内纯思路探讨则不必打断节奏结晶时克制每次至多提议 4 个输出且必须等用户显式选择后再写文件避免把探索会话变成工件制造机理解输出类型的语义边界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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/10 1:19:46 · 阅读 1.2k get-shit-done 的 Socratic 式想法探索工作流：从模糊灵感到 GSD 工件的完整落地指南
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-doneGSD这套面向 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} Lets think through this together. Ill ask questions to help clarify the idea before we commit to any artifacts.如果没有主题则直接询问## Explore Whats on your mind? This could be a feature idea, an architectural question, a problem youre trying to solve, or something youre not sure about yet.注意措辞里刻意放开边界功能点子、架构疑问、待解决问题、甚至自己都还没想清楚的东西都算有效输入。开场的目标不是收集需求而是让开发者先倾倒出自己的心智模型。Step 2苏格拉底式对话25 轮这是工作流的灵魂环节原则由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中途研究提议23 轮之后当对话暴露出事实性问题、技术对比、或存在未知可以通过研究解决时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, lets keep exploring]如果同意则 spawn 研究子代理Agent( promptQuick research: {specific_question}. Return 3-5 key findings, no more than 200 words., subagent_typegsd-phase-researcher )这里有两个值得注意的工程细节。第一研究预算被显式约束35 条关键发现、不超过 200 词防止研究喧宾夺主。第二工作流包含一条ORCHESTRATOR RULE —— CODEX RUNTIME调用Agent()之后必须立即停止当前任务不得再读文件、改代码或跑测试等待子代理返回结果。这条规则防止了重复工作、冲突编辑和上下文浪费。同时工作流也给出反方向约束如果话题不需要研究直接跳过此步不要硬塞Dont force it.。Step 4输出结晶36 轮之后当对话达成自然结论、或开发者示意准备就绪时Agent 分析对话内容从下表中选择至多 4 个输出建议TypeDestinationWhen to suggestNote.planning/notes/{slug}.mdObservations, context, decisions worth rememberingTodo.planning/todos/pending/{slug}.mdConcrete actionable tasks identifiedSeed.planning/seeds/{slug}.mdForward-looking ideas with trigger conditionsResearch question.planning/research/questions.md(append)Open questions that need deeper investigationRequirementREQUIREMENTS.md(append)Clear requirements that emerged from discussionNew phaseROADMAP.md(append)Scope large enough to warrant its own phaseSpike/gsd:spike(invoke)Feasibility uncertainty surfaced — will this API work?, can we do X?Sketch/gsd:sketch(invoke)Design direction unclear — what should this look like?, how should this feel?呈现建议时使用模板Based on our conversation, Id 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.mdSketch 命令定义在 commands/gsd/sketch.md。Step 5写入选定输出对每个被选中的输出按其类型写入文件Notes创建.planning/notes/{slug}.mdfrontmatter 含 title、date、contextTodos创建.planning/todos/pending/{slug}.mdfrontmatter 含 title、date、prioritySeeds创建.planning/seeds/{slug}.mdfrontmatter 含 title、trigger_condition、planted_dateResearch questions追加到.planning/research/questions.mdRequirements追加到.planning/REQUIREMENTS.md使用下一个可用的 REQ IDPhases通过 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 的正确用法用结构化选项帮助用户思考是提问环节的重要工具好的选项是对用户可能意思的解释、用来确认/否认的具体例子、能暴露优先级的具象选择。坏的选项包括泛化分类技术 / 业务 / 其他、预设答案的诱导选项、选项过多24 个为佳、超过 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、Ill explain必须立刻停止使用 AskUserQuestion改用纯文本追问等待用户在普通输入框回复处理完自由输入后再恢复 AskUserQuestion。反模式清单清单式走动——不管用户说了什么机械地遍历所有领域罐头问题——脱离上下文地问你的核心价值是什么哪些超出范围公司腔——你的成功标准是什么你的干系人是谁审问——不基于回答追问只顾连续发问赶进度——为尽快干正事而压缩提问浅层接受——接受含糊答案而不深挖过早约束——在理解想法之前先问技术栈用户技能——永远不要问用户的技术经验Claude 负责构建。四、底层支撑二domain-probes.md 的领域探测模式get-shit-done/references/domain-probes.md 是共享参考explore 与 discuss-phase 等流程共用。当用户提到某个技术领域时用这些探测提出有洞察力的追问。原则是不要当清单跑而是根据上下文挑选 23 条最相关的目标是浮出用户可能还没考虑到的隐藏假设与权衡。认证Authentication用户提到Agent 用领域知识探测login / authOAuth哪些提供商、JWT 还是 session需要社交登录还是仅邮箱/密码users / accounts需要 MFA 吗密码重置流程邮箱验证sessions会话时长与刷新策略服务端会话还是无状态 tokenroles / permissionsRBAC、ABAC 还是简单角色检查需要多少种角色API keys密钥轮换策略每把密钥的作用域权限按密钥限流实时更新Real-Time Updates用户提到Agent 用领域知识探测real-time / live updatesWebSockets、SSE 还是轮询哪些必须实时 vs 允许最终一致notifications推送通知浏览器/移动端、仅应用内、还是两者都要持久化与已读回执collaboration / multiplayer冲突解决策略OT 还是 CRDT预期并发用户数chat / messaging消息历史与搜索输入指示器已读回执streaming重连策略断连时是排队还是丢弃仪表盘Dashboard用户提到Agent 用领域知识探测dashboard数据源有哪些多少种视图charts / graphs交互式还是静态支持钻取吗可导出 CSV/PDF 吗metrics / KPIs刷新策略——实时、周期轮询还是按需可接受的过期程度admin panel基于角色的可见性除查看外还有哪些操作编辑、删除、审批mobile / responsive简化移动视图还是完全一致图表支持触控交互吗API 设计API Design用户提到Agent 用领域知识探测APIREST、GraphQL 还是 RPC 风格仅内部还是对外公开endpoints / routes版本化策略URL 路径、header、query 参数破坏性变更政策pagination基于游标还是 offset预期结果集规模稳定排序保证rate limiting按用户、按 IP 还是按 API key突发额度如何向客户端传达限制errors结构化错误格式错误码 vs 消息生产环境错误包含多少细节数据库Database用户提到Agent 用领域知识探测database / storageSQL 还是 NoSQL驱动选择的因素——关系完整性、灵活性、规模ORM / queriesORM哪个还是原生查询查询构建器作为中间方案migrations迁移工具回滚策略数据迁移 vs 结构迁移如何处理seeding / test data开发用种子数据逼真的假数据还是最小化 fixturesscale / performance读写比只读副本连接池策略搜索Search用户提到Agent 用领域知识探测search全文还是精确匹配专用搜索引擎还是数据库级filtering / facets分面过滤多少过滤维度组合过滤AND/ORautocomplete / typeahead防抖策略最小字符阈值结果排序indexing索引大小与更新频率实时索引还是批量可接受的索引延迟fuzzy / typo tolerance模糊匹配同义词支持语言相关的词干化文件上传与存储File Upload/Storage用户提到Agent 用领域知识探测upload / file upload本地文件系统还是云S3、GCS、Azure Blob直传还是经服务器images / media处理管线——缩放、压缩、缩略图生成格式转换size limits最大文件大小每用户最大总存储超限时怎么办CDN用 CDN 分发吗更新文件的缓存失效访问控制用签名 URLdocuments / attachments病毒扫描预览生成上传文件版本管理缓存Caching用户提到Agent 用领域知识探测caching / performance缓存在哪——浏览器、CDN、应用层、数据库查询缓存invalidation失效策略——TTL、事件驱动还是手动cache-aside vs write-throughstale data可接受的过期窗口stale-while-revalidate 模式Redis / Memcached缓存拓扑——单节点还是集群需要持久化还是纯缓存CDN / edge静态资源边缘缓存边缘动态内容缓存键策略测试Testing用户提到Agent 用领域知识探测testing / tests单元、集成、E2E 的配比测试投入重点在哪mocking / stubs模拟外部服务还是用 test containers数据库模拟策略CI / pipeline测试进 CI 吗并行执行PR 时测试还是 push 时测试coverage覆盖率目标作为门禁还是参考关注哪些指标行、分支、函数E2E / browser testingPlaywright、Cypress 还是其他有头还是无头视觉回归测试部署Deployment用户提到Agent 用领域知识探测deploy / hosting容器、serverless 还是传统 VM/VPS托管平台还是自托管CI/CD / pipelineGitHub Actions、GitLab CI 还是其他合并到 main 时部署还是手动触发environments多少环境dev、staging、prod环境一致性策略rollback回滚策略蓝绿、金丝雀还是即时回滚数据库回滚的考量secrets / config密钥管理——环境变量、vault 还是平台原生按环境的配置策略这些探测表的价值在于它们把领域专家的提问直觉编码成了可复用的模式使得 explore 对话能在 23 轮内就触及该领域最关键的隐藏权衡而不是停留在表面。五、输出工件与 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 配置。结合前文给实际使用者的几点建议把 explore 当作立项前的默认入口当想法只有一句话时不要急着/gsd:new-project或进入 plan-phase先/gsd:explore走完 36 轮对话让愿景在提问中成型信任一次一问的纪律批量问题会让对话变成问卷反而损失跟随能量所需的自然感单问、深挖、复述确认是让想法快速锋利的关键善用中途研究但不滥用事实性问题、技术选型对比适合触发gsd-phase-researcher35 条发现、200 词内纯思路探讨则不必打断节奏结晶时克制每次至多提议 4 个输出且必须等用户显式选择后再写文件避免把探索会话变成工件制造机理解输出类型的语义边界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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考