为什么我把 Codex、newtype-os、ChatGPT 分开用

第 3 篇文章发布那天，我差点犯一个错误。

不是代码报错，不是 build 失败。上传前检查时，我发现 drafts 目录有两份 newtype-os 生成的文件：一份是人确认过的 v0.2 草稿，另一份是包含工具交接记录、质量评分和工具交付数据的中文编辑指令文件。两份文件来自同一套工具，但性质完全不同。我差点把后者当成正式稿。

那一刻我意识到：技术工具都能跑通之后，真正的问题不是技术——而是”谁该干什么”的边界问题。

差点踩的坑

发布流程走到”上传”这一步时，我本能地想，让 Codex 来处理文章的语言细节吧——它既然能读写文件，应该也能改文章吧？

这是一个典型的”功能诱惑”：工具功能越多，越容易产生”用它干所有事”的冲动。不光是网站功能会让人想加加加，工具的使用边界也一样。很多项目做不下去，不是因为工具不够强，而是因为什么活都往同一个工具里塞。

好在工具边界提前划清楚了。Codex 的工作范围定在”工程执行”，不包含”文章质量打磨”。实际操作回到了正确路径：newtype-os 负责内容打磨，Codex 只负责工程执行。最终发布流程是：ChatGPT 提供结构 → 用户运行 nt write + nt edit → 人确认草稿 → Codex 创建正式文章、build、发布。

当然，分工不是绝对隔离。ChatGPT 的讨论可能影响文章结构，newtype-os 的打磨需要人的判断，Codex 的发布状态需要回传给 ChatGPT 做验收——信息是流通的，职责是清晰的。

那两份文件的混淆也在这次复盘后，被记录到《造物栈文章发布 SOP v0.2》和《文章质量审核与 newtype-os 打磨流程 v0.1》中，作为后续发布的约束规则。

四层分工

这次差点翻车让我更清楚地看到已经在用的四层结构——三个 AI 工具，加上人。

ChatGPT——战略层。 选题行不行，结构合不合理，材料够不够，先扔给它聊一轮。第 3 篇文章的选题就是从 ChatGPT 那里拿到结构反馈后确认的。它还帮我拆解了发布步骤、生成了 newtype-os 的输入模板、做最终的验收检查。它是一个讨论伙伴和结构顾问，不是执行工具。

之所以放在战略层，是因为它的对话能力天然适合”不确定→确定”的过程。选题好不好、逻辑有没有漏洞、有没有更好的切入点——这些问题需要讨论，而不是执行。

newtype-os——工艺层。 它是一套独立的 CLI 工具，专门负责文章生成、编辑、去 AI 味、减少概念包装、调整段落节奏。输出只进 docs/drafts，不会直接变成正式文章。真正的语言打磨——去掉 AI 常见的长尾形容词、让段落更有呼吸感、把”首先其次最后”换成自然的叙事节奏——这些事在这里完成。

Codex——工程层。 它只在真实目录里干工程活：创建正式文章文件、跑两次 build 确认构建正常、生成 sitemap、git add/commit/push、检查 Cloudflare Pages 上线状态。在造物栈的工作流中，Codex 不负责文章质量打磨——不是不能，而是这个分工更稳定。

人——决策层。 每次 newtype-os 输出草稿后，必须由人确认才能进入下一步。ChatGPT 的验收建议是参考，不是命令。Codex 的执行清单必须经过人审核。这个”人”不是流程里的点缀——他是唯一能对内容最终负责的角色。

一个判断

ChatGPT 的强项是对话式讨论和结构判断，newtype-os 的强项是专注的文本打磨，Codex 的强项是可靠的工程执行。把它们混成一个万能工具，表面效率高，实际上每次上下文切换都在丢失精度——ChatGPT 的长尾输出不适合直接当文稿，newtype-os 不能操作真实工程目录，Codex 的语言审美依赖注入的上下文质量。

分工不是为了复杂化，而是为了项目稳定。每个工具做自己擅长的事，输入输出清晰，出了问题知道找谁——哪个工具，哪一层。

这不是一篇”完美协作流程”展示。它只是第 3 篇文章生产过程中的一次实际边界碰壁。工具越多，功能诱惑越大——总想用同一个工具解决所有问题。但经历过一次差点翻车的发布后，我确认了一件事：

技术问题解决之后，真正的问题才开始——谁负责什么，输出到哪里，怎么验收。