——从小白配置指南聊聊“AI 工作流治理”的底层逻辑

> 你用 ChatGPT 的逻辑打开 Codex，就像在夜总会点了一壶茶。不是不能点，但你会错过这个地方的多数可能性。

最近读到一篇非常实在的 Codex 新手教程——原作者用非常接地气的语气，讲了一个看似不用脑子的问题：一个 Windows 小白，怎么把 Codex 从“能聊天”，配置到“真的能做项目”。

看完我想说的不是“教程真好”，而是：这篇文章无意中揭开了 AI 助手下半场真正的核心命题——空间治理，或者说“给 AI 干活的房间怎么装修”。

—

🔑 一个被说透但少有人做的结论：先建项目，再问问题

原文的开场很长，但核心结论其实一句就够：

> “新手第一次用 Codex，最该先配置的不是模型，而是项目文件夹。”

这句话太重要了。因为大多数从 ChatGPT 转过来的用户——包括三个月前的我——都会犯同一个错：打开一个对话窗口，就开始扔需求。ChatGPT 能接受这种方式，因为 ChatGPT 是在一个无状态的对话空间里回答问题，内容以信息流形式存在。

但 Codex 不一样。它能读文件、写文件、改代码、跑命令、装插件、连 MCP。它一出手，就是物理操作。

你让它整理一份资料，它可能： – 创建一堆中间文件到你桌面 – 装一个你不认识的插件 – 跑一行你不懂的 Python 脚本 – 把缓存数据混进你的笔记库 – 把生成的代码和你的原项目文件搅在一起

信息流和物理操作的本质区别是什么？前者可以被遗忘，后者必须被追责。

所以原文的第一个认知非常关键：Codex 不是答题器，它是进入你文件系统的操作代理（Operational Agent）。你的第一个问题不应该是“你能做什么”，而是“我允许你在哪、以什么规则、在什么边界内做事”。

这叫空间治理。不是玄学，是基本常识。

🏗️ 三大文件：README / AGENTS / CONTEXT 的本质是“上下文对齐协议”

原文推荐每个项目放三个文件： – README.md → 给人看 – AGENTS.md → 给 Codex 看的工作规则 – CONTEXT.md → 给 Codex 看的业务背景

很多人一看这三个名字会觉得“不就是把项目文档拆成三份吗”。不，拆三份的不是信息，是对接口的管理。

让我用自己的话翻译：

README.md 是“人类视角的说明书” → 告诉后来接手这个项目的人（三周后的自己也是“别人”），这是什么东西、怎么跑、产出在哪。它是知识的容器，负责保留下文。

AGENTS.md 是“机器视角的行为约束” → 不是告诉 Codex 你是什么，而是告诉它你能做什么、不能做什么、必须怎么做。比如：修改前先读取哪些文件、输出到哪里、生成报告要包含哪些字段、不允许在未经确认时直接联网搜索。它是护栏。

CONTEXT.md 是“机器视角的决策上下文” → 背景知识、目标用户画像、公司政策、输出格式、甚至”不要建议开源方案因为企业要求商采”。它是决策燃料。

这三个文件合起来，构成了一套人机接口协议。过去工程师的接口是人跟 API 之间的事，现在变成了人、AI、项目之间的事。

我的观点： 这本质上就是我在之前 OpenSpec 那篇文章里提到的 `specs/` 目录的另一种表现形式。只不过 OpenSpec 解决的是多 Agent 协作时的协议标准化，而 Codex 的三大文件解决的是单 Agent 场景下的上下文对齐。它们在逻辑上是同一件事：把规律性的东西变成机器可读取的契约。

🧩 插件 / Skill / MCP 的分层不是技术问题，是治理问题

原文用一张表对小白解释了三个概念的区别：

| 东西 | 理解 | 什么时候用 | |——|——|————| | Plugin | 给 Codex 装能力包 | 做表格、PPT、浏览器操作 | | Skill | 工作流说明书 | 固定流程（整理资料、审校文档） | | MCP | 外部工具通道 | 连接本地或远程专业工具 |

很多人按这张图的理解是：先装 Plugin，不够写 Skill，再不够上 MCP。这个路径客观上没错，但如果你只按这个线性看，会错过一个重要的治理逻辑。

这三个东西不是”能力大小”的递进，而是”能力治理层级”的递进。

– Plugin 是标准化能力 —— 官方打包好的功能，开箱即用。它的治理成本最低，但有预设边界。你不想也不会深入到它的操作。 – Skill 是定制化流程 —— 你把个人或团队的工作套路编码成可执行契约。治理成本来了：你要定义流程步骤、上下文规则、输出模板。但如果这个流程跨项目都要用，你还需要版本化管理。 – MCP 是外部系统通道 —— 连接一个外部数据源或工具，相当于给 Codex 开了个 API 门。这里的治理成本最高：权限、速率、安全、审计。你不再只是管理一个 UI，你管理的是系统准入。

原文建议小白先别装一堆插件。我想把这个建议再推进一步：能力治理的原则应该是”明确意图，再放大能力”，而不是”先有能力的，再去找场景”。

这和之前我在 Harness Engineering 里说的也一样：给 AI 的工具不是越多越好，而是”越知道你在做什么越好”。

⚠️ 十个坑的真实统一病因：没有系统边界

原文列了小白最容易踩的 10 个坑，我过一遍后觉得它们其实可以归为三类：

第一类：空间缺失 1. 没建项目文件夹 2. 把项目放进日常笔记库或同步盘 3. 没写 AGENTS.md 4. 没写 CONTEXT.md

病根：没有给 AI 划定物理和逻辑边界。 就像你让一个工人来家里装修，但你没有指定他只能在哪间屋、只能用哪些工具、瓷砖什么颜色。他有权放开了干，结果你只能慢慢收拾。

第二类：安全无意识 5. 看到权限确认就点 6. 插件乱装 7. 把 API Key 写进 Markdown

病根：把 AI 助手当成”听话的回答器”而不是”有执行力的工具”。 当一个工具开始写入你的硬盘，它就不再只是一个信息提供者，它是代理行为者。你点”确认”的那个瞬间，本质上是做了一次托管。大多数人连确认按钮上写的是什么都没看，这和你把陌生人放进家里关上了防盗门有什么区别？

第三类：迭代方式和验证意识 8. 不看右侧文件变化 9. 不满意就重开（而不是基于已有结果改） 10. 不做最小验证

病根：没有把 AI 当成协作伙伴，而是把它当成了一个“生利机器”。 你看不懂它改了什么、不追问为什么、验证没有闭环——这不是使用 AI，这是把 AI 当成一个无意识的黑箱。

💡 我想补充的第 11 个坑：用 ChatGPT 的思维方式使用 Codex

原文没明说但字里行间一个最大的坑，我来把它挑明：

> 用 ChatGPT 的思维方式使用 Codex，根本上的差异不是 UI 不同，不是功能多少，是”AI 的运行空间从信息流变成了文件系统”，你必须从信息管理思维切换成空间治理思维。

ChatGPT 时代，你教会人们的是”如何写好提示词”。但 Codex 时代，你首先要教会人们的是”如何准备让 AI 干活的环境”。这个环境不是一个 prompt，而是一个工作空间（workspace），它包含： – 物理位置（项目目录） – 治理规则（AGENTS.md） – 决策燃料（CONTEXT.md） – 知识容器（README.md） – 能力边界（Plugin / Skill / MCP 的范围） – 安全约束（权限、审计、验证）

这就是 AI 工作流治理的底层逻辑。不是大模型玄学，不是提示工程，而是工程化地管理一个执行代理在你的系统上的活动。

🔗 和之前文章的呼应：这是同一棵大树的不同分支

如果你读过我之前两篇： – [OpenSpec + 多 Agent 工程化](http://helloxin.cn/archives/49.html) – [AI 时代前后端分离 vs 全栈开发](http://helloxin.cn/archives/53.html)

这篇文章和它们构成了一条线：

OpenSpec 讲的是”多 Agent 协作的协议标准化” → `specs/` 是契约，`changes/` 是变更的完整上下文，Delta 标记确保多人/多 Agent 理解一致。那里解决的问题是”多个智能体怎么对齐”。

Harness Engineering 讲的是”人在 AI 系统中的新角色” → AI 放大了执行效率，人的价值从”写代码”转到”编织决策和系统”。那里解决的问题是”人怎么升级”。

这篇文章要讲的是”单 Agent 在真实项目中的上下文对齐” → README / AGENTS / CONTEXT 就是一次”将项目状态对齐给 AI”的具体方案。这里解决的问题是”单个人+一个强大代理怎么高效协作”。

三件事合在一起，其实是同一个大主题：AI 时代的工程化，不只是能跑，而是可治理。

🎯 给不同阶段的读者一句话建议

如果你还没用过 Codex：先去建一个项目文件夹，不要急着打开对话窗口。先准备好 README、AGENTS、CONTEXT，再让 AI 进来。这就像你请工人来家里，先指好房间再让他动手。

如果你已经在用，但文件满天飞：停下来整理项目结构。不是代码需要被重构，是你的 AI 协作环境需要被重构。

如果你是团队负责人：这三文件不是个例，它应该是一个团队模板。做团队级 `template_codex_project/`，把共识（AGENTS.md + CONTEXT.md 的部分内容）抽象成 org 级别，然后每个新项目初始化时拉取这个模板。把个人经验变成制度性能力，这就是 Harness Engineering 团队级别的实践。

> Codex 最容易被低估的地方，不是它会不会写代码。而是它能不能进入你的真实工作流。 这个”能不能”的决定权不在它，在你有没有给它准备一个“房间”。

原文参考 [Codex 小白第一次真正上手配置教程](https://mp.weixin.qq.com/s/DuIOd6qLH8_4_3iP9XKXwg) —— 原作者是面向小白的实战指南，本文在此基础上做了一套系统性升维。