# 第9-15页：开发实现篇

> 章节：02 开发实现
> 核心问题：如何让 AI 听话？如何构建 AI 上下文体系？如何调用外部工具？

---

## 第9页：分隔页（02 开发实现）

### 原文内容
章节分隔页，标志进入"开发实现"部分

### 研究要点
- 这是4个核心问题中的第2个
- 开发实现是整个流程中最关键的环节
- 核心目标：让 AI 生成高质量、符合规范的代码

---

## 第10页：如何让 AI 听话 - 规则、规格、技能

### 原文内容
**三要素模型**：

| 要素 | 定义 | 示例 |
|------|------|------|
| **规则 Rules** | 约束 AI 行为的边界，定义能做什么、不能做什么 | "请做一个登录注册页面，需要能实现邮箱验证" |
| **规格 Specification** | 把模糊的需求收敛为结构化的内容，甚至通过 DSL 描述 | 用户故事 + 验收标准 |
| **技能 Skill** | 通过打包提示词、脚本、模版，进一步精确拓展 AI 的能力 | 提示词 + 规格文档 |

**规则示例（Java 代码风格）**：
```markdown
# Java 代码风格 Rules
1. 使用 Java 17 语法，不使用已废弃 API
2. 类名使用大驼峰（PascalCase），方法名和变量名使用小驼峰（camelCase）
3. 常量使用全大写下划线分隔（UPPER_SNAKE_CASE）
4. 单行代码不超过 120 字符，超过则换行
5. 大括号采用 Egyptian 风格（左括号不换行）
6. 禁止使用 @Autowired 字段注入，改用构造器注入
```

**规格示例（用户故事 + 验收标准）**：
```markdown
作为一个新用户或现有用户，我想要一个同时支持注册和登录的页面，
并且在注册时能通过邮箱完成身份验证，以便安全地创建账户并登录系统。

验收标准（AC）：
1. 用户可以输入邮箱、密码等必要信息进行注册。注册提交后，
   系统向用户邮箱发送验证链接（或验证码）。用户点击链接
  （或输入验证码）后，账户状态变为"已验证"。
2. 已验证用户可使用邮箱和密码登录系统。未验证邮箱的用户
   尝试登录时，系统提示"请先完成邮箱验证"。
3. 邮箱格式不正确或已被注册时，系统给出明确提示。验证链
   接过期或无效时，支持重新发送验证邮件。
```

### 深入解读

**规则 Rules 的本质**
- 作用：约束 AI 的行为边界
- 载体：
  - Cursor：`.cursor/rules/` 目录
  - Claude Code：`CLAUDE.md` 文件
  - OpenCode：`.opencode/config.json`
  - 通用：`AGENTS.md` 文件

**规则的分类**：
1. 代码风格规则：命名规范、格式规范
2. 架构规则：分层架构、依赖方向
3. 安全规则：敏感数据处理、权限控制
4. 性能规则：数据库查询优化、缓存策略

**规格 Specification 的价值**
- 消除歧义：将模糊需求转化为明确定义
- 可验证性：验收标准可以直接转化为测试用例
- 可追溯性：需求变更有历史记录

**规格的格式**：
1. 用户故事格式：As a... I want... So that...
2. Given-When-Then 格式：行为驱动开发（BDD）
3. 表格格式：字段清单、业务规则
4. DSL 格式：领域特定语言

**技能 Skill 的概念**
- 定义：打包的可复用能力单元
- 组成：提示词模版、脚本工具、文档模版、配置文件
- 复用性：可以在多个项目中使用

### 实践建议
- 建立规则库：将常用的规则沉淀下来
- 使用规格模版：统一需求文档格式
- 开发技能包：将常用的能力封装成技能

---

## 第11页：构建 AI 上下文体系

### 原文内容
**核心理念**：使用完整的文档来描述上下文和约束体系，区分过程方案和事实方案，减少维护成本。

**文档分层结构**：
```
AGENTS.md          ← 宪法
docs/
├── standards/     ← 标准规格（架构/命名/API/安全规范）
├── features/      ← 需求规格（产品/BA维护）
├── plans/         ← 计划规格（过程方案）
├── designs/       ← 设计规格（事实方案，Source of Truth）
└── others/        ← 架构决策、Release、测试用例等
```

**规格流转**：
- 追加（Plans）：每次创建新文件，细微修改不再更新
- 变更（Designs）：每次以最终态更新，作为下一次 Plan 的事实依据

### 深入解读

**AGENTS.md 的内容**：
```markdown
# 项目基本信息
- 项目名称：示例项目
- 技术栈：Java 17, Spring Boot 3.x, MySQL 8.0
- 代码规范：阿里巴巴 Java 开发手册

# AI 行为规则
1. 生成代码必须符合代码规范
2. 数据库表必须包含 created_at, updated_at 字段
3. API 接口必须使用 RESTful 风格
4. 敏感数据必须加密存储
```

**过程方案 vs 事实方案详细对比**

| 维度 | 过程方案（Plans） | 事实方案（Designs） |
|------|------------------|-------------------|
| 目的 | 记录实现过程 | 记录当前状态 |
| 更新方式 | 追加新文件 | 覆盖更新 |
| 生命周期 | 短期（任务完成后归档） | 长期（持续维护） |
| 维护成本 | 低（不修改旧文件） | 高（必须保持最新） |
| 使用场景 | 任务执行、问题排查 | 新功能开发、架构决策 |
| 示例 | plan-2026-06-20-feature-x.md | database-schema.md |

**Plans 最佳实践**：
- 命名规范：`plan-YYYY-MM-DD-feature-name.md`
- 内容结构：目标、方案、任务列表、状态、问题记录
- 归档策略：任务完成后移动到 `archive/` 目录

**Designs 最佳实践**：
- 命名规范：使用功能名称，如 `database-schema.md`
- 内容结构：概述、详细设计、变更历史
- 更新策略：每次变更必须更新文档，保持最新

---

## 第12页：如何让 AI 调用外部工具？

### 原文内容
**三种方式**：

**1. MCP（Model Context Protocol）**
- AI 与外部系统通信的标准协议
- 标准化接口、双向通信、即插即用
```json
{
  "mcpServers": {
    "database": {
      "command": "node",
      "args": ["mcp-server-sqlite"]
    }
  }
}
```

**2. Skills**
- 将开源工具用脚本封装成 AI 可直接调用的能力单元
- 脚本封装、触发词驱动、可复用
```markdown
# Commit & Push Skill
## 触发词: commit, push
## 执行
git add -A
git commit -m "{message}"
git push
## 规则
- 提交前检查 lint
- 信息遵循 conventional commit
```

**3. Commands（CLI）**
- 通过 CLI 命令让 AI 直接调用外部工具
- 即时执行、管道组合、权限可控
```bash
# AI 通过 CLI 调用工具
> 部署到生产环境
npm run build
npx vercel --prod
```

### 深入解读

**MCP 详解**
- Anthropic 提出的开放标准协议
- Client-Server 架构
- 常用 MCP Server：
  - 数据库：mcp-server-sqlite、mcp-server-postgres
  - 文件系统：mcp-server-filesystem
  - Web 搜索：mcp-server-brave-search
  - GitHub：mcp-server-github
  - 浏览器：mcp-server-playwright

**Skills 详解**
- 可复用的能力单元
- 组成：触发词、执行逻辑、参数、规则
- 开发流程：需求分析 → 脚本开发 → 触发词定义 → 测试验证 → 文档编写

**CLI 安全考虑**：
- 白名单机制：只允许执行特定的命令
- 沙箱环境：在隔离环境中执行
- 审计日志：记录所有执行的命令

---

## 第13页：用什么 AI 编程工具？

### 原文内容
**三类工具**：

**1. 命令行类**（AI 优先，人辅助）
- Claude Code、Codex CLI、OpenCode

**2. AI IDE**（人掌控感更强）
- Cursor、Kiro、Trae

**3. 增强插件**（预制辅助工具集）
- Superpower、oh-my-opencode、oh-my-codex

### 工具对比表

| 工具 | 类型 | 价格 | AI 模型 | 适用场景 |
|------|------|------|---------|---------|
| Claude Code | CLI | 按 Token | Claude | 复杂逻辑 |
| Codex CLI | CLI | 按 Token | GPT-4 | 快速原型 |
| OpenCode | CLI | 免费 | 多模型 | 预算有限 |
| Cursor | IDE | $20/月 | 多模型 | 日常开发 |
| Kiro | IDE | 免费+付费 | Claude | AWS 项目 |
| Trae | IDE | 免费+付费 | 豆包 | 中文项目 |

### 各工具详解

**Claude Code**
- 强大的推理能力，支持长上下文
- 内置 MCP 支持，Loop 模式
- 适合复杂逻辑开发、架构设计

**Cursor**
- 基于 VS Code，AI 优先设计
- 强大的代码补全，Composer 模式
- 适合日常开发

**Kiro（AWS）**
- 深度集成 AWS 服务
- 支持 Spec 驱动开发
- 自动化测试生成

**Trae（字节跳动）**
- 集成豆包大模型
- 中文支持好
- 适合中文项目

---

## 第14页：用什么 SDD 框架比较好？

### 原文内容
**SDD（Spec-Driven Development）框架对比**

Spec = 单一事实来源（SSoT），甚至可以直接生成代码

| 维度        | BMAD                     | Spec Kit               | OpenSpec          | Kiro               |
| --------- | ------------------------ | ---------------------- | ----------------- | ------------------ |
| 方法定位      | 企业级 SDD 操作系统             | 工程化 Spec 工作流           | 轻量 Spec 层         | IDE 原生 SDD         |
| 核心理念      | Spec = 治理体系 + 多 Agent 编排 | Spec = 开发入口 + Git 生命周期 | Spec = 变更单元（持续演化） | Spec = 可执行源（代码与测试） |
| Spec 生命周期 | 全生命周期                    | 与分支绑定（短生命周期）           | 长期存在（持续演化）        | 持续驱动               |
| Spec 粒度   | 大（系统/模块级）                | 中（Feature级）            | 小（变更/Patch级）      | 中（Feature+行为）      |
| 可执行能力     | 通过流程驱动                   | 驱动开发流程                 | 类 Prompt          | 可生成代码+测试并自动校验      |
| 流程控制      | 强（阶段+审批+Agent）           | 中（Plan→Spec→Tasks）     | 弱（自由演化）           | 强（闭环）              |
| 自动验证      | 无                        | 无                      | 弱                 | 强（内建）              |
| 与代码关系     | 间接                       | 半耦合                    | 弱耦合               | 强耦合                |
| 适用场景      | 大型系统/多团队                 | 新项目（0→1）               | 存量项目/快速迭代         | 小团队/高自动化           |
| 失控风险      | 低                        | 中                      | 高                 | 中                  |

### 框架选择指南

| 团队规模 | 项目类型  | 推荐框架     |
| ---- | ----- | -------- |
| 大型团队 | 企业级项目 | BMAD     |
| 中型团队 | 新项目   | Spec Kit |
| 小型团队 | 存量项目  | OpenSpec |
| 个人开发 | 快速迭代  | Kiro     |

---

## 第15页：一个新星：Superpower

### 原文内容
- 提供了一些内置的 skills
- 方便开箱即用
- 缺点是不太方便精细调整

### 深入解读
- 为 AI 编程工具提供增强功能的插件集合
- 内置 Skills：预制的常用能力
- 优势：快速上手、功能丰富、社区支持
- 劣势：不够灵活、黑盒、依赖性强
- 适合快速原型和学习，不适合深度定制