Vibe Coding 知识交接复盘:把一次任务沉淀为下一次可用规则
合并后只留 PR 链接,下一位开发者仍会重复探索、误用旧 Prompt。本文用事实交接、无责复盘、规则候选和冷启动演练,把一次任务转成可维护知识。
本文要点
- 主题聚焦:AI、Vibe Coding、DevOps、开源
- 适合人群:独立开发者、全栈工程师、AI 应用开发者
- 核心价值:快速理解背景、实践路径、常见误区和工程建议
一个 Vibe Coding 任务合并后,最容易留下两种无用遗产:一段“已经搞定”的聊天总结,或一份按时间罗列所有 Prompt 的长文。前者没有边界,后者没有优先级。几周后另一个人仍要重新寻找构建命令、重试被否定方案,并猜某条测试为什么存在。交接复盘的目标不是保存更多文字,而是降低下一次正确行动所需的未知量。
它不替代进行中任务的Agent 到开发者接管检查点或跨会话重启摘要:那两者冻结未完成现场。本文只处理一个切片已被接受之后,团队如何提炼事实、决策和可复用防线。它也不是泛化的团队文化或个人知识库教程。
先交接“现在是什么”,再解释“经历了什么”
接收者首先需要当前事实页:完成的用户结果、最终 commit/PR、变更的公共合同、迁移和配置、验证入口、已知限制、回滚或支持入口,以及仍有 owner 的后续项。所有内容引用仓库路径和当前 revision;不要把“当时测试通过”写成永久事实。
然后附一份决策差量,只保存会影响未来选择的内容:选择了什么、拒绝了什么、当时证据与约束、什么变化会触发重审。普通调试尝试不必全部晋升为 ADR;只有架构、数据、权限、外部合同或高成本可逆性决策才需要长期记录。规格变更与重新验收已经保存正式承诺变化,复盘只链接它,不复制另一份容易漂移的版本。
复盘围绕证据,不围绕谁写了坏代码
Google SRE 的 postmortem 实践强调从事件中学习并避免责备个人。开发任务虽不一定是事故,也可采用同样结构:预期发生什么;实际观察到什么;哪些控制及时发现偏差;哪些信号误导;AI 在哪里减少重复劳动,在哪里补齐了错误假设;什么系统条件让问题容易发生。
避免写“Agent 太笨”或“reviewer 不仔细”。改成可行动事实:“任务上下文没有声明 API 版本,Agent 根据旧调用方生成 v1;契约测试在本地默认跳过,PR 包未披露 NOT_RUN。”前一句无法改变,后一句能转化为指令、测试和证据门。没有真实运行或记录支持的推测标为假设,不为复盘完整性编造根因。
一次 30 分钟复盘可回答五问:
- 哪个未知最晚才暴露,为什么入口工件没显示?
- 哪项 AI 建议被采纳或拒绝,依据是否能复查?
- 哪个验证真正阻止了错误,哪个绿色信号没有约束行为?
- 哪段知识只存在参与者脑中或私有 Prompt?
- 下次同类任务,最小应新增、修改或删除什么工件?
每条学习只能进入一个合适归宿
不要把全部结论堆进 README。按用途路由:跨任务硬边界进入共享仓库指令;可机器判断的错误进入测试、lint 或 CI;重复操作进入 runbook;高成本设计取舍进入 ADR;一次性现场留在关闭任务;尚未验证的改进进入有 owner 的 backlog。相同信息只设一个规范来源,其他位置用链接。
规则候选先写触发、动作、例外和验证,例如:
trigger: 修改 packages/sdk 的公开响应类型
required: 运行 consumer-contract 并附当前 head 回执
exception: 仅注释变化,由 sdk-owner 说明
evidence: scripts/verify-consumers.ts
owner: sdk-maintainers
reviewAfter: 2026-10-30
“以后注意兼容性”不算知识。规则也应有到期或复核条件;工具链已改变、风险被自动门禁完全覆盖后,删除重复指令。GitHub 的 issue 和 pull request templates 能提示贡献者提交必要上下文,但模板字段必须服务真实决策,不能积累成无人阅读的仪式。
用冷启动演练完成交接
让未参与任务的人从干净环境只读当前事实页和规范来源,完成三个动作:定位修改入口;运行一条关键验证;解释一个被拒方案为何当前不适用。记录他提出的问题、使用时间和误判点。若还需原作者翻聊天、提供本机文件或口头解释,知识没有完成交接。
演练发现缺口后,修正对应单一来源,再让第二位接收者复试。不要通过继续扩写总结来掩盖命令不可运行或路径已失效。异步评审证据包中的最终 generation 可作为事实索引,但评审材料中的临时截图和日志按保留政策处理,不自动进入长期知识库。
最后指定维护责任:谁在依赖升级、架构变化或事故后复核这条知识,谁能批准删除。任务 owner 对首次提炼负责,领域 owner 接受长期规则;无人接收的文档应留在任务归档,而不是假装成为团队标准。
一次有效复盘最终可能只新增一个失败测试、修改六行仓库指令并删除一段过时文档。衡量它的不是字数,而是下一位开发者能否少走一条已知弯路,同时仍能从证据理解规则为何存在。这样 Vibe Coding 的每次快速交付才会留下可复用判断,而不只是更多等待重新解释的代码。
Related