- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
缘由
我在开发一套新的 Harness Agent，源码在这 GitHub - liuzhengdongfortest/MA · GitHub 一开始当然是 VibeCoding，我只写我的设计，代码和问题都由 AI 来修改，这样一开始是非常 OK 的，也支撑我开发除了大部分的特性。直到有一天 Codex 反复解决不了一个我认为比较简单的问题，以及反复在同一个地方掉链子。我就知道项目需要一套工作流来维持它继续进行了。
我调研了 OpenSpec、SuperPowers、Oh-My-OpenAgent 这一类的工具。答案就是它们没有一个用着我觉得顺手的，原因很简单。OpenSpec 太简单了，没有 Compound 工程，而且生成的 Spec 很抽象，人类根本没法读。SuperPowers 没有流程来约束，我不知道该用哪个。Oh-My-OpenAgent 也太重。
所以我自己写了一套 EasySDD 体系。主要分为三大块：【Feature 工作流】 、【issue 工作流】以及【辅助工作流】。
Feature 工作流
Feature 工作流很常规：brainstorm → design → implement → acceptance
相信大家一看就知道了。头脑风暴、设计、实现、验收。这些大家如果自己 vibe 过或者用过其他框架应该很熟悉。
Issue 工作流
Issue 工作流参考了站内大佬的一些思路：report → analyze → fix，分别是汇报 bug、分析 bug、解决 bug。
那么 EasySDD 相比其他框架有什么特殊的？
EasySDD 有很多特殊的地方，让我一一道来。EasySDD 我认为最值得称道的是它的【辅助工作流】。首先可以看它的目录结构。
Architecture
系统架构所在地，这里就是整个系统架构的文档所在之处。在你实现完一个 feature 以后，的 acceptance 中，会自动将你的 feature 合并进架构文档里。
术语归一
这个说起来很复杂，简单来说就是把术语统一一下，确保人表述和 AI 理解的，AI 表述的和人理解的是一致的，这个大家用到的时候自己体会一下就知道了。
Compoud
这是 EasySDD 的重中之重，其中设计了大量的技能来归纳 compound，也就是所谓的复利工程，说白了就是积累知识，例如
easysdd-learning：从项目中学到什么
Easysdd-tricks：一些技巧
Easysdd-decisions：项目的决定
Easysdd-explore：项目探索。
那么归档以后如何召回呢？EasySDD 只在需要它的时候召回，例如在 easysdd-feature-design 中就显式地搜索了 compound 目录，easysdd-issue-analysis 也会显式地去查找。
这样整个系统就处于一种自洽状态，在 feature 和 issue 的过程中，积累知识会反哺到设计里，到最后越来越顺。
工作清单
跟 plan 不同，我在 design 以后会让模型生成一个 checklist 的 yaml 文件，实测起来遵从率居然比单纯的 markdown 和 csv 要高一些，我也不知道为啥。
Onboarding 技能
我专门做了一个上船技能，什么意思呢？就是帮你搭建 easysdd 的项目结构，一键启用。
Libdoc 和 guidedoc 技能
这两个技能都是我在写文档的时候会用到的，一个是维护库的 api 文档，一个是用来给用户和开发者写指南的技能，自用起来相当不错。
更多细节
总之，我认为 EasySDD 在逻辑上或者说工作流上已经达成了一种自洽的状态，细节很多，更多内容可以去项目里看，其实都是一系列的 SKILL 文件。
模型适配
由于我是在家和公司都用 EasySDD，所以我自己体感的是 Claude 模型和 glm 4.7 都适配，但是 Claude 可以一次性完成一个大颗粒的 feature，glm 4.7 只能小颗粒，而且每次 design 都得我去把一下关… 这个模型能力问题我真没办法。
设计上的权衡
有人会问，那 worktree，code-review 或者子代理开发这些技能呢？
这里就是设计上的权衡了，小到 openspec，大到 oh-my-openagent。它们都有各自的权衡。我并不想做一个大而全的框架，反而是够用就行，能帮我持续推进项目，让项目持续受控，让我感到安心就 OK。没有哪些复杂的 Subagent 和 hook 来污染你的 Claude 或者 Codex。
一些EasySDD 实际的例子
自动积累知识
在 feature 工作流的 acceptance 收尾阶段会自动积累相应的知识，同时会更新 architecture 的文档。
积累的关于 tauri 编译问题的知识
解决的 feature 和issue 文档显性化
有些时候需要往回翻阅当时解决了哪些 issue，所以我把 feature 和 issue 也留了一份存档。
最后
希望大家也不要全依赖 EasySDD，框架虽好也不能解决所有情况。像我只有觉得特性复杂度足够高的时候才会走 EasySDD的流程, 因为你既然约束了 AI 去按照流程办事，还是会多耗费一些 token 的。比如说一般我的一个 feature 需要 Claude Code 的 Opus 走完一个 200 k 的上下文才能完成。所以一般简单的 UI 调整呀我都是直接截图 vibe 就行了。
【安装】
npx skills add https://github.com/liuzhengdongfortest/easysdd
【github 链接】
github.com
GitHub - liuzhengdongfortest/EasySDD
通过在 GitHub 上创建帐户来为 liuzhengdongfortest/EasySDD 开发做出贡献。
16 个帖子 - 13 位参与者