AI 时代应用端开发的思考

Dongguabai

346人浏览 · 2026-03-30 20:43:11

Dongguabai · 2026-03-30 20:43:11 发布

欢迎关注公众号：【冬瓜白】

当 AI Agent 成为你的第三个"客户端"，后端服务的设计哲学需要一次根本性的转变。

一、引言

过去十年，后端开发者的核心命题是"如何服务好 APP 和 PC 两个端"。我们围绕 RESTful API、BFF 层、微服务拆分构建了一套成熟的工程体系。

但 AI 时代正在改变这个格局。

随着 MCP（Model Context Protocol）等协议的成熟，大模型不再只是"聊天机器人"，而是可以通过标准化协议调用后端服务的 Agent。这意味着后端服务多了一个全新的消费者 — 不是人类用户通过 UI 操作，而是 AI 通过 Tool 调用。

很多业务知识和业务功能，仍然需要后端服务来承载，通过 MCP 的方式对外暴露。后端不会消失，反而需要重新思考如何建设。

最近一段时间，我一直在折腾 OpenClaw 开发，也让我对"AI 时代后端服务应该怎么建设"有了一些感悟和思考。

二、服务三端：APP、PC、AI — 流量模型的本质差异

2.1 AI 是一个全新的"端"

以往我们说"多端适配"，指的是 APP 和 PC 的 UI 差异、屏幕尺寸差异、交互模式差异。但 AI 作为第三个端，差异不在 UI 层面，而在 流量模型 层面。

维度	APP / PC	AI（Agent / MCP）
流量可预测性	高，用户行为有固定路径	低，一次意图可能触发 N 次调用
调用模式	用户点击 → 单次请求	Agent 推理 → 多轮、多次、可能循环
并发特征	QPS 相对稳定，有峰谷规律	存在"扇出放大"效应，单用户可产生高并发
容错预期	用户可以重试、换个操作	AI 可能对同一个错误反复重试
SLA 要求	低延迟，用户体验敏感	分场景：后台分析类任务可接受较高延迟；但实时对话场景中，存在串行依赖的 Tool Call 延迟会叠加到用户等待时间上（无依赖的调用可并行），端到端响应时间依然敏感

这不是简单的"多一个调用方"。一个用户在 APP 上查工单，就是一次 API 调用。但同一个用户通过 AI 问"这个工单怎么样了"，AI 可能需要调用工单基础信息接口、流程进度接口、服务汇总接口，甚至在参数不确定时反复尝试 — 一次用户意图可能放大为 5-10 次甚至更多的 API 调用。

2.2 架构分层：独立 API 层，共享领域服务

基于流量模型的差异，合理的架构应该是：

APP / PC API 层  ──┐
                    ├──→  共享的领域服务层（核心业务逻辑）
AI / MCP API 层  ──┘

AI 层本质上是一个 独立的 API Gateway + 适配层，它：

对内复用已有的领域服务，不重复建设业务逻辑
对外暴露 MCP 协议兼容的 Tool 定义
独立做流控、熔断、审计、降级 — 策略与 APP/PC 端不同

AI 端需要更激进的限流和熔断策略。APP 端一个用户每分钟调 100 次接口大概率是异常，但 AI 端一个 Agent 每分钟调 100 次可能只是在处理一个复杂的分析任务。反过来，AI 陷入循环调用时，如果没有熔断机制，可能在几分钟内产生数千次无效调用，直接打垮核心服务。

核心原则：领域能力下沉复用，API 层按端的流量特征独立建设。

2.3 必要时，AI 服务需要独立存储

API 层的独立只是第一步。在实际落地中，我们发现 AI 后端服务可能还需要独立的存储服务（MySQL、ES 等）。

核心原因是：AI 端和 APP/PC 端的数据访问模式完全不同。

APP/PC 端的数据访问是围绕 UI 交互设计的 — 单条查询、分页列表、表单提交，查询模式可预测，索引可以针对性优化。

但 AI 端的数据访问是围绕"回答问题"设计的：

大范围聚合查询：用户问"湖北省本月未完结工单按品类分布"，这是一个随机的、任意维度组合的聚合请求，查询模式不可预测
全文检索 + 模糊匹配：前面提到的"岳阳安师傅"这类实体解析场景，需要模糊搜索、拼音匹配、别名匹配，对存储引擎的要求和精确查询完全不同
宽表 / 预计算视图：AI 需要"预处理好的结论"，这可能意味着需要专门的宽表或物化视图，把多个领域的数据预先聚合好，让 AI 一次查询就能拿到完整的业务视图

如果这些查询都打到 APP/PC 共用的主库上，风险很大：

AI 的大范围聚合查询可能 拖慢主库，影响 APP 端的正常业务
AI 的不可预测流量可能 打满连接池
为 AI 优化的索引（如全文索引、拼音索引）可能 影响写入性能

所以更合理的做法是：

APP / PC  →  主库（MySQL）— 针对 CRUD 优化
                ↓ 数据同步
AI / MCP  →  AI 专用存储（ES / 宽表 / 物化视图）— 针对聚合、搜索、模糊匹配优化

独立存储不是"浪费资源"，而是"隔离风险"。 它确保 AI 端的不可预测流量不会影响核心业务，同时也为 AI 场景提供了更适合的数据访问模式。这种模式接近 CQRS（Command Query Responsibility Segregation）的思路 — 读模型和写模型分离，AI 侧的读模型可以有完全不同的数据结构（宽表、物化视图、ES 索引），专门为查询和分析场景优化。当然，这个类比不完全精确：CQRS 强调的是同一业务实体的读写分离，而这里更多是不同消费者对同一数据的不同访问模式。但核心思想是一致的 — 为不同的使用场景提供不同的数据视图。

三、用户行为从有限到无限

3.1 UI 是一种"隐性约束"

这是一个容易被忽视但非常本质的变化。

传统 APP 和 PC 端，UI 本身就是对用户行为的约束。按钮就那几个，流程是固定的，表单字段是预定义的。用户只能在你设计的路径里操作。这种约束是隐性的 — 用户感知不到被限制，但开发者因此可以精确预测用户行为，进而设计出确定性的接口。

但 AI 时代，用户用自然语言表达意图，行为空间理论上是无限的。用户可以问任何问题、提任何要求、用任何表述方式。AI 端的接口设计思路必须转变 — 不是"我提供什么你用什么"，而是要考虑"用户可能想做什么"。

3.2 "聪明"在日常场景是优点，在业务场景是风险

这里有一个很容易产生的认知偏差。

日常我们使用 AI 的时候 — 写代码、查资料、做翻译 — 如果 AI 一条路走不通，自己尝试换个方式解决，我们会觉得"很聪明，很智能"。这种自主探索能力确实是 LLM 的核心优势。

但在处理真实业务的时候，同样的行为会变得很可怕、很不可控。

区别在于容错成本：

场景	AI "自己想办法"的后果	容错成本
写代码	最多编译不过，你能看到、能纠正	低
查资料	信息不准确，你能验证	低
查业务数据	可能查了错误的数据，给用户返回误导性结论	高
执行业务操作	可能调了不该调的接口，产生不可逆的业务影响	极高

更关键的是：日常场景下 AI 走偏了你能看到（代码报错、结果明显不对），但业务场景下 你可能根本不知道它走偏了 — 它返回了一个看起来合理但实际上错误的结论，用户信以为真，决策就出了问题。

所以在业务场景下，AI 的"自主探索"能力必须被严格约束。不是不让它聪明，而是只让它在你划定的范围内聪明。

3.3 无限行为空间下的范围限制

“考虑用户可能想做什么"不等于"什么都要支持”。必须有明确的能力边界。

一个真实的案例：用户问"岳阳安师傅今天进单情况？"

“岳阳安师傅"这种模糊的名称，用户因为天然带丰富的业务上下文，所以很好理解 — 可能是"岳阳安装服务部”（虚构示例）这个机构，也可能是一个姓安的师傅。但对于 AI 来说，它只能判断出"岳阳安"可能是工程师的名称，也可能是一个机构名称。而现有接口并没有提供按名称模糊搜索的能力。

于是 AI 自己想了一个"聪明"的办法：先查询一批工单，遍历每个工单对应的工程师和机构，看有没有匹配的。如果这批没找到，继续查下一批。如果还是没找到，再换个思路……

结果就是：AI 在那里生成了一大堆分析过程，反复调用接口，但始终无法返回结果。用户的感受是"AI 到底行不行，真慢啊"。

问题的根因不是 AI 笨，而是我们没有给它一条正确的路。 AI 在做一件它不该做的事 — 用猜测 + 遍历的方式去解决一个搜索问题。

正确的做法是：

服务端提供模糊搜索/实体解析接口，让 AI 能把"岳阳安"解析为具体的机构 ID 或工程师 ID
如果当前不支持，就明确告诉 AI 不支持，让 AI 直接向用户索要准确信息，而不是自己想办法

原则：为 AI 铺路，而不是让 AI 自己开路。同时，明确告诉 AI 哪些路不通。

四、确定性逻辑服务端做，AI 只做意图理解

4.1 核心论点：在业务场景中，推理步骤越多，出错风险越高

这是我在实践中最深的一个感悟。

LLM 的本质是概率模型。它擅长的是理解自然语言、推理意图、生成文本。但它 不擅长精确计算和确定性逻辑。推理链越长，整体可靠性越低 — 如果每一步推理的正确率分别是 p₁, p₂, …, pₙ，那么 n 步推理全部正确的概率是 p₁ × p₂ × … × pₙ，步骤越多，至少出一次错的概率越高。虽然 LLM 存在一定的自我纠错能力（后续步骤有时能修正前面的错误），但在业务场景中，前一步的输出往往是后一步的输入，一旦某步出错（比如参数映射错误），后续推理大概率会跟着偏离。此外，当上下文中噪声信息占比高、关键信息密度低时，AI 对关键信息的关注度也会下降。

业务规则是确定性的 — 工单是否超时、该走什么流程、赔付金额是多少，这些都有明确的计算逻辑。让概率模型去处理确定性问题，本身就是 用错了工具。

4.2 让 AI 做选择题，不做计算题

以工单场景为例：

不好的设计：

MCP Tool: 查询工单() → 返回原始数据
然后让 AI 自己判断：
  - 是否超时？（需要计算时间差）
  - 该走什么流程？（需要理解业务规则）
  - 赔付金额？（需要精确计算）

好的设计：

MCP Tool: 查询工单() → 返回预处理好的结论：
  - 工单状态：已超时（超过约定时限未完结）  ← 服务端算好的
  - 可执行操作：[催单, 转派, 升级]            ← 服务端根据规则过滤好的
  - 赔付金额：¥XXX.XX                        ← 服务端算好的

前者让 AI 做计算题，后者让 AI 做选择题。AI 只需要理解用户想知道什么，然后从服务端返回的结论中选择合适的信息呈现给用户。

4.3 原则：服务端封装确定性，AI 负责意图理解和调度编排

这个原则可以推广到所有 AI 接口的设计：

该服务端做的（确定性）	该 AI 做的（概率性）
状态判断（是否超时、是否完结）	理解用户意图（"这单怎么样了"）
规则计算（赔付金额、费用汇总）	选择调用哪个 Tool
权限过滤（用户能看什么、能操作什么）	组织语言回复用户
数据聚合（按维度统计、排名）	判断信息的详略程度
枚举映射（状态码→中文描述）	多轮对话的上下文理解

确定的事情，服务端做更好。没必要让 AI 处理得过于复杂 — 在业务场景中，推理步骤越多，出错风险越高。

五、为 AI 铺路：桥接工具与实体解析

5.1 传统端用 UI 消歧，AI 端用接口消歧

在 APP 端，用户输入模糊信息时，我们有丰富的 UI 组件来帮助消歧：

搜索框 + 下拉建议：输入关键词，弹出匹配的机构名称供选择
级联选择器：先选省份，再选城市，再选机构
表单校验：格式不对实时提示

这些 UI 组件的本质是 帮用户把模糊输入转化为精确参数。

AI 端没有 UI，但同样需要这个"模糊 → 精确"的转化过程。区别在于，这个过程必须通过接口来完成。

5.2 补全"桥接工具"

用户自然语言 → [模糊搜索/实体解析] → 结构化参数 → [业务查询] → 结果

中间的"模糊搜索/实体解析"就是桥接工具。以前面"岳阳安师傅"的案例为例，理想的桥接工具：

// MCP Tool: 模糊搜索业务实体
输入: { "keyword": "岳阳安", "types": ["engineer", "org"] }

输出: {
  "matches": [
    { "type": "org", "id": "B1001", "name": "某安装服务部", "score": 0.9 },
    { "type": "engineer", "id": "E1002", "name": "安某某", "score": 0.3 }
  ]
}

服务端做了模糊匹配、拼音匹配、别名匹配 — 这些是确定性算法，服务端做更准确。返回的 score 是基于字符串相似度算法（如编辑距离、拼音转换后匹配等）计算的分数，不是概率模型的输出。AI 可以根据分数高低判断选哪个，或者多个匹配分数接近时反问用户确认。

5.3 设计 MCP Tool 时要模拟 AI 的思考链路

在设计 MCP Tool 集合时，要站在 AI 的角度走一遍思考链路，问自己：

AI 拿到用户的模糊输入后，有没有工具能帮它消歧？
如果某个参数是必填的（如机构 ID），AI 有没有办法从用户的自然语言中获取到？
如果获取不到，有没有一个桥接工具帮它转换？
如果所有路都走不通，AI 知不知道应该直接向用户索要？

提前识别并补全桥接工具，是 AI 接口设计中最有杠杆效应的工作。 缺少桥接工具时，AI 很可能会用多次低效甚至错误的调用去弥补。

六、接口文档即 AI 的"认知"

6.1 给人看的文档 vs 给模型看的文档

传统接口文档的读者是前端开发者。他们有业务背景、有上下文、能理解隐含的约定。

但 MCP Tool Description 的读者是 LLM。它没有业务背景，只能从你写的描述中理解这个工具是什么、什么时候用、怎么用。

❌ 传统文档风格：
Tool: queryWorkOrder
Description: "查询工单接口，支持多条件筛选"
→ AI 不知道什么时候该用，不知道哪些参数组合合理

✅ 面向 AI 的描述：
Tool: queryWorkOrder
Description: "当用户想了解某个工单的详情、状态、进度时使用。
支持通过工单号(精确)或客户手机号(精确)查询。
如果用户提供的是模糊信息（如客户姓名），
请先使用 fuzzySearch 工具获取精确标识后再调用本接口。
返回结果已包含工单是否超时、可执行操作等预处理信息，无需额外计算。"

区别在于：

告诉 AI 什么场景下用 — 而不只是说"这是什么"
告诉 AI 参数怎么获取 — 尤其是参数依赖其他 Tool 的情况
告诉 AI 不需要做什么 — 减少多余推理，降低幻觉风险

6.2 仅靠 Tool Description 远远不够

在实际的 Skill 开发中，我们发现 MCP Tool Description 只是冰山一角。AI 要正确使用一个业务接口，还需要大量的补充知识：

知识类型	示例	承载方式
参数映射	"未完结"→ 对应状态编码的集合	Skill 内置映射表
业务枚举	服务方式：上门、寄修等 → 对应编码	Skill 参考文档
能力边界	不支持按工程师姓名模糊搜索	Skill 禁止行为列表
默认策略	未指定时间时默认查最近 7 天	Skill 补参规则
工具依赖	查流程节点详情前必须先查流程列表	Skill 工具配合关系
行为约束	禁止逐单调用模拟筛选	Skill 强制规则

这些知识理论上可以全部塞进 MCP Tool Description — MCP 协议的 Tool 定义支持丰富的 description 和 inputSchema（JSON Schema），你可以把枚举值、参数约束、使用说明都写在里面。但实践中我们发现，全塞进去效果反而更差：Description 过长会稀释 AI 的注意力，降低工具选择的准确率。所以需要分层承载 — 核心信息放 Tool Description（什么场景用、关键参数说明），补充知识放 Skill/Prompt 层（完整映射表、行为约束、默认策略）。

Tool Description 的质量很大程度上决定 AI 能不能找到正确的工具，Skill 层的业务知识很大程度上决定 AI 能不能正确地使用这个工具。 两者缺一不可。

6.3 一种新的技术写作能力

这意味着后端开发者需要一种新的能力：为 AI 写文档。

这不是传统的 API 文档写作，而是要站在 LLM 的"思维方式"角度，思考：

这段描述会不会让 AI 产生歧义？
AI 读完这段描述后，能不能在正确的场景下选择这个工具？
如果 AI 用错了，是不是因为我的描述有误导？

在当前阶段，Tool Description 和 Skill 的质量是 AI 应用效果的关键瓶颈之一。 写得好，AI 调用准确率大幅提升；写得差，AI 就会乱调、漏调、循环调。这项工作在技能要求上接近 Technical Writer + API Designer + Prompt Engineer 的交叉，其专业性在当前阶段容易被低估。

七、AI 接口的容错设计

7.1 传统 API 的严格校验 vs AI API 的宽容解析

传统 API 设计追求严格：参数类型不对返回 400，枚举值不在范围内返回错误码，格式不符合直接拒绝。这在 APP/PC 端没问题，因为前端会做表单校验，传过来的参数格式是确定的。

但 AI 传参可能不那么精确。它可能把日期写成"2026 年 3 月 21 日"而不是"2026-03-21"，可能把"到家服务"写成"上门"，可能把省份写成"湖北"而不是传对应的省份编码。

AI 接口需要更宽容的解析能力，在权限控制符合要求的前提下，尽可能地理解 AI 的意图。

7.2 容错的四个层次

第一层：语言归一化（AI / Skill 层做）

自然语言层面的理解和归一化，是 AI 最擅长的事：

"今天"→ “2026-03-21”，"最近一周"→ 计算出起止日期
“上门”=“到家”（多种表述指向同一服务类型）→ 识别为同一个服务方式
“湖北分公司"→ 识别为"湖北省”

这些本质上是 语义理解，AI 天然比服务端做得更好。让服务端去穷举所有自然语言表达方式反而是吃力不讨好。

第二层：意图兜底（Skill / Prompt 层做）

当用户没说清楚时，Skill 层用合理的默认值兜底，而不是反复追问：

未指定时间 → 默认最近 7 天
未指定返回条数 → 根据查询类型动态调整：聚合统计类可以不限条数（只返回聚合结果），明细列表类默认返回较小数量（如 20-50 条）并告知 AI 总数，让 AI 决定是否需要更多
“没处理的工单” → 默认映射为"未完结"大集合
“查一下这个工单” → 默认返回基础信息 + 流程进度

能默认的不问，能推断的不确认。只有真正缺少的关键信息才向用户索要。

第三层：业务编码映射 + 兜底（服务端做）

语言归一化之后，还有一步：把归一化后的业务概念映射为内部编码。比如 AI 理解了"到家"是一种服务方式，但"到家"→ 对应服务编码、"湖北"→ 对应省份编码，这些是 业务私有知识，不是通用语言知识。AI 要么靠 Skill 里写死的映射表（增加上下文长度），要么靠猜（幻觉风险）。

更合理的做法是：服务端接口直接支持接收语义化的参数值（如接受"到家"而不是只接受对应的内部编码），由服务端内部完成编码映射。这样做的好处是：

编码映射是确定性的、可测试的、不会退化的
Skill/Prompt 可能被修改，AI 的转换行为不完全可控；不同模型的转换能力也不同
即使 AI 侧已经做了编码转换，服务端也应该具备兜底的归一化能力 — 这是 纵深防御 的思路，关键路径上不应该只依赖概率性组件

第四层：错误反馈容错（服务端做，对 AI 友好）

传统 API 返回错误码，前端根据错误码展示提示语。但 AI 需要的是 能理解的错误信息，最好还能告诉它下一步该怎么做：

❌ { "code": 40001, "msg": "INVALID_PARAM" }
→ AI 不知道哪个参数错了，可能盲目重试

✅ { "code": 40001, "msg": "机构 ID 格式不正确，正确格式为字母前缀 + 数字编号（如 B1001），请向用户索要准确的机构 ID" }
→ AI 知道问题在哪，知道下一步该做什么

四层容错各司其职：AI 做语义理解，Skill 做意图兜底，服务端做编码映射和错误反馈。每一层解决不同性质的问题，合在一起降低 AI 的整体决策负担。

八、从"接口思维"到"能力思维"

8.1 传统接口思维的局限

传统后端开发是"接口思维"：一个页面需要什么数据，就提供什么接口。接口的粒度、结构、返回值都是围绕 UI 设计的。

工单详情页：
  工单基础信息接口     → 基础信息卡片
  工单商品列表接口     → 商品列表区域
  工单流程进度接口     → 流程进度条
  工单服务信息接口     → 服务信息区域

这在 APP/PC 端工作得很好。但对 AI 来说，它面对的不是"页面"，而是"问题"。用户问"这个工单怎么样了"，AI 需要的是一个完整的业务视图，而不是 4 个需要自己编排的细粒度接口。

8.2 能力思维：按业务问题组织

AI 时代的接口设计应该从"我有什么接口"转变为"我能解决什么问题"：

能力1: 查询工单全貌
  → 服务端内部编排基础信息 + 商品 + 流程 + 服务汇总
  → 一次调用返回完整业务视图

能力2: 工单报表分析
  → 服务端内部处理筛选 + 聚合 + 排序 + 分页
  → 支持按省份/机构/状态/品类等维度灵活分析

能力3: 模糊实体解析
  → 服务端内部处理模糊匹配 + 拼音匹配 + 别名匹配
  → 帮 AI 把模糊输入转化为精确参数

每个"能力"对应一个用户可能提出的业务问题，而不是一个数据库表的 CRUD 操作。

8.3 能力聚合层的出现

这自然引出了一个新的架构层次 — 能力聚合层。

传统架构：
  APP → BFF → 微服务A + 微服务B + 微服务C

AI 架构：
  AI → 能力聚合层 → 微服务A + 微服务B + 微服务C

能力聚合层的职责是：

将多个领域服务的能力编排为一个完整的业务能力
对外暴露语义化的 Tool 定义
处理参数归一化、默认值填充、结果预处理

本质上是把"编排逻辑"从 AI 侧下沉到服务端。 因为编排逻辑是确定性的 — 查工单全貌就是要基础信息 + 流程 + 商品 + 服务汇总，这个逻辑不需要 AI 来推理。这也呼应了第四章的核心原则：确定性的事情交给服务端，不要让概率性系统来处理。

8.4 能力聚合层 ≠ BFF

需要区分能力聚合层和传统 BFF：

维度	传统 BFF	AI 能力聚合层
服务对象	特定 UI 页面	业务能力 / 用户意图
粒度	按页面组件拆分	按业务问题聚合
返回值	包含 UI 相关字段（样式、跳转链接）	纯语义化的业务数据
生命周期	UI 改版就要改	业务能力不变就不变
设计驱动	前端需求驱动	业务能力驱动

AI 能力聚合层编排的是业务能力，而不是 UI 组件。它的设计质量取决于你对业务能力的梳理是否清晰。

九、AI 倒逼后端从"数据思维"转向"能力思维"

9.1 一个真实的转变

AI 作为后端服务的新消费者，迫使后端从"数据接口思维"转向"业务能力思维" — 你不能再只考虑"我有什么数据表、暴露什么 CRUD 接口"，而必须思考"我能帮用户解决什么问题"。

为了设计好 AI 能力聚合层，你必须回答：

我的业务有哪些"能力"？ — 不是有哪些接口，而是能解决哪些业务问题
每个能力的边界是什么？ — 查工单和改工单是两个能力，不是一个接口的两个方法
能力之间的依赖关系是什么？ — 查流程节点详情依赖先查流程列表，这个依赖应该在服务端内部解决（封装和信息隐藏的基本原则），而不是暴露给 AI

这些问题本身不新鲜 — 业务能力梳理、服务边界划分、依赖管理，都是架构设计的基本功。但 AI 给了一个非常直接的反馈机制：能力定义得好不好，AI 的调用准确率会立刻告诉你。 传统 APP 端，接口设计不合理，前端可以硬编码适配；AI 端没有这个缓冲，接口的语义清晰度会显著影响 AI 能不能正确使用。

需要说明的是，这种"能力视角"的转变和领域驱动设计（DDD）中"从业务领域出发组织软件"的思想方向一致，但两者并非等同关系。你可以不做 DDD，仍然设计出 AI 友好的能力聚合层；你也可以做了完整的 DDD，但如果对外暴露的 API 粒度不对，AI 照样用不好。关键不在于用什么方法论，而在于你是否真正从"用户想解决什么问题"的角度来组织后端能力。

9.2 从实践中看倒逼效应

以工单系统为例。在典型的微服务架构中，工单查询往往散落在多个微服务中，每个服务暴露自己的 CRUD 接口，前端按页面需要自行组装。

接 AI 之后，我们被迫思考：

"查工单全貌"是一个独立的业务能力，它需要编排哪些服务？
"工单报表分析"的能力边界在哪里？它能回答哪些问题，不能回答哪些？
工单状态枚举繁多，对外应该暴露原始状态码还是聚合后的业务语义（未完结/已完结/待接单）？

这些思考反过来推动了后端服务的重构 — 不是为了重构而重构，而是因为 不重构就没法给 AI 提供清晰的能力定义。

当然，这里也要务实地看 ROI：如果 AI 只是业务的辅助功能，为了它而重构整个后端未必划算。但如果 AI 是核心场景，这种倒逼效应就非常有价值。

9.3 一个有趣的类比

APP 时代，前端倒逼后端做 BFF；AI 时代，AI 倒逼后端做"能力聚合层"。

未来会有越来越多的"聚合服务"出现 — 它们在内部编排多个服务的能力，对外暴露语义化的业务能力。这不是一个新概念，但 AI 给了它一个非常直接的落地场景。

十、AI 接口的信息密度

10.1 返回数据越多，AI 越容易出错

传统 API 返回一个完整的数据对象，前端自己取需要的字段，多余的字段不影响前端的正确性。

但 AI 不一样。通俗地说，返回给 AI 的无关数据越多，AI 越容易被干扰。尤其当无关字段中存在名称相似但含义不同的字段时（如 status vs statusCode vs statusName），AI 可能产生混淆，增加理解偏差的风险。这和前面"推理步骤越多，出错风险越高"的论点一脉相承。

10.2 信息密度的设计

❌ 返回 50 个字段，AI 只需要其中 3 个
→ 47 个无关字段成为噪声，干扰 AI 的理解和推理

✅ 支持 AI 指定需要的字段，按需返回
→ AI 接收到的每条信息都是有效的，理解更准确

在实际的 Skill 开发中，我们为报表查询接口设计了"按需返回字段"的能力 — AI 可以指定只返回工单号、状态、创建时间这几个字段，而不是返回完整的上百个字段。这在传统 API 设计中不常见（通常是返回完整对象，前端自己取需要的字段），但在 AI 场景下能显著提升 AI 对返回数据的理解准确率。

10.3 通用性 vs 精准性的平衡

传统 API 设计追求 通用性 — 一个接口尽量覆盖多种场景，减少接口数量，降低维护成本。

AI API 可能需要追求 精准性 — 每个 Tool 解决一个明确的问题，返回 AI 需要的信息，不多不少。

这两个设计哲学存在张力。过于通用的接口，AI 需要从大量返回数据中提取有用信息，无关信息越多越容易被干扰；过于精准的接口，数量会膨胀，AI 选择工具的难度增加。

实践中的平衡点：按"业务能力"粒度设计 Tool，每个 Tool 内部支持参数化的灵活性。 比如"工单报表分析"是一个 Tool，但通过参数控制返回字段、聚合维度、筛选条件，兼顾了通用性和精准性。

十一、AI 时代的"前端"在哪里

11.1 AI 正在承担传统前端的角色

仔细想想，传统前端做的核心工作是什么？

前端职责	传统实现	AI 时代
理解用户意图	用户点击按钮/菜单	AI 理解自然语言
参数组装	表单收集、校验	AI 从对话中提取参数
接口编排	前端调多个接口组装数据	AI 选择并调用 Tool
结果展示	UI 渲染、数据格式化	AI 生成自然语言回复
交互引导	按钮、提示、流程引导	AI 主动追问、建议下一步

从这个角度看，AI 在信息传递和接口编排层面，承担了部分传统前端的职责。当然，前端的完整价值远不止于此 — 视觉设计、交互体验、离线能力、无障碍访问等，都不是 AI 能替代的。但在"理解用户意图 → 调用后端接口 → 组织信息返回"这条链路上，AI 确实成了用户和后端之间的新"中间层"。

11.2 协作模式的变化

这意味着后端开发者的协作对象正在扩展：

传统：后端 ↔ 前端开发 — 通过 API 文档对接，联调 UI 交互
AI 时代：后端 ↔ AI/Skill 开发 — 通过 Tool Description + Skill 规则对接，联调 AI 行为

接口评审的关注点也在变化：

传统评审：字段够不够、格式对不对、性能行不行
AI 时代评审：AI 能不能正确理解这个接口？参数映射有没有歧义？返回值对 AI 友好吗？能力边界清晰吗？

这不是说传统的评审维度不重要了，而是多了一个全新的维度。

十二、幂等性比以前更重要

12.1 AI 的重复调用风险

在 APP 端，用户点一次按钮，前端可以做防重（按钮置灰、loading 状态）。但 AI 可能因为多种原因重复调用同一个接口：

没理解返回结果，认为调用失败，重试一次
上下文窗口长度限制，早期的调用记录被截断，AI 丢失了已调用过的记忆，重新调一次
循环推理，在多轮推理中反复触发同一个 Tool
多 Agent 协作，不同 Agent 对同一个资源发起操作

同一个操作被调用多次的概率，比传统场景高得多。

12.2 只读无害，写操作必须严格幂等

对于只读查询，重复调用最多浪费资源和 Token，不会造成业务问题。但对于写操作 — 创建工单、提交审批、发起退款 — 重复调用可能导致严重的业务后果。

在 AI 场景下，写操作的幂等性设计必须更加严格：

每个写操作必须支持幂等键（idempotency key）
服务端必须能识别重复请求并返回相同结果，而不是重复执行
不能依赖调用方（AI）来控制防重 — AI 不像前端那样可以可靠地管理请求状态

十三、变更影响从确定性变成了概率性

13.1 传统开发的变更影响是可追踪的

传统开发中，改了一个接口，看看谁调了它就知道影响范围；改了一个按钮，影响的就是那个页面。代码层面有明确的调用链路，可以通过静态分析、依赖关系图来评估变更的影响面。即使评估不完全准确，至少有一个确定性的上界。

13.2 AI 应用的变更影响是概率性的

但在 AI 应用中，变更的影响变得难以预测：

Skill 改了一条规则：可能在目标场景上效果提升了，但在另一个你没想到的场景上 AI 的行为变了。LLM 对 Prompt 的响应不是确定性的，改了一句话，可能影响 AI 对所有输入的理解方式
MCP Tool Description 调了措辞：可能导致 AI 在某些边界场景下选错了工具，或者参数传错了
新增一个 Tool：可能导致 AI 在原本正确使用旧 Tool 的场景下，错误地选择了新 Tool
模型版本升级：即使 Skill 和 MCP 完全没动，换了一个模型版本，AI 的行为也可能发生变化

本质区别是：传统开发的变更影响可以通过静态分析来评估，AI 应用的变更影响主要依赖运行时测试来发现。

13.3 测试集与回归验证的必要性

这就引出了一个在传统后端开发中不太常见但在 AI 应用中至关重要的实践：标准测试集。

不是传统意义上的单元测试或集成测试，而是一套覆盖核心业务场景的 Query-Response 测试集 — 每次 Skill 变更、MCP 调整、甚至模型版本升级后，用这套测试集跑一遍，看 AI 的行为有没有回归。

测试用例示例：

输入：“湖北省上门未完结的工单有多少”

期望行为：

- 正确识别省份 → 湖北

- 正确识别状态 → 未完结

- 正确识别服务方式 → 到店

- 调用正确的 Tool

- 返回结果包含数量统计

这套测试集的价值在于：它是你最可靠的确定"改了之后没改坏"的手段。 没有它，每次 Skill 调整都是在"盲改" — 你觉得改好了，但可能在某个你没覆盖到的场景上悄悄退化了，而你根本不知道。

十四、反思：我们是否仍在用工程化思维束缚 AI？

写到这里，我想做一个诚实的自我反思。

回顾前面十二章的内容 — 内置映射表、禁止行为穷举、分阶段执行流程、纵深防御、能力边界预检 — 这些设计的底层逻辑是什么？

是我们不信任 AI。

我们在用大量确定性的工程手段去约束一个概率性的系统。这在当前阶段有其合理性 — Skill 开发中遇到的循环调用、幻觉、走偏都是真实的痛点。但我们也必须警惕：是否在不知不觉中，用工程化思维过度约束了 AI 的能力？

14.1 一个值得追问的问题

前面第七章讨论容错设计时，我们说"服务端应该做业务编码映射的兜底"。但换个角度想：如果 AI 的语义理解能力足够强，它完全可以从 Tool Description 中学会"到家"对应的内部编码。我们之所以还要在服务端做一层兜底，是因为 当前的 AI 还不够可靠，还是因为 我们的思维惯性让我们不敢放手？

当然，纵深防御的理由不仅仅是"AI 不够可靠"。更本质的原因是：即使 AI 足够聪明，概率性系统在关键路径上也需要确定性兜底 — 这是系统工程的基本原则，和信不信任 AI 无关。AI "学会"了映射关系，不等于它在每次实际调用时都能可靠地执行，注意力分散、上下文过长等因素都可能导致偶发错误。

但这个原则也有边界。不是所有路径都是"关键路径"，不是所有参数都值得做纵深防御。问题的关键在于：我们是否把太多非关键路径也当成了关键路径来保护？ 这个问题没有标准答案，但值得每个做 AI 应用的开发者持续追问。

14.2 哪些约束是必要的，哪些可能是过度设计

维度	工程化约束必要	应该更信任 AI
确定性业务规则（金额计算、权限校验）	✅ 这是确定性问题，不该让概率模型处理
语义理解（自然语言→意图、参数提取）		✅ 这是 AI 的核心能力
参数映射	高频或出错后果严重的映射应该内置	低频且出错后果可控的映射让 AI 自己处理
行为约束	✅ 关键红线（不能越权、不能写错数据）	非关键路径可以给 AI 更多自由度
输出格式	给框架和原则就够了	✅ 具体措辞、详略程度让 AI 自己判断

比如，在 Skill 中规定 AI 必须用特定的 emoji 标记每个阶段、必须按固定模板输出 — 这是在用工程化思维控制 AI 的表达方式。但 AI 完全有能力自己判断什么时候该展示推理过程、什么时候该简洁回答。过度约束不仅增加了 Skill 的维护成本，还可能限制了 AI 在某些场景下给出更好回答的可能性。

14.3 认知的三个阶段

回顾这段 Skill 开发的经历，我觉得对 AI 应用开发的认知大致会经历三个阶段：

第一阶段：天真乐观 — “把接口包一层 MCP 就完事了”。然后发现 AI 乱调接口、循环调用、返回错误结论，踩一堆坑。

第二阶段：工程化约束 — 用大量规则、映射表、禁止行为去约束 AI。效果显著提升，但 Skill 越写越长、越来越像一个"用自然语言写的程序"。本文前十二章的大部分内容，都处于这个阶段。

第三阶段：找到平衡 — 反思哪些约束是必要的（确定性逻辑、安全红线），哪些是因为不信任 AI 而过度设计的（输出格式、表达方式、长尾映射）。把该还给 AI 的还给 AI，把必须工程化保障的继续保障。

我目前大概在第二阶段向第三阶段过渡的位置。这个过渡没有捷径，必须经历第二阶段的"过度工程化"才能真正理解哪些约束是多余的 — 你得先管过了，才知道哪些不该管。

但怎么判断自己是否已经"管过了"？有几个信号值得关注：当 Skill 的维护成本开始超过它带来的准确率提升时；当你发现新增一条规则反而导致 AI 在其他场景表现变差时；当 Skill 越来越像一个"用自然语言写的 if-else 程序"时 — 这些都是过度工程化的信号，提示你该开始做减法了。

14.4 一个更长远的视角

随着模型能力的持续提升，今天我们认为"必须工程化保障"的很多事情，未来可能都可以交给 AI。比如：

今天我们需要在 Skill 里内置省份编码映射表，未来模型可能直接从 Tool Description 中学会
今天我们需要穷举"禁止行为"防止 AI 走偏，未来模型的指令遵循能力与业务理解能力共同提升后，可能只需要一句"不支持的能力直接告知用户"就够了
今天我们需要分 6 个阶段严格控制执行流程，未来模型可能自己就能规划出合理的执行路径

所以本文提出的这些设计原则，不是终态，而是当前阶段的实践尝试。好的架构应该为这种演进留出空间 — 当 AI 能力提升时，能够逐步放松约束，而不是被自己设计的工程化框架锁死。

十五、总结

AI 不是替代后端，而是对后端提出了更高的要求。

回顾全文，核心原则可以归纳为：

确定性下沉：确定性逻辑服务端做，AI 只做意图理解和调度编排。在业务场景中，推理步骤越多，出错风险越高，让 AI 做选择题而不是计算题。
能力聚合：从"接口思维"转向"能力思维"，按业务问题而非 CRUD 操作组织服务。能力聚合层的出现是必然趋势。
为 AI 铺路：补全桥接工具，消除断头路。传统端用 UI 组件帮用户消歧，AI 端用实体解析接口帮 AI 消歧。
降低 AI 决策负担：四层容错各司其职 — AI 做语言归一化，Skill 做意图兜底，服务端做业务编码映射和错误反馈。每一层解决不同性质的问题，合在一起让 AI 的每一步都尽可能简单。
知识外化：接口文档不再只是给人看的技术文档，而是 AI 的"认知基础"。Tool Description + Skill 层的业务知识补充，共同构成 AI 理解和使用服务的能力。
保持谦逊：承认我们当前的设计可能带有过度工程化的倾向。好的架构应该为 AI 能力的提升留出空间，能够逐步放松约束，把该还给 AI 的还给 AI。

后端开发者需要新增一项核心能力：设计 AI 能理解、能正确使用的业务能力。这要求我们重新审视领域建模、接口设计、文档写作、容错策略等每一个环节 — 同时也要警惕自己是否在用旧的思维方式解决新的问题。

AI 时代的后端服务建设，才刚刚开始。