AI技能工程师：从提示词到可复用技能的设计与落地

最近一年，AI 做 PPT 的能力已经强到不需要人帮忙排版。真正稀缺的能力，正在从“把信息摆到页面上”变成“告诉模型怎么处理信息”。围绕这个变化，一个新职业方向正在成型——AI 技能工程师。他们不做演示文稿，不画架构图，而是为大模型和 Agent 编写一组组可复用的技能：在什么场景触发、按什么步骤执行、调用哪些工具、输出如何验收、失败如何回退。

这套工作跟传统提示词工程有关，但比提示词更重。提示词只是“一句话讲清楚需求”，技能则是“一句话 + 上下文 + 工具调用 + 校验逻辑”的完整组合。它像软件工程里的模块化封装，只不过执行者是模型而不是代码。

这篇文章不从概念讲起，直接从如何落地讲起：技能工程师交付什么、用什么格式写、怎么接 API、怎么批量验证效果、上线后如何维护。读完你可以在现有大模型 API 或 Agent 平台上，搭出第一个可交付的 AI 技能，并量化它的稳定性、成本和边界。

1. 技能不是提示词，也不是工作流

先理清三个概念。很多人把技能和提示词混为一谈，实际上它们的粒度完全不同。

提示词解决的是单次对话问题。技能解决的是重复发生、需要稳定输出的业务问题。工作流则把多个技能按业务规则编排起来，形成一条流水线。

举个例子。你写一句话让模型“写一份周报”，这是提示词。如果把周报做成技能，它需要包含：

• 输入字段：本周工作事项、阻塞问题、下周计划；
• 系统指令：按公司周报模板输出，重点写结果而不是过程；
• 工具调用：从项目管理系统拉取任务状态；
• 校验规则：输出是否包含“完成进度”“风险”“下一步”三个模块；
• 兜底策略：如果原始输入太乱，先让模型整理输入再生成周报。

这就是技能。它把一个稳定的业务场景固化成文件，之后任何一次调用，都是同一套标准。

2. 技能工程师的交付物清单

从职业角度理解，技能工程师不是“写提示词的人”，而是“把业务转译成模型指令的人”。技术门槛不高，但需要很强的需求拆解能力和逻辑严谨度。

2.1 核心能力速览

2.2 一份完整的技能交付应该包含什么

• 需求说明：这个技能解决什么问题，输入是什么，输出给谁用；
• 技能定义文件：用结构化格式描述技能名称、参数、步骤和指令；
• 提示词模板：模型的系统提示和用户提示，包含变量占位符；
• 工具接口定义：如果技能需要调用外部系统，定义好 API 参数；
• 测试用例集：至少 10 到 20 条覆盖正常、边界、异常场景的输入；
• 评测结果：用同一批用例跑多轮，记录输出质量、耗时和 token 消耗；
• 版本记录：每次修改了什么、为什么修改、是否影响已有输出。

把这些交付物管理好，技能才能从“个人手里的一句话”升级为“团队可维护的数字资产”。

3. 需求拆解：从业务问题到技能步骤

写技能的第一步不是写提示词，而是拆需求。需求拆得越细，后续调试成本越低。

以“会议纪要生成”为例，完整拆解下来至少包含这些子步骤：

1. 输入获取：接收录音文件或转写文本；
2. 文本适配：如果输入是录音，先调用语音转写；
3. 内容结构化：把流水账按“议题、讨论、结论、待办”分类；
4. 待办提取：识别负责人、截止时间、跟进事项；
5. 摘要生成：按听众角色生成不同长度的摘要；
6. 质量校验：检查是否遗漏关键决策，是否出现幻觉；
7. 输出格式化：按预设模板输出 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": f"Bearer {API_KEY}", "Content-Type": "application/json" } start = time.time() response = requests.post(API_URL, headers=headers, json=payload, timeout=60) latency = time.time() - start return response.json(), latency def main(): with open(case_file, "r", encoding="utf-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", encoding="utf-8") as f: for item in results: f.write(json.dumps(item, ensure_ascii=False) + "\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. 常见问题与排查方法

9. 安全、隐私与合规边界

技能工程带来效率提升的同时，也扩大了模型出错的影响面。设计技能时，以下几点必须提前确认。

9.1 数据与隐私

如果技能处理的是客户信息、员工信息、合同数据，要明确数据是否能发送到外部模型服务。不能直接处理的场景，先做字段脱敏，再调用模型。能采用私有化部署模型解决敏感数据的，优先考虑私有化方案。

9.2 内容授权与版权

技能如果生成营销文案、研究报告、宣传材料，需要确认素材来源授权。不要让模型直接改写受版权保护的图片、文章、音视频内容。生成结果对外发布前，需要经过人工复核。

9.3 误导与滥用

任何面向内部决策或外部用户的技能，都必须加入“人工确认环节”。技能可以生成草稿，但最终决策需要人来确认。防幻觉、防伪造、防绕过限制的检查，应该写进技能评估用例，而不是依赖模型自觉。

9.4 文档与可审计性

上线后的技能必须有版本记录、调用日志、输出留档。如果某个技能在某次运行中产生错误结果，要能回溯是哪一版指令导致的、被谁调用过。这不是可选项，而是工程化底线。

10. 从“做内容的人”转型为“写技能的人”

如果你现在的工作是整理信息、做汇报材料、维护流程文档，转做技能编写并不需要从头学编程，但需要完成四个思维转变。

第一，从“把信息排版好看”到“把处理逻辑讲清楚”。模型不关心版式，关心的是条件和动作。你的工作重心从“美化”变为“定义”。

第二，从“一次性交付”到“持续迭代”。PPT 改一版就结束了，技能要反复测试、上线、回滚、更新。它是软件产品，不是一页文档。

第三，从“面向人写”到“面向系统和模型写”。读者不再是会脑补的人类同事，而是严格的模型执行器和 API 接口。每句话都要精确到“缺少输入时怎么办”“输出不符时怎么办”。

第四，从“单打独斗”到“团队协作”。技能会长期被人使用和修改，必须有清晰的命名、注释、版本记录。一个人写再好的技能，如果别人看不懂，也会变成维护负担。

11. 给技能工程初学者的四个建议

第一，先选一个最枯燥、反复发生的业务场景作为练习对象，不要一上来就做复杂 Agent。比如周报生成、报销说明生成、售后退款话术整理，这些场景规则明确、判断标准清晰。

第二，先写 20 条测试用例再写技能。测试用例本身就是需求说明书。你会发现很多逻辑漏洞在写用例时就暴露了。

第三，从“能跑通”到“稳定跑通”之间，至少要跨过三个版本。第一版只要能输出正确格式；第二版再提高内容质量；第三版才优化成本和延迟。不要试图一步到位。

第四，保留一套最小可运行技能模板。每次写新技能时，从模板复制，而不是从空白开始。模板里包含系统提示骨架、输入输出 schema、测试用例结构、评估脚本。

12. 总结与下一步

“新高端职业：编写技能而非制作幻灯片”这句话，核心不在于职业名称，而在于工作方式的转移：从整理信息，变成构造处理信息的规则。模型负责执行，人负责定义边界、步骤、工具和验收标准。这套方法不需要你重新训练模型，也不需要掌握底层算法，但需要你具备严谨的逻辑和把复杂业务拆成可执行步骤的能力。

真正应该最先上手验证的，是一个已经反复发生、输出结果可以被明确判断对错的小任务。用文中的模板写出第一个技能定义文件，配 10 到 20 条测试用例，跑一遍批量脚本，记录下通过率、成本和延迟。这一步做通后，再逐步增加工具调用、多轮会话、异常兜底这些能力。

容易踩的坑是：一上来就想写“全能型技能”，把大量规则塞进一个提示里，结果输出不稳定、排查困难、上线后几乎不敢改。正确的做法是让每个技能职责单一，一个技能只解决一类问题。技能之间可以互相调用，但不要互相混写。

下一步你可以继续深挖的方向包括：多工具串联的 Agent 工作流、结构化输出后接入数据库、技能评测的自动化、面向私有数据的检索增强生成。把“技能编写”当成长线能力来打磨，它带来的复利会比做一百页演示文稿更明显。