【自荐】厌倦了OpenSpec 、OMO、superpowers？试试CodeStable

2026-04-29 08:082阅读0评论SEO基础
  • 内容介绍
  • 文章标签
  • 相关推荐
问题描述：

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

  • 我的帖子已经打上 开源推广 标签： 是
  • 我的开源项目完整开源，无未开源部分： 是
  • 我的开源项目已链接认可 LINUX DO 社区： 是
  • 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
  • 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

EasySDD 正式改名为 CodeStable
PromotionalImage1672×941 129 KB

缘起

我在开发一套新的 Harness Agent（MA），一开始当然是 VibeCoding——我只写设计和需求，代码由 AI 来改。这样支撑了大部分特性的开发。直到有一天 Codex 反复解决不了一个我认为比较简单的问题，并且反复在同一个地方犯错。我就知道项目需要一套工作流来维持它继续进行了。

我调研了 OpenSpec、SuperPowers、Oh-My-OpenAgent 这一类工具，没一个用着顺手：

  • OpenSpec 太简单，没有复利工程，生成的 Spec 抽象到人类没法读
  • SuperPowers 没有流程约束，不知道该用哪个
  • Oh-My-OpenAgent 太重，且哲学上认为"人介入 = 失败"

CodeStable 的目标是解决严肃工程的软件实现和编码问题，不是造一个新名词、追求热点。

与其他框架的核心区别：编排的目标是谁

我看了一圈现在主流的 AI 编码框架——Superpowers、CCW、Oh-My-OpenAgent 等等——它们的工作重点是一样的：

如何编排 Agent 。 让它们组队、协作、头脑风暴、跑流水线、自动接力。围绕的实体始终是 Agent。

CodeStable 的思路不同：

编排的是软件本身的生命周期。 围绕的实体是构成软件的要素——每一个需求、每一个架构决定、每一个特性、每一个 bug、每一条历史里留下来的约束。

Agent 编排CodeStable
核心实体Agent / Role / TeamRequirement / Architecture / Feature / Issue / Decision
主线问题Agent 之间怎么分工、传递、协调？软件的需求、约束、决策怎么被记下来、被检索、被复用？
状态存在哪Agent 的 session / 消息总线 / 队列项目里的 codestable/ 文件树（人和 AI 都能读）
解决的痛点单 Agent 能力不够，需要协同放大软件复杂度膨胀撑破上下文、隐知识丢失、需求漂移
对人的定位人少介入越好，理想是全自动人在环 —— 程序员对整体把控负责，AI 是高效的执行体

CodeStableVSAgent1672×941 159 KB

这两个方向没有谁对谁错，甚至可以融合

如果你的任务是"用 AI 跑一个端到端的自动化产线"、“让多个 Agent 互相讨论方案”，Agent 编排显然会更强。

如果你的任务是"维护一个会跨年迭代的严肃软件"、“让今天写下的需求和决策三个月后还能被准确召回”——那以软件要素为中心才是对的。

软件工程的混乱本质上不是 Agent 不够强，而是要素没被组织好。Agent 再强，也写不了一个把需求、架构、历史决策全丢失的项目，因为从逻辑上就不可行。

与trellis 的区别

因为评论区很多人在询问与trellis的区别，所以我特意开一下这个章节说明一下。trellis是站内桃酥大佬的作品，链接在这里： Trellis v0.5.0 beta 版本测试！

这里叠个甲！绝不拉踩！绝不贬低！保持友好！
trellis的目录结构是这样的:

.trellis/ ├── spec/ # Project standards, patterns, and guides ├── tasks/ # Task PRDs, context files, and status ├── workspace/ # Journals and developer-specific continuity ├── workflow.md # Shared workflow rules └── scripts/ # Utilities that power the workflow

CodeStable的目录结构是这样的：

├── codestable/ │ ├── requirements/ # 需求实体（"为什么要有这个能力"） │ ├── architecture/ # 架构实体（"用什么结构实现"） │ ├── roadmap/ # 路线图（"接下来打算怎么走"） │ ├── features/ # 特性流程聚合根 │ ├── issues/ # 问题流程聚合根 │ ├── refactors/ # 重构流程聚合根（beta） │ ├── compound/ # 知识沉淀（复利工程）统一目录 │ ├── tools/ # 跨工作流共享脚本（onboarding 释放） │ └── reference/ # 共享参考文档（onboarding 释放） │ ├── shared-conventions.md # 跨技能口径 / 路径命名 / 元数据规范 │ ├── system-overview.md # CodeStable 体系总览 + 场景路由 └── AGENTS.md # 在项目根，不在 codestable/ 里

在我看来，虽然没有实际使用过，但是看README，trellis 依然是偏向于 Agent 编排的框架，虽然它也有Spec，所以根本区别上还是编排的目标的区别。如果我表述上还是不容易听懂的话，大家可以理解为CodeStable把所谓的Spec打得更细一点，更符合开发实践。

还是强调一点，每个人的作品都有倾向性，都有权衡，都有适用的场景！如果各位有自己的测试集也欢迎对比一下两个框架的行为差异，欢迎批评！

设计：6 个实体 + 3 个流程

CodeStable 顺着软件编码的真实流程来设计，把软件开发活动建模成 6 个实体 和 3 个流程。

6 个实体

实体 英文 干什么
需求 requirements 原始用户故事、当时的讨论与权衡。最终的逃生通道——代码烂成一坨屎时，可以摒弃所有代码、让 AI 重新生成
架构 architecture 为实现需求，系统的编排层长什么样。文档要尽可能精简、统一，给人读的，不是给 AI 自嗨的
路线图 roadmap “我想要一个权限校验系统”——直接塞 feature AI 接不住，先拆成路线图分步推进
特性 feature 实际落地的工程执行过程，人与 AI 共同协作，对 design / 实现 / 验收负责
问题 issue 开发完成后的 BUG 单子，AI 和人一同解决
知识 compound 复利工程的知识库，沉淀踩过的坑、好做法、技术决策

3 个流程

流程 关键技能链 说明
特性引入 cs-brainstorm → cs-feat-design → cs-feat-impl → cs-feat-accept 想清楚 → 综合架构设计 → 逐步编码 → 验收测试。各位程序员怎么顺手怎么来
问题修改 cs-issue-report → cs-issue-analyze → cs-issue-fix 跟 AI 说哪里有问题 → 让 AI 分析根因 → 让 AI 定点修复
代码重构 cs-refactor (beta) 软件架构腐化不是一蹴而就的。AI 辅助重构，但终归是人在重构——还在迭代中，欢迎赐教

技能总览

分组技能用途
接入cs-onboard把 CodeStable 接入到一个新仓库 / 已有零散文档的仓库
需求 & 架构cs-req整理 / 沉淀原始需求文档
cs-arch起草或更新 codestable/architecture/ 下的架构文档
路线图cs-roadmap把模糊大目标拆成可推进的子任务序列
讨论入口cs-brainstorm想法模糊时的统一讨论入口，做分诊：直接 design / 进 feature 写 brainstorm.md / 移交 roadmap
特性流程cs-feat新特性子流程入口
cs-feat-design起草 {slug}-design.md 作为后续唯一输入
cs-feat-impl按 design 的推进顺序写代码
cs-feat-accept逐层对照 design 核对实现，做完整验收闭环
cs-feat-ff超轻量通道：不写 design、不分阶段，让 AI 直接做
问题流程cs-issue问题修复子流程入口
cs-issue-report把脑子里的问题落成可复现、可追溯的 report
cs-issue-analyze找根因、评估修复风险、给方案
cs-issue-fix定点修复 + 验证 + 写 fix-note
重构流程cs-refactor(beta) 重构主流程
cs-refactor-ff(beta) 轻量重构通道
知识沉淀cs-learn把踩过的坑 / 好做法沉淀成 learning 文档
cs-trick把可复用的编程模式 / 库用法整理成处方性参考
cs-decide把已拍板的技术选型、架构决定、长期约束记成永久文档
探索 & 文档cs-explore定向代码探索，把"提问 → 读代码 → 得结论"沉淀成证据
cs-guide / cs-libdoc对外的开发者指南 / 库参考文档

工作流示意

CodeStable 的技能不是一条线性流水，而是分层 + 事件驱动的：

═══════════════════════════════════════════════════════════════════════ 阶段 0 · 接入 （只在新项目跑一次） ─────────────────────────────────────────────────────────────────────── cs-onboard ──▶ 生成 codestable/ 骨架 + 释放 reference/、tools/ ═══════════════════════════════════════════════════════════════════════ │ ▼ ═══════════════════════════════════════════════════════════════════════ 第 1 层 · 长效档案（"系统现在长什么样"，只记现状） ─────────────────────────────────────────────────────────────────────── cs-req ──▶ codestable/requirements/{slug}.md cs-arch ──▶ codestable/architecture/ARCHITECTURE.md └─ {type}-{slug}.md（子系统） ═══════════════════════════════════════════════════════════════════════ │ ▼ ═══════════════════════════════════════════════════════════════════════ 第 2 层 · 规划（"接下来打算怎么走"，大需求才需要） ─────────────────────────────────────────────────────────────────────── cs-roadmap ──▶ codestable/roadmap/{slug}/ 把一个"我想要 X 系统"拆成多个可执行的 feature （小需求可跳过本层，直接进第 3 层） ═══════════════════════════════════════════════════════════════════════ │ ▼ ═══════════════════════════════════════════════════════════════════════ 讨论入口（可选 · 想法模糊时进入，做分诊后路由到下游） ─────────────────────────────────────────────────────────────────────── ┌── case 1 已经够清楚 ──▶ cs-feat-design cs-brainstorm ────────▶┼── case 2 小需求方向定 ─▶ feature 流（落 brainstorm.md） └── case 3 大需求只有一个词 ─▶ cs-roadmap ═══════════════════════════════════════════════════════════════════════ │ ▼ ═══════════════════════════════════════════════════════════════════════ 第 3 层 · 执行流程（按事件类型选一条进入） ─────────────────────────────────────────────────────────────────────── ▸ 事件：新增能力 ┌──────────┐ cs-feat-design ──▶ cs-feat-impl ──▶ cs-feat-accept │ features │ cs-feat-ff ──(轻量直通车，跳过 design/accept)─▶ │ /YYYY-…/ │ └──────────┘ ▸ 事件：修复缺陷 ┌──────────┐ cs-issue-report ──▶ cs-issue-analyze ──▶ cs-issue-fix│ issues │ │ /YYYY-…/ │ └──────────┘ ▸ 事件：代码腐化（beta） ┌──────────┐ cs-refactor / cs-refactor-ff │refactors │ │ /YYYY-…/ │ └──────────┘ ═══════════════════════════════════════════════════════════════════════ │ ▼ 任意阶段觉得"这个值得记下来"都能触发 ▼ ═══════════════════════════════════════════════════════════════════════ 横切层 · 知识沉淀（复利工程） ─────────────────────────────────────────────────────────────────────── cs-learn ──▶ ┐ cs-trick ──▶ ├─▶ codestable/compound/YYYY-MM-DD-{doc_type}-{slug}.md cs-decide ──▶ │ doc_type ∈ { learning, trick, decision, explore } cs-explore ──▶ ┘ ↑ 下一次 cs-arch / cs-feat-design / cs-issue-analyze 会回头读 compound/，让经验在新工作里被复用 ═══════════════════════════════════════════════════════════════════════

运行时结构

/cs-onboard 跑完后，会在你的项目根下生成一个 codestable/ 目录

你的项目/ ├── codestable/ │ ├── requirements/ # 需求实体（"为什么要有这个能力"） │ │ └── {slug}.md # 一个能力一份，扁平不分组 │ │ │ ├── architecture/ # 架构实体（"用什么结构实现"） │ │ ├── ARCHITECTURE.md # 架构总入口 / 索引 │ │ └── {type}-{slug}.md # 子系统架构 doc（同类 ≥6 份自动收进子目录） │ │ │ ├── roadmap/ # 路线图（"接下来打算怎么走"） │ │ └── {slug}/ │ │ ├── {slug}-roadmap.md # 主文档：背景 / 拆解 / 排期 │ │ ├── {slug}-items.yaml # 机器可读子 feature 清单，acceptance 回写状态 │ │ └── drafts/ # 可选：草稿 / 调研 │ │ │ ├── features/ # 特性流程聚合根 │ │ └── YYYY-MM-DD-{slug}/ # 一个 feature 一个目录 │ │ ├── {slug}-brainstorm.md # 可选（cs-brainstorm 产出） │ │ ├── {slug}-design.md # 方案（cs-feat-design） │ │ ├── {slug}-checklist.yaml # 推进清单（impl 跑、accept 回写） │ │ └── {slug}-acceptance.md # 验收报告（cs-feat-accept） │ │ │ ├── issues/ # 问题流程聚合根 │ │ └── YYYY-MM-DD-{slug}/ │ │ ├── {slug}-report.md # 问题报告 │ │ ├── {slug}-analysis.md # 根因分析（不显然时才有） │ │ └── {slug}-fix-note.md # 修复记录 │ │ │ ├── refactors/ # 重构流程聚合根（beta） │ │ └── YYYY-MM-DD-{slug}/ │ │ ├── {slug}-scan.md │ │ ├── {slug}-refactor-design.md │ │ ├── {slug}-checklist.yaml │ │ └── {slug}-apply-notes.md │ │ │ ├── compound/ # 知识沉淀（复利工程）统一目录 │ │ └── YYYY-MM-DD-{doc_type}-{slug}.md │ │ # doc_type ∈ {learning, trick, decision, explore} │ │ │ ├── tools/ # 跨工作流共享脚本（onboarding 释放） │ └── reference/ # 共享参考文档（onboarding 释放） │ ├── shared-conventions.md # 跨技能口径 / 路径命名 / 元数据规范 │ ├── system-overview.md # CodeStable 体系总览 + 场景路由 │ └── ... │ └── AGENTS.md # 在项目根，不在 codestable/ 里

设计哲学

CodeStable 与 OMO 做的是完全相反的哲学。

  • OMO 认为：人只要干预就是失败的信号
  • CodeStable 认为：程序员是软件编码中的在环对象——可以对实现层黑盒不了解，但对整体实现必须有所把控，必要时也可深入

软件架构必须要 可演进、可观测、可控制。

【安装】
npx skills add https://github.com/liuzhengdongfortest/CodeStable

【github 链接】

github.com

GitHub - liuzhengdongfortest/CodeStable

通过在 GitHub 上创建帐户来为 liuzhengdongfortest/CodeStable 开发做出贡献。

网友解答：
--【壹】--：

我也一直在思考工作流的问题。像 GitHub 上的 superpowers、openspec 等工具我都尝试过，但总感觉还差点意思。

在 AI 编程实践中，还有一个比较棘手的问题是「上下文限制」。我当前的项目体量很大、模块关系也比较复杂。通常在和 AI 反复讨论需求、一起探索代码之后，上下文就已经接近上限了。

目前我采用的工作流大致是这样：

  1. 探索阶段
    让 AI 输出阶段性整理的知识文档，比如 research.md

  2. 规划阶段（新上下文）
    基于 research.md 重新开启对话，多轮讨论后产出 plan.md

  3. 实现阶段（再次新上下文）
    结合 research.md + plan.md，再进入具体编码过程

这个流程虽然有点偏繁琐、效率不算高，但整体是可运行的。

看到大佬分享的思路后，感觉体系更完整、更有扩展性，我准备尝试一下。感谢分享。

--【贰】--：

效果看起来还可以，不过我还是openclaw,等装了爱马仕试试看效果如何！

--【叁】--：

核心难点还是给编码Agent的上下文怎么生成和管理，任务上下文，项目上下文，平台限制，设计约束等等不同维度上下文，怕信息维度丢失还怕给的多了注意力有问题。

是给编码Agent更多的自主权，还是只让编码Agent填空，如果最开始的feature生成的有问题，要不要编码Agent自主糊起来

--【肆】--：

大佬辛苦了，我也一直觉得OMO太过重了，我平时处理一个小任务，他也分析的头头是道，搞的我头大。Superpowers又总是很难派上用场，你的这个我关注关注

--【伍】--：

我个人用起来并不重。首先最重的就是走完feature全流程，文章里也说了大概会走完一圈claude的200k上下文。这是用来应对一个相对的颗粒feature的。

其次我设计了fastforward技能，能够相对快速地实现一个特性。

最低还有vibe。

其实判断权在你，如果你觉得这个需求需要归档，那你就用easysdd的体系技能，如果不需要归档和积累知识，自己vibe就行没有任何影响。

--【陆】--：

才开始下载superpowers在使用，先看看好用不，之后再来试试佬的项目

--【柒】--：

我也是有这方面的困扰，我最终选择了oh-my-opencode-slim,但是有时候要嫌弃他的轻量。。。

--【捌】--：

佬，跟bmad相比咋样？目前主要在使用superpowers，bmad还在研究中，不过bmad比superpowers要强些

--【玖】--：

openspec是真的抽象，每次看openspec生成的spec之类的都觉得很抽象。然后向佬请教下 Compoud，openspec不是也有archive命令能将本次改动添加到主的spec中吗，这个和佬的compoud有什么区别吗

--【拾】--：

问问up主重吗？最近也在找工作流，都没有适合单人开发的，现在用的superpowers，缺点就是极其耗费token，实际上很多工作我都会主动让它不要用这个技能，写一大堆文档执行慢，单人vibe开发我就想要项目掌控感，快速迭代。试了一些工作流都感觉太繁琐太复杂化

--【拾壹】--：

太强了佬，看着很符合我目前的痛点，明天品鉴一下

--【拾贰】--：

有种脑子里长知识的感觉，明天高低得学习一下，试一下了

--【拾叁】--：

看起来很不错,最近也在寻找类似的体系,但是又担心过于重了,有空的时候我尝试一下

--【拾肆】--：

oh my openAgent还是有些核心bug的，连续对话还容易出现跳回之前TODO的情况，直接忘了当前问题。有些过不了编的直接反复尝试（主要太多次了，token主要消耗在这了）

--【拾伍】--：

@CyberNova4 这个东西挺好的，佬友，看看

--【拾陆】--：

我的绝对比superpower强，这点我很确定。

--【拾柒】--：

佬友 行动力拉满，牛的，

--【拾捌】--：

brainstorm阶段其实ai就会给你几个方向了，讨论完以后方向功能上的方向基本确定。然后design就是技术上的实现的概览，一般来说我会审阅一下。这方面如果没有技术功底就根本无法控制了我实话实说。

--【拾玖】--：

Easysdd在这方面的考虑得挺多，出来技能都是原子化的，你用完一个技能以后可以开一个新窗口@交付件继续干，token消耗也不会多很多。