个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化Cloud Code / Claude Code 装了近百个 Skill 后我只留下这 3 个Superpowers、Planning with Files、Rough Lop 实战经验1. 问题背景与写作目标2. 为什么不是 Skill 越多越好3. 三个 Skill 解决的核心问题4. Superpowers先头脑风暴再动手写代码5. Planning with Files让长任务不失忆6. Rough Lop防止 AI 半路收工7. 完成条件怎么写AI 才不容易糊弄过去8. 三个 Skill 的组合使用流程9. 效果验证与对比10. 常见问题与踩坑记录10.1 Superpowers 要不要全部子技能都打开10.2 Planning with Files 会不会显得多此一举10.3 Rough Lop 会不会让 AI 一直循环执行10.4 这三个 Skill 能不能替代人工代码审查10.5 为什么我用了这些 Skill 还是觉得效果一般11. 总结与进阶建议1. 问题背景与写作目标最近半年我围绕 Cloud Code / Claude Code 安装和尝试过近百个 Skill。刚开始的时候我也以为 Skill 越多越好觉得多装一些总能覆盖更多场景。实际用下来才发现这个想法是错的。真正能提升效率的 Skill不是功能最多的而是能稳定改变工作流的。很多 Skill 看起来很酷第一次用也有新鲜感但真正写项目、改代码、做长任务的时候它们并不能减少返工也不能让 AI 更可靠。最后我长期保留下来的只有三个Superpowers、Planning with Files、Rough Lop。它们分别解决三个核心问题开工前想不清楚、长任务中途失忆、AI 干到一半就想收工。这篇文章不是 Skill 清单堆砌而是一次真实使用后的筛选复盘为什么只留下这三个它们分别解决什么问题怎么用才不会浪费上下文以及哪些坑必须避开。先把最终结论放在最前面近百个 Skill 里真正能稳定提升效率的通常不是那些“看起来很全”的而是能让 AI 工作流变得更清晰、更可控、更可验证的。从图中可以看出最终留下的三个 Skill 对应的是三个不同阶段Superpowers 负责开工前想清楚Planning with Files 负责执行中不丢状态Rough Lop 负责收尾时不放水。这三个环节连起来才是真正提高效率的关键。2. 为什么不是 Skill 越多越好很多人第一次接触 Skill会陷入一个误区看到好像有用就装看到别人推荐就开。最后 Skill 越装越多上下文越来越重真正写代码时反而变慢。Skill 全开不是增强能力很多时候是在浪费上下文。尤其是一些包含大量子技能、模板、规则、提示词的 Skill如果没有明确使用场景它们会把模型注意力分散到很多不必要的方向。我现在判断一个 Skill 是否值得长期保留只看三个标准判断标准具体含义是否值得保留是否高频每周是否会反复使用高频才值得常驻是否减少返工是否能明显减少反复改需求、反复推倒重来能减少返工才有价值是否让结果可验证是否能让任务状态、完成标准、验收结果更清楚可验证才适合长任务我的建议是不要追求 Skill 数量要追求 Skill 对工作流的改造能力。如果一个 Skill 只是让提示词更花哨但不能减少返工、不能保存状态、不能约束完成标准那它就不应该常驻。3. 三个 Skill 解决的核心问题这三个 Skill 不是并列堆在一起用的而是形成一个完整链路。更准确地说它们分别作用在 AI 编程任务的三个阶段。未达到已达到开始一个复杂任务Superpowers Brainstorming先反问需求 生成设计思路Planning with Files把计划写入本地文件AI 按步骤执行并勾选进度Rough Lop是否达到完成标准拦截退出 继续执行任务闭环完成这套流程的本质是先把需求想清楚再把计划落到文件最后用完成标准约束 AI 不要提前收工。如果没有 SuperpowersAI 容易一上来就写代码结果方向错了。如果没有 Planning with Files长任务做到一半容易丢上下文。如果没有 Rough LopAI 很容易写到 70% 就说“基础框架已经搭好”。所以这三个 Skill 的价值不是单个看有多强而是组合起来能形成闭环。4. Superpowers先头脑风暴再动手写代码Superpowers 是最明显改变我使用习惯的一个 Skill。以前我用 Claude 写代码经常是直接把需求丢过去“帮我写一个用户模块”“帮我做一个后台管理页面”“帮我重构这个项目”。这种做法看起来省事实际非常危险。因为 AI 很可能马上开始写代码但它并没有真正理解你的业务目标、边界条件、数据结构、并发风险、接口约束和验收标准。现在我的习惯是复杂任务开工前先跑一遍 Brainstorming。这个过程会让 Claude 反过来问我问题例如目标用户是谁核心需求是什么数据库怎么选并发怎么处理成功标准是什么Superpowers 最有价值的地方不是帮你多写几行代码而是先把“你自己都没想清楚的问题”暴露出来。从图中可以看出Superpowers 的核心不是直接生成代码而是先通过 Brainstorming 把需求、用户画像、约束条件和成功标准整理出来。最终生成设计文档后再进入编码阶段返工概率会明显下降。但 Superpowers 有一个坑它包含 20 多个子技能千万别全开。我实际长期使用的主要是 Brainstorming其他子技能按需加载。否则它会占用大量上下文让模型在真正编码时注意力变散。我更推荐下面这种使用方式任务开始前 1. 先运行 Brainstorming 2. 让 Claude 反问需求、边界、风险和验收标准 3. 把讨论结果整理成设计文档 4. 确认设计方向后再进入代码实现一句话总结Superpowers 不是让 AI 更快开工而是让 AI 不要错误开工。5. Planning with Files让长任务不失忆第二个真正有价值的 Skill 是 Planning with Files。它解决的是一个非常真实的问题AI 做复杂任务做到一半会失忆。这种情况很多人都遇到过。你和 Claude 聊了半小时前面已经讨论完需求、计划、接口、模块拆分结果上下文一压缩它突然来一句“好的让我们开始吧。”然后把之前做过的事情又从头来一遍。问题的根因不是 AI 不努力而是长任务的状态如果只存在对话上下文里就天然不稳定。上下文会压缩会丢失会被后续内容覆盖。Planning with Files 的思路很简单不要把计划只放在“脑子里”而是写到本地文件里。比如创建一个 my-plan.md每完成一步就在文件里打勾。对于复杂任务来说本地计划文件就是任务的“外部记忆”。从图中可以看出Planning with Files 的重点是把计划拆成可勾选步骤并保存在本地文件中。即使上下文被清空AI 只要重新读取计划文件就能知道当前做到哪一步、哪些任务已完成、哪些任务还没开始。这个思路跟很多稳定的长任务系统类似不要相信短期记忆要相信可读取、可检查、可恢复的状态文件。一个比较合理的计划文件可以长这样# 用户模块重构计划 ## 目标 完成用户登录、注册、权限校验和基础资料管理。 ## 任务清单 - [x] 分析现有用户表结构 - [x] 设计登录接口 - [ ] 实现注册接口 - [ ] 增加权限校验中间件 - [ ] 编写接口测试 - [ ] 更新 README API 文档 ## 当前进度 正在实现注册接口。 ## 注意事项 - 不修改已有用户 ID 规则 - 密码必须加密存储 - 接口返回结构保持兼容推荐你让 Claude 每完成一步都更新计划文件而不是等全部完成后再总结。这样中途断掉也不可怕因为任务状态已经落到文件里了。6. Rough Lop防止 AI 半路收工第三个 Skill 是 Rough Lop。我更愿意把它叫做“监工”。因为它解决的问题非常具体Claude 有时候会写到一半就想提前下班。典型话术是这样的基础框架已经搭好了你可以在此基础上继续完善。翻译成人话就是活没干完但我先收工了。Rough Lop 的价值在于通过 Hook 拦截 Claude 的退出动作。当 Claude 认为任务结束时Hook 会检查它是否真的满足完成条件。如果没有达到标准就让它继续执行。它不是让 AI 无限工作而是把“是否完成”从 AI 自我感觉变成可检查的验收条件。Rough Lop 适合用在 CRUD 模块、文档补全、测试补齐、重构收尾这类任务上。尤其是你已经明确知道完成标准时它非常有用。从图中可以看出Rough Lop 的核心链路是AI 尝试退出Hook 拦截退出检查完成标准不满足就继续执行直到任务真正闭环。这个 Skill 的价值不在“多写代码”而在防止任务停在半成品状态。但 Rough Lop 不是万能的。完成条件如果写得模糊它也拦不住 AI 摸鱼。比如“做完用户模块”这种说法太虚AI 很容易自我说服“基础功能已经有了所以我完成了。”更合理的写法应该是完成登录接口接口可正常返回 token 完成注册接口重复用户名需要返回明确错误 所有用户模块接口测试通过 README 中补充用户模块 API 文档 运行测试命令后无失败用例。一句话总结Rough Lop 真正有效的前提是你先把“完成”定义清楚。7. 完成条件怎么写AI 才不容易糊弄过去这三个 Skill 最后都会落到同一个问题上你有没有把任务说清楚。很多人抱怨 AI 写代码不靠谱其实有一部分原因是自己给的目标不够具体。比如帮我做一个用户模块。 优化一下这个页面。 把这个功能完善一下。 修一下这个问题。这些话对人类同事来说都不够清楚对 AI 更不够清楚。AI 会根据自己的理解补全大量细节而这些细节很可能和你的真实预期不一致。更推荐的方式是把目标写成“可验证条件”。什么叫可验证就是执行完之后你能用测试、文件、接口、页面或命令判断它到底有没有完成。完成标准一定要从模糊描述改成可检查条目。从图中可以看出左侧的模糊目标很容易让 AI 自我解释而右侧的具体目标更适合验收。接口可用、测试通过、README 完整这些都是可以检查的条件。目标越具体AI 越不容易把半成品说成完成。我建议你以后写任务时直接使用下面这个格式## 任务目标 说明要完成什么功能不超过 3 句话。 ## 完成标准 - [ ] 接口 A 可正常调用并返回指定字段 - [ ] 异常场景有明确错误提示 - [ ] 单元测试或接口测试通过 - [ ] README 补充使用说明 - [ ] 不破坏原有功能 ## 不做什么 - 不重构无关模块 - 不修改数据库字段名 - 不引入额外大型依赖“不做什么”也很重要。因为 AI 很容易扩大任务范围看到一个问题就顺手改另一个模块。边界不写清楚任务就容易失控。8. 三个 Skill 的组合使用流程如果把这三个 Skill 单独看它们分别有价值但真正高效的用法是把它们组合成一个固定工作流。我的推荐流程如下阶段使用 Skill目标开工前Superpowers / Brainstorming先把需求、边界、风险问清楚执行中Planning with Files把计划写入本地文件持续更新状态收尾时Rough Lop用完成标准检查是否真的做完验收时人工复核跑测试、看文档、检查边界条件注意Skill 不能替代你的判断。它们只是让 AI 更有结构地工作而不是让你完全放弃审查。尤其是涉及数据库、权限、支付、生产脚本、批量删除、系统配置这类高风险操作时人必须复核。一个比较完整的使用流程可以这样写1. 用 Brainstorming 先让 AI 反问需求 2. 根据问答结果生成设计文档 3. 把设计拆成计划文件 4. AI 每完成一步更新计划文件 5. Rough Lop 根据完成标准拦截提前退出 6. 最后人工跑测试、检查 README、验证边界场景真正的效率提升不是少打几个字而是少返工、少失忆、少半成品。9. 效果验证与对比使用这三个 Skill 前后最大的变化不是“AI 写得更快”而是工作过程更可控。以前的问题主要集中在需求跑偏、上下文丢失、任务半成品三个方面。对比项没有使用这三个 Skill使用后开工方式直接丢需求让 AI 猜先 Brainstorming需求更清楚计划管理计划只存在对话里计划写进本地文件长任务稳定性上下文压缩后容易重来重新读取计划即可继续收尾质量AI 容易提前说完成Hook 检查完成标准返工概率经常方向跑偏前期问题暴露更多验收方式靠感觉判断靠测试、README、接口状态判断验证一个 Skill 是否真的有用不要看它第一次使用时是否惊艳而要看它连续使用一周后是否减少了返工和遗漏。我建议你用下面这几个问题判断1. 它是否减少了需求反复解释 2. 它是否让长任务中断后更容易恢复 3. 它是否让 AI 更少生成半成品 4. 它是否让最终结果更容易验收 5. 它是否值得长期占用上下文如果一个 Skill 不能通过这些问题大概率只是“看起来有用”。10. 常见问题与踩坑记录10.1 Superpowers 要不要全部子技能都打开不建议。Superpowers 包含多个子技能但常驻全开会浪费上下文。我的建议是只高频使用 Brainstorming其他子技能按任务需要临时加载。10.2 Planning with Files 会不会显得多此一举短任务可能没必要。但只要任务超过 30 分钟或者涉及多个文件、多个阶段、多个接口本地计划文件就很有价值。它解决的是状态持久化问题不是单纯写文档。10.3 Rough Lop 会不会让 AI 一直循环执行如果完成标准写得不合理有这个风险。所以完成条件不能写成“尽量优化”“继续完善”“做到最好”这种无法判断的句子。完成条件必须可验证否则 Hook 也会失去意义。10.4 这三个 Skill 能不能替代人工代码审查不能。它们能提升任务执行质量但不能替代你对代码结构、安全风险、业务逻辑和生产影响的判断。尤其是涉及权限、数据库迁移、删除数据、自动化脚本时人工审查仍然必须保留。10.5 为什么我用了这些 Skill 还是觉得效果一般大概率不是 Skill 的问题而是任务描述仍然模糊。你可以回头检查三个地方需求有没有说清楚计划有没有写进文件完成标准有没有可验证。如果这三点都没有做好Skill 也救不了一个模糊任务。11. 总结与进阶建议这半年装了近百个 Skill 后我最大的体会是真正提升效率的不是 Skill 数量而是工作流质量。Superpowers 解决的是开工前想不清楚的问题Planning with Files 解决的是长任务状态丢失的问题Rough Lop 解决的是 AI 半路收工的问题。三个 Skill 对应的是三个关键阶段想清楚、记得住、做到底。如果你只想先尝试一个我建议先从 Planning with Files 开始。因为它最稳定最容易看到收益也最不容易干扰上下文。等你习惯了本地计划文件再加入 Superpowers 做前期设计最后用 Rough Lop 做收尾验收。AI 编程不是把需求扔给模型就结束。真正可靠的做法是把需求拆清楚把计划写下来把完成标准定义具体然后让 AI 在这个边界内工作。一句话总结别指望 Skill 替你思考。真正有效的 Skill是逼你和 AI 一起把事情想清楚、做完整、验收明白。返回顶部
Cloud Code / Claude Code 装了近百个 Skill 后，我只留下这 3 个：Superpowers、Planning with Files、Rough Lop 实战经验
发布时间：2026/6/7 13:12:28
个人主页杨利杰YJlio❄️个人专栏《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》《微信助手》 《锤子助手》 《Python》 《Kali Linux》《那些年未解决的Windows疑难杂症》让复杂的事情更简单让重复的工作自动化Cloud Code / Claude Code 装了近百个 Skill 后我只留下这 3 个Superpowers、Planning with Files、Rough Lop 实战经验1. 问题背景与写作目标2. 为什么不是 Skill 越多越好3. 三个 Skill 解决的核心问题4. Superpowers先头脑风暴再动手写代码5. Planning with Files让长任务不失忆6. Rough Lop防止 AI 半路收工7. 完成条件怎么写AI 才不容易糊弄过去8. 三个 Skill 的组合使用流程9. 效果验证与对比10. 常见问题与踩坑记录10.1 Superpowers 要不要全部子技能都打开10.2 Planning with Files 会不会显得多此一举10.3 Rough Lop 会不会让 AI 一直循环执行10.4 这三个 Skill 能不能替代人工代码审查10.5 为什么我用了这些 Skill 还是觉得效果一般11. 总结与进阶建议1. 问题背景与写作目标最近半年我围绕 Cloud Code / Claude Code 安装和尝试过近百个 Skill。刚开始的时候我也以为 Skill 越多越好觉得多装一些总能覆盖更多场景。实际用下来才发现这个想法是错的。真正能提升效率的 Skill不是功能最多的而是能稳定改变工作流的。很多 Skill 看起来很酷第一次用也有新鲜感但真正写项目、改代码、做长任务的时候它们并不能减少返工也不能让 AI 更可靠。最后我长期保留下来的只有三个Superpowers、Planning with Files、Rough Lop。它们分别解决三个核心问题开工前想不清楚、长任务中途失忆、AI 干到一半就想收工。这篇文章不是 Skill 清单堆砌而是一次真实使用后的筛选复盘为什么只留下这三个它们分别解决什么问题怎么用才不会浪费上下文以及哪些坑必须避开。先把最终结论放在最前面近百个 Skill 里真正能稳定提升效率的通常不是那些“看起来很全”的而是能让 AI 工作流变得更清晰、更可控、更可验证的。从图中可以看出最终留下的三个 Skill 对应的是三个不同阶段Superpowers 负责开工前想清楚Planning with Files 负责执行中不丢状态Rough Lop 负责收尾时不放水。这三个环节连起来才是真正提高效率的关键。2. 为什么不是 Skill 越多越好很多人第一次接触 Skill会陷入一个误区看到好像有用就装看到别人推荐就开。最后 Skill 越装越多上下文越来越重真正写代码时反而变慢。Skill 全开不是增强能力很多时候是在浪费上下文。尤其是一些包含大量子技能、模板、规则、提示词的 Skill如果没有明确使用场景它们会把模型注意力分散到很多不必要的方向。我现在判断一个 Skill 是否值得长期保留只看三个标准判断标准具体含义是否值得保留是否高频每周是否会反复使用高频才值得常驻是否减少返工是否能明显减少反复改需求、反复推倒重来能减少返工才有价值是否让结果可验证是否能让任务状态、完成标准、验收结果更清楚可验证才适合长任务我的建议是不要追求 Skill 数量要追求 Skill 对工作流的改造能力。如果一个 Skill 只是让提示词更花哨但不能减少返工、不能保存状态、不能约束完成标准那它就不应该常驻。3. 三个 Skill 解决的核心问题这三个 Skill 不是并列堆在一起用的而是形成一个完整链路。更准确地说它们分别作用在 AI 编程任务的三个阶段。未达到已达到开始一个复杂任务Superpowers Brainstorming先反问需求 生成设计思路Planning with Files把计划写入本地文件AI 按步骤执行并勾选进度Rough Lop是否达到完成标准拦截退出 继续执行任务闭环完成这套流程的本质是先把需求想清楚再把计划落到文件最后用完成标准约束 AI 不要提前收工。如果没有 SuperpowersAI 容易一上来就写代码结果方向错了。如果没有 Planning with Files长任务做到一半容易丢上下文。如果没有 Rough LopAI 很容易写到 70% 就说“基础框架已经搭好”。所以这三个 Skill 的价值不是单个看有多强而是组合起来能形成闭环。4. Superpowers先头脑风暴再动手写代码Superpowers 是最明显改变我使用习惯的一个 Skill。以前我用 Claude 写代码经常是直接把需求丢过去“帮我写一个用户模块”“帮我做一个后台管理页面”“帮我重构这个项目”。这种做法看起来省事实际非常危险。因为 AI 很可能马上开始写代码但它并没有真正理解你的业务目标、边界条件、数据结构、并发风险、接口约束和验收标准。现在我的习惯是复杂任务开工前先跑一遍 Brainstorming。这个过程会让 Claude 反过来问我问题例如目标用户是谁核心需求是什么数据库怎么选并发怎么处理成功标准是什么Superpowers 最有价值的地方不是帮你多写几行代码而是先把“你自己都没想清楚的问题”暴露出来。从图中可以看出Superpowers 的核心不是直接生成代码而是先通过 Brainstorming 把需求、用户画像、约束条件和成功标准整理出来。最终生成设计文档后再进入编码阶段返工概率会明显下降。但 Superpowers 有一个坑它包含 20 多个子技能千万别全开。我实际长期使用的主要是 Brainstorming其他子技能按需加载。否则它会占用大量上下文让模型在真正编码时注意力变散。我更推荐下面这种使用方式任务开始前 1. 先运行 Brainstorming 2. 让 Claude 反问需求、边界、风险和验收标准 3. 把讨论结果整理成设计文档 4. 确认设计方向后再进入代码实现一句话总结Superpowers 不是让 AI 更快开工而是让 AI 不要错误开工。5. Planning with Files让长任务不失忆第二个真正有价值的 Skill 是 Planning with Files。它解决的是一个非常真实的问题AI 做复杂任务做到一半会失忆。这种情况很多人都遇到过。你和 Claude 聊了半小时前面已经讨论完需求、计划、接口、模块拆分结果上下文一压缩它突然来一句“好的让我们开始吧。”然后把之前做过的事情又从头来一遍。问题的根因不是 AI 不努力而是长任务的状态如果只存在对话上下文里就天然不稳定。上下文会压缩会丢失会被后续内容覆盖。Planning with Files 的思路很简单不要把计划只放在“脑子里”而是写到本地文件里。比如创建一个 my-plan.md每完成一步就在文件里打勾。对于复杂任务来说本地计划文件就是任务的“外部记忆”。从图中可以看出Planning with Files 的重点是把计划拆成可勾选步骤并保存在本地文件中。即使上下文被清空AI 只要重新读取计划文件就能知道当前做到哪一步、哪些任务已完成、哪些任务还没开始。这个思路跟很多稳定的长任务系统类似不要相信短期记忆要相信可读取、可检查、可恢复的状态文件。一个比较合理的计划文件可以长这样# 用户模块重构计划 ## 目标 完成用户登录、注册、权限校验和基础资料管理。 ## 任务清单 - [x] 分析现有用户表结构 - [x] 设计登录接口 - [ ] 实现注册接口 - [ ] 增加权限校验中间件 - [ ] 编写接口测试 - [ ] 更新 README API 文档 ## 当前进度 正在实现注册接口。 ## 注意事项 - 不修改已有用户 ID 规则 - 密码必须加密存储 - 接口返回结构保持兼容推荐你让 Claude 每完成一步都更新计划文件而不是等全部完成后再总结。这样中途断掉也不可怕因为任务状态已经落到文件里了。6. Rough Lop防止 AI 半路收工第三个 Skill 是 Rough Lop。我更愿意把它叫做“监工”。因为它解决的问题非常具体Claude 有时候会写到一半就想提前下班。典型话术是这样的基础框架已经搭好了你可以在此基础上继续完善。翻译成人话就是活没干完但我先收工了。Rough Lop 的价值在于通过 Hook 拦截 Claude 的退出动作。当 Claude 认为任务结束时Hook 会检查它是否真的满足完成条件。如果没有达到标准就让它继续执行。它不是让 AI 无限工作而是把“是否完成”从 AI 自我感觉变成可检查的验收条件。Rough Lop 适合用在 CRUD 模块、文档补全、测试补齐、重构收尾这类任务上。尤其是你已经明确知道完成标准时它非常有用。从图中可以看出Rough Lop 的核心链路是AI 尝试退出Hook 拦截退出检查完成标准不满足就继续执行直到任务真正闭环。这个 Skill 的价值不在“多写代码”而在防止任务停在半成品状态。但 Rough Lop 不是万能的。完成条件如果写得模糊它也拦不住 AI 摸鱼。比如“做完用户模块”这种说法太虚AI 很容易自我说服“基础功能已经有了所以我完成了。”更合理的写法应该是完成登录接口接口可正常返回 token 完成注册接口重复用户名需要返回明确错误 所有用户模块接口测试通过 README 中补充用户模块 API 文档 运行测试命令后无失败用例。一句话总结Rough Lop 真正有效的前提是你先把“完成”定义清楚。7. 完成条件怎么写AI 才不容易糊弄过去这三个 Skill 最后都会落到同一个问题上你有没有把任务说清楚。很多人抱怨 AI 写代码不靠谱其实有一部分原因是自己给的目标不够具体。比如帮我做一个用户模块。 优化一下这个页面。 把这个功能完善一下。 修一下这个问题。这些话对人类同事来说都不够清楚对 AI 更不够清楚。AI 会根据自己的理解补全大量细节而这些细节很可能和你的真实预期不一致。更推荐的方式是把目标写成“可验证条件”。什么叫可验证就是执行完之后你能用测试、文件、接口、页面或命令判断它到底有没有完成。完成标准一定要从模糊描述改成可检查条目。从图中可以看出左侧的模糊目标很容易让 AI 自我解释而右侧的具体目标更适合验收。接口可用、测试通过、README 完整这些都是可以检查的条件。目标越具体AI 越不容易把半成品说成完成。我建议你以后写任务时直接使用下面这个格式## 任务目标 说明要完成什么功能不超过 3 句话。 ## 完成标准 - [ ] 接口 A 可正常调用并返回指定字段 - [ ] 异常场景有明确错误提示 - [ ] 单元测试或接口测试通过 - [ ] README 补充使用说明 - [ ] 不破坏原有功能 ## 不做什么 - 不重构无关模块 - 不修改数据库字段名 - 不引入额外大型依赖“不做什么”也很重要。因为 AI 很容易扩大任务范围看到一个问题就顺手改另一个模块。边界不写清楚任务就容易失控。8. 三个 Skill 的组合使用流程如果把这三个 Skill 单独看它们分别有价值但真正高效的用法是把它们组合成一个固定工作流。我的推荐流程如下阶段使用 Skill目标开工前Superpowers / Brainstorming先把需求、边界、风险问清楚执行中Planning with Files把计划写入本地文件持续更新状态收尾时Rough Lop用完成标准检查是否真的做完验收时人工复核跑测试、看文档、检查边界条件注意Skill 不能替代你的判断。它们只是让 AI 更有结构地工作而不是让你完全放弃审查。尤其是涉及数据库、权限、支付、生产脚本、批量删除、系统配置这类高风险操作时人必须复核。一个比较完整的使用流程可以这样写1. 用 Brainstorming 先让 AI 反问需求 2. 根据问答结果生成设计文档 3. 把设计拆成计划文件 4. AI 每完成一步更新计划文件 5. Rough Lop 根据完成标准拦截提前退出 6. 最后人工跑测试、检查 README、验证边界场景真正的效率提升不是少打几个字而是少返工、少失忆、少半成品。9. 效果验证与对比使用这三个 Skill 前后最大的变化不是“AI 写得更快”而是工作过程更可控。以前的问题主要集中在需求跑偏、上下文丢失、任务半成品三个方面。对比项没有使用这三个 Skill使用后开工方式直接丢需求让 AI 猜先 Brainstorming需求更清楚计划管理计划只存在对话里计划写进本地文件长任务稳定性上下文压缩后容易重来重新读取计划即可继续收尾质量AI 容易提前说完成Hook 检查完成标准返工概率经常方向跑偏前期问题暴露更多验收方式靠感觉判断靠测试、README、接口状态判断验证一个 Skill 是否真的有用不要看它第一次使用时是否惊艳而要看它连续使用一周后是否减少了返工和遗漏。我建议你用下面这几个问题判断1. 它是否减少了需求反复解释 2. 它是否让长任务中断后更容易恢复 3. 它是否让 AI 更少生成半成品 4. 它是否让最终结果更容易验收 5. 它是否值得长期占用上下文如果一个 Skill 不能通过这些问题大概率只是“看起来有用”。10. 常见问题与踩坑记录10.1 Superpowers 要不要全部子技能都打开不建议。Superpowers 包含多个子技能但常驻全开会浪费上下文。我的建议是只高频使用 Brainstorming其他子技能按任务需要临时加载。10.2 Planning with Files 会不会显得多此一举短任务可能没必要。但只要任务超过 30 分钟或者涉及多个文件、多个阶段、多个接口本地计划文件就很有价值。它解决的是状态持久化问题不是单纯写文档。10.3 Rough Lop 会不会让 AI 一直循环执行如果完成标准写得不合理有这个风险。所以完成条件不能写成“尽量优化”“继续完善”“做到最好”这种无法判断的句子。完成条件必须可验证否则 Hook 也会失去意义。10.4 这三个 Skill 能不能替代人工代码审查不能。它们能提升任务执行质量但不能替代你对代码结构、安全风险、业务逻辑和生产影响的判断。尤其是涉及权限、数据库迁移、删除数据、自动化脚本时人工审查仍然必须保留。10.5 为什么我用了这些 Skill 还是觉得效果一般大概率不是 Skill 的问题而是任务描述仍然模糊。你可以回头检查三个地方需求有没有说清楚计划有没有写进文件完成标准有没有可验证。如果这三点都没有做好Skill 也救不了一个模糊任务。11. 总结与进阶建议这半年装了近百个 Skill 后我最大的体会是真正提升效率的不是 Skill 数量而是工作流质量。Superpowers 解决的是开工前想不清楚的问题Planning with Files 解决的是长任务状态丢失的问题Rough Lop 解决的是 AI 半路收工的问题。三个 Skill 对应的是三个关键阶段想清楚、记得住、做到底。如果你只想先尝试一个我建议先从 Planning with Files 开始。因为它最稳定最容易看到收益也最不容易干扰上下文。等你习惯了本地计划文件再加入 Superpowers 做前期设计最后用 Rough Lop 做收尾验收。AI 编程不是把需求扔给模型就结束。真正可靠的做法是把需求拆清楚把计划写下来把完成标准定义具体然后让 AI 在这个边界内工作。一句话总结别指望 Skill 替你思考。真正有效的 Skill是逼你和 AI 一起把事情想清楚、做完整、验收明白。返回顶部
相关文章
AI时代的轻创业：一个人也能打造自己的互联网事业
在过去，创业往往意味着租办公室、组建团队、投入大量资金。然而随着互联网技术和人工智能的发展，创业的门槛正在被不断降低。越来越多的人开始通过个人能力和数字化工具，在较低成本的情况下创造属于自己的事业。对于普通人来说，轻…
星露谷物语模组开发终极指南：用SMAPI打造你的专属农场
星露谷物语模组开发终极指南：用SMAPI打造你的专属农场 【免费下载链接】SMAPI The modding API for Stardew Valley. 项目地址: https://gitcode.com/gh_mirrors/smap/SMAPI 你是否曾经想过为星露谷物语添加新功能、自定义角色或者改变游戏玩法？S…
沪深A股LSTM价格预测实战资源包：含数据、训练代码、预训练模型与可视化结果
本文还有配套的精品资源，点击获取 简介：直接跑通股票价格预测的完整流程，内置上证指数（000001）和中国平安（000001.SZ）日线行情CSV数据，开箱即可运行。提供从数据获取（…
四层电梯PLC设计S7-1200(设计源文件+万字报告+讲解)（支持资料、图片参考_降重降ai）
四层电梯PLC设计S7-1200 含博途程序 HMI 电气原理图CAD报告 1、采用PLC构成四层简易电梯电气控制系统。电梯的上、下行由一台电动机拖动，电动机正转为电梯上升，反转为下降。 2、楼层呼叫按钮及电梯内按钮按下，电梯未达到相应楼层或未得到相应…
深度测评：中小企业72小时小程序快速上线，关键难点与解决路径
摘要：72小时上线小程序的核心不在于“快”，而在于“快且可用”。本文拆解功能完整、质量稳定、上线运营三大难点，给出可操作的判断与路径。问题背景：快速上线不等于匆忙上线一家社区餐饮店老板咨询：“我想在两周内上线…
超越传统视觉：DINOv2如何用自监督学习革新图像理解
超越传统视觉：DINOv2如何用自监督学习革新图像理解 【免费下载链接】dinov2 PyTorch code and models for the DINOv2 self-supervised learning method. 项目地址: https://gitcode.com/GitHub_Trending/di/dinov2 在计算机视觉领域，传统方法严重…
深度解析AKShare金融数据接口库的技术架构与实现原理
深度解析AKShare金融数据接口库的技术架构与实现原理 【免费下载链接】akshare AKShare is an elegant and simple financial data interface library for Python, built for human beings! 开源财经数据接口库 项目地址: https://gitcode.com/gh_mirrors/aks/akshare A…
批量给JPG照片添加GPS经纬度和海拔高度的Python工具
本文还有配套的精品资源，点击获取 简介：用命令行运行main.py脚本，自动从CSV文件读取每张照片对应的经度、纬度和海拔（单位：十进制度、米），精准写入同名JPG图片的EXIF GPSInfo字段。支持多图并…
华为欧拉系统上，手把手教你用Docker-compose搞定Harbor私有镜像仓库（ARM64版）
华为欧拉系统实战：Docker-compose部署ARM64版Harbor私有镜像仓库 在国产化技术生态快速发展的今天，华为欧拉操作系统作为国产服务器领域的重要力量，正逐渐成为企业级应用的新选择。对于使用ARM64架构的团队而言，如何在欧拉系统上高…
LED驱动技术全解析：从核心架构到实战选型与避坑指南
1. 从一颗灯珠到千亿市场：LED驱动的技术演进与商业逻辑十几年前，当我第一次从料盘上拿起一颗0603封装的白色LED时，它微弱的光晕和高达几块钱的单颗成本，让我很难想象今天它几乎照亮了我们生活的每一个角落。从手机屏幕的一抹背光&…
索引堆及其优化
索引堆及其优化 引言 索引堆是一种数据结构，广泛应用于计算机科学和软件工程领域。它主要用于解决优先队列问题，如最小堆和最大堆。本文将详细介绍索引堆的概念、实现方法以及优化策略。 索引堆的定义 索引堆是一种基于堆数据结构的索引机制。它通过维护一个堆来存储数据…
从零到日增237精准粉丝，我靠CSDN这张AI卡片爆了！手把手复刻全流程，含配置避坑清单
更多请点击： https://intelliparadigm.com 第一章：CSDN AI 数字营销的官方引流卡片是什么功能？ CSDN AI 数字营销平台推出的「官方引流卡片」，是一种面向技术创作者的轻量级、可嵌入式内容分发组件，专为提升博文、教程…
LED驱动技术全解析：从核心架构到实战选型与避坑指南
1. 从一颗灯珠到千亿市场：LED驱动的技术演进与商业逻辑十几年前，当我第一次从料盘上拿起一颗0603封装的白色LED时，它微弱的光晕和高达几块钱的单颗成本，让我很难想象今天它几乎照亮了我们生活的每一个角落。从手机屏幕的一抹背光&…
索引堆及其优化
索引堆及其优化 引言 索引堆是一种数据结构，广泛应用于计算机科学和软件工程领域。它主要用于解决优先队列问题，如最小堆和最大堆。本文将详细介绍索引堆的概念、实现方法以及优化策略。 索引堆的定义 索引堆是一种基于堆数据结构的索引机制。它通过维护一个堆来存储数据…
从零到日增237精准粉丝，我靠CSDN这张AI卡片爆了！手把手复刻全流程，含配置避坑清单
更多请点击： https://intelliparadigm.com 第一章：CSDN AI 数字营销的官方引流卡片是什么功能？ CSDN AI 数字营销平台推出的「官方引流卡片」，是一种面向技术创作者的轻量级、可嵌入式内容分发组件，专为提升博文、教程…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…