我写了 10 年底层系统：Java、Go、分布式存储、区块链。前端？只跑过几个 React demo。
中间有几年转去做技术管理，一度以为自己这辈子不会再大规模写代码了——精力跟不上，手速也跟不上，平时顶多看架构图，IDE 都很少打开。
但过去这一年，AI 改变了规则。
更准确地说：AI 让产能不再是瓶颈，瓶颈回到了工程决策。
我不是"突然变会前端"，而是把工程方法论塞进了 AI 的嘴里，让它像一个工程团队一样被我指挥。
结果是——我这个"已经不写代码"的老兵，反而拥有了比以前更强的工程输出能力，甚至做到了以前做不了的事：
- 3 天撸出一个完整的全栈财务管理系统
- 用工程化的方式驾驭一个高复杂度的量化系统（Rust + 多链多协议 + 回测/实盘统一 + 7×24）
这两件事分别对应两个阶段：Vibe Coding 和 Vibe Engineering。
今天聊聊这两次跃迁。
第一次跃迁：Vibe Coding
最原始形态：对话即代码
先说那个财务系统的故事。
我们是分布式团队，之前报销一直用 Google Sheet 凑合。每次对账、审核都很痛苦——格式乱、流程散、找历史记录像考古。
刚好那时 GPT 的代码能力起来了，我决定试试：不画原型，直接对话做一个完整系统。
技术栈选了 Next.js + TypeScript + Tailwind CSS——AI 对这套生态支持最好。
需求怎么来？我就按用户视角描述给 AI：
- 用户注册登录、密码找回
- 报销提交、审核、拨付
- 后续迭代再加固定资产管理、虚拟资产管理、记账等功能
3 天跑通主流程。 更让我意外的是 UI 效果：简洁、优雅。以前自己写前端要么生硬要么耗时，现在 AI 直接给我一个优雅可用的界面。
这一层级的本质是：
用自然语言驱动产出，用试错换速度。 AI 抹平了前端门槛，很多 CRUD / 管理系统可以快速落地。
但说实话——这也是非工程师能做到的层级。真正的差距，很快会出现。
工程师拉开第一层差距：让它"可维护"
第一版确实 3 天上线了，自己用没问题。
但当我要继续加功能、改逻辑时，痛苦开始了：能跑，但越改越乱。
典型症状包括：
- 权限逻辑散落：页面里一段
if(role===...)，API 又一段，最后审计都不知道谁能改什么 - 数据模型漂移：同一个字段，表里叫
amount，接口叫totalAmount，前端又叫money - 结构失控：utils 变成垃圾场，components 什么都往里塞，越改越像拆盲盒
我意识到：纯 Vibe 出来的东西，能用，但维护成本呈指数上升。
这里有一个关键认知：
Vibe Coding 本身并不等于不可维护。 不可维护的是：没有工程意识的 Vibe Coding。
踩过这个坑之后，我逼自己做了三件很"工程"的事，效果立竿见影。
工程师的「Vibe 可维护三件事」
目标很简单：用少量约束，把 AI 的随机性收住。
1）先定技术栈，不要漂移
开工前绑死核心选择：语言、数据库、框架、部署方式。小项目最怕边做边换，成本会快速失控。
2）前端先定风格边界，再让 AI 生成
UI 不要完全靠对话临场发挥。先用 Stitch（可辅以 Figma）定好页面骨架、组件规范和设计风格，再让 AI 落地。避免多轮对话后风格跑偏。
3）锁住关键数据格式和工程边界
至少统一三件事：核心对象、字段命名、模块职责。保证单一事实源，避免 amount / totalAmount / money 这类模型漂移。
这三步对小项目通常已经够用：先把边界定住，再让 AI 在边界内提速。
还有一条隐性原则：每次只改一个模块，不做"一次性全量生成"。保持你对系统的掌控感，这样最稳。
第二次跃迁：Vibe Engineering——用工程思维指挥 AI
Vibe Engineering，不是让 AI 写更多代码。 而是用工程方法论来指挥 AI 的产出，并且守住系统的质量下限。
当项目从"一个可用的系统"变成"一个可持续演进的系统"，复杂度就不再是代码量，而是：模块边界、演进路径、质量下限。
第二次跃迁发生在另一个项目上：我做了一个量化交易系统。
它不是 CRUD，也不是"把页面堆起来就能跑"的东西，而是一个要长期演进、7×24 小时在线、还能不断长出新策略的工程系统。
难点有四个：
- 语言门槛：我选的是 Rust——性能和可靠性很强，但对工程化、并发模型、生命周期的要求也更高。
- 异构复杂度：要支持多条区块链、链上不同协议，数据结构、事件模型、交易细节都不一样。
- 三态闭环：同一套策略必须同时跑得通回测 / 线上模拟 / 线上真实交易，而且真实交易要 7×24 不间断。
- 效率与灵活性的矛盾：回测要快（吞吐、并发、IO 体系要对），但策略框架又要足够灵活。
到这个复杂度，Vibe Coding 的"对话即代码"就不够用了。你不能再让 AI 自由发挥，而必须用工程方法论去"收敛"它的产出。
这时候工程师必须亲自承担 4 件事。
① 设计边界：先行但不过度
我试过用 OpenSpec 驱动开发，发现太八股了——规范写得越细，和实际代码的偏差越大，维护成本反而更高。
最后找到的平衡是：
- 设计必须先行：先把框架、模块、边界与主路径定下来
- 但不要追求一次写完：留出迭代空间
- 做的过程中多重构，比一开始就想完美更高效
对复杂系统来说，设计的价值不是"写完美文档"，而是让系统持续收敛。
② 架构把控：你是架构师，AI 是执行者
模块划分、系统架构这些 AI 可以给你方案，但它无法替你做关键决策：
- 哪些边界必须硬隔离？
- 哪些组件必须可替换？
- 哪些约束必须写死？（比如策略层绝对不能直接操作私钥）
你说"帮我设计一个架构"，AI 能给你选项；但选哪个、怎么组合、怎么权衡取舍，这是工程师的活。
Vibe Engineering 的核心：始终自己掌控架构，让 AI 在你划定的边界内发挥。
③ 多 AI 协作决策：让不同模型互相挑战
复杂设计我从不只靠一个 AI。我现在习惯用 Gemini、Claude、ChatGPT 等多个模型共同探讨同一个问题。
- 有的擅长长上下文与推理
- 有的擅长创意发散与结构化表达
- 有的在某些技术细节上更敏感
我会让它们围绕同一问题互相"反驳"：让一个模型给方案，另一个模型专门挑刺、找边界条件。
在复杂系统里，最值钱的不是"多写点代码"，而是提前发现你没想到的失败路径。
④ 交叉 Review：一个人拥有多个"同事"
写完代码我会让不同 AI 互相 review：让 Claude review GPT 生成的代码，或者反过来。
不同模型有不同的盲区，交叉 review 能快速发现问题，同时提高代码质量。
更重要的是：它让 solo 开发者第一次具备了接近团队协作的质量保障能力。
我甚至给自己设了一个很土但极有效的**「质量闸门」**（你也可以抄）：
- 关键路径是否有最小回归测试？
- 数据模型是否单一事实源（命名一致、结构一致）？
- 权限/鉴权是否集中（不要散落在 UI）？
- 关键接口是否有错误码与可观测性（log/trace）？
- 是否留下下一次迭代的钩子（扩展点、边界清晰）？
加速交付的同时守住工程质量，这就是 Vibe Engineering 的意义。
两次跃迁背后的认知
认知 1：全栈能力从"加分项"变成"默认配置"
AI 让编码民主化了，但后端工程师的系统思维反而成了优势。
不会全栈不是"不擅长"，是"没跟上"。
先让自己变全栈，这是 AI 时代的基本功。
我一个写了 10 年后端、中间断档了几年的技术管理者，现在都可以 3 天撸一个全栈系统——你也可以。
认知 2：AI 让写代码变简单了，但需求怎么拆、架构怎么定、质量怎么守——这些反而更值钱了
需求拆解、架构设计、模块管理、质量把控——这些决定了 AI 能帮你走多远。
Vibe Coding 人人能做，Vibe Engineering 才是护城河。
你的工程判断力，就是你在 AI 时代的核心竞争力。
写在最后
AI 时代程序员的升级路径，我认为是：
先用 Vibe Coding 扩边界，再用 Vibe Engineering 建壁垒。
你现在更像哪一种？
- A —— 能跑，但越改越乱
- B —— 能跑，但不知道边界怎么守
评论区留个字母 + 你的痛点，我挑典型问题写下一篇。
👇 扫码关注，一起边学边做
