1. 项目缘起：为什么我把营销方法论拆成了可执行的技能包
做增长这几年，我最大的感受是：营销这件事，方法论从来不缺，缺的是“把方法论变成动作”的那一层。你看过的SEO教程、CRO案例、数据分析框架加起来能塞满一个硬盘，但真到了要落地的时候，还是得靠人肉去拆解、去判断、去执行。尤其是这两年AI agents开始进入工作流，我一直在想一个问题——能不能把营销里那些高频、重复、但有明确判断标准的活儿，封装成一套结构化的技能，让AI agent直接调用？
marketingskills这个项目就是从这个念头开始的。它不是又一个营销课程，也不是一个SaaS工具，而是一套面向AI agents的营销技能定义集合。核心思路很简单：把SEO、CRO、analytics这三个营销核心领域里的关键操作，拆解成AI agent能理解、能执行、能验证的标准化技能单元。每个技能单元包含明确的输入输出定义、判断逻辑、执行步骤和验证标准。
这套东西解决的是什么问题？我举个实际场景。你运营一个独立站，需要定期做关键词布局检查、落地页转化率诊断、流量异常排查。传统做法是你自己打开工具，导出数据，逐条分析，然后手动改。有了这套技能包，你可以让AI agent按预设的逻辑自动跑一遍，输出一份带优先级的行动清单。你从执行者变成了审核者，效率差距是数量级的。
适合谁来参考？三类人。第一类是做独立站或内容站的运营，手上有站但没精力做精细化营销的。第二类是在用Claude Code这类AI编程工具做自动化工作流的开发者，想把营销场景接进去的。第三类是对AI agents应用感兴趣、想看看营销领域怎么落地的技术同学。不管你是哪类，只要你对“让AI帮你干营销的脏活累活”这件事有兴趣，这套思路都值得一看。
2. 整体设计思路：营销技能为什么要做成“技能包”而不是“提示词”
2.1 从提示词到技能包，差的是可复用性
很多人用AI做营销的方式是写一段提示词，比如“帮我分析这个页面的SEO问题”，然后每次用的时候复制粘贴。这种方式的问题在于：第一，每次输出的质量不稳定，因为提示词没有版本管理；第二，没法组合，你没法把“关键词分析”和“内容优化建议”串成一个流水线；第三，没法验证，你不知道AI给的结论对不对。
marketingskills的设计思路是把每个营销动作定义成一个独立的技能单元。每个单元有固定的结构：技能名称、适用场景、输入参数、执行逻辑、输出格式、验证规则。这样做的好处是，技能可以被AI agent按需调用，也可以被组合成更复杂的工作流。比如“关键词机会分析”这个技能，输入是一个种子关键词和竞品域名，输出是一组带搜索量、竞争度、意图分类的关键词列表。这个输出可以直接作为“内容规划”技能的输入，形成链条。
我选择这种设计，是因为营销工作的本质是“判断+执行”的循环。判断需要框架，执行需要步骤。技能包把框架和步骤都固化了，AI agent只需要在框架内做判断，执行步骤由技能定义来保证。这样既保留了AI的灵活性，又避免了“AI胡说八道”的风险。
2.2 为什么选SEO、CRO、Analytics这三个领域
营销的领域很多，但我选这三个作为起点，是因为它们构成了一个完整的闭环。SEO负责获取流量，CRO负责转化流量，Analytics负责衡量和反馈。这三个环节的数据是打通的：SEO的关键词数据可以指导CRO的页面优化，CRO的转化数据可以反馈给Analytics做归因，Analytics的洞察又可以反哺SEO的内容策略。
从技术实现角度，这三个领域的数据结构化程度高，判断标准相对明确，适合做成技能。比如SEO里的标题标签长度、关键词密度、内链结构，都有行业公认的参考范围。CRO里的按钮颜色、表单字段数、页面加载时间，也有大量A/B测试数据支撑。Analytics里的指标定义、异常检测阈值、归因模型，更是有成熟的数学框架。这些“有据可依”的特性，让技能包的验证规则可以写得很具体，而不是模糊的“感觉不错”。
2.3 技能包与AI agent的协作模式
这套技能包不是独立运行的，它需要宿主环境。我主要用Claude Code作为执行环境，因为它的终端集成能力比较强，可以直接读写文件、执行命令、调用API。技能包以Markdown文件的形式存在，每个技能一个文件，放在项目的skills/目录下。AI agent通过读取这些文件来获取技能定义，然后按定义执行。
协作模式是这样的：你先用自然语言告诉agent你要做什么，比如“帮我检查一下这个页面的SEO问题”。agent会匹配到对应的技能文件，读取输入参数要求，然后向你确认或自动获取参数。接着agent按技能定义的步骤执行，每一步的输出都会记录在日志里。最后agent按输出格式生成报告，并根据验证规则做自检。整个过程你是可以干预的，比如在某个步骤暂停、修改参数、或者跳过某个检查项。
这种模式的好处是透明。你知道agent在做什么，为什么这么做，结果是怎么来的。而不是像黑盒一样，输入一个问题，出来一个答案，你不知道中间发生了什么。对于营销这种需要信任和验证的领域，透明性比自动化程度更重要。
3. 核心技能拆解：SEO、CRO、Analytics各自的关键动作
3.1 SEO技能组：从关键词到内容的全链路覆盖
SEO技能组我拆了四个核心技能：关键词机会分析、页面SEO审计、内容差距分析、内链结构优化。每个技能解决一个具体问题，组合起来覆盖从关键词研究到内容发布的全流程。
关键词机会分析的输入是种子关键词和竞品域名，输出是带优先级的关键词列表。执行逻辑分三步：第一步，用种子关键词扩展出一批相关词，扩展方式包括搜索引擎下拉、相关搜索、竞品关键词反查。第二步，对每个词做搜索量、竞争度、商业意图的评估。搜索量用公开的估算工具，竞争度看搜索结果首页的域名权威度分布，商业意图用关键词修饰词判断（比如带“购买”“价格”“推荐”的词商业意图更强）。第三步，按“搜索量×商业意图÷竞争度”算一个机会分，排序输出。
这个技能的关键在于意图分类。我见过太多人做关键词研究只看搜索量，结果选了一堆高搜索量但没商业价值的词。比如“什么是SEO”搜索量很大，但搜这个词的人大概率不会付费。而“独立站SEO优化服务”搜索量小，但搜的人有明确的付费意向。技能包里我把意图分类做成了必选项，每个关键词必须标注是信息型、导航型、商业型还是交易型。这个分类直接影响后续的内容策略和CRO策略。
页面SEO审计的输入是一个URL，输出是一份带优先级的修改建议清单。审计项包括：标题标签长度和关键词位置、元描述长度和吸引力、H1-H6层级结构、图片alt属性、内链数量和质量、页面加载速度、移动端适配、结构化数据标记。每个审计项有明确的通过标准，比如标题标签建议在50-60个字符之间，核心关键词靠前。不通过的项会给出具体的修改建议，比如“标题标签当前72字符，建议精简到58字符，把核心关键词移到前30字符内”。
注意：页面SEO审计不要一次性改太多。我踩过的坑是，一个页面同时改了标题、描述、H1、内链，结果排名波动了两个月才恢复。建议每次只改一个维度，观察两周再改下一个。
内容差距分析的输入是你的域名和竞品域名，输出是竞品有排名而你没有的内容主题列表。执行逻辑是：抓取竞品的排名关键词，过滤掉你已经覆盖的，剩下的按搜索量和商业价值排序。这个技能的价值在于，它告诉你“哪些内容值得写”，而不是凭感觉选题。我自己的站用这个技能跑了一遍，发现竞品在一个我完全没关注的细分场景下有大量长尾词排名，补了五篇内容后，那个场景的流量涨了40%。
内链结构优化的输入是站点地图，输出是内链调整建议。执行逻辑是：分析每个页面的入链数量和来源，识别孤岛页面（入链数为零或极少），然后根据页面主题相关性建议从哪些页面添加内链。内链这个东西很多人忽视，但它对SEO的影响很大。一个孤岛页面，内容再好也很难被搜索引擎赋予权重。技能包里我把内链建议分成了三类：导航型内链（从首页或栏目页指向）、上下文内链（从相关文章正文指向）、聚合型内链（从标签页或专题页指向）。不同类型的优先级不同。
3.2 CRO技能组：把转化率拆成可优化的变量
CRO技能组我拆了三个技能：落地页诊断、表单优化建议、A/B测试设计。这三个技能覆盖了转化率优化的主要场景。
落地页诊断的输入是一个落地页URL和转化目标（比如注册、购买、留资），输出是一份按影响程度排序的问题清单。诊断维度包括：首屏信息清晰度（用户3秒内能否理解你是做什么的）、价值主张强度（有没有说清楚为什么选你）、信任信号（有没有客户案例、资质认证、媒体报道）、行动号召（按钮文案、位置、颜色）、摩擦点（表单字段数、必填项、验证码）。每个维度有评分标准，比如首屏信息清晰度，如果首屏没有一句话说明“你是谁、做什么、为谁服务”，直接判为不合格。
这个技能我用了最久，也踩了最多坑。最大的坑是“过度优化”。有一次我把一个落地页的按钮从蓝色改成橙色，转化率确实涨了，但涨的原因是橙色和页面主色调对比更强，而不是橙色本身有什么魔力。后来我做了一个对照实验，把按钮改成绿色，转化率也涨了。所以CRO的核心不是“什么颜色最好”，而是“什么颜色最突出”。技能包里我把这个逻辑写进了诊断规则：按钮颜色必须和页面主色调形成对比，而不是指定某个具体颜色。
表单优化建议的输入是表单页面URL，输出是字段精简和布局调整建议。执行逻辑是：统计当前字段数，按“必要、重要、可选”三级分类，建议删除或后置“可选”字段。同时检查字段标签的清晰度、输入框的尺寸、错误提示的友好度。表单是转化漏斗里最容易漏的地方，每多一个字段，转化率大概降5-10%。我见过一个留资表单有12个字段，精简到5个之后，提交率翻了一倍。
A/B测试设计的输入是测试假设和当前页面，输出是测试方案，包括测试变量、样本量计算、测试周期、成功指标。这个技能的关键是样本量计算。很多人做A/B测试，跑了两天看数据有差异就下结论，结果全是噪音。技能包里我内置了一个样本量计算器，根据当前转化率和你想检测的最小提升幅度，算出需要多少样本。比如当前转化率5%，你想检测10%的相对提升（即从5%到5.5%），在95%置信度下需要约3万样本。如果你的日流量只有500，那这个测试需要跑60天，根本不现实。这时候技能会建议你换一个影响更大的变量来测。
3.3 Analytics技能组：让数据说人话
Analytics技能组我拆了三个技能：流量异常检测、转化漏斗分析、归因模型选择。这三个技能解决的是“数据怎么看”的问题。
流量异常检测的输入是分析工具的API密钥和时间范围，输出是异常点列表和可能原因。执行逻辑是：拉取每日流量数据，用移动平均和标准差识别偏离正常范围的日期，然后按渠道、页面、设备维度下钻，定位异常来源。比如某天自然搜索流量突然掉了30%，下钻发现是某个核心关键词排名掉了，再查发现是竞品发了更强的内容。这个技能的价值在于“快速定位”，而不是“解释原因”。原因分析还是需要人来做，但定位可以自动化。
转化漏斗分析的输入是漏斗各步骤的数据，输出是各步骤的转化率和流失率，以及流失最严重的环节。执行逻辑是：计算每一步的转化率，和行业基准对比，标记低于基准的步骤。然后对流失最严重的步骤做细分分析，比如按设备、按来源、按新老用户拆分，看流失是否集中在某个细分群体。我自己的站用这个技能跑了一遍，发现移动端的支付步骤流失率是桌面端的三倍，查了一下是支付页面在移动端加载太慢。优化之后，移动端整体转化率涨了18%。
归因模型选择的输入是各渠道的转化数据，输出是不同归因模型下的渠道贡献对比。执行逻辑是：用首次点击、末次点击、线性、时间衰减四种模型分别计算渠道贡献，然后对比差异。差异大的渠道说明它在不同阶段的作用不同。比如某个渠道在首次点击模型下贡献很高，但在末次点击模型下贡献很低，说明它主要负责“拉新”而不是“收割”。这个技能帮你理解渠道的真实价值，而不是简单地看“哪个渠道转化多”。
4. 实操落地：从零搭建一套可运行的营销技能包
4.1 环境准备与工具选型
搭建这套技能包，你需要三样东西：一个AI agent执行环境、一个代码编辑器、一个版本管理工具。我用的组合是Claude Code + VS Code + Git。Claude Code负责执行技能，VS Code用来编辑技能文件，Git用来做版本管理。
Claude Code的安装方式取决于你的操作系统。macOS和Linux用户可以通过官方提供的安装脚本一键安装，Windows用户建议在WSL环境下安装，体验更接近Linux。安装完成后，你需要在项目目录下初始化Claude Code，它会生成一个配置文件，你可以在里面设置模型、权限、工作目录等参数。
提示：Claude Code的权限设置建议从“每次操作都确认”开始，等你熟悉了它的行为模式再逐步放开。我一开始就设了全自动，结果它把我一个测试文件删了，还好有Git。
VS Code的配置主要是安装Claude Code的扩展，这样你可以在编辑器里直接和agent交互，不用来回切换终端。扩展安装后，在设置里把Claude Code的可执行文件路径配好，然后在项目根目录下打开终端，运行claude命令就能启动。
Git的配置没什么特别的，但建议给技能包单独建一个仓库，因为技能文件会频繁修改，版本管理很重要。每次修改技能定义后，commit一下，这样出问题了可以回滚。
4.2 技能文件的目录结构与命名规范
技能包的目录结构我设计成这样：
marketingskills/ ├── skills/ │ ├── seo/ │ │ ├── keyword-opportunity.md │ │ ├── page-audit.md │ │ ├── content-gap.md │ │ └── internal-link.md │ ├── cro/ │ │ ├── landing-page-diagnosis.md │ │ ├── form-optimization.md │ │ └── ab-test-design.md │ └── analytics/ │ ├── traffic-anomaly.md │ ├── funnel-analysis.md │ └── attribution-model.md ├── config/ │ ├── thresholds.yaml │ └── benchmarks.yaml ├── logs/ └── README.md每个技能文件是一个Markdown文件，文件名用英文小写加连字符。文件内容的结构是固定的：
# 技能名称 ## 适用场景 描述这个技能在什么情况下使用。 ## 输入参数 - 参数名: 类型，说明，是否必填 ## 执行逻辑 分步骤描述执行过程。 ## 输出格式 描述输出的结构。 ## 验证规则 列出验证输出是否合格的规则。config/目录下放的是阈值和基准数据。thresholds.yaml里定义各种判断阈值，比如标题标签长度范围、页面加载时间上限、表单字段数上限。benchmarks.yaml里放行业基准数据，比如各行业的平均转化率、平均跳出率。这些数据独立于技能文件，方便统一调整。
4.3 一个完整技能的编写示例：以“页面SEO审计”为例
我拿“页面SEO审计”这个技能来演示怎么写。首先是适用场景：
## 适用场景 当你需要检查一个页面的SEO健康状况，获取具体的修改建议时使用。 适用于内容页、产品页、栏目页的定期审计。然后是输入参数：
## 输入参数 - url: string, 必填，要审计的页面URL - target_keyword: string, 选填，该页面希望排名的核心关键词 - competitor_url: string, 选填，竞品对应页面的URL，用于对比分析执行逻辑分步骤写：
## 执行逻辑 1. 抓取页面HTML，提取标题标签、元描述、H1-H6、图片alt、内链、外链。 2. 检查标题标签：长度是否在50-60字符之间，核心关键词是否在前30字符内。 3. 检查元描述：长度是否在120-155字符之间，是否包含行动号召。 4. 检查H1：是否有且仅有一个H1，是否包含核心关键词。 5. 检查H2-H6：层级是否合理，是否覆盖相关子主题。 6. 检查图片alt：是否所有图片都有alt属性，alt是否描述准确。 7. 检查内链：入链数量是否大于3，出链是否指向相关页面。 8. 检查页面加载速度：用PageSpeed Insights API获取评分。 9. 检查移动端适配：视口设置、字体大小、点击区域。 10. 检查结构化数据：是否有Article、Product、FAQ等标记。输出格式：
## 输出格式 生成一份Markdown报告，包含： - 审计概览：通过项数、不通过项数、优先级分布 - 详细结果：每个审计项的当前值、标准值、是否通过、修改建议 - 优先级排序：按影响程度从高到低排列修改建议验证规则：
## 验证规则 - 所有审计项必须有明确的通过/不通过判断，不能是模糊的“建议优化”。 - 修改建议必须具体到可执行，比如“标题标签从72字符精简到58字符”，而不是“标题太长”。 - 优先级排序必须有依据，依据写在报告末尾。写完这个文件后，你在Claude Code里输入“审计这个页面 https://example.com/page”，agent会自动匹配到这个技能，读取输入参数，然后按执行逻辑跑一遍。跑完后输出报告，你可以根据报告逐项修改。
4.4 技能组合与工作流编排
单个技能有用，但组合起来威力更大。我常用的一个工作流是“关键词机会分析 → 内容差距分析 → 页面SEO审计 → 内链结构优化”。这个工作流覆盖了从选题到发布的完整链路。
编排方式是在项目根目录下建一个workflows/目录，每个工作流一个YAML文件。比如content-pipeline.yaml：
name: content-pipeline description: 从关键词研究到内容发布的全流程 steps: - skill: seo/keyword-opportunity input: seed_keyword: "独立站SEO" competitor_domain: "competitor.com" output: keyword_list - skill: seo/content-gap input: my_domain: "mysite.com" competitor_domain: "competitor.com" keyword_list: "{{keyword_list}}" output: content_topics - skill: seo/page-audit input: url: "{{new_page_url}}" target_keyword: "{{selected_keyword}}" output: audit_report - skill: seo/internal-link input: sitemap_url: "mysite.com/sitemap.xml" new_page_url: "{{new_page_url}}" output: link_suggestions在Claude Code里运行claude run workflow content-pipeline，agent会按顺序执行每个技能，把上一步的输出作为下一步的输入。你可以在中间任何一步暂停，检查输出，调整参数，然后继续。
注意：工作流编排不要贪多。我一开始把七八个技能串在一起，结果中间某一步出错，整个流程就断了，排查起来很麻烦。建议从两三个技能的小工作流开始，跑顺了再往上加。
5. 常见问题与排查技巧实录
5.1 技能匹配失败怎么办
最常见的问题是agent找不到对应的技能。原因通常是技能文件的命名或描述和你的输入不匹配。比如你输入“帮我看看这个页面的SEO”，但技能文件里写的是“页面SEO审计”，agent可能匹配不上。
解决办法有两个。第一，在技能文件的“适用场景”里多写几个同义词和口语化表达。比如“页面SEO审计”的适用场景里加上“检查页面SEO”“看看页面有没有SEO问题”“页面SEO诊断”。第二，在Claude Code的配置里设置一个技能索引文件，把所有技能的名称、描述、关键词列出来，agent先查索引再匹配。
我自己的做法是两者结合。索引文件放在skills/index.md，每次新增技能后更新索引。同时在技能文件的适用场景里尽量覆盖多种表达方式。这样匹配成功率能到90%以上。
5.2 输出质量不稳定的排查思路
有时候agent输出的报告质量很高，有时候又很敷衍。排查思路是看三个地方：输入参数是否完整、执行逻辑是否被完整执行、验证规则是否被触发。
输入参数不完整是最常见的原因。比如“页面SEO审计”需要URL，但你只说了“审计一下我的站”，agent可能随便抓一个页面就开始跑。解决办法是在技能定义里把必填参数标清楚，agent在参数缺失时应该主动询问，而不是自己猜。
执行逻辑被跳过通常是因为agent“偷懒”。比如执行逻辑有10步，它只跑了5步就出报告了。解决办法是在验证规则里加一条“所有执行步骤必须有对应的输出记录”，agent在自检时会发现缺失并补跑。
验证规则没触发是因为验证规则写得太模糊。比如“修改建议必须具体”，什么叫具体？agent不知道。改成“修改建议必须包含当前值、目标值、修改动作”就明确多了。
5.3 数据准确性的验证方法
AI agent跑出来的数据，你不能全信。我的做法是抽样验证。比如关键词机会分析输出了50个关键词，我随机抽5个，手动查一下搜索量和竞争度，看和agent给的数据差多少。如果误差在可接受范围内（比如搜索量误差20%以内），就继续用。如果误差很大，就要检查数据源和计算逻辑。
另一个方法是交叉验证。同一个数据，用两个不同的技能或工具跑一遍，看结果是否一致。比如流量异常检测，我用agent跑一遍，再手动在分析工具里看一眼，如果agent标记的异常点和我在工具里看到的一致，说明逻辑没问题。
提示：数据准确性验证建议在技能上线初期做得频繁一些，等稳定了再降低频率。我一般是新技能跑前10次都抽样验证，之后每20次抽一次。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| agent找不到技能 | 技能描述不匹配 | 检查输入和技能适用场景的关键词重合度 | 补充同义词，更新索引文件 |
| 输出报告很敷衍 | 执行逻辑被跳过 | 检查日志里各步骤是否有输出 | 在验证规则里加步骤完整性检查 |
| 数据误差大 | 数据源或计算逻辑有问题 | 抽样手动验证，交叉验证 | 更换数据源，修正计算逻辑 |
| 工作流中断 | 中间步骤出错 | 查看中断步骤的日志和错误信息 | 单独跑该技能，修复后重跑工作流 |
| 技能执行太慢 | 步骤太多或API调用频繁 | 看日志里各步骤耗时 | 合并步骤，加缓存，减少API调用 |
| 输出格式不对 | 输出格式定义不清晰 | 对比输出和格式定义的差异 | 细化输出格式定义，加示例 |
6. 技能包的扩展与迭代思路
6.1 从三个领域扩展到更多营销场景
SEO、CRO、Analytics是起点，不是终点。这套技能包的架构是开放的，你可以按同样的模式扩展其他营销领域。比如内容营销可以加“选题策划”“内容日历生成”“内容分发策略”三个技能。邮件营销可以加“邮件序列设计”“主题行优化”“发送时间优化”。社交媒体可以加“内容排期”“话题挖掘”“互动分析”。
扩展的关键是保持技能定义的标准化。每个新技能都必须有适用场景、输入参数、执行逻辑、输出格式、验证规则这五个部分。不能因为领域不同就放松标准。我见过有人加了一个“社交媒体分析”技能，执行逻辑只写了“分析社交媒体数据”，这种技能agent根本没法执行。
6.2 技能版本管理与迭代节奏
技能文件是要迭代的。我的迭代节奏是：每周review一次技能执行日志，找出执行失败率高、输出质量差的技能，优先优化。每月做一次大版本更新，把积累的小修改合并，更新版本号。
版本管理用Git的tag功能。比如v1.0.0是初始版本，v1.1.0加了新技能，v1.1.1修了bug。每次tag对应一个稳定的技能包版本，方便回滚和对比。
迭代的时候要注意向后兼容。比如你修改了“关键词机会分析”的输出格式，从列表改成了表格，那依赖这个输出的“内容差距分析”技能也要同步修改。我一般会在修改一个技能后，跑一遍依赖它的工作流，确保没有断链。
6.3 与团队协作的注意事项
如果你不是一个人用这套技能包，而是团队共用，有几个地方要注意。第一，技能文件的修改要经过review，不能谁想改就改。第二，阈值和基准数据要统一维护，不能每个人用自己的。第三，日志要集中存储，方便排查问题和做效果分析。
我们团队的做法是：技能文件放在共享仓库，修改走Pull Request，至少一个人review后才能合并。阈值和基准数据放在config/目录，由我来统一维护，其他人只能读不能写。日志按日期和技能名归档，每周做一次汇总分析。
注意：团队协作时，技能命名要加前缀区分。比如
seo-keyword-opportunity、cro-landing-page-diagnosis。这样在日志和报告里一眼就能看出是哪个领域的技能。
7. 我在这套技能包上踩过的坑
第一个坑是“过度自动化”。我一开始想把所有判断都交给agent，结果发现有些判断需要人的经验，agent做不了。比如“这个关键词值不值得做”，agent只能算机会分，但最终决策还要考虑你的业务阶段、资源投入、竞争格局。后来我把技能定位成“辅助判断”而不是“替代判断”，agent给建议，人做决策。
第二个坑是“技能粒度太细”。我一开始把“检查标题标签”单独做了一个技能，结果技能文件太多，管理成本很高。后来合并成“页面SEO审计”，一个技能覆盖多个检查项。粒度太细的另一个问题是组合困难，你没法把十个细粒度技能串成一个流畅的工作流。
第三个坑是“忽视数据更新”。营销数据变化很快，行业基准、搜索量、竞争度都在变。我有一段时间没更新benchmarks.yaml，结果agent给的转化率基准还是去年的，和实际情况差了很多。后来我设了一个提醒，每季度更新一次基准数据。
第四个坑是“日志没用好”。一开始我没怎么看日志，后来发现日志里有很多有价值的信息，比如哪些技能执行失败率高、哪些步骤耗时最长、哪些输出被人工修改最多。这些信息是优化技能包的依据。现在我会定期分析日志，把高频问题优先解决。
这套技能包我用了大半年，从最初的三个技能扩展到现在的十几个，工作流从单步扩展到多步。最大的体会是：AI agent在营销领域的价值不在于“替代人”，而在于“放大人的判断力”。你把判断框架固化下来，agent帮你执行和验证，你专注于框架的迭代和例外情况的处理。这个分工模式，我觉得是现阶段AI和营销结合最务实的方式。
