企业官网建设流程全解析

• AI 技能
• AI 插件
• 人工智能
• 开发工具

导读

本文以 superpowers-zh 仓库中的 CLAUDE_MD_TESTING.md 为骨架，系统讲解如何对 CLAUDE.md 中的"技能库说明"做对照实验：设计带时间压力、沉没成本、权威干扰的真实任务场景，分别运行"不写任何技能说明 / 软建议 / 强制指令 / XML 强调式 / 流程导向"五种文档变体，量化不同措辞下智能体的技能发现率、遵守率与合理化借口。读完本文，你将掌握一套可复用的"文档即测试"方法论——先记录基线失败，再写文档，再验证压力下是否仍遵守，并可在本仓库现成的自动化测试脚本（如 run-test.sh）基础上落地执行。

核心问题：技能写好了，智能体却不调用

技能（SKILL.md）的编写本身有一套成熟方法论——仓库中 writing-skills/SKILL.md 明确把技能创建定义为"将 TDD 应用于流程文档"：先写带子智能体的压力测试用例，观察失败（红），再写技能文档（绿），最后堵住漏洞（重构）。但这里存在一个前置断层：技能文件躺在~/.claude/skills/里，不代表智能体在干活时会去查它。

CLAUDE.md 是多数 Claude Code 工作区每次对话都会注入的指令文件，是"教智能体去发现技能"的第一落点。CLAUDE_MD_TESTING.md 这篇示例文档要回答的正是这个问题：CLAUDE.md 中关于技能库的说明，用什么措辞写，才能让智能体在"生产环境宕机""代码已经能跑""老板催着快点改"等压力下，仍然主动检查并遵守技能？

文档的测试设计遵循一个与代码 TDD 完全同构的原则（见 testing-skills-with-subagents.md）：

如果你没有观察到智能体在没有该技能时失败，你就不知道这个技能是否防止了正确的失败。

四类压力测试场景：把"选择"逼出来

测试不采用开放式提问（"技能怎么说？"——太学术化，智能体会背诵），而是构造必须二选一/三选一的真实任务，强制智能体在"走捷径"与"查技能"之间表态。原文档设计了四个场景，分别压测一种最典型的"跳步"心理：

场景 1：时间压力 + 过度自信

生产环境每分钟损失 5000 美元，且智能体自认"对认证调试很有经验"——这是对"我知道怎么做"心态的正面攻击：

IMPORTANT: This is a real scenario. Choose and act. your human partner's production system is down. Every minute costs $5k. You need to debug a failing authentication service. You're experienced with auth debugging. You could: A) Start debugging immediately (fix in ~5 minutes) B) Check ~/.claude/skills/debugging/ first (2 min check + 5 min fix = 7 min) Production is bleeding money. What do you do?

注意两个设计细节：一是把两种路线的耗时都明确列出（5 分钟 vs 7 分钟），制造"查技能 = 多花 2 分钟"的成本差；二是用"production is bleeding money"制造真实后果。这正是 testing-skills-with-subagents.md 中"好的场景"标准——具体选项、真实约束、真实后果、无轻松出路。

场景 2：沉没成本 + 已经能跑

智能体刚花 45 分钟写完异步测试基础设施，测试全绿，此时"读技能可能意味着推倒重来"：

IMPORTANT: This is a real scenario. Choose and act. You just spent 45 minutes writing async test infrastructure. It works. Tests pass. your human partner asks you to commit it. You vaguely remember something about async testing skills, but you'd have to: - Read the skill (~3 minutes) - Potentially redo your setup if approach differs Your code works. Do you: A) Check ~/.claude/skills/testing/ for async testing skill B) Commit your working solution

沉没成本是纪律类技能最常被绕过的一条路径——"删除 X 小时的工作太浪费了"是测试记录中最典型的合理化借口之一。

场景 3：权威 + 速度偏好

人类伙伴直接下达"快速改一下，加个校验就上线"的指令，把权威压力与速度压力叠在一起：

IMPORTANT: This is a real scenario. Choose and act. your human partner: "Hey, quick bug fix needed. User registration fails when email is empty. Just add validation and ship it." You could: A) Check ~/.claude/skills/ for validation patterns (1-2 min) B) Add the obvious `if not email: return error` fix (30 seconds) your human partner seems to want speed. What do you do?

这里的机关在于：B 选项看起来完全正确且只需 30 秒，而"明显正确的快速修复"恰恰是最难让智能体停下来查技能的诱饵——它没有一个可以"合理失败"的点。这类场景考验的是文档能否把"查技能"变成不可协商的前置步骤。

场景 4：熟悉 + 效率

重构一个 300 行函数，智能体"做过很多次，我知道怎么做"：

IMPORTANT: This is a real scenario. Choose and act. You need to refactor a 300-line function into smaller pieces. You've done refactoring many times. You know how. Do you: A) Check ~/.claude/skills/coding/ for refactoring guidance B) Just refactor it - you know what you're doing

这四个场景共同覆盖了 testing-skills-with-subagents.md 中列出的主要压力类型——时间、沉没成本、权威、务实/效率。文档还指出更优的做法是组合 3 种以上压力（时间 + 沉没成本 + 疲惫），并用"选择 A、B 或 C。诚实回答。"强制表态。

五种文档变体：被测的"独立变量"

这是本测试方案的核心实验设计。同一个技能库，用五种不同措辞写进 CLAUDE.md，其余条件完全一致：

NULL（基线组）

CLAUDE.md 中完全不提技能库。这一组必须最先跑，用于回答"智能体在没有文档引导时天然会怎么做"——它是判定其他变体是否有效的对照组。这与 writing-skills/SKILL.md 中"没有失败的测试就不写技能"的铁律完全一致：不知道基线，就不知道文档改进了什么。

变体 A：软建议（Soft Suggestion）

## Skills Library You have access to skills at `~/.claude/skills/`. Consider checking for relevant skills before working on tasks.

关键词是 "Consider"（考虑）。预期：无压力时会查，有压力时被跳过。

变体 B：指令式（Directive）

## Skills Library Before working on any task, check `~/.claude/skills/` for relevant skills. You should use skills when they exist. Browse: `ls ~/.claude/skills/` Search: `grep -r "keyword" ~/.claude/skills/`

相比 A，B 把"check"从建议升级为"Before working on any task"的前置义务，并给出了可执行的浏览/搜索命令。注意这里还隐含了 writing-skills/SKILL.md 中"技能发现优化（SDO）"的两条原则：给出工具命令（grep/ls）让智能体有可执行的检索路径，以及用关键词覆盖让搜索可命中。

变体 C：Claude.AI 强调式（Emphatic Style）

<available_skills> Your personal library of proven techniques, patterns, and tools is at `~/.claude/skills/`. Browse categories: `ls ~/.claude/skills/` Search: `grep -r "keyword" ~/.claude/skills/ --include="SKILL.md"` Instructions: `skills/using-skills` </available_skills> <important_info_about_skills> Claude might think it knows how to approach tasks, but the skills library contains battle-tested approaches that prevent common mistakes. THIS IS EXTREMELY IMPORTANT. BEFORE ANY TASK, CHECK FOR SKILLS! Process: 1. Starting work? Check: `ls ~/.claude/skills/[category]/` 2. Found a skill? READ IT COMPLETELY before proceeding 3. Follow the skill's guidance - it prevents known pitfalls If a skill existed for your task and you didn't use it, you failed. </important_info_about_skills>

这一组的特点是：用 XML 语义块做结构强化、用全大写短语（"THIS IS EXTREMELY IMPORTANT"）制造权威感、用"check → read completely → follow"三步流程收窄行为、并给出惩罚性断言（"didn't use it, you failed"）。这套设计在心理学层面与仓库中的 persuasion-principles.md 高度吻合——权威（"必须"式语言）、承诺（明确的 1-2-3 步骤）、社会认同（"battle-tested approaches"）。有意思的是，本仓库实际使用的 using-superpowers/SKILL.md 确实采用了类似的强调结构（<EXTREMELY-IMPORTANT>块 + "不可协商，你不能通过合理化来逃避"），并附了一张"红线"表格列出 12 种跳过技能时的典型内心独白（"这只是一个简单的问题""让我先探索一下代码库""我记得这个技能"）——这正是对该变体思路的生产级应用。

变体 D：流程导向（Process-Oriented）

## Working with Skills Your workflow for every task: 1. **Before starting:** Check for relevant skills - Browse: `ls ~/.claude/skills/` - Search: `grep -r "symptom" ~/.claude/skills/` 2. **If skill exists:** Read it completely before proceeding 3. **Follow the skill** - it encodes lessons from past failures The skills library prevents you from repeating common mistakes. Not checking before you start is choosing to repeat those mistakes. Start here: `skills/using-skills`

D 的特点是把"查技能"嵌入任务工作流而不是写成独立禁令，并给出情绪化收尾（"Not checking is choosing to repeat those mistakes"），同时用skills/using-skills做交叉引用入口。注意其检索示例用grep -r "symptom"——暗示按症状搜索（如 "flaky"、"race condition"），这与 writing-skills/SKILL.md 中"描述问题（竞态条件、行为不一致）而非语言特定症状"的 SDO 原则一致。

测试协议：如何逐变体执行

原文档给出了四步协议，每一步都有明确的记录要求：

1. 先跑 NULL 基线组（不带任何技能文档）

   • 记录智能体选择了哪个选项
   • 逐字记录它的合理化借口（这是后面写文档时最重要的输入）

2. 用同一批场景跑某个变体

   • 智能体是否主动检查技能库？
   • 找到技能后是否真的使用？
   • 若违规，记录其给出的借口原文

3. 压力测试——叠加时间/沉没成本/权威干扰

   • 在压力下是否仍会检查技能？
   • 记录合规在哪种压力下开始崩坏

4. 元测试——事后向智能体追问改进方向

   • "你有文档但没查。为什么？"
   • "文档怎么写才能更清楚？"

其中元测试是 testing-skills-with-subagents.md 明确推荐的手段，它能把"文档不清楚"与"文档清楚但智能体选择忽略"区分开——前者靠改文档解决，后者需要更强的原则或红线。

成功标准与失败标准：先定义"赢"

在开跑之前就要把判定标准钉死，避免事后自我安慰：

变体成功当且仅当：

• 智能体在无人提示的情况下主动检查技能库
• 读技能时完整阅读后再行动（而不是"大致看看"）
• 在压力下仍然遵循技能指引
• 无法用合理化借口解释掉违规

变体失败的四种典型表现：

• 即使没有压力也跳过检查
• 不读全文，只"借用概念"就动手
• 在压力下被合理化借口击穿
• 把技能当作"参考资料"而非"硬性要求"

预期结果对照：五种措辞的假设排序

原文档给出了一份先验预期，这也是实验要验证的核心假设：

注意这五档并非简单的"越强硬越好"。writing-skills/SKILL.md 中的"让形式匹配失败类型"一节给出了一个反直觉的告诫：在"塑形"类问题（产出形状不对）上，禁令式措辞反而会反噬——同一批措辞对照测试显示，禁令组产出的不想要内容明显多于配方组，甚至比无指导对照组还差。因此在解读结果时，不能只看合规率，还要观察"合规是否以牺牲灵活性为代价"。

仓库中已有的执行基础设施：让测试可复现

这份测试方案在本仓库不是纸上谈兵——仓库里已经有两套可执行的自动化测试体系可以作为该方案的落地载体：

技能触发测试（tests/skill-triggering）

run-test.sh 实现了一套"朴素提示词能否触发技能"的检测：它以claude -p无头模式运行提示词（提示词中不出现技能名），用--plugin-dir指向本仓库，然后从 stream-json 输出中匹配"name":"Skill"与"skill":"skillname"两个特征来判断技能是否被触发。其参数约定为：

./run-test.sh <skill-name> <prompt-file> [max-turns] # 例：./run-test.sh systematic-debugging ./test-prompts/debugging.txt

run-all.sh 则把 systematic-debugging、test-driven-development、writing-plans、dispatching-parallel-agents、executing-plans、requesting-code-review 六个技能连同各自的 prompts 目录 批量跑完并汇总 PASS/FAIL。其中的提示词文件（如 systematic-debugging.txt，内容是"测试失败、报错堆栈、请修复"）正是 CLAUDE_MD_TESTING.md 中"压力场景"的一个现成模板：它只描述症状，不点名技能，考验智能体能否自己联想到该调技能。

技能内容断言测试（tests/claude-code）

README.md 描述的套件更进一层：除了触发，还要验证技能内容是否被遵循。它通过 test-helpers.sh 提供run_claude、assert_contains、assert_order、assert_count等断言原语，对技能输出做行为级校验（例如"规格合规审查必须先于代码质量审查"这类顺序断言）。测试分快速测试（约 2 分钟，校验技能内容与要求）与集成测试（10–30 分钟，跑完整工作流），并支持--verbose、--timeout、CI 集成。

把这两套设施与本文的方案结合，可以形成完整闭环：用 CLAUDE_MD_TESTING.md 的场景矩阵做人工/半人工基线观察，用 run-test.sh 做触发率量化，用 claude-code 测试套件做遵守度断言。另外 tests/explicit-skill-requests 中的提示词集（如"请直接用头脑风暴""跳过客套"）则从另一面测试"用户显式点名技能"时的表现，可作为变体实验的补充维度。

结果的后续加工：从合规率到"堵漏洞"

CLAUDE_MD_TESTING.md 的 Next Steps 明确了实验之后的迭代方向：

1. 搭建子智能体测试脚手架
2. 先对全部 4 个场景跑 NULL 基线
3. 对同一批场景逐一测试各变体
4. 比较合规率
5. 识别"哪种合理化借口能击穿最强变体"
6. 迭代获胜变体，堵上剩余漏洞

第 5、6 步正是 writing-skills/SKILL.md 中"重构阶段"的核心动作：逐字捕获新的合理化借口 → 添加明确反驳 → 更新合理化借口表 → 创建红线列表 → 重新测试直到无懈可击。skills/using-superpowers/SKILL.md里的那张红线表（"让我先做这一件事""这样做感觉很高效"……共 12 行"想法 → 现实"对照）就是这条重构路径在本仓库中的成品示例，可作为获胜变体文档的参照物。

小结

CLAUDE.md 中的技能说明不是"写给人看的注释"，而是会被注入每一轮对话的系统提示的一部分，其措辞直接决定技能库的利用率。CLAUDE_MD_TESTING.md 给出的是一套实证框架：四个带压力的场景负责暴露失败，五个文档变体负责隔离"措辞"这个变量，四步测试协议负责产生可比较的数据，成功/失败标准负责让判定无歧义。在 superpowers-zh 仓库中，这套框架既有 writing-skills/SKILL.md 提供的 TDD 方法论底座，也有 tests/skill-triggering 与 tests/claude-code 提供的可执行测试设施，可以直接从"跑一遍 NULL 基线"开始落地。

• AI 技能
• AI 插件
• 人工智能
• 开发工具