GSD Discuss 模式指南Assumptions 与 Interview 双模式上下文采集【免费下载链接】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-doneGSDget-shit-done的discuss-phase命令负责在规划planning之前采集当前阶段的实现上下文。为了适配全新代码库 强用户主张与成熟代码库 高速上下文两类截然不同的场景GSD 提供了discussInterview访谈式与assumptions假设式两种运行模式。本文将以 docs/ko-KR/workflow-discuss-mode.md 为核心骨架结合英文原版 docs/workflow-discuss-mode.md 与仓库中的命令、工作流与子代理实现说明如何配置两种模式、各自的执行机制、输出格式与--auto等标志的兼容性帮助你在自己的 GSD 项目中选对上下文采集路径。两种模式什么时候该让 Claude 提问什么时候该让它先读代码GSD 的规划阶段需要锁定实现决策而决策的质量取决于上下文采集是否到位。discuss-phase因此提供两套完全不同的采集哲学详见 commands/gsd/discuss-phase.md 的命令说明。discussInterview默认模式这是最原始的访谈式流程。Claude 先分析当前阶段找出其中模糊的领域gray areas把它们列出供你勾选然后对每个领域约提 4 个问题逐个深挖直到信息充分。该模式适合以下情形代码库刚起步、处于早期阶段代码能提供的线索很少你对某个阶段有强烈的个人主张希望主动表达出来而不是被代码带偏你偏好被引导式的对话采集喜欢在问答中逐步厘清思路。assumptions代码库优先模式这是先读代码、再下结论的流程。Claude 通过子代理深度分析代码库读取 515 个相关文件形成带证据的假设assumption再提交给你确认或修正而不是机械地提问。该模式适合以下情形已进入中后期阶段代码库成熟、模式清晰很多问题读代码就有答案你觉得访谈式问题答案显而易见提问反而拖沓需要更快的上下文采集交互次数从约1520 次压缩到约24 次。两种模式的分工也可以这样理解源自 get-shit-done/workflows/discuss-phase-assumptions.md 的 philosophy 段落assumptions 模式把用户当作愿景家visionary而非代码库考古学家——用户只需要判断假设是否与自己的意图一致而无需回答那些 Claude 通过读代码就能自己搞清楚的问题。配置按项目切换模式配置通过 GSD 的 CLI 工具写入命令形式如下即 docs/ko-KR/workflow-discuss-mode.md 中的配置小节# 启用 assumptions 模式 node gsd-tools.cjs config-set workflow.discuss_mode assumptions # 切回访谈interview模式 node gsd-tools.cjs config-set workflow.discuss_mode discuss该配置按项目生效最终存储在项目根目录的.planning/config.json中。在配置目录文档 get-shit-done/references/planning-config.md 中可看到该键的完整契约定义配置键类型默认值可选值说明workflow.discuss_modestringdiscussdiscuss,assumptionsdiscuss-phase 的默认模式discuss运行交互式提问assumptions分析代码库并直接提出假设workflow.text_modebooleanfalsetrue,false使用纯文本编号列表代替 AskUserQuestion 菜单远程会话常用从 SDK 实现侧看sdk/src/config.ts 的配置 schema 中声明了discuss_mode: string字段而 get-shit-done/references/planning-config.md 也给出了其默认值锚点discuss_mode: discuss。模式在命令入口如何被路由模式并不是写死在某一个流程里的而是在 discuss-phase 命令的process段做动态路由见 commands/gsd/discuss-phase.md。大致逻辑如下DISCUSS_MODE$(gsd-sdk query config-get workflow.discuss_mode 2/dev/null || echo discuss) # 1) 若参数中带 --assumptions执行「列出假设」的纯对话流程 # 2) 否则若 DISCUSS_MODE assumptions执行 discuss-phase-assumptions 工作流 # 3) 否则discuss / 未设置 / 其他值执行原 discuss-phase 工作流这意味着存在三级触发命令行临时指定/gsd:discuss-phase 3 --assumptions之类会走纯对话式假设列出流程项目级配置workflow.discuss_mode assumptions会让后续所有 discuss 调用默认走 assumptions 工作流默认回退任何其他值包括未设置都会安全回退到传统的discuss模式。Assumptions 模式的五步工作方式根据 docs/ko-KR/workflow-discuss-mode.md 的概述assumptions 模式分五步推进下面把每一步对照 get-shit-done/workflows/discuss-phase-assumptions.md 中的真实流程节点展开。1. Init初始化— 与 discuss 模式完全一致加载先前上下文PROJECT.md、REQUIREMENTS.md、STATE.md、历史各阶段的-CONTEXT.md、侦察代码库、核对待办事项todo避免重复询问已经决定过的问题。2. 深度分析Deep analysis— explore 子代理读取与本阶段相关的 515 个代码库文件。在真实实现中这一步由专门的gsd-assumptions-analyzer子代理承担详见 agents/gsd-assumptions-analyzer.md它需要读取 ROADMAP.md 的阶段描述 → 读取早期阶段的 CONTEXT.md → 用 Glob/Grep 检索相关文件 → 精读 515 个源文件 → 返回结构化的假设。之所以用子代理而不是主对话读取是为了把原始文件内容挡在主导航上下文窗口之外保护 token 预算。3. 提出假设Surface assumptions— 每条假设都包含三要素这也是与访谈式提问最本质的区别Claude 打算怎么做、为什么这么做引用具体文件路径作为证据如果假设错了会发生什么具体的失败后果置信度等级Confident代码里看得很清楚/Likely合理推断/Unclear存在多种走向。子代理在返回时使用上述统一的置信度词汇表见 agents/gsd-assumptions-analyzer.md。4. 确认或修正Confirm or correct— 用户审阅全部假设勾选需要变更的条目对每条被勾选的条目Claude 只追问一个聚焦的问题并给出 23 个推荐选项推荐项排最前。5. 写入 CONTEXT.md— 输出格式与 discuss 模式完全一致详见后文输出一节每条假设映射为一条已锁定的决策编号D-01、D-02……用户修正则覆盖原假设。面向新代码的轻量假设变体若代码库仍不足以支撑深度分析--assumptions标志会路由到另一份纯对话工作流 get-shit-done/workflows/list-phase-assumptions.md。它与正式 assumptions 模式的关键区别在于它是对Claude 当前想法的分析analysis而不是对用户已有知识的采集intake不产生任何文件输出纯粹以对话形式围绕五个领域展开技术方案Technical Approach、实现顺序Implementation Order、范围边界Scope Boundaries、风险区Risk Areas、依赖Dependencies每条假设同样标注信心Fairly confident / Assuming / Unclear最后以 What do you think? 收尾等待反馈再引导进入 discuss-phase、plan-phase 或重新审视。校准Calibration假设数量与深度是自适应的assumptions 模式并非每次都抛出相同规模的假设。根据 get-shit-done/workflows/discuss-phase-assumptions.md 的deep_codebase_analysis步骤主流程会优先解析用户的偏好画像USER-PROFILE.md或项目级preferences.vendor_philosophy并映射到三级校准档位校准档触发来源假设领域数备选方案full_maturityconservative / thorough-evaluator 画像35 个每个 Likely/Unclear 项给 23 个备选standard默认档位34 个每个 Likely/Unclear 项给 2 个备选minimal_decisiveopinionated 画像23 个每项只给一个果断的推荐若未发现USER-PROFILE.md则按standard处理。同一套档位规则也固化在子代理描述中agents/gsd-assumptions-analyzer.md保证主流程与子代理口径一致。外部研究兜底如果子代理发现仅靠代码库不够的领域例如第三方库版本兼容性、生态最佳实践会返回needs_research列表主流程此时再拉起一个general-purpose研究子代理通过 Context7库相关或 WebSearch生态/最佳实践补齐证据并把结论合并回对应假设的置信度。若没有缺口这一步会直接跳过——大多数阶段都会跳过。与discuss完全一致的输出契约无论走哪种模式产出的 CONTEXT.md 都包含相同的 6 个章节骨架来自 docs/ko-KR/workflow-discuss-mode.md文件模板细节见 get-shit-done/templates/context.mddomain— 阶段范围阶段边界。来自 ROADMAP.md是固定的讨论只澄清范围内怎么做绝不决定是否新增能力decisions— 已锁定的实现决策。每条以D-01、D-02编号列出来自假设或用户修正置信度全为 Confident 的领域直接标记为锁定决策canonical_refs— 下游子代理必须先行阅读的规格/文档清单一律使用完整相对路径。这是必填章节没有外部规格时也要显式写明requirements fully captured in decisions above不得静默省略code_context— 可复用资产、既有模式、集成点来自代码库侦察与 explore 子代理的发现specifics— 用户的参考与偏好如我要像 pg_dump 一样的感觉这类原始表述deferred— 为后续阶段记录的搁置想法含讨论时被挡回的 scope creep 与未折叠的待办。值得注意的是CONTEXT.md 的类别并不是预定义死的模板强调类别从当前阶段真正讨论的内容中涌现——CLI 阶段产生 CLI 相关小节UI 阶段产生 UI 相关小节。而关键的纪律是下游子代理researcher、planner、checker不论模式一律以同一份文件、同一种方式消费因此切换模式对下游完全透明。配套的审计日志assumptions 模式还会额外写出{phase_num}-DISCUSSION-LOG.md审计日志见 get-shit-done/workflows/discuss-phase-assumptions.md 的write_discussion_log步骤记录展示过的假设及证据、发生的修正原假设 → 用户修正 → 理由、自动解析的 Unclear 项、外部研究结论。文件头部明确标注Audit trail only. Do not use as input to planning/research/execution agents.——它只保留过程痕迹决策仍以 CONTEXT.md 为准。标志兼容性--auto、--batch、--text、--analyze由于两种模式交互形态不同各标志的语义也有差异。下表完整继承自 docs/ko-KR/workflow-discuss-mode.md标志discuss模式assumptions模式--auto自动选择推荐答案跳过确认关卡自动处理 Unclear 项取推荐默认--batch将问题分批成组处理不适用修正本身已是批量处理--text纯文本提问远程会话纯文本提问远程会话--analyze显示每题权衡trade-off对照表不适用假设本身已内含证据--auto在 assumptions 工作流中是一条贯穿始终的自动化主线见 get-shit-done/workflows/discuss-phase-assumptions.md已有 CONTEXT.md 时自动选择 Update it展示假设时若全部为 Confident/Likely 则直接写上下文存在 Unclear 项时记录告警并用推荐默认值自动解析完成后再自动推进到 plan-phase。此外workflow.text_mode: true或--text会强制所有交互改用纯文本编号列表避免在远程会话中调用 AskUserQuestion 图形菜单。从命令到文件完整调用链一览把以上内容串起来一次 assumptions 模式的 discuss 触发后的完整链路为入口命令 commands/gsd/discuss-phase.md 读取配置并路由到 get-shit-done/workflows/discuss-phase-assumptions.md工作流经 init → check_existing复用/更新旧 CONTEXT.md→ load_prior_context → cross_reference_todos折叠相关待办→ load_methodology → scout_codebase优先复用已有代码地图deep_codebase_analysis拉起 agents/gsd-assumptions-analyzer.md 定义的分析子代理做深读并产出结构化假设必要时衔接外部研究子代理present_assumptions→correct_assumptions完成用户确认/修正write_context按 get-shit-done/templates/context.md 的六段模板落盘.planning/phases/{padded}-{slug}/{padded}-CONTEXT.mdwrite_discussion_log落盘审计日志随后由git_commit、update_state提交并更新 STATE.md若无--auto展示下一步建议通常引导进入/gsd:plan-phase。项目的自动化测试同样覆盖了该模式的选择与配置见 tests/discuss-mode.test.cjs、tests/config.test.cjs可作为理解模式切换行为与配置校验规则时的辅助证据。实践建议如果你在为一个全新仓库的第一个阶段做规划请保留默认的discuss模式——此时代码几乎没有可读的证据你的主张就是最稀缺的信息而当一个项目已经推进到中后期、各阶段模式成熟后一条config-set workflow.discuss_mode assumptions就能把每次阶段的上下文采集从约 1520 次问答压缩到 24 次假设确认让 Claude 把读代码能搞清楚的交给读代码把真正需要你判断的留给你。【免费下载链接】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），仅供参考