以前写代码，会先在脑子里过一遍实现，再坐在编辑器前一个字符一个字符敲出来。现在更多是在聊需求、看方案、拆任务、验收结果，不对的地方再继续调整。
这篇不算教程，也不是工具横评，主要记录一下这一年半用过的工具，以及自己的开发方式是怎么变化的。
最早用的是 GitHub Copilot
大概是 2023 到 2024 年，当时 GitHub Copilot 好像是每个月 10 美元。主要就是 Tab 补全，帮忙写一些简单方法和重复代码。整体还是自己在编程，Copilot 只是猜接下来要写什么。
中间大概 Gap 了半年。到 2025 年三四月份开始用 Cursor ，才算真的进入现在大家说的 Vibe Coding 。
用 Cursor 做了「字节篝火」
我用 Cursor 做的第一个完整项目，是一个叫「字节篝火」的自动化科技播客。
大概流程是：
n8n 是我自己研究的，里面涉及的 Python 小项目基本都是 Cursor 写的。这个项目实际跑了三四个月，一共做了六十多期，不是只跑通了一次的 Demo 。
从那时开始，我基本就不怎么手动敲代码了。以前碰到不熟悉的技术，第一反应是要不要先学一下、需要学多久。后来逐渐变成先确定自己想做什么，再把爬虫、TTS 、网站和 RPA 拼起来。
再后来，因为模型、TTS 和云服务都有一些持续成本，我又开始做 Mytesla ，「字节篝火」就停掉了。
从 Mytesla 到 Mytess
Mytesla 的起点很简单。我自己在用 TeslaMate ，但一直想要一个适合手机查看的数据面板，所以就开始用 Cursor 做。
那时候还没有现在这么完整的 Skills 、Spec 、Issue 工作流，MCP 也才刚流行。开发方式基本就是在 Cursor 里聊需求，先让它做一个页面，跑起来之后再一点点调整。
最开始做的是 Dashboard 和车辆状态页。第一版比较粗糙，来回改了很多轮，最后效果达到了自己的预期，我就继续把其他功能做了出来。后面也试过 Google Antigravity ，Cursor 里用过比较早期的 Claude Opus 4 系列。
和「字节篝火」相比，Mytesla 已经不是几个小服务串起来就结束了。它需要长期维护，要考虑数据结构、页面状态、部署、升级，以及今天改的东西会不会影响之前的功能。
2025 年底到 2026 年一月份，我决定在 Mytesla 的基础上做原生 iOS App ，也就是 Mytess 。
这个阶段开始尝试 Claude Code 。除了让它写功能，我也开始折腾一些开发流程：
当时 Claude Code 和 Codex 还没有现在这么方便的移动端支持，我自己拼了一套远程开发方式：
手机
↓
Moshi + tmux
↓
Claude Code / Codex
↓
Bark 通知
↓
OTA 安装测试版
出门的时候可以直接在手机上下任务。Agent 做完之后，Bark 会发通知，我再打开测试版看结果，不需要走 TestFlight ，在外面也能安装最新版本。
Happy 我也试过，不过当时感觉延迟有点高，最后还是 Moshi 和 tmux 用得更多。
试过多 Agent ，后来又收了回来
用 Claude Code 的时候，我还尝试过 Teams ，给 Agent 分过产品、研究员、研发和测试几个角色。通常会先和产品角色聊需求，再 Research 一下技术方案和产品边界，生成 PRD ，最后交给研发实现。
效果其实不错，做东西非常快，但问题也恰恰是太快了。功能一下子做了很多，我自己根本测不过来。即使有测试 Agent ，页面顺不顺手、实际数据有没有问题、之前的功能有没有受到影响，最后还是得自己打开 App 一个个看。
后来我就不再追求很多 Agent 同时跑了，重新回到比较简单的 Skills 流程。一次只做相对明确的任务，自己也参与得更多。研发速度上去以后，测试和验收很容易变成新的瓶颈。
后来主力换成了 Codex
一方面是 Claude 的额度比较少，另一方面有段时间感觉模型状态不太稳定。大概从 2026 年四五月份开始，我把 Codex 作为主力。
到这个阶段，我已经不太纠结某一个模型偶尔能不能写出更漂亮的代码了，更重要的是把自己反复遇到的问题，写进 Agent 和 Skills 里。
比如 iOS 国际化。一开始只是每次提醒一句“记得处理国际化”，但还是经常漏。有时只加了英文，有时出现硬编码，有时改了原文却没有同步其他语言。
后来就拆成了两部分：
现在比起在 Prompt 里反复强调“请注意”，我更相信最后有没有一套 Verify 。
现在主要使用 Orca
目前主要在用 Orca，模型还是 GPT 的最新版本。
Orca 比较适合我现在的使用方式。Task 、Issue 、状态、预览和追评都放在一起，iOS Debug 和测试也方便很多。相比以前自己拼 Moshi 、tmux 、Bark 和 OTA ，现在整体顺畅不少。
开发流程强烈推荐使用 Matt Pocock Skills：
Wayfinder
讨论需求、边界和大致路线
To Spec
整理成可以执行的 Spec
To Tickets
按照依赖关系拆成多个 Issue
Implement
根据 Spec 完成对应 Issue
以前可能聊完一个需求就直接开做，现在通常会先把边界讨论清楚：这个功能到底解决什么问题，哪些情况要覆盖，哪些内容这次先不做。然后生成 Spec ，再按照依赖拆成 Issue 。
目前 Agent 对需求的完成度已经比较高了。还需要我自己反复参与的，主要是 UI 、UX 和 iOS 真机测试。UI 第一版通常能用，但距离舒服、自然，还是要再调几轮。
iOS 的边界问题更麻烦，比如前后台切换、弱网、权限变化、异常数据、不同设备和不同语言。目前我还没有找到特别好的自动化方案，最后还是得自己上手测。
最近面试校招生，也发现很多学生已经开始用 Claude Code 和国内大模型做项目了。项目看起来可能挺完整，但继续问底层实现、数据怎么流转、为什么这样设计，有些人自己也不清楚。
我还是更看重懂底层、懂架构、心里有最佳实践，同时也会用 AI 的人。自己知道什么是好的，AI 才能把这个能力放大。自己完全不懂，只是一路让 AI 生成，最后做出来的东西可能能跑，但一般不会特别好用。
AI 没有改变这些核心的东西，主要还是降低了实现和尝试的成本。以前一个想法可能要花几周才能验证，现在可以先做出来、用几天，再决定值不值得继续。
对我来说，角色也慢慢从单纯写代码的人，变成了一个需要自己处理产品、开发、测试和发布的独立开发者。
本文由 yekk 与 GPT-5.6-sol high 共同完成。
