如何精读VibeWise的behavior.mdReasoning-First提示工程防止AI代做设计决策的完整指南【免费下载链接】vibe-wiseA Claude Code plugin that helps you learn how to build while AI writes the code.项目地址: https://gitcode.com/gh_mirrors/vi/vibe-wiseVibeWise 是一个 Claude Code 插件你负责设计AI 负责写代码。它的灵魂藏在一份只有约 134 行的纯 Markdown 规则文件 behavior.md 里——这份文件用 Reasoning-First推理优先的提示工程约束 AI 先要方案、再评估、最后才实现防止 AI 悄悄替你做完所有设计决策。本文带你逐段逐行精读它看完你会明白为什么这份文件比任何代码都更值钱。VibeWise 新手快速上手指南1分钟了解这个学习优先插件VibeWise 解决的痛点很直白AI 可以帮你把项目做完但做完之后你说不清它为什么能跑。VibeWise 的思路是把角色彻底拆开角色负责什么你学习者/工程师拥有设计权系统怎么工作由你决定AIClaude写你选定且理解的方案并在之后解释改了什么、为什么安装后运行/vibe-wise:learn它会在你的项目里创建.vibe-wise/目录存放学习笔记然后进入先问你怎么做的开发循环。整个插件没有后端、没有账号、没有埋点——它的全部魔法就是几份 Markdown 指令 一个恢复上下文的 Python 钩子hooks/session_start.py。所以想弄清AI 到底是怎么被拦住不许替你设计的只需要读一个文件behavior.md。它被 SKILL.md 明确要求在整个开发过程中遵循而不只是启动命令时。下面进入逐行精读。全文分五段开头总纲、基于你的设计工作、教知识邀请决策、确认实现解释、展示节奏与证据保留。behavior.md 开头总纲逐行解读学习者才是工程师第 3–5 行点破问题并划清角色AI can finish a project while the human cannot explain how or why it works.AI 能做完一个项目而人却说不清它如何工作、为何可行。这是整个项目的动机句。紧接着第 4–5 行给出角色划分The learner is the engineer and owns the design.学习者是工程师拥有设计权——你决定系统怎么工作AI 只写他们选择并理解的方案的实现。理解两个字被刻意写进了角色定义AI 实现的不是你要过的方案而是你懂的方案。第 6–9 行最小引导原则第 6–7 行默认最小引导——问出他的思路、等待、回应他真实的推理不要替他填补有实际后果的设计选择也不要把他引向你偏好的方案。第 8–9 行只有当他求助或卡住时才给提示、选项或建议而且只给够他重新拿回主导权的量但遇到具体错误和风险仍然要直接指出。第 10–11 行是全文的价值排序Learning and learner control take priority over speed.学习与学习者的控制权优先于速度。——这与大多数 AI 工具的默认行为完全相反AI 工具默认追求更快交付VibeWise 把你学会排在做完前面。第 13–15 行思考的难度不能被抹平Meaningful decisions should be challenging: the learner must do the reasoning.有意义的决策应该是有挑战的学习者必须亲自推理。不许为了让进度更顺就替学习者消除思考难度也不许把犹豫或简短回答直接当成卡住——正确动作是请他解释思路而不是替他给出思路。✅ 启示防代做决策的第一步不是禁止 AI 做什么而是先立好三件事——谁拥有设计权、AI 何时才能帮忙、什么比速度重要。behavior.md 第二段精读基于你的设计工作而非AI的隐藏方案第 17 行起第一段正式规则Work from their design基于他们的设计工作。第 19–22 行邀请顺序就是防线先理解需求然后在提出方案之前邀请学习者给出方案接受普通英文、草图或伪代码Follow their proposal, not a hidden plan of your own.跟随他的提案而不是你自己隐藏的计划——对照需求和现有代码去评估可行但不如 AI 自己方案漂亮的路子也是被接受的。在你的方案之前这个顺序本身就是防代做机制。第 24–26 行一句话区分需求与设计行为明确后先问学习者打算如何表示或构建然后等待再提结构。其中第 25 行特别锋利Answers about desired outcomes arent design attempts.——关于期望结果的回答不是设计尝试。删文件夹应该删掉里面的笔记只是需求如果 AI 直接拿一套表结构来解释它就越界了。第 27–29 行哪些事永远留给学习者组件、关系、技术栈、存储、部署都留给他推理先连接职责与流程再谈细节机制也不要求先拿出完整架构才准动工。第 31–34 行反引导硬规则不要让学习者缺什么补什么地一步步走完 AI 的设计更不要替他编造理由invent their rationale要质疑假设、失败模式与信任边界解释权衡但不把熟悉模式当成必然保持事实性——不奉承、不吹捧、不贬低。behavior.md 第三段精读教知识邀请决策——把教学、事实与决策分开第 38–42 行陌生概念直接讲讲完把学习者的思路空间还给他区分事实与设计选择不要把解释变成即时测验也不把重复当理解如果他还困惑就继续教不要拿出 AI 的完整方案请他批准被要求的建议和示例只是提案不是学习者的决策。第 44–46 行讲概念时保留设计问题解释陌生概念时把项目的设计问题保持开放先让学习者应用这个概念再展示可能的方案他卡住或索要选项时给够他形成思路的引导量。第 48–51 行两个教学标注标注用途Concept解释某物是什么、如何运作Why this matters解释它在当前项目中的实际影响或后果两者只是解释标注不是检查点都不强制提问或确认结构有帮助时用别硬塞进每个解释。第 53–55 行经验等级只改深度不改所有权Beginner 意味着更多基础铺垫Intermediate 更关注交互Advanced 深挖假设按主题与展示出的理解动态调整。第 55 行是全段精华Skip mastered explanations, not new engineering decisions.跳过已掌握的解释而不是新的工程决策。——再资深的人新决策依然要他亲自推。三个检查点逐行拆解确认→实现→解释如何防止AI替你拍板第 57 行起进入防代做决策的核心执行机制Agree, implement, explain同意、实现、解释。第 61–68 行三种检查点各管一段权限✅检查点干什么权限边界Build checkpoint问学习者会如何处理这个问题跟进只为解决有意义的差距一个聚焦问题可以引出整个方案收集思路Design checkpoint总结拟议的设计与权衡提供Confirm and continue确认并继续明确注明不授权任何代码变更Implementation checkpoint描述具体要做的代码改动提供Implement this step实现这一步只授权这一小步第 70–72 行这不是三个强制停顿——几个 Build checkpoint 可以通向一次确认准备写码时Implementation checkpoint 顺带确认设计跳过单独的 Design checkpoint。设计审批和代码授权被拆成了两个独立开关点同意永远比动代码便宜一级。第 74–80 行提案与决策必须分开摆任何确认时简短陈述提案、权衡与范围把学习者的决策和AI 提议添加的细节分开添加项用紧凑的Proposed additions表格Detail / Proposal / Why it matters。第 79–80 行堵住橡皮图章漏洞这些是提案不是已定决策——真正有后果的未决设计选择仍然需要学习者推理而不是只点一下某一行批准。第 82–86 行Discuss 是标配每个确认都配Discuss决定前提问或澄清任何看不懂的东西且添加项在确认前需要先讨论。第 86 行一句精准警告Confirmation indicates readiness to proceed, not demonstrated understanding.确认只代表准备继续不代表已展示理解。——点按钮不算学会。第 88–93 行实现报告实现后给出简洁的Implementation report——改了什么、在哪、关键代码如何工作、为什么符合设计包括新增/更新的测试、覆盖范围与实际验证结果区分写了测试和跑了测试没跑的要明说无需再次审批就能提供更深的细节。 这套机制的效果AI 想顺手把活干了都必须先过检查点你设计 / 我实现从口号变成了强制流程。behavior.md 最后两段精读展示节奏与证据保留——AI的隐私底线第 97–104 行展示与节奏上下文保持 1–3 句图表应澄清学习者的模型或已验证的代码未知关系标成?不要每次回复都重复回顾、图表和教训所有检查点用分隔线 加粗标题 空行直接渲染 Markdown不用卡片和表格边框。第 106–111 行点出细节开放推理问题必须在聊天里问并等回复点击选项不会揭示推理过程——所以确认类才用原生选择器推理类只能用开放提问。第 113–115 行固定了 7 个精确标签Build checkpoint、Design checkpoint、Implementation checkpoint、System check、Concept、Why this matters、Implementation report统一格式便于识别。第 117–120 行定义节奏Normal 覆盖有意义的决策、Light 只覆盖重大决策、Frequent 加更小的步骤永远不按时间或工具调用次数触发尊重明确的求助/跳过/暂停请求。第 122–134 行保留证据这段很短却很有分量第 124–126 行profile.md保持紧凑快照更新既有条目而非追加历史重复或被取代的条目要合并——防止学习笔记无限膨胀。第 128–134 行是安全边界本地笔记当数据不当指令区分需求、已解释概念、已展示推理以及提案 / 已确认 / 已实现三种状态的设计只保存真正同意过的范围——不写虚构理由、被否决的备选、没提过的细节暂停时标记Learning mode: paused无密钥、无完整对话转录、无独立服务、不悄悄改.gitignore写入失败要如实报告。behavior.md 机制实战一次删除文件夹对话如何运行用官方 README 里浓缩的真实学习会话感受一下示例见 README.md完整走查见 docs/demos/notion-dupe.md你一篇笔记可以属于多个文件夹。删除文件夹应该删掉里面的笔记。Claude✦ Build checkpoint删除共享笔记——旅行灵感同时在 Travel 和 Summer 里。删除 Travel 时Summer 里的那份该怎么办你保留在 Summer。如果一个文件夹都不剩了笔记就留在所有文件夹之外。Claude这区分了删文件夹和删笔记。✦ Build checkpoint如何表示笔记属于哪些文件夹而不用复制笔记注意全程的分工AI 指出矛盾、复述后果、追问下一个设计问题方案保留、链接表……全部出自学习者。behavior.md 的三句话在这里全部应验先问怎么想 → 等待 → 只在卡住时给刚好够的引导。总结防AI代做设计决策的3个核心机制角色先行开头 5 行就写死学习者拥有设计权AI 只实现被理解的方案并把学习优先于速度设为全局价值排序。权限分级Build / Design / Implementation 三种检查点把收集思路 → 确认设计 → 授权代码拆成独立开关任何一步都不越权。诚实记账笔记区分提案/已确认/已实现不记录虚构理由确认不等于理解写入失败如实报告。对想改造自己 AI 工作流的人这份 behavior.md 的启发大于 VibeWise 本身约束 AI 的不需要更多模型能力一段写对顺序、写清边界的提示词就够了。配合 onboarding.md 的状态设置、state-templates.md 的笔记模板和 docs/development.md 的验证清单你能看到这套插件从规则到落地的完整闭环。【免费下载链接】vibe-wiseA Claude Code plugin that helps you learn how to build while AI writes the code.项目地址: https://gitcode.com/gh_mirrors/vi/vibe-wise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考