夜雨聆风很多前端工程师开始使用 AI 之后，第一感觉是：效率明显变高了。
以前要查文档，现在直接问。
以前写一个组件要半小时，现在几分钟就能生成初稿。
以前写测试、写注释、写说明文档都觉得麻烦，现在让 AI 起一版，很快就有结果。
这种提升是真实的。
但过一段时间后，也会出现另一种情况：
AI 生成得很快，但你改得很久。
一开始看起来代码完整，接进项目后到处不适配。
它帮你写了一个方案，但你后来发现边界没考虑清楚。
它解释了一段报错，但方向其实是错的，你跟着排查半天才发现问题不在那里。
这时候就要警惕一种东西：
假效率。
所谓假效率，就是局部看起来变快了，但整体并没有变快；当下好像省事了，但后面付出了更多返工成本。
AI 工具越常用，越需要识别这种假效率。
生成快，不等于交付快
AI 最明显的能力，是生成速度快。
你给一个需求，它能迅速给代码。
你贴一段逻辑，它能迅速解释。
你让它整理文档，它也能马上输出一版。
但真实开发里，速度不是只看“第一版出来得快不快”。
还要看：
能不能接入项目？
是否符合已有代码风格？
类型是否准确？
边界状态是否完整？
业务规则有没有误解？
后续维护成本会不会变高？
如果 AI 生成的东西需要你大量修改、反复校准、重新拆解，那它只是让你更快看到一个初稿，并不一定真的缩短了交付链路。
很多时候，工程里的效率不在“写得快”，而在“少返工”。
一个慢一点但边界清楚的方案，可能比一个五分钟生成、后面改两小时的方案更高效。
最容易出现假效率的，是模糊需求
AI 很怕模糊需求。
但它不会像一个谨慎的同事那样停下来问你：“这里需求不清楚。”
它往往会直接补全。
你说：
帮我写一个审批列表页面。
它会默认你需要搜索、分页、状态筛选、操作按钮、弹窗、接口调用。
看起来很完整。
但真实业务里，审批可能有角色权限、状态流转、撤回、转交、驳回原因、二次确认、批量操作、超时提醒。
如果这些没说清楚，AI 就会按照通用模式猜。
猜得越完整，越容易让人误以为需求已经清楚了。
这是假效率里最危险的一种：
它把需求的不确定性，包装成了代码的确定性。
代码写出来了，但问题没有被解决。
只是被推迟到了联调、测试、上线前，甚至线上。
所以，当需求还模糊时，不要急着让 AI 写代码。
更好的用法是先问：
这个需求可能有哪些需要确认的业务规则、角色权限、状态流转和异常场景？请先列问题，不要写代码。
先让 AI 帮你暴露不确定性，再进入实现。
这比快速生成代码更有价值。
AI 会放大你的判断力，也会放大你的偷懒
AI 工具很有意思，它对不同人的放大效果不一样。
如果你本来就会拆问题，AI 会帮你更快推进。
如果你本来就重视类型、边界、测试和可维护性，AI 会帮你减少重复劳动。
如果你本来就会做技术判断，AI 会成为很好的第二视角。
但如果你一开始就想跳过思考，AI 也会配合你跳过。
你不想梳理状态，它直接给你几个 useState。
你不想设计类型，它直接给你 any 或宽泛对象。
你不想判断组件边界，它直接把请求、状态、渲染、业务操作都塞进一个组件。
你不想写测试，它也不会强迫你补。
这就是问题所在。
AI 不会天然把你带向更好的工程习惯。
它更多是在放大你的当前习惯。
你认真，它能提高质量和速度。
你糊弄，它能让你更快地产出一堆看起来能跑的东西。
所以 AI 时代更需要自我约束。
不是因为 AI 不好用，而是因为它太好用了，容易让人误以为“有结果”就等于“有质量”。
真效率来自流程，而不是一次生成
如果想避免假效率，关键不是少用 AI，而是改变使用方式。
不要把 AI 当成“一次生成完整答案”的工具。
更好的方式，是把它放进一个可验证的工程流程里。
比如做一个复杂功能，可以这样用：
第一步，让 AI 帮你拆需求。
列出对象、状态、权限、接口、异常场景。
第二步，让 AI 帮你设计类型和数据结构。
先不写 UI，先把业务模型说清楚。
第三步，让 AI 帮你生成局部代码。
一次只做一个小任务，比如表格区域、表单校验、请求封装。
第四步，让 AI 做 review。
从类型安全、组件边界、异常状态、性能风险几个维度检查。
第五步，让 AI 帮你补测试清单和文档。
把需要人工验证的地方列出来。
这个流程看起来比“直接生成完整页面”慢。
但它更稳。
因为每一步都可以检查，每一步都能纠偏。
真正的效率，不是让 AI 一口气生成最多内容，而是让它在正确的位置参与，减少返工和误判。
前端工程师要建立自己的质量闸门
AI 生成的东西，不能直接等于可交付代码。
你需要自己的质量闸门。
比如：
TypeScript 是否通过？
有没有不必要的
any？组件责任是否清楚？
状态是否存在非法组合？
请求是否处理 loading、error、竞态和取消？
是否符合项目已有风格？
是否引入了不必要依赖？
是否有测试或至少有测试清单？
这些检查不是形式主义。
它们是在防止 AI 的“快”，变成项目后期的“慢”。
尤其是前端项目，复杂度经常不是一开始爆炸的，而是在很多个小地方慢慢堆起来的。
一个组件多塞一点逻辑。
一个状态多加一个布尔值。
一个接口错误少处理一次。
一个业务规则临时写死。
这些东西短期都能跑，长期都会变成维护成本。
AI 可以帮你写代码，但质量闸门要你自己守。
产品和业务理解，是识别假效率的关键
很多假效率，不是技术层面马上能看出来的。
代码能跑，类型也过了，但业务不对。
比如一个“导出”功能。
AI 可能很快写出按钮、请求、下载文件。
但业务上可能还需要考虑：
导出范围是否受筛选条件影响？
大数据量是否异步导出？
是否有权限控制？
是否包含敏感字段？
失败后是否能重试？
导出记录是否要留痕？
如果你不理解业务，只看代码是否实现了下载，就会以为功能完成了。
这就是前端判断力的重要性。
前端不是只把页面写出来，而是要理解页面背后的业务动作。
AI 能帮你生成实现，但它不知道哪些规则对你的业务重要。
这部分必须由人来判断。
这也是“产品和业务理解提高判断力”的现实意义。
它不是一句漂亮话，而是用来识别哪些效率是真的，哪些效率只是表面快。
可以用三个问题检查 AI 是否真的提高了效率
每次用 AI 完成一个任务后，可以问自己三个问题。
第一，它减少的是重复劳动，还是跳过了必要思考？
如果只是帮你生成样板代码、补测试、整理文档，这是好的效率。
如果它让你跳过需求澄清、类型设计、边界判断，就要小心。
第二，它的产出是否容易验证？
如果 AI 生成的内容可以通过类型、测试、review、运行结果验证，就比较稳。
如果只是一个看起来合理的解释或方案，但没有验证路径，就不能轻信。
第三，它有没有降低后续维护成本？
真正的效率应该让项目更清楚，而不是更模糊。
如果 AI 生成的代码让组件更大、状态更乱、规则更分散，那它只是提高了当前速度，增加了未来成本。
这三个问题很简单，但能过滤掉很多假效率。
最后
AI 工具当然值得用。
不用 AI，不代表更专业。
但盲目相信 AI 生成的速度，也不代表真的高效。
前端工程师在 AI 时代要练的，不只是“如何让 AI 更快给答案”。
更重要的是：
如何让 AI 参与正确的问题。
如何让 AI 的产出可验证。
如何判断它是不是把问题藏到了后面。
如何用类型、测试、工程规范和业务理解来校准它。
「前端之外」的长期主线是：
前端专业能力打底，AI 协作能力放大效率，再用产品和业务理解提高判断力。
这里的“放大效率”，不是单纯生成更多代码。
而是更快地理解问题，更稳地推进方案，更少地制造返工。
AI 工具用得越多，越要警惕假效率。
真正的效率，不是今天少写了几行代码。
而是一个月后，你和团队依然能清楚地理解、修改和维护它。
