引言：三万英尺高空的反思
在飞往某个目的地的航班上，@rudrank 写下了这篇坦诚的反思。没有网络的三小时里，他无法"tokenmaxxing"——也就是那种把提示词丢给 AI、等待魔法发生的开发方式。
他的 App Store Connect CLI 项目已经接近 30 万行代码，有创始人想把它集成到影响数亿设备的发布流程中。但问题是：他自己不会写 Go。
“我知道命令怎么用，但我不会 Go 语言。”
这不是一个技术能力的问题，而是一个工程哲学的问题：当 AI 生成的代码从"GitHub 上的个人玩具"变成"生产环境的基础设施"，我们需要什么样的开发范式？
Vibe-Coding 的黄金时代
什么是 Vibe-Coding？
Vibe-coding（氛围编程）是 AI 时代的新现象：
- 有个想法
- 打开 Cursor/Claude Code
- 输入 “pls fix” 或类似提示
- AI 生成代码
- 能跑就行，不深究
@rudrank 承认他用这种方式在一小时内搞定了 TestFlight 反馈和崩溃日志的 MVP。听起来很美好，对吧？
为什么它曾经有效
- 速度极快：几小时出原型，几天出功能
- 门槛低：不需要精通语言就能产出
- 试错成本低：个人项目，坏了就修，不行就删
但当项目开始被严肃对待时，问题浮现了。
临界点：当玩具变成基础设施
第一个信号：代码量与理解度的背离
@rudrank 的项目有近 30 万行 Go 代码，但他坦承：
“我只懂表面。”
这造成了几个连锁反应：
| 问题 | 后果 |
|---|---|
| 命令结构散乱 | 用户学习成本高，API 不一致 |
| 缺乏架构设计 | 新增功能困难，改动牵一发而动全身 |
| 测试覆盖不足 | 边界情况处理不可靠 |
| 无法评估 trade-offs | 技术决策质量低 |
第二个信号：维护成本超过开发成本
朋友找他实现 fastlane 的 parity（功能对等）。模型估计：
- 完整 parity：5-6 个月 + 1 个资深 Go 工程师
- MVP：7-8 周
@vibe-coding 的速度优势在面对系统性重构时消失了。因为：
- 不能简单删除重写（已有用户）
- 必须走废弃流程（deprecation）
- 需要向后兼容
- 每个改动都要考虑影响面
第三个信号：责任的压力
“有创始人想把我的 CLI 放进他们的发布流程，影响数亿设备。”
这是关键转折点。当代码的影响范围从"我自己"扩展到"数百万用户"，“vibe"就不再是一个可接受的开发策略。
新的范式：Agent 协作工程化
@rudrank 没有回到手工编程。相反，他提出了一个更 nuanced 的模式：
核心转变
| Vibe-Coding | Agent 协作 |
|---|---|
| “帮我写这个” | “我们一起设计这个” |
| 不参与设计过程 | 深度参与架构决策 |
| 不 review 代码 | 系统性审查流程 |
| 不了解实现细节 | 要求解释 trade-offs |
| 追求速度 | 追求可靠性 |
具体实践
1. 设计阶段的人机协作
不再是把需求扔给 AI，而是：
我：我想实现 X 功能
Agent：我建议方案 A（优点/缺点）和方案 B（优点/缺点）
我：考虑到我们的使用场景，A 更好，但能否优化 Y 部分？
Agent：可以，这里有三种优化方式...
关键：人做决策，AI 提供选项和分析。
2. 强制性的代码审查流程
@rudrank 的新 checklist：
- Agent 解释设计思路和关键决策
- 评估 trade-offs（性能 vs 可读性 vs 维护性）
- 检查工具调用是否可以优化（减少 API 调用次数）
- 验证测试覆盖（尤其是边界情况）
- 确认是否符合项目整体架构风格
3. 渐进式重构而非大爆炸
对于现有的 30 万行代码，策略是：
- 选定一个命令模块
- 用新流程重新设计和实现
- 对比旧版本，确保行为一致
- 标记旧版本为 deprecated
- 给用户迁移时间
- 最终移除旧版本
这比"一晚上 vibe 完"慢得多，但是可持续的。
深层洞察：AI 时代的软件工程本质
洞察 1：代码生成不等于软件开发
AI 让写代码变得廉价，但设计系统依然昂贵。
Vibe-coding 混淆了这两者。它假设：
- 如果能生成代码，就能交付软件
- 如果功能 work，就是好的实现
但现实是：
- 代码只是软件工程的输出之一
- 架构设计、测试策略、可维护性、文档——这些都无法 vibe 出来
洞察 2：复杂度守恒定律
无论 AI 多强大，系统的内在复杂度不会消失，只会转移。
| 阶段 | 复杂度位置 |
|---|---|
| 手工编程 | 人的大脑（设计 + 实现） |
| Vibe-coding | 被掩盖（直到爆发） |
| Agent 协作 | 人机交互界面（设计决策） |
Vibe-coding 的问题在于把复杂度"外包"给了未来——那个不得不还债的未来。
洞察 3：责任与理解的正比关系
“我不会手动写代码了，但我投入在过程中的精力和写代码一样多。”
这是最关键的认知升级。
当代码影响数亿设备时，作者需要对它有深度理解——不是每行代码怎么写，而是：
- 架构决策的理由
- 各种 trade-offs 的权衡
- 失败模式的分析
- 长期维护的策略
这些理解无法通过"看 AI 写代码"获得，必须通过主动提问、批判性思考、系统性 review 获得。
可实践的建议
如果你正在用 AI 写代码
✅ 应该做的
-
要求解释
"请解释这个设计方案的关键决策点" "为什么选择 A 而不是 B？" "这个实现在什么情况下会失败？" -
建立 Review Checklist
- 设计合理性
- Trade-offs 分析
- 测试覆盖
- 性能影响
- 可维护性
-
从小模块开始迭代
- 不要试图一晚上 vibe 完整个项目
- 先搞定核心抽象
- 再逐步添加功能
-
投资测试基础设施
- AI 写的代码更需要测试
- 重点覆盖边界情况和错误路径
- 自动化回归测试
❌ 不应该做的
-
“pls fix"然后不管
- 这是 vibe-coding 的标志性反模式
- 短期省时间，长期埋雷
-
盲目追求代码量
- @rudrank 说得好：“真正的 flex 是用更少的代码行数”
- AI 容易生成 verbose 的代码
- 要 actively 要求简化
-
忽视架构一致性
- 每个新功能都要符合现有架构
- 不一致比缺失功能更糟糕
如果你是团队负责人
-
定义 AI 使用的成熟度模型
- Level 1: 个人 vibe-coding（原型阶段）
- Level 2: 有 review 流程的 AI 辅助
- Level 3: 系统化的 Agent 协作工程
-
建立共享的上下文
- 用 Skills（Claude Code）或类似机制固化团队标准
- 确保 AI 生成的代码符合组织规范
-
投资代码理解工具
- 架构可视化
- 依赖分析
- 复杂度度量
结语：未来的开发范式
@rudrank 的觉醒代表了一个更广泛的转变：
“这就是我想象中的未来——高度专注，与 Agent 协作，让它负责实现和测试，给我几乎无 bug 的输出。”
注意这里的措辞：
- 不是 “让 AI 替我开发”
- 而是 “与 Agent 协作，我专注设计和决策”
AI 没有降低软件工程的门槛，而是改变了门槛的位置。过去你需要精通语法和框架；现在你需要：
- 系统设计能力
- 批判性思维
- 工程判断力
- 对质量的执着
Vibe-coding 是一个有趣的实验，证明了 AI 的能力边界。但当代码走出个人项目、进入生产环境时，我们需要更严肃的态度。
不是因为 AI 不够好，而是因为我们对用户负有责任。
参考资源
- 原文：Stopping Vibe-Coding for Good by @rudrank
- 相关讨论：The Complete Guide to Building Skills for Claude
- 延伸阅读：Writing code is cheap now by Simon Willison
本文作者：VictorHong
最后更新：2026-02-23
