管理员发布一个新版本
管理员在看板选择预设版本并点击发布。GitHub 上本轮使用的 Plugin 目录和文件随之更新；没有点击，就保持原样。
两件事都能做到
能提醒更新，也能看到用户做到了哪一步。
前提是把链路补齐
短文助手负责检查和询问，公开目录负责提供版本，自己的服务负责保存进度。用户同意后，正文也可以一起上传。
当前 Demo 的两项核心能力，纯 Skill 和 Plugin 都能完成。
本轮为了尽快把旧版安装、版本发布、更新确认和结果核对放进同一场演示，我们先用了 Plugin。它现成提供版本清单和安装缓存，少做了一套版本规则。这是本轮的实现选择，不是能力成立的条件。
先把 Marketplace 说清楚
Plugin 安装目录（Codex 称为 Marketplace）是一份 JSON 清单，告诉 Codex 有哪些 Plugin、版本是多少、安装文件在哪里。 它不是 GitHub Marketplace，不是 Cloudflare，也不是 DHub 或 Docker Hub，更不是自动升级服务。
纯 Skill 能否完成当前 Demo
能。纯 Skill 配合自己的版本文件、安装器和更新器，也可以查版本、询问用户、替换文件、核对结果并发送进度。区别只是版本规则由项目自己维护。
本轮为什么先用 Plugin
Plugin 已有明确版本字段、固定缓存和 Plugin 目录安装入口，适合快速做出一条可核对的演示链路。它省的是搭建时间，不是补上纯 Skill 缺失的联网或打点能力。
| 同一个业务需求 | 纯 Skill | 本轮 Plugin 路径 |
|---|---|---|
| 公开安装 | 从 GitHub 写入标准 Skill 目录；安装入口由项目提供。 | 先加入 Plugin 目录，再安装清单中的 Plugin。 |
| 版本发布与回退 | 读取项目自己的版本文件和发布包。 | 读取 Plugin 清单和对应版本缓存。 |
| 发现新版并询问 | 使用 Skill 时，由自带脚本查询并询问。 | 本轮同样由 Skill 脚本查询并询问。 |
| 记录步骤与内容 | 需要自己的云端服务和用户同意。 | 同样需要自己的云端服务和用户同意。 |
从发布新版，到看见用户完成任务
更新提醒和进度记录不是两套孤立功能。它们发生在同一次真实使用里。
服务端重新核对公开版本
服务端会从 GitHub 再读一次。两边版本一致才算成功；失败就保留旧版，并记下失败原因。
用户下次使用短文助手
短文助手主动检查版本。这不是服务端主动推送。发现新版后询问“要不要更新”；普通更新一天只检查一次，避免反复打扰。
用户更新或跳过，然后继续写作
跳过就继续用旧版；确认更新后，先核对是否真的装好，再继续选择润色方向、标题方向，最后生成终稿。本轮由 Plugin 安装命令完成替换；纯 Skill 路径会改用项目自己的更新器。
看板还原整段过程
同一安装环境下，安装记录、写作任务和更新结果会放在一起。用户同意后，原文、选择和终稿也会显示；拒绝后只保留步骤。
我们究竟验证了什么
资料部分来自用户提供的 2026 年 7 月 21 日资料快照。实测部分只写我们亲自跑过、并留下证据的结果。这样可以避免把“一次成功”说成“平台保证”。
| 问题 | 实测答案 | 结论 |
|---|---|---|
| 纯 Skill 能联网吗？ | 能。带上脚本且环境允许联网时，可以查询版本和上报数据。
查看经过筛选的过程Codex
运行 Skill 自带脚本，先向服务端查询当前公开版本。 工具结果
版本查询成功；随后五条步骤事件全部送达，服务端按顺序保存。 这份证据的边界：证明纯 Skill 的脚本可以联网查询和上报；不证明 OpenAI 为纯 Skill 提供原生版本管理或自动升级。 |
能，版本规则需自建 |
| 发布后会主动弹窗吗？ | 不会。用户再次使用短文助手时，客户端主动检查，才会发现新版。 | 使用时检查 |
| 公开目录变了，用户就升级了吗？ | 不一定。还要核对安装记录、本地文件，以及新任务真正加载的版本。 | 要核对结果 |
| 装成 Plugin 就会自动有数据吗？ | 不会。安装、操作步骤、成功或失败，都要由产品明确发送。 | 需要自己的服务 |
| Windows 能直接安装纯 Skill 吗？ | 能看到成功案例。本轮提供的 Dashi PPT 会话中，Codex 自带的 Python 安装器把 Skill 从 GitHub 直接写入 Skill 目录，没有调用 Plugin 命令。
查看经过筛选的过程用户
要求在 Windows 环境安装公开的 Dashi PPT Skill。 Codex
选择 Codex 自带的 Python Skill 安装器，从 GitHub 下载并写入用户的 Skill 目录。 工具结果
安装器返回成功，目标目录已经生成；整个过程没有调用 Plugin 命令。 查看工具调用python [CODEX_HOME]/skills/.system/skill-installer/scripts/install-skill-from-github.py --repo chuspeeism/dashi-ppt-skill --path skills/dashi-ppt这份证据的边界：证明一次 Windows 纯 Skill 首装；不等于短文助手已经在 Windows 完成安装、升级和数据回传的全流程。 |
安装已观察到 |
| 用户写的内容能上传吗？ | 能。安装时询问一次；同意后上传原文和终稿，拒绝后只记录步骤。 | 已验证同意与拒绝 |
| 完整 Demo 是否端到端跑通？ | 跑通。旧版、发布、更新选择、三轮写作、内容授权、看板记录、失败保护和最终重置都经过同一套验收。 | 完整链路通过 |
| 能跨设备认出同一个人吗？ | 这次没有验证。匿名用户只代表同一安装环境，不等于真实自然人。 | 未覆盖 |
我们曾经看到 Codex 在新任务启动时自动刷新目录并加载较新版本，但不能保证每次启动都自动升级。
官方机制
Plugin 目录可以刷新；安装后的 Plugin 会按目录、名称和版本进入本地缓存。目录更新和已安装版本升级是两件事。
本轮观察
Codex 曾在一个新任务启动时刷新 GitHub 上的 Plugin 目录，并加载较新版本。这证明路径可能发生，不代表每次都会发生。
未被承诺
官方没有承诺每次启动或每次调用 Skill 都会自动升级，也不会替产品留下“成功、失败或跳过”的记录。
如果进入 OpenAI 官方 Plugin 目录，版本发布、发现和安装路径会更统一，也更有机会由平台在启动或新任务阶段刷新；相对纯 Skill，项目少维护一套目录和缓存规则。但这不等于自动升级得到保证。因此，Demo 仍固定旧版，再让产品主动检查、询问、安装、核对和记录。
Windows 有安装证据，完整流程仍待验证
Windows 上已经观察到 Dashi PPT 以纯 Skill 方式安装成功；短文助手的完整 Demo 仍只在 Ubuntu 跑通。 这说明“Windows 必须通过 Plugin 安装”的判断不成立，但还不能替代短文助手从安装、升级到数据回传的整套验收。
macOS 本轮也没有完成同等深度的验证。因此，报告不对 Windows 或 macOS 下“能不能使用”作绝对判断。TELE 开头的记录能力可以帮助后续观察安装和升级结果，但它本身不代表跨平台验证已经完成。
查看资料侧主要来源
OpenAI：Build skills · OpenAI：Plugins · OpenAI：Build plugins · OpenAI：CLI plugin commands · OpenAI：Windows App · Dashi PPT Skill。官方页面可能随平台更新；Dashi 是公开项目案例，不代表 OpenAI 的平台承诺。
谁负责什么
这套方案只有一条主线，但每一部分各管一段。名词看起来多，职责其实很清楚。
GitHub 仓库：公开版本来源
nexteamer/codex-short-essay-marketplace 是本轮仓库的真实名称，保存安装脚本、可发布版本和 Plugin 目录。名字里虽然有 marketplace，它仍只是一个 GitHub 仓库；不是 GitHub Marketplace、DHub 或 Docker Hub。
Plugin 目录：告诉 Codex 去哪里安装
它就是前面定义的 JSON 清单，写明有哪些 Plugin、版本是多少、文件在哪里。OpenAI 可以维护官方目录，团队也可以把自己的目录放在 GitHub。Plugin 目录只服务于本轮 Plugin 路径；纯 Skill 的安装和更新不需要它。
Skill：真正完成短文业务
Skill（技能）包含业务说明和可选脚本，负责询问润色方向、标题方向、展示终稿，也可以查询版本和发送记录。当前两项核心能力都发生在这里和自建服务之间。
Plugin：本轮采用的分发外壳
Plugin（插件）把 Skill、版本清单和安装信息打成一个产品包。本轮用它快速建立可核对的版本链路；它不负责自动打点，也不是纯 Skill 完成同一 Demo 的前提。
Cloudflare Worker：保存在线状态
它保存当前版本、匿名安装、操作进度、授权内容和升级结果，并把数据提供给运行看板。
GitHub Actions：真正执行发布
管理员点击发布后，这个自动流程才会更新公开仓库。没有点击发布，就不会换版本。
Cloudflare Pages：只托管这份报告
报告和公开证据一起放在 Pages 上。即使本机服务器关闭，网页仍能独立打开。Pages 不参与短文助手的更新和数据记录。
| 使用入口 | 官方支持的方式 | 本次判断 |
|---|---|---|
| 纯 Skill 安装 | Codex 自带 Skill 安装器可以从 GitHub 下载并写入用户的 Skill 目录。 | Dashi PPT 已在本轮 Windows 会话中安装成功；短文助手的覆盖升级仍需要自己的更新器。 |
| Plugin / Plugin 目录 | 独立 Codex CLI 可以用 codex plugin marketplace 和 codex plugin 管理目录与插件；命令中的 marketplace 指的就是这份目录。 | 本轮 Ubuntu 完整 Demo 采用这条路，便于核对清单版本和缓存。 |
| Windows App 原生模式 | 官方支持 Skill、Plugin 和 PowerShell 沙盒。 | 纯 Skill 首次安装已经观察到；短文助手从升级到回传的完整流程尚未验证。 |
| Windows App 的 WSL 模式 | 官方支持让 agent 在 WSL2 中运行。 | 本轮没有单独验证 WSL 与 Windows 原生环境在重启加载上的差异。 |
| macOS | 官方提供独立 CLI 安装方式。 | 本轮没有安排完整验证，后续可按同一套验收流程补测。 |
为什么安装仍然需要权限
两条路径都要访问 GitHub并写入用户的 Skill 目录，这些操作超出了当前项目目录。Plugin 路径还会写入 Plugin 目录配置与插件缓存，并通过 Codex CLI 管理安装。遥测则是另一项联网行为，只发送用户已同意的数据；是否打点不会决定它是 Skill 还是 Plugin。
最容易混淆的三件事
平台可能刷新插件目录；产品主动检查服务端版本；用户确认升级后，产品再安装并核对。它们不是同一件事，只有最后两步组成了这次可控的升级流程。
这份结论应该怎么用
这次没有证明
服务端可以在 Codex 关闭时主动弹出通知。
登录 Codex 就等于登录你的产品，或匿名 ID 能跨设备识别人。
任何电脑和企业网络都已经验证可用。本轮完整流程只在 Ubuntu 验证；Windows 和 macOS 因时间有限尚未完成同等验证，因此不作绝对结论。
按目标选择
只想复用一套方法：用 Skill 就够了。
希望直接证明 Skill 安装方便：用纯 Skill，加自己的版本文件和一键安装、更新脚本。
希望沿用 Codex 的 Plugin 管理方式：再使用 Plugin 和公开 Plugin 目录。Plugin 是一种可选的分发方式，不是当前两项能力的前提。
希望看到用户进度：再配一个轻量服务；要上传材料，就先取得同意。
希望跨设备连续服务：增加自己的登录体系。
完整验收的过程和底层材料已经放进上一节“完整 Demo 是否端到端跑通”的展开区，不必离开主线才能读懂。
需要时，再看这些细节
服务端最少记录什么
anonymous_user_id 代表一个安装环境，run_id 代表一次短文任务，step_id 代表走到哪一步，attempt_id 把一次升级的开始和结果连在一起。正文只在用户同意后发送。
为什么普通更新一天只检查一次
目的是减少打扰。用户跳过某个版本后，短时间内也不会反复询问。验收时可以强制检查，但日常默认不会这样做。
纯 Skill 的版本和更新从哪里来
Skill 标准没有统一版本字段，因此项目需要在 Skill 内保存自己的 version.json 或 package.json，并用更新器下载、校验和替换目标版本。Dashi PPT 展示了这种做法的可行性。它证明的是“项目可以自建更新”，不是 OpenAI 提供了 Skill 原生自动升级。
数据怎么清理
原始记录按 30 天窗口清理；完整重置会恢复 0.1.0，并清空安装和任务数据。网络或记录失败，不会阻塞短文润色本身。
Windows 和 macOS 后续要验证什么
按与 Ubuntu 相同的流程，分别验证安装、版本检查、确认升级、重启后加载和结果记录即可。TELE 记录可以辅助观察结果，但不能代替实际验证。