AI 编程工具
目录
AI coding
业界已有的AI编程工具按照插件、IDE、独立终端三个维度进行划分：
| 类型 | 工具名称 | 开发商 | 主要功能特点 | 支持的IDE/平台 |
|---|---|---|---|---|
| 插件 | GitHub Copilot | GitHub/Microsoft | 基于GPT-4模型的代码补全，支持多种编程语言，自动生成代码建议 | VS Code, JetBrains, Visual Studio, Neovim |
| 插件 | Codeium | Codeium | 免费AI代码补全工具，支持多种模型，提供代码生成和聊天功能 | VS Code, JetBrains, Vim, Emacs |
| 插件 | Amazon CodeWhisperer | Amazon | AWS官方AI编程助手，支持代码补全、安全扫描和代码建议 | VS Code, JetBrains, Visual Studio |
| 插件 | Tabnine | Tabnine | 企业级AI代码补全，支持私有部署，提供代码预测和自动完成 | VS Code, JetBrains, Vim, Sublime |
| 插件 | Continue | Continue.dev | 开源AI编程助手，支持多种模型，提供代码编辑和聊天功能 | VS Code, JetBrains |
| 插件 | Sourcegraph Cody | Sourcegraph | 基于代码库理解的AI助手，提供代码搜索、解释和生成功能 | VS Code, JetBrains |
| 插件 | Aider | Aider | AI代码编辑助手，支持多文件编辑和代码重构 | VS Code |
| 插件 | CodeBuddy | 腾讯 | 由腾讯混元与DeepSeek双模型驱动，支持跨IDE协作，符合等保三级要求 | VS Code, JetBrains |
| 插件 | Cursor Agent | Cursor | Cursor的VS Code插件版本，提供AI代码生成和编辑功能 | VS Code |
| IDE | Cursor | Cursor团队 | 基于VS Code的AI升级版，深度集成LLM，提供上下文感知的代码生成和调试建议 | 独立应用 |
| IDE | Cline | 开源社区 | AI驱动的代码助手，理解整个代码库，规划复杂变更并执行多步骤任务 | VS Code插件/独立版本 |
| IDE | Continue.dev | Continue.dev | 开源AI IDE，支持多种模型，提供完整的AI编程体验 | 独立应用 |
| IDE | Zed | Zed Industries | 高性能编辑器，内置AI功能，支持代码补全和编辑 | 独立应用 |
| IDE | Trae | 字节跳动 | AI原生IDE，支持中文描述生成项目结构和代码，内置GPT-4o模型 | 独立应用 |
| IDE | Codeium Chat | Codeium | Codeium的独立聊天界面，支持代码生成和问答 | 独立应用 |
| IDE | Windsurf | Codeium | AI驱动的集成开发环境，支持智能代码补全、实时错误检测、自动化调试和多语言支持 | 独立应用 |
| 命令行 | Warp | Warp | AI增强的终端工具，提供命令建议和自动补全 | 独立应用 |
| 命令行 | Aider CLI | Aider | 命令行AI代码编辑工具，支持Git集成和多文件编辑 | 终端 |
| 命令行 | Cline CLI | Cline | Cline的命令行版本，支持终端中的AI代码助手功能 | 终端 |
| 命令行 | GitHub Copilot CLI | GitHub | GitHub Copilot的命令行版本，支持终端中的代码生成 | 终端 |
| 命令行 | Cursor CLI | Cursor | Cursor的命令行工具，支持终端中的AI代码操作 | 终端 |
| 命令行 | Continue CLI | Continue.dev | Continue的命令行版本，提供终端中的AI编程功能 | 终端 |
| 命令行 | CodeBuddy CLI | 腾讯 | CodeBuddy的命令行版本，支持终端中的代码生成和编辑 | 终端 |
| 命令行 | Gemini CLI | Google Gemini的命令行工具，支持代码生成和问答 | 终端 | |
| 命令行 | Codeium CLI | Codeium | Codeium的命令行版本，支持终端中的代码补全和生成 | 终端 |
工具分类说明
插件
- 集成到现有IDE中，无需切换开发环境
- 通常提供代码补全、代码生成、代码解释等功能
- 适合希望增强现有IDE功能的开发者
IDE
- 完整的开发环境，深度集成AI功能
- 提供更丰富的AI交互体验和上下文理解
- 适合希望获得完整AI编程体验的开发者
独立终端
- 轻量级，适合终端工作流
- 通常支持脚本化和自动化
- 适合喜欢命令行操作和需要集成到自动化流程的开发者
主要工具简介
Cline
有免费模式，可选模型和响应速度比较受限
也支持购买的自定义模型
CodeBuddy
公司内部免费的推荐使用CodeBuddy, 可选各种先进模型包括Cluade, GPT, gemini等
Cursor
基于VS Code的AI升级版IDE，深度集成大型语言模型，提供上下文感知的代码生成、调试建议和自然语言重构功能。
小技巧：Ctrl+M 自动生成提交信息
Gemini CLI
Google Gemini的命令行工具，支持代码生成和问答功能。
三种模式
Ask：聊天模式
Plan：先规划后执行，类似下面介绍的规范驱动开发
Agent: 代理，自动完成编码任务
AI 编码方法
在使用 AI 辅助编程时，有多种不同的方法来指导 AI 生成代码。理解这些方法的区别和适用场景，可以帮助你更高效地与 AI 协作。
Rules（规则驱动）
Rules 是一种通过明确的规则和约束来指导 AI 生成代码的方法。这种方法强调精确性和可预测性。
特点：
– 明确性：通过具体的规则、约束和规范来指导 AI
– 可预测性：相同规则下，AI 生成的代码风格和行为相对一致
– 结构化：规则通常以列表、条件语句等形式组织
适用场景：
– 需要严格遵循代码规范和最佳实践
– 团队协作，需要统一的代码风格
– 有明确的架构约束和设计模式要求
– 需要符合特定框架或库的约定
示例：
规则：
- 使用 TypeScript，启用严格模式
- 所有函数必须有类型注解
- 使用 async/await 处理异步操作
- 错误处理使用 try-catch
- 函数名使用 camelCase，常量使用 UPPER_SNAKE_CASE
优势：
– 生成的代码质量稳定，符合规范
– 便于团队协作和代码审查
– 减少代码风格不一致的问题
局限性：
– 规则过多可能导致 AI 理解困难
– 灵活性相对较低，可能限制创造性
– 需要维护和更新规则文档
Vibe-coding（感觉驱动）
Vibe-coding 是一种通过描述代码的”感觉”、风格或整体印象来指导 AI 的方法，而不是使用严格的规则。
特点：
– 描述性：通过自然语言描述期望的代码风格和感觉
– 灵活性：不依赖严格的规则，允许 AI 有更多发挥空间
– 直观性：更容易表达难以用规则描述的设计意图
适用场景：
– 探索性编程和原型开发
– 需要快速迭代和尝试不同方案
– 代码风格要求不那么严格的项目
– 个人项目或小型项目
示例：
"写一个简洁优雅的 React 组件，感觉要现代、轻量，用 hooks 风格，
代码要易读，不要过度工程化"
优势：
– 表达方式更自然，易于沟通
– 允许 AI 有更多创造性
– 适合快速原型和探索
局限性：
– 结果可能不够一致
– 难以精确控制代码细节
– 可能不适合大型团队项目
Spec-coding（规范驱动）
Spec-coding 是一种通过详细的规范（specifications）来指导 AI 生成代码的方法，介于 Rules 和 Vibe-coding 之间。
特点：
– 详细性：提供完整的功能需求、接口定义、行为描述
– 结构化：使用结构化的方式描述需求（如用户故事、场景、测试用例）
– 完整性：不仅描述”做什么”，还描述”怎么做”和”为什么”
适用场景：
– 复杂功能的实现
– 需要详细文档和测试的项目
– 遵循规范驱动开发（Spec-Driven Development）的项目
– 需要可追溯性和可维护性的项目
示例：
需求：实现用户登录功能
规范：
- 输入：用户名和密码
- 验证：检查用户名格式（邮箱或手机号）
- 安全：密码使用 bcrypt 加密存储
- 响应：成功返回 JWT token，失败返回错误码
- 场景：
- 场景1：有效凭证 → 返回 token
- 场景2：无效凭证 → 返回 401
- 场景3：用户不存在 → 返回 404
优势：
– 生成的代码更符合需求
– 便于测试和验证
– 支持规范驱动的开发流程
– 可追溯性强
局限性：
– 需要编写详细的规范，工作量较大
– 可能过于正式，不适合快速迭代
– 需要维护规范文档
方法选择建议
| 方法 | 适用场景 | 团队规模 | 项目阶段 |
|---|---|---|---|
| Rules | 需要严格规范、团队协作 | 中大型团队 | 生产环境 |
| Vibe-coding | 快速原型、探索性开发 | 个人/小团队 | 早期阶段 |
| Spec-coding | 复杂功能、需要文档化 | 中大型团队 | 设计/开发阶段 |
最佳实践：
– 根据项目阶段和需求灵活选择方法
– 可以组合使用：用 Spec 定义功能，用 Rules 约束实现，用 Vibe 调整风格
– 在团队中建立共识，统一编码方法的使用标准
openspec 使用
// step1: install
npm install -g @fission-ai/openspec@latest
// step2: initialze projec
cd my-project
openspec init
// 按提示交互命令执行
实践分享
个人相册管理
核心功能：
1. 检查文件名称是否包括清晰的年月日信息，如果没有读取文件的信息，并重命名
2. 去重
3. 分类
codebuddy：详细的需求描述和执行步骤，基本实现了要求的功能，但有些实现细节不符合需求描述，修Bug花了不少时间
Cursor: 少量的prompt, 正确的实现了要求的功能
结论：模型和工具的选择非常重要，有时差距很大
结论
Rules + OpenSpec + MCP + SubAgents + agent skills