搜索：
搜索到 3 篇与 的结果-
别让 AI 直接上手写代码——用 Superpowers 把它变成遵守流程的技术合伙人 想让你的 AI 编码小助手不再乱跑、随手写代码，而是像资深工程师一样先思考、先规划，再动手？本文教你把一堆碎片化的技巧，装进一个叫 Superpowers 的插件里，让 AI 自动遵循「先想后做」的工作流，省掉无数回头改代码的折腾。一、核心痛点：AI 直接上手，代码质量难保 提出需求就开始改文件，结果经常缺设计、缺测试，后期 bug 爆炸。 团队里每个人都在手动写代码审查、写测试，效率低下。 AI 只能记住有限的上下文，长时间的项目会把重要信息冲掉。 二、大家常误以为：只要加几个提示词就够了很多人把所有规则堆进系统提示，结果要么忘记，要么被新需求冲掉。就像把所有菜谱写在厨房的门上，厨师忙着翻找根本找不到想要的那一道。三、实际干货：把流程拆成「技能」模块，让 AI 自动调用Superpowers 把完整的软件开发过程切成 14+ 个独立的「技能」： brainstorming：在动手前把需求拆成一块块小问题，和你确认。 writing‑plans：把大需求细化成 2‑5 分钟能完成的小任务，每个任务都有文件路径、实现目标和验证步骤。 test‑driven‑development：先写会失败的测试，再写最小代码让测试通过，确保每行代码都有意义。 using‑git‑worktrees：自动在隔离的工作树里跑每个任务，干净不影响主分支。 subagent‑driven‑development：每个小任务交给一个「子代理」去完成，子代理完成后再回到主代理检查。 还有系统化调试、代码审查、分支收尾等技能，全部可以自动触发。 这些技能在 SKILL.md 文件里写好，AI 在对话时会对照「description」字段自动匹配，符合条件就把对应的指令和检查表塞进上下文。四、为什么「自动触发」比手动指令更靠谱传统的「/plan」或「/test」命令需要你记得每一步什么时候该敲。Superpowers 把「只要有 1% 的可能性需要这个技能，就马上调用」写进了启动脚本。于是： 你说「帮我加个按钮」，AI 先进入 brainstorming，不直接写代码。 确认设计后自动跑 writing‑plans，生成任务清单。 只有当任务里出现「写测试」的需求时，才会调 test‑driven‑development。 这样即使你忘记了某个环节，AI 也会把它补上，像一位严格的项目经理。五、实战演练：从需求到交付的完整流程下面用一个「按钮组件」的例子，演示完整的 5 步走法： 启动插件：在 Claude Code 里执行 /plugin install superpowers@claude-plugins-official，重启会话。 提出需求："我要在设计系统里加一个主按钮，支持主/次/危险三种风格，大小有小中大。" AI 立即进入 brainstorming，一个问题一个问题确认细节。 确认设计：AI 把设计文档写成 docs/button‑spec.md，等你点「ok」才继续。 生成计划：writing‑plans 把实现拆成 9 条任务，每条都带失败测试。 子代理执行：每条任务分配给子代理，子代理完成后回报结果，主代理做 code‑review，不通过的直接让子代理修。 收尾合并：所有任务绿灯后，finishing‑a‑development‑branch 自动创建 PR，提示你合并或继续迭代。 整个过程你只动了两次「确认」——一次确认需求，一次确认设计。其余所有细节都被插件自动完成。六、适用场景与边界 适合 **中等以上** 的功能实现、组件库建设、后台服务迭代。 不适合一次性改一个小 bug——那时 brainstorming 会显得多余，可以直接在对话前加「跳过脑暴」指令。 团队想要统一的编码规范、测试覆盖率或审查流程时，直接在 SKILL.md 里写好即可。 七、和其它工作流的互补如果你已经在用 GSD（Get‑Shit‑Done）这样的手动指令式流程，完全可以把它放在前端：先用 GSD 进行需求访谈、业务拆解；然后交给 Superpowers 负责实现、测试、审查。两者像「前菜」和「主菜」一样配合，既保留了人为的设计思考，又不会手动敲每个工程细节。八、安装小贴士与常见坑 确保在全新会话里启动插件，旧会话的上下文里不会自动加载。 如果发现某个技能没有触发，检查本地的 CLAUDE.md 是否有冲突指令，用户指令会覆盖插件。 工作树创建前一定要先 git init，否则会默默失败。 对极小改动想跳过流程，可在开头加「这只是一次性修补，直接改文件」让 AI 服从。 九、结语：让 AI 成为真正的「技术合伙人」Superpowers 把「先想后做」的工程哲学写进了 AI 的「脑子」里，让它不再是只会写代码的「小抄」工具，而是能和你一起走完整个研发流程的伙伴。只要你把需求说清，它就会帮你把每一步落实到位。想了解更细节的插件安装方式、或者看看其他人在真实项目里怎么使用的，建议去看一下 Superpowers 项目首页。如果你已经尝试过，或者还有哪些环节觉得不够顺手，欢迎在下方评论区留言，咱们一起把这套流程磨得更顺滑！ -
让 AI 编码小伙伴在你睡觉时跑代码：gnhf 实战全拆解 不想下班后再跟代码纠缠？只要一句命令，让 AI 在你睡觉时自动提交干净代码！本文教你一步一步把 gnhf（good night, have fun）装进项目，让它像自来水一样悄悄流进你的仓库。核心本质：把 AI 当成守夜的代码工匠 把目标（比如补全测试、降低复杂度）喂进去，AI 每次尝试都用 git commit 把成功的改动保存。 失败就立马 git reset --hard 把现场恢复，保证仓库始终干净。 所有迭代过程写进 notes.md，相当于一本“工作日志”。 为什么大家都以为自动化只能靠 CI？传统 CI 只能在代码 push 后跑一次检查，不能主动去改代码。很多人误以为只能手动写脚本或一次性生成代码，结果要么一次成功要么全盘崩溃。gnhf 的反直觉干货：让 AI 持续迭代、实时回滚、自动记忆gnhf 把每一步都当作一次“微提交”。如果本轮改动不符合预期，直接回滚不留污点；如果符合，就记录下来并且把 notes.md 注入下一轮提示，形成跨轮记忆。这样即使模型偶尔跑偏，也不会把仓库弄得一团糟。一步到位的上手流程 全局安装：npm install -g gnhf。 进入干净的 Git 项目，确保 git status 显示 clean。 给出明确目标并启动：gnhf "reduce complexity of the codebase without changing functionality" 想限定时间？加 --max-iterations 10 --max-tokens 5000000。 进阶玩法：多 Worktree 同时跑不同任务如果你有多个小目标，使用 --worktree 参数让每个 AI 在独立的工作树里跑，互不干扰。类似于给每个 AI 分配一套独立的厨房，做各自的菜。# 同时跑三个任务 $ gnhf --worktree "add tests for module A" & $ gnhf --worktree "refactor utils" & $ gnhf --worktree "optimize startup time" & 常见坑与最佳实践 任务描述要写清楚“验收标准”。比如“把所有重复函数合并成一个，且单元测试覆盖率不低于 80%”。 默认情况下如果提示不够具体，AI 可能会无限迭代。加 --max-iterations 或在提示里写“只需要一次提交”。 注意 notes.md 会随迭代累计，长任务会导致 Token 费用升高，必要时手动清理或分支归档。 连续三次失败后 gnhf 会自动 abort，防止跑死循环。 实战案例速递有人用 gnhf 在一整夜里把项目的代码行数从 5000 行压缩到 3800 行，提交历史清晰可追溯；也有人让它在凌晨自动补全所有模块的 README，第二天直接把文档拉进主分支。后续阅读推荐如果想了解更细粒度的配置细节，之前我们聊过 gnhf 项目仓库；还可以看看关于 Git 工作流最佳实践的文章，帮助你把 AI 生成的提交更好地融合到团队协作中。今天的分享就到这里，快去试试让 AI 替你“熬夜”吧！有遇到奇怪的日志或者好玩的结果，欢迎在下面留言聊聊～
-
山顶洞人也能写代码：caveman 插件到底怎么省 Token、提速还能保准 大家都觉得 AI 编码助手会帮你省心，结果却常常被‘废话’淹没在日常使用 AI 代码伙伴时，很多人都会惊讶于它们总是喜欢在答案前面加一句“好的，我来帮你”。这类客套话看似礼貌，却无形中把本该直接的技术要点埋进了冗长的文字里。对于每一次对话来说，平均要多消耗三四十个 token，累积下来每月光是这些客套话就能花掉上万 token，等于是多付了几十美元的费用。实际情况是：AI 并没有因为多说几句话而变得更聪明。相反，模型在生成冗余文字时会占用更多计算资源，导致响应速度下降，成本却没有实质性提升。于是有人想：为什么不让 AI 像原始人一样，只说核心技术点？这就是 caveman 插件 的来源。它的核心思想很直接——把所有无意义的填充词、客套话和重复表达全部砍掉，只保留技术要点和代码本身。实现方式是通过一套规则把自然语言部分压缩约 75%，而代码块、路径、URL 等技术细节则原样保留，保证答案的准确性不受影响。caveman 的工作原理到底是怎样的？ 先识别文本中的自然语言段落； 删除冠词、代词、礼貌用语等非必要成分； 对剩余内容进行简化，使用最短的词汇表达同样的因果关系； 保留所有代码块、命令行、错误信息等技术信息不动。 如此一来，同样的问题，从原本的上千 token 直接压缩到几百 token，甚至更低。实测数据显示，平均节省约 65%，极端情况下还能省到 87%。怎么把 cav caveman 带进自己的开发工作流？整个流程就像装插件一样简单： 确保本机已经装好 Node.js 或者 Python 环境。 使用一行命令把插件装到目标 AI 伙伴上，例如：npx skills add JuliusBrussee/caveman（如果是 Claude Code 还可以直接在插件市场里点击安装）。 在每次会话开始时说一句 “talk like caveman”，或者直接敲 /caveman 激活。 如果需要切换强度，使用 /caveman lite（保留基本语法），/caveman full（默认最简），或 /caveman ultra（极限压缩）。 想让 AI 阅读自己项目的记忆文件也省 token？运行 /caveman:compress CLAUDE.md 把记忆文件压缩成 caveman 语言。 这些步骤完成后，无论是写代码、审查 PR 还是调试错误，AI 的回答都会像山顶洞人一样直接、干脆。三档强度到底适合谁？ 轻量级（lite）：去掉客套话，保留完整语法，阅读体验仍然像普通人说话。适合日常对话，想要省点 token 又不想太生硬。 标准版（full）：完全砍掉冠词、主语等，答案像电报一样简短。适合需要快速定位问题根源的场景。 极限版（ultra）：把所有可以缩写的词都压缩，甚至使用符号链式表达。适合只有结论需求的紧急情况。 实际使用体验分享有位开发者每天大约 200 次对话，开启 caveman 后，每轮平均少掉 30 token，一天省下 6000～8000 token，月省约 40‑50 美元的费用。更重要的是，回复速度提升约 3 倍，调试时不再被冗余文字干扰。在代码审查时，他会先关闭 caveman（因为审查需要完整语境），等到审查结束再打开，以保持审查的完整性。注意事项与坑点 caveman 只压缩自然语言，不会动代码，故对于纯代码修改的任务节省不明显。 极限模式的表达非常简洁，阅读起来可能有点像电报，需要使用者习惯。 在多语言团队里，需要自行增加其他语言的变体，否则非英语使用者可能会看不懂。 在某些 IDE 或插件系统里需要手动把规则文件放到对应目录，确保 always‑on 生效。 对普通开发者的意义如果你每天都在和 AI 代码伙伴聊天，那么每一次的冗余文字都是在消耗你的时间和金钱。caveman 把“说太多”这一隐形成本直接砍掉，让你把注意力集中在核心逻辑上。省下的 token 可以用来扩展上下文、跑更大的模型，甚至直接省下一笔费用。总之，caveman 并不是把 AI 的智慧削弱，而是把“废话”抽离，只留下“答案”。在当下 AI 成本仍然是硬指标的环境里，这种“砍枝留芽”的思路值得每一个工程师去尝试。如果你还在为每次对话的冗长答复而烦恼，赶紧装上 caveman，体验一下山顶洞人的高效沟通方式吧！ 🎉
