get-shit-done 的 `--batch` 成组提问模式：把 Discuss Phase 的四轮单问压缩为一轮编号批量提问-北京尧图网络

get-shit-done 的--batch成组提问模式把 Discuss Phase 的四轮单问压缩为一轮编号批量提问【免费下载链接】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导读--batch是 get-shit-done 的/gsd:discuss-phase工作流提供的一种交互模式叠加层overlay它把默认模式下每个讨论区域连续发起 4 次单问题 AskUserQuestion 交互的流程压缩为一次纯文本消息内以编号形式提出 25 个问题的成组提问grouped question batch。本指南以 get-shit-done/workflows/discuss-phase/modes/batch.md 为骨架结合其父工作流与测试用例完整讲解--batch的参数解析规则、对讨论流程的具体影响、设计哲学、与--all/--chain/--text/--analyze的组合叠加方式以及它在渐进式披露progressive disclosure架构中的实现位置。读完你将能正确使用并组合--batch模式让领域澄清对话更高效、可回答性更强。定位discuss-phase 的一个懒加载模式叠加层在 get-shit-done 中/gsd:discuss-phase负责在规划之前提取下游 Agent研究 Agent、规划 Agent所需的实现决策其完整流程定义在 get-shit-done/workflows/discuss-phase.md 中。该父文件通过一张渐进式披露表格把不同模式的实现体mode bodies、模板templates和顾问流程全部设计为按需懒加载以便把父工作流保持在 500 行以内的预算约束下对应 issue #2551与 agent 预算 #2361 相互呼应。--batch正是这张路由表中的一个条目get-shit-done/workflows/discuss-phase.md触发条件加载内容--power在 $ARGUMENTS 中modes/power.md直接退出标准流程--all在 $ARGUMENTS 中modes/all.md叠加层--chain在 $ARGUMENTS 中modes/default.mdmodes/chain.md--text在 $ARGUMENTS 中或workflow.text_mode: truemodes/text.md叠加层--batch在 $ARGUMENTS 中modes/batch.md叠加层--analyze在 $ARGUMENTS 中modes/analyze.md叠加层无任何标志modes/default.md父工作流的initialize步骤明确规定当--batch出现在 $ARGUMENTS 中时应在进入discuss_areas步骤之前读取 modes/batch.md未设置相应标志时则不得读取模式文件。这种路由机制也由 tests/workflow-size-budget.test.cjs 中的测试强制验证测试会断言commands/gsd/discuss-phase.md中的每个--flag都有对应的模式文件且父文件必须引用discuss-phase/modes/batch.md详见该测试对[power, all, auto, chain, text, batch, analyze, default, advisor]模式文件列表的校验逻辑。命令入口 commands/gsd/discuss-phase.md 的argument-hint也正式声明了该标志的合法位置phase [--all] [--auto] [--chain] [--batch] [--analyze] [--text] [--power] [--assumptions]参数解析--batch的三种写法与取值钳制batch.md对参数解析给出了精确的规则实现上由工作流从$ARGUMENTS中解析接受--batch、--batchN或--batch N三种写法其中 N 为每批问题数量未提供数字时默认每批 4 个问题显式指定的批次大小会被钳制clamp到 25以保证一批问题始终处于可回答的规模太少则失去成组效率超过 5 则会增加单次回复负担、降低回答质量若$ARGUMENTS中完全没有--batch则保持原有的一次一问题one-question-at-a-time默认流程即加载 modes/default.md。这套解析语义意味着--batch是一个增量覆盖开关它不改变讨论的总体目标捕获下游 Agent 需要的决策只改变提问的节奏与呈现形式。钳制上限 5 的设计与默认值 4 相互呼应——默认模式每个区域恰好问 4 个单问题而 batch 模式用一批 25 个编号问题覆盖同样的信息量。对 discuss_areas 的影响一次成组轮次替代四轮单问在默认模式modes/default.md中discuss_areas对每个被选中的灰色地带gray area执行4 次单问题 AskUserQuestion 轮次然后询问是否继续的循环。--batch模式将其替换为每个区域以一次纯文本轮次提出 25 个编号问题不再依赖 TUI 菜单式的 AskUserQuestion 交互。batch.md对成组提问的落地给出 5 条操作准则按区域归组——把当前区域下紧密相关的问题合并进同一条消息而不是把每个问题拆成独立交互保持每题可回答——每个问题必须具体、能用一句话答复避免开放度过高导致用户需要长篇描述优先内联选项——当选项有帮助时在每个问题内直接给出简短的行内选项如(a) Session cookies而不是为每个条目单独发起一次 AskUserQuestion回读确认——用户回复后向用户复述已捕获的决策、指出未回答的条目并且只追问完成决策所需的最少后续问题然后继续批间自适应——批次与批次之间保持自适应性使用用户给出的完整答案集来决定下一批问题或判断当前区域是否已经足够清晰、可以结束。设计哲学保持自适应把节奏交给用户batch.md明确阐述了该模式背后的哲学——保持自适应但让用户选择节奏Stay adaptive, but let the user choose the pacing。两种模式在哲学层面是一一对应的维度默认模式--batch模式每个区域的提问形态4 次单问题轮次AskUserQuestion1 次成组轮次25 个编号问题纯文本区域结束后检查是否继续追问检查是否继续追问相同决策推进机制每个答案揭示下一个问题每个答案组揭示下一批问题或下一区域两套流程共享相同的自适应内核每套答案应当揭示下一个问题或下一批问题Each answer set should reveal the next question or next batch。区别仅在打包粒度默认模式以问一个、答一个的细粒度推进--batch以问一批、答一批的粗粒度推进。对于偏好快速走完澄清流程、或者已经对领域有清晰判断的用户batch 模式能显著减少交互往返次数。示例批次完整继承原文档的可运行模板batch.md提供了一个可直接复用的成组提问模板以用户认证区域为例这里完整保留其结构Authentication — please answer 1–4: 1. Which auth strategy? (a) Session cookies (b) JWT (c) OAuth 2.0 PKCE 2. Where do tokens live? (a) httpOnly cookie (b) localStorage (c) memory only 3. Session lifetime? (a) 1h (b) 24h (c) 30d (d) configurable 4. Account recovery? (a) email reset (b) magic link (c) both Reply with your choices (e.g. 1c, 2a, 3b, 4c) or describe in your own words.该模板蕴含三个可推广的写作要点任何区域都可以套用消息首行声明区域名与题目数量Authentication — please answer 1–4让用户对工作量有预期每道题同时给出问题、行内选项和缩写式答案格式用户既可以回答1c, 2a, 3b, 4c这样的紧凑选择串也可以用自己的话自由描述——后者对应默认模式中 AskUserQuestion 的 Other 自由输入分支回复指令明确Reply with your choices ... or describe in your own words降低理解成本。结合 modes/text.md 可以理解这种纯文本编号渲染的深层动机当 Claude Code 运行在远程会话/rc模式等无法把 TUI 菜单选择转发回宿主的场景时纯文本编号列表是唯一可靠的交互形式。--batch天生就是纯文本形态因此天然兼容这些受限环境。叠加与组合--analyze→--batch→--text的固定套娃顺序--batch不是独占模式它可以与默认模式、--all、--chain、--text、--analyze组合使用这是batch.md头部声明、父工作流discuss_areas步骤再次确认的能力。父工作流对叠加层的组合规则给出固定顺序Overlay stacking:overlays combine and apply outer→inner in fixed order--analyze→--batch→--text--batch --analyze为每个问题组question group先呈现一张权衡分析表再给出成组的编号问题——--analyze见 modes/analyze.md在每个问题之前提供 23 个选项的 pros/cons、推荐方案与已知陷阱与 batch 成组后形成一组权衡表一组编号问题的结构再加--text整条链路最终以纯文本形式渲染--text叠加层禁止使用 AskUserQuestion见 modes/text.md--batch --all--all让present_gray_areas阶段自动全选灰色地带跳过 AskUserQuestion 选择--batch则接管后续每个区域的提问形态--batch --chain讨论结束后自动推进到 plan-phase → execute-phase见 modes/chain.md 的auto_advance步骤即成组讨论全自动执行的流水线。需要注意的是叠加层只改变提问形态所有模式共享的通用规则依旧生效——包括规范引用累积用户回答中提到的文档/规范/ADR 立即加入 canonical refs 累加器、范围蔓延重定向新增能力记入 deferred ideas、每个区域完成后写入增量检查点checkpoint以及讨论日志累积供git_commit步骤生成 DISCUSSION-LOG.md。源码佐证懒加载、检查点与规模预算--batch模式的工程实现可以从三个角度在仓库中交叉印证1. 懒加载路由由父工作流强制。get-shit-done/workflows/discuss-phase.md 的模式分发步骤逐条列出各标志对应的模式文件读取时机--batch明确安排在discuss_areas之前。路由表的顺序即执行顺序未设置标志绝不预读模式文件这是把父文件压在 500 行预算内的关键手段。2. 模式文件的存在性由测试强制。tests/workflow-size-budget.test.cjs 中针对 issue #2551 的用例断言workflows/discuss-phase/modes/目录必须包含batch等 9 个模式文件且父工作流必须引用discuss-phase/modes/batch.md否则测试失败。这意味着--batch的对外契约命令文档中的 flag与对内实现模式文件由 CI 级测试锁死任何一侧漂移都会被拦截。3. 批间进度通过检查点持久化。无论何种模式discuss_areas的通用规则都要求每个区域完成后写${phase_dir}/${padded_phase}-DISCUSS-CHECKPOINT.json其结构定义在 get-shit-done/workflows/discuss-phase/templates/checkpoint.json记录areas_completed、areas_remaining、按区域分组的decisions问题、答案、呈现过的选项、deferred_ideas与canonical_refs。当会话在批间被中断时父工作流的check_existing步骤会检测到检查点并提供Resume / Start fresh选择从上次完成的区域继续——这正是批间自适应能够在多轮会话中长期保持的底层保障。CONTEXT.md 模板templates/context.md与讨论日志模板templates/discussion-log.md则在write_context与git_commit步骤中把成组讨论的成果落盘为下游 Agent 唯一信任的权威记录。使用建议何时使用--batch当区域内的待决策点彼此独立、可以一口气回答或你希望减少交互往返、快速完成澄清时当你处于无法弹出 TUI 菜单的远程会话时它更是与--text搭配的首选。何时退回默认模式当某个区域高度不确定、需要一问一答逐步收敛时默认的 4 次单问轮次能提供更强的引导性。保持问题可回答性严格执行每题具体、一行可答、内联选项的准则若某题需要用户长篇描述才能回答说明它应拆成后续的单独追问而不是塞进当前批次。尊重钳制区间显式--batchN会被钳制在 25这是为了让单条回复保持可消化如需超过 5 个问题请拆成多个批次并利用回读确认环节追问未回答条目。--batch的本质是在不牺牲每套答案揭示下一个问题的自适应内核的前提下把提问粒度从1 问 1 答调整为成组编号提问让讨论节奏真正由用户掌控——这正是 get-shit-done 将用户视为愿景者visionary、将 Agent 视为构建者builder这一分工哲学在交互层面的直接体现。【免费下载链接】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），仅供参考

get-shit-done 的 `--batch` 成组提问模式：把 Discuss Phase 的四轮单问压缩为一轮编号批量提问

相关推荐

Matlab实现PSO优化CNN的多输入单输出回归预测

SpringBoot+SSM双栈架构实战：美食平台高性能开发指南

Swin Transformer U-Net图像分割实战：从原理到源码跑通的完整指南

更多资讯

Appsmith 的 Cursor AI 协作开发规范：.cursor 目录设计、规则体系与工程实践

Tabby 用量收集（Usage Collection）机制详解：采集内容、上报原理与关闭方法

用C4模型重新理解架构图：四层抽象与实战规范

从数据模型到事件总线：一体化协同办公底层的设计逻辑

Odoo 19仓库库位完全指南：类型、编码与调拨避坑实践

交换机十大品牌与实战配置指南：选型、命令与排障全解析

今日更新

CopilotKit Vue Demo 与 React Demo 的 Parity 实现指南：路由、运行时端点与交互语义的全框架对齐

Harbor RBAC 实战：db_auth 模式下非管理员用户管理项目成员的完整验证与权限模型解析

STM32平衡车纯平衡程序从拆包到参数整定的完整调试指南

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？