APSer-Atelier 从哪里来

先说结论

• APSer-Atelier 是我们在自身交付中使用的工作平台，2026 年 4 月 6 日第一次提交；9 月 27 日重新定位为「可持续交付的底座」，回答的是客户关心的系统交付之后还能不能持续地改、改错了能不能退回、换了人能不能接手里，属于交付方的那部分。
• 它起于一人公司多项目并进的场景；一路上被冻结过、停过、砍过，我们也反复怀疑过它是不是痴人说梦、狂妄自大、自嗨。每次想放下它，总有真实的麻烦把它推回来。
• 证据和反面证据都照实列出：截至 9 月 29 日，Atelier 代码仓有 1870 个提交，平台记下 465 件「一件事」的完整记录；同时，自动派出的工作有三成出错，从一句意图出发、无人介入一路做到上线，目前只在测试用的代码仓上跑通过。
• 最近的一步，是让平台在一个真实产品项目上完整执行一轮，全程留下可核对的记录；更远的「可进化的企业应用」是要去验证的方向，不作承诺。

APSer-Atelier 是青岛艾普仕在自身交付中使用的工作平台，现在的定位是「可持续交付的底座」。本文是「Atelier」专栏的第一篇，讲它的来历。这半年有过不少摇摆，也照实写；时间和数字都回到提交记录、平台数据和当时的原话核对过，找不到记录的直接写「没有记录」。

一、「Atelier」这个名字从哪里来？

「Atelier」是法语词，源自古法语 astelier，最初指木工作坊，后来泛指各类工坊；在艺术史上，指一位主理匠人带着助手和学徒一起创作的工作室。我们取的正是这层意思：我们是工坊的主理人，AI 是协同创作的助手，软件在一个人主导、人机协同的工坊里打磨出来。这也对应一人公司的本质：小而精，主理人对每一件作品负全责。

最早的书面记录，是 4 月 21 日一份发布准备文档里的一行：「多 Agent 平台命名，Atelier 中选」。候选名单和最初由谁提出，都没有记录。在这之前，它叫过「通用 Agent 平台」和「个人 AI 开发副驾」。

二、它是哪天诞生的，最初做了什么？

第一次提交在 2026 年 4 月 6 日 9:24，做的是几件朴素的事：按依赖关系排任务、四个分工不同的 Agent、本机大模型、把结果推送到钉钉、一个网页监控界面。4 月 25 日，冷启动交接上线：每个项目一份接班入口，写明是什么项目、做到哪了、下一步做什么。当时的记录写着：「多会话漂移」本身就是这套交接要解决的核心痛点。

三、当初为什么要做它？

我们是一人公司，一个人同时推进好几个项目，大量执行工作交给 AI。通用的 AI 编程工具很强，设计上多围绕多人协作：一个代码库、一项明确的任务、有同事评审。6 月 10 日，我们说的大意是：这几件工具很厉害，但针对一人公司多项目并进的场景，存在诸多缺点，这正是 Atelier 的初衷。

四、我们怀疑过自己什么？

最难的一段是怀疑自己。三个问题反复出现。

是不是痴人说梦。 一个人，靠 AI 编程工具和自己多年的经验，能不能做出这样一套东西？9 月 10 日我们说：「我也很担心，自研这条路是否真的能走的通。」傍晚面对一份整改计划，又说：「这份计划相当于认可了我一个人……能够自研计划中定位的这套 harness。我个人仍有怀疑。」（harness 指把 AI 执行器组织起来的整套外壳。）

是不是狂妄自大。 8 月 28 日，它的定位升级为「一人公司的完整 AI 工作平台」；9 月 10 日的架构核查结论是，当时的实现还配不上这个定位。9 月 26 日，我们一度觉得它可能是一条很有竞争力的路，紧接着就问：「冷静地想一下，这个想法是不是过于自大了？」得到的回答是：措辞自大，内核不自大。冷静下来的说法是，这是一条值得验证的假设。

是不是自嗨。 8 月 28 日：「我们在 Atelier 内构建这套能力是否真的有价值呢？」9 月 9 日：「说实话，我有点怀疑这个方向的投入，有可能属于纯粹浪费精力。」9 月 16 日，要求做一次独立评审：平台的计划目标，会不会是一次自嗨和臆想？

五、投还是停，我们怎样犹豫过？

一路上丢掉的：多系统通用平台的说法、网页监控界面、向量检索、钉钉推送的旧通道。

三次关键的「停」：

• 8 月 28 日，功能冻结。 我们发现重点变成了平台自己的建设，耽搁了产品项目。当天定下纠偏：平台的成功标准改为业务项目的可验证交付，手头一块做完就冻结。
• 9 月 9 日，算账。 一次只读诊断：9 月上旬，平台自身的开发占了自动执行时间的 45.1%；一个项目 34 小时自动执行 6 次，只换来 4 行产品代码。结论是，在当时的模型能力下，让平台「替人执行」得不偿失，真正值得做的是让不同工具之间的认知接得上。
• 9 月 12 日，留退路。 整改后差距仍大，就先聚焦产品项目，平台只作记录和展示。

最后没有停。9 月 16 日起，平台的推进单独成为一条主线。事后看，问题出在两处：定位先于证据；认知跟着工具走，换工具时规矩锁在前一家的私有记忆里，经过见《Claude Code、Codex 与 APSer-Atelier》。

六、哪几次让我们离不开它？

• 9 月 2 日，两家工具并用，两边的规矩对不上。当时的原话：「……割裂了，痛苦无比。」当天定下：平台是唯一的指挥位，AI 编程工具都是可替换的执行器。
• 9 月 8 日，工具客户端卡死，靠平台的网页前端把工作接了回来：「这次幸亏 Atelier 前端挽救了我们。」
• 9 月 9 日，人在两个工具之间来回传话，由此有了前端的会话交互和等人拍板的提醒。
• 9 月 17 日、18 日，写下来的规矩管不住，由此有了在出错时刻直接拦截的钩子，见《从记忆、规则到钩子》。
• 9 月 22 日，两路同时改一个代码仓出了错，由此定下一个代码仓同一时间只有一个写入者。

每次想放下它，总有真实的麻烦把它推回来。9 月 10 日那次怀疑之后，我们说过大意是：信心恰恰来自一步步发现自建平台的必要性和可行性。

七、它解决了哪些问题？

具体做法见《APSer-Atelier 的场景锚定与价值定位，以及实践总结》。今天每天在用的，有接班入口、在制品上限与停车清单、等人拍板、要求登记、单写入者、上线检查和钩子。

八、有哪些证据和反面证据？

能拿出来的证据

平台数据库与代码仓记录，截至 2026 年 9 月 29 日 20:00：

这些数字说明它每天在被使用，说明不了它让交付变快了多少。

反面证据

• 自动派出的工作，三成出错：7 月 16 日以来派出 258 次，完成 155 次，出错 87 次，取消 15 次，统计时还有 1 次在运行。
• 平台一度吃掉了自己的时间：见第五节 9 月 9 日的诊断。
• 第一代自动执行链整条停用：6 月 16 日到 7 月 1 日跑了 154 个任务，完成 100 个、失败 15 个、取消 39 个，之后没再用。
• 取消的事占三分之一：465 件里取消 157 件。事情多，不等于产出多。
• 有些成绩要记在执行工具头上：9 月 26 日我们说过，大意是，那次靠的是 AI 编程工具，没靠 Atelier 平台。
• 还没有无人介入地推进过一个真实项目：平台派出的单件工作，9 月 5 日、6 日在几个产品项目上走通过落地、推送、上线和线上验收；从一句意图出发、无人介入一路做到上线，目前只在测试用的代码仓上跑通过。9 月以来，产品项目的工作绝大多数由主控会话直接组织完成，没有经过平台的受管派发。这里说的 APSer-Atelier 主控包括两部分：面对我们的主控会话（一段 Claude Code 或 Codex 对话），负责组织和派出；Atelier 平台，负责登记每一件事、挂起待拍板、记下要求、按规矩放行并留下记录。

九、为什么重新定位为「可持续交付的底座」？

9 月 27 日凌晨，我们在讨论官网文案时说：「其实，更准确的定位应该是，可持续交付的底座。」对内对外全面替换。原因是一次客户演示准备让我们看清：客户关心的是系统交付之后还能不能持续地改、改错了能不能退回、换了人能不能接手。平台长出来的做法，回答的正是其中属于交付方的那部分。同一时期，对外状态改为「持续打磨中」，入口只有预约交流。

用《权力与预测》的三级分类回看

这篇文章发出后，一位朋友读完推荐了《权力与预测》 [1]。书里把 AI 落地分成三级：改进一个现有环节、其余不动的点解决方案；带来一种新做法的应用解决方案；要求相关的决定一起改变的系统解决方案，价值最大，也最慢。回头看，把写代码交给 AI 编程工具，是点解决方案；6 月的第一代自动执行链、之后的自动派出，是在往应用级走，摔过跤；9 月 9 日那次算账之后，我们转向重新安排「谁产出、谁拍板、谁放行」，这才是系统级的尝试。书里还说，系统级的改动早期指标往往难看，这与我们的反面证据对得上。

按书的说法，AI 生成代码、出方案，做的是预测，会越来越便宜、越来越容易替换；判断留给人。所以我们给定位补了一句机制说明：执行交给可替换的执行器，主控留在 Atelier，该由人拍板的事登记成待拍板、等人答复，规矩编成检查去拦截，按后果轻重分级放行，每一步可核对、可退回。书的详细读法，见本栏目《AI 降下来的是执行的成本：读《权力与预测》，对照制造企业》。

十、它现在做到了哪一步？

平台的推进是一条独立主线；代码与运行服务不开源，当前不做多租户、计费和对外订阅。还没做到的：自主推进一个真实项目；「只留一个面对人的主控会话」仍是目标形态；早期代码还没清理干净；本地大模型接手执行要等真实需求。

十一、接下来打算做什么？

最近的一步，是让平台在一个真实产品项目上完整执行一轮，从接到意图到验收全程留下可核对的记录。9 月 29 日我们问自己：Atelier 离能给客户和同行演示，还有多长时间？答案要看接下来的记录。更远的方向是「可进化的企业应用」，这是要去验证的方向，不作承诺。

活字格新版发布之后：由 Atelier 接替 WorkBuddy 当主控

活字格是葡萄城的低代码平台，我们多年用它为制造企业做定制交付。2026 年 5 月发布的新版开始把 AI 接进平台：开发侧提供 AI 可调用的 MCP 服务和 MCP 插件开发能力，管控侧加入大模型用量计量与调用管控，见《AI 协同开发时代，活字格低代码平台的价值分析》。

设计器对外部 AI 工具开放后，一种做法是让 WorkBuddy 这类通用 AI 工具当主控，执行时经设计器的 MCP 落地。9 月 17 日我们定下的方向是：替代这类没有活字格开发经验的第三方 AI 工具，平台自带的 AI 助手不在替代之列。这条链实际跑过两次：

• 9 月 18 日，执行这一侧：Claude Code 作为外部 AI 工具，经设计器的 MCP 从建页面到保存落盘走完闭环，产物逐项合规，运行页面经人工验收通过；前提是 AI 要完整读取我们的规则文档。
• 9 月 22 日到 23 日，主控这一侧：WorkBuddy 当主控、是工程唯一的写入方，参照我们的设计规范搭一套应用框架，Codex 负责推动和独立复验。首轮没通过；整改后框架 12 项检查、重开工程和小范围扩展通过，会话隔离下的重连等几项没验证完，未记为整体通过。

下一步的计划，是由 Atelier 接替 WorkBuddy 当主控：接需求、拆成一件件事、派执行器经 MCP 落地、独立复核、等人拍板、留痕可回退。两侧都已各跑通一次，Atelier 的接入还没做；9 月 19 日之后，我们的精力一直在排程项目上。交付给客户的应用只依赖活字格运行，不依赖 Atelier 在线。

以下是我们的看法

先有痛点，后有功能。 留下来的做法都对应一个真实的麻烦；被砍掉的，多半是先想出来、再去找用处的。

怀疑是这个平台的一部分。 每一次怀疑都逼着我们算一次账、砍一批功能。

定位要跟着证据走。 「可持续交付的底座」这个定位，是先有了做法、再找到的说法。

如果您也在搭自己的 AI 工作方式，可以常问自己：这套东西，是在帮您交付，还是在占用您交付的时间？

专栏里的其他文章

参考来源