企业官网建设流程全解析

上周五我处理一个客户投诉，前后开合了四个后台：先翻CRM看客户合约周期，再去工单系统查最近三个月有没有服务记录，然后回知识库翻产品说明，最后还要找运维要一份日志摘要。整个过程四十分钟，大部分时间都耗在点菜单和复制粘贴上。数据其实一直都在，CRM有客户全景，工单里有交互轨迹，知识库里有标准答案，可它们谁也看不见谁——这就是最典型的数据孤岛。最近我换了个思路，不再费劲去搭数据中台，而是花了一天时间整理出一套Skills，交给Agent按需调用，让它在一次对话里替我完成跨系统查证。这篇文章就是这套方案的完整复盘，包含设计思路、核心文件写法、实测效果和踩坑记录，适合正在被多系统来回切换折磨的运维、业务开发，以及想给团队引入Agent工作流的朋友参考。

1. 数据孤岛的真问题：不是没有数据，而是数据不具备“即问即答”的能力

1.1 客户的完整画像，被拆散在四个系统里

那个客户案例特别能说明问题。客户打电话进来的时候，客服只能看到CRM里一句"合约还有45天到期"，但看不到这45天里客户已经提了三次工单，也看不到知识库里对应产品线最近刚出过版本变更公告。要搞清楚"这个客户续约时该怎么谈"，人肉操作是没法绕开的：先记住CRm里的合约号，切到工单系统搜一遍，把投诉记录复制到文档里，再去知识库查产品公告，最后还得猜一下日志里显示的服务中断跟客户反馈是不是同一件事。

这个场景里的数据孤岛，不是"没有数据"，而是数据被各自的系统锁死了。每个系统都在自己的界面里回答自己的问题，但你问一个跨系统的问题，没有任何一个界面能给出完整答案。我把这种状态总结成一句话：数据能存、能查，但不会答。存储做到了，单点查询也做到了，唯独"组合式问答"这个能力完全缺失。

更麻烦的是，这种缺失不是靠"多打开几个系统"就能补上的。客户问得快，运营翻得慢，中间的信息损耗比数据损耗还大。我在复盘这个案例时意识到，很多公司其实不缺数据中台规划，也不缺BI报表，最缺的是一个能让人用自然语言直接把问题抛给所有数据源、并且当场拿到组装后答案的入口。Skills这个机制，恰好能在这一层派上用场。

1.2 传统的"打通孤岛"方案，为什么总让人感觉使不上劲

过去我们聊数据孤岛，第一反应都是上数据仓库、做ETL、搞API聚合层、建BI报表。这些方案我没少用过，结论是：都能解决一部分问题，但都有让人难受的代价。

ETL的问题是重。拿我们这个小团队来说，真要打通CRM和工单系统，得约数据负责人、谈字段映射、定同步频率、处理脏数据，光初始方案就能磨两周。API聚合层听着轻巧，但每个新场景都要改代码重新发布，本质上还是把"业务问题"翻译成"开发任务"。BI报表则是给决策者看趋势用的，你让它回答"这个客户能不能续约"，它就哑火了。

问题的根源在于，这些方案都在做"数据层面的搬迁"，而我们真正需要的其实是"问答层面的连接"。业务同事不在乎数据放在哪，只在乎当我问出那个跨系统的问题时，能不能立刻得到答案。这个目标用重型数据平台去做，就像为了喝杯热水专门盖个锅炉房，方向对，但用力过猛。

1.3 换个思路：把"查询口"变成"能力包"，而不是把数据搬到一起

我第一次接触Agent Skills时，脑子里立刻浮现的就是那个客户投诉场景。Skills这套机制的核心理念，和传统打通孤岛的方式正好相反：它不搬数据，它给每个数据源装一个"会说话的窗口"。CRM的数据继续留在CRM，工单的数据继续留在工单，区别是每个系统边上多了一个按标准格式描述好的技能包——告诉Agent这个系统里有什么、怎么查、什么时候该用它、返回什么格式。

这样一来，跨系统问答变成了Agent的编排活。用户说"查一下这个客户最近的投诉和合约到期时间"，Agent看到问题里有"投诉"和"合约"两个概念，就会分别调用工单查询技能和CRM查询技能，拿回数据后在上下文里完成关联，最后给出人话答案。数据还是散落在各处的，但"提问—取数—组装—回答"这条链路被打通了。

这个思路尤其适合中小团队。我们没有专职数据平台团队，但有业务系统API、有少量脚本能力、有一堆想少点几个系统的业务同事。Skills刚好落在"够用且灵活"的位置：不用动基础设施，只要把取数逻辑封装成技能包，就能在Agent里获得一个跨系统的虚拟入口。

2. Skills机制拆解：为什么它天生适合做跨系统连接器

2.1 一个Skill到底长什么样：元描述、脚本与数据的三层结构

Skills并不是什么玄乎的新技术，拆开看就是一个标准的目录结构加一套可执行脚本。我们团队约定的每个Skill长这样：

skills/ ├── crm-query/ │ ├── SKILL.md # 技能说明书：名字、描述、触发场景、参数说明 │ ├── scripts/ │ │ └── query.py # 真正干活的脚本：调CRM接口、过滤字段、返回结果 │ └── assets/ │ └── config.json # 辅助参考配置，比如字段白名单 ├── ticket-lookup/ │ ├── SKILL.md │ ├── scripts/ │ │ └── search.py │ └── assets/ └── kb-search/ ├── SKILL.md ├── scripts/ │ └── retrieve.py └── assets/

这三层各有分工。SKILL.md是给Agent看的，里面用自然语言写清楚这个技能在什么情况下被启用、怎么传参数、返回什么格式。scripts里是给机器执行的，承担真正的HTTP请求、鉴权、字段裁剪和错误处理。assets则放一些辅助数据，比如映射表、关键词列表、配置项。

我一开始对这个结构不以为然，觉得不就是"传统接口套了个壳"。用久了才体会到SKILL.md这层描述文本的重要性：因为Agent不像代码那样靠函数签名判断调用，它靠的是语义理解。技能能不能被正确触发、会不会被误触发，全靠SKILL.md写得好不好。从这个角度看，SKILL.md就是技能包的"招聘启事"，写得不清楚，Agent要么不找你，要么乱找你。

2.2 和插件、API、Prompt模板相比，Skill多出来的东西

很多人问我，Skills跟以前的插件系统、API封装、Prompt模板有什么本质区别。我梳理过一张对照表：

插件是"我给某个应用装了个功能"，和Agent掌握全局上下文这件事是两套逻辑。API是"我在代码里显式调用"，不会因为用户一句话就被临时选上。Prompt模板能引导Agent的思路，但没有执行能力，说完话还是得有人去点系统。Skill是把这几种东西凑齐了：有自然语言描述让Agent理解用途，有可执行代码让它真正去拿数据，有assets让它理解业务上下文。它更像一个"带简历的工人"，Agent读到简历觉得合适，直接派他去干活。

国外有些文章从First Principles角度讨论Agent Skills，我读下来收获很大，但落到实战层面，观察起来其实很朴素：这个机制解决了Agent"知道该问谁"和"能真正问到数据"之间的空隙。没有Skills时，Agent再聪明也只能在用户给定的一段上下文里推理；有了Skills，Agent可以主动去系统里取数，再基于新数据继续推理。

2.3 用"运行时聚合"替代ETL里的多表Join

我最喜欢Skills的一点，是它用运行时聚合替代了传统ETL的预聚合。过去我们要回答"最近30天有投诉且下月合约到期的客户有哪些"，得把CRM的合约表和工单系统的事件表都导到数仓，做一次Join再输出结果。这个链路周期长，而且一旦口径变了，整套ETL都要调整。

Skills方案完全换了个姿势。Agent收到问题后，先去CRM技能那里拿"下月合约到期客户"列表，再去工单技能那里查这些客户的投诉记录，然后在自己的上下文窗口里做交集。这个过程很像人在手动操作，只是把"人"换成了"Agent+技能包"。优点是数据不动、口径可控、按需组合，缺点是别指望它对几百万行全量数据做分析——它不是为大数据设计的，而是为"业务问答"设计的。

我特别想强调一句：Skills不会消灭数据仓库，它消灭的是"等数据仓库给答案"这件事的焦虑感。前者继续负责全量分析、指标统一和深度建模，后者负责日常业务问答里那些零碎的跨系统查询。两者不打架，反而互补。

2.4 生态热度背后是一个趋势：给Agent配好工具箱

最近社区里关于Skills的内容一下子多了起来，前端开发skills、AI编程助手的技能包、文档处理、数据分析、逆向分析等场景都有现成技能包，也有一些专门的技能市场冒出来。我理解这股热度背后的逻辑：Agent的能力瓶颈已经从"模型智商"转移到了"工具可触达性"。模型再聪明，拿不到数据也是巧妇难为无米之炊。Skills恰好把"模型能力"和"系统数据"之间的胶水给补上了。

对我们这种被数据孤岛困扰的团队来说，这个趋势是个好消息。通用技能可以从市场上找现成的改造，内部系统技能自己写一套，两者拼起来，Agent就不是一个只能聊天的玩具，而是一个带着整套工具箱上岗的准员工。这一步跨过去，数据孤岛问题才算真正有了一个轻量级、可落地的解法。

3. 一套打通数据孤岛的Skills，我是怎么设计的

3.1 先盘点数据源：我把"数据源清单"做成了设计起点

真正动手写Skill之前，我花了大半天做了一件看起来特别不技术的事：列数据源清单。我把团队日常查询最多的系统一个个列出来，记下每个系统里有什么数据、通过什么方式访问、有没有只读权限、最常见的查询需求是什么。

做完清单才发现，我们对每个系统最常做的就是"查询"，而且基本都是低并发、低频次的临时查询。这个发现让我彻底打消了上数据仓库的念头：既然高频需求只有查询，那让Agent学会查询就够了。清单做出来后，每个系统对应几个技能包就顺理成章了——CRM一个、工单一个、知识库一个、数据库一个、监控一个。

清单本身也是后续配置权限和网络白名单的依据。每个Skill脚本里访问什么域名、用什么凭证，都可以从这张表里直接对照出来，省得后面反复问"这个系统的token在哪里"。

3.2 四条设计原则：单一职责、显式触发、返回裁剪、安全只读

Skills设计得不好，很容易变成一个大而全的脚本，最后Agent根本不知道该不该用它。我的经验是坚持四条原则：

单一职责。一个技能只回答一类问题。CRM技能就管客户和合约，别顺手把报表统计也塞进去。职责越单一，Agent越容易准确触发。我见过把十多个功能写进一个SKILL.md的情况，结果描述怎么写都有遗漏，实际调用全靠猜。

显式触发。SKILL.md里的描述不能含糊。要写清楚"何时使用"，更要写清楚"何时不用"。比如工单查询技能里加一句"本技能不处理工单创建和状态修改"，能挡住一大串误触发。

返回裁剪。脚本返回给Agent的数据必须是"最小充分集"。字段按白名单输出，行数设置上限，长文本截断或摘要。这既是为上下文窗口考虑，也是为了让Agent不被无关信息带偏。

安全只读。所有连接内部系统的Skill一律使用只读凭证，网络访问做白名单限制。Agent本身没有恶意，但你无法保证它每次都被用户正确引导，权限边界必须从基础设施上兜住。

这四条写起来简单，但每一条背后都有一次翻车经历支撑。后面第5节我会展开讲几个具体踩坑案例，现在先按住不说。

3.3 三个核心技能包实例：CRM查询、工单检索、知识库问答

挑三个最典型的技能包展示一下核心设计。

CRM查询技能的SKILL.md，我写成了下面这个样子：

--- name: crm-query description: 查询CRM系统中的客户基本资料、合约状态和最近跟进记录。仅在需要了解客户信息、合约周期、到期时间时使用。不处理销售统计和市场分析。 --- # CRM客户查询 ## 适用场景 - 用户询问某客户的基本资料、联系人或所属负责人 - 用户询问合约是否到期、还剩多长时间 - 用户需要客户维度的信息作为续约/服务判断依据 ## 参数 - customer_id: 客户ID或手机号 - keyword: 客户名称模糊查询关键字，可选 ## 输出约定 - 始终以JSON返回 - 字段限制为：customer_id, name, owner, contract_end, last_follow_up - 无结果时返回: {"status": "no_result"}

工单检索技能的脚本核心逻辑更简单：

import json import os import urllib.request def search_ticket(customer_id, days=90): base = os.environ["TICKET_API_BASE"] token = os.environ["TICKET_TOKEN"] url = f"{base}/tickets?customer_id={customer_id}&days={days}" req = urllib.request.Request(url, headers={"Authorization": f"Bearer {token}"}) with urllib.request.urlopen(req, timeout=10) as resp: data = json.loads(resp.read().decode("utf-8")) # 裁剪字段，只保留时间、类型、标题、状态 result = [ {"time": t["created_at"], "type": t["category"], "title": t["subject"], "status": t["status"]} for t in data.get("tickets", []) ][:20] # 限制最多20条 return json.dumps({"status": "ok", "tickets": result})

知识库问答技能稍微特殊一点，它需要先调检索接口拿到相关文档片段，再做长度裁剪：

def retrieve(query, max_chars=1200): # 调用知识库检索API，取相关度最高的文档 # 对文档做章节切分，取与query相关的片段 # 确保返回的纯文本不超过max_chars

这三个技能包固定下来以后，团队里任何一个人都能往里面加新的查询入口，遵循同一个模式就行。

3.4 一次真实的编排日志：Agent怎样跨系统组装答案

设计完成不代表能用，我找了个真实问题做验证："客户A的合约还有多久到期？过去三个月有没有投诉？适合按什么策略谈续约？"

Agent的执行路径是这样的：

1. 先调kb-search，查询知识库里当前产品线的续约策略和产品变更公告，拿到策略框架。
2. 再调crm-query，拿客户A的合约到期时间和最近跟进记录。
3. 看到"到期时间"后，调ticket-lookup，拉取客户ID对应的工单列表，筛选投诉类别。
4. 把三份结果拼成一个上下文，按"策略—客户状态—风险点"的结构输出建议。

整个过程中，Agent每一次取数都只做一件事，但编排起来就是一次完整的跨系统问答。以前这个流程要我开三四个系统翻半小时，现在一分钟内出结论。这个例子让我确信：Skills方案的核心价值不在单个技能本身，而在Agent对技能的组合调度能力。

4. 从零到一落地：Skill怎么建、怎么注册、怎么调

4.1 目录与依赖管理：让每个Skill自带干粮

写Skill时有几个实现层面的细节特别容易踩坑。第一个是依赖管理。Skill脚本如果依赖一堆第三方库，会让部署变得很痛苦。我的建议是脚本尽量走标准库，HTTP调用用urllib就够，JSON解析用内置的json。实在要requests也可以用，但要把依赖写清楚，且保证在目标环境里装好。

第二个是环境变量。SKILL.md和脚本里绝对不能写死token、域名、账号。我们有个约定：凡涉及连接信息的一律从环境变量读取，Agent注入这些变量，脚本只负责消费。这样一套技能包可以在测试、预发、生产环境之间原样移动，不会因为代码里写了一个测试域名而出事故。

第三个是自包含。每个技能包的assets里放自己的参考配置，不依赖外部共享目录。当初为了省事共享过一个config.json，结果某个技能改了配置，其他技能行为全变了，排查半天才发现是共享文件被改。自包含虽然多花一点存储，但心智负担小很多。

4.2 SKILL.md怎么写才能少误触发：好描述与烂描述的差距

SKILL.md是误触发的重灾区。我最早写过一个"文档查询"技能，描述只有一句"用于查找文档资料"，结果Agent只要听到"文档"两个字就触发，用户问"帮我生成一份Word文档"它也去查知识库，完全驴唇不对马嘴。

后来我总结了SKILL.md里必须写清楚的几个点：

• 系统的边界：这个技能的数据来自哪个系统，只覆盖哪几类查询。
• 触发词：尽量列出典型触发词，比如"合约到期""客户投诉记录""产品公告"。
• 负面排除：明确写"不用于"什么场景，这是减少误触发最有效的一招。
• 输出格式自描述：在SKILL.md里贴一段示例返回JSON，帮助Agent理解后续能拿到的数据长什么样。

用一个对比来说明。写得差的描述：

description: 查询客户数据。

写得好的描述：

description: 查询CRM系统中的客户基本资料、合约状态和最近跟进记录。仅在需要了解客户信息、合约周期、到期时间时使用。不处理销售统计和市场分析。

后者多出来的内容，都是在帮Agent"做选择题"。Agent不是人，它不会主动追问，只能靠描述里的信号来判断该不该调用。描述写得越像一份精确的需求说明书，误触发概率就越低。

4.3 脚本接口设计：参数校验、超时、错误码一个都不能少

脚本是Skill的"手"，如果脚本写得糙，Agent拿到的数据就不可靠。我用三个规范来约束脚本质量：

参数校验。脚本入口要对传入参数做严格检查，缺参数时返回结构化错误而不是抛异常。比如查询客户ID为空时返回{"status": "error", "message": "missing customer_id"}，Agent看到这个错误会知道自己参数传错了，还能尝试补救。

超时设置。所有外部调用必须有超时时间，我们统一设10秒。内部系统再慢，也不能让Agent在取数这一步无限等待。超时后返回错误码2，并给出提示"系统暂时不可用，可稍后重试"。

白名单字段。返回数据永远从接口原始字段里挑出需要的再返回，不直接把整个响应体透传。这样既控制token消耗，也避免把无关敏感字段漏给Agent。

def safe_return(data, allowed_fields, max_rows=20): rows = data.get("items", [])[:max_rows] return [ {k: item.get(k) for k in allowed_fields if k in item} for item in rows ]

这个小函数是我所有Skill脚本的公共底座，把最容易被忽略的"返回裁剪"做成了强制逻辑。

4.4 把Skills挂到Agent上的两种方式：本地技能包与团队共享

技能包写好后，挂载方式决定了团队协作的顺畅度。我们试过两种方式。

第一种是本地挂载。把技能包放在自己机器的Agent技能目录下，修改后重启Agent就能生效。这种方式适合个人开发调试，改起来最快，但问题是团队其他人看不到你的改动。

第二种是项目共享。把技能包放进一个git仓库，部署时同步到公共目录，团队所有人共一套。好处是一致性强、可审查，可以走代码评审流程。缺点是升级时要通知大家刷新，否则有人用的旧版有人用的新版，行为不一致。

我的建议是：个人实验用本地，正式接入业务线用项目共享。现在很多Agent工具都支持从技能市场或压缩包安装第三方技能，社区里那批现成的文档处理、前端开发、编码辅助技能包就是这么分发出去的。内部系统技能因为涉及连接信息，建议本地维护，不要上传到公开市场；通用型技能则可以大胆用现成的，没必要重造轮子。

4.5 权限模型：只读账号+最小化token+审计日志

安全这块我特别想多说几句。Skills给了Agent执行能力，这是好事也是风险。Agent可能在用户诱导下查询本不该查的数据，也可能因为脚本bug误操作。我们的权限模型是三件套。

第一，所有业务系统统一用只读账号。查询类技能全部使用只读token，不允许有任何写接口。写操作以后另做一套审批流程，绝不让普通查询技能碰。第二，token范围最小化。CRM的token只能查客户和合约，查不了订单明细；数据库账号只授权了必要的几张表的SELECT权限，其他表一律没授权。第三，审计日志。每个Skill脚本执行时都把调用时间、入参、返回条数、执行结果摘要打到一个独立日志文件里，出了问题可以追溯是哪一次调用、传了什么参数。

这套权限模型不复杂，但对防线来说已经够用。Agent本身的推理能力再强，只要执行层权限足够小，风险就能被锁在笼子里。

5. 实测效果与翻车现场：哪些坑真实存在

5.1 第一轮翻车：SKILL.md写太泛，所有问题都找它

上线第一天就出洋相。我们把"爱问"技能挂上去，结果所有问题都往那里跑。用户问"出差报销流程"，它去查CRM；用户问"帮我起个英文名"，它去查客户数据库；甚至问"今天午饭吃什么"，它也想从系统里找答案。

我打开Agent调用日志一看，触发词就一个"查询"，描述里没写任何排除条件。加上这个技能排在技能列表靠前的位置，Agent在犹豫时就倾向于它。修复方案很简单：把描述重写，明确列出"仅当需要客户资料/合约信息时使用"，并加了负面排除"不用于报销流程、不用于产品咨询、不用于一般性问答"。改完以后误触发率立刻降下来了。

5.2 第二轮翻车：返回原文太长，上下文被塞爆

第二个坑来自知识库检索。刚开始我偷懒，让检索脚本直接把命中的文档段落整段返回，想着Agent能自己筛重点。结果一段产品文档返回了三四千字，再叠加其他技能的返回数据，Agent的上下文窗口很快就满了，输出质量肉眼可见地下降，甚至开始漏掉关键信息。

这个问题的本质是技能返回数据里"噪音太多"。后来我做了两层处理：脚本里先对检索结果做相关性截断，每段最多返回1200字符；SKILL.md里明确写"本技能返回的是文档片段摘要，具体细节可要求进一步查询"。这才是Skill和上下文窗口的正确相处方式——把最小充分集交给Agent，而不是把整个文档搬过去。

5.3 第三轮翻车：并行调用时两个技能给出同一指标两个口径

最隐蔽的一个坑出现在CRM技能和数据库技能同时被触发的时候。用户问"这个月销售额是多少"，CRM技能返回的销售数据里含未回款订单，数据库技能返回的订单金额只统计已支付订单，数字对不上。Agent拿到两个数都很自信，最后给出一个被拼凑出来的答案——单独看每步都对，整体看是错的。

这暴露了Skills方案的天然短板：它解决"数据可达"，不解决"口径一致"。两个系统对同一个指标定义不同，Agent是无从判断的。我们的补救措施是在SKILL.md里加"口径定义"字段，明确每个技能返回的指标是怎么统计的，并且给同域技能加"权威源"标记。如果用户问的指标存在多源冲突，SKILL.md指引Agent优先采用权威源，必要时直接提示"该系统与另一系统口径不一致，请确认"。

5.4 调稳之后：跨系统查证从40分钟到1分钟以内

把上面三个坑填平之后，这套Skills方案才真正进入可用的稳定状态。现在团队处理类似的跨系统客户查询，流程统一变成：用户提问，Agent按需调用技能，输出结构化结论。以前我开四个系统翻半小时才能确认的事实，现在一分钟内就能拿到，而且每个结论后面都带着数据出处，可以直接追溯验证。

另一个让我意外的收益是，业务同事开始主动提新需求。他们发现加一个技能包比自己翻系统容易多了，于是"能不能也查一下物流信息""能不能顺便把合同状态也查了"这类需求接踵而至。技能的扩展成本低，业务方自然愿意拥抱，这比推一套正式数据平台遇到的阻力小得多。

6. 这套方案能用到什么程度：边界与取舍

6.1 适合Skills做的三件事

把一段时间的使用经验压缩成结论，我认为Skills在三个场景里表现最好。

第一，跨系统只读查询与聚合。这是最核心的用武之地，客户资料、工单记录、知识库文档、订单状态这类高频业务问答，用技能包组合调度，体验拔群。第二，知识库与文档检索问答。文档类技能把"翻知识库"变成"提问即答"，非常适合做内部IT支持、新员工入职问答。第三，可控的自动化动作。在权限严格受限的前提下，技能也可以触发开票、创建工单这类简单动作，但一定要走单独的审批和审计流程，不要跟查询技能混在一起。

6.2 不适合硬塞给Skills的事

拿表格里的"全量数据分析"来说，Skills方案本质上是对"点"查询的编排，你让它处理几百万行明细做聚类分析，既没这能力也没这必要。高并发低延迟更是Agent的软肋，每次问答都要走一遍模型推理，延迟从几百毫秒到几十秒不等，这不是技能代码能优化的。强事务写入则是红线——几条数据改错了可以人工修，资金或库存类的写入绝对不能靠Agent技能包去碰。

6.3 什么时候应该回头用正规数据平台

如果团队已经明显出现这些信号——指标口径反复扯皮、需要统一的大屏实时看板、数据团队开始专职做分析、业务对准确性要求上升到财务审计级——那就说明组织已经跨过了"轻量打通"阶段，该认真上数仓或指标平台了。Skills解决的问题是"最后一公里的问答"，它替代不了数据中台里的指标治理、质量监控和数据建模。

我在实际中的体会是：先靠Skills把日常查询体验做起来，让业务同事意识到"数据是可以被问出来的"，后面再推数据平台时，大家的接受度和需求表达都会清晰得多。Skills不是数据中台的敌人，反而能成为它最好的前哨站。

6.4 顺着这个思路继续扩展的玩法

如果你也想试，我建议不要一上来就搭全套，先选一个你每天重复至少三次的动作，把它做成第一个技能。比如你天天要查订单状态，就写一个订单查询技能；天天要翻合同，就写一个合同检索技能。一个技能跑顺之后，你会慢慢理解Agent到底怎么理解描述、怎么选择调用，这时候再铺开做多系统打通，就顺手了。

技能也可以延伸到工作流里：每周把团队周报的素材聚合、把多个系统的数据汇总成一张简报、把会议纪要归档到知识库并关联相关客户——这些都可以变成一套"个人助理技能包"。数据孤岛的墙不是一天砌起来的，自然也不可能一夜拆完，但每多一个能跨系统回答问题的技能，那面墙就薄了一分。