随时重构
Source: Dev.to
请提供您希望翻译的具体文本内容，我会将其翻译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！
传统恐惧
在传统开发中，重构被视为风险：
- “我们正处于功能开发中——不要动基础。”
- “先把这个完成，然后再清理。”
- “现在重构会导致一切不稳定。”
当重构成本高且容易出错时，这些担忧是有道理的。
有了 AI，重构成本大幅下降。问题从 “我们能负担得起重构吗？” 转变为 “我们的情境是否支持重构？”
基于上下文的再生成
AI 并不 修改 代码；它 从提供的上下文 中重新生成 代码。
当可以进行重构时，这一点会改变：
| Condition | Refactoring Possible? |
|---|---|
| 上下文清晰完整 | ✅ 是 |
| 上下文碎片化或陈旧 | ❌ 否 – 首先修复上下文 |
| 功能进行中，但上下文保持完整 | ✅ 是 |
| 长时间中断且没有日志 | ❌ 否 – 首先重建上下文 |
重构的可用性取决于上下文状态，而非项目阶段。
如果您已经维护了日志、保持了制品的一致性，并保留了决策历史——您可以在任何时候进行重构，即使在功能进行中。
AI 重构的产出
当你让 AI 在没有约束的情况下进行重构时，它会优化职责分离。
| 人类期望 | AI 输出 |
|---|---|
| 合并重复代码 | 按职责分离 |
| 减少文件数量 | 增加文件数量 |
| DRY（不要重复自己） | 在关注点之间建立清晰的边界 |
AI 重构往往会增加代码量。
这并不是错误——只是不同的优化目标。AI 更倾向于在职责清晰度上进行优化，而不是追求简洁。
DRY问题
当你明确请求进行 DRY 重构时，会出现一个新问题：作用域限制。
AI 只能看到其上下文窗口内的内容。当代码库超出该窗口时：
- AI 只能看到部分重复代码。
- AI 在可见范围内提出合并方案。
- 合并可能与范围外的代码冲突。
- 结果：引用破损，抽象不完整。
规模依赖指令
| 代码库规模 | 方法 |
|---|---|
| 小（可放入上下文） | “Refactor for DRY” 有效 |
| 中 | 指定要考虑的文件 |
| 大 | 将其拆分为明确的范围边界，逐步重构 |
对于大型代码库，您必须 显式管理范围：
Refactor these 3 files for shared utilities:
- /src/handlers/userHandler.ts
- /src/handlers/orderHandler.ts
- /src/handlers/productHandler.ts
Do not modify files outside this set.重构的真正目的
使用 AI 进行重构并非关于美学或最佳实践。
这关乎让代码保持 AI 可控。
随着代码规模的增长，AI 越来越难以：
- 在上下文中保持完整的全局视图
- 理解组件之间的关系
- 在不产生意外影响的情况下进行修改
重构将代码重新组织为 AI 能够管理的单元：
| 重构前 | 重构后 |
|---|---|
| 关注点混杂的大文件 | 关注点明确的小文件 |
| 隐式依赖 | 显式接口 |
| 责任交叉混乱 | 责任分离 |
| 需要完整上下文才能理解 | 每个单元可单独理解 |
当 AI 难以控制代码时进行重构。困难本身就是信号。
何时重构
传统时机：
- 功能完成后
- 在专门的“重构冲刺”期间
- 当技术债务变得难以承受时
AI 时代时机：
- 当上下文能够支持时（日志已维护，制品已对齐）
- 当代码超出 AI 可舒适控制的范围时
- 当你注意到 AI 因结构复杂性而出错时
- 只要满足上述任意条件即可
不要等到“重构阶段”。如果上下文干净且代码变得难以管理，就立即重构。
重构循环
1. Notice AI struggling (repeated errors, confusion, partial understanding)
2. Check context state (are logs current? are artifacts aligned?)
3. If context is ready → refactor
4. If context is stale → rebuild context first
5. After refactor → update logs with the new structure重构成为持续流程的一部分，而不是独立的活动。
重构揭示上下文问题
当你在带有人为意图的情况下进行重构时，要做好意外的准备。
结果往往不会完全符合你的预期——会有一些偏差：出现你未预料的结构、感觉奇怪的分离、以及出现在意想不到位置的边界。
这些意外并非 AI 的失误，而是上下文问题浮现。
这种不匹配揭示了：
- 你默认但从未说明的前提
- 只存在于你脑中的优先级顺序
- 未被清晰传达的目标
机会
不要修复代码。修复上下文。
当重构产生意外结果时：
- 识别差距 – AI 生成的内容与您预期的有什么不同？
- 追溯到上下文 – 缺失的是哪项前提、优先级或目标？
- 重建上下文：
- 明确重新陈述前提（并指明顺序）
- 澄清优先级的排列顺序
- 定义目的及其相对重要性
随后使用已纠正的上下文再次进行重构。
Context Reconstruction Checklist
| Element | Question |
|---|---|
| Premises | 我们基于哪些假设？顺序如何？ |
| Priorities | 什么最重要？什么可以牺牲？ |
| Purpose | 这段代码想要实现什么目标？ |
| Constraints | 有哪些限制条件？ |
重构是上下文调试。意外的输出即为错误信息。
责任分离 vs. DRY
接受此权衡：
| 目标 | 结果 | AI 兼容性 |
|---|---|---|
| 责任分离 | 文件更多，边界更清晰 | 高 – AI 处理良好 |
| DRY 合并 | 文件更少，共享抽象 | 中 – 需要范围管理 |
如果你想要 DRY，你必须投入范围管理。如果让 AI 主导，你会得到分离。两者都没有错——只要了解你选择了哪一种。
摘要
| 传统 | AI 时代 |
|---|---|
| 在功能完成后或专门的冲刺期间进行重构。 | 在上下文干净且 AI 对代码结构感到困难时进行重构。 |
| 决策受限于人力资源和风险规避。 | 决策取决于上下文质量以及 AI 保持控制的能力。 |
| DRY（不要重复自己）通常是主要目标。 | 职责分离通常是主要目标；DRY 需要明确的作用域处理。 |
| 重构是一个单独的、计划好的活动。 | 重构是一个持续的、由上下文驱动的循环。 |
保持上下文整洁，AI 将保持代码整洁。
# Refactor When Context Supports It风险
- 不稳定风险 – 仅在上下文陈旧时出现。
原则
- 优化 DRY – 保持代码可复用且易维护。
- 优化 AI 可控性 – 确保 AI 能可靠地管理代码库。
活动类型
- Scheduled activity – 计划的重构会议。
- Continuous capability – 随着代码演进的持续改进。
Refactoring is no longer a phase.
它是当代码超出 AI 控制时你可以使用的工具——这可能随时发生。
这是 “Beyond Prompt Engineering” 系列的一部分，探讨结构性和文化性方法如何在 AI 辅助开发中胜过提示优化。