人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载导读本篇围绕 GSD-2 内置技能 verify-before-complete 展开讲解它在长时间自主 Agent 工作流中扮演的完成声明闸门角色代码编译通过不等于工作完成验证证据齐全才算完成。读完本文你将掌握如何在任务、切片slice、里程碑的任意完成节点上执行先验证、后宣称的严格流程并能从源码层面理解 GSD-2 如何在gsd_slice_complete、证据交叉核对、过期回合检测等机制上把这一契约变成系统级强制力。为什么需要一道完成声明闸门GSD-2 是一个支持 Agent 长时间自主运行的 meta-prompting 与 spec-driven development 系统。在这样的系统中系统提示词system prompt负责设定预期complete-slice.md与auto-verification.ts在切片边界上强制执行验证但在切片边界之间——任务进行中、调试中、评审中——Agent 很容易滑入我觉得它应该能工作的模式然后把坏代码交付出去。verify-before-complete这个技能就是用来在任何完成节点打破这种模式的行为仪式。其核心目标objective是对 GSD work is not done when code compiles; work is done when verification passes 契约的落地执行没有在当前消息中生成验证输出就宣称完成是一次破碎的宣称。触发时机技能的 context 段落 明确了它在哪些节点必须被唤醒即将通过gsd_*工具把复选框从[ ]勾选为[x]时即将 commit、push 或打开 PR 时即将把某个任务或切片总结为已完成时即将说 tests pass、build works、lint clean、fixed、done 时回复用户是的它能工作之类的确认时。这些触发点并非只停留在文档层面。在 system-context.ts 中技能注册为一条系统级触发规则Block completion claims until verification evidence has been produced in this message并由 skill-manifest.ts 将其挂载到校验 / 完成类流程的 allowlist 中配合 bundled-skill-triggers.test.ts 做回归保障。核心原则EVIDENCE BEFORE CLAIMS, ALWAYS技能给出了一条不可退让的铁律EVIDENCE BEFORE CLAIMS, ALWAYS.我前面跑过了不算证据。三次工具调用之前的日志在代码已经发生变化之后也不再是证据。验证必须发生在最后一次代码改动之后、当前这条消息之内并且产出新鲜的输出。VIOLATING THE LETTER IS VIOLATING THE SPIRIT.如果这条原则让你感到不便那恰恰说明它是承重墙。去找验证命令去运行它去读它的输出。从源码实现看这条原则不是空话GSD-2 的验证证据记录evidence record在 verification-evidence.ts 中被结构化为带schemaVersion: 1的机器可读 JSON每条 check 包含command、exitCode、durationMs、verdict: pass | fail并且刻意把 stdout/stderr 排除在 JSON 之外以避免文件无限膨胀——证据的价值在于可判定的通过/失败结论而不在于把整段输出塞进存储。五步执行流程技能把一次诚实的完成声明拆解为五个可检查、可复盘的步骤Step 1识别宣称Identify the claim先把你要宣称什么精确命名出来而不是给一个模糊的 it worksTests pass → 具体是哪一组测试Build works → 针对哪个构建目标Bug is fixed → 对应哪个复现步骤Task complete → 对应哪条验收标准宣称越模糊验证就越无从谈起。Step 2匹配验证命令Identify the verification command将宣称与验证命令一一对应。技能的对照表完整如下宣称验证方式Tests pass项目实际使用的测试命令npm test、cargo test、pytest等——套件很大时收窄到改动的代码范围Build works项目真实的构建命令——如果项目需要打包tsc --noEmit不算数Lint clean对改动文件运行lsp diagnostics外加 CI 会跑的 linterBug fixed从 bug 报告或测试中拿到的复现步骤新鲜地跑一遍UI works在运行中的应用里通过browser_snapshot_refsbrowser_assert做浏览器验证——diff 里看起来对不算Slice completeS##-PLAN.md里的每一条验收标准都对照真实行为重新核对如果根本不存在对应的验证命令说明这个任务没有产生可证伪的宣称它不算完成——此时应该先写验证参见仓库中的tdd、test技能。这一按宣称选择验证表面的思路在源码中有完整对应complete-slice提示词要求切片级验证必须走 closeout-safe 的验证表面gsd_exec/ Context Mode verification evidence明确禁止直接用bash跑验证命令见 complete-slice.md。Step 3现在就跑Run it now一次性命令用async_bash长时间运行的服务器/监听器用bg_shell。等它退出读输出——是逐字读不是扫一眼。输出表示失败你还不拥有完成声明。回到循环里——检查错误、修复、重跑直到通过或者出现真正需要用户介入的阻塞。不允许部分宣称测试基本通过——要么通过要么如实报告失败。输出表示成功在你的回复里引用相关的那一行。42 tests passing 或 Exit code 0 或 LSP reports 0 errors on the 3 edited files.Step 4检查过期性Check for staleness如果你在这条消息的早些时候跑了验证之后又改了代码那么那份输出已经过期必须重跑。同时取消在编辑之前发起的 in-flightasync_bash任务对应系统提示词里的 stale job hygiene 规则。过期即失效在系统层面有专门机制支撑auto/turn-epoch.ts 用 AsyncLocalStorage 维护回合代数turn generation。每当回合被判定结束超时恢复、显式取消bumpTurnGeneration递增代数写点通过isStaleWrite检查——若捕获的代数早于当前代数说明回合已被取代写入被丢弃。这从机制上杜绝了旧回合的过期验证/过期写入污染新回合的问题。Step 5现在才能宣称Now claim只有在拿到新鲜输出之后你才可以通过gsd_*把任务/切片/里程碑标记为完成commit / push / 打开 PR说出 done、fixed、passes、works。并且要把证据一并写进宣称Slice complete —npm testpassed (84/84),npm run buildexit 0, acceptance criterion 3 verified against live UI at /dashboard.反模式清单哪些话术不是验证技能明确列出了必须杜绝的行为每一条都直指自主 Agent 最常见的虚假完成来源It should work应该能用—— 这不是验证去跑命令Tests passed earlier之前测过—— 已过期现在重跑The code looks right代码看着对—— code review 不是验证tsc --noEmit当作构建检查当项目需要打包时—— 要测用户真正体验到的东西静默失败测试被超时杀掉了所以我就当它没问题—— 不行部分通过80/84 不等于 tests pass—— 报告那 4 个失败因为我知道它为什么能工作就跳过—— 你的心智模型不是证据。成功标准一次合格的完成声明技能的自检清单如下全部满足才意味着这次完成声明是诚实的宣称是精确的——不是 it works而是 npm testpassed with 84/84 tests.验证命令在最后一次代码改动之后、当前这条消息内运行输出被逐字读过了不是扫一眼失败本可以被发现——验证内容确实测到了宣称所断言的东西相关证据被引用在了宣称回复里。源码纵深契约如何变成系统强制力verify-before-complete是行为层面的仪式而 GSD-2 在工程层面给了它三重落地保障。第一重切片完成工具的内容闸门gsd_slice_complete的实现 tools/complete-slice.ts 内置了一道验证内容闸门verification content gateissue #3580当提交的verification或uatContent中匹配到status: blocked、verification_result: failed、slice is blocked、cannot complete、verification failed等阻塞信号时直接拒绝完成并返回错误slice verification indicates blocked/failed state — do not complete a slice that has not passed verification.这防止了提示词回归导致被阻塞的切片被静默推进。对应的行为级回归测试 complete-slice-verification-gate.test.ts 用真实 handler 驱动六种场景verification failed、verification_result: failed、status: blocked、slice is blocked、cannot complete都会被拒绝同时用干净输入不应误伤的用例守住闸门不过度敏感。第二重宣称证据与实际调用的交叉核对即使 Agent 在摘要里写下了命令和退出码系统仍会比对声称与事实。safety/evidence-cross-ref.ts 把 Agent 声称的验证证据commandexitCode与证据收集器记录的真实 bash 调用做交叉引用按精确匹配 → 子串匹配 → token 相似度三级查找真实调用若声称exitCode0但真实调用实际失败会产生severity: error的不一致条目找不到任何匹配调用则产生 warning。同时只有最新一批同一createdAt时间戳的宣称参与判定避免重试留下的旧批次干扰。配套测试见 evidence-cross-ref.test.ts。第三重自动验证门与证据落盘在 auto 模式下auto-verification.ts 会在任务收尾时跑 typecheck/lint/test 检查、捕获运行时错误、做依赖审计并把结果写为验证证据 JSON含 pre/post-execution checks。这些证据随后以结构化verificationEvidence数组进入gsd_task_complete/gsd_slice_complete的契约参数其 JSON 持久化与 Markdown 表格格式化由 verification-evidence.ts 统一处理。把这一契约用到你的日常流程即便你不运行完整的 GSD 流水线verify-before-complete提出的纪律也完全可移植宣称必须可证伪任何 done/fixed/works 都对应一条可运行的命令或可复现的步骤写不出验证命令的宣称不成立。证据必须新鲜验证时间必须在最后一次改动之后——之前跑过这个词在完成声明里没有位置。证据必须被引用宣称里带上具体数字与退出码84/84 passed, exit 0而不是情绪化的没问题。失败要如实报告部分通过就是失败阻塞就诚实说阻塞——系统甚至会替你拒绝那些写着 blocked 却想蒙混过关的完成请求。这条规则的价值密度与 Agent 的运行时长成正比跑得越久、改动越多新鲜验证与过期输出之间的界限就越关键而这正是verify-before-complete在 GSD-2 中长期自主运行架构中扮演的角色——一道让每个完成声明都有据可查的闸门。赞分享人工智能AI Agent代码智能体Agent 编排CLIAI 应用【免费下载链接】gsd-2A powerful meta-prompting, context engineering and spec-driven development system that enables agents to work for long periods of time autonomously without losing track of the big picture项目地址https://gitcode.com/gh_mirrors/gs/gsd-2点击查看免费下载相关推荐OpenRig 完成前验证技能Verification Before Completion实战解析先取证再宣称OpenRig 完成前验证技能Verification Before Completion实战解析先取证再宣称 本文以 OpenRig 仓库内置的 Ag人工智能AI Agent多智能体Agent 编排代码智能体CLISuperpowers verification-before-completion为 Agent 工作流装上先验证、后声明的完成门禁Superpowers verification before completion为 Agent 工作流装上先验证、后声明的完成门禁 SuperpoweAI 技能AI 插件开发工具gsd-2 需求契约指南用 REQUIREMENTS.md 模板维护可验证的能力契约与覆盖度追踪gsd 2 需求契约指南用 REQUIREMENTS.md 模板维护可验证的能力契约与覆盖度追踪 本篇以 REQUIREMENTS.md 模板 https:/人工智能AI Agent代码智能体Agent 编排CLIAI 应用上一篇深入解析高效Prompt Engineering指南专业开发者的最佳实践下一篇【亲测免费】 开源项目 luci-app-aliddns 使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
