开发者用5个接口把AI编程效率翻3倍，代码还没写架构先定死

一个Go开发者用AI写代码，3天搭完别人3周的活。不是靠Prompt工程，是靠5个接口把架构锁死在第一行代码之前。

这事发生在Flames项目里——一个给Firecracker微虚拟机做控制平面的开源工具。作者用ContextPin做AI协作中枢，让Claude Code当主程，自己只审架构。第一版Spec（技术规格书）写完，5个Provider接口的边界已经焊死。

这5个接口分别是：State（状态存储）、Cache（数据缓存）、Queue（任务队列）、Blob（对象存储）、Ingress（网络入口）。

听起来像常规抽象？但魔鬼在"第一遍就写对"的契约设计。作者的原话是：「Having these written down before implementation meant I could hand them to Claude Code and say 'build this'」——把Spec甩给AI，自己只负责Review。

为什么本地跑demo不能碰数据库

Go圈的老毛病：早期绑定具体基础设施。本地开发要起Docker Compose，测试要连Redis集群，Demo都跑不起来。

Flames的解法很Go：窄接口+内存默认实现。每个接口独立成包，只依赖model/和providererr/，零外部依赖。开发者跑go run时，后台是map[string]interface{}；上生产时，同一套代码插PostgreSQL、S3、AWS SQS。

作者画了一张架构图：绿色节点是5个Provider接口，黑色节点是领域模型，顶层控制平面只消费接口、不碰实现。这张图在写代码之前就定稿了。

关键决策：接口的导入图必须干净。没有循环依赖，每个实现可单独测试。

这听起来像基础功，但多数项目做到中期才发现import地狱。Flames把这条红线画在Day 0，靠的不是经验，是Spec-Driven Development——先写结构化文档，再让AI填代码。

AI当主程，人当架构师

作者坦承：「I write the specs, I bring my Go experience to the table, and I let AI handle the bulk of the implementation」。人做接口设计、数据流梳理、并发权衡；AI生成实现、跑测试、修Bug。

这套分工的底气来自ContextPin——一个专门给AI协作做的Workspace工具。Specs、上下文、决策记录全塞进去，Claude Code随时能查到「为什么这个接口要这样设计」。作者写了三份结构化笔记才开第一行Go代码。

结果：实现阶段的速度远超单人开发，但架构没崩。因为AI不是在猜，是在执行人定好的契约。

作者的原话值得细品：「The spec becomes the shared language between me and the AI」。Spec不是文档，是人机协作的协议层。

Firecracker场景为什么必须VM级隔离

Flames瞄准的是AI生态里的沙箱需求：跑不可信代码、Agent工作流、隔离执行环境。容器不够用了——要真正的硬件隔离，还要快、还要可编程。

Firecracker是AWS开源的微虚拟化技术，Jailer做安全加固。启动速度毫秒级，内存开销几十MB。但 orchestration（编排）层一直是空白：怎么批量起VM、怎么管生命周期、怎么做网络 ingress，没有现成答案。

作者选Go写控制平面，看中的就是interface的解耦能力。5个Provider覆盖完整基础设施栈，但代码层面完全不感知底层是SQLite还是DynamoDB。

第一版Spec已经冻结。Claude Code正在填实现，作者每天Review diff。项目开源在GitHub，文档里贴着那张架构图——绿色节点和黑色节点的边界，从Day 0就没变过。

最后一个细节：作者提到被早期基础设施绑定「burned before」（坑过）。这次用5个接口和3份Spec笔记，把坑填在了代码之外。如果你也在用AI写生产代码，你的「共享语言」是什么？