AI 应用开发

AI 应用开发不是在现有页面旁边放一个聊天框，也不是把提示词搬进后端。一个有实际价值的 AI 功能，应该接收真实业务输入，产出能进入下一步的结构化对象，在错误发生时可发现、可恢复，并用反馈证明它确实减少了工作。

本专题默认你要做的是能被使用和运营的应用。每篇都从工作、输入、输出、风险和验收开始，再谈模型、检索、Agent 或框架。

按要做的功能进入：MCP Server 建设 · AI 应用架构 · Agent 开发实战 · 项目教程地图。前三条都要交付可验证结果；基础原理和客户端安装放在资料库按需查阅。

1. 先选值得开发的工作

不要从“我想用 RAG / Agent / 多模态”开始。从一项当前由人完成的工作开始：

要确认的事实	合格答案示例	危险信号
谁在做	运营每天处理 80 条异常记录	“所有人可能都会用”
输入是什么	工单、订单记录、政策版本	“用户随便问点什么”
交付物是什么	带证据的异常案卷和分流结果	“一段更聪明的回答”
下一步是什么	进入人工复核队列或创建工单	输出后没有系统接收
如何发现错误	字段规则、证据引用、处理人反馈	只能凭感觉看着不错
失败代价是什么	误分流可撤回，错误付款不可接受	没有权限与责任边界

如果真实流程、责任人和验收方法都说不清，先做工作调研，不要先选模型。

2. 先看高价值应用模式

《别再做聊天框：七种高价值 AI 应用模式》给出可以直接映射到业务的产品构件：

1. 变更影响雷达；
2. 异常分流台；
3. 证据化结构抽取；
4. 案例档案生成器；
5. 决策材料编译器；
6. 受控操作编译器；
7. 代码库维护雷达。

它们的共同点是：模型只完成语义密集步骤，输出进入现有工作系统，关键结论有证据，写操作受程序和人工约束。

3. 三条可直接开工的路线

3.1 路线 A：把非结构资料变成可靠数据

适用：合同、检测报告、维修记录、投标文件、报销附件和历史表单。

按《证据化结构抽取流水线》实现解析、候选召回、字段抽取、引用对齐、业务规则和人工复核。最终产物不是摘要，而是每个字段都能回到原文的数据记录。

完成标志：关键字段证据对齐率达到 100%，解析失败不会静默产生空值，人工修订原因能回到评测集。

3.2 路线 B：把变化变成工程动作

适用：政策更新、需求变更、供应商条款、API 版本和代码改动。

按《实战：构建变更影响雷达》把新旧版本拆成原子变化，结合资产目录找到受影响的代码、配置、文档和测试，再交由负责人确认。

完成标志：报告中的每条影响都有证据、负责人和可执行检查，历史严重漏项进入固定回归集。

3.3 路线 C：让分钟级 AI 任务稳定运行

适用：批量分析、多工具调用、需要审批或可能超过一次 HTTP 请求的任务。

按《可恢复的 AI 任务执行器》实现持久化状态、检查点、幂等、预算、取消、审批与重放。先做固定工作流，再在少量节点加入 Agent 判断。

完成标志：进程随时退出也不会丢失状态或重复副作用，预算不会因并发重试被突破，人工审批绑定到不可变产物。

4. 工程底座按问题补齐

你遇到的问题	阅读	解决到什么程度
原型能跑但不能上线	生产级 AI 应用架构	网关、结构化输出、超时、降级、安全、观测
文档问答经常找错资料	RAG 检索增强工程	数据、召回、重排、权限、引用和更新闭环
改了提示或模型却不知道是否更好	AI 评测驱动开发	真实样本、切片评分、回归门禁和线上反馈
一个内部能力要被多个 AI 客户端复用	实战：把一个查询能力做成 MCP Server	工具/资源/提示词、stdio 与 HTTP 双端点、权限边界
路径必须根据中间结果动态变化	Agent 系统架构	状态机、终止条件、工具边界和恢复

技术名词不是学习顺序。遇到检索问题再读 RAG，需要动态决策再引入 Agent；不要在单次分类任务上预装全部复杂度。

5. 一条生产链路的职责边界

业务入口
  → 输入与权限校验（程序）
  → 资料选择与候选召回（程序）
  → 语义抽取 / 判断 / 生成（模型）
  → Schema 与业务规则（程序）
  → 证据呈现与人工确认（产品）
  → 幂等写入与审计（程序）
  → 反馈进入评测集（质量系统）

可记住一条边界：模型负责提出候选，程序负责守住不变量，人负责高代价判断。 身份、权限、金额、状态迁移、最终写入和审计不能只靠提示词。

6. 第一个纵向切片

第一版不要建设“统一知识库”“通用 Agent 平台”或“全公司 AI 中台”。只做一条两周内能交付的窄链路：

一个真实数据源
+ 一个语义任务
+ 一个结构化交付物
+ 一条关键校验
+ 一个现有下游入口
+ 一个反馈动作

示例：从供应商合同中抽取“自动续费”和“终止通知天数”，附原文证据；规则发现冲突时进入法务现有待办队列；审核人的接受或修改写回评测集。

7. 每次迭代都交付证据

一次改动至少记录：

• 数据集版本与真实样本数量；
• 代码、提示、模型、检索库和工作流版本；
• 总体指标与高风险切片指标；
• P50/P95 延迟、每成功任务成本；
• 人工介入、修改和驳回原因；
• 失败样本与回滚条件。

“模型看起来更聪明”不是发布依据。只有在真实任务上提高成功率、减少人工时间，且严重错误、成本和延迟仍在边界内，改动才算有效。

8. 上线前最低标准

• [ ] 有来自真实工作、经过脱敏的固定评测样本；
• [ ] 重要输出是结构化对象，并经过 Schema 与业务规则校验；
• [ ] 关键主张或字段能回到允许访问的证据；
• [ ] 外部写操作具备权限检查、幂等键、审批和审计；
• [ ] 一次任务有时间、Token、费用和工具次数上限；
• [ ] 日志能串起输入版本、检索、模型、校验、工具和结果；
• [ ] 失败可以分类、重试、降级、转人工或从检查点恢复；
• [ ] 有明确灰度范围、停止阈值和回滚路径；
• [ ] 人工反馈能进入错误分类与回归集；
• [ ] 敏感数据遵循最小化、授权和保留周期。

满足这些要求后，AI 功能才从“可以演示”进入“可以持续运营”。