夜雨聆风Codex 的 sites 插件同时用了三种集成机制，复杂度远超其他六个
约 2284 字·阅读 6 分钟
打开 sites 插件的目录，我愣了一下——它同时带着 .codex-plugin/plugin.json、.mcp.json 和 .app.json 三个配置文件。
7 个插件里，只有它同时用了 Skill（工作流指令）+ MCP Server（本地工具）+ App Connector（云端服务）三种集成机制。其他插件最多用一种两种。
这暗示了一件事：sites 不是一个工具，是一个端到端的产品。从设计选择、代码生成、构建打包到部署上线，全流程塞在一个插件里。
· · ·
01
先判断走哪条路
sites-building/SKILL.md 一上来就给出了路径选择。满足全部条件——全新空工作区、单页面搞定、不需要数据库/认证/外部连接器/浏览器测试——走 One-shot 快速路径，少打断用户。其他情况都走 Capability 路径，多页面、要持久化、要登录、要外部数据，每步都到位。
简单站别折腾用户，复杂站别偷懒。一刀切要么过度打扰，要么能力不够。
· · ·
02
1-4 次设计选择器
这是 sites 最有意思的设计。建站前，AI 会用图片选择器让用户挑设计方向，最多 4 次。
每次选择，AI 并行派 3 个子 agent，各自生成一个独立的设计方案：
Spawn exactly three subagents in parallel to create three distinct options. Give them the same content, viewport, aspect ratio, and medium.
三个方案给同样的内容、同样的视口、同样的尺寸——保证差异只在设计变量上，方便用户对比。然后这三个 HTML 被渲染成 1600×1000 的 PNG 图片，通过 choose_site_design 工具让用户选。
为什么最多 4 次？SKILL.md 里白纸黑字写着：
Never exceed four pickers.
理论上可以让用户无限选下去追求完美设计，但实践中超过 4 次选择，用户决策疲劳，收益急剧下降。明确的数字上限防止 AI 失控——让 AI 做交互式决策时，给一个明确的次数上限，防止"无限优化循环"。
· · ·
03
MCP Server 不只是暴露工具
那个 choose_site_design 工具是怎么实现的？sites 自带了一个 MCP server，启动后通过 JSON-RPC 2.0 over stdio 暴露工具给 AI。
但这个 MCP server 有个不寻常的能力——它能反向请求客户端。mcp/server.mjs 里有 clientSupportsOpenAIForm 和 request() 函数，server 不只是被动响应 AI 的调用，还能向客户端发起请求，比如让客户端弹出富 UI 的选择器界面。
这是 sites 能做图片选择器的技术基础。纯文本对话里没法展示三张设计预览图让用户点选，但 MCP 的双向通信让宿主应用能弹出真正的图形界面。
App Connector 那边连的是 OpenAI 的云端 Sites 平台，提供 create_site、deploy_site_version、get_deployment_status 等 API。所以 sites 的完整能力栈是：skill 做工作流指挥，MCP server 在本地提供设计选择器工具，App connector 在云端做建站和部署。
· · ·
04
模板预留了所有扩展点
sites-building/templates/vinext-starter/ 是一个完整的 Next.js 项目模板，作为所有新站点的起点。
几个设计亮点值得说。第一是加载骨架屏——新项目一启动，用户立即看到一个"加载中"的骨架屏而不是空白页。AI 在背后通过 HMR 持续构建真正的站点，骨架屏一被替换就完成。先让用户看到反馈，再慢慢填实。
第二是模板里已经埋好了 ChatGPT 认证、Drizzle ORM 数据库 schema、Cloudflare D1 数据库示例、R2 对象存储绑定。要加登录、要存数据、要传文件，模板都预留了位置，AI 只管填业务逻辑。
最终的部署产物是 Cloudflare Worker 兼容的 ESM。这意味着 Sites 平台底层大概率跑在 Cloudflare 上。
让 AI 生成代码类产物时，给它一个开箱即用、预留扩展点的模板，比让 AI 从零写一个项目可靠得多——模板保证了架构合理性，AI 只管填业务。
· · ·
05
7 步部署流水线
sites-hosting/SKILL.md 给出了一条精确的部署流水线，我浓缩着讲。
源码没变就直接复用构建产物，不重复 build。新站调 create_site 拿到 project_id 和 source write credential，用 credential 作 HTTP auth header 把源码 push 上去——credential 不写进 Git 配置或 remote URL，防泄漏。然后把 dist 目录和元数据打成压缩包，用 branch-head SHA 作 commit_sha 存一个版本。部署时优先走私有部署，只有共享或公开部署时先问用户。最后轮询状态直到成功或失败。
几个原则贯穿整套流程：能复用的绝不重做，临时错误才重试而配额权限错误直接终止，敏感数据隔离不进 Git 配置，默认私有部署公开要用户同意。
💡 提示：写部署类工作流时，明确区分"可重试错误"和"终止性错误"，能节省大量无意义的重试时间。
· · ·
06
对非技术用户说人话
sites 的两个 skill 都有大段沟通规范，核心就一句话：
Assume the user is a nontechnical knowledge worker. Keep source control, credentials, IDs, commits, branches, archives, versions, packaging, connector calls, and deployment polling out of user-facing messages.
默认用户是不懂技术的知识工作者。不要把 Git、commit、打包、连接器、部署轮询这些术语丢给用户。要说"你的站点已经好了，我正在私下发布它"，而不是"正在执行 deploy_private_site_version，commit_sha 为 abc123"。
更新频率也有规定——每个用户可见阶段最多一条短更新，超过 60 秒才再补一条。AI 给非技术用户的反馈，要翻译成业务语言、控制更新频率、隐藏技术细节。这决定了产品是"给开发者用的"还是"给大众用的"。
· · ·
07
克制到细节
图片使用也很克制。SKILL.md 明确要求避免 AI 自己生成的 SVG 插画（质量不可控），不需要图时就别加图（用排版、颜色、CSS 形状代替），需要真图时优先网络图搜，最后才考虑用 imagegen 生成。
社交预览图的生成也有讲究——只生成一次，在剩余实现和验证的同时并行跑，失败只重试一次，再不行就省略 og:image，绝不放通用占位图。宁可没有，不要假的。
目录里还有个 TEMPEST.md，描述的是这个插件代码本身的风险治理规则——什么算低风险变更可以直接合并，什么必须人工 review。因为 sites 涉及部署、认证、用户数据，它的 prompt 和 manifest 改动需要严格审查。把 AI 系统当生产软件来治理，AI 的 prompt 就是产品逻辑，需要和代码一样受版本控制和审查。
· · ·
08
为什么这篇文章值得你转发
sites 插件是 7 个里最完整的产品级实现。它不是在解决一个技术问题，是在解决一个产品问题——怎么让不懂技术的用户通过对话就能建站上线。
从路径分流到并行设计选择器，从 MCP 反向调客户端到模板预留扩展点，从 7 步部署流水线到非技术用户沟通规范，每一步都有可借鉴的设计。任何做 AI 产品的人都该把它拆开来看一遍。
你的 AI 产品里，复杂能力的全流程是怎么串起来的？ 评论区聊聊。顺手转发给也在做 AI 产品的朋友。
· · ·
「拆解 Codex 7 大插件」系列 · 第 5 篇 · 共 9 篇下一篇：Codex 让 AI 在对话里画可视化，沙箱策略比我预期的狠。
感谢关注
