AI 写代码这半年，我从兴奋到冷静，再到整了一堆 skill

大概半年前我第一次用 Codex。我说了一句「帮我写一个 todo list 的页面」，它就开始哗哗地创建文件、装依赖、写组件。五分钟后，一个能跑的前端页面出现在浏览器里。

这种感觉太爽了。好像突然拥有了一个不用吃饭、不用睡觉、不会抱怨的实习生。而且它比实习生强多了，你让它改什么它立刻改，不会跟你顶嘴，也不会甩锅。

然后我就上头了。

那段时间我几乎所有代码都交给 AI 写。需求一说，它就开始改。我也懒得看过程，反正最后能跑就行。

但大概过了一个月，问题开始冒出来了。

有一天我让 AI 帮我加一个用户登录功能。它写完之后我 review diff，发现它把之前好不容易调好的路由结构全改了，还顺手把我没让动的数据库模型也动了。登录功能是有了，但整个项目的逻辑变得特别拧巴。

我问它为啥要改这些。它说，「为了让登录功能更好地集成进系统」。

它不是不会写。它是太会写了。只要你说得不绝对清楚，它就会按自己的理解去补全，去「优化」，去「让系统更完整」。最后补出来的东西不一定是你要的，但 diff 一定很大，大到你看不完。

从那以后，我对 AI 开发工具就没一开始那么兴奋了。

它还是有用，但前提是任务、范围、验收标准，得先说清楚。不说清楚，它就会自己往下补，补到你都不认识这个项目为止。

我日常主要用两个工具，Codex 和 Claude Code。

Codex 用得更多，因为我主力模型还是 GPT。日常改项目、跑本地工作流，Codex 成本低，工具调用和文件修改的流程也已经被 OpenAI 打磨得差不多了。

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

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

不过日常开发我还是 Codex 为主。毕竟现在这套习惯是围着 GPT 和 Codex 搭起来的，要换的话迁移成本不低。而且 Codex 的响应速度确实快，写那种需要反复试错的代码时，快几秒的体验差距还挺明显的。

说到 skill，这玩意是我最近半年觉得最值的东西。

你可以把它理解成一种「可复用的 prompt 模板」。有些工作流程或者约束标准，你每次跟 AI 对话都要重复说一遍，很烦。把它写成一个 skill，需要的时候直接调用，AI 就会按那套规则来执行。

我自己现在沉淀了几个常用的，挑几个有意思的聊聊。

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

agent-browser 能打开页面、看页面状态、点按钮、填表单、截图。做前端改动以后，让它跑一遍页面流程，比只看代码更容易发现问题。复杂交互还是要自己看，但日常页面检查，它已经够用了。

darwin-skill 是我用来检查和优化其他 skill 的。它能帮你发现 skill 里有没有边界不清、说明不够具体之类的问题。补几条规则之后，AI 的行为确实会好一点。

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

我现在更倾向于够用就停。skill 不是越厚越好。它应该让 AI 更清楚，不是把所有可能出错的地方都堵一遍。堵不完的。你自己写代码还会出 bug 呢，凭什么要求 AI 看了几十条规则就绝不犯错？

ai-board 是我自己写的小工具，主要用来管 vibe coding 里的任务状态。这个我后面专门写了一篇文章讲，这里就不展开了。

better-icons 是我最近才开始用的，但用了一次就离不开了。它的作用很简单，就是让 AI 在写前端的时候，别随便找个图标就往上堆。你告诉它你要什么风格、什么场景的图标，它会去搜一套统一的、质量在线的图标资源，而不是让页面上出现三四种不同风格的图标混在一起的惨剧。

GPT 写前端有个毛病，遇到图标就随手扔一个 LuIcon 或者 FaIcon，有时候同一个页面里线性和面性图标混用，粗细还不一致。你肉眼一看就觉得哪里怪怪的，但 AI 自己完全意识不到。better-icons 就是专门治这个的。它会让 AI 先想明白这套 UI 适合什么风格的图标，再找一套统一的来用。

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

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

前端 skill 能把下限拉高一点，但上限还是看模型和参考模板。你给它一张设计稿，它至少能抄个大概。你让它从零开始自由发挥，那画面通常不太能看。

做项目的时候，我现在养成了一个习惯，让 AI 先 plan，再写代码。

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

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

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

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

说到前端，我现在基本不让 GPT 裸写了。

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

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

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

折腾了这么久，我现在对 AI 写代码的态度挺明确的。

它是个很强的工具，但工具不能替你思考。需求是你自己的，验收标准也是你自己的。AI 可以帮你快速实现，但方向对不对，最终还是要人来判断。

那些觉得「有了 AI 以后我不用学代码了」的人，可能还没被 diff 炸过。

等你经历过一次 AI 把项目改得面目全非、你花了整整一个下午才理清楚它到底动了什么之后，你就会明白。AI 不是来替代你的，它是来加速你的。但加速的前提是，你自己得知道路在哪。

不然它加速的方向，可能是悬崖。