AI Coding Toolkit — 掌握每一种 AI 编程助手

实现 10 倍生产力的完整方法论，适用于 Cursor、Windsurf、Cline、Aider、Claude Code、GitHub Copilot 等工具——无需依赖特定工具的原则，处处适用。

第一阶段：快速评估 —— 你目前处于什么水平？

请在每个维度上打分（1-5 分）：

评分解读：

• 5-10 分：请阅读全部内容——你将实现 10 倍输出提升
• 11-18 分：可跳至第四阶段及以后，学习高级技巧
• 19-25 分：聚焦第八至第十阶段，掌握精通模式

第二阶段：工具选择矩阵

决策指南：何时使用哪种 AI 编程工具？

工具选择决策树

需要边打字边获得补全？
  → GitHub Copilot（可与其他工具叠加使用）

在 VS Code/IDE 中工作？
  ├─ 希望获得集成编辑体验？ → Cursor 或 Windsurf
  ├─ 希望模型灵活且透明？ → Cline
  └─ 希望配置最少、开箱即用？ → Cursor

在终端中工作？
  ├─ 希望原生支持 Git 的结对编程？ → Aider
  ├─ 希望拥有带工具的完整代理？ → Claude Code
  └─ 希望持久化自主运行的代理？ → OpenClaw

构建复杂的多文件功能？
  → Cursor Composer 或 Windsurf Cascade 或 Claude Code

需要后台自主执行任务？
  → OpenClaw（定时任务、心跳机制、多会话支持）

推荐工具组合（可叠加使用）

单人开发者：

1. GitHub Copilot（始终开启补全）
2. Cursor 或 Windsurf（主要开发环境）
3. Claude Code 或 Aider（终端代理，处理复杂任务）

团队协作：

1. GitHub Copilot（组织范围部署）
2. Cursor（主开发环境，代码库中包含 .cursorrules）
3. CI/CD 中的 AI 代码审查（自动化 PR 审查）

第三阶段：上下文工程 —— 最关键的技能

上下文决定一切。AI 输出的质量与你提供的上下文质量直接相关。

上下文层级结构（从最重要到最不重要）

1. 系统指令（.cursorrules、AGENTS.md、CLAUDE.md、.windsurfrules）
2. 显式上下文（你 @提及或添加到聊天中的文件）
3. 隐式上下文（打开的标签页、最近修改的内容、项目索引）
4. 模型知识（训练数据——对你代码库的可靠性最低）

项目规则文件模板

在项目根目录创建。文件名根据工具而定：

• Cursor：.cursorrules
• Windsurf：.windsurfrules
• Claude Code：CLAUDE.md
• Aider：.aider.conf.yml + 规范文档
• OpenClaw：AGENTS.md

# [PROJECT] — AI 编程上下文配置

## 项目概述
- 名称：[项目名称]
- 技术栈：[例如：Next.js 14 + TypeScript + Tailwind + Drizzle + PostgreSQL]
- 架构：[例如：App Router，默认使用服务端组件]
- 单体仓库：[是/否，若是，请说明结构]

## 代码规范（必须严格执行）
- 启用 TypeScript 严格模式（`tsc --noEmit --strict`）
- 函数最大 50 行，文件最大 300 行
- 每个文件只负责单一职责
- 命名规范：函数用 camelCase，类型用 PascalCase，常量用 SCREAMING_SNAKE
- 导入规范：使用命名导入，禁止默认导出
- 错误处理：显式 try/catch，使用类型化错误，禁止静默捕获

## 应遵循的设计模式
- [模式 1 及示例]
- [模式 2 及示例]
- [模式 3 及示例]

## 禁止使用的反模式（绝对不要做）
- [反模式 1]
- [反模式 2]
- [反模式 3]

## 文件结构

src/

components/ # React 组件

lib/ # 共享工具函数

server/ # 仅服务器代码

db/ # 数据库 schema + 查询

types/ # 共享 TypeScript 类型

## 测试规范
- 测试框架：[vitest/jest/pytest]
- 编写模式：AAA（Arrange, Act, Assert）
- 命名规则：`should [预期行为] when [条件]`
- 覆盖率目标：[80%+]

## 依赖项管理
- 推荐使用：[列表]
- 禁止使用：[列表，附原因]

## 常用命令
- `npm run dev` — 启动开发服务器
- `npm run test` — 运行测试
- `npm run lint` — 格式检查 + 类型校验
- `npm run build` — 生成生产版本

上下文窗口管理

80/20 法则： 80% 的上下文应为当前任务相关的具体文件或函数，20% 用于项目规范和标准。

上下文压缩技巧：

1. 总结而非粘贴 — 不要直接粘贴 500 行文件，描述其作用并只提供相关片段
2. 使用 @ 引用 — 使用 @file.ts 代替复制粘贴（工具特异性）
3. 创建参考文档 — 制作一页架构摘要，供 AI 参考
4. 清理对话历史 — 新任务开启新聊天；过时上下文 = 产生幻觉
5. 使用 tree 命令 — 向 AI 展示项目结构：tree -I node_modules -L 3

上下文刷新规则

每次新任务开始前，确保上下文干净、准确。避免旧信息干扰新请求。

每隔 5-10 条消息，检查一次：AI 是否仍在正确跟踪上下文？

如果开始出现幻觉（如错误的文件名、函数名，或做出错误假设），请开启新对话，使用全新上下文。

上下文就像牛奶，会变质。

阶段 4：代码提示工程

SPEC 框架（结构、精确性、示例、约束）

差的提示：

修复登录问题

好的提示（SPEC）：

## 结构
修复 `src/auth/login.ts` 中的身份验证流程

## 精确性
- 登录函数在用户存在时仍抛出 "用户未找到" 错误
- 错误发生在第 42 行，查询邮箱时（区分大小写匹配）
- PostgreSQL 查询使用精确匹配，但邮箱在数据库中存储为小写

## 示例
- 输入："User@Example.com" → 应匹配数据库中的 "user@example.com"
- 当前行为：返回 null
- 期望结果：返回用户记录

## 约束
- 不得更改数据库模式
- 使用 `src/utils/email.ts` 中现有的 `normalizeEmail()` 工具函数
- 添加针对不区分大小写的查找的测试用例
- 保持现有错误处理模式（抛出 AppError）

按任务类型划分的提示模板

功能实现：

在 [文件/位置] 实现 [功能]。

要求：
1. [带验收标准的需求]
2. [带验收标准的需求]
3. [带验收标准的需求]

约束：
- 遵循 [参考文件] 中的现有模式
- 使用 [特定库/方法]
- 包含对 [边缘情况] 的错误处理
- 在 [测试文件位置] 编写测试

参考：类似功能 [X] 的实现方式如下：
[paste relevant code snippet]

Bug 修复：

问题：[描述]
文件：[路径]
复现步骤：[1, 2, 3]
期望行为：[行为]
实际行为：[行为]
错误信息：[粘贴错误消息/堆栈追踪]

修复约束：
- 不得修改 [受保护区域]
- 添加回归测试
- 修复前先解释根本原因

重构：

重构 [文件/模块] 以达成 [目标]。

当前状态：[描述当前架构]
目标状态：[描述期望架构]
动机：[原因 — 性能、可读性、可维护性]

规则：
- 保持所有现有行为不变（无功能变更）
- 所有现有测试必须通过
- 分成小而可审查的提交
- 每个提交应可独立部署

代码审查：

审查以下代码的：
1. 正确性 — 逻辑错误、边界情况、竞态条件
2. 安全性 — 注入攻击、认证绕过、数据泄露
3. 性能 — N+1 查询、不必要的内存分配、缺少索引
4. 可维护性 — 命名、复杂度、测试覆盖率

需具体说明：引用行号，解释问题，提出修复建议。
跳过风格/格式问题 — 由 linter 处理。

[paste code]

阶段 5：工作流模式 — 以代理为核心的开发

模式 1：基于测试的 AI 开发（TDD-AI）

1. 先编写测试（自己完成或借助 AI）
2. 让 AI 实现能通过测试的代码
3. 运行测试 — 确保绿色
4. 让 AI 在保持测试通过的前提下进行重构
5. 自己审查最终代码

为何有效： 测试即规范。当 AI 有明确目标时，写出的代码质量更高。你也能立即发现幻觉。

模式 2：搭建 → 填充 → 审查

1. 让 AI 搭建整体架构（文件结构、接口、类型）
2. 审查并批准该架构
3. 让 AI 逐个文件填充实现
4. 逐个文件审查
5. 对完整功能进行集成测试

为何有效： 你掌握架构控制权。AI 负责重复性工作。错误在每一层被及时发现。

模式 3：对话分层

对话 1：架构讨论 → 决策文档化
对话 2：组件 A 的实现（参考架构文档）
对话 3：组件 B 的实现（参考架构文档）
对话 4：集成 + 测试

为何有效： 每个组件使用全新上下文，防止偏离。架构文档提供连续性。

模式 4：AI 合作编程（Aider/Claude Code）

1. 启动会话并加载项目上下文
2. 用自然语言描述任务
3. AI 提出变更作为 git diff
4. 在接受前逐个审查每个 diff
5. AI 使用有意义的提交信息提交
6. 你负责处理边缘情况和集成

模式 5：自主代理工作流（OpenClaw/Claude Code）

1. 以结构化格式定义任务（验收标准、约束）
2. 代理规划 → 执行 → 验证（读取文件、运行测试）
3. 代理创建 PR/分支并提交变更
4. 你审查完整的变更集
5. 根据反馈迭代

阶段 6：工具特化技巧

Cursor

Cursor Pro 技巧：

• 使用 @git 引用最近的变更
• 使用 @docs 引用官方库文档
• 创建 .cursor/rules/ 目录，按领域存放多个规则文件
• “应用”按钮可直接将聊天建议应用到代码中

Windsurf（Cascade）

Windsurf 使用技巧：

• Cascade 在多文件重构方面表现卓越——请提供完整的代码范围
• 使用“撤销流程”可回滚整个多步骤更改
• 将重要文件固定在上下文中
• 让 AI 读取终端输出的错误信息，实现自我修复

Cline

Cline 使用技巧：

• 设置使用额度以防止 API 费用失控
• 简单任务使用更便宜的模型（如 Haiku 或 GPT-4o-mini）
• 启用“差异模式”以查看应用前的具体变更内容
• 为特定任务创建指令文件

Aider

Aider 使用技巧：

• 复杂功能使用 --architect 标志（规划者 + 实现者模式）
• 使用 /drop 命令移除不需要的文件，释放上下文窗口空间
• 使用 --map-tokens 控制代码库地图大小
• 运行 aider --model claude-sonnet-4-20250514 以获得最佳代码质量

Claude Code

Claude Code 使用技巧：

• 编写详尽的 CLAUDE.md——这是你最大的杠杆点
• 复杂任务先使用“计划模式”，再进入“实现模式”
• 让 AI 自行运行测试并修正错误——不要中途打断循环
• 当上下文过长时使用 /compact 命令压缩

第七阶段：代码质量防护机制

信任但需验证检查清单

每次 AI 生成代码后，请完成以下核查：

• [ ] 逐行阅读 —— 不要盲目接受。AI 会生成看似合理实则错误的代码
• [ ] 检查导入 —— AI 经常引入不存在的模块或错误版本
• [ ] 验证函数签名 —— 参数名、类型、返回值是否正确
• [ ] 测试边界情况 —— AI 通常只优化正常流程
• [ ] 检查安全性 —— 是否存在硬编码密钥、缺少认证检查、SQL 注入风险
• [ ] 运行测试 —— 测试通过是好迹象；若无测试，应先编写测试
• [ ] 检查漂移 —— 是否修改了未要求更改的文件？
• [ ] 验证依赖项 —— 是否新增了包？这些包是否存在？是否安全？

常见 AI 代码缺陷

三重审阅法

1. 快速浏览 —— 结构是否合理？文件和方法选择是否恰当？
2. 逻辑审查 —— 每个函数是否按预期工作？边界情况是否处理？
3. 集成审查 —— 是否与现有代码库兼容？是否有破坏性变更？

第八阶段：成本优化

Token 成本意识

成本降低策略

1. 分层使用 —— 简单任务用廉价模型，复杂任务用高价模型
2. 减少上下文 —— 上下文中每个多余文件都会增加成本
3. 开启新对话 —— 长时间对话会累积昂贵的历史记录
4. 对简单任务使用自动补全 —— Copilot 采用固定费率，单位补全成本更低
5. 缓存项目上下文 —— 使用规则文件避免重复解释
6. 批量处理相关任务 —— 将关联变更集中在一次对话中完成

月度成本基准（全职开发者）

第九阶段：团队采纳

向团队推广 AI 编码工具

第 1–2 周：基础建设

• 确定主用工具（推荐 Cursor 或 Windsurf 用于团队）
• 在仓库中提交 .cursorrules / .windsurfrules 配置文件
• 组织 1 小时工作坊：讲解基础操作、提示词技巧、代码审核流程
• 制定团队规范（代码审查要求、安全规则等）

第 3–4 周：实践落地

• 每日 15 分钟“AI 成功案例”站会分享
• 开展结对编程：经验丰富的用户与新手配对
• 收集常用提示词，建立团队提示词库
• 监控并回应反馈（质量、依赖管理等问题）

第二个月：优化

• 衡量指标：提交前时间（time-to-PR）、每功能缺陷数（bugs-per-feature）、开发者满意度
• 根据团队反馈迭代 .cursorrules 配置
• 在共享文档中创建针对具体任务的提示模板
• 识别技能短板：谁使用得较好，谁需要帮助？

第三个月：系统化

• 将 AI 辅助代码审查作为 CI 流程的一部分
• 为新功能自动生成测试
• 为团队工作流定制斜杠命令 / 快捷片段（snippets）
• 每季度回顾：投资回报率（ROI）、质量指标、工具更新

团队指南模板

# AI 编码规范 — [团队名称]

## 推荐工具
- [工具1] 用于 [使用场景]
- [工具2] 用于 [使用场景]

## 规则
1. AI 生成的代码需与人工编写代码同等严格的审查标准
2. 未经批准的数据处理流程，不得将专有或客户数据粘贴至 AI 工具
3. 所有 AI 生成的测试必须审查断言质量
4. 涉及安全的代码（认证、支付、个人身份信息 PII）应采用以人为主的方法
5. 提交信息中不应提及 AI —— 对你提交的代码负责

## 质量门禁
- [ ] 类型检查通过（`tsc --noEmit --strict`）
- [ ] 所有测试通过
- [ ] 无新增警告
- [ ] 所有 AI 生成代码均经过人工审查
- [ ] 安全敏感区域由安全负责人进行复审

第十阶段：高级模式

多智能体开发架构

任务：实现功能 X

智能体 1（架构师）：规划实现方案，定义接口
智能体 2（实现者）：编写代码
智能体 3（测试者）：编写并运行测试
智能体 4（评审者）：审查质量、安全性、设计模式

协调器：统筹流程，解决冲突，保持上下文一致

自修复开发循环

1. 智能体编写代码
2. 智能体运行测试
3. 测试失败 → 智能体读取错误信息，修复代码
4. 重复直到测试通过
5. 智能体运行代码风格检查器（linter）
6. 风格检查失败 → 智能体修复
7. 全部通过 → 创建 Pull Request

提示词库模式

在项目中维护一个 prompts/ 目录：

prompts/
  feature-implementation.md
  bug-fix.md
  refactoring.md
  code-review.md
  test-generation.md
  migration.md
  documentation.md

每个文件是一个可复用的提示模板。使用时引用：“参考 prompts/feature-implementation.md 中的模板”

模型路由策略

task_routing:
  autocomplete: copilot  # 常驻模式，固定费率
  simple_edit: haiku     # 快速、低成本
  feature_impl: sonnet   # 平衡性能
  architecture: opus     # 关键任务时使用
  debugging: sonnet      # 需要理解代码逻辑推理
  documentation: haiku   # 简单转换任务
  security_review: opus  # 不容出错的高风险任务
  test_generation: sonnet # 需要理解代码逻辑

第十一阶段：反模式 —— 不该做的事

第十二阶段：评分与持续改进

AI 辅助开发质量评分（0-100 分）

每周自我审查问题

1. 本周我最出色的 AI 辅助产出是什么？它为什么好？
2. AI 在哪些地方浪费了我的时间？上下文或提示出了什么问题？
3. 我是否足够认真地审查了，还是只是草率通过？
4. 哪些提示模式效果良好？将其加入提示库。
5. 我是否对 AI 过度依赖，而忽略了本应深入理解的任务？

每月指标

• 加速因子：每日完成任务数 vs AI 使用前基线
• 缺陷率：AI 辅助代码中的缺陷数 vs 手动编写代码
• 每功能成本：API 花费 / 发布的功能数量
• 上下文效率：出现偏差前的平均对话长度
• 覆盖率：有 AI 辅助测试的代码占比

快速参考：自然语言指令

1. “为 [项目] 设置 AI 编码” —— 生成规则文件 + 工具推荐
2. “为 [任务类型] 生成提示” —— 生成符合 SPEC 框架的提示模板
3. “审查这段 AI 输出” —— 执行“信任但验证”检查清单
4. “对比 [工具 A] 与 [工具 B] 在 [使用场景] 中的表现” —— 工具选型分析
5. “优化我的 AI 编码成本” —— 分析使用情况并建议模型路由
6. “创建团队 AI 编码指南” —— 生成团队规范文档
7. “诊断为什么 AI 一直 [幻觉 X]” —— 上下文问题排查
8. “为 [功能] 设置测试驱动的 AI 工作流” —— TDD-AI 模式指导
9. “为 [项目类型] 创建提示库” —— 生成提示模板集合
10. “评估我的 AI 编码成熟度” —— 执行质量评估
11. “为 [人员] 安排 AI 编码入职培训” —— 生成培训计划
12. “审计 AI 编码安全实践” —— 生成安全审查清单