spec-superflow 已经在 GitHub 开源MIT 协议。如果你也被 AI 写代码的失控点折磨过建议直接装上试试源码就在仓库里架构、契约模板、状态机都看得见。大模型写代码最大的事故不是它不会写而是它在你没想清楚的时候就开始动手以及在你已经想清楚之后还是动手太随意。这两个问题开源社区其实各自有答案。OpenSpec 解决第一个Superpowers 解决第二个。但现实是绝大多数团队只装了一个或者两个都装了却没人手动把它们串起来。于是Github 有一个「自包含的工作流 owner」把两者的核心引擎源码级吸收进同一个插件用一个 8 状态机加 1 个执行契约桥接层把「想清楚」和「做对路」钉死在同一条流水线上。它叫 spec-superflow。spec-superflow 已经在 GitHub 开源MIT 协议。如果你也被 AI 写代码的失控点折磨过建议直接装上试试源码就在仓库里架构、契约模板、状态机都看得见。仓库地址在这里点个 Star 支持一下。GitHub - MageByte-Zero/spec-superflow: 源码级融合 OpenSpec 规划引擎 Superpowers 执行纪律的 AI 编程工作流插件。17 平台支持9 skillsSpec-first契约驱动。 · GitHub站在哪两个巨人肩膀上先把两位主角说清楚后面才好讲融合。superpowers一套「纪律优先」的 Agent 方法论superpowers作者 obra目前 v6.1.1不是单个提示词而是一整套面向编程智能体的可组合技能加启动引导。它的核心理念只有一句话Discipline over vibes用纪律代替感觉。它内置 14 个技能每个技能都是一个带 YAML frontmatter 的 SKILL.md靠description里的触发条件被 Agent 按需加载。几个关键角色你一定眼熟。using-superpowers是元技能也是入口网关。它有一条近乎霸道的规则哪怕你认为某技能只有 1% 的概率适用也必须调用它。它在每次会话启动时被各平台Claude Code、Cursor、Codex、Copilot CLI 等的 hook 注入首条消息变成「正在遵守」的元规则。brainstorming是创意工作前的强制门禁一次只问一个问题给出两到三个方案并推荐写设计文档到docs/superpowers/specs/而且有硬门禁设计没被批准前禁止任何实现动作。test-driven-development有一条铁律没有先写失败测试就写的生产代码必须删除重来RED 到 GREEN 再到 REFACTOR。subagent-driven-developmentSDD把每个任务派给一个全新的实现子 Agent每步做 spec 合规加代码质量双裁决用.superpowers/sdd/progress.md进度台账抵抗上下文压缩丢失。systematic-debugging要求先找根因再修连续三次修复失败就要质疑架构。verification-before-completion更狠声明完成前必须在本条消息里真正跑过验证命令并读到输出把「声称完成」视为一种不诚实。这套东西的精髓是它不靠「请你守规矩」的愿望式提示而是用行为塑形文档去约束 Agent。superpowers 关心的是 Agent 怎么 behave它的产物是 specs 和 plans 文件它自己既是规格的作者也是执行者。OpenSpec一套「规格驱动」的开发系统OpenSpec包名 fission-ai/openspec目前 v1.5.0的定位是「AI-native system for spec-driven development」一句话心智模型是 agree first, then build confidently先对齐再自信地构建。它解决的是「需求只活在聊天记录里、不可靠、不可追溯」的问题。人和 AI 之间加一层轻量的约定层agreement layer。它最漂亮的设计是 delta spec。变更里不重写整个规格只写差异用 ADDED、MODIFIED、REMOVED、RENAMED 四类区块表达。天然适配存量代码支持并行变更互不冲突归档时干净合并进主规格。默认工作流叫 spec-driven是一条 artifact 依赖图proposal 到 specs 到 design 到 tasks最后 apply。规格和变更文档是 Markdown配置和 schema 是 YAML主规格目录openspec/specs/是事实来源变更提案放openspec/changes/归档落openspec/changes/archive/。它还是 agent-friendly 的多数命令支持--json输出有指令注入机制能直接被 AI 消费。更夸张的是它给 30 多个 AI 编程客户端生成 skill 或 command 文件Claude Code、Cursor、Codex、Copilot、Kimi、Pi 都不在话下。前置只要 Node.js 20.19.0 以上用npm install -g fission-ai/openspec就能装。吃透这两位主角后你会发现一个尴尬的事实。OpenSpec 让 AI 必须先写规划工件才能动代码但它管不了执行阶段。superpowers 在执行阶段铁律森严但它自己也是规划工件的作者和执行者没把规划层和实现层用一份契约死死钉住。一个是「想清楚」的专家一个是「做对路」的教练。可大多数团队要么只请了一位要么两位都请了却没人负责把他俩的手牵到一起。设计理念源码级融合不是简单并列spec-superflow 官网文档里有一句我很喜欢的话它是 source-level fusion, not side-by-side installation源码级融合不是简单并列。这是它和「装两个插件」最本质的区别。它不让你去分别装 OpenSpec 和 superpowers再把两者手工串起来而是把两者的核心引擎源码级吸收进同一个插件。从 OpenSpec 借来的是规划侧的引擎Schema、验证、解析。Requirement、Scenario、Delta、Change、Spec 的类型定义从 proposal 里解析## Why、## What Changes与 delta 区块校验 spec 必须含 SHALL 或 MUST 以及#### Scenario:实现验证时按 Completeness、Correctness、Coherence 三维度比对 diff 和 spec。从 superpowers 借来的是执行侧的纪律TDD 铁律、SDD 子代理驱动、根因调试、代码审查三级严重度、完成前验证。但光借不够融合的真正难点在于怎么把「规划」和「执行」焊成一条流水线。spec-superflow 在这里独创了两样东西。一样是 contract-builder 桥接层。它把四份规划工件自动压缩成一份 execution-contract.md作为规划到实现的唯一交接层Guarded Handoff。没有这份契约或者契约没被批准就不准进入实现。另一样是 8 状态路由引擎由 workflow-start 这个入口技能承载。它把规划状态机和执行状态机统一成一条显式状态机并且阻止一切非法跳转。spec-superflow 模块架构所以你说它是站在巨人肩膀上一点不夸张。但它不是把巨人搬过来摆着而是把巨人的肌肉拆下来重新长进自己身体里再补上巨人们没空做的那块连接组织。整个插件自包含零运行时依赖仅 TypeScript 作为 devDependency不需要你再装 OpenSpec 或 superpowers。spec-superflow 融合能力矩阵架构设计模块、组件、数据流spec-superflow 的代码分两层一层是嵌入式 TypeScript 引擎一层是基于技能的工作流层。底座再实现的 OpenSpec 引擎src/目录下是它重新实现的 OpenSpec 引擎编译进dist/。schema/里定义 Requirement、Scenario、Delta、Change、Specparsing/里是正则解析器validation/里是校验器。注意它用的是正则解析没有引入 Zod 这类运行时校验库这正是它零运行时依赖的代价与底气。校验规则很硬。proposal.md 的## Why不能少于 50 个字符。spec.md 每个 Requirement 必须含 SHALL 或 MUST且至少一个#### Scenario:块。实现验证时把 diff 和 spec、design 比对按 Completeness、Correctness、Coherence 三维度判定。中层9 个核心技能skills/目录下是 9 个技能每个技能对应状态机里的一个阶段加一套指令集。workflow-start是入口做内容级状态检测、8 状态路由、阻止非法跳转。它读的是工件内容不是文件时间戳所以你关掉会话再打开它能准确判断自己停在哪一步。need-explorer负责探索一次一问加方案对比加推荐把方向失控掐死在萌芽。spec-writer产出 proposal、specs、design、tasks 四份工件且由 Schema 引擎实时验证。contract-builder是独创桥接层解析引擎自动提取四份工件压缩成 execution-contract.md。build-executor是执行核心TDD 铁律加 SDD 子代理驱动加 Review Gate 三重纪律。bug-investigator走四阶段根因分析三次修复失败必须质疑架构。code-reviewer做结构化审查问题分 Critical、Important、Minor 三级。release-archivist负责验证收口加归档加风险总结。spec-merger把 delta spec 智能合并回主规范专门防规范腐烂。数据流一次完整跑通把上面的组件连起来端到端是这样走的。你说「帮我加一个权限控制」workflow-start 作为唯一入口先做内容级状态检测路由到正确的技能。进入 exploringneed-explorer 会问你要 RBAC 还是 ABAC粒度多大。确认完进入 specifyingspec-writer 产出四份工件Schema 引擎当场验证格式。进入 bridgingcontract-builder 自动提取生成 execution-contract.md。到这里会出现整个流程里唯一一次人工介入契约批准DP-3。不批准不许写一行业务代码。批准后进入 executingbuild-executor 按 TDD 到 SDD 到 Review Gate 的顺序推进。遇到 bug 强制进 debugging由 bug-investigator 走根因分析不允许随便试试。收口由 release-archivist 验证加归档最后 spec-merger 把 delta spec 同步回主规范防止规范腐烂。spec-superflow 端到端数据流spec-superflow 八状态机它还有两条快速路径。hotfix 是改动不超过两个文件、不引入新模块时可以跳过完整规划工件但仍必须先生成一份最小 execution-contract.md 并完成 DP-3。tweak 是不超过四个文件、纯配置或文档修改时直接编辑。你看哪怕是小修小补那道契约硬墙也始终立着。使用方式装好说一句话就够了spec-superflow 不是单一平台插件而是多平台、单一源。同一套 skills、scripts、docs、templates、hooks通过各平台 manifest 和安装器分发到 17 个客户端。安装以 WorkBuddy 为例一句话搞定。npx spec-superflowlatest install-workbuddy本地调试可以用绝对路径先预览再装。node /绝对路径/spec-superflow/scripts/spec-superflow.mjs install-workbuddy --local /绝对路径/spec-superflow ssf install-workbuddy --dry-runClaude Code 走插件市场。/plugin marketplace add MageByte-Zero/spec-superflow /plugin install spec-superflowspec-superflowCursor 用户直接跑安装器。npx spec-superflowlatest install-cursor全局 CLI 也行npm install -g spec-superflow之后用ssf命令比如ssf validate dir校验工件ssf state sub dir看状态。启动装好之后对 Agent 说一句话就能拉起整套流水线。用 workflow-start 开始新功能开发时你说「加一个 SSO 登录」AI 会先问清 SAML、OIDC、账号体系、Provider 这些跑完四份规划工件加一份执行契约加 DP-3 审批才写第一行业务代码。恢复旧变更就说「继续上次的工作流」不确定当前状态就说「帮我看看现在该干什么」workflow-start 会在路由前先扫描 overlay 告诉你下一步。可选配置项目根目录放一个spec-superflow.config.json可以为不同执行角色配置模型。{ models: { mechanical: vendor-small, standard: vendor-standard, strong: vendor-strong, review: vendor-review } }机械性修改用便宜小模型架构和最终审查用最强模型。只读解析一个 profile 的命令是ssf config --resolve-model mechanical它只解析本地配置不调 API也不切当前会话模型。价值主张为什么不直接用两个框架讲到这价值已经藏在架构里了我把它摊开说。第一它用一面硬墙把两个失控点隔开而不是让你分别装两个工具。需求澄清到工件沉淀Schema 引擎验证格式执行契约桥接TDD 加 SDD 加 Review Gate 三重纪律强制执行验证收口delta spec 同步防腐烂一气呵成。第二规划白写的问题被根治。很多团队 proposal、design 写了也白写AI 执行照样跑偏。execution-contract.md 是规划到实现的唯一交接层规划一旦锁定执行就被关进契约的笼子里。第三自包含、零运行时依赖。上游两个工具都偏重团队往往不愿引入两个插件。spec-superflow 一个插件全包没有运行时负担。第四规范防腐烂。spec-merger 强制把 delta spec 合并回主规范避免「规格写完一次就腐烂」这个棕地项目最常见的痛。第五可审计、可重放、可证明。每个变更留下五份正式工件加 checkpoint 历史三个月后回看为什么这么写一目了然。workflow-start 内容级重放会话恢复时自动判断处于哪个状态。第六也是它相对两个上游最实在的工程卖点跨 17 个平台零迁移成本。今天用 Claude Code明天换 Cursor后天切 Trae同一套工作流原样带走skills、scripts、hooks 自动部署。它最适合大型功能开发、多人协作、长期维护、需要 TDD 加 Review Gate 的棕地项目。一次性脚本、纯咨询问答这类场景就别请它出山了。从「AI 写完再修」到「AI 一次写对」这才是规格驱动加执行纪律真正值钱的地方。spec-superflow 已经在 GitHub 开源MIT 协议目前已有 380 Star。如果你也被 AI 写代码的失控点折磨过建议直接装上试试源码就在仓库里架构、契约模板、状态机都看得见。仓库地址在这里求点个 Star 支持一下。https://github.com/MageByte-Zero/spec-superflow
spec-superflow 已经在 GitHub 开源MIT 协议。如果你也被 AI 写代码的失控点折磨过建议直接装上试试源码就在仓库里架构、契约模板、状态机都看得见。大模型写代码最大的事故不是它不会写而是它在你没想清楚的时候就开始动手以及在你已经想清楚之后还是动手太随意。这两个问题开源社区其实各自有答案。OpenSpec 解决第一个Superpowers 解决第二个。但现实是绝大多数团队只装了一个或者两个都装了却没人手动把它们串起来。于是Github 有一个「自包含的工作流 owner」把两者的核心引擎源码级吸收进同一个插件用一个 8 状态机加 1 个执行契约桥接层把「想清楚」和「做对路」钉死在同一条流水线上。它叫 spec-superflow。spec-superflow 已经在 GitHub 开源MIT 协议。如果你也被 AI 写代码的失控点折磨过建议直接装上试试源码就在仓库里架构、契约模板、状态机都看得见。仓库地址在这里点个 Star 支持一下。GitHub - MageByte-Zero/spec-superflow: 源码级融合 OpenSpec 规划引擎 Superpowers 执行纪律的 AI 编程工作流插件。17 平台支持9 skillsSpec-first契约驱动。 · GitHub站在哪两个巨人肩膀上先把两位主角说清楚后面才好讲融合。superpowers一套「纪律优先」的 Agent 方法论superpowers作者 obra目前 v6.1.1不是单个提示词而是一整套面向编程智能体的可组合技能加启动引导。它的核心理念只有一句话Discipline over vibes用纪律代替感觉。它内置 14 个技能每个技能都是一个带 YAML frontmatter 的 SKILL.md靠description里的触发条件被 Agent 按需加载。几个关键角色你一定眼熟。using-superpowers是元技能也是入口网关。它有一条近乎霸道的规则哪怕你认为某技能只有 1% 的概率适用也必须调用它。它在每次会话启动时被各平台Claude Code、Cursor、Codex、Copilot CLI 等的 hook 注入首条消息变成「正在遵守」的元规则。brainstorming是创意工作前的强制门禁一次只问一个问题给出两到三个方案并推荐写设计文档到docs/superpowers/specs/而且有硬门禁设计没被批准前禁止任何实现动作。test-driven-development有一条铁律没有先写失败测试就写的生产代码必须删除重来RED 到 GREEN 再到 REFACTOR。subagent-driven-developmentSDD把每个任务派给一个全新的实现子 Agent每步做 spec 合规加代码质量双裁决用.superpowers/sdd/progress.md进度台账抵抗上下文压缩丢失。systematic-debugging要求先找根因再修连续三次修复失败就要质疑架构。verification-before-completion更狠声明完成前必须在本条消息里真正跑过验证命令并读到输出把「声称完成」视为一种不诚实。这套东西的精髓是它不靠「请你守规矩」的愿望式提示而是用行为塑形文档去约束 Agent。superpowers 关心的是 Agent 怎么 behave它的产物是 specs 和 plans 文件它自己既是规格的作者也是执行者。OpenSpec一套「规格驱动」的开发系统OpenSpec包名 fission-ai/openspec目前 v1.5.0的定位是「AI-native system for spec-driven development」一句话心智模型是 agree first, then build confidently先对齐再自信地构建。它解决的是「需求只活在聊天记录里、不可靠、不可追溯」的问题。人和 AI 之间加一层轻量的约定层agreement layer。它最漂亮的设计是 delta spec。变更里不重写整个规格只写差异用 ADDED、MODIFIED、REMOVED、RENAMED 四类区块表达。天然适配存量代码支持并行变更互不冲突归档时干净合并进主规格。默认工作流叫 spec-driven是一条 artifact 依赖图proposal 到 specs 到 design 到 tasks最后 apply。规格和变更文档是 Markdown配置和 schema 是 YAML主规格目录openspec/specs/是事实来源变更提案放openspec/changes/归档落openspec/changes/archive/。它还是 agent-friendly 的多数命令支持--json输出有指令注入机制能直接被 AI 消费。更夸张的是它给 30 多个 AI 编程客户端生成 skill 或 command 文件Claude Code、Cursor、Codex、Copilot、Kimi、Pi 都不在话下。前置只要 Node.js 20.19.0 以上用npm install -g fission-ai/openspec就能装。吃透这两位主角后你会发现一个尴尬的事实。OpenSpec 让 AI 必须先写规划工件才能动代码但它管不了执行阶段。superpowers 在执行阶段铁律森严但它自己也是规划工件的作者和执行者没把规划层和实现层用一份契约死死钉住。一个是「想清楚」的专家一个是「做对路」的教练。可大多数团队要么只请了一位要么两位都请了却没人负责把他俩的手牵到一起。设计理念源码级融合不是简单并列spec-superflow 官网文档里有一句我很喜欢的话它是 source-level fusion, not side-by-side installation源码级融合不是简单并列。这是它和「装两个插件」最本质的区别。它不让你去分别装 OpenSpec 和 superpowers再把两者手工串起来而是把两者的核心引擎源码级吸收进同一个插件。从 OpenSpec 借来的是规划侧的引擎Schema、验证、解析。Requirement、Scenario、Delta、Change、Spec 的类型定义从 proposal 里解析## Why、## What Changes与 delta 区块校验 spec 必须含 SHALL 或 MUST 以及#### Scenario:实现验证时按 Completeness、Correctness、Coherence 三维度比对 diff 和 spec。从 superpowers 借来的是执行侧的纪律TDD 铁律、SDD 子代理驱动、根因调试、代码审查三级严重度、完成前验证。但光借不够融合的真正难点在于怎么把「规划」和「执行」焊成一条流水线。spec-superflow 在这里独创了两样东西。一样是 contract-builder 桥接层。它把四份规划工件自动压缩成一份 execution-contract.md作为规划到实现的唯一交接层Guarded Handoff。没有这份契约或者契约没被批准就不准进入实现。另一样是 8 状态路由引擎由 workflow-start 这个入口技能承载。它把规划状态机和执行状态机统一成一条显式状态机并且阻止一切非法跳转。spec-superflow 模块架构所以你说它是站在巨人肩膀上一点不夸张。但它不是把巨人搬过来摆着而是把巨人的肌肉拆下来重新长进自己身体里再补上巨人们没空做的那块连接组织。整个插件自包含零运行时依赖仅 TypeScript 作为 devDependency不需要你再装 OpenSpec 或 superpowers。spec-superflow 融合能力矩阵架构设计模块、组件、数据流spec-superflow 的代码分两层一层是嵌入式 TypeScript 引擎一层是基于技能的工作流层。底座再实现的 OpenSpec 引擎src/目录下是它重新实现的 OpenSpec 引擎编译进dist/。schema/里定义 Requirement、Scenario、Delta、Change、Specparsing/里是正则解析器validation/里是校验器。注意它用的是正则解析没有引入 Zod 这类运行时校验库这正是它零运行时依赖的代价与底气。校验规则很硬。proposal.md 的## Why不能少于 50 个字符。spec.md 每个 Requirement 必须含 SHALL 或 MUST且至少一个#### Scenario:块。实现验证时把 diff 和 spec、design 比对按 Completeness、Correctness、Coherence 三维度判定。中层9 个核心技能skills/目录下是 9 个技能每个技能对应状态机里的一个阶段加一套指令集。workflow-start是入口做内容级状态检测、8 状态路由、阻止非法跳转。它读的是工件内容不是文件时间戳所以你关掉会话再打开它能准确判断自己停在哪一步。need-explorer负责探索一次一问加方案对比加推荐把方向失控掐死在萌芽。spec-writer产出 proposal、specs、design、tasks 四份工件且由 Schema 引擎实时验证。contract-builder是独创桥接层解析引擎自动提取四份工件压缩成 execution-contract.md。build-executor是执行核心TDD 铁律加 SDD 子代理驱动加 Review Gate 三重纪律。bug-investigator走四阶段根因分析三次修复失败必须质疑架构。code-reviewer做结构化审查问题分 Critical、Important、Minor 三级。release-archivist负责验证收口加归档加风险总结。spec-merger把 delta spec 智能合并回主规范专门防规范腐烂。数据流一次完整跑通把上面的组件连起来端到端是这样走的。你说「帮我加一个权限控制」workflow-start 作为唯一入口先做内容级状态检测路由到正确的技能。进入 exploringneed-explorer 会问你要 RBAC 还是 ABAC粒度多大。确认完进入 specifyingspec-writer 产出四份工件Schema 引擎当场验证格式。进入 bridgingcontract-builder 自动提取生成 execution-contract.md。到这里会出现整个流程里唯一一次人工介入契约批准DP-3。不批准不许写一行业务代码。批准后进入 executingbuild-executor 按 TDD 到 SDD 到 Review Gate 的顺序推进。遇到 bug 强制进 debugging由 bug-investigator 走根因分析不允许随便试试。收口由 release-archivist 验证加归档最后 spec-merger 把 delta spec 同步回主规范防止规范腐烂。spec-superflow 端到端数据流spec-superflow 八状态机它还有两条快速路径。hotfix 是改动不超过两个文件、不引入新模块时可以跳过完整规划工件但仍必须先生成一份最小 execution-contract.md 并完成 DP-3。tweak 是不超过四个文件、纯配置或文档修改时直接编辑。你看哪怕是小修小补那道契约硬墙也始终立着。使用方式装好说一句话就够了spec-superflow 不是单一平台插件而是多平台、单一源。同一套 skills、scripts、docs、templates、hooks通过各平台 manifest 和安装器分发到 17 个客户端。安装以 WorkBuddy 为例一句话搞定。npx spec-superflowlatest install-workbuddy本地调试可以用绝对路径先预览再装。node /绝对路径/spec-superflow/scripts/spec-superflow.mjs install-workbuddy --local /绝对路径/spec-superflow ssf install-workbuddy --dry-runClaude Code 走插件市场。/plugin marketplace add MageByte-Zero/spec-superflow /plugin install spec-superflowspec-superflowCursor 用户直接跑安装器。npx spec-superflowlatest install-cursor全局 CLI 也行npm install -g spec-superflow之后用ssf命令比如ssf validate dir校验工件ssf state sub dir看状态。启动装好之后对 Agent 说一句话就能拉起整套流水线。用 workflow-start 开始新功能开发时你说「加一个 SSO 登录」AI 会先问清 SAML、OIDC、账号体系、Provider 这些跑完四份规划工件加一份执行契约加 DP-3 审批才写第一行业务代码。恢复旧变更就说「继续上次的工作流」不确定当前状态就说「帮我看看现在该干什么」workflow-start 会在路由前先扫描 overlay 告诉你下一步。可选配置项目根目录放一个spec-superflow.config.json可以为不同执行角色配置模型。{ models: { mechanical: vendor-small, standard: vendor-standard, strong: vendor-strong, review: vendor-review } }机械性修改用便宜小模型架构和最终审查用最强模型。只读解析一个 profile 的命令是ssf config --resolve-model mechanical它只解析本地配置不调 API也不切当前会话模型。价值主张为什么不直接用两个框架讲到这价值已经藏在架构里了我把它摊开说。第一它用一面硬墙把两个失控点隔开而不是让你分别装两个工具。需求澄清到工件沉淀Schema 引擎验证格式执行契约桥接TDD 加 SDD 加 Review Gate 三重纪律强制执行验证收口delta spec 同步防腐烂一气呵成。第二规划白写的问题被根治。很多团队 proposal、design 写了也白写AI 执行照样跑偏。execution-contract.md 是规划到实现的唯一交接层规划一旦锁定执行就被关进契约的笼子里。第三自包含、零运行时依赖。上游两个工具都偏重团队往往不愿引入两个插件。spec-superflow 一个插件全包没有运行时负担。第四规范防腐烂。spec-merger 强制把 delta spec 合并回主规范避免「规格写完一次就腐烂」这个棕地项目最常见的痛。第五可审计、可重放、可证明。每个变更留下五份正式工件加 checkpoint 历史三个月后回看为什么这么写一目了然。workflow-start 内容级重放会话恢复时自动判断处于哪个状态。第六也是它相对两个上游最实在的工程卖点跨 17 个平台零迁移成本。今天用 Claude Code明天换 Cursor后天切 Trae同一套工作流原样带走skills、scripts、hooks 自动部署。它最适合大型功能开发、多人协作、长期维护、需要 TDD 加 Review Gate 的棕地项目。一次性脚本、纯咨询问答这类场景就别请它出山了。从「AI 写完再修」到「AI 一次写对」这才是规格驱动加执行纪律真正值钱的地方。spec-superflow 已经在 GitHub 开源MIT 协议目前已有 380 Star。如果你也被 AI 写代码的失控点折磨过建议直接装上试试源码就在仓库里架构、契约模板、状态机都看得见。仓库地址在这里求点个 Star 支持一下。https://github.com/MageByte-Zero/spec-superflow
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
