2026 Codex 已不只是写代码：真正稳定的工作流不是背 Work、Ultra、Sites 按钮，而是按交付物、验收和权限路由能力
AH-0356 是一篇非常典型的“产品刚更新就立刻写完整教程”的文章。 它看到 Codex 左侧出现： Work； Chat； 插件目录里出现： Sites； Template Creator； Visualize； 推理/多 Agent 场景又出现： Ultra。 然后试图把这些能力组织成一个完整的工作台： Work 做研究和文档； Codex 做代码； Plugins 封装专业能力； Brow
2026 Codex 已不只是写代码：真正稳定的工作流不是背 Work、Ultra、Sites 按钮，而是按交付物、验收和权限路由能力
AH-0356 是一篇非常典型的“产品刚更新就立刻写完整教程”的文章。
它看到 Codex 左侧出现：
Work； Chat；
插件目录里出现：
Sites； Template Creator； Visualize；
推理/多 Agent 场景又出现：
Ultra。
然后试图把这些能力组织成一个完整的工作台：
Work 做研究和文档； Codex 做代码； Plugins 封装专业能力； Browser 查资料和测试； 多 Agent 并行； Chat 负责讨论再加入任务。
这个方向总体上是对的。
截至 2026 年，OpenAI 官方确实已经把 Codex 从最初的软件开发 Agent， 不断扩展到：
研究； 文档； 表格； 演示； 插件； 浏览器； Sites； 多角色工作流。
但 AH-0356 自己其实已经意识到了最大风险：
> UI、功能名称、账号权限会灰度； > 不要把模型名或模式名写进长期 SOP。
这句话应该成为整篇文章真正的核心。
所以 Batch 36 不做：
“Codex 2026 新按钮大全”。
而重构成：
> Codex Capability Routing Contract
---
一、先分 Stable Capability 和 Product Surface
Stable Capability
较稳定的任务能力。例如：
Research； File generation； Code editing； Testing； Browser use； External apps； Workflow plugins； Site/app creation； Parallel task execution。
Product Surface
这些能力今天在哪里出现、叫什么。例如：
Work； Codex； Sites； Plugins； 某个按钮； 某个模式名。
Product Surface 会变化。
Capability 相对更耐久。
所以：
> Codex Capability ≠ UI Label
---
二、为什么这对长期教程特别重要？
假设你把 SOP 写成：
“第一步点左侧 Work。”
三个月以后 UI 改名。
你的整篇教程就开始过期。
但如果写成：
> “当最终成果是研究报告、表格或演示时，选择面向资料与成果交付的工作面；当最终成果是经过测试的代码改动时，选择代码任务工作面。”
即使按钮改了，
方法仍成立。
---
三、OpenAI 当前官方已经确认：Codex 正在扩展到非开发工作
OpenAI 2026 年 6 月公开说明：
Codex 已经越来越被：
analysts； marketers； operators； designers； researchers； investors； bankers
使用。
并推出：
role-specific plugins； Sites； annotations
等工作能力。
所以“Codex不只是代码”已经不是作者个人观察。
它是当前产品方向。
---
四、Work 和 Codex 怎么选？不要问“谁更强”
源文给了一个很好用的判断：
最终想拿到：
报告、文档、表格、PPT
和：
代码修改 + 测试
是不同验收对象。
这个思想保留并升级。
Deliverable Contract
如果最终要：
Research Brief； Spreadsheet； Presentation； Document； Synthesis；
验收：
准确； 完整； 结构； 文件质量。
如果最终要：
Code Patch； Feature； Bug Fix； Refactor；
验收：
Tests； Runtime； Diff； Security； Acceptance Criteria。
所以：
> Work vs Codex by Deliverable + Acceptance
---
五、“先研究再开发”是 alphahole 最该保留的组合
一个真实产品项目可能是：
Research → Requirements → Architecture → Build → Test。
前半段需要：
市场； 用户； 来源； 竞品； 规格。
后半段需要：
代码； Repo； Shell； Tests。
因此正确协作不是：
Work 和 Codex 二选一。
而是：
> Research Output Becomes Build Contract
这与 alphahole 既有 research-first 工作流完全一致。
---
六、Plugin 到底是什么？
OpenAI 当前官方 Help Center 对 Plugin 的定义已经比较清楚：
Plugin 是：
> 面向一个工作流打包的 capability。
它可以包含：
Skills； Apps； App templates。
其中：
Skill 提供可复用指令/流程； App 连接外部数据与操作； App template 帮管理员配置所需 App。
所以：
> Plugin ≠ 一个简单工具按钮。
它更像：
Workflow Package。
---
七、Plugin 能出现，不代表你一定能用
官方当前也强调：
插件是否可安装/调用取决于：
Plan； Workspace Settings； Role； Supported Surface； Region； Underlying App Capability。
所以任何教程都要写：
> Visible ≠ Enabled ≠ Authorized
---
八、Plugin 也不会自动获得更多数据权限
一个 Plugin 里包含某个 App，
不代表它绕过：
workspace permission； source-system access； user authentication。
所以：
> Plugin Capability ≠ Permission Escalation
这与 Agent Governance 的 least privilege 完全一致。
---
九、源文提到 Template Creator，应该怎么写才耐久？
如果当前目录确实出现某个模板创建类插件， 它的具体名称可以记录成：
Current Surface。
但长期方法应该是：
> Reference Artifact → Extract Structure → Create Reusable Template/Skill → Test on New Input → Compare Output
不要把价值绑定在：
“Template Creator 永远叫这个名字”。
---
十、Visualize 也是同理
用户真正需要的是：
数据 → 选择合适可视化 → 生成 → 验证标签/比例/来源 → 输出。
插件只是当前实现。
所以产品方法应叫：
Visualization Workflow。
不是：
“Visualize 插件教程”。
---
十一、Sites 是值得注意的新 Product Surface
OpenAI 2026 年 6 月官方公开推出 Sites 预览：
允许团队用 Codex 创建互动网站/应用， 并通过 URL 与 workspace 分享。
这说明：
Codex 的 deliverable 已经从：
文件/代码
扩展到：
interactive artifact。
---
十二、但 Sites ≠ 所有生产网站的默认部署方式
当前 Sites 仍然有：
public beta / rollout / plan / workspace
等可用性条件。
而且当前产品能力本身也有边界。
所以不能写：
“以后做网站不用部署了，全部用Sites。”
正式选择仍然问：
是内部交互演示？ 团队分享？ 公开产品？ 需要自定义域名？ 实时数据库？ 支付？ 生产 SLA？
---
十三、Sites 的实时数据能力也要按当前文档写
当前 OpenAI Sites Academy 对实时数据存在明确产品边界：
Site 本身不是任意外部实时数据库的万能前端。
如果要更新数据， 可以通过：
workflow/automation
等方式刷新。
所以：
> Interactive Site ≠ Full Production Backend
---
十四、Browser 的真正价值不是“能上网”
Agent Browser 真正改变的是：
过去只能：
读 HTML / API。
现在可以：
打开页面； 点击； 测试； 观察 UI； 下载； 完成需要浏览器的步骤。
这对：
Research； QA； Website Testing； Admin Workflow
很有价值。
---
十五、Browser 最大风险也是权限
如果浏览器已经登录：
邮箱； 后台； 支付； 云平台； 社交账户；
Agent 看到的是：
真实授权环境。
所以：
> Browser Session Access ≠ Credential Export Permission
它可以在你授权范围内执行任务。
不代表：
应该把 Cookie、密码、密钥导出来给模型。
---
十六、高后果 Browser Action 默认 Human Gate
例如：
购买服务器； 删除资源； 发布； 付款； 发送邮件； 修改生产配置。
即使技术上可以自动，
也应该按：
Reversibility / Financial Consequence / External Communication
分级。
---
十七、多 Agent 并行什么时候真的有用？
适合：
四个独立竞品； 四个独立文档； 不同模块研究； 互不修改同一文件。
不适合：
4个 Agent 同时改一个核心文件。
否则：
冲突； 重复； 上下文覆盖； 合并成本
会抵消并行收益。
所以：
> Multi-agent Parallelism Requires Work Isolation
---
十八、并行前先做 Dependency Graph
把任务分：
A：独立； B：依赖A； C：独立； D：依赖B。
只能并行：
A + C。
如果你让：
A/B/C/D
全部一起跑，
“并行”只是制造返工。
---
十九、Worktree / 文件所有权比 Agent 数量更重要
代码场景里：
每个 Agent 应有：
branch / worktree / file scope / acceptance。
最后统一：
merge； test； review。
所以成熟多Agent不是：
“开4个就快4倍”。
而是：
> Parallelism = Isolation + Merge Discipline
---
二十、Ultra 这种模式名应该怎样进入长期 SOP？
只作为：
Current UI Observation。
记录：
Name / Surface / Plan / Date / What It Appears to Do。
如果官方没有足够稳定的一手说明，
不要写：
“Ultra永远最多4个Agent” “Ultra一定是某模型”。
这就是：
> Product Surface Drift Gate
---
二十一、Chat → Add to Task 的价值是什么？
不是这个按钮名字。
而是：
> Discussion → Executable Specification
人在 Chat 里：
脑暴； 比较； 澄清。
形成明确规格以后， 再把它交给执行任务。
这个“从想法到执行合同”的流程很稳定。
按钮名字可以变。
---
二十二、最重要的 Prompt 改进不是“写得长”
AH-0356 给 Work 的示例 Prompt 做对了一个关键点：
不只说：
“研究一下。”
还写：
资料范围； 分析维度； 交付格式； 验收标准。
这就是：
> Task Contract
---
二十三、一个通用 Task Contract
Goal
最终要解决什么？Inputs
允许使用哪些来源？Constraints
不能做什么？Deliverable
要什么文件/代码？Acceptance
怎么判断成功？Verification
要不要测试/渲染/浏览器检查？Human Gate
哪些动作必须确认？这比“高级提示词”更耐用。
---
二十四、插件也应该过 Skill Trust Gate
任何安装插件都问：
Trigger / Permissions / Data / External Action / License/Terms / Update / Eval / Failure / Exit。
不能因为“官方目录里有”就：
全装。
B26 的 Stack Complexity Budget 继续有效。
---
二十五、Template Workflow 也需要回归测试
如果从一份好 PPT 生成模板，
下一份实际报告要测试：
标题长度变化； 表格变多； 图片比例不同； 中文/英文； 极端页数。
否则：
“看起来像原文件”
不代表模板稳定。
---
二十六、文件交付必须包含渲染 QA
源文要求：
Word 生成以后检查：
表格溢出； 孤行； 标题断页。
这正是非常好的 Acceptance Pattern。
所有 Artifact workflow 都要有：
Generate → Render → Inspect → Fix → Re-render。
---
二十七、真正稳定的 Codex Capability Map
Research
Search / Read / Synthesize。Artifact
Docs / Sheets / Slides / Reports。Code
Edit / Shell / Test / Git。Browser
Web research / UI validation / computer use。Apps
External data/actions。Plugins
Reusable role/workflow packages。Sites
Interactive deliverables。Parallel
Independent tasks。这些能力比：
左边第几个按钮
更值得写进 alphahole。
---
二十八、Capability Drift Contract
每个产品功能保存：
Feature / Surface / Account / Plan / Region / Rollout / Permission / Stable Principle / Last Verified。
这直接继承既有：
Capability Drift。
---
二十九、为什么这个体系比“2026新功能大全”更值钱？
功能大全：
发布那天最值钱。
三个月后不断贬值。
Capability Router：
只需要更新 surface mapping。
例如：
某个“Work”以后改名，
Router 的：
Deliverable / Acceptance
不变。
---
三十、产品方向
进入：
> AI Work OS / Codex Workspace Router
Free
Deliverable Router。Low-price
Task Contract / Permission Checklist。Membership
Current Product Surface Map。High-ticket
团队 AI workflow governance。---
三十一、V3
找30个真实任务：
研究； 报告； 表格； PPT； 网站； Bug； 新功能； 浏览器测试。
分别让用户：
A：按界面名字猜。
B：用 Capability Routing Contract。
比较：
wrong-surface rate； rework； time-to-accepted-output； permission incidents； tool proliferation。
---
三十二、Stop Rule
如果 Router 最后只是：
“报告用Work，代码用Codex”
那它不够产品化。
只有当它真正减少：
错误入口； 权限问题； 返工； 功能漂移带来的教程过期
才继续。
---
最后
2026 年 Codex 真正发生的变化不是：
“又多了几个按钮。”
而是：
> 越来越多种工作，开始进入同一个 Agent 工作台。
这时候最差的学习方式，
就是记住每个按钮。
最好的方式是记住：
我要交付什么？怎么验收？需要什么权限？哪些动作必须由人负责？
按钮会变。
这四个问题不会。