我给 Vibe Coding 写了一份轻量工作约定

让 AI 帮忙写一个小工具，第一步往往很轻松：说出想法，等它生成代码，再看看效果。

但我更在意后面的事。它是否理解了我真正想解决的问题？这次修改会不会碰到原有功能？所谓“已完成”，到底是写完了代码，还是实际运行过？如果改坏了，我能不能回到上一个可用状态？

围绕这些问题，我整理了 Vibecoding Personal。它是一份面向个人小型网站、应用、脚本和原型的 Skill，也是一套我希望与 AI 共同遵守的工作约定。

我想保留快速动手的自由，也给每次修改留下足够的依据和退路。

个人项目需要多大的工程流程？

个人开发有一个很实际的矛盾：流程太少，项目容易在几轮修改后变得难以解释；流程太重，一个简单需求又可能被拖成漫长的准备工作。

给自用待办工具加个导出按钮，没有必要默认引入微服务、容器、监控平台或复杂 CI。但“个人使用”也不能成为忽略数据的理由。一个几十行的整理脚本，如果会批量覆盖照片，它需要的保护可能比一个纯展示页面更多。

所以，这份 Skill 的出发点是：按照实际影响安排工作量。

改一处文案，就做相称的检查；涉及数据、登录、密钥或外部写入，就把失败路径和恢复限制考虑进去。项目规模和操作风险，需要分别判断。

先理解目标，再决定怎么做

用户描述需求时，常常会顺手带上一个实现方案。例如：“给这个工具接个数据库。”

但真正想要的，也许只是刷新页面后数据不丢失。数据库可能合适，也可能暂时只需要本地存储。AI 如果直接照着方案开工，代码可以写得很快，却未必解决了最初的问题。

因此，我把“检查与理解”放在最前面：先读相关模块、看看类似实现，确认当前行为和预期行为，再判断需要改哪里。

这里有两类不确定性。项目里已经存在的事实，应该由 AI 自己检查；涉及使用体验、成本、隐私和需求范围的决定，才值得拿出来讨论。

我不希望每个内部细节都变成一道选择题，也不希望重要决定被悄悄替我做掉。

先给简明方案，确认后连续执行

这份 Skill 默认要求：实质性修改前，先给出与任务规模相称的方案，获得确认后再实施。

方案不必很长，但要能回答几个问题：准备解决什么、会碰到哪里、怎么判断完成，以及出了问题怎么恢复。小改动几句话就够；涉及多文件和数据时，再补充必要细节。

确认的意义，是把双方对范围的理解对齐。确认之后，普通编辑、相关测试和范围内的修复应该连续推进，不必每改一个文件就回来询问。

如果中途发现必须改变数据结构、公开接口、成本或明显扩大范围，就需要重新说明取舍。至于真实发送、扣费、删除数据和公开发布，准备工作与实际执行也应该分开看待。

流程的作用是明确每一步交接的依据。验证发现问题，就回到实现继续修正。

验证做多少，取决于可能影响什么

我在文档里把任务分成了五个等级。这是这份工作流自己的分类，方便判断需要投入多少保护和验证。

这些等级要看具体操作。开发一个邮件发送功能，可以先使用替身或测试环境；真正向外发出邮件，是另外一个有实际影响的动作。

验证也应该来自验收目标。如果修改的是表单，就观察填写、错误提示和提交行为；如果修改的是导出，就检查文件内容是否完整、中文是否正常、空数据如何处理。不能只看一条命令变绿，就推断整个功能已经可用。

一个具体例子：给个人待办工具增加本地导出功能。

我希望 AI 先检查当前数据结构和保存方式，再说明导出格式、修改范围与验证方法。获得确认后，完成最小可用实现，用测试数据检查普通内容、空列表和中文内容，最后交代文件在哪里、实际检查了什么、还有哪些限制。

这里的“完成”应该有可观察的结果。

恢复能力，要说清楚能恢复到哪里

恢复是这份设计里我比较在意的一部分。

有 Git 时，可以利用现有历史和差异保护工作；没有 Git 时，也可以只对受影响文件保留必要副本。为了用这份 Skill，不需要先把个人项目升级成一整套工程平台。

但恢复代码与撤回真实副作用是两回事。代码回滚，不会让已经发出的邮件消失；恢复一个本地文件，也不一定能撤销远端数据写入。

因此，交付时应该提供具体恢复方式，并区分“已经演练”和“只写了步骤、尚未测试”。如果没有可靠的恢复路径，也应该直接说明。

记录同样保持轻量：做了什么、为什么这样做、实际验证了什么、如何恢复、还剩哪些限制。能帮助下一次继续开发，就有价值；不需要为了记录本身建立庞大的审计系统。

为什么拆成主文件和参考资料？

这份 1.0.0 分发包的核心结构是：

vibecoding-personal/
├── SKILL.md
├── agents/openai.yaml
├── references/
│   ├── planning.md
│   ├── verification.md
│   ├── recovery-audit.md
│   └── data-security.md
└── assets/iteration-template.md

主文件负责说明原则和主流程；规划、验证、恢复和数据安全的细节，按当前任务需要再读。迭代模板提供一个记录起点，使用时删去不适用的字段。

这样安排，是希望常用路径足够短，同时在遇到复杂情况时有地方查。它也提醒我：规则需要组织，不能只靠不断往一段提示词后面追加要求。

调用时，我会把任务和预期边界一起说清楚。例如：

$vibecoding-personal
帮我给这个个人待办工具增加本地导出功能。
先检查项目，给我简明方案，等我确认后再改。

这只是调用表达示例，具体技能发现与调用方式还取决于所用客户端和版本。本文分享工作流设计，不把它当成所有环境通用的安装教程。

下载与使用

我把这份工作约定整理成了可下载的完整包：

下载 Vibecoding Personal 1.0.0（ZIP）

文件存放于夸克网盘，通过我的 OpenList 文件服务提供下载。

压缩包包含技能主文件、参考资料、迭代记录模板、安装脚本和中文说明。使用前建议先读 README.zh-CN.md；需要检查验证范围时，再看 VALIDATION.md。手动安装时保留整个技能文件夹，里面的参考资料也是工作流的一部分。

分发包采用 MIT 许可，可以在保留许可的前提下修改和分享。也欢迎根据自己的项目习惯裁剪规则，尤其是审批频率、验证方式和记录位置。

它能提供约束，但不能提供保证

这份 Skill 最需要说明的边界是：它是可复用指令，不是强制执行的权限机制。

写了“先备份”，不代表备份已经创建；写了“必须测试”，不代表测试实际运行；写了“未经确认不要发布”，也不能替代运行环境本身的权限控制。

附包中的 VALIDATION.md 记录了一些已完成检查，包括结构检查、Linux 下的安装器验证，以及一次独立临时项目的开发场景。那次场景检查了未批准时先提出方案、批准后限定修改范围等行为。

这些是原包的验证记录，本文没有重新运行上述测试。原包也明确列出了限制：Windows 和 macOS 的安装运行、真实 CLI / IDE 技能发现与调用的端到端验证，以及高风险场景全覆盖评测，都没有完成。

单个场景的结果，不能证明模型在所有任务里都会遵守流程。更合理的做法，是继续观察实际使用中的偏差，再修改规则和验证方式。

接下来，我会怎样继续打磨？

这套设计的一个代价是，默认方案确认会增加一次交互。对于连续的细碎调整，它可能显得繁琐。我的倾向是先把一轮迭代的范围说明白，在这个范围内连续完成；确实很小的任务，也可以明确免除本次方案审批。

另一个需要继续验证的地方，是规则能否在长对话和复杂上下文里稳定发挥作用。按需加载让主流程更短，也依赖 AI 在正确的时候读取正确的参考资料。后续可以补充更多真实场景，观察哪些环节容易漏掉，再调整文档。

我暂时更愿意沿着这条路线迭代：保留简短主流程，用实际失败案例补充边界，减少重复要求。如果以后需要更强的执行约束，再把适合机械检查的部分交给脚本、测试和权限工具。

Vibecoding Personal 想解决的，是一个很日常的问题：当我让 AI 帮忙把想法做出来时，我也希望自己知道它改了什么、凭什么说能用，以及下一次该从哪里继续。

本文依据作者提供的 Vibecoding Personal 1.0.0 分发包整理，参考其中的 README、SKILL、规划、验证、恢复与数据安全资料及验证记录。文中示例用于解释工作流。配图为本篇原创示意图。