引言：AI 没有让系统变简单，它只是转移了复杂度
过去很长一段时间，我深度依赖 AI 编程。一个很真实的感受是：AI 解放了“实现力”，但无限放大了“系统失控风险”。
以前觉得“代码写出来能跑就行”，但现在变成“代码我必须解释得清楚，才敢上线”。目前的AI 能让一个人写得更快，但还没法让一个人真正撑起一个完整产品的质量底线。它只是把“写代码”这件事变简单了，并没有把“做系统”变简单——甚至，代码越容易产出，系统反而越容易失控。
在这个背景下，需要建立一套新的工作纪律。以下是我在实践中沉淀下来的浅显想法。
第一部分：掌控
面对 AI，最大的风险不是它会犯错，而是开始**“无意识地依赖”**。为了守住底线，将代码区分对待，并强制自己进行思维建模。
1. 不是所有代码都一样对待
核心逻辑：根据代码修改的成本和影响范围，决定 AI 的参与深度。这能帮我们合理分配有限的注意力。
我把代码分成三个风险层级：
- ✅低风险（高度依赖 AI）：如 UI 组件、样板代码（Boilerplate）、简单工具函数。这类代码出问题影响面小，改造成本低，可以大胆交给 AI。
- ⚠️中风险（AI 写，人 Review）：如业务逻辑、数据处理、状态管理。AI 可以起草初稿，但人必须过一遍，理解其数据流向。
- 🚨高风险（人主导，AI 参考）：如并发逻辑、缓存策略、权限安全、核心架构。这类代码我基本不会“直接用 AI 结果”，最多作为参考。
2. 强制“二次建模”
AI 写完之后，在脑子里重新建一遍数据模型。
不要只看代码是否跑通，而是追问自己：
- 数据是怎么流动的（从输入到渲染）？
- 状态在哪个环节发生变化？
- 哪个地方最容易出错（异常分支）？
如果讲不清楚这段代码在干嘛，即使它能跑，我也选择重写或弃用。这是从“调包侠”进化为“架构师”的必经之路。
第二部分：建立量化的质量防线
光有理念不够，必须落地为具体的行动。我在开发流程中植入了“最小验证”、“自动审查”和“可观测性”三把锁。
3. 用小成本换大安心
不用一上来就搞完整的 TDD（测试驱动开发），但至少要做三个路径的冒烟测试：
- 正常路径（Happy Path）
- 异常路径（Error Path）
- 边界测试（Edge Case）
实战案例：针对 AI 写的请求封装，写一个小测试：
// 测试缓存是否误存了失败请求awaitrequestFail();// 模拟失败awaitrequestAgain();// 立即重试 —— 验证是否还返回失败，还是错误地返回了缓存这种微型测试代码量极少，但能救命——尤其是在 AI 容易犯错的缓存和异步逻辑上。
4. 让 AI 参与“审查”
AI 写完初稿，我不仅看代码，还会把代码拷回 AI，要求它做 Code Review。
我的常用 Prompt：
“这段代码有什么潜在问题？”
“有没有边界情况没考虑？”
“如果是高并发场景会怎样？”
有时候，AI 确实能指出人类的思维盲区。相当于多了一层**“自动结对编程”**。同时，我们要练就火眼金睛，建立自己的 Code Review 清单（边界值、并发安全、索引命中率等），把质量把控做成绝对壁垒。
5. 给关键代码加“可观测性”
以前前端写日志总觉得多余，但现在不行。AI 写的代码，你无法完全预判其运行时行为，只能提高可观测性。
对于关键逻辑（如支付、鉴权、数据同步），我会强制加上：
- 关键路径
console.log（或业务日志） - 性能监控（Monitor）
- 错误上报（Sentry 等）
6. 控制“上下文复杂度”：拆分任务，步步为营
经验法则：不要一次性让 AI 生成太复杂的东西。越复杂的上下文，AI 越容易产生幻觉，产出越难 Review。
我的习惯是：
- 拆小任务
- 分步骤生成
- 每一步都进行验证
第三部分：自我进化
把 AI 当成“黑奴”浅尝辄止是不行的。把 AI 当成超级实习生，建立标准作业程序。
7. 建立自己的“可信代码库”（核心资产）
我把一些常用能力（请求封装、缓存策略、状态管理模式）沉淀成自己的私有实现。之后，AI 只能“调用”我的库，不能“改写”核心逻辑。
这样 AI 写的代码都在我的安全边界内运行，避免反复踩坑。
8. 完善测试护城河
以前我对“写测试”有点抗拒，尤其是前端，觉得页面能跑就行。但自从 AI 大量生成代码后，态度彻底变了：不写测试，我根本不敢提交代码。
现在必须把单元测试和集成测试纳入交付标准，确保重构和 AI 生成代码的可靠性。
9. 建立 Prompt 军火库
给 AI 喂极度精准的背景上下文（Context），设定严格的代码规范，通过多轮追问（Prompt Engineering）让 AI 迭代，甚至让 AI 先输出设计思路再写代码。建立属于自己的 Prompt 模板库，能让单兵作战能力飙升。
第四部分：处境最难的前端er
React 正在成为 AI 的默认答案，而 Vue 在全球 AI 生成代码的曝光度中明显“隐身”。
这并非框架优劣问题，而是技术生态在 AI 时代的映射：
- 训练数据的地理偏差（主因）：AI 的训练集是互联网的快照，严重偏向英文/美国视角。React（Meta）在英文社区占据压倒性语料优势，而 Vue 虽在中文互联网极其流行，但中文语料在大模型中的权重远低于英文。
- JSX 对 AI 生成的友好度：React 的 JSX 语法（HTML in JS）天然适合 AI 生成，结构、逻辑、样式在单文件中，无需协调
.vue、.html、.css多个文件，AI 生成出错率更低，可运行率更高。在 RLHF（人类反馈）阶段，“能跑起来的代码”获得高分，强化了 React 路径。 - 生态锁定效应：Next.js 统治 SSR/SSG 领域，绑定了 React；就业市场要求 React -> 开发者学 React -> 开源项目用 React -> AI 训练数据 React 多，形成了一个难以打破的自我强化循环。
Vue 真的消失了吗？
客观答案：没有，但在 AI 世界里隐形了。
- 国内大厂仍大量使用 Vue；Uniapp / 小程序生态绑定 Vue；Nuxt 3在 SSR 领域强势。
- 但在全球 AI 生成代码、英文开源社区的曝光度上极低。
给前端开发者的实用建议：
如果项目想用 Vue/Svelte，不要让 AI 自由发挥。你必须明确指定技术栈：
“用Vue 3 + Composition API + Vite实现一个待办事项应用……”
“用Svelte 5写一个计数器……”
结论：在 Vibe Coding 时代，“谁在决定技术的默认路径？”答案不仅是开发者，更是被训练数据统计结果所重塑的 AI。得清醒地意识到这种偏见，并主动干预。
结语：AI 是加速器，还是放大器？
最后，回到那个深刻的问题：AI 到底是在帮我们加速，还是只是把复杂度换了个地方？
我的答案是：AI 是“执行力”的加速器，却是“确定性”的放大器。
它把我们从繁重的重复劳动中解放出来，让我们有精力去思考更高阶的东西——业务模式、系统架构、DDD（领域驱动设计）。但同时，如果我们不守住“理解代码”这条底线，技术债务和线上故障会被无限放大。
我可以不写代码，但我不能不理解代码。
这条线一旦守住了，AI 是天使；守不住，它就是魔鬼。如果你也在用 AI 写代码，请务必保持这种“清醒的掌控感”。多出的人效，应该用来发展新的产品线，去解决业务痛点，而不是应付 AI 留下的烂摊子。
