Atelier 为什么要选择 Go 语言

先说结论

• Atelier 选择 Go 做后端、React 做界面，首先考虑本机交付、系统接口和长期维护。
• 面向用户的交付形态已选定为 macOS 桌面应用：同一个 Go 二进制承载后端与窗口入口，窗口使用系统自带的 WebKit，用户无需另装 Go 或 Node 运行时。
• 选择 Go 同时意味着接受前后端两种语言的维护成本，并把协议适配、数据库写入和平台差异处理清楚。
• Windows 已纳入目标平台，实现与安装包属于后续工作，目前不作已经支持的声明。

APSer-Atelier 的定位是可持续交付的底座，仍在持续打磨。 它面向一人公司、多项目并进和 AI 协同开发：负责人表达目标与优先级，平台维持计划、工作、执行和验收的连续性。 语言选型要服务于这类工作能否持续推进、遇到中断能否查清状态、交付之后能否继续维护。

这篇文章讨论新一轮建设中已经确定的技术选择与工程约束。 选型决定、设计要求和实际验收各有边界；下文谈到的交付目标，不等于面向其他团队的安装、签名与分发已经完成。

一、先从用户拿到什么开始

Atelier 的交付要求很明确：用户拿到应用后，无需自行配置语言运行时。 开发时可以安装编译器和前端工具，使用时不应把这些开发依赖转交给用户。 Go 的二进制交付方式符合这个方向，因此成为选型的重要依据。

访问入口也已经确定为桌面应用。 用户从程序坞或启动台打开 Atelier，在独立窗口里操作，无需记住本机地址与端口。 设计上，同一个 Go 二进制在进程内启动后端，再通过系统自带的 Cocoa 与 WebKit 建立窗口、显示 React 页面。 页面、命令与刷新推送仍由本机后端提供，浏览器入口保留给开发和排障。

这里需要说清楚“单个二进制”的含义。 macOS 窗口部分通过 cgo 调用系统框架，因此应用仍依赖操作系统提供的库；“免装语言运行时”描述的是用户的安装负担，不能由此推导出整个桌面应用完全静态链接。

二、后台工作需要接得住系统进程

AI 编程工具运行一项工作时，可能继续启动其他进程。 只记录最初启动的那个进程，无法充分说明后续工作是否还在运行。 Atelier 的技术选型记录已经确认过这样一个情况：Codex 启动的子进程会另开进程组，父进程被强制终止后，子进程可能被系统接管。

这使进程管理成为实际的选型条件。 平台需要登记后代进程，在重启后核对状态；不能只凭界面断开、父进程退出或一次请求失败，就宣布工作结束。 Go 可以直接接入系统接口，适合承接这部分进程查询与管理工作。

进程接口同时带来平台边界。 macOS 与 Windows 的进程管理机制需要分别适配，语言本身不会抹平差异。 现行约定要求把平台相关代码隔离在对应文件或包里，让共用业务逻辑保持独立。 这是一项实现约束，Windows 版本仍须完成自己的实现与验证。

三、长期维护需要可读、明确的控制流程

Atelier 的选型理由还包括：后台长期运行、由一人维护，并大量借助 AI 编写代码。 在这个前提下，我们看重 Go 相对收敛的语言写法与显式错误处理，希望减少阅读、审查和接手代码时需要判断的分岔。

显式错误处理也需要配合明确的业务边界。 例如数据库写入发生冲突时，事务如何开始、连接由谁管理，都需要统一的写法。 语言提供表达方式，产品仍须自己定义规则，并通过实现与验证让规则成立。

这也解释了为什么没有把界面一并改成 Go。 现行分工保留 React 页面，由 Go 承担后端职责。 代价是前后端两种语言要共同维护；接口数据类型按后端定义生成，是选型时确定的衔接方式。 界面和后端各自采用适合其职责的工具，接口则需要明确的定义与校验。

四、协议接入按实际需要控制范围

接入 AI 编程工具，需要处理协议、消息类型和版本变化。 Atelier 对 Codex 选择的是 app-server JSON-RPC 接口，并按实际使用的方法定义 Go 结构体，不以官方 SDK 作为接入前提。

完整协议包含较多联合类型，Go 在表达这类类型时需要额外组织代码，这是明确接受的代价。 选型时的判断是：围绕实际调用范围编写适配，比把整个协议预先搬进产品更符合当前需要。

协议升级仍然需要专门验证。 既定做法是锁定接入的 Codex 版本，升级时重放已记录的协议收发并重跑探测，检查原有交互是否继续成立。 Go 承担适配代码的实现，兼容性由版本约束与验证过程保障。

五、数据库写法也属于选型成本

后端换用 Go 后，SQLite 的写入方式需要明确约束。 Atelier 的编码规范要求写数据库固定走单连接，事务开头取得写锁，使用 BEGIN IMMEDIATE 并配置忙等超时。 存储层对外提供事务操作，调用方不能拿到裸连接随意写入。

这样做是为了把状态变化、命令去重记录和刷新通知意图放在同一事务里，并减少连接使用错误带来的锁冲突或死锁风险。 规范记录了随机并发验证，并据此选定单连接写法；本文不把这项局部验证扩展为整体吞吐或性能承诺。

Go 的并发能力提供了组织工作的手段，数据库的一致性仍依赖明确的事务边界。 选择语言时，把这些限制与写法一起确定，后续维护才有共同依据。

六、macOS 是当前交付形态，Windows 是后续工作

现行技术选择以 macOS 桌面应用为落地形态，签名、公证和面向其他团队的安装分发仍有后续工作。 窗口设计也区分了关闭窗口和退出应用：关闭窗口时后台继续推进，退出应用时停止后端。 这些是已确定的产品行为要求，具体版本是否达到要求，仍应以对应验收为准。

Windows 已列入目标平台，但实现和安装包尚未进入当前交付范围，也未确定排期。 窗口、进程管理、文件锁和默认数据目录等差异，需要分别处理；现阶段要求隔离平台代码，为后续实现保留清楚的边界。 选择 Go，为共用后端与系统适配提供了实现路径；跨平台支持还需要逐个平台完成工程与验收。

我们选择 Go，围绕的是应用怎么交付、后台工作怎么持续、系统状态怎么核对，以及代码怎么长期维护。 这也对应 Atelier 作为可持续交付底座的方向：让计划、执行、验证与交接有连续的依据，让每一次技术选择都有清楚的理由与代价。