1. 从"marketingskills"这个标题说起：它到底在解决什么问题
第一次看到"marketingskills"这个词，我脑子里冒出来的不是某个具体工具，而是一类很实际的需求：做独立站、做SEO、做转化率优化的人，手里往往有一堆零散的动作——写文案、调页面结构、改标题标签、分析落地页跳出率——但这些东西散落在各种工具和文档里，没有一个统一的"技能包"把它们串起来。而"marketingskills"这个标题，本质上指向的就是把营销相关的操作能力，封装成一套可以被复用、被调用、被自动化的技能集合。
关键词里出现了Claude Code、AI agents、SEO、CRO这几个词，这基本锁定了场景：用AI agent的方式，把SEO和CRO这类营销工作流做成可执行的技能模块。CRO是Conversion Rate Optimization，转化率优化；SEO是搜索引擎优化。这两个是独立站和内容站最核心的两件事。而Claude Code在这里扮演的角色，是一个能直接读写文件、执行终端命令、跑脚本的AI编程代理，它不只是聊天，而是能真正动手改代码、改配置、跑分析。
所以这篇内容适合谁看？三类人：第一类是做独立站或者内容站、想用AI把SEO和CRO流程自动化的运营；第二类是已经在用Claude Code、想把它从"写代码工具"扩展成"营销工作流引擎"的开发者；第三类是对AI agents感兴趣、想看看营销场景下agent能落地到什么程度的技术人。不管你是哪一类，核心逻辑是一样的：把重复的营销动作抽象成技能，让agent去执行，人只做判断和决策。
我自己的体会是，很多人一上来就想搞一个"全自动营销机器人"，结果发现根本跑不通，因为营销里太多判断依赖上下文和业务理解。正确的做法是先拆技能，再谈自动化。下面我就按这个思路，把marketingskills这套东西拆开讲。
2. 拆解marketingskills：SEO与CRO技能模块的边界划分
2.1 为什么不能把SEO和CRO混成一个技能
我见过不少人做技能封装时，图省事把"优化页面"做成一个大而全的技能，输入一个URL，输出一堆建议。这种做法的直接后果是：agent不知道该在什么阶段调用它，也不知道输出的建议该落到哪个文件、哪个字段。SEO和CRO虽然都作用于页面，但它们的判断依据和产出物完全不同。
SEO关注的是页面能不能被搜索引擎正确抓取、理解、排序，产出物通常是标题标签、meta描述、结构化数据、内链结构、sitemap、robots配置这类偏"机器可读"的东西。CRO关注的是真实用户到了页面之后会不会转化，产出物通常是CTA按钮文案、表单字段数量、首屏信息密度、信任元素位置这类偏"人可感知"的东西。两者的优化目标甚至可能冲突——比如SEO希望页面内容足够丰富以覆盖更多关键词，CRO希望首屏足够聚焦以降低认知负担。
所以marketingskills的第一层拆分，就是按"面向机器"和"面向人"把技能分开。这不是为了好看，而是为了让每个技能的输入输出边界清晰，agent调用时不会串味。
2.2 技能颗粒度：拆到多细才算合适
颗粒度这个问题，我踩过坑。一开始拆得太粗，一个技能叫"优化落地页"，结果agent拿到这个技能后完全不知道从哪下手，因为它需要同时处理文案、结构、技术SEO、加载性能，信息量太大。后来拆得太细，一个技能只做"检查title标签长度"，结果技能数量爆炸，维护成本极高，而且agent在编排时要在几十个技能里挑，反而容易出错。
我的经验是：一个技能对应一个"可独立验证的产出物"。比如"生成meta描述"这个技能，输入是页面核心内容，输出是一段符合长度要求的描述文本，这个产出物可以单独拿出来验证对错。再比如"检查并修复内链锚文本"这个技能，输入是页面HTML，输出是修改后的HTML加一份变更清单，同样可验证。按这个标准拆，SEO方向大概能拆出十来个核心技能，CRO方向也能拆出十来个，加起来二十多个，这个量级对agent来说是可管理的。
2.3 技能之间的依赖关系怎么理
拆完技能不是就完事了，还得理清楚谁依赖谁。举个实际例子：CRO里的"优化表单转化"技能，它依赖"分析当前表单字段"这个前置技能的输出；而"分析当前表单字段"又依赖"抓取页面DOM结构"这个更底层的技能。如果依赖关系没理清，agent在编排时可能跳过前置步骤直接调后面的技能，拿不到输入数据就瞎编。
我的做法是给每个技能标注清楚三样东西：输入依赖、输出格式、前置技能。这三样写在一个技能描述文件里，agent在规划任务链时会先读这个描述，再决定调用顺序。这个描述文件本身也是marketingskills的一部分，而且是最容易被忽略但最关键的部分。
3. 用Claude Code承载marketingskills的工程化思路
3.1 为什么选Claude Code而不是纯聊天式AI
纯聊天式AI做营销建议，最大的问题是它只能"说"，不能"做"。你问它"帮我优化这个页面的title"，它会给你一段建议文本，但你还得自己复制粘贴到文件里。而Claude Code这类能操作文件系统和终端的agent，可以直接读取你的项目文件、修改配置、跑构建脚本、执行分析命令。这个差别在单次操作上不明显，但在批量处理几十上百个页面时，差距是数量级的。
具体到marketingskills，Claude Code能做的事情包括：直接读取站点源码里的模板文件，批量修改meta标签，跑一个脚本扫描全站内链，执行Lighthouse或者类似工具拿到性能数据，然后根据数据调整页面结构。这些动作如果靠人工，一个站点几百个页面，光改title就能耗掉一整天。用agent跑，配置好技能之后，可能十几分钟就出结果。
3.2 技能以什么形式存在：文件、脚本还是提示词
这是工程化里最实际的问题。marketingskills不能只是一堆提示词，因为提示词没法保证输出格式稳定。我的做法是三层结构：最底层是脚本，负责确定性的数据处理，比如解析HTML、计算关键词密度、生成sitemap；中间层是提示词模板，负责需要语言理解和生成的环节，比如写meta描述、生成CTA文案；最上层是技能描述文件，告诉agent什么场景调用哪个脚本加哪个提示词。
这样分层的好处是，确定性的活交给代码，不确定性的活交给模型，各司其职。比如"检查title标签是否超过60个字符"这种活，写个正则脚本一秒跑完，没必要让模型去数。而"根据页面内容生成一个吸引点击的title"这种活，就得靠模型。把两者混在一起，要么浪费算力，要么结果不稳定。
3.3 环境准备里最容易翻车的几个点
Claude Code的安装和配置，网上教程很多，但有几个坑是教程里不太提的。第一个是Node版本，Claude Code对Node版本有要求，版本太低会直接报错，建议用当前LTS版本。第二个是权限问题，在Linux或者macOS上，如果项目目录权限设置不对，agent读写文件会失败，表现是"命令执行成功但文件没变"。第三个是终端环境，有些终端模拟器对交互式命令支持不好，agent执行需要交互的命令时会卡住，建议在配置里把需要交互的命令改成非交互模式。
还有一个容易被忽略的点：agent执行终端命令时的工作目录。如果没显式指定，它可能在错误的目录下执行，导致找不到文件。我的习惯是在技能描述里明确写清楚工作目录，或者在调用前先执行一个cd命令。
4. 把SEO技能落到实操：从关键词到页面结构的完整链路
4.1 关键词研究技能：从种子词到可执行清单
关键词研究是SEO的起点，但很多人做这一步时只是拉一堆词出来，没有转化成可执行的页面动作。marketingskills里的关键词技能，目标不是给你一个词表，而是给你一个"词到页面"的映射清单。具体来说，输入是一组种子词，输出是每个词对应的目标页面、建议的title、建议的H1、以及这个词的竞争难度评估。
这个技能的实现逻辑是：先用脚本调关键词工具的接口或者读取本地词库，拿到搜索量和竞争度数据；然后用模型对词做聚类，把语义相近的词归到一组，对应同一个页面；最后生成每个页面的优化建议。这里的关键是聚类这一步，纯靠脚本做不好，因为语义相似度需要模型判断；纯靠模型做又太慢，因为词量可能上千。所以是脚本先做粗筛，模型再做精聚类。
我实测下来，一个中等规模的站点，几百个关键词，这个技能跑完大概需要几分钟，产出的清单可以直接交给下一个技能去改页面。
4.2 页面元素优化技能：title、meta、H标签的批量处理
拿到关键词清单之后，下一步是改页面元素。这个技能处理的是title标签、meta描述、H1到H3的层级结构。为什么这几个要放在一个技能里？因为它们之间有强关联：title和H1应该语义一致但表述不同，meta描述应该包含title里的核心词但更偏向行动号召，H标签的层级应该反映内容的逻辑结构而不是为了塞关键词。
这个技能的执行流程是：先读取页面模板文件，解析出当前的title、meta、H标签；然后根据关键词清单里的建议，生成新的内容；最后写回文件。这里有个细节要注意：写回文件时不能破坏原有的模板语法，比如有些模板引擎用特定占位符，直接字符串替换可能会把占位符也改掉。我的做法是先用解析器把模板结构解析成树，只改文本节点，不动结构节点。
提示：批量改title和meta之前，一定要先备份原文件，或者确保项目在版本控制下。我见过有人跑完技能之后发现改错了几百个页面，又没有备份，只能一个个手动回滚。
4.3 内链结构优化技能：锚文本与链接深度的处理
内链是SEO里被低估的一环。很多站点的内链是随机的，编辑在写文章时随手链到哪算哪，导致重要页面拿不到足够的内链权重，而一些次要页面反而被链了很多次。这个技能的目标是让内链结构更合理：重要页面获得更多内链，锚文本多样化且相关，链接深度控制在合理范围内。
实现上，这个技能先跑一个全站爬取脚本，拿到所有页面和它们之间的链接关系，构建一个有向图；然后计算每个页面的入链数量和链接深度；再根据预设的规则（比如核心页面入链数不低于某个值，任何页面距离首页不超过四跳）生成内链调整建议；最后把建议落到具体的文章内容里，插入或修改链接。
这个技能跑一次可能改动很多文件，所以建议先跑"只分析不改动"模式，看看建议是否合理，确认后再跑"执行改动"模式。
4.4 技术SEO检查技能：那些容易被忽略的配置项
技术SEO这块，很多问题是配置层面的，不涉及内容。比如robots.txt有没有误屏蔽重要目录，sitemap有没有包含所有该包含的页面，canonical标签有没有指错，结构化数据有没有语法错误。这些检查项如果靠人工，很容易漏，因为平时不会天天去看。
marketingskills里的技术SEO技能，本质是一组检查脚本加一个报告生成器。脚本负责跑各项检查，报告生成器把结果整理成可读的清单，标注严重程度。严重程度高的（比如robots误屏蔽）直接标红，建议立即处理；严重程度低的（比如某个图片缺alt）标黄，可以排期处理。
这里有个经验：技术SEO检查最好做成定时任务，每周跑一次，而不是等出问题了才跑。因为很多配置问题是慢慢积累的，比如随着文章增多，内链深度逐渐变深，sitemap逐渐变大，这些变化是渐进的，定期检查才能及时发现趋势。
5. CRO技能模块：让页面从"能看"变成"能转化"
5.1 首屏信息密度分析：用户三秒内看到了什么
CRO的核心是理解用户在页面上的行为，而首屏是决定用户去留的关键区域。这个技能做的事情是：抓取页面首屏的渲染结果，分析其中包含的信息元素——标题、副标题、主图、CTA按钮、信任标识——然后评估信息密度是否合理。
什么叫信息密度不合理？两种情况：一种是太稀疏，首屏只有一张大图和一句模糊的标语，用户不知道这个页面是干什么的，也不知道下一步该做什么；另一种是太密集，首屏塞了五六个不同的卖点和三个CTA按钮，用户注意力被分散，反而什么都不点。合理的状态是首屏有一个清晰的主信息，一个明确的行动指引，加一两个辅助的信任元素。
这个技能的实现需要能渲染页面，因为很多首屏内容是JavaScript动态生成的，直接读HTML源码拿不到。所以要用无头浏览器跑一遍，截图加提取DOM，然后分析。分析部分可以用模型来判断信息是否清晰，也可以用规则来判断元素数量和位置。
5.2 CTA按钮优化技能：文案、位置与视觉权重
CTA按钮是转化的直接触发点，但很多站点的CTA做得很随意。这个技能从三个维度优化CTA：文案、位置、视觉权重。文案方面，把"提交""了解更多"这种模糊表述改成有具体利益点的表述；位置方面，确保首屏有一个主CTA，长页面在中段和末尾各有一个；视觉权重方面，确保CTA按钮在视觉上足够突出，不被其他元素淹没。
文案优化这块，模型比人更有优势，因为它可以快速生成几十个变体，然后根据历史数据或者A/B测试结果筛选。位置和视觉权重则更适合用规则来判断，比如"首屏必须有一个CTA"这种规则，写死在技能里就行。
我自己的经验是，CTA文案的优化效果往往被低估。同一个页面，只改CTA文案，转化率差出百分之二三十是常有的事。所以这个技能值得反复跑，每次生成一批新文案，持续测试。
5.3 表单转化优化：字段数量与填写阻力的平衡
表单是转化漏斗里最容易流失的环节。每多一个字段，就多一层流失。但这个技能不是简单地"字段越少越好"，因为有些字段是业务必需的，少了没法后续跟进。所以核心是找到"业务必需"和"用户愿意填"之间的平衡点。
这个技能的分析逻辑是：先列出当前表单的所有字段，标注每个字段的业务必要性；然后分析每个字段的填写阻力，比如"手机号"比"邮箱"阻力大，"公司名称"比"姓名"阻力大；最后给出优化建议，比如把非必需字段改成选填、把阻力大的字段后置、把多个字段合并成一个。
还有一个技巧是"渐进式表单"，先只让用户填最少的字段完成第一步，后续信息在用户已经产生沉没成本之后再逐步收集。这个模式在很多场景下比一次性填完所有字段的转化率高。
5.4 信任元素布局：评价、案例、保障标识怎么放
信任元素是转化的催化剂，但放错位置等于没放。这个技能处理的是评价、客户案例、退款保障、安全标识这类元素的布局。核心原则是：信任元素要出现在用户产生疑虑的位置附近。比如价格旁边放退款保障，表单旁边放隐私承诺，CTA按钮下方放用户评价。
实现上，这个技能先分析页面的"疑虑点"——通常是价格、表单、购买按钮这些位置；然后检查这些位置附近有没有信任元素；最后给出插入建议。信任元素的内容可以从已有的评价数据里提取，也可以用模型根据产品特点生成。
6. 技能编排：让多个marketingskills协同工作的实战链路
6.1 单次任务链的设计：从输入URL到输出报告
单个技能跑通不难，难的是把多个技能串成一条任务链。举个完整的例子：输入一个URL，期望输出一份包含SEO和CRO建议的综合报告。这条链大概是这样的：先跑页面抓取技能拿到页面内容，然后并行跑SEO分析技能和CRO分析技能，SEO这边再细分跑关键词匹配、元素检查、内链分析，CRO这边细分跑首屏分析、CTA检查、表单分析，最后跑报告生成技能把所有结果汇总。
这条链的设计要点是：能并行的就并行，减少总耗时；有依赖的必须串行，保证输入正确。比如关键词匹配依赖页面内容抓取，就必须等抓取完成；而SEO分析和CRO分析之间没有依赖，可以同时跑。
6.2 批量处理时的并发与限流
单页面跑通了，下一步是批量。一个站点几百个页面，如果一个个串行跑，时间会很长。这时候要考虑并发。但并发不是越高越好，因为有些技能会调外部接口，接口有频率限制；有些技能会大量读写磁盘，并发太高反而变慢。
我的做法是给每个技能标注一个"并发安全等级"，读多写少的技能可以高并发，写文件的技能必须串行或者加锁。然后在编排层做一个简单的调度器，根据技能等级决定并发数。这个调度器不用很复杂，一个队列加一个并发计数器就够了。
6.3 结果验证：怎么知道技能跑对了
技能跑完不代表跑对了。尤其是涉及内容生成的技能，模型可能生成看起来合理但实际有问题内容。所以每个技能都要有验证环节。验证分两种：一种是格式验证，检查输出是否符合预期格式，比如meta描述是否在长度范围内；另一种是内容验证，检查输出是否和输入相关，比如生成的title是否包含了目标关键词。
格式验证用脚本做，快且准。内容验证可以用模型做，让另一个模型实例来判断"这个输出是否合理"，或者用规则做，比如检查关键词是否出现。我倾向于两者结合，脚本做初筛，模型做复核。
7. 实操中踩过的坑与应对经验
7.1 模型生成内容的不稳定性怎么处理
模型生成的内容，同一个输入跑两次可能得到不同结果。这在单次操作时没问题，但在批量处理时会导致不一致。比如同一批页面，有的title生成得很规范，有的就偏了。应对办法是给模型更严格的约束：提供few-shot示例，明确输出格式，限制生成长度，必要时用温度参数降低随机性。但即使这样，也不能保证百分之百一致，所以批量处理之后一定要有人工抽检环节。
7.2 技能描述写得太模糊导致agent乱调用
技能描述是给agent看的，如果描述里只写"优化页面"，agent可能在任何场景都调用它。所以描述要写清楚适用场景和不适用场景。比如"本技能适用于已有明确目标关键词的页面，不适用于关键词尚未确定的页面"。这样agent在规划任务链时就能正确判断该不该调用。
7.3 文件读写权限与版本控制的配合
批量改文件之前，确保项目在版本控制下，这样改错了可以回滚。如果项目不在版本控制下，至少要先做一次完整备份。另外，agent读写文件时用的用户身份要和文件所有者一致，否则会出现"能读不能写"的情况。在Linux上尤其要注意这点。
7.4 外部接口调用的失败重试
关键词工具、页面分析工具这些外部接口，偶尔会超时或者返回错误。技能里要加失败重试逻辑，但不能无限重试，一般重试两到三次，还失败就跳过并记录，不要因为一个页面失败导致整个批量任务卡住。
8. 关于marketingskills这套思路的延伸想法
这套东西跑通之后，我发现它的价值不局限于SEO和CRO。同样的技能封装思路，可以迁移到内容生产、社媒运营、邮件营销这些场景。核心逻辑是一样的：把重复的判断和操作抽象成技能，让agent去执行，人只做策略和审核。
另外一个感受是，技能库是需要持续迭代的。搜索引擎的规则在变，用户的偏好在变，技能里的规则和提示词也要跟着更新。我现在的习惯是每个月回顾一次技能库，看看哪些技能的产出质量下降了，哪些技能的使用频率变低了，然后针对性地调整。这个维护成本不高，但不做的话，技能库会慢慢失效。
最后分享一个小心得：刚开始搭技能库时，不要追求大而全，先挑一个最痛的点，做一个最小可用的技能，跑通之后再扩展。我一开始就是先做了title和meta的批量优化，因为这个最直接、最容易验证效果，跑通之后有了信心，再逐步加其他技能。这个顺序比一上来就搭大框架要靠谱得多。
