代码生成提示词速查表 - 需求/上下文/约束/验收
代码生成与写文案最大的差别在于输出必须可编译、可运行，而模型最容易出错的正是「看起来合理」的语法。因此提示词不能只描述目标，而要把四件事一次交代齐：任务与最小上下文（贴真实代码片段而非形容词）、不可违背的约束（语言、框架版本、风格、禁改范围）、输入输出契约（函数签名、返回类型、错误语义）、以及可判定的验收标准（给定输入应得到什么输出、边界与异常路径怎么处理）。写法上，最小改动原则能显著压低回归风险；明确要求先给计划再给代码，能在早期发现理解偏差；把输入输出样例直接写进提示，通常比任何形容词都更少返工。表里按需求与上下文、约束与契约、边界与测试、验收与交付、常见避坑分组，附可套用的模板结构，照着填即可。
需求与上下文 5
任务：{做 X}。上下文：{现有代码结构/依赖}。现有相关代码：
```{lang}
{code}
```目标文件/函数：{path#func}，请只改必要处不要重构无关代码，保持最小改动先解释思路再给代码约束与契约 5
语言/框架/版本：{TS 5 + Nuxt 4}，遵循{风格指南}函数签名必须：{输入类型}→{返回类型}，不抛未声明异常不要引入新依赖；复用现有工具函数命名遵循{项目约定}，不加 emoji/缩写兼容{Node 20+ / 浏览器最新两版}边界与测试 5
处理边界：{空输入/超长/非法类型/并发}给出 3 个单元测试（含一个异常路径）若输入不合法，返回{明确的错误}而非崩溃考虑{性能/内存}上限，给出复杂度说明标注可能的失败点与兜底验收与交付 5
验收标准：{能通过 X 测试 / 输出符合 Y}给出调用示例与预期输出说明与现有代码的集成点列出未覆盖的风险或假设如无法完全满足，先说明取舍避坑 5
上下文给全比长描述有用签名/契约写死防跑偏要测试尤其异常路径最小改动原则验收要可判定命令示例
完整四段式：任务与上下文、约束与契约、边界、验收
任务：把 X 实现出来。上下文：现有代码结构与依赖如下。
目标文件/函数：{path#func}，只改必要处，不要重构无关代码。
语言/框架/版本：{TS 5 + Nuxt 4}，遵循{风格指南}。
函数签名必须：{输入类型}→{返回类型}，不抛未声明异常。
不要引入新依赖；复用现有工具函数。
处理边界：{空输入/超长/非法类型/并发}；输入不合法时返回{明确的错误}而非崩溃。
验收标准：{能通过 X 测试 / 输出符合 Y}，并给出调用示例与预期输出。把 intro 里强调的四件事一次交代齐：最小上下文、可判定的契约、显式边界清单、可判定的验收标准。最少改动原则压低回归风险。
测试要求：三个单测且必须含异常路径
给出 3 个单元测试（含一个异常路径）。
若输入不合法，返回{明确的错误}而非崩溃。
考虑{性能/内存}上限，给出复杂度说明。
标注可能的失败点与兜底。异常路径不在提示里点名就不会出现；把错误语义（返回什么错误、不崩溃）与复杂度说明一起要求，生成结果才可能直接合入。
先方案后实现：思路先行，附集成点与风险
先解释思路再给代码。
说明与现有代码的集成点。
列出未覆盖的风险或假设。
如无法完全满足，先说明取舍。四步把交付从「一段代码」变成一份可评审的变更说明；最后一句避免模型默默少做一半却报告完成。
调用示例即文档：输入对应期望输出
给出调用示例与预期输出。
现有相关代码：
{code}
目标文件/函数：{path#func}，请只改必要处。把期望输出写成样例（输入 → 期望结果）比用「请返回 JSON 格式」这类描述更少返工；贴真实片段让模型沿用现有风格与工具函数。
常见坑与注意事项
- 用形容词描述现状而不贴真实代码片段（「代码结构混乱」），模型只能猜，越猜越跑偏。
- 不写函数签名与错误语义契约，生成结果会用自己发明的参数顺序和异常类型，调用方全部要改。
- 不列边界清单也不点名异常路径，测试里就只会剩正常用例，最容易出事的分支没有覆盖。
- 不声明禁止改动的文件与最小改动原则，模型会顺手重构无关代码，PR 体积失控、review 成本暴涨。
- 验收标准写成「代码质量高」这类无法判定的表述，交付时无法判断是否达标，返工往往在最后才发现。
提示
- 代码生成提示词的核心是"把任务、上下文、约束、验收一次性交代清楚"——贴相关代码片段比形容词描述更降歧义。
- 显式语言/框架/版本约束 + 函数签名契约，能把模型从"自由发挥"拉回"按规范实现"。
- 边界与测试（尤其异常路径）最易被漏，提示里主动列边界清单并要求单测，可大幅提升可用率。
- 最小改动原则 + 可判定验收标准，让生成的代码容易 review、容易合并。
- 把期望输出直接写成样例（输入 → 期望结果）比用「请返回 JSON 格式」这类描述更少返工。
- 在提示里写明禁止改动的文件清单与调用方签名，模型才不会顺手重命名公共函数。
- 要求先复述需求再动手，歧义会在这一步暴露，比生成后返工便宜得多。
常见问题
为什么贴代码片段比写形容词更降歧义？
因为模型只能依据你给的信息判断现状，写「现有代码结构混乱」不如直接贴出真实片段：调用方长什么样、现有工具函数叫什么、风格是什么样。同时在提示里写明目标文件与函数（如 path#func）并要求只改必要处，歧义会集中在真正需要决策的那一处，而不是散落在各处。
怎么防止生成的代码「看起来对」但接不进项目？
把契约写死：函数签名必须是「输入类型 → 返回类型」且不抛未声明异常；不引入新依赖，复用现有工具函数；命名遵循项目约定；运行环境约束写明（如 Node 20+ 或浏览器最新两版）；并把不可改动的文件与调用方签名一并列出。模型才不会顺手重命名公共函数或引入一个你没批准的库。
边界与测试该怎么在提示里要求？
主动列边界清单（空输入、超长、非法类型、并发等），明确要求 3 个单元测试且其中必须包含一个异常路径，并规定输入不合法时返回明确的错误而不是崩溃。另外要求给出性能或内存上限的复杂度说明，以及标注可能的失败点与兜底。异常路径是最容易漏的一环，不在提示里点名它，它就不会出现在测试里。
「先复述需求再动手」为什么值得多花一步？
因为歧义会在这一步暴露，比生成后返工便宜得多。同理，先解释思路再给代码，能让你在看实现之前就否掉方向错误的方案。提示里还可以加一句：若无法完全满足，先说明取舍——这让模型给出降级方案并说明代价，而不是默默少做一半。
验收标准怎么写才「可判定」？
用能通过的具体测试或能对照的具体输出来表述，而不是「代码质量高」。同时给出调用示例与预期输出（输入对应什么结果），要求说明与现有代码的集成点，并列出未覆盖的风险或假设。把期望输出直接写成样例比写「请返回 JSON 格式」这类描述更少返工。
由 巧匠 维护
公开更新于 2026年8月23日，内容持续校对官方文档。