大模型踩坑经验汇总：从提示词到成本控制的真实问题清单
大模型接入后出的问题，大多不是模型本身不行，而是使用方式没设边界。
提示词随手写、上下文不限长、输出不校验、成本不监控、结果不做兜底，这五类问题占了新手踩坑的绝大多数。
下面按现象、原因和可操作的检查方法逐条整理，方便对照排查。
提示词写得太随意，同一问题两次答案差很多
最典型的踩坑是提示词里只写“帮我总结一下”，结果每次输出长度、语气、重点都不一样。
大模型对指令的敏感度很高，模糊描述会被自由发挥。
可落地的做法是把提示词拆成固定结构：角色、任务、输入、输出要求、禁止事项。
例如：
你是客服质检助手。
任务：判断下面这段对话是否存在辱骂用户的情况。
输入：{{dialog_text}}
输出：只返回 JSON，字段为 risk（是/否）和 reason（不超过30字）。
禁止：不要输出解释性段落，不要编造对话中不存在的内容。检查方法：用同一批 10 到 20 条样例反复调用，观察输出结构是否稳定。
如果字段名、长度、语气仍漂移，说明约束还不够具体，优先补“禁止事项”和输出示例。
上下文塞得太满，长文档处理开始报错或变慢
把整本手册或整段日志直接塞进一次请求，常见结果是报上下文超限，或者虽然没报错但回答质量明显下降。
原因是大模型对超长输入的注意力会衰减，中间部分容易被忽略。
判断是否踩坑，可以看两个信号：请求返回长度相关的错误码，或回答只覆盖了输入的开头和结尾。
处理方式不是一味换更长上下文的模型，而是先做切分：
- 按段落或章节切块，每块控制在几百到一两千字，保留标题作为定位信息。
- 先检索再拼接，只把最相关的几段送进模型，而不是全量输入。
- 在提示词里明确要求“只根据以下材料回答，材料没有的内容回复不知道”。
验证方法：拿一份超长文档，分别用全量输入和切分后输入各跑一次，对比回答是否覆盖了文档中段的关键信息。
输出格式不校验，程序解析直接崩
要求模型返回 JSON，结果它加了“好的，以下是结果”这样的前缀，或者字段名拼错，下游解析就报错。
这不是偶发问题，而是默认行为，必须做校验。
实用做法是两层防护。
第一层在提示词里给一个完整输出示例，并明确“只输出 JSON，不要 Markdown 代码块”。
第二层在代码里做解析兜底：
import json
def parse_output(text):
text = text.strip()
try:
return json.loads(text)
except json.JSONDecodeError:
start = text.find("{")
end = text.rfind("}")
if start != -1 and end > start:
return json.loads(text[start:end + 1])
raise ValueError("模型输出无法解析为 JSON")解析失败时不要静默吞掉，记录原始输出用于复盘。
如果失败率持续偏高，说明提示词约束不够，而不是解析代码有问题。
Token 成本失控，月底账单超出预期
成本踩坑往往不是单价高，而是调用结构没控制。
常见原因包括：把完整对话历史每次都重发、对简单任务用了大模型、失败重试没有上限、日志里存了超长输入。
建议在接入初期就做三件事：
- 记录每次调用的输入和输出 Token 数，按业务维度汇总，找出消耗最大的调用方。
- 对简单分类、抽取任务先用小模型，效果不达标再升级，不要默认上最大模型。
- 给重试设置次数上限和退避间隔，避免失败请求反复放大成本。
成本监控不需要复杂系统，一个按天汇总的脚本就能暴露大部分异常。
重点看单位业务量的平均 Token 消耗是否突然上升。
幻觉没有兜底，错误答案直接流到用户面前
模型会自信地编造不存在的条款、数字或链接，这是使用大模型绕不开的边界。
踩坑点在于把模型输出直接当事实展示，没有人工或规则校验。
降低风险的组合做法：要求模型在回答中标注依据来源，材料没有就明确说不知道；
对涉及金额、政策、资质等关键信息，设置人工复核环节；
对高频问题建立答案库，命中时优先返回固定答案，模型只负责改写表达。
需要明确的是，这些措施只能降低概率，不能保证完全消除幻觉。
涉及对外承诺的内容，人工确认不可省略。
上线前值得做的一次复查
把上面几类问题收敛成一份检查清单：提示词是否有固定结构和输出示例；
长输入是否做了切分和检索；
输出是否强制校验并记录失败样本；
Token 消耗是否按业务维度监控；
关键结论是否有人工兜底。
这五项都落实后，再考虑扩大调用量或接入更多场景，踩坑概率会明显下降。
