AI 开发工具和 Skill 用下来的一点感受

这段时间一直在用 AI agent 写代码。刚开始很容易上头，说一个需求，它就开始改文件、跑命令、补代码，好像很多事都不用自己一点点敲了。

但用久了以后，问题也会慢慢出来。它不是不会写，而是太容易写着写着就偏了。一个需求说得不够清楚，它会自己补很多东西。你临时改几次方向，它也会把前面说过的东西混在一起。等到要 review 的时候，diff 很大，你也说不清它到底是从哪一步开始不对的。

所以我现在对 AI 开发工具没一开始那么兴奋了。它还是有用，但前提是任务、范围、验收先说清楚。不说清楚，它会自己往下补，最后补出来的东西不一定是你要的。

工具#

我平时主要用 Codex 和 Claude Code。

Codex 用得更多一点，主要是因为我主力模型还是 GPT。日常改项目、跑本地工作流，用 Codex 成本低。工具调用、文件修改这些流程基本已经适配好了。

Codex 接别的模型会麻烦一些。2026 年那次接口调整以后，其他模型想接进来经常要走中转，或者本地再套一层代理。能跑是能跑，但工具调用会变得不稳定。有时候你明明没给它那个工具，它还是像真的有一样去调用。这个问题我遇到过几次，排查成本不低。

Claude Code 接其他 AI API 更方便，agent 相关的能力也更完整，比如上下文管理、子代理这些。我如果要试国产模型，或者想折腾多模型，一般会先想到 Claude Code。

不过日常开发我还是 Codex 为主。现在这套习惯是围着 GPT 和 Codex 搭起来的，要换的话迁移成本不低。

Skill#

Skill 可以理解成给 AI 的一份工作说明。它告诉 AI 这类任务应该怎么做，哪些地方要注意，哪些东西不要乱来。

我一开始以为它主要是写文案用的，后来发现不止。浏览器测试、前端风格、项目流程、代码 review，都能靠 skill 稍微约束一下。它不保证 AI 一定听话，但比只靠一段 prompt 稳一点。

我现在常用的几个大概是这些。

agent-browser#

agent-browser 适合做前端页面检查。

以前让 AI 测前端，我经常用 Playwright 那一套。Playwright 能用，但 AI 有时候找不到元素，有时候页面还没加载完就开始点，还有时候明明点错了还继续往下跑。测试日志显示流程跑完了，页面实际状态不一定对。

agent-browser 能打开页面、看页面状态、点按钮、填表单、截图。做前端改动以后，让它跑一遍页面流程，比只看代码更容易发现问题。

复杂交互还是要自己看。但日常页面检查，它已经够用了。

darwin-skill#

darwin-skill 能用，但不要太依赖。

它适合帮你看一个 skill 有没有边界不清、说明不够具体之类的问题。很多时候补几条规则，AI 的行为确实会好一点。

问题是 skill 容易越写越长。今天发现一个问题，加一条规则。明天又发现一个偏差，再加一条。加到后面，文件里全是限制，AI 读起来也累，自己维护也累。

所以我现在更倾向于够用就停。skill 不是越厚越好。它应该让 AI 更清楚，不是把所有可能出错的地方都堵一遍。

ai-board#

ai-board 是我自己写的小工具，主要用来管 vibe coding 里的任务状态。

我写它是因为聊天记录太不靠谱。一个项目做几天以后，AI 早期答应过什么、现在到底在改哪个范围、这个任务怎么验收，全部散在对话里。上下文一压缩，很多东西就没了。

ai-board 做的事不复杂，就是把任务、scope、验收、状态这些放到外部文件里。AI 改代码前先看当前任务，改完以后再按任务验收。它谈不上什么大系统，能让每次改动留个记录就行。

它也管不住所有问题。比如业务上的冲突，路径级 scope 看不出来。但对我自己的小项目来说，先把任务状态留下来，已经比直接靠聊天记录管理更稳。

前端类#

前端我现在会一起开几个 skill。

frontend-design 和 ui-ux-pro-max 主要是让 AI 别写得太随便。它们会提醒一些布局、颜色、组件状态之类的问题。效果有，但也不能指望开了 skill 就直接出很好看的页面。

uncodixfy 是专门用来压 GPT 前端味的。GPT 写前端经常会堆大圆角、玻璃拟态、卡片套卡片，页面上还喜欢写一堆解释文字。uncodixfy 能压一点，但模型本身审美不行的话，它也救不了太多。

前端 skill 能把下限拉高一点，但上限还是看模型和参考模板。

先拆需求#

做项目时，我现在会尽量让 AI 先 plan，再写代码。

这个习惯是踩坑踩出来的。以前我经常直接说“帮我做一个 xxx”，AI 很快就开始写。做到一半才发现，它理解的功能和我想的不一样。有时候页面路由不对，有时候数据结构不对，有时候它多做了一堆我根本没要的东西。

空项目还好，大不了删掉重来。麻烦的是项目已经有一部分代码了，它再按自己的理解改一大片。你 review 的时候会很痛苦，因为你不只是看代码质量，还要重新判断它有没有偏离需求。

所以现在我会先让它把需求拆出来，确认功能列表、数据模型、页面、文件范围。确认差不多了再动手。前面多花一点时间，后面少返工。

我后来也把这个流程放进了 ai-board 的 onboard 里。接手一个项目时，先把方向问清楚，再排任务。不然 AI 开始写得太快，反而容易把自己带偏。

前端#

前端我现在基本不让 GPT 裸写。

GPT 能写前端，代码也能跑。但它写出来的页面经常有一种很重的 AI 味。组件很大，圆角很多，到处都是半透明和渐变。还有一个问题是，它喜欢在界面里写很多说明，好像怕用户不知道这个按钮是干嘛的。

prompt 能修一部分问题，但模型自己的审美底子影响很大。同一个需求，Claude 和 Gemini 做出来的东西通常更能看。国产模型里 DeepSeek 我也试过，价格便宜，前端效果也不差。

换模型也不能完全靠它自由发挥。更稳的办法是先给一个还不错的模板，让 AI 对着改。这样它至少有参考，不会从零开始乱画。

前端 skill 也是这个作用。它不是设计师，只是帮 AI 别跑得太离谱。

工具#