怀古游戏宅SIR1. 技术选型：先想清楚问题，再挑轮子
1.1 模型选型：开源还是闭源，70B还是7B
做AI应用开发，第一个绕不开的决策就是选模型。我见过太多团队一上来就冲着最大的模型去，结果钱花了、延迟扛不住、效果也没比小模型好多少。选模型本质上是选“能力边界”和“成本边界”的交集，而不是选“排行榜第一名”。
先说闭源API和开源模型的取舍。闭源API的优势是效果稳定、迭代省心，适合对效果要求高、团队没有专门优化模型的人才储备的情况。但它的劣势也很明显：数据出域、单价随调用量线性上涨、接口变更不可控。开源模型则可以私有化部署，数据留在自己手里，长线成本更可控，但你需要有人懂推理优化、显存管理、并发调度，这些隐性成本经常被忽略。
我个人的经验是：先确认业务是否允许数据出域，如果不允许，直接锁定开源路线，不用犹豫。如果允许，再算一笔账——按你的日活和调用频次，闭源API一年的费用大概是多少；同样的预算拿去租GPU机器跑开源模型，能覆盖多大吞吐。这笔账算完，方向基本就清晰了。
再说参数量怎么选。这里有一个常见的误区：以为参数量越大越好。实际上，7B到14B的模型在多数垂直任务上，经过微调或好的提示词工程，效果并不比70B差太多，而推理成本可能差出10倍。选型时要结合任务复杂度：简单的分类、抽取、摘要，7B足够；复杂的多跳推理、长文本理解、代码生成，再考虑34B以上；如果还要处理极强的逻辑链和工具调用，闭源大模型仍然是稳妥选项。
还要注意一个细节：同样参数量，不同架构和训练数据的模型，擅长方向差异很大。有的模型中文效果好，有的数学推理强，有的指令跟随稳。选型时不要只看跑分，要找跟你的业务最接近的评测集自己跑一遍，把“基于常见实践的补充说明”落到实处。
1.2 框架与中间件选型：别一上来就堆全家桶
项目一开始，团队容易犯的另一个毛病是“全家桶依赖症”——见一个框架火就接一个，LangChain有了还要接LlamaIndex，向量库用Milvus还要再套一层Elasticsearch，最后项目还没跑起来，基础设施先铺了一大片。
框架选型的核心原则是：你的业务复杂度决定框架复杂度，而不是反过来。如果项目核心就是“文档问答”或“知识库检索”，一个成熟的RAG框架就够了，不需要引入完整的Agent编排框架。如果项目确实要做多工具调用、多步推理、状态管理，才需要考虑接入Agent框架。
以LangChain为例，它确实封装了很多工具，但版本迭代快、抽象层级多，出了问题排查成本很高。我现在的习惯是：对稳定业务，尽量少依赖框架的高级抽象，核心链路用原生代码写清楚，框架只做工具调用的薄封装。这样做的收益是——出了问题你能控制堆栈，而不是被框架牵着走。
数据层选型同样要克制。如果你已经有PostgreSQL在跑业务，优先考虑pgvector，省掉一套新组件；只有数据量到了千万级别、检索性能成为瓶颈，再升级到Milvus这类专用向量数据库。中间的迁