那些跑偏的对话，是 vibe coding 最好的工程文档

你跟 AI 说，帮我把这个文件夹里的图片按颜色分个类。

它信心满满地开始写代码。十分钟后，你打开结果一看——红色系图片跟紫色系混在了一起，蓝色系被拆成三份，还有几张直接掉进“杂项”，那个“杂项”文件夹里什么都有。它确实在做颜色分类，但完全不是你要的。

AI其实不太理解你想要的分类
你深吸一口气，开始修复。你说“不是这种红色，我要的是暖色调的统一归类”。它道歉，重新调整。你又发现它对渐变色的处理有问题，告诉它“遇到渐变色时，取主色调”。它再次修改。来回折腾半小时，分类结果终于符合预期。你拿到想要的东西，关掉窗口，开始下一个任务。

那段修复对话，大概率再也不会被打开。

这是 vibe coding 里最熟悉的日常。你花在纠偏上的时间，往往比最初下达指令的时间长得多。产品需求越模糊、越依赖主观判断——颜色归类、文案风格、UI 细调——偏差就越频繁。奇怪的是我们习惯把这些对话当成一次性消耗品。代码留下了，commit 留下了，甚至文档都写了，唯独那段反复修复的对话被当废料处理。

我想说的刚好相反：你扔掉的那些修复对话，比最终产出的代码和文档更有长期价值。

修复对话里藏着什么

传统编程通过注释和 commit message 记录“做了什么”。你在代码旁边写下“修复颜色分类边界判断错误”，或提交信息里写“改用 HSV 色彩空间替代 RGB”。这些都是结果导向的记录——记录问题被解决之后的最终方案。

vibe coding 的修复对话记录的则是另一层东西：你当时错以为需要什么，以及实际需要什么。

传统代码注释与 vibe coding 修复对话的内容差异

回到图片分类的例子。你最初给 AI 的指令是“按颜色分类图片”。这个指令在你脑子里清晰得很——你知道自己有一批设计素材，想按暖色调、冷色调、中性色分开。但对 AI 来说，“按颜色分类”是个巨大的模糊空间。它可能用 RGB 平均值，可能用色相直方图，可能把一张夕阳照片里占比极小的红色当成分类依据。它没有错，它只是在没有足够约束的情况下，找了一个统计学上合理的解。

修复对话的价值就在这里。那半小时的来回不只是在纠错，你在无意中完成了一次需求的外化——从脑子里的模糊感觉，变成精确到能让机器执行的语言。“不是这种红色”升级为“暖色调统一归类”，“渐变色处理有问题”升级为“取主色调”。每一个修复节点，都是你对自己真实需求的重新理解。

这些理解如果能留下来，下次你做类似的分类任务——或者团队里另一个人要做——就不需要再从头摸索。这也是把临时对话转成 可复用上下文 的过程。你从“帮我按颜色分类图片”开始，直接跳到“用 HSV 色彩空间，按色相划分暖色、冷色、中性三组，渐变色取面积占比最大的主色调”。省掉的不是 AI 写代码的时间，是人的认知纠偏时间。

更值得留意的是，那些让你最有挫败感的对话，往往包含着最清晰的需求误解。当你被一个明显错误的结果激怒时，会不自觉地用非常直白的语言去纠正——那种直白，恰好是 AI 最需要的精确指令形态。你无意中用情绪为自己提炼了最有效的 prompt。把它扔掉，等于扔掉了一份自动生成的高级教程。

怎么把废料变成资产

做法不复杂，但需要一点刻意练习。核心动作只有三个：

• 保存。 别让修复对话留在聊天记录里沉底。定期导出那些来回超过三轮的长对话——那些你明显在纠正方向、不是简单补充细节的对话。导出时不需要整理，原样保留。混乱本身也是信息的载体。
• 提取。 用 AI 扫描这些对话，让它按三个维度提取关键信息：你的原始错误假设、纠正过程中暴露的问题、最终有效的精确指令。把下面这段 prompt 丢给它就行：

扫描这段对话，提取三个维度的信息：
- 我最初给了什么模糊或错误的假设
- 在修复过程中暴露了哪些需求理解偏差
- 最终那条真正起作用的精确指令是什么

对于图片分类的例子，提取结果大概是这样：原始假设：AI 能自动理解我的颜色分类标准；过程中暴露：对色彩空间选择、渐变处理、边界判断的隐性需求；最终有效指令：一条包含色彩空间、分组逻辑和边界规则的完整描述。

• 归类。 把提取结果放进一个文档或团队知识库，按任务类型归类——视觉类、数据处理类、文本生成类、接口设计类。每次做完同类任务，把新的修复对话提取结果追加进去。时间久了，你得到的不是一堆散落对话，而是一份按场景索引的“AI 协作指令手册”。

坦诚讲，这件事在初期会让人觉得很蠢。你可能扫描了十几条对话，提取出来的东西看起来像废话合集——“要把需求说清楚”“要给具体例子”“不能假设 AI 理解我的审美”。你忍不住想，这值得花时间吗。

值不值得，要等到第一次重复出现同一个错误模式时才能判断。比如你发现自己第三次在接口设计上要求 AI“重新设计这个 API 的结构”，而三次纠偏都指向同一个问题：你没有在一开始说明数据流向和调用频率。这时候那条反复出现的修复记录就不再是废话，它是一个可命名的错误模式。你可以给它起个名字，写成一条前置检查项，在下一次 vibe coding 开始前扫一眼——然后这次对话根本不需要修复环节。

累积的不是量，是模式

修复对话的数量本身没有意义。有价值的是数量达到某个临界点之后浮现出来的模式——那些你反复掉进去的坑，反复说不清楚的需求，反复在同一个维度上跟 AI 拉扯的瞬间。

这些模式一旦被命名，就从“模糊的挫败感”变成了“可移植的经验”。你今天在图片分类上积累的“必须明确色彩空间和边界规则”这条经验，可以用到视频处理、数据可视化、甚至任何涉及主观美感判断的任务上。问题本质不是关于颜色的，是关于如何把人类认为不言自明的东西，翻译成机器可执行的约束。

vibe coding 大幅放大了写代码的速度，但没有自动放大工程判断力的积累速度。

代码可以在几秒内生成，但从错误中学会下一次不说错话的能力，仍然需要人主动去沉淀。修复对话是你花了时间和算力换来的经验切片，是你在跟 AI 协作时最诚实的思考痕迹——不是计划中的思考，而是被问题逼出来的、不得不发生的思考。

下次你花半小时修复完一个“怎么又偏了”的问题，别立刻关掉窗口。那段对话不是废料，是你这个项目里唯一精准记录了你踩坑轨迹的工程文档。