这一页列的是我们常用的技术与做法，按场景选型，不为了用新技术而用。
具体项目会按客户的环境调整，也可能用你已有的技术栈。
模型与推理
- 训练与微调：PyTorch、Hugging Face Transformers、LoRA 等参数高效微调
- 推理部署：vLLM 类推理服务、量化与蒸馏、并发与显存压测
- 能力方向：文本生成与信息抽取、多模态理解、Embedding 与检索增强
- 私有化：模型与推理服务可部署在客户内网或指定云环境，数据不出边界
数据与检索
- 文档解析与切片：PDF、Word、扫描件、表格与图文混排
- 向量检索：主流向量库选型与索引调优，混合检索（关键词 + 向量）
- 质量控制：标注规范、答案评估集、错例回流与回归测试
- 数据工程：清洗、去重、权限打标、增量更新链路
应用与终端
- 后端：Java / Spring Boot、Python / FastAPI、Node.js
- 前端与小程序：Vue 生态、微信小程序、移动端应用
- 集成：API 网关、单点登录、权限体系、与 MES/ERP/PLC 等既有系统对接
- 工业侧：视觉检测工位软件、边缘部署、产线数据采集与看板
云与运维
- 容器化：Docker、编排与配置管理
- 交付流水线：CI/CD、灰度发布、回滚机制
- 可观测：日志、指标、告警、链路追踪
- 可靠性：备份与恢复演练、故障响应约定
我们怎么做项目
先判该不该做。 需求诊断阶段我们就可能给出”现在不适合做”的结论，并说明缺什么条件。
验收标准写在前面。 大模型类项目效果依赖数据质量，开工前就把评估集和达标线定下来，避免”演示看着不错、上线没人用”。
交付即可自持。 源码、部署文档、操作培训一并交付，日常业务配置不需要技术人员参与。
留闭环，不只交一版。 使用数据、错例、版本计划进运营迭代，效果要能守住。
不适合我们做的
- 需要央行等持牌资质的支付结算业务本身（我们只做系统与设备侧的支撑）
- 承诺”保证收录””保证排名第一”这类无法验证的搜索或 AI 结果保证
- 没有数据、没有明确场景，只为了”上个 AI”的项目