让 AI 写代码之前，先准备一份能被执行和验收的项目包，减少范围失控、误改文件和“看起来完成”的假交付。
Vibe Coding 的核心不是“用哪款编辑器”，而是你能否把模糊想法整理成 AI 可以执行、你自己可以验收的工作包。下面这份清单适用于网站、小工具和内部系统的第一版，也适用于把一个已有项目交给编码智能体继续修改。准备完成后，你应该能明确回答：做什么、不做什么、允许改哪里、怎样算完成、失败后怎样恢复。
清单一：一页需求必须包含五件事
先写用户、场景、核心动作、完成标准和不做清单。比如“访客选择日期并提交预约”是动作，“做一个现代化预约系统”只是愿望。把每条需求改成可观察结果：手机宽度下表单保持单列；空日期不能提交；提交失败显示原因；成功后展示预约编号。
再列出第一版明确不做的功能，如在线支付、会员等级、复杂排班和多语言。AI 会根据常见产品补全功能，如果你没有边界，它的“积极发挥”往往就是返工来源。任何尚未确认的价格、规则和业务口径标注“待确认”，不允许模型自行补造。
清单二：上下文不是越多越好，而是能定位
给 AI 一张项目地图：启动命令、主要目录、数据来源、关键页面、测试命令、部署方式。已有项目要先让它只读检查，并返回将要修改的文件和理由。品牌资料、接口文档和参考截图分别存放，说明哪份是事实来源，哪份只参考视觉。
编码智能体需要能够真正构建和测试项目。GitHub 的云端智能体环境说明强调，应预装依赖和工具，使智能体能够可靠地构建、测试与验证。这条原则不只适用于 Copilot：如果你自己都不知道如何启动测试，AI 也只能用“代码看起来合理”代替真实验证。
清单三：先划权限，再谈自动执行
建立工作分支或完整备份，确认回退方法后再开始。密码、API 密钥、生产数据库和真实用户数据不粘贴进提示词，不写入仓库；使用环境变量和脱敏样例。默认不允许智能体直接删除生产数据、修改域名解析、发送外部消息或上线收费功能。确实需要时，把动作、目标和验证条件单独写清。
把“允许修改的范围”写成路径，例如只改 src/pages/booking 和对应测试。依赖升级、数据库迁移、权限调整属于高风险改动，要求 AI 先说明影响与回滚方案。一次任务只解决一个可独立验收的问题，避免在同一轮里同时重构、换框架和加功能。
清单四：把任务拆成可以停下来的小步
推荐顺序是：读取现状；输出方案；实现最小链路；运行测试；检查界面；记录变更。每一步都有可停止状态。任务描述中加入“如果发现需求冲突，停止修改并列出冲突”，比一句“自行判断”更能避免错误扩散。
让 AI 在每轮结束时交付四项：改动摘要、文件清单、测试结果、仍未验证的风险。GitHub 对 Pull Request 的定义也围绕分支、差异、讨论、自动检查和合并展开，详见Pull Request 官方说明。即使是个人项目，这种结构也能让你知道“它到底改了什么”。
清单五：验收不能只看页面能打开
为核心路径写正常、空值、错误值和网络失败四组测试。界面还要检查手机与桌面、键盘操作、加载中状态、错误提示和刷新后的状态。后端检查权限、重复提交、日志与数据一致性。上线前要求构建、测试和静态检查真实执行。
GitHub 的状态检查文档说明，构建、测试、代码扫描和部署检查可以帮助判断改动是否具备合并条件。注意“检查被跳过”可能也显示成功，因此不要只看绿色图标，还要确认该跑的任务确实运行。
失败时按这个顺序排查
项目启动不了：先比较依赖版本、安装日志和启动命令。页面能开但功能不动：查看浏览器控制台与网络请求。测试通过但线上失败：比对环境变量、构建产物和运行环境。AI 反复修不好：恢复到最近可用提交，把问题缩成最小复现，再让它处理。不要在未知状态上连续叠补丁。
成本上，先用低成本模型完成目录梳理、格式化和简单修改，把复杂架构或跨文件问题留给更强模型；但任何模型都不能替代真实测试。敏感项目还要确认所用服务的数据保留、训练使用和访问控制政策。
常见问题
准备清单会不会让开发变慢？
十分钟的边界和验收定义，通常能省掉数小时返工。清单不需要写成长文，只要让任务和终点可观察。
AI 已经能读整个仓库，还需要项目说明吗？
需要。读到文件不等于理解业务规则。启动方式、事实来源、禁止项和上线标准仍应由项目负责人明确。
什么时候可以让智能体自动上线？
只有当测试、回滚、权限隔离和发布监控已经稳定，并且自动上线的风险可接受时。新项目应先保留人工审批点。