一些好用的 AI Coding 辅助工具

如果把 AI Coding Agent 看成“大脑”，那么 Skill 更像工作经验和方法论，MCP 是它连接外部世界的感官系统，CLI 则是最基础的工具箱。真正成熟的 AI Coding 环境，并不是给模型挂几十个 MCP，而是让这三层各司其职，最终形成“理解、实现、运行、验证、修正”的完整工程闭环。

这两年我换过不少 AI 编程工具，也越来越少纠结一个问题：到底哪个模型写代码最强？

Codex、Claude Code、OpenCode，包括各种 IDE Agent，单看模型能力其实都已经到了一个很高的水平。真正影响日常开发体验的，很多时候反而不是模型排行榜上那几个百分点，而是：你到底给 AI 提供了什么能力。

一个只能读写文件、执行 Shell 的 Agent，和一个能理解代码符号、查询最新文档、操作浏览器、分析 GitHub、执行结构化代码搜索的 Agent，即使背后使用同一个模型，最终表现也可能完全不一样。我现在越来越倾向于把 AI Coding 看成一个完整的工程系统，而不是一个聊天框。

                    AI Coding Agent
                          │
              ┌───────────┼───────────┐
              │           │           │
            Skill        MCP         CLI
              │           │           │
          开发规范      语义能力      原子能力
          项目知识      外部系统      本地工具
          工作流程      浏览器等      搜索/处理

模型只是这个系统的大脑。CLI、MCP、Skill，以及项目本身的上下文，才逐渐构成了它的手、眼睛和工作方法。

Serena：不要再让 AI 一遍遍读整个文件

这是我最近比较看好的一个方向。

很多人使用 Coding Agent 时，其实没有意识到一个问题：AI 对代码的理解，经常还是文本级的。

比如你问：

UserService 这个方法在哪里被调用了？帮我分析一下整个调用链，然后重构。

最朴素的 Agent 很可能开始：搜索 UserService → 打开 UserService.java → 读取整个文件 → 搜索方法名 → 打开 Controller → 读取整个文件 → 再搜索其他引用……项目小的时候没问题，但如果面对一个几十个 Module、几千个 Java 文件的老项目，这种方式很快就会变得笨重，不仅慢，还浪费 Context。

Serena 比较有意思的地方，就是它试图给 Coding Agent 提供 Symbol 级别的代码理解和编辑能力。AI 不再只是看到文本层面的字符，而是能更接近 IDE 的视角去理解代码结构：

UserService
 ├── getUser()
 ├── createUser()
 ├── updateUser()
 └── deleteUser()

以及某个 Symbol 被谁引用。这件事看起来只是“搜索方式高级了一点”，但实际对 Agent 的意义很大。因为软件工程本身就不是纯文本问题——我们平时在 IDEA 里为什么离不开 Find Usages、Go to Definition、Call Hierarchy？本质上就是因为 代码的结构比代码的文本更重要。

所以我现在比较喜欢这样的组合：Serena 负责符号理解，再由 Agent 进行修改，而不是上来就把几万个 Token 的代码塞进 Context。对于 Java、Go 这种中大型工程，这种能力尤其值得拥有。

Context7：解决 AI 编程里一个非常隐蔽的问题

AI 写代码最麻烦的问题之一，其实不是它不会写，而是 它太像会写了。

比如你告诉它：“用某某框架最新版实现这个功能。”它很快就能给你一份代码，类名对、调用方式看起来也对，然后 npm run dev，直接报错——你查半天才发现，AI 使用的是两年前的 API。现在前端框架、AI SDK、云服务 SDK 更新速度飞快，模型训练时记住的知识和当前项目真实版本之间必然存在时间差。

Context7 解决的就是这个问题。它不是单纯给 AI 一个搜索引擎，而是让 Agent 在需要使用某个 Library 时，去获取 与当前版本匹配的文档和示例。整个流程就从“模型凭记忆生成代码 → 祈祷 API 没变”变成“识别依赖版本 → 查询 Context7 → 确认 API → 生成代码”。

我觉得这类工具以后甚至应该成为 AI Coding 的基础设施。随着 Vibe Coding 越来越普及，一个很危险的趋势是：开发者越来越少亲自查文档，而 AI 又越来越自信地生成代码。这时候“让 AI 主动查文档”反而比以前人自己查文档更加重要。甚至可以直接把它写进项目 Skill：“涉及第三方框架时，先确认版本，查询对应文档，确认 API 后再实现。”这几句话看起来不起眼，却可能比换一个更强的模型更能降低返工率。

Playwright MCP：把 Vibe Coding 最后那个人工环节干掉，顺便帮我“刷”网站

如果经常让 AI 写前端，这个能力非常值得折腾。

以前我的工作流经常是：告诉 AI 修改页面 → AI 改 Vue → 我启动项目 → 我打开浏览器 → 发现不好看 → 截图发给 AI → 继续修改。这里存在一个明显的问题：AI 能写页面，但 AI 看不到最终结果。 于是人一直充当 AI 的眼睛。

Playwright MCP 这类工具真正有价值的地方，不只是“AI 可以控制浏览器”，而是它让 Coding Agent 形成一个完整闭环：修改代码 → 启动项目 → Playwright 打开真实页面 → 检查 DOM、操作、截图 → AI 判断结果 → 不满意继续修改。这样 AI 就完成了“实现—运行—观察—验证—修正”的循环。

而把这件事延伸到工作和生活场景，那就更有意思了。比如我最近要参加一个在线培训，每天得做一套网页答题，题目重复性很高，但必须手动点。以前我只能自己傻傻地打开浏览器、读题、选答案、提交，再等下一题。现在呢？我写一个 Skill，告诉 AI：“用 Playwright 登录这个培训系统，进入每日答题页面，识别题目类型，根据我预先提供的题库或常见答案模式进行选择，提交，然后继续下一题，直到完成。”

AI 就会自动打开浏览器，输入账号密码，逐题分析，甚至截屏确认，最后把结果告诉我。这已经不只是“编程辅助”了，这是 把重复的网页操作完全自动化。后台管理系统、表单、登录页、Dashboard 这类项目当然也适合浏览器自动验证，但更贴近生活的场景——比如自动打卡、自动签到、自动填表——Playwright MCP 都能胜任。以后我甚至可以把“UI Review”和“自动答题”都做成固定 Skill，让 AI 既帮我写代码，又帮我处理那些无聊的网页劳动。

ast-grep：让 AI 少做危险的字符串替换

另外一个我觉得被低估的工具是 ast-grep。

我们平时让 AI 修改大量代码，经常会看到这种操作：grep → 找到字符串 → replace。问题在于：代码不是字符串。 比如 userService.getUser(id);，对文本工具来说只是一串字符，但从 AST 角度看，它是一个方法调用表达式。这两种理解方式完全不是一回事。

所以涉及几十甚至几百个文件的批量修改时，我更倾向让 Agent 用 ast-grep 识别特定代码模式，再进行结构化修改，而不是单纯依赖正则替换。比如批量迁移旧 API、修改某种 Controller 写法、替换特定调用模式、大规模框架升级——这种任务，AST 级工具天然比 Regex 更适合。AI 时代以后，类似 ast-grep 反而可能变得更重要，因为以前一个人很少会随手重构 500 个文件，现在 Agent 真敢。既然执行能力变强了，就更需要给它一把可靠的手术刀。

真正不起眼的，反而是 rg、fd、jq、yq

如果只看名字，这几个工具完全没有 AI 味，甚至已经“老”得不能再老。但我现在越来越觉得：好的 AI Coding 环境，不一定到处都是 AI 工具。 有时候传统 CLI 反而特别适合 Agent。

ripgrep 快速搜索整个项目，fd 找文件，jq 处理 JSON，yq 处理 YAML。它们最大的价值不是功能多高级，而是 可以减少进入模型 Context 的垃圾信息。 例如某个接口返回 300KB JSON，最差的方式是全部交给模型，让它自己找其中三个字段；更合理的方式是用 jq 提取真正需要的数据，压缩到 3KB 再交给模型分析。这其实也是 AI 工程里很重要的思想：不是 Context 越多越好，而是有效 Context 越多越好。 CLI 很适合承担这一层预处理。

GitHub CLI：让 AI 从“写代码”进入真正的软件开发流程

如果项目托管在 GitHub，我觉得 gh 也值得成为 Coding Agent 的基础工具。因为真实的软件开发从来不只是“打开 IDE → 写代码”，而是 Issue → 需求分析 → 代码定位 → 开发 → 测试 → Commit → PR → CI → Review → Release。GitHub CLI 恰好可以把这一整套工作流暴露给 Agent：gh issue list、gh pr diff、gh run view 等等。于是以后完全可以给 Agent 一个任务：“分析最近的 Issue，找出可直接修复的 Bug，定位代码并完成修改，跑测试后整理 PR。”AI Coding 的边界就从“帮我写这个方法”扩展到了“帮我处理这个 Issue”。

我现在反而不喜欢装几十个 MCP

MCP 火起来之后，很容易出现一种情况：什么都 MCP 化。最后 Agent 启动时挂着几十个 Tool，看起来特别豪华，但实际使用未必更好。因为每多一个工具，模型就需要理解它的用途、参数，Tool Schema 本身也占用 Context，工具越多，选择复杂度越高。

所以我更认同一种克制的划分：CLI 负责干活（搜索、文件处理、JSON/YAML、Git、Docker、HTTP），MCP 负责连接和理解（代码语义、最新文档、浏览器、数据库、外部业务系统），Skill 负责告诉 AI 应该怎么干（项目规范、开发流程、架构约束、Review规则、工具使用策略）。这样整个系统反而会更干净。

真正应该搭建的，是自己的 AI Coding Toolchain

如果现在让我重新配置一套开发环境，我可能不会再花很多时间纠结“Claude 和 Codex 到底谁强一点”。我更愿意把时间花在下面这套东西上：

                      Codex / Claude Code
                              │
               ┌──────────────┼──────────────┐
               │              │              │
             Skills          MCP            CLI
               │              │              │
          项目开发规范       Serena           rg
          自动答题流程       Context7         fd
          UI Review         Playwright       jq
          DB Review         Database         yq
          Architecture                      ast-grep
                                            gh
                                            docker
                                            curl
                                            mysql

然后再进一步，把这些配置全部项目化：放进 Git，或者做成配置服务。这样换电脑、换模型甚至换 Coding Agent，都不需要重新教一遍。模型可以变，客户端可以变，但我的工程规范、项目知识、工具链和工作方式没有变。

以前我们折腾开发环境，是配置 JDK、Maven、Node、IDEA、Docker、Git。现在可能还要多一层：Model、Agent、MCP、CLI、Skill、Context。模型能力还会继续快速变化，今天最强的是 A，几个月之后可能又变成 B。如果所有能力都绑定在某一个模型上，那么每次迁移都得重新开始。

但如果把自己的开发方式逐渐沉淀成 Skill + MCP + CLI + Context + Workflow，模型反而会越来越像一个可以替换的执行引擎。所以我已经不太想问“哪个 AI 最适合写代码？”我现在更关心的是另一个问题：

我能不能把自己的开发环境，建设成一个任何强模型接进来都能立刻开始干活的工程系统？

如果这件事情做成了，那么真正被长期积累下来的，就不再是某个 Prompt，也不是某个模型的使用技巧，而是属于自己的 AI Coding Toolchain。它不仅能帮我写代码，还能帮我自动答题、自动填表、自动处理那些重复的网页事务——让 AI 成为真正替我分担劳动的数字伙伴，而不仅仅是一个高级聊天框。