从会回答，到会交账：CrossFrame v5.1.7 做了什么

最近我又把 CrossFrame Skill Suite 往前推了一版。

现在公开仓库已经到 v5.1.7-20260624，release 名称是 CrossFrame Skill Suite v5.1.7。这次升级不是给它再堆几个新 skill，也不是让它多写几种文章体裁，而是把之前已经能跑起来的系统，继续往“可验证、可安装、可审计”的方向压。

简单说，这一版的重点不是让 AI 更会回答。

而是让它在回答之后，必须能交账。

为什么是“交账”

我现在越来越觉得，一个 AI 框架最危险的地方，不是它写不出来，而是它写得太顺。

写不出来的问题很明显：读者一眼就能看出它弱。真正麻烦的是另一种情况：它能写，能铺陈，能引用术语，能把一句判断包装成很完整的文章。读者读完觉得“好像有道理”，但回头一追问：这个判断从哪来？证据最多支持到哪一档？正文有没有比底稿更强？行动建议有没有越过证据？这些问题反而没人回答。

CrossFrame 一开始想解决的，就是这种“漂亮滑过去”的问题。

所以从 v5.0 到 v5.1.7，真正的变化不是让它更像一个聪明的作者，而是让它更像一个会被审计的工作流。它可以写文章，可以做结构诊断，可以处理公共议题、组织复盘、历史材料和读者来信，但每一步都要留下边界：事实边界、来源边界、概念边界、判断档位和撤回条件。

这就是我说的“交账”。

Claim ledger 变硬了

这次升级里最关键的一块，是 claim ledger 继续变硬。

以前我们说：判断要能回到 source_id 和 claim_id。这已经比普通 AI 输出强很多，因为它至少要求每一句中心判断知道自己属于哪条命题链。但只有字段还不够。只要没有反例测试，schema 就可能只是一个看起来严肃的表格。

所以 v5.1.7 新增了 claim ledger schema fixtures。

它不只是有一个“正确样例”，还专门放了几个坏样例：机制没有 id、强判断没有 source ledger、正文强于台账但没有处理方式、明明有 claims 却缺 ledger。然后用 scripts/validate_claim_ledger_schema_fixtures.py 去验证：好样例必须通过，坏样例必须失败。

这个动作看起来很工程，但它对应的是一个很基本的写作伦理：如果正文比证据更强，就不能假装没有发生。

很多 AI 文章的问题就在这里。底稿里可能只是“开放断言”，正文里却写成“已经证明”；底稿里只是“机制候选”，正文里却写成“根本原因”；证据只够支持低档判断，结尾却突然升到公共定性。claim ledger 要防的就是这种强度偷渡。

我想要的不是每篇文章都变成表格，而是让每篇文章背后都有一套能追责的命题台账。

触发边界更清楚了

第二个变化，是 crossframe-history 和 crossframe-inquiry 的触发语义被重新整理。

它们现在统一成 explicit-or-suite。

意思是：可以由用户显式调用，也可以由 crossframe-suite 路由进入，但不能在普通任务中偷偷触发。

这个边界很重要。

一个 skill 太容易触发，表面上看是智能，实际上可能是污染。用户只是问一个普通问题，系统却自动套上历史接口、追问接口、质量闸和复杂台账，最后输出看起来很“高级”，但其实违背了用户的任务边界。

反过来，如果一个 skill 永远只能 suite 内部调用，用户又无法明确点名它，就会损失可控性。比如用户就是想直接用 /crossframe-history 做史料边界分析，或者用 /crossframe-inquiry 接着上一轮输出追问反证，那就应该允许显式调用。

所以这一版的边界是：普通任务不隐式触发，明确点名可以触发，suite 调度也可以触发。

这不是小细节。它决定 CrossFrame 是一个可控工具，还是一个到处抢话的系统。

输出体积也被写成规则

第三个变化，是 crossframe-suite 增加了输出体积档位：

  • brief-visible
  • standard-visible
  • full-visible-v5-longform

之前 suite 默认就是重型链路：完整可见底稿、完整长文正文、review。这个默认对公开文章和复杂问题是有价值的，但它也有成本。不是每一次用户都要看一整套长文，不是每一个问题都值得把全部后台展开。

所以现在可以显式要求短版或标准版。

但这里有一个关键限制：体积可以变短，质量要求不能消失。

brief-visible 不能变成“随口一句判断”。即使是短答，也要保留事实边界、关键 claim_id、判断档位、撤回条件和行动上限。standard-visible 可以压缩正文，但不能把 review 摘成一句“已通过”。

这对我来说是 v5.1.7 很重要的一步。

因为真正成熟的框架，不应该只有一个输出形态。它要能长，也要能短；能写完整文章，也能给一个清楚的方向。但不管长短，它都不能靠删掉边界来换取轻便。

公开仓库开始像一个真正项目

这次还有一部分变化，是给公开仓库补工程基础。

GitHub Actions 的 verify workflow 现在不只跑基本检查，还会检查 Bash、PowerShell、Python 脚本语法，校验 claim ledger schema fixtures，检查 mirror sync，并做发布包 smoke test。

换句话说，仓库现在不只是“放了一组 skill 文件”，而是开始有一套公开可复验的发布门槛。

这点对我很重要。

因为 CrossFrame 这种东西，如果只停在文档层，很容易变成“作者说它很严谨”。但一旦放到公开仓库里，它就必须接受另一种约束：脚本能不能跑，安装包是不是完整，网页是不是同步，CI 有没有通过，release 里的内容和 README 说的是不是同一件事。

我不想让它只靠理念成立。

它应该在文件结构、校验脚本、CI workflow、release 包和公开页面里同时成立。

安装和网页也在变稳

v5.1.7 还修了一些看起来不那么宏大的东西。

比如 Windows 的 install-codex.ps1 增加了 py -3 / python fallback。以前如果用户机器上没有 py launcher，安装脚本就可能卡住。现在它会先找 py，找不到再找 python，都没有才明确报错。

公开介绍页也做了交互补强：Demo / Install tabs 支持方向键、Home、End 切换；没有 JavaScript 的时候，页面仍然保留默认安装命令和说明。

这些东西不性感，但很必要。

一个工具如果只在作者自己的机器上顺手，那还不能算公开项目。公开项目必须考虑别人打开页面、复制命令、缺少环境、浏览器禁用脚本、键盘操作等细节。它不是让框架变“更哲学”，而是让框架更像一个真的可以被别人使用的东西。

这一版真正改变了什么

如果只看 changelog，v5.1.7 的更新可以概括成几条：

  • claim ledger schema fixtures
  • history / inquiry 的 explicit-or-suite
  • suite 输出体积档位
  • 更完整的 CI 验证
  • 安装脚本和网站交互补强

但我更愿意把它理解成一个方向的继续收紧：

CrossFrame 不是要让 AI 更能说，而是让 AI 更难在没有证据、没有边界、没有撤回条件的时候把话说满。

这也是我这一轮升级最想保留的精神。

AI 当然会越来越会写。它会写得更顺、更像专家、更像完整文章。但越是这样，越需要有东西把它按回去：这句话是谁支持的？这个概念有没有被武器化？这个判断强度有没有偷渡？用户有没有真的要求这个 skill 启动？输出变短之后，边界是不是也被一起删掉了？

如果这些问题没有被回答，那再漂亮的输出也只是包装。

从框架到项目

我现在对 CrossFrame 的理解也在变。

最早它是一套结构诊断框架。后来它变成了一组可以被 agent 调用的 skills。再往后，它开始有网页、安装脚本、release、CI、schema fixtures 和发布包。

这个过程其实是在把一套思想，慢慢压进工程结构里。

思想层面说“不要越界”很容易。

工程层面要做的是：把越界变成能被检查出来的东西。

比如正文强于台账，就要能被 schema fixture 想到；普通任务不该触发 history，就要在 skill trigger 和 agent policy 里写清楚；公开页面说能安装，就要让安装命令在 no-JS 状态下也能被看到；release 说包完整，就要让 CI 打包并检查 zip 里有没有关键文件。

这就是这次升级的意义。

它不是一次“功能扩展”，而是一次“约束扩展”。

我越来越相信，复杂 AI 工作流真正有价值的地方，不在于它能生成多少东西，而在于它能不能限制自己。

能回答，是能力。

能交账，才是框架。