Paul 打开 Claude Code，输入的不是 Python，是一行 LDA #42。1975 年用在 Apple II 上的 6502 汇编，现在被他拿来调度 AI 修 Bug。
这事听起来像技术考古，但作者认真做了：15 条指令、零页内存、进位标志位判断测试成败。AI 的回应不再是长篇大论的"让我分析一下"，而是几行可 diff、可 grep、可重跑的汇编痕迹。
他为什么这么做？这套东西到底解决什么问题？
我们拆解正反两方的判断，看看这是程序员的中二玩笑，还是人机交互的某种预兆。
正方：结构即价值
作者的核心论点很直接：现在的 AI 输出太"话痨"了。
一个典型的 Claude Code 会话，AI 会用 800 个 token 写一段散文："让我分析一下这个问题。我先查看文件……" 然后是动作，然后是更多解释。作者把这种模式叫做" prose response "——散文式回应。
他的替代方案是 opcode 技能。15 条指令，全部借自 6502 汇编：
LDA 加载工单，STA 持久化到槽位，LDX/INX/CPX 处理循环，JSR 调用九个 I/O 向量（获取、修复、测试、审查、推送、拉取、克隆、分析），BCC/BCS 根据测试结果分支，BRK 提交并停止，PHA/PLA 把待办事项压栈出栈——直接映射到 Claude Code 的任务列表。
关键代码片段只有六行：
如果测试通过（C=1），提交并停止。如果失败（C=0），跳转到 skip 分支，不提交直接返回。BCC/BCS 模式从真实的 6502 芯片原封不动搬过来：进位标志位置位表示成功，清零表示失败。
他的 oneshot.s 更进一步：获取工单、分析、修复、测试、自审、提交，带一次重试分支。第一次修复通过测试和审查，BRK 立即提交。不行的话，重试分支再给一次机会。再失败，RTS 把分支留给人来处理。
他强调的是"结构性价值"：痕迹是可 diff 的，可 grep 的，可重跑的。无论 token 成本是否真的降低，这种可预测性本身就是收益。
反方：符号层的过度设计
但质疑的声音同样直接：这到底解决了什么新问题？
6502 的 56 条操作码、64KB 地址空间，在 1975 年是硬件约束下的最优解。2025 年的 AI 工作流，约束条件完全不同。把现代 issue 系统（带描述、验收标准、标签、截图、关联 PR 图谱）塞进 8 位处理器的语义框架，是必要抽象还是复古癖发作？
作者自己也承认："这不是真正的 6502，我只是借用了助记符。" 但借用本身制造了认知负担。熟悉现代 DevOps 的工程师需要额外学习 6502 的寻址模式；而懂 6502 的老派程序员，面对的不是寄存器里的字节，而是"工单 42 号，带视觉模型可读取的截图"。
更实际的质疑：token 成本真的降了吗？作者说"比预期的复杂"。汇编痕迹虽然短，但 Claude Code 底层仍需把助记符解析成实际动作。抽象层没有消除计算，只是转移了表达形式。
还有可维护性问题。opcode 技能目前只有他一个人写、一个人用。如果团队采用，谁负责这套 DSL 的文档、调试、版本迁移？15 条指令确实能"全部记在脑子里"，但 15 条指令加上 9 个 I/O 向量的组合爆炸，调试时真的比读 AI 的散文日志更直观吗？
我的判断：这不是工具，是探针
两边都有道理，但问题的框架可能需要调整。
这个项目不是"用 6502 汇编替代 Python 写 AI 工作流"的严肃工程提案。作者自己说得很清楚："这开始是个玩笑。" 但玩笑做到这个程度——完整的技能实现、可运行的示例、对 token 成本的实际测量——已经超出了玩票的范畴。
它的真正价值在于暴露了一个被忽视的维度：人机交互的"文体"问题。
我们习惯了 AI 用散文回应，以至于忘记了这不是唯一选项。6502 汇编是一种极端的替代方案，极端到几乎不可用，但正是这种极端性，让我们看清散文回应的默认地位是多么偶然。
作者的项目像一根探针，刺穿了"自然语言是 AI 交互终点"的假设。探针本身不需要成为基础设施，它只需要证明：还有其他可能性存在。
至于 15 条指令能否扩展成生产工具，或者会不会有人用 ARM 汇编、RISC-V 甚至 Brainfuck 重做一遍，都是次要问题。核心问题已经提出：当 AI 的输出从"可读"变成"可执行"，交互的本质会不会改变？
答案尚不清楚。但 1975 年的芯片指令能在 2025 年引发这场讨论，本身就是值得记录的现象。
热门跟贴