从零开始到底有多零
这位作者不懂 Swift，分不清前端后端，开始项目之前连 GitHub 账号都没注册过。终端在他眼里就是一个黑色窗口，唯一会的命令是 cd——还是 AI 教的。日常工作跟编程完全无关，但因为对 AI 感兴趣，过去半年一直在用 Claude Code 处理各种杂事，算是一个重度用户。
换句话说，他具备的不是编程能力，而是跟 AI 协作的经验。这个区别很重要。
想法怎么来的
产品的起点是两个不相干的东西撞到了一起。
第一个是刷到了 Notchi——有人在 MacBook 刘海区域做了一个 Claude Code 的状态监控。他意识到刘海这块屏幕空间是可以利用的。第二个是他自己的场景：MacBook 上跑着 Claude Code，Mac Mini 上养着一只 OpenClaw 小龙虾，两边都在消耗 token，但信息散落在不同地方。
他想把所有 AI 的状态聚合到一个入口，用一个有情绪的像素生物来展示——AI 工作的时候它跟着忙，等回复的时候它跟着等，报错了它生气，token 烧完了它翻肚皮。
搁以前，这个想法百分之百死在备忘录里。但这一次他打开了 Claude Code。
第一行命令
他在 Claude Code 里敲了一句话：
"我想做一个 macOS 应用，一只像素小龙虾住在 MacBook 的刘海区域，能跟着 AI 的工作状态动起来。"
Claude 没说"这很难"，也没说"你先去学 Swift"。它直接开始干了——生成 project.yml，用 XcodeGen 创建工程，写了第一个 SwiftUI 视图，让一只静态的像素小龙虾出现在了刘海区域。
晚上十点，屏幕上出现了一只红色的小龙虾。他说那个瞬间的感觉不是成就感，而是一种错位感：刚才做了一件完全不懂的事情，而它真的发生了。
Vibe Coding 的真实手感：不是写代码，是当产品经理
接下来的开发方式和传统编程完全不同。不写代码，写需求。本质上就是在和 AI 聊天。
几个实际的对话示例：
- 提需求："小龙虾现在只会站着，我想让它动起来——思考的时候摆钳子，工作的时候忙碌地爬，空闲的时候悠闲地吐泡泡。" → Claude 改了
CrawfishSpriteView.swift，加上精灵表动画系统。 - 提视觉："水下要有海草在摇摆，有气泡从底部往上飘，有光线从水面透下来。" → Claude 用 Canvas 和 TimelineView 画了整个水下场景。
- 提交互："AI 消耗的 token 能不能像游戏里的血条一样显示？满的时候绿色，快用完了红色闪烁，归零就 K.O.。" → 于是有了街霸风格的像素血条系统。
这里有一个反直觉的发现：不懂技术的人，反而敢提更大胆的需求。 懂开发的人会自我审查——"这个动画太复杂了""这个通信协议搞不定"。不懂的人不会。复杂不复杂，那是 AI 的事。
踩坑才是真实的部分
Vibe Coding 不是一路聊天一路顺风。真正的考验不是"代码怎么写"，而是"出了 bug 怎么办"。
Socket 通信被截断：小龙虾需要接收 Claude Code 发来的状态事件，但大数据包总是被截断。他描述了现象，Claude 诊断出是 100ms 的接收超时太短，改成了 5 秒，加上 Content-Length 精确读取。
"用久了会变慢"：他连"内存泄漏"这个词都不知道，只是告诉 Claude"用久了会变慢"。Claude 排查了一圈，发现是 SessionData 里的 sleepTimer 没有被清理，加了一个 cleanup() 方法解决了。
应用闪退：很多时候 bug 的表现是"小龙虾突然不动了"或者"应用闪退了"，连怎么描述问题都不知道。他学到的方法是：把日志贴给 AI 看。终端报错、Xcode 崩溃日志、控制台输出——不需要看懂，只需要复制粘贴。
这段经历指向一个关键结论：Vibe Coding 最核心的能力是描述问题的能力。 你不需要知道原因是什么，但你得说清楚发生了什么——哪个操作触发的、什么时候出现的、具体表现是什么。会观察、会表达，就够了。
从一只虾到一个生态系统
功能是怎么一步步"失控"膨胀的：
- 一开始只是一只虾
- Mac Mini 上也在跑 AI → 加了远程模式，两台机器可以配对连接
- 想在 MacBook 上直接给远程 Agent 发指令 → 加了双向通信，刘海展开后底部多了输入框
- 一只虾太孤单 → 加了双生物系统，寄居蟹追踪本机 AI，小龙虾追踪远程 AI，两只生物在同一个鱼缸里各自游动、偶尔碰撞弹开
- 只支持中文太可惜 → 加了三语系统，中文、英文、日文运行时切换
从 v0.1 到 v2.0.5，两天迭代了 7 个版本，代码从几百行膨胀到 12800 行。
这里面有一个值得注意的现象：每一个新功能的边际成本几乎是零。 他唯一付出的是想清楚"我要什么"以及"怎么跟 AI 描述清楚"。当实现成本趋近于零，想法本身就变成了唯一的稀缺资源。
最后一公里：发布比写代码更麻烦
代码写完不等于做完。macOS 应用需要代码签名（Code Signing）、Apple 公证（Notarization）、打包成 DMG。Developer ID、Hardened Runtime、Staple 票据嵌入——每一个词他都是第一次听到。
Claude 写了 build-release.sh，一键完成编译、签名、打包、公证。公证失败了好几次，每次原因都不一样，但最终一个带着 Apple 认证的 DMG 文件出现在了桌面上。
双击安装，拖进 Applications，打开。这不是一个 Demo 或原型，是一个可以分发给任何人使用的正式应用。
48 小时的产出清单
最终交付的数据：
- 71 个 Swift 源文件，12800 行代码
- 35 套精灵动画
- 本机和远程两套通信协议
- 中英日三语切换
- 会话历史、菜单栏控制、开机自启
- 无障碍适配（Claude 主动加的，作者根本没想到）
- 通过 Apple 公证，可直接分发
瓶颈转移了
这个项目最值得思考的不是技术细节，而是它揭示的一个变化：瓶颈的位置变了。
以前，从想法到产品之间横亘着一道技术鸿沟——不懂框架、搞不定接口、环境配不好、编译报错看不懂。现在 AI 把这道鸿沟填平了。
剩下的瓶颈是什么？是想象力，是你能多清晰地描述你想要什么。作者自己的总结很准确：AI 写代码，但决定做什么、怎么描述需求、判断结果好不好、方向对不对——这些全是人的工作。感觉更像是突然有了一个不知疲倦的技术合伙人，而你是产品经理。
对于那些"有想法没能力"的人来说，这可能是第一次觉得，想做一个东西的时候，真的可以直接去做。如果你也有一个烂在备忘录里的想法，不妨试试把它说出来——说给 AI 听，看看会发生什么。