企业官网建设流程全解析

1. 从“marketingskills”说起：一个被低估的增长工具箱

第一次看到marketingskills这个词，很多人会下意识以为它又是一个“营销话术合集”或者“增长黑客清单”。但如果你最近在折腾 Claude Code、AI agents，或者正在给自己的独立站做 SEO、CRO 和数据分析，就会意识到这个词背后其实指向一个非常具体的东西：一套可以被 AI agent 直接调用的营销技能模块集合。

说白了，marketingskills不是一门课程，也不是一个 SaaS 产品，它更像是一组“技能包”——把 SEO 审计、转化率优化、数据指标解读、内容策略这些原本散落在各种工具和文档里的能力，封装成结构化的、可被 AI 代理理解和执行的模块。你给它一个页面 URL，它能按预设逻辑跑一遍 SEO 检查；你给它一段落地页文案，它能按 CRO 框架给出修改建议；你给它一份 GA4 或 Plausible 的导出数据，它能帮你定位异常波动。

这套东西解决的核心问题是：营销执行中的重复性判断太多，而 AI agent 恰好擅长按规则做重复判断。传统做法是打开 Screaming Frog 爬一遍、导出 CSV、人工筛标题缺失和内链问题，再打开 Hotjar 看录屏，最后在 Notion 里写整改清单。整个链路割裂、耗时、容易漏项。marketingskills的思路是把这些检查项变成 agent 可调用的“技能”，让 Claude Code 这类工具在终端里直接跑完，输出结构化结果。

适合谁来参考？三类人最受益：一是独立开发者或小团队运营，没有专职 SEO 和 CRO 人员，需要一套“够用且能自动化”的方案；二是增长方向的产品经理或运营，想理解 AI agent 在营销场景里到底能落地到什么程度；三是已经在用 Claude Code 做开发、想把它扩展到营销工作流的工程师。哪怕你之前没接触过 AI agent，只要你会用命令行、能看懂基本的 HTML 和表格数据，这篇内容里的步骤都能直接抄。

我自己的背景是做了七八年增长和 SEO，从早期手工做外链、调 Title 标签，到后来用 Python 脚本批量处理站点审计，再到最近一年把大量重复工作交给 Claude Code 和自定义 agent。marketingskills这个方向我踩过不少坑，也攒了一些实测有效的配置和排查经验，下面按实际落地顺序拆开讲。

2. 整体设计与思路拆解：为什么是“技能模块”而不是“大而全工具”

2.1 核心思路：把营销判断拆成 agent 可执行的原子技能

传统营销工具的设计逻辑是“功能聚合”——一个后台里塞进关键词研究、排名追踪、外链分析、页面审计、竞品监控。好处是数据集中，坏处是每个功能都浅，而且你没法按自己的业务逻辑重新组合。marketingskills走的是相反路线：把每个判断拆成足够小的技能单元，让 agent 按需调用、自由编排。

举个例子，一个完整的“落地页转化诊断”在传统工具里可能是一个大按钮，点下去出一份几十页报告。但在技能模块思路下，它被拆成：check_title_length、check_meta_description、check_h1_uniqueness、check_cta_visibility、check_form_field_count、check_page_speed_signals、check_trust_badges等十几个原子技能。每个技能只做一件事，输入输出都定义清楚。Agent 拿到任务后，按顺序或并行调用这些技能，最后汇总。

这种设计的好处非常实际。第一，可调试：某个检查项误报了，你直接改那个技能，不影响其他。第二，可组合：今天做 SEO 审计就调 SEO 相关技能，明天做 CRO 就调转化相关技能，不用换工具。第三，可解释：每个技能的输出都带判断依据，不像黑盒工具只给一个分数。第四，可扩展：你自己业务有特殊规则，比如“所有 CTA 按钮必须包含价格锚点”，写成一个新技能加进去就行。

注意：技能拆分的粒度很关键。拆得太粗，agent 调用时容易一次做太多事导致输出混乱；拆得太细，调用链路过长，token 消耗和延迟都会上去。我的经验是，一个技能对应一个明确的“是/否”判断或一个可量化的指标提取，这个粒度最稳。

2.2 为什么选 Claude Code 作为执行载体

热词里大量出现 Claude Code 的安装、配置、接入 DeepSeek 等内容，说明很多人已经在把它当成本地 agent 运行环境。marketingskills和 Claude Code 结合是顺理成章的：Claude Code 能直接在终端执行命令、读写文件、调用外部 API，这意味着技能模块可以落地成实际的脚本和配置文件，而不是停留在 prompt 层面。

具体来说，Claude Code 在这个场景里承担三个角色。第一是调度器：它读取你的任务描述，决定调用哪些技能、按什么顺序。第二是执行器：技能背后可能是 Python 脚本、curl 请求、或者对本地文件的解析，Claude Code 直接跑。第三是汇总器：把各技能的输出整理成人类可读的报告，或者写入指定格式的文件。

相比纯 prompt 方案，这种做法的优势在于结果可复现。纯 prompt 每次输出格式可能漂移，但技能模块背后是确定的代码逻辑，同样的输入永远得到同样的判断。对于营销审计这种需要对比历史数据的场景，可复现性比“灵活”重要得多。

2.3 方案选型背后的取舍：不追求全自动，追求“人机协作”

我见过一些团队一上来就想做“全自动营销 agent”，输入域名就自动改页面、自动发内容、自动调预算。实测下来，这条路在现阶段风险很高。marketingskills的设计哲学是人在关键节点做决策，agent 做重复判断和信息聚合。

比如 SEO 审计，agent 可以自动爬取、自动检查、自动生成问题清单，但“这个标题要不要改”“这个内链结构要不要调整”仍然由人决定。CRO 建议也是同理，agent 给出基于规则的修改方向，人来判断是否符合品牌调性和业务实际。这样做的好处是：出错成本可控，而且人对 agent 输出的信任是逐步建立的，不是一次性押注。

另一个取舍是优先做“检查型”技能，后做“生成型”技能。检查型技能（如标题长度、H1 数量、图片 alt 缺失）判断标准明确，容易验证，出错也容易发现。生成型技能（如自动写 meta description、自动生成 CTA 文案）主观性强，质量波动大，适合在检查型技能跑通、建立信任后再逐步加入。

3. 核心细节解析与实操要点：技能模块到底怎么落地

3.1 技能模块的目录结构与文件组织

落地marketingskills第一步是定目录结构。我实测下来最顺手的是按“领域 + 技能名”两级组织，每个技能一个独立目录，里面放技能定义、执行脚本、测试样例。

marketingskills/ ├── seo/ │ ├── check_title_length/ │ │ ├── skill.md # 技能定义：输入、输出、判断逻辑 │ │ ├── run.py # 执行脚本 │ │ └── fixtures/ # 测试样例 │ ├── check_meta_description/ │ └── check_h1_uniqueness/ ├── cro/ │ ├── check_cta_visibility/ │ ├── check_form_field_count/ │ └── check_trust_badges/ ├── analytics/ │ ├── detect_traffic_anomaly/ │ └── summarize_funnel_dropoff/ └── shared/ ├── fetch_page.py # 公共抓取逻辑 └── parse_html.py # 公共解析逻辑

skill.md是整个技能的核心，它用自然语言加结构化字段描述这个技能做什么、怎么调用、输出什么。Claude Code 读取这个文件后就知道该技能的能力边界。我一般按这个模板写：

# Skill: check_title_length ## 用途 检查页面 title 标签长度是否在推荐范围内。 ## 输入 - url: string, 页面地址 ## 输出 - status: pass | warn | fail - actual_length: number - recommended_range: [30, 60] - message: string ## 判断逻辑 - 长度 30-60 字符：pass - 长度 1-29 或 61-80：warn - 长度 0 或 >80：fail ## 依赖 - shared/fetch_page.py

这种写法的好处是人和 agent 都能读。人看一遍就知道技能干什么，agent 解析后知道怎么调用、输出什么格式。run.py则是实际执行逻辑，通常很短，因为公共逻辑抽到了shared/里。

3.2 技能定义的三个关键字段：输入、输出、判断逻辑

技能定义写得好不好，直接决定 agent 调用时会不会翻车。我踩过的坑主要集中在三个字段上。

输入字段要尽量窄。早期我写过一个check_page_quality技能，输入只有一个 URL，输出一大堆指标。结果 agent 调用时经常把不同维度的结果混在一起，汇总报告时逻辑混乱。后来拆成多个单一输入技能，每个只接收 URL 或 HTML 字符串，输出聚焦一个维度，稳定性大幅提升。

输出字段要固定 schema。营销数据经常需要跨页面、跨时间对比，如果每次输出格式不一样，后续聚合就很痛苦。我现在的做法是所有技能输出都包含status、value、message三个基础字段，再按需加扩展字段。status统一用pass/warn/fail三档，方便 agent 快速筛选。

判断逻辑要写清楚边界条件。比如标题长度检查，30 和 60 到底算 pass 还是 warn，必须明确。我见过有人写“大约 30 到 60”，结果 agent 每次判断都不一样。营销规则可以简单，但必须确定。

实操心得：技能定义写完后，一定要用 fixtures 里的样例跑一遍，确认输出符合预期。我一般每个技能准备 3 个样例：一个明显 pass、一个边界 warn、一个明显 fail。跑通再接入 agent。

3.3 与 Claude Code 的对接方式：从 prompt 到可执行工作流

Claude Code 调用技能模块有两种方式，我两种都用过，各有适用场景。

第一种是 prompt 内嵌调用。在对话里直接说“用 check_title_length 技能检查 https://example.com”，Claude Code 会读取技能定义、执行脚本、返回结果。这种方式适合临时检查、调试技能、或者一次性任务。优点是灵活，缺点是每次都要描述清楚，批量任务时效率低。

第二种是工作流文件调用。把一组技能的调用顺序写成一个 workflow 文件，Claude Code 读取后按流程执行。比如一个完整的落地页审计工作流：

# workflows/landing_page_audit.yaml name: landing_page_audit steps: - skill: seo/check_title_length input: { url: "{{target_url}}" } - skill: seo/check_meta_description input: { url: "{{target_url}}" } - skill: seo/check_h1_uniqueness input: { url: "{{target_url}}" } - skill: cro/check_cta_visibility input: { url: "{{target_url}}" } - skill: cro/check_form_field_count input: { url: "{{target_url}}" } - skill: cro/check_trust_badges input: { url: "{{target_url}}" } output: format: markdown path: "./reports/{{target_url | slugify}}.md"

这种方式适合固定流程的批量任务。我每周给客户做站点审计时，就是跑这个 workflow，输入一批 URL，输出一批报告。Claude Code 在这里的角色是流程引擎加结果汇总，技能模块是实际干活的。

两种方式可以混用。日常调试用 prompt，正式任务用 workflow。关键是技能定义本身要稳定，这样无论哪种调用方式，结果都一致。

3.4 数据抓取与解析的公共层设计

技能模块里最容易重复造轮子的地方是抓取和解析。每个技能都写一遍requests.get加BeautifulSoup是浪费，而且容易出现超时、编码、重定向处理不一致的问题。我的做法是抽一个shared/fetch_page.py，统一处理这些事。

# shared/fetch_page.py import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry def fetch_page(url, timeout=15): session = requests.Session() retries = Retry(total=3, backoff_factor=0.5, status_forcelist=[500, 502, 503, 504]) session.mount("https://", HTTPAdapter(max_retries=retries)) headers = { "User-Agent": "Mozilla/5.0 (compatible; MarketingSkillsBot/1.0)" } resp = session.get(url, headers=headers, timeout=timeout, allow_redirects=True) resp.raise_for_status() return resp.text

这个公共层做了几件事：重试机制避免偶发网络问题导致误报；统一 User-Agent避免被简单拦截；超时控制防止单个页面卡死整个工作流；重定向跟随确保拿到最终页面内容。这些细节看起来小，但批量审计时能省掉大量排查时间。

解析层同理，shared/parse_html.py封装 BeautifulSoup 的常用操作，比如提取 title、meta、h1、所有链接、所有图片。技能脚本只调用这些封装好的函数，不直接碰解析细节。这样以后换解析库或者加缓存，只改一处。

注意：抓取频率要控制。批量审计时如果并发太高，目标站点可能限流甚至封 IP。我一般设 2-3 个并发，每个请求间隔 0.5 秒。Claude Code 执行 workflow 时可以配置并发数，别贪快。

4. 实操过程与核心环节实现：从零跑通一个 SEO 审计工作流

4.1 环境准备：Claude Code 安装与基础配置

先把执行环境搭起来。Claude Code 的安装方式根据系统不同有差异，我分别在 macOS、Ubuntu 和 Windows 上装过，记录一下实际步骤。

macOS 和 Ubuntu 下，官方推荐用 npm 全局安装：

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

装完后在终端输入claude就能启动。第一次启动会引导你完成登录和基础配置。如果你在 VS Code 里用，也可以装 Claude Code 的 VS Code 扩展，这样在编辑器内就能直接调用，不用切终端。

Windows 下稍微麻烦一点，建议在 WSL2 里操作，体验和 Ubuntu 一致。原生 Windows 下 npm 安装也能跑，但路径和权限问题多一些。我实测 WSL2 最稳。

配置方面，核心是确认 Claude Code 能正常执行终端命令和读写文件。启动后可以先用一个简单任务测试：

claude "在当前目录创建一个 test.txt，写入 hello"

如果文件正常创建，说明基础环境没问题。接下来把marketingskills目录放到一个固定位置，比如~/projects/marketingskills，然后在 Claude Code 里cd进去，让它读取技能定义。

提示：如果你在配置过程中遇到模型接入的问题，Claude Code 支持配置不同的模型后端。具体配置方式参考官方文档，这里不展开。重点是确保 agent 能稳定执行本地命令。

4.2 第一个技能：check_title_length 的完整实现

拿check_title_length做第一个技能，因为它足够简单，能快速验证整条链路。

先写skill.md，按前面说的模板定义清楚。然后写run.py：

# seo/check_title_length/run.py import sys import os sys.path.append(os.path.join(os.path.dirname(__file__), "../../shared")) from fetch_page import fetch_page from parse_html import extract_title def check_title_length(url): html = fetch_page(url) title = extract_title(html) length = len(title) if title else 0 if length == 0: status = "fail" message = "页面缺少 title 标签" elif length > 80: status = "fail" message = f"title 过长（{length} 字符），建议压缩到 60 以内" elif length < 30: status = "warn" message = f"title 偏短（{length} 字符），可能浪费关键词空间" elif length > 60: status = "warn" message = f"title 略长（{length} 字符），搜索结果中可能被截断" else: status = "pass" message = f"title 长度合适（{length} 字符）" return { "status": status, "actual_length": length, "recommended_range": [30, 60], "message": message } if __name__ == "__main__": url = sys.argv[1] result = check_title_length(url) print(result)

parse_html.py里的extract_title就是简单的 BeautifulSoup 提取：

# shared/parse_html.py from bs4 import BeautifulSoup def extract_title(html): soup = BeautifulSoup(html, "html.parser") title_tag = soup.find("title") return title_tag.get_text(strip=True) if title_tag else ""

写完用 fixtures 测试：

python seo/check_title_length/run.py https://example.com

输出应该是一个字典，包含 status、actual_length、message。确认无误后，在 Claude Code 里调用：

claude "用 seo/check_title_length 技能检查 https://example.com，输出结果"

Claude Code 会读取 skill.md、执行 run.py、返回格式化结果。到这一步，第一个技能就跑通了。

4.3 批量审计工作流：从单页检查到站点级报告

单页检查跑通后，扩展到站点级。核心是加一个 URL 收集步骤，然后对每个 URL 跑技能组合。

URL 收集我一般用两种方式。一是从 sitemap.xml 解析，适合结构规范的站点：

# shared/collect_urls.py import requests from bs4 import BeautifulSoup def collect_from_sitemap(sitemap_url, limit=200): resp = requests.get(sitemap_url, timeout=15) soup = BeautifulSoup(resp.text, "xml") urls = [loc.get_text(strip=True) for loc in soup.find_all("loc")] return urls[:limit]

二是从首页爬取内链，适合没有 sitemap 或 sitemap 不全的站点。两种方式可以结合，sitemap 为主，内链补充。

拿到 URL 列表后，工作流按这个顺序跑：

1. 对每个 URL 跑check_title_length、check_meta_description、check_h1_uniqueness
2. 汇总所有结果，按 status 分组
3. 生成 Markdown 报告，包含问题清单和优先级建议

报告结构我固定成三部分：概览（总页面数、pass/warn/fail 分布）、问题清单（按严重程度排序，每条含 URL、问题描述、建议）、附录（原始数据表格）。这样客户拿到报告能直接看重点，需要细节时再翻附录。

# SEO 审计报告：example.com ## 概览 - 检查页面数：156 - Pass：98（62.8%） - Warn：41（26.3%） - Fail：17（10.9%） ## 高优先级问题 | URL | 问题 | 建议 | |-----|------|------| | /pricing | title 缺失 | 添加包含核心关键词的 title，控制在 30-60 字符 | | /blog/post-12 | H1 重复 | 确保每页只有一个 H1，且与 title 语义一致 | ## 附录：完整数据 ...

这个报告模板我用了大半年，客户反馈最实用的是高优先级问题表格，直接告诉改什么、怎么改，不用自己从一堆数据里找。

4.4 CRO 技能的接入：转化率检查怎么和 SEO 审计并行

SEO 审计跑顺后，把 CRO 技能接进来。CRO 检查和 SEO 检查的关注点不同，SEO 看的是搜索引擎能不能理解页面，CRO 看的是用户能不能顺利完成转化动作。

我常用的 CRO 技能有这几个：

• check_cta_visibility：检查 CTA 按钮是否在首屏可见、对比度是否足够、文案是否明确
• check_form_field_count：统计表单字段数，超过 5 个给出警告
• check_trust_badges：检查是否有信任标识（客户 logo、评价、安全认证等）
• check_page_speed_signals：检查影响加载速度的明显问题（大图未压缩、阻塞脚本等）

这些技能和 SEO 技能可以并行跑，因为输入都是 URL，输出格式统一。Claude Code 的 workflow 里可以配置并行执行，节省时间。

CRO 检查的输出我一般单独成一份报告，因为受众不同。SEO 报告给技术或内容团队，CRO 报告给设计和运营团队。两份报告可以交叉引用，比如某个页面 SEO 没问题但 CRO 问题多，就在两份报告里都标注出来。

实操心得：CRO 技能的判断标准比 SEO 更依赖业务上下文。比如表单字段数，B2B 场景下 7 个字段可能正常，B2C 场景下 3 个都嫌多。所以 CRO 技能的阈值我做成可配置的，在 skill.md 里加一个config字段，调用时传入业务类型，技能根据类型选不同阈值。

5. 常见问题与排查技巧实录

5.1 技能调用失败：从报错信息定位问题

批量跑技能时最常见的失败是抓取超时或解析异常。我整理了一个排查顺序，基本能覆盖 90% 的情况。

这个表我贴在项目 README 里，团队新人遇到问题先查表，大部分能自己解决。

5.2 误报处理：当技能判断和人工判断不一致

技能跑多了，一定会遇到误报。比如某个页面 title 长度 62 字符，技能判 warn，但人工看觉得没问题。这种情况不要急着改技能阈值，先分析误报原因。

我遇到过的误报主要三类。第一类是规则本身太死，比如 title 长度硬卡 60，但某些语言或某些关键词就是需要更长。解决方式是加例外规则，比如品牌词结尾的 title 允许放宽到 70。第二类是页面特殊情况，比如登录页、404 页本来就不需要标准 SEO 配置。解决方式是在 URL 收集阶段过滤掉这些页面。第三类是抓取问题，比如拿到了重定向前的页面。解决方式是确认 fetch 逻辑跟随了重定向。

处理误报的原则是：先确认是规则问题还是数据问题，再决定改规则还是改数据。不要一遇到误报就放宽阈值，那样技能会越来越松，最后失去判断力。

5.3 性能优化：批量任务怎么跑得更快

站点大了以后，批量审计的耗时主要花在抓取上。我实测过几种优化方式，效果从高到低排列。

第一是并发抓取。串行抓 200 个页面可能要十几分钟，改成 3-5 个并发能压到几分钟。但并发不能太高，否则目标站点可能限流。我一般设 3 个并发，每个请求间隔 0.3 秒。

第二是缓存。同一批审计里，多个技能可能抓同一个页面。如果每个技能都独立抓，浪费严重。我的做法是在 workflow 层面先抓一次，把 HTML 存到临时目录，技能从本地读。这样抓取次数从“技能数 × 页面数”降到“页面数”。

第三是增量审计。第二次审计同一站点时，只跑上次之后有变化的页面。判断变化可以用 sitemap 的 lastmod，或者对比页面内容的 hash。这个优化对定期审计的客户特别有用，能把耗时降一个数量级。

# shared/cache.py import hashlib import os CACHE_DIR = "/tmp/marketingskills_cache" def get_cache_path(url): url_hash = hashlib.md5(url.encode()).hexdigest() return os.path.join(CACHE_DIR, f"{url_hash}.html") def cache_page(url, html): os.makedirs(CACHE_DIR, exist_ok=True) with open(get_cache_path(url), "w", encoding="utf-8") as f: f.write(html) def read_cache(url): path = get_cache_path(url) if os.path.exists(path): with open(path, "r", encoding="utf-8") as f: return f.read() return None

这个缓存逻辑很简单，但效果立竿见影。200 页的站点，加缓存后整体耗时从 8 分钟降到 2 分钟左右。

5.4 技能扩展：怎么加自己业务的专属检查

marketingskills最大的价值是可扩展。每个业务都有自己特殊的检查需求，加技能是常态。我加过的一些业务专属技能包括：检查产品页是否包含特定认证标识、检查博客文章是否包含内链到产品页、检查落地页是否包含价格锚点。

加技能的流程很固定：先写 skill.md 定义清楚，再写 run.py 实现，然后用 fixtures 测试，最后接入 workflow。整个过程熟练后 20 分钟能加一个技能。

有个小技巧：新技能先在 prompt 模式下单独测试，确认输出稳定后再加入 workflow。直接加 workflow 的话，一旦技能有问题，整个工作流都会受影响，排查起来麻烦。

注意：技能多了以后要定期清理。有些技能可能只在一个项目里用过，或者业务规则已经变了。我一般每季度过一遍技能列表，把不再用的归档，把规则过时的更新。保持技能库精简，agent 调用时选择更准确。

6. 从 SEO 到 Analytics：把数据反馈接进技能闭环

6.1 审计结果和实际数据的对照

SEO 和 CRO 技能跑出来的都是“应该怎样”，但实际效果要看数据。把 Analytics 接进来，才能形成闭环。我常用的做法是：审计报告生成后，拉取对应页面的流量和转化数据，对照看哪些问题真的影响了业务指标。

比如审计发现 20 个页面 title 缺失，但其中只有 5 个页面有自然流量。那优先级就很清楚：先修有流量的 5 个。这个判断如果只靠审计报告做不了，必须结合 Analytics 数据。

Analytics 技能我一般做两个：fetch_page_metrics拉取指定页面的流量、跳出率、转化率；detect_traffic_anomaly检测流量异常波动。前者用于审计报告增强，后者用于日常监控。

6.2 用 agent 做定期监控和告警

审计是周期性的，监控是持续的。我把marketingskills里的检查技能和 Analytics 技能组合成一个定期任务，每天跑一次，发现异常就输出告警。

告警规则我设了几条：自然流量周环比下降超过 20%、核心页面跳出率上升超过 15%、转化率下降超过 10%。触发任何一条，agent 就生成一份简报，包含异常指标、可能相关的页面问题、建议排查方向。

这个监控跑了一个季度，确实抓到过几次问题。有一次是某个产品页的 CTA 按钮被误删，CRO 技能在当天检查中就发现了，比等周报发现早了好几天。

6.3 数据驱动的技能迭代

Analytics 数据反过来也能优化技能本身。比如某个 CRO 技能建议“表单字段减到 5 个以内”，但数据显示字段减少后转化率没变化，那这个技能的阈值可能不适合这个业务，需要调整。

我一般每季度做一次技能效果回顾：把技能给出的建议和实际数据变化对照，看哪些建议真的有效，哪些是噪音。有效的保留或加强，无效的调整或移除。这样技能库会越来越贴合业务实际，而不是一堆通用规则的堆砌。

这个迭代过程不需要很复杂，一张表格就能管起来：

这张表每季度更新一次，技能库的优化方向就很清楚了。

7. 一些实测下来的经验和小技巧

技能定义里的判断逻辑，能用数字就别用形容词。“标题偏短”不如“标题少于 30 字符”，agent 理解起来更准，输出也更一致。

抓取公共层一定要做重试和超时。我早期没做，批量跑的时候经常因为一两个页面卡住整个流程，排查半天发现只是网络抖动。

workflow 文件用 YAML 写，别用 JSON。YAML 可读性好，改起来方便，而且支持注释，团队协作时能标注每个步骤的意图。

技能输出统一用pass/warn/fail三档，别用分数。分数看起来精细，但阈值难定，而且不同技能的分数量纲不一样，汇总时很麻烦。三档足够表达“没问题/要注意/有问题”。

定期审计和持续监控分开跑。审计用 workflow 批量跑，监控用定时任务单页跑。两者共用技能库，但触发方式和输出格式不同。

新技能先在 prompt 模式测试，稳定后再进 workflow。这个习惯帮我省了很多排查时间。

技能库要版本管理。用 git 管起来，每次改技能定义或阈值都提交，出问题能回滚，也能看到规则演变历史。

最后分享一个我常用的调试技巧：技能输出不对时，先单独跑run.py，确认脚本本身没问题，再在 Claude Code 里跑，确认 agent 调用没问题。两层分开排查，定位快很多。