人工智能AI 应用提示工程开发工具工作流自动化AI Agent【免费下载链接】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-integration-phase是 get-shit-doneGSD系统中生成 AI 设计契约AI-SPEC.md的关键工作流。它曾经存在一个隐蔽的并发缺陷当gsd-ai-researcher与gsd-domain-researcher被并行派发时后者的Write调用会以整文件覆盖的方式静默抹掉前者写入的 Section 3/4实测发生率高达 40%5 个 agent 中有 2 个中招。本文基于变更记录 .changeset/fix-3096-ai-integration-parallel-race.md结合工作流定义、Agent 提示词与回归测试源码完整拆解这一竞态的根因、修复策略显式顺序执行约束 Edit-only 工具纪律以及防止复发的测试保障并提炼出可复用到任何多 Agent 协作场景的共享文件写入工程原则。一、背景ai-integration-phase与 AI-SPEC.mdai-integration-phase是 GSD 生命周期中介于 discuss-phase 与 plan-phase 之间的设计契约阶段。其命令入口定义在 commands/gsd/ai-integration-phase.md由工作流 get-shit-done/workflows/ai-integration-phase.md 具体编排按顺序完成四步流水线Select Framework → Research Docs → Research Domain → Design Eval Strategy → Done即依次派发四个 Agentgsd-framework-selector—— 选定 AI 框架含备选方案与理由gsd-ai-researcher—— 研读框架官方文档产出 AI-SPEC.md 的 Section 3Framework Quick Reference、Section 4Implementation Guidance与 Section 4bAI Systems Best Practicesgsd-domain-researcher—— 研究业务领域与专家评估标准产出 Section 1bDomain Contextgsd-eval-planner—— 基于领域上下文设计评估策略产出 Section 5/6/7Evaluation Strategy、Guardrails、Production Monitoring。最终产物 AI-SPEC.md 由模板 get-shit-done/templates/AI-SPEC.md 生成在规划开始前锁定四类关键决策框架选择、实现指引、领域上下文与评估策略。工作流末尾的校验步骤Step 10会逐项检查 Section 2 框架名、Section 1b 的领域评估要素、Section 3 的代码块、Section 4b 的 Pydantic 示例、Section 5 的评估维度表等是否非空防止生成空壳契约。二、Bug #3096并行派发导致的 AI-SPEC.md 整体覆盖2.1 根因两个看似不相交的 Agent 共享同一个文件在修复之前工作流的 Step 7 与 Step 8 只按顺序罗列了派发动作并未显式声明二者的执行约束。而gsd-ai-researcher与gsd-domain-researcher写入的是 AI-SPEC.md 中互不重叠的章节前者写 Section 3/4/4b后者写 Section 1b。这种章节不相交的表象让编排者产生了一个完全合理的优化冲动并行派发这两个 Agent 以缩短整体耗时。这正是竞态的温床依据如下gsd-ai-researcher的职责定义见 agents/gsd-ai-researcher.md要求使用Write工具创建/更新文件并明确ALWAYS use the Write tool to create filesgsd-domain-researcher见 agents/gsd-domain-researcher.md同样声明使用Write工具完成 Section 1b 的写入。2.2 事故现场最后写入者赢last-writer-winsWrite工具的语义是整文件替换而非增量更新。并行场景下的事件序列如下编排者同时派发两个 Agent二者各自读取 AI-SPEC.md 模板在各自的内存中持有文件的初始副本gsd-ai-researcher完成研究用Write提交了包含 Section 3/4/4b 内容的完整新文件gsd-domain-researcher随后完成领域研究在 finalization 时用Write提交它内存中那份尚未包含 Section 3/4的旧副本——这一步把整个 AI-SPEC.md 静默替换回了 researcher 写入前的状态Section 3/4 就此丢失。变更记录给出的实测数据是发生率约 40%一次真实运行中 5 个 worktree agent 有 2 个触发该竞态。其危险之处在于失败是静默的——文件依然存在、结构依然完整、没有报错只有事后校验时才能发现 Section 3/4 缺失。修复前的恢复代价同样高昂需要重新派发一次gsd-ai-researcher大约 18 分钟的真实墙钟时间。三、修复方案两层防线双管齐下变更记录与工作流源码共同确认了修复的两条核心措施落地于 get-shit-done/workflows/ai-integration-phase.md3.1 第一道防线显式的顺序执行约束在 Step 7 顶部新增了专门的排序说明块Ordering noteOrdering note (prevents tool-level last-writer-wins race):Steps 7 and 8 write disjoint sections of AI-SPEC.md but MUST run sequentially — wait for Step 7 to complete before spawning Step 8.Step 8 同样携带独立提示Wait for Step 7 to complete before spawning this step(see ordering note in Step 7).关键措辞是MUST run sequentially与wait for Step 7 to complete before spawning Step 8。这不是一句模糊的建议按顺序而是把执行约束写进契约本身任何读取该工作流的编排者无论是 Claude Code、Codex 还是其他运行时的 orchestrator都会看到明确的指令——第 8 步必须在第 7 步完成之后才能启动。同时说明块直接点破了设计动机两个步骤虽然写不同章节但共享同一个文件Write的整文件替换语义会让并行派发产生 last-writer-wins 覆盖。3.2 第二道防线Edit-only 工具纪律注入仅靠顺序约束并不够——即使顺序执行若两个 Agent 各自仍持有过期的内存副本并在收尾时用Write提交依然可能覆盖对方成果。因此修复同时向两个 Agent 的派发提示中都注入了强制工具纪律Tool discipline (mandatory):Use the Edit tool exclusively when modifying AI-SPEC.md — NEVER use Write on this file. Write replaces the entire file and will overwrite work from parallel or sequential sibling agents. Before editing, verify the section you are about to write is still a template placeholder.这段注入包含三个层次工具切换把默认的Write改为Edit——Edit只针对目标行做增量修改不触碰文件其余部分原理说明明确告知 AgentWrite会替换整个文件并覆盖兄弟 Agent 的成果无论并行还是顺序消除为什么不能用 Write的歧义前置校验要求 Agent 在编辑前先确认目标章节仍是模板占位符!-- ... --注释块从源头避免对已写入内容的二次覆盖。对应地两个 Agent 的独立定义文件也保留了文档查找、质量标准与成功标准等完整规范见 agents/gsd-ai-researcher.md 与 agents/gsd-domain-researcher.md修复并未削弱各自的研究深度要求只是修正了如何落盘的方式。四、回归测试把竞态防御固化为可执行断言修复不是一次性的仓库用专门的回归测试 tests/bug-3096-ai-integration-phase-parallel-race.test.cjs 把防御固化成了可重复验证的契约。该测试直接读取get-shit-done/workflows/ai-integration-phase.md的文本内容用四个断言守护修复成果Step 7 必须包含顺序执行声明校验工作流文本中出现sequentially或sequential字样缺失即视为竞态可复发Step 7 的 agent 提示必须包含 Edit-only 纪律截取 Step 7 到 Step 8 之间的文本块断言其中同时出现Edit tool与NEVER use WriteStep 8 的 agent 提示同样包含 Edit-only 纪律截取 Step 8 到 Step 9 之间的文本块做同样的断言Step 8 必须引用等待指令断言 Step 8 文本块中出现Wait/wait/complete字样。从测试源码可以推断其防御逻辑因为ai-integration-phase.md的文本本身就是运行时所加载的部署契约测试注释明确标注 reading product workflow markdown to verify structural ordering contract对文本做结构断言就是对运行时行为做验证。任何人后续编辑工作流时若误删排序说明或工具纪律测试会立刻失败。配套的 tests/ai-evals.test.cjs 则从配置侧守护整个 AI 集成阶段验证workflow.ai_integration_phase配置项默认值为true、支持config-set/config-get读写以及健康检查在缺失该配置时发出 W016 警告、并在--repair模式下通过addAiIntegrationPhaseKey自动补齐。五、通用工程启示多 Agent 共享文件的三条铁律从这次 40% 发生率的真实事故中可以提炼出适用于任何多 Agent或多进程协作写入共享文件的工程原则这也是本修复超越单一仓库的通用价值Write是破坏性操作共享文件必须禁用任何会并发或接力写入的共享文件都应约定Edit/patch式增量修改并把这一约定以强制措辞注入每个参与者的提示词章节不相交不等于可以并行只要共享同一物理文件整文件替换语义就足以让任何顺序优化变成数据丢失事故——必须显式声明MUST run sequentially而非依赖读者的合理推断用测试锁死契约文本当文档文本即运行时行为时对文档做结构断言包含顺序关键字、包含工具纪律、包含等待指令是最直接有效的防回归手段成本极低且可自动执行。GSD 团队在 .changeset/fix-3096-ai-integration-parallel-race.md 中将这次修复定性为Fixed关闭 issue #3096并选择将实测发生率、恢复代价写入变更记录——这些数据让后来的维护者能理解为什么这里要写得这么严格而不是把约束当成过度设计。六、如何在你的项目里复现与验证如果你希望在自己的 GSD 项目中观察这套防御机制是否生效可以按以下步骤操作仓库为只读以下均为查看与运行验证方式阅读工作流契约打开 get-shit-done/workflows/ai-integration-phase.md定位## 7. Spawn gsd-ai-researcher与## 8. Spawn gsd-domain-researcher两个小节确认排序说明块与 Edit-only 纪律文本均在位核对 Agent 提示词对照 agents/gsd-ai-researcher.md 与 agents/gsd-domain-researcher.md 中关于文件写入的约束表述运行回归测试执行测试 tests/bug-3096-ai-integration-phase-parallel-race.test.cjs四个断言全部通过即说明顺序约束与工具纪律未被破坏验证配置开关通过gsd-sdk query config-get workflow.ai_integration_phase确认 AI 集成阶段启用默认true或运行validate health观察 W016 警告的触发与--repair自愈行为。这套顺序执行 Edit-only 回归测试的组合拳让 AI-SPEC.md 的生成从一次 40% 概率的静默数据丢失变成有契约、有纪律、有验证的可靠流水线。赞分享人工智能AI 应用提示工程开发工具工作流自动化AI Agent【免费下载链接】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点击查看免费下载相关推荐gsd-core 多 Agent 并行写共享文件的竞态修复AI-SPEC.md 的 last-writer-wins 问题、Edit-only 纪律与回归保障gsd core 多 Agent 并行写共享文件的竞态修复AI SPEC.md 的 last writer wins 问题、Edit only 纪律与回归保障get-shit-done 状态机修复实战让 state complete-phase 幂等化彻底杜绝 STATE.md 被重复执行回滚get shit done 状态机修复实战让 state complete phase 幂等化彻底杜绝 STATE.md 被重复执行回滚 本篇技术指南围绕人工智能AI 应用提示工程开发工具工作流自动化AI Agentget-shit-done 修复 3599 深度解析roadmap get-phase 如何正确命中 project-code 前缀阶段 IDget shit done 修复 3599 深度解析roadmap get phase 如何正确命中 project code 前缀阶段 ID 本文基于仓库中人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇3分钟把NCM转成MP3ncmdump拖拽上手指南下一篇QKeyMapper按键映射教程键鼠手柄跨设备互换指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 11:57:51 · 阅读 1.2k get-shit-done 竞态修复实录：`ai-integration-phase` 如何用「顺序执行 + Edit-only」消除 AI-SPEC.md 的 last-writer-wins 覆盖
人工智能AI 应用提示工程开发工具工作流自动化AI Agent【免费下载链接】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-integration-phase是 get-shit-doneGSD系统中生成 AI 设计契约AI-SPEC.md的关键工作流。它曾经存在一个隐蔽的并发缺陷当gsd-ai-researcher与gsd-domain-researcher被并行派发时后者的Write调用会以整文件覆盖的方式静默抹掉前者写入的 Section 3/4实测发生率高达 40%5 个 agent 中有 2 个中招。本文基于变更记录 .changeset/fix-3096-ai-integration-parallel-race.md结合工作流定义、Agent 提示词与回归测试源码完整拆解这一竞态的根因、修复策略显式顺序执行约束 Edit-only 工具纪律以及防止复发的测试保障并提炼出可复用到任何多 Agent 协作场景的共享文件写入工程原则。一、背景ai-integration-phase与 AI-SPEC.mdai-integration-phase是 GSD 生命周期中介于 discuss-phase 与 plan-phase 之间的设计契约阶段。其命令入口定义在 commands/gsd/ai-integration-phase.md由工作流 get-shit-done/workflows/ai-integration-phase.md 具体编排按顺序完成四步流水线Select Framework → Research Docs → Research Domain → Design Eval Strategy → Done即依次派发四个 Agentgsd-framework-selector—— 选定 AI 框架含备选方案与理由gsd-ai-researcher—— 研读框架官方文档产出 AI-SPEC.md 的 Section 3Framework Quick Reference、Section 4Implementation Guidance与 Section 4bAI Systems Best Practicesgsd-domain-researcher—— 研究业务领域与专家评估标准产出 Section 1bDomain Contextgsd-eval-planner—— 基于领域上下文设计评估策略产出 Section 5/6/7Evaluation Strategy、Guardrails、Production Monitoring。最终产物 AI-SPEC.md 由模板 get-shit-done/templates/AI-SPEC.md 生成在规划开始前锁定四类关键决策框架选择、实现指引、领域上下文与评估策略。工作流末尾的校验步骤Step 10会逐项检查 Section 2 框架名、Section 1b 的领域评估要素、Section 3 的代码块、Section 4b 的 Pydantic 示例、Section 5 的评估维度表等是否非空防止生成空壳契约。二、Bug #3096并行派发导致的 AI-SPEC.md 整体覆盖2.1 根因两个看似不相交的 Agent 共享同一个文件在修复之前工作流的 Step 7 与 Step 8 只按顺序罗列了派发动作并未显式声明二者的执行约束。而gsd-ai-researcher与gsd-domain-researcher写入的是 AI-SPEC.md 中互不重叠的章节前者写 Section 3/4/4b后者写 Section 1b。这种章节不相交的表象让编排者产生了一个完全合理的优化冲动并行派发这两个 Agent 以缩短整体耗时。这正是竞态的温床依据如下gsd-ai-researcher的职责定义见 agents/gsd-ai-researcher.md要求使用Write工具创建/更新文件并明确ALWAYS use the Write tool to create filesgsd-domain-researcher见 agents/gsd-domain-researcher.md同样声明使用Write工具完成 Section 1b 的写入。2.2 事故现场最后写入者赢last-writer-winsWrite工具的语义是整文件替换而非增量更新。并行场景下的事件序列如下编排者同时派发两个 Agent二者各自读取 AI-SPEC.md 模板在各自的内存中持有文件的初始副本gsd-ai-researcher完成研究用Write提交了包含 Section 3/4/4b 内容的完整新文件gsd-domain-researcher随后完成领域研究在 finalization 时用Write提交它内存中那份尚未包含 Section 3/4的旧副本——这一步把整个 AI-SPEC.md 静默替换回了 researcher 写入前的状态Section 3/4 就此丢失。变更记录给出的实测数据是发生率约 40%一次真实运行中 5 个 worktree agent 有 2 个触发该竞态。其危险之处在于失败是静默的——文件依然存在、结构依然完整、没有报错只有事后校验时才能发现 Section 3/4 缺失。修复前的恢复代价同样高昂需要重新派发一次gsd-ai-researcher大约 18 分钟的真实墙钟时间。三、修复方案两层防线双管齐下变更记录与工作流源码共同确认了修复的两条核心措施落地于 get-shit-done/workflows/ai-integration-phase.md3.1 第一道防线显式的顺序执行约束在 Step 7 顶部新增了专门的排序说明块Ordering noteOrdering note (prevents tool-level last-writer-wins race):Steps 7 and 8 write disjoint sections of AI-SPEC.md but MUST run sequentially — wait for Step 7 to complete before spawning Step 8.Step 8 同样携带独立提示Wait for Step 7 to complete before spawning this step(see ordering note in Step 7).关键措辞是MUST run sequentially与wait for Step 7 to complete before spawning Step 8。这不是一句模糊的建议按顺序而是把执行约束写进契约本身任何读取该工作流的编排者无论是 Claude Code、Codex 还是其他运行时的 orchestrator都会看到明确的指令——第 8 步必须在第 7 步完成之后才能启动。同时说明块直接点破了设计动机两个步骤虽然写不同章节但共享同一个文件Write的整文件替换语义会让并行派发产生 last-writer-wins 覆盖。3.2 第二道防线Edit-only 工具纪律注入仅靠顺序约束并不够——即使顺序执行若两个 Agent 各自仍持有过期的内存副本并在收尾时用Write提交依然可能覆盖对方成果。因此修复同时向两个 Agent 的派发提示中都注入了强制工具纪律Tool discipline (mandatory):Use the Edit tool exclusively when modifying AI-SPEC.md — NEVER use Write on this file. Write replaces the entire file and will overwrite work from parallel or sequential sibling agents. Before editing, verify the section you are about to write is still a template placeholder.这段注入包含三个层次工具切换把默认的Write改为Edit——Edit只针对目标行做增量修改不触碰文件其余部分原理说明明确告知 AgentWrite会替换整个文件并覆盖兄弟 Agent 的成果无论并行还是顺序消除为什么不能用 Write的歧义前置校验要求 Agent 在编辑前先确认目标章节仍是模板占位符!-- ... --注释块从源头避免对已写入内容的二次覆盖。对应地两个 Agent 的独立定义文件也保留了文档查找、质量标准与成功标准等完整规范见 agents/gsd-ai-researcher.md 与 agents/gsd-domain-researcher.md修复并未削弱各自的研究深度要求只是修正了如何落盘的方式。四、回归测试把竞态防御固化为可执行断言修复不是一次性的仓库用专门的回归测试 tests/bug-3096-ai-integration-phase-parallel-race.test.cjs 把防御固化成了可重复验证的契约。该测试直接读取get-shit-done/workflows/ai-integration-phase.md的文本内容用四个断言守护修复成果Step 7 必须包含顺序执行声明校验工作流文本中出现sequentially或sequential字样缺失即视为竞态可复发Step 7 的 agent 提示必须包含 Edit-only 纪律截取 Step 7 到 Step 8 之间的文本块断言其中同时出现Edit tool与NEVER use WriteStep 8 的 agent 提示同样包含 Edit-only 纪律截取 Step 8 到 Step 9 之间的文本块做同样的断言Step 8 必须引用等待指令断言 Step 8 文本块中出现Wait/wait/complete字样。从测试源码可以推断其防御逻辑因为ai-integration-phase.md的文本本身就是运行时所加载的部署契约测试注释明确标注 reading product workflow markdown to verify structural ordering contract对文本做结构断言就是对运行时行为做验证。任何人后续编辑工作流时若误删排序说明或工具纪律测试会立刻失败。配套的 tests/ai-evals.test.cjs 则从配置侧守护整个 AI 集成阶段验证workflow.ai_integration_phase配置项默认值为true、支持config-set/config-get读写以及健康检查在缺失该配置时发出 W016 警告、并在--repair模式下通过addAiIntegrationPhaseKey自动补齐。五、通用工程启示多 Agent 共享文件的三条铁律从这次 40% 发生率的真实事故中可以提炼出适用于任何多 Agent或多进程协作写入共享文件的工程原则这也是本修复超越单一仓库的通用价值Write是破坏性操作共享文件必须禁用任何会并发或接力写入的共享文件都应约定Edit/patch式增量修改并把这一约定以强制措辞注入每个参与者的提示词章节不相交不等于可以并行只要共享同一物理文件整文件替换语义就足以让任何顺序优化变成数据丢失事故——必须显式声明MUST run sequentially而非依赖读者的合理推断用测试锁死契约文本当文档文本即运行时行为时对文档做结构断言包含顺序关键字、包含工具纪律、包含等待指令是最直接有效的防回归手段成本极低且可自动执行。GSD 团队在 .changeset/fix-3096-ai-integration-parallel-race.md 中将这次修复定性为Fixed关闭 issue #3096并选择将实测发生率、恢复代价写入变更记录——这些数据让后来的维护者能理解为什么这里要写得这么严格而不是把约束当成过度设计。六、如何在你的项目里复现与验证如果你希望在自己的 GSD 项目中观察这套防御机制是否生效可以按以下步骤操作仓库为只读以下均为查看与运行验证方式阅读工作流契约打开 get-shit-done/workflows/ai-integration-phase.md定位## 7. Spawn gsd-ai-researcher与## 8. Spawn gsd-domain-researcher两个小节确认排序说明块与 Edit-only 纪律文本均在位核对 Agent 提示词对照 agents/gsd-ai-researcher.md 与 agents/gsd-domain-researcher.md 中关于文件写入的约束表述运行回归测试执行测试 tests/bug-3096-ai-integration-phase-parallel-race.test.cjs四个断言全部通过即说明顺序约束与工具纪律未被破坏验证配置开关通过gsd-sdk query config-get workflow.ai_integration_phase确认 AI 集成阶段启用默认true或运行validate health观察 W016 警告的触发与--repair自愈行为。这套顺序执行 Edit-only 回归测试的组合拳让 AI-SPEC.md 的生成从一次 40% 概率的静默数据丢失变成有契约、有纪律、有验证的可靠流水线。赞分享人工智能AI 应用提示工程开发工具工作流自动化AI Agent【免费下载链接】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点击查看免费下载相关推荐gsd-core 多 Agent 并行写共享文件的竞态修复AI-SPEC.md 的 last-writer-wins 问题、Edit-only 纪律与回归保障gsd core 多 Agent 并行写共享文件的竞态修复AI SPEC.md 的 last writer wins 问题、Edit only 纪律与回归保障get-shit-done 状态机修复实战让 state complete-phase 幂等化彻底杜绝 STATE.md 被重复执行回滚get shit done 状态机修复实战让 state complete phase 幂等化彻底杜绝 STATE.md 被重复执行回滚 本篇技术指南围绕人工智能AI 应用提示工程开发工具工作流自动化AI Agentget-shit-done 修复 3599 深度解析roadmap get-phase 如何正确命中 project-code 前缀阶段 IDget shit done 修复 3599 深度解析roadmap get phase 如何正确命中 project code 前缀阶段 ID 本文基于仓库中人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇3分钟把NCM转成MP3ncmdump拖拽上手指南下一篇QKeyMapper按键映射教程键鼠手柄跨设备互换指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考