管理员发布一个新版本
管理员在看板选择预设版本并点击发布。GitHub 上的插件目录和文件随之更新；没有点击，就保持原样。
两件事都能做到
能提醒更新，也能看到用户做到了哪一步。
前提是把链路补齐
短文助手负责检查和询问，公开目录负责提供版本，自己的服务负责保存进度。用户同意后，正文也可以一起上传。
单独的 Skill 也能借助脚本联网。真正的差别不是“能不能”，而是“能不能长期管得住”。
所以我们最终用了 Plugin。它有明确的版本和安装来源，能把“发布了什么、用户装了什么、升级有没有成功”说清楚。Skill 继续负责业务步骤，Plugin 则把它变成一个可安装、可升级的产品。
纯 Skill 能做到哪一步
它可以写业务步骤，也可以带脚本去查版本、发进度。前提是已经装到正确位置，并且环境允许它运行脚本和联网。
为什么最后还是 Plugin
因为业务不只关心“这次能跑”，还要知道用户装了哪一版、从哪里更新、更新后是否真的生效。Plugin 用明确版本和安装目录把这些问题接起来。
从发布新版，到看见用户完成任务
更新提醒和进度记录不是两套孤立功能。它们发生在同一次真实使用里。
服务端重新核对公开版本
服务端会从 GitHub 再读一次。两边版本一致才算成功；失败就保留旧版，并记下失败原因。
用户下次使用短文助手
短文助手主动检查版本。这不是服务端主动推送。发现新版后询问“要不要更新”；普通更新一天只检查一次，避免反复打扰。
用户更新或跳过，然后继续写作
跳过就继续用旧版；确认更新后，先核对是否真的装好，再继续选择润色方向、标题方向，最后生成终稿。
看板还原整段过程
同一安装环境下，安装记录、写作任务和更新结果会放在一起。用户同意后，原文、选择和终稿也会显示；拒绝后只保留步骤。
我们究竟验证了什么
资料部分来自用户提供的 2026 年 7 月 21 日资料快照。实测部分只写我们亲自跑过、并留下证据的结果。这样可以避免把“一次成功”说成“平台保证”。
| 问题 | 实测答案 | 结论 |
|---|---|---|
| 纯 Skill 能联网吗？ | 能。带上脚本且环境允许联网时，可以查询版本和上报数据。查看早期证据 | 能，但难管理版本 |
| 发布后会主动弹窗吗？ | 不会。用户再次使用短文助手时，客户端主动检查，才会发现新版。 | 使用时检查 |
| 公开目录变了，用户就升级了吗？ | 不一定。还要核对安装记录、本地文件，以及新任务真正加载的版本。 | 要核对结果 |
| 装成 Plugin 就会自动有数据吗？ | 不会。安装、操作步骤、成功或失败，都要由产品明确发送。 | 需要自己的服务 |
| 用户写的内容能上传吗？ | 能。安装时询问一次；同意后上传原文和终稿，拒绝后只记录步骤。 | 已验证同意与拒绝 |
| 能跨设备认出同一个人吗？ | 这次没有验证。匿名用户只代表同一安装环境，不等于真实自然人。 | 未覆盖 |
我们曾经看到 Codex 在新任务启动时自动刷新目录并加载较新版本，但不能保证每次启动都自动升级。
这次观察说明什么
平台有时会刷新指向 GitHub 主分支的目录，甚至可能在询问用户前换版。
它不能说明什么
官方没有承诺每次调用 Skill 都会自动升级；平台刷新也不会替产品留下“成功、失败或跳过”的记录。
因此，Demo 不把这次偶发现象当作依赖。我们固定旧版，再让产品主动检查、询问、安装、核对和记录。这样更稳，也更有说服力。
Windows 和 macOS：留待下一轮验证
本轮时间主要用于跑通 Ubuntu 上的完整 Demo，Windows 和 macOS 还没有完成同等深度的端到端验证。 官方资料显示，Windows App 支持 Plugin、Skill、PowerShell 和 WSL，macOS 也提供独立 CLI 安装方式；从现有机制看，两端都有可继续验证的路径。
本轮在 Windows 自动安装入口上收集到了一些环境差异，但时间不足以继续定位并完成验证。因此，报告只把 Ubuntu 标为已验证，不对 Windows 或 macOS 下“能不能使用”作绝对判断。TELE 开头的记录能力可以帮助后续观察安装和升级结果，但它本身不代表跨平台验证已经完成。
查看资料侧主要来源
OpenAI：Plugins · OpenAI：Build plugins · OpenAI：CLI plugin commands · OpenAI：Windows App。这些是官方页面，内容可能随平台更新。
谁负责什么
这套方案只有一条主线，但每一部分各管一段。名词看起来多，职责其实很清楚。
GitHub 仓库：公开货架
nexteamer/codex-short-essay-marketplace 保存安装脚本、可发布版本和插件目录。这里的 Marketplace 只是 Codex 能读懂的一份目录，不是 DHub，也不是 Docker Hub。
Marketplace：告诉 Codex 去哪里拿
这份目录写明有哪些 Plugin、版本是多少、文件在哪里。OpenAI 有自己的精选目录；团队也可以用项目目录或个人目录。我们的目录放在公开 GitHub 上，属于自建目录，不是 OpenAI 官方精选目录。
Plugin 和 Skill：装进客户端并完成业务
Plugin（插件）是带版本号的产品包；Skill（技能）是里面的业务说明，负责引导用户选润色方向、选标题、看终稿。
Cloudflare Worker：保存在线状态
它保存当前版本、匿名安装、操作进度、授权内容和升级结果，并把数据提供给运行看板。
GitHub Actions：真正执行发布
管理员点击发布后，这个自动流程才会更新公开仓库。没有点击发布，就不会换版本。
Cloudflare Pages：只托管这份报告
报告和公开证据一起放在 Pages 上。即使本机服务器关闭，网页仍能独立打开。Pages 不参与短文助手的更新和数据记录。
| 使用入口 | 官方支持的方式 | 本次判断 |
|---|---|---|
| 独立 Codex CLI | 可以打开插件浏览器，也可以用 codex plugin marketplace 和 codex plugin 管理目录与插件。 | 最适合脚本化安装，但前提是当前 shell 能正常启动 CLI，并有权写用户配置。 |
| Windows App 原生模式 | 官方支持 Plugin、Skill 和 PowerShell 沙盒。 | 官方能力路径已经存在；本轮时间有限，尚未完成从安装到升级的完整验证。 |
| Windows App 的 WSL 模式 | 官方支持让 agent 在 WSL2 中运行。 | 同样需要单独验证 WSL 与 Windows 原生环境在安装、配置和重启加载上的实际表现。 |
| macOS | 官方提供独立 CLI 安装方式。 | 本轮没有安排完整验证，后续可按同一套验收流程补测。 |
为什么安装需要额外权限
不是因为“加了打点”就自动变危险，而是安装本身要做三件超出当前项目目录的事：访问 GitHub 获取目录和文件、写入 Codex 的用户配置与插件缓存、启动 Codex CLI 完成安装和核对。遥测还会额外联网发送用户已同意的数据，但它和安装权限是两条不同的线。
最容易混淆的三件事
平台可能刷新插件目录；产品主动检查服务端版本；用户确认升级后，产品再安装并核对。它们不是同一件事，只有最后两步组成了这次可控的升级流程。
这份结论应该怎么用
这次没有证明
服务端可以在 Codex 关闭时主动弹出通知。
登录 Codex 就等于登录你的产品，或匿名 ID 能跨设备识别人。
任何电脑和企业网络都已经验证可用。本轮完整流程只在 Ubuntu 验证；Windows 和 macOS 因时间有限尚未完成同等验证，因此不作绝对结论。
按目标选择
只想复用一套方法：用 Skill 就够了。
希望公开安装和升级：用带版本号的 Plugin，再配公开插件目录。
希望看到用户进度：再配一个轻量服务；要上传材料，就先取得同意。
希望跨设备连续服务：增加自己的登录体系。
需要时，再看这些细节
服务端最少记录什么
anonymous_user_id 代表一个安装环境，run_id 代表一次短文任务，step_id 代表走到哪一步，attempt_id 把一次升级的开始和结果连在一起。正文只在用户同意后发送。
为什么普通更新一天只检查一次
目的是减少打扰。用户跳过某个版本后，短时间内也不会反复询问。验收时可以强制检查，但日常默认不会这样做。
数据怎么清理
原始记录按 30 天窗口清理；完整重置会恢复 0.1.0，并清空安装和任务数据。网络或记录失败，不会阻塞短文润色本身。
Windows 和 macOS 后续要验证什么
按与 Ubuntu 相同的流程，分别验证安装、版本检查、确认升级、重启后加载和结果记录即可。TELE 记录可以辅助观察结果，但不能代替实际验证。