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