GSD 上下文收集双模式深入解析discuss 交互式访谈 vs assumptions 代码优先假设推断get-shit-done 实战指南【免费下载链接】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导读在 TÂCHES 的 get-shit-done下称 GSD这套基于 Claude Code 的轻量级 meta-prompting、上下文工程与规范驱动开发系统中discuss-phase是规划plan-phase之前最重要的“上下文收集”环节它把下游 Agent 在动手前必须知道的实现决定沉淀为 CONTEXT.md。本文基于仓库中的 workflow-discuss-mode.md及日文版 docs/ja-JP/workflow-discuss-mode.md系统讲解该阶段的两种工作模式——默认的discuss访谈式与assumptions代码库优先的假设推断式覆盖两种模式的适用场景、配置方法、底层工作流实现、命令行标志兼容性以及统一的六段式 CONTEXT.md 输出契约。读完本文你将能够判断何时切换模式、如何通过workflow.discuss_mode按项目级配置并理解每条假设背后的源码级实现依据。一、discuss-phase 在 GSD 工作流中的位置GSD 采用规范驱动spec-driven的 Phase 编排每个阶段在规划与执行前都需要先收集实现上下文。discuss-phase命令的 命令定义 明确指出它的目标Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.即产出决策足够清晰的{phase_num}-CONTEXT.md让下游 Agentresearcher 负责查什么、planner 负责哪些决定已被锁定不必再回头打扰用户。因此整个 discuss 阶段本质上解决一个问题——在用户脑中想怎么做与 Agent 需要写进计划的明确决定之间搭一座桥。它有两种模式供选择正是这座桥的两种不同搭法。二、两种模式概览与选型依据discuss默认访谈式这是 GSD 最初的访谈式流程Claude 先分析当前阶段识别出灰色地带gray areas即用户在乎、且存在多种合理做法的实现决策点把它们作为选项交给用户挑选然后对每个被选中的领域提出约 4 个问题进行逐层深挖。从官方文档的适用性描述看它适合三类情形代码库处于早期阶段尚无成熟模式可循无法由代码推断结论用户有强烈的个人主张希望主动表达如特定交互形态、命名偏好用户更享受引导式、对话式的上下文收集节奏。访谈式的实现细节可以从 discuss-phase.md 工作流 中得到印证它先按domain boundary → prior decisions → gray areas的顺序分析再用AskUserQuestion多选让用户圈定要讨论的领域进入discuss_areas后默认模式为每个领域 4 个单问题回合对应工作流中引用的modes/default.md直到满意为止。整个过程还会维护增量检查点DISCUSS-CHECKPOINT.json供会话中断后恢复。assumptions代码库优先假设推断式与访谈相反assumptions 模式先把代码库读透再带着证据给出判断Claude 通过子 Agent 深度分析代码库读取 515 个相关文件形成带证据的假设然后仅就哪里不对征求用户的确认与修正。官方文档给出的适用场景代码库模式已成熟稳定现有代码能直接回答该怎么做用户觉得访谈问题答案显而易见不想被逐个询问追求更快的上下文收集——整个流程约24 次往返而访谈式约1520 次。工作流文件里的设计哲学可以解释这一模式为何高效discuss-phase-assumptions.mdThe user is a visionary, not a codebase archaeologist. They need enough context to evaluate whether your assumptions match their intent — not to answer questions you could figure out by reading the code.并由此引出三条铁律先读代码、后形成观点、只问真正不清楚的问题每条假设必须引用证据文件路径、发现的模式每条假设必须说明若判断错误的后果把用户交互次数压到最低约 24 次修正 vs 1520 个问题。快速选型对照决策维度discuss访谈式assumptions假设式数据来源用户的意见与偏好代码库证据 用户修正互动强度约 1520 轮问答约 24 轮确认/修正适用阶段早期、代码库新、无模式可循模式成熟、经验丰富的代码库关键角色Claude 提问、用户回答Claude 读代码下结论、用户纠错产物六段式 CONTEXT.md六段式 CONTEXT.md完全一致三、配置按项目切换讨论模式配置命令workflow.discuss_mode是一个项目级字符串配置取值discuss默认或assumptions。原文档给出的设置方式为# 启用 assumptions 模式 gsd-tools config-set workflow.discuss_mode assumptions # 切回访谈模式 gsd-tools config-set workflow.discuss_mode discuss该配置按项目生效保存在项目根目录的.planning/config.json中。从当前仓库的源码看配置读取发生在 discuss-phase 命令定义 的模式路由处DISCUSS_MODE$(gsd-sdk query config-get workflow.discuss_mode 2/dev/null || echo discuss)即读不到该键时静默回退为discuss。配置的默认值在仓库的多处保持一致——默认配置模板 与 SDK 的 config-defaults.manifest.json 均声明discuss_mode: discussSDK 的配置类型定义见 sdk/src/config.ts。官方配置文档条目CONFIGURATION.md 对workflow.discuss_mode的完整说明类型string默认discuss。控制/gsd-discuss-phase如何收集上下文discuss默认逐个提问assumptions先读代码库、生成带置信度级别的结构化假设只请你修正错误之处。v1.28 加入。与相邻配置键的关系讨论阶段的体验还受另外两个工作流开关影响配置时值得一并了解配置键默认说明workflow.discuss_modediscuss本文核心assumptions启用代码优先模式workflow.text_modefalse用纯文本编号列表替换AskUserQuestion交互菜单远程会话必需等价于每次运行的--text标志workflow.max_discuss_passes3discuss-phase 的最大提问轮数防止无人值守/自动模式下无限讨论四、模式路由配置级与命令级的两条入口需要特别澄清的是仓库中存在配置级路由与命令级标志路由两个层次它们会走向不同的工作流文件见 commands/gsd/discuss-phase.md--assumptions命令标志每次运行级若在参数中检测到--assumptions直接执行 list-phase-assumptions.md 并结束。这是一个纯对话式的假设预检流程——按技术方案、实现顺序、范围边界、风险点、依赖五个维度展示 Claude 的理解等待用户确认或纠正不产出 CONTEXT.md 文件可视为正式讨论前的摸底。workflow.discuss_mode配置项目级默认当配置值为assumptions时执行完整的 discuss-phase-assumptions.md该流程会真正写出 CONTEXT.md。其他情况discuss/未设置/任意其他值回退到访谈式 discuss-phase.md。也就是说日常使用中绝大多数场景走第 2、3 条路径——本文第四节Assumptions 模式的工作机制描述的正是完整上下文捕获流程。五、Assumptions 模式的五步工作机制原文档将 assumptions 模式归纳为五步仓库中的 discuss-phase-assumptions.md 提供了每一步的完整源码级实现对比如下第 1 步初始化Init与 discuss 模式完全相同的启动过程解析$ARGUMENTS中的阶段号通过gsd-sdk query init.phase-op ${PHASE}获取阶段信息phase_found、phase_dir、has_context、has_plans、plan_count等若阶段不存在则提示使用/gsd:progress查看可用阶段并退出。随后依次执行check_existing若该阶段已有 CONTEXT.md询问Update it / View it / Skip若已有计划文件则询问是否Continue and replan after。load_prior_context读取.planning/PROJECT.md、REQUIREMENTS.md、STATE.md以及此前各阶段的*-CONTEXT.md构建内部prior_decisions避免重复询问已决定的问题。cross_reference_todos通过todo.match-phase查找与本阶段相关的待办让用户决定哪些并入本次范围自动模式下 score ≥ 0.4 的待办会被自动折叠。load_methodology若存在.planning/METHODOLOGY.md解析各具名 lens诊断与建议让活跃 lens 参与假设的生成与评估。第 2 步深度分析Deep analysisClaude 派生gsd-assumptions-analyzer子 Agent 深入分析代码库。这样设计的目的在工作流中有明确说明把原始文件内容挡在主干上下文窗口之外保护 Token 预算见 discuss-phase-assumptions.md。子 Agent 的能力契约定义在 agents/gsd-assumptions-analyzer.md其工具集仅限Read, Bash, Grep, Glob不联网搜索核心任务为读取 ROADMAP.md 的阶段描述与历史 CONTEXT.md → 用 Glob/Grep 定位相关文件 →读取 515 个最相关源文件→ 输出结构化假设并把代码库无法回答的问题如三方库版本兼容性、生态最佳实践单独标记为Needs External Research。关键细节是**校准层级calibration tier**机制根据用户画像USER-PROFILE.md 中的 vendor philosophy优先级低于项目配置preferences.vendor_philosophy决定假设的密度校准层级假设领域数每个 Likely/Unclear 项可选方案证据深度full_maturity保守/审慎型3523 个带行级的详细路径引用standard默认342 个文件路径引用minimal_decisive果断型23单一果断推荐仅关键路径若子 Agent 标记了需要外部研究的话题工作流会再派生一个 general-purpose 研究 Agent通过 Context7 查库、WebSearch 查生态并把研究结论回填到对应假设的置信度与来源上——大多数阶段会跳过这一步。第 3 步呈现假设Surface assumptions子 Agent 返回后主工作流按领域分组展示假设。每条假设固定携带三要素这正是本文第一部分的原文档骨架也是区别于访谈式的核心Claude 打算做什么、为什么——引用文件路径作为证据Why this way若假设错误会出什么问题——具体的、可感知的后果而非空泛的可能有问题If wrong置信度级别——Confident代码可直接证实/Likely合理推断/Unclear有多种可能。子 Agent 的 输出格式模板 与规则进一步强调每条假设必须至少引用一条文件路径证据、必须给出具体后果、禁止夸大Confident、禁止超出阶段边界做范围扩张。第 4 步确认或修正Confirm or correct假设展示后Claude 通过AskUserQuestion给出确认门confirm gate问题These all look right?这些看起来都对吗选项Yes, proceed把假设作为决定写入 CONTEXT.md/ Let me correct some让我修正其中一些选择修正时进入多选修正界面每个选项的 label 是假设原文、description 是If wrong后果用户勾选后Claude 再对每个被选中的假设追问那我们改成什么并给出 23 个描述用户可感知结果的具体替代方案推荐项排首位逐条记录原始假设、用户选择与理由。第 5 步生成 CONTEXT.mdWrite context确认/修正完毕后写入与 discuss 模式完全同格式的${phase_dir}/${padded_phase}-CONTEXT.md。假设→决定的映射规则为每条假设变成一条锁定决定D-01、D-02…用户修正覆盖原假设全 Confident 领域直接标记为锁定决定并入的待办进入decisions下的 Folded Todos。此外assumptions 模式还额外写一份DISCUSSION-LOG.md 审计日志假设表 修正记录 自动处理记录文件头部明确标注Audit trail only. Do not use as input to planning, research, or execution agents.——它只供人工复盘下游 Agent 一律不消费。随后工作流会把 CONTEXT.md 与 DISCUSSION-LOG.md 提交并更新.planning/STATE.md记录会话断点方便下次/resume。六、命令行标志兼容性矩阵原文档给出了两种模式下的标志兼容表这是命令入口层面的行为契约现完整继承并标注仓库实现依据标志discuss模式assumptions模式--auto自动选择推荐答案跳过确认门自动解析 Unclear 项--batch将问题分组批量呈现N/A修正本身已批量处理--text纯文本形式提问远程会话用纯文本形式提问远程会话用--analyze每个问题前展示权衡对比表N/A假设本身已含证据在 discuss-phase-assumptions.md 中可验证--auto的完整语义L86-L92、L364-L369初始化与 check_existing 阶段自动选择 Update it / Continue and replan afterpresent_assumptions 阶段若全部假设为 Confident 或 Likely直接跳过确认门进入 write_context并记录日志[auto] All assumptions Confident/Likely — proceeding to context capture.若存在 Unclear 项为每项自动选择推荐方案并记录[auto] {N} Unclear assumptions auto-resolved with recommended defaults.流程结束自动推进到 plan-phase显示GSD ► AUTO-ADVANCING TO PLAN横幅。--text在两个工作流中的语义一致任何AskUserQuestion调用都会被替换为纯文本编号列表用户输入序号作答若回答为空则重试一次仍为空则降级为纯文本列表——这是 Claude Code远程会话/rc模式下 UI 菜单无法渲染时的必选项也可通过配置键workflow.text_mode持久化开启。--batch、--analyze属于访谈式工作流的叠加层overlay在 discuss-phase.md 中按--analyze→--batch→--text的固定顺序叠加例如--batch --analyze 每批问题前先出权衡表。而 assumptions 模式天然不再需要它们——这正是矩阵中标 N/A 的原因--batch的批量性已被一次性展示全部假设取代--analyze的权衡信息已被每条假设自带证据与后果取代。附注另有命令级--assumptions标志见第四节它运行的是纯对话式的 list-phase-assumptions.md不写文件、只做预检与配置驱动的完整 assumptions 流程是两个不同入口。七、统一输出契约六段式 CONTEXT.md无论以哪种模式讨论最终产物的结构完全一致这是 downstream 消费者researcher、planner、checker无需感知模式差异就能统一消费的关键设计。六段结构如下段标记内容含义domain阶段边界Phase Boundary——本阶段该做什么的锚点源自 ROADMAP.mddecisions已锁定的实现决定D-01、D-02…canonical_refs下游 Agent 在规划/实现前必须阅读的规范、文档、ADRcode_context可复用资产、既有模式、集成点specifics用户的参考对象与偏好我要做成 X 那样deferred延后到未来阶段的思路Deferred Ideasassumptions 工作流中的 write_context 模板 揭示了几个值得注意的实现细节canonical_refs是强制的累积来源包括 ROADMAP.md 该阶段的 Canonical refs、REQUIREMENTS.md/PROJECT.md 引用的规格与 ADR、以及代码库侦察中发现的文档引用每条都必须展开为完整相对路径成功标准中标注 MANDATORY。若确无外部规格需显式注明 No external specs — requirements fully captured in decisions above。code_context沉淀代码洞察细分为 Reusable Assets可复用资产、Established Patterns既有模式、Integration Points集成点三个子块内容源自代码库侦察与 Explore 子 Agent 的发现。deferred承载范围外想法讨论中出现的越界想法scope creep统一放入此处并标注 would be a new capability — thats its own phase既不丢失也不执行。两个工作流文件都内置了这条范围护栏discuss-phase.md 与 discuss-phase-assumptions.md。头部会标注**Gathered:** {date} (assumptions mode)与 discuss 模式的产物在语义上无缝衔接文件写入后随即提交并更新 STATE.md。八、实践建议与小结综合官方文档与仓库实现选择讨论模式的务实建议是项目早期、前几个阶段默认discuss访谈式。此时没有既成模式可推断且用户通常对产品愿景有强烈想法逐题深挖能沉淀出更高质量的specifics。中后期、代码库模式成型后切换assumptions。用户不再想回答代码里已经写着答案的问题Confident/Likely假设能在一两次往返内锁定绝大多数决定。想先摸底再决定在单个阶段上使用--assumptions标志做纯对话式预检不改动项目级配置。远程/无人值守场景组合--auto跳过确认门与--text纯文本提问或将workflow.text_mode持久化配置。无论哪种模式CONTEXT.md 的六段结构、canonical_refs的完整路径要求、越界想法进deferred的护栏都是统一不变的下游 researcher → planner → checker 无需感知模式差异。一句话总结discuss把用户当作信息源来采访assumptions把代码库当作信息源来取证、把用户当作评审者来复核——两者殊途同归都为了在规划前把决定锁定成一份下游 Agent 可直接执行的 CONTEXT.md。延伸阅读仓库内索引docs/workflow-discuss-mode.md本文主题的英文权威版与 docs/ja-JP/workflow-discuss-mode.md命令入口与路由逻辑commands/gsd/discuss-phase.md访谈式完整工作流get-shit-done/workflows/discuss-phase.md假设式完整工作流get-shit-done/workflows/discuss-phase-assumptions.md对话式假设预检--assumptions标志get-shit-done/workflows/list-phase-assumptions.md假设分析子 Agent 契约agents/gsd-assumptions-analyzer.md配置键总表含workflow.discuss_mode、text_mode、max_discuss_passesdocs/CONFIGURATION.md默认配置模板与 SDK 默认清单get-shit-done/templates/config.json、sdk/shared/config-defaults.manifest.json【免费下载链接】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），仅供参考 GSD 上下文收集双模式深入解析：discuss 交互式访谈 vs assumptions 代码优先假设推断（get-shit-done 实战指南）
GSD 上下文收集双模式深入解析discuss 交互式访谈 vs assumptions 代码优先假设推断get-shit-done 实战指南【免费下载链接】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导读在 TÂCHES 的 get-shit-done下称 GSD这套基于 Claude Code 的轻量级 meta-prompting、上下文工程与规范驱动开发系统中discuss-phase是规划plan-phase之前最重要的“上下文收集”环节它把下游 Agent 在动手前必须知道的实现决定沉淀为 CONTEXT.md。本文基于仓库中的 workflow-discuss-mode.md及日文版 docs/ja-JP/workflow-discuss-mode.md系统讲解该阶段的两种工作模式——默认的discuss访谈式与assumptions代码库优先的假设推断式覆盖两种模式的适用场景、配置方法、底层工作流实现、命令行标志兼容性以及统一的六段式 CONTEXT.md 输出契约。读完本文你将能够判断何时切换模式、如何通过workflow.discuss_mode按项目级配置并理解每条假设背后的源码级实现依据。一、discuss-phase 在 GSD 工作流中的位置GSD 采用规范驱动spec-driven的 Phase 编排每个阶段在规划与执行前都需要先收集实现上下文。discuss-phase命令的 命令定义 明确指出它的目标Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.即产出决策足够清晰的{phase_num}-CONTEXT.md让下游 Agentresearcher 负责查什么、planner 负责哪些决定已被锁定不必再回头打扰用户。因此整个 discuss 阶段本质上解决一个问题——在用户脑中想怎么做与 Agent 需要写进计划的明确决定之间搭一座桥。它有两种模式供选择正是这座桥的两种不同搭法。二、两种模式概览与选型依据discuss默认访谈式这是 GSD 最初的访谈式流程Claude 先分析当前阶段识别出灰色地带gray areas即用户在乎、且存在多种合理做法的实现决策点把它们作为选项交给用户挑选然后对每个被选中的领域提出约 4 个问题进行逐层深挖。从官方文档的适用性描述看它适合三类情形代码库处于早期阶段尚无成熟模式可循无法由代码推断结论用户有强烈的个人主张希望主动表达如特定交互形态、命名偏好用户更享受引导式、对话式的上下文收集节奏。访谈式的实现细节可以从 discuss-phase.md 工作流 中得到印证它先按domain boundary → prior decisions → gray areas的顺序分析再用AskUserQuestion多选让用户圈定要讨论的领域进入discuss_areas后默认模式为每个领域 4 个单问题回合对应工作流中引用的modes/default.md直到满意为止。整个过程还会维护增量检查点DISCUSS-CHECKPOINT.json供会话中断后恢复。assumptions代码库优先假设推断式与访谈相反assumptions 模式先把代码库读透再带着证据给出判断Claude 通过子 Agent 深度分析代码库读取 515 个相关文件形成带证据的假设然后仅就哪里不对征求用户的确认与修正。官方文档给出的适用场景代码库模式已成熟稳定现有代码能直接回答该怎么做用户觉得访谈问题答案显而易见不想被逐个询问追求更快的上下文收集——整个流程约24 次往返而访谈式约1520 次。工作流文件里的设计哲学可以解释这一模式为何高效discuss-phase-assumptions.mdThe user is a visionary, not a codebase archaeologist. They need enough context to evaluate whether your assumptions match their intent — not to answer questions you could figure out by reading the code.并由此引出三条铁律先读代码、后形成观点、只问真正不清楚的问题每条假设必须引用证据文件路径、发现的模式每条假设必须说明若判断错误的后果把用户交互次数压到最低约 24 次修正 vs 1520 个问题。快速选型对照决策维度discuss访谈式assumptions假设式数据来源用户的意见与偏好代码库证据 用户修正互动强度约 1520 轮问答约 24 轮确认/修正适用阶段早期、代码库新、无模式可循模式成熟、经验丰富的代码库关键角色Claude 提问、用户回答Claude 读代码下结论、用户纠错产物六段式 CONTEXT.md六段式 CONTEXT.md完全一致三、配置按项目切换讨论模式配置命令workflow.discuss_mode是一个项目级字符串配置取值discuss默认或assumptions。原文档给出的设置方式为# 启用 assumptions 模式 gsd-tools config-set workflow.discuss_mode assumptions # 切回访谈模式 gsd-tools config-set workflow.discuss_mode discuss该配置按项目生效保存在项目根目录的.planning/config.json中。从当前仓库的源码看配置读取发生在 discuss-phase 命令定义 的模式路由处DISCUSS_MODE$(gsd-sdk query config-get workflow.discuss_mode 2/dev/null || echo discuss)即读不到该键时静默回退为discuss。配置的默认值在仓库的多处保持一致——默认配置模板 与 SDK 的 config-defaults.manifest.json 均声明discuss_mode: discussSDK 的配置类型定义见 sdk/src/config.ts。官方配置文档条目CONFIGURATION.md 对workflow.discuss_mode的完整说明类型string默认discuss。控制/gsd-discuss-phase如何收集上下文discuss默认逐个提问assumptions先读代码库、生成带置信度级别的结构化假设只请你修正错误之处。v1.28 加入。与相邻配置键的关系讨论阶段的体验还受另外两个工作流开关影响配置时值得一并了解配置键默认说明workflow.discuss_modediscuss本文核心assumptions启用代码优先模式workflow.text_modefalse用纯文本编号列表替换AskUserQuestion交互菜单远程会话必需等价于每次运行的--text标志workflow.max_discuss_passes3discuss-phase 的最大提问轮数防止无人值守/自动模式下无限讨论四、模式路由配置级与命令级的两条入口需要特别澄清的是仓库中存在配置级路由与命令级标志路由两个层次它们会走向不同的工作流文件见 commands/gsd/discuss-phase.md--assumptions命令标志每次运行级若在参数中检测到--assumptions直接执行 list-phase-assumptions.md 并结束。这是一个纯对话式的假设预检流程——按技术方案、实现顺序、范围边界、风险点、依赖五个维度展示 Claude 的理解等待用户确认或纠正不产出 CONTEXT.md 文件可视为正式讨论前的摸底。workflow.discuss_mode配置项目级默认当配置值为assumptions时执行完整的 discuss-phase-assumptions.md该流程会真正写出 CONTEXT.md。其他情况discuss/未设置/任意其他值回退到访谈式 discuss-phase.md。也就是说日常使用中绝大多数场景走第 2、3 条路径——本文第四节Assumptions 模式的工作机制描述的正是完整上下文捕获流程。五、Assumptions 模式的五步工作机制原文档将 assumptions 模式归纳为五步仓库中的 discuss-phase-assumptions.md 提供了每一步的完整源码级实现对比如下第 1 步初始化Init与 discuss 模式完全相同的启动过程解析$ARGUMENTS中的阶段号通过gsd-sdk query init.phase-op ${PHASE}获取阶段信息phase_found、phase_dir、has_context、has_plans、plan_count等若阶段不存在则提示使用/gsd:progress查看可用阶段并退出。随后依次执行check_existing若该阶段已有 CONTEXT.md询问Update it / View it / Skip若已有计划文件则询问是否Continue and replan after。load_prior_context读取.planning/PROJECT.md、REQUIREMENTS.md、STATE.md以及此前各阶段的*-CONTEXT.md构建内部prior_decisions避免重复询问已决定的问题。cross_reference_todos通过todo.match-phase查找与本阶段相关的待办让用户决定哪些并入本次范围自动模式下 score ≥ 0.4 的待办会被自动折叠。load_methodology若存在.planning/METHODOLOGY.md解析各具名 lens诊断与建议让活跃 lens 参与假设的生成与评估。第 2 步深度分析Deep analysisClaude 派生gsd-assumptions-analyzer子 Agent 深入分析代码库。这样设计的目的在工作流中有明确说明把原始文件内容挡在主干上下文窗口之外保护 Token 预算见 discuss-phase-assumptions.md。子 Agent 的能力契约定义在 agents/gsd-assumptions-analyzer.md其工具集仅限Read, Bash, Grep, Glob不联网搜索核心任务为读取 ROADMAP.md 的阶段描述与历史 CONTEXT.md → 用 Glob/Grep 定位相关文件 →读取 515 个最相关源文件→ 输出结构化假设并把代码库无法回答的问题如三方库版本兼容性、生态最佳实践单独标记为Needs External Research。关键细节是**校准层级calibration tier**机制根据用户画像USER-PROFILE.md 中的 vendor philosophy优先级低于项目配置preferences.vendor_philosophy决定假设的密度校准层级假设领域数每个 Likely/Unclear 项可选方案证据深度full_maturity保守/审慎型3523 个带行级的详细路径引用standard默认342 个文件路径引用minimal_decisive果断型23单一果断推荐仅关键路径若子 Agent 标记了需要外部研究的话题工作流会再派生一个 general-purpose 研究 Agent通过 Context7 查库、WebSearch 查生态并把研究结论回填到对应假设的置信度与来源上——大多数阶段会跳过这一步。第 3 步呈现假设Surface assumptions子 Agent 返回后主工作流按领域分组展示假设。每条假设固定携带三要素这正是本文第一部分的原文档骨架也是区别于访谈式的核心Claude 打算做什么、为什么——引用文件路径作为证据Why this way若假设错误会出什么问题——具体的、可感知的后果而非空泛的可能有问题If wrong置信度级别——Confident代码可直接证实/Likely合理推断/Unclear有多种可能。子 Agent 的 输出格式模板 与规则进一步强调每条假设必须至少引用一条文件路径证据、必须给出具体后果、禁止夸大Confident、禁止超出阶段边界做范围扩张。第 4 步确认或修正Confirm or correct假设展示后Claude 通过AskUserQuestion给出确认门confirm gate问题These all look right?这些看起来都对吗选项Yes, proceed把假设作为决定写入 CONTEXT.md/ Let me correct some让我修正其中一些选择修正时进入多选修正界面每个选项的 label 是假设原文、description 是If wrong后果用户勾选后Claude 再对每个被选中的假设追问那我们改成什么并给出 23 个描述用户可感知结果的具体替代方案推荐项排首位逐条记录原始假设、用户选择与理由。第 5 步生成 CONTEXT.mdWrite context确认/修正完毕后写入与 discuss 模式完全同格式的${phase_dir}/${padded_phase}-CONTEXT.md。假设→决定的映射规则为每条假设变成一条锁定决定D-01、D-02…用户修正覆盖原假设全 Confident 领域直接标记为锁定决定并入的待办进入decisions下的 Folded Todos。此外assumptions 模式还额外写一份DISCUSSION-LOG.md 审计日志假设表 修正记录 自动处理记录文件头部明确标注Audit trail only. Do not use as input to planning, research, or execution agents.——它只供人工复盘下游 Agent 一律不消费。随后工作流会把 CONTEXT.md 与 DISCUSSION-LOG.md 提交并更新.planning/STATE.md记录会话断点方便下次/resume。六、命令行标志兼容性矩阵原文档给出了两种模式下的标志兼容表这是命令入口层面的行为契约现完整继承并标注仓库实现依据标志discuss模式assumptions模式--auto自动选择推荐答案跳过确认门自动解析 Unclear 项--batch将问题分组批量呈现N/A修正本身已批量处理--text纯文本形式提问远程会话用纯文本形式提问远程会话用--analyze每个问题前展示权衡对比表N/A假设本身已含证据在 discuss-phase-assumptions.md 中可验证--auto的完整语义L86-L92、L364-L369初始化与 check_existing 阶段自动选择 Update it / Continue and replan afterpresent_assumptions 阶段若全部假设为 Confident 或 Likely直接跳过确认门进入 write_context并记录日志[auto] All assumptions Confident/Likely — proceeding to context capture.若存在 Unclear 项为每项自动选择推荐方案并记录[auto] {N} Unclear assumptions auto-resolved with recommended defaults.流程结束自动推进到 plan-phase显示GSD ► AUTO-ADVANCING TO PLAN横幅。--text在两个工作流中的语义一致任何AskUserQuestion调用都会被替换为纯文本编号列表用户输入序号作答若回答为空则重试一次仍为空则降级为纯文本列表——这是 Claude Code远程会话/rc模式下 UI 菜单无法渲染时的必选项也可通过配置键workflow.text_mode持久化开启。--batch、--analyze属于访谈式工作流的叠加层overlay在 discuss-phase.md 中按--analyze→--batch→--text的固定顺序叠加例如--batch --analyze 每批问题前先出权衡表。而 assumptions 模式天然不再需要它们——这正是矩阵中标 N/A 的原因--batch的批量性已被一次性展示全部假设取代--analyze的权衡信息已被每条假设自带证据与后果取代。附注另有命令级--assumptions标志见第四节它运行的是纯对话式的 list-phase-assumptions.md不写文件、只做预检与配置驱动的完整 assumptions 流程是两个不同入口。七、统一输出契约六段式 CONTEXT.md无论以哪种模式讨论最终产物的结构完全一致这是 downstream 消费者researcher、planner、checker无需感知模式差异就能统一消费的关键设计。六段结构如下段标记内容含义domain阶段边界Phase Boundary——本阶段该做什么的锚点源自 ROADMAP.mddecisions已锁定的实现决定D-01、D-02…canonical_refs下游 Agent 在规划/实现前必须阅读的规范、文档、ADRcode_context可复用资产、既有模式、集成点specifics用户的参考对象与偏好我要做成 X 那样deferred延后到未来阶段的思路Deferred Ideasassumptions 工作流中的 write_context 模板 揭示了几个值得注意的实现细节canonical_refs是强制的累积来源包括 ROADMAP.md 该阶段的 Canonical refs、REQUIREMENTS.md/PROJECT.md 引用的规格与 ADR、以及代码库侦察中发现的文档引用每条都必须展开为完整相对路径成功标准中标注 MANDATORY。若确无外部规格需显式注明 No external specs — requirements fully captured in decisions above。code_context沉淀代码洞察细分为 Reusable Assets可复用资产、Established Patterns既有模式、Integration Points集成点三个子块内容源自代码库侦察与 Explore 子 Agent 的发现。deferred承载范围外想法讨论中出现的越界想法scope creep统一放入此处并标注 would be a new capability — thats its own phase既不丢失也不执行。两个工作流文件都内置了这条范围护栏discuss-phase.md 与 discuss-phase-assumptions.md。头部会标注**Gathered:** {date} (assumptions mode)与 discuss 模式的产物在语义上无缝衔接文件写入后随即提交并更新 STATE.md。八、实践建议与小结综合官方文档与仓库实现选择讨论模式的务实建议是项目早期、前几个阶段默认discuss访谈式。此时没有既成模式可推断且用户通常对产品愿景有强烈想法逐题深挖能沉淀出更高质量的specifics。中后期、代码库模式成型后切换assumptions。用户不再想回答代码里已经写着答案的问题Confident/Likely假设能在一两次往返内锁定绝大多数决定。想先摸底再决定在单个阶段上使用--assumptions标志做纯对话式预检不改动项目级配置。远程/无人值守场景组合--auto跳过确认门与--text纯文本提问或将workflow.text_mode持久化配置。无论哪种模式CONTEXT.md 的六段结构、canonical_refs的完整路径要求、越界想法进deferred的护栏都是统一不变的下游 researcher → planner → checker 无需感知模式差异。一句话总结discuss把用户当作信息源来采访assumptions把代码库当作信息源来取证、把用户当作评审者来复核——两者殊途同归都为了在规划前把决定锁定成一份下游 Agent 可直接执行的 CONTEXT.md。延伸阅读仓库内索引docs/workflow-discuss-mode.md本文主题的英文权威版与 docs/ja-JP/workflow-discuss-mode.md命令入口与路由逻辑commands/gsd/discuss-phase.md访谈式完整工作流get-shit-done/workflows/discuss-phase.md假设式完整工作流get-shit-done/workflows/discuss-phase-assumptions.md对话式假设预检--assumptions标志get-shit-done/workflows/list-phase-assumptions.md假设分析子 Agent 契约agents/gsd-assumptions-analyzer.md配置键总表含workflow.discuss_mode、text_mode、max_discuss_passesdocs/CONFIGURATION.md默认配置模板与 SDK 默认清单get-shit-done/templates/config.json、sdk/shared/config-defaults.manifest.json【免费下载链接】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），仅供参考