在AI智能体轻创业的初期，技术选型看似只是工程师的一次“工具挑选”，实则是一场关乎产品生死、团队存续与商业节奏的战略抉择。许多创始人抱着“先跑通MVP”的朴素想法仓促上马，却在三个月后陷入模型不可维护、API成本失控、数据无法闭环、合规风险爆发等泥潭。以下是十个高频、隐蔽、且后果严重的技术选型陷阱，来自数十个真实轻创业项目的复盘教训：

1. 过度依赖闭源大模型API，忽视推理可控性
把GPT-4或Claude作为唯一推理引擎，短期内开发飞快，但很快会遭遇：响应延迟波动大、上下文长度被平台单方面缩减、提示词工程效果不可复现、审计日志缺失、以及最关键的——当业务增长十倍时，API账单呈指数级飙升。轻创业团队应从Day 1就规划混合架构：核心逻辑用开源小模型（如Qwen2.5-7B、Phi-3）本地微调+关键环节调用闭源API兜底。

2. 把LangChain/LlamaIndex当“银弹”，不评估抽象泄漏
这些框架极大降低了编排门槛，但也悄悄引入了隐式状态管理、非标准错误码、版本碎片化等“抽象泄漏”。一个典型症状是：本地调试通过，部署到K8s后因缓存策略冲突导致记忆丢失。建议初期只用其最原子的组件（如DocumentLoader、Embeddings），其余链路手写，待MVP验证后再反向封装。

3. 选用未经过生产验证的新兴向量数据库
Weaviate、Qdrant虽活跃，但轻创业团队常忽略其在高并发更新、元数据过滤稳定性、分片再平衡等方面的成熟度。曾有项目上线两周后因向量索引重建失败导致全量检索失效。初期优先选择PostgreSQL+pgvector——它支持ACID、可备份、有完善监控，且90%的语义搜索场景已足够胜任。

4. 忽视RAG中的“召回-重排”分离设计
直接用单一向量库做召回+排序，导致长尾Query准确率断崖下跌。正确路径是：第一阶段用稠密向量粗筛（快），第二阶段用Cross-Encoder或轻量级reranker精排（准）。跳过重排等于放弃对专业领域问答质量的底线把控。

5. 在无明确用户反馈前，盲目投入Agent多步规划能力
ReAct、Plan-and-Execute等范式炫酷，但80%的早期用户需求本质是“单轮精准响应”。过早构建复杂Agent工作流，会吞噬本应用于打磨Prompt、优化知识库和提升响应速度的资源。牢记：可用性永远优于智能性。

6. 采用未经裁剪的开源模型全量参数部署
下载一个Llama3-70B直接扔进4×A10，结果OOM崩溃、首token延迟超8秒。轻创业必须坚持“模型即服务”的最小可行原则：使用GGUF量化（Q4_K_M）、vLLM推理引擎、动态批处理，并始终以P95延迟≤1.2秒为硬指标反向约束选型。

7. 将所有数据无差别注入向量库，不建分级索引策略
用户手册、会议纪要、客服对话混存一库，导致检索噪声爆炸。必须按数据可信度、更新频率、业务权重建立三层索引：结构化知识（高精度向量+关键词）、半结构化流程（带Schema嵌入）、非结构化日志（仅关键词检索）。

8. 忽略本地化部署的合规刚性要求
面向金融、医疗、政务类客户的项目，若在技术方案中默认采用境外云服务或未备案API，将直接丧失投标资格。选型时需前置确认：模型权重是否可离线加载？向量库是否支持国产芯片（如昇腾）？日志存储是否满足等保二级？

9. 用Jupyter Notebook原型直接转生产服务
Notebook里一行model.generate()很优雅，但生产环境需要请求队列、熔断降级、GPU显存隔离、异常采样上报。所有Notebook代码必须经过“三化”改造：模块化（拆出data/model/prompt层）、容器化（Dockerfile明确CUDA版本）、可观测化（接入Prometheus+Grafana）。

10. 技术栈过度追求“最新”，放弃社区支持纵深
选择刚发布两周的推理框架，却发现GitHub Issues无人响应、中文文档为零、连基础CUDA兼容问题都要自己逆向调试。轻创业不是技术发布会——稳定、文档全、Stack Overflow有2000+相关问答、国内有活跃微信群，这些“软性指标”比Benchmark跑分重要十倍。

技术选型没有最优解，只有最适配当前阶段约束条件的次优解。真正的轻创业智慧，不在于追逐技术浪潮之巅，而在于清醒识别哪些技术能为你省下三个月时间、规避一次融资危机、守住第一条客户信任。每一次选型决策，都该自问：这个选择，是让我的团队更快抵达用户，还是更快迷失在技术迷宫里？