标准回答
第一步:看 badcase,找失败模式
不要凭感觉乱改。先把效果差的实际输出收集一批,分析共性:是它没听懂指令、输出格式乱、漏了关键约束、还是缺背景知识?先定位「错在哪类」。
第二步:按失败模式针对性改
指令模糊 → 把要求写明确、给清晰角色和目标;答得没谱 → 加 2–3 个 few-shot 示例示范;格式乱 → 明确规定输出格式(如只输出 JSON);推理类错得多 → 让它分步思考(CoT);越界/跑题 → 加约束和边界(「只根据给定材料回答」);任务太复杂 → 拆成多步分别处理。
第三步:一次只改一处 + 对照评测
每次只动一个地方,在固定评测集上跑前后对比,确认这处改动是涨还是跌。同时改好几处会让你分不清哪个有效、哪个有害。
第四步:固定评测集防回退
维护一个有代表性的样例集(含难例),每轮迭代都全量跑一遍,避免「按下葫芦浮起瓢」。核心是用数据驱动迭代,而不是改一句看一眼就觉得变好了。
常见误区
⚠️ 常见踩坑
凭感觉一次改一大堆,又没有评测集,看一两个例子就以为变好——很可能修了 A 又坏了 B,且无法复现哪次改动真正有效。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。