OpenAI研究者通过AI自动化自身工作，但LLM虽出色却存在不精确、非确定性的缺陷。解决方法是结合快速、确定性的工具，并构建形式化工作流，而非依赖AI独立完成复杂任务。

根据您提供的英文内容，以下是中文重述版本，保留了核心细节并删除了与主题无关的内容：

标题：自动化“自我淘汰”

A. Karpathy 曾指出，OpenAI 的研究人员通过改进AI，实际上是在“自动化自己”。目前，我正使用Anthropic的Fable模型开发Beagle SCM。这个模型非常出色，能在一大堆代码中找出问题、提交工单并进行修复。但昨天，它两次将build/目录错误地提交到了项目中。它很聪明，却也很笨拙。

由于大语言模型（LLM）的本质，这个问题不会随着技术进步而消失。它们往往不精确且非确定性。相比之下，像Ragel这样的解析器生成器能瞬间生成一个10千行代码、形式上完全正确的解析器，且结果确定。而Claude呢？我的指令明确用大写字母写着：永远不要手动解析任何东西。因为手动解析既痛苦又容易出错。但它还是会尝试，所以我得定期让它扫描代码库，找出并删除任何手动解析的尝试。这基本有效。

它越来越聪明，但笨拙依旧。

处理这种昂贵、缓慢、笨拙却聪明的LLM的方法是：给它快速、强大且确定性的工具，并将整个流程构建成确定性的正式工作流。让它更快，在正确的时间看到相关内容，减少笨拙，并实现自我修正。将聪明但不一致的非确定性夹在强大的确定性工具和同样正式的流程之间。

如果让这些工具和流程变得可塑，故事会更有趣。这样，如果Claude频繁执行某些操作，我们就将其自动化；如果它在某件事上反复失败，我们就自动化验证步骤。

本质上，我们让LLM自动化自己，转而使用简单可靠的确定性工具。

Beagle SCM允许LLM用JavaScript编写自己的脚本。所有繁重的工作都在C中实现且很少改动，而工具层（三明治的下层）和工作流层（上层）都是JavaScript，并从文件系统中加载代码，类似node_modules的方式。想象一下，git钩子可以解析几乎所有语言的源文件、检查文件历史和提交历史、交叉验证链接，并访问git内部能触及的任何数据。这就是Beagle。

（注：原文中的图片链接和部分技术细节（如Ragel、libdog、beagle-ext等）已保留，但删除了与主题无关的图片描述和部分冗余表述。）

根据评论内容，总结主要观点如下：

核心共识：应优先使用确定性系统，将LLM限制在辅助角色 - 多位评论者强调，应避免让LLM直接处理确定性任务，而是将其作为生成确定性流程或代码的工具（评论2、8、11） - 关键引用：stego-tech "why the fuck are we handing deterministic processes to probabilistic systems"；mchusma "we prefer deterministic software as the solution first, followed by LLMs, followed by humans"

实践方法：构建中间层与验证循环 - 通过抽象层（如DOM简化、Roslyn API）减少LLM直接操作的不确定性（评论9、8） - 需要自验证循环确保输出质量（评论10） - 关键引用：bob1029 "semi-automation with contextual and domain-specific tooling is the key"；orbital-decay "This needs a self-verification loop"

对文章内容的质疑与补充 - 部分评论认为文章缺乏具体实践案例（评论3、4） - 指出非确定性问题的根源在于自然语言本身，而非模型输出随机性（评论10） - 关键引用：derdi "I'm somehow missing the actual blog post"；orbital-decay "that has nothing to do with non-determinism the author is talking about"

对过度使用LLM的批评 - 有评论认为用LLM替代简单脚本是过度工程化（评论6） - 强调应尽快将LLM抽象出流程，避免依赖脆弱系统（评论2） - 关键引用：vinceguidry "It would have never occurred to me to repeatedly invoke an LLM to do what a simple script could"；stego-tech "LLMS should be abstracted out of a process as soon as practicable"