1. Vibe Coding 的失忆症为什么 AI 总在同一个坑里反复摔1.1 Vibe Coding 的爽与痛我决定认真琢磨 Vibe Coding 流程数据化这件事起因是一个特别尴尬的瞬间同一个下午我在三个不同文件里让 AI 编程助手修复同一类错误——外部接口返回的字段命名不统一。第一次修完它表现很好第二次稍微换了种写法又踩坑第三次干脆连我都开始怀疑是不是自己的描述方式有问题。翻看记录后我确认了一点每次会话一结束AI 对项目里的隐性约定、我个人的偏好、甚至它自己刚犯过的错误都会忘得一干二净。Vibe Coding 这个词现在很流行本质上就是你用自然语言描述意图AI 负责生成代码、改代码你在旁边导航、审查、纠偏。它让开发效率肉眼可见地提升但它有一个致命短板每次会话都是一次新的失忆开始。现实中的团队项目里我会有一堆写代码时应该注意的事但 AI 不知道我更希望它能从自己犯过的错误里总结教训下次主动避开可惜默认情况下它做不到。1.2 真正的问题不是模型不够聪明而是没有复盘刚开始我以为是模型能力问题后来发现不是。你把同一个错误描述得再清楚只要换一个会话、上下文里没有对应信息它大概率还会以不同姿势再现。问题出在没有反馈闭环AI 生成的代码、测试失败的结果、你手动修正的动作这些信息全部散落在各种工具日志和你的记忆里模型永远看不到。人类带新人是靠复盘和错题本成长的AI 的开发流程里缺的正是这套机制。常规替代方案是手动写代码规范、维护一份长篇提示词文档但我试了一段时间后发现维护成本极高。规范文档写归写AI 实际生成代码时根本不会主动去对照而且文档越长越容易被模型忽略。1.3 我的思路三件事串联让 AI 有错题本所以我把整套流程拆成三件事对应本文的三个部分流程数据化把一次 Vibe Coding 会话过程中发生了什么系统性记录下来形成结构化数据规则提炼从这些数据里沉淀出这类错误下次应该怎么避免的规则按一定格式存进规则库规则回流在下次会话开始前把相关规则动态注入给 AI让它在工作之前先看到过去的教训。这个思路不算新本质上是给 AI 编程流程加一条反馈回路。但真正落地的细节很多数据从哪来、规则怎么写、怎么注入才不会变成一堆废话每一步都有门道。接下来的内容适合正在重度使用 AI 编程助手的人也适合想给团队搭建一套统一 AI 工作流的开发者。2. 流程数据化先给每次会话做体检才谈得上让 AI 学习2.1 一个最小数据模型四类事件缺一不可要建立反馈闭环第一步不是立规则而是搞清楚一次会话里到底发生了什么。我把一次 Vibe Coding 会话拆成四类事件这四类事件基本能覆盖从意图到产出再到修正的完整链路事件类型含义关键字段记录时机意图事件你给 AI 的任务描述、附带的参考文件描述文本、涉及文件、会话阶段每次发送请求时生成事件AI 产出的代码、改动、文件操作文件路径、操作类型、代码块摘要每次生成结果返回时检验事件测试、编译、静态检查的结果检查类型、通过/失败、失败信息自动触发反馈事件你对结果做的修正动作与评价修正类型、评论标签、重写代码手动标记或代码变更时为什么一定要这四类因为少了任何一块后面提炼规则都缺依据。比如你只记录错误日志不知道当时 AI 是怎么被要求的就很难定位是描述不清还是模型乱来你只记录生成代码不知道随后被你怎么改的就不知道真实答案是什么。2.2 一条真实会话记录长什么样我用的存储格式是最朴素也最实用的 JSONL每行一个事件所有事件按时间排序用session_id串起同一次会话。这样无需引入数据库普通文本文件就能分析也方便后续做规则提取。一条记录长这样{ ts: 2024-11-17T14:23:01Z, session_id: s_8f21, event: intent, payload: { prompt: 把用户列表接口改成分页返回注意保持旧字段兼容, ref_files: [src/api/user.go], stage: modify } }同一会话里的生成事件和反馈事件通过session_id和ts关联起来。我的习惯是每次反馈事件里用一个tag字段标上语义标签比如schema_break、missing_error_handling、logic_reverse。这些标签后面就是规则提炼的关键索引。2.3 采集层如何搭建不依赖特定编辑器的轻量方案很多人一听数据化就头疼觉得要把 AI 工具内部日志扒出来才行。实际不用。我采用的是一个很轻的外部采集方案完全不侵入 AI 工具本体写一个监听脚本监控项目目录里的文件变更把文件路径 变更时间 变动摘要追加为生成事件在测试命令外面包一层脚本自动读取测试结果失败时把断言信息存成检验事件每次 AI 生成结果后我手动或通过快捷键附带一句评价比如tagschema_break、note字段名不一致程序把这句话收集为反馈事件所有事件统一写入date.jsonl文件按天分文件避免单个文件过大。这套方案两个要求一是及时事件发生的当下就记录不要事后补二是不二次加工AI 的原始输出、测试的原始报错有什么记什么分析工作在后续单独做。做到这两点数据才有价值。3. 规则提炼把错误教训变成可执行约束的关键一跳3.1 错误分类先给问题定级规则才有针对性收集回来的数据是原料直接拿去给 AI 看效果很差。我发现必须先做一层错误分类把问题归拢成几类再为每个类别设计对应规则的写法。从我自己项目的命中统计来看Vibe Coding 场景下的高频错误集中在四类错误类型典型表现适合生成的规则模板语法/API 误用接口参数顺序错、方法不存在当使用 X 接口时必须按照 Y 签名传入参数接口契约破坏改了返回值调用方没同步修改公共函数签名前必须同时更新所有调用处业务逻辑颠倒把 A、B 分支写反条件判断方向反了该判断条件的优先级是先校验权限再校验数据上下文假设失误误以为某个字段一定存在、缓存一定有效读取配置字段前必须先判断是否为空分类的价值在于不同错误类型规则表述的姿势完全不同。接口契约类适合硬约束业务逻辑类适合给场景说明上下文假设类则要带上为什么这样做的原因AI 才更容易在决策时真正用上。3.2 从错误到规则人工总结与自动归纳结合我就测试过许多次等 AI 连续错误然后手动把规则提炼出来把这类教训重述给 AI 听效果几乎为零。光靠提醒不够规则必须落在条件明确、动作明确、原因明确的格式里。我常用的规则模板是当 [触发条件] 时必须 [动作约束]因为 [失败原因]。举例一条沉淀下来的真实规则当调用 user_service.GetUserList 方法时必须传入 page 和 pageSize 参数 不要依赖旧的无参版本因为该函数已经改为分页协议缺失参数会返回 400。生成规则的方式我建议半自动先让程序把同一tag、近因明显的错误事件聚合成候选再用 AI 模型把这类事件总结成一条规则草案最后人工审核后移入正式规则库。审核这一步不要省模型总结的规则有时候会过度泛化把一次偶然错误变成一刀切的约束。3.3 规则库维护版本、冲突与淘汰规则库存储我仍用 JSONL每条规则增加一批元信息{ rule_id: r_104, version: 3, status: active, scope: [src/api, src/internal], trigger_count: 12, last_hit: 2024-11-02T10:00:00Z, condition: 调用 GetUserList 时, action: 必须传入 page/pageSize, reason: 无参版本已废弃返回 400, source_session: [s_811, s_913] }规则库不能只进不出否则几个星期后就会膨胀到没法用。我的维护节奏是版本化规则逻辑被推翻时要新增版本而不是直接改原文保留历史供追溯冲突消解两条规则条件重叠但动作相反时给它们标记conflict_need_review并优先展示源事件与触发次数更高的一条淘汰降级连续一个月没有任何命中的规则自动降为suggest态不再强制注入只作为可参考建议。没有这套维护机制规则库会变成另一个失忆源——AI 记住了太多旧教训反而不知道当前关注什么。4. 规则自我进化的回流机制让规则在下一次会话里自动生效4.1 注入时机与位置选择规则提炼出来只是半成品真正让 AI 从错误中自动学习的是回流机制。我试过几种注入方案从效果来看差别很大方案一全量注入。把整个规则库拼进提示词。直接失败上下文窗口全被规则占满AI 的核心任务反而被稀释。方案二仅会话开始时注入。有点效果但 AI 中途遇到不相关规则覆盖的场景时还是容易跑偏。方案三动态加载 时机触发。每次对话开始前只加载与项目、当前涉及文件相关的规则如果这次会话涉及了某个特定的接口或模块再追加对应规则。这个效果最好。我最终采用的是方案三。它背后的道理很简单规则的作用粒度不是整个项目而是某类动作、某个文件、某个函数调用。只有在那类动作即将发生时对应规则才有价值提前堆给 AI 只会提高噪声。4.2 规则优先级相关性优先高频优先动态加载时我写了一个简单的排序器核心逻辑是三层加权文件范围匹配规则scope包含了当前会话涉及文件权重最高触发频率trigger_count越高的规则说明越容易踩坑优先注入最近命中last_hit越近说明这个坑最近还在发生时效性更强。排序之后我并不是把所有规则都丢给 AI而是严格限制注入条数。个人经验是每次追加 5 到 8 条规则已经是上限再多 AI 就开始选择性忽略。真遇到冲突规则我会特意在提示词里注明这两条规则存在冲突请 AI 在生成代码时主动询问而不是自行断言选哪边。4.3 回流实现的一个可行模板具体到脚本层面前面几项建议可以拼装成一个非常简单的命令# 生成当前会话的规则摘要 rules$(cat rules.jsonl | jq -r select(.statusactive) \ | python3 rank_rules.py --files src/api/user.go \ | head -8 | jq -r .action .reason ) # 把摘要注入到 AI 会话前的系统提示词 echo [历史规则] 本次会话请优先遵守以下项目经验 /tmp/rules_prompt.md echo $rules /tmp/rules_prompt.mdrank_rules.py做的事情就是把上一节的排序规则写成几十行代码输入当前涉及文件、输出按优先级排列的规则列表。注入时我还会同时附上源事件里的典型失败代码片段让 AI 知道上次这么写炸了。只给规则不给反例AI 往往理解不了约束的紧迫程度。回流跑通之后我发现一个正反馈效果一旦 AI 在生成代码时避开了某个历史错误规则里对应的trigger_count会下降长期不命中的规则慢慢降级出活跃区新出现的错误又会被数据化后提炼成新规则补进来。整个规则库确实像一个自我进化的系统。5. 跑通闭环之后的实测体会与几条生存经验5.1 规则会膨胀要学会做减法流程跑通两周后我最直观的感受是错误率确实下降了但规则库从 30 条膨胀到了 180 多条然后效果反而开始下降。AI 在生成代码时明显变得束手束脚有些简单逻辑因为背上太多历史规则而写出了冗余判断。后来重做保洁才明白一个道理规则的价值在于约束关键路径不是约束所有路径。我给自己设了几条红线同一个 API 的规则最多保留 3 条优先级低的直接降级一次会话里如果新增规则超过 5 条说明分类粒度太细需要合并每月做一次规则淘汰把只命中一次的错误移出活跃规则库但保留在历史数据里。5.2 上下文窗口是硬约束注入要有预算规则注入腾挪空间其实非常小。AI 编程助手的上下文窗口固定你塞了规则留给代码和真实需求的 token 就少。我用 token 计数把每次注入的规则总长度控制在 2000 字符以内超过的部分用摘要模式——只保留条件和动作省略原因。实测下来保留精简后的 5 条规则 2 个典型反例比保留 10 条完整规则效果更好。典型反例要让模型直观地看到错误后果这比抽象规则有力得多。5.3 别让规则变成AI 的枷锁也要防个人经验绑架团队另一条重要经验是关于人的。规则回流机制跑顺手之后我一度陷入什么错误都想沉淀成规则的冲动。后来同事提醒我不是所有错误都值得长期约束。有些错误是一次性的、跟当时业务决策强相关这种事沉淀成规则反而会误导后续开发。这也牵出一个团队协作层面的问题如果规则库是个人私有库你每次回流的都是自己的偏好和踩坑记录一旦进入团队协作别人面对这些规则可能会懵。我的建议是给规则加一个owner_team字段团队共享的规则走评审个人规则仅在个人会话生效避免一套个人经验绑架整个团队。5.4 接下来值得做的两件事闭环跑通后我还有两个自己正在尝试的扩展方向。一是用修正操作反推规则候选每次你手动改写 AI 代码时diff 本身就构成一份极好的训练数据可以自动生成AI 建议 vs 人工正确版的对照再结合测试结果确认提炼规则候选的过程可以进一步自动化。二是生成规则演化周报每周对规则库的命中情况、新增规则、淘汰规则做一次汇总这能直观看出这个自我进化系统到底在朝哪个方向进化。我在实际使用中最深的体会是所谓让 AI 从错误中自动学习本质不是让模型动态更新权重而是让流程具备记忆能力——把一次会话产生的教训转化成下一次会话开始前可被检索、可被注入的结构化规则。这套方案不一定精致但足够直接是任何用 AI 写代码的人都能自己搭起来的东西。