AI 时代应用端开发的思考

欢迎关注公众号【冬瓜白】当 AI Agent 成为你的第三个客户端后端服务的设计哲学需要一次根本性的转变。一、引言过去十年后端开发者的核心命题是如何服务好 APP 和 PC 两个端。我们围绕 RESTful API、BFF 层、微服务拆分构建了一套成熟的工程体系。但 AI 时代正在改变这个格局。随着 MCPModel Context Protocol等协议的成熟大模型不再只是聊天机器人而是可以通过标准化协议调用后端服务的Agent。这意味着后端服务多了一个全新的消费者 — 不是人类用户通过 UI 操作而是 AI 通过 Tool 调用。很多业务知识和业务功能仍然需要后端服务来承载通过 MCP 的方式对外暴露。后端不会消失反而需要重新思考如何建设。最近一段时间我一直在折腾 OpenClaw 开发也让我对AI 时代后端服务应该怎么建设有了一些感悟和思考。二、服务三端APP、PC、AI — 流量模型的本质差异2.1 AI 是一个全新的端以往我们说多端适配指的是 APP 和 PC 的 UI 差异、屏幕尺寸差异、交互模式差异。但 AI 作为第三个端差异不在 UI 层面而在流量模型层面。维度APP / PCAIAgent / 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 场景提供了更适合的数据访问模式。这种模式接近 CQRSCommand 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 拿到用户的模糊输入后有没有工具能帮它消歧如果某个参数是必填的如机构 IDAI 有没有办法从用户的自然语言中获取到如果获取不到有没有一个桥接工具帮它转换如果所有路都走不通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 和 inputSchemaJSON 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维度传统 BFFAI 能力聚合层服务对象特定 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 时代前端倒逼后端做 BFFAI 时代AI 倒逼后端做能力聚合层。未来会有越来越多的聚合服务出现 — 它们在内部编排多个服务的能力对外暴露语义化的业务能力。这不是一个新概念但 AI 给了它一个非常直接的落地场景。十、AI 接口的信息密度10.1 返回数据越多AI 越容易出错传统 API 返回一个完整的数据对象前端自己取需要的字段多余的字段不影响前端的正确性。但 AI 不一样。通俗地说返回给 AI 的无关数据越多AI 越容易被干扰。尤其当无关字段中存在名称相似但含义不同的字段时如 status vs statusCode vs statusNameAI 可能产生混淆增加理解偏差的风险。这和前面推理步骤越多出错风险越高的论点一脉相承。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 时代的后端服务建设才刚刚开始。