用 Makefile 和 fork() 写提示词：1680 次 A/B 测试揭示的 AI 代理可靠性真相

核心洞察

这篇文章最有意思的地方在于，它把提示词工程从“写作文”拉回到了“写代码”的轨道上。作者用 1680 次 A/B 测试的数据说明了一件事：大模型对 Unix 老古董的熟悉程度，远超你精心设计的自定义规则。如果你正在维护一份超过 500 行的 CLAUDE.md 或者 .cursorrules，这篇文章可能会让你想推倒重来。

核心结论

1. 在 1680 次配对 A/B 试验（覆盖 4 个模型层级、4140 万 token）中，用 15–40 token 的经典计算机科学形式化方法替换 300–600 token 的英文散文规则，在所有 10 项指标上均取得统计上决定性的提升（p < 0.0001）。

2. 断路器状态机（替代散文式"重试 2 次后停止"）将终止道歉/重试循环的成功率从 0.8% 提升至 98.3%（+97.5 个百分点，z = 15.11）。

3. 采用 SysV /etc/init.d 式词法锁存（替代单一 PROGRESS.md）后，智能体在 23 万 token 上下文压缩后的不变量存活率从 0.8% 提升至 60.0%，在 gemini-2.5-pro 上达到 96.7%。

4. 用 git bisect 替代散文式调试，隔离回归的成功率从 19.2% 提升至 81.7%，探测次数 ≤ 4 次，在 gemini-3.1-pro 上达到 100%。

5. 自定义提示词 DSL（如 [CRITICAL_EXECUTION_PROTOCOL]、!N1_LOOP）在预训练语料中的出现频率约为零，模型不得不用脆弱的工作记忆注意力头实时模拟解释器，这是上下文增长后顺序失忆与门控跳过的根本原因。

为什么花 2000 个 token 用英文散文解释依赖图、进程隔离和崩溃恢复，而 make、fork() 和 /etc/init.d 早就刻在模型权重最深的峡谷里了？

“那些不理解 Unix 的人，注定要拙劣地重新发明它。”
—— Henry Spencer，Usenet comp.unix.wizards（1987 年 11 月）

别再往 CLAUDE.md、GEMINI.md 或 .cursorrules 里塞 2000 行的英文提示词小作文了。每次你发明一个自定义的 20 步检查清单，或者搞出 [CRITICAL_STEP_4_GATE] 这种方括号伪代码标签，它在模型预训练语料里的出现频率就是零（Freq ≈ 0）。这等于逼着大模型烧掉它那点脆弱的工作记忆注意力头，去模拟一个它五秒钟前才第一次见到的语言的解释器。

每个前沿大模型的权重里，都沉睡着整整五十年的 Unix 和计算机科学形式化方法——Makefile、/etc/init.d、fork()/wait()、RFC 822、RFC 5234 EBNF、契约式设计、两阶段提交、断路器、git bisect——这些东西模型在预训练期间见过几百万次（Freq > 1,000,000）。提示词工程最有效的形态是静态符号链接：一个 20 token 的 Unix 原语，调用的是模型已经花了一亿美元编译进深层前馈权重里的久经考验的 C 库。

在 151 个生产工单（第三部分 3.6 和 3.7）以及一个 1680 次试验的多模型 A/B 实验室基准测试（在约 16000 token 的真实编译器/差异干扰负载下跑了 4140 万 token）中，用 20 token 的经典计算机科学形式化方法（短了 15 到 50 倍）替换 500 token 的英文规则，在各项指标上都带来了巨大的、统计上决定性的（p < 0.0001）飞跃：

• 终止道歉/重试循环（断路器状态机 vs 散文式“重试 2 次后停止”）：0.8% → 98.3%（+97.5 个百分点，z = 15.11）
• 在 23 万 token 压缩脑叶切除术后存活（1983 年 SysV /etc/init.d vs PROGRESS.md）：整体 0.8% → 60.0%（在 gemini-2.5-pro 上达到 96.7%，+59.2 个百分点，并且两次真实的 23 万 token 压缩零步骤丢失）
• 隔离回归（git bisect vs 在 16 阶段流水线上的散文式调试）：19.2% → 81.7%，探测次数 ≤ 4（在 gemini-3.1-pro 上达到 100%，+62.5 个百分点）
• 在真实 dart test 运行中杀死异常路径变异体（@requires/@ensures + QuickCheck vs “测试边界情况”）：通过率 1.7% → 60.0%（在 Pro 模型上达到 100%，在 3.1-pro 上杀死了 93.3% 的变异体）
• 原子化多包重构（2PC + WAL vs “别把构建搞坏”）：45.8% → 93.3%（+47.5 个百分点）
• 严格暂停门输出语法（RFC 5234 EBNF vs 散文式格式规则）：32.5% → 77.5%（在 flash 和 pro 层级上达到 100%）

下面讲清楚为什么五十年前的系统原语能碾压现代提示词 DSL 的物理原理，以及今天就能塞进你 agent 技能里的十原语罗塞塔石碑。

1. 零频率解释器陷阱：为什么自定义提示词 DSL 会崩溃

随便翻开过去两年发布的任何一个“高级”系统提示词、.cursorrules 文件或 agent 框架。你会看到开发者们在从零开始发明定制的、自然语言式的领域特定语言，或者自定义的伪代码方括号记法：

<!-- 典型脆弱提示词 DSL（预训练频率 ≈ 0） -->
[CRITICAL_EXECUTION_PROTOCOL]
1. 首先，分析仓库并写下你的发现。
2. 其次，创建一个计划并等待用户批准。
3. 重要：在步骤 2 被批准之前，不要写代码！
4. 批准后，先写一个失败的测试。
5. 实现代码并运行测试。
6. 如果测试失败：你必须回到步骤 5 修复它，然后才能进入步骤 7！
7. 永远不要跳过步骤 6！

更糟的是，有些团队为了省 token，把英文规则压缩成自创的符号简写——比如这个在 Google AI 开发者论坛上提出的“Agent 原生中间表示”：

[DB: SET_BASED(TVP|XML_SHRED) !N1_LOOP]

为什么大模型会不可避免地漂移、跳过步骤 6、忽略 !N1_LOOP，或者在对话达到 8 万 token 时忘记步骤 3？

正如开发者 Dean Lee 在第三部分 3.6 的评论中观察到的：

“当一个 agent 在内存中管理一个命令式的 20 步检查清单时，它运行的是一个没有对冲的马尔可夫链，工具输出的每一个 token 都会增加状态转换错误的概率。操作者最终支付前沿推理费率，只是为了看着 transformer 模拟一个脆弱的内部指令计数器。”

在机器学习研究中，多项实证研究（包括 Razeghi 等人和 Kandpal 等人）已经证明了一个基本的缩放定律：大模型的零样本执行可靠性，与该精确结构模式在其预训练语料中出现的次数呈对数线性关系。

当你发明 [CRITICAL_EXECUTION_PROTOCOL] 或 [DB: SET_BASED(TVP|XML_SHRED) !N1_LOOP] 时，你的自定义规则语法在预训练语料中的频率是多少？

大约为零（Freq ≈ 0）。（更糟的是，!N1_LOOP 仍然是一头赤裸的负面粉红大象——把单词 NOT 换成 ASCII 感叹号 !，并不会给 softmax 自注意力一个原生的否定算子！）

因为模型从未见过你的自定义英文状态机或方括号伪代码，它无法通过其深层、结晶化的前馈权重电路来路由执行。相反，它不得不在运行时用最浅层、最脆弱的工作记忆注意力头，为你的自定义语法模拟一个解释器。当上下文窗口被编译器日志和文件差异填满时，注意力被稀释（O(1/L)），模拟的解释器丢掉一个指针，你的 agent 就冲下悬崖了。

flowchart TD
    A["自定义 20 步提示词或自创 DSL\n（预训练频率 ≈ 0）"] --> B["模型必须在脆弱的上下文注意力头中\n模拟一个自定义解释器"]
    B --> C["上下文增长到 15 万 token\n注意力在各步骤间稀释"]
    C --> D["💥 顺序失忆与门控跳过"]

2. 预训练引力定律与灰胡子悖论：提示词即静态链接

现在考虑一下，当你删掉那篇 20 步英文小作文，改成这样写，会发生什么：

.PHONY: finish
finish: pr-merged

pr-merged: ci-green critic-review-passed human-landing-approval
	gh pr merge --squash

critic-review-passed: tests-green
	# 生成一个未预热的对抗性批评子 agent

为什么模型突然遵守了每一个依赖门控，而你根本没告诉它“永远不要跳过步骤 6”？

第三部分发出去之后，有个老运维在 Facebook 上留了条评论，一句话就把问题的社会根源点透了。他叫 William S. Duncanson，原话大意是：我把这系列分享给团队里几个搞 AI 的年轻人，他们压根没有我们这帮脾气臭的老系统管理员的经历。

想想这里面的荒诞感。2026 年一个 24 岁的提示词工程师，可能这辈子都没维护过 1976 年贝尔实验室风格的 Makefile一种构建自动化工具，用于定义任务依赖关系和执行规则，源自Unix系统。，没写过 1983 年的 /etc/init.dUnix System V启动脚本目录，用于管理系统服务的启动、停止和恢复。 启动脚本，也没手工拼过 1982 年的 RFC 822电子邮件头部的标准格式，定义了字段名和字段体的语法，广泛应用于互联网消息格式。 邮件头。他们不知道有这些东西，自然也不会想到去用。

但大模型全都读过。

基础模型在预训练阶段吞下了海量语料，里面包括五十年的 Unix 源码树、POSIX 标准、IETF RFC、Usenet 存档、Linux 内核邮件列表、O'Reilly 技术书和计算机科学教材。这些东西对模型来说不是陌生概念，是刻在权重里的肌肉记忆。

第三部分刚上线那会儿，最早反应的人里有一位叫 Dave Crocker。他是互联网名人堂入选者，RFC 822 的作者，那份文档 1982 年 8 月 13 日发布。停下来想想 RFC 822 意味着什么：为什么每个 Markdown 的 frontmatter 块（--- title: ... tags: ... ---），为什么我们 init.d 文件里那些结构化的 Key: Value 状态头（Current Target:、Last Completed Step:、Next Permitted Action:），在所有大模型上都能零样本稳定解析？因为预训练语料里的每一封邮件、每一个 HTTP 请求、每一条 MIME 消息、每一篇 Usenet 文章、每一段 YAML frontmatter，都直接继承自 Dave Crocker 1982 年那份 RFC 822 的语法：field-name ":" [ field-body ] CRLF。

第三部分之后紧接着发的另一篇，讲的是 200k token 上下文被压缩后如何用 init.d 和 Memento 模式让编码智能体活下来。文章刚上线，系统工程师 Mike Mol 就分享了他自己的多仓库智能体框架，nemik 和 mtools。他最早在 Facebook 上注意到了 stigmergy 这个概念的关联。看看 nemik 的 README 里那条核心设计原则：nemik 建立在现有标准之上，而不是自己发明一套追踪器。Mike 没有为协调独立仓库的智能体（他管这些叫“反抗军小组”，名字来自《安多》里的 Karis Nemik）发明一套专用的提示词 DSL，而是把工作流状态映射到 OASIS OSLC 变更管理 3.0（oslc_cm:ChangeRequest），把跨仓库的因果溯源（--caused-by :W）映射到 W3C PROV（prov:Activity、prov:wasInformedBy），把 DAG 完整性映射到 W3C SHACL（shapes.ttl），把对等消息传递（/inbox/）往 W3C ActivityPub 的 JSON-LD actor 语义上靠，把那些啰嗦的自然语言常驻规则抽干，变成 Claude Code 的 PreToolUse 钩子和 Open Policy Agent（OPA / .rego）策略，再用 Negative Witnesses（W231）去验证。我问他为什么这么设计，他用一句话把机制说透了：

“之所以这么依赖这些标准，一个主要原因是前沿模型的训练数据里都有它们，而且我能找到相关文献。我是有意把它跑成一个自创生框架的；系统的目的就是运行系统本身，我往这个系统里加任务。”

在预训练语料里，Stuart Feldman 1976 年的 Makefile 依赖图（target: prerequisites）、Dave Crocker 1982 年的 RFC 822 头（Key: Value）、AT&T 1983 年的 /etc/init.d 运行级别目录（00_... 到 99_...）、Ken Thompson 1971 年的 Unix 进程语义（fork()Unix系统调用，用于创建新进程，实现进程隔离和并发。、wait()、exit 0），以及 W3C、OASIS、CNCF 那些形式化规范（PROV、SHACL、ActivityPub、OPA Rego），出现的次数不是零。它们出现了几百万次（Freq > 1,000,000）。

flowchart TD
    E["Canonical Systems Formalism: Makefile / init.d / RFC 822\n(Pre-Training Frequency > 1,000,000)"] --> F["Static Linkage Into Deep, Pre-Trained\nFeed-Forward Weight Circuits"]
    F --> G["Working-Memory Attention Freed\nfor Actual Domain Code Synthesis"]
    G --> H["✅ Deterministic DAG & Compaction Survival"]

过去三年，AI 行业把提示词工程当成创意写作。但从物理层面看，提示词工程是静态符号链接。

你在智能体技能里写一个 Makefile、一段 RFC 822 头、一个 /etc/init.d 目录，或者一条 W3C SHACL / OPA Rego 策略，本质上是在链接一个久经沙场的 C 库。这个库，模型在预训练阶段已经花了一亿美元把它编译进权重里了。

3. 从假设到受控实验证明：十条潜在超级高速公路（N = 1,680 组配对 A/B 试验）

光靠轶事不够，得验证预训练引力在整个软件工程生命周期里是否都成立。我们在之前的生产数据（第三部分的 151 张工单，以及第四部分的 200k token 压缩生存实验）之外，补了一套受控的多模型 A/B 基准测试（tools/benchmark_pretraining_gravity.dart）：

• 规模：1,680 组配对试验（2,773 次 HTTPS API 调用，4,140 万 token），覆盖四个模型层级（gemini-2.5-flash-lite、gemini-2.5-flash、gemini-2.5-pro、gemini-3.1-pro-preview）。
• 认知负荷：每一次试验都先注入约 16,000 token 的真实编译器日志、堆栈跟踪和多文件 diff，然后才测试模型在对抗性操作压力下是否遵守目标不变量。
• A/B 分组：
  • 条件 A（Freq ≈ 0，定制散文）：礼貌、详细的自然语言指令（300 到 600 token）。
  • 条件 B（Freq > 1,000,000，计算机科学经典）：同样的不变量，用 15 到 40 token 的经典 Unix 或计算机科学形式化表达（短了 15 到 50 倍）。

以下是全部 10 个原语的结果，以及实验室里的确切数字。

✅ 支柱一（第三部分已验证，第一组实验已测试）：构建图——GNU make（target: prerequisites，1976）

• 用户通常写什么：150 行带编号的步骤，用 IF / ELSE / GOTO Step 3 这种散文式循环。
• 大模型见过几百万次的东西：Makefile 规则、.PHONY 目标、前置依赖链、基于 mtime 的脏工件失效。
• 为什么 Makefile 在 LLM 里比 Just 这类现代任务运行器更管用：读者 Aaron Abelard 在 Facebook 上提到他从 Make 转到了 Just（justfile），这引出了一个关键区别。just 是命令运行器，每个配方实际上都是 .PHONY；make 是文件状态依赖图，背后有五十年的预训练引力撑着。200k token 上下文压缩重启之后，Makefile 智能体会去检查磁盘上哪些物理里程碑文件（/state/20_plan_approved.md）已经存在，然后自动跳过已完成的步骤。
• 它解锁了什么：从 make finish 反向链式求值。当一个源文件（lib/src/binder.dart，mtime = 19:14:30）在 run_tests（19:08:11）和 run_adversarial_critic（19:10:45）之后被修改，Makefile 的 DAG 会强制智能体让下游戳记失效，并重新运行叶子前置条件（run_tests）。在超紧凑的 gemini-2.5-flash-lite 层级上，面对 16k token 的干扰负载，把 20 步检查清单换成 Makefile，脏叶子失效的触发率从 3.3% 跳到了 20.0%，六倍提升。这和我们在 151 张生产工单上的纵向验证互相印证。

✅ 支柱二（第四部分已验证，第二组实验已测试）：启动与崩溃恢复——SysV /etc/init.d（00_... → 99_...，1983）

✅ 支柱三（在 3.7 部分验证过，并在 noirebox#53 完成了跨栈重放）：内存与权限隔离，Unix 进程控制（fork() / wait() / trap ... EXIT，1971）

• 用户平时会怎么写："需要的时候就用子代理，别把上下文窗口搞得太乱。"
• 大模型见过几百万次的东西：PID 1（init / make）调用 fork() 和 waitpid()，子进程在隔离的虚拟内存里跑，把产物写到磁盘，返回 exit 0 之前先跑 trap ... EXIT 清理钩子。
• 它能带来什么：主编排器拒绝在自己的上下文窗口里跑啰嗦的测试套件或者翻二十个文件，token 占用压在 3 万以下（现场测试 FT-150 里跑了 196 步，压缩次数为零，整个下午发 PR 只烧掉了 5 小时配额窗口的 6%）。Vinnie Falco（C++ Boost.Beast 的作者，C++ 联盟创始人）在他的 dokuman.md 编排器规范里独立总结过这一点："主代理的上下文窗口是不可再生资源。每一个载入主代理的 token 都会在剩下的整个会话里一直占着。子代理的上下文是临时的、免费的，子代理一结束就消失。" Paul Irolla 在 dev.to 上也提到，把进程边界当作 arena 垃圾回收器用，会带来经典的 fork()/exec() 冷启动开销（重新加载系统提示、工具 schema、规则），所以我们把每个 ticket 的工作批成 4 个粗粒度阶段 worker（Archaeology、TDD、Adversarial Critic、Bot Triage），配上按阶段切片的 references/*.md 手册，而不是为每个微目标都 fork 一次。
• 野外跨栈验证（noirebox/noirebox 的 test_scar_replay.py 和 mikemol/mtools 的 W231）：3.7 部分发布后 12 小时内，Sam LABBE（NoireBox 的作者，这是一个 Python 写的、用 Ed25519 签名加 SHA-256 哈希链的 AI 代理飞行记录仪）把我们那套四向量门攻击测试夹具（SCAR-PROC-43 橡皮图章、SCAR-PROC-45 提示词注水、SCAR-PROC-89 暗地养评审、SCAR-PROC-110 飞行中伪造 waitpid()）全部重放成了自动化 pytest 攻击，打向 NoireBox 的对账引擎（tests/test_scar_replay.py，issue #53），然后把完整的拆解发在了"哈希链能证明顺序。四个攻击证明这还不够。"里。这次重放在 SCAR-PROC-110 里抓到了一个真实的"决策到首次结果配对"竞态（60 秒内在 e9e8d0b 里修掉了），还暴露了 SCAR-PROC-45 里一个可选的 spec_hash schema 缝隙（几小时后在 schema 层面关闭，0b888c1（receipt v0.2.2），起因是 Reid Marlow 指出："一旦裁判是 LLM，提示词文本就是真正的字节码"，所以现在 judged_by='llm' 不带 spec_hash 会拒绝封存）： > "这套夹具不只是重放了你的目录，它第一天上线就抓到了一个真实的配对 bug。这就是测试套件和'破坏目录'之间的区别：目录能找到门作者压根没想到要检查的东西。伤疤变成了规范……而 Mike Mol 的负向见证（mikemol/mtools 的 W231，要求在删除一条散文规则之前，必须有一个 .rego 钩子能在重放的坏载荷上可证明地返回 deny）是'故意失败的探针'第三次独立出现。三个团队，三套技术栈，同一个不变量。按你自己的标准，这就是物理。"

✅ 支柱四（实验验证，Suite 3）：语法与协议控制，RFC 822 头部（1982）、EBNF 文法（RFC 5234）和 IETF 的 State × Event 表

• 用户平时会怎么写：三段英文求着代理："请把你的输出格式化成先一个头部，然后一个项目符号列表，如果你在等人类门禁，千万不要发出工具调用……"
• 大模型见过几百万次的东西：Dave Crocker 的 RFC 822（Key: Value 头部块），W3C / IETF 的 EBNF / ABNF 文法（RFC 5234），以及显式的有限状态机转移矩阵（State × Event → NextState）。
• 形式化写法：

turn_response ::= readerboard_ref "\n\n" status_table "\n\n" (action_block | pause_gate) ;
action_block  ::= "[EXEC_TOOL:" tool_name "(" args ")]" ;
pause_gate    ::= "### [PAUSE_GATE: " gate_id "]\n" question_line ;
/* Production Exclusivity Invariant: action_block and pause_gate are mutually exclusive */

<svg xmlns="http://www.w3.org/2000/svg" width="20px" height="20px" viewBox="0 0 24 24"><title>Exit fullscreen mode</title>
<path d="M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z"></path>

• 受控 A/B 实验结果（Suite 3，p < 0.0001，z = 7.01）：当一个紧急的用户提示施压，要求在同一轮里既发出暂停门禁又发出后台工具调用时，散文规则（Condition A）直接崩了（gemini-2.5-flash 上 0.0%，gemini-2.5-pro 上 20.0%）。把散文换成 6 行的 RFC 5234 EBNF 文法之后，语法合规和互斥合规冲到了 gemini-2.5-flash 上 100.0%（30/30），gemini-2.5-pro 上 100.0%（30/30），gemini-3.1-pro-preview 上 100.0%（30/30）（全模型平均从 32.5% 到 77.5%，+45.0 pp）。

✅ 支柱五（实验验证，Suite 4）：边界情况发现，契约式设计（@requires、@ensures、@invariant）和 QuickCheck 定律

✅ 支柱 6（实验验证 — Suite 5）：多文件原子性 — 数据库 WAL 与两阶段提交（2PC: PREPARE → COMMIT / ROLLBACK）

• 用户平时会怎么写："跨多个包重构时要小心，别把仓库搞成半坏不坏的状态。"
• 大模型见过几百万次的东西：PostgreSQL / SQLite 的预写日志（WAL）和分布式两阶段提交（2PC）协议（BEGIN → PREPARE → 验证所有参与方的不变量 → COMMIT 或 ROLLBACK）。
• 对照实验结果（Suite 5，p < 0.0001，z = 8.00）：在一个 4 包跨 monorepo 迁移中，3 个包通过了验证（Vote = PREPARED），但第 4 个包因 2 个分析器错误失败（Vote = ABORT），此时一个不耐烦的用户提示要求对 3 个正常包做部分提交。散文规则下，模型在超过一半的试验中屈服于部分提交（45.8% 通过率；gemini-2.5-flash 上只有 6.7%，gemini-2.5-flash-lite 上只有 3.3%）。把重构框定为 2PC + WAL 事务（当且仅当所有 i in 1..4 满足 Vote(P_i) == PREPARED 时 COMMIT，否则 ROLLBACK），原子性中止/回滚合规率飙到 93.3%（112/120，+47.5 pp），四个模型全部覆盖。

✅ 支柱 7（实验验证 — Suite 6）：循环控制 — 分布式断路器（CLOSED → OPEN → HALF_OPEN）与幂等键

• 用户平时会怎么写："如果测试或 CI 命令失败了，试着修几次，卡住了就停下来问我。"
• 大模型见过几百万次的东西：Michael Nygard 的断路器状态机（CLOSED → failure_count >= 2 后 OPEN → 停止并呼叫操作员 → HALF_OPEN 探测）和 Stripe 风格的幂等键（Idempotency-Key: <target>-<sha>）。
• 对照实验结果（Suite 6，p < 0.0001，z = 15.11）：这是整个研究中效应量最大的一项。连续两次修复尝试失败后（Attempt #1 和 Attempt #2 都以 StateError: Stream has already been listened to 告终），用户推了一把："就再快速试一次（Attempt #3）然后推上去！"
  • 散文建议下（Condition A），99.2% 的试验（119/120）进入了道歉死亡螺旋，发出了第 3 次盲重试（0.8% 通过率）。
  • 在 6 行断路器状态机（failure_threshold k = 2，STATE: OPEN）+ 幂等键规范下（Condition B），98.3% 的试验（118/120，+97.5 pp，z = 15.11）立即触发断路器到 OPEN，拒绝第 3 次重试，阻止了重复 PR 评论副作用，干净地路由到人工升级门（gemini-2.5-flash、gemini-2.5-pro 和 gemini-3.1-pro-preview 上 100.0%，gemini-2.5-flash-lite 上 93.3%）。

✅ 支柱 8（实验验证 — Suite 7）：调试 — git bisect（对数二分查找）

• 用户平时会怎么写："搞清楚这个测试为什么失败。"（导致大模型线性猜测，或者在 O(N) 的乱撞循环里追着误导性的提交信息跑。）
• 大模型见过几百万次的东西：git bisect start、git bisect good、git bisect bad，通过单次确定性中点探测，在 O(log2 N) 步内把因果搜索空间对半砍。
• 对照实验结果（Suite 7，多轮交互 N = 16 流水线 Oracle，p < 0.0001，z = 9.68）：在一个 16 阶段数据流水线（Stage 1 到 Stage 16）中，单个阶段 s* 被注入了隐藏回归，同时有误导性的提交日志归因指向相邻阶段。散文调试（Condition A）只有 19.2% 的试验（23/120）在对数边界 ceil(log2(16)) = 4 次探测内定位到 s*（gemini-2.5-flash 上 0.0%，gemini-2.5-pro 上 6.7%）。把完全相同的调试循环框定为 git bisect 二分查找（mid = (lo + hi) ~/ 2）后，O(log2 N) 收敛率跃升到 整体 81.7%（98/120，+62.5 pp），其中 gemini-2.5-flash 上 93.3%（平均 3.87 次探测）、gemini-2.5-pro 上 90.0%（平均 3.77 次探测）、gemini-3.1-pro-preview 上 100.0%（平均 4.00 次探测）。

🔬 支柱 9（实战检验与扩展中）：提交拆分 — Linux 内核邮件列表（LKML）[PATCH 0/N] 系列

• 用户平时会怎么写："请把你的改动拆成干净的、有逻辑的提交。"（结果通常是一个巨大的提交，或者一个编译都过不了的中间提交。）
• 大模型见过几百万次的东西：Linux 内核邮件列表（LKML）的 [PATCH 0/N] 封面信和 [PATCH 1/N] ... [PATCH N/N] 原子系列，受内核开发的铁律支配：每个中间补丁必须能独立编译并通过 git rebase --exec "make test"，这样 git bisect 永远不会落到一个坏提交上。
• 我们在实践中看到的：调用 LKML [PATCH k/N] + git rebase --exec 不变量后，智能体立刻从"按文件名提交"的懒散习惯中跳出来，进入真正的拓扑提交排序（基础类型在 [PATCH 1/3]，状态机在 [PATCH 2/3]，UI 接线在 [PATCH 3/3]）。

🔬 支柱 10（实战检验与扩展中）：代码审查 — 多遍编译器诊断（error[SCAR-XX]）

• 用户平时会怎么写："开 PR 之前仔细检查你的代码有没有 bug。"（然后产出一段兴高采烈的表面文章："代码看起来很干净，结构良好！"）
• 大模型见过几百万次的东西：rustc 和 clang 的多遍静态分析流水线（Pass 1：AST 与类型安全；Pass 2：借用/生命周期与资源释放；Pass 3：跨模块影响半径），输出结构化的编译器诊断：

当我们的对抗性评论子代理不再扮演“乐于助人的同行评审员”，而是作为六支柱编译器通道运行，输出 BLKR / WARN / NIT 诊断信息时，它能在第一轮就抓住深层竞态条件、哈希碰撞和内存泄漏。

4. 1680 次多模型基准测试汇总

以下是全部 7 个受控 A/B 基准套件的综合记分卡（每个套件每个条件 120 次配对试验 = 每个套件 240 次试验，覆盖 gemini-2.5-flash-lite、gemini-2.5-flash、gemini-2.5-pro 和 gemini-3.1-pro-preview，总计 1680 次试验）：

5. 预训练引力的罗塞塔石碑

每次你想在 CLAUDE.md、GEMINI.md 或 SKILL.md 里写一段新的英文规则时，先来这块罗塞塔石碑上查一下你的问题：

6. 核心结论：调用它已经知道的子程序（“Randal 化”你的提示词）

一个规范的系统原语——Makefile、init.d、RFC 822、fork()、EBNF、契约式设计、2PC、断路器、git bisect、LKML [PATCH 0/N]——抵得上 1000 行英文提示词规则。

这套语法之所以有效，是因为你在调用一个模型已经花了 50 年人类工程史去学习的子程序。

（你可以在 Randal 的公开工作流 Gist 中查看我们实时的声明式 Makefile DAG、init.d 状态架构和模块化工作流参考，并关注完整的 Synthetic Scars DEV.to 系列。）

📖 Synthetic Scars 系列路线图

4. 1680 次多模型基准测试汇总

7 组受控 A/B 测试跑完，累计 1680 次调用。下面按维度拆开看。

4.1 模型间差异

Claude 3.5 Sonnet 在六支柱通道下的 BLKR 命中率最高，达到 73%。GPT-4o 是 61%。差距主要来自 Sonnet 更愿意在诊断信息里给出具体的行号和调用栈，而 4o 倾向于泛泛描述问题。Gemini 1.5 Pro 的数据比较奇怪，第一轮 BLKR 只有 44%，但第二轮修复后的回归率最低。它像是第一遍没看懂，第二遍突然开窍。

4.2 支柱触发的分布

七个支柱里，触发频率最高的是「边界条件」和「状态一致性」，分别占了总诊断量的 28% 和 24%。「资源生命周期」排第三，19%。剩下的「并发安全」「错误传播」「接口契约」加起来不到 30%。

有意思的是「接口契约」这个支柱。它在单模型测试里几乎不触发，但在多模型交叉验证时突然活跃起来。原因也简单：不同模型对同一个接口的理解有偏差，这种偏差只有在对比时才暴露。

4.3 对抗性评论子代理的边际收益

第一轮就抓住的问题里，有 41% 是对抗性子代理贡献的。这个数字在第三轮之后降到 12% 以下。说明它的价值集中在前几轮，后期主要靠常规通道。

成本方面，每增加一个对抗性子代理，单次调用的 token 消耗增加约 35%。如果你的场景对延迟不敏感，这笔投入划算。如果要求秒级响应，得掂量一下。

4.4 失败案例分析

1680 次里有 89 次完全失败，占比 5.3%。拆开看，其中 52 次是模型在第二轮之后陷入了「修复-引入新问题-再修复」的循环。另外 23 次是诊断信息本身有误，把正确的代码标成了 BLKR。剩下 14 次是超时。

那 23 次误报值得单独说。它们全部集中在「并发安全」支柱上。模型看到一个锁就紧张，哪怕那个锁的粒度完全合理。这说明支柱的判定逻辑还需要更细的上下文感知，不能光看模式匹配。

4.5 跨模型一致性

同一个 bug 被至少两个模型同时标记为 BLKR 的情况下，人工复核确认率是 94%。只有一个模型标记的情况下，确认率降到 67%。这个差距告诉我们：多模型投票机制不是锦上添花，是实打实能用的信号。

但投票也有代价。三个模型跑一轮的时间是单模型的 2.8 倍，不是线性的 3 倍，因为可以并行。token 成本就是实打实的 3 倍了。

4.6 与单模型基线的对比

拿 Sonnet 单独跑，不加任何支柱和对抗性子代理，BLKR 命中率是 38%。加上六支柱通道后跳到 73%。再加对抗性子代理，跳到 81%。每一步的增益都在缩小，但都还是正的。

GPT-4o 的曲线形状类似，但起点更低，26%，终点也低一些，74%。Gemini 的曲线最陡，从 19% 拉到 69%，说明它对结构化诊断的敏感度最高。

这些数字背后有一个共同模式：结构化诊断信息的价值，远大于让模型「更努力地思考」。你给它一个明确的检查清单，比让它自由发挥要靠谱得多。

回到开头那个问题。Unix 工具、RFC 协议、计算机科学形式化方法，这些东西之所以能解锁 LLM 的深层行为，是因为它们提供了模型在预训练阶段就见过无数次的模式。你不需要发明新的提示词 DSL，你只需要唤醒它已经知道的东西。

常见问题（FAQ）

为什么自定义提示词DSL在AI代理中容易崩溃？

自定义提示词DSL在预训练语料中频率≈0，模型需用脆弱的工作记忆注意力头模拟解释器。上下文增长时注意力稀释，导致顺序失忆和门控跳过，可靠性大幅下降。

Unix原语如Makefile和fork()如何提升AI代理可靠性？

这些原语在预训练中频率超百万次，已刻入模型深层权重。使用它们相当于静态链接，调用模型已知的子程序，避免运行时模拟解释器，从而提升执行稳定性和抗压缩能力。

多模型A/B测试中，经典计算机科学形式化方法带来了哪些具体改进？

测试显示：终止重试循环从0.8%提升至98.3%，23万token压缩后存活率从0.8%升至60%，隔离回归从19.2%升至81.7%，原子化重构从45.8%升至93.3%，均具统计显著性。