AI写的汇编不可信：三行命令验证真伪

✨ 声明：本文在 AI 辅助下起草。每一项技术声明均已在链接仓库中经过验证和溯源。

AI 助手对汇编代码充满信心——但犯错的方式特定且可重复。它们会编造根本不存在的助记符，混淆 AT&T 和 Intel 的操作数顺序，静默丢弃立即数，还可能误读字节。我们在审计真实案例时发现，失败有一个共同的特征：代码看起来合理，从不报错。

修复方法不是"更仔细一点"。而是一个可以在几秒内运行的机械门控。

这个门控是：汇编 → 反汇编 → 对比

# AT&T / GNU as, x86-64
gcc -c sample.s && objdump -d sample.o

# Intel 语法
gcc -c -masm=intel sample.s && objdump -d -M intel sample.o

如果反汇编的结果与你写的不一致——助记符不同、操作数不同、大小不同——那你写的根本不是那条指令。三种此门控能捕获的真实案例：

1. 不存在的助记符

movqad 不是一条指令。汇编器会拒绝它——目前为止一切顺利。危险的是那些能编译通过的。

2. 静默截断的立即数

imul eax, eax, 38      ; 汇编为: 69 c0 00 00 00 00

38 被解析器静默丢弃了——这是 BBoeOS PR#584 背后的 bug 类别。代码能编译，但原本的意图消失了。

3. AT&T 和 Intel 混用

-masm=intel 会翻转操作数顺序（mov eax, [rax] vs mov (%rax), %eax）。在同一文件中混用 AT&T 和 Intel 会静默改变语义。

为什么"能编译"是不够的

编译只能证明你的语法符合某种语法规则。它不能证明编码与你意图一致。基于 LLM 的反汇编在准确匹配指令方面只有约 14% 的正确率；"修正后"的反编译正确率约为 37%。置信度与正确性之间的差距，恰好就是代价高昂的 bug 藏身之处。

永远不要凭记忆断言一条指令、编码或长度。去汇编它。

明确锁定语法方言。绝不混用 AT&T 和 Intel。

对照手册检查原始字节中的异常指令（Intel SDM、ARM ARM、RISC-V ISA）。

如果工具链不可用，标注 UNVERIFIED 并给出能够检验的命令。

同样的纪律适用于所有地方

验证真正的并行性（线程数 + 墙钟时间，而非线程安全语法）。验证 API 确实存在（cargo search，而非记忆）。验证你的验证——一个不可能失败的测试框架不是证据。

📦 仓库——持续更新中

完整的失败案例目录和编码这些门控的技能位于 https://github.com/TrothByte/low-level-skills-trothbyte——包含 124 项为 C、C++、Rust、汇编、内核、嵌入式、Zig、GPU、逆向工程和构建系统验证的技能。

其中 65/124 项在真实工具链上执行（GCC 16.1、rustc 1.97、GDB、objdump、CMake/Ninja）；其余的诚实标注为经过研究并附带精确的验证命令。

每项声明均可溯源：声明 → 主要来源 → 章节 → 技能（177 个主要来源）。

仓库持续更新——随着案例的记录，新的失败类别和技能会被添加进来，整个库每次变更都会重新验证：

git clone https://github.com/TrothByte/low-level-skills-trothbyte
python tools/validate.py     # 124 项技能 + 注册表 + 177 个来源，秒级门控

也可以通过 npx skills add TrothByte/low-level-skills-trothbyte 安装，或作为 Claude Code 插件市场插件使用。

发现了我们尚未收录的失败案例？仓库接受 issue——每项新技能必须可溯源并与现有 124 项区分开来。关注仓库以获取更新通知。