AI原生软件工程与Agentic SDLC开发流程
面向已经具备软件工程基础、希望系统使用 AI Coding Agent 进行需求分析、编码、测试、审查和交付的工程师。
本文回答一个实际问题：从 Vibe Coding、SDD、Spec 之后，当前更完整、更适合生产项目的 AI 开发流程是什么？
资料核对日期：2026-09-03
目录
- 1. 结论先行
- 2. 术语和方法的关系
- 3. 从 Vibe Coding 到 Agentic SDLC 的演进
- 4. 推荐的完整 AI 开发流程
- 5. 核心产物设计
- 6. 一套可直接落地的目录结构
- 7. Agent 的职责边界与人机分工
- 8. Context Engineering 实践
- 9. Harness Engineering 实践
- 10. 测试、评估与质量门禁
- 11. 多 Agent 和并行开发
- 12. 工具和方法选择
- 13. 典型项目的落地模板
- 14. 前端和多端项目的特殊约束
- 15. 安全、权限和供应链
- 16. 常见反模式
- 17. 团队推广路线
- 18. 生产检查清单
- 19. 结论：现在应该怎样理解 VB、SDD 和 Agent 开发
- 20. 参考资料与核对说明
1. 结论先行
如果这里的 VB 指的是 Vibe Coding，那么当前的演进不是：
Vibe Coding → SDD → 新方法取代 SDD
而是：
Vibe Coding
+ Spec-Driven Development
+ Agentic Software Engineering
+ Context Engineering
+ Harness Engineering
+ Eval-Driven Development
+ Orchestration
可以把它概括为：
用 Vibe Coding 探索，用 Spec 固化意图，用 Agent 执行，用 Harness 约束环境，用 Test/Eval 验证，用生产观测反馈。
当前更完整的名称通常是：
- Agentic Software Engineering：智能体驱动的软件工程。
- AI-native Software Development：AI 原生软件开发。
- Agentic SDLC：智能体驱动的软件开发生命周期。
- Context Engineering：上下文工程。
- Harness Engineering：面向 Agent 的工程执行环境设计。
- Eval-Driven Development：评估驱动开发。
这些词语不是同义词，而是不同层次：
方法层：SDD / Agile / TDD / BDD
执行层：Agentic Coding / Agentic SDLC
知识层：Context Engineering
基础设施层：Harness Engineering
质量层：Test / Eval / Observability
调度层：Orchestration / Multi-Agent
交互层：Vibe Coding
因此，SDD 没有过时。真正的变化是：
Spec 从“给人看的需求文档”，升级为 Agent 可以读取、执行和验证的工程契约。
2. 术语和方法的关系
2.1 Vibe Coding
Vibe Coding 是一种以自然语言对话驱动代码生成的工作方式。它的关键特征是：
- 先描述目标，再快速生成代码。
- 通过连续对话迭代结果。
- 初期不一定完整理解所有实现细节。
- 适合探索、原型和低风险自动化。
它不是完整的软件工程生命周期，也不是质量保证方法。
适合场景
- UI 方案探索。
- 一次性脚本。
- 技术选型验证。
- Demo 和 PoC。
- 低风险页面调整。
- 还没有稳定需求的早期发散。
不适合直接作为生产流程的场景
- 支付、订单、权限、登录。
- 数据迁移和资金相关逻辑。
- 复杂状态机。
- 跨端兼容逻辑。
- 多服务事务。
- 需要审计和回滚的核心功能。
- 任何“看起来能运行”但验收标准不清晰的改动。
正确的定位是：
Vibe Coding = 探索模式 / 交互模式
不是完整的生产交付方法
2.2 SDD 与 Spec
SDD（Spec-Driven Development） 是以规格为中心的开发方式。规格优先于实现，代码需要满足规格定义的行为。
一个生产级 Spec 不应该只写功能描述，还应该包含：
- 背景和问题。
- 用户价值。
- 功能范围。
- 非目标（Non-goals）。
- 不可妥协的约束（Constraints）。
- 正常场景。
- 异常场景。
- 边界条件。
- 可测量的成功标准。
- 验收条件。
- 兼容性和迁移要求。
- 风险、依赖和假设。
SDD 的核心作用是降低以下风险：
需求歧义
→ 实现方向漂移
→ Agent 自行补全假设
→ 代码快速增加
→ 测试无法判断对错
通过 Spec 把链路变成：
业务意图
→ 可验证行为
→ 技术设计
→ 可执行任务
→ 代码和测试
2.3 Agentic Software Engineering
Agentic Software Engineering 不是“使用一个聊天机器人写代码”，而是让一个或多个 Agent 在工具、上下文、任务和验证机制的约束下，执行跨文件、跨步骤、可恢复的软件工程任务。
典型能力包括：
- 读取仓库和工程规则。
- 分析依赖关系。
- 生成实施计划。
- 修改多个文件。
- 执行测试、构建和静态检查。
- 根据失败输出继续修复。
- 更新任务状态和变更记录。
- 创建提交或 Pull Request。
- 在遇到不确定性时暂停并请求决策。
它的关键不是“模型一次生成多少代码”，而是：
Agent 是否能在受控环境中持续完成一个有验收条件的工程任务。
2.4 Context Engineering
Context Engineering 关注的是：
Agent 在某一个执行步骤中，需要看到什么信息，才能做出正确判断？
上下文包括但不限于：
- 项目规则。
- 目录结构。
- 当前模块实现。
- 相关 API 和数据模型。
- 架构决策。
- 历史变更。
- 当前任务和依赖。
- 测试命令。
- 生产限制。
- 平台差异。
- 之前的失败和已知问题。
它和 Prompt Engineering 的差异如下：
| 对比项 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注对象 | 一次提示词 | Agent 的连续工作状态 |
| 主要动作 | 优化措辞 | 组织、加载、压缩和更新上下文 |
| 典型载体 | Prompt | 规则、文档、代码、任务、工具、日志 |
| 主要风险 | 回答不理想 | Agent 误解项目、重复犯错或越界修改 |
| 工程手段 | 模板和示例 | 仓库结构、索引、检索、规则、门禁 |
2.5 Harness Engineering
Harness 是 Agent 的工程执行环境。它不等同于某一个 Agent，也不等同于 Prompt。
一个 Harness 通常包含：
- Agent 可以使用的工具。
- 工具的参数和权限。
- 工程规则和上下文入口。
- 测试、构建、lint 和格式化命令。
- 沙箱、容器或隔离 Worktree。
- 任务状态和恢复机制。
- 自动化质量门禁。
- 日志、指标和审计记录。
- 失败分类和重试策略。
如果没有 Harness，Agent 只能“生成代码”；有了 Harness，Agent 才可能稳定地“完成工程任务”。
2.6 Eval-Driven Development
Eval-Driven Development 是以评估集、指标和失败分析驱动开发迭代。
传统测试主要判断：
代码是否满足已知断言
AI 系统还需要判断：
Agent 是否选择了正确工具？
是否遵循了项目规则？
是否在边界条件下做出正确决策？
是否输出可接受的业务结果？
成本、延迟和稳定性是否达标？
评估应当在开发早期建立，而不是等到上线后才发现无法判断质量。
2.7 Orchestration
Orchestration 是对多个 Agent、任务、工作区和验证流程的调度。
它解决的问题不是“一个 Agent 能不能写代码”，而是：
- 哪些任务可以并行。
- 哪些任务有严格依赖。
- 每个 Agent 修改哪些文件。
- 如何避免不同 Agent 互相覆盖。
- 如何汇总测试结果。
- 如何把完成的变更交给人工审查。
- 如何在 Agent 失败后恢复。
多 Agent 不一定优于单 Agent。只有当任务边界清晰、写入范围互斥、接口契约稳定时，并行才有价值。
3. 从 Vibe Coding 到 Agentic SDLC 的演进
3.1 第一阶段：Vibe Coding
人：描述目标
Agent：生成代码
人：继续描述修改
Agent：继续修改
优点：速度快、反馈快、适合发散。
缺点：
- 需求和实现混在一起。
- Agent 的假设没有显式记录。
- 代码可能逐渐偏离真实目标。
- 很难恢复被中断的任务。
- 很难判断“完成”到底意味着什么。
- 质量依赖使用者的即时判断。
3.2 第二阶段：Spec-Driven Development
需求
→ Spec
→ Plan
→ Tasks
→ Implement
→ Verify
SDD 解决了 Vibe Coding 的主要问题：
- 先明确行为，再决定实现。
- 让验收条件可追踪。
- 让任务可以中断、恢复和交接。
- 让代码审查有稳定参照物。
但单纯 SDD 仍然可能有不足：
- 文档写得很好，但 Agent 看不到真实仓库约束。
- Spec 和代码可能逐渐漂移。
- 任务完成不代表业务结果正确。
- 测试、工具权限和部署环境没有被纳入方法。
3.3 第三阶段：Agentic SDLC
当前更完整的流程是：
Explore / Assess
→ Context
→ Spec / Contract
→ Research / Design
→ Tasks
→ Agent Execute
→ Test / Eval
→ Human Review
→ Deploy / Observe
→ Feedback
变化有四个：
- Spec 之前增加 Explore / Assess：先判断问题和范围。
- Spec 旁边增加 Context：让 Agent 理解真实工程环境。
- Implement 旁边增加 Harness：把工具、权限、命令和质量门禁组合起来。
- 发布之后增加 Observe / Feedback：让生产数据反哺 Spec、规则和评估集。
3.4 当前推荐的心智模型
Vibe Coding = 快速发散
SDD = 固化意图
Agentic Coding = 执行任务
Context = 提供正确知识
Harness = 控制执行环境
Eval = 判断质量
Human Review = 处理高风险判断
Observability = 反馈真实结果
4. 推荐的完整 AI 开发流程
4.1 阶段 0：Explore / Assess
阶段目标：Explore / Assess
在写代码和正式写 Spec 之前，确认问题、价值、范围和风险。
Agent 应完成
- 阅读用户输入和已有上下文。
- 扫描相关代码、文档、接口和测试。
- 找出相似实现和潜在复用点。
- 列出不确定性和需要确认的问题。
- 评估变更影响面。
- 给出“实现、澄清、拒绝或延期”的建议。
人应决定
- 这个问题是否值得解决。
- 成功指标是什么。
- 哪些范围不做。
- 哪些风险必须由人确认。
- 是否允许 Agent 继续进入规划阶段。
推荐输出
exploration.md
assessment.md
questions.md
阶段出口条件：Explore / Assess
- 问题描述不再依赖模糊词。
- 已识别主要依赖和影响面。
- 已列出需要人工决策的问题。
- 已明确是否进入 Spec 阶段。
4.2 阶段 1：建立上下文和工程宪法
阶段目标：上下文和工程宪法
为 Agent 提供稳定、可发现、分层加载的工程事实。
推荐上下文内容
项目定位
目录结构
模块边界
运行命令
测试命令
代码规范
安全规范
平台差异
架构决策
不可修改范围
发布和回滚规则
工程宪法的特点
- 规则必须可执行或可验证。
- 规则应该少而稳定，避免变成无效长文。
- 规则中要说明“为什么”，尤其是反直觉约束。
- 规则不能替代 Spec，项目规则回答“怎么做”，Spec 回答“要实现什么”。
- 规则应该通过 lint、CI、脚本或测试尽可能自动化。
阶段出口条件：上下文和工程宪法
- Agent 知道从哪里读取规则。
- Agent 知道如何启动、测试和构建项目。
- Agent 知道哪些目录和文件不能随意修改。
- Agent 知道平台、环境和安全边界。
4.3 阶段 2：编写 Spec / Contract
阶段目标：Spec / Contract
把用户目标转成不依赖具体实现、但可以被验证的系统行为。
Spec 的推荐结构
# 功能名称
## 背景
## 用户价值
## 目标
## 非目标
## 约束
## 用户场景
## 功能需求
## 非功能需求
## 状态和异常
## 验收标准
## 兼容性
## 风险和依赖
## 未决问题
需求应该可验证
不推荐：
系统要有良好的支付体验。
推荐：
当用户从第三方支付页面返回时，系统必须根据 requestId 查询服务端支付状态；
在服务端确认成功前，客户端不得展示“支付完成”；
重复返回同一 requestId 时不得重复创建订单或重复发放权益。
推荐使用场景格式
### Requirement: 支付回调可恢复
系统必须在第三方页面返回后恢复支付流程。
#### Scenario: 用户从支付页返回
- WHEN 用户从第三方支付页面回到业务页面
- THEN 客户端根据 requestId 查询服务端最终状态
- AND 在查询完成前展示明确的恢复中状态
- AND 不依赖一次性内存事件作为唯一结果通道
#### Scenario: 重复返回相同 requestId
- WHEN 同一个 requestId 被重复消费
- THEN 服务端状态查询必须保持幂等
- AND 客户端不得重复提交订单完成动作
阶段出口条件：Spec / Contract
- 没有未处理的关键澄清项。
- 需求没有把实现细节误写成业务目标。
- 每个核心需求至少有一个正常场景和一个异常场景。
- 成功标准可以被测试或评估。
- 非目标和约束已经明确。
4.4 阶段 3：Research / Plan / Design
阶段目标：Research / Plan / Design
在不修改业务代码之前，确定实现策略和架构边界。
Research 要回答
- 当前项目已有何种实现。
- 是否存在可以复用的抽象。
- 当前依赖和平台是否支持目标能力。
- 有哪些可行方案。
- 方案之间的成本、风险和兼容性差异。
- 哪些事实需要通过实验验证。
Design 要回答
- 数据如何流动。
- 状态如何转移。
- 接口契约是什么。
- 失败如何恢复。
- 如何保证幂等。
- 哪些模块允许修改。
- 哪些行为必须保持不变。
- 如何测试和回滚。
推荐设计格式
# 技术设计
## 当前状态
## 目标状态
## 目标与非目标
## 关键决策
## 数据流 / 状态流
## 接口与数据契约
## 文件和模块影响面
## 失败处理与恢复
## 安全与权限
## 测试策略
## 发布与回滚
## 风险、权衡与未决问题
阶段出口条件：Research / Plan / Design
- 关键方案已经有人确认。
- 设计和 Spec 没有互相矛盾。
- 失败、重试、幂等、回滚都有说明。
- 任务可以从设计中直接拆出。
4.5 阶段 4：拆解 Tasks 和建立执行边界
阶段目标：Tasks 和执行边界
把设计转成 Agent 可以独立执行、验证和恢复的任务。
好任务的特征
- 修改范围有限。
- 有明确的前置依赖。
- 有明确的完成条件。
- 有可执行的验证命令。
- 不需要 Agent 自行补充重大业务决策。
- 完成后可以独立提交或回滚。
推荐任务格式
## 1. 类型和状态模型
- [ ] 1.1 增加支付状态类型
- 修改范围：src/domain/payment/types.ts
- 完成条件：覆盖待支付、处理中、成功、失败、未知状态
- 验证：npm run typecheck
- [ ] 1.2 增加状态归一化函数
- 修改范围：src/domain/payment/normalize-status.ts
- 完成条件：未知服务端状态进入安全兜底分支
- 验证：npm run test -- payment-normalize
## 2. 页面恢复
- [ ] 2.1 增加页面恢复入口
- 前置依赖：1.1、1.2
- 完成条件：页面重新激活时可恢复未完成支付
- 验证：npm run test -- payment-recovery
是否需要为每个任务创建独立 Worktree
| 情况 | 建议 |
|---|---|
| 单人、小改动 | 当前分支直接执行即可，但必须保持 diff 可控 |
| 多 Agent 并行 | 每个 Agent 使用独立 Worktree |
| 高风险迁移 | 独立分支和独立验证环境 |
| 只读分析 | 不需要创建 Worktree |
| 需要反复试验 | 使用临时分支或沙箱 |
阶段出口条件：Tasks 和执行边界
- 任务顺序和依赖关系清晰。
- 每个任务都有验证方式。
- 已定义 Agent 的文件写入范围。
- 已定义暂停条件。
- 已定义哪些情况必须回到 Spec 或 Design 修改。
4.6 阶段 5：Agentic Implementation
推荐执行循环
选择任务
↓
读取任务、Spec、Design 和项目规则
↓
检查当前代码和工作区
↓
实现最小变更
↓
运行针对性验证
↓
分析失败
↓
更新任务状态和变更记录
↓
进入下一个任务或暂停
Agent 每个任务开始前必须确认
当前变更名称
当前任务编号
前置任务是否完成
允许修改的文件
不能改变的行为
验收标准
验证命令
暂停条件
Agent 不应自行猜测的事项
- 业务规则存在冲突时的最终选择。
- 破坏性 API 是否可以接受。
- 是否可以扩大修改范围。
- 是否可以删除旧逻辑。
- 安全策略是否可以放宽。
- 失败时是否可以吞掉错误。
- 测试无法运行时是否可以直接标记完成。
- 真实设备、生产数据或第三方状态是否已经确认。
标记任务完成的条件
只能在以下条件同时满足时标记完成：
- 需求行为已实现。
- 任务范围内的代码已经自检。
- 针对性测试或替代验证已执行。
- 没有已知的未处理错误。
- 任务文件和 File List 已同步。
- 没有偷偷吸收超出 Spec 的额外工作。
4.7 阶段 6：Test / Eval / Verify
目标
验证的不只是“代码能运行”，还包括：
- 是否满足 Spec。
- 是否满足边界条件。
- 是否引入回归。
- Agent 是否遵循工程规则。
- 输出是否满足业务质量。
- 成本、延迟和稳定性是否达标。
推荐验证顺序
格式和空白检查
→ 类型检查
→ 单元测试
→ 组件 / 集成测试
→ 构建
→ 静态分析
→ 安全检查
→ 端到端测试
→ 评估集
→ 人工验收
不是所有项目都必须有所有层级，但每个项目都应该明确：
本项目哪些检查是强制门禁？
哪些检查只能提供参考？
哪些检查需要真实设备或真实环境？
Test 和 Eval 的区别
| 类型 | 关注点 | 示例 |
|---|---|---|
| Unit Test | 函数和模块行为 | 状态归一化、权限判断 |
| Integration Test | 模块协作 | 页面、Store、API 协作 |
| E2E Test | 用户完整流程 | 登录、支付、下单 |
| Contract Test | 服务和接口契约 | 请求、响应、错误码 |
| Property Test | 不变量 | 幂等、单调性、状态约束 |
| Regression Test | 已修复问题 | 历史缺陷不能复现 |
| Agent Eval | Agent 决策和工具使用 | 是否读取规则、是否正确调用工具 |
| Production Eval | 真实运行质量 | 成功率、延迟、成本、告警 |
验证结果必须分类
代码缺陷
测试缺陷
需求歧义
设计缺陷
环境问题
依赖问题
工具链问题
真实设备 / 真实服务未验证
不能把所有失败都归因于 Agent，也不能把“命令成功退出”当成真实业务验收完成。
4.8 阶段 7：Human Review / Merge
人工审查不应该重复 Agent 已经做好的机械工作，而应重点关注：
- 需求是否被正确理解。
- 业务边界是否正确。
- 是否引入安全风险。
- 是否改变了不应改变的行为。
- 是否存在隐含的数据一致性问题。
- 是否需要补充测试和监控。
- 是否满足发布和回滚条件。
推荐 Review 顺序
先看 Spec 和验收标准
↓
再看 Design 和影响范围
↓
再看任务完成情况
↓
最后看代码 diff
只从代码 diff 开始，容易陷入“代码看起来合理，但实际做错需求”的问题。
4.9 阶段 8：Deploy / Observe / Learn
发布不是流程终点。
需要观察：
- 核心业务成功率。
- 错误率和异常类型。
- 延迟、吞吐和资源消耗。
- Agent 工具调用失败率。
- Token 和模型成本。
- 用户行为和转化指标。
- 回滚次数。
- 人工干预次数。
- 需求、文档和实现是否出现漂移。
生产反馈应反哺：
- Spec。
- 验收场景。
- 回归测试。
- Agent 规则。
- 架构决策。
- 评估集。
- 监控和告警。
推荐形成闭环：
线上事件
→ 缺陷或新约束
→ 更新 Spec / Eval / Rule
→ 修复实现
→ 回归验证
→ 再次发布
5. 核心产物设计
5.1 Proposal
Proposal 解决“为什么需要这个变更”。
# Proposal: <变更名称>
## Why
- 当前问题是什么？
- 对用户、业务或工程的影响是什么？
## What Changes
- 新增什么？
- 修改什么？
- 删除什么？
- 哪些是破坏性变更？
## Non-Goals
- 明确本次不做什么。
## Impact
- 受影响的模块、接口、数据、部署和文档。
## Alternatives
- 考虑过哪些替代方案？
- 为什么不采用？
## Approval
- 决策人：
- 决策日期：
- 状态：Draft / Approved / Rejected / Archived
5.2 Spec
Spec 解决“系统必须表现成什么样”。
# Spec: <功能名称>
## Background
## Goals
## Non-Goals
## Constraints
## Actors
## User Scenarios
## Functional Requirements
### Requirement: <需求名称>
系统必须……
#### Scenario: <场景名称>
- WHEN ……
- THEN ……
- AND ……
## Non-Functional Requirements
- 性能：
- 可用性：
- 安全：
- 可观测性：
- 兼容性：
## State Model
## Error Handling
## Acceptance Criteria
- [ ] ……
## Dependencies and Assumptions
## Open Questions
5.3 Design
Design 解决“准备如何实现”。
# Design: <功能名称>
## Current State
## Target State
## Goals / Non-Goals
## Architecture Decisions
### Decision: <决策名称>
- 选择：
- 原因：
- 放弃的替代方案：
- 风险：
## Data Flow
## State Transitions
## API and Data Contracts
## Module Boundaries
## Failure and Recovery
## Idempotency
## Security
## Compatibility
## Test Strategy
## Rollout and Rollback
## Open Questions
5.4 Tasks
Tasks 解决“具体先做什么”。
# Tasks: <功能名称>
## Execution Rules
- 任务必须按依赖顺序执行。
- 遇到需求、设计或范围冲突时暂停。
- 未执行验证时不得勾选完成。
## 1. Foundation
- [ ] 1.1 <任务描述>
- 依赖：无
- 修改范围：
- 完成条件：
- 验证：
## 2. Core Behavior
- [ ] 2.1 <任务描述>
- 依赖：1.1
- 修改范围：
- 完成条件：
- 验证：
## 3. Verification
- [ ] 3.1 增加回归测试
- 依赖：2.1
- 验证：
## Completion Summary
- 完成任务：
- 未完成任务：
- 验证命令：
- 已知限制：
5.5 Verification
Verification 解决“实际验证了什么”。
# Verification: <功能名称>
## Scope
## Commands
| 检查 | 命令 | 结果 | 备注 |
| --- | --- | --- | --- |
| Diff check | `git diff --check` | PASS / FAIL | |
| Typecheck | `npm run typecheck` | PASS / FAIL / BLOCKED | |
| Unit test | `npm run test -- <pattern>` | PASS / FAIL | |
| Build | `npm run build` | PASS / FAIL / BLOCKED | |
| E2E | `<command>` | PASS / FAIL / NOT RUN | |
## Acceptance Matrix
| 验收条件 | 验证方式 | 结果 | 证据 |
| --- | --- | --- | --- |
| …… | 单元测试 | PASS | 测试文件 |
## Failures
### <失败项>
- 类型：代码 / 测试 / 环境 / 工具链 / 未验证
- 现象：
- 原因：
- 处理：
## Real-Device / Production Boundary
- 是否完成真实设备验证：
- 是否完成真实第三方服务验证：
- 是否完成生产或预发布验证：
5.6 Decision Log
Decision Log 用于记录重要决策，防止 Agent 在后续会话中重新讨论已经确定的问题。
# Decision Log
## ADR-001: <决策标题>
- 日期：2026-09-03
- 状态：Accepted
- 背景：
- 决策：
- 选择原因：
- 影响：
- 后续验证：
6. 一套可直接落地的目录结构
6.1 小型项目
project/
├── AGENTS.md
├── docs/
│ ├── architecture.md
│ ├── decisions/
│ └── changes/
│ └── 2026-09-feature-name/
│ ├── proposal.md
│ ├── spec.md
│ ├── design.md
│ ├── tasks.md
│ └── verification.md
├── src/
├── tests/
└── package.json
6.2 中大型项目
project/
├── AGENTS.md
├── .agent-context/
│ ├── core.md
│ ├── architecture.md
│ ├── frontend.md
│ ├── backend.md
│ ├── security.md
│ └── testing.md
├── docs/
│ ├── product/
│ ├── architecture/
│ ├── decisions/
│ ├── contracts/
│ ├── specs/
│ ├── plans/
│ └── changes/
│ └── <change-id>/
│ ├── proposal.md
│ ├── spec.md
│ ├── design.md
│ ├── tasks.md
│ ├── verification.md
│ └── decision-log.md
├── apps/
├── packages/
├── services/
├── tests/
└── scripts/
6.3 OpenSpec 风格的变更目录
openspec/
├── specs/
│ └── <domain>/
│ └── spec.md
├── changes/
│ └── <change-name>/
│ ├── proposal.md
│ ├── design.md
│ ├── tasks.md
│ └── specs/
│ └── <domain>/
│ └── spec.md
└── config.yaml
其中：
specs/表示当前系统行为的事实来源。changes/表示尚未归档的变更提案。- 变更完成并合并后，再把有效变更归档回当前规格。
7. Agent 的职责边界与人机分工
7.1 推荐职责划分
| 工作 | Agent | 人 |
|---|---|---|
| 扫描代码和文档 | 主责 | 监督 |
| 生成探索报告 | 主责 | 判断是否可信 |
| 识别影响范围 | 主责 | 确认遗漏 |
| 生成 Spec 初稿 | 主责 | 批准目标和边界 |
| 技术方案对比 | 主责 | 做关键取舍 |
| 任务拆解 | 主责 | 确认粒度和优先级 |
| 常规编码 | 主责 | 监督范围 |
| 机械测试和格式化 | 主责 | 检查门禁是否合理 |
| 业务验收 | 辅助 | 主责 |
| 安全和合规决策 | 辅助 | 主责 |
| 高风险架构决策 | 辅助 | 主责 |
| 发布批准 | 提供证据 | 主责 |
| 生产事故判断 | 提供分析 | 主责 |
7.2 必须人工确认的节点
建议在以下节点保留人工 Gate：
需求是否进入开发
↓
Spec 是否批准
↓
架构和数据变更是否批准
↓
是否允许扩大任务范围
↓
是否允许破坏性变更
↓
是否允许访问敏感环境
↓
是否满足发布条件
7.3 Agent 必须暂停的条件
- Spec 中有未解决的关键歧义。
- Design 和现有代码存在冲突。
- 任务需要修改未授权的目录。
- 实现需要新增 Spec 未描述的行为。
- 测试失败原因不明确。
- 发现安全、权限或数据风险。
- 需要删除或迁移重要数据。
- 需要访问生产、真实用户数据或高权限凭据。
- 需要改变接口契约。
- 无法证明需求已经满足。
8. Context Engineering 实践
8.1 上下文分层
不建议把所有内容塞进一个超长规则文件。推荐按稳定性和作用域分层：
组织级规则
↓
仓库级规则
↓
领域级规则
↓
模块级规则
↓
当前变更 Spec / Design / Tasks
↓
当前文件和测试输出
组织级
适合放：
- 安全底线。
- 代码提交规范。
- 通用质量原则。
- 敏感信息处理方式。
仓库级
适合放：
- 项目定位。
- 包管理器和命令。
- 目录结构。
- 分支策略。
- 构建、测试、发布方式。
领域级
适合放：
- 前端规范。
- 后端规范。
- 小程序平台差异。
- 数据库规范。
- Agent 和工具调用规则。
模块级
适合放：
- 特定业务状态机。
- 模块 API。
- 不允许改变的兼容行为。
- 特殊测试方式。
变更级
适合放：
- 当前 Spec。
- Design。
- Tasks。
- 验收标准。
- 当前决策和未决问题。
8.2 AGENTS.md 的正确定位
AGENTS.md 适合作为 Agent 的项目入口，但不应承载全部知识。
推荐内容：
- 项目定位。
- 开发命令。
- 测试命令。
- 目录导航。
- 关键工程规则。
- 安全边界。
- 文档索引。
- 常见失败处理。
不推荐内容：
- 数千行重复代码规范。
- 已经在代码中可以直接推断的规则。
- 与当前项目无关的通用理论。
- 过期命令和失效链接。
- 所有历史讨论的全文复制。
好的 AGENTS.md 应该更像：
入口 + 导航 + 不可违反的规则
而不是：
项目所有知识的无结构压缩包
8.3 上下文的加载策略
任务开始时加载
- 根目录规则。
- 当前目录规则。
- 当前变更的 Proposal、Spec、Design、Tasks。
- 相关架构和决策文档。
- 当前 Git 状态。
修改某模块时加载
- 模块局部规则。
- 直接依赖模块的接口。
- 相关测试。
- 最近的变更记录。
运行验证时加载
- 测试命令。
- 环境要求。
- 真实设备或外部服务边界。
- 失败分类规则。
不应该默认加载
- 全仓库所有历史日志。
- 与当前任务无关的业务文档。
- 大量生成产物。
- 敏感配置。
- 没有经过筛选的聊天记录。
8.4 上下文质量检查
每次提交规则或文档变更前，检查：
- 规则是否存在冲突。
- 命令是否真的可执行。
- 相对链接是否有效。
- 文档是否包含过期版本。
- 示例是否泄露敏感信息。
- 是否把实现细节错误写成业务约束。
- 是否将一次性决策错误写成永久规则。
- 是否出现“必须”“始终”“绝不”等无法执行的空泛要求。
9. Harness Engineering 实践
9.1 Harness 的组成
Agent
├── Context Loader
├── Repository Reader
├── Code Search
├── Editor / Patch Tool
├── Test Runner
├── Build Runner
├── Linter / Formatter
├── Browser / Device Tool
├── MCP Tools
├── Git / Worktree
├── Permission Boundary
├── Progress Tracker
├── Review Gate
└── Audit Log
9.2 将隐性规则变成机器门禁
只在文档中写规则是不够的。可以把规则变成：
- ESLint 规则。
- TypeScript 严格检查。
- Schema 校验。
- OpenAPI 或 GraphQL 契约检查。
- Dependency Cruiser 或模块边界检查。
- Git diff 检查。
- Secret Scanner。
- License 检查。
- 单元和集成测试。
- 构建检查。
- E2E 和视觉回归。
- CI 必须通过的状态检查。
例如，不要只写：
禁止页面直接调用原生网络 API。
更好的做法是同时提供：
规则文档
+ 统一请求封装
+ ESLint 禁止列表
+ 代码搜索检查
+ CI 门禁
9.3 Agent 执行环境
最小权限原则
- 只授予当前任务需要的目录和命令权限。
- 默认禁止访问生产凭据。
- 默认不读取真实用户数据。
- 网络访问按域名和用途限制。
- 高风险命令需要人工确认。
- 删除、迁移、发布操作必须可审计。
隔离策略
| 场景 | 建议环境 |
|---|---|
| 只读分析 | 只读工作区 |
| 普通代码修改 | 独立分支或当前任务分支 |
| 多 Agent 并行 | 独立 Git Worktree |
| 依赖和脚本实验 | 临时容器或沙箱 |
| 数据迁移 | 脱敏副本和专用环境 |
| 发布验证 | 预发布环境，禁止直接使用生产写权限 |
9.4 可恢复性和幂等性
Agent 任务必须支持中断后恢复。
恢复依赖以下信息：
- 当前变更 ID。
- 当前任务 ID。
- 已完成任务。
- 当前工作区状态。
- 已修改文件列表。
- 最近一次验证结果。
- 已知失败和未决问题。
- 下一步动作。
对于支付、订单、回调、异步任务等业务，还必须在业务层保证：
- 结果先持久化，再消费。
- 重复事件可以安全处理。
- 客户端恢复不依赖一次性内存事件。
- 最终状态以服务端确认结果为准。
- 状态消费接口幂等。
- 重试不会重复发放权益或重复扣款。
这类业务不能仅依赖 Agent 记住上一次对话内容。
10. 测试、评估与质量门禁
10.1 测试和评估的分层
代码级：类型、lint、单元测试
模块级：组件、集成、契约测试
系统级：E2E、回归、性能、安全
Agent 级：规则遵循、工具选择、任务完成
业务级：成功率、转化、错误恢复
生产级：延迟、成本、稳定性、告警
10.2 AI Coding Agent 的评估维度
任务完成质量
- 是否满足所有验收条件。
- 是否覆盖异常和边界场景。
- 是否修改了正确的文件。
- 是否引入不必要的重构。
- 是否留下未处理的 TODO。
工程纪律
- 是否读取项目规则。
- 是否遵守命名和类型约束。
- 是否通过测试、lint 和构建。
- 是否更新任务和变更记录。
- 是否在不确定时暂停。
代码质量
- 设计是否符合当前架构。
- 抽象是否过度或不足。
- 是否正确处理错误和资源释放。
- 是否保证幂等性和一致性。
- 是否增加了可观测性。
成本和效率
- 总 token 消耗。
- 运行时长。
- 工具调用次数。
- 重试次数。
- 人工干预次数。
- 一次完成率。
- 回滚率。
10.3 红绿验证循环
对于核心逻辑，推荐使用明确的红绿循环：
先定义验收场景
↓
写出测试或评估
↓
确认失败或未实现
↓
实现最小代码
↓
运行验证
↓
重构和补充边界
需要注意：严格 TDD 是一种可选的工程策略，但对关键领域强制“先有可执行验收再实现”通常更稳。并不是所有 UI 探索、一次性脚本都需要先写完整测试。
10.4 失败分类
| 失败类型 | 示例 | 处理方式 |
|---|---|---|
| 需求失败 | Spec 无法解释两种行为 | 回到 Explore / Spec |
| 设计失败 | 当前架构无法支持目标 | 更新 Design |
| 实现失败 | 代码不满足测试 | 修复实现 |
| 测试失败 | 测试断言错误或环境缺失 | 修复测试或补充环境 |
| 工具链失败 | 依赖、脚本或构建工具异常 | 单独记录，不误判为业务失败 |
| 环境失败 | 网络、设备、第三方服务不可用 | 标记未验证或阻塞 |
| 业务验证失败 | 代码通过但真实流程不符合预期 | 补充 E2E / 生产评估 |
11. 多 Agent 和并行开发
11.1 适合并行的任务
- 互不重叠的模块修改。
- 前端和后端分别实现稳定契约。
- 测试补充和文档补充。
- 独立的调研任务。
- 不同方案的 PoC。
- 不同平台的适配，但共享契约已经确定。
11.2 不适合并行的任务
- 多个 Agent 同时修改同一个核心文件。
- 需求尚未明确的功能。
- 数据模型尚未确定的上下游实现。
- 共享状态机的连续修改。
- 需要频繁改变公共接口的任务。
- 多个 Agent 同时决定架构方向。
11.3 推荐并行模型
主 Agent：维护 Spec、Design、任务依赖和最终集成
├── Agent A：领域模型和服务端契约
├── Agent B：前端状态和页面实现
├── Agent C：测试、Mock 和回归用例
└── Agent D：文档、监控和发布配置
每个 Agent 都应该拥有：
- 独立 Worktree。
- 明确的写入范围。
- 明确的输入契约。
- 明确的输出文件。
- 明确的验证命令。
- 明确的回传格式。
11.4 主 Agent 的集成职责
主 Agent 不能只做文件合并，还需要检查：
- 各分支是否实现了同一个 Spec。
- 接口和类型是否一致。
- 测试是否覆盖跨模块行为。
- 是否出现重复实现。
- 是否有任务被“看似完成”但实际上延期。
- 是否需要更新 Design 或 Decision Log。
12. 工具和方法选择
12.1 GitHub Spec Kit
核心流程（Spec Kit）
/specify
→ /plan
→ /tasks
→ /implement
典型产物
specs/<feature>/
├── spec.md
├── research.md
├── plan.md
├── data-model.md
├── contracts/
├── quickstart.md
└── tasks.md
适用场景（Spec Kit）
- 希望规格优先。
- 需要完整的规划和任务拆解。
- 新功能、新产品或复杂变更。
- 需要可追溯的工程流程。
- 希望统一不同 Coding Agent 的执行方式。
不适合
- 一行配置修复。
- 极小的样式调整。
- 需求和影响面都非常简单的变更。
当前判断（Spec Kit）
Spec Kit 是“结构化 SDD + Agent 执行”的代表。它不是 SDD 的替代品，而是将 SDD 变成可执行工作流的一种实现。
12.2 OpenSpec
核心流程（OpenSpec）
/opsx:explore
→ /opsx:propose
→ /opsx:apply
→ /opsx:archive
其中 propose 通常生成：
proposal.md
specs/
design.md
tasks.md
适用场景（OpenSpec）
- 存量项目持续变更。
- 希望区分当前系统规格和待合并变更。
- 需要 delta spec。
- 想要比完整产品流程更轻量的 SDD。
- 需要在多个 Coding Agent 之间交接变更。
当前判断（OpenSpec）
OpenSpec 更偏向“变更管理型 SDD”。它强调：
当前事实
+ 变更提案
+ 可审查设计
+ 可跟踪任务
+ 完成后归档
12.3 BMAD Method
当前阶段
Analysis
→ Planning
→ Solutioning
→ Implementation
典型工作流
产品探索 / 调研
→ PRD / UX / SPEC
→ Architecture
→ Epics / Stories
→ Sprint Planning
→ Build
→ Code Review
→ Retrospective
适用场景（BMAD Method）
- 中大型产品。
- 产品、UX、架构、开发需要连续协作。
- 需要 Epic、Story 和 Sprint 管理。
- 需要多角色 Agent。
- 需要完整的从产品到交付流程。
当前命令注意事项
BMAD 的旧教程可能仍然使用 create-story、dev-story 等命令。当前 v6 方向已经将 bmad-build 作为实现阶段的统一入口，推荐以当前仓库文档和变更记录为准，不要机械照搬旧教程。
12.4 如何选择
| 场景 | 推荐流程 | 原因 |
|---|---|---|
| 原型和探索 | Vibe Coding | 需要快速发散，不值得建立完整文档 |
| 小型修复 | Lightweight Plan → Implement → Verify | 控制成本，保留最小可追溯性 |
| 存量项目功能变更 | OpenSpec 或轻量 SDD | 适合记录增量变更和兼容边界 |
| 复杂新功能 | Spec Kit | 需求、计划、任务和实现链路完整 |
| 中大型新产品 | BMAD Method | 覆盖产品、UX、架构、Sprint 和交付 |
| 多 Agent 并行 | Agentic SDLC + Harness | 需要隔离、调度、权限和质量门禁 |
| AI Agent 产品 | Eval-Driven Development | 需要评估行为、成本、延迟和稳定性 |
13. 典型项目的落地模板
13.1 小型修复
适用于：
- 单文件修复。
- 低风险样式或文案变更。
- 已经明确的类型错误。
- 已有测试覆盖的局部 Bug。
1. 读取规则和当前 diff
2. 定位代码和测试
3. 写 3 至 5 行实施计划
4. 修改最小范围
5. 运行针对性测试和 git diff --check
6. 人工确认 diff
推荐产物：
commit message
verification note
不需要为每一行改动建立完整 PRD。
13.2 中型业务功能
适用于：
- 多文件修改。
- 页面、状态和接口联动。
- 需要处理异常和恢复。
- 需要新增测试。
推荐流程：
Explore
→ proposal.md
→ spec.md
→ design.md
→ tasks.md
→ Agent 执行
→ verification.md
→ Review
推荐要求：
- Spec 先于代码。
- 任务按依赖顺序执行。
- 每个任务都运行局部验证。
- 页面状态不能替代服务端最终状态。
- 关键事件要考虑重复、乱序、丢失和恢复。
13.3 大型新产品
推荐使用：
Discovery
→ Product Brief
→ PRD
→ UX
→ SPEC
→ Architecture
→ Epics
→ Stories
→ Sprint Planning
→ Build
→ Review
→ Eval
→ Release
→ Retrospective
必须提前建立：
- 产品目标和非目标。
- 领域模型。
- 系统边界。
- 架构决策记录。
- 接口契约。
- 验收场景。
- 评估集。
- 发布和回滚策略。
- 可观测性指标。
13.4 多 Agent 并行项目
推荐流程：
主 Agent 建立 Spec 和 Design
↓
拆分互斥任务
↓
每个任务分配独立 Worktree
↓
Agent 执行并运行局部验证
↓
主 Agent 集成和跨模块验证
↓
统一 Review
↓
合并和发布
不要让多个 Agent 直接共享同一个未提交工作区。
14. 前端和多端项目的特殊约束
14.1 前端项目
Agent 修改前应明确：
- React、Vue 或其他框架版本。
- 状态管理方式。
- 请求封装位置。
- 路由和权限边界。
- 样式组织方式。
- 组件 Props 和事件命名规范。
- 测试和构建命令。
- SSR、CSR、预渲染或边缘运行时限制。
14.2 小程序和跨端项目
必须在 Spec 和 Design 中明确平台：
微信小程序
支付宝小程序
H5
App
不能把一个平台的原生 API 直接套到另一个平台。
需要单独记录：
- 生命周期差异。
- WebView 行为差异。
- 支付和授权差异。
- 返回页面后的恢复机制。
- 真实设备验证边界。
- 编译器和分包差异。
- H5 与小程序的网络和域名限制。
14.3 支付和认证类流程
这类流程应该采用：
业务结果先持久化
→ 页面恢复
→ 服务端确认
→ 幂等消费
→ UI 展示
不要把关键业务结果只放在：
- 一次性 EventBus 事件。
- 页面内存变量。
- 某次组件回调。
- WebView 关闭时的瞬时消息。
关键结果必须能够在页面重建、生命周期切换、重复回调和网络重试后恢复。
14.4 真实设备边界
以下验证不能被“代码检查通过”替代：
- 真机授权弹窗。
- 系统返回和页面重载。
- WebView 回跳。
- 第三方支付或认证回调。
- 不同平台的生命周期。
- 弱网、杀进程和恢复。
- 设备权限和系统版本差异。
文档中应该明确记录：
静态检查通过 ≠ 真机验收通过
构建成功 ≠ 第三方业务链路成功
单元测试通过 ≠ 多端生命周期正确
15. 安全、权限和供应链
15.1 Agent 权限
- 默认最小权限。
- 读写目录必须按任务范围控制。
- 生产凭据不进入上下文。
- 真实用户数据必须脱敏。
- 高风险命令必须人工确认。
- 外部网络访问必须可审计。
- 工具调用必须记录调用者、参数和结果。
15.2 代码和依赖安全
- 不接受 Agent 直接写入密钥、Token、AppSecret 或密码。
- 不把
.env、真实日志和私有接口信息写入公开文档。 - 新增依赖前检查来源、许可证、维护状态和供应链风险。
- 不为了通过测试而关闭安全校验。
- 不为了绕过 CORS、权限或类型错误而加入不受控的宽泛放行。
- 用户输入必须进行合法性校验和必要的转义或净化。
15.3 Prompt Injection 防护
读取外部内容时，不应默认相信内容中的指令。
尤其要区分：
业务数据
文档内容
第三方网页内容
仓库规则
用户明确指令
系统安全约束
外部内容可以作为待分析数据，但不能未经确认就提升权限、执行命令、上传数据或改变系统规则。
15.4 供应链和生成代码审查
Agent 生成的代码也必须经过：
- 依赖审查。
- Secret 扫描。
- License 检查。
- 静态安全分析。
- 代码所有权和许可证确认。
- 生成内容的来源和可维护性判断。
16. 常见反模式
16.1 把一条 Prompt 当成完整需求
帮我实现一个完整的订单系统
问题：范围、状态、异常、权限、幂等和验收都不清楚。
改进：先 Explore，再 Spec，再拆 Tasks。
16.2 文档很完整，但 Agent 不读取
问题：Spec 放在一个 Agent 不会主动发现的位置，执行时只看用户最后一句话。
改进：
- 在
AGENTS.md中提供文档入口。 - 当前任务明确列出上下文文件。
- 使用脚本检查文档和代码的关联。
- 让 Agent 在执行前报告已读取的上下文。
16.3 Agent 自己扩大范围
表现：
- 顺手重构无关模块。
- 修改公共组件行为。
- 删除旧逻辑。
- 更新大量依赖。
- 改动与任务无关的格式。
改进：定义允许修改范围和禁止范围；超出范围必须暂停。
16.4 只验证“能编译”
编译通过只说明语法、类型或构建链路达到某个条件，不代表：
- 需求正确。
- 状态转换正确。
- 异常恢复正确。
- 真实平台正确。
- 第三方服务成功。
- 生产指标达标。
16.5 把测试失败全部归因于 Agent
失败可能来自：
- 测试命令错误。
- 依赖没安装。
- 环境变量缺失。
- 浏览器或设备未准备。
- 基线分支本来就失败。
- 外部服务不可用。
应分类记录，避免错误修复。
16.6 多 Agent 共享一个工作区
问题：
- 文件互相覆盖。
- 测试结果无法归属。
- 回滚困难。
- 任务边界失效。
改进：独立 Worktree、明确写入范围、主 Agent 集成。
16.7 过度流程化
不是每个按钮文字修改都需要完整的 PRD、架构评审和多 Agent 编排。
推荐按风险分级：
低风险：短计划 + 局部验证
中风险：Spec + Design + Tasks + Review
高风险：完整 SDD + 多层测试 + 人工 Gate + 灰度发布
16.8 只追求 Agent 自主，不设计暂停机制
真正可靠的 Agent 不是“永远不停地执行”，而是知道何时：
- 继续执行。
- 重试。
- 回滚。
- 更新设计。
- 请求人工决策。
- 标记阻塞。
17. 团队推广路线
17.1 第 1 阶段：统一入口
先建立：
- 根目录
AGENTS.md。 - 统一开发、测试、构建命令。
- 统一变更目录。
- 统一验证记录格式。
- 统一敏感信息规则。
目标：让不同 Agent 至少能正确进入项目。
17.2 第 2 阶段：引入轻量 SDD
每个中等以上变更至少有：
proposal.md
spec.md
tasks.md
verification.md
目标：让需求、执行和验证可追踪。
17.3 第 3 阶段：建立 Harness
自动化：
- 类型检查。
- lint。
- 测试。
- 构建。
- 变更范围检查。
- Secret 扫描。
- 文档链接检查。
- 规则漂移检查。
目标：把依赖个人记忆的规则变成机器门禁。
17.4 第 4 阶段：引入 Eval
为高价值任务建立评估集：
- 典型需求。
- 历史 Bug。
- 边界场景。
- 失败案例。
- 安全案例。
- 跨端案例。
目标：用数据比较 Agent、Prompt、规则和流程的变化。
17.5 第 5 阶段：并行 Agent
只有在以下条件满足后再并行：
- 任务可拆分。
- 接口稳定。
- 写入范围互斥。
- Worktree 隔离。
- 自动验证可靠。
- 主 Agent 有集成能力。
目标：提升吞吐，而不是增加混乱。
17.6 第 6 阶段：生产闭环
收集：
- Agent 任务完成率。
- 一次通过率。
- 人工修改比例。
- 回滚率。
- 缺陷逃逸率。
- Token 成本。
- 平均完成时间。
- 测试和评估覆盖率。
目标：从“感觉 AI 提效”变成可测量的工程改进。
18. 生产检查清单
18.1 需求和 Spec
- 背景和问题清晰。
- 用户价值清晰。
- 目标和非目标清晰。
- 约束已记录。
- 正常、异常和边界场景已覆盖。
- 验收条件可验证。
- 关键歧义已解决。
18.2 上下文
- Agent 能找到项目规则。
- 开发、测试和构建命令可执行。
- 模块边界清晰。
- 相关架构决策可读取。
- 平台差异已说明。
- 未把敏感信息放入上下文。
- 文档和代码没有明显漂移。
18.3 Design 和 Tasks
- 设计方案已批准。
- 关键权衡已记录。
- 任务有依赖关系。
- 每个任务有完成条件。
- 每个任务有验证命令。
- Agent 的写入范围已定义。
- 已定义暂停条件。
18.4 实现
- Agent 读取了 Spec、Design 和项目规则。
- 只修改了任务范围内的文件。
- 没有吸收未批准的额外需求。
- 类型和错误处理完整。
- 关键业务逻辑具备幂等和恢复能力。
- 用户输入和外部数据经过校验。
- 没有硬编码敏感信息。
18.5 验证
-
git diff --check通过。 - 类型检查通过。
- 相关单元测试通过。
- 相关集成或 E2E 测试通过。
- 构建通过。
- 安全检查通过。
- 评估集通过或已记录失败。
- 基线失败与本次回归已区分。
- 真实设备和第三方服务边界已标注。
18.6 Review 和发布
- Review 先对照 Spec，再看代码。
- 高风险业务有人工批准。
- 有发布和回滚方案。
- 有监控和告警。
- 有灰度或逐步放量策略。
- 生产反馈会更新测试、Spec 或规则。
19. 结论：现在应该怎样理解 VB、SDD 和 Agent 开发
19.1 最简关系图
Vibe Coding
↓ 负责快速探索和原型
Explore / Assess
↓ 负责判断问题、范围和风险
SDD / Spec
↓ 负责固化意图、边界和验收
Plan / Design / Tasks
↓ 负责形成可执行路径
Agentic Implementation
↓ 负责跨文件、多步骤执行
Harness Engineering
↓ 负责工具、权限、规则和恢复
Test / Eval / Review
↓ 负责质量和人工判断
Deploy / Observe
↓ 负责生产闭环
Update Spec / Context / Eval
19.2 一句话版本
可以用 Vibe Coding 发散，但生产交付应进入 Agentic SDLC；SDD 是其中的规格骨架，Context 和 Harness 是执行基础，Test/Eval 是质量控制，Human Review 是高风险决策边界。
19.3 推荐的默认流程
对于大多数中小型前端和全栈项目，推荐从这套流程开始：
Explore
→ Inspect Repository
→ Proposal
→ Spec
→ Plan / Design
→ Tasks
→ Agent Implement
→ Test / Lint / Build / Eval
→ Human Review
→ Merge / Deploy
→ Observe / Update
不建议一开始就引入过重的多 Agent 编排。先把以下四件事做好，收益通常最高：
- 可读的项目上下文。
- 可验证的 Spec。
- 可恢复的 Tasks。
- 可靠的测试和质量门禁。
20. 参考资料与核对说明
以下资料均为截至 2026-09-03 访问或通过 Context7 检索到的官方项目文档、官方工程文章或官方一手资料。版本和命令会变化，实际使用前应再次核对仓库当前文档。
20.1 GitHub Spec Kit
核心流程：
specify → plan → tasks → implement
20.2 OpenSpec
核心流程：
explore → propose → apply → archive
20.3 BMAD Method
核心阶段：
Analysis → Planning → Solutioning → Implementation
20.4 Context Engineering
20.5 Harness Engineering 与 AI-native Engineering
- OpenAI：Harness Engineering
- OpenAI：Building an AI-native Engineering Team
- OpenAI：Symphony 开源 Agent 编排项目
20.6 资料使用边界
- 本文不是某个具体工具的完整命令手册。
- 工具命令、版本和目录结构可能随项目更新变化。
- 具体项目应优先使用本地仓库规则、当前版本文档和实际 CLI 输出。
- “真实设备通过”“第三方业务成功”“生产可用”等结论不能仅由静态检查或 Agent 自报完成得出。
- 本文推荐的流程是对当前公开工程实践的综合归纳，不代表存在一个被所有团队统一采用的唯一标准。