用户进入 BenszAPI 里，对应的API开启智能路由模式。然后，在Codex里输入更新 bensz skills即可更新。

Bensz Channel 已经陪 huangwb8/skills 走过好几轮迭代了：早些时候，我们聊过 v4.0.1～v4.0.4 的 awesome-code 重构与自动代码测试，随后是 v4.1.0～v4.1.1 的 BAC 贡献追踪与精准安装；6 月看着 auto-draw-plot 让技能库开始“会画图”，又经历了 v4.1.3～v4.2.0 的工作区搬家。7 月那篇继续整理更新、任务和图片交付的关系，最近一篇则在 8 月 9 日收到了 v4.3.5，重点是计划、协议错误、Windows 编码和 API 地址这些真实的小坑。把这些文章放在一起看，项目一直在把使用过程中遇到的问题沉淀成规则和工具；这次轮到更深一层的事情了：AI 做完一件事以后，凭什么认定它真的做完？

上次文章之后，仓库从 v4.3.6 一路更新到 v5.0.13。截至本文核对的 2026 年 10 月 2 日，最新正式 release 仍是 9 月 25 日的 v5.0.13，主分支最新提交为 9cba9fd。这一轮我最想展开的是两个变化：一边，BSK 执行内核让任务阶段、检查结果和放行证据逐渐连成一条可追溯的链；另一边，R 分析工作流开始认真处理依赖、恢复、验证和统计推断。如果你平时会用 Codex 写代码、做数据分析，尤其是准备论文里的结果，这轮更新值得花点时间看看。(～￣▽￣)～

1 概览

• v5.0 带来执行内核 BSK。 对接它的 skill 可以记录任务阶段、运行身份和验证结果，在必要证据缺失时阻止流程继续。
• 更新和运行环境更集中。 快速版本检查、静默增量更新、Gitee 镜像与统一托管环境陆续落地，减少技能文件与执行环境各自漂移的问题。
• R 工作流收敛到 simple / complex 两种模式。 简单分析保持轻量，复杂分析由 targets 管依赖和增量重算，renv 管项目依赖。
• v5.0.13 补上论文级统计推断要求。 关键结果需要对应估计对象、适当区间与方法依据；不适用、不可估计和未运行要诚实标明。
• 普通使用与 beta 能力要分清。 默认安装覆盖 alpha；本文介绍的两个 R skill 目前在 beta，需要显式选择安装源。

2 从 v4.3.6 到 v4.3.8：先把上次留下的小坑补齐

8 月 10 日的 v4.3.6，修的是 init-project 一个很具体的问题：用户已经通过 --disable-bac 关闭贡献记录，生成的 AGENTS.md 却还可能写着“默认且强制启用”。这样的文件交给 AI 以后，它到底应该听参数还是听项目指令？新版让生成内容与用户选择一致。8 月 18 日的 v4.3.7 又补了手动模式里未替换占位符的问题，避免把半成品指令留给后续任务。

同一版也延续了上次讲过的“问题优先计划”。writing-plans 开始默认照顾没有专业背景的读者：先用一句白话说明发生了什么，再通过具体场景或准确的类比解释改动，最后给专业判断。这个变化对我很实用。计划是用来让人判断的，读完以后应该知道改哪里、为什么改、对自己有什么影响；满页文件名和术语，很难帮助人做决定。

8 月 23 日的 v4.3.8继续处理图片配置。Windows、Git Bash、PowerShell 对用户目录的理解经常不一样，现在 auto-draw-plot 统一考虑 %USERPROFILE%、%HOMEDRIVE%%HOMEPATH% 和 HOME。如果 Codex 配置与 BenszAPI 环境变量里的 Base URL 或 API Key 不一致，会在提交图片请求前停止，并说明是哪类冲突；诊断保留配置来源和密钥短指纹，不记录完整密钥。对装过多个终端、换过 API 配置的小伙伴来说，这能减少“明明改了配置，怎么还在用旧的”这种费时间的排查。

3 v5.0：给 Skill 加上能留下证据的执行内核

9 月 3 日发布的 v5.0.0，带来了正式发布到 PyPI 的 bensz-skill-kernel 1.0.0，简称 BSK。此后仓库继续发布 v5.0.x，内核则迭代到了 2.1.6。这里先提醒一句：仓库版本、内核包版本、单个 skill 版本是三件事，所以 v5.0.13 搭配 Kernel 2.1.6、bensz-rmd-rules 0.29.0，是正常的。

BSK 在做什么？可以把它想成一次任务的流程记录和检查系统。State 表示“现在走到哪一步”，Verifier 负责“这一项有没有证据支持”，Gate 决定“能否继续”。例如，一个文档检查任务到了核验阶段，却没有运行必需的检查，系统就不能仅凭 AI 写出一句“检查完成”进入最终交付。检查确实跑了，但结果不确定，也要留下不确定状态。

这套设计里我比较看重的一点，是脚本、AI 判断和人工判断可以共同参与，但各自要说清输入、证据和结果。文件存在、路径是否越界，适合脚本检查；引用能否支持一句论断，可能还需要语义判断；必须由人确认的事情，则保留人工环节。BSK 把这些检查的发现、执行、记录和放行机制放到公共层，具体领域的判断仍留给各自的契约包。

它也没有要求每个普通 skill 都接上一整套状态机。当前仓库把这种接入保留为显式选择；最新的 R 分析 skill 本身也明确不自动接入 State、Verifier、Pack 或 Gate。需要这套机制的复杂流程，可以增加可核对的执行记录；简单任务仍然可以保持简单。 因此，看到项目有了 BSK，不宜理解成所有 skill 已经全面获得相同等级的验证保证。

4 最近几次内核更新：把“检查通过”绑到这一次任务

从 v5.0.6 到 v5.0.12，内核有一连串看起来偏底层、实际很影响可靠性的调整。用一个例子就容易理解：上午检查过某份结果，下午改了数据或代码，还能不能拿上午的“通过”去交付？如果任务重试了，旧的通过记录还能不能沿用？这些问题，光靠 AI 自己记住并不稳妥。

v5.0.6 收紧了检查结果的时间窗口，阶段进入之前的旧证据不能直接满足当前阶段要求。v5.0.7 增加阶段内关键动作的单次授权，并让同时接入 State 和必需 Verifier 的目标 skill 提供统一编排入口。这样，状态读取、请求准备、检查、放行和迁移可以由一个入口串起来，减少调用者漏步骤的机会。

v5.0.8 又把身份拆成“整次任务、某次阶段访问、阶段内的一次尝试”。任务重新进入一个阶段，或在阶段内开始新尝试，旧证据窗口与尚未消费的授权就会失效。它对应的其实是我们很熟悉的情况：同一个项目可以反复修改，同一个阶段也可以反复重试，但每一次结果都应该能找到自己的来路。

到了 v5.0.10与 v5.0.11，Gate 开始绑定业务证据的内容哈希和引用，状态迁移也要消费同一份证据绑定。尤其值得注意的是，v5.0.11 修复了一个实际控制链缺口：此前 CLI 可能只检查 Gate 存在，却没有把对应的证据绑定一起写入和消费。现在，受保护迁移要核对当前来源身份的允许 Gate；历史没有绑定的记录仍能读取，但会明确标为 legacy_unbound。“有一条通过记录”与“这条记录证明当前结果可以交付”，终于被更严格地区分开了。

9 月 21 日的 v5.0.12则修正了初始化限制：strict-v2 流程可以直接进入 skill 声明的领域初始状态，不必恰好从某个固定状态名开始。按发布记录，Kernel 2.1.6 在 192 项包内测试通过、发行包检查通过后发布到 PyPI。这里说的是项目公开记录中的验证结果；也要记住，这些测试证明的是内核相关行为，具体业务结果仍需对应业务检查。

5 更新 Skill 的同时，也把运行环境管起来

上次我们已经讨论过更新缓存，这次又往前走了一段。v5.0.2增加远程快速版本更新脚本：先读远端版本，远端更高或本地缺失时再调用远程安装流程；支持只检查、不安装，也支持筛选 skill。Gitee Raw 镜像优先、失败再回退 GitHub，仓库还增加了 GitHub 到 Gitee 的同步链路。

同一阶段新增的 --silent-update 使用 72 小时检查间隔，增量更新已经安装的技能；更新异常时保留最近可用版本。这个 72 小时是静默更新的检查节奏，不要理解成主动要求更新也必须等三天。用户需要主动更新时，仍然可以使用开头的那句指令，让 Codex 调用适合当前安装情况的更新入口。

到了 v5.0.9，安装器开始独占管理 ~/.bensz-skills/envs/benszapi 这个 Conda 运行时，并生成固定的 ~/.bensz-skills/bin/bsk 入口。以前可能出现项目 Python 装了一个版本、系统 Python 又装了另一个版本，终端里的 bsk 还来自第三个地方；统一托管以后，接入内核的流程可以更明确地使用同一个执行环境。

新的生产使用约定也收敛到最新版 BSK：新建或修改的 skill 声明内核包名，执行前由安装器确认最新生产版；旧的版本与能力字段保留为历史迁移兼容。需要手动检查时，安装器也提供运行时状态、创建或更新入口。这里的“统一”范围是技能执行内核；具体分析项目的 R 包依赖，仍然需要下面要讲的 renv 来管理。

6 R 分析这轮变化很大：简单流程轻装上阵，复杂流程交给 targets

最近几次 commit 里，bensz-rmd-rules 是变化最集中的部分。9 月中旬，它先引入编号分析单元和自制缓存、恢复机制；随后在 v5.0.12 中把 complex 模式改成 targets-first，9 月 23 日的 fc14b79 提交进一步删除编号 runner 与 legacy 兼容，收敛到 simple / complex 两种模式。中间方案已经被后续重构替代，照着早期 commit 里的执行器配置新项目，会跟当前规范冲突。

simple 适合线性、成本低的分析：明确的 R/Rmd 入口即可，不必为了一个小分析搭出复杂流水线。complex 则适合昂贵计算、非线性依赖、多个下游复用、局部失效、恢复或并行等需求。它用 _targets.R 声明依赖图，计算函数放进 R/，由 targets 管依赖、缓存和增量重建；Rmd 通过 tar_read()、tar_load() 读取结果。

以一个科研分析为例：原始数据清洗之后，需要拟合模型，再做敏感性分析和最终图表。如果只是调整图表颜色，合理的流程应该尽量复用仍然有效的清洗和模型结果；如果关键输入发生变化，受影响的下游结果则应重新计算。targets 正是用来管理这种关系的。计算与报告分开以后，修改报告排版也更容易避开昂贵计算。 当然，前提是实际依赖被正确写进图里，缓存本身不会替你判断科学设计是否正确。

目录也有了更清楚的用途：raw/ 保持只读；_targets/ 保存流水线的机器状态；products/ 保存需要审阅、复用或交付的科学产物；reports/ 承载报告相关产物。新项目必须用 renv 固定项目依赖。交付 complex 项目时，还需要提供语义清楚的 target 命名、阶段注释和 tar_manifest() 快照，让人能读懂这条数据流。

对已有项目，新版不会自动迁移。有 _targets.R 的按 complex 维护，没有 targets 的按 simple 语义维护；确实需要升级复杂能力时，再由人明确选择迁移。0.28.0 删除旧执行器是一次不兼容变更，所以依赖旧编号 runner、checkpoint helper 或 SUCCESS 标记的项目，升级前应先核对入口，不能把“更新 skill”理解成旧执行链已经获得兼容保证。

验证方式也更贴近实际：新建或实质修改的流程，需要用保持数据结构和边缘条件的合成数据，或得到授权的项目子集，调用真实分析入口。complex 的测试使用隔离 targets store，避免污染正式缓存与产物。语法或契约预检、真实轻量运行、全量数据运行分别报告；小数据跑通，不能顺手写成全量分析已经完成。这点我很认同，尤其是耗时几小时甚至几天的科研任务。

7 v5.0.13：让关键估计有统计依据，也允许诚实地说“算不了”

9 月 25 日的 v5.0.13把 bensz-rmd-rules 更新到 0.29.0，重点落在统计推断完整性。它要求计算之前逐项明确关键估计对象：针对什么人群、什么观察单位、什么参数或比较，研究设计是什么，目的是描述、估计、检验还是预测。先确定这些事情，才能判断区间和检验是否需要、是否可算、该用哪种方法。

例如，同一批受试者治疗前后的变化，分析单位应该保留配对关系；模型在外部验证集上的 AUC，要考虑对应验证设计的区间；如果只是汇报一个固定常数或完整已知总体的描述量，就没有必要为了让表格显得“专业”硬配一个 p 值。这些例子都说明，一个点估计不能自动推出一套合理的统计推断。

新版默认展示适当的 95% CI，已有方案另有预定置信水平时遵循方案；有明确零假设和检验问题时才给 p 值，批量检验还要说明比较族、调整方法以及 q 值或调整后 p 值。计算层保留未经显著性阈值筛掉的完整结果，报告里的数字能追溯到参数身份、单位、有效样本量或事件数、方法和数据代码来源。区间、p 值与实际意义一起解释，不能让“显著”两个字承担所有结论。

我尤其喜欢它对缺失结果的处理：明确区分已估计 estimated、不适用 not_applicable、不可估计 not_estimable 和未运行 not_run，后三者写清原因。模型不可识别、事件过少或某段计算没有执行，就应该如实告诉读者；不能补一个漂亮的数字，也不能把“未运行”写成阴性结果。对论文而言，知道结果在哪些条件下站不住，往往与知道结果本身同样重要。

这套规则也承认自己的验证边界：文本检查器可以定位措辞和数字缺口，却不能因为正文出现了“CI”“p 值”，就证明推断已经正确计算。真正复核还要逐项对照研究设计、完整结果和代码。详细规则已经落在 statistical_inference_protocol.md里，做论文级分析的小伙伴值得直接翻一翻。

8 新增 bensz-r-developer：可复用的 R 软件组件有了专门分工

9 月 19 日新增的 bensz-r-developer，负责可独立复用的 R 函数、类、公共 API 和 Package；9 月 20 日的后续提交又明确了它与 R 分析 skill 的边界。判定依据是主要交付物和复用范围：只服务当前分析的 helper，仍由 bensz-rmd-rules 主导；需要跨项目复用、独立版本化的组件，再交给 bensz-r-developer。

它把一些个人开发习惯写成了具体约定：数据确有不变量或生命周期时再选择 S3、S4、R6；最终输出使用 output.dir，可重建缓存使用 cache.dir；函数里的 if (FALSE) 块方便逐行手测，但自动测试仍由 testthat 等工具承担。Package 文档、依赖和检查则通过 roxygen2、devtools 等标准工具维护，并提供可运行的示例包。

性能方面也比较克制：先 profile，再考虑算法、向量化、复制和 I/O，随后才是并行或 C++。包内尊重调用方的 future plan，原生加速保留 R 参考实现与等价测试。对于越写越大的分析代码，这能帮助我们在确实有复用价值时抽出组件，并把组件验收与整条分析流程的验收分别做好。

目前 bensz-rmd-rules 和 bensz-r-developer 都位于 skills/beta/。 仓库默认安装与普通更新主要沿 alpha 源进行，beta 必须显式指定源；如果你要体验这部分功能，可以在 Codex 中进一步说明“请显式安装 beta 源中的 bensz-rmd-rules 和 bensz-r-developer”，并让它核对安装器与源配置。已有本地完整仓库的用户，也可以按安装说明使用本地安装器的 --source、--skill 参数。不要把开头的一句更新指令当成“自动安装所有候选技能”。

9 还有一些小变化，使用时很容易感受到

图片生成方面，v5.0.5 把 OpenAI 图片路径扩展为 gpt-image-2.5-flare、gpt-image-2.5-sunburst、gpt-image-2 三个白名单模型，默认选择 flare；三者沿用 BenszAPI 子域名校验、异步图片任务和请求状态不明确时不重放提交的约束。这是 skill 已支持的模型范围，实际使用仍取决于对应服务的可用配置。

最近两次界面修复也很具体。9 月 24 日的 2e1ef2a在 Liquid Glass 主题的代码区域关闭字体连字，避免 R 的 <- 被某些编程字体显示成单个箭头字形。9 月 25 日的 206190d则修复动态目录展开时，鼠标移入目录正文反而触发收回的问题，并补充 Chromium 交互回归测试。前者关乎代码能否被准确看懂，后者关乎目录是否顺手；都是长时间读分析报告时会在意的细节。

此外，better-prompt 在 v5.0.2 吸收了原 prompt-programming 的知识资产，把 Prompt Program 保留为可选输出模式；auto-test-skill 的 9 月 15 日提交要求显式传入 --task-root，测试产物统一进入任务工作区，不再由被测 skill 目录决定产物位置。文档、测试和中间文件的边界，也继续随着这轮重构一起整理。

10 小结

从上次的 v4.3.5 到现在的 v5.0.13，bensz skills 已经积累了一轮值得认真了解的变化。BSK 把阶段、身份、检查与证据绑定起来，安装器把技能更新和内核运行环境集中管理；R 工作流则通过 targets、renv、真实轻量测试与统计推断规则，让分析结果更容易复查。小伙伴可以先按开头的方法更新，再按需选择 beta 能力。对我来说，这轮最有价值的地方，是越来越多“完成”的说法能找到具体依据，而算不了、没运行或仍不确定的部分，也有了明确的表达方式。

项目 GitHub：https://github.com/huangwb8/skills