标准回答
一、先给出结论和背景
- 第一步：用最强现成模型做 Prompt 原型：不要一开始就想着微调或搭一套系统。先拿 GPT/Claude 这类现成强模型，写个 prompt 把任务跑起来，这是成本最低的可行性探针——如果最强模型加好 prompt 都做不好，自研更难成。
- 第二步：收集几十条真实样例手测：从真实业务里捞 20–50 条有代表性的样例（含难例、边界），逐条跑看效果，找失败模式。这比看官方 demo 真实得多。
二、拆开关键步骤和判断点
- 第三步：先定成功标准，再跑小评测集：明确「达到什么算可行」，比如准确率 ≥ 85%、人工满意率达标。把样例整理成小评测集，量化跑分，用数据说话而不是凭感觉。
- 第四步：估成本与延迟：算一下单次调用的 token 成本、并发下的费用，以及响应延迟用户能否接受。可行性 = 效果达标 + 成本可控 + 延迟可接受。
三、补上落地边界和取舍
- 第五步：达标再投工程：验证通过再考虑 RAG、微调、工程化；不通过就快速调整方向或放弃，省下大量试错成本。
常见误区
⚠️ 常见踩坑
误区一：容易答偏的地方：一上来就训练模型或搭复杂系统，投入巨大才发现方向不对；或只看几个漂亮 demo 就拍板，没有评测集和成功标准，上线后效果崩盘。
追问
追问 1：验证阶段要不要先做微调？
通常不要。微调成本高、迭代慢，应放到最后。先用强模型 + Prompt + few-shot + RAG 把效果做上去，只有当这些都顶到天花板、且有足够标注数据时，再考虑微调。验证阶段追求的是快和省。
追问 2：小评测集怎么搭，多少条够？
从真实数据里抽几十条代表性样例（覆盖常见 + 难例 + 边界），标好期望答案。验证阶段几十条就能看出大致行不行；要上线再扩到几百条并固定下来，每次改动都跑一遍防回退。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习