6502汇编如何构建AI工单处理工作流？2026实用技巧

核心洞察

复古硬件的美学不仅仅是一种怀旧装饰，它迫使你将工作流压缩成可验证、可版本化的指令序列，从而彻底消除大语言模型（LLM）输出中的冗余叙事。这个项目巧妙地证明了：最有效的 AI 交互，有时不是更长的对话，而是更短的、结构化的程序。

The aesthetic of retro hardware is not just nostalgic decoration; it forces you to compress workflows into verifiable, versionable sequences of instructions, thereby eliminating the redundant narrative in large language model (LLM) outputs. This project cleverly demonstrates that the most effective AI interaction is sometimes not a longer conversation, but a shorter, structured program.

---

In 1975 the 6502 processed 8-bit values through memory and control flow. A Claude Code skill now uses the same mnemonics to process forge tickets through triage loops.

1975 年，6502 处理器通过内存和控制流处理 8 位数值。如今，一个 Claude Code 技能使用相同的助记符，通过分类循环来处理工单。

Paul Newell · Apr 2026 · 8 min read

I'll be honest, this started as a joke. I wanted to see if I could get Claude Code to understand 6502 assembly language.

说实话，这始于一个玩笑。我想看看能否让 Claude Code 理解 6502 汇编语言。

The 6502 powered the Apple II, the Commodore 64, the BBC Micro, the NES. It had 56 opcodes, 64KB of address space and absolutely no business anywhere near a large language model.

6502 曾驱动 Apple II、Commodore 64、BBC Micro 和 NES。它只有 56 条操作码、64KB 地址空间，完全没有理由出现在大语言模型附近。

So I built a Claude Code skill that maps its instruction set onto a modern triage-and-fix workflow. You write .s files. Claude executes them. Its response is also assembly. There's a zero-page. There's a stack. BRK means "commit and halt."

于是我构建了一个 Claude Code 技能，将其指令集映射到现代的分类与修复工作流中。你编写 .s 文件，Claude 执行它们，它的回复也是汇编。有零页，有堆栈。BRK 表示“提交并停止”。

Same Verbs, Bigger Nouns

相同的动词，更大的名词

Forty years later I'm writing LDA to load issue 42, which arrives with a description, acceptance criteria, a set of labels, screenshots Claude can actually see with vision and a graph of linked PRs.

四十年后，我正在用 LDA 加载编号为 42 的问题，它附带描述、验收标准、一组标签、Claude 通过视觉功能实际能看到的截图，以及一个关联 PR 的图表。

The verbs haven't changed. The nouns got about six orders of magnitude bigger.

动词没变，名词的体积大了大约六个数量级。

The Smallest Useful Program

最小的实用程序

peek.s — 6502 在彩色环境中显得格格不入
peek.s — 6502 looking very out of place in colour

Six opcodes, three flags in play. This is the heart of what the whole thing does:

六条操作码，三个标志位。这就是整个工作的核心：

It's not a real 6502, of course. I just borrowed the mnemonics.

当然，这并非真正的 6502，我只是借用了它的助记符。

If the tests pass (C=1), commit and halt. If they fail (C=0), branch to skip and return without committing. That's it. The BCC/BCS pattern carries over directly from the real 6502. Carry set means success, carry clear means failure.

如果测试通过（C=1），提交并停止；如果测试失败（C=0），跳转到 skip 并返回而不提交。仅此而已。BCC/BCS 模式直接源自真实的 6502：进位位设置表示成功，清除表示失败。

The Trace Is the Reply

追踪即是回复

An 800-token prose response ("Let me analyse this issue. I'll start by examining the file at...") becomes a handful of lines of assembly trace.

一段 800 token 的散文式回复（“让我分析这个问题，我将从检查文件开始……”）变成了几行汇编追踪。

Issue fetched, file fixed, tests passed, diff reviewed, committed, PR opened. No "Let me now...", no "I'll proceed to...", no "Here's what I did...". Just the trace.

问题获取、文件修复、测试通过、差异审查、提交、PR 打开。没有“现在让我……”，没有“我将继续……”，没有“这是我做的……”。只有追踪。

That trace is structured. Diffable. Greppable. Re-runnable. Whether it costs fewer tokens than prose turned out to be more complicated than I expected, but the structural value is still there.

这种追踪是结构化的、可比较差异的、可 grep 的、可重新执行的。它是否比散文消耗更少的 token 最终比我预想的要复杂，但结构性价值依然存在。

One Shot, One Fix

一次尝试，一次修复

oneshot.s is the next step up: fetch an issue, analyze it, fix it, test it, self-review, and commit, with a single retry branch if the first attempt fails.

oneshot.s 是下一个升级步骤：获取一个问题，分析它，修复它，测试它，自我审查，并提交。如果第一次尝试失败，则提供一个重试分支。

If the first fix passes tests and review, BRK commits immediately. If not, the retry branch gives it one more shot. If that also fails, RTS leaves the branch uncommitted for a human to pick up. The carry flag is doing exactly what it did on the original chip, routing control flow on a binary result.

如果第一次修复通过测试和审查，BRK 立即提交。否则，重试分支再给一次机会。如果依然失败，RTS 使分支保持未提交状态，供人工接手。进位位执行的功能与原始芯片完全相同：基于二进制结果路由控制流。

oneshot.s — 好多了，看起来更舒服
oneshot.s — that's better, much easier on the eyes

How It Works: 15 Opcodes and 9 Vectors

工作原理：15 条操作码与 9 个向量

The skill is called opcode and it defines a semantic DSL that borrows the 6502's mnemonics but maps them onto issue triage. The core ISA is just 15 opcodes. You can genuinely hold the entire thing in your head.

该技能名为 opcode，它定义了一个语义 DSL，借用了 6502 的助记符，但将其映射到问题分类上。核心 ISA 只有 15 条操作码，你完全可以将其全部记住。

The nine I/O vectors provide the interface to external systems:

There's a zero-page with named slots. $00 is the current issue ID, $01 is the branch name, $02 is the current file, $05 is the commit message. The fetched issue queue lives at $10-$1F. The stack page at $0100-$01FF is the Claude Code task list.

有一个带有命名槽位的零页。$00 是当前问题 ID，$01 是分支名称，$02 是当前文件，$05 是提交消息。获取的问题队列位于 $10-$1F。位于 $0100-$01FF 的堆栈页正是 Claude Code 的任务列表。

Opcode Oriented Programming (OOP, obviously 🙂)

6502 mnemonics. Modern AI execution. Workflows as programs.

面向操作码编程（OOP，显而易见 🙂）

6502 助记符。现代 AI 执行。工作流即程序。

It talks to GitHub or GitLab through a forge abstraction layer so JSR PUSH opens a PR on GitHub or an MR on GitLab. Nobody has to compromise their vocabulary.

它通过一个工单抽象层与 GitHub 或 GitLab 通信，因此 JSR PUSH 在 GitHub 上打开 PR，在 GitLab 上打开 MR。无需任何人妥协他们的词汇。

A Real Triage Session

真实的分类会话

This program loops through every issue labelled bug, tries to fix each one and only commits the ones where tests pass and the self-review is clean. Failed fixes get skipped. At the end it opens PRs for everything that worked. The PHA/PLA cycle maps directly onto Claude Code's task list so each pushed issue becomes a real tracked todo.

该程序循环遍历每个标记为“bug”的问题，尝试修复每个问题，并且只提交那些测试通过且自我审查无问题的。失败的修复被跳过。最后，它为所有成功的修复打开 PR。PHA/PLA 循环直接映射到 Claude Code 的任务列表，因此每个推入的问题都成为真正可追踪的待办事项。

drain-the-swamp.s — 以其偏好的输出格式呈现；附带历史准确的代码审查注释
drain-the-swamp.s — in its preferred output format; complete with historically accurate code review comments

The Constraint Is the Feature

约束即是特性

The 6502 aesthetic isn't just nostalgic decoration, it's a forcing function. When your output format is assembly you commit to a verb sequence before execution instead of wandering through chat mode. The resulting traces scan way faster than prose. They're diffable, greppable and versionable. You can commit a .s file alongside your code and re-run it on the next batch of issues.

6502 的美学不仅仅是怀旧的装饰，它是一种强制功能。当你的输出格式是汇编时，你在执行之前就承诺了一个动词序列，而不是在聊天模式中游荡。生成的追踪比散文浏览速度快得多，它们是可差异比较、可 grep 且可版本化的。你可以将 .s 文件与代码一起提交，并在下一批问题上重新运行。

The temptation to add "just one sentence of context" is the whole failure mode. Resist it absolutely.

添加“仅仅一句上下文”的诱惑是整个失败模式。必须彻底抵制。

The skill is pretty militant about this. Claude's response must be a valid .s program. No greetings, no sign-offs, no "Let me", no markdown headers. If it doesn't fit as an instruction, a directive or a semicolon comment it doesn't get said. There are escape hatches like .ASK for questions (≤60 chars), .NOTE for observations (≤80 chars) and .ERR for errors. But these are pressure-release valves, not invitations to prose.

该技能对此非常严格。Claude 的回复必须是有效的 .s 程序。没有问候语，没有结束语，没有“让我”，没有 Markdown 标题。如果它不能作为指令、伪指令或分号注释来表达，就不会被说出口。也有一些逃生舱口：.ASK 用于提问（≤60 字符），.NOTE 用于观察（≤80 字符），.ERR 用于错误。但这些是减压阀，而不是对散文的邀请。

The Extended ISA: For Completeness and Nostalgia

扩展 ISA：为了完整性与怀旧

There's a full extended layer (~40 more mnemonics) you can opt into with .EXTENDED ON. Shifts become priority promotions (ASL A = "promote priority"). Logic ops become label-filter algebra (AND #imm = "intersect label mask"). BVS branches on merge conflict. Most of these are tagged as metaphor so they get narrated in the trace but not actually executed.

通过 .EXTENDED ON 可以启用一个完整的扩展层（约 40 条额外助记符）。移位变为优先级提升（ASL A = “提升优先级”）。逻辑运算变为标签筛选代数（AND #imm = “交集标签掩码”）。BVS 在合并冲突时分支。其中大多数被标记为隐喻，因此在追踪中被叙述但不会实际执行。

And for completeness there are six illegal opcodes behind .UNSAFE ON. The real undocumented 6502 ops like LAX, SAX and DCP. Pure flavour. Narrated, never executed, not even with the directive set. They exist simply because I could not resist adding them.

为了完整性，还有六条非法操作码（隐藏在 .UNSAFE ON 之后）。真正的未文档化 6502 操作码，如 LAX、SAX 和 DCP。纯粹的风味。被叙述，但从不执行，即使设置了该指令也不会。它们的存在仅仅是因为我无法抗拒添加它们。

What about tokens?

关于 token 的问题

I expected the tight assembly output to translate to substantial cost savings versus prose Claude. The story turned out more nuanced.

我原本期望紧凑的汇编输出相比散文式 Claude 能带来巨大的成本节省，但实际情况更为微妙。

The reason is asymmetric overhead. For small, deterministic tasks, the orchestration overhead dominates the work — like running a CI pipeline to compile a single file. Opcode comes out ahead on larger programs with more decision points (multi-issue queue walks, longer reasoning chains where prose Claude would actually ramble).

原因在于不对称的开销。对于小的、确定性的任务，编排开销占据了主导——就像运行 CI 流水线来编译单个文件。而 Opcode 则在包含更多决策点的更大程序上胜出（例如多问题队列遍历、更长的推理链，其中散文式 Claude 实际上会漫无边际地描述）。

Prose prompts invite interpretation. Assembly doesn't.

散文式提示邀请解读，汇编不会。

So Is This Actually Useful?

那么这真的实用吗？

Maybe. If you're running the same triage pattern across many issues like scanning a backlog, fixing straightforward bugs and opening PRs then the token savings start making sense and the structured output is way tighter to read than endless TL;DR prose.

也许吧。如果你在多个问题上运行相同的分类模式——比如扫描待办事项、修复直接的 bug 并打开 PR——那么 token 节省就开始有意义了，结构化的输出比无穷无尽的“太长不看”散文紧凑得多。

The .s files are reviewable artifacts.

.s 文件是可审查的制品。

The traces are audit logs.

追踪是审计日志。

And the constraint of planning your workflow as a sequence of opcodes before execution turns out to be surprisingly good discipline.

在执行之前将工作流规划为一系列操作码的约束，被证明是一种出乎意料的好纪律。

BRK

BRK

At the end of the day the question is the same one it's always been.

归根结底，问题一如既往。

Are you a quiche eater or a Real Programmer?

你是吃乳蛋饼的人，还是真正的程序员？

Real Programmers don't need prose.

真正的程序员不需要散文。

They need opcodes, a carry flag and a BRK at the end.

他们需要操作码、一个进位位以及末尾的 BRK。

Commit the work. Halt the machine 🙂

提交工作，停止机器 🙂

---

Somewhere between JSR FETCH and BRK this stopped feeling entirely satirical.

在 JSR FETCH 和 BRK 之间的某个地方，这不再完全感觉像讽刺了。

But if this article raised a smile or jogged some long-distant memories then please comment below.

但如果这篇文章让你会心一笑，或唤起了久远的记忆，请在下方评论。

---

The code

代码

Full skill and example programs: github.com/newell-paul/opcode

完整的技能和示例程序：github.com/newell-paul/opcode

常见问题（FAQ）

opcode技能如何将6502汇编与工单处理结合？

opcode将6502助记符映射到工单分类工作流，用户编写.s文件，用LDA、STA等指令获取、修复、测试、审查和提交问题，Clue执行并输出结构化汇编追踪。

为什么选择6502汇编作为基础？

6502指令集简洁（仅15个操作码），其BCC/BCS等标志位语义自然对应测试通过/失败，零页和堆栈机制适合结构化工作流，强制简洁和纪律性。

使用opcode技能相比传统散文回复有什么优势？

输出结构化、可diff、可grep、可重执行，显著减少冗余叙事，提升token效率；迫使将工作流压缩为可验证的指令序列，消除LLM输出中的废话。