AI 编程最难兼顾的两件事是速度和确定性。只追求速度小任务做得很快遇到跨模块改造却容易在执行中改变需求、遗漏边界只追求严谨每个任务都写完整规格、设计和审查材料一个小修复也会被流程拖慢。spec-superflow 2.0 给出的答案是让流程随风险变化。边界清楚的小任务走 Direct在当前会话连续开发、验证和交付复杂任务走 Planned用 proposal、tasks 和按需规格锁定目标再通过完整范围审查与最终验证保证实现没有漂移。它融合了 OpenSpec 的结构化规划能力也吸收了 Superpowers 的调试、审查和验证纪律。最终得到的不是两套工具的简单拼接而是一套能覆盖真实软件开发复杂度的 AI 工程工作流。一套工作流覆盖两类完全不同的开发任务spec-superflow 2.0 把新任务收敛为两个入口。Direct让明确的小任务直接进入开发Direct 适合目标、边界和验证方式都清楚的工作例如修复一个已经定位的登录超时调整配置、文档或局部交互修改少量文件且不改变公共协议已经知道根因和验收命令的缺陷修复。它不强制先生成完整规划工件也不默认派发子代理或创建 worktree。AI 可以留在当前会话连续理解代码、完成实现、自检并运行最终验证减少上下文交接和重复读取。Direct 的价值不是“少写几份文档”而是让简单任务保持简单。Planned让复杂任务从批准范围走到可验证交付Planned 面向跨模块、公共接口、状态机、数据语义和多人协作等复杂变更。默认只需要两份核心工件proposal.md为什么改、要改变什么、边界在哪里tasks.md怎样执行、每一步如何验证。当行为基线需要精确定义时再增加 delta specs当存在架构选择和长期约束时再增加 design。工件由风险决定不用固定模板把任务越写越重。批准以后执行始终围绕同一份计划推进。范围发生变化系统会明确识别漂移实现完成后审查覆盖完整 Git range最终验证记录真实结果。复杂任务因此既能持续推进也不会在几十轮对话后变成另一个需求。OpenSpec 管“做什么”Superpowers 管“怎样可靠地做完”OpenSpec 最有价值的地方是把需求从聊天内容变成可检查的工程对象。proposal 保存变更动机和范围delta spec 用ADDED、MODIFIED、REMOVED、RENAMED表达行为变化Requirement 与 Scenario 把“应该这样工作”变成可以测试的约束。这让复杂任务在进入代码前就有稳定边界。Superpowers 的优势则在执行纪律先理解再实现遇到失败先调查根因完成前审查真实改动并运行验证。它解决的是 AI 容易“写完就宣布完成”的问题。spec-superflow 2.0 把两者连接成一条闭环用风险选择 Direct 或 PlannedPlanned 用结构化工件锁定目标Direct 保留明确 scope默认在当前会话连续执行减少上下文损耗失败进入根因调试回环修复后回到原执行链按入口加载审查强度最后统一验证只有真实验证通过才能记录为verified。如果某项风险经过人类判断可以接受也能记录为accepted-risk但失败证据会被保留不会被包装成验证通过。机器负责提供证据人类保留最终决策权。复杂任务为什么不容易漂移很多 AI 工作流的问题不在“有没有计划”而在计划、代码、审查和验证是不是同一件事。spec-superflow 2.0 为这条链路补齐了几个关键约束。规划事实只有一个来源。新 Planned 任务由 schema v2 execution plan 承载授权、范围和执行模式避免多份摘要彼此不一致。审查覆盖完整改动。它拒绝空 Git range也不会用HEAD~1把多提交变更截成最后一次提交。审查证据必须与实际变更范围一致。验证结果绑定最终状态。finish 验证会记录影响结果的输入指纹。代码或环境发生变化就不能继续复用旧的“通过”。恢复必须回到正确目录和分支。默认隔离方式是普通特性分支只有明确需要多个并行 checkout 时才创建 worktree。恢复记录会校验仓库、分支和路径submodule 与失败重试也保留在正确隔离环境中。路径边界可以验证。symlink、安装目标、overlay 和跨平台 realpath 都经过边界检查避免自动化流程把文件写到预期目录之外。这些能力平时不会增加对话负担却会在复杂任务最容易失控的位置发挥作用。9 个 Skills是能力菜单不是九个必经阶段Skill作用workflow-start选择 Direct / Planned启动或恢复任务need-explorer在需求模糊时澄清目标、边界和验收标准spec-writer生成 proposal、tasks 以及按需 specs/designcontract-builder兼容旧 change 的执行合同不进入新任务默认链build-executor在批准范围内连续实现、自检和验证bug-investigator调查根因避免随机试修和无效循环code-reviewer对 Planned 或高风险改动做完整范围审查spec-merger将 delta spec 原子同步到正式规格基线release-archivist运行最终验证记录 verified 或 accepted-risk小任务最短可以是workflow-start → build-executor → release-archivist复杂任务则按需要组合need-explorer? → spec-writer → workflow-start → build-executor → code-reviewer → spec-merger? → release-archivist问号代表按需启用。你获得的是一组可以组合的工程能力而不是一条所有任务都必须走完的流水线。默认更轻也保留高级执行能力2.0 默认使用 Native 模式让当前 Agent 在当前会话持续实现。普通任务不必为了“流程完整”自动拆成子任务、派发多个 Agent再等待逐波审查。复杂任务需要并行时SDD、子代理和逐波 review 仍然可以显式启用需要同时维护多个 checkout 时也可以显式选择 worktree。区别在于这些能力现在由任务需要触发而不是成为每次开发的固定成本。普通会话也不会被 SessionStart 或全局规则塞入完整工作流进入已有 change 或显式调用时才读取需要的说明和状态。这让 spec-superflow 既适合一个文件的小修复也能承载跨模块、跨提交、长周期的复杂开发。经过大版本验证而不只是改了流程说明从 v1.2.0 到 v2.0.0本次升级跨越 5 个提交、115 个文件Git shortstat 为 3374 行新增、3291 行删除。本地发布候选完成了153 个测试 suite、916 个自动化测试raw package 安装与运行 smoke testCLI、Skills、模板、安装器和文档一致性检查Linux、macOS 与 Windows 路径边界覆盖。项目保持零运行时依赖Node.js 20 即可运行并为 Codex、Claude Code、Cursor、GitHub Copilot CLI、Gemini CLI、OpenCode、WorkBuddy、Trae 等 19 个 AI 编程平台提供接入方式。使用方式一安装 2.0截至本文发布准备时v2.0.0tag 已指向包含新版 README 的最新提交。GitHub Release 与 npm 2.0.0 仍等待 Marketplace 版本门禁因此 Codex CLI / App 可以先固定 tag 安装codex plugin marketplace add MageByte-Zero/spec-superflow --ref v2.0.0 codex plugin add spec-superflowspec-superflow其他平台可以从仓库根目录运行安装器也可以查阅INSTALL.md中对应平台的命令。使用方式二用 Direct 完成一个小任务边界明确的小任务直接启动 Directmkdir -p changes/fix-login-timeout ssf workflow start changes/fix-login-timeout \ --path direct \ --scope 修复登录超时不改变认证协议实现完成后用真实验证命令结束任务ssf workflow complete changes/fix-login-timeout \ --verification-command npm test如果验证失败状态不会被写成通过。修复后继续执行同一个 change再次完成验证即可。使用方式三用 Planned 推进复杂任务复杂任务先创建proposal.md和tasks.md。涉及公共行为时补充 specs存在架构取舍时补充 design。用户确认范围后启动ssf workflow start changes/add-session-refresh \ --path planned \ --confirm \ --reason 用户已批准 proposal.md 与 tasks.md执行过程中可以随时检查和恢复ssf resume changes/add-session-refresh ssf checkpoint save changes/add-session-refresh ssf validate changes/add-session-refresh如果包含 delta specs交付前使用ssf sync原子同步正式规格完成实现、完整范围审查和最终验证后再执行关闭与归档。使用方式四选择分支或显式 worktree默认创建普通特性分支ssf isolate changes/add-session-refresh只有需要同时维护多个 checkout 时才显式创建 worktreessf isolate changes/add-session-refresh --worktree恢复和完成操作都会核对记录中的仓库、分支和路径避免在错误目录继续执行。选择标准可以压缩成三句目标和验证清楚用 Direct需要先批准范围用 Planned只有并行收益或隔离需求明确时才启用子代理和 worktree。让 AI 编程既快又能对最终结果负责spec-superflow 2.0 的目标很明确小任务不被流程拖慢复杂任务不因对话变长而漂移。OpenSpec 提供可持续维护的需求与规格结构Superpowers 提供根因调试、代码审查和完成前验证spec-superflow 则把它们变成可以在真实项目里按风险运行的完整闭环。如果你正在用 Codex、Claude Code、Cursor 或其他 AI Agent 开发项目可以从一个 Direct 小任务开始下一次遇到跨模块改造再用 Planned 感受范围锁定、执行恢复和完整审查带来的确定性。项目地址MageByte-Zero/spec-superflow。欢迎 Star、试用和提交反馈。 
长河君 · 2026/10/31 11:09:41 · 阅读 1.2k spec-superflow 2.0：小任务快跑，复杂任务不漂移
AI 编程最难兼顾的两件事是速度和确定性。只追求速度小任务做得很快遇到跨模块改造却容易在执行中改变需求、遗漏边界只追求严谨每个任务都写完整规格、设计和审查材料一个小修复也会被流程拖慢。spec-superflow 2.0 给出的答案是让流程随风险变化。边界清楚的小任务走 Direct在当前会话连续开发、验证和交付复杂任务走 Planned用 proposal、tasks 和按需规格锁定目标再通过完整范围审查与最终验证保证实现没有漂移。它融合了 OpenSpec 的结构化规划能力也吸收了 Superpowers 的调试、审查和验证纪律。最终得到的不是两套工具的简单拼接而是一套能覆盖真实软件开发复杂度的 AI 工程工作流。一套工作流覆盖两类完全不同的开发任务spec-superflow 2.0 把新任务收敛为两个入口。Direct让明确的小任务直接进入开发Direct 适合目标、边界和验证方式都清楚的工作例如修复一个已经定位的登录超时调整配置、文档或局部交互修改少量文件且不改变公共协议已经知道根因和验收命令的缺陷修复。它不强制先生成完整规划工件也不默认派发子代理或创建 worktree。AI 可以留在当前会话连续理解代码、完成实现、自检并运行最终验证减少上下文交接和重复读取。Direct 的价值不是“少写几份文档”而是让简单任务保持简单。Planned让复杂任务从批准范围走到可验证交付Planned 面向跨模块、公共接口、状态机、数据语义和多人协作等复杂变更。默认只需要两份核心工件proposal.md为什么改、要改变什么、边界在哪里tasks.md怎样执行、每一步如何验证。当行为基线需要精确定义时再增加 delta specs当存在架构选择和长期约束时再增加 design。工件由风险决定不用固定模板把任务越写越重。批准以后执行始终围绕同一份计划推进。范围发生变化系统会明确识别漂移实现完成后审查覆盖完整 Git range最终验证记录真实结果。复杂任务因此既能持续推进也不会在几十轮对话后变成另一个需求。OpenSpec 管“做什么”Superpowers 管“怎样可靠地做完”OpenSpec 最有价值的地方是把需求从聊天内容变成可检查的工程对象。proposal 保存变更动机和范围delta spec 用ADDED、MODIFIED、REMOVED、RENAMED表达行为变化Requirement 与 Scenario 把“应该这样工作”变成可以测试的约束。这让复杂任务在进入代码前就有稳定边界。Superpowers 的优势则在执行纪律先理解再实现遇到失败先调查根因完成前审查真实改动并运行验证。它解决的是 AI 容易“写完就宣布完成”的问题。spec-superflow 2.0 把两者连接成一条闭环用风险选择 Direct 或 PlannedPlanned 用结构化工件锁定目标Direct 保留明确 scope默认在当前会话连续执行减少上下文损耗失败进入根因调试回环修复后回到原执行链按入口加载审查强度最后统一验证只有真实验证通过才能记录为verified。如果某项风险经过人类判断可以接受也能记录为accepted-risk但失败证据会被保留不会被包装成验证通过。机器负责提供证据人类保留最终决策权。复杂任务为什么不容易漂移很多 AI 工作流的问题不在“有没有计划”而在计划、代码、审查和验证是不是同一件事。spec-superflow 2.0 为这条链路补齐了几个关键约束。规划事实只有一个来源。新 Planned 任务由 schema v2 execution plan 承载授权、范围和执行模式避免多份摘要彼此不一致。审查覆盖完整改动。它拒绝空 Git range也不会用HEAD~1把多提交变更截成最后一次提交。审查证据必须与实际变更范围一致。验证结果绑定最终状态。finish 验证会记录影响结果的输入指纹。代码或环境发生变化就不能继续复用旧的“通过”。恢复必须回到正确目录和分支。默认隔离方式是普通特性分支只有明确需要多个并行 checkout 时才创建 worktree。恢复记录会校验仓库、分支和路径submodule 与失败重试也保留在正确隔离环境中。路径边界可以验证。symlink、安装目标、overlay 和跨平台 realpath 都经过边界检查避免自动化流程把文件写到预期目录之外。这些能力平时不会增加对话负担却会在复杂任务最容易失控的位置发挥作用。9 个 Skills是能力菜单不是九个必经阶段Skill作用workflow-start选择 Direct / Planned启动或恢复任务need-explorer在需求模糊时澄清目标、边界和验收标准spec-writer生成 proposal、tasks 以及按需 specs/designcontract-builder兼容旧 change 的执行合同不进入新任务默认链build-executor在批准范围内连续实现、自检和验证bug-investigator调查根因避免随机试修和无效循环code-reviewer对 Planned 或高风险改动做完整范围审查spec-merger将 delta spec 原子同步到正式规格基线release-archivist运行最终验证记录 verified 或 accepted-risk小任务最短可以是workflow-start → build-executor → release-archivist复杂任务则按需要组合need-explorer? → spec-writer → workflow-start → build-executor → code-reviewer → spec-merger? → release-archivist问号代表按需启用。你获得的是一组可以组合的工程能力而不是一条所有任务都必须走完的流水线。默认更轻也保留高级执行能力2.0 默认使用 Native 模式让当前 Agent 在当前会话持续实现。普通任务不必为了“流程完整”自动拆成子任务、派发多个 Agent再等待逐波审查。复杂任务需要并行时SDD、子代理和逐波 review 仍然可以显式启用需要同时维护多个 checkout 时也可以显式选择 worktree。区别在于这些能力现在由任务需要触发而不是成为每次开发的固定成本。普通会话也不会被 SessionStart 或全局规则塞入完整工作流进入已有 change 或显式调用时才读取需要的说明和状态。这让 spec-superflow 既适合一个文件的小修复也能承载跨模块、跨提交、长周期的复杂开发。经过大版本验证而不只是改了流程说明从 v1.2.0 到 v2.0.0本次升级跨越 5 个提交、115 个文件Git shortstat 为 3374 行新增、3291 行删除。本地发布候选完成了153 个测试 suite、916 个自动化测试raw package 安装与运行 smoke testCLI、Skills、模板、安装器和文档一致性检查Linux、macOS 与 Windows 路径边界覆盖。项目保持零运行时依赖Node.js 20 即可运行并为 Codex、Claude Code、Cursor、GitHub Copilot CLI、Gemini CLI、OpenCode、WorkBuddy、Trae 等 19 个 AI 编程平台提供接入方式。使用方式一安装 2.0截至本文发布准备时v2.0.0tag 已指向包含新版 README 的最新提交。GitHub Release 与 npm 2.0.0 仍等待 Marketplace 版本门禁因此 Codex CLI / App 可以先固定 tag 安装codex plugin marketplace add MageByte-Zero/spec-superflow --ref v2.0.0 codex plugin add spec-superflowspec-superflow其他平台可以从仓库根目录运行安装器也可以查阅INSTALL.md中对应平台的命令。使用方式二用 Direct 完成一个小任务边界明确的小任务直接启动 Directmkdir -p changes/fix-login-timeout ssf workflow start changes/fix-login-timeout \ --path direct \ --scope 修复登录超时不改变认证协议实现完成后用真实验证命令结束任务ssf workflow complete changes/fix-login-timeout \ --verification-command npm test如果验证失败状态不会被写成通过。修复后继续执行同一个 change再次完成验证即可。使用方式三用 Planned 推进复杂任务复杂任务先创建proposal.md和tasks.md。涉及公共行为时补充 specs存在架构取舍时补充 design。用户确认范围后启动ssf workflow start changes/add-session-refresh \ --path planned \ --confirm \ --reason 用户已批准 proposal.md 与 tasks.md执行过程中可以随时检查和恢复ssf resume changes/add-session-refresh ssf checkpoint save changes/add-session-refresh ssf validate changes/add-session-refresh如果包含 delta specs交付前使用ssf sync原子同步正式规格完成实现、完整范围审查和最终验证后再执行关闭与归档。使用方式四选择分支或显式 worktree默认创建普通特性分支ssf isolate changes/add-session-refresh只有需要同时维护多个 checkout 时才显式创建 worktreessf isolate changes/add-session-refresh --worktree恢复和完成操作都会核对记录中的仓库、分支和路径避免在错误目录继续执行。选择标准可以压缩成三句目标和验证清楚用 Direct需要先批准范围用 Planned只有并行收益或隔离需求明确时才启用子代理和 worktree。让 AI 编程既快又能对最终结果负责spec-superflow 2.0 的目标很明确小任务不被流程拖慢复杂任务不因对话变长而漂移。OpenSpec 提供可持续维护的需求与规格结构Superpowers 提供根因调试、代码审查和完成前验证spec-superflow 则把它们变成可以在真实项目里按风险运行的完整闭环。如果你正在用 Codex、Claude Code、Cursor 或其他 AI Agent 开发项目可以从一个 Direct 小任务开始下一次遇到跨模块改造再用 Planned 感受范围锁定、执行恢复和完整审查带来的确定性。项目地址MageByte-Zero/spec-superflow。欢迎 Star、试用和提交反馈。