Chef

这个页面是什么

发布在这个地址上的页面并不描述一个叫 Chef 的产品。它是 Convex 在论证：当编码智能体生成应用后端时，后端应该怎样表现才合适；值得读的是论证过程与证据，而不是功能清单。它的主张是，后端的默认值决定了智能体写出的代码是否安全，所以平台的选择比写代码的模型更关键。

它做什么

论证的核心是事务行为。Convex 的每次 mutation 都以可串行化事务运行，所以并发的智能体编辑不会把数据留在损坏状态里，这正是这个页面要解决的失败模式。为了说明这一点，公司跑了一次评测，让多个模型生成同样的十个应用，并且公开了评测仓库，这是其中最有用的部分，因为任何人都能重复它。页面点名了用到的模型并提供了材料，所以这个主张至少是可被检验的。

适合谁使用

受众是用编码智能体生成应用后端、并且被「代码通过了评审却在负载下出问题」坑过的团队。它适合要决定统一用哪个后端的工程负责人，也适合希望生成器的产物是失败得很安全、而不是无声地失败的人。

需要留意什么

这个对比由厂商自己跑，正确的读法是把它当成关于默认值的陈述，而不是关于哪个工具更胜出，所以把这些数字当成进一步查看的理由，而不是可以引用的排名。要想清楚自动重试意味着什么。被重试的事务会重新执行，因此 mutation 里的任何副作用都会跑不止一次，除非你专门为此设计；在依赖那句安全主张之前，你应当先理解这个行为。

两点实用提醒。评测之所以可复现，是因为仓库公开，这是它最有力的地方；而这个论证其实是在讲「选一个事务能保护你的后端」，所以结论是一条供你自己判断的标准，而不是对某个产品的裁决，因为这个页面是在立论，证据留给你去验证，不是一个该无条件接受的结果。

在据此行动之前，先读那个公开仓库；如果这个主张对你的技术栈重要，就自己把评测跑一遍，因为厂商自己跑的基准测试只有在你有能力重复时才算数。再把事务保证与你今天用的后端权衡一下。写 mutation 时记住重试行为，因为页面描述的安全性依赖的是预期会跑两次的代码。把这页当作挑选后端的采购标准，而不是一个你要采用的产品，因为你真正选的是一组让智能体代码不会损坏你数据的默认值。