1. 从marketingskills这个标题说起它到底想解决什么问题第一次看到marketingskills这个项目名我的直觉是这不是一个单纯的工具库而更像是一套能力封装。它把营销场景里那些重复、琐碎、但又必须做扎实的动作——SEO 诊断、转化率优化CRO、数据埋点分析、内容分发——打包成一组可被 AI agent 调用的技能模块。换句话说它试图回答一个很现实的问题当 AI 已经能写文案、能读数据、能跑脚本的时候营销人到底该怎么把这些能力接到自己的日常流程里而不是每次从零开始写提示词。这个项目的核心价值不在于它提供了多少条提示词而在于它把营销动作抽象成了技能skill这一层。技能和提示词的区别就像菜谱和食材的区别食材谁都能买但菜谱决定了你什么时候放盐、火候多大、什么时候起锅。marketingskills想做的就是给 AI agent 一套营销领域的菜谱让它在面对帮我看看这个落地页为什么转化低这类问题时知道先查什么、再查什么、最后怎么给结论。适合读这篇内容的人我大致分三类。第一类是独立站运营者尤其是做谷歌 SEO 和付费流量的手里有站点、有数据但缺一套系统化的诊断方法第二类是增长/营销方向的从业者想借助 AI agent 把重复劳动自动化比如批量生成 meta 描述、批量检查内链结构第三类是对 AI agent 落地感兴趣的开发者想看看技能这种抽象在真实业务里长什么样。不管你是哪一类这篇内容都会从为什么这样设计讲到具体怎么跑起来尽量让你看完能直接上手。需要提前说明的是marketingskills本身是一个偏概念和框架的项目它依赖 AI agent 的运行环境比如 Claude Code 这类能在本地执行命令、读写文件的 agent 工具来发挥价值。所以我会花不少篇幅讲清楚技能是怎么被 agent 调用的以及在这个过程中容易踩的坑。这些坑我在实际配置和调试时都遇到过有些还挺隐蔽后面会逐个拆开讲。2. 为什么营销场景特别适合技能化封装2.1 营销动作的三个特征高频、可枚举、有明确产出营销工作有个很尴尬的特点它既需要创意又充满了大量机械重复。写一篇深度文章需要灵感但检查 200 个页面的 title 标签是否重复、是否超过 60 字符这纯粹是体力活。marketingskills的切入点就在这里——把那些高频、可枚举、有明确产出的动作抽出来做成技能。我拿 SEO 举例。一个完整的 SEO 审计拆开来看无非是这几件事抓取站点结构、检查 robots 和 sitemap、分析 title/description 的覆盖率和重复率、检查 H 标签层级、看内链分布、评估页面加载相关的技术指标、对比关键词排名。这些动作每一个都有明确的输入一个 URL 或一份页面列表和明确的输出一份问题清单。这种输入输出清晰的特性正是技能化封装的最佳土壤。反过来像帮我策划一个品牌 campaign这种任务输入模糊、输出开放就不适合做成固定技能更适合让 agent 自由发挥。理解这个边界很重要否则你会试图把什么都塞进技能里最后发现技能又臭又长还不如直接对话。2.2 技能和提示词的本质区别可复用、可组合、可版本管理很多人会把技能理解成高级提示词这个理解只对了一半。提示词是一次性的你这次写了一段让 AI 分析落地页的话下次换个页面还得重写。技能不一样它是一份带参数的、可复用的操作说明书。我自己的体会是技能至少带来三个好处。第一是一致性同一个技能每次执行检查项和判断标准都一样不会因为今天心情好多查两项、明天赶时间少查两项。第二是可组合一个落地页诊断技能可以调用标题检查CTA 分析表单字段审查三个子技能像搭积木一样。第三是可版本管理技能是文件可以放进 Git改了什么、为什么改都有记录。这在团队协作里太重要了——你不想每次换个人接手诊断标准就全变了。提示判断一个动作该不该做成技能我的标准是这个动作我一个月内会不会重复做三次以上。会就值得封装不会直接对话更省事。2.3 从人找工具到agent 调技能的范式转变传统工作流是人找工具我要做 SEO 审计打开 Screaming Frog我要看转化打开 GA我要查排名打开 Search Console。工具之间数据不通人成了搬运工。marketingskills代表的是一种转变agent 成为调度中心技能成为它的手。你告诉 agent帮我审计 example.com 的 SEO 状况agent 自己去调用抓取技能、分析技能、报告生成技能最后给你一份整合结论。人从操作工具变成定义目标。这个转变听起来很美但落地时有前提agent 必须能访问数据源。这就是为什么这类项目通常和 Claude Code 这种能在本地执行终端命令、读写文件的 agent 绑定——因为只有能跑命令agent 才能真正去抓页面、跑脚本、读日志。纯聊天式的 AI 做不到这一点它只能基于你粘贴给它的内容分析。3. 把 marketingskills 跑起来环境准备里那些没人告诉你的细节3.1 agent 运行环境的选择为什么本地执行能力是硬门槛前面说了技能要真正干活agent 得有手。这个手就是本地执行能力。市面上能提供这种能力的 agent 工具不多Claude Code 是其中比较有代表性的一个——它能在你的终端里执行命令、读写项目文件、调用外部脚本。marketingskills这类项目通常就是围绕它设计的。这里有个常见误区很多人以为装个桌面版客户端就够了。实际上桌面版和命令行版的能力边界不一样。命令行版CLI通常对本地文件系统和终端命令的访问更直接适合跑需要读写文件、执行脚本的技能桌面版更偏向交互体验适合日常对话和轻量任务。如果你要跑的是批量抓取站点并生成报告这种重活CLI 是更稳的选择。安装环节本身不复杂但有几个细节容易卡住人。第一是运行环境Node.js 版本建议用 LTS长期支持版太新的版本有时候会和某些依赖冲突。第二是权限agent 要执行终端命令你得确保它在你授权的目录下有读写权限否则技能跑到一半报permission denied排查起来很费劲。第三是网络环境抓取外部站点、调用 API 都需要稳定的网络这个不用多说。3.2 技能目录的组织方式一个清晰的目录结构能省你一半时间marketingskills这类项目技能通常以文件形式存在。我建议的目录组织方式是这样的marketingskills/ ├── seo/ │ ├── audit-site.md # 站点级 SEO 审计技能 │ ├── check-meta.md # meta 标签检查技能 │ └── internal-links.md # 内链结构分析技能 ├── cro/ │ ├── landing-page-review.md # 落地页转化诊断 │ └── form-analysis.md # 表单字段与流失分析 ├── analytics/ │ ├── traffic-report.md # 流量报告生成 │ └── funnel-analysis.md # 漏斗分析 └── shared/ ├── fetch-page.md # 通用页面抓取技能 └── report-format.md # 统一报告格式规范这个结构的好处是按业务域分层。SEO、CRO、analytics 各自独立共享的底层能力抓取、报告格式放在 shared 里。当你要新增一个技能时先想清楚它属于哪个域再决定放哪。我见过有人把所有技能平铺在一个目录里几十个文件堆在一起找起来眼花缭乱改起来还容易误伤。注意技能文件命名尽量用动词名词的形式比如check-meta、audit-site一眼能看出这个技能干什么。别用skill1、test这种名字过两周你自己都不记得是啥。3.3 让 agent 认识你的技能注册与索引机制技能文件写好了agent 怎么知道它们存在这就涉及注册机制。不同 agent 工具的做法不一样但核心逻辑类似要么在配置文件里显式声明技能路径要么让 agent 扫描指定目录自动索引。我倾向于显式声明因为可控。自动扫描虽然省事但技能一多agent 每次启动都要扫一遍慢不说还可能把你不想要的临时文件也索引进去。显式声明的话你清楚知道哪些技能是激活状态调试时也容易定位问题。注册完之后建议做个冒烟测试随便挑一个技能让 agent 执行一次看它能不能正确找到技能文件、理解技能意图、按预期产出。这一步别省我见过太多人技能写得很漂亮结果 agent 根本找不到文件白忙活。4. SEO 技能模块的拆解从站点审计到 meta 优化的完整链路4.1 站点级审计技能抓取、解析、问题归类站点级 SEO 审计是marketingskills里最重的一个技能也是最能体现技能化价值的。它的完整链路是这样的先抓取站点通常从 sitemap 或首页出发递归抓内链把页面存下来然后解析每个页面的关键元素title、description、H 标签、图片 alt、内链、外链最后按问题类型归类生成报告。抓取环节有个坑递归深度和并发数要控制好。深度太浅抓不全太深容易陷入无限循环尤其是那些带参数的 URL。并发数太高目标站点可能把你当攻击直接封 IP。我的经验是并发控制在 5 到 10 之间递归深度限制在 3 到 4 层同时设置一个最大抓取页数上限比如 500 页防止小站点抓出几万页的意外情况。解析环节的关键是标准化。不同站点的 HTML 结构千差万别但 SEO 关注的核心元素是固定的。技能里要定义清楚title 取title标签内容description 取meta namedescriptionH1 取第一个h1等等。遇到缺失的元素标记为缺失而不是报错跳过因为缺失本身就是个问题。问题归类我习惯分四档致命比如整站 noindex、robots.txt 屏蔽了所有爬虫、严重大量重复 title、关键页面缺失 H1、一般description 过长或过短、图片缺 alt、建议内链可以更丰富、URL 结构可以更语义化。分档的好处是报告出来之后运营者知道先修哪个。4.2 meta 标签批量检查重复率、长度、关键词覆盖meta 标签检查是个典型的看起来简单、做起来琐碎的活。一个 500 页的站点人工检查 title 和 description 得花大半天还容易漏。做成技能之后几分钟出结果。检查维度我一般设这几个。重复率完全相同的 title 有多少组高度相似的比如只差一个词有多少组。长度title 建议 50 到 60 字符description 建议 120 到 158 字符超出会被搜索引擎截断。关键词覆盖目标关键词有没有出现在 title 和 description 里出现的位置靠不靠前。这里有个细节值得说长度计算要按字符数还是像素宽度严格来说搜索引擎是按像素宽度截断的中文字符和英文字符宽度不同。但实操中按字符数估算已经够用除非你做的是多语言站点中英混排那最好按像素宽度算。技能里可以内置一个简单的宽度估算函数中文按 2 个单位、英文按 1 个单位累加。提示批量检查出来的重复 title不要急着全改。先看这些页面是不是分页或筛选产生的这类页面有时候用相同 title 是合理的强行差异化反而可能引入新问题。4.3 内链结构分析孤岛页面与权重流动内链是 SEO 里最容易被忽视、但影响很大的部分。搜索引擎靠链接爬行和理解页面关系内链结构乱了权重流动就不畅有些页面可能永远不被收录。内链分析技能主要看三件事。第一是孤岛页面没有任何内链指向的页面。这类页面搜索引擎很难发现除非在 sitemap 里。第二是链接深度从首页出发点几次能到目标页面。深度超过 4 层的页面抓取优先级会下降。第三是锚文本分布指向同一个页面的内链锚文本是不是太单一或者太泛比如全是点击这里。我做过一个站点首页内链指向的全是导航栏那几个页面几百篇内容页只能靠 sitemap 被发现收录率一直上不去。后来在相关文章模块里加了内链两个月后收录率从 60% 涨到 90% 多。这个案例说明内链分析不能只看有没有链接还要看链接放的位置合不合理。5. CRO 与 analytics 技能让数据真正指导决策5.1 落地页转化诊断从首屏到表单的逐层排查CRO转化率优化技能的核心是逐层排查。一个落地页的转化路径大致是用户到达 → 看首屏 → 往下滚动 → 找到 CTA → 点击 → 填表单 → 提交。每一层都有流失技能要做的就是定位流失最严重的那一层。首屏排查看什么看价值主张是否清晰用户 3 秒内能不能明白你是干嘛的、看主 CTA 是否可见不用滚动就能看到、看视觉焦点是否被无关元素抢走。往下滚动看什么看内容节奏是不是一大段文字没有分隔、看信任元素评价、案例、资质有没有、看 CTA 是否重复出现。表单是流失重灾区。字段越多流失越高这是常识。但具体到你的业务哪个字段最劝退技能可以结合 analytics 数据回答如果表单有公司规模这个字段而放弃填写的人里 70% 都停在这一步那这个字段就值得重新考虑。5.2 流量与漏斗分析技能把 GA 数据翻译成行动项analytics 技能的价值在于翻译。GA 里一堆数字跳出率、会话时长、转化率运营者看得懂数字但看不懂所以呢。技能要做的是把数字翻译成行动项。比如某个渠道的跳出率 85%远高于站点平均的 55%。技能不应该只报告这个数字而应该进一步分析这个渠道来的用户落地页是哪个落地页内容和渠道广告的承诺一致吗如果广告说免费试用落地页却要预约演示那跳出率高就说得通了。这种数字 → 原因 → 行动的链路才是 analytics 技能该产出的东西。漏斗分析同理。用户从访问到加购到下单每一步的转化率是多少哪一步掉得最狠。掉得最狠的那一步就是优化优先级最高的地方。技能可以自动算出每一步的转化率并和行业基准对比给出正常/偏低/严重偏低的判断。5.3 报告生成技能统一格式让结论可执行前面所有技能产出的都是原始发现报告生成技能负责把它们整合成一份人能读、能执行的文档。格式统一很重要我习惯用这个结构模块内容执行摘要3 到 5 条最重要的发现按严重程度排序问题清单每个问题含描述、影响范围、严重程度、修复建议数据附录支撑结论的原始数据方便复核行动优先级按影响 × 紧急度排序的待办清单这个结构的好处是分层阅读。老板只看执行摘要执行的人看问题清单和行动优先级需要深挖的看数据附录。一份报告满足三种读者比写三份报告高效得多。6. 实操中踩过的坑与排查思路6.1 技能被 agent 忽略从文件格式到触发词的排查链路我遇到最多的问题是技能写好了agent 却不调用。排查这个问题的链路我总结成四步。第一步确认文件被索引了。让 agent 列出它当前能看到的技能如果列表里没有你的技能那就是注册或路径问题。第二步确认文件格式正确。技能文件通常有固定的头部格式比如 YAML front matter少个冒号、缩进错了agent 就解析不了。第三步确认触发词匹配。技能里一般会写什么时候用这个技能如果你的提问和触发词对不上agent 就不会调用。第四步确认技能描述清晰。描述太模糊agent 判断不了该不该用。这四步里第三步最隐蔽。我写过一个检查页面加载速度的技能触发词写的是性能分析结果我提问时说看看这个页面快不快agent 就没触发。后来把触发词改得更口语化问题就解决了。6.2 抓取被限流或封禁并发、频率与 User-Agent 的处理抓取外部站点时被限流几乎是必然的。目标站点的防护策略各不相同有的看频率有的看并发有的看 User-Agent。我的处理原则是先慢后快。第一次抓一个新站点并发设 1每次请求间隔 1 到 2 秒先抓 10 个页面看看反应。如果顺利再逐步提高并发、缩短间隔。如果遇到 429请求过多或 403禁止访问立刻降速并检查 User-Agent 是不是被识别成了爬虫。User-Agent 这块有个细节不要伪装成搜索引擎的爬虫比如 Googlebot这既不道德也可能触发更严格的验证。老老实实用一个正常的浏览器 UA配合合理的抓取频率大多数站点不会为难你。注意抓取前先看目标站点的 robots.txt这是基本礼仪也是避免法律风险的必要步骤。robots.txt 里 Disallow 的路径别碰。6.3 分析结果看起来对但没用如何让技能产出可执行结论这是最让人沮丧的坑技能跑通了报告生成了数据都对但看完不知道要干嘛。问题出在技能的设计上——它只做了描述没做判断。举个例子。技能报告这个页面有 3 个 H1 标签。这是描述。但3 个 H1 会导致搜索引擎困惑建议保留 1 个其余降级为 H2——这才是判断加建议。技能里必须内置判断规则否则产出的就是一堆数字不是洞察。我的做法是每个检查项都配一条判断逻辑。比如 title 长度规则是小于 30 字符标记过短30 到 60 标记正常大于 60 标记过长。有了规则技能才能自动给出结论而不是把原始数据甩给你。6.4 技能之间的依赖与冲突组合调用时的顺序问题当技能开始组合调用时顺序就变得重要了。比如站点审计技能内部会调用抓取技能和meta 检查技能。如果抓取还没完成meta 检查就没数据可查。处理依赖关系我建议在技能里显式声明前置条件。比如 meta 检查技能开头写清楚本技能需要一份页面列表作为输入如果输入为空先调用抓取技能。这样 agent 在组合调用时就知道该先做什么。冲突则更微妙。两个技能可能对同一份数据给出不同建议。比如一个技能说title 越短越好另一个说title 要包含完整关键词可以长一点。这种冲突要在技能设计阶段就协调好统一判断标准否则 agent 会无所适从。7. 我对这套东西的真实看法用了一段时间marketingskills这类技能化方案我最大的感受是它把营销工作里可标准化的部分和需要人判断的部分分开了。标准化的部分交给技能跑得快、不出错、可复用需要判断的部分留给人比如这个品牌调性该用什么语气这个转化目标合不合理。这个分工挺健康的。以前营销人大量时间耗在重复劳动上现在可以把精力挪到真正需要思考的地方。但也要清醒技能不是万能的。它擅长检查和归纳不擅长创造和权衡。指望它替你做战略决策那是不现实的。另外技能是需要维护的。搜索引擎的规则在变用户的行为在变技能的判断标准也得跟着更新。我建议每隔一两个月回头看看技能里的规则还准不准有没有新的检查项该加进去。把技能当成一份活的文档而不是写完就扔的脚本。最后分享一个小技巧刚开始别贪多先做两三个技能跑顺了再扩展。我见过有人一上来就规划了二十个技能结果每个都半成品用起来处处是坑。技能这东西质量比数量重要得多。一个打磨到位的站点审计技能价值超过十个粗糙的半成品。