提示词工程：Context、Constraints、Clarity 三个 C

用 AI 生成测试用例，第一步是把话说清楚。三个 C 是个好起点，但它解决不了这个垂类最要命的那个问题。

三个 C

Context（上下文） —— 被测的是什么、给谁用、跑在哪儿。没有它，模型只能按「一般的登录功能」来写，而你的登录可能有短信验证、有企业 SSO、有锁定策略。

Constraints（约束） —— 输出成什么形状、覆盖到什么程度、哪些不要写。这一格最容易漏的是否定式约束：不要写 CSS 选择器、不要假设有测试账号、不要编造界面文案。

Clarity（清晰） —— 一句话只说一件事，用词固定。同一个概念在提示词里出现三个叫法，模型会当成三样东西。

但三个 C 治不了幻觉

这是这一篇真正要说的。

我拿一份四段的产品文档跑过一轮，生成了 66 条用例。检查断言里引用的界面文案：12 条里只有 4 条能在文档里查到。

查不到的那些长这样：

「邮箱格式无效」
「密码必须包含大写字母」
「账户已锁定，请 10 分钟后再试」

看起来完全合理 —— 而这正是问题。文档里写的是规则（「密码至少 8 位，必须含一个大写字母」「连续输错 5 次锁定 10 分钟」），没写产品会显示哪句话。

规则和文案是两回事：文档承诺了行为，没承诺措辞。 拿没承诺的措辞去断言，对着一个完全正确的产品也会红。

后来我试着写一个更狠的检测器 —— 把断言里所有中文词块拿去材料里查 —— 结果 66 条全被标可疑。那个 100% 的误报率反而说明问题比我原先量到的大得多：多数断言压根不带引号，编造的措辞混在自然语句里，连数都数不出来。

怎么治：要出处

这个垂类的综述给了明确方向：幻觉控制做得好的系统，无一例外都引入了 external anchoring —— 每条产出必须能指回一个外部锚点。

落到提示词和 schema 上是两条：

一、每条用例必须给出依据，逐字抄材料原话。 抄不到就说明材料没讲，那就别写这条。

二、不许编界面文案。 除非材料里明写了某句话，否则断言只描述行为（跳转到哪、出没出现错误提示），不写具体措辞。

但光写进提示词不够 —— 提示词是请求，代码才是约束。所以还要有一道校验：依据在材料里查不查得到、断言里引号内的文案有没有出处。我实测这道检查在真实脑补样本上七中六，而且两条好用例零误伤。

三个 C 之外该补的一个 C

我想补一个：Cost（代价）。

提示词里每加一句，都是每次调用都在付的税。而更值得知道的是：这个方向的问题比「写不写得清楚」严重得多。DeCon 那篇拿四个模型在 HumanEval 上做过统计，生成的断言里超过 62% 是不正确的。

这个数和我自己量到的那 12 条里只有 4 条可溯源，几乎是同一个量级 —— 断言这一格的基线，本来就比人们以为的低得多。

所以「把所有能想到的都写进提示词」是个坏策略。 能在解析层做的（认下字段的别名）、能在代码里做的（校验出处），都不该占提示词的位置 —— 说到底提示词是请求，代码才是约束。

边界与代价

出处校验只能查引号里的文案。 不带引号的编造（「跳转到收件箱」，而产品其实是「待办列表」）它抓不到。我试过更宽的检测，误报率 100%，只能放弃。这道门缩小了问题，没有消灭问题 —— 但它仍然值得装，因为幻觉控制做得好的系统，无一例外都引入了某种外部锚点。

再补一句我自己的判断，关于这道门的代价。加上「抄不到原话就不许写」之后，模型的产出明显变少了 —— 有些它本来能想到的边界情况，因为文档里没写，它就不写了。这个代价我认，理由是：在测试这一格里，一条查不到依据的用例造成的伤害，比少一条用例大得多。 一条编造的断言会对着一个完全正确的产品报红，而红了之后没人查得出它为什么红 —— 那才是真正贵的东西。

要求给出处会降低产出量。 模型抄不到依据就不写这条用例，覆盖度会掉。这个代价我认，因为一条编造的用例比没有这条用例更贵 —— 它会在某天变成一次假报警。

这一格量出来的数字来自一个演示产品。 66 条、12 条引用、4 条有出处 —— 换一份更详细的文档，比例会变。可以拿它论证「要查出处」，不能拿它推算你的项目会有多少条是编的。