最新

Ariandel 是一种内存模型，其中每个堆对象都位于由作用域管理的区域内。作用域退出时以 O(1) 的时间复杂度重置区域——只需一次指针写入和一次释放，无论分配了多少对象。 安全默认：分配函数返回 ARENA_PTR 句柄（打包的 arena_id 和偏移整数），而不是原始指针。在函数返回边界处，默认情况下无法构造悬空指针。跨作用域的生命周期延续是显式的——在分配之前，你需要通过 SCOPE(ptr) 进入目标区域，这样对象就会被路由到外部区域，而不转移所有权。 基准测试（未启用优化标志）：100 万节点树的清理时间从 31 毫秒降至 1 毫秒（约 30 倍）。在紧密的内循环中确实存在回归（约 0.76 倍），因为 DEREF 无法像编译器那样提升基指针——规范对此进行了诚实的记录。 这是一个基于 C 宏的内存模型概念验证，目标是用于编译语言。值得关注的问题不是 C 实现本身，而是作用域结构化的区域路由是否可以作为垃圾回收和借用检查的合理替代，适用于重要程序类别。 代码库：<a href="https://github.com/hollow-arena/ariandel" rel="nofollow">https://github.com/hollow-arena/ariandel</a> — SPEC.md 包含完整模型，包括并发语义以及与 Tofte 和 Talpin 基于区域的内存的比较。

我正在使用Claude来维护一个代理循环，该循环在重要工具调用之前会暂停以征求用户的批准。在进行一些错误修复时，我发现了一些明显的模式和原因，为什么对没有技术知识和架构专业知识的人来说，Vibe编码可能会失败。 首先让我描述一下我的工作流程——这是我在数百个成功会话中的工作流程： 1. 通过自我测试识别错误 2. 请Claude代码调查代码库中的三个潜在根本原因 3. 将根本原因和建议的修复方案粘贴到Claude项目中，我在这里存储所有架构文档和设计决策，以便让其评估 4. 与Claude在项目中讨论，撰写详细的任务规范——任务规范将具有指定格式，并包含各种测试 5. 将其交还给Claude代码以实施修复 在今天的会话中，根本原因分析仍然很出色，但建议的修复方案却糟糕透顶，我真的认为这就是大多数Vibe编码项目在长期内失去可维护性的原因。 以下是两个根本原因和建议的修复方案： 错误：代理请求用户批准，但有时批准弹窗不会显示。我尝试发送消息以解锁它，消息却被默默吞掉。代理看起来像是死掉了，我不得不重启整个系统。 Claude的评估： 根本原因1： 批准弹窗通过实时连接发送一次。如果用户的界面在那一刻没有连接——页面刷新、手机后台运行、不稳定的连接——他们就永远看不到它。没有重试，没有恢复。 这实际上是正确的。 建议的修复： “让我们将批准状态保存到磁盘，以便在崩溃后仍然存在。”听起来不错，但关键在于设计，如果发生崩溃，代理将从会话日志中冷启动，而无论如何不会获取批准状态。这个修复只增加了架构复杂性，完全没有用。 根本原因2： 当批准被中断（守护进程崩溃、用户重启）时，会话历史中会出现一个孤立的工具调用，但没有匹配的工具结果。 建议的修复： “写一个合成的工具结果，以保持会话文件的结构有效。”听起来很干净。但我问：谁实际上会因为这个而出错？是LLM API吗？不，它可以处理缺失的结果。会话重放呢？不，它读取现有内容。孤立的工具调用准确地表示了发生的事情：工具被调用但从未完成。这才是事实。写一个虚假的结果来掩盖它引入了新的写协调问题（到底什么时候写虚假结果？如果在写入期间守护进程崩溃怎么办？）来解决一个并不存在的问题。会话文件并没有“损坏”，它是准确的。 Claude拥有完整的架构文档、代码库以及上下文中超过一百个会话的项目历史。它仍然选择复杂的解决方案，因为它看起来像是良好的工程。它从未问过“重启后这是否重要？” 我个人多次遇到这种对看似更强大过度工程的偏好。我真心相信，这正是人类操作应该介入的地方，而不是仅仅给出一句话的需求，然后看着代理进行各种“稳健”的工程。