一篇文章引发的前端思考
最近读了一篇文章，叫 《Why Your "AI-First" Strategy Is Probably Wrong》，是 CREAO 的联合创始人写的——他们是一家 25 人的 AI 智能体平台公司，前 Meta LLaMA 团队成员。文章的核心观点是：绝大多数声称"AI优先"的团队，其实只是"AI辅助"。
"他们只是在原有工作流里加了一个 AI 工具，而没有围绕 AI 重新设计整个工作流。"
BCG（波士顿咨询）2026 年调研印证了这一点：近三分之一的公司去年将超过 1.7% 的营收投入 AI，但 60% 的企业报告收益极小甚至为零——问题不在技术，在于工作方式没有真正改变。
区别不是工具用了多少，而是流程有没有被重新设计。
AI 辅助
AI 优先
这两者的差距不是加法，而是乘法。
还有一种常见形式叫做"氛围编程（vibe coding）"：打开 Cursor，不断对话直到代码能跑，提交，周而复始。这充其量只能产出原型。生产系统需要稳定、可靠、安全——需要一套体系来保证 AI 写出的代码也具备这些属性。真正要构建的是这套体系，提示词本身是用完即弃的。
"vibe coding" 由 OpenAI 联合创始人、前 Tesla AI 总监 Andrej Karpathy 于 2025 年 2 月命名，同年入选柯林斯词典年度词汇。
OpenAI 在 2026 年 2 月给了这件事一个名字
工程团队的首要工作不再是写代码，而是构建让智能体能够可靠工作的"脚手架"。当出现问题时，解决方案不是"再努力一点"，而是：缺少哪种能力？如何让智能体能够理解和执行？
🧪 测试基础设施
使 AI 生成的代码可验证。不能自动测试智能体写的代码，就不能信任智能体写的代码。
👁 可观测性
每个服务输出结构化的、可查询的信号。如果 AI 无法读取日志，它就无法诊断问题。
🚀 确定性部署流水线
CI/CD 门禁不是为了减慢速度，而是为了让 AI 快速工作时保证安全。流水线可预测，智能体才能推理失败原因。
🔀 功能开关
每个功能在开关后面发布，随时可回滚。风险可控，才敢让 AI 快速迭代。
驾驭工程是基础设施工作，和应用代码无关，但它决定了应用代码是否可靠。《重构》作者 Martin Fowler 在同一时期也写了一篇文章，核心观点一样：当 AI 成为主要的代码编写者，工程师的工作就变成构建让 AI 可靠工作的基础设施。他把这件事也叫 Harness Engineering。
组合起来之后，会形成一个每天自动运转的循环。以文章中的团队为例：
人在整个循环里只做一件事——决定"这个问题要不要现在修、修到什么程度、会不会影响线上用户"。
把这个框架映射到我们的日常工作
文章有一个关键决策：把分散在多个仓库的代码统一成 Monorepo，原因只有一个——"让 AI 能看到全貌"。
分散的代码库对智能体来说是不可见的，统一的代码库才是可读的。
映射到我们前端：组件命名是否一致、可预测？样式方案是散落的 CSS 文件，还是有统一的变量体系？状态管理的模式是不是每个项目各写各的？接口对接有没有统一的请求封装和错误处理？目录结构能不能让 AI 不看文档就理解模块边界？
这些本来就是前端工程化的好实践，现在多了一个新的理由：让 AI 能更好地帮我们干活。
文章里有一句话说得很直接：构建时间两小时，测试时间三天——这不是在解决问题，只是把瓶颈往下游挪了三米。
验证必须与实现同速，否则 AI 带来的速度优势会全部堆积在 QA 环节消失掉。
但前端的验证有两个难题。逻辑层——状态流转、接口对接、缓存同步、异步竞态——大型项目里这些组合起来的复杂度不亚于后端，现有的测试方案各有短板，没有银弹。视觉层——"这个页面长得对不对"——连写成测试用例都做不到，很大程度上依赖人眼。两层都缺通用解法，这个问题我们后面展开。
文章的判断是：快速写代码的能力每个月都在贬值，评估、批判和引导 AI 的能力则在升值。从个人技能角度，具体到前端有三个方向：
交互判断力
这个交互方案好不好，用户会不会迷失——AI 可以生成代码，但它没有用户感知。
性能系统思维
AI 能写代码，但不会主动做架构级的性能决策——首屏优化、渲染策略、资源加载这些属于系统判断。
AI 工程能力
不只是用 AI 写代码，而是有能力设计让 AI 自主运转的系统：拆任务、给上下文、搭工作流、构建自动化流水线。这就是文章开头说的，从 AI 辅助到 AI 优先。
逻辑和视觉，两层都缺通用解法
前端的验证难题分两层，都没有通用解法。如果有，就不需要人盯着 AI 写代码了。
| 生成代码难度 | 自动验证难度 | |
|---|---|---|
| 后端 | 较高（需理解业务逻辑、数据模型） | 低——测试用例明确，结果确定性高 |
| 前端 · 逻辑层 | 高（状态联动、异步竞态、缓存同步） | 高——能测但测不全，每种方案各有短板 |
| 前端 · 视觉层 | 较低（UI 组件、页面结构相对直观） | 高——视觉和交互正确性难以形式化 |
逻辑层面
视觉层面
交互层面
状态组合层面
逻辑层的测试方案
单元测试
能覆盖纯函数和独立逻辑，但前端大量逻辑绑在组件生命周期和渲染上下文里，脱离环境就不真实。
集成测试
更接近真实场景，但 mock 管理是噩梦——mock 和真实 API 一旦不同步，测试全绿上线就炸。
视觉层的测试方案
快照测试
把组件渲染出的 DOM 结构存一份，下次对比有没有变。比的是代码输出不是视觉效果——改了个 class 名就报错，视觉可能没变。
视觉回归测试（Chromatic / Percy）
在真实浏览器里截图做像素级对比。比快照更准，但一个像素变了就标出来，不管有没有意义。
跨两层的方案
E2E 测试（Playwright / Cypress）
从用户视角操作页面，能同时触及逻辑和视觉两层。但粒度粗、速度慢、维护成本高，只能验证最终结果，中间的状态流转和竞态问题看不到。
结论
每种方案只覆盖一部分。两层加起来，没有哪种方案能让人放心说"AI 写的代码没问题"。
方向在分两条线演进：TestSprite 走的是 AI 自主生成和执行测试的路径，通过 MCP 集成进 Cursor 等编码工作流，选择器失效时可自动修复——但它本质上是测试平台，不改业务代码；Percy 走的是视觉回归检测路径，通过 AI 过滤无意义的像素差异、减少误报。两条线解决的是不同问题，目前也都处于早期。人工审查短期内仍不可替代。
什么不会被替代
文章的判断：快速写代码的能力在贬值，但架构判断、系统性思维、对"好的"的识别力——这些在 AI 时代反而更稀缺，因为 AI 最难替代的恰恰是这些判断力。
"批判 AI 的能力将比生产代码的能力更有价值。" — 文章作者
文章里还有更多关于角色分工和转型路径的讨论，感兴趣可以看原文。
结合我们自己的情况
① 团队的隐性知识，AI 进不了传递链
组件库升级了一半，旧写法和新写法同时存在——老员工知道"新页面用新的"，AI 看到哪个学哪个。某个接口封装绕过去会触发历史 bug——这件事在老员工脑子里，没有文件，AI 可能直接调原始接口。
这类知识靠"老带新"维持，AI 进不了这个传递链。它读不到的，就等于不存在。
② 有没有最基本的自动验证？
文章说"驾驭工程"第一条就是测试基础设施——不能自动测试，就不能信任 AI 写的代码。
如果项目连基本的自动化测试都没跑起来，那不管 AI
多强，生成的代码对不对，最终全靠人看。这可能是当前最大的瓶颈。
③ 从"用 AI"到"为 AI 而建"
前两个问题都是具体的切入点，但背后指向同一件事：我们现在是把 AI 加进了已有的工作流，流程本身没有变。
AI 辅助和 AI 优先的差距不在工具，在于有没有把流程、架构、验证体系围绕 AI
重新设计。
如果有经验或想法，欢迎聊聊。