企业官网建设流程全解析

1. “装了十几个 Skill 还是不好用”——这不是你操作的问题，是能力建模的错位

我去年帮三个团队做过 AI 工具链落地咨询，其中一家做跨境电商的公司，技术负责人拉着我看了他们内部知识库页面：整整一页密密麻麻的 Skill 列表——“商品标题优化”“竞品价格比对”“物流时效预测”“多语言客服话术生成”……加起来二十三个。他点开一个叫“自动回复差评”的 Skill，输入一条真实差评：“发货慢、包装破、客服不回”，系统返回：“感谢您的反馈，我们将持续优化服务体验。”——和没答一样。

他苦笑说：“我们不是没下功夫，每个 Skill 都配了 prompt、调了 temperature、接了 RAG，连 embedding 模型都换过两轮。”
我说：“你装的是功能按钮，但 AI 真正执行时靠的是‘能力’。而你现在这二十三个 Skill，绝大多数根本没在同一个能力维度上对齐。”

这就是标题里说的“能力缺口”——它不是指模型不会写文案、不会算价格、不会查物流，而是指：当用户提出一个真实业务请求时，AI 缺乏将该请求精准映射到自身可调度能力集合中的认知路径。就像给一个刚学会 20 个单词的英语初学者，扔过去一本《金融衍生品定价手册》，问题不在书不好，也不在他不肯学，而在于他根本不知道“volatility”这个词该对应到自己脑中哪个语义槽位、哪个推理链条、哪组记忆锚点。

这个缺口，藏在三个地方：

• 语义粒度错配：用户说“帮我处理这条差评”，背后隐含“情绪识别→归因分析→责任归属→补偿策略→话术生成→合规校验”六步能力链，但你只部署了一个“话术生成”Skill；
• 上下文承载断裂：用户前一句问“上周退货率最高的 SKU 是哪个”，后一句说“针对它做一份改进方案”，两个请求之间需要跨会话维持状态、共享数据视图、继承推理上下文，而多数 Skill 是无状态、单次调用的孤岛；
• 能力边界模糊：你标着“支持售后决策”，但没定义清楚——是仅输出建议？还是能调用 ERP 修改工单状态？或是能触发邮件模板并抄送主管？没有明确定义的能力契约，就等于没有能力。

提示：别再用“这个 Skill 能不能做 XX”来评估能力，改用“当用户发出 XX 请求时，AI 是否具备从理解→拆解→调度→执行→验证的完整闭环能力”。前者是功能清单思维，后者才是能力建模思维。

我见过太多团队把 Skill 当成 App 图标往界面上堆——图标越多，体验越碎。真正稳的系统，往往只有 3～5 个 Skill，但每个都覆盖了从意图识别到结果交付的全能力链。后面我会用一个真实案例，带你一帧一帧拆解：怎么把“处理差评”这个模糊需求，变成可测量、可调度、可验证的 AI 能力单元。

2. 能力缺口的本质：AI 不是工具箱，是“能力操作系统”

很多人以为 Skill 就像手机 App：微信用来聊天，高德用来导航，抖音用来刷视频——各司其职，装得越多，功能越全。但 AI 的 Skill 完全不是这么工作的。它没有独立进程、没有内存隔离、没有权限沙箱。所有 Skill 共享同一个底层模型、同一套 token 缓存、同一组 attention 权重。它们不是并行运行的程序，而是在同一片神经网络里被动态激活的不同子图。

这就引出一个关键事实：Skill 的数量 ≠ 能力的广度，Skill 的耦合深度才决定能力的真实覆盖半径。

举个例子：

• Skill A：接收用户输入，提取情绪关键词（如“愤怒”“失望”“怀疑”）；
• Skill B：根据关键词匹配预设话术模板；
• Skill C：调用数据库查该用户历史订单数、退款次数、VIP 等级；
• Skill D：基于前三者输出最终回复。

如果这四个 Skill 是彼此割裂、各自调用的，那每次执行都要重新加载上下文、重复解析原始文本、多次触发模型 infer，响应延迟翻倍，错误率叠加——更致命的是，一旦用户中途插入一句“等等，其实我买的是赠品”，整个链路就断了，因为 Skill C 和 D 根本没设计“中断重置+上下文回滚”机制。

而真正健壮的“差评处理能力”，应该是一个原子化能力单元（Atomic Capability Unit, ACU）：它有明确的输入契约（必须包含原始差评文本 + 用户 ID）、明确的输出契约（结构化 JSON：{“emotion”: “anger”, “root_cause”: “logistics_delay”, “compensation_suggestion”: “5元券”, “response_text”: “…”}）、明确的状态管理（支持 pause/resume/cancel）、明确的失败降级路径（如数据库不可用时，自动 fallback 到规则引擎兜底）。

ACU 不是代码模块，而是能力契约。它回答三个问题：

1. 我能做什么？（不是“能生成文字”，而是“能在 3 秒内，基于用户历史与当前差评，生成符合公司 SOP 的、带补偿建议的客服回复”）；
2. 我依赖什么？（必须接入 CRM 接口、必须读取 last_7d_order_summary 表、必须调用 sentiment_v3 模型）；
3. 我失败时怎么办？（若 sentiment_v3 返回置信度 <0.6，则启动人工审核队列，并标记为 high_risk_case）。

我们团队曾用这套 ACU 框架重构某保险公司的理赔助手。原来他们有 17 个 Skill：查保单、核身份、传照片、判责任、算金额、填表格、发短信、推链接……上线后客服抱怨“比手动填还慢”。我们砍掉 14 个，只保留 3 个 ACU：

• ACU-ClaimIntake（理赔受理）：输入事故描述+照片，输出结构化报案单+风险等级；
• ACU-CompensationCalc（赔付计算）：输入报案单+条款库版本，输出赔付明细+法律依据引用；
• ACU-CaseEscalation（案件升级）：输入赔付结果+用户情绪分，判断是否需人工介入，并自动生成转交话术。

三个 ACU 之间通过标准化事件总线通信（不是 HTTP 调用），每个 ACU 内部封装了完整的容错逻辑。结果：平均处理时长从 8.2 分钟降到 1.4 分钟，人工介入率下降 63%，而且所有失败案例都能精准定位到是哪个 ACU 的哪个契约环节出了问题——比如“情绪分计算超时”，而不是笼统地说“AI 不好用”。

注意：ACU 的命名必须带业务动词+名词，如 ClaimIntake、CompensationCalc，禁止使用“NLU_Module”“Backend_Service”这类技术黑话。能力是给业务方看的，不是给架构师看的。

3. 拆解“能力缺口”：从用户请求到能力调度的四层衰减链

为什么你装了十几个 Skill，用户还是觉得“不好用”？不是因为 Skill 写得差，而是因为在从用户真实请求到 AI 实际执行之间，存在四层不可见的衰减链。每一层都在 silently 吞噬能力完整性。我把它画成一张衰减漏斗：

用户原始请求（口语化、模糊、带情绪） ↓ 衰减层①：意图解析失真 AI 理解后的结构化意图（可能丢失关键约束，如“尽快”“别提赔偿”“要书面说明”） ↓ 衰减层②：能力路由偏移 匹配到的 Skill（可能选了“通用回复生成”，而非“差评专项回复”） ↓ 衰减层③：上下文承载断裂 Skill 执行时的上下文快照（缺失用户历史、当前会话状态、业务规则版本） ↓ 衰减层④：结果交付失焦 返回内容（格式不符、信息冗余、遗漏动作项，如没附上补偿券码）

我们逐层深挖。

3.1 衰减层①：意图解析失真——你以为听懂了，其实只抓到了关键词

用户说：“这个快递太慢了，我等不及了，能不能先给我补发？”
表面看，关键词是“快递慢”“补发”。但真正关键的是三个隐含约束：

• 时效性约束：“等不及了” → 必须在 2 小时内响应；
• 动作唯一性约束：“先给我补发” → 暂不处理原包裹，不退款，不道歉；
• 责任规避约束：“能不能” → 用户在试探权限边界，需要明确告知“可以，但需您确认收件地址”。

普通 NLU 模型只会抽取出 intent=“request_reshipment”，slots={“item”: “unknown”, “reason”: “delivery_slow”}。它把“等不及了”当成情绪修饰词丢掉了，“能不能”当成礼貌用语忽略了。结果 Skill 调用的是标准补发流程，生成回复：“您好，已为您安排补发，预计 3 天送达。”——完全违背用户“先”“马上”的核心诉求。

实操解法：在意图识别层强制注入业务约束词典。不是让模型自己学，而是人工标注高频业务约束短语，并绑定到能力契约上。例如：

• “等不及了” → 绑定到 ACU-Reshipment 的urgency_level: critical字段；
• “能不能” → 触发 ACU-Reshipment 的permission_check_required: true流程分支；
• “先给我” → 设置action_sequence: [reship_first, then_handle_original]。

我们用 spaCy 训练了一个轻量级约束识别器（不到 5MB），专攻这类短语。它不参与主意图分类，只做“约束增强”。上线后，补发类请求的意图解析准确率从 68% 提升到 94%，关键是——错误类型从“完全跑偏”变成了“细节偏差”，后者可通过 ACU 内部校验修复。

3.2 衰减层②：能力路由偏移——Skill 名字骗了你

你给 Skill 起名叫“售后助手”，但它实际只做了三件事：查订单状态、生成话术、发通知。用户问：“上次投诉后你们承诺的赠品还没寄，现在能补吗？”

• 意图解析正确：intent=“follow_up_gift_delivery”；
• 但路由系统看到“赠品”“补”，就调用了“售后助手”；
• “售后助手”查完订单，发现无赠品记录，就返回：“未查询到相关赠品信息。”
  ——它根本没意识到，这是个跨系统的履约追踪问题，需要调用 CRM 的 Promise Tracking API，而不是查 ERP 的订单表。

问题出在路由逻辑：它用关键词匹配（gift, send, missing），而不是能力契约匹配。真正的路由应该基于 ACU 的 capability_signature：

• ACU-GiftTracking：signature = {“domain”: “promise_fulfillment”, “input”: [“promise_id”, “customer_id”], “output”: {“status”: “shipped|pending|failed”, “eta”: “date”}}；
• ACU-OrderQuery：signature = {“domain”: “order_management”, “input”: [“order_id”], “output”: {“items”: […], “status”: “…”}}。

路由引擎不是查“gift”这个词，而是比对用户请求中是否包含promise_id或promise_date这类字段。如果没有，就触发 ACU-GiftTracking 的前置引导流程：“请问您还记得当时客服承诺的编号或日期吗？这能帮我们更快定位。”

我们用 Apache Calcite 构建了这个签名路由引擎，它把每个 ACU 的 signature 编译成 SQL-like 查询条件。当新请求进来，引擎不是匹配字符串，而是执行一次“能力存在性验证”：SELECT * FROM capabilities WHERE input_fields @> ARRAY[‘promise_id’]; 如果没结果，就走兜底的 ACU-IntentClarification（意图澄清）。

3.3 衰减层③：上下文承载断裂——每个 Skill 都在“失忆”中工作

这是最隐蔽也最致命的缺口。你可能已经做了 RAG，接入了向量库，但 RAG 只解决了“知识记忆”，没解决“会话记忆”和“状态记忆”。

用户第一句：“我买了 iPhone 15，屏幕有划痕。”
第二句：“能换一台新的吗？”
第三句：“算了，退钱吧。”

如果每个 Skill 都是独立调用：

• 第一句触发 ACU-DefectAssessment，存入临时会话状态 {“product”: “iPhone 15”, “defect”: “screen_scratch”}；
• 第二句触发 ACU-ExchangePolicy，但它没拿到前面的状态，只能重新解析“iPhone 15”，再查一遍政策库；
• 第三句触发 ACU-RefundProcess，又得重新确认产品型号、缺陷类型……

三次调用，三次重复解析，三次数据库查询，三次模型 infer。更糟的是，如果用户在第二句和第三句之间切换了 App，会话状态就丢了，第三句变成全新请求，ACU-RefundProcess 根本不知道前面聊过划痕。

解法：引入轻量级会话状态机（Session State Machine, SSM），不是用 Redis 存 key-value，而是用有限状态机定义会话生命周期。SSM 有三个核心状态：

• init：接收初始请求，触发意图解析，生成初始 state object；
• negotiate：用户在多个选项间切换（换货/退款/维修），state object 持续更新；
• commit：用户确认最终动作，触发 ACU 执行，并清空 state。

SSM 的 state object 是结构化 JSON，每个字段都有 schema 和 TTL（如 product_info TTL=30min，defect_photo TTL=5min）。ACU 在执行前，必须声明自己依赖哪些字段，并指定最小 TTL。如果字段过期，ACU 自动触发 refresh flow，而不是硬报错。

我们用 Python 的 transitions 库实现了 SSM，整个状态机代码不到 300 行，但让跨 Skill 的上下文流转变得可预测、可审计。现在，用户从“换货”切到“退款”，系统能自动继承 product_info 和 defect_photo，只刷新 refund_policy 字段，响应时间降低 40%。

3.4 衰减层④：结果交付失焦——AI 交卷，但没答对题

最后一步，AI 把结果塞给你，你以为结束了。但用户看到的可能是：

• 一段冗长的话术，没突出补偿金额；
• 一个 JSON，但前端没解析，显示成乱码；
• 一个链接，点击后跳转到 404 页面。

这不是 UI 问题，是能力契约的交付接口没对齐。ACU 的 output 必须是契约化交付物（Contractual Delivery Artifact, CDA），不是任意格式的输出。CDA 有三个强制字段：

• primary_action：用户下一步必须做的动作（如“点击领取 5 元券”）；
• secondary_info：支撑 primary_action 的必要信息（如券码、有效期、使用范围）；
• failure_fallback：当 primary_action 失败时，用户可立即执行的备选动作（如“复制券码手动输入”）。

例如，ACU-CompensationDelivery 的 CDA 永远长这样：

{ "primary_action": "click_to_claim", "secondary_info": { "voucher_code": "XQ7F9K2M", "valid_until": "2024-12-31T23:59:59Z", "scope": "all_products" }, "failure_fallback": "copy_and_paste_voucher" }

前端不用再猜“这个 JSON 怎么渲染”，它只认这三个字段。primary_action决定按钮文案和点击行为，secondary_info决定弹窗内容，failure_fallback决定长按菜单选项。契约一旦定死，前后端就彻底解耦。

我们曾遇到一个坑：某次 ACU 更新了 output schema，加了个tracking_id字段，但前端没适配，导致所有补偿券页面空白。后来我们强制要求：任何 ACU 的 CDA schema 变更，必须同步更新 OpenAPI spec，并触发前端 CI 的 schema validation。现在，schema 不兼容的发布会被自动拦截。

4. 填补缺口实战：用“能力缺口诊断表”重构你的 Skill 清单

光讲理论没用。我现在给你一套可直接上手的诊断工具——一张 5 列 12 行的 Excel 表（我习惯叫它“能力缺口诊断表”），我们用它来重审你现有的十几个 Skill。这张表不是用来打分的，是用来暴露隐藏断点的。

填表关键动作：

1. 第 2 列“用户典型请求”：不要写你设计的测试用例，去翻真实的客服对话记录、用户反馈邮件、App 内搜索词。找 3 条最常出现的原话。
2. 第 3 列“意图解析后结构化意图”：不是你希望模型输出的，而是你线上系统实际 log 下来的。打开你的 NLU 日志，粘贴 raw output。你会发现很多 slots 是 null 或 default 值。
3. 第 4 列“路由到的 ACU”：查你的路由日志。别信文档，信生产日志。你会发现，80% 的请求都路由到了“通用 Skill”，因为它的匹配权重最高。
4. 第 5 列“CDA 交付物示例”：不是你设想的，而是你前端实际收到的 response body。用浏览器开发者工具 Network Tab 抓包，粘贴真实 JSON。
5. 最后一列“缺口定位”：对照前面讲的四层衰减链，每条请求至少打一个 ✓。如果一条请求打了三个 ✓，说明这个 Skill 已经严重失能，建议直接下线。

我们用这张表诊断过某教育公司的 15 个 Skill。结果：

• 12 个 Skill 在“路由”栏打了 ✓（全部路由到通用问答 ACU）；
• 9 个在“交付”栏打了 ✓（CDA 里没有primary_action，前端只能渲染纯文本）；
• 7 个在“语义粒度”栏打了 ✓（用户说“孩子数学考砸了，怎么辅导”，意图解析成 intent=“academic_advice”，但没抽取出“grade_level: 5th”, “subject: math”, “score: 52/100”）。

诊断完，我们没急着写新 Skill，而是先做了三件事：

• 合并：把“数学辅导”“语文辅导”“英语辅导”三个 Skill，合并为 ACU-AcademicSupport，输入契约强制要求grade_level和subject字段；
• 增强：给 ACU-AcademicSupport 加入约束识别器，专门抓“考砸了”“没及格”“家长很着急”这类情绪强度词，触发不同响应策略；
• 契约化：定义 CDA 必须包含next_step（如“请上传孩子错题照片”）和resource_link（如“五年级数学易错题集 PDF”）。

两周后上线，家长咨询中“需要人工介入”的比例从 41% 降到 12%，而且所有自动回复都带明确动作指引，不再有“请再提供更多信息”这种无效交互。

提示：诊断表不是一次性工具。我们每月初固定用它扫描所有 ACU，重点关注“缺口定位”栏新增的 ✓。如果某个 ACU 连续两月在“上下文”栏打 ✓，说明它的 state management 逻辑需要重构。

5. 能力演进路线：从 Skill 堆砌到 ACU 生态的三年实践

最后，分享我们团队走过的真实能力演进路径。它不是理论模型，而是踩着坑、熬着夜、看着监控曲线一点点调出来的。

5.1 第一年：止血期——砍掉 70% 的 Skill，建立能力基线

目标不是“做出更多”，而是“让剩下的能用”。我们定了三条铁律：

• 铁律①：每个 ACU 必须有可测量的成功率 SLA。不是“调用成功”，而是“用户后续无追问完成率 ≥85%”。我们用会话结束标识（用户发送“好的谢谢”或 5 分钟无消息）作为 success signal。
• 铁律②：所有 ACU 输入输出必须通过 JSON Schema 验证。Schema 存在中央 registry，任何变更需 PR + 三方 review（后端、前端、业务方）。
• 铁律③：禁止 ACU 直接调用外部 API。必须通过统一的 Adapter Layer，Adapter 负责认证、限流、熔断、日志埋点。这样，当某 API 故障时，我们能快速定位是 Adapter 问题，还是 ACU 逻辑问题。

第一年结束，我们从 23 个 Skill 砍到 7 个 ACU，但整体用户满意度（CSAT）从 62% 提升到 79%。最关键的是，故障排查时间从平均 4.2 小时降到 22 分钟——因为所有问题都能定位到具体 ACU 的具体契约环节。

5.2 第二年：编织期——构建 ACU 间的“能力织网”

单一 ACU 再强，也解决不了复杂请求。第二年我们重点做“能力编排”。但不是用传统 workflow 引擎（太重），而是设计了一套轻量级能力编织协议（Capability Orchestration Protocol, COP）。

COP 的核心是Event-Driven Capability Chaining（事件驱动能力链）：

• 每个 ACU 执行完，必须 emit 一个标准化事件，如acu.compensation.delivery.success；
• 事件 payload 包含本次执行的 input、output、duration、error_code（如有）；
• 其他 ACU 可以 subscribe 这些事件，触发后续动作。例如：
  • ACU-CompensationDelivery 成功后，自动 emitcompensation_delivered事件；
  • ACU-CustomerSentimentMonitor 订阅此事件，调用情感分析模型，判断用户情绪是否因补偿而改善；
  • 如果情绪显著提升（delta >0.3），则 emitloyalty_boosted事件，触发 ACU-LoyaltyProgram 发放额外积分。

所有事件都通过 Kafka 传输，Schema 由中央 registry 管理。我们没写一行编排代码，只配置 event subscription rules。好处是：ACU 之间完全解耦，新增一个 ACU 只需声明它 emit 和 subscribe 哪些事件，无需修改其他 ACU。

这一年，我们新增了 4 个 ACU，但用户感知到的“能力变多了”，是因为它们开始协同工作。比如用户收到补偿券后，30 秒内就收到一条：“检测到您刚领取补偿券，为您准备了《如何避免屏幕划痕》小贴士，点击查看。”——这不是一个 Skill，而是 ACU-CompensationDelivery、ACU-ContentRecommendation、ACU-NotificationService 三个 ACU 的自然协作。

5.3 第三年：生长期——让 ACU 具备“自我进化”能力

真正的成熟，是 ACU 能从失败中学习。第三年我们给 ACU 加入了Failure-Driven Adaptation Loop（失败驱动自适应环）。

流程很简单：

1. 每个 ACU 都有failure_handler函数，当执行失败（如 API timeout、模型置信度低、CDA 校验失败），它不直接报错，而是：
   • 记录 failure context（时间、输入、错误码、上游 ACU）；
   • 触发acu.failure.detected事件；
2. 中央 Failure Analyzer 服务订阅此事件，用轻量级 ML 模型（XGBoost）分析 failure pattern：
   • 如果连续 5 次 failure 都发生在input.length > 500 chars时，自动触发 ACU 的 input preprocessor 升级（加入摘要压缩）；
   • 如果 failure 集中在某个时段（如每天 10:00-10:15），且关联到特定上游 ACU，就调整该上游 ACU 的 timeout 参数；
3. 分析结果生成adaptation_plan，自动提交 PR 到 ACU 代码库，附带测试用例和 rollback 方案。

我们第一个实现自适应的 ACU 是 ACU-DocumentSummarization。它原来对长 PDF 处理失败率 37%，启用自适应环后，三个月内失败率降到 4.2%，而且所有优化都是自动发生的，研发团队只审核了 3 次 PR。

现在，我们的 ACU 清单稳定在 12 个，但能力覆盖度比第一年的 23 个 Skill 高出 2.3 倍。因为能力不再是静态功能，而是持续生长的有机体。

我在实际项目中最深的体会是：别再问“这个 Skill 能不能做 XX”，改问“当用户发出 XX 请求时，我的能力体系能否在 3 秒内，给出带明确动作指引的、可验证的结果？”
前者是功能思维，后者是能力思维。而能力思维的第一步，就是承认那个缺口的存在——它不在模型里，不在代码里，而在你对“AI 如何真正帮人解决问题”的理解里。