Change Budget Prompt：阻止 AI 辅助编码中的范围蔓延

Source: Dev.to

请提供您希望翻译的正文内容，我将按照要求保留源链接、格式和技术术语进行简体中文翻译。

思路

在请求解决方案之前，先用模型能够遵守的方式定义预算：

• 最大触及文件数（例如 2）
• 最大更改行数（例如 30）
• 不添加新依赖
• 不重命名 / 不新增模块
• 保持公共 API 稳定

预算迫使助理寻找最小可行的补丁，而不是“最干净”的架构。可以把它看作 AI 辅助编码的 WIP 限制：部件越少，隐藏的故障就越少。

Source:

复制/粘贴模板

以下是一个您可以随手保存的模板：

Task: 

Change budget:
- Touch at most  files
- Change at most  lines (excluding formatting)
- No renames
- No new dependencies
- Keep function signatures stable unless explicitly required

Output format:
1) Brief plan (2‑4 bullets)
2) Patch (diff)
3) Why this stays within budget
4) What to test (commands + key cases)

两点很重要

1. 明确不计入的内容（例如“不计入格式化”），这样就不会在无关的代码美化上浪费预算。
2. 强制生成 diff。Diff 能让“预算违规”一目了然。

示例 1：在不重构的情况下修复 bug

假设你有一个 Node/Express 处理函数，当数据库返回 null 时偶尔会返回 500。

糟糕的提示

Fix this handler.

更好的提示（带预算）

Task: Prevent 500s when user is missing. Return 404 instead.

Change budget:
- Touch at most 1 file
- Change at most 12 lines
- No new dependencies
- No renames

Output: diff + tests

Code:

预算会引导模型朝以下方向：

• 使用 guard 子句（if (!user) return res.status(404)…）
• 编写最小的测试用例

而不是：

• “让我们引入一个 UserService 类”
• 重构中间件
• 重写整个文件

示例 2：安全地添加功能标志

功能标志是另一种范围蔓延的诱因：助理可能想要集中配置、添加库或构建完整的标志系统。如果你只需要一个小的开关，请对其加以限制：

Task: Add an env flag NEW_CHECKOUT=1. If enabled, route /checkout to NewCheckoutPage.

Change budget:
- Touch at most 2 files
- Change at most 25 lines
- No new packages
- Do not change existing routes

Output: diff + rollback note

可能的结果是一条单一的条件分支加上一段简短的说明：

• 如何启用/禁用
• 当变量缺失时会发生什么

这正是你想要的。

示例 3：“改进性能”而不重写所有内容

性能提示很危险，因为它们会导致大范围的重写。不要写：

Make this faster.

尝试：

Task: Reduce allocations in parseCsvRow().

Change budget:
- Touch at most 1 file
- Change at most 20 lines
- Keep behavior identical (including edge cases)

Also provide:
- A micro‑benchmark snippet
- A note on complexity tradeoffs

你在告诉助手：在局部进行优化，使用基准测试进行验证，不要重新设计整个系统。

为什么它有效（机械层面）

大多数助手通过生成合理的后续步骤来“搜索”解空间。在没有约束的情况下，它们会倾向于全局“优雅”的代码：

• 对称性
• “干净的架构”
• 新抽象

预算会改变目标函数。模型开始优化最小编辑和低风险差异，这往往与以下方面相关：

• 更少的回归
• 更容易审查
• 更容易回滚

在实践中，你还能获得更好的人机工程学：小的差异易于快速浏览。

让它更紧凑：两遍工作流

当任务棘手时，使用两遍：

1. 计划遍（预算内）：要求提供 3 条要点的计划和假设列表。
2. 修补遍（预算内）：要求提供 diff。

这样可以在早期捕捉误解，而不会在会被丢弃的代码上浪费时间。

计划提示

Before coding: propose a plan that stays within the change budget.
List assumptions and unknowns.
If the budget is unrealistic, say so and propose the smallest budget increase.

这种“预算协商”很重要：有时 12 行根本不够，你宁愿提前知道。

常见失败模式（及修复方法）

1. 助手会重新格式化所有内容。
   添加：“除非必要，否则不要更改格式或重命名变量。”

2. 它仍然会超出预算。
   添加：“如果无法在预算内完成，请停止并请求扩展预算的许可。”

3. 它会产生不可见的行为更改。
   添加：“行为必须保持一致；请包含一个小的测试矩阵。”

4. 它通过删除代码路径来‘修复’。
   添加：“不要删除功能；保留现有分支。”

为你的下一个提示快速检查清单

• 最小可接受的结果是什么？
• 什么必须保持不变？
• 你今天愿意审查的最大差异是多少？
• 你希望得到什么（差异、测试、命令）？

如果你回答这些，你将获得以最佳方式“无聊”的补丁。

The Change Budget Prompt 并不是在限制助手的创造力，而是让输出与工程现实保持一致：小而可审查的更改即可发布。