如果你最近在参与企业AI项目大概会有一种感受真正值钱的不是“把方案讲清楚”而是“让AI能自动把事情做掉”。过去职场人把大量时间花在制作幻灯片上用来向老板、客户和同事解释一件事现在越来越多的岗位开始要求你交付另一种东西——一段可以被AI调用的技能。这里的“技能”不是简历上的形容词而是具体的工具函数、提示模板、Agent工作流或接口服务。它能让AI在收到“生成周报”“分析销售数据”“整理客户反馈”这类指令时自动完成拆解、调用、生成和反馈。相比制作幻灯片编写技能交付的不是“解释”而是“执行”。这个转变正在悄悄改写高端职业的能力定义。本文不会只聊趋势也不会只给一个“要拥抱AI”的结论。我会从技术底层讲清楚什么是技能编写、为什么它比做幻灯片更适合作为长期能力再给出一个可以从零跑通的最小示例包含代码、配置、运行验证和常见坑。就算你还没有真实的模型API也可以先完成技能接口的开发和本地测试。1. 这篇文章真正要解决的问题先问一个现实问题在AI开始大范围接管日常工作的今天哪种能力最不容易被替代答案不是“会用Prompt”也不是“会做漂亮的PPT”而是能把一个模糊的业务需求拆成一套AI可以稳定执行的技能。做PPT的本质是信息整理和呈现这件事大模型已经做得越来越好编写技能的本质则是把业务逻辑、数据访问、异常处理和输出规范固化下来让AI在权限可控的范围内自动完成工作这件事目前仍然非常依赖人。这也是这篇文章要解决的核心问题如何从“给AI下指令”升级为“给AI编写技能”。我们会聊清楚几个关键点技能编写和普通提示词到底有什么区别一个技能通常由哪几个部分组成如何用函数调用Function Calling和接口服务实现一个真实技能如何验证技能是否被正确调用以及失败时怎么排查在团队和项目中技能如何管理、评估和安全上线。适合读这篇文章的读者不只是程序员。AI产品经理、SAAS解决方案架构师、数据运营、售前工程师只要你的工作需要把业务需求翻译成可执行的AI能力都应该理解这一套工作方式。差别只在于研发会写代码实现技能非研发至少需要学会描述技能的输入、输出和边界条件这样才能和工程师高效协作。你不需要一次掌握所有技术细节但看完本文后应该能建立一条清晰的学习路径先写一个最小技能让它被模型调用成功再逐步扩展成可复用的技能库。2. 基础概念与核心原理技能到底是什么在动手之前先统一几个概念。因为关于AI Agent和技能业内术语还比较乱不同平台叫法也不一样。提示词Prompt你发给模型的指令文本。它告诉模型要做什么、按什么格式回答。函数调用Function Calling模型在生成回答时不直接输出最终结果而是先输出一个结构化的“调用请求”比如“调用 get_weather 函数参数 city北京”。真正执行函数的是外部代码或服务模型拿到结果后再组织回答。Agent代理一个能理解目标、规划步骤、调用工具、根据结果继续迭代的AI系统。Agent的“手”就是各种工具或技能。技能Skill把一个任务的标准做法固化下来。它通常包括触发描述、处理步骤、工具函数、模型行为约束和输出格式。本文里我们用“技能”统称这些东西。MCPModel Context Protocol一种开放的工具协议用来让AI客户端发现并调用远程工具。它解决的也是“模型怎么调用外部能力”的问题属于技能接入层的标准化方案。这些概念很容易混在一起但理解它们的关系并不难。你可以把Prompt想象成“说明书”把Function Calling想象成“表单”把技能想象成“一个带说明书的工具箱”把Agent想象成“一个会看说明书并按步骤使用工具箱的实习生”。回到我们的核心问题为什么“编写技能”比“制作幻灯片”更能体现新职业能力对比维度制作幻灯片编写技能交付物PPT文件函数、脚本、接口、配置运行环境人的眼睛AI模型、服务器、业务系统主要价值解释和说服自动化和复用成功标准观众理解并认可系统稳定并正确执行迭代方式改文案、改排版改代码、改Schema、回归测试可复用性低换场景基本重做高同一技能多处调用“技能”的核心原理可以从一次完整调用说起。当用户说“帮我生成上周销售周报”时模型本身并不知道上周销售数据是什么。它需要先判断这个问题需要调用fetch_sales_data这个工具参数是last_week。模型输出一个结构化的工具调用请求外部代码执行真正的数据查询把结果返回给模型模型再把这些数据组织成一篇通顺的周报。技能编写者真正要做的是让这个链条里的每一环都可控选择该调用哪个函数、函数参数如何设计、返回结果如何校验、模型拿到的数据如何防止篡改或泄漏。这些工作远比调整一页PPT的字体和布局复杂也因此更有职业壁垒。3. 环境准备与前置条件我们用一个“销售周报生成器”作为贯穿示例。它不算复杂但足够展示技能编写的关键环节定义工具函数、暴露为HTTP接口、让模型在需要时调用。3.1 运行环境建议使用Python 3.10及以上版本。如果本机没有安装可以先安装Python或者使用Conda创建一个独立环境。下面命令中不写死具体版本号以你环境可用的版本为准。python -m venv .venv source .venv/bin/activate # Windows 下使用.venv\Scripts\activate3.2 安装依赖我们要用FastAPI把技能函数暴露成HTTP接口用Uvicorn启动服务用OpenAI SDK演示模型侧调用。如果你没有真实模型API也可以只启动接口服务并用curl测试不影响理解。pip install fastapi uvicorn openai python-dotenv requests安装完成后建议在项目根目录创建.env文件放置模型API密钥。# 文件路径.env OPENAI_API_KEY你的密钥注意.env文件不要提交到Git仓库。如果你用了版本管理建议创建.gitignore并加入.env。3.3 是否必须准备真实模型API没有真实模型API也可以跑通本文大部分内容。技能本身的执行逻辑是普通Python代码完全可以在本地验证模型只会负责任务理解和参数抽取。如果只是开发调试你可以先不用OpenAI SDK直接用curl调用自己写的接口。接入真实模型时再把模型侧代码加上即可。如果你使用的是国内模型平台比如通义、智谱、DeepSeek等它们大多提供OpenAI兼容接口代码结构基本相同只需要改base_url、api_key和model三个地方。本文以OpenAI风格接口为例不代表具体厂商。4. 核心流程拆解一个技能是怎么被设计出来的编写技能不是直接写几行代码而是先做任务分析。很多人第一步就写错了看到需求就开写函数结果模型不知道怎么调用或者参数设计不合理。4.1 第一步明确输入和输出接到“生成销售周报”这个需求时先不要想模型怎么生成正文而是想清楚用户最终要什么一份包含概况、趋势和下一步行动的中文周报。完成这份周报需要什么数据销售总额、订单数、新客数、时间范围。这些数据从哪来可能是数据库、数仓也可能是第三方CRM接口。我们先用模拟数据代替。输出格式是什么Markdown正文供用户复制到文档或邮件。这个环节的输出是一份技能设计说明。它不一定要写到文档里但必须在脑子里清楚。4.2 第二步拆任务决定哪些交给模型哪些交给代码模型适合做归纳、总结、组织语言代码或接口适合做计算、查库、权限校验。所以不要把“查数据库”的逻辑写进Prompt里也不要用模型去自己编数据。正确做法是定义一个工具函数负责查数据模型负责在需要时调用它。这是很多初学者最容易犯的错让模型用训练数据里学到的知识编一份“销售周报”结果数据全是幻觉。真正可用的Agent数据必须来自真实执行结果。4.3 第三步定义函数签名和JSON Schema模型的Function Calling并不是读你的源码而是读一份JSON Schema。Schema里必须说清楚函数名称简短、语义化比如fetch_sales_data函数描述告诉模型何时调用这里就是“查询指定时间范围的销售汇总数据”参数说明参数名、类型、是否必填、可取值约束能用枚举就用枚举比如this_week和last_week避免模型自由发挥。Schema写得好不好直接决定模型是否调用得准。描述里要包含业务语义但不要啰嗦。参数越少、约束越明确模型越不容易出错。4.4 第四步实现执行逻辑和兜底工具函数本身要足够健壮。比如传入未知的date_range要抛出明确异常连接数据库失败要有重试或备用方案返回的数据必须符合模型后续使用的预期。这一层最容易出问题。很多AI项目挂在模型不会调用工具上最后发现真正原因是函数内部异常太多导致调用链崩溃。技能发布前先用普通单元测试覆盖函数本身不要让AI帮你测代码。4.5 第五步测试模型调用链路技能上线前至少要测出三个问题的答案模型在什么上下文中会调用我的工具如果一个闲聊问题也触发了工具说明描述写得太宽泛。模型传的参数是否正确如果它总是传错字段说明Schema示例不够清楚或枚举覆盖不全。工具返回结果后模型能否正确组织最终回答如果模型拿到数据后仍然答非所问说明后续的Prompt约束不够。这五步完成一个技能才算开发完成。下一章我们直接看代码。5. 完整示例销售周报技能代码实现5.1 定义技能工具函数与JSON Schema首先创建一个目录skills在里面放sales_tool.py负责定义数据获取函数和对应的Schema。# 文件路径skills/sales_tool.py def fetch_sales_data(date_range: str): 模拟从数仓查询销售汇总数据。 真实项目中可以把这里的实现替换为数据库查询、 第三方接口调用或消息队列任务。 if date_range this_week: return { date_range: this_week, total_revenue: 186000, orders: 512, new_customers: 83, } if date_range last_week: return { date_range: last_week, total_revenue: 128000, orders: 342, new_customers: 57, } raise ValueError(f暂不支持日期范围{date_range}) TOOLS [ { type: function, function: { name: fetch_sales_data, description: 获取指定时间范围的销售汇总数据用于生成销售周报。, parameters: { type: object, properties: { date_range: { type: string, enum: [this_week, last_week], description: 希望查询的时间范围仅支持本周和上周。 } }, required: [date_range] } } } ]这段代码包含两个关键部分。fetch_sales_data是技能真正的执行单元TOOLS是给模型看的能力描述。模型不会运行Python代码它只读取TOOLS里的结构决定要不要在回复里请求调用函数。5.2 用FastAPI暴露技能接口为了让外部AI客户端或Agent系统可以调用这个技能我们用FastAPI把它包装成HTTP接口。这样做的好处是技能可以与模型解耦任何能发HTTP请求的客户端都能使用。# 文件路径app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from skills.sales_tool import fetch_sales_data app FastAPI(titleWeekly Report Skill) class ToolRequest(BaseModel): name: str arguments: dict app.post(/tools/fetch_sales_data) def call_sales_tool(req: ToolRequest): if req.name ! fetch_sales_data: raise HTTPException(status_code400, detail未知工具) date_range req.arguments.get(date_range) if not date_range: raise HTTPException(status_code400, detail缺少 date_range 参数) try: data fetch_sales_data(date_range) return {success: True, data: data} except ValueError as e: raise HTTPException(status_code400, detailstr(e))这段代码的关键在于接口层不关心调用方是谁只关心参数是否符合契约。收到合法请求就执行函数并返回结果收到非法参数就返回明确的错误信息。真实项目里这里还应该加入鉴权、限流和审计日志。5.3 模型侧调用让AI决定何时使用技能这一节需要真实模型API。如果你暂时没有key可以先跳过后续再回来验证。下面的代码演示了最基础的流程模型先看到用户的周报请求然后决定调用fetch_sales_data我们执行函数后把结果回传给模型模型生成最终周报。# 文件路径run_skill.py import json import os from dotenv import load_dotenv from openai import OpenAI from skills.sales_tool import TOOLS, fetch_sales_data load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def run(): messages [ { role: system, content: 你是一名销售周报助手。如果用户需要数据请先调用 fetch_sales_data 获取数据再输出周报。, }, { role: user, content: 请帮我生成上周的销售周报包含销售趋势判断。, }, ] # 第一轮模型可能返回工具调用请求而不是最终答案 response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, ) message response.choices[0].message # 如果模型决定调用工具 if message.tool_calls: for tool_call in message.tool_calls: if tool_call.function.name fetch_sales_data: args json.loads(tool_call.function.arguments) result fetch_sales_data(args[date_range]) # 注意要把模型的调用请求追加回对话再把工具结果追加为 tool 消息 messages.append(message) messages.append( { role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse), } ) # 第二轮模型拿到数据后生成最终周报 second_response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, ) print(second_response.choices[0].message.content) else: print(message.content) if __name__ __main__: run()这段代码是理解Agent技能调用的最小骨架。它没有处理多轮连续调用但你已经能看到核心链路模型调用工具、代码执行、结果回传、模型组织答案。后续要做的Agent框架本质上是在这个循环上增加状态管理和任务规划。5.4 技能元信息配置示例除了代码技能还需要一份面向人类的“说明书”。很多Agent平台都支持用配置文件描述技能的触发条件和行为约束。我们用一个通用的YAML示例帮助你理解这种抽象# 文件路径skill.yaml name: weekly_report_writer description: 根据销售数据生成周报 version: 1.0.0 trigger: - 生成周报 - 写周报 - 上周销售 tools: - fetch_sales_data prompt: | 你是一名数据分析助理。请根据用户要求先调用 fetch_sales_data 获取数据 再输出包含【本周概况】【趋势判断】【下一步行动】的周报。 Markdown 格式不要虚构没有的数据。配置文件和代码分离的好处是产品经理可以维护触发描述和业务说明工程师维护函数逻辑。技能的“版本”也便于追溯和回滚。6. 运行结果与效果验证技能开发完成后不要急着直接连模型先验证接口本身。6.1 启动接口服务在项目根目录执行uvicorn app:app --reload启动成功后终端会显示服务地址通常是http://127.0.0.1:8000。6.2 用curl测试技能接口打开另一个终端发送测试请求curl -X POST http://127.0.0.1:8000/tools/fetch_sales_data \ -H Content-Type: application/json \ -d {name:fetch_sales_data,arguments:{date_range:last_week}}预期返回{ success: true, data: { date_range: last_week, total_revenue: 128000, orders: 342, new_customers: 57 } }这个结果说明技能接口本身可用参数传递正确函数执行成功。这是后续一切AI能力的基础。如果这一步报错问题大概率出在函数内部逻辑或参数解析和模型无关。6.3 接入模型后如何验证成功如果你执行了run_skill.py需要观察两件事第一轮模型返回的tool_calls列表中是否出现了fetch_sales_data第二轮模型生成的周报是否基于真实返回的数据而不是自己编造。你可以在run_skill.py的第二次请求前后加打印也可以通过日志平台记录完整请求。正常情况下最终输出应该是类似下面的结构【本周概况】 上周销售总额为128000订单量342新增客户57人。 【趋势判断】 相比本周如果有对比数据上周整体数据偏低建议关注新客转化。 【下一步行动】 1. 复盘上周渠道投放效果。 2. 加强重点客户回访。这里我不给出具体生成文本因为不同模型语言风格会不一样。关键验证点是数字不能来自模型记忆必须来自fetch_sales_data的返回值。7. 常见问题与排查思路技能开发中最麻烦的不是写函数而是“模型不按预期工作”。下面这些坑基本每个项目都会遇到。问题现象可能原因排查方式解决方案模型不调用工具直接编数据工具描述不够清晰或用户请求未触发模型判断查看请求和工具Schema给工具加“何时使用”说明在函数描述里写明触发场景示例提问引发调用模型调用了工具但参数缺失JSON Schema约束太少模型认为参数可选检查必填项查看模型输出的funny arguments将参数设为required使用枚举限制可选值工具调用后最终回答依然错误工具结果格式太复杂模型没理解打印传给模型的工具结果人工查看可读性简化返回字段或用中文字段名注释接口报404或400请求路径和代码路由不一致查看FastAPI日志确认接口路径和请求方法对齐路由名称必要时加健康检查接口同一功能在多个技能里重复实现缺乏技能管理团队各写各的检查技能仓库和文档建立技能目录统一Schema版本管理用户恶意指令绕过约束技能没有做权限隔离检查有无漏洞例如让模型帮忙“把数据导出到任意地址”对高权限操作增加人工确认限制目标地址白名单模型调用工具速度很慢网络请求、模型推理、工具执行串行观测链路耗时分布将工具调用改为并行或优化工具执行耗时密钥写死在前端或仓库忽略敏感信息管理扫描仓库关键词使用环境变量和密钥管理服务这里特别强调一个安全风险不要以为“模型只会干好事”。如果你给Agent开放了删除、写入、转账之类的工具一定要加授权确认。最小权限原则在AI时代同样适用甚至更重要因为用户可以通过注入恶意指令间接操纵Agent调用工具。8. 最佳实践与工程建议技能编写这件事看起来只是“写个函数”但要真正工程化还有很多细节值得注意。8.1 技能要小但边界要清不要试图做一个覆盖所有办公场景的超级技能。正确做法是拆成多个小技能查销售数据一个查客户信息一个生成周报一个。小技能便于测试、便于替换、便于判断错误。边界清晰后Agent在规划时更容易选择正确技能。8.2 函数描述即产品文档模型不会读你的代码注释它只读JSON Schema里的名称和描述。所以函数描述里的每一句话都要服务于“帮模型做判断”。描述要写清楚“什么时候调用”而不是“这个函数来自哪个部门”。参数描述同样重要枚举值要说明业务含义。8.3 输出保持结构化技能函数的返回值最好使用稳定的JSON结构。不要返回一团自然语言也不要让模型自己决定用什么结构。因为下游可能有多个Agent复用同一个技能结构越稳定后续处理和评估越容易。8.4 日志是做AI应用的刚需传统的接口日志可能只需要记录状态码和耗时但AI技能调用还需要记录用户原始输入、模型是否请求工具、工具参数、工具返回结果、最终输出、token消耗。只有把这套链路完整记录下来才能回答“为什么这次回答不对”这类问题。8.5 技能需要测试集和回归真正把技能作为产品的团队不会只靠人工点两下验证。要给每个技能准备一组固定输入比如“上周销售周报”“空数据”“非法日期范围”每次变更都跑一遍确认模型仍然能正确调用工具、参数仍然正确、输出仍然符合格式。AI模型升级后也要重新跑测试集因为模型版本变化可能导致工具调用行为改变。8.6 安全边界必须前置在技能设计阶段就要想清楚权限问题。低频场景下可以先让AI生成结果人工确认后再执行。高频场景下要确保只读技能不能访问写接口写接口要有审计和审批。对用户的输入要做基本的注入检测防止提示词污染导致工具在不期望的情况下被调用。9. 总结与后续学习方向从“制作幻灯片”到“编写技能”变化的不是工具而是工作交付物的性质。幻灯片帮人理解一件事技能让系统自动完成一件事。AI时代真正稀缺的能力是后者把一个模糊需求拆解成输入、输出、边界条件再固化成一个可以被模型稳定调用的执行单元。如果你要从今天开始实践最低成本的起步方式不是买各种Agent工具而是先做一个最小技能定义一个函数写清Schema启动一个本地接口用curl验证它。然后再尝试接入真实模型观察模型是否会调用你的技能。这整个过程其实就是AI应用开发的第一块基石。接下来值得深入的方向有三个第一学习Function Calling的进阶用法比如多工具并行、流式输出第二了解MCP等工具协议看如何把技能标准化方便多个Agent复用第三学习Agent工作流编排理解多步骤任务中技能之间如何协作和容错。每一块展开都是大课题但核心认知不会变AI不会替你定义什么是“正确的事”写技能的人才是那个把正确性编进系统的人。