1. 为什么我要给 AI 助手攒一組可复用的 Skills而不是每次现场发挥先说结论把 10 个高频动作固化成 Skills 之后我处理日常杂活的效率大概翻了一倍。这个翻倍不是说 AI 变聪明了而是我把自己变懒了——每次开新会话不用再重复交代背景、要求、输出格式直接一个触发词喊出来它就知道该按什么套路干活。WorkBuddy 是我自己搭的一套助手配置工作台底层接的是通用大语言模型接口上面套了一层自定义指令管理。你可以把它理解成一个预装指令集的遥控器每个 Skill 就是遥控器上的一个按钮。按钮背后存的不只是一段提示词还包括触发条件、输出模板、使用示例以及我最常踩的坑和规避方式。我最早不用 Skills 的时候典型流程是这样的复制一篇长文粘贴给助手先写帮我总结一下然后它给了一个一百字的泛泛总结我再补一句要分点、要保留关键数据它又改一版还是不够细再追加按背景、分析、结论三个部分输出……一轮下来光调提示词就花了十分钟等我回过神来还不如自己看完自己写。后来我把高频动作拆开看发现日常真正在反复用的其实就十类读长文、提炼事实、找资料、出创意、写结构稿、改口播、润色邮件、拆任务、做排期、写复盘。每一类单独做成一个 Skill用的时候直接触发助手一次性按我预设的规则输出我再在里面做删改而不是从零开始和它磨。设计 Skill 时我给自己定了四个原则这里先说一下后面每个具体示例都会贯彻第一单一职责。一个 Skill 只干一件事不要在摘要里顺带叫它顺便给点写作建议它一旦多线程就容易两头都干不好。第二输入契约明确。每个 Skill 都要写清楚你给我什么我还你什么避免它自作主张去猜。第三输出模板固定。提前定好标题、分点、列表、表格这些结构让它按模板填内容而不是每次重新发明排版。第四示例必须更新。模型能力在变工具也在变隔几个月就要把 Skill 里的示例输出翻新一遍否则会照着旧逻辑给你过时答案。这套思路在你自己的工作环境里也一样适用不管你是用现成的助手平台还是自己封装 API只要能把提示词触发条件输出模板示例组合成可复用模块本质上就是在做同一件事。2. 十个 Skills 全景图先看清每颗按钮的用途再谈怎么配在逐个拆解之前我先把十个 Skills 摆在一张表里方便你对照自己的需求来选。这十个技能我按工作流分成三大侧输入侧负责把信息吃透输出侧负责把想法变成稿子执行侧负责把目标拆成可落地的行动。分类Skill 名称触发词示例输出形态典型使用场景输入侧长文摘要/summary三段式要点论文、行业报告、政策文件输入侧事实提炼/facts字段化表格会议记录、访谈、聊天记录输入侧检索辅助/research搜索词 信源清单写文章前划定搜索边界输出侧创意脑暴/brainstorm发散清单 收敛排序想选题、想方案、想切入角度输出侧结构化写作/write大纲 分段落稿写方案、写长文、写说明文档输出侧口播稿改写/script口语化脚本视频口播、音频分享、开场白输出侧邮件润色/email得体邮件正文商务沟通、催办、道歉、同步执行侧任务拆解/wbs可验收任务树项目启动、目标落地执行侧日周排期/schedule时间表 缓冲区间制定当日 / 本周计划执行侧阶段复盘/review结构复盘报告周报、项目收尾、季度总结我刻意把输入侧放在最前面是因为大多数低效对话都发生在信息输入环节原文没梳理清楚后面所有生成内容都会跟着歪。你先让助手把一段材料吃透把关键事实、矛盾点、决策信息提取出来再喂给后面的写作、拆解类技能整个链路就稳了。选择这十个而不是更多的原因也很直白其他技能我试过比如让它起名、翻译、做心理测试耍着玩可以但无法稳定进入日常生产流。真正能让我效率翻倍的反而不是花哨能力而是那些我每天都会重复、但现在能让助手一次到位的脏活累活。你完全可以按自己行业替换其中几个但先把我这套骨架搭起来再换零件会容易很多。3. 输入侧三个 Skills让 AI 先把信息吃透后半场才不翻车3.1 长文摘要核心不是压缩而是按需提取决策信息很多人用摘要技能时只说一句帮我总结这篇文章结果助手给它一个四平八稳的概括既不解决阅读效率问题也不解决决策问题。我的/summary设计的是三段式先给结论再给论据最后给和我有什么关系。触发语/summary 功能对粘贴进来的长文本输出三段式摘要 要求 第一段用 4 行以内说清文本的主题、核心结论、站在谁的角度写的 第二段用无序列表列出 5 到 8 个关键论据每个论据后标注它在原文中的大致位置 第三段单独列出 2 条对决策最有用的信息并说明它能直接回答什么判断。 约束 - 不添加原文之外的事实 - 如果原文内部有矛盾数据必须明确指出并引用原文片段 - 不要输出本文是一篇……这类废话开头。这里有一个容易被忽略的细节站在谁的角度写的尤其关键。同样一份行业分析报告投资人读到的决策信息、运营人员读到的执行信息完全不一样。我在设计 Skill 时强制它先判断作者立场和读者视角后面提炼的要点会准很多。一个我实际用过的例子是处理一份三万字的产品体验报告中第一段直接点出读者的结论是该功能整体可用但注册环节流失率异常存在三个未验证假设第二段列出证据时我一眼就能定位哪些段落需要重读第三段给出的决策信息直接接上了下一周的产品评审。如果你觉得三万字太长也可以在这个 Skill 前面加一个分段提问的步骤让助手先给一个一分钟版本的摘要满意后再展开细读。但这属于补充用法基础配置用上面的模板就够了。3.2 事实提炼从会议记录里抽出谁、何时、做了啥、下一步长文摘要管的是文章事实提炼管的是对话记录。我最常用它处理两类输入一类是会议转录文本一类是群聊里零散交代的事项。直接让助手把重要信息提取出来不行输出会变成一个段落复述找不到重点。我把输出强行改成字段表。触发语/facts 功能从对话记录中提取结构化事实 要求 输出一张 Markdown 表格列包括事项 / 涉及人 / 时间点 / 结论或下一步 / 来源句子。 规则 - 对每个人名、时间、数据原样保留不做猜测 - 时间如果原文只有下周明天标注为未明确需确认 - 发现有相互矛盾的信息时单独在表格下面列矛盾点清单 - 如果对话中有待办事项把所有待办单独再列一个小节按紧急排序。这个模板最初是为一个某跨平台系统项目的周会服务的。过去我开完会要重新听一遍录音把各人的交付时间点一个个手打出来自从用了/facts直接把原始转录文本贴进去表格立刻出来我再花五分钟校对一遍省下的时间至少一小时。需要留意的坑是模型在提取事实时倾向于脑补缺失内容。比如原文说A 将在近期完成接口联调它可能写成本周五完成接口联调。所以我在规则里特意加了来源句子这一列每一行都可以回溯到原始语句还有未明确需确认这种占位符逼着它承认自己不知道。宁可慢一点也不要让它给你造出个假时间点。3.3 检索辅助让助手先生成搜索方案而不是直接搜给你看很多助手工具带联网搜索功能但直接让它搜最近的行业动态出来的内容要么太泛、要么太旧。我后来想明白了一个道理与其让 AI 替我搜索并总结不如让它先生成一套搜索指挥方案我自己拿着方案去各信源里精确捞效率和准确率反而更高。触发语/research 功能给定某个主题生成检索任务清单 要求 1. 给出 8 个精准搜索词分为核心词、限定词、时间词、排除词 2. 给出 5 个相对可信的信源类型并说明从哪个渠道能找到这类信源 3. 列出 3 个可能获取反方观点的搜索方向避免只看单一立场 4. 最后用一句话说明这个主题最容易被忽略的盲区。这个 Skill 的实际价值在于它逼着我去思考什么才算有效搜索。比如想了解某类新工具在中小企业里的落地情况时它给的搜索词会是中小企业 数字化 工具 落地 失败案例 2024其中失败案例是反直觉的关键词能搜出很多站在推销对立面的真实内容反而比单纯搜有哪些好工具有价值得多。有一个经验是/research的搜索结果不要直接拿给助手总结出文章而应该和/facts配合。你先搜到一批材料把材料贴给/summary和/facts让它们各自提取一遍再进入后面的写作链路。这样每一层都有明确输入、明确处理、明确输出整体质量会稳定很多。4. 输出侧四个 Skills把脑子里那团乱麻变成能直接交付的稿子4.1 创意脑暴先发散再收敛别让助手一上来就选最优我以前让助手帮我想十个选题它总能给我十个四平八稳的表达每个都像但每个都平庸。问题出在我给了它想十个这个数量要求它会为了凑数而放弃质量。后来我把/brainstorm设计成了两轮赛制第一轮无差别罗列第二轮按标准淘汰。触发语/brainstorm 功能对一个主题进行创意发散和收敛排序 流程 第一轮列出 12 个方向或想法尽量互不重叠不要评价好坏不要前面的排挤后面的 第二轮按三个标准筛选成本、受众痛点、差异化每次筛掉一个最后剩 3 个 第三轮为保留下来的 3 个分别写一句如果用一句话向别人推荐这个选题怎么说。 约束全程不要使用首先、然后、最后之类的连接词直接列条目。这个设计参考了头脑风暴里常见的两个阶段原则发散时禁止评判收敛时严格执行标准。我实际用它做过一个内容选题规划第一轮的 12 个想法里有几个明显有风险比如直接讲竞品缺陷但第二轮按成本和受众敏感度筛掉之后留下的那个反而成了当时数据最好的一篇内容。要注意的是脑暴 Skill 只负责生想法不负责写全文。很多朋友把脑暴结果直接丢给写作 Skill希望一步到位出一篇文章结果发现风格断裂。正确的做法是脑暴产出的 3 个方向里挑 1 个然后用下一个/write去扩写。4.2 结构化写作把写长文变成填结构而不是对着空白页硬憋结构化写作是我用得最频繁的输出型 Skill适用范围从方案文档、产品说明到汇报材料都能覆盖。它的核心思想是人类更适合在框架里填内容不适合对着空白页从零开始生成所以先让 AI 给框架再在框架基础上做增删。触发语/write 功能根据输入的主题和素材生成可编辑的结构化文稿 参数 - 读者角色例如运营负责人技术评审人普通用户 - 读者目标例如决定是否启动项目了解新功能用法认可这个结论 - 内容基调严谨 / 轻松 / 中立 输出要求 1. 给出文章标题候选项 3 个 2. 给出完整大纲包括一级标题、二级标题和每部分的写作意图 3. 按大纲填充首段和三段示例正文其余段落用占位注释标注应放什么素材 4. 全文不要插入没有来源支撑的数据。为什么强调读者目标和内容基调因为写作中最常见的失败是目标读者错位。一份给技术评审人看的方案应该开门见山说清楚架构取舍给普通用户看的功能说明应该用场景和操作步骤引导。/write在开头先把这两个参数问清楚后面生成的骨架才不至于跑偏。我举个例子某次做跨平台系统升级方案我填的读者角色是技术负责人读者目标是评估该方案是否可以进入开发排期产出的首段直接点明了兼容性范围、改造成本和团队规模假设而不是从一个企业数字化转型的宏大背景讲起。这就是结构与目标匹配带来的差异。4.3 口播稿改写把书面语翻成会说人话的版本做视频或者播客的朋友一定有过这种体验写出来的稿子自己念两遍就觉得不像在讲话。原因很简单书面语和口语是两套系统。口播稿改写的本质不是缩短句子而是把阅读节奏转成听觉节奏。触发语/script 功能将输入的书面文本改写为口语化口播稿 要求 1. 允许保留原文全部关键信息但可以用语气词和口头过渡来衔接 2. 单句尽量控制在 25 字以内逗号太多时拆成两句 3. 避免出现此外综上所述值得注意的是这类书面连接词 4. 在每段话后面加一个语气提示比如[停顿]、[重读]、[放慢]方便录制时参考 5. 口播稿不要太像网络段子保持自然说话感即可。拿走这个 Skill 最直接的收益是改稿效率。以前写一篇两分钟的视频文案写完书面版还要逐句念、逐句改现在直接让/script一遍改写我再对照实际用词习惯微调基本两遍能定稿。有一个细节值得说我在第 4 条里明确禁止网络段子化。之前没加这条时AI 会把所有句子都改成网感十足的短句反而失去了专业感。对内容创作者来说口语化和随意化之间是有明确边界的。4.4 邮件润色语气得体但别让 AI 替你客套到底邮件润色看起来最简单其实是最考验分寸感的 Skill。中文商务邮件的麻烦不在语法而在语气同一件事催对方提交和礼貌提醒对方提交措辞完全不同。如果只给一句帮我写一封催交报告的邮件AI 很容易写成又委婉又啰嗦的客套话反而模糊了重点。触发语/email 功能根据输入邮件类型润色或生成邮件正文 参数 - 邮件类型正式汇报 / 催办 / 道歉 / 同步信息 / 请求支持 - 收件人关系上级 / 平级 / 外部合作方 - 语气强度弱 / 中 / 强 - 要点列表用户在冒号后粘贴希望传达的核心信息 输出要求 1. 第一段交代背景不超过两句话 2. 中间段按要点排序每件事单独占一行 3. 结尾明确写出期待对方回复的行动项和截止时间 4. 没有意义的内容如再次感谢敬请期待之类最多出现一次。我特别想提醒你的是不要让它把多少冒昧打扰百忙之中这类谦辞堆在前面。真正得体的邮件是信息密度高、行动项清楚、语气和善但不卑微。我试过让 AI 把同样一封催办邮件按三种语气强度输出我和同事比较后一致认为中等强度行动项明确的版本效率最高弱语气版本反而让人忽略重点强语气版本则显得冒犯。目前在/email里我最常调用的场景是 催办和同步信息两类因为这两类最容易在沟通里得罪人。把关系字段填清楚它会自动控制分寸省掉了我每次斟酌措辞的精力。5. 执行侧三个 Skills任务拆解、排期、复盘让 AI 帮你盯住项目全流程5.1 任务拆解按可验收结果拆不要按动作拆普通的任务拆解容易拆成了解需求、整理资料、完成代码、测试这种动作列表看起来有步骤实际没法验收。设计/wbs时我要求它按交付物思路来拆每一项任务必须有明确的完成标准。触发语/wbs 功能将目标拆解为可验收的任务树 参数 - 项目目标一句话说明要达成什么 - 已知约束时间 / 人手 / 可用资源 / 明显限制 输出要求 1. 输出一到三级的任务树 2. 每个最底层任务必须写成完成 XXX以 YYY 为标准例如完成数据迁移脚本以全量数据校验通过为准 3. 在同级任务里标出依赖关系例如 B 必须在 A 之后开始 4. 额外给出一份潜在风险清单包括可能延期、容易返工、需要外部配合的事项。这个 Skill 在一个某跨平台系统的开发计划里帮了大忙。我们当时目标是把现有系统升级到跨平台架构看起来方向明确但一直没人去拆验收标准。用了/wbs之后它把一个多月的工作量拆成了可验收的模块任务而且精确指出用户数据迁移和权限体系改造之间存在耦合依赖得安排同一个负责人盯着不然中间必然出现移交返工。拆解这一步还有另一个隐藏价值它能帮你说服别人。当一个庞大目标被拆成一条条带完成标准的任务时无论是给上级汇报还是跟合作方对齐都比正在推进整体方案这种模糊表述有力得多。你需要做的只是拿着拆解结果逐条确认挑错而不是自己从头排计划。5.2 日周排期让 AI 给任务加缓冲别排成一排紧贴的方块任务拆解完进入排期阶段。很多人让 AI 排计划得到的是一张精密的日历表精密到每半小时换一个任务看起来完美实际执行两天就崩了因为缺乏对真实工作节奏的建模。我做的/schedule有两个特点给每个任务估算一个区间并强制加入缓冲。触发语/schedule 功能根据任务列表生成可执行的日 / 周计划 参数 - 任务列表来自 /wbs 的输出或手动填写 - 时间段一天 / 一周 - 已知会议和固定安排以时间段—事项格式列出 输出要求 1. 每个任务按乐观、正常、悲观三种情形给工时估算 2. 按悲观工时安排计划而不是按乐观工时 3. 每天保留至少 30% 空白时间不排任何任务 4. 同一时间内最多安排一个深度工作任务其他只放响应性工作 5. 所有工作按优先级排序前 3 项必须是最重要的哪怕前 3 项只完成一部分。这条 Skill 背后的逻辑我是在踩过几次坑之后才想明白的AI 排期容易把人和机器混为一谈机器不需要休息、不会被打断也不用开会。人不是这样一个上午能真正专注的时间其实有限。所以我设计时明确要求按悲观工时排期而且还要求空出至少 30% 空白时间听起来很浪费但执行率反而高得多。我最近一次用它排的一周计划里它甚至把每日固定回复消息的时间也纳入了安排这样避免了每天被碎片消息打断几次的问题。你拿它排完计划之后别急着执行先看后三天的安排如果觉得太松散就加任务如果刚好够忙就保持反正比从零开始手排要快得多。5.3 阶段复盘让 AI 当你的项目镜子而不是干巴巴填周报模板最后一个执行类技能是复盘。周报谁都会写但我想要的不是流水账而是目标差距分析和经验沉淀。我把/review设计成一次结构化的回顾对话让它扮演一个不带情绪的观察者帮我从过去一段时间的原始记录里找出真正值得注意的东西。触发语/review 功能根据工作记录和关键结果生成结构化复盘报告 输入 - 目标列表期初设定的目标 - 实际结果完成任务列表或关键事件 - 过程记录聊天记录、日志摘要、里程碑 输出要求 1. 目标回顾目标是否达成差距用具体数字描述不写基本完成 2. 原因分析区分外部因素、内部执行因素和判断失误三类 3. 经验条目归纳出 3 条可以复用的行动准则每条例外说明在什么情况下不适用 4. 下一步给出不超过 5 条行动建议按优先级排列每条标明建议负责人和完成时间。复盘的最大陷阱在于自我美化人会本能地把失败归结为外部因素AI 没有这个心理包袱。只要你在输入时把原始记录贴全它给出的原因分析往往会比你自己写的更直白。比如某次项目延期人写的复盘里写了三条沟通成本高、需求变动多、人手不足但/review从记录里发现真正的问题是需求确认环节缺少一个固定节点每次都是开发到一半才让负责人拍板。这个结论虽然不讨好但直接指向了流程缺陷比泛泛而谈有价值得多。要清楚的是/review的价值是提供第三视角的初稿最终还是需要人来定论。我一般会把它的输出当作一个质疑清单逐条去回想当时发生了什么同意的留下不同意的地方删掉或补充证据。这样做出来的复盘比我空着手写周报信息量大一个层次。6. 配置 Skills 时踩过的五个坑和对应的调优方法6.1 坑一让 AI 扮演某个角色输出反而又空又油早期配置 Skill 的时候我喜欢加一句你现在是一位拥有十年经验的产品专家以为这样能提升专业感。结果输出确实圆润了但空洞得一塌糊涂全是正确的废话。后来我意识到角色扮演给 AI 的不是专业知识而是一种腔调知识密度反而可能下降。我的调整方法是删掉所有角色扮演改成让 AI 直接面对目标和约束。比如不写你是产品专家而写你的目标是帮读者降低理解成本如果方案可行直接给出结论如果不可行明确提出反对意见。相比之下后一种写法更接近以结果为导向的思考方式也不会让输出变得油腻。6.2 坑二格式约束太死模型为了凑格式会编数据我一度把所有输出都设计成严丝合缝的表格要求每个单元格不能为空。后来发现 AI 宁可编一个本周规划出来也不愿意留空。这非常危险因为格式要求越严格模型在填空压力下越容易顺着模板生成并不存在的细节。现在我在每个需要表格的 Skill 里都加了一句未知信息填 N/A并在表外单独注明哪些内容属于推测。这一句的性价比极高它给了模型一个诚实的选项而不是逼它制造虚假确定感。对于事实提炼类技能这个约束尤其重要。6.3 坑三不同 Skill 之间互相串味当我把摘要、写作、复盘等技能放进同一个工作台后发现它们不是各自独立的而是会用相同的口吻和结构处理问题。比如/summary输出的摘要有时候带着/write的分段模式/review分析原因时也会不自觉地采用写作 Skill 里的层次感语言。这本质上是因为所有 Skill 都基于同一个模型模型会受其他指令的历史影响。我的解决办法是在每个 Skill 的约束一节里显式写明这是专用指令不要参考通用写作风格只执行本指令列出的要求。另外在 WorkBuddy 的配置里尽量给不同 Skill 设置不同的输出例子让模型知道每个场景适用的模板并不相同。6.4 坑四示例不更新AI 一直给你过期模板模型在一次更新之后输出风格和结构理解都会有微妙变化。我最早配置的摘要 Skill 里不小心留了一段旧示例结果它每次都会把示例中的段落标题原封搬进新输出哪怕内容完全不相关。后来我养成了一个维护习惯每两到三个月更新一遍 Skill 的示例部分同时把最后更新日期写在 Skill 描述里。这样每次调用时模型看到更新日期会更倾向按新的示例模板输出。这个做法成本很低收益却很明显。6.5 坑五触发词设得太短误触发后一顿乱改一开始我给摘要类技能设的触发词是摘要两个字排期类技能设的是计划两个字。结果每次普通对话里提到帮我安排一下计划都会误触发排期技能打断原来的对话节奏。后来我把所有触发词改成带斜杠的固定指令比如/summary、/schedule并且要求它触发后只执行该动作不解释、不寒暄。加了这个约束之后误触发基本消失了对话也变得更干脆。这里也顺带建议你触发词越生僻越好不要用自然语言里的高频词。语言的歧义很难规避与其费劲调模型不如直接换一个几乎不会在日常对话里出现的词。7. 最后的维护心得把 Skill 当代码来维护而不是当收藏夹如果你读完前面这些准备去照着配置一遍那我最后想分享的是经验层面的东西这些 Skill 不是配好就能永久使用的它们更像代码需要持续迭代。我给自己定的节奏是一个月翻一遍十个 Skill 的示例输出和约束条件结合当月使用中发现的不足做小改动比如哪句话不够明确、哪个输出模板不符合实际需求、哪个约束要求过强限制了灵活性。每次改动之后我都会把它保存为新版本并在描述里更新日期。这个习惯让我在助手能力升级之后不至于被旧模板拖后腿也让我每次使用时越来越接近一次到位。还有一点不要追求 Skill 数量。我见过有人一口气配了五十几个觉得功能越多越好结果触发词冲突严重维护成本爆炸。保持十个以内的核心模块每个都是你真实高频使用的场景比堆数量有用得多。配置这件事的终极目的不是让 AI 显得多能干而是让它在关键时刻能安静地把活干完你就能腾出手来做那些只有你能做的事情。 
长河君 · 2026/10/22 8:55:28 · 阅读 1.2k 可复用AI Skills：提示词模板与自动化工作流的实践指南
1. 为什么我要给 AI 助手攒一組可复用的 Skills而不是每次现场发挥先说结论把 10 个高频动作固化成 Skills 之后我处理日常杂活的效率大概翻了一倍。这个翻倍不是说 AI 变聪明了而是我把自己变懒了——每次开新会话不用再重复交代背景、要求、输出格式直接一个触发词喊出来它就知道该按什么套路干活。WorkBuddy 是我自己搭的一套助手配置工作台底层接的是通用大语言模型接口上面套了一层自定义指令管理。你可以把它理解成一个预装指令集的遥控器每个 Skill 就是遥控器上的一个按钮。按钮背后存的不只是一段提示词还包括触发条件、输出模板、使用示例以及我最常踩的坑和规避方式。我最早不用 Skills 的时候典型流程是这样的复制一篇长文粘贴给助手先写帮我总结一下然后它给了一个一百字的泛泛总结我再补一句要分点、要保留关键数据它又改一版还是不够细再追加按背景、分析、结论三个部分输出……一轮下来光调提示词就花了十分钟等我回过神来还不如自己看完自己写。后来我把高频动作拆开看发现日常真正在反复用的其实就十类读长文、提炼事实、找资料、出创意、写结构稿、改口播、润色邮件、拆任务、做排期、写复盘。每一类单独做成一个 Skill用的时候直接触发助手一次性按我预设的规则输出我再在里面做删改而不是从零开始和它磨。设计 Skill 时我给自己定了四个原则这里先说一下后面每个具体示例都会贯彻第一单一职责。一个 Skill 只干一件事不要在摘要里顺带叫它顺便给点写作建议它一旦多线程就容易两头都干不好。第二输入契约明确。每个 Skill 都要写清楚你给我什么我还你什么避免它自作主张去猜。第三输出模板固定。提前定好标题、分点、列表、表格这些结构让它按模板填内容而不是每次重新发明排版。第四示例必须更新。模型能力在变工具也在变隔几个月就要把 Skill 里的示例输出翻新一遍否则会照着旧逻辑给你过时答案。这套思路在你自己的工作环境里也一样适用不管你是用现成的助手平台还是自己封装 API只要能把提示词触发条件输出模板示例组合成可复用模块本质上就是在做同一件事。2. 十个 Skills 全景图先看清每颗按钮的用途再谈怎么配在逐个拆解之前我先把十个 Skills 摆在一张表里方便你对照自己的需求来选。这十个技能我按工作流分成三大侧输入侧负责把信息吃透输出侧负责把想法变成稿子执行侧负责把目标拆成可落地的行动。分类Skill 名称触发词示例输出形态典型使用场景输入侧长文摘要/summary三段式要点论文、行业报告、政策文件输入侧事实提炼/facts字段化表格会议记录、访谈、聊天记录输入侧检索辅助/research搜索词 信源清单写文章前划定搜索边界输出侧创意脑暴/brainstorm发散清单 收敛排序想选题、想方案、想切入角度输出侧结构化写作/write大纲 分段落稿写方案、写长文、写说明文档输出侧口播稿改写/script口语化脚本视频口播、音频分享、开场白输出侧邮件润色/email得体邮件正文商务沟通、催办、道歉、同步执行侧任务拆解/wbs可验收任务树项目启动、目标落地执行侧日周排期/schedule时间表 缓冲区间制定当日 / 本周计划执行侧阶段复盘/review结构复盘报告周报、项目收尾、季度总结我刻意把输入侧放在最前面是因为大多数低效对话都发生在信息输入环节原文没梳理清楚后面所有生成内容都会跟着歪。你先让助手把一段材料吃透把关键事实、矛盾点、决策信息提取出来再喂给后面的写作、拆解类技能整个链路就稳了。选择这十个而不是更多的原因也很直白其他技能我试过比如让它起名、翻译、做心理测试耍着玩可以但无法稳定进入日常生产流。真正能让我效率翻倍的反而不是花哨能力而是那些我每天都会重复、但现在能让助手一次到位的脏活累活。你完全可以按自己行业替换其中几个但先把我这套骨架搭起来再换零件会容易很多。3. 输入侧三个 Skills让 AI 先把信息吃透后半场才不翻车3.1 长文摘要核心不是压缩而是按需提取决策信息很多人用摘要技能时只说一句帮我总结这篇文章结果助手给它一个四平八稳的概括既不解决阅读效率问题也不解决决策问题。我的/summary设计的是三段式先给结论再给论据最后给和我有什么关系。触发语/summary 功能对粘贴进来的长文本输出三段式摘要 要求 第一段用 4 行以内说清文本的主题、核心结论、站在谁的角度写的 第二段用无序列表列出 5 到 8 个关键论据每个论据后标注它在原文中的大致位置 第三段单独列出 2 条对决策最有用的信息并说明它能直接回答什么判断。 约束 - 不添加原文之外的事实 - 如果原文内部有矛盾数据必须明确指出并引用原文片段 - 不要输出本文是一篇……这类废话开头。这里有一个容易被忽略的细节站在谁的角度写的尤其关键。同样一份行业分析报告投资人读到的决策信息、运营人员读到的执行信息完全不一样。我在设计 Skill 时强制它先判断作者立场和读者视角后面提炼的要点会准很多。一个我实际用过的例子是处理一份三万字的产品体验报告中第一段直接点出读者的结论是该功能整体可用但注册环节流失率异常存在三个未验证假设第二段列出证据时我一眼就能定位哪些段落需要重读第三段给出的决策信息直接接上了下一周的产品评审。如果你觉得三万字太长也可以在这个 Skill 前面加一个分段提问的步骤让助手先给一个一分钟版本的摘要满意后再展开细读。但这属于补充用法基础配置用上面的模板就够了。3.2 事实提炼从会议记录里抽出谁、何时、做了啥、下一步长文摘要管的是文章事实提炼管的是对话记录。我最常用它处理两类输入一类是会议转录文本一类是群聊里零散交代的事项。直接让助手把重要信息提取出来不行输出会变成一个段落复述找不到重点。我把输出强行改成字段表。触发语/facts 功能从对话记录中提取结构化事实 要求 输出一张 Markdown 表格列包括事项 / 涉及人 / 时间点 / 结论或下一步 / 来源句子。 规则 - 对每个人名、时间、数据原样保留不做猜测 - 时间如果原文只有下周明天标注为未明确需确认 - 发现有相互矛盾的信息时单独在表格下面列矛盾点清单 - 如果对话中有待办事项把所有待办单独再列一个小节按紧急排序。这个模板最初是为一个某跨平台系统项目的周会服务的。过去我开完会要重新听一遍录音把各人的交付时间点一个个手打出来自从用了/facts直接把原始转录文本贴进去表格立刻出来我再花五分钟校对一遍省下的时间至少一小时。需要留意的坑是模型在提取事实时倾向于脑补缺失内容。比如原文说A 将在近期完成接口联调它可能写成本周五完成接口联调。所以我在规则里特意加了来源句子这一列每一行都可以回溯到原始语句还有未明确需确认这种占位符逼着它承认自己不知道。宁可慢一点也不要让它给你造出个假时间点。3.3 检索辅助让助手先生成搜索方案而不是直接搜给你看很多助手工具带联网搜索功能但直接让它搜最近的行业动态出来的内容要么太泛、要么太旧。我后来想明白了一个道理与其让 AI 替我搜索并总结不如让它先生成一套搜索指挥方案我自己拿着方案去各信源里精确捞效率和准确率反而更高。触发语/research 功能给定某个主题生成检索任务清单 要求 1. 给出 8 个精准搜索词分为核心词、限定词、时间词、排除词 2. 给出 5 个相对可信的信源类型并说明从哪个渠道能找到这类信源 3. 列出 3 个可能获取反方观点的搜索方向避免只看单一立场 4. 最后用一句话说明这个主题最容易被忽略的盲区。这个 Skill 的实际价值在于它逼着我去思考什么才算有效搜索。比如想了解某类新工具在中小企业里的落地情况时它给的搜索词会是中小企业 数字化 工具 落地 失败案例 2024其中失败案例是反直觉的关键词能搜出很多站在推销对立面的真实内容反而比单纯搜有哪些好工具有价值得多。有一个经验是/research的搜索结果不要直接拿给助手总结出文章而应该和/facts配合。你先搜到一批材料把材料贴给/summary和/facts让它们各自提取一遍再进入后面的写作链路。这样每一层都有明确输入、明确处理、明确输出整体质量会稳定很多。4. 输出侧四个 Skills把脑子里那团乱麻变成能直接交付的稿子4.1 创意脑暴先发散再收敛别让助手一上来就选最优我以前让助手帮我想十个选题它总能给我十个四平八稳的表达每个都像但每个都平庸。问题出在我给了它想十个这个数量要求它会为了凑数而放弃质量。后来我把/brainstorm设计成了两轮赛制第一轮无差别罗列第二轮按标准淘汰。触发语/brainstorm 功能对一个主题进行创意发散和收敛排序 流程 第一轮列出 12 个方向或想法尽量互不重叠不要评价好坏不要前面的排挤后面的 第二轮按三个标准筛选成本、受众痛点、差异化每次筛掉一个最后剩 3 个 第三轮为保留下来的 3 个分别写一句如果用一句话向别人推荐这个选题怎么说。 约束全程不要使用首先、然后、最后之类的连接词直接列条目。这个设计参考了头脑风暴里常见的两个阶段原则发散时禁止评判收敛时严格执行标准。我实际用它做过一个内容选题规划第一轮的 12 个想法里有几个明显有风险比如直接讲竞品缺陷但第二轮按成本和受众敏感度筛掉之后留下的那个反而成了当时数据最好的一篇内容。要注意的是脑暴 Skill 只负责生想法不负责写全文。很多朋友把脑暴结果直接丢给写作 Skill希望一步到位出一篇文章结果发现风格断裂。正确的做法是脑暴产出的 3 个方向里挑 1 个然后用下一个/write去扩写。4.2 结构化写作把写长文变成填结构而不是对着空白页硬憋结构化写作是我用得最频繁的输出型 Skill适用范围从方案文档、产品说明到汇报材料都能覆盖。它的核心思想是人类更适合在框架里填内容不适合对着空白页从零开始生成所以先让 AI 给框架再在框架基础上做增删。触发语/write 功能根据输入的主题和素材生成可编辑的结构化文稿 参数 - 读者角色例如运营负责人技术评审人普通用户 - 读者目标例如决定是否启动项目了解新功能用法认可这个结论 - 内容基调严谨 / 轻松 / 中立 输出要求 1. 给出文章标题候选项 3 个 2. 给出完整大纲包括一级标题、二级标题和每部分的写作意图 3. 按大纲填充首段和三段示例正文其余段落用占位注释标注应放什么素材 4. 全文不要插入没有来源支撑的数据。为什么强调读者目标和内容基调因为写作中最常见的失败是目标读者错位。一份给技术评审人看的方案应该开门见山说清楚架构取舍给普通用户看的功能说明应该用场景和操作步骤引导。/write在开头先把这两个参数问清楚后面生成的骨架才不至于跑偏。我举个例子某次做跨平台系统升级方案我填的读者角色是技术负责人读者目标是评估该方案是否可以进入开发排期产出的首段直接点明了兼容性范围、改造成本和团队规模假设而不是从一个企业数字化转型的宏大背景讲起。这就是结构与目标匹配带来的差异。4.3 口播稿改写把书面语翻成会说人话的版本做视频或者播客的朋友一定有过这种体验写出来的稿子自己念两遍就觉得不像在讲话。原因很简单书面语和口语是两套系统。口播稿改写的本质不是缩短句子而是把阅读节奏转成听觉节奏。触发语/script 功能将输入的书面文本改写为口语化口播稿 要求 1. 允许保留原文全部关键信息但可以用语气词和口头过渡来衔接 2. 单句尽量控制在 25 字以内逗号太多时拆成两句 3. 避免出现此外综上所述值得注意的是这类书面连接词 4. 在每段话后面加一个语气提示比如[停顿]、[重读]、[放慢]方便录制时参考 5. 口播稿不要太像网络段子保持自然说话感即可。拿走这个 Skill 最直接的收益是改稿效率。以前写一篇两分钟的视频文案写完书面版还要逐句念、逐句改现在直接让/script一遍改写我再对照实际用词习惯微调基本两遍能定稿。有一个细节值得说我在第 4 条里明确禁止网络段子化。之前没加这条时AI 会把所有句子都改成网感十足的短句反而失去了专业感。对内容创作者来说口语化和随意化之间是有明确边界的。4.4 邮件润色语气得体但别让 AI 替你客套到底邮件润色看起来最简单其实是最考验分寸感的 Skill。中文商务邮件的麻烦不在语法而在语气同一件事催对方提交和礼貌提醒对方提交措辞完全不同。如果只给一句帮我写一封催交报告的邮件AI 很容易写成又委婉又啰嗦的客套话反而模糊了重点。触发语/email 功能根据输入邮件类型润色或生成邮件正文 参数 - 邮件类型正式汇报 / 催办 / 道歉 / 同步信息 / 请求支持 - 收件人关系上级 / 平级 / 外部合作方 - 语气强度弱 / 中 / 强 - 要点列表用户在冒号后粘贴希望传达的核心信息 输出要求 1. 第一段交代背景不超过两句话 2. 中间段按要点排序每件事单独占一行 3. 结尾明确写出期待对方回复的行动项和截止时间 4. 没有意义的内容如再次感谢敬请期待之类最多出现一次。我特别想提醒你的是不要让它把多少冒昧打扰百忙之中这类谦辞堆在前面。真正得体的邮件是信息密度高、行动项清楚、语气和善但不卑微。我试过让 AI 把同样一封催办邮件按三种语气强度输出我和同事比较后一致认为中等强度行动项明确的版本效率最高弱语气版本反而让人忽略重点强语气版本则显得冒犯。目前在/email里我最常调用的场景是 催办和同步信息两类因为这两类最容易在沟通里得罪人。把关系字段填清楚它会自动控制分寸省掉了我每次斟酌措辞的精力。5. 执行侧三个 Skills任务拆解、排期、复盘让 AI 帮你盯住项目全流程5.1 任务拆解按可验收结果拆不要按动作拆普通的任务拆解容易拆成了解需求、整理资料、完成代码、测试这种动作列表看起来有步骤实际没法验收。设计/wbs时我要求它按交付物思路来拆每一项任务必须有明确的完成标准。触发语/wbs 功能将目标拆解为可验收的任务树 参数 - 项目目标一句话说明要达成什么 - 已知约束时间 / 人手 / 可用资源 / 明显限制 输出要求 1. 输出一到三级的任务树 2. 每个最底层任务必须写成完成 XXX以 YYY 为标准例如完成数据迁移脚本以全量数据校验通过为准 3. 在同级任务里标出依赖关系例如 B 必须在 A 之后开始 4. 额外给出一份潜在风险清单包括可能延期、容易返工、需要外部配合的事项。这个 Skill 在一个某跨平台系统的开发计划里帮了大忙。我们当时目标是把现有系统升级到跨平台架构看起来方向明确但一直没人去拆验收标准。用了/wbs之后它把一个多月的工作量拆成了可验收的模块任务而且精确指出用户数据迁移和权限体系改造之间存在耦合依赖得安排同一个负责人盯着不然中间必然出现移交返工。拆解这一步还有另一个隐藏价值它能帮你说服别人。当一个庞大目标被拆成一条条带完成标准的任务时无论是给上级汇报还是跟合作方对齐都比正在推进整体方案这种模糊表述有力得多。你需要做的只是拿着拆解结果逐条确认挑错而不是自己从头排计划。5.2 日周排期让 AI 给任务加缓冲别排成一排紧贴的方块任务拆解完进入排期阶段。很多人让 AI 排计划得到的是一张精密的日历表精密到每半小时换一个任务看起来完美实际执行两天就崩了因为缺乏对真实工作节奏的建模。我做的/schedule有两个特点给每个任务估算一个区间并强制加入缓冲。触发语/schedule 功能根据任务列表生成可执行的日 / 周计划 参数 - 任务列表来自 /wbs 的输出或手动填写 - 时间段一天 / 一周 - 已知会议和固定安排以时间段—事项格式列出 输出要求 1. 每个任务按乐观、正常、悲观三种情形给工时估算 2. 按悲观工时安排计划而不是按乐观工时 3. 每天保留至少 30% 空白时间不排任何任务 4. 同一时间内最多安排一个深度工作任务其他只放响应性工作 5. 所有工作按优先级排序前 3 项必须是最重要的哪怕前 3 项只完成一部分。这条 Skill 背后的逻辑我是在踩过几次坑之后才想明白的AI 排期容易把人和机器混为一谈机器不需要休息、不会被打断也不用开会。人不是这样一个上午能真正专注的时间其实有限。所以我设计时明确要求按悲观工时排期而且还要求空出至少 30% 空白时间听起来很浪费但执行率反而高得多。我最近一次用它排的一周计划里它甚至把每日固定回复消息的时间也纳入了安排这样避免了每天被碎片消息打断几次的问题。你拿它排完计划之后别急着执行先看后三天的安排如果觉得太松散就加任务如果刚好够忙就保持反正比从零开始手排要快得多。5.3 阶段复盘让 AI 当你的项目镜子而不是干巴巴填周报模板最后一个执行类技能是复盘。周报谁都会写但我想要的不是流水账而是目标差距分析和经验沉淀。我把/review设计成一次结构化的回顾对话让它扮演一个不带情绪的观察者帮我从过去一段时间的原始记录里找出真正值得注意的东西。触发语/review 功能根据工作记录和关键结果生成结构化复盘报告 输入 - 目标列表期初设定的目标 - 实际结果完成任务列表或关键事件 - 过程记录聊天记录、日志摘要、里程碑 输出要求 1. 目标回顾目标是否达成差距用具体数字描述不写基本完成 2. 原因分析区分外部因素、内部执行因素和判断失误三类 3. 经验条目归纳出 3 条可以复用的行动准则每条例外说明在什么情况下不适用 4. 下一步给出不超过 5 条行动建议按优先级排列每条标明建议负责人和完成时间。复盘的最大陷阱在于自我美化人会本能地把失败归结为外部因素AI 没有这个心理包袱。只要你在输入时把原始记录贴全它给出的原因分析往往会比你自己写的更直白。比如某次项目延期人写的复盘里写了三条沟通成本高、需求变动多、人手不足但/review从记录里发现真正的问题是需求确认环节缺少一个固定节点每次都是开发到一半才让负责人拍板。这个结论虽然不讨好但直接指向了流程缺陷比泛泛而谈有价值得多。要清楚的是/review的价值是提供第三视角的初稿最终还是需要人来定论。我一般会把它的输出当作一个质疑清单逐条去回想当时发生了什么同意的留下不同意的地方删掉或补充证据。这样做出来的复盘比我空着手写周报信息量大一个层次。6. 配置 Skills 时踩过的五个坑和对应的调优方法6.1 坑一让 AI 扮演某个角色输出反而又空又油早期配置 Skill 的时候我喜欢加一句你现在是一位拥有十年经验的产品专家以为这样能提升专业感。结果输出确实圆润了但空洞得一塌糊涂全是正确的废话。后来我意识到角色扮演给 AI 的不是专业知识而是一种腔调知识密度反而可能下降。我的调整方法是删掉所有角色扮演改成让 AI 直接面对目标和约束。比如不写你是产品专家而写你的目标是帮读者降低理解成本如果方案可行直接给出结论如果不可行明确提出反对意见。相比之下后一种写法更接近以结果为导向的思考方式也不会让输出变得油腻。6.2 坑二格式约束太死模型为了凑格式会编数据我一度把所有输出都设计成严丝合缝的表格要求每个单元格不能为空。后来发现 AI 宁可编一个本周规划出来也不愿意留空。这非常危险因为格式要求越严格模型在填空压力下越容易顺着模板生成并不存在的细节。现在我在每个需要表格的 Skill 里都加了一句未知信息填 N/A并在表外单独注明哪些内容属于推测。这一句的性价比极高它给了模型一个诚实的选项而不是逼它制造虚假确定感。对于事实提炼类技能这个约束尤其重要。6.3 坑三不同 Skill 之间互相串味当我把摘要、写作、复盘等技能放进同一个工作台后发现它们不是各自独立的而是会用相同的口吻和结构处理问题。比如/summary输出的摘要有时候带着/write的分段模式/review分析原因时也会不自觉地采用写作 Skill 里的层次感语言。这本质上是因为所有 Skill 都基于同一个模型模型会受其他指令的历史影响。我的解决办法是在每个 Skill 的约束一节里显式写明这是专用指令不要参考通用写作风格只执行本指令列出的要求。另外在 WorkBuddy 的配置里尽量给不同 Skill 设置不同的输出例子让模型知道每个场景适用的模板并不相同。6.4 坑四示例不更新AI 一直给你过期模板模型在一次更新之后输出风格和结构理解都会有微妙变化。我最早配置的摘要 Skill 里不小心留了一段旧示例结果它每次都会把示例中的段落标题原封搬进新输出哪怕内容完全不相关。后来我养成了一个维护习惯每两到三个月更新一遍 Skill 的示例部分同时把最后更新日期写在 Skill 描述里。这样每次调用时模型看到更新日期会更倾向按新的示例模板输出。这个做法成本很低收益却很明显。6.5 坑五触发词设得太短误触发后一顿乱改一开始我给摘要类技能设的触发词是摘要两个字排期类技能设的是计划两个字。结果每次普通对话里提到帮我安排一下计划都会误触发排期技能打断原来的对话节奏。后来我把所有触发词改成带斜杠的固定指令比如/summary、/schedule并且要求它触发后只执行该动作不解释、不寒暄。加了这个约束之后误触发基本消失了对话也变得更干脆。这里也顺带建议你触发词越生僻越好不要用自然语言里的高频词。语言的歧义很难规避与其费劲调模型不如直接换一个几乎不会在日常对话里出现的词。7. 最后的维护心得把 Skill 当代码来维护而不是当收藏夹如果你读完前面这些准备去照着配置一遍那我最后想分享的是经验层面的东西这些 Skill 不是配好就能永久使用的它们更像代码需要持续迭代。我给自己定的节奏是一个月翻一遍十个 Skill 的示例输出和约束条件结合当月使用中发现的不足做小改动比如哪句话不够明确、哪个输出模板不符合实际需求、哪个约束要求过强限制了灵活性。每次改动之后我都会把它保存为新版本并在描述里更新日期。这个习惯让我在助手能力升级之后不至于被旧模板拖后腿也让我每次使用时越来越接近一次到位。还有一点不要追求 Skill 数量。我见过有人一口气配了五十几个觉得功能越多越好结果触发词冲突严重维护成本爆炸。保持十个以内的核心模块每个都是你真实高频使用的场景比堆数量有用得多。配置这件事的终极目的不是让 AI 显得多能干而是让它在关键时刻能安静地把活干完你就能腾出手来做那些只有你能做的事情。