命令与工作流：一句话需求如何连通整套系统
4 个内置命令，覆盖从项目初始化到持续重构的完整生命周期。
全景图
人类的全部工作量：一句话
│
│ ┌──────────────────────────────────────────────────────────────────┐
│ │ Archon Protocol 命令体系 │
│ │ │
│ │ /init /demand /audit /refactor │
│ │ 初始化 一句话需求 全面审计 渐进式重构 │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ ▼ │
│ │ ┌──────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ │ 部署 │ │ 实现 │ │ Lint │ │ 分析架构 │ │
│ │ │ 文件 │ │ ↓ │ │ ↓ │ │ ↓ │ │
│ │ │ ↓ │ │ 性能审计 │ │ 测试 │ │ 识别债务 │ │
│ │ │ 配置 │ │ ↓ │ │ ↓ │ │ ↓ │ │
│ │ │ ↓ │ │ 六维自审 │ │ 规则合规 │ │ 生成方案 │ │
│ │ │ 验证 │ │ ↓ │ │ ↓ │ │ ↓ │ │
│ │ │ │ │ 修复 │ │ 边界检查 │ │ 拆分里程碑│ │
│ │ │ │ │ ↓ │ │ ↓ │ │ ↓ │ │
│ │ │ │ │ 测试同步 │ │ 报告 │ │ 写入计划 │ │
│ │ │ │ │ ↓ │ │ │ │ │ │
│ │ │ │ │ 知识进化 │ │ │ │ │ │
│ │ │ │ │ ↓ │ │ │ │ │ │
│ │ │ │ │ 提交 │ │ │ │ │ │
│ │ └──────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ ▼ │
│ │ 配置文件 代码 + 测试 审计报告 重构计划 │
│ │ + 规则 + 文档更新 + 修复建议 + 里程碑 │
│ └──────────────────────────────────────────────────────────────────┘命令 1：/init — 初始化
"把这套系统装到我的项目里。"
/init
│
├─── 检测：已安装？
│ │
│ ├── 否 ──────────────────────────────────────────────┐
│ │ │
│ │ 1. 扫描项目结构 │
│ │ ├── 检测语言（JS/TS/Python/Go/Rust） │
│ │ ├── 检测框架（Next.js/React/Vue/Django...） │
│ │ ├── 检测 i18n 库 │
│ │ ├── 检测状态管理 │
│ │ └── 检测测试框架 │
│ │ │
│ │ 2. 生成配置 │
│ │ └── archon.config.yaml（基于扫描结果填充） │
│ │ │
│ │ 3. 部署文件 │
│ │ ├── archon.config.yaml（项目配置） │
│ │ └── skills/ → .cursor/skills/ │
│ │ .claude/skills/ │
│ │ .codex/skills/ │
│ │ （所有约束和工作流） │
│ │ │
│ │ 4. 运行完整性测试 │
│ │ └── vitest run --config archon-protocol/vitest.config.js │
│ │ │
│ └─────────────────────────────────────────────────────┘
│ │
│ ├── 是（已安装）──────────────────────────────────────┐
│ │ │
│ │ 1. 验证文件完整性 │
│ │ ├── 验证所有 skill 文件存在 │
│ │ └── config 与项目实际匹配？ │
│ │ │
│ │ 2. 运行测试 │
│ │ └── 报告任何失败项 │
│ │ │
│ │ 3. 修复差异 │
│ │ └── 缺失文件 → 重新部署 │
│ │ 配置过期 → 提示更新 │
│ │ │
│ └─────────────────────────────────────────────────────┘
│
▼
产出：
📄 archon.config.yaml（项目配置）
📁 skills/ → .cursor/skills/, .claude/skills/, .codex/skills/（所有约束和工作流）
✅ 全部测试通过关键设计： /init 不是简单复制文件。它会扫描项目，自动检测技术栈并填充配置。如果项目已经安装过，它变成健康检查器——验证一切仍然完整和一致。
命令 2：/demand — 一句话需求
"加个暗色模式" — 只需要这一句，剩下全自动。
这是整个 Archon Protocol 最核心的命令。一句话需求连通了 8 个阶段的自动化流水线：
/demand "添加暗色模式切换"
│
│ ┌──────────────────────────────────────────────────────────────────────┐
│ │ │
│ │ Stage 0: 对齐重构计划 │
│ │ ────────────────── │
│ │ 检查是否存在 /refactor 产出的重构计划 │
│ │ │
│ │ 存在 → 读取计划，确认当前需求与哪个里程碑相关 │
│ │ 实现时优先采用目标架构的模式 │
│ │ 完成后更新里程碑进度 │
│ │ 不存在 → 跳过 │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 1: 实现 │
│ │ ───── │
│ │ 在约束下编写代码 │
│ │ │
│ │ 读取约束 Skills（code-quality, test-sync 等）──► 禁止项作为硬边界 │
│ │ 读取现有代码 ──► 遵循项目已有模式 │
│ │ 检查 archon.config.yaml ──► 了解技术栈上下文 │
│ │ │
│ │ 此阶段产出：✏️ 新代码 / 修改的代码 │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 2: 性能审计 │
│ │ ───────── │
│ │ 对照性能文档逐项检查 │
│ │ │
│ │ ☐ 列表渲染 <Link> 有 prefetch={false}？ │
│ │ ☐ 异步区域有骨架屏 + 错误重试 + 三态显示？ │
│ │ ☐ 无冗余请求（缓存/去重/条件跳过）？ │
│ │ ☐ 屏幕外区域用了 IntersectionObserver 懒加载？ │
│ │ │
│ │ 此阶段产出：🔍 性能问题清单 │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 3: 六维自审 ┌────────────────────┐ │
│ │ ────────── │ 调用 self-auditor │ │
│ │ │ skill │ │
│ │ 3.1 规则合规 ── 搜索 ❌ 禁止项是否被违反 │ │ │
│ │ 3.2 代码结构 ── 文件大小、职责、循环依赖 │ 返回 6 维报告 │ │
│ │ 3.3 边界条件 ── null/空/0/负数/超大值 │ │ │
│ │ 3.4 测试同步 ── 找到受影响测试 ────────────────┼─► 调用 test-runner │ │
│ │ 3.5 国际化 ── t("key")、所有语言、无 replace │ skill │ │
│ │ 3.6 知识进化 ── 发现新反模式？ └────────────────────┘ │
│ │ │
│ │ 此阶段产出：📋 审计报告 + 问题清单 │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 4: 修复 │
│ │ ───── │
│ │ 逐一修复 Stage 2 + Stage 3 发现的所有问题 │
│ │ 重新运行测试直到全部通过 │
│ │ │
│ │ 此阶段产出：✏️ 修复后的代码 │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 5: 知识进化 │
│ │ ────────── │
│ │ │
│ │ 发现新反模式？ ─── 是 ──► 写入 ❌ 禁止项到对应约束 Skill │
│ │ 发现新技术？ ──── 是 ──► 更新驱动规则或文档 │
│ │ 性能新发现？ ──── 是 ──► 更新性能文档 │
│ │ 架构决策？ ───── 是 ──► 更新架构文档 │
│ │ 无 ──────────── 跳过 │
│ │ │
│ │ 此阶段产出：📄 更新的约束 Skill / 文档（如有） │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 6: 重构进度更新（如有计划） │
│ │ ──────────────────── │
│ │ │
│ │ 读取重构计划 → 标记本次需求完成了哪些重构项 │
│ │ 更新完成百分比 │
│ │ 如果当前里程碑完成 → 标记并提示下一里程碑 │
│ │ │
│ │ 此阶段产出：📄 更新的重构计划（如有） │
│ │ │
│ ├──────────────────────────────────────────────────────────────────────┤
│ │ │
│ │ Stage 7: 提交 │
│ │ ───── │
│ │ git add (仅相关文件) → conventional commit → git status 确认 │
│ │ │
│ │ 此阶段产出：📦 git commit │
│ │ │
│ └──────────────────────────────────────────────────────────────────────┘
│
▼
最终产出：
✅ 代码：功能实现 + 所有问题已修复
✅ 测试：对应测试已更新并全部通过
✅ 性能：符合项目性能标准
✅ 文档：规则/知识已同步更新（如有新发现）
✅ 重构：进度已更新（如有计划）
✅ 提交：conventional commit 已创建/demand 的内部调用链
/demand
│
├─ 直接执行：Stage 0 (对齐), 1 (实现), 2 (性能审计)
│
├─ 调用 Skills：
│ ├── self-auditor skill ──► Stage 3.1-3.3, 3.5-3.6
│ └── test-runner skill ──► Stage 3.4
│
├─ 直接执行：Stage 4 (修复), 5 (知识进化), 6 (重构更新), 7 (提交)
│
└─ 可选调用：
└── verifier skill ──► 对最终结果做独立验证（用户可追加）快捷参数
| 指令 | 跳过的阶段 | 适用场景 |
|---|---|---|
/demand "..." quick | 性能审计、i18n、知识进化 | 紧急小修复 |
/demand "..." no-commit | 提交 | 想手动 review 后再提交 |
/demand "..." skip-tests | 测试同步 | 纯文档或配置修改 |
命令 3：/audit — 全面审计
"帮我全面检查下项目质量。"
/audit
│
├──────────────────────────────────────────────────────────────┐
│ │
│ Phase 1: 静态检查 │
│ ────────── │
│ ├── 运行 Linter (ESLint / 项目配置的 lint 工具) │
│ ├── 运行 TypeScript 类型检查（如适用） │
│ └── 汇总：N 个 error, M 个 warning │
│ │
│ Phase 2: 测试 │
│ ────── │
│ ├── 运行全部测试套件 │
│ ├── 运行 Archon Protocol 内部测试 │
│ └── 汇总：X passed, Y failed, Z skipped │
│ │
│ Phase 3: 规则合规（全项目扫描） ┌────────────────────┐ │
│ ──────────────── │ 调用 self-auditor │ │
│ ├── 收集所有 ❌ 禁止项 │ skill │ │
│ ├── 扫描全部源文件 │ │ │
│ └── 报告每个违反项 └────────────────────┘ │
│ │
│ Phase 4: 架构健康度 │
│ ──────────── │
│ ├── 文件大小超标？列出超限文件 │
│ ├── 循环依赖？ │
│ ├── 未覆盖测试的模块？ │
│ └── 过时的文档引用？ │
│ │
│ Phase 5: 报告 │
│ ────── │
│ 生成结构化审计报告 │
│ │
└──────────────────────────────────────────────────────────────┘
│
▼
产出：
📊 审计报告
┌──────────────────────────────────────────────┐
│ Lint: 12 errors, 3 warnings │
│ Tests: 145 passed, 2 failed │
│ Rules: 3 violations found │
│ File sizes: 2 files over limit │
│ Coverage: 5 modules lack tests │
│ Score: 78/100 │
│ │
│ Top priorities: │
│ 1. Fix 2 failing tests │
│ 2. Resolve 3 rule violations │
│ 3. Split oversized files │
└──────────────────────────────────────────────┘关键设计： /audit 是只读的——它不修改代码，只产出报告和优先级建议。修复由 /demand 执行。
/audit vs /self-auditor
| /audit | /self-auditor | |
|---|---|---|
| 范围 | 全项目 | 仅 git diff 中的变更 |
| 包含 | lint + 测试 + 规则 + 架构 | 仅 6 维代码审计 |
| 用途 | 定期健康检查 | 每次 /demand 内部调用 skill |
| 是否修改代码 | 否（只读） | 否（只读） |
命令 4：/refactor — 渐进式重构
"给我一个重构方案。"
这是最独特的命令——它不是一次性执行完毕，而是生成一个持久计划，影响后续每一次 /demand。
/refactor
│
├──────────────────────────────────────────────────────────────┐
│ │
│ Phase 1: 架构分析 │
│ ────────── │
│ ├── 扫描项目目录结构 │
│ ├── 分析依赖关系 │
│ ├── 识别代码气味（超大文件、循环依赖、重复代码） │
│ ├── 识别架构反模式 │
│ └── 读取现有文档了解设计意图 │
│ │
│ Phase 2: 生成重构方案 │
│ ──────────── │
│ ├── 定义目标架构（从当前架构到理想架构的路径） │
│ ├── 识别可独立重构的模块 │
│ └── 评估每个模块的复杂度和风险 │
│ │
│ Phase 3: 拆分为渐进式里程碑 │
│ ────────────────── │
│ ├── 里程碑按依赖顺序排列（先重构被依赖的底层模块） │
│ ├── 每个里程碑包含： │
│ │ ├── 目标（这个阶段要达到什么状态） │
│ │ ├── 涉及的文件/模块列表 │
│ │ ├── 具体的重构操作 │
│ │ └── 验收标准（怎么算完成） │
│ └── 里程碑之间可以正常开发（渐进式，不停工） │
│ │
│ Phase 4: 写入计划 │
│ ────── │
│ └── 保存到 docs/refactor-plan.md │
│ │
└──────────────────────────────────────────────────────────────┘
│
▼
产出：
📄 docs/refactor-plan.md
┌──────────────────────────────────────────────────────────┐
│ # 重构计划 │
│ │
│ 当前架构: [描述] │
│ 目标架构: [描述] │
│ │
│ ## Milestone 1: 基础层重构 ░░░░░░░░░░ 0% │
│ - [ ] 提取共享类型到 types/ │
│ - [ ] 统一错误处理模式 │
│ - [ ] 验收：所有 API 路由使用统一错误类 │
│ │
│ ## Milestone 2: 状态管理清理 ░░░░░░░░░░ 0% │
│ - [ ] 消除冗余 state │
│ - [ ] 统一数据获取模式 │
│ - [ ] 验收：无直接 fetch，全部走 RTK Query │
│ │
│ ## Milestone 3: 组件架构优化 ░░░░░░░░░░ 0% │
│ - [ ] 拆分超大页面组件 │
│ - [ ] 统一布局模式 │
│ - [ ] 验收：所有文件符合大小限制 │
│ │
│ 进度总览: 0/3 里程碑完成 │
└──────────────────────────────────────────────────────────┘/refactor 如何与 /demand 联动
这是最精妙的设计——重构计划一旦生成，每次 /demand 都会自动对齐：
/refactor 生成计划
│
▼
┌─────────────────────────────────────────────────────────┐
│ docs/refactor-plan.md 已存在 │
└─────────────┬───────────────────────────────────────────┘
│
│ 后续每次 /demand：
│
▼
/demand "添加用户设置页"
│
├─ Stage 0: 读取重构计划
│ ├── "用户设置页" 涉及 Milestone 2（状态管理）
│ └── 实现时采用 RTK Query 而非直接 fetch
│
├─ Stage 1-5: 正常执行...
│
└─ Stage 6: 更新重构进度
├── Milestone 2 的 "统一数据获取模式" +1 完成项
└── 更新进度条 ████░░░░░░ 40%
│
▼
/demand "重构错误处理"
│
├─ Stage 0: 读取重构计划
│ ├── 直接对应 Milestone 1
│ └── 按计划的目标模式实现
│
├─ Stage 1-5: 正常执行...
│
└─ Stage 6: 更新重构进度
├── Milestone 1 ████████░░ 80%
└── 提示："Milestone 1 还剩 2 项，建议下次完成"
│
▼
经过 N 次 /demand 后...
│
├── Milestone 1 ██████████ 100% ✅
├── Milestone 2 ████████░░ 80%
└── Milestone 3 ██░░░░░░░░ 20%关键设计：
- 渐进式 — 不需要停下来专门重构，每次正常需求都在推进重构进度
- 自动对齐 —
/demand的 Stage 0 自动读取计划，实现时采用目标架构模式 - 进度可追踪 — 每次
/demand完成后更新进度，可视化哪些里程碑完成了 - 不阻塞业务 — 即使重构未完成，新功能照样能做，只是会尽量遵循目标架构
四个命令的协作关系
┌──────────┐
│ /init │
│ (一次性) │
└────┬─────┘
│ 安装 Archon Protocol
▼
┌──────────────────────────────────────┐
│ Archon Protocol 已就绪 │
└──────┬────────────┬──────────────────┘
│ │
▼ ▼
┌──────────┐ ┌───────────┐
│ /refactor │ │ /audit │
│ (可选) │ │ (定期) │
└─────┬────┘ └─────┬─────┘
│ │
│ 生成计划 │ 发现问题
│ │
▼ ▼
┌──────────────────────────────────────┐
│ docs/refactor-plan.md │
│ 审计报告中的待修复项 │
└──────────────┬───────────────────────┘
│
│ 输入
▼
┌──────────────┐
│ │
┌────►│ /demand │◄────┐
│ │ (日常) │ │
│ └──────┬───────┘ │
│ │ │
│ ▼ │
│ 实现 + 审计 + 修复 │
│ + 知识进化 │
│ + 重构进度更新 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 约束 Skill 更新 │ │
│ │ 文档更新 │ │
│ │ 重构进度更新 │ │
│ └──────┬───────┘ │
│ │ │
└────────────┘ │
下一条需求 │
(约束更强) 定期回到 /audit
检查整体健康度循环的本质：
/init是入口——装一次/refactor是方向——定义目标架构/demand是引擎——每次迭代都在接近目标，同时自我进化/audit是体检——定期确认没有偏离轨道
从人类视角看
Day 1: /init → Archon Protocol 就绪
Day 1: /refactor → 有了重构路线图
Day 2: /demand "加用户设置页" → 功能完成 + 推进重构 + 学到新规则
Day 3: /demand "修复登录 bug" → Bug 修复 + 测试同步 + 规则体系更强
Day 5: /audit → 全面体检，发现 3 个遗漏
Day 5: /demand "修复审计发现的问题" → 问题修复 + 重构进度 +30%
Day 10: /demand "加支付功能" → 新功能 + 重构进度 +15%
Day 20: /audit → 体检通过，重构 85% 完成
Day 25: /demand "完成剩余重构" → 重构 100% ✅
──────────────────────────────────
结果：25 天内，人类只打了 ~10 条指令
Archon Protocol 自动完成了：
- 全部功能开发
- 全部测试
- 全部性能优化
- 渐进式架构重构
- 规则体系从 0 进化到完善