失败记录能不能成为产品的一部分？

整理 GitHub README 时，我发现一个有点尴尬的现象：项目做得越久，README 反而越像项目刚开始时写的。

它会告诉别人项目有什么功能、用了什么技术、怎么启动，却很少留下那些真正花时间的东西。为什么架构后来变了，哪个方案试过但不行，某个看起来奇怪的限制是怎样出现的。

最后展示出来的是一栋已经盖好的房子，脚手架、返工的墙和画废的草图全被清走了。

我们为什么习惯隐藏失败

一部分原因很现实。README 要让人快速理解和运行项目，写太多过程会干扰主线。另一部分原因可能是学生项目总带着被评判的压力，我们希望每个技术选择都显得早有计划。

但我自己的项目并不是这样长出来的。

AI Postman 一开始最吸引我的是“每天自动整理信息”，真正做起来才发现，最难的不是总结，而是什么时候宁愿不发。Offer 决策工作台最初想给一个明确答案，后来才把重点移到证据和待核验问题。小说转剧本的流程也不是一次设计完成，而是在长任务、连接池和页面假死这些问题出现后，才逐渐拆成队列、短事务和 SSE。

如果只保留当前功能列表，这些项目最有价值的部分就消失了。

失败不等于故障列表

我说的失败记录，不是把每个 bug 都抄进 README。真正值得留下的，应该是改变了理解的尝试。

原来的假设：模型调用失败时，用模板摘要兜底，至少能准时发邮件。
实际结果：邮件按时到了，但内容不值得打开，准时失去了意义。
现在的选择：最终整理失败时不发送，并明确记录失败原因。
仍未解决：如何在可靠送达和内容质量之间找到更细的降级方式。

这四行比“支持多级降级”更能说明系统为什么长成现在这样。它也让后来的人有机会继续推翻当前结论。失败记录不是给旧方案立碑，而是把推理过程留在现场。

如果产品自己能保存创造过程呢

我还想到一个更激进的方向：不只在 README 里人工总结，产品能不能原生记录自己的演化？

AI 工作流每次运行时已经产生了大量轨迹：输入、工具调用、中间结果、人工修改、重试和最终输出。大多数系统把这些当日志，出了问题才看。如果把其中一部分整理成可阅读的 build log，用户也许能看到一个结果是怎样被共同做出来的。

当然，这很容易变成另一种信息垃圾。完整链路可能包含隐私，模型思考也不等于可靠解释。真正要设计的是哪些节点值得保留，以及谁有权决定它们是否公开。

我还没做这个功能。现在能先做的很小：给每个原创仓库留一个“转折点”或“没奏效的尝试”章节，让项目不再假装自己从第一天就知道答案。

完整的项目让人知道它能做什么。留下缝隙的项目，可能更容易让人想到下一步还能做什么。