AI-04 融入业务：智能生成、分类与推荐

不做孤立的“AI 页面”，让模型在正确的位置辅助用户完成任务

AI 特色功能的价值，来自它改善了哪一步业务

接通模型 API、实现流式输出或建立知识库，只说明项目具备了 AI 技术能力。用户真正关心的是：填写内容是否更省事、信息能否更快归类、面对大量选择时能否得到有依据的建议。

本节介绍三种常见业务模式：智能文本生成、智能分类和智能推荐。它们可以共用前面完成的模型客户端，但业务目标、风险和评价方法不同。学生只需选择一种与项目最相关的模式，完成一个小而稳定的功能闭环。

本节学习目标

从真实业务问题中选择合适的 AI 模式，设计模型输入、结构化输出、人工确认和规则兜底，将 AI 结果接入现有页面与 Service，并分别使用内容检查、分类指标和推荐反馈验证效果。

返回上一节：构建 RAG 知识库 返回扩展篇导读 进入下一节：Tool Calling、MCP 与智能体

---

🎯 本节完成后，你要交付

成果	要求
AI 业务功能任务卡	明确用户、业务步骤、输入、输出、风险和预期价值
一种可运行 AI 功能	在生成、分类、推荐中选择一种，接入真实业务页面
业务规则与模型边界	说明哪些由代码决定，哪些由模型建议，谁最终确认
结构化输出处理	后端校验模型结果，不直接信任返回文本
失败与降级方案	AI 不可用或结果无效时，原有业务仍能继续
效果评测记录	使用固定数据对效果、风险、耗时和成本进行验证
演示材料	展示正常结果、人工修改和失败降级各一个案例

本节不是要求同时完成三类功能

文本生成、分类和推荐各自都可以成为一个完整特色功能。课程项目优先选择一个最贴近业务、能够测试和稳定演示的方向。

---

一、从业务问题选择 AI 模式

1. 三种模式分别解决什么问题

模式	典型问题	模型输出	用户角色
智能生成	用户不知道怎样组织文字	草稿、摘要、说明或通知	编辑和确认
智能分类	信息量大，人工归类重复	标签、类别和理由	确认或纠正
智能推荐	选项很多，用户难以筛选	候选项排序和推荐理由	自主选择

2. 选择判断

用户需要创建或改写一段内容？
→ 选择智能生成

系统需要把已有内容放入预先定义的类别？
→ 选择智能分类

系统需要从已有候选项中找出更适合用户的内容？
→ 选择智能推荐

如果问题可以由确定规则稳定解决，应优先使用规则。

问题	更合适的方式
报修描述表达不完整	AI 生成草稿
标题中包含“停电”就进入电力类	关键词规则
描述复杂，需要在多个相近类别中判断	AI 分类建议
按发布时间倒序展示活动	SQL 排序
根据兴趣、时间和报名条件选择活动	规则筛选 + AI 推荐理由
查询当前用户订单状态	业务数据库查询

3. 不要从技术名称出发

错误思路：

我要使用大模型，所以给项目增加一个聊天框。

推荐思路：

用户发布二手商品时经常漏写成色、使用时间和交付方式
→ 根据表单要点生成可编辑商品描述
→ 用户确认后发布
→ 检查信息完整度和修改率

---

二、设计 AI 与业务规则的边界

1. 三层职责

确定性业务规则
→ 决定权限、状态、金额、库存和数据归属

AI 模型
→ 生成语言草稿、提出分类建议、解释推荐原因

用户或管理员
→ 核对不确定结果，并作出最终业务决定

2. AI 不应直接决定的内容

• 是否授予管理员权限；
• 是否通过退款、处罚或资助申请；
• 订单金额、账户余额和库存变化；
• 用户是否有权查看或修改数据；
• 医疗、法律或财务高风险结论；
• 重要记录的最终删除；
• 无法人工复核的自动外部操作。

这些结果必须由后端规则、正式流程或授权人员决定。

3. 自动化等级

等级	AI 作用	示例	建议
L0	不使用 AI	用户手工填写	基础流程必须保留
L1	提供草稿或建议	生成商品描述	用户确认
L2	自动填入但允许修改	建议报修类别	明确标记来源
L3	低风险自动处理并抽查	公开内容添加辅助标签	记录结果，可回退
L4	直接执行高风险决定	自动审批退款	不适合作为课程初次实践

课程项目推荐从 L1 或 L2 开始。

---

三、填写 AI 业务功能任务卡

项目	内容
功能名称	【填写】
AI 模式	【生成 / 分类 / 推荐】
目标用户	【填写】
当前困难	【哪一步重复、困难或选择过多】
使用位置	【现有业务流程中的页面和步骤】
模型输入	【用户输入和允许使用的业务数据】
模型输出	【草稿、类别或推荐列表】
确定规则	【必须由代码执行的限制】
人工确认	【谁确认、怎样修改或拒绝】
失败降级	【AI 不可用时怎样继续】
成功指标	【怎样判断确实改善业务】
明确不做	【本次范围之外的能力】

示例：宿舍报修智能分类

目标用户：提交报修的学生和维修管理员
当前困难：用户不清楚分类，错选后需要管理员重新分派
使用位置：用户填写故障描述后、正式提交前
模型输入：故障描述和系统允许的类别列表
模型输出：建议类别、简短理由、是否需要人工确认
确定规则：类别必须来自数据库中的启用类别；紧急程度由正式规则判断
人工确认：用户可以修改；低置信或无法判断时不自动选中
失败降级：显示原有类别下拉框，由用户手工选择
成功指标：固定测试集分类正确率、人工修改率、错误分派数量
明确不做：不自动派单、不自动修改维修优先级

---

四、模式一：智能文本生成

1. 适合的业务场景

• 根据表单要点生成商品描述；
• 根据活动信息生成通知草稿；
• 根据处理记录生成工作摘要；
• 将口语化报修描述整理为规范文字；
• 根据项目数据生成阶段报告初稿；
• 根据已有内容生成不同长度的摘要。

2. 文本生成的完整闭环

用户填写结构化要点
→ 后端校验必要字段
→ 组合受控提示词
→ 模型生成草稿
→ 后端检查长度和格式
→ 页面显示“AI 草稿”
→ 用户编辑和确认
→ 调用原有业务接口保存

模型生成接口与正式保存接口应分开：

POST /api/ai/product-description
→ 只生成草稿，不写数据库

POST /api/products
→ 用户确认后，按原有规则创建商品

3. 输入应优先使用结构化字段

相比把整个页面和数据库记录都交给模型，优先只发送必要字段：

public record ProductDescriptionRequest(
        String name,
        String condition,
        String usedDuration,
        String features,
        String deliveryMethod
) {
}

模型不需要接收：

• 用户密码、Token 和手机号；
• 商品表全部内部字段；
• 其他用户的信息；
• 管理员备注；
• 数据库连接和服务器配置。

4. 提示词示例

你是校园二手商品描述助手。

任务：
根据用户提供的商品要点，生成 100—180 字的中文描述草稿。

要求：
1. 只使用用户提供的信息；
2. 不虚构品牌、购买价格、质量保证或使用效果；
3. 明确描述商品成色和交付方式；
4. 不生成联系方式；
5. 不使用夸大宣传；
6. 只输出描述正文。

商品要点：
名称：台灯
成色：八成新
使用时间：一年
特点：三档亮度，可折叠
交付方式：校内当面交付

5. 后端校验输出

public String validateGeneratedDraft(String draft) {
    if (draft == null || draft.isBlank()) {
        throw new BusinessException(503, "AI 未生成有效内容");
    }

    String result = draft.trim();
    if (result.length() > 500) {
        throw new BusinessException(503, "AI 生成内容过长，请重试");
    }

    return result;
}

长度检查只能过滤明显异常，不能判断事实是否正确。最终仍需用户核对。

6. 生成结果怎样评价

维度	检查问题
忠实	是否只使用输入中存在的事实
完整	是否保留必要要点
清晰	用户是否容易理解
合规	是否包含隐私、攻击性或夸大内容
可编辑	用户是否可以修改或放弃
有价值	相比手工填写是否节省时间或提高完整度

可以记录用户修改率：

直接采用
轻微修改后采用
大幅修改后采用
放弃生成结果

修改率不是越低越好，也不能单独代表质量。它需要结合任务难度和用户反馈解释。

---

五、模式二：智能分类

1. 分类任务必须有明确标签

模型不能自由创造业务类别。后端应从数据库读取当前允许的标签：

可选类别：
- WATER：水电问题
- ELECTRIC：用电问题
- FURNITURE：家具问题
- NETWORK：网络问题
- OTHER：其他问题

模型输出只能从这些代码中选择。

2. 结构化输出

推荐模型返回：

{
  "categoryCode": "ELECTRIC",
  "reason": "描述中提到插座无电，属于用电问题",
  "needsReview": false
}

不要要求模型返回一个难以稳定解析的自然语言段落：

我觉得这大概属于电器一类，可能也需要宿管看看。

3. 定义项目自己的结果对象

public record ClassificationResult(
        String categoryCode,
        String reason,
        boolean needsReview
) {
}

4. 后端必须再次校验

public ClassificationResult validateResult(
        ClassificationResult result,
        Set<String> allowedCodes
) {
    if (result == null
            || result.categoryCode() == null
            || !allowedCodes.contains(result.categoryCode())) {
        return new ClassificationResult(
                null,
                "无法确定有效类别，请人工选择",
                true
        );
    }

    String reason = result.reason() == null
            ? ""
            : result.reason().trim();

    if (reason.length() > 200) {
        reason = reason.substring(0, 200);
    }

    return new ClassificationResult(
            result.categoryCode(),
            reason,
            result.needsReview()
    );
}

即使提示词要求“只能选择给定标签”，模型仍可能输出不存在的值。后端枚举或数据库校验才是真正的业务边界。

5. 分类 Service 流程

读取启用类别
→ 校验用户描述
→ 将类别代码、名称和说明交给模型
→ 要求返回 JSON
→ 解析 JSON
→ 校验类别是否存在
→ 判断是否需要人工复核
→ 返回建议，不直接提交业务

模型返回 JSON 时仍可能出现：

• Markdown 代码围栏；
• 字段缺失；
• 类型错误；
• 额外说明；
• 无效类别；
• 截断的 JSON。

解析失败时应进入人工选择，不应继续猜测。

6. 规则与模型混合

确定性强的规则可以先处理：

描述包含“漏电”“冒烟”“火花”
→ 标记需要立即人工确认
→ 不由普通分类结果降低优先级

其他描述
→ 交给模型建议类别

模型适合处理语言表达，正式的紧急规则仍由代码执行。

7. 分类效果怎样评测

先准备人工标注的数据：

编号	故障描述	正确类别
C01	宿舍水龙头关不严，一直滴水	WATER
C02	书桌旁插座没有电	ELECTRIC
C03	衣柜门脱落	FURNITURE
C04	校园网能连接但无法访问网页	NETWORK

至少记录：

• 总测试数量；
• 正确数量；
• 各类别正确数量；
• 哪些类别容易混淆；
• 解析失败数量；
• 需要人工复核数量；
• 与原有规则或人工方式的差异。

基础正确率：

正确率 = 正确分类数量 / 总测试数量

数据类别严重不均衡时，只看总正确率可能产生误导。例如 90% 数据都属于 OTHER，始终预测 OTHER 也可能得到很高数值。应同时查看每个类别的表现。

8. 混淆记录

真实类别	预测类别	次数	可能原因	改进
WATER	OTHER	3	描述过短	引导用户填写故障现象
ELECTRIC	FURNITURE	2	“台灯坏了”含义不清	增加人工确认

改进顺序建议：

1. 检查标签定义是否重叠；
2. 检查输入是否包含足够信息；
3. 增加每个标签的说明和示例；
4. 调整提示词；
5. 再考虑更换模型。

---

六、模式三：智能推荐

1. 推荐不是让模型凭空列出内容

错误做法：

请推荐五个适合我的校园活动。

模型可能生成数据库中不存在的活动。

推荐必须从真实候选项中选择：

数据库查询当前可报名活动
→ 业务规则过滤过期、满员和无权限活动
→ 根据用户允许使用的偏好排序
→ AI 从候选项中解释或辅助排序
→ 页面展示真实活动 ID

2. 推荐的四个阶段

阶段	主要方式	示例
候选获取	数据库查询	查询仍可报名的活动
硬规则过滤	后端代码	排除满员、冲突和无权限活动
排序	规则、相似度或模型	兴趣和时间匹配
解释	模型生成	“与你关注的编程主题一致”

大模型不应绕过前两步。

3. 推荐输入

只使用经过授权且与任务相关的数据：

public record RecommendationContext(
        List<String> selectedInterests,
        List<String> availableTimeSlots,
        String preferredLocation
) {
}

不要未经说明使用：

• 私人聊天记录；
• 精确位置历史；
• 与推荐无关的个人资料；
• 其他平台抓取的数据；
• 用户已经拒绝使用的数据。

4. 候选项必须带稳定 ID

public record ActivityCandidate(
        Long id,
        String title,
        List<String> tags,
        String timeSlot,
        String location,
        int remainingPlaces
) {
}

模型返回：

{
  "items": [
    {
      "id": 105,
      "reason": "主题与你选择的编程兴趣一致，时间也可参加"
    },
    {
      "id": 87,
      "reason": "地点较近，并且仍有剩余名额"
    }
  ]
}

后端只接受候选列表中真实存在的 ID。

5. 校验推荐结果

public List<RecommendedItem> validateRecommendations(
        List<RecommendedItem> items,
        Map<Long, ActivityCandidate> candidates
) {
    if (items == null) {
        return List.of();
    }

    return items.stream()
            .filter(item -> item.id() != null)
            .filter(item -> candidates.containsKey(item.id()))
            .distinct()
            .limit(5)
            .toList();
}

实际去重应按 id 执行；示例中的 distinct() 依赖 RecommendedItem 的相等性定义。更稳妥的实现可以使用 LinkedHashMap<Long, RecommendedItem> 保持顺序并按 ID 去重。

6. 一个更稳定的混合推荐

第一版可以让代码负责排序，让模型只生成理由：

规则计算：
- 兴趣标签相同 +3
- 时间可参加 +2
- 地点偏好相同 +1
- 已满员直接排除

按分数取前 5 项
→ 模型根据真实字段生成简短推荐理由

优点：

• 排序可解释、可复现；
• 模型不可用时仍能返回推荐列表；
• 模型不会创造不存在的候选项；
• 测试更容易；
• 成本和响应时间更可控。

7. 冷启动

新用户没有历史数据时，可以：

• 让用户主动选择兴趣；
• 展示热门或近期内容；
• 根据当前页面上下文推荐；
• 允许“不使用个性化推荐”；
• 不通过猜测隐私属性建立画像。

8. 推荐效果怎样评测

课程项目不必搭建复杂推荐实验平台，可以记录：

指标	说明
有效候选率	推荐项是否都真实存在且当前可用
点击率	用户是否点击推荐项
采纳率	用户是否报名、收藏或选择
无效推荐数	已满员、过期、无权限或不存在的项目
多样性	是否总是推荐同一类内容
用户反馈	推荐理由是否有帮助
降级可用性	模型失败时规则推荐是否正常

点击率和采纳率受到页面位置、标题和活动本身影响，不能单独证明模型质量。

---

七、统一设计结构化输出

生成长文本时可以返回字符串，分类和推荐更适合结构化 JSON。

1. 为什么需要结构化输出

后端需要明确知道：

• 类别代码是什么；
• 推荐对象 ID 是什么；
• 是否需要人工复核；
• 推荐理由对应哪个对象；
• 哪些字段可以进入后续业务。

自然语言很难可靠解析。

2. 提示词中给出严格格式

只返回一个 JSON 对象，不要添加 Markdown 代码围栏或解释。

格式：
{
  "categoryCode": "必须来自允许列表",
  "reason": "不超过80字",
  "needsReview": true
}

3. 后端处理顺序

接收模型原始文本
→ 去除允许处理的外层空白
→ 使用 Jackson 解析 DTO
→ 校验必填字段和类型
→ 校验枚举或候选 ID
→ 校验长度和数量
→ 不满足要求则人工处理或降级

不要使用字符串截取寻找关键字段，也不要使用 eval 执行模型输出。

4. 结构化不等于可信

即使 JSON 格式完全正确，也可能包含：

{
  "categoryCode": "NOT_EXISTS",
  "reason": "模型自行创建了这个类别",
  "needsReview": false
}

格式校验通过后，仍需业务校验。

---

八、将 AI 功能接入现有模块

1. 推荐的模块边界

现有业务页面
→ AI 辅助接口
→ AiFeatureService
→ LlmClient

用户确认
→ 原有业务接口
→ 原有 BusinessService
→ 数据库

AI 辅助接口不直接替代正式业务接口。

2. 接口示例

功能	AI 辅助接口	正式业务接口
商品描述	POST /api/ai/product-description	POST /api/products
报修分类	POST /api/ai/repair-category	POST /api/repairs
活动推荐	POST /api/ai/activity-recommendations	POST /api/registrations

3. 权限仍由原业务判断

• AI 可以建议类别，但不能授予操作权限；
• AI 可以推荐活动，但报名接口仍检查名额和时间；
• AI 可以生成商品描述，但发布接口仍检查字段和用户身份；
• AI 生成成功不代表正式业务一定提交成功；
• 正式业务数据以提交时的最新状态为准。

4. 防止状态过期

推荐时活动有名额，不代表用户点击报名时仍有名额。正式提交必须重新查询：

推荐结果显示“剩余 1 个名额”
→ 其他用户先完成报名
→ 当前用户点击报名
→ 后端重新检查名额
→ 返回已满员

不能因为 AI 推荐过就跳过并发和状态校验。

---

九、设计人工确认与反馈

1. 不同功能的确认方式

功能	确认方式
文本生成	用户编辑后主动保存
智能分类	用户选择接受或改成其他类别
智能推荐	用户自主点击，不自动替用户报名

2. 页面标识

推荐使用：

AI 生成草稿，请核对后提交

建议分类：用电问题
原因：描述中提到插座无电
[采用建议] [选择其他类别]

为你推荐
推荐理由由 AI 辅助生成，实际名额以报名时为准

不要把建议显示为确定结论：

系统已经判定：必须选择用电问题。

3. 收集有用反馈

可以记录：

• 是否采用生成草稿；
• 是否修改建议类别；
• 是否点击推荐；
• 用户选择的正确类别；
• 用户主动给出的“有帮助 / 没帮助”；
• 失败类型和人工处理结果。

不应为了评测偷偷记录与功能无关的个人数据。

4. 反馈不能直接成为真相

用户修改结果可能因为个人偏好，也可能是误操作。反馈数据进入后续优化前，需要：

• 去除重复和异常记录；
• 保护用户隐私；
• 由业务人员抽样确认；
• 说明数据用途；
• 避免把攻击性输入重新用于提示词。

---

十、失败、降级与成本控制

1. 每种模式的降级

模式	AI 成功	AI 失败
文本生成	返回可编辑草稿	用户手工填写
智能分类	返回建议类别	显示原有类别选择
智能推荐	返回排序或理由	使用热门、最新或规则推荐

2. 不保存半成品

以下情况不应自动写入正式业务：

• 模型响应超时；
• JSON 解析失败；
• 类别代码无效；
• 推荐 ID 不在候选集合；
• 输出被截断；
• 用户尚未确认；
• 页面连接中断。

3. 降低调用量

• 用户点击后再调用，不随每次输入自动调用；
• 输入未变化时避免重复生成；
• 规则能完成的步骤不用模型；
• 推荐理由可以按候选结果缓存；
• 限制输入、输出、候选数量和调用频率；
• 测试使用模拟客户端；
• 记录每类功能的调用次数、耗时和失败率；
• 设置平台预算或额度提醒。

4. 缓存注意事项

缓存前先确认：

• 输入是否包含个人数据；
• 不同用户是否允许共享结果；
• 候选项是否可能过期；
• 资料或业务状态更新后怎样失效；
• 缓存键是否包含必要版本。

不能把 A 用户的个性化结果错误返回给 B 用户。

---

十一、测试三类 AI 业务功能

1. 通用测试

编号	场景	预期
COMMON-01	正常输入	返回符合当前模式的有效结果
COMMON-02	缺少必填项	后端拒绝，不调用模型
COMMON-03	超长输入	返回明确提示
COMMON-04	模型超时	进入降级，不阻断业务
COMMON-05	返回空内容	不作为成功结果
COMMON-06	返回格式错误	解析失败并人工处理
COMMON-07	恶意指令	不泄露数据，不执行操作
COMMON-08	重复点击	不产生失控的并发调用
COMMON-09	未登录或无权限	后端拒绝访问
COMMON-10	用户放弃结果	不写入正式业务

2. 文本生成专项测试

• 是否保留所有必要要点；
• 是否添加不存在的事实；
• 是否出现隐私、攻击或夸大表述；
• 是否超过长度；
• 用户修改后保存的是否是修改版本；
• 重新生成是否覆盖未经确认的重要内容。

3. 分类专项测试

• 所有返回类别是否来自允许列表；
• 各类别是否都有测试样例；
• 相近类别是否容易混淆；
• 信息不足时是否进入人工复核；
• 紧急规则是否始终优先；
• 模型配置变化后正确率是否下降。

4. 推荐专项测试

• 推荐 ID 是否都来自真实候选项；
• 过期、满员和无权限项目是否已经过滤；
• 是否出现重复推荐；
• 推荐理由是否与真实字段一致；
• 新用户能否得到合理的非个性化结果；
• 模型失败时规则推荐是否正常；
• 正式操作是否重新校验最新业务状态。

5. 建立基线

AI 功能需要和一个简单方案比较：

功能	基线方案
文本生成	用户完全手工填写
分类	关键词规则或人工选择
推荐	最新、热门或固定规则排序

比较内容可以包括：

• 完成时间；
• 正确率或有效率；
• 用户修改次数；
• 错误数量；
• 调用成本；
• 失败后是否可继续。

只有比基线更有价值，AI 功能才值得保留。

---

十二、效果评测记录模板

# AI 业务功能评测记录

## 1. 基本信息

| 项目 | 内容 |
| :--- | :--- |
| 功能名称 | 【填写】 |
| AI 模式 | 【生成 / 分类 / 推荐】 |
| 模型与配置 | 【填写，不记录密钥】 |
| 测试版本 | 【填写】 |
| 测试时间 | 【填写】 |

## 2. 业务边界

- 模型负责：【填写】
- 后端规则负责：【填写】
- 人工确认方式：【填写】
- 失败降级方式：【填写】

## 3. 固定测试结果

| 编号 | 输入或场景 | 预期 | 实际 | 是否通过 | 说明 |
| :--- | :--- | :--- | :--- | :---: | :--- |
| T01 | 【填写】 | 【填写】 | 【填写】 | 是/否 | 【填写】 |

## 4. 与基线比较

| 指标 | 基线 | AI 功能 | 结论 |
| :--- | :--- | :--- | :--- |
| 【填写】 | 【填写】 | 【填写】 | 【填写】 |

## 5. 失败案例

- 失败现象：【填写】
- 可能原因：【填写】
- 用户影响：【填写】
- 修复或降级：【填写】
- 回归结果：【填写】

## 6. 是否保留

- [ ] 保留为正式功能
- [ ] 保留为实验功能
- [ ] 暂时下线

理由：【填写】

---

十三、🤖 让 AI 帮你设计业务功能

请先阅读当前项目的：
1. 需求说明书和核心业务流程；
2. 目标页面、业务 Service、权限和状态规则；
3. 已有 LlmClient、异常处理和配置；
4. 与本功能相关的真实类别、候选项或表单字段；
5. 测试报告和部署限制。

我要在【业务步骤】增加一个【生成 / 分类 / 推荐】功能。

请先回答：
- 用户当前有什么具体困难？
- 普通规则是否已经足够？
- 模型输入最少需要哪些字段？
- 哪些数据不能发送？
- 输出应是草稿、建议还是候选排序？
- 哪些规则必须由后端决定？
- 谁进行最终确认？
- 模型失败时原业务怎样继续？
- 用什么固定数据和基线评价？

实现要求：
1. 页面只调用项目后端；
2. 不新增第二套登录和权限；
3. 分类只能返回已有类别；
4. 推荐只能返回真实候选 ID；
5. 结构化结果必须经过 Jackson 和业务校验；
6. AI 结果不直接执行高风险操作；
7. 不虚构模型平台接口和字段；
8. 先给最小改动计划，再分步实现和验证。

人工必须核对：

• 功能是否真的改善业务，而不是装饰；
• 是否可以用更简单的规则完成；
• 输入数据是否必要且获得授权；
• 结构化结果是否经过业务校验；
• 人工确认是否真实存在；
• 测试集是否包含失败和边界样例；
• AI 不可用时基础流程是否正常；
• 是否有可解释的基线比较。

---

十四、常见问题与修正方法

常见问题	后果	修正方法
三种功能全部一起做	范围失控、无法充分测试	只选择一种完成闭环
增加孤立聊天窗口	与业务无关	放到用户真正需要帮助的步骤
AI 直接保存正式数据	错误内容进入业务	返回草稿或建议，用户确认后提交
模型自由创造类别	数据无法统计和流转	后端提供允许列表并再次校验
模型自由推荐对象	出现不存在或不可用内容	从真实候选集合选择稳定 ID
用提示词替代权限	产生越权风险	权限始终由后端执行
JSON 能解析就直接使用	无效代码或 ID 进入业务	继续执行枚举、候选和状态校验
推荐绕过硬规则	推荐满员或无权限项目	先由代码过滤，再排序和解释
只记录成功截图	无法判断真实效果	使用固定测试集和基线
只看总分类正确率	忽略少数类别失败	查看各类别和混淆情况
模型失败后页面不能操作	AI 阻断核心业务	保留手工输入、选择和规则推荐
未经同意使用个人数据	隐私和信任风险	最少数据、明确用途、允许关闭

---

十五、提交前自查

业务设计

• 只选择一种主要 AI 模式；
• 功能对应一个明确用户问题；
• 已比较普通规则或人工基线；
• 功能位于现有业务流程的正确步骤；
• AI 结果不会直接执行高风险操作；
• 明确模型、后端规则和用户各自职责。

数据与输出

• 只发送完成任务所需的数据；
• 未经授权的隐私数据不会进入模型；
• 分类标签来自系统允许列表；
• 推荐对象来自真实候选集合；
• 结构化输出经过解析和业务校验；
• 文本草稿可编辑、放弃和重新生成。

稳定性与效果

• 模型失败时原有业务仍能继续；
• 已限制输入、输出、候选数量和调用频率；
• 正式提交时重新检查最新业务状态；
• 已完成正常、异常、边界和恶意输入测试；
• 已使用固定数据与基线比较；
• 已记录失败案例、人工修改和降级结果；
• 演示包含正常、修改和失败降级。

---

本节小结

AI 融入业务的关键不是模型调用次数，而是职责分工和可验证价值：

真实业务困难 → 选择生成、分类或推荐 → 后端确定规则 → 模型提供草稿或建议 → 结构化校验 → 人工确认 → 失败降级 → 与基线比较

完成本节后，你已经能够把模型能力放进具体业务，同时不让不确定输出破坏权限、状态和数据。下一节将认识 Tool Calling、MCP 与智能体，理解模型怎样在受控条件下选择和调用工具。

进入下一节：AI-05 Tool Calling、MCP 与智能体 返回上一节：AI-03 构建 RAG 知识库 返回扩展篇导读