外观
规范优先开发
在要求 Claude 构建之前，先在 CLAUDE.md 中定义你想要的内容。一次结构良好的迭代，等于八次无结构迭代。
目录
- TL;DR
- 该模式
- 任务粒度：为智能体调整工作规模
- CLAUDE.md 规范模板
- 逐步工作流
- 工具集成
- 何时使用
- 反模式
- 另请参阅
TL;DR
Plain
1. 在 CLAUDE.md 中编写规范
2. Claude 自动读取规范
3. 实现严格遵循规范
4. 对照规范进行验证CLAUDE.md 就是你的规范文件。将它视为一份契约。
该模式
规范优先开发颠转了典型的 AI 编码流程：
Plain
传统方式： 规范优先：
────────── ──────────
提示词 → 代码 规范 → 提示词 → 代码 → 验证
│ │ │ │
└─ 希望是你想要的 └─ 契约已定义 └─ 遵循规范
└─ 对照规范检查规范成为真理的来源，它能：
- 约束 Claude 所构建的内容
- 为团队记录决策
- 支持对完整性的验证
任务粒度：为智能体调整工作规模
在编写规范之前，先验证任务规模是否合适。智能体最适合处理垂直切片——细薄的端到端单元，贯穿所有层，但只实现一个完整的用户行为（例如："通过邮件重置密码"，而非"认证系统"）。
经验法则：一个智能体会话 = 一个垂直切片。如果任务描述需要在两个用户行为之间加"并且"，就应该拆分。
PRD 质量清单
在将任何任务交给智能体之前先运行此清单。需要验证六个维度：
| 维度 | 需要问的问题 | 红旗信号 |
|---|---|---|
| 问题清晰度 | 问题陈述是否无歧义？ | "提升性能" |
| 可测试标准 | 完成情况是否可自动验证？ | "运行良好" |
| 范围边界 | 明确哪些内容不在范围内？ | 没有列出任何排除项 |
| 可观察的完成状态 | 对用户而言"完成"看起来是什么样？ | 仅描述内部实现 |
| 需求清晰度 | 规范中没有实现细节？ | "使用 Redis 做缓存" |
| 术语一致性 | 全程使用相同的术语？ | "用户"和"账户"混用 |
如果某个任务在 2 个以上维度不合格，在交给智能体之前需要修订。规范审查能提前捕获歧义，否则这些歧义会在会话中途以错误实现的形式暴露出来。
Plain
❌ 过于宽泛，有歧义：
"为应用添加用户认证"
✅ 一个垂直切片：
"用户可以用邮箱 + 密码登录。
- POST /auth/login 成功返回 JWT，失败返回 401
- 凭证无效时显示'邮箱或密码错误'（不指出哪个错误）
- 会话 24 小时后过期
- 不在范围内：OAuth、密码重置、记住我"功能列表：机器可读的范围控制
功能列表是一个 JSON 文件，用于跨智能体会话追踪每个功能的范围和完成状态。与描述意图的 PRD 不同，功能列表是智能体的操作契约：会话开始时读取，会话结束时更新，并在交接时持续存在。
每个功能条目有三个必填字段。description 告诉智能体要构建什么。verify 字段是一个在成功时退出码为 0 的 shell 命令，这很重要，因为它强制将"完成的定义"变为可执行的，而不仅仅是描述性的。status 字段通过单向状态机追踪进度：not_started → active → blocked → passing。条目只能向前移动，不能后退。当功能达到 passing 状态时，evidence 字段记录证明内容（测试名称、命令输出或特定的日志行）。
WIP=1 规则在此同样适用：任何时刻只能有一个功能处于 active 状态。多个活跃功能会导致所有功能上的部分工作和不完整验证。
将 feature_list.json 存放在项目根目录，与 AGENTS.md 并列。会话开始时，智能体读取它以了解已完成的内容和接下来要处理的内容。会话结束时，智能体在提交前写入更新后的状态和证据。
功能列表与 claudedocs/handoffs/ 配合使用。两个组件共同为下一次会话提供操作状态（哪些功能已完成并经过验证）和叙述上下文（发生了什么、尝试了什么、还留有哪些问题）。两者互不替代。
展示两个处于不同阶段的功能的最小示例：
JSON
{
"features": [
{
"id": "feat-001",
"name": "Document Import",
"description": "Allow users to import PDF and TXT files from local filesystem",
"verify": "npm test -- --grep 'document import'",
"status": "passing",
"evidence": "npm test: 12 passed, 0 failed (2026-05-01 14:22)"
},
{
"id": "feat-002",
"name": "Document Chunking",
"description": "Split imported documents into ~500-character chunks with metadata",
"verify": "npm test -- --grep 'chunking'",
"status": "not_started",
"evidence": "",
"dependencies": ["feat-001"]
}
]
}feat-001 上的 evidence 字段显示了确切的运行内容和时间。feat-002 条目是 not_started，evidence 字段为空，等待 feat-001 确认通过后才变为 active。此模式在 Anthropic 工程博客关于长时间运行应用框架工程设计的文章中有描述。可在 examples/workflows/feature-list.json 找到即用模板。
CLAUDE.md 规范模板
功能规范（最常用）
Markdown
## 功能：[名称]
### 描述
[2-3 句话解释功能用途]
### 能力
- 必须：[必需功能]
- 必须：[另一个需求]
- 应该：[锦上添花的功能]
- 不得：[明确排除项]
### 技术栈
- 必需：[lib1, lib2, lib3]
- 禁止：[lib4, lib5]
### 验收标准
- [ ] 标准 1：[具体、可测试的条件]
- [ ] 标准 2：[另一个条件]
- [ ] 标准 3：[边缘情况处理]
### API 契约（如适用）
- 端点：POST /api/[resource]
- 请求：{ field1: string, field2: number }
- 响应：{ id: string, created: timestamp }
- 错误：400（验证失败）、404（未找到）、500（服务器错误）架构规范
Markdown
## 架构：[组件名称]
### 用途
[此组件存在的原因]
### 边界
- 负责：[此组件负责的内容]
- 委托给：[其他组件处理的内容]
- 不负责：[明确的非责任事项]
### 依赖
- 上游：[调用此组件的组件]
- 下游：[此组件调用的组件]
### 数据流输入 → 验证 → 处理 → 输出│ │└─ 错误 ──┘
Plain
### 约束
- 性能：[响应时间、吞吐量]
- 安全：[认证要求、数据处理]
- 可扩展性：[预期负载、限制]API 规范
Markdown
## API：[端点名称]
### 端点
`POST /api/v1/[resource]`
### 认证
需要 Bearer 令牌。Scope：`read:resource`、`write:resource`
### 请求
```json
{
"field1": "string (required, max 255 chars)",
"field2": "number (optional, default: 0)",
"nested": {
"subfield": "boolean"
}
}响应
JSON
{
"id": "uuid",
"created_at": "ISO 8601 timestamp",
"data": { ... }
}错误码
| 码 | 含义 | 响应体 |
|---|---|---|
| 400 | 验证失败 | { "errors": [...] } |
| 401 | 未认证 | { "message": "..." } |
| 403 | 未授权 | { "message": "..." } |
| 404 | 资源未找到 | { "message": "..." } |
Plain
---
## 逐步工作流
### 第 1 步：编写规范
在任何实现请求之前，将规范添加到 CLAUDE.md：
```markdown
## 功能：用户认证
### 能力
- 必须：邮箱/密码登录
- 必须：JWT 令牌生成
- 必须：使用 bcrypt 进行密码哈希
- 应该：记住我功能
- 不得：存储明文密码
### 技术栈
- 必需：bcrypt、jsonwebtoken
- 禁止：passport.js（此用例过于重量级）
### 验收标准
- [ ] 用户可以用有效凭证登录
- [ ] 无效凭证返回 401
- [ ] 令牌在 24 小时后过期（选择"记住我"则 7 天）
- [ ] 密码以成本因子 12 进行哈希第 2 步：在提示词中引用规范
Plain
按照 CLAUDE.md 中指定的内容实现用户认证功能。
严格遵循验收标准。Claude 自动读取 CLAUDE.md 并遵循规范。
第 3 步：对照规范验证
实现完成后进行验证：
Plain
对照用户认证规范审查实现。
勾选每个已满足的验收标准。
列出所有差距。第 4 步：按需更新规范
如果实现过程中需求发生变化：
Plain
更新用户认证规范，添加：
- 必须：频率限制（每分钟 5 次尝试）
然后实现频率限制。工具集成
与 Spec Kit 集成（绿地项目）
Bash
# 安装 Spec Kit
npx @anthropic/spec-kit init
# 使用斜杠命令
/speckit.constitution # 定义项目护栏
/speckit.specify # 编写功能规范
/speckit.plan # 创建实现计划
/speckit.implement # 基于规范构建与 OpenSpec 集成（棕地项目）
Bash
# 安装 OpenSpec
npm install -g @fission-ai/openspec@latest
openspec init
# 使用斜杠命令
/openspec:proposal "添加暗黑模式" # 创建变更提案
/openspec:apply add-dark-mode # 实现变更
/openspec:archive add-dark-mode # 合并到规范与计划模式集成
Plain
[按 Shift+Tab 进入计划模式]
我需要实现支付处理功能。
请审查 CLAUDE.md 中的规范并创建实现计划。何时使用
使用规范优先
| 场景 | 原因 |
|---|---|
| 新功能 | 构建前先定义 |
| API 设计 | 契约必须明确 |
| 架构决策 | 记录约束 |
| 团队协作 | 建立共同理解 |
| 复杂需求 | 减少歧义 |
跳过规范优先
| 场景 | 原因 |
|---|---|
| 快速修复 | 开销不值得 |
| 探索性开发 | 还不知道你想要什么 |
| 原型开发 | 需求会变 |
| 单行修改 | 意图显而易见 |
反模式
模糊的规范
Markdown
# 错误
## 功能：用户管理
- 处理用户
# 正确
## 功能：用户管理
### 能力
- 必须：创建用户（邮箱、密码、姓名）
- 必须：更新用户资料（姓名、头像）
- 必须：软删除（标记为非活跃，不删除数据）
- 不得：允许重复邮箱编码后才写规范
Plain
# 错误的工作流
1. 让 Claude 实现功能
2. 编写记录已构建内容的规范
# 正确的工作流
1. 编写规范，定义应该构建什么
2. 让 Claude 基于规范实现忽略禁止项
Markdown
# 不要忘记排除项
### 技术栈
- 必需：React、TypeScript
- 禁止：jQuery、原生 JS、类组件
↑ 这些约束防止偏移模块化规范设计
模式：将大型规范拆分为多个专注的文件，而不是把所有内容塞进一个 CLAUDE.md。
问题：单体 CLAUDE.md
当规范超过约 200 行时，会出现几个问题：
- 上下文污染：Claude 难以从臃肿的上下文中提取相关信息
- 认知超载：开发者无法快速找到所需内容
- 维护负担：更新一个区域需要在无关内容中导航
- 性能下降：大型 CLAUDE.md 文件会减慢上下文加载和处理速度
何时拆分
| 阈值 | 操作 |
|---|---|
| <100 行 | 单个 CLAUDE.md 没问题 |
| 100-200 行 | 若存在明显的独立领域，考虑拆分 |
| >200 行 | 立即拆分 —— 已超过认知负担阈值 |
| 多团队项目 | 无论大小，按领域/所有权拆分 |
拆分策略
1. 基于功能拆分
Plain
CLAUDE.md # 核心项目上下文
CLAUDE-auth.md # 认证规范
CLAUDE-api.md # API 端点规范
CLAUDE-billing.md # 支付处理规范2. 基于角色拆分
Plain
CLAUDE.md # 共享约定
CLAUDE-frontend.md # UI/UX 规范
CLAUDE-backend.md # API/数据库规范
CLAUDE-infra.md # DevOps/部署规范3. 基于工作流拆分
Plain
CLAUDE.md # 日常开发规则
CLAUDE-testing.md # 测试规范
CLAUDE-release.md # 发布流程规范
CLAUDE-security.md # 安全要求实现模式
主 CLAUDE.md（保持简洁）：
Markdown
# 项目：[名称]
## 技术栈
[核心技术]
## 命令
[日常命令]
## 规则
[通用规则]
## 详细规范
- 认证：参见 @CLAUDE-auth.md
- API 设计：参见 @CLAUDE-api.md
- 测试：参见 @CLAUDE-testing.mdCLAUDE-auth.md（专注规范）：
Markdown
# 认证规范
## 能力
- 必须：基于 JWT 的认证
- 必须：刷新令牌轮换
- 不得：将令牌存储在 localStorage
## API 契约
[详细的认证端点...]
## 安全要求
[具体的认证安全规则...]优势：
- Claude 可以通过
@CLAUDE-auth.md引用特定文件 - 上下文加载更快（只加载相关规范）
- 维护更简单（修改一个领域不影响其他领域）
- 团队协作更好（每个规范文件有所有权归属）
来源：Addy Osmani，"如何为 AI 智能体编写良好规范"（2026 年 1 月）
操作边界
模式：为 AI 智能体应该自动执行的操作、需要先询问的操作以及绝对禁止的操作定义明确的边界。
三级系统
传统规范使用二元约束（必须/不得），但操作工作需要三个级别：
| 级别 | 含义 | Claude Code 映射 |
|---|---|---|
| 总是 | 无需询问自动执行 | 自动接受模式 |
| 先询问 | 继续前获取用户确认 | 默认模式 |
| 绝不 | 阻止或需要计划模式 | 计划模式 / Hooks（钩子）阻止 |
操作边界模板
Markdown
## 边界
### 总是（自动接受）
- 代码修改后运行测试
- 使用 Prettier 格式化代码
- 移动文件时更新导入
- 修复 lint 错误
- 为未类型化的代码添加类型注解
### 先询问（需确认）
- 修改数据库 Schema
- 添加新依赖
- 变更 API 契约
- 重构超过 50 行代码
- 更新配置文件
### 绝不（阻止）
- 推送到生产分支
- 提交密钥或 API 密钥
- 删除数据而不备份
- 在未经审查的情况下修改 CI/CD 工作流
- 绕过安全检查映射到 Claude Code 权限
总是 → 权限允许列表：
JSON
// 在 .claude/settings.json 中
{
"permissions": {
"allow": [
"Bash(npm test*)",
"Bash(npx prettier*)",
"Bash(npx tsc*)"
]
}
}先询问 → 默认模式：
- 标准行为，每次操作都会提示
- 用于具有中等风险/影响的操作
绝不 → 计划模式 + Hooks（钩子）：
Bash
# 通过 settings.json 配置的钩子（工具前钩子事件）
#!/bin/bash
if [[ "$TOOL_NAME" == "Bash" ]] && [[ "$INPUT" =~ "git push origin main" ]]; then
echo "已阻止：禁止直接推送到 main。请使用功能分支。"
exit 2 # 向 Claude 发送反馈（非零退出阻止该操作）
fi决策框架
对每个操作问自己：
- 它会导致数据丢失吗？ → 先询问或绝不
- 它可以用 Git 撤销吗？ → 也许总是
- 它影响其他开发者吗？ → 先询问
- 它有安全风险吗？ → 绝不
- 它是标准工作流的一部分吗？ → 总是
示例：API 开发
Markdown
### 总是
- 运行单元测试（npm test）
- 验证请求 Schema
- 生成 API 文档
- 检查响应格式
### 先询问
- 添加新的 API 端点
- 修改现有端点签名
- 修改认证要求
- 更新频率限制规则
### 绝不
- 公开内部端点
- 记录敏感用户数据
- 禁用认证检查
- 移除频率限制维护
每季度审查边界：
- 提升：从未引起问题的操作（先询问 → 总是）
- 降级：曾引起问题的操作（总是 → 先询问）
- 阻止：反复出错的操作（先询问 → 绝不）
来源：Addy Osmani，"如何为 AI 智能体编写良好规范"（2026 年 1 月）
命令规范模板
模式：记录可执行命令及其预期输出和错误处理。
为何命令规范重要
大多数规范关注功能（"构建认证"），但命令（"如何测试认证"）对 AI 智能体同样至关重要。
模板结构
Markdown
## 命令
### [命令类别]
**用途**：[此命令完成的内容]
#### 命令：`[实际命令]`
**时机**：[触发条件]
**预期输出**：[成功时是什么样子]
**错误处理**：[失败时做什么]
**标志**：[重要选项]
---示例：测试命令
Markdown
## 命令
### 测试
#### 命令：`pnpm test`
**时机**：每次提交前，代码修改后
**预期输出**：
- 所有测试通过（退出码 0）
- 覆盖率 ≥80%（行、分支、函数）
- 无控制台警告
**错误处理**：
- 测试失败 → 修复测试，不跳过
- 覆盖率下降 → 为未覆盖代码添加测试
- 出现警告 → 提交前先调查
**标志**：
- `--coverage`：生成覆盖率报告
- `--watch`：开发时以监视模式运行
- `--silent`：抑制控制台输出
#### 命令：`pnpm test:e2e`
**时机**：合并到 main 之前，在 CI 流水线中
**预期输出**：
- 所有 E2E 场景通过
- 失败时捕获截图
- 测试时长 <5 分钟
**错误处理**：
- 若不稳定 → 调查竞态条件，不盲目重试
- 若超时 → 检查网络 mock、异步处理
- 若截图不同 → 有意地审查 UI 变更
**标志**：
- `--headed`：以可见浏览器运行（调试用）
- `--project chromium`：测试特定浏览器示例：构建与部署
Markdown
## 命令
### 构建
#### 命令：`pnpm build`
**时机**：部署前，在 CI 流水线中
**预期输出**：
- 构建成功（退出码 0）
- 输出在 `dist/` 目录
- 无 TypeScript 错误
- 包大小 <500KB（主 chunk）
**错误处理**：
- TypeScript 错误 → 修复类型，不使用 `@ts-ignore`
- 包过大 → 用 `pnpm analyze` 分析，进行代码分割
- 缺少资源 → 检查 public/ 目录，更新路径
**标志**：
- `--mode production`：生产优化
- `--analyze`：生成包大小报告
### 部署
#### 命令：`pnpm deploy:staging`
**时机**：PR 通过审批后，生产前
**预期输出**：
- 部署成功
- 健康检查返回 200 OK
- Staging URL：https://staging.example.com
**错误处理**：
- 健康检查失败 → 自动回滚
- 数据库迁移失败 → 不继续，进行调查
- 环境变量缺失 → 检查 .env.staging，更新密钥
**绝不**：手动运行 `pnpm deploy:production` —— 只通过 CI/CD示例：数据库命令
Markdown
## 命令
### 数据库
#### 命令：`pnpm db:migrate`
**时机**：拉取 Schema 变更后，开发前
**预期输出**：
- 迁移成功应用
- 数据库 Schema 与模型匹配
- 加载种子数据（仅开发环境）
**错误处理**：
- 迁移失败 → 检查数据库连接，审查 SQL
- 检测到冲突 → 解决迁移，不强制执行
**绝不**：在生产环境手动运行迁移 —— 只通过 CI/CD
#### 命令：`pnpm db:reset`
**时机**：仅开发环境，绝不在 staging/生产环境
**预期输出**：
- 数据库已删除并重建
- 所有迁移已应用
- 已加载种子数据
**错误处理**：
- 生产环境检查失败 → 立即中止，验证环境
**安全**：需要 `NODE_ENV=development` 检查与 CLAUDE.md 集成
在主 CLAUDE.md 中引用命令规范：
Markdown
## 命令
- 构建：`pnpm build`（错误处理见规范）
- 测试：`pnpm test`（提交前必须通过）
- 部署：完整流程见 CLAUDE-deployment.md来源：Addy Osmani，"如何为 AI 智能体编写良好规范"（2026 年 1 月）
反模式：单体 CLAUDE.md
问题
症状：你的 CLAUDE.md 已增长到 300+ 行，混杂了功能规范、API 契约、测试要求、部署流程和团队约定。
影响：
- 上下文低效：Claude 为每个请求加载全部 300 行，即使对于简单任务也如此
- 响应变慢：大上下文 = 处理更慢
- 准确度降低：重要细节淹没在噪音中
- 维护开销：更新一个部分需要在无关内容中导航
- 团队摩擦：多名开发者编辑同一文件 = 合并冲突
真实案例
之前（单体）：
Markdown
# CLAUDE.md（387 行）
## 技术栈
[20 行]
## 认证
[45 行认证规范]
## API 端点
[67 行 API 契约]
## 数据库 Schema
[52 行 Schema 规则]
## 测试
[38 行测试要求]
## 部署
[41 行部署流程]
## 安全规则
[55 行安全要求]
## 团队约定
[33 行编码规范]
## Git 工作流
[28 行分支规则]
## 故障排查
[8 行常见问题]问题：当用户问"为用户资料添加新的 API 端点"时，Claude 加载了全部 387 行
之后（模块化）：
Plain
CLAUDE.md（82 行） # 核心上下文：技术栈、命令、规则
CLAUDE-auth.md（45 行） # 仅认证规范
CLAUDE-api.md（67 行） # 仅 API 契约
CLAUDE-database.md（52 行） # 仅数据库 Schema
CLAUDE-testing.md（38 行） # 仅测试要求
CLAUDE-deploy.md（41 行） # 仅部署流程
CLAUDE-security.md（55 行） # 仅安全要求优势：Claude 加载 CLAUDE.md（82 行）+ CLAUDE-api.md（67 行）= 149 行（减少 61%）
拆分策略
第 1 步：识别领域
寻找规范中的自然边界：
- 这些部分服务于不同的目的吗？
- 不同的团队成员会拥有不同的部分吗？
- 某些部分的引用频率高于其他部分吗？
第 2 步：提取到专注文件
将特定领域的内容移到专用文件：
Bash
# 保留在 CLAUDE.md 中（始终加载）
- 技术栈（不变的基准）
- 日常命令（频繁引用）
- 通用规则（适用于所有工作）
# 提取到领域文件（按需加载）
- 功能规范 → CLAUDE-[feature].md
- API 契约 → CLAUDE-api.md
- 测试 → CLAUDE-testing.md
- 部署 → CLAUDE-deploy.md第 3 步：在主 CLAUDE.md 中创建索引
Markdown
# 项目：[名称]
## 技术栈
[核心技术]
## 命令
[日常命令]
## 规则
[通用规则]
## 详细规范
引用这些文件以获取特定领域的要求：
- @CLAUDE-auth.md — 认证与授权
- @CLAUDE-api.md — API 端点契约
- @CLAUDE-database.md — Schema 和迁移
- @CLAUDE-testing.md — 测试要求
- @CLAUDE-deploy.md — 部署流程
- @CLAUDE-security.md — 安全要求第 4 步：按需引用
Claude 可以引用特定文件：
Plain
用户："为用户设置添加新的 API 端点"
Claude：读取 CLAUDE.md + @CLAUDE-api.md（仅相关上下文）维护规则
- 保持 CLAUDE.md <100 行（仅核心上下文）
- 领域文件各 <150 行（若更大，进一步拆分）
- 每季度审查：合并少用文件，拆分频繁更新的部分
- 使用 @file 引用：明确加载所需内容
迁移清单
[ ] 识别当前 CLAUDE.md 中的领域（>200 行？）
[ ] 创建特定领域的文件（CLAUDE-[domain].md）
[ ] 将内容移到专注文件
[ ] 用索引/引用更新主 CLAUDE.md
[ ] 测试：让 Claude 执行特定领域的任务
[ ] 验证：用
/status检查上下文使用情况[ ] 记录：向团队说明新结构
来源：Addy Osmani，"如何为 AI 智能体编写良好规范"（2026 年 1 月）
SDD（规范驱动开发）vs TDD（测试驱动开发）vs BDD（行为驱动开发）
到 2026 年，规范驱动开发已经足够成熟，可以有意义地与旧方法论进行比较。区别不在于哪个在抽象层面更好——而在于哪个制品在主导。
| 方法论 | 主导制品 | 运行时机 | 人的角色 | 可再生成？ |
|---|---|---|---|---|
| TDD | 测试套件 | 代码存在后 | 先写测试，再写代码 | 否——测试记录已构建的内容 |
| BDD | Gherkin（.feature 文件） | 代码存在后 | 编写场景，再自动化 | 部分——场景可驱动代码生成 |
| SDD | 规范文件（自然语言结构化） | 代码存在前 | 编写规范，审批契约 | 是——代码在原则上是规范的可推导输出 |
SDD 一列的实际含义：如果规范是主导制品，那么代码在原则上可以从规范再生成。Tessl 将此推向逻辑极端，使用标注 // GENERATED FROM SPEC - DO NOT EDIT 的文件。Martin Fowler 指出这是"规范优先"（代码从规范开始），但还不是"规范锚定"（规范和代码随时间自动保持同步）。目前没有任何工具在生产规模上可靠地解决了规范漂移问题。
无规范结构的多文件任务失败率：与隔离函数的 87% 相比，多文件基础设施任务的 pass@1 降至 19.4%（Augment Code 内部数据，无已发表的同行评审研究）。方向性主张是可信的——没有持久任务上下文的智能体在跨文件和组件的任务上更容易失败。具体数字来自供应商。
Factory.ai 任务架构
生产中文档最完善的多智能体 SDD（规范驱动开发）实现。架构：
- 编排者在任何实现开始前将需求转化为行为验证契约。
- 工作者并行实现功能，每人从契约中接收一个有边界的任务描述。
- 验证者智能体（对抗性、独立）对照契约验证每个实现。它们没有来自工作者的上下文——只有契约和输出。
在一个有记录的 Slack 克隆项目中：验证者在任何代码合并之前发现了 81 个问题，产生了 34% 的总实现工作量作为"修复功能"。任务中位时长：2 小时。记录最长的任务：16 天。Factory.ai 在共享制品（验证契约、功能列表、技能定义）中外化状态，以在多天任务期间跨上下文重置存活。
CLI 参考（使用 Factory.ai 时）：
Bash
droid exec --mission path/to/mission.yaml # 启动任务
droid status # 检查活跃任务
droid validate --mission-id <id> # 手动运行验证者规范漂移：未解决的问题
生产中最重要的风险：当规范和代码出现分歧时，智能体会再次生成已经修复过的 bug。缓解模式：
- 在任何实现提交之前，将规范作为 Git 制品进行版本控制。
- Cursor
/evolve命令：当实现有意偏离规范时更新规范。 - Intent（智能体）：在实现过程中将变更写回规范，保持两者同步。
- GitHub Spec Kit：将规范作为版本化文件存储在
.specify/中，CI 可以读取。
截至 2026 年 5 月，没有任何工具具有可靠、广泛采用的规范-代码长期自动同步机制。这是 SDD（规范驱动开发）目前的主要未解决问题。
另请参阅
- 「../core/methodologies.md」 — SDD（规范驱动开发）及其他方法论
- Spec Kit 文档
- OpenSpec 文档
- 「tdd-with-claude.md」 — 与 TDD（测试驱动开发）结合
- Spec-to-Code Factory — 带工具化强制执行的完整参考实现（6 个关卡通过 Node.js 实现，"无规范不写代码"+"无任务不提交"不变量，约 90 万 Token（词元）/项目）
- Superpowers — 插件套件（95k+ 星），其
brainstorming技能将规范优先作为强制关卡：智能体在规范被审查和批准之前拒绝编写代码。安装：/plugin install superpowers@claude-plugins-official。
来源：飞书 · AI Spark 知识库 ｜ 原文（最新版）：https://lcnniolukk80.feishu.cn/wiki/WRqzwVZJli2LwvkbRAgcJTbyn2e ｜ 归档：2026-06-04