vibe coding 在复杂老项目中的实战
最近在几个项目里测试不同的 AI 开发方式，其中就包括：能否用 vibe coding 推动一个复杂老项目的二次开发。本打算做完对比实验再写总结，但对 vibe coding 有很多不吐不快，就先单独成文。
概述
简单介绍一下项目，该项目是在 原鼠须管输入法（Rime for macOS）基础上二次开发，仓库见 RJiazhen/squirrel-flypy。 本次主要做了两块小功能：
- 小鹤音形配置文件整合；
- 快速加词弹窗及相关逻辑。
涉及的技术栈包括：
- Swift
- Git 子模块
- GitHub Actions
读者们不需要理解这些具体是什么技术，只需要知道这些技术面非常广，虽然没有典型的互联网项目的后端与数据库，但整体复杂度仍然不低。
个人侧：长期以前端与工程化为主，Swift 只有少量接触，基本可以认为是个「小白」，正好适合用来试 vibe coding。工具上主要用 Cursor，并搭配 OpenAI 的 Codex。
结果：磕磕绊绊地完成了
从结果看，功能算是落地。按我的粗估，熟手不用 AI 做这两块，大约 24–32 小时；我断断续续约 7 天，累计 40+ 小时。在实际开发过程中，AI 写功能代码的时间其实并不多，更多耗在若干卡点上反复试错，例如：
- 沿用项目原有打包配置，给重命名后的工程打发布包；
- 尝试用 MCP 接 Xcode，拿运行日志并驱动自动修复 bug；
- 跑通 GitHub Actions 的测试与发布；
- 尝试修复右键菜单里异常消失的菜单项（最后仍未解决，只能砍掉该功能）；
- 基本只会死啃代码，而不会主动去翻原项目在 GitHub 上的 wiki 和搜索其他的相关的资料。
此外，「完成」不等于「做得完美」：仍有各类 bug，只能等后续再修复。
这些情况也归结为几类常见的 AI 开发问题：
- 怎样让 AI 识别并接上既有工程化与 CI/CD？
- 怎样让 AI 真正接入测试，并闭环到自主发现与修复？
- 怎样让 AI 获得足够项目相关信息（尤其缺文档、缺注释的老项目）？
难以评估的安全性
我自 2022 年底以来就在用 AI 辅助写代码，但一直没把纯 vibe coding 当成默认选项，主要原因就是很难判断改动质量，也很难评估安全风险。
这次同样如此：我没有全程交给命令行工具或 Cursor Agent，多数时候还是在 Cursor 侧边栏里对话。一是想顺带看看它改动了哪些文件（能看懂的其实不多）；二是不少步骤仍离不开图形界面。
实际使用中，自动化脚本被频繁修改并执行，也会出现使用 Python 脚本调用外部工具的情况；Cursor Agent 对工作区外文件的读写也比较开放。负责打包、发布的那类脚本也有被大幅改动，每次运行这些脚本都会让人紧张（其中涉及需要输入本机账号密码才能完成授权的步骤）。
总的来说，主要是这些情况让我对 Coding Agent 的安全性不太放心：
- 读写工作区外的路径；
- 安装并运行外部工具包；
- 生成临时脚本并直接执行；
- 大面积修改构建、发布相关脚本。
在更常见的 AI 协作开发里，同样会出现「生成脚本并执行」，但频率和体量一般不会到这种程度；对我不熟悉的项目来说，仅从脚本字面也更难判断后续会发生什么。
复杂的开发体验
在一般的 AI 辅助开发里，AI 多半只承担一部分编码和查漏；方案、审阅、功能测试仍然主要靠自己。相对的，很多 vibe coding 的叙述会把重点放在：需求讲清楚就够了，其余尽量交给 AI，人只需要做验收。
在初上手时确实很爽：讲好需求并与 AI 多轮对齐之后，就可以在对话框里看到它连续输出一长串工作说明，自己只需要玩手机，等结果验收就可以了。
但问题就在于，现在的 Coding Agent 能力还很难一次性验收通过。一旦结果有问题，就会进入反复拉锯：除了按 AI 给出的步骤自检，往往还要补充报错信息、日志、复现路径，问题才能继续推进。更常见的是同一处来回修改仍然失败，最后只能自己亲自查看代码指出更具体的疑点——这就已经不是纯粹的 vibe coding 了。
顺带吐槽一下 Xcode 的 MCP 接入，本来以为配置后就可以直接让 AI 接入 Xcode，用来自动获取运行日志并驱动自动修复 bug，实际却是 Xcode 每次重启后都需要重新授权；再加上输入法项目经常要在 macOS 上注销和重新登录账户，实在是把我弄烦了。最后干脆直接让 AI 把日志写到文件里，再自行读取排查。
结论：vibe coding 无法应对复杂工程
在正常开发里，开发者最终还是要面对代码本身；而 vibe coding 则是把项目当成黑盒，只关注输入输出。但以当前这一代 AI，复杂老项目仍旧很难从头到尾一口气独立完成，必然需要开发者去打开黑盒，亲自查看代码。而到那一步时，代码往往已经被 AI 改得极度复杂，可维护性大打折扣。
这一问题的核心在于：单靠模型与 Agent，还不足以扛起复杂工程的全程交付。 OpenAI 关于 Harness 的文章也从侧面说明：即便像 Codex 这样的 Coding Agent，仍需要大量提示词约束，并结合周期性的重构，才能稳住长期质量。因此，全流程只靠 vibe coding、几乎不介入实现细节，很难覆盖这类老项目的开发。
接下来我还会新开一个项目，测试用 OpenAI 那套强约束提示词体系再跑一轮（以前在生产里也试过类似思路，只是约束没那么系统），有结论再写一篇对比。