# SpecDo：本地优先的AI开发工作流整合方案

> SpecDo是一个将SuperSpec执行核心、AGENTS角色配置、SKILLS技能方法和CodeGraph代码理解工具整合到同一仓库的本地优先AI开发工作流方案，解决AI开发中能力散落、难以复用和维护的问题。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-24T03:44:45.000Z
- 最近活动: 2026-05-24T03:49:10.925Z
- 热度: 159.9
- 关键词: AI开发, 工作流, SuperSpec, Agent, Skill, 本地优先, 代码理解, 多智能体协作
- 页面链接: https://www.zingnex.cn/forum/thread/specdo-ai
- Canonical: https://www.zingnex.cn/forum/thread/specdo-ai
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**：MoonCoder-HAPPY
- **来源平台**：GitHub
- **原始标题**：SpecDo
- **原始链接**：https://github.com/MoonCoder-HAPPY/SpecDo
- **发布时间**：2026年5月24日

## 背景：AI开发工作流的碎片化困境

当前AI辅助开发工具层出不穷，但开发者普遍面临一个尴尬局面：spec工具是一套、agent配置是一套、skill方法是一套、代码理解工具又是另一套。当需要把这些能力整合到实际项目中时，往往发现自己能用但别人接不住，当下能跑但长期难以维护。

这种碎片化不仅增加了学习成本，更让团队协作变得困难。仓库里明明有能力，却没有清楚的接入路径；配置散落在各处，缺乏统一的目录和入口。

## SpecDo的解决思路

SpecDo并非要再造一个平台，而是把执行核心、角色配置、技能方法和代码理解工具的独立说明整理到同一个仓库里。通过四层分工的清晰界定，让这套东西更容易被复用、审查和持续维护。

### 四层能力架构

SpecDo的核心架构由四个相互独立又协同工作的层次组成：

**1. SuperSpec：执行核心与主流程**

SuperSpec是整个工作流的引擎，基于OpenSpec整理而来，负责用spec驱动需求收敛、生成change工作目录、基于tasks.md推进执行，并支持verify、sync、archive等收尾动作。它是当前仓库里唯一需要正式构建的程序，暴露openspec CLI供开发者调用。

**2. AGENTS：角色分工与多智能体协作**

AGENTS目录是可复用的agent角色库，决定了"谁来做"。开发者可以把前端任务交给前端agent，把评审任务交给reviewer，把调试任务交给debugger。这种角色分工让AI协作更加有序，不同任务可以匹配最合适的执行者。

**3. SKILLS：执行方法与质量约束**

SKILLS目录是可复用的技能库，决定了"怎么做得更稳"。它为开发、调试、测试、评审、发版等动作提供默认约束，例如用test-driven-development控制实现节奏，用systematic-debugging约束排查过程，用release-management管发版收尾。

**4. CodeGraph：代码理解能力**

CodeGraph负责另一层独立能力：先给代码仓库建立索引，再按符号、文件、上下文、影响范围去理解项目，让AI不用每次都从头扫文件。它解决的是代码理解层面的问题，与主流程、角色、方法形成互补。

## 仓库结构与快速上手

SpecDo的仓库结构清晰地反映了四层架构：

```
SpecDo/
├── CodeGraph/   # CodeGraph独立使用说明
├── SuperSpec/   # 执行核心与CLI
├── AGENTS/      # agent配置与角色目录
├── AGENTS.md    # 仓库级协作契约
├── SKILLS/      # skill方法论目录
├── LICENSE
└── README.md
```

### 最小闭环验证

要验证SpecDo是否适合自己的工作流，可以按以下步骤快速上手：

首先构建SuperSpec：

```bash
cd SuperSpec
pnpm install
pnpm run build
npm link
openspec --help
```

然后在测试项目初始化：

```bash
openspec init
openspec update
```

如果openspec --help能正常输出，且测试项目中生成了openspec/相关结构，说明主流程已经接通。接下来可以查看AGENTS/和SKILLS/目录，挑选适合自己项目的角色和方法。

## 适用场景与边界

SpecDo适合以下场景：

- 需要一套仓库级工作流，而非单个命令行工具
- 愿意在仓库里维护AGENTS/和SKILLS/这类本地目录
- AI编程工具支持或至少能够兼容repo-local agents/skills这类接入方式
- 接受"本地优先整合"而非"一键托管平台"的理念

但SpecDo也有明确的边界：它不保证所有AI工具都能直接识别AGENTS/或SKILLS/，不负责托管远程服务或做平台级集成，也不承诺所有目录都必须一键接入。AGENTS/和SKILLS/更偏本地可审计素材，而非统一远程市场。

## 实际工作流示例

假设要实现"增加暗色模式"的需求，SpecDo的工作流如下：

1. 用openspec在业务项目里创建和推进change
2. 在tasks.md里写清任务目标、验证方式和review focus
3. 把实现任务交给前端或全栈agent
4. 在实现前后套用test-driven-development、webapp-testing、code-reviewer等skill
5. 最后用verify、sync、archive收尾

这个流程体现了SpecDo的核心思路：主流程由SuperSpec驱动，角色协作由AGENTS补齐，执行质量由SKILLS约束，代码理解由CodeGraph支撑。

## 安全与维护原则

使用SpecDo时应遵守以下原则：

- 不提交密钥、令牌、私有配置
- 不默认信任新增第三方skill或agent
- 先在低风险项目中验证，再带入正式环境
- 保持目录清洁，不把缓存、日志、临时产物提交进来

贡献代码时建议按层处理：改SuperSpec表示改执行核心，改AGENTS表示改角色资产，改SKILLS表示改方法资产。尽量不要把三个层次的问题混进同一次改动里。

## 总结

SpecDo的价值在于把散落在各处的AI开发能力整合到一套可交付的结构中。它不是要取代现有工具，而是提供一个统一的组织框架，让spec驱动、角色分工、技能约束和代码理解能够协同工作。对于希望建立可复用、可审查、可持续维护的AI开发工作流的团队来说，SpecDo提供了一个值得参考的整合方案。