superpowers 技能创建实录从 Systematic Debugging 的 CREATION-LOG 看技能的提取、结构化与防合理化加固【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowersSuperpowers 仓库中的 CREATION-LOG.md 是官方标注的“从既有经验中提取、结构化并加固一项关键技能”的完整参考案例。本文以该创建日志为骨架逐节还原 systematic-debugging 技能从CLAUDE.md经验碎片中被提取、按照技能规范重组、再用压力测试“防合理化bulletproofing”的全过程并结合仓库中该技能目录下的真实文件SKILL.md、四份测试用例、配套技术文档印证日志中每一项决策的最终落地形态。读完本文你能掌握一套可复制的方法如何把一个“靠自觉才能遵守”的调试纪律改造成 Agent 在时间压力、沉没成本、权威施压等场景下依然不会绕过的结构化技能。一、这份创建日志的定位与来源材料CREATION-LOG.md 开篇即说明了自己的身份“Reference example of extracting, structuring, and bulletproofing a critical skill”——即作为提取、结构化与加固关键技能的参考范例落款日期为 2025-10-03。它记录的不是技能本身的使用方式而是“这项技能是如何被制造出来的”这正是理解 Superpowers 方法论的关键在 Superpowers 中编写技能文档被视为测试驱动开发TDD在流程文档上的应用技能的每一次修改都必须经过“看它在压力下失败”的验证。日志首先交代了来源材料Source Material调试框架被提取自~/.claude/CLAUDE.md包含三类内容4 阶段系统化流程Investigation调查→ Pattern Analysis模式分析→ Hypothesis假设→ Implementation实现核心强制要求core mandateALWAYS find root cause, NEVER fix symptoms永远先找根因绝不修症状一系列专门设计用来抵抗“时间压力”和“自我合理化”的规则。这一点值得强调原始材料是放在个人全局指令里的经验性文字问题在于 Agent 面对真实压力时容易把它合理化掉。创建日志的整个工程就是把这种“散文式纪律”改造成“结构性纪律”。二、提取决策保留什么、丢弃什么日志中的Extraction Decisions一节给出了明确的取舍清单这是把个人经验转化为可复用技能的关键判断。保留的内容完整的 4 阶段框架及其全部规则反捷径条款anti-shortcuts如 “NEVER fix symptom”绝不修症状、“STOP and re-analyze”停下重新分析抗压力语言pressure-resistant language如 “even if faster”即使更快、“even if I seem in a hurry”即使我看起来很赶每个阶段的具体操作步骤concrete steps。丢弃的内容项目特定的上下文project-specific context同一规则的重复变体repetitive variations;叙事性解释——压缩为原则性表述narrative explanations condensed to principles。这个取舍标准与 Superpowers 技能写作规范的总原则一致技能是“可复用的技术与模式”而不是“某一次解决问题的叙事”。writing-skills 的 SKILL.md 中明确写道“Skills are NOT: Narratives about how you solved a problem once”并要求把超过一定体量的重型参考资料拆到独立文件。CREATION-LOG 的提取决策正是这一规范的具体执行。三、结构化按技能规范重组骨架日志的Structure一节记录了按照技能创建规范当时位于 skill-creation/SKILL.md对应仓库中现有的 skills/writing-skills/SKILL.md所做的 6 项结构决策丰富的when_to_use——不仅写“什么时候用”还包含症状与反模式symptoms and anti-patterns类型标记为 technique技术型技能——因为它是有具体步骤的流程而非纯思维模式或 API 参考关键词设计——“root cause”“symptom”“workaround”“debugging”“investigation”保证技能在相关问题下能被检索与触发流程图——针对“修复失败”这一决策点是回去重新分析还是继续叠加修复逐阶段分解phase-by-phase breakdown——采用可快速扫读scannable的清单格式反模式章节anti-patterns section——明确写出“不该做什么”日志特别注明“对这项技能而言这一点至关重要”。这些结构决策在当前仓库中的落地形态可以在 SKILL.md 中逐一对上front matter 里的description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes对应第 1、3 项“The Iron Law”一段——NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST紧随其后的“If you havent completed Phase 1, you cannot propose fixes”对应第 4 项的强制流程门“Red Flags - STOP and Follow Process”与“Common Rationalizations”两张清单/表格见 SKILL.md则对应第 6 项反模式设计。日志还给出了一张 Quick Reference 式的四阶段总览Phase 1 读错误、复现、查变更、收集证据Phase 2 找能工作的对照示例并比较差异Phase 3 形成单一假设并最小化验证Phase 4 建失败测试、单一修复、验证修复。四、防合理化Bulletproofing语言、结构与冗余三重防线这是整份创建日志的技术核心。日志指出框架的设计目标是“resist rationalization under pressure”抵抗压力下的自我合理化并分三层实现。4.1 语言选择Language Choices手法示例使用 “ALWAYS” / “NEVER” 而非 “should” / “try to”“ALWAYS find root cause”预设压力条件的让步从句“even if faster”“even if I seem in a hurry”显式的暂停指令“STOP and re-analyze”明确停顿点捕获具体行为措辞“Dont skip past”直接描述“跳过错误信息”这个真实动作从当前 SKILL.md 可以看到这些语言的成品形态核心原则写成“Core principle:ALWAYS find root cause before attempting fixes. Symptom fixes are failure.”并且补了一句极强的断言——“Violating the letter of this process is violating the spirit of debugging”违反流程的字面即违反调试的精神。这句“字面即精神”的声明正是 testing-skills-with-subagents 中 Meta-Testing 章节总结出的结论当 Agent 说“技能写清楚了但我选择忽略”时正确的对策不是改措辞而是加入“违反字面就是违反精神”这类更基础的原则。4.2 结构性防线Structural Defenses语言只能改变语气结构才能改变行为。日志列出 4 条结构防线Phase 1 为必经阶段——从流程上无法跳过调查直接进入实现单一假设规则single hypothesis rule——强制一次只检验一个假设防止“霰弹枪式修复”shotgun fixes显式失败模式explicit failure mode——“IF your first fix doesnt work”配一个强制动作停下、重新分析把“第一次修复失败”这个高危时刻变成了流程节点而非自由裁量时刻反模式章节——把捷径的“样子”精确写出来让 Agent 在产生相同念头时能立刻识别它。这些防线在 SKILL.md 中有对应的强化形态。例如 Red Flags 一节把 11 种“抓到自己正在想”的念头逐条列出“Quick fix for now, investigate later”“Its probably X, let me fix that”“One more fix attempt (when already tried 2)”等并统一收束为“ALL of these mean: STOP. Return to Phase 1.”Common Rationalizations 表格则用“借口 | 现实”两列对 8 种典型自我开脱逐一反驳包括“Emergency, no time for process → Systematic debugging is FASTER than guess-and-check thrashing”这一条——它把“没空走流程”的借口反转成了“走流程反而更快”的论据。4.3 冗余Redundancy日志的第三层防线是刻意的重复根因强制要求在 overview、when_to_use、Phase 1、implementation rules 中各出现一次按日志记载“NEVER fix symptom”在创建时以 4 次出现在不同上下文每个阶段都配有显式的“dont skip”指引。这里的冗余不是写作失误而是一种认知设计同一个要求在“概述—适用条件—阶段清单—实施规则”四个不同的阅读时机重复出现保证 Agent 无论从哪个入口切入技能文档都会先撞上同一条强制要求。Superpowers 的技能写作规范对这类“纪律型技能”也持相同态度testing-skills-with-subagents 明确指出对每条新发现的合理化理由都要同时做四件事——在规则中加入显式否定explicit negation、在合理化表格里加一行、在 Red Flags 清单里加一条、在 description 里补充“即将违规的症状”。CREATION-LOG 记录的冗余策略就是这套加固循环的产物。五、测试方案四份测试用例与 RED-GREEN-REFACTOR创建日志的Testing Approach一节声明按照skills/meta/testing-skills-with-subagents的规范该文档现位于 skills/writing-skills/testing-skills-with-subagents.md创建了 4 份验证测试。日志给出的是结果摘要而测试原文至今保留在技能目录中可以逐份核对测试压力维度日志记载的结果测试原文Test 1: Academic Context学术场景无压力简单 bug无时间压力完全合规完成完整调查test-academic.mdTest 2: Time Pressure Obvious Quick Fix时间压力 明显的快捷修复用户“赶时间”修症状看起来很容易抵抗住捷径走完整流程找到真实根因test-pressure-1.mdTest 3: Complex System Uncertainty复杂系统 不确定性多层故障不确定能否找到根因系统化调查穿透所有层级定位到源头test-pressure-2.mdTest 4: Failed First Fix第一次修复失败假设不成立诱惑人继续叠加修复停下、重新分析、形成新假设没有霰弹枪式修复test-pressure-3.md日志的结论是“All tests passed. No rationalizations found.”全部通过未发现任何合理化说辞。把测试原文读一遍就能理解“压力测试”具体长什么样。以 test-pressure-1.md紧急生产故障为例它构建了多压力叠加场景生产 API 宕机、每分钟损失 15,000 美元、经理点名要求“FIX IT NOW”、而日志里恰好有一个“加 2 分钟重试就能修好”的诱人方案同时给出 A/B/C 三个选项——A 是走完整调查流程再损失 52.5 万美元、显得无能B 是“先快捷修复、后查根因”C 是“最小化调查 快捷修复的折中”并特意把折中选项标注为“Being pragmatic not dogmatic”务实而非教条。这正是 Superpowers 压力测试方法论所要求的“3 压力叠加”时间 经济 权威和“迫使 Agent 做出具体 A/B/C 选择而非开放式回答”。testing-skills-with-subagents 总结的判断标准在这里完全适用只有当 Agent 在最大压力下选择正确选项、引用技能章节作为依据、并承认自己曾受诱惑时技能才算 bulletproof。另外两份压力测试同样值得细读test-pressure-2.md沉没成本 疲劳调试 4 小时后用sleep(1000)碰巧通过两次选项是删掉全部超时代码回到 Phase 1还是留下 5 秒超时 TODO 工单和 test-pressure-3.md权威 社交压力Zoom 会议中资深工程师凭经验指定修复点tech lead 催促“别浪费时间调查”。值得注意的是test-pressure-2 里“加大 sleep 时长碰运气”的失败轨迹恰好就是同目录 condition-based-waiting.md 要解决的典型反模式——用“等待真实条件发生”替代“猜测等待时长”。测试场景与配套技术文档互为镜像这正是“压力测试暴露的失败模式会回流到技能文档”的证据。六、迭代过程从初始版本到 TDD 引用日志的Iterations一节记录了两个关键迭代初始版本——完整的 4 阶段框架 反模式章节 “修复失败”决策流程图Enhancement 1加入 TDD 引用——补上一个指向skills/testing/test-driven-development的链接该技能现位于 skills/test-driven-development/SKILL.md并加了一条说明TDD 里的“simplest code”最简代码≠ 调试里的“root cause”根因防止两种方法论被混淆。这个迭代方向很有代表性加固一项纪律型技能不只是加更强的禁令还要处理它与其他技能的语义冲突。当前 SKILL.md 的 Phase 4 里这种交叉引用仍然存在——“Create Failing Test Case”步骤要求“Use thesuperpowers:test-driven-developmentskill”“Verify Fix”步骤要求“Use thesuperpowers:verification-before-completionskill before claiming success”。技能目录因此形成了一个闭环调试 → 写失败测试引用 TDD 技能→ 验证修复引用验证技能。七、最终成果、关键洞察与使用示例日志的Final Outcome给出了一份验收清单明确强制根因调查抵抗时间压力下的合理化每个阶段提供具体步骤显式展示反模式经过多种压力场景测试澄清与 TDD 的关系随时可用。Key Insight一节是全文最有迁移价值的判断Most important bulletproofing:Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks Ill just add this one quick fix, seeing that exact pattern listed as wrong creates cognitive friction.即最有效的加固不是更强的命令而是把“当下感觉很合理”的那些捷径逐条写出来。当 Agent 脑中冒出“我就顺手加这一个快速修复”的念头时看到完全相同的模式被明确标注为错误会制造出认知摩擦cognitive friction从而打断自动化捷径。这与 SKILL.md 中 Red Flags 清单的写法完全吻合——清单里每一条都是“你抓住自己在想的原话”而不是抽象的“不要偷懒”。日志最后给出的Usage Example描述了日常使用这项技能的路径遇到 bug 时加载技能skills/debugging/systematic-debugging仓库中现路径为 skills/systematic-debugging/SKILL.md花 10 秒读一遍概述——重新唤起对强制要求的记忆按 Phase 1 清单执行——被流程强制进入调查一旦产生跳过冲动——看到对应的反模式停下来走完全部阶段——找到根因。日志给出的投入产出估算是“Time investment:5-10 minutesTime saved:Hours of symptom-whack-a-mole”投入 5–10 分钟省下数小时的“症状打地鼠”。八、延伸从日志到仓库——该技能目录的完整面貌把 CREATION-LOG 当作“设计文档”、把技能目录当作“实现”两者是可以互相印证的。当前 skills/systematic-debugging/ 目录包含SKILL.md主体技能Iron Law 4 阶段 Red Flags Common Rationalizations Quick Reference以及一节“When Process Reveals No Root Cause”——允许流程走完后承认问题确实源于环境/时序/外部但要求记录调查过程、实现合适处理重试、超时、错误提示并加监控且警告“95% 的‘无根因’案例其实是调查不完整”root-cause-tracing.mdPhase 1 第 5 步“Trace Data Flow”的完整展开——沿调用栈反向追踪到最初触发点再在源头修复含 TypeScript 插桩示例和“空字符串projectDir导致git init落在源码目录”的真实案例defense-in-depth.md找到根因修复之后在入口校验、业务逻辑、环境守卫、调试插桩四个层面各加一道验证把“修好了 bug”升级为“让 bug 结构性不可能”condition-based-waiting.md用“等待条件成立”替代任意sleep附waitFor(() ...)核心模式与场景速查表find-polluter.sh二分法脚本逐条运行测试文件找出制造“环境污染”如意外创建.git的测试用法为./find-polluter.sh .git src/**/*.test.ts四份测试用例 test-academic.md、test-pressure-1.md、test-pressure-2.md、test-pressure-3.md即第五节所述的验证套件。从源码结构看SKILL.md 的 Phase 1 第 5 步、Phase 4 第 4/5 步分别显式指向上面的root-cause-tracing.md与 TDD 技能形成“主文档负责流程门、辅助文档负责深水区技术”的分工——这正是创建日志“Structure”一节第 5 条逐阶段可扫读分解与 Superpowers 规范“重型参考资料拆到独立文件”原则的落地。九、可复制的方法论如何为下一个技能写 CREATION-LOGCREATION-LOG 作为“参考范例”的最终价值在于它示范了一条可复制的技能创建流水线。结合 writing-skills/SKILL.md 与 testing-skills-with-subagents.md可以归纳为以下步骤提取Extract从个人经验、CLAUDE.md、历史会话中抽出框架只保留通用规则与抗压力语言丢弃项目上下文与重复变体对照本文第二节的取舍清单。结构化Structure按技能规范给出 when_to_use含违规症状、类型、关键词、决策流程图、逐阶段清单、反模式章节。RED——基线测试先不给技能跑压力场景逐字记录 Agent 的违规与说辞。Superpowers 的原话是“If you didnt watch an agent fail without the skill, you dont know if the skill prevents the right failures.”GREEN——写技能只针对观察到的失败写最小规则不写为假想情况预留的内容。REFACTOR——补洞对每条新说辞做四件事显式否定 合理化表一行 Red Flags 一条 description 补症状然后重测同一场景直到“Agent 在最大压力下仍选择正确选项”。写一份 CREATION-LOG像 CREATION-LOG.md 这样记录来源材料、提取决策、结构决策、加固要素、测试结果与迭代历史——它既是技能的“设计文档”也是下一个技能创建者可以直接模仿的范例。需要说明的适用前提这套方法的对象是纪律型技能TDD、验证、系统化调试等“有合规成本、可能被合理化掉”的技能而非纯参考型技能API 文档、语法指南testing-skills-with-subagents 明确列出了不该做压力测试的情形。对纪律型技能验证手段则是把带 3 压力叠加的 A/B/C 选项场景交给子代理执行并核对它的选择、引用与对诱惑的承认——这正是本文第五节四份测试用例所演示的内容。十、结语CREATION-LOG.md 用一份创建日志完整回答了“如何让 Agent 遵守纪律”这个工程问题答案不是把话说得更重而是把纪律做进结构里——必经的 Phase 1 门、单一假设规则、显式的失败处理分支、把每条捷径原样写出来的反模式清单以及“字面即精神”的基础原则并且这一切都必须通过无技能基线、多压力叠加的 A/B/C 场景测试来验收。日志中 4 项测试全部通过、未发现任何合理化说辞的结论加上技能目录中至今仍保留的测试原文与配套技术文档使得这份 2025-10-03 的创建日志既是 systematic-debugging 技能的历史档案也是 Superpowers 整个技能方法论的一份可直接执行的样板。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考