在一场前端面试中，面试官给出一个写于 2017 年的 React Class 组件：17 个 props、5 个布尔 state，生命周期里还挂着 4 个异步请求。要求很直接：25 分钟内用 AI 重构。但他强调，自己不看最终代码，只看候选人会不会拆。
候选人最初的反应是让 Cursor 将 Class 组件改成函数式组件，并优化性能。AI 很快生成了一份包含 useEffect、useState 和箭头函数的新代码，语法现代、结构整齐。但面试官只问了一句：原来的 bug 在哪？这个问题暴露出 AI 辅助重构的关键风险：如果只是让 AI 翻译语法，旧代码里的结构问题、隐藏假设和副作用依赖，可能会被更漂亮的写法重新包裹起来。
先画依赖图，再决定从哪里下刀
旧组件真正难处理的地方，往往不是行数多，而是关系被长期迭代后藏得很深。一个 props 可能从父组件传入，在 componentDidMount 里转成 state，在 shouldComponentUpdate 中影响更新，最后又在某个回调里反向写回。改一行代码，可能牵动多个位置。
素材中的方法论给出的第一条规则是：改第一行代码之前，先画三张图。面试现场可以用白板，日常项目可以用 Miro 或 Markdown。画图的目的不是补充文档，而是先识别组件内部的数据流向、副作用触发点，以及状态之间的代理关系。
在这个案例里，画图后发现真正的问题并不是 Class 写法本身，而是 props 与 state 互相代理：A 来自 props，B 从 A 派生，C 又在回调里写回 A。如果直接让 AI 重写，这类关系可能不会消失，反而会藏进新的 hooks 和状态逻辑里，使问题更难定位。
识别隐藏假设，把“默认成立”变成显式条件
老代码中常见的一类风险，是代码本身看似没有错误，但它依赖的前提已经在多年迭代中失效。素材举出的例子是 componentDidMount 中根据 userId 请求用户信息：写这段代码时，userId 可能是稳定、非空的数字；但多年之后，上游可能传入字符串、空对象，甚至 undefined。
因此，第二步不是让 AI 立即重写，而是让它先列出所有默认成立但没有写下来的条件。素材中，Cursor 列出了 11 条隐藏假设。这类假设如果不在重构前转成断言、类型约束或显式分支，就相当于把原来的风险从旧代码搬进新代码，而且更难察觉。
这也是面试官明确反对“一键全量重写”的原因：生产环境中，很少有人能一次性验证数百行新代码。重构需要可检查、可回滚，而不是追求一次生成完整结果。
按副作用边界拆分，而不是按视觉边界拆分
拆分旧组件时，常见误区是按界面结构切成 Header、Form、Footer。但素材指出，视觉上的拆分未必能解除耦合：几个模块可能仍在共享同一个 state，拆完之后依旧互相影响。
更有效的方式是按副作用边界拆分，也就是先把数据请求、状态变更、清理逻辑从 UI 中剥离。素材给出的示例中，原始组件把请求、加载、错误、编辑和渲染都放在一个 Class 组件内部。重构第一步是抽出 useUser 这样的数据请求 hook，把请求状态封装为 status、user、error；UI 组件只负责消费状态并展示。
这一步并没有解决所有问题，但完成了两件关键事情：数据请求与界面渲染分离，后续可以分别验证；状态表达从多个布尔值变成更明确的状态流程。对于长期维护的组件来说，这种边界清晰化比单纯换成函数式写法更重要。
给 AI 可验证指令，而不是模糊愿望
在提示词写法上，素材对比了两种指令。第一种是“帮我把这个 Class 组件改成函数组件，优化性能”。这类提示听起来合理，但缺少验收标准，AI 输出的结果即使表面正确，开发者也难以判断它是否保留了原有行为。
第二种指令更具体：将 5 个控制请求、编辑和错误状态的 state 合并成一个 status 状态机，包含 idle、loading、success、error；同时要求保证原有渲染分支不丢失、组件卸载时不会 setState，并给出 3 个覆盖状态转换的单元测试用例。
后者的关键在于可验证。AI 生成内容是否合格，可以围绕明确条件检查，而不是依赖“看起来更现代”。
素材还整理出一份重构前检查清单，可作为 AI 辅助处理旧组件时的参考：
- 是否已画出组件依赖关系和数据流向
- 是否识别出 props、state、生命周期和回调之间的代理关系
- 是否列出未写明的隐藏假设
- 隐藏假设是否能转为类型、断言或显式分支
- 是否按副作用边界拆分，而不是只按视觉结构拆分
- 每次改动是否足够小，便于验证和回滚
- 提示词是否包含明确输入、输出和验收标准
- 是否要求 AI 给出测试用例或状态转换说明
这套方法的核心不是让 AI 变得更聪明，而是防止开发者被 AI 的流畅输出误导。面试中那句“我不看代码，只看你会不会拆”，落到工程实践里，就是要求开发者能够给出清晰边界、明确假设和可验收标准。
素材最后提到，候选人最终拿到了 offer，并将这套四步法带进真实项目。后来他处理一个 2019 年的表单组件时，没有进行一次性大提交，而是通过小步验证完成重构，回滚成本接近零。对于 AI 编程来说，这个案例的意义并不在于 AI 能写多快，而在于开发者是否知道旧代码的问题在哪里、风险在哪里、边界在哪里。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-chong-gou-jiu-zu-jian-bu-neng-cong-bang-wo-chong-xie-kai
