项目越建越多以后，我终于学会了少建项目

2026-09-18 复审：本文已更新至 v0.5。上方播客保留 8 月 6 日录音，尚未随正文重录；涉及项目数量、模型、记忆和归档，请以本次修订的文字为准。

我刚学会不把所有事情塞进一个对话框，马上又走向了另一个极端：既然要分，那就多建几个项目，总不会错吧？

播放器一个项目，风神播客一个项目，测试一个项目，小工具一个项目。公众号、个人 IP、个人管理、公司管理，听起来也都能各有各的家。每个名字都讲得通，每个入口都像是“更专业了”。

可真用一段时间，问题就出来了。

一件事到底去播放器项目，还是去风神播客？测试通过了，到底对应哪个源码和哪个候选？个人 IP 里做了一篇播放器文章，播放器的发布责任是不是也跟着过去？旧项目舍不得删，新项目又不断长，侧栏重新热闹起来。

这就是我对 Codex 的第三次认知变化。

第一次，我把一个对话框聊到死。第二次，我学会了分任务，却把项目也分得太细。第三次才终于明白：任务可以很多，项目应该少而稳定。

什么时候用：每冒出一个新名字时

新功能最容易让人兴奋。一有名字、一张原型、一个仓库，就觉得应该给它建个项目。

我现在会先压住这股冲动，让它在最接近的现有项目里活一阵。只有它连续产生多个结果，而且真的长出了独立事实、独立规则、独立权限、独立发布责任或独立生命周期，才让它分家。

有一句判断特别好用：

它能不能独立活着，也能不能独立死去？

一个按钮不能。一个网站栏目通常也不能。它们会跟着所属产品一起更新、一起验收、一起停更。

另一个更狠的问题是：以后做甲时，我是否愿意默认让它看见乙的文件和规则，也接受一次改动可能同时影响两边？如果不愿意，它们就不该只因为名字相近而住在一起。

项目是少数稳定的家，模型只是当前任务可更换的引擎。

图里的房子不多，但每座房子里面可以有很多房间。项目也是这样。它不会因为文章多、音频多、代码目录多就“撑爆”。真正会撑爆项目的，是互相冲突的权限、真源、发布责任和验收标准。

怎么做：先做一次真实的项目手术

小龙哥自己的项目整理，最初看起来像一道无解题。

风神播客、博客、公众号、普通书稿和个人网站，全部归个人 IP，会不会太大？播放器以前和播客绑在一起，究竟跟内容走，还是跟软件走？游目、披卷、听澜要不要各建项目？小工具和测试是不是可以顺手合并？个人管理和公司运营都围绕小龙哥本人，能不能再省一个项目？“小龙哥的那些年”是不是也应该并进个人 IP？

如果按名字和功能分，这些问题永远吵不完。换成责任边界以后，答案突然变得很清楚。

风神播客、博客、公众号和普通书稿，回到个人 IP

它们共享的是同一个人设、选题素材、表达方式、受众和内容发布责任。播客是一条日常流水线，公众号是一种分发形式，博客和网站是内容承载面。它们不是四家公司。

所以它们可以住在一个项目里，内部按栏目和当期任务分层。今天做一期播客，开一个任务；明天整理一篇公众号，再开一个任务。项目不会因为任务多而爆炸，只会因为没有清楚的总览和目录而变乱。

听澜、游目、披卷，回到“小龙哥 Mac 哲学”

播放器可以播放风神播客，但“播放谁的内容”和“谁负责软件”是两回事。

风神播客的节目、声音、网站和运营归个人 IP。听澜播放器的源码、权限、安装、签名、公证、发布和真实设备测试，归 Mac 产品体系。游目和披卷也是同一套第一方产品能力，可以各有目录、版本和任务，却不必各买一套房。

内容项目可以调用播放器，播放器也可以承载内容。使用关系不等于所有权相同。两个项目之间留一条窄接口，比把内容和软件发布责任揉成一团更干净。

五个常用入口，按长期责任命名

2026 年 9 月 18 日重新回读后，我的五个常用项目已经是下面这些名字。8 月版本写的“六个常设项目”是当时方案，不能再当现状使用。

这些是五个常用入口，不是说侧栏和所有账号只能出现五个项目。此次仍能看到测试实验室、归档项目与另外的 ChatGPT 项目；不能把常用入口规划说成所有历史入口已经删除或全部合并。

五个名字也不是技术上完全互斥的五个箱子。Mac 产品会有内容和工具，公司也会用 AI。遇到交叉，先问“这份成果以后归谁维护”：修 Mac 功能归 Mac哲学；写一篇面向读者的通用 AI 文章归内容创作；改善通用 AI 工作方法归 AI与工具。具体任务仍按产品规则、原始资料和发布责任找真源。

改名称，只解决入口；归属和权限还要另做

这轮五项目整理保留了原项目 ID 和工作目录，首先改变的是 Codex 的显示名。旧目录里仍可能有历史名称，不能由此判断资料丢了，也不能以为改名就完成了资料搬迁。

AI与工具承接架构、规则和手机连接的日常需求，但工程实现与运行资料仍沿用各自真源；固定手机消息入口继续原绑定。显示入口收拢，不需要再复制一份规则或重建一个网关。

测试实验室可用于一次性探索；正式测试必须跟随所属源码、候选与版本，不能只在一个公共抽屉里留下“测试通过”。探索入口是否保留，和正式质量责任属于谁，是两个问题。

个人生活和腾龙公司需要分清资料用途。项目分类本身并不自动形成安全隔离：私人日记、员工资料等，仍要靠文件权限、应用授权和明确的读取范围保护。个人经历可以成为内容素材，也必须先确认适合公开的部分；不能因为入口归为内容创作，就把整套私人史料默认公开。

五这个数字没有魔法。适合我的五项，不一定适合你的工作。重要的是每项能回答：长期负责什么，成果写在哪里，谁能看，怎么验收；太宽会混责，太碎会让同一批资料到处复制。

新项目要过的四道门

以后再冒出新想法，我会让它先回答四个问题。

第一，它会不会持续产生多个不同结果，而不是只有一张原型？

第二，它有没有自己的事实真源和长期规则？

第三，它是否需要独立权限、发布责任或验收方式？

第四，它能否独立暂停、转交甚至停更，而不拖着原项目一起死？

多数答案还不确定，就先作为现有项目里的一条能力线。一个新想法不是新项目，一个原型不是新项目，一个名字更不是新项目。新项目要靠事实长出来，不靠兴奋建出来。

模型怎么选：先看当前可用，再看任务表现

项目整理清楚以后，模型选择是另一层决定。换模型通常不用换项目；资料和规则也不应跟某个模型名字绑死。

截至 2026 年 9 月 18 日，我这里的默认主力已经是 GPT-6 Astra。当前本机工具还列有 Sol、Terra、Luna 与 GPT-5.5；这是我的当前入口快照，不代表每个账号、平台或 API 都有相同选项。旧文“日常 Terra、复杂 Sol”的固定推荐已经不适合继续当作我的现行用法。

Astra 官方模型说明可用来了解能力定位；具体能选什么，以你正在用的客户端和账号为准。选择时看三件事：能否把这类任务做对、等多久、消耗是否合适。不要只凭名字推断，也不要拿一次短回答判断整个模型。

对大多数刚开始使用的人，先用当前可用且可靠的主力模型，把交付物与完成标准说清。只有当速度、费用或某类任务质量成为实际问题时，再用同一组真实样本比较候选模型。小龙哥这里默认 Astra，是当前工作选择，不是要求所有人都照抄。

推理档位、Ultra 和子智能体，分别判断

推理档位决定模型为当前任务投入多少推理。支持哪些档位与模型、客户端、API 和账号有关，不能把某一入口的选项写成所有版本都支持的固定清单。

例如，当前 Astra API 文档列出 low、medium、high、xhigh、max，本机 Codex 的任务工具还列有 ultra。这是入口差异。应使用当前入口实际支持的值，不把本机选项直接抄进 API 请求。

简单、易核对的任务先用足够的档位；跨多个资料找根因、做复杂设计时，可以提高推理强度，再检查是否减少返工。固定主力模型也不等于所有任务一律拉满。

旧文把 Ultra 直接说成“类似多智能体”，不够准确。现行子智能体文档把本地 Codex 的 Ultra 描述为支持模型的最深推理档；是否委派子任务是另一个决定。选了 Ultra，不能据此宣称已经启动多个子智能体。

子智能体适合有清楚输入、输出和验收条件、能独立推进的子工作，例如一个核对官方资料，一个审查候选，主任务回收结论。是否允许委派还要遵守用户、AGENTS.md 或 Skill 的要求；当前本地规则要求明确的委派依据。几个人同时改同一个文件或同一生产环境，依然会互相覆盖，档位再高也解决不了归属问题。

容易踩坑：极简不是只剩一个盒子

• 为了省事把所有内容、软件、私人资料和公司运营塞进一个项目，权限和责任会互相污染。
• 为了显得专业给每个功能建项目，共同真源会被切碎。
• 因为都叫“小龙哥”就合并，名字会遮住隐私和生命周期差异。
• 因为仓库不同就分项目，忽略了一个产品本来就可以有多个相关目录。
• 永远使用最强模型，却从不比较结果、时间和成本。
• 把某个客户端的推理档位当成所有 API 都支持的参数，或把 Ultra 当成已经委派子智能体的证据。
• 把测试项目当中央王国，让“通过”失去版本和候选。

验收标准：以后每件事只走这一条路

先找家：这件事长期是谁负责？

再看工作台：还是原来的结果就继续；结果变了，就在正确项目里新开。

再选模型：先用当前可用且可靠的主力，从足够的推理档位开始；按同类任务的质量、耗时与消耗调整。

执行时看真证据：文件有没有生成，哪一个候选通过，是否真实安装，是否正式发布，用户有没有验收，分别记账。

最后写回项目总览，收口临时工作、交接长期服务、保全代码现场；没有待验收动作或固定入口绑定时，再归档任务。项目继续长，侧栏重新留白。

这就是小龙哥走过三次弯路以后，留下的那条最短路线：

项目少而稳定，任务短而清楚，模型按失败代价选，事实永远写到能接班的地方。

可复用提示词

请不要因为出现了新功能或新名字就建立 Codex 项目。

先判断它是否已经连续产生多个结果，是否拥有独立真源、规则、权限、发布责任和生命周期，并回答它能否独立活着、也能否独立停更。

如果边界还没长出来，请把它放进最接近的现有项目，切成一个可独立验收的任务。

再核对当前入口实际可用的模型和推理档位，按任务表现、耗时与消耗推荐。推理强度和子智能体委派分别判断；只有规则允许、子工作能独立验收且不抢同一文件或环境时，才考虑委派。

最后写明交付证据要落在哪里，什么条件满足后可以归档。

如果你是从第三篇进来的，可以回到开头：先弄清 Codex 到底靠什么接班。