Ai coding 分享

组内要做 Ai 工具的分享，在网上搜索了很多博客整理了下面的内容，各位 V 友能给点建议吗，看是否有需要修改调整的地方

Ai 模型选择
SWE-bench
个人感受：
● 除了 Claude code 和 codex ，其他工具的模型或多或少受一些限制
● claude 编程能力综合最强
● codex 中的 gpt5.2 codex high 感觉是除了 claude code 中的 opus4.5 最强的，思考时间长（但是有点太长了），找 Bug 能力不错，CodeReview 也仔细，并且也非常遵循 rules 。
● Gemini3 Pro 前端能力比较强
● GLM4.6 体验过，当时效果感觉一般。

Ai 工具选择
● claudecode: 官网的基本用不了，中转的费用也在 200 多左右。但是 Opus4.5 在 claudecode 效果确实好，并且有 skills 、subagent 、插件、斜杠命令等工具
● Codex：
○ gpt5.2codex high 模型效果不错和 Opus4.5 差距不大，并且价格便宜，无论是官网还是说中转都比 ClaudeCode 便宜，中转只要 60 元每月。思考时间长（但是有点太长了），找 Bug 能力不错，CodeReview 也仔细，一个对话窗口还挺大也能自动压缩。并且也非常遵循 rules 、skills ，也会去找相关的代码。
○ 有插件和 cli ，但是插件最新的模型好像不支持，还是主要使用 cli ，指明代码上下文没那么方便，看代码变更也没那么方便
● Cursor：
○ 需要稍微干净的魔法不然用不了 Claude 等模型（还需要考虑魔法的价格），价格也不便宜，每月 20 美刀起步套餐， 有 Team 套餐，但是好像 40 美刀起步
○ 第一次 Ai 编程首选，上手快，独一档的 Tab 。各种功能完善，使用了 cursor 后使用其他的软件感觉都没有那么舒服。迭代更新速度快。
○ 咸鱼也有按量卖的，但是规模不大，不能开票
● Augment Code：
○ 官网用不了，现在要用只能使用咸鱼按量卖的，不能开票，并且价格也不便宜
○ 插件形式效果最好的工具，独一档的上下文搜索工具：ACE
● Antigravity：
○ 需要非常纯净的美国 ip （魔法的价格就不便宜），现在 claude 的额度在减少，在网上也能经常看到吐槽
○ 有免费额度，谷歌年度 pro 也能使用信用卡白嫖，然后讲 Antigravity 的额度逆向到 claudecode 使用
● windsurf：
○ 之前使用好像不需要使用魔法，价格 15 美刀起步
○ 经常把代码块改坏然后又修复，按次收费
● Trae：
○ 不用魔法，价格便宜
○ 按次收费
● Kiro：
○ 现在 0.88 就能用 500 额度，但是使用效果一般，主要用来帮助理解代码
○ spec 模式
○ 各种小功能都非常难用：代码变更都没有做好，上下文的窗口小的离谱，压缩上下文的操作也很难受，会话不能重命名，不能渲染 mermind 图，不能排队任务
● Qoder：
○ 不用魔法，价格也好像不便宜
○ 阿里闭源模型，没用来写过需求不做评价
● OpenCode：
○ 开源的 claudecode （可以这么理解），只能使用 api ，相当于只能使用国内的 GLM4.7 。主要配合 OMO 插件使用，主要的思路还是使用多个 subagents 去执行任务，并且不同的 subagents 可以指定不同的模型。
○ 主要的优势是不用去折腾 subagents 、skills ，但是具体效果网上褒贬不一，让子弹再飞一会。


能力特性：

skills

好用的 skills
现有：doc 、excel 、pdf 、ppt 、画图、前端样式描述
可以把工作上的流程（主要还是需要重复和 Ai 说的）封装成一个个 skills ，然后让 ai 再不同的阶段去获取 skills：代码 review 、Bug 处理等

Bug 处理
当你被要求修复一个 Bug 时，请遵循以下步骤：
1. **理解问题 (Understand):** 仔细阅读 Bug 描述和相关代码，复述你对问题的理解。
2. **分析原因 (Analyze):** 提出至少两种可能的根本原因。
3. **制定计划 (Plan):** 描述你打算如何验证这些原因，并给出修复方案。
5. **执行修复 (Execute):** 实施修复。
6. **审查 (Review):** 查看自己的修改有没有问题。
7. **解释说明 (Explain):** 解释你做了哪些修改以及为什么。
8. 预防措施：如何避免再次发生

如何创建 skills
可以直接手动创建文件夹，文档、脚本、参考文件就行。或者直接让 Ai 帮忙生成，自己描述 skills 内容就行

Mcp
● Context7 MCP 、ACE 、Chrome DevTools MCP 、tapd 、apifox
Subagents （智能体，角色）
● 有点类似直接开了一个新的对话窗口，然后和主 agent 一样可以调用不同的工具然后加上一些提示词。
● 可以用来去查询信息，比如说查询业务信息，查询最新的文档，也可以去让 subagent 去使用 skills 和 MCP ，然后把处理的信息精炼后返回给主 agent ，然后去搜索的过程就不会占用主 agent 的上下文
● 主要是可以把自己经常要和 Ai 做的操作去做成 subagents （代码 review ）

斜杠命令
● 其实就是把经常要输入给 Ai 的提示词来生成命令，然后 Ai 就能获取信息

插件
SuperPowers：主要利用了 skills 和 subagents
https://github.com/obra/superpowers
https://github.com/anthropics/claude-code/blob/main/plugins/feature-dev/commands/feature-dev.md
ohmyopencode：

Cursor 的一些功能介绍
● 自定义模型：可以使用 GLM4.7
● worktree：
● 同时运行多个模型：计划或者复杂的情况
● 浏览器：内置的浏览器可以打开前端页面，然后进行调整，并且修改代码。
● 命令

编程技巧：

开发前置配置：
● 项目 rules：直接使用 init 初始化的 AGENTS.md/claude.md （项目介绍、技术栈等等），将项目一些经常需要修改的代码规范也可以写在这个文件中
● 全局 rules:
● 给项目代码加上索引
使用计划模式（ spec ，或者说平时的沟通）
切换计划模式（ Plan Mode ）。Agent 不会立即写代码，而是：
1. 研究你的代码库，找到相关文件
2. 询问澄清性问题，明确需求
3. 创建详细的实现计划，包含文件路径和代码引用
4. 等待你确认后再开始构建

计划模式实战：
理解需求，阅读需求有关的代码，整理开发思路与 Ai 沟通思路的可行性，输出给 Ai：Agent 会询问澄清性问题，创建可审阅的计划。
计划会以 Markdown 文件形式打开，你可以直接编辑——删除不必要的步骤、调整方案，或补充 Agent 遗漏的上下文，以及后续对话新加的内容也需要加到文件里面。
生成的任务也不要一次性都完成，一个任务一个任务的完成，并且再补充一些上下文信息，再进行代码 review ，功能自测。
代码开发完后还能让 Ai 生成单元测试，以及让 Ai Review 代码 业务逻辑、性能、安全等方面。

当然并非每个任务都需要详细计划。快速修改或你已经做过很多次的任务，直接用 Agent 就好。
有时 Agent 构建的东西与你期望的不符。与其通过追加提示词来修补，不如回到计划阶段。撤销更改，细化计划使其更具体，然后重新运行。这通常比修正进行中的 Agent 更快，结果也更干净。

管理上下文
引用现有的信息
● 代码、数据库表、业务信息、类似的逻辑代码
● 之前的 spec 文档
● cursor 还支持引用之前的对话
● 现有的业务文档
何时开始新对话
最常见的问题之一：继续当前对话还是开始新的？
开始新对话的情况：
● 转向不同的任务或功能
● Agent 看起来很困惑或反复犯同样的错误
● 完成了一个逻辑工作单元
● 上下文内容过多
继续当前对话的情况：
● 在同一个功能上迭代
● Agent 需要之前讨论的上下文
● 正在调试它刚构建的东西
长对话会让 Agent 失去焦点。经过多轮对话和摘要后，上下文会累积噪音，Agent 可能会分心或转向不相关的任务。如果你发现 Agent 效率在下降，就该开始新对话了。

拓展 agent
● rules
● skills
● 自定义命令
● 插件
● subagents

Ai 的一些其他用法
● 需求梳理：
○ 指明具体的代码后，先让 ai 把代码解释一下，并且画图帮助自己理解。然后自己去看具体的代码，如果有不懂让 ai 继续解释不懂的代码并且画图，然后自己再去梳理业务。梳理的业务文档还可以再给 Ai 看一下，看是否有业务遗漏，后续的对话再在该文档上进行补充。
○ 有时候也可以让 Ai 给一些具体的数据来帮助理解代码
● 业务图：
○ 业务的一些流程图、表关系也可以借助 ai 生成 mermind 格式的代码，然后导入到 draw.io ，再自己进行调整细节。一些 markdown 格式也能支持 mermind 格式的渲染。现在 obsidian 开源了一个 skills ，生成图的颜色，可读性更高了

Ai 时代的一些思考
● 需要注重自己的独立思考能力提升
● 加强对复杂业务的理解
● 使用 Ai 协助开发而不是完全交给 Ai 开发
● 需要注重技术基础和架构能力
● 需要知道 Ai 擅长与不擅长的点，充分利用 Ai 提效，积极拥抱 Ai