最近一年AI 做 PPT 的能力已经强到不需要人帮忙排版。真正稀缺的能力正在从“把信息摆到页面上”变成“告诉模型怎么处理信息”。围绕这个变化一个新职业方向正在成型——AI 技能工程师。他们不做演示文稿不画架构图而是为大模型和 Agent 编写一组组可复用的技能在什么场景触发、按什么步骤执行、调用哪些工具、输出如何验收、失败如何回退。这套工作跟传统提示词工程有关但比提示词更重。提示词只是“一句话讲清楚需求”技能则是“一句话 上下文 工具调用 校验逻辑”的完整组合。它像软件工程里的模块化封装只不过执行者是模型而不是代码。这篇文章不从概念讲起直接从如何落地讲起技能工程师交付什么、用什么格式写、怎么接 API、怎么批量验证效果、上线后如何维护。读完你可以在现有大模型 API 或 Agent 平台上搭出第一个可交付的 AI 技能并量化它的稳定性、成本和边界。1. 技能不是提示词也不是工作流先理清三个概念。很多人把技能和提示词混为一谈实际上它们的粒度完全不同。层次粒度示例复用性提示词一条指令“把下面文本总结成三条要点”低技能一组完整能力“会议纪要转写、结构化、提取待办、生成摘要”高工作流多技能串联的流程“新员工入职信息收集、合同生成、审批提醒”更高提示词解决的是单次对话问题。技能解决的是重复发生、需要稳定输出的业务问题。工作流则把多个技能按业务规则编排起来形成一条流水线。举个例子。你写一句话让模型“写一份周报”这是提示词。如果把周报做成技能它需要包含输入字段本周工作事项、阻塞问题、下周计划系统指令按公司周报模板输出重点写结果而不是过程工具调用从项目管理系统拉取任务状态校验规则输出是否包含“完成进度”“风险”“下一步”三个模块兜底策略如果原始输入太乱先让模型整理输入再生成周报。这就是技能。它把一个稳定的业务场景固化成文件之后任何一次调用都是同一套标准。2. 技能工程师的交付物清单从职业角度理解技能工程师不是“写提示词的人”而是“把业务转译成模型指令的人”。技术门槛不高但需要很强的需求拆解能力和逻辑严谨度。2.1 核心能力速览能力项说明核心工作需求拆解、指令设计、工具接入、效果评估、版本维护输入材料文本、文档、结构化数据、API 返回结果、用户上下文输出物技能描述文件、提示词模板、工具定义、测试用例、评测报告工具栈YAML/JSON、Markdown、Python、大模型 API、Agent 平台部署方式Agent 平台配置、企业内部 API 服务、模型 Function Calling批量任务通过脚本批量跑评测用例汇总准确性、成本、延迟典型门槛不需要会训练模型需要理解业务、写清楚逻辑、会看日志适合场景办公自动化、客服问答、数据分析、文档处理、内容审核辅助2.2 一份完整的技能交付应该包含什么需求说明这个技能解决什么问题输入是什么输出给谁用技能定义文件用结构化格式描述技能名称、参数、步骤和指令提示词模板模型的系统提示和用户提示包含变量占位符工具接口定义如果技能需要调用外部系统定义好 API 参数测试用例集至少 10 到 20 条覆盖正常、边界、异常场景的输入评测结果用同一批用例跑多轮记录输出质量、耗时和 token 消耗版本记录每次修改了什么、为什么修改、是否影响已有输出。把这些交付物管理好技能才能从“个人手里的一句话”升级为“团队可维护的数字资产”。3. 需求拆解从业务问题到技能步骤写技能的第一步不是写提示词而是拆需求。需求拆得越细后续调试成本越低。以“会议纪要生成”为例完整拆解下来至少包含这些子步骤输入获取接收录音文件或转写文本文本适配如果输入是录音先调用语音转写内容结构化把流水账按“议题、讨论、结论、待办”分类待办提取识别负责人、截止时间、跟进事项摘要生成按听众角色生成不同长度的摘要质量校验检查是否遗漏关键决策是否出现幻觉输出格式化按预设模板输出 Markdown 或 Word。这些子步骤中哪些可以直接由大模型完成哪些需要调用外部工具哪些需要用户人工确认把每个步骤都标注清楚技能的结构就出来了。拆解完成后把步骤转成技能设计。可以用一个简单的 YAML 描述name: meeting_minutes_skill version: 1.0.0 description: 生成结构化会议纪要支持录音转写和文本输入 input: meeting_title: type: string required: true audio_path: type: string required: false transcript: type: string required: false audience: type: string enum: [single, team, executive] default: team steps: - transcribe_audio - structure_discussion - extract_action_items - generate_summary - validate_output - format_output output_schema: meeting_summary: string discussion_points: array action_items: - owner: string deadline: string task: string这里用 YAML 做演示是说明“技能应该被结构化”并不是说所有平台都必须用 YAML。实际落地时根据目标平台的配置格式调整即可。4. 指令设计把模型当作新员工来培训技能的核心仍然是指令设计但这里的指令不是一句话而是一套完整的“员工手册”。4.1 系统提示的结构一个可执行的系统提示通常包含四层。第一层是身份与目标。告诉模型它是什么角色这次任务要达成什么目标。第二层是输入说明。模型需要知道用户会传什么字段每个字段是什么含义哪些字段允许为空。第三层是处理规则。这是最关键的一层。要写出“如果遇到 X就执行 Y”的规则而不是给一句抽象要求。第四层是输出约束。指定输出格式、长度、必须包含的模块以及禁止出现的内容。你是一个会议纪要编写助手。 用户会提供会议标题、讨论内容文本以及听众类型。 处理规则 1. 将讨论内容按“议题、结论、分歧点”分类。 2. 如果原文缺少结论标记为“待确认”不要自行编造。 3. 从讨论中提取所有带负责人或时间信息的待办事项。 4. 根据听众类型调整摘要长度 - single输出 100 字以内 - team输出 300 字以内 - executive只输出决策和风险50 字以内。 输出要求 使用 Markdown 格式必须包含 meeting_summary、discussion_points、action_items 三个模块。 禁止输出与会议无关的内容。如果无法判断输出“信息不足请补充”。这种系统提示的作用是让模型在面对不同输入时走同一套决策路径。它的价值不在文采而在于规则覆盖度。4.2 函数调用与外部工具定义很多技能必须接入外部系统。这个时候要用到 Function Calling 或工具调用机制。以提取待办为例定义一个“创建待办”的函数{ name: create_action_item, description: 在项目管理系统中创建一条待办事项, parameters: { type: object, properties: { task_title: { type: string, description: 待办事项标题 }, assignee: { type: string, description: 负责人 }, due_date: { type: string, description: 截止日期格式 YYYY-MM-DD }, priority: { type: string, enum: [high, medium, low] } }, required: [task_title, assignee] } }模型会根据上下文决定是否调用这个函数并自动填充参数。技能工程师需要做好的是字段定义足够明确、枚举值足够完整、必要字段尽量少减少模型“填错参数”的概率。工具接入的通用原则是能结构化传给工具的数据不要丢给模型自由发挥能从工具返回的数据尽量写进下一次模型上下文里。5. 批量测试与效果评估技能写完不能只测一两个样例。输出不稳定是大模型应用的常态必须通过批量测试掌握真实水平。5.1 建立测试用例集测试集要覆盖四类输入正常输入符合预期形态的典型数据边界输入超长文本、空字段、特殊符号、多语言混排异常输入内容缺失、格式混乱、包含明显错误信息对抗输入诱导模型输出虚构结论、忽略限制条件。每个用例至少记录输入、期望结果、判断标准。判断标准尽量客观比如“必须包含 3 个待办事项”“不能出现编造的负责人”。5.2 批量评估脚本批量测试不需要复杂框架用 Python 脚本即可。下面是一个通用模板实际接口地址和参数需要根据你使用的模型服务调整。import json import time import requests API_URL your_llm_api_endpoint API_KEY your_api_key case_file test_cases.json result_file eval_results.jsonl def call_skill(payload): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } start time.time() response requests.post(API_URL, headersheaders, jsonpayload, timeout60) latency time.time() - start return response.json(), latency def main(): with open(case_file, r, encodingutf-8) as f: cases json.load(f) results [] for case in cases: try: output, latency call_skill(case[payload]) results.append({ case_id: case[id], latency_ms: round(latency * 1000, 2), output: output, error: None }) except Exception as e: results.append({ case_id: case[id], latency_ms: 0, output: None, error: str(e) }) with open(result_file, w, encodingutf-8) as f: for item in results: f.write(json.dumps(item, ensure_asciiFalse) \n) if __name__ __main__: main()跑完脚本后人工或使用另一个模型做结果校验统计三个指标通过率合格输出数 / 总用例数平均延迟多次调用的平均响应时间单次成本同批用例的总 token 消耗 / 用例数。如果一个技能在 20 条用例中通过率低于 80%不要急着上线先回到指令设计层修规则。5.3 输出稳定性观察对同一条输入连续跑三次如果三份输出结构差异很大说明指令约束不足。常见做法是增加输出模板示例或者增加“必须按给定结构输出”的强约束语句。更激进的做法是让模型先生成 JSON 结构再渲染成自然语言。另一种稳定性问题是“内容幻觉”。模型可能补全一个不存在的会议结论。缓解手段是在指令中明确“只基于用户提供的上下文回答不要补充外部猜测”同时在校验规则中加入“关键信息必须能在原文中找到依据”的要求。6. 部署与上线技能如何被使用技能上线有两种常见形态。第一种是配置在 Agent 平台或企业内部工作台里。用户通过对话触发技能平台负责调度模型、工具和记忆。这种方式适合客服、办公助手、知识问答等场景。第二种是把技能封装成 API 服务。自己写一个轻量服务接收请求参数、调用大模型接口、返回结果。这种方式适合深度集成到现有业务系统比如生产工具的自动单据生成、数据分析报告生成。如果采用 API 服务的形态目录结构可以规划成skills/ meeting_minutes/ 1.0.0/ skill.yaml prompt.md schema.json test_cases.json support_ticket/ 1.0.0/ skill.yaml prompt.md schema.json test_cases.json scripts/ evaluate.py deploy.py技能文件放进 Git 仓库每次修改走版本管理评估脚本与技能文件放在一起。这样团队协作时每个人都能看到技能当前版本和对应的评测数据。7. 成本与性能观察大模型技能的成本和性能需要持续观察重点看四个维度。7.1 Token 消耗技能设计中容易忽略的是指令本身也在消耗 token。系统提示写得越长每次调用固定开销越大。每次优化技能时都应该记录系统提示长度与输出 token 的关系避免用高开销换小提升。7.2 延迟技能涉及外部工具调用时延迟会叠加。比如先调语音转写、再调模型、再创建待办每一步都可能增加 1 到 3 秒。优化思路包括把不需要模型处理的步骤放到模型调用之前或之后对必须串行的步骤做合并对可以并行的调用改成并行。7.3 失败重试批量任务里偶发超时和限流是常见问题。评估脚本需要对失败请求做重试并区分“模型输出错误”和“网络调用失败”。重试策略建议递增等待时间避免集中重试加重服务负担。7.4 上下文溢出长文档输入时模型可能超过上下文长度限制。常用处理方法是先做分段摘要再把摘要拼起来继续生成。或者在技能设计时直接限制输入长度超出部分提示用户先拆分。更稳妥的判断是把技能输入控制在模型容量的三分之一以内给输出和工具返回留出缓冲。8. 常见问题与排查方法问题现象可能原因排查方式解决方案同一输入输出差异大指令约束不足连续跑三次看输出结构增加输出模板示例强制指定结构模型生成虚构内容缺少“只依据上下文”的约束检查指令是否允许外部知识补全增加来源限制增加校验规则工具参数总是填错参数定义不清晰查看模型实际传入的参数精简参数增加 enum 约束给出示例长文本处理报错超过上下文限制记录输入长度与报错信息分段摘要或限制输入长度批量任务经常超时单次请求耗时长统计各用例延迟分布增大超时时间增加并发控制成本增长过快指令过长或输出无约束统计 token 消耗精简系统提示限制输出长度模型不按步骤执行指令顺序描述不清复读指令看模型理解把步骤编号增加“严格按顺序执行”上线后质量下降输入分布与测试集差异大对比线上输入与测试集补充线上真实用例重新评估9. 安全、隐私与合规边界技能工程带来效率提升的同时也扩大了模型出错的影响面。设计技能时以下几点必须提前确认。9.1 数据与隐私如果技能处理的是客户信息、员工信息、合同数据要明确数据是否能发送到外部模型服务。不能直接处理的场景先做字段脱敏再调用模型。能采用私有化部署模型解决敏感数据的优先考虑私有化方案。9.2 内容授权与版权技能如果生成营销文案、研究报告、宣传材料需要确认素材来源授权。不要让模型直接改写受版权保护的图片、文章、音视频内容。生成结果对外发布前需要经过人工复核。9.3 误导与滥用任何面向内部决策或外部用户的技能都必须加入“人工确认环节”。技能可以生成草稿但最终决策需要人来确认。防幻觉、防伪造、防绕过限制的检查应该写进技能评估用例而不是依赖模型自觉。9.4 文档与可审计性上线后的技能必须有版本记录、调用日志、输出留档。如果某个技能在某次运行中产生错误结果要能回溯是哪一版指令导致的、被谁调用过。这不是可选项而是工程化底线。10. 从“做内容的人”转型为“写技能的人”如果你现在的工作是整理信息、做汇报材料、维护流程文档转做技能编写并不需要从头学编程但需要完成四个思维转变。第一从“把信息排版好看”到“把处理逻辑讲清楚”。模型不关心版式关心的是条件和动作。你的工作重心从“美化”变为“定义”。第二从“一次性交付”到“持续迭代”。PPT 改一版就结束了技能要反复测试、上线、回滚、更新。它是软件产品不是一页文档。第三从“面向人写”到“面向系统和模型写”。读者不再是会脑补的人类同事而是严格的模型执行器和 API 接口。每句话都要精确到“缺少输入时怎么办”“输出不符时怎么办”。第四从“单打独斗”到“团队协作”。技能会长期被人使用和修改必须有清晰的命名、注释、版本记录。一个人写再好的技能如果别人看不懂也会变成维护负担。11. 给技能工程初学者的四个建议第一先选一个最枯燥、反复发生的业务场景作为练习对象不要一上来就做复杂 Agent。比如周报生成、报销说明生成、售后退款话术整理这些场景规则明确、判断标准清晰。第二先写 20 条测试用例再写技能。测试用例本身就是需求说明书。你会发现很多逻辑漏洞在写用例时就暴露了。第三从“能跑通”到“稳定跑通”之间至少要跨过三个版本。第一版只要能输出正确格式第二版再提高内容质量第三版才优化成本和延迟。不要试图一步到位。第四保留一套最小可运行技能模板。每次写新技能时从模板复制而不是从空白开始。模板里包含系统提示骨架、输入输出 schema、测试用例结构、评估脚本。12. 总结与下一步“新高端职业编写技能而非制作幻灯片”这句话核心不在于职业名称而在于工作方式的转移从整理信息变成构造处理信息的规则。模型负责执行人负责定义边界、步骤、工具和验收标准。这套方法不需要你重新训练模型也不需要掌握底层算法但需要你具备严谨的逻辑和把复杂业务拆成可执行步骤的能力。真正应该最先上手验证的是一个已经反复发生、输出结果可以被明确判断对错的小任务。用文中的模板写出第一个技能定义文件配 10 到 20 条测试用例跑一遍批量脚本记录下通过率、成本和延迟。这一步做通后再逐步增加工具调用、多轮会话、异常兜底这些能力。容易踩的坑是一上来就想写“全能型技能”把大量规则塞进一个提示里结果输出不稳定、排查困难、上线后几乎不敢改。正确的做法是让每个技能职责单一一个技能只解决一类问题。技能之间可以互相调用但不要互相混写。下一步你可以继续深挖的方向包括多工具串联的 Agent 工作流、结构化输出后接入数据库、技能评测的自动化、面向私有数据的检索增强生成。把“技能编写”当成长线能力来打磨它带来的复利会比做一百页演示文稿更明显。