# 别只会调用模型：18 个值得 AI 工程师动手做的生产级项目

很多 AI Demo 看起来很惊艳，但一到生产环境，真正棘手的问题往往不是“模型能不能回答”，而是：回答是否有依据、成本是否可控、系统是否可观测、失败后能否恢复、敏感数据是否安全，以及高风险操作能否交给人来把关。

Suraj Sharma 在一则 X 帖子中列出了 18 类 AI 工程项目，覆盖检索、路由、评测、观测、安全、部署、商业化与开源协作。与其把它们理解成“每个人都必须完成的作业”，不如把它们当成一张生产级 AI 能力地图。

> 原文：Suraj Sharma，[*18 production AI projects every AI engineer should build*](https://x.com/suraj_sharma14/status/2084542353344282850)
>
> 说明：原帖是一份项目与技术栈清单，没有提供代码仓库、性能指标或实际运行结果。本文在保留原有 18 项顺序的基础上进行中文整理，并补充有限的实践解读。

## 1. 带引用的生产级 RAG

构建一个 PDF 问答系统：回答时引用具体页码，同时加入混合检索、重排序和 grounding，避免系统只给出听起来合理、却无法追溯的答案。

**参考技术栈：** LangGraph、SQLite-vec、Cross-Encoder。

真正值得展示的不是“接入了向量数据库”，而是引用准确率、检索命中率，以及无依据时能否拒答。

## 2. 成本优化的模型路由器

根据查询复杂度，将请求分配给不同价格和能力的模型，并记录每次请求的成本。

**参考技术栈：** LiteLLM、Prometheus、自定义路由器。

模型路由不能只看费用，还要同时测量回答质量、延迟和路由误判。否则省下的调用费，可能会变成更高的返工成本。

## 3. 多 Agent 研究系统

由 Supervisor 协调研究、写作和事实核查 Agent，并加入共识逻辑、人工审批与审计记录。

**参考技术栈：** CrewAI、审计轨迹。

多 Agent 并不天然优于单 Agent。这个项目真正要验证的是：角色拆分是否提高结果质量，额外调用成本是否值得，以及冲突如何收敛。

## 4. 自动化评测框架

每次部署前运行 100 个以上的 golden cases，发现质量回归就阻断发布，并持续追踪指标趋势。

**参考技术栈：** DeepEval、RAGAS、LangSmith。

原帖提出了“100+”这一规模，但没有给出通用依据。测试数量不是重点，覆盖真实失败模式、指标定义清楚、结果能控制发布，才是评测框架的价值。

## 5. 实时可观测性面板

集中展示分布式追踪、单请求成本、延迟分位数、错误率，并对异常进行告警。

**参考技术栈：** OpenTelemetry、Grafana、Prometheus。

不要只做一张好看的 Dashboard。更关键的是：一次异常能否从用户请求追踪到模型、检索、工具和下游服务，并定位具体失败环节。

## 6. 安全护栏中间件

在统一入口检测提示注入、脱敏个人信息、过滤输出、执行限流，并隔离高风险代码或工具调用。

**参考技术栈：** Guardrails AI、自定义规则。

安全能力需要用攻击样本、误报率和绕过测试来验证。仅仅接入护栏库，并不能说明系统已经安全。

## 7. Local-First 开发环境

在本地完成离线测试，尽量减少 API 成本，同时让开发架构接近生产环境。

**参考技术栈：** Ollama、SQLite-vec 或 LanceDB、FastAPI、Docker。

本地环境适合快速迭代，但要保留模型差异测试：本地模型跑通，不等于生产模型的输出、工具调用和性能表现完全一致。

## 8. 流式 Copilot 界面

实现 Token 实时流式输出、乐观更新、延迟升高时的优雅降级，以及中断后的错误恢复。

**参考技术栈：** Next.js、Vercel AI SDK。

用户体验不只是“字一个个出现”。断线重连、重复提交、取消生成、超时提示和部分结果保留，才是生产界面的难点。

## 9. 基于 LoRA 的微调流水线

覆盖数据准备、指令微调、DPO 对齐、微调前后评测，以及灾难性遗忘检查。

**参考技术栈：** PEFT、Hugging Face。

完整流水线必须回答两个问题：微调是否真的优于提示工程或 RAG，以及新能力是否以损害旧能力为代价。

## 10. 多租户 SaaS Agent

实现租户隔离、按租户限流、按使用量计费、数据分区和审计记录。

**参考技术栈：** Supabase、Stripe、LangGraph。

这是从 Demo 走向产品的重要一步。重点不在支付页面，而在跨租户数据泄漏防护、计费准确性和权限边界验证。

## 11. AI 系统的 CI/CD

将自动测试、金丝雀发布、功能开关和质量下降后的自动回滚纳入部署流程。

**参考技术栈：** GitHub Actions、Argo CD。

传统服务通常按错误率和延迟回滚；AI 系统还需要质量指标。但自动回滚之前，必须先定义什么叫“质量下降”。

## 12. 规模化向量数据库

实现混合检索、元数据过滤、Embedding 缓存、索引优化，以及备份和恢复流程。

**参考技术栈：** Qdrant 或 Weaviate。

不要只比较向量数据库的功能表。用自己的数据测量召回率、延迟、吞吐量、索引成本和恢复时间，结果才有意义。

## 13. Agent 记忆系统

设计短期缓冲、长期召回、上下文压缩、跨会话同步和记忆淘汰策略。

**参考技术栈：** Redis、向量数据库。

记忆系统不应只追求“记得更多”。还要解决错误记忆、过期信息、隐私权限、冲突覆盖，以及用户删除记忆后的可验证清除。

## 14. 生产级推理服务器

部署 vLLM 或 SGLang，实践 KV Cache 优化、连续批处理、量化和负载均衡。

**参考技术栈：** vLLM、Kubernetes。

这个项目应交付真实的吞吐量、首 Token 延迟、显存占用、并发能力和单位请求成本，而不是只有一份部署配置。

## 15. Human-in-the-Loop 工作流

检测不确定性，为高风险任务提供审批界面，并支持暂停、恢复、上下文校验和完整审计。

**参考技术栈：** LangGraph、自定义 UI。

人工审批不应成为装饰性按钮。系统需要说明何时必须交给人、审批者能看到什么证据，以及拒绝后任务如何安全终止。

## 16. Agent 自动化管道

通过 Webhook 触发异步任务，并实现幂等、死信处理、重试和指数退避。

**参考技术栈：** FastAPI、Celery。

可靠性要靠故障测试证明：重复事件会不会执行两次、下游中断后能否恢复、超过重试上限的任务是否可追踪。

## 17. 垂直领域基准测试

面向法律、医疗、金融或代码等领域创建评测套件，并尝试建设公开排行榜和社区协作机制。

**参考技术栈：** 自定义评测、pytest。

领域评测的难点通常不是写测试脚本，而是数据来源、专家标注、合规边界和指标能否反映真实风险。公开排行榜和社区采用是目标，不是项目完成后自动获得的结果。

## 18. 参与开源项目

为 LangGraph、CrewAI 或 LlamaIndex 等项目修复缺陷、增加功能、补充文档或发布基准测试。

**参考技术栈：** 自选。

与自建 Demo 相比，被真实项目接受的贡献更能体现代码质量、协作能力和维护意识。但贡献规模和实际影响仍需通过合并记录、用户反馈或后续维护来判断。

## 不要一次做完 18 个项目

这份清单的价值在于覆盖面，而不是让人同时维护 18 个孤立仓库。更实际的做法，是先选择一个端到端项目，再逐步把其他能力合并进去。

例如，可以从“带引用的 RAG”开始，然后依次补齐：

1. 用固定问题集建立评测门禁；
2. 记录质量、成本、延迟和错误率；
3. 加入提示注入检测与敏感信息脱敏；
4. 对高风险回答启用人工审批；
5. 通过金丝雀发布和自动回滚控制变更；
6. 用故障注入验证重试、幂等和恢复流程。

这样最终得到的不是六个浅层 Demo，而是一个有评测、有观测、有安全边界、能恢复、可发布的完整系统。

## 衡量项目价值，别只看技术栈

如果准备把这些项目放进作品集，可以用五组问题检查完成度：

- **质量：** 有固定测试集和明确指标吗？失败会阻断发布吗？
- **成本：** 能看到单次请求和不同模型路径的真实费用吗？
- **可靠性：** 超时、重复请求、下游故障和数据恢复都测试过吗？
- **安全：** 权限、租户隔离、敏感信息和工具执行边界验证过吗？
- **可运营性：** 有追踪、告警、审计、回滚和人工接管机制吗？

最终，能证明生产能力的并不是项目名称，也不是用了多少热门框架，而是你能否拿出真实指标、失败案例、边界设计和恢复证据。

## 结语

这 18 个项目勾勒出一条清晰的能力升级路线：从模型调用，走向质量控制、系统可靠性、安全治理和持续运营。

但“每位 AI 工程师都必须全部构建”仍是过强的判断。更值得采用的原则是：根据岗位和业务风险选择一个真实问题，做出最小的端到端闭环，再用评测、观测、安全与回滚把它逐步推向生产，而不是堆砌 18 个只有 README 的仓库。