最近科技界一扫前些年死气沉沉的阴霾，各种新东西乘着 AI 的东风纷至沓来。我自己分享欲也有点爆表，所以闲暇时 vibe coding 了两个小项目，想要尝试拓展一下自己表达的边界和形式。这篇文章先简单介绍一下两个项目，然后谈谈（作为一个“资深”程序员）在开发过程中的一些体会和感受。
项目简介
Magpie
首先是驱动我个人链接收藏页面的 Magpie (喜鹊，没错我就是很喜欢用鸟来给项目命名的人)，它是一个轻量级的链接收藏，后端接入 AI 模型，可以从链接 URL 中获取内容，自动提取标签以及合适的分类，甚至按需求写一些短评。你可以把它想成上个世代的各种 Read it later 服务的 AI 加强版，并且配套的管理后台、快捷指令和 Chrome 插件也都齐备了。
AI 贼船
其次是一个更简单一些的静态页面「上了AI的贼船」。我会不定期在这个页面分享我在使用 AI 工具进行日常开发，生活和娱乐等方面的心得以及实际的使用案例。在 build 时，我使用中文书写的内容会通过 LLM 自动翻译成其他支持的语言；当然，深浅颜色切换，feed 订阅这些基本要素也都完备。
Repo 地址
两个项目都已经开源在 GitHub 了。对于 Magpie，需要一个后端和数据库支持，为了方便起见，提供了 Docker 部署的方式；对于「AI 贼船」，由于是静态页面，所以直接 fork 后改改内容，找个 Netlify 或者 Vercel 这样的 host，就能很简单地完成部署了。
非常欢迎大家加星和尝试，以及提出建议。
开发中的 Vibe Coding 体验
我在上一篇博文中已经谈了一些 vibe coding 的初步感受，其中大多数印象都依然有效，不过也有一些更加深入的体验，我想再强调一下。
初始 plan 的重要性
这两个项目是纯 vibe coding 的产物：我一行代码都没有写过，使用的命令也就仅限于项目开始时的 mkdir 以及启动 agent 的命令 (codex)，更甚至给 AI 提示词也都是通过语音输入和 AI 后处理完成的。整个过程除了一台能够打开 terminal 和安装开发环境的设备外，并没有其他需求（包括键盘）。而其中接近一半的工作量，都是通过手机或者平板连接回家里的电脑完成的。我是真没想到，期望了多年的“iPad 当做生产力工具”，最终会以这样的方式得以实现。
这两个站点创作时的成功经验，无情地告诉了我一个事实：原有的创建 web app 的范式大概已经彻底终结了。那种技术调研、搭建脚手架项目、跑起 demo 、然后理解并实现需求，进入迭代开发的传统流程，在效率上完全被碾压。作为两个项目的 first commit (Magpie, AI 贼船)，我都采用了先聊清楚需求，然后生成持久化文档的工作方式，这对项目初期能够快速成型一个概念验证的产品至关重要。
对于目测可以一次成型的小项目（比如「AI贼船」这种规模），我在初期 plan 后向 AI 要求创建了一个待办列表，然后让 AI 严格按照列表逐一实现。这种待办列表的方式，在多个 context window 的对话里的重要性不言而喻，但是对于单个 context window，也能提供非常不错的效果：明确的经过人类审核的待办列表，能够引导 AI 注意力，以开发者最熟悉的路径（虽然这可能不是最快的路径）来实现初期产品。
Magpie 的情况要复杂一些：它实际牵涉到多个项目，包括 web 前端，API 后端，Chrome extension 等；在初期，就已经把数据库、针对 SEO 的 API 代理和首页渲染、各个页面的大体设计都确定了。在聊这个项目的初期需求时，我花费了大概两三小时和 AI 一起探讨了各个组件，并且让多个 AI 多次互相进行审阅和验证，最终生成了大约 2500 行的初期计划文档。事后证明，这些文档有效地指导了后续开发：它们不仅是未来 AI 进行后续开发的依据，也是对人类的提示。
就算是“随心所欲”的独立开发者，在 AI 时代，最好也多多“书写”（当然实际上肯定是 AI 代笔）人类和 AI 都能参考的程序设计文档。未来的 AI 和未来的你，应该都会感激这个当初的决定。
web app 断崖式的领先
基于 HTML、CSS 和 JavaScript 系语言的前端开发，在当前的 AI 辅助编程环境中展现出了断崖式的领先优势。这种领先不仅仅是技术层面的，更是生态和训练数据层面的全面碾压。
如果你让 AI 实现一个 React 组件，它不仅能快速生成符合最佳实践的代码，还能顺手帮你配上漂亮的 CSS 动画、响应式布局、无障碍访问支持，甚至还会贴心地加上 TypeScript 类型定义。对于 Next.js、Vue、Svelte 等流行框架，AI 更是如数家珍，各种最新 API 和最佳实践信手拈来。这种体验就像是请了一位经验丰富的全栈工程师，从数据库设计到前端交互，从 SEO 优化到性能调优，都能给你专业的建议和实现。
但当你把目光转向 iOS 开发时，情况就大不相同了。SwiftUI 的 API 变化太快，很多训练数据中的用法已经过时；UIKit 虽然稳定，但 AI 经常会产生一些让人啼笑皆非的“创新”用法。更不用说那些相对小众的领域，比如 macOS 桌面应用开发或者 watchOS 开发，AI 的表现更是参差不齐。
这种差异的根本原因在于训练数据的丰富程度。前端开发的开源项目数量庞大，GitHub 上的高质量前端代码库数不胜数，这为模型提供了充足的“养料”。而 iOS 开发相对封闭，很多商业项目的代码不会开源，导致训练数据相对匮乏。
不过，这种差距正在逐渐缩小。随着更多开发者开始使用 AI 进行 iOS 开发，新的训练数据也在不断积累。但至少在当下，如果你想要体验最丝滑的 vibe coding，web 前端开发依然是首选。
“幕后”设计的巧思细节
设计的 sense 很重要，一些设计上的小巧思和细节，很可能成为 AI 做不到但是人类可以的部分。几个例子。
配色方案的选择
既然是 Magpie (喜鹊)，最简单的想法就是在大自然中寻找灵感。
很容易提取一个相对漂亮的色盘，配合一些想象，就可以大致确定出配色了。
高亮悬停
- Magpie 的悬停高亮。初期 AI 挑选了一个没有动画的实现，且高亮部分只是链接部分。问题不大，但是不好：没有动画的高亮显得十分急躁，高亮区域是一个孤岛。
- 后来进行了重新设计，添加了和呼吸节奏相近的缓慢淡入淡出，希望读者能够以更平和的状态进行阅读。同时让高亮和边栏采用同样的颜色，让高亮时融为一体，不那么突兀。
小设计增加“交互感”
AI 在实现基础功能和调整布局时非常好用，但是生成的页面总会有些冰冷。我在 Magpie 中加入一些悬停动效，增加页面的趣味性。
对于「AI贼船」，希望能更专注提供的内容。在页面顶部我添加了大范围的留白，这让站点标题更加突出；为了让页面不要全是文字，结合站点标题准备了一艘小船图标作为标题的补充；为了能让站点具备一定的动态感，为标题和图标添加了悬停动画，让小船能真正“出航”。
在 vibe coding 的环境下，对这些细节的思考和实现所花的时间，甚至超过了页面的业务逻辑本身。不过也正是这些地方，才能让你的 app 免于千篇一律。
我当前使用的工具
Codex 为主力，GLM-4.6 作为补充，达到相对平衡。由于个人感情和可能的法律风险，以后应该也不再会使用 Claude Code。Magpie 的前半程使用的是 Claude Code，后半程切换到 Codex 接手；而「AI贼船」则是完全的 Codex 产物。
当前的 LLM 用户忠诚度接近于零，新模型吊打旧模型是业界常态，于是用户也像候鸟一样来回迁移。除了年付费的那些可怜孩子受伤之外，这种激烈的竞争态势对于用户其实是好事。一些产商试图通过应用层来建立一些使用壁垒（比如引导用户创建 commands 或 subagent 等），但是这种努力在模型的差距或者性价比等更重要的指标面前，往往显得苍白无力。
当一个新的模型在核心能力上实现突破时，用户迁移的成本其实很低。那些精心设计的 commands、subagent 配置，在新的模型面前可能只需要几分钟的复制粘贴就能达到类似的效果。这种”降维打击”让应用层的护城河变得异常脆弱。真正能够留住用户的，还是模型本身的能力和性价比。
而模型显然具有”个性”，在长时间使用后，你会逐渐发现每个模型都有自己独特的”脾气”。Claude 相对啰嗦但细致，它喜欢把每个决策的前因后果以及自己正在做什么都给你解释清楚，有时候还能提供一些 “You are absolutely right” 的情绪价值。这种特性在需要对项目理解和或是实现一些简单的测试和挖掘任务时表现出色，但处理困难任务时可能会让人觉得效率不高，且容易被用户带偏。
Codex 则完全是另一种风格——人狠话不多，总是直达要害。它几乎不解释为什么这么做，往往就自己闷头苦干十来分钟，然后直接给出的一个简洁有效的解决方案。这种特性就仿佛再和一个扫地僧对话，一个眼神胜过千言万语。不过，有时候这种”含蓄”也会带来问题，比如架构设计或是研究时，除非明确要求解释，否则缺少互动可能会让开发者难以理解其思路。
想要高效使用某个模型，确实需要一定时间进行习惯。你需要了解它们的强项和弱项，以及边界大概在哪里，并在不同的任务中选择最合适的工具。有时候，甚至需要在同一个项目中混合使用不同的模型，让它们各自发挥所长。
当代码变得廉价时
在这一节里，我想跳出刚才这两个具体的项目，来说一些“形而上”的东西，谈谈新时代里我们一般开发者所面临的困境。
其中最大的疑惑应该是：AI 写的代码往往又快又好，作为工程师，应该怎么办？当代码的生成成本趋近于零时，我们的价值在哪里？这可能是每个开发者都需要重新思考的问题。
精确表达和快速验证
如果要说最应该学习的一项技能，我认为会是如何向 AI 清晰地表达需求。一个模糊的需求会产生模糊的代码，而一个清晰的需求则能产生高质量的有效代码。表达能力是高效正确使用 AI 的基石。（所以大家多写博客锻炼吧！😂）
现在真的是一个有点子就能实现的世界：不会有人再喊“就差一个程序员”了，也不会有人再有借口能说“我不懂设计，所以就先做个凑合的”。当代码书写和设计修改都变得廉价时，实现的速度不再是瓶颈，验证的速度反而变得更加重要。AI 可以在几分钟内生成上千行代码，但验证这些代码的正确性、安全性和性能，可能需要数倍的时间。
在 AI 时代，程序员的角色正在从“代码编写者”转变为“代码验证者”和“需求定义者”。我们需要能够快速判断 AI 生成的代码是否满足需求，是否安全可靠，是否易于维护。这种验证能力，新时代里会比单纯的编码能力更加重要。而这正是当下的软件开发者相较其他直接所掌握的核心优势：我们理解 AI 的运作方式和我们自己产品的运作方式，这种验证天然是开发者的任务。
尝试掌握复合型的知识
单一的技术栈知识现在正在快速贬值。AI 可以轻松掌握某个具体框架的用法（比如使用 effect 改变 UI），帮助你完成某个明确的任务（比如将按钮改成圆角），但它其实还很难理解不同领域之间的内在联系和权衡取舍。
举个例子，当你要设计一个高并发的系统时，AI 可以帮你写出漂亮的代码，但它可能无法理解为什么在某些场景下选择 Redis 而不是 MySQL，为什么在某些情况下需要引入消息队列，以及这些技术选型背后的业务逻辑和团队能力考量，这是你需要指挥 AI 去完成的。
复合型知识意味着你要能够跨越多个技术领域，理解它们之间的协同效应。你要知道前端性能优化如何影响后端架构，数据库设计如何影响应用层代码，以及安全考虑如何贯穿整个技术栈。这种跨领域的理解能力，是 AI 目前难以企及的。
更重要的是，复合型知识还包括对业务领域的深入理解。AI 可以写出完美的代码，但它无法理解你的用户为什么需要某个功能；AI 可以帮你把某个按钮往上往右调整一些，但它也无法理解为什么这个按钮需要在这个位置才是最优。这种业务、技术和设计结合的能力，是人类工程师当前的真正价值所在。
依靠工程师的嗅觉生存
虽说没有自己亲手写代码，但我仍然会看一眼生成结果。在完成一块需求后，我会要求 AI 把实现思路讲给我听，从架构、边界条件到异常处理都过一遍，再凭经验判断这种实现方式是否合理、是否容易在未来出问题。这其实就是“工程师嗅觉”——一种对代码质量、架构平衡和潜在风险的直觉判断。这其实需要实际的工程经验和踩过一些坑。
在 AI 时代的原生项目里，几乎可以让 AI 参与到每一个环节：从需求分解、接口设计到代码实现与文档生成，自动化程度非常高。但也正因为如此，更需要人为地去思考「扩展」与「维护」的问题。AI 能在一天内产出一个看似完美的功能模块，却未必考虑到未来的扩展性、性能瓶颈或团队协作成本。这会为未来埋下隐患，今天的小错误会积累到明天后天，然后在某个时刻不受控地爆炸。
相比之下，已有项目虽然 AI 的参与度会低一些，却能受益于既有的架构规范和代码风格。指挥 AI 遵守当前的模块边界、命名规则和测试策略，反而能让它成为一个合格的“团队成员”，而不是一个失控的自由开发者。这样生成的代码更容易被接手、被复用，也能在长期维护中保持方向一致，不至于被一次次“聪明”的生成结果带偏。
利用独特的工程师嗅觉，分辨 AI 写出的 good code 和 bad code，是 copilot 和 vibe coding 中工程师的新责任。
总结
在此刻，其实我又不禁回想起 20 年前乔布斯的那句“求知若饥，虚心若愚” (Stay hungry. Stay foolish.)（2025 年）。可能你有所不知，这句话其实最早是半个世纪前《全球概览》休刊时的封底告别语（1974 年）。它穿越过 1976 年 Apple I 诞生所引领个人电脑革命，见证了 2007 年 iPhone 横空初始所划破的长空。如果说这几个月以来，在我和 AI 高强度共生后所能参悟到的新的“信条”的话，我希望能以这一句话做一个暂时的小结：
AI 的强大在于它的“全知”，而人类的优势则在于“通识”。AI 的全知确实让人可以无知，但其实唯有那些不甘于无知的人，才有资格在新的时代立足。
「Stay hungry. Stay foolish.」我感觉，在今天，这句话的分量无比之重。你，我，我们，甚至于整个人类，可能比以往更需要保持不断学习和虚心。