Claude Code、Codex 与 APSer-Atelier：一个人同时交付多个项目的使用体会

先说结论

• 2026 年我们用 AI 编程工具的方式变了三次：春天以 Claude Code 为主，8 月上旬转到 Codex，8 月底起两家并用、按任务能力分工。
• 换工具时最费力的是规则难以继承：两家读取的说明文件、文件引用写法、记忆存放位置和自动检查的开关方式都不同，只写在一家专用文件和私有记忆里的规矩，到另一家就不生效。
• 两家并用后的应对：项目的工程知识一律写进项目仓库自己的文档；同一个项目同一时间只允许一个写入者；一家写完由另一家只读复审；指挥状态放进持久的记录，对话用完即弃。
• APSer-Atelier 在两家工具之上担任主控：接住要做的事，决定交给哪一家，核对结果，留下记录；两家只是它调度的执行器。

APSer 是一人公司：由创始人主导交付，AI 编程工具承担大量执行工作，同时推进的项目通常有好几个。2026 年这一年，我们用过的 AI 编程工具主要是两家：Claude Code 和 Codex。从春天到秋天，使用方式前后变了三次：先以一家为主，再转到另一家，最后两家并用。

本文按时间记录这段经过：每一段遇到了什么，当时怎么应对，留下了哪些做法。前五节只写事实和我们自己的使用情况；我们的观点集中放在最后一节，并标明为观点。

需要先说明两点。第一，两家工具都在快速更新，文中写到的行为是我们使用时的情况，现在可能已经不同。第二，文中写到的不便，多数来自我们自己的习惯和原有规则，属于换工具时我们这一侧要付的代价，与工具本身的好坏无关。

本文反复用到两个词，先说清楚。执行器，是真正读代码、改代码、跑测试的 AI 编程工具，本文里指 Claude Code 和 Codex；它负责把交给它的一件事做完。主控，是站在执行器之上组织工作的一层：接住要做的事，决定交给哪个执行器，安排复核，核对结果，留下记录。在我们这里，主控是自研的 APSer-Atelier，包括两部分：面对我们的主控会话（一段 Claude Code 或 Codex 对话），负责组织和派出；Atelier 平台，负责登记每一件事、挂起待拍板、记下要求、按规矩放行并留下记录。

一、春天以 Claude Code 为主时，遇到了哪些麻烦？

2026 年 4 月起，我们的主力工具是 Claude Code：在命令行里读代码、改代码、跑构建、提交版本。

最早的一个麻烦出在「搬运」上。那时我们习惯在网页版对话里想方案、定决策，再到命令行里的 Claude Code 去执行。两边的上下文互不相通：方案要从网页复制到命令行，执行结果要截图贴回网页，网页给出的意见再复制回命令行。人在中间来回搬，既费时间，也容易漏掉细节。当时的应对，是把项目的规矩和背景写进 CLAUDE.md。CLAUDE.md 是放在项目根目录的一份说明文件，Claude Code 每次启动会自动读取。

第二个麻烦出在会话记录上。Claude Code 的本地会话记录默认只保留一段时间，到期自动清理。之后我们把保留期调长，并把旧记录单独归档备份。

到了 6 月，我们意识到另一件事：项目的规矩、踩过的坑、实测得出的结论，几乎全部写在只有一家工具会读的说明文件里。这些内容本来属于项目，却只能通过一家工具生效。当时给自己定了一个目标：哪天换了工具，项目开发和日常运营也不受影响。从那时起，我们开始把文档改写成不依赖某一家工具的形式。这项工作进展不快，到 8 月还远没有做完。

二、8 月上旬转到 Codex，原有的规则为什么难以继承？

8 月上旬，账号或服务的可用性出了变化，我们把主要工作转到了 Codex。

Codex 能用，开发很快接续上了。不习惯的是我们自己：用了几个月的交互方式和工作节奏，换一家工具就要重新熟悉；原来那套规则也没法原样搬过去。

规则难以平滑继承，具体来自两家在机制上的几处差异。下面这些都是两家各自的设计，各有道理；麻烦在于我们原有的规则是照着其中一家的习惯一点点长出来的。

读取的说明文件不同。 Claude Code 自动读取 CLAUDE.md；Codex 读取 AGENTS.md。AGENTS.md 是多家 AI 编程工具都认的开放约定，同样放在项目根目录，作用也是给工具交代项目背景和规矩。我们的规矩当时几乎都写在 CLAUDE.md 里，Codex 侧的规则文件还没补齐。结果是，一部分规矩在新工具里没有生效。

文件之间的引用写法不通用。 CLAUDE.md 支持用 @文件名 的写法，把另一份文件的内容一并引入。我们后来想过让两家共用同一份规矩：规矩写在 AGENTS.md 里，CLAUDE.md 顶部写一行 @AGENTS.md 引入。这对 Claude Code 有效；Codex 不读取 CLAUDE.md，也就不会处理其中的引用。所以给 Codex 交接工作时，要明确把 AGENTS.md 排在阅读顺序的第一位。

记忆放在不同的地方。 两家工具都有自己的「记忆」，用来记住跨会话的偏好和经验，但存放位置和组织方式不同，没有现成的办法把一边的记忆整体搬到另一边。我们只能逐条盘点：哪条仍然有效，哪条应该写进项目文档，哪条已经过时，哪条含有不该带走的敏感信息。盘点完再按项目分批迁移，一个项目重新活跃起来时才处理它那一批。

自动检查的开关方式不同。 两家都支持在特定时机自动运行检查脚本，比如提交前检查格式、输出前检查语言。在 Claude Code 里，这些检查写在设置文件中，没有单条检查的开关，想暂停其中一条，只能把它从设置里整条摘出来；Codex 可以在配置里按条启用或关闭。同一条规矩，要在两边各写一份、分别维护，也就容易出现一边改了、另一边没跟上。

这几处差异单看都不大，叠在一起，就是换工具时我们这一侧要付的一笔代价。回头看，6 月开始的文档改写方向是对的，只是做得不够早，也不够彻底。

三、8 月底起两家并用，怎样按能力分工？

8 月上旬有一段时间，我们主要只用一家；到了月底，改为两家都接入，按任务能力分配。我们不再押注某一家工具：两家都作为可以互相替换的执行器，也都可以担任复核者。

9 月初，分工进一步明确。在我们的使用中，大致是这样分的：

• 架构判断、跨项目的综合分析、需要长上下文的复杂实现，多由 Claude Code 在交互对话里主导；
• 需要大量运行命令、跑测试、构建、部署和复杂诊断的工作，多交给 Codex；
• 一家的账号或服务暂时不可用时，同一件事由另一家接手，接着原来的进度往下做，不另起一件新任务。

这份分工是按我们手上的任务类型和当时的可用性定的，会随工具更新和任务变化调整，不代表两家能力的高低。

四、两家并用带来了哪些新问题，怎样应对？

两家并用以后，单一工具时不明显的几个问题都冒了出来。

知识只在一家那边

项目知识如果只存在某一家工具的记忆里，另一家接手时就看不到。我们的应对是：凡是项目的工程知识，包括架构决定、「已经定下、不要重新发明」的结论、踩过的坑、实测结论，一律写进项目仓库自己的文档，短条目进 AGENTS.md，长的写成单独的决策记录。各家工具私有的记忆里，只放和协作方式有关的偏好。

判断的标准只有一句：如果明天换一个工具接手这个项目，它需要知道的内容，就不能只存在某一家工具的记忆里。

同一个项目被几路同时改

两家同时在跑，很容易出现两路改动落在同一个项目上，互相覆盖，版本号和变更记录也跟着打架。我们的应对是：同一个项目同一时间只允许一个写入者，不同项目之间可以并行。

自己审自己，看不出问题

同一家工具写完再自己检查，思路往往和写的时候一样，容易看不出问题。我们的应对是跨家族复审：除了低风险的小改动，一家写完，由另一家只读复审，只看、只提意见，不动手改；同一家不审自己的改动。

两家互相复审，都发现过对方需要返修的问题。这也说明，复审的价值来自「换一双眼睛」，与哪一家担任复审方无关。

对 AI 生成的代码保留审慎，在行业里也很普遍。Google Cloud 的 DORA 研究团队 2025 年 9 月发布的报告，调查了全球近 5,000 名技术从业者：90% 在工作中使用 AI，同时有 30% 表示对 AI 生成的代码很少信任或完全不信任；报告据此认为，使用 AI 的团队需要具备批判性验证的能力 [1]。

长会话在机器重启后很难原样续上

一段对话开得越久，里面积累的上下文越多，也越依赖这段对话一直开着。机器一重启，长会话很难原样续上，里面的进度、判断和待办就跟着散了。我们的应对是：把指挥状态放进持久的记录里，包括当前在做哪件事、停在哪一步、有哪些等人决定的事项；对话只当作临时的执行场所，用完即弃。离开手头一件事之前，先写下「下一步做什么、什么条件下继续」，下一段对话无论用哪家工具，都从这里接着做。

两边的规矩对不上

两家的自动检查写法不同、开关方式不同，时间一长，清单上登记的检查和实际生效的检查就对不上了。我们的应对是维护一份统一的检查清单，并在 APSer-Atelier 里提供一处统一查看的页面，下一节会讲到。

几种管法的对照

同时用几家 AI 编程工具，常见的管法有下面几种。下表按我们关心的几件事逐项对照，您可以按自己的场景取舍。

五、Atelier 在其中做什么？

Atelier 是我们自研、在自身交付中使用的工作平台，在两家工具之上担任主控：接住要做的事，决定交给哪一家，核对结果，留下记录；两家只是它调度的执行器。它的来历和服务的场景，另一篇文章《APSer-Atelier 的场景锚定与价值定位，以及实践总结》有完整介绍。这里只讲它和两家工具相关、而且已经在用的部分。

• 两家都作为执行器接入。 一项工作派出去时，可以交给 Codex，也可以交给 Claude Code。
• 派出一项工作时，由系统选执行器，也可以直接指定一家。 交给平台派出时，由系统按两家当时的可用性和这项任务的要求自动选定执行器；也可以直接在指定一家的会话里做。
• 可以开启另一家复审。 开启后，一家写完，系统安排另一家只读复审，低风险的改动不送审；不接受同一家自审。
• 两家的自动检查在一页里看。 一个页面汇总两家实际生效的自动检查；Claude Code 一侧与登记清单逐条比对，哪里对不上会直接标出来，Codex 一侧目前只列出、不比对。由本人在本机设置口令之后，可以在这里停用或恢复单条检查，每次操作都要输入这个口令。
• 会话记录只建索引，不复制。 Claude Code 的原生会话正文留在它原来的位置，Atelier 只记录索引，需要时只读打开查看，不另存一份。
• 执行时的权限刻意收窄。 派出去执行的工作只在隔离出来的工作区里改动，担任复审的一方只能读、不能改。这是我们主动做的安排，用来约束执行过程，与哪一家工具的能力无关。

Atelier 目前仍在持续打磨中，对外的入口只有预约交流。上面列的是已经在我们自己的交付中使用的部分，不构成对未来产品功能的承诺。

按《权力与预测》一书的说法，执行器做的是预测，会越来越便宜、越来越容易替换；和它互补的判断和记录，才是要长期积累的部分 [2]。这也是我们把认知放进开放格式文档、放在 Atelier 这一层的原因。

六、同时用几家工具，可以按什么顺序整理？

如果您的项目也在同时用几家 AI 编程工具，可以参照我们整理的顺序：

1. 把项目规矩从工具专用的说明文件挪进项目仓库的 AGENTS.md。 多家工具都读同一份规矩，换工具时不必重写。
2. 逐条盘点各家工具的记忆，工程知识写回项目文档。 换一家接手时，它需要知道的内容不能只在上一家的记忆里。
3. 定下「同一个项目同一时间只有一个写入者」。 两路改动落在同一个项目上会互相覆盖；在我们这里由 APSer-Atelier 登记每个项目当前的写入者。
4. 按任务类型写一份分工，写明一家不可用时由另一家接手。 分工清楚，切换时接着原来的进度做，不另起一件新任务。
5. 开启跨家族只读复审。 一家写完由另一家只看、只提意见，换一双眼睛才看得出同一思路里的盲点；在我们这里由 Atelier 安排复审方，同一家不审自己。
6. 离开一件事之前写下交接点：下一步做什么、什么条件下继续。 对话中断或机器重启后，任何一家都能从这里接着做。
7. 把两家的自动检查汇总成一份清单，定期对照实际生效的情况。 两家写法和开关方式不同，时间一长就会对不上；我们在 Atelier 里用一个页面统一查看。

以下是我们的看法

以下内容是我们的观点，供您参考。

第一，两家各有擅长，按能力分工比押注一家稳。 在我们的使用中，两家工具在不同类型的任务上各有顺手的地方。按任务能力分配，一家暂时不可用时另一家能接着做，手上的工作就不会停下来。押注一家，省去了两套规则的维护，但可用性一旦变化，所有工作会一起受影响。

第二，规矩和知识要放在任何一家工具之外。 换工具时最费力的，是那些只写在一家工具专用文件和私有记忆里的规矩与经验。把它们写进项目自己的、多家工具都能读的开放格式文档，换工具时要付的代价会小很多。这件事越早做越省事，等到真要换工具再补，就只能边换边补。

第三，让不同的工具互相复审。 同一家工具自己检查自己，容易沿着原来的思路走下去。换一家来审，看问题的角度会不一样。在我们这里，这一条带来的收获比预想的多。

第四，场景决定工具。 我们的场景是一个人同时推进多个项目，最在意的是换了工具和对话还能续上、改动之间不互相踩、结果有人复核。您的场景如果不同，合用的工具和用法也会不同。别处行之有效的做法，放到自己的场景里验过再用。

如果您也在用 AI 编程工具做项目交付，或者正在考虑同时用几家工具，欢迎预约交流，聊聊各自的做法。

参考来源