选型的核心不是模型
很多团队选型时先纠结用哪个大模型，其实模型的替换成本比想象中低。真正难换的是应用架构、数据模型和交互实现。
所以第一步应该确定应用形态：是纯前端体验、带后端的 Web 应用，还是需要流式与长任务的完整服务。
一个够用的默认组合
对于大多数 Web AI 应用，一套稳妥的组合是：React/TypeScript 负责界面，Node.js 负责 API 与编排，PostgreSQL 存业务数据，向量数据库存知识，模型通过统一网关调用。
这套组合的优点是每一层都有成熟的生态，团队容易找到人、查到文档、长期维护。
什么时候需要更重的方案
需要异步任务队列、定时知识库更新、大量并发调用时，引入消息队列和任务系统是值得的。需要多租户、细粒度权限和审计时，先设计数据隔离而不是后期打补丁。
判断标准不是「未来可能需要」，而是「未来三个月内会不会出现」。
- 模型接入统一网关，避免供应商锁定
- 数据权限在第一天设计，而不是上线后补
- 流式输出、重试、超时从第一版就实现
给未来留一个替换口
把模型调用、知识检索、评测都封装成接口，模型可以换、向量库可以换、提示词可以改，而应用主体不动。
技术选型的最终标准：一年后团队还能轻松改它。
三个常见选型失误
第一个失误是为「未来的规模」选择重架构，结果半年内团队都在维护超出需求的复杂度。第二个失误是把模型供应商的能力直接耦合进业务代码，换模型时牵一发动全身。
第三个失误是忽略数据权限：技术栈再漂亮，多租户数据隔离没设计好，上线即事故。选型时把这三个失误当成反面清单，比追逐新框架更有效。
一个中小项目的落地顺序
先写业务代码和数据模型，再接入模型调用，最后才做性能优化。顺序反了，团队会在没有用户验证的架构上浪费大量时间。
第一周的目标是跑通一条「脏但完整」的链路：用户输入、模型处理、结果返回。有了链路，才能开始讨论延迟、成本和稳定性。
技术选型的答案会在真实链路里自己浮现：哪些环节慢、哪些环节贵、哪些环节不可靠，比任何架构评审都清楚。
什么时候需要重写
技术栈需要重写的信号有三个：改一个功能要动五个模块、上线一次要全量回归、新同事要一个月才能看懂。这三个信号同时出现，才值得认真讨论重写。
重写最怕的是「借重写之名行重构之实」：一边改架构一边加需求，结果半年没有版本交付。
如果只是局部混乱，先做模块隔离和接口收敛；只有当隔离已经救不了整体，才启动重写。