get-shit-done Discuss Phase 双模式深入解析assumptions代码先行式上下文收集与standard访谈式提问【免费下载链接】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的/gsd-discuss-phase命令负责在正式规划前收集“实现阶段上下文”是衔接需求与plan-phase的关键环节。为了适配不同类型的项目与人机协作偏好GSD 提供standard访谈式提问与assumptions代码先行式假设确认两种工作模式。本文围绕 GSD 官方工作流说明 workflow-discuss-mode.md并对照其英文权威版本 docs/workflow-discuss-mode.md系统对比两种模式的适用场景与取舍结合仓库中的命令路由、工作流实现与测试代码完整讲解配置方法、assumptions模式的端到端执行流程、命令行 Flag 兼容矩阵以及统一的 CONTEXT.md 输出规范帮助你依据项目成熟度与个人协作偏好选出最合适的上下文收集方式。一、背景discuss-phase 在 GSD 管线中的位置在 GSD 的分阶段开发方法论中每个里程碑阶段通常遵循“讨论discuss→ 研究research→ 规划plan→ 执行execute→ 验证verify”的链路。/gsd-discuss-phase位于链路最前端其目标非常明确——把阶段范围内尚未决定的“灰色地带”gray areas收敛为可执行决策产出{phase_num}-CONTEXT.md供下游gsd-phase-researcher决定“研究什么”、gsd-planner决定“哪些选择已被锁定”从而避免用户反复回答问题。正如命令定义文件 commands/gsd/discuss-phase.md 所述Output:{phase_num}-CONTEXT.md— decisions clear enough that downstream agents can act without asking the user again.GSD 为此提供了两种风格mode以适配不同团队的工作习惯与代码库状态模式收集方式交互密度核心哲学standard即discuss默认开放访谈围绕灰色地带逐个提问约 15–20 次问答通过引导式对话挖掘用户偏好assumptions代码库分析优先先生成带证据的假设再由用户确认/纠正约 2–4 次纠正确认用户是“愿景家”而非“代码考古学家”只让其纠正错误假设[!NOTE] 多语言版说明文档本主题 pt-BR 版中指出在存在多个 runtime 与动态模型 profile 的环境中当“复用既有代码模式”是优先目标时应优先选用assumptions模式。二、两种模式的适用场景与取舍standard何时使用按 pt-BR 版说明 的建议standard适合以下情形项目尚未形成清晰的代码约定/标准你希望自由地探索替代方案存在尚未拍板的产品/UX 决策。优势发现面广descoberta ampla能把用户脑子里尚未成型的偏好充分“问”出来。代价可能消耗更多提问时间。对照英文权威版 docs/workflow-discuss-mode.mdinterview 风格的细分适用点还包括代码库较新、几乎不存在既有约束的早期阶段用户对阶段有强烈主观意见、并希望主动表达用户偏爱“有引导、偏对话式”的上下文收集方式。assumptions何时使用适合代码库已经沉淀出稳定、清晰的约定访谈式问题对用户而言过于“显而易见”提问变成摩擦团队更愿意评审“提案/假设”而不是接受一场开放式访谈。优势速度快、与既有代码保持一致。代价效果依赖代码库上下文映射mapping de contexto的质量——代码本身读得越准假设越可靠。三、如何启用三种配置途径assumptions模式并非一次性临时开关而是项目级持久化配置读取键为workflow.discuss_mode。途径 1交互式设置通过/gsd-settings设置对应 settings.md 工作流 中discuss_mode: discuss | assumptions的选择项等效 JSON 配置为{ workflow: { discuss_mode: assumptions } }途径 2CLI 直接配置默认值含义从 docs/workflow-discuss-mode.md 可知也可以用 gsd-tools CLI 一键切换# 启用 assumptions 模式 node gsd-tools.cjs config-set workflow.discuss_mode assumptions # 切回访谈模式discuss 为默认值可不设 node gsd-tools.cjs config-set workflow.discuss_mode discuss该配置按项目隔离存储位于项目内.planning/config.json。仓库侧的默认值证据包括默认清单 sdk/shared/config-defaults.manifest.json 中discuss_mode: discuss参考文档 planning-config.md 的字段表workflow.discuss_mode类型string默认discuss合法值discuss、assumptions配置总览 docs/CONFIGURATION.md 注明该键在 v1.28 加入并解释discuss默认逐个提问assumptions先读代码库、生成带置信度的结构化假设、只要求你纠正错误项。途径 3命令行级临时路由值得注意的是除了全局配置命令本身也接受--assumptions标志进行单次覆盖路由。见 commands/gsd/discuss-phase.md 中的“Mode routing”逻辑DISCUSS_MODE$(gsd-sdk query config-get workflow.discuss_mode 2/dev/null || echo discuss)路由优先级为--assumptions标志 → 配置值为assumptions→ 其余一律走discuss。也就是说即便没有改配置你也可以对某一个阶段临时发起“假设面谈”见本文第六节。四、assumptions模式的完整执行流程此部分依据 get-shit-done/workflows/discuss-phase-assumptions.md 的实现展开。pt-BR 文档将其概括为四步读 PROJECT.md/代码映射/约定 → 生成结构化假设 → 用户确认/纠正/扩充 → 写入 CONTEXT.md而实际工作流要更精细共分如下阶段1. 初始化与既有上下文加载initialize / check_existing / load_prior_context通过gsd-sdk query init.phase-op ${PHASE}校验阶段是否存在于 ROADMAPphase_foundfalse时直接退出并提示使用/gsd:progress查看可用阶段。若该阶段已存在 CONTEXT.md会先询问“更新 / 查看 / 跳过”若已有 plan 文件则提示“继续并在之后重规划 / 查看 plans / 取消”避免你的决策对既有计划失效却无人知晓。读取.planning/PROJECT.md愿景、原则、不可妥协项、.planning/REQUIREMENTS.md验收标准、约束、.planning/STATE.md进度与标志并遍历所有更早阶段的 CONTEXT.md抽取decisions与specifics把“用户一贯偏好最小化 UI”这类模式沉淀为内部prior_decisions——确保已决定的问题绝不重复提问。2. 代码库侦察与深度分析scout_codebase / deep_codebase_analysis这是assumptions与访谈模式最本质的分水岭先读代码再形成观点。先检查.planning/codebase/下是否已有代码库映射CONVENTIONS.md / STRUCTURE.md / STACK.md没有则用 grep 从阶段目标抽取关键词定向检索源码粗读 3–5 个最相关文件。然后派生子代理gsd-assumptions-analyzer见 agents/gsd-assumptions-analyzer.md做深度分析它读取该阶段 5–15 个相关源文件返回结构化假设。之所以用子代理是为了“把原始文件内容挡在主上下文窗口之外保护 token 预算”。若存在USER-PROFILE.md会先解析出校准档位calibration tierconservative/thorough-evaluator映射为full_maturity3–5 个领域、给更多备选与证据、opinionated映射为minimal_decisive2–3 个领域、给出果断的单一推荐、其余走standard3–4 个领域、每项 2 个备选。若假设中发现“代码库证据不足”的话题如库版本兼容性、生态最佳实践标记进needs_research由独立 research 代理配合 Context7/WebSearch 补证并回填置信度。3. 呈现假设每条都带证据、后果与置信度present_assumptions每条假设必须包含三要素这与 docs/workflow-discuss-mode.md 的说明一致Claude 会怎么做、为什么引用文件路径作为证据假设若错误会出什么问题具体后果而非泛泛警告置信度Confident代码证据明确/Likely合理推断/Unclear可能有多种走向。展示格式为按领域分组、带置信度徽章证据与后果分别以↳ Evidence:和↳ If wrong:缩进列出。--auto模式下若全部为 Confident/Likely 则直接跳过确认门进入写文件存在 Unclear 项则告警并自动以推荐默认值解析。4. 确认或纠正correct_assumptions这是控制交互数量的关键设计先以多选询问“哪些假设需要纠正”选项的 label 为假设陈述、description 即“If wrong”后果用户只对选中的项再回答一个聚焦问题备选通常为 2–3 个“可感知结果不同的具体方案”推荐项排最前。因此典型流程只需2–4 次交互而访谈模式往往要 15–20 次。5. 写 CONTEXT.md 与审计日志write_context / write_discussion_log假设逐条映射为decisions中带编号的锁定决策D-01、D-02……被纠正的假设以用户选择方案覆盖原假设。额外写出{padded_phase}-DISCUSSION-LOG.md审计日志记录“呈现的假设表、纠正记录、自动解析项、外部研究结果”并明确标注仅作审计追溯不得作为规划/研究/执行代理的输入。随后通过gsd-sdk query commit docs(${padded_phase}): capture phase context (assumptions mode) ...提交两个文件并用state.record-session更新.planning/STATE.md最后展示“决策摘要 下一步/gsd:plan-phase ${PHASE}”。6. 自动接力auto_advance若传入了--auto或链式自动模式生效则在写文件后直接显示 “AUTO-ADVANCING TO PLAN” 横幅并以gsd-plan-phase ${PHASE} --auto接力规划否则回到confirm_creation等待用户指示。五、Flag 兼容矩阵两种模式共享/gsd-discuss-phase的命令槽位见 commands/gsd/discuss-phase.md 的参数提示[--all] [--auto] [--chain] [--batch] [--analyze] [--text] [--power] [--assumptions]但各 Flag 的语义在两种模式下并不完全对等。对照 docs/workflow-discuss-mode.md 的官方矩阵Flagdiscuss模式assumptions模式--auto自动选择推荐答案跳过确认门自动解析 Unclear 项--batch将问题分组批量呈现不适用纠正本身已是批量式--text纯文本问题远程会话纯文本问题远程会话--analyze逐问题展示权衡表不适用假设本身已含证据--assumptions—触发清单式假设面谈见下节交互层还有一个重要实现细节每次AskUserQuestion之后都会做答案有效性校验——若返回为空或纯空白先用相同参数重试一次仍为空则以纯文本编号列表兜底呈现。启用--text或配置workflow.text_mode: true时则完全不调用AskUserQuestion一律以编号列表呈现详见 discuss-phase-assumptions.md 的answer_validation段。对于 VS Code Copilot 环境运行时说明 commands/gsd/discuss-phase.md 提示用vscode_askquestions等价替代AskUserQuestion。六、--assumptions标志与清单式假设面谈如果你只想“让 Claude 先亮出它对阶段的判断、讨论讨论再决定”而不需要产出正式文件可以给 discuss-phase 传--assumptions它会路由到 get-shit-done/workflows/list-phase-assumptions.md。与完整 assumptions 工作流不同它是纯对话式的分析输出不写任何文件跨越五个维度技术方案Technical Approach——会用什么库/框架/模式为什么实现顺序Implementation Order——先做什么、依赖关系是什么范围边界Scope Boundaries——包含什么、明确不包含什么、哪些模棱两可风险区Risk Areas——预判的复杂点与隐患依赖Dependencies——依赖前序阶段的产出、外部依赖、会被谁消费。呈现时同样要求诚实标注不确定性Fairly confident/Assuming/Unclear并以“What do you think?”邀请用户指出“对在哪里、错在哪里、漏了什么”。这份对话产出的纠正意见可在随后的/gsd:discuss-phase中被吸收进 CONTEXT.md。七、统一输出无论哪种模式CONTEXT.md 六段式不变两种模式最关键的兼容性承诺在于输出完全同构。无论用访谈还是假设收集最终 CONTEXT.md 都固定包含 6 个区段write_context步骤强制逐段校验相关断言见 tests/discuss-mode.test.cjsdomain—— 阶段边界来自 ROADMAP.md 的范围锚点decisions—— 已锁定的实现决策含被纠正假设的替代方案、Claude 裁量项、折叠进来的 todoscanonical_refs—— 下游代理必须先读的规格/文档清单要求补全为仓库全路径code_context—— 可复用资产、既有模式、集成点specifics—— 用户的具体引用与偏好deferred—— 暂缓/越界想法记录但不执行。正因为下游的gsd-phase-researcher、gsd-planner、checker 都只依赖这份统一格式两种模式之间切换不会给下游带来任何额外适配成本。模板本身位于 context.md 模板懒加载于write_context步骤内。八、最佳实践清单综合 pt-BR 版 与英文版说明建议遵循以下实践进入 plan-phase 前先审阅假设——CONTEXT.md 中的假设一经确认即成为锁定的D-xx决策直接影响下游研究范围尽早纠正命名/路径的歧义——假设引用的文件路径是证据链的关键一旦路径理解错误后续所有决策都会跑偏计划若偏离预期回到 discuss-phase 精修——CONTEXT.md 支持重复更新check_existing步骤提供“更新/查看/跳过”不要带着错误的上下文强行推进根据代码库成熟度选模式——新代码库、强主观意见、偏好对话者选standard约定成熟、追求吞吐者选assumptions利用校准档位控制篇幅——通过 USER-PROFILE 的 vendor philosophy 评分让假设呈现的领域数与备选数匹配你想要的决断力度防止越界蔓延——无论哪种模式讨论都只回答“范围内怎么做”新能力建议一律记入deferred供未来阶段处理工作流内置了固定的 scope guardrail 话术。九、如何验证当前配置与进一步阅读要确认当前项目实际处于哪种模式可运行gsd-sdk query config-get workflow.discuss_mode # 未配置时回退输出 discuss相关测试集中在 tests/discuss-mode.test.cjs它验证了命令文件确实路由到discuss-phase-assumptions.md、assumptions 工作流包含deep_codebase_analysis/present_assumptions/correct_assumptions等必要步骤、两种模式产出相同的 CONTEXT.md 区段并覆盖了--auto与--text的处理。想进一步深入可以继续阅读配置字段总览docs/CONFIGURATION.mdworkflow.discuss_modev1.28 引入配置参考字段表get-shit-done/references/planning-config.mdassumptions 完整工作流get-shit-done/workflows/discuss-phase-assumptions.md清单式假设面谈get-shit-done/workflows/list-phase-assumptions.md命令入口与模式路由commands/gsd/discuss-phase.mdassumptions 分析子代理agents/gsd-assumptions-analyzer.md。结论standard与assumptions不是先进与落后的区别而是“外显提问”与“代码取证定点纠正”两种上下文工程策略。默认配置始终是discuss项目只要一行workflow.discuss_mode assumptions即可切换到代码先行式收集理解了两者的路由机制、交互预算差异与统一的 CONTEXT.md 输出你就能在保证下游规划质量的前提下把讨论阶段的摩擦降到最低。【免费下载链接】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），仅供参考