1. 从单点工具到组合拳为什么你需要一个AI工作台很多人用AI的方式还停留在“打开一个对话框问一个问题复制答案关掉”的阶段。这种用法不是不行但效率天花板极低。你每次都在重新交代背景、重新设定角色、重新调整输出格式大量时间浪费在重复的“热身”动作上。而真正把AI用出生产力的人早就不这么干了。他们做的事情用一句话概括就是把多个Skill组合起来搭一个属于自己的AI工作台。所谓Skill你可以把它理解成一个“技能包”或者“能力插件”。一个Skill负责一件事——比如专门做会议纪要整理、专门做代码审查、专门做竞品分析、专门做周报生成。单独一个Skill已经能解决一个具体问题但真正的威力在于把它们串起来、叠起来、编排起来形成一个自动化的工作流。这就是“AI工作台”的核心思路。这篇文章适合谁看三类人第一类是对AI工具有基本使用经验但还没形成系统工作流的职场人第二类是正在探索Agent开发、想理解Skill编排逻辑的技术爱好者第三类是已经在用各种AI平台但觉得每次都要手动切换、重复输入、效率上不去的重度用户。不管你是哪一类接下来的内容都会给你一套可以直接抄作业的方案。我自己的AI工作台从最初的两三个Skill到现在稳定运行十几个Skill的编排链路中间踩了不少坑也总结出了一些只有实际用过才知道的门道。下面我把整套思路和实操细节拆开讲。2. 核心思路拆解Skill组合的底层逻辑2.1 单个Skill的局限性在哪里先说说为什么单个Skill不够用。假设你有一个“写周报”的Skill它的提示词写得很好能根据你提供的工作内容生成结构清晰的周报。但实际使用中你会发现几个问题第一输入不规范。你每次给它的原始信息格式都不一样有时候是零散的几句话有时候是一堆会议记录有时候是任务清单。Skill本身如果没有预处理能力输出质量就会波动。第二上下游断裂。周报写完之后你可能还需要把它转成邮件格式发给领导或者提取关键数据填入项目管理系统。这些动作如果每次都手动做Skill的价值就被稀释了。第三缺乏上下文积累。一个好的周报应该能体现你本周和上周工作的连续性但单次调用的Skill没有记忆每次都是从零开始。这三个问题的本质是单个Skill只能完成一个原子操作而真实工作流是多步骤、有依赖、需要上下文传递的。所以我们需要组合。2.2 组合的基本模式串行、并行与条件分支Skill组合不是简单地把几个Skill排在一起就完事了。根据我实际搭建的经验常见的组合模式有三种串行模式是最基础的。Skill A的输出作为Skill B的输入B的输出再给C。比如原始语音转文字 → 文字整理成结构化笔记 → 笔记提炼成行动项 → 行动项分配责任人并生成通知。这条链路上每一步都依赖上一步的结果顺序不能乱。并行模式适合处理独立子任务。比如你拿到一份长文档同时需要“提取关键数据”“生成摘要”“检查合规风险”三个结果。这三个任务互不依赖可以并行调用三个Skill最后汇总。并行模式的关键是汇总环节的设计——你得有一个“合并Skill”来整合多路输出否则结果就是散的。条件分支模式是进阶玩法。根据上一步的输出内容决定下一步走哪条路。比如一个“客户反馈处理”工作流如果反馈是投诉类走“投诉处理Skill”如果是咨询类走“知识库检索Skill”如果是建议类走“产品需求整理Skill”。这种模式需要你在编排层写清楚判断条件。我自己的工作台里三种模式都有用到。最常用的是串行加并行的混合结构——先串行做预处理和清洗然后并行跑几个分析Skill最后串行做汇总和格式化。2.3 为什么强调“属于自己的”工作台市面上有很多现成的AI工作流平台为什么还要自己搭核心原因是通用方案解决通用问题但你的工作流是独特的。你的行业术语、你的输出格式偏好、你的审批流程、你常用的数据源——这些东西没有哪个平台能完全适配。自己搭工作台的过程本质上是在把你的隐性知识显性化、把你的工作习惯结构化。一旦搭好它就是一个完全贴合你个人工作方式的效率引擎。而且自己搭的工作台是可迭代的。你今天发现某个环节输出不好改一下那个Skill的提示词就行明天有了新的需求加一个Skill进去就行。这种灵活性是现成平台给不了的。3. 搭建前的准备工作别急着写提示词3.1 梳理你的高频工作流很多人一上来就开始写Skill的提示词这是典型的本末倒置。正确的第一步是拿出纸笔列出你每周重复三次以上的工作流程。注意关键词是“重复三次以上”。偶尔做一次的事情不值得做成Skill因为投入产出比不划算。只有高频、重复、有固定模式的工作才值得自动化。我当初梳理的时候列了二十多条然后按频率和复杂度筛了一遍最后留下八条核心工作流。这八条覆盖了我日常80%的重复性工作。你可以用下面这个表格来梳理工作流名称触发频率单次耗时涉及步骤数是否适合Skill化会议纪要整理每天2-3次15分钟4步非常适合竞品动态追踪每周1次60分钟6步适合周报生成每周1次30分钟3步适合代码Review每天1次20分钟2步适合临时数据查询不定期5分钟1步不太适合这张表的关键作用是帮你分清优先级。先做那些频率高、步骤多、耗时长的效果立竿见影。3.2 确定你的技术底座“技术底座”这个词听起来很唬人其实就是在问你打算在哪里跑这些Skill目前主流的选择有几类。一类是直接用大模型平台的对话界面通过系统提示词来定义Skill手动串联。这种方式门槛最低但自动化程度也最低适合刚起步的阶段。另一类是用支持工作流编排的平台可以可视化地拖拽节点、连接Skill、设置条件分支。这种方式适合有一定技术基础、想要更高自动化程度的用户。还有一类是自己写脚本调用API把Skill编排逻辑写在代码里。这种方式最灵活但需要编程能力。我的建议是从第一类开始逐步过渡到第二类有需要再上第三类。不要一上来就追求全自动先把单个Skill打磨好再考虑编排。3.3 建立你的提示词素材库在正式搭建之前还有一个准备工作非常重要建一个提示词素材库。什么意思就是把你平时用得好的一些提示词片段、输出格式模板、角色设定语句统一存到一个地方。比如你常用的角色设定“你是一位有十年经验的财务分析师擅长用通俗语言解释复杂财务概念”你偏好的输出格式“用Markdown表格输出列名为项目、现状、风险、建议”你常用的约束条件“不要使用专业术语如果必须使用请用括号解释”这些东西在你写每个Skill的时候都会反复用到。提前整理好写Skill的时候直接拼装效率会高很多。我自己的素材库分了四个文件夹角色设定、输出模板、约束条件、示例样本。每次写新Skill从这四个文件夹里各取所需十分钟就能拼出一个可用的初版。4. 核心Skill的设计与实现细节4.1 输入预处理Skill把脏活累活干掉在任何工作流里输入预处理都是最不起眼但最重要的环节。原始输入往往是脏的——格式混乱、信息冗余、关键信息埋在废话里。如果预处理没做好后面的Skill再强也是垃圾进垃圾出。我设计的输入预处理Skill主要做三件事第一格式归一化。不管你丢进来的是语音转文字、手打笔记、还是复制的聊天记录统一转成结构化的Markdown格式。这一步的关键是定义好“结构化”的标准。我的标准是标题、时间、参与人、正文、待办事项五个字段。所有输入都往这五个字段里塞。第二信息去噪。去掉语气词、重复内容、无关寒暄。这一步看起来简单但提示词要写得很细。比如我会明确告诉模型“删除所有‘嗯’‘啊’‘那个’‘就是说’等语气词删除与工作内容无关的闲聊如果同一信息出现多次只保留最完整的一次表述。”第三关键信息提取。从去噪后的内容里提取出人名、时间节点、数字、决策结论这四类关键信息单独列出来。这一步的目的是为后续Skill提供“索引”。这个Skill的提示词我改了十几版才稳定下来。最大的坑是不要试图让一个Skill同时做归一化和提取。我一开始图省事把两个任务写在一个提示词里结果模型经常顾此失彼。后来拆成两个独立的Skill串行执行稳定性大幅提升。4.2 核心处理Skill每个只做一件事核心处理Skill是整个工作台的主体。设计原则只有一条一个Skill只做一件事做到极致。我见过很多人写Skill恨不得一个提示词解决所有问题。结果就是每个环节都做得马马虎虎。正确的做法是拆——把一个大任务拆成若干个原子任务每个原子任务对应一个Skill。举个例子“竞品分析”这个大任务我拆成了四个Skill信息采集Skill从指定来源抓取竞品动态输出原始信息列表分类归档Skill把原始信息按“产品更新”“市场动作”“人事变动”“融资情况”分类影响分析Skill针对每条信息分析对我方产品的潜在影响报告生成Skill把分析结果整合成结构化报告每个Skill的提示词都很短但很精准。比如分类归档Skill的提示词核心就一句话“将以下信息按产品更新、市场动作、人事变动、融资情况四类归档每类下按时间倒序排列如果某条信息同时属于多个类别只归入最相关的一类。”这种“短提示词单一职责”的设计好处是调试极其方便。哪个环节出问题直接改那个Skill就行不会牵一发而动全身。4.3 输出格式化Skill让结果直接可用很多人忽略了输出格式化的重要性。辛辛苦苦跑出来的结果格式乱七八糟还得手动整理一遍自动化就失去了意义。输出格式化Skill的核心任务是把上游Skill的输出转成你最终需要的格式。这个格式可能是邮件正文、可能是PPT大纲、可能是Excel表格的CSV格式、可能是即时通讯工具的消息格式。我常用的输出格式化Skill有三个邮件格式化把内容转成正式邮件格式包含称呼、正文、落款、附件说明表格格式化把内容转成Markdown表格或CSV方便直接粘贴到表格软件消息格式化把内容转成适合在即时通讯工具里发送的短段落格式每段不超过三行这三个Skill的提示词里我都会加上具体的格式示例。比如邮件格式化Skill里我会贴一个完整的邮件模板作为参考。模型看到示例输出格式的准确率会高很多。4.4 质量检查Skill最后一道防线质量检查Skill是我踩了很多坑之后才加上的。它的作用是在输出最终结果之前自动检查一遍常见问题。检查项包括是否有事实性错误比如把A的数据安到B头上、是否有格式错误比如表格列数不对、是否有遗漏比如要求输出五个点只输出了三个、是否有敏感信息比如不小心把内部数据带出来了。这个Skill的提示词设计有个技巧不要让它“检查并修改”而是让它“检查并报告”。因为让模型同时做检查和修改它往往会为了修改而修改把原本正确的内容改错。正确的做法是让它输出一份检查报告列出发现的问题然后由你决定是否修改或者再跑一个专门的修改Skill。5. 实操从零搭建一个会议纪要工作台5.1 场景定义与流程设计光讲理论没意思我拿一个最常用的场景——会议纪要整理——来完整走一遍搭建过程。先定义场景你每天要参加多个会议会议有录音转文字的记录你需要把记录整理成结构化的会议纪要提取行动项分配给责任人并生成一封通知邮件。整个流程拆成五步输入预处理把原始录音转文字整理成结构化文本信息提取提取会议主题、参与人、讨论要点、决策结论、行动项行动项分配给每个行动项指定责任人和截止时间纪要生成整合成标准格式的会议纪要邮件生成把纪要转成通知邮件对应五个Skill串行执行。5.2 每个Skill的提示词设计与参数说明Skill 1输入预处理提示词核心逻辑你是一个文本预处理助手。输入是一段会议录音转文字的内容。 请完成以下操作 1. 删除所有语气词嗯、啊、那个、就是说、然后呢等 2. 删除重复表述同一信息只保留最完整的一次 3. 按发言顺序整理每段发言标注发言人如果能识别 4. 输出格式纯文本每段发言之间空一行这个Skill不需要输出结构化数据只需要把文本洗干净。参数上我设置了“温度”为0.3因为预处理不需要创造性越稳定越好。Skill 2信息提取提示词核心逻辑你是一个会议信息提取助手。输入是一段清洗后的会议记录。 请提取以下信息并以JSON格式输出 - 会议主题一句话概括 - 参与人列表 - 讨论要点列表每条不超过50字 - 决策结论列表 - 行动项列表每条包含事项描述、建议责任人、建议截止时间 如果某项信息在原文中没有明确提及对应字段填“未提及”。这个Skill的输出是结构化的JSON方便后续Skill解析。温度设为0.2因为提取任务需要高准确性。Skill 3行动项分配提示词核心逻辑你是一个任务分配助手。输入是行动项列表和参与人列表。 请为每个行动项指定责任人规则如下 1. 如果原文中已明确责任人保持不变 2. 如果未明确根据行动项内容与参与人职责的匹配度推荐 3. 如果无法判断标记为“待确认” 同时根据行动项的紧急程度建议截止时间 - 紧急24小时内 - 重要3个工作日内 - 常规本周内 输出格式Markdown表格列名为行动项、责任人、截止时间、优先级这个Skill需要一点判断力温度设为0.5给它一定的灵活空间。Skill 4纪要生成提示词核心逻辑你是一个会议纪要撰写助手。输入是会议主题、参与人、讨论要点、决策结论、行动项表格。 请生成一份标准格式的会议纪要格式如下 # 会议纪要 ## 基本信息 - 主题 - 时间 - 参与人 ## 讨论要点 分点列出 ## 决策结论 分点列出 ## 行动项 表格形式 要求语言简洁正式不添加原文没有的信息。温度设为0.3保持稳定输出。Skill 5邮件生成提示词核心逻辑你是一个邮件撰写助手。输入是一份会议纪要。 请生成一封通知邮件格式如下 主题【会议纪要】 会议主题 正文 各位好 以下是本次会议的纪要请查阅。 粘贴会议纪要正文 如有疑问请随时沟通。 此致 敬礼 要求邮件正文中不要重复“会议纪要”标题直接放内容。温度设为0.4。5.3 串联与调试第一次跑通全流程五个Skill写完之后先别急着串联。逐个单独测试确保每个Skill在典型输入下都能稳定输出。我的测试方法是准备三组测试数据——一组标准输入格式规范、信息完整、一组边界输入信息缺失、格式混乱、一组极端输入超长文本、多语言混杂。每个Skill都要在这三组数据上跑通。单独测试通过后开始串联。串联的时候最容易出的问题是格式不兼容——Skill A输出的JSONSkill B解析不了Skill C输出的表格Skill D当成纯文本处理了。解决方法是在每两个Skill之间加一个“格式转换”说明。比如在Skill 2和Skill 3之间我会明确告诉Skill 3“输入是JSON格式包含以下字段...”。这样模型就知道该怎么解析上游的输出。第一次跑通全流程大概花了两个小时中间调试了七八次。主要卡在行动项分配的准确性上——模型有时候会把行动项分配给不相关的人。后来我在提示词里加了一条“如果行动项涉及多个参与人选择职责最相关的一人作为主责任人其他人列为协作人。”这个问题就基本解决了。5.4 效果验证与迭代优化跑通之后我用了两周时间来验证和迭代。每天的实际会议记录都跑一遍记录哪些环节输出好、哪些环节需要手动修改。两周下来发现三个高频问题第一行动项提取有遗漏。有些行动项藏在讨论过程中没有用“行动项”这个词明确标出。解决方案是在Skill 2的提示词里加一条“注意识别隐含的行动项比如‘这个事谁来跟进一下’‘下周之前需要搞定’等表述。”第二责任人分配有时不合理。模型倾向于把任务分配给发言最多的人而不是最相关的人。解决方案是在Skill 3的提示词里加入参与人的职责描述作为参考。第三邮件格式偶尔跑偏。有时候会加上一些不必要的客套话。解决方案是在Skill 5的提示词里加一条“不要添加原文没有的客套话保持简洁。”迭代三次之后整个工作流的准确率从最初的70%左右提升到了90%以上。剩下的10%主要是极端情况手动改一下就行。6. 常见问题与排查技巧实录6.1 Skill之间“打架”怎么办这是组合使用中最常见的问题。表现是Skill A的输出被Skill B误解或者Skill B的输出风格被Skill C带偏。根本原因是Skill之间的边界不清晰。每个Skill都应该有明确的“输入契约”和“输出契约”——我接受什么格式的输入我保证输出什么格式的结果。排查方法把每个Skill的输入输出单独打印出来逐个检查。如果发现某个Skill的输出格式不稳定就在它的提示词里加格式约束并且给出明确的示例。我自己的经验是在提示词里加一句“无论输入如何你的输出必须严格遵循以下格式”然后附上格式模板。这句话能解决80%的格式漂移问题。6.2 输出质量不稳定的排查思路同样的输入有时候输出很好有时候输出很差。这种波动性在组合工作流里会被放大——上游一个小波动下游可能变成大偏差。排查步骤先定位是哪个Skill的输出不稳定。逐个Skill单独跑看哪个环节的波动最大。检查那个Skill的提示词是否有歧义。常见的歧义来源包括任务描述不够具体、格式要求不够明确、缺少示例。调整温度参数。需要稳定输出的Skill温度调到0.2-0.3需要一定灵活性的0.4-0.6需要创造性的0.7以上。如果还不行考虑把那个Skill拆成两个更细的Skill。我遇到过一个典型案例一个“摘要生成”Skill有时候输出三句话有时候输出三段话。后来发现是提示词里写了“简洁摘要”但没定义“简洁”的标准。改成“输出不超过100字分2-3句话”之后就稳定了。6.3 性能瓶颈与优化方向当Skill数量多起来之后整个工作流的执行时间会变长。如果每个Skill平均需要10秒十个Skill串行就是100秒体验就很差了。优化方向有几个并行化把互不依赖的Skill改成并行执行。比如“信息提取”和“情感分析”可以同时跑不用一前一后。缓存对于重复的输入缓存上一次的输出结果。比如同一份会议记录如果跑了两次第二次直接返回缓存结果。精简Skill定期审查每个Skill看是否有可以合并的。有些Skill拆得太细反而增加了编排开销。异步执行对于耗时长的Skill改成异步调用不阻塞主流程。等结果出来再通知。我自己的优化经验是先把串行链路跑通再考虑并行化。不要一上来就追求极致性能那样会陷入过度设计的陷阱。6.4 常见问题速查表问题现象可能原因排查方法解决方案输出格式错乱提示词格式约束不明确检查该Skill的格式要求加格式模板和示例信息遗漏提取规则不够细对比输入输出找遗漏点补充提取规则上下游不兼容输入输出契约不清晰打印中间结果检查明确每个Skill的输入输出格式输出波动大温度参数过高调低温度重试温度调到0.2-0.3执行时间过长串行Skill过多分析依赖关系并行化无依赖的Skill责任人分配错误缺少职责信息检查参与人描述补充职责字段7. 进阶玩法让工作台自己“长”出新能力7.1 Skill的版本管理与回滚当你有了十几个Skill之后管理就成了问题。改了一个Skill可能影响下游三个Skill。没有版本管理出了问题都不知道回滚到哪个版本。我的做法是每个Skill的提示词都存成独立文件用日期版本号命名。比如meeting-preprocess-v3-20250115.md。每次修改都新建一个版本不覆盖旧版本。同时在文件头部记录修改原因和影响范围。这样做的成本很低但收益很大。有一次我改了一个提取Skill的规则导致下游三个Skill的输出全部异常。因为保留了旧版本五分钟就回滚了。7.2 用“元Skill”自动生成新Skill这是一个比较进阶的玩法写一个“Skill生成器”Skill它的输入是你对某个新任务的自然语言描述输出是一个完整的Skill提示词。比如你输入“我需要一个Skill能把英文技术文档翻译成中文并且保留专业术语的英文原文。”这个元Skill就会输出一个包含角色设定、任务描述、格式要求、示例的完整提示词。这个玩法的好处是降低新Skill的创建门槛。你不需要每次都从零开始写提示词只需要描述需求就行。当然生成的提示词还需要你手动微调但至少有了一个不错的起点。我自己的元Skill提示词核心逻辑是你是一个Skill设计专家。用户会描述一个任务需求。 请生成一个完整的Skill提示词包含以下部分 1. 角色设定一句话 2. 任务描述分步骤 3. 输入格式说明 4. 输出格式说明附示例 5. 约束条件至少三条 6. 异常处理至少两条 输出格式Markdown可直接复制使用。7.3 工作流的监控与日志当工作流跑在后台自动执行时你需要知道它有没有出问题。我的做法是每个Skill执行后都写一条日志记录执行时间、输入摘要、输出摘要、是否成功。日志不需要很复杂一个简单的文本文件就行。关键是格式要统一方便后续检索。我的日志格式是[时间戳] [Skill名称] [状态] [输入摘要] [输出摘要] [耗时]有了日志之后排查问题就快多了。哪个Skill经常失败、哪个Skill耗时最长、哪个Skill的输出经常被下游拒绝一目了然。7.4 从个人工作台到团队协作当你自己的AI工作台跑顺了之后很自然会想到能不能让团队也用起来我的经验是先个人跑通再团队推广。个人跑通的标准是连续两周每天使用准确率稳定在90%以上。达到这个标准之后再把Skill分享给团队。团队协作的关键是统一输入输出标准。每个人的使用习惯不同如果输入格式五花八门Skill的稳定性就会下降。所以推广之前先制定一个简单的使用规范——比如“所有会议记录统一用XX格式提交”“所有输出统一用XX模板”。另外团队使用时要特别注意权限管理。有些Skill可能涉及敏感数据不是所有人都能用。我的做法是给Skill打标签分为“公开”“团队”“个人”三级不同级别对应不同的使用权限。8. 我踩过的坑与实战心得8.1 不要追求“大而全”的工作台我一开始的野心很大想搭一个覆盖所有工作场景的超级工作台。结果花了大量时间在编排上每个Skill都做得不精。后来砍掉了三分之二的Skill只保留最高频的八个反而效果好得多。少即是多。一个精炼的、每天都能用上的工作台比一个庞大但很少跑通的工作台有价值得多。8.2 提示词不是越长越好新手容易犯的错误是把提示词写得非常长恨不得把所有可能的情况都写进去。结果模型被过多的约束搞晕了输出反而更差。我的经验是提示词的长度和任务的复杂度成正比但有一个上限。单个Skill的提示词控制在300-500字比较合适。超过这个长度就要考虑拆分成多个Skill。8.3 定期“体检”你的工作台工作台搭好之后不是一劳永逸的。你的工作内容会变AI模型会更新原来的Skill可能慢慢就不适用了。我每个月会做一次“体检”把每个Skill单独跑一遍看输出是否还符合预期。如果某个Skill连续三次输出不理想就标记为“待优化”安排时间修改。这个习惯帮我避免了很多“温水煮青蛙”式的问题——Skill慢慢变差但你一直没发现直到某天出了大问题才意识到。8.4 保持手动兜底的能力不管工作台多智能永远要保留手动处理的能力。我见过有人完全依赖自动化工作流结果某天模型服务出问题整个工作就瘫痪了。我的做法是关键环节保留手动入口。比如会议纪要工作流如果自动生成的结果不理想我可以手动修改任何一个环节的输出然后继续往下跑。这种“半自动”的模式比“全自动但不可控”要实用得多。8.5 记录每一次“意外的好结果”有时候模型会输出一些超出预期的好结果——比如一个特别精准的总结、一个特别巧妙的分类方式。这些“意外的好结果”往往包含了有价值的提示词改进方向。我的习惯是遇到这种情况立刻把输入和输出都保存下来分析是什么提示词设计导致了这么好的结果。然后把这个发现应用到其他Skill上。这个习惯让我的Skill质量在三个月内提升了一个档次。9. 关于Agent与Skill的关系顺便聊几句最近很多人都在讨论Agent好像Agent是一个全新的东西。但在我看来Agent本质上就是Skill组合的高级形态。一个Agent拆开来看就是一组Skill加上一个编排层。编排层负责决定什么时候调用哪个Skill、怎么传递参数、怎么处理异常。Skill负责执行具体的任务。你把我前面讲的Skill组合玩明白了再去看Agent框架会发现底层逻辑是相通的。所以我的建议是不要一上来就搞Agent先把Skill组合玩透。Skill组合是基本功Agent是进阶。基本功不扎实直接上Agent大概率是搭了一个跑不通的花架子。另外关于“Agent安全”这个话题我的看法是在个人工作台阶段安全风险主要来自两个方面——一是敏感数据不小心被发送到外部服务二是自动执行的操作超出了预期范围。对于第一点我的做法是在预处理Skill里加一个“敏感信息检测”步骤发现敏感内容就标记出来由我决定是否继续。对于第二点我的做法是给所有“写操作”类的Skill加上确认环节不自动执行等我确认后再跑。这些做法不复杂但能避免很多麻烦。毕竟工作台是为你服务的不是给你添乱的。