用 Codex 搭建自媒体运营与网站开发团队：角色、模型与协作流程

适用场景与完成后的结果

如果你一个人同时运营公众号、知乎、小红书、短视频账号和网站，最常见的困境不是“不会用 AI”，而是每天都在不同任务之间切换：上午追热点、下午写文章、晚上改网页，最后没有任何一项做深。把所有工作交给同一个 Codex 对话，也会让上下文越来越乱、模型额度越来越快耗尽。

这篇教程用一支小型“自媒体运营与网站开发团队”举例。读完后，你可以在自己的 Codex 项目中配置中文岗位分工：谁负责决定今天做什么，谁负责找资料，谁负责写内容，谁负责改网站，谁负责验收。每个岗位都有明确的模型、推理强度、输入和交付物。

本文不要求你复制某个现成网站或团队。你只需要把岗位替换成自己的业务：内容号、知识库、个人作品集、工具站或小型产品都适用。

先定团队：每个岗位只解决一种问题

下面是一套适合“内容运营 + 网站维护”的七岗位示例。前五个是核心岗位；视觉体验设计师和工具采编员按需启动，不需要每天运行。

这张表最重要的不是模型名称，而是边界：运营负责人决定做什么；研究员和编辑把内容做深；开发工程师实现已批准的改动；审核员判断是否达到交付标准。

一个真实工作日怎样流转

假设你经营一个 AI 工具教程网站，同时在做公众号和短视频分发。某天早上，运营负责人发现：网站最近三天没有新教程；本地有一篇“多智能体团队配置”草稿，但用户反馈说内容太空；同时某个热门 AI 工具发布了更新。

不要让七个岗位同时开工。按下面顺序做，通常只会启动 2～3 个岗位：

1. 运营负责人先检查网站首页、内容更新时间、本地草稿和上一轮反馈，决定今天只做一件主事：把现有草稿改成一篇能直接照着配置的教程。
2. 选题研究员补齐读者真正需要的资料：模型名称、推理强度、岗位职责和官方配置依据。它交付来源和事实清单，不直接写整篇文章。
3. 内容编辑拿到任务卡后重写正文：先写具体岗位表，再写配置文件和一天的协作顺序。读者读完应能知道“下一步打开哪个文件、复制什么、怎样验证”。
4. 如果文章需要配套修改网站页面，才创建一个范围明确的开发任务；网站开发工程师只改被批准的文件。
5. 网站质量审核员在独立上下文里对照任务卡检查：角色是否齐全、模型与推理强度是否写清、代码或文章是否真的解决了读者问题。

这样一天的结果不是“七个 Agent 都输出了一份报告”，而是一篇更具体的文章，或一个经过验证的小改动。

给每个岗位一张任务卡

很多多智能体团队失败，是因为主任务只说“写一篇好文章”或“把网站优化一下”。每次派任务都应至少给出这六项：

目标：本次要解决什么问题？
读者或用户：谁会受益？
输入：需要读取哪些资料、草稿或页面？
输出：要交付文章、任务卡、代码还是审核报告？
完成标准：怎样算完成？
不做什么：本次明确不碰哪些内容、代码或发布动作？

例如交给内容编辑的任务卡可以这样写：

目标：把“多智能体配置”草稿改成自媒体运营与网站开发团队案例。
读者：独立内容创作者、个人站长和小团队负责人。
输入：现有草稿、选题研究员提供的模型配置清单、官方 Codex 配置文档。
输出：一篇中文教程，包含岗位表、模型、推理强度、协作顺序和可复制 TOML。
完成标准：读者能分清运营负责人、研究员、内容编辑、开发和审核各自负责什么。
不做什么：不展示任何真实项目名称、账号、密钥、内部数据或生产记录。

第一步：设置项目的主任务模型

在项目根目录创建 .codex/config.toml。这份文件只决定当前项目的默认主任务模型和推理强度，不放 API Key。

# .codex/config.toml
model = "gpt-5.6-terra"
model_reasoning_effort = "high"

[agents]
max_concurrent_threads_per_session = 3

这里把并发限制为 3，是因为自媒体小团队通常不需要同时启动所有岗位。运营负责人正在判断方向时，研究员和编辑最多并行；开发和审核等到任务明确后再启动。并发过多不会让内容更好，只会让你同时处理更多半成品。

第二步：先把外部模型 Provider 配好

DeepSeek V4 Flash 和 GLM-5.2 不是只写进岗位 TOML 就能使用。它们需要先在用户级 Codex 配置中声明 Provider；项目里的 .codex/config.toml 只放主任务模型、推理强度和并发数。

Codex 自定义 Provider 使用 responses 协议，配置规则见 Codex 配置参考。外部服务商的套餐、模型 ID 和端点会变化，下面是配置形态，不是对所有账户的兼容性承诺：Base URL 必须从你自己的控制台或服务商当前文档中取得，并确认它支持 Codex 所需的 Responses 协议。

# ~/.codex/config.toml

[model_providers.deepseek]
name = "DeepSeek"
base_url = "<从当前控制台复制的 Responses 地址>"
env_key = "DEEPSEEK_API_KEY"
wire_api = "responses"

[model_providers.volcengine_plan]
name = "Volcengine Coding Plan"
base_url = "<从当前控制台复制的 Responses 地址>"
env_key = "VOLCENGINE_API_KEY"
wire_api = "responses"

env_key 只写环境变量名称，真实 Key 留在你的系统环境变量或密码管理工具中，不要写进项目文件、截图或提示词。DeepSeek 和火山引擎的模型名、套餐与端点分别以 DeepSeek 官方文档 和 火山引擎控制台/产品页 为准。

如果服务商只说明支持 Chat Completions，或者没有明确说明 Responses 兼容，就不要把它直接放进这套 Codex 配置。先保留内置模型岗位，等拿到确认的地址后再启用外部岗位。

先做一次只读验证，再让它接正式工作

重启 Codex 后，先让每个外部岗位执行一个小而只读的任务。例如：让选题研究员只读取项目 README，列出三个读者问题和对应来源；让内容编辑只根据一段给定材料改写摘要。只有任务详情中显示该岗位正常完成、没有 Provider 或协议错误，才把它标记为可用。

这张表不能靠 TOML 解析成功来填写“通过”。如果出现 400、401、422 或模型不存在，先停止派正式任务，检查模型 ID、账户额度、Base URL 与协议是否匹配，再重试最小只读任务。

第三步：配置五个核心岗位

以下文件名是 Codex 的技术标识，方便命令行和跨平台调用；岗位名称、职责和提示词全部使用中文。把文件放在项目的 .codex/agents/ 目录中。

1. 运营负责人：定方向，不代写所有内容

.codex/agents/ceo-product-manager.toml

name = "ceo-product-manager"
description = "运营负责人：负责内容方向、用户问题、优先级和任务编排。"
model = "gpt-5.6-terra"
model_reasoning_effort = "high"

developer_instructions = """
你是自媒体运营与网站开发团队的运营负责人。
每天先检查已发布内容、本地草稿、用户反馈和正在进行的任务。
今天最多确定 3 个优先事项；没有明确价值时可以不派新任务。
你负责目标用户、选题优先级、分发方式和成功标准，不负责替研究员写资料、替编辑写全文或替开发工程师改代码。
每次派发任务必须写清目标、输入、输出、完成标准和不做范围。
"""

2. 选题研究员：找到可用资料，不替运营负责人拍板

.codex/agents/topic-researcher.toml

name = "topic-researcher"
description = "选题研究员：核对公开资料、用户问题和竞品变化，输出可追溯的选题研究卡。"
model = "deepseek-v4-flash"
model_provider = "deepseek"
model_reasoning_effort = "xhigh"

developer_instructions = """
你只完成被分配的研究问题。
输出必须区分官方事实、用户反馈、你的推断和未知项，并附上来源链接。
不要直接发布文章，不修改网站代码，不决定内容方向，也不读取任何密钥。
"""

3. 内容编辑：把事实和案例写成读者能照做的内容

.codex/agents/content-editor.toml

name = "content-editor"
description = "内容编辑：把通过的选题研究卡写成教程、长文、视频脚本和社交媒体拆稿。"
model = "glm-5.2"
model_provider = "volcengine_plan"
model_reasoning_effort = "xhigh"

developer_instructions = """
你根据任务卡和来源材料写作。
开头先说明读者是谁、什么时候用、完成后能做什么；正文给出步骤、示例和常见失败。
不要把未经确认的猜测写成事实，不要自行批准或发布自己的最终稿。
"""

4. 网站开发工程师：只做已批准的小范围实现

.codex/agents/website-developer.toml

name = "website-developer"
description = "网站开发工程师：只实现已批准、范围明确且可测试的网站改动。"
model = "glm-5.2"
model_provider = "volcengine_plan"
model_reasoning_effort = "xhigh"

developer_instructions = """
先读取项目规则、正式任务书和相关代码，只修改任务明确允许的文件。
完成后给出实际改动、测试结果、风险和仍需审核的事项。
不得自行改变产品方向、权限、价格、数据库、部署或发布状态。
"""

5. 网站质量审核员：只验收，不代替开发

.codex/agents/website-quality-reviewer.toml

name = "website-quality-reviewer"
description = "网站质量审核员：在独立上下文中检查任务目标、真实改动和验证证据。"
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

developer_instructions = """
先读取原任务和验收标准，再看真实 diff 与测试结果。
结论只能是通过、返工或阻塞，并列出可复现的问题。
不修改代码，不审核自己的实现，不提交、不发布、不部署。
"""

两个按需岗位：有明确问题再启动

.codex/agents/visual-experience-designer.toml

name = "visual-experience-designer"
description = "视觉体验设计师：负责品牌视觉、页面信息层级、交互、动效和移动端设计规格。"
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

developer_instructions = """
只在运营负责人已经定义业务问题、目标用户和成功标准后进行设计审查。
输出桌面端与移动端方案、组件状态、动效和可实施规格；不决定产品优先级，不修改代码。
"""

.codex/agents/skill-curator.toml

name = "skill-curator"
description = "工具采编员：核对公开工具、插件或技能的来源、适用场景、许可证和风险。"
model = "deepseek-v4-flash"
model_provider = "deepseek"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"

developer_instructions = """
只处理任务指定的工具或技能目录，输出来源、适用场景、许可证和风险说明。
不克隆、不安装、不执行第三方代码；不决定内容方向，不修改网站代码或生产数据。
"""

如果你还没有配置外部模型 Provider，先只启用运营负责人和质量审核员，其他岗位可以暂时使用你账户中可用的模型。Provider 的 Base URL、模型 ID 和环境变量名称以你自己的服务商控制台与当前官方文档为准；不要把教程中的示例当成账户保证。

第四步：按内容与开发两条链路协作

内容链路

运营负责人确定选题
→ 选题研究员给出来源和读者问题
→ 内容编辑完成文章与分发稿
→ 运营负责人检查是否符合任务卡
→ 再进入网站现有的发布流程

内容编辑的任务不是“每天写一篇”，而是把一个明确问题写透。例如“产品经理如何用 Codex 完成网页原型”可以拆成：选题文章、完整教程、常见错误、60 秒视频脚本和一条社交媒体摘要。它们服务同一个用户问题，而不是五篇互不相干的内容。

网站改动链路

运营负责人定义业务问题与成功标准
→ 视觉体验设计师给出页面和交互方案（需要时）
→ 网站开发工程师实现
→ 网站质量审核员独立验收
→ 你决定是否发布

例如“读者看完教程后没有继续阅读”不是开发任务。运营负责人要先把它写成可验证的问题：希望提升下一篇教程点击率；视觉体验设计师再决定推荐区怎么呈现；开发工程师最后才实现。这样不会把“感觉网站普通”直接变成一轮无边界改版。

第五步：何时值得增加按需岗位

当内容量和网站迭代增加后，再增加这两个岗位：

它们不需要每日定时运行。没有已证实的问题，就不启动；这比“每个 Agent 每天打卡”更省钱，也更容易看出每次投入是否有效。

常见问题

所有岗位都用最强模型，会不会质量更高？

不一定。模型更强只能提高某些任务的上限，不能替代清楚的任务卡和验收标准。研究员没有来源要求时，再强的模型也可能整理出一份漂亮但不可靠的资料；开发任务没有范围时，再强的模型也可能改出一大片无关代码。

为什么内容编辑和网站开发都用 GLM-5.2 的极高推理？

这两个岗位都需要把长上下文变成可交付结果，并要多轮检查细节。内容编辑需要处理结构、案例和读者理解；开发工程师需要处理代码、测试和回归。把它们设为 xhigh 的前提是：每次只给一个明确任务，避免把额度消耗在泛泛讨论上。

为什么审核员不用便宜模型？

审核通常不是高频任务，却会决定一篇关键内容或一次网站改动能否进入下一步。这里保留 Terra high，是为了让审核员有能力识别范围漂移、遗漏测试和读者理解断点。它只在完成后按需启动，不会像日常运营一样持续消耗额度。

如何判断该不该增加新岗位？

先连续两周记录：哪类任务经常返工、哪个岗位总是被同一件事卡住、哪些工作确实重复出现。只有当一个职责重复、输入输出稳定、现有岗位无法承担时，才新增岗位。否则先改任务卡或合并流程。

直接交给 Codex 的搭建提示词

请在当前项目中为我搭建一支“自媒体运营与网站开发”多智能体团队。

先读取项目规则、现有 .codex 配置和当前代码；先给方案，不要立即修改文件。

团队至少包含：
1. 运营负责人：GPT-5.6 Terra，推理强度 high，负责用户、选题、优先级、任务卡和复盘。
2. 选题研究员：DeepSeek V4 Flash，推理强度 xhigh，负责公开资料、竞品和用户问题研究。
3. 内容编辑：GLM-5.2，推理强度 xhigh，负责教程、长文、视频脚本和社交媒体拆稿。
4. 网站开发工程师：GLM-5.2，推理强度 xhigh，只实现已批准的代码任务。
5. 网站质量审核员：GPT-5.6 Terra，推理强度 high，在独立上下文中验收，不修改代码。

按需岗位：视觉体验设计师使用 GPT-5.6 Terra / high；工具采编员使用 DeepSeek V4 Flash / xhigh。

请为每个岗位写清：职责、输入、输出、不得做什么、模型、推理强度和启动条件。
日常只让运营负责人固定运行；其他岗位必须由明确任务卡触发，不要全部每天运行。
外部模型岗位开始正式工作前，先在用户级配置中声明对应 Provider，并让每个岗位完成一次只读验证；TOML 能解析不等于 Provider 已可用。
不要读取或输出任何密钥，不要修改生产数据、支付、权限、定时任务、网站代码或部署配置，除非我对具体任务再次确认。

下一步

先让运营负责人完成一次“今天应该做什么”的小型排期，然后只启动一个研究或编辑任务。跑完一周后，查看三件事：内容是否更具体、返工是否减少、模型额度是否能承受。团队是否有效，不取决于岗位数量，而取决于每个岗位能否交出清楚、可验证的结果。

参考

• OpenAI Codex 配置参考，访问与核验：2026-08-03。
• OpenAI Codex 多智能体文档，访问与核验：2026-08-03。
• DeepSeek 快速开始与定价，访问与核验：2026-08-03。
• 火山引擎 Coding Plan 产品入口，访问与核验：2026-08-03。

本文中的模型名称和推理强度是一个自媒体运营与网站开发团队的配置示例。你的账户、套餐、Provider 和客户端版本可能不同；请以自己的 Codex 可选模型和服务商控制台为准。