近半年，AI 加持下的开发感悟
前言
本篇文章，只是记录一下我最近半年多使用 AI 工具进行日常工作的感悟。
到了如今的这个时代，基本上不适用 AI 工具很难继续进行工作了。
Claude Code 终端
其实我最早使用的 AI 工具是 Trae，因为公司有合作，奈何 Token 配额太少，根本无法胜任常规任务，于是就在今年年初使用了 Claude Code 终端，当时使用的模型是 GLM-4.6（白嫖了同事的账号）以及自己付费购买的 MiniMax 套餐。
有关之前做过的工作，其实我在上一篇文章中已经做了详细说明，这里就不再多做描述，有兴趣的大家可以看看。 聊聊我最近都干了些什么，AI 时代的手动撸码人
感悟就是 AI 确实可以提高效率，因为实战的项目都是代码升级、库更新、技术栈更新，所以很难以点概面。当时我的理解是，对于复杂度特别高的工作，AI 还是不太行。
后来因为各种原因，再加上 Claude Code 自己"作死"，要求不允许使用，于是换工具势在必行。
Codex App 桌面端
后来我就用上了 Codex App。其实一开始我是特别抵触的：我好不容易用习惯了 Claude Code 终端，现在说换就换，重新培养使用习惯难道就不是成本吗？
于是在 B 站刷了几个教学视频，实际操作了一番，发现——有 Codex App 桌面端，还需要啥子自行车？
Codex App 桌面端，真香！
用上了 Codex 之后，不论是上传图片、文件、文件夹等，都比终端友好很多。
除了编程之外，使用 Codex 之后，它可以更加系统地读取整个工程项目了，页面 UI 的易用性也让人忍不住想用。
同时我除了接触 GLM、MiniMax 之外，也接触了更多的模型，DeepSeek 差不多也是在这个时期开始接触的。
DeepSeek 给我的感觉就是很强，但是当时手上有 Code Plan，谈不上深度使用。也不太理解模型和模型之间的能力差距怎么会这么大。
真正的转折出现在 AI 工作流的使用上。
AI 工作流
之前编码工作，基本上就是在现有代码上做小修小补，或者说小迭代，使用 AI 输入与输出即可。真正考验 AI 的是从零开始的项目，如果要让 AI 从零开始工作，一套完整的 AI 工作流必不可少。
GSD
公司大佬当时在内部推荐使用 GSD 流程，我也在工作中尝试使用。说来这个 GSD 也挺有意思的，因为原作者因某些原因"提桶跑路"之后，后续只好另起炉灶。
使用 GSD 发现的模型之间的差异
在使用 GSD 的过程中，我觉得这个流程还是很不错的，就是 Skill 太多，有时候不知道如何选择。另外我的 Code Plan 是 MiniMax 的，在使用过程中，我越来越发现它是真的"蠢"：它不会自己压缩上下文，有的时候 Skill 明显需要自己触发，它仍然非常头铁地自己干，不用 Skill，同时经常活儿没干完就停下来了。
于是没办法，借用了同事的 GLM，自己充值了 DeepSeek 试了一下，发现原来自己写的提示词没问题，纯粹是模型能力导致的问题。
于是 MiniMax 的 Code Plan 打水漂了。为了保障后续开发工作的顺利进行，更换模型势在必行。
Skills for Real Engineers
随着项目的持续进行，以及模型的不断进化，我们在工作中发现使用 GSD 的问题会越来越多——并不是 GSD 不好，而是不适合我们。于是在几次试用之后，我们的 AI 工作流迁移到了前端大神 matt pocock 的 AI 工作流上。
使用 Skills for Real Engineers 的心得
首先，要使用这套 Skill，至少要保证模型能力过关。这个阶段我自己充值了 Codex Plus 的 Code Plan，再配合 DeepSeek，简直一发不可收拾。
随着 Grill me / Grill with Docs → toSpec → toTickets → Implement 的主流程走下来，最难的是第一步 Grill。
经常一个需求输入进来，Grill 一来就是啪啪啪 30 个问题，让人很崩溃。幸好后面这个 Skill 升级了，有了推荐回答。但是，但是，但是（重要的事情说三遍），作为开发者，你手上握着最终决定权，推荐的回答未必是你期望的需求，所以一定要认真审核！
后面的流程就简单了，toSpec → toTickets → Implement，AI 进行 Code Review，自己再验收一下成品。
除了有些费 Token，我认为这一套流程走下来还是经得起推敲的。
AI，我，以及感悟
上面的内容只是记录我的使用流水账，下面这些才是我自己的一些感悟。
有 AI 了，上班还是很累
其实单纯写代码不累，因为困难的代码基本不用自己写了，技术上的瓶颈也基本不存在了。但是随着 AI 越来越会写代码，我自己的职责边界却变了，这些反而让人更辛苦。
比如之前，需求输入到我这里，我只需要理解需求、写代码、自测即可。但现在，任务变成了：如何将自己的理解转化为 AI 能够接收的输入，让 AI 输出符合预期的功能代码。绞尽脑汁地撰写提示词成了一件颇为麻烦的事。如果没有 AI 流程（toSpec → toTickets）的辅助，我认为写出一份规范的需求输入本身就是一件极其耗费脑力的工作。
另外，就算不写代码了，我也需要审核大量文档，这同样不轻松。尤其在项目初期，我还需要在每个功能模块下审核 AI 写的代码是否符合预期。虽然有各种 md 文件与规则去约束 AI 写代码，但仍需按流程逐一过一遍。
另外，从领导的角度看，我手上一定会有 AI，工作量与排期都比之前快了很多。而且公司对 AI 的 Token 支持不太友好，目前真的就是"付费上班"。既然是付费上班，我自然希望按计划完成功能、准时下班，但事实并非如此。
有 AI 了，心态变了很多
之前，我总觉得 AI 就算发展得再快，想要干掉移动端开发还是有点难度的，因为移动端开发有别于前端，它非常依赖多模态的模型（UI 需要），同时 Xcode 的配置又非常复杂。但是随着 AI 的发展，甚至 Xcode 27 的配置改为了 JSON，其实都是在为 AI 服务。
我从一开始的有点抗拒，到后来的接受，再到现在的积极拥抱，转变非常之快。
目前唯一的焦虑是：我到底可以干什么？我在自己的岗位上是不是可有可无？我会不会被干掉？
有 AI 了，这几个月都干了些什么？
之前的 RxStudy 还只是我用自己的项目做技术栈迁移，随着公司项目的接入就不一样了。
我在 7~9 月份，在其中一个项目上完成了 React Native 在双端的落地；同时在另外一个项目上，完成了 KMP 以及 CMP 在双端的落地。这个项目期望也有 HarmonyOS Next 端，我们甚至做完了一部分 Quickly + KMP 在 HarmonyOS Next 端的验证，以及完整的鸿蒙 Flutter 开发。
作为一个 iOS 开发，很多技术栈我之前并不了解，但最后还是都成功落地了。项目的配置我无需关心，只需看看代码是否看得懂即可。
现在大家都调侃 AI 叫"天才程序员"，目前我除了看看它写的代码结构与分层的合理性之外，大部分时间都很难再仔细阅读它写的代码了——因为它的写法比我更高级，架构与思路也常常比我优秀。
有了 AI，写代码已经没有乐趣
这确实是我最真实的感受。当人类停止探索时，乐趣便随之消失——这和打游戏一样，当你面对一片未知广袤的地图，一步步探索、一步步推进，才会获得乐趣。目前 AI 写代码没有什么技术难点，在我看来，只要 Token 充足、时间周期允许，需求合理，都可以开发出来。
而我们，则像流水线上的工人，逐项检查与核对。
乐趣变成了如何想出一个好的点子，甚至是一个有趣的交互或动画。从繁重且重复的编码工作中抽身之后，我会更多地参与到需求输入环节：需求是否合理、能不能跑通。
模型强是关键
我也看过很多人讨论：同一个模型在不同的 IDE 加持下，表现会存在些许差异。但是从我用过的 GLM、MiniMax、DeepSeek 和 ChatGPT 来看，如果模型本身足够强大，就能做到"力大砖飞"的效果。
我会经常使用 Skill、MCP 以及插件，甚至专门去研究如何安装与配置。但是在实际开发过程中我发现，对于一个足够强的模型，只要说清楚要做什么、授予必要的权限，剩下的事情交给它自己处理即可。
同时需要注意的是，权限的赋予是一柄双刃剑，在带来便利的同时也伴随着潜在的风险。
好了，以上就是我的一些感悟，欢迎大家交流。如果大家对 Skills for Real Engineers 感兴趣，我也可以考虑单独写一篇文章交流。
BTW，这篇文章我没有使用任何 AI 工具生成，全部手敲。
