约束明确的提示词

是什么，为什么存在

约束明确的提示词是一份有边界的改动请求。它说明什么必须成立、哪里可以修改、哪些看似合理的结果被明确排除、哪些现有行为必须保留，以及哪些证据决定任务完成。它仍然使用自然语言，但关键选择足够明确，可以逐项审查。

只描述所需功能，相当于在很大的解空间里只指定一个点。「增加优惠券上限」可能让智能体修改验证逻辑、替换依赖、重命名公开函数、迁移存储数据、格式化相邻文件，甚至放宽阻碍其实现的测试。即使原意只允许改两个文件，每一步在局部看来都可能合理。

问题并不是智能体缺乏主动性。代码库里常有多种看似可行的模式、不完整的文档和彼此冲突的局部示例。约束没有写明时，模型只能从这些证据推断产品与维护决策，流畅的输出也就可能掩盖请求者从未授权的选择。

四类字段承担了大部分边界定义工作：

范围首先是修改边界，而不是阅读边界。智能体可能需要检查允许修改范围之外的调用方、配置、测试或指令，才能理解改动。好的提示词会区分「可以检查」与「可以修改」，既让调查有效，又不会悄悄扩大补丁。

非目标是主动排除项，不是填充文字。它记录一项很有吸引力的相邻改动，避免这项改动被误当成当前任务。「不要替换验证库」在仓库同时存在旧辅助函数和新库时很有用；「不要做任何不必要的改动」只是把同一个判断再次交给智能体。

兼容性限制指出 API 契约（API contract） 中受保护的部分。它可以保护位置调用和关键字调用、JSON 字段、异常类、事件顺序或最低运行时版本。在提示词明确使用者及其观察结果之前，「不要引入破坏性变更」并没有说清禁止哪一种 破坏性变更（breaking change） 。

验收命令让完成条件可以复现。命令应来自仓库脚本或经过本地验证，并写明必要的工作目录以及成功标准。命令退出码是证据；智能体所说的「测试应该能通过」不是证据。

约束明确不等于篇幅很长。小型私有改动可能只需一个允许文件、一项受保护行为和一条测试命令。跨软件包改动、持久化数据、公开 API、身份验证、支付或迁移需要更明确的边界，因为一个看似合理的错误假设代价更高。

当智能体可以自主编辑、运行工具并连续执行多个步骤时，这类提示词尤其有用。行动循环越长，范围漂移的机会越多，早期假设也越容易影响后续改动。提示词为每一步提供稳定的参照点。

提示词不是授权系统。写下「不要读取秘密」不能撤销文件系统访问权限，写下「只能编辑 src/checkout/」也不能强制实现沙箱。安全边界应由权限、隔离、审查关卡和确定性验证落实；提示词约束用于传达预期工作。

工作原理

先从仓库证据出发，而不是凭记忆起草约束。找出活跃符号、调用方、失败行为、本地指令、软件包脚本、运行时目标和当前差异。这样才能把「保持兼容性」之类的通用偏好，转成与真实使用者有关的要求。

可以按以下顺序起草：

1. 写明一个可观察结果，以及需要该结果的用户或调用方。
2. 指定有充分依据的最小修改面，并说明哪些生成文件不能直接编辑。
3. 排除当前仓库中合理但本次不需要的相邻工作。
4. 分开列出受保护的兼容性维度与有意改变的行为。
5. 给出确切验收命令，以及有判别力的正向和负向案例。
6. 定义智能体必须停止并报告的条件，避免它自行猜测或扩大范围。

这个顺序很重要，因为后面的约束会限定目标。「显式页大小为零时返回零」是行为要求。「保留现有单参数导出」保护兼容性，而「不要修改调用方」收窄实现范围。这些条款不能安全地相互替代。

限定修改面

文件范围是最容易在差异中检查的边界。手术式改动可以指定确切文件；允许新增测试或生成快照时，可以指定目录与文件类型。如果任务最多允许修改三个文件，就应写明这项改动预算，让第四个文件触发讨论，而不是悄悄扩张。

只列路径可能过于僵硬。提示词允许 src/checkout/discount.mjs 却遗漏配套测试文件，就无法提供证明。更合适的做法是给出一组很小的必需文件，再补充条件规则，例如「可以在 test/checkout/ 下增加一个测试夹具；修改清单、锁文件、模式或公开类型前必须先报告」。

还要说明语义边界。「定价策略留在 discount.mjs 中；不要把网络调用移入该文件」保护了一条仅靠路径列表无法表达的 架构边界（architecture boundary） 。改动即使都落在允许目录中，仍可能反转依赖方向，或者把策略与 I/O 混在一起。

阅读范围通常应该比修改范围更宽。可以要求智能体搜索所有调用点并检查软件包指令，同时把修改限定在具名范围内。如果调查证明修复还需要另一个所有者或迁移，停止条件就应要求它先提交证据，再讨论是否扩张。

写出有效的非目标

非目标应当与任务相邻、很有诱惑力，并且可以在最终差异中检查。常见例子包括升级软件包、修改数据库模式、重命名无关符号、引入框架、重新格式化未触碰的代码，或顺手修复附近的第二个缺陷。每一项都阻止一种真实的范围蔓延。

不要试图预言所有不想要的行为。上百条禁令难以协调，也容易被跳读。只选择仓库证据提示的少数排除项，然后增加一条通用停止规则，处理必须越过允许边界的改动。

负面措辞需要指出正面归属。「不要编辑生成文件」还应说明哪个源文件拥有它们，以及哪条生成命令可以更新它们。「不要改 API」还应给出确切导出符号和受保护的观察结果。否则智能体只知道不能往哪里走，却不知道合法改动应该落在哪里。

按维度规定兼容性

向后兼容性（backward compatibility） 总是相对于一组以前有效的交互而言。应当明确这组交互。对于 JavaScript 函数，它可能包括依赖参数个数的反射、参数省略时的默认行为、是否接受零、抛出的错误类、返回对象字段和异步时序。

不同兼容性维度可能指向不同要求：

把有意的不兼容与受保护行为分开。如果无效字符串以前会被强制转成数字，现在必须失败，就要明确写出这项变化。提示词不能既要求严格拒绝，又要求与依赖强制转换的调用方保持完全行为兼容。

存在未知使用者时，不可能提出普遍兼容保证。应要求搜索调用点、盘点公开表面或编写特征测试，再把承诺限定在实际找到的证据上。如果证据不完整，就要求智能体标出不确定性，而不是宣称「没有回归」。

让验收可执行

验收命令应该可以直接复制、从具名目录运行，并能因目标缺陷而失败。应写 node test/checkout/discount.test.mjs，而不是「运行相关测试」。只有当仓库的类型、检查、构建或格式化命令适用于当前改动面时，才把它们加入验收。

命令与行为标准互为补充。宽泛测试套件可能通过，却没有检查新的零值边界；聚焦测试也可能遗漏类型或打包故障。用文字写出有判别力的案例，再写明执行这些案例的命令。

还要为禁止的改动提供负向验收证据。git diff --check 可以发现空白错误，已修改文件检查可以发现范围漂移，清单差异可以发现意外依赖。这些检查无法证明语义正确，却能补上行为测试常见的缺口。

还要定义命令无法运行时的处理方式。智能体应报告确切命令、退出状态和阻碍；不能用「看起来正确」代替，也不能悄悄省略检查。如果基线已有无关失败，应要求证据把它与当前补丁造成的回归区分开。

先运行便宜且聚焦的检查，再运行昂贵且宽泛的检查。这样可以缩短反馈时间，又不会削弱最终关卡。提示词仍应明确：所有具名命令都通过才算完成，而不是任意一项早期检查通过即可。

编辑前解决冲突

所有约束组成同一个集合，因此矛盾必须一起处理。严格的双文件范围可能与重新生成锁文件的要求冲突。保留错误类也可能与采用另一个公开包装器错误不同的库冲突。只有所有细节都能同时成立时，更多细节才真正有帮助。

为智能体写出优先级与升级规则：先遵守仓库指令和安全边界；显式任务约束限定所需行为；两项要求无法同时满足时，提交最小冲突集合和一两个有证据支持的选项，然后停止。不要让智能体自行选择看起来更重要的条款。

要求在假设进入代码前把它们显式列出。简短的编辑前摘要可以列出计划修改的文件、受保护行为、预期命令和未决问题。对于直接的任务，这可以是一份紧凑清单，不必变成形式化计划。

可复用的提示词结构

以下字段只是起点，不是强制表单：

• 任务： 一个可观察行为变化、目标符号和受影响的调用方。
• 证据： 当前行为、失败示例、相关源码位置和仓库指令。
• 范围： 允许的文件或目录、文件预算、生成文件策略和允许的阅读范围。
• 非目标： 明确排除的相邻重构、迁移、依赖变化或产品行为。
• 兼容性： 受保护的签名、失败、数据形状、运行时版本和使用者。
• 验收： 确切命令、关键案例、差异检查和预期成功条件。
• 停止条件： 冲突、权限缺失、证据不可用，或必须在范围外写入。

各字段应使用仓库自己的语言。如果软件包把边界称为适配器，就沿用这个词并给出文件名。如果测试脚本是 pnpm test:checkout，就准确复制；凭空编造通用的 npm test 会削弱原本精确的请求。

示例

下面的示例把提示词条款转成能够拒绝诱人但未获授权补丁的检查。这些脚本只是仓库关卡的小型模型，并不意味着仅靠文字就能强制智能体遵守约束。所有输出都在本地使用 Node 24 实际生成。

拒绝扩大修改范围

假设任务是调整结账折扣。提示词允许修改两个具名根目录下的实现与测试文件，把补丁上限设为三个文件，并把软件包元数据标为受保护文件。它的非目标排除了文档清理和依赖变更。

聚焦方案满足路径规则。扩张方案也只有三个文件，但其中两个违反了更具体的边界。因此，文件数量预算不能替代允许列表或受保护文件规则。

提示词仍应允许调查这些根目录以外的内容。为了找到测试命令而读取 package.json，与修改它是两回事。如果实现确实需要一个依赖，正确结果是提交范围外发现，而不是暗中编辑清单。

保护兼容性边界

接下来要修改 parsePageSize，让无效值明确失败。提示词保留单参数调用，让 undefined 继续映射到 25，让显式 0 继续有效，把上限设为 100，并要求保留现有 RangeError 消息。这些条款可以阻止生成的 value || 25 捷径改变零值语义。

function parsePageSize(value) {
  if (value === undefined) return 25;
  if (!Number.isSafeInteger(value) || value < 0 || value > 100) {
    throw new RangeError("pageSize must be an integer from 0 to 100");
  }
  return value;
}

const cases = [
  ["missing", undefined],
  ["zero", 0],
  ["maximum", 100],
  ["too large", 101],
];

for (const [name, value] of cases) {
  try {
    console.log(`${name}: ${parsePageSize(value)}`);
  } catch (error) {
    console.log(`${name}: ${error.name}: ${error.message}`);
  }
}

missing: 25
zero: 0
maximum: 100
too large: RangeError: pageSize must be an integer from 0 to 100

这些案例区分了省略参数与显式假值，并在上限边界放置示例。它们也让错误通道和消息可观察。「保持旧行为」无法说明请求者究竟保护其中哪些交互。

验收条款可以指定 node compatibility_matrix.mjs 并要求退出状态为零，而打印的各行仍是有用的审查证据。如果真实仓库已有聚焦测试命令，提示词应调用那条命令，而不是另建一套平行的临时工具。

拒绝不完整的验收证据

最后一个示例建立完成关卡模型。提示词要求聚焦行为检查、针对修改面的代码检查，以及差异卫生检查。只有证据包含全部命令且退出码都为零时，智能体才能报告完成。

const requiredCommands = [
  "node test/checkout/discount.test.mjs",
  "pnpm eslint src/checkout test/checkout",
  "git diff --check",
];

function releaseDecision(results) {
  const evidence = new Map(results.map((result) => [result.command, result.exitCode]));
  let ready = true;

  for (const command of requiredCommands) {
    const exitCode = evidence.get(command);
    const state = exitCode === undefined ? "MISSING" : exitCode === 0 ? "PASS" : `FAIL exit=${exitCode}`;
    console.log(`${state}: ${command}`);
    if (exitCode !== 0) ready = false;
  }

  console.log(`decision: ${ready ? "READY" : "NOT READY"}`);
}

releaseDecision([
  { command: "node test/checkout/discount.test.mjs", exitCode: 0 },
  { command: "pnpm eslint src/checkout test/checkout", exitCode: 1 },
]);

PASS: node test/checkout/discount.test.mjs
FAIL exit=1: pnpm eslint src/checkout test/checkout
MISSING: git diff --check
decision: NOT READY

聚焦测试通过不能抵消代码检查失败，省略差异检查也不等于通过。有效的智能体响应应包含真实失败与缺失证据，然后修复范围内的原因；如果解决问题需要越界，就应停止。

确切命令字符串还可以防止替换证据。pnpm eslint src/checkout test/checkout 与编辑器显示的「没有可见警告」并不是等价检查。如果命令本身已经过期，修改验收契约需要显式决策，不能悄悄替换。

陷阱

添加无法同时满足的约束

修复方法： 编辑前先检查可满足性。把每项必需结果与它涉及的文件和命令配对。如果两个条款冲突，就提交最小冲突集合，并请所有者放宽或拆分其中一项要求。

把非目标写成模糊克制

修复方法： 写明两三个与仓库有关的诱惑项：不升级软件包、不迁移模式、不重命名 src/checkout/ 以外的内容，也不清理既有检查问题。对照最终文件列表和差异逐项验证。

让范围僵硬或无限

修复方法： 先给出狭窄的默认范围，再定义条件扩张。写明允许增加哪些测试或生成文件、哪些文件受保护，以及智能体必须在增加其他路径前报告哪些证据。

把兼容性当成口号

修复方法： 用小型兼容性矩阵列出受保护的使用者与维度。在每个重要行旁放置示例或特征测试，并明确哪些行为允许有意改变。

过度限制实现方式

修复方法： 先约束可观察行为与架构边界。只有内部形式能够保护所有权、依赖方向、安全、性能或稳定约定时才规定它，并在提示词中写明理由。

把具名命令当成已执行证据

修复方法： 要求完成报告写出命令、必要的工作目录、退出码和简短真实输出。命令缺失或受阻时，结果仍未完成；遇到基线失败，还要用聚焦比较说明补丁是否改变了它。

延伸阅读

• OpenAI 文档：提示词
• GitHub 文档：GitHub Copilot Chat 提示工程
• Claude Code 文档：最佳实践
• 语义化版本 2.0.0
• Google 工程实践：编写良好的 CL 描述