面向 AI 的重构：当你的代码审查员是机器时
I’m happy to translate the article for you, but I’ll need the full text of the post (the part you’d like translated). Could you please paste the article’s content here? Once I have the text, I’ll provide a Simplified‑Chinese translation while preserving the original formatting, markdown, and any code blocks or URLs.
Source:
为什么你应该在意
如果你在使用 AI 助手（ChatGPT、Claude、Copilot）编写代码，你可能已经注意到一件奇怪的事：“好代码”的规则正在改变。
传统的重构建议假设人类会阅读你的代码。但如果 AI 阅读代码的频率比人类更高呢？如果 AI 被你那“完美可读”的代码弄糊涂了呢？
这件事正在发生，我们必须谈谈它。
新问题：理解债务
我们都了解 技术债务——以后必须修复的代码。但 AI 原生开发产生了另一种问题：理解债务。
| 技术债务 | 理解债务 |
|---|---|
| “以后改动会很困难” | “没人知道它现在为什么能工作” |
| 未来维护成本 | 立即的理解成本 |
| 可以逐步偿还 | 现在就阻碍你 |
什么导致了它？
当 AI 生成代码时：
- 你不理解它——它能跑，就直接上线。
- 没有一致性——每次的模式都不一样。
- 过于复杂——AI 加入了你没有要求的边缘情况。
编写 代码的成本下降了，而 理解 代码的成本上升了。
但是……我们真的需要理解它吗？
现在，我其实已经很少阅读代码了。当我需要了解某件事时，我会：
- 问 AI：“这个函数是干什么的？”
- 问 AI：“它为什么会这样设计？”
- 问 AI：“如果我改动 X，会发生什么？”
如果 AI 能比人类更好地解释代码，那么“人类可读性”仍然是目标吗？
情节反转：有时是，有时不是。让我展示 AI 失效的地方。
当 AI 卡住时：调试的死亡循环
你可能经历过这样的情形：
You: "This function has a bug, can you fix it?"
AI: *adds console.log()*
AI: *adds another console.log()*
AI: *adds error handling that doesn't help*
AI: *adds more logs in random places*
AI: *suggests rewriting the whole thing"
You: 😤AI 在调试方面表现不佳，因为：
- 没有记忆——忘记自己已经尝试过的内容。
- 没有假设——只是把解决方案随意抛出。
- 没有退出点——一直尝试下去。
教训：AI 能很好地生成和解释代码，但它不擅长调查问题。
新的重构目标：让 AI 不迷路
传统重构是为 人类大脑 优化的：
- 短变量名 → 清晰命名
- 长函数 → 小函数
- 复杂逻辑 → 简单逻辑
新的重构是为 AI 准确性 优化的：
- 小作用域——AI 在大文件里会失去跟踪。
- 明确依赖——AI 处理不了隐式耦合。
- 更少状态——AI 追踪不到全局变更。
- 更多测试——AI 需要验证检查点。
有趣的事实是：这两者有很大重叠！“对人类友好的好代码”和“对 AI 友好的好代码”目前还不太一样……但差距正在缩小。
人类与 AI 的分歧
函数规模
人类偏好：
// I want to see the whole story in one place
function processUser(user) {
// validate
// transform
// save
// notify
// all in one flow
}AI 偏好：
// I can jump between functions instantly
function processUser(user) {
const validated = validate(user);
const transformed = transform(validated);
const saved = save(transformed);
notify(saved);
}对于人类来说，在文件之间跳转会打断思维流程。
对于 AI 来说，这毫无代价。
实用答案
现在？为 AI 优化。
为什么？
- 人类可以让 AI 解释流程。
- AI 不能让人类重新组织以便更好解析。
- AI 的局限性更具约束性。
Source: …
实用技巧：停止调试循环
-
缩小范围
❌ "Fix the bug in this file" ✅ "Check if validateEmail() correctly handles subdomains" -
你提出假设，AI 进行验证
❌ "Why is this broken?" ✅ "I think the issue is timezone handling. Check lines 45‑60" -
三次机会规则 – 如果 AI 连续三次使用相同方法，停止并重新思考：
- 重置对话。
- 换一个 AI 试试。
- 自己动手调试。
-
为 AI 实验使用独立分支
# Don't let AI pollute your main branch git checkout -b ai-debug-session # Let it try stuff # If it works, cherry‑pick the good parts # If not, delete the branch -
始终为功能生成测试
❌ "Build a login system" ✅ "Build a login system with unit tests"
何时重构
需要重构的红旗：
- AI 在相同代码上出现 3 次以上的混淆。
- 你无法解释函数的作用。
- 添加一个功能需要修改 5 个以上文件。
- 测试不稳定或缺失。
可以进行重构的绿灯：
- 两个冲刺之间。
- 在添加重大功能之前。
- 当你有专门的时间（不是星期五下午）。
快速收获：
- 拆分大函数（> 50 行）。
- 移除全局状态。
- 为未测试的代码添加测试。
- 将魔法数字提取为常量。
每天做一个。不要一次性尝试重构所有内容。
未解之问
说实话？我并没有所有答案。
- AI 的偏好会随着新模型而改变吗？
- 我们真的应该降低对人类可读性的重视吗？
- 如果 AI 学会更好地处理复杂性怎么办？
我确实知道的是：
- “这段代码是给谁的？”这个问题现在变得真实了。
- AI 的调试局限是当前的瓶颈。
- 针对“AI 不会迷失”进行优化是一个有用的启发式方法。
今日尝试
挑选一个让 AI 遇到困难的函数，然后：
- 将其拆分为更小的部分（每个只承担一个职责）。
- 添加测试。
- 让 AI 在该区域调试某些东西。
- 观察它是否表现得更好。
然后在评论里告诉我——它有效吗？
讨论
你的经验是什么？
- 使用 AI 时，你会以不同的方式重构吗？
- 你发现了哪些其他模式会帮助/阻碍 AI 的理解吗？
- 我是不是想得太多了？ 😅
在下面留下你的想法。我仍在摸索中，想了解哪些方法对你有效（或无效）。
我在博客上写了更多关于此类思考过程和工程决策的内容。
如果你感兴趣的话：