夜雨聆风标题：Prompt决定AI应用的上限
digest：同一模型效果差十倍，问题不在模型在Prompt
发布日期：2026-08-21
一、为什么 Prompt 是上限
很多人把 Prompt 当"调用参数"，觉得反正模型这么强，说清楚就行。这个心智模型错在哪儿？
Prompt 不是参数，Prompt 是接口契约。你和大模型之间没有类型系统、没有 IDE 提示、没有编译器检查。唯一能约束模型行为的，就是这段自然语言。契约模糊，模型的输出方差就大，上层业务能拿到的确定性就低。
一个真实的对照：
实习生版本：「请你把下面这段话分类到合适的标签……」 重写版本：Role 明确是"客服工单分类系统"、Context 给出每个标签的定义和边界样例、Task 拆成"读原文 → 匹配定义 → 输出标签"三步、Format 强制 JSON、Constraints 明确"无法归类返回 unknown 而不是硬猜"。
差 48 个百分点的准确率，模型不背这个锅。
二、Prompt 差距会技术债化
Prompt 写差，最要命的不是当下效果差，而是技术债会累积。
第一阶段：效果不好，产品拍着你加检索。你加了 RAG，效果好一点。
第二阶段：还是不稳定，产品说加微调。你花两周准备数据集，微调完好一点。
第三阶段：新场景来了，还是不稳。你开始怀疑模型不够强，去等下一代。
真实情况是：如果 Prompt 本身是模糊的，你在下游加多少层都是在为混乱的接口打补丁。RAG 会把不该检索的东西也送进去，微调会把 Prompt 里的模糊性烧进权重里。
Prompt 是最底层的杠杆。这一层没做好，上面每一层的 ROI 都会打折。
三、Prompt 是可以工程化的
Prompt 工程之所以是"工程"，不是"艺术"，因为它满足工程的三个基本特征：
- 可拆解
：一个好 Prompt 能拆成 Role/Context/Task/Format/Constraints 这样的独立模块，每个模块职责单一。 - 可版本管理
：Prompt v1 → v2 的每次改动应该有 diff、有测试集、有指标对比。 - 可回归测试
：改一个模块，跑测试套件，能定量看到影响哪些用例。
如果你的 Prompt 是一整段散文，改一个词你都不知道会不会影响其他 case——这就不是工程，是玄学。
四、用代码感受一下差距
我们把上面那个实习生场景写成可运行代码，跑一遍就明白 Prompt 结构的价值。
# 实际运行需要 ANTHROPIC_API_KEYfrom __future__ import annotationsfrom dataclasses import dataclassfrom typing import Callableimport anthropicclient = anthropic.Anthropic()MODEL = "claude-sonnet-4-6"BAD_PROMPT = """请你把下面这段话分类到合适的标签，标签有：账号问题、退款、物流、产品咨询、投诉、其他。用户反馈：{feedback}"""GOOD_PROMPT = """<role>你是电商平台客服工单分类系统。</role><task>1. 阅读用户反馈原文2. 对照标签定义判断归属3. 若无法明确归类，返回 unknown 而非强行选择</task><labels>- account: 登录、注册、账号安全- refund: 已支付订单的退款申请- shipping: 物流查询、配送异常- product_qa: 产品功能、参数咨询（未下单）- complaint: 对服务或产品的投诉表达- unknown: 无法明确归入以上任一类</labels><format>仅输出 JSON：{{"label": "<标签>", "confidence": <0-1>}}不要输出任何解释文字。</format><feedback>{feedback}</feedback>"""@dataclassclass Case: text: str expected: strdef classify(prompt_template: str, feedback: str) -> str: """调用模型分类，返回原始文本。""" resp = client.messages.create( model=MODEL, max_tokens=200, messages=[{"role": "user", "content": prompt_template.format(feedback=feedback)}], ) return resp.content[0].textdef evaluate(prompt_template: str, cases: list[Case], parse: Callable[[str], str]) -> float: """在测试集上计算准确率。""" hit = 0 for c in cases: pred = parse(classify(prompt_template, c.text)) if pred == c.expected: hit += 1 return hit / len(cases)def parse_bad(raw: str) -> str: # 散文 Prompt 输出难解析，只能粗匹配 for kw, lb in [("退款", "refund"), ("物流", "shipping"), ("账号", "account")]: if kw in raw: return lb return "unknown"def parse_good(raw: str) -> str: import json try: return json.loads(raw)["label"] except Exception: return "unknown"if __name__ == "__main__": cases = [ Case("我上周下单的东西还没发货，物流状态一直不更新", "shipping"), Case("这个功能到底怎么用啊，说明书完全看不懂", "product_qa"), ] # print("bad :", evaluate(BAD_PROMPT, cases, parse_bad)) # print("good:", evaluate(GOOD_PROMPT, cases, parse_good))
真实场景下，BAD_PROMPT 因为输出没有结构，你连"模型答错了"和"模型答对了但解析失败"都分不清；GOOD_PROMPT 给了明确 JSON 契约，任何错误都能精确归因。
五、这个系列的立足点
Prompt 决定上限这句话有两层含义：
- 正向
：一个精心设计的 Prompt，能把模型能力压榨到接近其真实上限。 - 反向
：一个糟糕的 Prompt，会让你以为模型不够强，把你导向错误的技术决策。
接下来 8 篇，我们一层一层把 Prompt 工程的方法论拆开。下一篇聊结构化 Prompt 设计，Role/Context/Task/Format/Constraints 五要素，怎么用、怎么落地成模板。