chill/chill_notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
682e3e52df5453e27fe8d48e7d28a6e3c2c30940
chill_notes/AI工程/团队级AI_Coding简明手册_逐页研究/01_开发实现_第9-15页.md
FNS Service 682e3e52df Update from Sync Service
2026-06-22 11:30:51 +08:00

11 KiB
Executable File
Raw Blame History

第9-15页：开发实现篇

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

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

原文内容

章节分隔页，标志进入"开发实现"部分

研究要点

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

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

原文内容

三要素模型：

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

规则示例（Java 代码风格）：

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

规格示例（用户故事 + 验收标准）：

作为一个新用户或现有用户，我想要一个同时支持注册和登录的页面，
并且在注册时能通过邮箱完成身份验证，以便安全地创建账户并登录系统。

验收标准（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 的内容：

# 项目基本信息
- 项目名称：示例项目
- 技术栈：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 与外部系统通信的标准协议
  • 标准化接口、双向通信、即插即用
{
  "mcpServers": {
    "database": {
      "command": "node",
      "args": ["mcp-server-sqlite"]
    }
  }
}

2. Skills

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

3. Commands（CLI）

  • 通过 CLI 命令让 AI 直接调用外部工具
  • 即时执行、管道组合、权限可控
# 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 View Git Blame Copy Permalink