篇一让 AI 守规矩篇二让 AI 有记忆但还有一层问题没解决AI 完成同一类任务的做法本身是不稳定的。今天让它排查一个 bug它一头扎进代码里改明天类似的 bug 再来一次它换了另一套思路改完了事中间该有的验证环节可能压根没走。规则管的是不能做什么知识库管的是项目是什么但这类任务该按什么步骤做篇一篇二都没覆盖——这是工作方法论的问题。一、先说痛点1. 同一类任务做法每次都不一样排查一个线上问题AI 这次直接改了个 if 判断就说修好了下次遇到类似问题又去翻日志、加断点、写测试重现——不是说这些手段不对而是完全没有章法运气好蒙对了运气不好改出一个新 bug。方法论不固定结果的可靠性也就没法固定。2. 需求没搞清楚就直接写代码让 AI “加个退款功能”它经常直接开始写 Controller、Service写完一看才发现理解错了——退款到底是全额退还是支持部分退款退款后订单状态该怎么变这些没问清楚就动手返工成本比多问两句高得多。3. 做完了全靠 AI 自己说AI 说已经修复但没有真的跑一遍测试说已经验证过但验证的只是代码能编译不是逻辑对不对。宣称和事实之间没有强制的核对环节全靠人事后发现问题。4. 复杂任务缺少分解和检查点一个稍微复杂点的任务AI 容易一头做到尾、中途不回头看出了偏差往往到最后才暴露这时候已经改了一大堆代码想回退或者调整方向的成本已经很高了。二、解决方案把工作方法论打包成可复用的技能1. 每个技能只管一件事别塞进越写越长的规则文件篇一讲过规则文件不能无限膨胀工作方法论更是不该往里塞——“怎么做需求澄清”“怎么系统化排查 bug”“怎么写一份靠谱的实施计划”这些是完整的方法论不是一两条规则能表达清楚的。合理的做法是把每一套方法论独立打包成一个技能模块职责单一用的时候整个加载不用的时候不占上下文。2. 触发要自动化不能靠人记得去调用技能包如果需要人手动敲命令才能触发等于又把负担丢回给人。更好的设计是给每个技能配一段清晰的适用场景描述AI 自己根据当前对话判断该不该用这个技能——你说帮我加个功能它自己意识到这是需求不明确的场景主动触发先澄清的技能而不是等你明确说用一下需求澄清技能。3. 技能要能串联成流程而不是各自孤立单个技能解决单个环节但真正的价值在于能不能连起来先澄清需求澄清完自动进入写实施计划计划写完自动进入按计划执行、每个任务验证一次。技能之间知道我完成之后该交给谁才能撑起一整条从提需求到交付代码的流水线而不是一堆互不相关的独立工具。4. 别每个项目重新发明一遍直接复用现成的技能库这套需求澄清 → 写计划 → 执行 → 验证的方法论不是什么项目专属的秘密业界已经有沉淀好的实现。superpowersgithub.com/obra/superpowers作者 Jesse VincentMIT 协议就是一个真实的开源技能库把 TDD、系统化调试、需求澄清brainstorming、写实施计划、按计划执行、代码评审等一整套方法论打包成可安装的技能包覆盖 Claude Code、Codex、Cursor、Gemini CLI 等主流 AI 编码工具。下面教程直接用它落地。三、动手教程给 acme-order-service 装一套标准工作流程步骤 1一条指令安装在 Cursor 的 Agent 对话框里直接输入/add-plugin superpowers其他工具Claude Code、Codex 等也各有一条对应的安装指令装好之后不需要额外配置技能会在合适的场景自动触发。步骤 2看看技能长什么样装完之后打开插件目录会看到类似这样的结构superpowers/ └── skills/ ├── brainstorming/ │ └── SKILL.md ├── writing-plans/ │ └── SKILL.md ├── systematic-debugging/ │ ├── SKILL.md │ └── root-cause-tracing.md # 补充参考资料非必需 └── ...每个技能的核心就是一份SKILL.md最上面是 YAML frontmatter--- name: brainstorming description: You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. --- # Brainstorming Ideas Into Designs ...具体的方法论步骤description这一句话是关键——AI 会拿当前对话场景去匹配每个技能的description判断要不要主动用它不需要你手动点名。步骤 3触发一次真实流程在acme-order-service项目里跟 AI 说“帮我加一个退款功能”。装了 superpowers 之后正常情况下它不会立刻开始写代码而是先问退款是全额还是部分、退款后订单状态怎么流转——这就是brainstorming技能被自动触发的表现。等需求澄清完、你确认设计之后它才会转入写实施计划再进入实际编码。跟没装技能包时一上来就写对比一下能直接感受到差别。步骤 4写一个项目专属的自定义技能superpowers 提供的是通用方法论项目里如果有自己的专属流程也可以照着同样的格式自己写一个。比如给acme-order-service写一个最小的自定义技能--- name: acme-refund-check description: Use when implementing or modifying refund-related logic in acme-order-service, to make sure the order state transition rules are respected. --- # 退款功能开发检查清单 修改退款相关逻辑前必须 1. 确认退款是否会触发订单状态变更变更方向是否符合状态机的单向流转规则 2. 检查是否存在部分退款场景部分退款和全额退款的处理逻辑不能混用 3. 修改完成后运行订单模块的单元测试不允许仅凭代码编译通过就认为完成步骤 5验证是否真的会被自动触发新开一个对话清空上下文模拟下一次会话同样说给退款功能加一个新的校验规则观察 AI 是否主动提到了状态机流转规则或者部分退款场景——如果提到了说明这个自定义技能已经在生效如果没有通常是description写得不够具体需要让触发场景更明确。自动触发并不总是可靠——description匹配是概率性的上下文一复杂AI 可能直接开写代码。想稳定触发superpowers或某个具体技能在提示词里把场景说清楚必要时直接点名技能帮我给 acme-order-service 加一个退款功能。 先用 brainstorming 技能做需求澄清不要直接写代码。用 systematic-debugging 技能排查订单取消后库存没有释放。 先找根因确认之前再改代码。用 brainstorming 澄清需求确认设计后写实现计划writing-plans 但不要走 TDD改完 compile 通过就行。几条实用原则任务类型要对上description说加个功能 / 改行为比说帮我看看更容易命中brainstorming说排查 bug / 测试失败更容易命中systematic-debugging。点名比暗示稳using-superpowers技能要求 AI “只要有 1% 可能就要加载技能”但执行时仍会偷懒你在提示词里写上技能名等于把用户意图提到最高优先级superpowers 自己也规定用户明确指令 技能默认行为。自定义技能更要具体步骤 4 的acme-refund-check如果description只写 “refund”太宽写成 “when implementing or modifying refund-related logic in acme-order-service” 这种带项目名 动作的描述命中率会高很多。额外补充一直开着 superpowers 的代价以及怎么只用其中一部分superpowers 的设计目标是复杂功能从需求到交付走完整方法论不是给每个小改动都套同一套流程。插件常驻开着常见副作用包括现象原因Token 消耗明显变大每个技能被触发时会整份加载SKILL.md有的还带参考资料using-superpowers还要求只要有 1% 可能就先去查技能对话开头往往多好几轮技能探测。小改动拖很久改一行配置、修个 typo也可能被brainstorming拉去做需求澄清、写设计文档再被writing-plans/test-driven-development接上写计划、先写测试——对简单任务来说过重。测试流程你不想走时很难停技能链默认是澄清 → 计划 → TDD 实现 →verification-before-completion验证。你不想要其中某几步得在对话里明确说否则 AI 会按技能里的 HARD-GATE 硬走。子 agent / 多轮评审更耗时subagent-driven-development等技能会拆任务、派子 agent、做检查点——质量更好但等待时间和对话轮次都更长。不是让你卸掉 superpowers而是按任务分级用1. 复杂功能推荐全套新模块、跨多文件、业务规则不清——让技能链自然跑brainstorming → writing-plans → 执行 → 验证。提示词可以很简短让插件自己判断。2. 中等任务点名 裁剪在提示词里写清用哪些、不用哪些用户指令优先级最高用 brainstorming 先澄清退款规则设计确认后直接实现。 跳过 TDD不要写 design doc 到 docs/superpowers/specs/改完 compile 即可。3. 琐碎修改绕开或覆盖改注释、调配置、一行 bugfix——在AGENTS.md里加一条元规则和 superpowers 并存## 与 superpowers 的分工 - 改 typo、单行修复、纯配置调整直接改不触发 brainstorming / TDD / writing-plans - 新功能、行为变更、多文件重构必须走 brainstorming 澄清后再实现也可以在对话开头直接说“这是单行修复跳过 superpowers 全套流程。”4. 只想用 brainstorming三种做法从轻到重每次点名最省事先用 brainstorming 技能澄清完我确认再写代码不要自动进入 writing-plans项目规则收窄推荐在AGENTS.md写清楚哪些场景才允许触发后续技能等于给 superpowers 加刹车只拆一个技能进阶从superpowers/skills/brainstorming/把SKILL.md复制到你自己的技能目录或写成项目内.cursor/rules/规则不装整套插件——只带走需求澄清不带 TDD 和子 agent 流水线和篇二一样的结论工具是模块不是宗教。superpowers 的价值在于复杂任务有章可循简单任务强行走全流程反而浪费 token 和时间。用提示词点名、用AGENTS.md划边界、必要时只拆单个技能——三种方式可以组合按你和团队的节奏来。步骤 6跟规则、知识库分好工别互相重复篇一讲过统一入口这个原则在技能包这一层同样适用技能包里不要重复抄AGENTS.md里已经写过的命名规范和安全红线也不要把项目背景知识整段搬进技能文件——那些内容各自有该待的地方。技能包只负责做这类任务该按什么流程走具体的约束交给规则文件具体的项目事实交给知识库三者互相引用而不是互相重复。小结三篇下来实际上是在搭一个三层体系规则文件回答不能做什么知识库回答项目是什么、为什么这么设计技能包回答这类任务该按什么步骤做。三层各管一块谁也别越界重复谁的内容。下一篇会把这三层串起来走一次端到端的真实场景看它们具体是怎么协同工作的。
篇一让 AI 守规矩篇二让 AI 有记忆但还有一层问题没解决AI 完成同一类任务的做法本身是不稳定的。今天让它排查一个 bug它一头扎进代码里改明天类似的 bug 再来一次它换了另一套思路改完了事中间该有的验证环节可能压根没走。规则管的是不能做什么知识库管的是项目是什么但这类任务该按什么步骤做篇一篇二都没覆盖——这是工作方法论的问题。一、先说痛点1. 同一类任务做法每次都不一样排查一个线上问题AI 这次直接改了个 if 判断就说修好了下次遇到类似问题又去翻日志、加断点、写测试重现——不是说这些手段不对而是完全没有章法运气好蒙对了运气不好改出一个新 bug。方法论不固定结果的可靠性也就没法固定。2. 需求没搞清楚就直接写代码让 AI “加个退款功能”它经常直接开始写 Controller、Service写完一看才发现理解错了——退款到底是全额退还是支持部分退款退款后订单状态该怎么变这些没问清楚就动手返工成本比多问两句高得多。3. 做完了全靠 AI 自己说AI 说已经修复但没有真的跑一遍测试说已经验证过但验证的只是代码能编译不是逻辑对不对。宣称和事实之间没有强制的核对环节全靠人事后发现问题。4. 复杂任务缺少分解和检查点一个稍微复杂点的任务AI 容易一头做到尾、中途不回头看出了偏差往往到最后才暴露这时候已经改了一大堆代码想回退或者调整方向的成本已经很高了。二、解决方案把工作方法论打包成可复用的技能1. 每个技能只管一件事别塞进越写越长的规则文件篇一讲过规则文件不能无限膨胀工作方法论更是不该往里塞——“怎么做需求澄清”“怎么系统化排查 bug”“怎么写一份靠谱的实施计划”这些是完整的方法论不是一两条规则能表达清楚的。合理的做法是把每一套方法论独立打包成一个技能模块职责单一用的时候整个加载不用的时候不占上下文。2. 触发要自动化不能靠人记得去调用技能包如果需要人手动敲命令才能触发等于又把负担丢回给人。更好的设计是给每个技能配一段清晰的适用场景描述AI 自己根据当前对话判断该不该用这个技能——你说帮我加个功能它自己意识到这是需求不明确的场景主动触发先澄清的技能而不是等你明确说用一下需求澄清技能。3. 技能要能串联成流程而不是各自孤立单个技能解决单个环节但真正的价值在于能不能连起来先澄清需求澄清完自动进入写实施计划计划写完自动进入按计划执行、每个任务验证一次。技能之间知道我完成之后该交给谁才能撑起一整条从提需求到交付代码的流水线而不是一堆互不相关的独立工具。4. 别每个项目重新发明一遍直接复用现成的技能库这套需求澄清 → 写计划 → 执行 → 验证的方法论不是什么项目专属的秘密业界已经有沉淀好的实现。superpowersgithub.com/obra/superpowers作者 Jesse VincentMIT 协议就是一个真实的开源技能库把 TDD、系统化调试、需求澄清brainstorming、写实施计划、按计划执行、代码评审等一整套方法论打包成可安装的技能包覆盖 Claude Code、Codex、Cursor、Gemini CLI 等主流 AI 编码工具。下面教程直接用它落地。三、动手教程给 acme-order-service 装一套标准工作流程步骤 1一条指令安装在 Cursor 的 Agent 对话框里直接输入/add-plugin superpowers其他工具Claude Code、Codex 等也各有一条对应的安装指令装好之后不需要额外配置技能会在合适的场景自动触发。步骤 2看看技能长什么样装完之后打开插件目录会看到类似这样的结构superpowers/ └── skills/ ├── brainstorming/ │ └── SKILL.md ├── writing-plans/ │ └── SKILL.md ├── systematic-debugging/ │ ├── SKILL.md │ └── root-cause-tracing.md # 补充参考资料非必需 └── ...每个技能的核心就是一份SKILL.md最上面是 YAML frontmatter--- name: brainstorming description: You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. --- # Brainstorming Ideas Into Designs ...具体的方法论步骤description这一句话是关键——AI 会拿当前对话场景去匹配每个技能的description判断要不要主动用它不需要你手动点名。步骤 3触发一次真实流程在acme-order-service项目里跟 AI 说“帮我加一个退款功能”。装了 superpowers 之后正常情况下它不会立刻开始写代码而是先问退款是全额还是部分、退款后订单状态怎么流转——这就是brainstorming技能被自动触发的表现。等需求澄清完、你确认设计之后它才会转入写实施计划再进入实际编码。跟没装技能包时一上来就写对比一下能直接感受到差别。步骤 4写一个项目专属的自定义技能superpowers 提供的是通用方法论项目里如果有自己的专属流程也可以照着同样的格式自己写一个。比如给acme-order-service写一个最小的自定义技能--- name: acme-refund-check description: Use when implementing or modifying refund-related logic in acme-order-service, to make sure the order state transition rules are respected. --- # 退款功能开发检查清单 修改退款相关逻辑前必须 1. 确认退款是否会触发订单状态变更变更方向是否符合状态机的单向流转规则 2. 检查是否存在部分退款场景部分退款和全额退款的处理逻辑不能混用 3. 修改完成后运行订单模块的单元测试不允许仅凭代码编译通过就认为完成步骤 5验证是否真的会被自动触发新开一个对话清空上下文模拟下一次会话同样说给退款功能加一个新的校验规则观察 AI 是否主动提到了状态机流转规则或者部分退款场景——如果提到了说明这个自定义技能已经在生效如果没有通常是description写得不够具体需要让触发场景更明确。自动触发并不总是可靠——description匹配是概率性的上下文一复杂AI 可能直接开写代码。想稳定触发superpowers或某个具体技能在提示词里把场景说清楚必要时直接点名技能帮我给 acme-order-service 加一个退款功能。 先用 brainstorming 技能做需求澄清不要直接写代码。用 systematic-debugging 技能排查订单取消后库存没有释放。 先找根因确认之前再改代码。用 brainstorming 澄清需求确认设计后写实现计划writing-plans 但不要走 TDD改完 compile 通过就行。几条实用原则任务类型要对上description说加个功能 / 改行为比说帮我看看更容易命中brainstorming说排查 bug / 测试失败更容易命中systematic-debugging。点名比暗示稳using-superpowers技能要求 AI “只要有 1% 可能就要加载技能”但执行时仍会偷懒你在提示词里写上技能名等于把用户意图提到最高优先级superpowers 自己也规定用户明确指令 技能默认行为。自定义技能更要具体步骤 4 的acme-refund-check如果description只写 “refund”太宽写成 “when implementing or modifying refund-related logic in acme-order-service” 这种带项目名 动作的描述命中率会高很多。额外补充一直开着 superpowers 的代价以及怎么只用其中一部分superpowers 的设计目标是复杂功能从需求到交付走完整方法论不是给每个小改动都套同一套流程。插件常驻开着常见副作用包括现象原因Token 消耗明显变大每个技能被触发时会整份加载SKILL.md有的还带参考资料using-superpowers还要求只要有 1% 可能就先去查技能对话开头往往多好几轮技能探测。小改动拖很久改一行配置、修个 typo也可能被brainstorming拉去做需求澄清、写设计文档再被writing-plans/test-driven-development接上写计划、先写测试——对简单任务来说过重。测试流程你不想走时很难停技能链默认是澄清 → 计划 → TDD 实现 →verification-before-completion验证。你不想要其中某几步得在对话里明确说否则 AI 会按技能里的 HARD-GATE 硬走。子 agent / 多轮评审更耗时subagent-driven-development等技能会拆任务、派子 agent、做检查点——质量更好但等待时间和对话轮次都更长。不是让你卸掉 superpowers而是按任务分级用1. 复杂功能推荐全套新模块、跨多文件、业务规则不清——让技能链自然跑brainstorming → writing-plans → 执行 → 验证。提示词可以很简短让插件自己判断。2. 中等任务点名 裁剪在提示词里写清用哪些、不用哪些用户指令优先级最高用 brainstorming 先澄清退款规则设计确认后直接实现。 跳过 TDD不要写 design doc 到 docs/superpowers/specs/改完 compile 即可。3. 琐碎修改绕开或覆盖改注释、调配置、一行 bugfix——在AGENTS.md里加一条元规则和 superpowers 并存## 与 superpowers 的分工 - 改 typo、单行修复、纯配置调整直接改不触发 brainstorming / TDD / writing-plans - 新功能、行为变更、多文件重构必须走 brainstorming 澄清后再实现也可以在对话开头直接说“这是单行修复跳过 superpowers 全套流程。”4. 只想用 brainstorming三种做法从轻到重每次点名最省事先用 brainstorming 技能澄清完我确认再写代码不要自动进入 writing-plans项目规则收窄推荐在AGENTS.md写清楚哪些场景才允许触发后续技能等于给 superpowers 加刹车只拆一个技能进阶从superpowers/skills/brainstorming/把SKILL.md复制到你自己的技能目录或写成项目内.cursor/rules/规则不装整套插件——只带走需求澄清不带 TDD 和子 agent 流水线和篇二一样的结论工具是模块不是宗教。superpowers 的价值在于复杂任务有章可循简单任务强行走全流程反而浪费 token 和时间。用提示词点名、用AGENTS.md划边界、必要时只拆单个技能——三种方式可以组合按你和团队的节奏来。步骤 6跟规则、知识库分好工别互相重复篇一讲过统一入口这个原则在技能包这一层同样适用技能包里不要重复抄AGENTS.md里已经写过的命名规范和安全红线也不要把项目背景知识整段搬进技能文件——那些内容各自有该待的地方。技能包只负责做这类任务该按什么流程走具体的约束交给规则文件具体的项目事实交给知识库三者互相引用而不是互相重复。小结三篇下来实际上是在搭一个三层体系规则文件回答不能做什么知识库回答项目是什么、为什么这么设计技能包回答这类任务该按什么步骤做。三层各管一块谁也别越界重复谁的内容。下一篇会把这三层串起来走一次端到端的真实场景看它们具体是怎么协同工作的。
)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
