企业官网建设流程全解析

1. 大模型能力扩展的演进脉络与核心逻辑

1.1 从“会聊天”到“能干活”的分水岭

大模型刚火起来那阵子，大家最直观的体验就是“能聊天”。你问它答，写个文案、改个邮件、编个故事，确实挺惊艳。但用久了就会发现一个尴尬的问题：它知道很多，却做不了什么。你让它帮你订个餐厅，它只能给你一段“你可以打开某App，搜索某关键词”的文字说明；你让它查一下今天的天气，它只能告诉你“我无法获取实时信息”。这种“知识渊博但四肢瘫痪”的状态，是早期大模型最真实的写照。

真正让大模型从“聊天机器人”变成“生产力工具”的转折点，就是能力扩展机制的出现。所谓能力扩展，说白了就是给大模型装上“手”和“脚”，让它不仅能思考，还能调用外部工具、访问实时数据、执行具体操作。这个思路的演进，大致经历了三个阶段：插件时代、工具调用时代、技能封装时代。每个阶段解决的核心问题不同，技术实现方式也差异巨大。

我刚开始接触这块的时候，也是从ChatGPT-Plugin开始入坑的。那时候觉得“插件”这个概念简直天才——大模型负责理解意图，插件负责执行具体任务，两者一结合，想象空间无限大。但实际用下来才发现，理想很丰满，现实很骨感。插件生态的碎片化、调用链路的不可控、权限管理的模糊性，都是实打实的坑。后来Claude-Skills的出现，让我看到了另一种思路：与其让模型去适配无数个插件，不如把能力封装成模型可以直接理解和执行的“技能包”。这个思路的转变，背后是对大模型能力边界和工程化落地的深刻反思。

1.2 为什么“扩展”是大模型落地的必经之路

要理解能力扩展为什么重要，得先搞清楚大模型的本质局限。大模型的核心能力是模式识别和内容生成，它擅长的是“根据已有信息推断合理输出”，而不是“主动获取新信息”或“执行物理操作”。这就决定了它有三个天然短板：信息时效性差、无法与外部系统交互、缺乏执行能力。

信息时效性差很好理解，训练数据截止到某个时间点，之后发生的事情它一概不知。无法与外部系统交互，意味着它不能查数据库、不能调API、不能读写文件。缺乏执行能力，就是它只能输出文本，不能真的帮你点击按钮、发送请求、修改配置。这三个短板，每一个都足以让大模型在真实业务场景中“寸步难行”。

能力扩展机制就是针对这三个短板来的。通过工具调用，模型可以实时查询外部数据源，解决时效性问题；通过API集成，模型可以与各种业务系统对接，解决交互问题；通过技能封装，模型可以执行一系列预定义的操作流程，解决执行问题。可以说，没有能力扩展，大模型永远只能停留在“演示”阶段，无法真正嵌入到生产流程中。

我见过太多团队在POC阶段被大模型的“聪明”惊艳到，然后兴冲冲地推进到生产环境，结果发现它连最基本的“查一下库存”都做不到，最后项目不了了之。问题就出在只关注了模型的“脑力”，忽略了给它配“手脚”。

1.3 三个时代的核心差异对比

为了让大家更直观地理解这三个阶段的差异，我整理了一个对比表格。这个表格是我自己在做技术选型时反复参考的，基本上涵盖了最核心的决策维度。

从表格里能看出来，每个阶段都在解决前一个阶段的核心痛点。插件时代的问题是“别人写什么你用什么”，开发者没有主动权；工具调用时代把主动权交回来了，但代价是你要自己写大量集成代码；技能封装时代试图在两者之间找平衡，既保留灵活性，又降低集成成本。

这个演进脉络背后，其实是一个很朴素的工程逻辑：让专业的人做专业的事，同时让协作成本尽可能低。插件时代是“平台搭台，开发者唱戏”，但平台对开发者的约束太弱，导致生态混乱；工具调用时代是“开发者自己搭台自己唱”，灵活但累；技能封装时代是“平台提供标准化的舞台和道具，开发者专注于编排剧本”，试图兼顾标准化和灵活性。

2. ChatGPT-Plugin：第一次让大模型“长出双手”

2.1 插件机制的核心设计思路

ChatGPT-Plugin刚发布的时候，我第一时间就去申请了开发者权限。当时最让我兴奋的不是某个具体插件有多好用，而是它展示了一种全新的可能性：大模型不再是一个封闭的知识库，而是一个可以连接万物的“中枢”。你问它今天有什么新闻，它可以通过插件去查；你让它帮你订机票，它可以通过插件去操作。这种“模型+插件”的架构，本质上是在大模型周围构建了一个能力扩展层。

插件的核心设计思路其实不复杂。每个插件本质上是一个符合OpenAPI规范的HTTP服务，它需要提供一个ai-plugin.json描述文件，告诉ChatGPT“我是谁、我能做什么、怎么调用我”。ChatGPT在收到用户请求后，会根据插件的描述判断是否需要调用某个插件，如果需要，就生成对应的API调用请求，发送给插件服务器，拿到结果后再整合成自然语言回复给用户。

这个流程听起来很顺畅，但实际落地时会遇到一个关键问题：模型怎么知道什么时候该调用哪个插件？这就涉及到插件的描述质量问题。如果描述写得太模糊，模型可能该调用的时候不调用，不该调用的时候乱调用；如果描述写得太具体，又可能限制插件的适用范围。我见过不少插件因为描述文件写得不好，导致调用成功率极低，最后被用户弃用。

提示：插件的description_for_model字段是决定调用准确率的关键。这个字段不是写给用户看的，是写给模型看的。要用模型能理解的方式描述“什么场景下应该调用我”，而不是堆砌功能列表。

2.2 插件生态的繁荣与乱象

ChatGPT-Plugin上线初期，确实迎来了一波爆发式增长。短短几个月，插件数量从几十个飙升到上千个，覆盖了购物、餐饮、旅行、办公、开发等几乎所有能想到的领域。那段时间我几乎每天都在试新插件，感觉就像在逛一个巨大的应用商店，什么都有，什么都想试试。

但繁荣背后，问题也很快暴露出来。首先是质量参差不齐。很多插件就是个人开发者花几天时间做出来的demo，功能不稳定、响应速度慢、错误处理几乎没有。我印象最深的是一个号称能查股票行情的插件，第一次用还行，第二次就直接超时，第三次返回了一堆乱码。这种体验多了之后，用户自然就不愿意用了。

其次是调用链路不可控。插件调用涉及模型推理、API请求、结果解析等多个环节，任何一个环节出问题都会导致整个流程失败。而且由于插件是第三方提供的，你很难排查到底是模型理解错了，还是插件服务器挂了，还是网络问题。这种“黑盒”感让很多企业用户望而却步。

再就是权限和安全问题。插件需要访问用户的某些数据才能工作，比如订餐插件需要知道你的位置，购物插件需要访问你的购物车。但用户很难判断一个插件到底需要哪些权限、这些权限会被怎么使用。虽然平台有一些审核机制，但面对海量插件，审核的覆盖面和深度都有限。

2.3 插件开发实战：从零到一的关键步骤

虽然插件生态有这样那样的问题，但如果你现在要做一个类似的能力扩展，插件的设计思路仍然很有参考价值。我以自己做过的一个“会议安排助手”插件为例，把关键步骤拆解一下。

第一步：定义能力边界。不要想着做一个“万能助手”，那只会让模型困惑。明确你的插件只做一件事，比如“根据参会人空闲时间推荐会议时间”。能力越聚焦，调用准确率越高。

第二步：编写OpenAPI规范。这是插件的“说明书”，模型会根据它来生成调用请求。关键是要把每个接口的用途、参数含义、返回值格式写清楚。我一般会用一个/schedule接口，接收参会人列表、时间范围、会议时长三个参数，返回推荐的时间段列表。

第三步：实现服务端逻辑。这部分就是常规的后端开发，用任何语言都可以。核心是要做好错误处理，因为模型可能会传入各种奇怪的参数，你的服务要能优雅地返回错误信息，而不是直接崩溃。

第四步：编写ai-plugin.json描述文件。这个文件决定了模型在什么情况下会调用你的插件。我的经验是，description_for_model要写得像给一个聪明但不懂业务的实习生解释一样，既要说清楚能力，也要说清楚限制。

第五步：测试和调优。这是最耗时的环节。你需要反复测试各种用户表达方式，看模型是否能正确触发插件调用。我当时的做法是准备50个不同的用户问法，逐一测试，记录调用成功率和返回质量，然后针对性优化描述文件。

{ "schema_version": "v1", "name_for_human": "会议安排助手", "name_for_model": "meeting_scheduler", "description_for_human": "根据参会人空闲时间推荐会议时间", "description_for_model": "当用户需要安排会议、寻找共同空闲时间时调用此插件。输入参会人邮箱列表、时间范围和会议时长，返回推荐的时间段。注意：此插件只能推荐时间，不能直接创建会议。", "api": { "type": "openapi", "url": "https://example.com/openapi.yaml" } }

2.4 插件模式的根本性局限

用了一段时间插件之后，我逐渐意识到一个更深层的问题：插件模式本质上是一种“外挂式”的能力扩展，模型和插件之间是松耦合的。这意味着模型对插件的理解完全依赖于描述文件，而描述文件能承载的信息量是有限的。当插件功能稍微复杂一点，描述文件就说不清楚了，模型调用出错率就会飙升。

另一个问题是执行环境的不可控。插件运行在第三方服务器上，你无法控制它的可用性、响应速度、数据安全。对于企业级应用来说，这是致命的。你不可能把一个核心业务流程建立在一个你无法控制的第三方服务上。

还有一个容易被忽视的问题是上下文断裂。每次插件调用都是一次独立的请求，模型无法在多次调用之间保持状态。比如用户先说“帮我查一下明天的天气”，然后说“那后天呢”，模型需要理解“那后天呢”是在延续上一个问题。但在插件模式下，这种上下文延续需要模型自己维护，而模型并没有一个可靠的机制来做到这一点。

这些局限，直接催生了下一阶段的演进：工具调用。

3. 工具调用时代：把控制权交还给开发者

3.1 Function Calling 的核心突破

OpenAI推出Function Calling的时候，我第一反应是“这才是正确的方向”。和插件模式不同，Function Calling不再要求你把能力部署成一个独立的HTTP服务，而是让你在调用模型时，直接告诉它“我有这几个函数，你可以调用”。模型会根据用户输入，决定是否调用某个函数，并输出结构化的调用参数。然后你在自己的应用里执行这个函数，把结果再传回给模型。

这个转变看似不大，但实际上解决了插件模式的好几个核心问题。第一，控制权回到了开发者手里。函数在你自己应用里执行，你可以完全控制它的行为、权限、错误处理。第二，调用链路更短。不需要经过第三方服务器，减少了故障点。第三，上下文保持更容易。因为整个对话历史都在你的应用里管理，你可以很方便地在多次函数调用之间保持状态。

我印象最深的一次体验，是用Function Calling做一个“数据库查询助手”。用户用自然语言问“上个月销售额最高的产品是什么”，模型自动生成SQL查询语句，我在应用里执行查询，把结果返回给模型，模型再用自然语言解释结果。整个流程非常顺畅，而且因为SQL执行在我自己的环境里，数据安全完全可控。

3.2 从“插件描述”到“函数Schema”的思维转变

Function Calling的使用方式和插件有很大不同，最核心的变化是从写描述文件变成了写JSON Schema。你需要为每个函数定义一个Schema，包括函数名、参数列表、参数类型、参数描述等。模型会根据这个Schema来决定是否调用以及如何调用。

这个转变对开发者的要求其实更高了。写描述文件的时候，你可以用自然语言“糊弄”过去；但写Schema的时候，你必须精确地定义每个参数的类型和含义。我刚开始用的时候，经常因为参数类型定义不准确，导致模型生成的调用参数格式错误。比如我把一个应该是字符串的参数定义成了数字，模型就会尝试把“北京”转成数字，结果自然是一团糟。

# 一个典型的Function Calling定义示例 functions = [ { "name": "query_sales_data", "description": "查询指定时间范围内的销售数据", "parameters": { "type": "object", "properties": { "start_date": { "type": "string", "description": "开始日期，格式YYYY-MM-DD" }, "end_date": { "type": "string", "description": "结束日期，格式YYYY-MM-DD" }, "metric": { "type": "string", "enum": ["revenue", "quantity", "profit"], "description": "查询指标：revenue-销售额，quantity-销量，profit-利润" } }, "required": ["start_date", "end_date", "metric"] } } ]

注意：enum字段非常有用，它限制了模型只能从预定义的选项中选择，大大降低了参数错误的概率。如果你的参数有固定取值范围，一定要用enum。

3.3 多轮工具调用的编排与状态管理

Function Calling真正强大的地方在于多轮调用。模型可以在一次对话中多次调用不同的函数，根据前一个函数的结果决定下一步调用什么。这就为实现复杂的业务流程提供了可能。

我做过一个“智能报销助手”的项目，流程是这样的：用户上传发票图片，模型先调用OCR函数提取发票信息，然后调用规则引擎函数判断是否符合报销标准，如果符合，再调用数据库函数写入报销记录，最后调用通知函数告知用户结果。整个流程涉及四个函数的串联调用，模型会根据每一步的结果自动决定下一步做什么。

但这个过程中有一个关键问题：状态管理。模型本身不保存状态，每次调用都是独立的。你需要在自己的应用里维护一个状态机，记录当前流程进行到哪一步、上一步的结果是什么、下一步应该调用什么。我的做法是用一个session对象来保存所有中间状态，每次调用模型时把相关状态作为上下文传进去。

# 简化的多轮调用状态管理示例 class ReimbursementSession: def __init__(self): self.invoice_data = None self.is_valid = None self.record_id = None self.step = "extract_invoice" def process(self, user_input): if self.step == "extract_invoice": self.invoice_data = call_ocr(user_input) self.step = "validate" elif self.step == "validate": self.is_valid = check_rules(self.invoice_data) self.step = "save" if self.is_valid else "reject" # ... 后续步骤

3.4 工具调用在实际项目中的踩坑记录

Function Calling虽然比插件好用很多，但实际项目中还是有不少坑。我挑几个印象最深的说说。

第一个坑是参数幻觉。模型有时候会“编造”一些不存在的参数，或者把参数值填成看起来合理但实际错误的内容。比如用户说“查一下张三的报销记录”，模型可能会生成{"name": "张三", "department": "技术部"}，但你的函数只接受name参数，多出来的department就会导致调用失败。解决办法是在函数实现里做严格的参数校验，忽略未知参数，并对缺失参数给出明确的错误提示。

第二个坑是调用时机误判。模型有时候会在不该调用函数的时候调用，或者该调用的时候不调用。比如用户只是闲聊“今天天气不错”，模型可能误以为要查天气而调用天气函数。这个问题需要通过优化函数描述和提供few-shot示例来缓解。我的经验是在系统提示词里明确写清楚“只有在用户明确要求查询数据时才调用函数，闲聊时不要调用”。

第三个坑是错误处理不完善。函数执行失败时，模型需要知道失败原因才能决定下一步怎么做。如果你的函数只是返回一个空结果或通用错误信息，模型就懵了。正确的做法是返回结构化的错误信息，包括错误类型、错误描述、建议的下一步操作。

4. Claude-Skills：能力扩展的“封装化”新思路

4.1 Skills 到底是什么：从“调用”到“加载”的范式转换

Claude-Skills刚出来的时候，我看了官方文档，第一感觉是“这不就是更高级的Function Calling吗”。但仔细研究之后发现，两者的设计哲学有本质区别。Function Calling的核心是**“调用”——模型决定调用哪个函数，然后你的应用去执行。而Skills的核心是“加载”**——模型直接加载一个技能包，技能包里包含了执行逻辑、知识、工具定义等所有必要信息。

这个区别听起来很抽象，我打个比方你就明白了。Function Calling就像你给一个员工一本电话簿，告诉他“需要联系谁就打哪个电话”，但具体怎么沟通、说什么话，员工自己发挥。Skills就像你给员工一本操作手册，里面不仅写了联系方式，还写了沟通话术、常见问题处理、注意事项，员工照着做就行。

这个转变的意义在于：它把“能力”从一个抽象的函数定义，变成了一个可封装、可复用、可版本管理的实体。你可以把一个复杂的业务流程封装成一个Skill，里面包含多个步骤、多个工具调用、多个条件分支，模型只需要知道“这个Skill是干什么的”，不需要知道内部细节。

4.2 技能包的结构与核心组件

一个典型的Skill包通常包含以下几个部分：

技能描述文件（Skill Manifest）：告诉模型这个技能是干什么的、什么时候应该使用、需要什么输入。这个文件的质量直接决定了模型能否正确识别和使用技能。

执行逻辑（Execution Logic）：技能的具体实现，可以是一段代码、一个工作流定义、或者一组工具调用的编排。这部分是技能的核心，决定了技能的实际能力。

知识库（Knowledge Base）：技能相关的领域知识、规则、示例。这部分可以帮助模型更好地理解技能的使用场景和边界。

工具定义（Tool Definitions）：技能内部使用的工具，比如API调用、数据库查询、文件操作等。这些工具对外部是不可见的，只在技能内部使用。

配置参数（Configuration）：技能的可配置项，比如超时时间、重试次数、权限级别等。

# 一个简化的Skill描述文件示例 name: meeting_scheduler description: 根据参会人空闲时间推荐会议时间 version: 1.0.0 triggers: - "安排会议" - "找共同空闲时间" - "约个会" inputs: - name: attendees type: array description: 参会人邮箱列表 - name: duration type: integer description: 会议时长（分钟） - name: date_range type: object description: 日期范围，包含start和end execution: type: workflow steps: - tool: get_calendars params: users: "{{attendees}}" - tool: find_common_slots params: calendars: "{{steps.get_calendars.output}}" duration: "{{duration}}" range: "{{date_range}}" - tool: rank_slots params: slots: "{{steps.find_common_slots.output}}"

4.3 技能封装相比函数调用的优势与代价

从我的实际使用体验来看，Skills相比Function Calling有几个明显的优势。

第一是复用性更好。一个封装好的Skill可以在不同项目、不同场景中重复使用，不需要每次都重新定义函数和编写调用逻辑。这对于团队协作特别有价值，一个人写好的Skill，其他人直接拿来用就行。

第二是维护成本更低。当业务逻辑变化时，你只需要更新Skill包，所有使用这个Skill的地方都会自动生效。而Function Calling模式下，你可能需要在多个地方修改函数定义和调用代码。

第三是安全性更高。Skill可以在沙盒环境中执行，权限控制更细粒度。你可以精确控制每个Skill能访问哪些资源、能执行哪些操作，降低了安全风险。

但Skills也不是没有代价的。最大的代价是灵活性降低。一旦你把能力封装成Skill，就意味着你接受了一套预定义的输入输出格式和执行流程。如果遇到Skill覆盖不了的边缘情况，你可能需要修改Skill本身，而不是像Function Calling那样灵活地调整调用参数。

另一个代价是学习曲线更陡。Function Calling的概念很简单，就是“定义函数-模型调用-执行函数”。但Skills涉及技能包结构、执行环境、权限模型等多个概念，新手需要花更多时间理解。

4.4 从零构建一个Skill的完整流程

我以“竞品监控”这个场景为例，完整走一遍Skill的构建流程。这个Skill的功能是：定期抓取竞品官网的动态，分析变化内容，生成监控报告。

第一步：定义技能边界。明确这个Skill只做“监控+报告”，不做“自动应对”。输入是竞品官网URL列表和监控频率，输出是变化摘要和报告链接。

第二步：设计技能结构。我把这个Skill拆成三个子模块：抓取模块负责获取网页内容，分析模块负责对比变化，报告模块负责生成摘要。每个模块可以独立测试和替换。

第三步：实现执行逻辑。抓取模块用定时任务触发，分析模块用文本diff算法，报告模块用模板引擎生成HTML。整个流程用工作流引擎编排。

第四步：编写技能描述。这是最关键的一步。描述要写清楚：什么时候触发这个Skill（用户说“监控竞品”或“看看对手有什么新动作”）、需要什么输入（URL列表、频率）、输出什么（变化摘要、报告链接）、有什么限制（只能监控公开页面、不能处理需要登录的页面）。

第五步：测试和迭代。我用三个竞品官网做了两周的测试，发现了一些问题：有些页面是动态加载的，抓取不到内容；有些页面结构经常变，导致diff结果噪音很大。针对这些问题，我在Skill里增加了“动态渲染”和“结构归一化”两个预处理步骤，效果好了很多。

提示：Skill的描述文件要写得像给一个新员工交代任务一样，既要说清楚做什么，也要说清楚不做什么。边界越清晰，模型使用Skill的准确率越高。

5. 能力扩展的工程化落地与选型建议

5.1 三种方案的适用场景对照

经过这几个项目的实践，我总结了一个选型决策表。这个表不是绝对的，但可以作为参考起点。

我个人的经验是：先用Function Calling快速验证，验证通过后再考虑是否封装成Skill。不要一上来就追求“完美封装”，那样容易过度设计，浪费大量时间在架构上，而不是在验证核心价值上。

5.2 能力扩展的通用架构设计

不管用哪种方案，一个健壮的能力扩展系统通常包含以下几个层次：

接入层：负责接收用户请求，做初步的意图识别和路由。这一层可以用规则引擎，也可以用一个小模型做分类。

编排层：负责决定调用哪些能力、以什么顺序调用、如何处理中间结果。这一层是核心，决定了系统的智能程度。

执行层：负责实际执行工具调用或技能加载。这一层要处理好错误、超时、重试、并发等问题。

数据层：负责存储对话历史、执行日志、技能配置等数据。这一层要保证数据的一致性和可追溯性。

监控层：负责监控整个系统的运行状态，包括调用成功率、响应时间、错误分布等。这一层对于生产环境至关重要。

# 一个简化的能力扩展架构示例 class CapabilityOrchestrator: def __init__(self): self.router = IntentRouter() self.executor = ToolExecutor() self.memory = ConversationMemory() self.monitor = MetricsCollector() def process(self, user_input, session_id): # 1. 意图识别 intent = self.router.classify(user_input) # 2. 获取上下文 context = self.memory.get_context(session_id) # 3. 决定调用哪个能力 capability = self.select_capability(intent, context) # 4. 执行 try: result = self.executor.execute(capability, user_input, context) self.monitor.record_success(capability) except Exception as e: result = self.handle_error(e, capability) self.monitor.record_failure(capability, e) # 5. 更新上下文 self.memory.update(session_id, user_input, result) return result

5.3 性能、安全与可维护性的平衡

在实际项目中，能力扩展系统面临的最大挑战不是“能不能做”，而是“做得好不好”。性能、安全、可维护性这三个维度，往往需要权衡。

性能方面，最大的瓶颈通常是模型推理延迟和工具调用延迟。模型推理延迟取决于模型大小和部署方式，工具调用延迟取决于外部系统的响应速度。我的优化经验是：能并行调用的工具就并行调用，能缓存的結果就缓存，能预加载的技能就预加载。

安全方面，核心是权限控制和数据隔离。每个能力应该只能访问它需要的资源，不能越权。技能之间应该相互隔离，一个技能的故障不能影响其他技能。用户数据应该在会话结束后及时清理，避免泄露。

可维护性方面，关键是模块化和可观测性。每个能力应该是独立的模块，可以单独测试、单独部署、单独升级。系统应该记录详细的执行日志，方便排查问题。技能应该有版本管理，方便回滚和灰度发布。

注意：不要为了追求“智能”而牺牲“可控”。一个80%准确率但完全可控的系统，比一个95%准确率但经常出错的系统更有价值。在生产环境中，可预测性比绝对准确率更重要。

5.4 我踩过的三个大坑与应对策略

第一个坑：过度依赖模型判断。我早期做过一个系统，完全依赖模型来决定调用哪个工具。结果模型经常“想太多”，把简单问题复杂化。后来我加了一层规则引擎，对于高频、明确的意图直接用规则路由，只有复杂意图才交给模型判断。效果立竿见影，响应时间降了40%，准确率反而升了。

第二个坑：忽视错误处理。我一开始觉得“模型这么聪明，出错也能自己处理”。结果有一次一个工具调用超时，模型等了30秒后返回了一个“抱歉，我无法完成这个请求”的回复，用户体验极差。后来我加了超时控制和降级策略，工具调用超过5秒就返回“正在处理中，请稍后”，同时后台继续执行，完成后主动通知用户。

第三个坑：技能包版本混乱。有一次我更新了一个Skill的逻辑，但没有更新版本号，导致线上系统加载了旧版本的缓存，行为不一致。排查了半天才发现是版本管理的问题。后来我强制要求每次修改Skill都必须更新版本号，并且在加载时校验版本一致性。

6. 从能力扩展看大模型工程的未来走向

6.1 能力扩展正在成为大模型应用的“标配”

回顾这几年的演进，我有一个很强烈的感受：能力扩展已经从“加分项”变成了“必选项”。早期你做一个大模型应用，能聊天就行；现在你做一个大模型应用，不能调用外部工具、不能执行业务流程，根本没人用。用户已经被各种智能助手“惯坏了”，他们期望的是“说一句话就能把事情办了”，而不是“说一句话得到一段操作指南”。

这个趋势对开发者的影响是深远的。以前你只需要懂模型、懂提示词就行；现在你还需要懂API集成、懂工作流编排、懂权限管理、懂错误处理。大模型工程正在从一个“算法问题”变成一个“系统工程问题”。我见过不少算法背景的开发者，模型调得很溜，但一到工程落地就抓瞎。反过来，有后端经验的开发者，在能力扩展这块反而更有优势。

6.2 技能生态可能带来的新机会

Claude-Skills这类技能封装机制，我觉得最值得关注的是它可能催生一个技能交易市场。就像手机应用商店一样，开发者可以把自己封装的技能发布出来，其他开发者可以直接购买或订阅。这会大大降低能力扩展的门槛，让更多团队能够快速构建复杂的智能应用。

我甚至觉得，未来可能会出现专门做“技能开发”的团队，就像现在有专门做App开发的团队一样。他们不训练模型，也不做应用，就专注于把某个垂直领域的能力封装成高质量的Skill。这个方向对于中小团队来说，可能比自己做模型、做应用更现实。

另一个机会是技能编排工具。当技能数量多起来之后，如何组合、编排、调度这些技能就成了一个专门的问题。我预计会出现一些可视化的技能编排平台，让非技术人员也能通过拖拽的方式构建复杂的智能工作流。

6.3 给不同阶段开发者的学习建议

如果你是刚接触大模型开发的新手，我的建议是先从Function Calling入手。它的概念简单、上手快、反馈直接，能让你快速理解“模型+工具”的基本模式。不要一上来就搞复杂的技能封装，那样容易迷失在架构细节里。

如果你已经有一定经验，正在做企业级应用，那重点研究Skills的封装和治理。包括技能的生命周期管理、版本控制、权限模型、监控告警等。这些工程化能力，才是企业级应用和demo之间的真正差距。

如果你是在做技术选型决策，我的建议是不要非此即彼。Function Calling和Skills不是互斥的，完全可以混合使用。简单的、多变的工具用Function Calling，复杂的、稳定的流程用Skills。关键是建立一套统一的编排层，让上层应用不需要关心底层用的是哪种机制。

最后分享一个我自己的体会：能力扩展的核心不是技术，而是对业务的理解。你只有真正理解了一个业务场景的流程、规则、异常情况，才能设计出好用的能力扩展方案。技术只是手段，业务价值才是目的。我见过太多技术很炫但没人用的“智能助手”，问题往往出在开发者没有真正理解用户需要什么。