50+营销Skill装进AI Agent：从Prompt到可调度技能单元

1. 这个项目到底解决了什么问题第一次看到“把 50 多种营销 Skill 装进 AI Agent”这个说法我脑子里冒出来的第一个念头是又是一个把提示词打包成“技能库”的仓库吧。但真正把项目拉下来跑了一遍之后我发现它想做的事情比“提示词合集”要实在得多——它试图把营销工作中那些高频、重复、有固定套路的动作抽象成 AI Agent 可以直接调用的技能单元让 Agent 从“会聊天”变成“会干活”。先说清楚这个项目是什么。它是一个开源项目核心产物是一套面向营销场景的 Skill 集合数量在 50 个以上覆盖内容创作、SEO、广告投放、社媒运营、邮件营销、落地页优化、竞品分析、用户调研等常见营销环节。每个 Skill 本质上是一段结构化的指令加配套的上下文模板可以被 AI Agent 加载后按需调用。它解决的问题很具体营销人每天要写大量重复性的东西比如产品卖点提炼、标题变体、广告文案、邮件序列、关键词分组这些活儿有章法但费时间交给通用大模型又经常“答得漂亮但不落地”。这个项目就是把这些章法固化下来让 Agent 按套路输出。适合谁来参考三类人最受益。第一类是独立开发者和小团队没有专职营销需要一个人顶一个市场部这套 Skill 能帮你把基础动作标准化。第二类是AI Agent 的搭建者你正在用 Claude Code、Codex、Cursor、Windsurf 这类工具做自己的 Agent缺的就是垂直领域的技能包这个项目可以直接拿来当参考或者直接接入。第三类是营销从业者想搞清楚 AI 到底能在自己工作流里承担哪部分这套 Skill 的拆解方式本身就是一份很好的“营销工作可自动化清单”。需要提前说明的是这个项目不是那种“装完就自动帮你赚钱”的东西。它的价值在于结构和复用你得理解每个 Skill 背后的营销逻辑才能真正用好。下面我会从设计思路、核心细节、实操过程、问题排查几个层面把这个项目拆开讲透。2. 项目整体设计与思路拆解2.1 为什么是 Skill 而不是 Prompt很多人做 AI 营销工具的第一反应是写一堆 Prompt 模板用户复制粘贴就能用。这个项目没有走这条路而是选择了 Skill 的形式这个选择背后有明确的工程考量。Prompt 的问题是一次性的。你写一段“帮我写 10 个广告标题”的提示词用户每次用都要重新粘贴、重新填产品信息、重新调整语气。而 Skill 是可被 Agent 调度的它包含三个层次触发条件什么时候用这个技能、输入参数需要用户提供什么、执行逻辑怎么处理、输出什么格式。这三层结构让 Skill 可以被程序化调用而不是靠人肉复制。举个具体例子。项目里有一个“产品卖点提炼”的 Skill它的触发条件是“当用户提供了产品描述但还没有明确卖点”输入参数是产品名称、目标人群、核心功能执行逻辑是先做功能拆解再映射到用户收益最后按优先级排序输出。这套逻辑如果写成 Prompt用户得自己记住顺序写成 SkillAgent 可以自动判断当前对话是否满足触发条件然后按固定流程执行。提示Skill 和 Prompt 的核心区别在于“可调度性”。Prompt 是给人看的Skill 是给 Agent 调用的。做 Agent 开发时优先考虑 Skill 化而不是堆 Prompt。2.2 50 多个 Skill 是怎么分类的项目把 50 多个 Skill 分成了几个大类这个分类方式本身就值得研究。我整理了一下大致的结构类别典型 Skill解决的核心问题内容创作标题生成、长文大纲、卖点提炼从零到一产出内容框架SEO 优化关键词分组、TDK 生成、内链建议让内容能被搜到广告投放广告文案变体、受众画像、A/B 测试方案提升投放转化社媒运营帖子排期、话题标签、互动话术维持账号活跃度邮件营销欢迎序列、弃购召回、 newsletter 模板自动化用户触达落地页首屏文案、CTA 优化、信任元素清单提升页面转化率竞品分析功能对比、定价拆解、SWOT 生成快速摸清竞争格局用户调研问卷设计、访谈提纲、反馈归类结构化收集用户声音这个分类的逻辑是按营销工作流走的而不是按“AI 能力”走。很多 AI 工具喜欢按“文本生成、图像生成、数据分析”来分那是技术视角这个项目按“你工作中先做什么、再做什么”来分是业务视角。对使用者来说后者更容易找到自己需要的技能。2.3 为什么选择兼容多个 AI 编程助手项目标题里提到了 Claude Code、Codex、Cursor、Windsurf 这些工具这不是随便列的。这些工具的共同点是都支持自定义指令或技能加载但格式和调用方式各有差异。项目在设计时做了一个抽象层把 Skill 的核心逻辑和具体平台的适配分开。具体来说每个 Skill 有一个核心定义文件描述触发条件、输入输出和执行逻辑然后针对不同平台有对应的适配文件。比如在 Claude Code 里Skill 可能以特定目录结构下的 Markdown 文件存在在 Cursor 里可能通过.cursorrules或自定义指令的方式加载。这种设计的好处是你写一次 Skill可以在多个工具里复用不用为每个平台重写一遍。这个选择背后的判断是AI 编程助手市场还没有定型今天用 Cursor 的人明天可能换 Windsurf如果 Skill 和平台绑死迁移成本就很高。做成平台无关的核心加平台适配层是更稳妥的工程决策。2.4 这套设计避免了哪些坑我对比过一些类似的“AI 营销工具包”常见的坑有三个这个项目在设计上都有意避开了。第一个坑是技能粒度太粗。有的项目一个 Skill 叫“写一篇营销文章”输入一个主题输出一整篇。这种 Skill 看起来省事但实际用起来很痛苦因为文章结构、语气、重点全由 AI 随机决定你没法控制。这个项目的 Skill 粒度普遍较细比如“生成文章大纲”“优化开头段落”“添加过渡句”是分开的你可以按需组合。第二个坑是缺少输入约束。很多 Prompt 模板不告诉你需要提供什么信息用户随便输入一句“帮我写个广告”AI 就只能瞎编。这个项目的每个 Skill 都明确列出了必填参数和可选参数比如“广告文案变体”这个 Skill 要求必须提供产品名称、核心卖点、目标人群可选提供竞品参考和禁用词。输入越明确输出越可控。第三个坑是没有输出格式规范。AI 输出最怕格式飘忽这次给你列表下次给你段落再下次给你表格。这个项目的 Skill 大多定义了输出格式比如“关键词分组”固定输出 Markdown 表格“邮件序列”固定输出编号列表加主题行。格式稳定了后续处理才方便。3. 核心细节解析与实操要点3.1 Skill 的文件结构长什么样我把项目拉下来之后第一件事是看单个 Skill 的文件结构。一个典型的 Skill 通常包含以下几个部分# Skill 名称产品卖点提炼 ## 触发条件 当用户提供产品描述但未明确卖点时触发 ## 输入参数 - 必填产品名称、核心功能列表 - 可选目标人群、竞品名称、价格区间 ## 执行逻辑 1. 将核心功能拆解为功能点 2. 每个功能点映射到用户收益 3. 按“收益强度”和“差异化程度”排序 4. 输出前三个作为核心卖点 ## 输出格式 Markdown 表格列卖点、对应功能、目标人群、差异化说明 ## 示例 输入... 输出...这个结构看起来很朴素但每个部分都有讲究。触发条件决定了 Agent 什么时候自动调用这个 Skill写得太宽会导致误触发写得太窄又用不上。输入参数分必填和可选是为了在信息不足时也能给出合理输出而不是直接报错。执行逻辑是 Skill 的核心它把营销方法论翻译成了步骤。输出格式和示例则是为了保证一致性。注意触发条件的写法很关键。我见过有人写“当用户需要营销帮助时触发”这种太模糊Agent 根本判断不了。好的触发条件应该是具体的、可判断的比如“当用户输入包含产品名称和功能描述但没有出现‘卖点’‘优势’‘亮点’等词时触发”。3.2 营销方法论是怎么翻译成执行逻辑的这是我觉得这个项目最有价值的部分。它没有简单地说“让 AI 写卖点”而是把经典的营销方法论拆成了可执行的步骤。以“产品卖点提炼”为例它用的是FAB 模型Feature-Advantage-Benefit但做了改良。传统 FAB 是功能 → 优势 → 收益。这个项目加了一步“差异化校验”就是在输出卖点之前先问一句“这个卖点竞品有没有”。如果竞品也有那这个卖点就不算核心卖点只能算基础功能。这个改动很实战因为很多 AI 生成的卖点听起来漂亮但放到市场上毫无区分度。再比如“广告文案变体”这个 Skill它用的是钩子-痛点-方案-行动的四段式结构但要求每个变体只改变其中一个要素。比如变体 A 换钩子变体 B 换痛点描述变体 C 换行动号召。这样做的目的是让 A/B 测试有明确的变量而不是一次改一堆东西最后不知道哪个因素起了作用。这种“方法论 工程约束”的组合是普通 Prompt 模板做不到的。普通模板只会说“写 5 个不同风格的广告文案”但不会告诉你这 5 个变体之间应该是什么关系。3.3 输入参数的校验与补全机制实操中我发现一个细节这个项目对输入参数的缺失有补全机制而不是直接拒绝。比如“邮件序列”这个 Skill必填参数是产品名称和序列目的欢迎、召回、促销可选参数是用户画像和品牌语气。如果你没提供品牌语气它会默认用“专业但友好”的语气并在输出末尾标注“未指定语气已使用默认值”。这个设计很实用因为营销人经常在信息不全的情况下就要开始干活。如果每个 Skill 都要求填完所有参数才能用实际使用率会很低。但补全机制也有风险就是默认值可能不符合你的品牌调性。我的做法是第一次使用某个 Skill 时把默认值都显式覆盖一遍确认输出符合预期后再在后续使用中依赖默认值。还有一个细节是参数冲突检测。比如你同时提供了“目标人群大学生”和“价格区间高端”Skill 会提示这两个参数可能存在冲突建议确认。这种校验在人工写文案时靠经验在 AI 工作流里就需要显式写出来。3.4 输出格式的稳定性设计AI 输出格式不稳定是个老问题。这个项目用了两个手段来保证稳定性。第一个手段是模板锁定。每个 Skill 的输出格式都定义得很死比如“关键词分组”必须输出三列关键词、搜索意图、优先级。Agent 在生成时会被要求严格按这个格式来不允许自由发挥。第二个手段是示例锚定。每个 Skill 都附带一个输入输出示例Agent 在生成时会参考示例的格式。这比单纯描述格式更有效因为大模型对示例的模仿能力很强。我实测下来加了示例锚定之后格式错误率从大概三成降到了不到一成。剩下的错误主要出现在输入特别复杂的时候比如关键词有 200 个Agent 会试图合并一些行来“偷懒”。这种情况的解决办法是分批处理每次不超过 50 个关键词。4. 实操过程与核心环节实现4.1 环境准备与项目获取先说环境。这个项目本身是纯文本的 Skill 定义不依赖特定运行时所以环境准备很简单。你需要的是一个支持自定义 Skill 或指令的 AI 编程助手以及 Git 用来拉取项目。我用的组合是 Claude Code 加项目自带的 Skill 目录。Claude Code 对 Markdown 格式的 Skill 支持比较好加载方式也直接。如果你用 Cursor可以把 Skill 文件放到项目目录下通过.cursorrules引用。Windsurf 的话它有类似的规则加载机制适配方式在项目的 README 里有说明。获取项目的命令很标准git clone 项目地址 cd 项目目录 ls skills/你会看到按类别分好的目录每个目录下是一组 Markdown 文件。我建议先不要全部加载而是挑三到五个你最常用的 Skill 先跑通确认工作流顺畅后再逐步增加。提示不要一次性加载全部 50 多个 Skill。Agent 的上下文窗口有限加载太多会导致每个 Skill 的优先级下降触发判断也会变慢。我的做法是按项目阶段加载比如这周做 SEO就只加载 SEO 相关的 8 个 Skill。4.2 单个 Skill 的加载与调用以 Claude Code 为例加载一个 Skill 的步骤是这样的。首先确认 Skill 文件在正确的目录下通常是.claude/skills/或者项目根目录的skills/。然后在对话中Agent 会根据触发条件自动判断是否调用。但自动触发有时候不够准所以我更常用的是显式调用。比如我想用“产品卖点提炼”会直接说“使用产品卖点提炼 Skill产品名称是 X核心功能是 A、B、C”。这样 Agent 就不会去猜直接按 Skill 定义执行。显式调用的好处是可控。自动触发适合探索性使用你不知道有哪些 Skill 可用时让 Agent 自己判断。显式调用适合目标明确时你知道自己要什么直接指定 Skill减少不确定性。调用之后Agent 会按 Skill 定义的执行逻辑走一遍然后按输出格式返回结果。我第一次跑“产品卖点提炼”时输入了一个蓝牙耳机的产品描述Agent 输出了三个卖点每个都附带了对应功能和差异化说明。输出格式是表格很规整可以直接复制到文档里。4.3 多 Skill 串联的工作流搭建单个 Skill 好用但真正的价值在于串联。营销工作很少是一个 Skill 能搞定的通常需要多个 Skill 配合。我搭了一个内容营销的串联工作流大概是这样的先用“关键词分组”Skill把一批关键词按搜索意图分成几组选一组关键词用“长文大纲”Skill 生成文章结构用“标题生成”Skill 产出 10 个标题变体用“开头段落优化”Skill 打磨首段用“内链建议”Skill 补充内部链接最后用“TDK 生成”Skill 产出 SEO 元信息这个工作流跑下来一篇 SEO 文章的框架和核心元素就齐了剩下的就是填充内容。我实测过原来写一篇这样的文章从调研到成稿大概要 4 到 5 小时用这套工作流之后框架搭建部分压缩到了 40 分钟左右效率提升很明显。串联的关键是数据传递。上一个 Skill 的输出要能直接作为下一个 Skill 的输入。这个项目在设计时考虑了这一点输出格式大多是结构化的方便解析和传递。但实操中还是需要手动复制粘贴一些内容因为 Agent 不会自动把上一个 Skill 的输出喂给下一个。我的做法是在对话中明确说“把上一步的关键词分组结果作为输入执行长文大纲 Skill”。4.4 参数调优与效果验证Skill 跑通之后下一步是调优。我以“广告文案变体”为例说一下调优过程。第一次跑输入了产品名称、卖点、目标人群输出 5 个变体。看了一遍发现 5 个变体里有 3 个的钩子很相似都是“你是不是也遇到过……”这种句式。这就是典型的多样性不足问题。解决办法是在输入参数里加一条“禁用句式”把“你是不是也遇到过”列进去。再跑一次钩子就分散开了有提问式、数据式、场景式、对比式。这个调整很小但效果很明显。另一个调优点是输出长度。默认输出每个变体大概 50 到 80 字但投 Facebook 广告和投 Google 搜索广告的长度要求不一样。我后来在调用时加了一句“每个变体控制在 30 字以内适合搜索广告”输出就自动压缩了。注意调优时不要一次改太多参数否则你不知道是哪个改动起了作用。我的习惯是每次只改一个变量跑三次取平均效果确认有效后再改下一个。4.5 与现有工作流的集成这个项目最终要落到你的实际工作流里才有价值。我把它集成到了两个场景。第一个场景是内容日历。每周一我会用“社媒帖子排期”Skill 生成一周的帖子主题和发布时间然后逐个用“帖子文案”Skill 填充内容。原来这个活儿要花一上午现在一个小时能搞定而且主题分布更均匀不会出现某天没内容发的情况。第二个场景是落地页迭代。每次要改落地页先用“首屏文案”Skill 生成 5 个版本再用“CTA 优化”Skill 给每个版本配行动号召最后用“信任元素清单”Skill 检查有没有遗漏社会证明、资质展示这些元素。这套流程跑下来落地页的迭代速度从“两周一次”变成了“一周两次”而且每次都有明确的测试假设。集成的关键是不要试图替换现有流程而是增强它。AI 生成的初稿仍然需要人工审核和调整但初稿的质量和速度提升了人的精力就可以放在策略和创意上而不是重复劳动上。5. 常见问题与排查技巧实录5.1 Skill 不触发或触发错误这是最常见的问题。表现是你说了一句话Agent 没有调用你期望的 Skill或者调用了错误的 Skill。排查思路分三步。第一步检查触发条件是否匹配。比如“产品卖点提炼”的触发条件是“用户提供产品描述但未明确卖点”如果你在输入里已经写了“帮我提炼卖点”那触发条件就不满足了因为“卖点”这个词已经出现了。解决办法是显式调用直接说“使用产品卖点提炼 Skill”。第二步检查 Skill 是否被正确加载。有时候文件放对了位置但 Agent 没有读取到。可以在对话里问一句“你现在加载了哪些 Skill”看列表里有没有你要的那个。第三步检查优先级冲突。如果两个 Skill 的触发条件有重叠Agent 可能选了另一个。解决办法是在 Skill 定义里调整优先级或者在调用时明确指定。问题表现可能原因解决办法完全不触发Skill 未加载检查文件路径和加载配置触发但输出不对触发条件太宽收窄触发条件或显式调用触发了错误的 Skill优先级冲突调整优先级或显式指定时灵时不灵上下文长度超限减少同时加载的 Skill 数量5.2 输出格式错乱格式错乱的表现是该输出表格的时候输出了段落该输出列表的时候输出了连续文本或者列数不对、字段缺失。我遇到最多的情况是输入太长导致格式崩坏。比如关键词分组输入 100 个关键词Agent 输出到后面就开始偷懒把多个关键词塞进一个单元格。解决办法是分批处理每次不超过 50 个。如果必须一次处理 100 个可以在 Skill 调用时加一句“如果输入超过 50 个请分两批输出每批之间用分隔线隔开”。另一个原因是示例不够清晰。如果 Skill 自带的示例格式和实际期望有出入Agent 会按示例来。解决办法是修改示例让它更贴近你的实际需求。这个项目的 Skill 文件都是纯文本直接改就行。5.3 输出内容质量不稳定同样的 Skill同样的输入跑两次结果质量不一样这是大模型的固有特性。但可以通过一些手段来收敛。第一个手段是降低温度参数。如果你用的工具支持调整 temperature把它调到 0.3 到 0.5 之间输出会更稳定。Claude Code 和 Cursor 都支持在配置里调这个。第二个手段是增加约束条件。比如在调用“标题生成”Skill 时加上“避免使用问句”“每个标题不超过 20 字”“必须包含数字”这些约束输出会更可控。第三个手段是多次生成取最优。同一个 Skill 跑三次人工挑最好的一个。这听起来笨但实际用起来很快因为生成一次只要几秒钟挑的时间比从零写快得多。5.4 跨平台迁移的坑如果你从 Claude Code 换到 Cursor或者从 Cursor 换到 WindsurfSkill 的加载方式会变。这个项目虽然做了适配层但实操中还是有一些细节要注意。Claude Code 对 Markdown 格式的 Skill 支持最好直接放目录里就能用。Cursor 需要通过.cursorrules引用而且对文件大小有限制太大的 Skill 文件可能加载不全。Windsurf 的规则加载机制和 Cursor 类似但目录结构要求不同。我的建议是迁移之前先在一个小项目上测试确认 Skill 能正常加载和触发再迁移到主项目。另外不同平台对 Skill 的调用语法可能有差异比如 Claude Code 里直接说“使用 XX Skill”就行Cursor 里可能需要用特定的指令格式。这些细节在项目的 README 里有说明迁移前过一遍能省很多时间。5.5 独家避坑技巧说几个我在实操中踩过的坑常规文档里不会写。第一个坑是不要用中文文件名。虽然项目支持中文 Skill 名称但有些平台在加载时对中文路径处理有问题会导致 Skill 加载失败。我的做法是文件名用英文Skill 内部的名称用中文这样既不影响使用又避免了路径问题。第二个坑是Skill 之间的依赖要显式声明。比如“内链建议”Skill 依赖“长文大纲”的输出如果大纲还没生成就直接跑内链建议输出会很空泛。解决办法是在 Skill 定义里加一句“前置条件需要已有文章大纲”或者在调用时手动确保顺序。第三个坑是定期清理不用的 Skill。加载的 Skill 越多Agent 的判断越慢误触发也越多。我每个月会清理一次把过去一个月没用过的 Skill 移出加载目录。这样 Agent 的响应速度和准确率都会提升。第四个坑是输出结果要存档。AI 生成的内容有时候当时觉得一般过几天回头看发现有个点子不错但已经找不到了。我的做法是每次跑完 Skill把输出复制到一个按日期命名的文档里积累下来就是一个创意库。6. 这套 Skill 体系的扩展与二次开发6.1 如何添加自己的 Skill项目自带的 50 多个 Skill 覆盖了常见营销场景但每个团队都有自己的特殊需求。添加自定义 Skill 的流程不复杂照着现有 Skill 的结构写就行。我以“播客节目大纲”为例说一下我添加的一个自定义 Skill。首先确定触发条件“当用户提供播客主题和时长要求时触发”。然后定义输入参数必填是主题、时长、目标听众可选是嘉宾信息、往期节目参考。执行逻辑分四步确定节目结构开场、主体、结尾、分配时间、设计每个环节的讨论要点、生成提问清单。输出格式是带时间戳的大纲表格。写完之后放到 Skill 目录下重启 Agent 或者重新加载就能用了。我实测下来自定义 Skill 的触发准确率和内置 Skill 没有区别关键是触发条件要写具体。6.2 Skill 的组合与工作流编排单个 Skill 是积木组合起来才是工作流。项目本身没有提供工作流编排功能但你可以通过对话的方式手动串联或者写一个简单的脚本来自动化。手动串联适合探索阶段你边跑边调整顺序。自动化适合稳定阶段流程固定了用脚本跑更省事。我用 Python 写了一个简单的编排脚本核心逻辑是读取一个工作流定义文件按顺序调用各个 Skill把上一个的输出传给下一个。# 工作流编排示例伪代码 workflow [ {skill: 关键词分组, input: keywords.txt}, {skill: 长文大纲, input: 上一步输出}, {skill: 标题生成, input: 上一步输出}, ] for step in workflow: result call_skill(step[skill], step[input]) save_result(result)这个脚本不复杂但能把重复性的串联工作自动化省去手动复制粘贴的时间。6.3 效果追踪与迭代Skill 用了一段时间之后需要评估效果决定哪些保留、哪些优化、哪些淘汰。我用的指标有三个使用频率、输出采纳率、人工修改量。使用频率好理解就是某个 Skill 你多久用一次。输出采纳率是指 AI 生成的内容有多少直接被采用多少需要大改。人工修改量是指采用的内容里你改了多少字。这三个指标结合起来看能判断一个 Skill 的价值。使用频率高、采纳率高、修改量小的是核心 Skill要重点维护。使用频率低但采纳率高的可能是场景特殊保留但不用频繁更新。使用频率高但采纳率低的说明 Skill 定义有问题需要优化触发条件或执行逻辑。我每季度做一次这样的评估过去两个季度淘汰了 5 个 Skill优化了 12 个新增了 8 个。这套体系是活的不是装完就不管了。6.4 团队协作中的 Skill 管理如果你在团队里用这套东西管理方式要变。个人使用时Skill 放本地就行团队使用时需要版本控制和共享机制。我的做法是把 Skill 目录放到 Git 仓库里每个人都可以提交新的 Skill 或修改现有的。修改需要走 Pull Request至少一个人审核。审核的重点是触发条件是否清晰、执行逻辑是否符合团队的方法论、输出格式是否统一。另外团队使用时需要一份Skill 使用手册说明每个 Skill 的适用场景、输入要求、输出示例。这份手册不用写得很正式一个共享文档就行但必须有否则新人不知道有哪些 Skill 可用也不知道怎么用。提示团队协作时Skill 的命名要统一规范。我的习惯是“类别-动作-对象”比如“内容-生成-标题”“SEO-分组-关键词”。这样在列表里排序清晰找起来快。7. 我个人的使用体会这套 Skill 体系我用了大概三个月最大的感受是它把 AI 从“聊天对象”变成了“工作伙伴”。以前用大模型是我问它答问答之间没有结构现在用 Skill是我定义任务它按流程执行执行完我审核。这个转变看起来小但实际效率差别很大。另一个体会是Skill 的质量取决于你对业务的理解深度。项目自带的 Skill 是通用模板能用但不够贴。真正好用的 Skill 是你自己根据团队方法论改出来的。我改过的 Skill 里效果最好的几个都是把团队内部的经验固化进去的比如“我们家的标题必须包含数字和年份”“我们的邮件开头不能超过两句话”。这些约束 AI 自己不会知道但你写进 Skill 里它就能稳定执行。最后说一个实际数据。我用这套体系之前内容营销的产出大概是每周 3 篇长文加 10 条社媒帖子。用了之后同样的时间能产出 5 篇长文加 20 条帖子而且质量没有下降因为框架和初稿由 AI 完成我的精力集中在策略和终审上。这个提升不是 AI 带来的是结构化的工作流带来的AI 只是执行者。如果你也在做 AI Agent 相关的项目我的建议是不要追求 Skill 的数量先把你最常做的三件事写成 Skill跑通、调优、稳定之后再扩展。50 个 Skill 听起来很多但真正每天用的可能就 5 到 8 个。把这几个打磨好价值远大于堆一堆用不上的技能。