--- id: GUIDE-004 sequence: 7 number: "007" kind: guide slug: codex-model-workflow label: Codex 入门 03 category: AI 协作 topics: - 项目边界 - Codex 模型 - 推理档位 - 多智能体 audience: 已经会开任务，却发现项目越建越多、每次选模型都纠结的人 read_minutes: 13 title: 项目越建越多以后，我终于学会了少建项目 subtitle: 功能可以很多，长期的家要少而稳定；模型只是随任务更换的引擎 summary: 用小龙哥亲手做过的一次项目断舍离，讲清什么应该合、什么必须分、何时新建项目，以及 Luna、Terra、Sol、推理档位和 Ultra 的具体选择。 published_at: "2026-08-06" updated_at: "2026-08-07" version: v0.4 verification: verified visibility: public publication_state: published legacy_path: "" public_url: https://aixlg.com/exp/codex-model-workflow/ wechat_url: "" source_href: https://aixlg.com/exp/codex-model-workflow/ source_cta: 阅读完整指南 article_state: "" takeaways: - 新项目要靠独立边界长出来 - 功能多不会撑爆项目，责任混才会 - 日常 Terra，机械 Luna，高风险 Sol deliverables: - 小龙哥真实项目断舍离案例 - 新项目的四道事实门槛 - Luna、Terra、Sol、推理档位和 Ultra 场景选择 source_refs: - https://learn.chatgpt.com/docs/projects - https://developers.openai.com/api/docs/models - https://developers.openai.com/api/docs/guides/latest-model - https://openai.com/index/gpt-5-6/ - https://learn.chatgpt.com/docs/agent-configuration/subagents - https://learn.chatgpt.com/docs/automations replaces: [] revisions: - version: v0.4 date: "2026-08-07" note: 经小龙哥确认正式发布，文章、原始 Markdown、机器目录与独立播客一并进入公网经验包。 - version: v0.3 date: "2026-08-06" note: 新增宁宁与明明的独立播客版，把小龙哥真实的项目断舍离、六个常设入口、两个条件入口和模型选择串成一条可执行路线；完成高配音频机器质检并嵌入文章。 - version: v0.2 date: "2026-08-06" note: 根据小龙哥 40 分反馈推倒重写，以真实项目手术和具体模型现场替代大表格，并加入原创总关系图。 - version: v0.1 date: "2026-08-06" note: 初版候选，建立项目硬边界、模型选型与完整闭环。 audio: - label: 播客版 · 第三期 note: 宁宁 × 明明｜13:30｜高配版，机器质检通过 src: /exp/audio/codex-projects-models-20260806.mp3 --- > 我刚学会不把所有事情塞进一个对话框，马上又走向了另一个极端：既然要分，那就多建几个项目，总不会错吧？ 播放器一个项目，风神播客一个项目，测试一个项目，小工具一个项目。公众号、个人 IP、个人管理、公司管理，听起来也都能各有各的家。每个名字都讲得通，每个入口都像是“更专业了”。 可真用一段时间，问题就出来了。 一件事到底去播放器项目，还是去风神播客？测试通过了，到底对应哪个源码和哪个候选？个人 IP 里做了一篇播放器文章，播放器的发布责任是不是也跟着过去？旧项目舍不得删，新项目又不断长，侧栏重新热闹起来。 这就是我对 Codex 的第三次认知变化。 第一次，我把一个对话框聊到死。第二次，我学会了分任务，却把项目也分得太细。第三次才终于明白：任务可以很多，项目应该少而稳定。 ## 什么时候用：每冒出一个新名字时 新功能最容易让人兴奋。一有名字、一张原型、一个仓库，就觉得应该给它建个项目。 我现在会先压住这股冲动，让它在最接近的现有项目里活一阵。只有它连续产生多个结果，而且真的长出了独立事实、独立规则、独立权限、独立发布责任或独立生命周期，才让它分家。 有一句判断特别好用： > 它能不能独立活着，也能不能独立死去？ 一个按钮不能。一个网站栏目通常也不能。它们会跟着所属产品一起更新、一起验收、一起停更。 另一个更狠的问题是：以后做甲时，我是否愿意默认让它看见乙的文件和规则，也接受一次改动可能同时影响两边？如果不愿意，它们就不该只因为名字相近而住在一起。 ![少数稳定的项目房屋各有内部房间，窄桥负责协作；当前任务车按需要更换轻巧、均衡或强劲的引擎。](/exp/images/codex-projects-and-models.jpg "项目是少数稳定的家，模型只是当前任务可更换的引擎。") 图里的房子不多，但每座房子里面可以有很多房间。项目也是这样。它不会因为文章多、音频多、代码目录多就“撑爆”。真正会撑爆项目的，是互相冲突的权限、真源、发布责任和验收标准。 ## 怎么做：先做一次真实的项目手术 小龙哥自己的项目整理，最初看起来像一道无解题。 风神播客、博客、公众号、普通书稿和个人网站，全部归个人 IP，会不会太大？播放器以前和播客绑在一起，究竟跟内容走，还是跟软件走？游目、披卷、听澜要不要各建项目？小工具和测试是不是可以顺手合并？个人管理和公司运营都围绕小龙哥本人，能不能再省一个项目？“小龙哥的那些年”是不是也应该并进个人 IP？ 如果按名字和功能分，这些问题永远吵不完。换成责任边界以后，答案突然变得很清楚。 ### 风神播客、博客、公众号和普通书稿，回到个人 IP 它们共享的是同一个人设、选题素材、表达方式、受众和内容发布责任。播客是一条日常流水线，公众号是一种分发形式，博客和网站是内容承载面。它们不是四家公司。 所以它们可以住在一个项目里，内部按栏目和当期任务分层。今天做一期播客，开一个任务；明天整理一篇公众号，再开一个任务。项目不会因为任务多而爆炸，只会因为没有清楚的总览和目录而变乱。 ### 听澜、游目、披卷，回到“小龙哥 Mac 哲学” 播放器可以播放风神播客，但“播放谁的内容”和“谁负责软件”是两回事。 风神播客的节目、声音、网站和运营归个人 IP。听澜播放器的源码、权限、安装、签名、公证、发布和真实设备测试，归 Mac 产品体系。游目和披卷也是同一套第一方产品能力，可以各有目录、版本和任务，却不必各买一套房。 内容项目可以调用播放器，播放器也可以承载内容。使用关系不等于所有权相同。两个项目之间留一条窄接口，比把内容和软件发布责任揉成一团更干净。 ### 小工具保留，测试项目退出 极简小工具是一个真正的工坊：它持续产出独立、轻量、可复用的工具，所以保留。 测试不是一门独立业务。正式测试必须跟着所属源码、候选版本和环境走。播放器的测试回播放器所属产品，网站的测试回网站所属项目。否则一句“测试通过”，没人知道通过的是哪一个版本。 把测试塞进小工具，也只是把旧杂物抽屉换了个标签。一次性探索可以开普通任务；确实需要隔离时，用临时沙箱或工作树。它们都不需要升格为长期项目。 ### 个人管理和公司运营，连接，但不合并 两边都会出现小龙哥本人，不代表它们共享责任。 个人管理里有日记、健康、私人资料和个人决策；公司运营里有员工、客户、门店、经营流程和企业权限。私人日记不该默认暴露给公司任务，员工数据也不该塞进个人生活项目。 它们可以通过一条窄接口协作：公司产生需要本人处理的事项，进入个人待办；本人完成经营决定，再回写公司真源。可以连接，不必合并。 ### “小龙哥的那些年”，暂时不动 它可能给个人 IP 提供故事，但自传、口述史、老照片、隐私和长期编纂节奏，与每天的品牌内容并不相同。现在没有必要为了极简强行搬家。等它真的启动，再看是否已经长出独立史料真源、隐私边界和出版生命周期。 这叫条件项目：不靠想象提前装修，也不因为名字相近就仓促并入。 ### 最后留下的，不是一锅粥，也不是几十个抽屉 整理以后，小龙哥的日常入口收成了六个常设项目：Codex 架构与效率、小龙哥 Mac 哲学、极简小工具、AI 小龙哥个人 IP、个人管理、公司运营。手机端基础设施和“小龙哥的那些年”暂时作为条件项目，只有真的承担独立长期责任时才进入活跃区。 六这个数字没有魔法。重要的是每一个都能回答：长期负责什么，哪些东西不归它，真源在哪里，谁能看，怎样验收，什么时候可以停。少一个会混责，多一个会把共同上下文切碎。 ## 新项目要过的四道门 以后再冒出新想法，我会让它先回答四个问题。 第一，它会不会持续产生多个不同结果，而不是只有一张原型？ 第二，它有没有自己的事实真源和长期规则？ 第三，它是否需要独立权限、发布责任或验收方式？ 第四，它能否独立暂停、转交甚至停更，而不拖着原项目一起死？ 多数答案还不确定，就先作为现有项目里的一条能力线。一个新想法不是新项目，一个原型不是新项目，一个名字更不是新项目。新项目要靠事实长出来，不靠兴奋建出来。 ## 模型怎么选：别再把“最强”当默认答案 项目整理清楚以后，模型其实比想象中好选。 先记住：模型不是房子，也不是记忆。它是当前任务车上的引擎。换模型不用换项目，通常也不用换对话框。 截至 2026 年 8 月 6 日，OpenAI 对 GPT-5.6 三个层级的定位是：Sol 面向复杂推理、编码和专业工作；Terra 平衡智能与成本；Luna 面向成本敏感的大批量工作。把官方定位翻成日常现场，大概是这样。 要把五十份资料按同一规则分类、抽字段、改格式，失败也很容易看出来，用 Luna。它适合规则清楚、机械、批量、低风险的活。 要写一篇日常文章、修改常规代码、整理项目文件、处理一个边界清楚的故障，用 Terra。它是最省心的日常起点。拿不准时，从 Terra 的中等推理开始，通常比每次纠结排行榜更有效。 要做项目大手术、跨多个真源查根因、审高风险发布、决定权限或长期架构，用 Sol。因为这类任务一旦理解错，返工代价远大于多花的时间。 这不是永久排行榜。以后名字会变，价格会变，能力也会变。真正不会过时的是三个问题：失败代价高不高？工作能不能机械验收？更强推理有没有带来实测收益？ ## 推理档位不是军衔，Ultra 也不是“再高一格” GPT-5.6 当前支持 `none、low、medium、high、xhigh、max`。官方建议把 `medium` 当平衡起点，延迟敏感时用 `low`，只有测出质量收益再升到 `high` 或 `xhigh`，把 `max` 留给最难、最看重质量的任务。 所以，简单改格式开满并不会更专业，只会更慢。复杂任务也不必一上来拉满：先让模型完成一个可验证步骤，发现理解深度不够，再升级。 Ultra 解决的是另一件事。它类似多智能体协作：官方资料核验、历史证据整理、站点检查三条路线可以独立并行，最后由主任务合并，这时有意义。几个人同时改同一个文件、抢同一个生产环境，不叫强，只叫互相踩脚。 给小白一个可以直接用的默认值： > 机械批量，Luna 低档或中档；日常大多数工作，Terra 中档；复杂高风险，Sol 高档；只有确实能拆成互不重叠的工作流，才考虑 Ultra。 选错了也不用重建项目。模型是执行参数，不是身份承诺。看证据，随时调档。 ## 容易踩坑：极简不是只剩一个盒子 - 为了省事把所有内容、软件、私人资料和公司运营塞进一个项目，权限和责任会互相污染。 - 为了显得专业给每个功能建项目，共同真源会被切碎。 - 因为都叫“小龙哥”就合并，名字会遮住隐私和生命周期差异。 - 因为仓库不同就分项目，忽略了一个产品本来就可以有多个相关目录。 - 永远使用最强模型，却从不比较结果、时间和成本。 - 把 `max` 和 Ultra 混成一条从低到高的刻度。 - 把测试项目当中央王国，让“通过”失去版本和候选。 ## 验收标准：以后每件事只走这一条路 先找家：这件事长期是谁负责？ 再看工作台：还是原来的结果就继续；结果变了，就在正确项目里新开。 再选引擎：机械用 Luna，日常用 Terra，复杂高风险用 Sol；从最小够用档位开始。 执行时看真证据：文件有没有生成，哪一个候选通过，是否真实安装，是否正式发布，用户有没有验收，分别记账。 最后写回项目总览，停净后台，处理代码现场，归档任务。项目继续长，侧栏重新留白。 这就是小龙哥走过三次弯路以后，留下的那条最短路线： > 项目少而稳定，任务短而清楚，模型按失败代价选，事实永远写到能接班的地方。 ## 可复用提示词 ~~~text 请不要因为出现了新功能或新名字就建立 Codex 项目。 先判断它是否已经连续产生多个结果，是否拥有独立真源、规则、权限、发布责任和生命周期，并回答它能否独立活着、也能否独立停更。 如果边界还没长出来，请把它放进最接近的现有项目，切成一个可独立验收的任务。 再按失败代价推荐 Luna、Terra 或 Sol，并从最小够用的推理档位开始。只有子工作能清楚拆开、不会抢同一文件或环境时，才建议 Ultra 或多智能体。 最后写明交付证据要落在哪里，什么条件满足后可以归档。 ~~~ 如果你是从第三篇进来的，可以回到开头：[先弄清 Codex 到底靠什么接班](/exp/codex-project-task-basics/)。