GSD Core 默认切换到 end-of-phase 人工验证模式：`workflow.human_verify_mode` 的原理、配置与回退指南

【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载导读本文围绕 GSD CoreGit. Ship. Done — Core在 PR #3309 中引入的关键行为变更展开workflow.human_verify_mode的默认值从任务中途逐点暂停人工确认mid-flight切换为阶段末尾批量人工验收end-of-phase。你将理解为什么这个默认值变更能显著降低执行器executor冷启动带来的 Token 消耗掌握两种模式在 PLAN.md 中的 XML 任务结构差异、verifyhuman-check块的收割harvest链路以及如何通过gsd config-set在.planning/config.json中显式配置与回退到旧行为。变更背景为什么默认值从 mid-flight 改为 end-of-phase在 #3309 之前GSD Core 的规划器planner会在需要人工确认的位置向 PLAN.md 中发射独立的task typecheckpoint:human-verify任务。执行器每遇到这样一个检查点就必须暂停等待用户确认后再继续。问题在于每次暂停都会引发一次完整的执行器冷启动。因为子代理subagent的上下文会在暂停期间被丢弃恢复时需要重新读取 CLAUDE.md、MEMORY.md、STATE.md并重新读取 PLAN.md 才能恢复现场。在真实项目中实测每次往返round-trip的冷启动成本高达数万 Token一份包含 N 个人工验证检查点的计划需要支付 N1 次冷启动成本每一次暂停一次、最终结束又一次。这一成本是end-of-phase成为默认值的直接原因。从仓库源码可以印证这一变更被完整实现与测试config.cts 的CONFIG_DEFAULTS中将workflow.human_verify_mode默认值写为end-of-phase同文件 config.cts 定义了合法取值枚举[mid-flight, end-of-phase]非法值会被assertEnumValue拒绝tests/config.test.cjs 覆盖了默认值断言、两种模式之间的config-set往返切换、以及非法值midflight被拒绝报Invalid workflow.human_verify_mode midflight的用例。两种模式的行为对比维度end-of-phase默认#3309 起mid-flight旧行为opt-back-in规划器发射的检查点不再发射task typecheckpoint:human-verify在需要人工确认的位置发射独立检查点任务人工验证信息的载体嵌入相关auto任务的verifyhuman-check子块独立检查点任务的what-built/how-to-verify/resume-signal验证时机阶段phase结束时由验证器verifier统一批量收割、合并进{phase_num}-UAT.md流执行到每个检查点即暂停由用户逐点确认Token 成本无逐点暂停避免 N1 次执行器冷启动每个检查点一次冷启动往返实测每次数万 Token适用场景后续任务不依赖前一步的人工确认结果后续任务必须在前一步获得人工确认后才能继续硬性屏障checkpoint:decision/checkpoint:human-action不受影响仍正常发射不受影响仍正常发射核心区别可以概括为end-of-phase 是把事后验证已完成工作的人机交互推迟到阶段末尾统一处理而 mid-flight 是在流程中建立硬性暂停点。前者省成本后者提供硬屏障。end-of-phase 模式verifyhuman-check块的结构在end-of-phase模式下规划器把原本独立的验证检查点折叠进相关的auto任务通过verify块内的human-check子块携带人工验证信息。下面是 planner-human-verify-mode.md 中给出的完整结构示例task typeauto nameWire dashboard route/name filesapp/dashboard/page.tsx, app/api/dashboard/route.ts/files action.../action verify automatednpm test -- --filterdashboard/automated human-check testVisit http://localhost:3000/dashboard/test expectedSidebar left, content right on desktop gt;1024px; collapses to hamburger at 768px/expected why_humanVisual layout — grep cannot verify breakpoint behavior/why_human /human-check /verify doneLayout renders correctly across breakpoints/done /task关键字段说明test人工需要执行的具体验证动作访问哪个 URL、点击哪个流程expected预期的可观察结果尽量量化断点尺寸、行为变化why_human为什么必须由人来验证——例如grep 无法验证断点行为这类视觉/交互类判断automated可选同一任务中可由程序自动完成的验证命令与人工检查互补。验证器的阶段末尾收割链路这些被推迟的人工验证项不会丢失。验证器gsd-verifier在阶段末尾execute-phase 的验证步骤统一处理gsd-verifier.md 的 Step 8 Identify Human Verification Needs 会扫描阶段内每一份 PLAN 文件收割所有auto任务上的verifyhuman-check块将其合并进自己的human_verification列表并对描述相同检查的项去重收割得到的人工验证项随后进入 execute-phase.md 中human_needed状态的Step A生成{phase_dir}/{phase_num}-UAT.md如1-UAT.md以 UAT 模板格式逐条呈现测试项、预期行为与验收状态收割链路的唯一汇点是既有的human_needed→{phase_num}-UAT.md流程不会为这些项单独创建新文件。用户在阶段结束时一次性审阅全部人工验证项而不是为每一项支付一次冷启动成本。mid-flight 模式恢复逐点暂停的检查点结构如果你确实需要后续任务必须等前一项人工确认通过后再执行的硬性屏障可以通过配置恢复旧行为#3309 之前的行为gsd config-set workflow.human_verify_mode mid-flight恢复后规划器会在需要人工确认的位置重新发射独立的checkpoint:human-verify任务执行器在每个检查点暂停等待用户task typecheckpoint:human-verify gateblocking what-builtDev server running at http://localhost:3000/what-built how-to-verify 1. Visit /dashboard 2. Sidebar collapses at 768px /how-to-verify resume-signalapproved or describe issues/resume-signal /task字段说明what-built已完成并交付/启动的内容含 URL、端口等可直接访问的信息how-to-verify编号列出的精确验证步骤resume-signal用户如何指示继续如输入approved或描述问题gateblocking默认门控表示自动模式下可被自动放行见下文门控说明。选择mid-flight的合理场景是下一个任务确实依赖前一个任务的人工视觉确认且你接受冷启动成本作为硬性暂停的代价。不受影响的检查点checkpoint:decision与checkpoint:human-actionworkflow.human_verify_mode只影响checkpoint:human-verify的发射。以下两类检查点在两种模式下都会照常发射checkpoint:decision约 9%需要用户在技术选型、架构方向、功能优先级等影响实现方向的问题上做选择。它门控的是工作本身——执行器需要用户做出的决策checkpoint:human-action约 1%完全没有 CLI/API 可自动化、只能由人工执行的步骤典型如认证门auth gate执行器尝试自动化时遇到Not authenticated动态创建检查点请求用户完成登录/邮箱验证/2FA验证通过后重试原任务。这两类门控的是工作本身是否需要用户参与决策或执行而非对已完成工作的事后验证因此不受human_verify_mode取值影响。门控属性gateblocking与gateblocking-human无论处于哪种human_verify_mode检查点的gate属性都决定其在自动模式下的行为两者相互正交gate 值自动模式行为用途gateblocking按规则 5 被绕过human-verify自动批准decision仅在携带匹配的auto_select时自动选择否则升级给人默认值。事后验证与实现选择适合无人值守时走推荐路径gateblocking-human永不绕过即使在自动模式下也停下来等真人不可逆或需要建立信任的步骤安装前的包合法性验证、默认答案可能是错误假设的决策、执行器无法自行建立的precondition事实#3210详细规则见 checkpoints.md。其中金规则 5/6 强调gateblocking-human在任何模式含 auto 模式下都不会被自动批准执行器会拒绝自动放行并经由checkpoint_return_format升级给人。执行器侧例外tracer 反馈门#3299human_verify_mode不只是规划器的关注点。执行器在typetracer任务之后、任何扩展expansion任务之前会运行一个由执行器在运行时合成的早期集成检查点——tracer 反馈门。这个检查点不是规划器发射的因此规划器侧的抑制机制触及不到它门本身必须读取human_verify_mode自行判断。该门在 execute-plan.md 的execute步骤中按优先级链求值完整表格见 checkpoints.md 的 Tracer feedback gate (#3299)#运行场景tracerverify行为1任何模式含自动携带gateblocking-humanSTOP→ 生成checkpoint:human-verify永不自动继续2自动模式生效任意第 1 行已处理 blocking-human重跑验证失败 HALT成功继续#3299 之前既有行为3交互式 end-of-phase默认仅automated重跑验证失败 HALT成功继续扩展——无检查点4交互式 end-of-phase携带human-checkSTOP → 生成checkpoint:human-verify5交互式 mid-flight任意STOP → 生成checkpoint:human-verify需要特别注意 #3299 自动继续第 3 行的三个前提必须同时成立交互式运行、模式为end-of-phase、tracer 的verify只含automated。任何一项不满足都会 STOP 或落入既有自动模式分支失败 HALT 在第 2、3 行都是无条件的——失败的 tracer 永远不会变成可批准的检查点也永远不会进入扩展因为在损坏的切片上叠加扩展正是这个门要防止的失败。为什么携带human-check的 tracer 仍然停下而不是推迟到阶段末尾的 UAT 批量参考文档明确给出了三个理由其一决定性end-of-phase 收割不覆盖 tracer——验证器只从auto任务收集verifyhuman-check块若把 tracer 的人工证据推迟而不先拓宽收割接缝证据会直接丢失比停下更糟其二tracer 门的存在就是为了防止扩展叠加到未经证明的切片上推迟人工证据会让每个扩展任务都建立在一个无人确认的切片之上其三被报告的缺陷限定在没有人工可观察证据的 tracer超出该范围时 fail-closed停下才是安全方向。配置实操读取、写入与兼容性默认值如何生效workflow.human_verify_mode end-of-phase是新项目的默认值但注意一个重要细节该键不在SCHEMA_DEFAULTS中。因此对于配置早于 #3309 的项目裸执行gsd_run query config-get workflow.human_verify_mode会以非零退出并报Key not found不会解析到文档声称的end-of-phase默认值。所有消费方必须显式传默认值HUMAN_VERIFY_MODE$(gsd_run query config-get workflow.human_verify_mode --default end-of-phase --raw 2/dev/null || echo end-of-phase)这正是 execute-plan.md 中parse_segments步骤的写法。写入与切换新默认值在.planning/config.json被重写时生效例如通过gsd config-set或在新的 GSD 版本上首次运行。显式写入gsd config-set workflow.human_verify_mode end-of-phase # 显式确认新默认 gsd config-set workflow.human_verify_mode mid-flight # 回退到 #3309 之前的逐点暂停行为非法值会被拒绝例如midflight会报Invalid workflow.human_verify_mode midflight见 tests/config.test.cjs。对既有项目与在途计划的影响在途的旧 PLAN.md已包含checkpoint:human-verify任务的计划在两种模式下都能继续正常工作。该标志只改变规划器下一次运行时的发射行为不会改写已生成的计划文件配置缺失的项目config.json早于 #3309 的项目在键被写入或配置被重写前不会获得新默认值读取方需显式传入--default end-of-phase见上文。与其他模式的兼容性模式兼容性说明workflow.tdd_mode正交。TDD 任务仍发射tddtrue和behavior当human_verify_mode end-of-phase时verify块携带human-check子元素MVP_MODE正交。垂直切片顺序不变首个任务仍是失败的端到端测试后续auto任务可携带verifyhuman-check而非独立的检查点任务workflow.auto_advance/_auto_chain_activemid-flight 模式下会自动批准checkpoint:human-verify暂停end-of-phase 模式下没有规划器发射的暂停可自动批准因此这两个标志对规划器输出无效。但在执行期并非惰性执行器侧 tracer 反馈门会合成自己的检查点且那里的自动模式分支优先于human_verify_mode——除了gateblocking-human它最先求值并在所有模式下 STOP#3299结语如何选择模式默认选择end-of-phase绝大多数项目都应保持默认。人工验证项被折叠进auto任务的verifyhuman-check块由验证器在阶段末尾一次性收割进{phase_num}-UAT.md用户批量审阅执行器不会为每次人工确认支付 N1 次冷启动的 Token 成本实测每次往返数万 Token。仅在有硬依赖时选择mid-flight当后续任务必须以之前任务的人工确认结果为前提、且你接受冷启动成本作为硬性屏障的代价时执行gsd config-set workflow.human_verify_mode mid-flight恢复逐点暂停。记住两个例外checkpoint:decision与checkpoint:human-action不受模式影响执行器合成的 tracer 反馈门自行读取模式携带human-check的 tracer 在任何交互模式下都会停下。如需深入可继续阅读仓库内的权威参考planner-human-verify-mode.md、checkpoints.md、功能说明 end-of-phase-human-verification-mode.md以及执行链路 execute-plan.md 与 execute-phase.md。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐esp-idf NVS 分区解析工具 nvs_partition_tool读取、调试与完整性检查 NVS 存储分区的实战指南esp idf NVS 分区解析工具 nvs_partition_tool读取、调试与完整性检查 NVS 存储分区的实战指南 本文围绕 ESP IDF 的 Nget-shit-done 人类验证模式human_verify_mode深度指南end-of-phase 与 mid-flight 的取舍get shit done 人类验证模式human_verify_mode深度指南end of phase 与 mid flight 的取舍 本文围绕 g人工智能AI 应用提示工程开发工具工作流自动化AI Agentget-shit-done 规划器人机验证模式深度解析end-of-phase 与 mid-flight 的成本权衡、切换与源码佐证get shit done 规划器人机验证模式深度解析end of phase 与 mid flight 的成本权衡、切换与源码佐证 导读 get shit人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇Swift泛型函数文档生成终极指南VVDocumenter-Xcode的类型参数注释技巧下一篇3个维度解析ET框架如何用C构建高性能游戏服务器的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考