如何让 AI 整合代码——无需微观管理

Source: Dev.to

（请提供您希望翻译的具体文本内容，我将按照您的要求将其翻译为简体中文，并保留原始的格式、Markdown 语法以及技术术语。）

问题

当你说“重构这个”时，AI 默认会进行职责分离。

"Refactor this namespace"
    ↓
AI splits by responsibility
    ↓
More files, clearer boundaries
    ↓
Context size increases
    ↓
Worse than before

我亲身经历了这种情况。一个命名空间变得太大，于是我让 AI 对其进行重构。结果是出现了更多的文件、更多的间接引用，且上下文窗口更大。

为了强制 DRY 合并，我不得不进行微观管理：

• 指定确切的文件
• 指向具体的行号
• 解释哪些模式是“相同的”

这根本无法扩展。

第一次尝试：策略声明

我的第一个想法是提前声明一个重构策略：

Refactoring Policy:
- Priority: DRY (consolidate duplicates)
- Prefer integration into existing files
- Minimize responsibility separation
- Do not increase file count

AI 理解了该策略，然后问道：

“您想要合并哪些文件以及哪些重复内容？”

又回到了微观管理。该策略告诉 AI 如何 重构——但没有告诉它 寻找什么。

缺失的环节：阶段

突破在于意识到这一点：

AI 需要明确的授权——以及一个工作流——才能自行 发现 重构目标。

• 策略 定义方向。
• 阶段 定义代理。

干‑先重构协议

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━─
DRY-First Refactoring Protocol
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━─

【Phase 1】Discovery
List the following:
- Files with similar processing
- Duplicate code patterns
- Consolidation candidates

【Phase 2】Proposal
For each discovered duplicate:
- Where to consolidate
- How to integrate
(Do not implement yet)

【Phase 3】Implementation
After "approved", implement.

【Priority】
1. DRY (consolidate duplicates)
2. Integration into existing files
3. Responsibility separation (minimum necessary)

结果

第1阶段：发现

相似的处理：

• SelectBuilder.cs、ProjectionBuilder.cs、HavingBuilder.cs – 共通点：SQL 运算符映射、常量字符串化
• JoinBuilder.cs、GroupByBuilder.cs、HavingBuilder.cs – 共通点：Lambda / MemberExpression 提取

合并候选项：

• GetSqlOperator 和 VisitConstant → 合并统一
• Lambda 提取 → 合并到 BuilderUtil

第2阶段：提案

合并运算符和常量处理
目标：BuilderUtil.cs

• 添加 GetSqlOperator(ExpressionType)
• 添加 FormatConstant(ConstantExpression)
• 在 Select/Projection/Having 构建器中替换实现

合并 Lambda/成员提取
目标：BuilderUtil.cs

• 添加 ExtractLambda(Expression)
• 添加 UnwrapLambdaBody(Expression)
• 在各构建器中替换自定义实现

回复 “approved” 以继续第3阶段。

我回复：approved。AI 已实现合并——无需微观管理。

第3阶段：实现

（如上所述已实现。）

测量影响

目标并不是大幅度削减，而是在不扩张的前提下进行整合。这一目标已实现。

为什么这样有效

关键洞察： AI 可以发现重复模式——前提是你明确要求它。没有发现阶段，AI 会等待；有了发现阶段，AI 会行动。

前后对比

之前（无协议）：

"Refactor this"
→ AI separates by responsibility
→ File count increases
→ Human intervenes with specific instructions
→ Micromanagement

之后（有协议）：

"Refactor this" + protocol
→ AI lists duplicates
→ AI proposes consolidation
→ Human approves
→ AI implements
→ No micromanagement

何时使用此协议

使用场景：

• 命名空间或模块变得过大
• 你感觉到重复但不想列举出来
• 之前的重构增加了复杂性
• 上下文大小成为瓶颈

不适用场景：

• 实际目标是职责分离
• 代码库足够小，可直接指令
• 你已经明确知道要合并的内容

更深的教训

AI 的默认行为并不是错误——职责分离是一种有效的重构策略。问题在于 隐式默认。当你没有指定方向时，AI 会自行选择。

此协议使意图明确：

• 要 查找的内容（重复）
• 何时 停止（在实现之前提出方案）
• 如何 排序优先级（DRY 优先于分离）

这不是在控制 AI，而是让 AI 的主动性与您的目标保持一致。

摘要

三阶段。一批准。无微观管理。

本文是“超越提示工程”系列的一部分，探讨结构化——而非临时——的 AI 辅助开发方法。