反直觉的地方在于：每隔几周，就有人发布帖子，信誓旦旦地宣称某个语言模型在任务上“失败”了。但如果你翻看评论区，差不多有一半的回复都是另一些人拿着同样的任务，跑出了可靠的结果，只是他们从来不说自己到底写了什么提示词。
这当然不是替任何一个模型辩护。值得点明的是一种反复出现的模式：大多数“AI弄错了”的报告，本质上是需求没写清楚的报告。这个困境一直存在，只是换了一层新的交互界面。当一张工单上只写着“修复登录bug”，却没有重现步骤、没有期望行为、没有环境信息，最后得到的修复方案很可能对不上号。对于这种结果，没有人会感到意外，大家只会说：工单需要更多细节。
可同样的失败模式换到语言模型身上，反应就完全不同了。 最常见的定论不再是“提示词还得再具体一些”，而变成了“模型的能力还不够好”。在某些场景下，这个判断也许成立，但更多时候，这就是那个老问题——规格说明不充分——穿上了一件新的外衣。
那么，到底什么会真正改变输出质量？ 答案不是长度，而是具体程度。 试着比较下面这两种提问：
模糊版本：
“写一个函数，用来验证用户输入。”
具体版本：
“编写一个函数，用于验证注册表单：
· 电子邮件需符合 RFC 5322 标准，而不仅仅是轻量正则匹配；
· 密码至少 12 个字符，包含 1 个数字和 1 个符号；
· 用户名只允许字母、数字和下划线，长度在 3 到 20 个字符之间。
返回值不是一个简单的真/假值，而是列出所有的具体错误信息。
使用 Python 编写，不允许依赖标准库之外的任何外部库。”
用的是同一个模型，前后输出的质量天差地别。在这两个请求之间，模型本身并没有任何改变——改变的是约束的表面积。 明确地给出约束条件、明确地定义“完成”的标准、明确地划定范围边界，有时“不要做什么”甚至比“要做什么”更重要。 这种能力和任何神秘的“提示词工程技巧”都沾不上边，它更接近起草一份好的需求规格说明，或者写一条高质量的代码评审意见。
多数人其实已经掌握了这项技能。我们在写 Jira 工单、在撰写 PR 描述、在评论同事的代码时，都会自然地给出具体的上下文和验收标准。这套手艺几乎可以直接平行迁移过来。之所以觉得不对劲，是因为和语言模型对话时，它仍然带着一种聊天的错觉，让人忽略了背后需要的依然是规格思维。 一旦错把对话感当成唯一的工作方式，模糊的请求就成了常态，而糟糕的输出则被错误地归因给模型本身。
那么，在给现实世界提交一份“这个模型做不到”的错误报告之前，有一个立即可行的调试步骤：如果把你的提示词原文一字不改地交给一个新入职的同事，除了这张纸条之外不提供任何额外信息，他能不能拿出一份在质量上明显更好的结果？ 如果连一个有上下文判断力的人类同事都做不到，那就不能把这说成是模型的能力瓶颈。
这是一道规格问题，而不是模型问题。它不需要等待下一次模型升级，也不需要更换更新的版本——你完全可以在接下来的五分钟内，像收紧一张模棱两可的工单一样，把它修正过来。 具体的指令、量化的验收标准和清晰的排除边界，才是让输出从“大致对”转向“精确符合预期”的真正杠杆。 每一次把模糊归咎于模型，都可能错过一个只要重新想清楚需求就能瞬间补上的机会。
热门跟贴