最近帮同事 Review 了两个需求，都打回重做了。

用的还是最顶尖的模型，但问题不在 AI，在人。

第一个需求是调整一个配置项的字段——原来的字段名叫 buttonType，对应 UI 上展示的是「按钮类型」。

对于开发来说，这很好理解，无外乎 primary、secondary、dashed、text、default 这些值。

但产品对「按钮类型」的理解完全不同——他们想的是跳转链接、打开弹窗、toast 提示这类行为。

所以需求是：把 buttonType 对应的 UI 改成「按钮 UI 类型」，同时新增一个字段让产品配置按钮点击后的行为。

需求本身不复杂，麻烦的地方在于 buttonType 会落库，字段一旦改名，历史数据就需要兼容处理。

AI 给出的方案是：把 buttonType 改为 buttonUIType，新增 buttonClickType 存储点击行为，同时在前端做兼容——读取数据时，如果存在 buttonType，就映射到 buttonUIType 上。

贴心、严谨、能跑通。

但其实有一个更简单的答案——只改 UI 上的文案，字段名一个字母都不用动。

产品看到的标签从「按钮类型」变成「按钮 UI 类型」，需求满足了，历史数据无需兼容，兼容代码一行不用写。

AI 的那段兼容逻辑确实能跑，但当线上所有老数据都退出历史舞台之后，它就成了一段永远不会被执行的僵尸代码。除了徒增维护成本，还会引导 AI 在后续类似场景里照葫芦画瓢，最终积成屎山。

第二个需求麻烦一些，涉及全局埋点字段的处理：每次按钮点击，都要上报一份全局数据。

核心问题就一个：这份全局数据怎么带。

AI 在同事的指挥下给出了方案：在根组件获取全局数据，然后一层一层往下传，点击时作为参数上报。

任务是完成了，但方案是”把全局数据一层一层手动透传”——典型的用最笨的办法解决问题。

熟悉 React 的都知道，跨组件共享数据走 Context 就好了。更进一步，这类公共参数直接封装进埋点方法里，调用方根本不需要关心它的存在。

AI 没有主动建议 Context，是因为同事没有给它足够的背景——AI 只看到了「如何传参数」这个局部问题，不知道这是一个跨多层组件的全局数据场景。

返工的时候，同事也没有自己动手，而是把改进方向告诉了 AI，重新生成，顺利通过了 Code Review。

两个案例，AI 都完美执行了交代的任务。但受限于使用者自身的技术判断，最终交出的代码是不及格的。

后来我们总结了一个使用习惯：

拿到需求，先自己想清楚思路，再让 AI 执行；如果思路不清晰，先让 AI 出方案（比如 Plan 模式），对齐之后再动手。

这样既快，又不会堆屎山。

AI 是放大器——放大的是使用者的判断力，而不是替代它。锅最终还是自己的。