Update from Sync Service
This commit is contained in:
FNS Service
315
AI工程/团队级AI_Coding简明手册_逐页研究/01_开发实现_第9-15页.md
Executable file
315
AI工程/团队级AI_Coding简明手册_逐页研究/01_开发实现_第9-15页.md
Executable file
@@ -0,0 +1,315 @@
|
||||
# 第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：预制的常用能力
|
||||
- 优势：快速上手、功能丰富、社区支持
|
||||
- 劣势：不够灵活、黑盒、依赖性强
|
||||
- 适合快速原型和学习，不适合深度定制
|
||||
Reference in New Issue
Block a user