我们每天都会失败，但那次失败会成为我们下一次尝试的成功（feat. Claude Code）
I’m happy to translate the article for you, but I’ll need the full text of the post. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and technical terms.
失败重复
不久前，我负责的一个服务发生了生产事故。
一个由 SQS 触发的 Lambda 处理程序处理了单个事件，却在并行中产生了过多的 DynamoDB 事务。最终，Lambda 达到了超时时间限制。
这提醒我们，基于 Promise 的并行并不总是最佳方案。I/O 密集型工作负载有时需要并发控制，甚至需要顺序执行。代码在逻辑上看似正确，却在真实的资源约束下失效。
我在一个玩具项目中也有类似经历。内存持久化层在本地环境运行完美，但部署到基于云的 Docker 环境后，一致性测试失败。根本原因是设计中存在状态性，而容器实例在每次请求时可能会变化。
这两起事件教会我们的不仅仅是简单的 bug 修复：
- 代码可能在逻辑上是正确的，但如果忽视了执行环境的约束，系统最终会崩溃。
- 这些经验教训显然对未来的项目大有裨益。
每一次失败都会导致成功吗？
我们每天都会失败。我们会遇到 bug，做出错误的假设，并且在性能问题上苦苦挣扎。
成为高级工程师往往意味着累积这些经验，直至它们转化为直觉。运营事故、扩展失败以及有缺陷的架构决策会逐渐形成一种“某些事情感觉很风险”的感受。
然而，实际上，并非每一次失败都会转化为未来的成功。许多教训从未被记录，也从未被重新审视，类似的错误会在不同的情境中再次出现。
问题不在于失败本身。问题在于失败消失了。
Source: …
Dev Sentinel：检测与保留失败
Dev Sentinel 源于这样的观察。核心思路很简单：检测失败循环、记录它们，并在类似情形再次出现时呈现出来。
我将失败定义为一个循环：尝试 → 挫败感 →（放弃 | 解决）。
在这个循环中，我设计了两个概念。
1. 经验捕获
检测到挫败感后，追踪该尝试是以放弃还是解决结束，并将其存储为一次经验。这不仅仅是日志记录；它对上下文进行结构化：问题是什么、困难出现在哪里、以及如何结束。
2. 主动回忆
当再次检测到类似的挫败感时，展示相关的过去经验。目标不是自动解决问题，而是提醒开发者：“你以前已经遇到过类似的情况。”
为实现这一点，Dev Sentinel 利用 Claude Code 的 UserPromptSubmit 与 Stop 钩子。
- 在
UserPromptSubmit期间 – 检测挫败感的信号（用词、重复尝试、上下文切换等）。 - 在
Stop期间 – 判断失败循环是否已经结束，并存储结构化的经验。
如果 Dev Sentinel 曾经存在会怎样？
回顾之前的事件：
- Lambda 超时，原因是并行度过高
- 容器化环境中的有状态设计失败
这两者并非单纯的实现错误；它们共享一个模式：低估了环境约束。
如果 Dev Sentinel 当时已经存在，那么在后续项目中：
- 在设计高并发处理逻辑时
- 在随意引入内存缓存时
它本可以把过去的经验呈现出来作为提醒：不是直接给出答案，而是询问：“你之前见过这种模式失败吗？”
Between Organizational Runbooks and Personal Memory
许多组织通过运行手册、标准作业程序（SOP）、维基和知识库来降低故障率。这些方法非常有效，但组织知识并不总是能与个人情境完全匹配。
Dev Sentinel 采用相反的方向：
- 首先捕获个人的故障经验
- 随时间累积这些经验
- 在相关时将其返回给个人
期望是，累积的个人经验能够提升设计判断力，而这种判断力最终会影响项目和组织。
结束语
我们每天都会失败。但失败并不会自动转化为资产。未被记住的失败会被重复。
Dev Sentinel 并不是一个宏大的 AI 系统。它是一个小机制，防止失败悄然消失。今晚是一个很好的时机，去反思今天的教训是什么。
Git repo: