Claude Code 营销技能实战：SEO 审计与 CRO 实验自动化落地

1. 从"marketingskills"这个标题说起：它到底想解决什么问题

第一次看到"marketingskills"这个词，我脑子里冒出来的不是某个具体工具，而是一类很实际的需求：把营销这件事拆成一项项可复用的技能，然后让 AI 去执行。过去我们做 SEO、做转化率优化（CRO）、做内容分发，靠的是人肉查资料、手动改页面、凭经验拍脑袋。现在有了 Claude Code 这类能直接读写文件、执行终端命令的 AI agent，营销工作流里那些重复、琐碎、需要大量上下文判断的环节，第一次有了被"技能化"的可能。

所谓 marketingskills，我的理解是一套面向营销场景的 AI 技能集合——它可能是一组提示词模板、一套脚本工具、一批结构化数据生成规则，也可能是把 SEO 审计、CRO 实验设计、FAQ 结构化数据生成这些动作封装成 Claude Code 可以调用的"技能包"。它的核心价值在于：让一个懂营销但不懂编程的人，也能通过自然语言指挥 AI 完成原本需要工程师配合才能落地的技术营销任务。

这篇文章适合三类人看。第一类是独立站运营者，尤其是做谷歌 SEO 的，你们最清楚 FAQPage 结构化数据、页面速度、内链结构这些东西对排名的影响，但往往卡在"知道要改却不会改"。第二类是营销团队里负责增长的人，你们需要一套可复制的流程，而不是每次活动都从零开始。第三类是对 Claude Code 感兴趣、想把它用到实际业务里的技术爱好者，你们关心的是怎么配置、怎么调用、怎么让它稳定干活。

我会围绕 marketingskills 这个核心，把 Claude Code 的安装配置、营销技能的设计思路、SEO 和 CRO 场景的具体落地、以及实操中踩过的坑，一层层拆开讲。不堆概念，只讲能直接抄作业的东西。

2. Claude Code 作为营销技能载体的能力边界

2.1 它和普通聊天式 AI 的本质区别

很多人第一次接触 Claude Code，会把它当成"另一个 ChatGPT"。这个认知偏差会导致你完全用错方向。普通聊天式 AI 的工作模式是：你问，它答，答案停留在对话框里，你需要手动复制粘贴到目标位置。而 Claude Code 的核心能力是直接操作你的工作环境——它可以读取你本地的文件、修改代码、执行终端命令、调用外部 API，然后把结果写回文件系统。

这个区别在营销场景里意味着什么？举个例子。你要给一个独立站的 50 个产品页面批量添加 FAQPage 结构化数据。用聊天式 AI，你得把每个页面的内容贴进去，让它生成 JSON-LD，再手动贴回每个页面。50 个页面就是 50 次复制粘贴，中间还容易出错。用 Claude Code，你可以写一个技能脚本，让它遍历指定目录下的所有 HTML 文件，提取页面内容，生成对应的 FAQ 结构化数据，直接插入到每个文件的<head>区域。整个过程你只需要下达一次指令。

提示：Claude Code 的能力边界取决于你给它的权限。默认情况下它不会随意修改文件，需要你明确授权。这个设计是为了安全，但也意味着你需要理解它的权限模型，否则会觉得"它怎么什么都不干"。

2.2 营销技能化的三个层次

我把 marketingskills 的落地分成三个层次，从浅到深分别是：

第一层：提示词技能化。把常用的营销指令固化成模板。比如"分析这个页面的 SEO 问题并给出修改建议"、"为这个产品生成 5 个 A/B 测试的标题变体"、"检查这个页面的结构化数据是否符合规范"。这一层不需要写代码，只需要把提示词整理好，让 Claude Code 按固定格式输出。

第二层：脚本技能化。把需要批量处理、需要读写文件、需要调用外部工具的任务写成脚本。比如批量生成 FAQPage 结构化数据、批量检查页面 meta 标签、批量生成内链建议。这一层需要你懂一点 Shell 或 Python，但不需要很深。

第三层：工作流技能化。把多个技能串联成完整的工作流。比如"抓取竞品页面 → 分析其 SEO 策略 → 生成优化建议 → 自动修改本地页面 → 输出变更报告"。这一层需要你对整个营销流程有清晰的理解，并且能把它拆解成 AI 可执行的步骤。

大多数独立站运营者从第一层开始就够了，等技术熟练了再往第二层、第三层走。不要一上来就想搞全自动工作流，那样很容易因为某个环节出错而整个流程崩溃。

2.3 为什么营销场景特别适合 Claude Code

营销工作的特点是什么？重复性高、上下文依赖强、需要频繁读写文件、需要和外部工具打交道。这四个特点恰好都是 Claude Code 的强项。

重复性高意味着你可以把一次成功的操作固化成技能，之后反复调用。上下文依赖强意味着你需要 AI 理解你的业务背景，而 Claude Code 可以通过读取你的项目文件来获取这些上下文。需要读写文件意味着你不能只靠聊天窗口，必须有工具能直接操作文件系统。需要和外部工具打交道意味着你需要一个能执行命令的载体，而不是只能生成文本的模型。

我实测下来，用 Claude Code 处理 SEO 审计任务，效率比手动操作提升至少 5 倍。一个包含 30 个页面的站点，手动检查 meta 标签、标题、结构化数据、内链结构，至少需要半天。用 Claude Code 写好的技能脚本，20 分钟跑完，还能自动生成一份带优先级的修改建议报告。

3. 把 Claude Code 跑起来：环境准备与模型接入的实操细节

3.1 安装方式的选择与常见卡点

Claude Code 的安装方式主要有两种：通过 npm 全局安装，或者下载桌面版。我建议优先用 npm 方式，因为它的更新更及时，而且和终端工作流的配合更顺畅。

npm install -g @anthropic-ai/claude-code

安装完成后，在终端输入claude就能启动。第一次启动会引导你完成账号注册和授权。这里有个细节需要注意：如果你所在的环境无法直接访问官方服务，可能会遇到提示说当前地区不支持。这种情况下你需要考虑使用第三方 API 接入方案，后面会详细讲。

Windows 用户要特别注意：Claude Code 对 64 位 Windows 的支持是有的，但如果你用的是 32 位系统或者某些精简版 Windows，可能会遇到兼容性问题。我建议在 WSL2 环境下运行，稳定性和兼容性都好很多。Mac 和 Ubuntu 用户相对省心，直接按官方文档走就行。

注意：安装过程中如果遇到权限报错，不要用sudo强行安装。正确的做法是配置 npm 的全局目录权限，或者使用 nvm 管理 Node.js 版本。用sudo安装会导致后续更新和卸载都很麻烦。

3.2 接入第三方模型：以 LM Studio 本地模型为例

Claude Code 默认使用 Anthropic 的官方模型，但很多人出于成本或隐私考虑，想接入本地模型或其他第三方模型。这里以 LM Studio 为例讲一下接入思路。

LM Studio 可以在本地运行开源模型，并提供一个兼容 OpenAI API 格式的接口。Claude Code 支持通过环境变量配置自定义的 API 端点。你需要做的是：

1. 在 LM Studio 中加载一个模型，启动本地服务器，记下端口号（默认是 1234）。
2. 设置环境变量，把 Claude Code 的 API 地址指向本地服务。

export ANTHROPIC_BASE_URL="http://localhost:1234/v1" export ANTHROPIC_API_KEY="lm-studio"

3. 启动 Claude Code，它会使用你配置的本地模型。

这里有个坑要提醒：本地模型的上下文窗口通常比官方模型小，处理大文件时容易截断。我建议用本地模型处理单个文件的简单任务，复杂任务还是用官方模型或者上下文窗口更大的第三方模型。

3.3 VS Code 插件的配置逻辑

Claude Code 有 VS Code 插件，安装后在侧边栏会出现一个面板。很多人装了插件却不知道怎么用，其实它的核心逻辑是：插件提供了一个图形界面，底层调用的还是你本地安装的 Claude Code CLI。所以你必须先确保 CLI 能正常工作，插件才能正常工作。

配置步骤：

1. 确保claude命令在终端中可以正常运行。
2. 在 VS Code 中安装 Claude Code 插件。
3. 在插件设置中指定 CLI 的路径（通常会自动检测）。
4. 打开一个项目文件夹，插件会自动读取项目上下文。

插件的优势在于你可以直接在编辑器里看到 AI 的修改建议，并且可以一键接受或拒绝。对于需要频繁修改文件的营销任务来说，这个交互方式比纯终端要友好得多。

3.4 账号注册与否的实际差异

Claude Code 可以不注册账号使用吗？可以，但功能受限。不注册的情况下，你只能使用有限的免费额度，而且无法使用一些高级功能。注册账号后，你可以获得更稳定的服务、更大的使用额度，以及完整的技能调用能力。

如果你是通过第三方 API 接入的，那么账号注册与否影响不大，因为计费和授权都由第三方服务商处理。但要注意，第三方 API 的稳定性和数据安全性需要你自己评估。我个人的做法是：日常开发用官方账号，敏感数据处理用本地模型，批量任务用第三方 API 控制成本。

4. 营销技能包的设计：从 SEO 审计到 CRO 实验

4.1 SEO 审计技能的核心检查项

一个完整的 SEO 审计技能应该覆盖哪些检查项？我根据实际使用经验，整理了一份清单：

把这个清单写成 Claude Code 技能，你可以让它遍历指定目录下的所有 HTML 文件，逐项检查并输出报告。报告格式建议用 Markdown 表格，方便直接查看和分发。

# 伪代码示例：SEO 审计技能的核心逻辑 import os from bs4 import BeautifulSoup def audit_page(file_path): with open(file_path, 'r', encoding='utf-8') as f: soup = BeautifulSoup(f.read(), 'html.parser') issues = [] # 检查标题标签 title = soup.find('title') if not title: issues.append(('高', '缺少标题标签')) elif len(title.text) > 60: issues.append(('中', f'标题过长：{len(title.text)} 字符')) # 检查 Meta 描述 meta_desc = soup.find('meta', attrs={'name': 'description'}) if not meta_desc: issues.append(('高', '缺少 Meta 描述')) # 检查 H1 h1_tags = soup.find_all('h1') if len(h1_tags) == 0: issues.append(('高', '缺少 H1 标签')) elif len(h1_tags) > 1: issues.append(('中', f'存在多个 H1 标签：{len(h1_tags)} 个')) return issues

这个脚本的逻辑很简单，但实际使用时你需要根据自己站点的结构做调整。比如有些站点用 JavaScript 渲染内容，BeautifulSoup 就抓不到，需要换成 Playwright 或 Selenium。

4.2 FAQPage 结构化数据的生成规则

FAQPage 结构化数据是谷歌 SEO 里一个很实用的东西。它能让你的页面在搜索结果中展示常见问题解答，增加点击率。但很多人不知道怎么正确生成它，要么格式错误，要么内容不符合规范。

FAQPage 的 JSON-LD 格式长这样：

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "问题内容", "acceptedAnswer": { "@type": "Answer", "text": "答案内容" } } ] }

用 Claude Code 生成 FAQPage 结构化数据的技能，核心逻辑是：读取页面内容 → 提取或生成常见问题 → 按格式生成 JSON-LD → 插入到页面的<head>区域。

这里有几个实操要点：

问题要真实。不要为了结构化数据而编造问题。谷歌的算法能识别出哪些 FAQ 是真实有用的，哪些是凑数的。我建议从客服记录、搜索查询报告、用户评论中提取真实问题。

答案要简洁。每个答案控制在 50-100 字，直接回答问题，不要绕弯子。如果需要详细解释，可以在答案中加一个指向页面详细内容的链接。

不要滥用。不是每个页面都需要 FAQPage。产品页、服务页、教程页适合加，首页和关于页通常不需要。

提示：生成 FAQPage 后，一定要用谷歌的富媒体结果测试工具验证一下。格式错误的结构化数据不仅不会带来好处，还可能被判定为垃圾内容。

4.3 CRO 实验设计的技能化思路

CRO（转化率优化）的核心是实验。但很多小团队做 CRO 的问题是：不知道测试什么、不知道怎么设计实验、不知道怎么分析结果。Claude Code 可以在这三个环节提供帮助。

测试想法生成。你可以让 Claude Code 读取你的落地页内容，然后基于常见的 CRO 原则（如社会证明、紧迫感、清晰的价值主张、减少摩擦）生成一批测试想法。提示词可以这样写：

读取 landing-page.html 的内容，基于以下 CRO 原则生成 10 个 A/B 测试想法： 1. 社会证明（客户评价、数据统计、信任徽章） 2. 紧迫感（限时优惠、库存提示） 3. 价值主张清晰度（标题、副标题、CTA 文案） 4. 减少摩擦（表单字段、步骤数量） 每个想法包括：测试假设、变体描述、预期影响、实施难度。

实验设计。生成想法后，你需要设计具体的实验方案。包括：样本量计算、测试时长、成功指标、分流比例。Claude Code 可以根据你的当前流量数据帮你算出合理的样本量。

结果分析。实验跑完后，把数据丢给 Claude Code，让它帮你分析统计显著性、计算提升幅度、给出下一步建议。

我实测下来，这套流程能把 CRO 实验的周期从"想到哪测到哪"变成"有系统有节奏"。一个落地页一个月跑 3-4 个实验，三个月下来转化率提升 20%-30% 是很常见的。

4.4 内容分发的批量处理技能

做独立站的人都知道，内容分发是个体力活。一篇文章写完后，要改写成适合不同平台的版本，要生成社交媒体文案，要配图，要加标签。这些工作用 Claude Code 可以批量处理。

一个实用的技能是：读取一篇原始文章 → 生成 Twitter/X 线程版本 → 生成 LinkedIn 帖子版本 → 生成邮件通讯版本 → 生成 5 个标题变体 → 输出到一个 Markdown 文件。

这个技能的关键在于提示词的设计。你需要明确告诉 Claude Code 每个平台的风格特点：Twitter/X 要短平快、有钩子；LinkedIn 要专业、有故事性；邮件通讯要亲切、有个人色彩。把这些要求写进技能模板，每次调用时只需要传入文章内容就行。

5. 实操中踩过的坑与排查链路

5.1 文件编码问题导致的中文乱码

这是我踩的第一个坑。用 Claude Code 批量处理中文页面的 HTML 文件时，生成的 JSON-LD 里中文变成了乱码。排查过程是这样的：

第一步，检查原始文件编码。用file -i命令查看，发现文件是 GBK 编码，而 Claude Code 默认按 UTF-8 读取。

第二步，检查输出文件编码。生成的 JSON-LD 确实是 UTF-8，但内容已经乱了。

第三步，定位问题。Claude Code 读取文件时没有自动检测编码，直接按 UTF-8 解码 GBK 内容，导致乱码。

解决方案：在技能脚本中显式指定编码，或者在处理前先把文件转成 UTF-8。

# 批量转换文件编码 find ./pages -name "*.html" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \;

注意：转换编码前一定要备份原始文件。我有一次没备份，转换失败后原始文件也被覆盖了，只能从 Git 历史里恢复。

5.2 上下文窗口超限导致的任务中断

处理大文件时，Claude Code 会因为上下文窗口超限而中断任务。我遇到过一次：一个包含 200 多个产品页面的目录，让它一次性处理，跑到第 80 个页面时中断了。

排查过程：查看日志发现是 token 数量超过了模型限制。Claude Code 在处理每个文件时都会把文件内容加载到上下文中，文件多了就会累积超限。

解决方案：分批处理。把大任务拆成小批次，每批处理 20-30 个文件，处理完一批后清空上下文再处理下一批。

# 分批处理的思路 for batch in $(seq 1 10); do start=$((($batch - 1) * 20 + 1)) end=$(($batch * 20)) # 处理第 start 到 end 个文件 claude --task "处理第 $start 到 $end 个文件的 SEO 审计" done

这个坑的教训是：不要贪心，不要想着一次搞定所有文件。分批处理虽然麻烦一点，但稳定性高得多。

5.3 权限配置不当导致的静默失败

Claude Code 在执行文件写入操作时，如果权限不足，它不会报错，而是静默失败。我遇到过好几次：技能脚本跑完了，报告显示"已修改 50 个文件"，但实际检查发现一个都没改。

排查过程：手动执行一次写入操作，发现是文件权限问题。当前用户对目标目录没有写权限。

解决方案：检查并修改目录权限，或者在技能脚本中加入权限检查逻辑。

# 检查目录写权限 if [ ! -w "./pages" ]; then echo "错误：当前用户对 pages 目录没有写权限" exit 1 fi

这个坑的教训是：任何自动化操作都要有验证环节。不要相信"执行成功"的提示，要实际检查结果。

5.4 第三方 API 的速率限制与重试策略

用第三方 API 接入时，速率限制是个常见问题。我用的某个第三方服务，每分钟只允许 20 次请求。批量处理时很容易触发限制，导致任务中断。

解决方案：在技能脚本中加入重试逻辑和速率控制。

import time import requests def call_api_with_retry(prompt, max_retries=3): for attempt in range(max_retries): try: response = requests.post(API_URL, json={"prompt": prompt}) if response.status_code == 429: wait_time = 2 ** attempt * 10 print(f"触发速率限制，等待 {wait_time} 秒后重试") time.sleep(wait_time) continue return response.json() except Exception as e: print(f"请求失败：{e}") time.sleep(5) raise Exception("达到最大重试次数")

这个策略的核心是指数退避：第一次等待 10 秒，第二次 20 秒，第三次 40 秒。这样既能避免频繁触发限制，又不会无限等待。

5.5 模型幻觉导致的结构化数据错误

Claude Code 在生成结构化数据时，偶尔会产生幻觉。比如生成一个不存在的 schema 属性，或者把日期格式写错。这种错误很隐蔽，因为生成的 JSON 看起来是合法的，但不符合 schema.org 的规范。

排查过程：用谷歌的富媒体结果测试工具验证，发现报错说某个属性不被识别。

解决方案：在技能脚本中加入验证环节。生成 JSON-LD 后，用 schema.org 的验证器检查一遍，或者写一个简单的校验脚本。

import json def validate_faq_schema(json_ld): data = json.loads(json_ld) assert data.get("@context") == "https://schema.org" assert data.get("@type") == "FAQPage" for item in data.get("mainEntity", []): assert item.get("@type") == "Question" assert "name" in item assert "acceptedAnswer" in item assert item["acceptedAnswer"].get("@type") == "Answer" assert "text" in item["acceptedAnswer"] return True

这个校验脚本很简单，但能拦住大部分低级错误。我建议把它作为技能流程的必经环节。

6. 让营销技能真正落地的几个关键习惯

6.1 从最小可用技能开始，不要追求大而全

我见过太多人一上来就想搞一个"全自动营销系统"，结果卡在某个技术细节上，最后什么都没做成。正确的做法是：先做一个最小可用的技能，跑通一个完整流程，然后再逐步扩展。

比如，你的第一个技能可以只是"检查单个页面的标题标签和 Meta 描述"。这个技能很简单，但跑通之后你就理解了 Claude Code 的基本工作方式。然后你可以扩展成"检查整个目录的页面"，再扩展成"生成修改建议"，再扩展成"自动修改文件"。每一步都是在验证过的基础上往前走，风险可控。

6.2 技能文档化，让团队其他人也能用

如果你是在团队里推广 marketingskills，文档化是必须的。每个技能都应该有一份说明文档，包括：技能用途、输入要求、输出格式、使用示例、常见问题。

我习惯在技能目录下放一个 README.md，用统一的模板：

# 技能名称：SEO 页面审计 ## 用途 检查指定目录下所有 HTML 页面的 SEO 基础项。 ## 输入 - 目标目录路径 - 可选的检查项过滤（如只检查标题和 Meta） ## 输出 - Markdown 格式的审计报告 - 按优先级排序的问题列表 ## 使用示例 claude --skill seo-audit --dir ./pages --checks title,meta ## 常见问题 - 如果页面是 JS 渲染的，需要先配置 Playwright - 如果文件编码不是 UTF-8，需要先转换编码

这份文档不需要写得很长，但要让一个没接触过这个技能的人能在 5 分钟内上手。

6.3 建立反馈循环，持续优化技能

技能不是写完就完了，需要根据实际使用情况持续优化。我的做法是：每次使用技能后，记录三个东西——哪些地方卡住了、哪些输出不符合预期、哪些步骤可以自动化。

比如，我发现 SEO 审计技能生成的报告里，问题描述太技术化，运营同事看不懂。于是我修改了提示词，要求用"人话"描述问题，并给出具体的修改建议。改完之后，运营同事可以直接拿着报告去改页面，不需要再问我。

这个反馈循环的关键是：把每次使用都当成一次测试，而不是"用完就完了"。你用得越多，技能就越完善。

6.4 安全边界：哪些事不要让 AI 自动做

虽然 Claude Code 能自动修改文件，但有些事我建议不要让它全自动做。比如：

• 直接修改线上文件。让 AI 在本地或测试环境修改，人工审核后再部署到线上。
• 删除文件。删除操作不可逆，让 AI 生成删除列表，人工确认后再执行。
• 涉及用户数据的操作。处理用户数据时要格外小心，确保符合隐私规范。
• 涉及支付的页面修改。支付流程的任何改动都可能影响收入，必须人工审核。

我的原则是：AI 负责生成和修改，人负责审核和发布。这个分工既能提高效率，又能控制风险。

6.5 成本控制：什么时候用官方模型，什么时候用本地模型

Claude Code 调用官方模型是按 token 计费的。批量处理大量文件时，成本会快速上升。我的经验是：

• 简单任务用本地模型。比如格式转换、简单的文本提取、基础检查。这些任务对模型能力要求不高，本地模型完全够用。
• 复杂任务用官方模型。比如需要理解上下文、需要生成创意内容、需要做判断的任务。这些任务本地模型容易出错，用官方模型更可靠。
• 批量任务用第三方 API。如果第三方 API 的价格比官方低，而且稳定性可以接受，批量任务可以用第三方。但要确保数据安全性。

我粗略算过一笔账：一个包含 100 个页面的 SEO 审计任务，用官方模型大约花费 2-3 美元，用本地模型几乎零成本但需要多花 30% 的时间调试。如果你的时间成本高于模型成本，用官方模型更划算；反之则用本地模型。

7. 一个完整的 marketingskills 工作流示例

7.1 场景设定：独立站新品上线的 SEO 准备

假设你运营一个独立站，要上线一款新产品。上线前需要做一系列 SEO 准备工作：生成产品页的 meta 标签、生成 FAQPage 结构化数据、检查内链结构、生成社交媒体分享文案。

传统做法是：运营写内容，SEO 专员检查优化，工程师改代码，设计师做图。整个流程走下来至少两三天。用 marketingskills 工作流，可以压缩到半天。

7.2 工作流拆解与技能调用

第一步：内容准备。运营提供产品描述、卖点、常见问题。这些内容放在一个 Markdown 文件里。

第二步：Meta 标签生成。调用技能，读取产品描述，生成标题标签和 Meta 描述。

claude --skill generate-meta --input product.md --output meta.json

第三步：FAQPage 生成。调用技能，读取常见问题，生成 JSON-LD 结构化数据。

claude --skill generate-faq --input product.md --output faq-schema.json

第四步：内链建议。调用技能，分析现有页面内容，生成内链建议。

claude --skill suggest-internal-links --dir ./pages --target product.html

第五步：社交文案生成。调用技能，生成 Twitter/X、LinkedIn、邮件的分享文案。

claude --skill generate-social --input product.md --platforms twitter,linkedin,email

第六步：整合与审核。把所有输出整合到一个报告里，人工审核后部署。

这个工作流的关键在于：每个技能只做一件事，技能之间通过文件传递数据。这样既灵活又可控，任何一个环节出问题都不会影响其他环节。

7.3 工作流的监控与异常处理

工作流跑起来后，你需要监控每个环节的执行情况。我的做法是：每个技能执行后都输出一个状态文件，记录执行时间、处理文件数、遇到的问题。

{ "skill": "generate-meta", "status": "success", "timestamp": "2025-01-15T10:30:00Z", "files_processed": 1, "issues": [] }

如果某个环节失败，状态文件会记录错误信息。你可以根据错误信息决定是重试、跳过还是人工介入。

提示：工作流跑通后，建议把它写成一个 Shell 脚本或 Makefile，这样每次新品上线只需要改一下输入文件，然后执行一条命令就行。

8. 关于 marketingskills 的一些个人体会

我用 Claude Code 做营销自动化有一段时间了，最大的体会是：AI 不会取代营销人，但会用 AI 的营销人会取代不会用的。这句话听起来像鸡汤，但实际感受确实如此。

以前我做 SEO 审计，一天只能处理一个站点，因为大部分时间花在重复的检查工作上。现在我用技能脚本，一天能处理五六个站点，省下来的时间用来分析数据、制定策略、和团队沟通。工作的价值密度提高了，而不是被 AI 替代了。

另一个体会是：技能的质量取决于你对业务的理解深度。如果你自己都不清楚 SEO 审计应该检查什么，那你写出来的技能也是糊弄事的。AI 是放大器，它放大的是你的专业能力，而不是替代你的专业能力。

还有一个很实际的建议：不要追求完美，先跑起来。我见过太多人花大量时间设计"完美"的技能架构，结果一直没落地。我的做法是：先写一个能用的版本，跑起来，发现问题再改。迭代的速度比初始的完美度重要得多。

最后分享一个小技巧：把常用的提示词存成文件，用的时候直接引用。比如我把"SEO 审计"的提示词存在prompts/seo-audit.md里，每次调用技能时用--prompt-file参数引用它。这样修改提示词只需要改一个文件，所有用到这个提示词的技能都会同步更新。这个习惯帮我省了很多重复劳动，也让技能维护变得简单。