GSD 2 长期规范驱动编码代理工作流

问题：长周期编码代理的失控与遗忘

当编码代理连续运行数小时甚至数天时，最常见的故障模式是“漂移”。随着上下文窗口不断膨胀，代理会逐渐遗忘早期的架构规范，开始生成偏离初衷的代码。此外，线性执行耗时过长，如果缺乏自动化的验收机制，工程师根本无法放心离开键盘。

工作原理：拆解、隔离与验证

该技能将宏大的长期目标转化为受监督的标准化工作流：

• 里程碑拆解：将复杂项目分解为多个独立且可管理的里程碑，使代理能够逐个击破。
• 上下文与分支管理：隔离不同任务的上下文环境，防止内存污染，并通过分支管理并行的开发路径。
• 漂移恢复：监控代理的输出轨迹，当检测到偏离规范时及时介入纠偏，避免系统级重构。
• 验证执行：在每个任务结束后，自动运行如 npm run test 或 npm run lint 的检查命令，确保交付质量。

适用边界与配置注意点

这套工作流的可靠性高度依赖于验证配置，它并不能魔法般地解决所有工程问题：

• 保持验证命令纯粹：验证脚本必须是简单独立的可执行命令。严禁在配置中使用 shell 管道（如 |）或逻辑控制语法（如 &&），否则可能导致静默失败。
• 隔离运行环境：官方建议在隔离的 Docker 沙盒中运行自动模式，以防止代理执行危险操作时波及宿主机。
• 并行的前提是解耦：尽管它支持同时编排多个里程碑以实现“走开后带回来成品”的体验，但前提是你的项目架构具备合理的模块独立性，否则并行冲突会抵消加速收益。