Prompt2ELF：让 LLM 跳过编译器直接生成 ELF 可执行文件

GitHub 上的开源项目 Prompt2ELF 尝试了一种非常规的编程路径：让大语言模型驱动的编码智能体直接写出 Linux x86-64 的 ELF 可执行文件，过程中不使用任何编译器、汇编器或链接器。项目作者将这一思路打包成一套「Agent Skill」，可被 Claude Code、GitHub Copilot、Devin、OpenCode 等主流 AI 编码助手加载调用。

项目能做什么

Prompt2ELF 的核心是一条 /prompt2elf forge "..." 指令。智能体收到任务后，会按预设的 ELF 布局和指令编码规则，把最终的可执行文件内容写成纯十六进制文本，再由项目自带的一个 334 字节的「hexwriter.bin」工具把十六进制文本解码为真正的可执行二进制。

项目附带了几组代表性产物：

hello.bin：167 字节，运行后输出 Hello, world! 并退出。
mandelbrot.bin：322 字节，在终端渲染一个 64×32 的 ASCII Mandelbrot 图形。
server.bin：449 字节，启动后在 0.0.0.0:9000 上提供 Hello, world! 的 HTTP 服务。

所有可执行文件在 hex/ 目录下都有对应的「源码」，但这里的「源码」不是 C 或汇编，而是可以直接喂给 hexwriter 的十六进制文本。

工作原理

整个流程可以概括为四步：

智能体读取项目根目录下的 SKILL.md，获取目标 ABI、编码流程和安全约束。
根据任务自行设计 ELF 文件头布局、段结构和指令序列，把完整可执行文件写成十六进制文本。
用 hexwriter.bin 将十六进制文本解码为字节、写入文件，并标记可执行权限。
对重建后的二进制做逐字节比对，并在本地以原生 Linux 进程形式测试运行。

作者特别指出，hexwriter.bin 还可以「自我复制」——用自己的十六进制源重新生成一份自身，再与原文件用 cmp -s 比对，以此验证重建流程的正确性。

与 AI 编码助手的集成方式

Prompt2ELF 以标准 Agent Skills 包的形式发布，使用方式是把整个仓库复制到对应编码智能体识别的技能目录下，例如：

Claude Code：.claude/skills/prompt2elf/
Devin / OpenCode：.agents/skills/prompt2elf/
GitHub Copilot：.github/skills/prompt2elf/

加载完成后，既可以直接用 /prompt2elf forge "任务描述" 触发，也可以用自然语言让智能体调用，例如「用 Prompt2ELF 做一个仅监听 loopback 的 HTTP 状态服务器」。需要注意的是，forge 是该技能内部定义的动作，与 Foundry 等同名外部命令无关。

局限与定位

Prompt2ELF 并非要取代日常开发中的编译器。作者明确给出了几项边界条件：

目前仅支持 Linux x86-64 平台。
指令偏移和 ELF 尺寸必须严格精确，微小改动往往需要重新计算多处。
示例程序优先追求体积小和逻辑清晰，缺乏生产级的错误处理。
生成的原生代码应尽量在最小权限下运行和检查。

作者强调，对于普通的应用开发，仍然应该使用编译器；Prompt2ELF 的定位是帮助理解可执行文件内部结构、构造极小的自包含程序，以及探索「人类意图—机器码」之间的直接接口。项目未来的方向，是做一个类似 BusyBox 的小型 multicall 二进制，仍然由提示词直接生成，依赖 Linux 系统调用即可运行。