主题
1.7 Vibe Coding 思维方式：说清目标，小步实现，持续验证
请设计师布置房间时，你可能先说明想要明亮、安静、方便阅读，再看草图和样品，逐步调整。你不必亲自画每一条线，但仍需要判断布局是否合适、预算是否可接受、做出来能否使用。
以自然语言与 AI 协作开发，也有类似过程：描述目标，观察结果，补充要求，再继续修改。Vibe Coding 常被用来描述这种以意图和反馈推进的方式。它是协作方式，不是一种独立的模型架构或软件协议。
为什么需求表达变得更重要
当生成代码变得容易，含糊的需求也会更快变成一大批实现。比如“帮我做一个读书网站”，可能被理解成书店、阅读器、读书笔记或书评社区。生成得快，并不能弥补方向选错。
可以先把目标缩小为：“做一个个人读书笔记页面，能够新增笔记、按书名筛选，并在刷新后保留数据。第一版只在本机使用，不做账号系统。”
这段话确定了用户、功能、数据要求和本次范围。界面颜色还可以继续讨论，但项目已经有了可检查的起点。
前面几种方式怎样放在一起理解
这些方式能够同时使用，并不存在必须依次替换的关系：
| 方式 | AI 主要参与什么 | 人需要重点判断什么 |
|---|---|---|
| 人工编写 | 可以不参与 | 设计、实现与验证 |
| 代码补全 | 提供局部实现建议 | 建议是否符合当前逻辑 |
| 对话协作 | 讨论问题、起草代码和解释 | 资料是否充分、答案是否可执行 |
| 编辑器集成 | 连接项目资料与修改操作 | 修改范围、上下文和关联影响 |
| 编码智能体 | 连续执行、读取反馈、调整 | 目标、权限、停止条件和验收证据 |
| 可视化流程 | 组合已有能力 | 业务分支、失败处理和维护方式 |
Vibe Coding 可以发生在其中多种工具里。用聊天制作一个原型，与让智能体维护长期运行的服务，承担的责任并不相同。原型允许快速试验；涉及真实用户和数据时，则需要进一步审查、测试与运维安排。
一次任务中，哪些信息不能省略
目标：让结果可以判断
“更好看”“更稳定”“优化一下”可以作为开始，但还需要补充观察标准。例如，“手机竖屏下不出现横向滚动”“搜索失败时显示重试入口”“删除前允许取消”，都可以实际检查。
如果暂时说不清，可以先要求 AI 提供两种方案及各自影响。做决定之后，再进入实现，避免一边生成大量代码一边反复改变核心方向。
上下文：提供已经确定的事实
项目使用什么语言、已有接口在哪里、哪些功能不能改变，都属于工作依据。把这些信息放在项目说明或规则文件中，并让 AI 阅读相关代码。
资料不需要越多越好。与当前任务无关的长文、过期截图和旧方案，可能让关键约定更难找。最好标明哪些是当前规则、哪些只是参考，以及信息来自哪个版本。
验证：检查真实行为
要求 AI 汇报实际执行了什么检查，并亲自操作关键流程。对资金、权限、数据删除等重要逻辑，还需要查看实现与边界条件。
不能因为代码由 AI 生成，就省略必要审阅；也不能把“没有报错”当成“符合需求”。验证应该从预期行为出发，而不是只证明生成的实现能够运行。
用一个小项目练习完整过程
以读书笔记为例，可以分成四次交付：
- 展示几条固定笔记，确认信息层次和手机排版。
- 增加新建与编辑，明确标题为空时的处理。
- 增加保存，验证刷新后数据是否保留。
- 增加搜索，验证中文、空格和没有匹配结果的情况。
每一步都留下可运行的结果。若第三步出问题，先确认保存与读取逻辑，不必同时重做页面样式。适合记录版本时，由开发者按项目约定保存一个清楚的提交；让智能体代为提交则需要明确指令。
什么时候应该暂停继续生成
如果同一个错误反复出现，先回到证据：错误能否稳定复现？运行的是刚修改的文件吗？依赖是否装在正确环境？如果这些问题未确定，继续让 AI “再修一次”可能只会增加变化。
另一个信号是改动越来越偏离原目标。只要求添加搜索，却更换了数据库和页面框架，就应重新确认必要性。合理的迭代是不断缩小未知条件，而不是用更多代码掩盖不确定性。
从会描述需求，到能够判断结果
刚开始可以更多依靠 AI 解释代码。随着实践推进，逐渐把注意力放到数据流、异常处理和模块边界上：输入如何进入系统，哪些地方修改数据，失败时如何恢复。
这些知识会让你的需求更具体，也会让反馈更有效。第二章会补齐这些基本概念，第三章再把运行环境、模型接入和开发流程串起来。
可配合阅读 Anthropic 关于构建有效智能体的文章，了解固定工作流与自主执行之间的取舍。