AI 编程工作流深度解析

软件工程师
AI编程
Author

jdragon

Published

March 12, 2026

AI 编程工作流深度解析：从 Vibe Coding 到规范驱动的演进之路

前言

AI 编程正在经历一场范式转移——从「凭感觉写」的 Vibe Coding，走向规范驱动开发（SDD）。本文基于多篇一线实践文章，深度解析当前最主流的 AI 编程工作流、工具和方法论，帮助你构建高效、可控、可规模化的 AI 编程体系。

一、核心问题：为什么需要工作流？

1.1 未被驯服的 AI 编程现状

大部分人使用 AI 编程工具的流程是这样的：

打 prompt → 等 AI 吐代码 → 看一眼不太对 → 改 prompt → 再等 → 再看
→ 循环几轮，代码勉强能跑
→ 但说不清它为什么这么写，也不确定改了会不会炸

这种模式的核心问题：

问题 症状 后果
上下文污染 话题飘到七八个方向 AI 忘记早期指令，开始出错
缺乏规划 AI 直接开写，15 分钟后发现解决的是另一个问题 大量返工
无验证标准 你成了唯一的质检员 每个错误都得你来抓
知识不沉淀 同样的错误反复犯 团队效率无法提升
变更失控 AI 乱改代码，改一处错一片 线上问题频发

1.2 工作流的核心价值

一句话总结：把思考和打字分开。

  • Research 防止 AI 在不理解的情况下乱改
  • Plan 防止它做错误的修改
  • Annotate 注入你的判断和领域知识
  • Implement 让执行变成机械性的、可预测的

二、工作流共性提炼：核心原则与统一思路

在深入各种具体工作流之前，我们先提炼它们的共性。无论是 Boris Tane 的 Claude Code 工作流、Superpowers 技能体系，还是 OpenSpec 规范框架，背后都遵循一套统一的核心原则。

2.1 统一工作流模型

所有主流工作流都可以映射到以下五个阶段：

┌─────────────┐
│  1. 理解    │  让 AI 读懂代码和上下文
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  2. 规划    │  制定书面计划，人类审核
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  3. 迭代    │  批注 - 修改循环，注入人类判断
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  4. 执行    │  按计划机械性实现，持续验证
└──────┬──────┘
       │
       ▼
┌─────────────┐
│  5. 验证    │  证据驱动，完成前必须验证
└─────────────┘

不同工作流只是在这五个阶段上做了不同的封装和自动化。

2.2 六大核心原则

原则一：规划优先（Plan Before Code）

核心思想： 永远不要让 AI 写代码，直到你审核并批准了一份书面计划。

为什么有效：

  • 规划阶段的 token 成本远低于返工成本
  • 书面计划是人类和 AI 之间的「共享可变状态」
  • 计划文档持久存在，可审查、可批注、可追溯

反模式：

  • ❌ 直接进入实现模式
  • ❌ 在聊天里口头描述计划
  • ❌ 没有书面产出物就开始编码

原则二：证据驱动（Evidence Before Assertion）

核心思想： 任何声称工作完成之前，必须独立运行验证命令并展示证据。

为什么有效：

  • 防止「应该能工作」「看起来正确」等模糊断言
  • 强制 AI 自我验证，减少人工质检负担
  • 形成可追溯的验证记录

反模式：

  • ❌ 「测试应该通过了」
  • ❌ 「代码看起来没问题」
  • ❌ 不运行验证就声称完成

原则三：上下文管理（Context Is Expensive）

核心思想： 上下文窗口是你最贵的资源，必须高效使用。

为什么有效：

  • 上下文越满，AI 表现越差
  • 子智能体隔离调查，保持主对话干净
  • 定期清理污染，保持会话聚焦

反模式：

  • ❌ 一个 session 聊五个话题
  • ❌ 调查类任务占用主上下文
  • ❌ 同一个错误纠正三次以上不重置

原则四：批注优于聊天（Annotation Over Chat）

核心思想： 在计划文档里直接批注，而不是在聊天里解释。

为什么有效：

  • 批注位置精确，AI 不会误解
  • 计划文档是一份结构化的、完整的规格说明，可以整体审查
  • 聊天记录需要翻来找去才能重建决策

反模式：

  • ❌ 在聊天消息里逐条解释修改
  • ❌ 没有批注就直接说「开始写吧」
  • ❌ 批注循环少于 1 次就进入实现

原则五：技能化消灭重复（Skill The Repetition）

核心思想： 一天做了两次的事，就变成一个 skill。

为什么有效：

  • 消灭重复劳动，减少上下文切换
  • 团队知识沉淀为可复用资产
  • 一个命令完成复杂工作流

反模式：

  • ❌ 每次都手动输入相同的长 prompt
  • ❌ 同样的流程反复解释
  • ❌ 团队知识停留在聊天记录里

原则六：并行是效率杠杆（Parallelism Is Leverage）

核心思想： 能并行的任务全部并行，同时跑 3-5 个 session。

为什么有效：

  • 独立任务并行显著节省时间
  • 一个 session 写，一个 session 审，质量更高
  • 子智能体并行调查，主会话不受影响

反模式：

  • ❌ 所有任务顺序执行
  • ❌ 调查任务占用主会话上下文
  • ❌ 没有代码审查就合并

2.3 工作流成熟度模型

根据团队和项目特点，可以选择不同成熟度的工作流：

Level 1: 基础规范
├── 书面计划（plan.md）
├── 批注循环（至少 1 次）
└── 完成前验证

Level 2: 工程化
├── Research 文档（research.md）
├── Todo List 追踪
├── CLAUDE.md 规则沉淀
└── 子智能体隔离

Level 3: 自动化
├── 自定义 Skills
├── 并行 Session
├── 自动代码审查
└── CI/CD 集成

Level 4: 规范驱动
├── Spec-Kit 全流程
├── OpenSpec 变更管理
├── Superpowers TDD
└── 增量规范归档

建议： 从 Level 1 开始，跑通三遍后再升级。不要一开始就上 Level 4。

2.4 人类与 AI 的分工

工作流的核心是重新定义人类和 AI 的分工：

阶段 人类角色 AI 角色
理解 指定范围、审查研究结果 深读代码、撰写研究报告
规划 批注、否决、添加约束 提出方案、写计划文档
迭代 注入领域知识、做判断 理解批注、更新计划
执行 监工、简短纠正 机械性实现、持续验证
验证 审查证据、批准完成 运行验证、展示输出

关键洞察： 创造性的工作发生在批注循环里，实现阶段应该是无聊的。

三、典型工作流模型详解

3.1 Boris Tane 工作流（Claude Code 之父）

背景与起源

Boris Tane 是 Cloudflare 工程负责人，也是 Claude Code 的早期核心用户。他用 Claude Code 做主力开发工具 9 个月，在真实生产项目中打磨出这套工作流。

这套工作流的最大特点是经过长时间实战验证，不是理论设计，而是从数千小时的实际开发中提炼出来的。Boris 在个人博客公开发布后，被大量开发者采用并验证有效。

适用场景： - 中大型功能开发 - 复杂系统修改 - 需要人类深度参与架构决策的场景

核心理念： 把规划和执行分开，防止浪费精力，让你始终掌控架构决策，并且用更少的 token 产出明显更好的结果。

完整流程

Research → Plan → Annotate（循环 1-6 次）→ Todo List → Implement → Feedback & Iterate

第一步：Research — 让 AI 先读懂代码

核心原则： 每次开始一个有意义的任务，第一件事不是让 AI 写代码，而是让它深读相关代码，而且必须把研究结果写进一个持久化的 markdown 文件里。

推荐 Prompt：

read this folder in depth, understand how it works deeply, what it does and 
all its specificities. when that's done, write a detailed report of your 
learnings and findings in research.md

关键词： “deeply”、“in great details”、“intricacies”、“go through everything”

为什么要写成文件？ research.md 是你的审查面。你可以打开它，验证 AI 是不是真的理解了系统，在任何规划发生之前纠正误解。如果研究阶段就错了，后面的计划会错，实现会更错——Garbage in, garbage out。

这一步防的是 AI 编程中最昂贵的失败模式——不是语法错误，不是逻辑 bug，而是写出来的代码在隔离环境下能跑，但放进真实系统就炸。一个忽略了现有缓存层的函数，一个没考虑 ORM 约定的数据库迁移，一个重复造轮子的 API 端点。Research 阶段就是为了防这些。

第二步：Plan — 让 AI 出计划，不是出代码

Research 审核通过后，让 AI 写一份详细的实现计划，输出到单独的 plan.md 文件：

推荐 Prompt：

I want to build a new feature <name and description> that extends the system 
to perform <business outcome>. write a detailed plan.md document outlining 
how to implement this. include code snippets.

计划文档应包含： - 方法的详细说明 - 展示实际修改的代码片段 - 要修改的文件路径 - 权衡和注意事项

为什么不用工具自带的 plan mode？ 内置的 plan mode 很烂。自己的 markdown 文件给你完全的控制权——你可以在编辑器里打开它、加批注、它作为一个真实的文件留在项目里持久存在。

一个技巧： 如果你在开源项目里见过类似功能的好实现，把那段代码贴给 AI 当参考。AI 有具体参考实现时，表现会好得多——比让它从零设计强太多。

第三步：Annotate — 整个工作流最值钱的环节

这是 Boris 工作流里最独特的部分，也是人类价值最大的地方。

拿到 plan.md 后，你不是直接说”开始写吧”，而是在编辑器里打开这个文件，直接在文档里加批注。这些批注用来纠正假设、否决方案、添加约束、或者提供 AI 不具备的领域知识。

真实批注示例： - "use drizzle:generate for migrations, not raw SQL" — AI 不知道的领域知识 - "no — this should be a PATCH, not a PUT" — 纠正错误假设 - "remove this section entirely, we don't need caching here" — 否决一个提议的方案 - "the queue consumer already handles retries, so this retry logic is redundant. remove it and just let it fail" — 解释为什么某个东西应该改

然后把带批注的文件交回给 AI：

I added a few notes to the document, address all the notes and update the 
document accordingly. don't implement yet.

这个循环通常重复 1 到 6 次。 那句”don’t implement yet”的护栏至关重要，没有它，AI 一觉得计划差不多了就会跳去写代码。但”差不多”不够——什么时候够好，你说了算。

为什么这招这么好用：

plan.md 文件充当了你和 AI 之间的共享可变状态。你可以按自己的节奏思考，精确地在出问题的地方加批注，然后重新开始对话而不丢失上下文。你不是在聊天消息里试图解释所有事情——你是指着文档里的确切位置，把你的修正写在那里。

这和试图通过聊天消息来引导实现有本质区别。计划是一份结构化的、完整的规格说明，你可以整体审查。聊天记录是你得翻来翻去才能重建决策的东西，计划每次都赢。

三轮”我加了批注，更新计划”就能把一份通用的实现计划变成一份完美契合现有系统的方案。AI 擅长理解代码、提出方案、写实现，但它不知道你的产品优先级、用户痛点、或者你愿意做的工程权衡。批注循环就是你注入这些判断的过程。

第四步：生成 Todo List

在开始实现之前，要求生成一份细粒度的任务分解：

add a detailed todo list to the plan, with all the phases and individual 
tasks necessary to complete the plan - don't implement yet.

这会创建一份清单，在实现过程中充当进度追踪器。AI 完成一项就标记一项，你随时可以扫一眼计划，看到进度到哪了。

第五步：Implement — 计划确认后才写代码

当计划准备好了，发出实现指令：

implement it all. when you're done with a task or phase, mark it as completed 
in the plan document. do not stop until all tasks and phases are completed. 
do not add unnecessary comments or jsdocs, do not use any or unknown types. 
continuously run typecheck to make sure you're not introducing new issues.

这一条 prompt 编码了所有重要的事： - "implement it all"：执行计划里的所有内容，不要挑着做 - "mark it as completed in the plan document"：计划是进度的唯一真相来源 - "do not stop until all tasks and phases are completed"：不要在中途暂停等确认 - "do not add unnecessary comments or jsdocs"：保持代码干净 - "do not use any or unknown types"：维持严格类型 - "continuously run typecheck"：尽早发现问题，不要等到最后

实现变成了机械性的，而不是创造性的 ——这是刻意的。我们希望实现阶段是无聊的，创造性的工作发生在批注循环里。一旦计划对了，执行应该是直截了当的。

实现过程中的反馈

一旦 AI 开始执行计划，你的角色从架构师变成了监工，你的 prompt 会变得极短。

规划阶段的批注可能是一整段话，但实现阶段的纠正往往只有一句话： - "You didn't implement the deduplicateByTitle function." - "You built the settings page in the main app when it should be in the admin app, move it."

AI 有计划的完整上下文和整个会话的记忆，所以简短的纠正就够了。

前端工作是最需要反复迭代的部分，在浏览器里测试，然后快速发出纠正： - "wider" - "still cropped" - "there's a 2px gap"

视觉问题有时候直接贴截图，一张表格没对齐的截图比文字描述快得多。

保持控制权

即使把执行委托给了 AI，也从不给它完全的自主权。绝大部分的主动引导在 plan.md 文档里完成。

几个具体的引导方式：

从提议中挑选： 当 AI 识别出多个问题时，逐个过：「第一个，直接用 Promise.all，不要搞得太复杂；第三个，提取成单独的函数提高可读性；第四个和第五个忽略，不值得增加复杂度。」你在根据自己对当前优先级的了解做逐项决策。

砍范围： 当计划包含锦上添花的内容时，主动砍掉。「从计划里删掉下载功能，我现在不想实现这个。」防止范围蔓延。

保护现有接口： 当你知道某些东西不应该变时，设硬约束：「这三个函数的签名不能变，调用方去适配，不是库去改。」

覆盖技术选择： 有时候你有 AI 不知道的特定偏好：「用这个模型而不是那个」或者「用这个库的内置方法，不要自己写一个」。快速、直接的覆盖。

AI 处理机械性的执行，你做判断性的决策。 计划在前期捕获大决策，选择性的引导处理实现过程中冒出来的小决策。

3.2 Superpowers 五阶段开发模型

背景与起源

Superpowers 是由 Vercel Labs 维护的一套 AI Agent 技能体系，包含 12 个协同工作的技能。该技能集在 GitHub 上累计安装量超过 200K，展现了其在开发者社区中的广泛认可度。

与 Boris 工作流不同，Superpowers 是结构化、可安装的技能集合。它将最佳实践封装成可复用的技能，AI 助手可以按需加载。这种设计使得工作流可以跨项目、跨团队复用。

适用场景：

  • 需要严格 TDD 的高可靠场景
  • 团队协作需要统一工作流
  • 希望将最佳实践固化为技能

核心理念： 为 AI 编程助手提供了一套经过验证的开发方法论，理解并正确使用这些技能的配套关系，能显著提升开发效率、代码质量和团队协作效率。

技能总览与职责划分

技能 安装量 核心职责
brainstorming 34.4K 需求分析、设计探索
writing-plans 17.0K 任务规划、计划编写
test-driven-development 15.4K 测试驱动开发
executing-plans 14.4K 执行已完成的计划
requesting-code-review 13.7K 代码审查请求
using-superpowers 12.9K 技能查找与加载
subagent-driven-development 11.6K 子代理驱动的开发执行
receiving-code-review 11.0K 代码审查反馈处理
verification-before-completion 11.0K 完成前验证
using-git-worktrees 10.6K Git 工作树隔离
writing-skills 10.6K 技能编写与测试
dispatching-parallel-agents 10.0K 并行子代理调度

完整工作流

第一阶段：需求与设计（Brainstorming）
    ↓
第二阶段：任务规划（Planning）
    ↓
第三阶段：环境准备（Isolation）
    ↓
第四阶段：执行与实现（Implementation）
    ↓
第五阶段：审查与反馈（Review）

第一阶段：需求与设计（Brainstorming）

强制执行流程：

  1. 探索项目上下文 — 检查现有文件、文档、最近的提交记录
  2. 提出澄清问题 — 逐个提问，理解目的、约束、成功标准
  3. 提出 2-3 种方案 — 附带权衡分析和建议方案
  4. 展示设计 — 按复杂度分节展示，获取用户逐节确认
  5. 编写设计文档 — 保存至 docs/plans/YYYY-MM-DD-<topic>-design.md
  6. 过渡到实现阶段 — 调用 writing-plans 技能创建实施计划

关键原则： 「一次只问一个问题」，优先使用选择题而非开放式问题。

第二阶段：任务规划（Planning）

核心功能：

  • 读取设计文档
  • 提取所有可执行任务
  • 为每个任务附加完整上下文
  • 创建结构化的任务列表

输出结果是一个包含多个独立任务项的实施计划，每个任务项都有明确的交付标准和上下文信息。

第三阶段：环境准备（Isolation）

使用技能： using-git-worktrees

在任何实现工作开始之前，必须先创建隔离的工作环境。核心原则是：「系统化的目录选择 + 安全验证 = 可靠的隔离」。

完整执行流程：

  1. 检测现有目录 — 按优先级检查 .worktrees 或 worktrees
  2. 检查 CLAUDE.md — 如有明确偏好则直接使用
  3. 询问用户 — 如无预设则让用户选择
  4. 安全验证 — 确保目录已被 gitignore 忽略
  5. 创建工作树 — 使用新分支创建 worktree
  6. 运行项目初始化 — 自动检测并运行 npm install、cargo build 等
  7. 验证基线 — 运行测试确保环境干净

第四阶段：执行与实现（Implementation）

使用技能组合： subagent-driven-development / executing-plans + test-driven-development + verification-before-completion

子代理驱动开发（推荐）：

每个任务经历两阶段审查：

  1. 调度实现子代理
  2. 实现子代理实现、测试、提交、自我审查
  3. 调度规范合规审查 — 确认代码实现了设计要求且没有添加额外功能
  4. 调度代码质量审查 — 确保代码符合质量标准
  5. 标记任务完成

测试驱动开发（TDD）：

强制执行 RED-GREEN-REFACTOR 循环：

  • RED — 编写失败的测试
  • GREEN — 编写最简代码使测试通过
  • REFACTOR — 重构优化代码

核心铁律： 「没有先写失败测试的生产代码」。如果代码先于测试编写，必须删除并重新开始。

完成前验证：

执行流程：

  1. 识别 — 确定什么命令能证明该断言
  2. 运行 — 执行完整命令（全新、完整）
  3. 读取 — 完整输出，检查退出码，统计失败数
  4. 验证 — 输出是否确认了断言？
  5. 然后 — 做出断言

禁止使用「应该能工作」「看起来正确」「之前通过了」等模糊表述。必须展示实际的命令输出作为证据。

第五阶段：审查与反馈（Review）

使用技能组合： requesting-code-review + receiving-code-review

必须请求审查的时机：

  • subagent-driven-development 中每个任务完成后
  • 完成主要功能后
  • 合并到主分支前

处理审查反馈：

  1. 阅读 — 完整阅读反馈，不立即反应
  2. 理解 — 用自己的话复述需求（或提问）
  3. 验证 — 对照代码库实际状况检查
  4. 评估 — 对当前代码库在技术上是否合理？
  5. 响应 — 技术性确认或有理有据地反对
  6. 实现 — 逐项实现，每项测试

3.3 OpenSpec 轻量级规范框架

背景与起源

OpenSpec 是由 Fission AI 开发的轻量级规范框架，专为 AI 编码助手设计。与 Spec-Kit 和 Superpowers 不同，OpenSpec 的核心理念是灵活而非僵化，适合已有项目的快速迭代。

适用场景：

  • 存量项目快速迭代
  • 需求频繁变更的场景
  • 需要轻量级变更管理

核心理念：

  • 灵活而非僵化 — 无需阶段门限，按需工作
  • 迭代而非瀑布 — 边做边学，持续改进
  • 简单而非复杂 — 轻量设置，最小仪式感
  • 存量优先 — 支持现有代码库，不只是全新项目

工作流程概览

     ┌────────────────┐
     │  1. 开始变更   │  /opsx:propose 或 /opsx:new
     └───────┬────────┘
             │
             ▼
     ┌────────────────┐
     │  2. 创建产出物 │  proposal → specs → design → tasks
     └───────┬────────┘
             │
             ▼
     ┌────────────────┐
     │  3. 实现任务   │  /opsx:apply
     └───────┬────────┘
             │
             ▼
     ┌────────────────┐
     │  4. 验证工作    │  /opsx:verify
     └───────┬────────┘
             │
             ▼
     ┌────────────────┐
     │  5. 归档变更   │  增量规范合并到主规范
     └────────────────┘

核心概念

1. 规范（Specs）

规范描述系统行为，使用结构化的需求和场景：

# Auth Specification

## Purpose
Authentication and session management for the application.

## Requirements

### Requirement: User Authentication
The system SHALL issue a JWT token upon successful login.

#### Scenario: Valid credentials
- GIVEN a user with valid credentials
- WHEN the user submits login form
- THEN a JWT token is returned
- AND the user is redirected to dashboard

按领域组织规范——对你的系统有意义的逻辑分组。常见模式：

  • 按功能区域：auth/、payments/、search/
  • 按组件：api/、frontend/、workers/
  • 按边界上下文：ordering/、fulfillment/、inventory/

2. 变更（Changes）

变更是对系统提议的修改，封装在一个文件夹中：

openspec/changes/add-dark-mode/
├── proposal.md           # 为什么以及是什么
├── design.md             # 如何做（技术方案）
├── tasks.md              # 实现清单
└── specs/                # 增量规范（改变了什么）
    └── ui/
        └── spec.md

3. 增量规范（Delta Specs）

增量规范描述相对于当前规范的变化，包含三个部分：

部分 含义 归档时发生什么
## ADDED Requirements 新行为 追加到主规范
## MODIFIED Requirements 更改的行为 替换现有需求
## REMOVED Requirements 弃用的行为 从主规范中删除

为什么用增量而非完整规范：

  • 清晰 — 增量准确显示变化内容
  • 避免冲突 — 两个变更可以修改同一规范文件的不同需求
  • 审查效率 — 审查者只看变化
  • 适配存量 — 大多数工作是修改现有行为

两种工作流模式

核心模式（core，默认）：

  • /opsx:propose
  • /opsx:apply
  • /opsx:archive

典型流程：/opsx:propose → /opsx:apply → /opsx:archive

扩展模式（custom）：

  • /opsx:new
  • /opsx:continue
  • /opsx:ff
  • /opsx:verify
  • /opsx:sync
  • /opsx:bulk-archive

典型流程：/opsx:new → /opsx:ff → /opsx:apply → /opsx:verify → /opsx:archive

3.4 OpenCode 实战工作流

背景与起源

OpenCode 是一个开源的 AI 编程 Agent，GitHub 100K+ stars，700+ 贡献者，每月 250 万开发者在用。它不是一个”好用的终端工具”——它有三种完整形态：桌面端、Web UI、终端 TUI，三种形态共享同一套会话和状态。

适用场景：

  • 需要多端协同的开发场景
  • 希望有原生批注功能的团队
  • 需要手机监工的场景

核心优势：

  • 三种完整形态：桌面端、Web UI、终端 TUI，共享同一套会话和状态
  • 自动加载 LSP：AI 在 Research 阶段读代码时能拿到类型信息和诊断结果
  • 多会话并行：可以同时开多个 Agent
  • 75+ 模型供应商：Anthropic、OpenAI、GitHub Copilot 等都支持
  • 完全开源免费：没有订阅费，没有 vendor lock-in

完整开发流程（Golang + Vue 示例）

准备阶段：先搭好骨架

mkdir myproject && cd myproject
mkdir -p wiki/guide docs/reports docs/plans

在 wiki/guide 目录下放几个常用文件：

文件 内容
agents.md 代码规范、设计文档路径、项目约定
log.md 日志系统、分布式追踪、统一 API 响应及错误码方案
database.md GORM 多数据库支持配置
config.md 系统配置方案（Viper 等）
middleware.md 中间件框架集成
redis.md Redis 客户端集成

项目骨架：先规划，再动手

/technical-research-before-planning
我需要完成一个用户权限管理系统，请帮我完成需求分析、技术选型、项目骨架创建方案的报告，
写入 docs/reports/project_init.md。需求如下：
- 支持 RBAC 权限模型
- 支持 JWT Token 认证
- 前端使用 Vue3 + Element Plus
- 后端使用 Gin + GORM + PostgreSQL
- 需要操作日志审计功能

technical-research-before-planning只做研究不写代码。它会头脑风暴、查资料、评估方案，最后输出评估报告。

初始化项目

/init
/executing-plans-with-standards
请根据@docs/reports/project_init.md 的内容，创建项目骨架

基础能力建设

基础能力就像搭积木，一块一块往上摞。每块都遵循同样的模式：研究→计划→执行。

请依照@wiki/guide/log.md 的说明，为本项目集成日志系统
请依照@wiki/guide/database.md 的说明，为本项目集成数据库框架
请依照@wiki/guide/config.md 的说明，为本项目集成系统配置方案
请依照@wiki/guide/middleware.md 的说明，为本项目集成中间件框架
请依照@wiki/guide/redis.md 的说明，为本项目集成 redis

遇到不熟悉的集成？ 走完整的研究 - 计划 - 执行流程：

/technical-research-before-planning
我需要集成 Casbin 以实现 RBAC 权限控制，请帮我评估并生成报告，写入 docs/reports/casbin.md

/analyzing-code-then-planning
请根据@docs/reports/casbin.md，帮我制定代码实现方案与实施计划，写入 docs/plans/casbin.md

/subagent-driven-plan-execution
执行计划@docs/plans/casbin.md

SKILL 速查表

SKILL 用途 核心原则
technical-research-before-planning 技术方案研究 只研究不写代码，做头脑风暴、设计评估、联网搜索
analyzing-code-then-planning 代码分析 + 计划制定 先分析代码、搜索复用、制定计划、等待确认后再实现
executing-plans-with-standards 标准化计划执行 严格遵守 AGENTS.md 标准，串行执行，含业务审查和三方对齐
subagent-driven-plan-execution 子代理驱动式执行 每个任务派独立子代理，支持串/并行，Prompt 嵌入完整上下文
code-chain-review 代码链审查 验证调用链数据正确性，确保实现与设计一致
triparty-alignment-assessment 三方对齐评估 评估计划 vs 设计 vs 代码对齐度，输出评估报告和修复建议
finish-implementation 完成开发收尾 测试验证→合并/保留分支→工作区清理

3.5 按开发阶段的 Skills 组合拳

基于真实微信小程序项目开发经验，按不同开发阶段整理出实用的 Skills 组合：

阶段一：原型阶段

核心技能：brainstorming

当需求模糊、产品形态不清晰时，使用 brainstorming 进行结构化探索。

使用方式：

npx skills add https://github.com/obra/superpowers --skill brainstorming

关键技巧：

  • 让 AI 出选择题而非开放式问题
  • 从产品定位、目标用户、功能范围到技术栈偏好逐层细化
  • 通过选项逼自己做决策，产品形态自然浮现

阶段二：UI 阶段

核心技能：ui-ux-pro-max + planning-with-files

确定产品方向后，先做 playground（实验环境），再写代码。

UI 设计技能：

npx skills add https://github.com/nextlevelbuilder/ui-ux-pro-max-skill --skill ui-ux-pro-max

设计约束示例：

这是一个游戏化的人生 RPG 小程序。核心交互是'资源分配'——用户像玩策略游戏一样，
在多个目标之间分配资金。设计风格要：年轻、有游戏感、但不幼稚。用色要清新，
避免传统理财软件那种'严肃的蓝绿色'。参考风格：Monument Valley 的极简几何 + 
Duolingo 的激励感。

规划技能：

npx skills add https://github.com/othmanadi/planning-with-files --skill planning-with-files

会创建 task_plan.md、findings.md、progress.md 三个文件，随时可以问”我现在做到哪了”。

阶段三：开发阶段

核心技能：test-driven-development

先写测试用例，再写功能代码。

npx skills add https://github.com/obra/superpowers --skill test-driven-development

微信小程序开发技巧：

  1. 先让 AI 生成 HTML+CSS+JS 的 playground
  2. 告诉 AI：「前端设计完全按照 playground 来不要自己改」
  3. 用 PUA 话术：「你一定要以一个完整成熟的小程序产品的角度去修改代码，不要从简。有什么困难先自己上网搜解决，我相信你有这个能力。」

阶段四：沉淀阶段

核心技能：自定义技能提炼

基于开发对话，提炼专属 skills：

基于我们刚才写小程序的对话，结合 insights 报告给我整理一下我以后可能需要生成的 skills

四、工具对比与选型指南

4.1 三剑客核心定位

工具 核心解决 类比 最佳场景
Spec-Kit 按什么规矩干 AI 编程的”行为准则手册” 企业级新建项目、多人协作
OpenSpec 改了什么、怎么改 AI 代码变更的”可控审批单” 存量维护、中小型快速迭代
Superpowers 怎么干、干到什么程度 AI 执行编码的”标准操作手册（SOP）” TDD、高可靠、强校验场景

4.2 关键维度对比

维度 Spec-Kit OpenSpec Superpowers
出品方 GitHub Fission AI 社区开源（Vercel Labs）
流程重量 重（全流程） 轻（变更） 中（强执行）
学习成本 ⭐⭐⭐ ⭐ ⭐⭐
存量兼容 一般 极佳 中等
AI 兼容 18+ 代理 全主流 全主流（Claude Code 最优）
约束强度 高 低 极高
最佳阶段 新项目立项 需求迭代/BUG 修复 核心模块/高可靠
文档产出 Constitution + Spec Proposal + Delta Spec Design + Plan
验证机制 内置测试生成 CI 集成 TDD 强制
变更管理 完整版本控制 增量规范归档 Git Worktree 隔离

4.3 选型指南

根据你的场景，直接选：

  1. 新项目、需要团队协作、计划长期维护 → 选 Spec-Kit，从一开始就定好规矩，避免后期混乱。

  2. 老项目、频繁改需求、需要快速上线 → 选 OpenSpec，轻量不折腾，管住变更就够了。

  3. 金融/核心业务、必须做 TDD、怕 AI 瞎写 → 选 Superpowers，用证据驱动，保证代码质量。

  4. 需要多端协同、原生批注体验 → 选 OpenCode，桌面端 + Web UI + 手机监工。

  5. 微信小程序等特定平台开发 → 按阶段组合 Skills，灵活应对平台特性。

推荐黄金组合：

  • 大型项目：Spec-Kit（定规矩）+ OpenSpec（管变更），全流程覆盖，协作更顺畅。
  • 中小项目：OpenSpec（日常迭代）+ Superpowers（核心模块），灵活又能保质量。
  • 个人开发：Boris 工作流（核心）+ 自定义 Skills（提效），轻量高效。

4.4 常见失误与解决方案

失误模式 症状 解决方法
厨房水槽 session 话题飘到五个方向 切任务就 /clear
纠正死循环 同一个错误纠正 3 次 + 清空上下文，重写 prompt
CLAUDE.md 膨胀 规则文件 500 行 问自己”没这行会犯什么错”，删掉多余的
无边界调查 Claude 读了几百个文件，上下文耗尽 给调查划定范围，或用子智能体隔离
Skills 收集癖 装了 78 个 skills，真正用的没几个 按开发阶段选择组合拳，而非全部安装
跳过 Research AI 不理解系统就开写 强制先写 research.md
计划无批注 计划直接通过，无人类判断注入 至少 1 轮批注循环
验证不充分 声称完成但无证据 强制运行验证命令展示输出

五、总结与展望

5.1 核心要点

AI 编程的未来，不是「让 AI 随便写」，而是用规范把 AI 变成可信赖的生产力。

  • Spec-Kit 从源头定好规则，驯服 AI 的”随意性”
  • OpenSpec 管控变更，驯服 AI 的”破坏性”
  • Superpowers 强化验证，驯服 AI 的”不确定性”

三者结合，就能让 AI 完全听从我们的指挥。

5.2 工作流核心原则

  1. 先规划，后执行 — 永远不要让 AI 写代码，直到你审核并批准了一份书面计划
  2. 批注优于聊天 — plan.md 文件充当了你和 AI 之间的共享可变状态
  3. 证据在断言之前 — 任何声称工作完成之前，必须独立运行验证命令并展示证据
  4. 并行是效率杠杆 — 同时跑 3-5 个 session，每个做不同的任务
  5. 技能化消灭重复 — 一天做了两次的事，就变成一个 skill
  6. 上下文是稀缺资源 — 用子智能体隔离调查，保持主对话干净

5.3 最佳实践清单

5.4 工作流成熟度演进建议

第 1-2 周：掌握 Boris 工作流
├── 熟练使用 research.md + plan.md
├── 完成至少 3 次完整的批注循环
└── 建立 CLAUDE.md 基础规则

第 3-4 周：引入 Superpowers 技能
├── 安装 test-driven-development
├── 安装 verification-before-completion
└── 开始使用 subagent-driven-development

第 5-8 周：工程化升级
├── 引入 Spec-Kit 或 OpenSpec
├── 建立团队规范文档
├── 创建自定义 Skills
└── 集成 CI/CD 验证

第 8 周+：持续优化
├── 根据项目特点调整工作流
├── 沉淀团队专属最佳实践
└── 分享和贡献社区

附录：一些技巧

背景说明

Claude Code 官方最佳实践来自 Claude Code 之父 Boris Cherny 的内部团队实践，以及官方文档。这些技巧经过 Anthropic 内部团队和大量外部用户验证。

十大核心技巧

技巧一：让 Claude 自己验证自己的工作

把验证标准直接写进 prompt：

写一个验证邮箱的函数。测试用例：hello@gmail.com 应该通过，hello@ 应该失败，
@domain.com 应该失败。写完后跑一遍测试告诉我结果。

技巧二：先规划，再动手

标准流程： 1. 进入 Plan Mode，让 Claude 读相关文件，摸清项目结构 2. 让 Claude 写出完整的执行计划 3. 你自己读一遍计划，有问题直接改 4. 切回普通模式，按计划执行 5. 执行完让 Claude 写清晰的 commit message

技巧三：CLAUDE.md 是你最被低估的工具

CLAUDE.md 是 Claude 每次启动都会读的文件，放在项目根目录里。你写进去的规则，Claude 每次都会遵守，不用再一遍遍重申。

进化技巧： 每次 Claude 犯了某个错，纠正完之后在对话末尾加一句：

更新你的 CLAUDE.md，确保下次不再犯同样的错误。

⚠️ 注意： 别让 CLAUDE.md 变成一个 500 行的怪兽。每一行都应该对应一个真实的错误。

技巧四：并行才是真正的效率杠杆

Claude Code 支持多个 session 同时运行，可以用 git worktrees 在同一个项目里开多个独立工作区。

典型并行用法： - Session A：写新功能 - Session B：审 Session A 写的代码，找边界情况和漏洞 - 把 B 的反馈喂给 A

技巧五：Bug 修复，直接扔原始数据给 Claude

把原始数据扔给 Claude，说”fix”。

  • 直接把 Slack 对话贴进去，一个字：“fix。”
  • 或者直接说：“去修一下 CI 上失败的测试。”

关键是：给 Claude 真实的信息——错误日志、Slack 线程、docker 输出——而不是你对这些信息的描述。

技巧六：子智能体——让主对话保持干净

当 Claude 需要深度调查一个问题时，让它读很多文件会占满上下文窗口。子智能体（Subagents） 解决这个问题：让一个独立的 Claude 实例去做调查工作，它有自己的独立上下文。

用法：在任何调查类请求后面加一句：

用子智能体来……（后面接具体任务）

技巧七：写 Skill（自定义命令），消灭重复劳动

规则：一天做了两次的事，就变成一个 skill。

比如一个 /fix-issue 的 skill，你只需要说/fix-issue 447，Claude 自动：

  1. 读取 GitHub issue #447
  2. 找到项目里相关的文件
  3. 做修复
  4. 写测试并运行
  5. 创建 Pull Request

技巧八：提示词技巧

① 让 Claude 审你

用最挑剔的方式质问这些改动，直到我通过你的测试才能开 PR。

② 让 Claude 重写一个更优雅的版本

你现在知道所有背景了。把这个方案推翻重来，给我一个优雅的实现。

③ 要求 Claude 证明

证明给我看这个改动有效。把 main 分支和我的 feature 分支的行为差异展示出来。

技巧九：用好 /clear 和 Checkpoint

当你在一个 session 里工作了很久，修了 bug、问了无关问题、聊到了另一个话题……这叫上下文污染。

解法：

  • /clear：硬重置，清空上下文。然后用一个更清晰的 prompt 重新开始。
  • /compact：软重置，告诉 Claude 保留什么，清掉其他噪音。

建议： 如果你在 session 里对同一个问题纠正了两次，Claude 还是没改对——不要再纠正第三次了。清掉上下文，写一个更精准的起始 prompt，重头开始。

技巧十：把 Claude Code 当成学习工具

进入新项目时，你可以直接问：

这个项目的日志系统是怎么工作的？
这个函数具体在做什么，为什么要调这个方法而不是那个？
用户登录的完整流程是什么，从第一个请求到 session 建立？

参考资源

  1. Boris Tane. How I Use Claude Code. https://boristane.com/blog/how-i-use-claude-code/
  2. Claude Code 官方最佳实践文档。https://code.claude.com/docs/en/best-practices
  3. Superpowers 官方技能库。https://skills.sh/obra/superpowers
  4. OpenSpec 文档。https://github.com/Fission-AI/OpenSpec
  5. OpenCode 官网。https://opencode.ai
  6. 数智启思 - Superpowers Skill 配套使用指南。https://jdragonnudt.github.io/inspiraHub/myblog/posts/superpower_skills/
  7. 数智启思 - OpenSpec 中文使用指南。https://jdragonnudt.github.io/inspiraHub/myblog/posts/AIcoding_openspec/
  8. Spec-Kit 文档。https://github.com/github/spec-kit

引用信息

引用本文请注明以下信息。

@article{lj_AIcoding_workflow_2026,
  author = {龙军},
  title = {AI 编程工作流深度解析},
  year = {2026},
  url = {https://jdragonnudt.github.io/inspiraHub/myblog/posts/AIcoding-workflow},
}
Back to top