Skip to content

v1.34.0 — 有向 relatedness、结论可复算、评估集自检

Choose a tag to compare

@Spc-jgs Spc-jgs released this 17 Aug 03:08
· 62 commits to master since this release
8373913

本版一个新 helper,两条关于怎么得出结论的仓库约束,一次裁定,以及一轮把评估集自己送上审判席的返工 —— 三个「测量的东西不是它声称在测的东西」被抓出来并修掉。

有向 relatedness:笔记声明自己依赖谁(#75)

suggest-directed-links 回答的是跟随一条链接时读者真正的问题:这些链接里哪些是这篇笔记倚仗的,倚仗它做什么。

判断刻意不是相似度,而 #75 冻结的标签就是理由。它 16 条硬负例每一条都与来源共享一个词、此外毫无关系:Release Quality GateAirport Departure Gates,Source Archive FormatMuseum Archive Visit,Read-only RetrievalReading List。任何基于词重叠的排序器都会给它们高分 —— 这个集合的存在就是为了惩罚 search-vault 用的那种方法

16 条正例的共同点是来源在自己的正文里说出了它拿目标做什么:它引用委托给导入遵循表示为其倍数

所以候选需要同一句话里同时有显式引用和依赖短语。裸链接不是依赖:一篇 See also 列了五条链接的笔记,声明了五条链接、零条依赖,links_without_a_dependency 数着它们,好让「没找到」读起来不同于「没链接」。没有分数、没有阈值、没有置信度 —— 一个候选要么有声明的依赖,要么不是候选。

阈值在写任何代码之前就登记在 issue 上,附一条可证伪的预测:负例会得而不是「低于某阈值」,而如果需要调一个数字,就说明判据本身错了。预测成立:16/16 正例带证据找到,0/16 负例被提出,负例侧根本没看见任何引用。

参考 Vault 上:195 篇笔记、262 条链接行、5 个候选、256 条链接被正确拒绝。五个都是真的 —— 一篇把另一篇引作选型依据,以及 Python 系列的前置链:迭代器依赖生成器依赖切片迭代。262 里出 5 条是发现,不是缺陷:放宽判据把这个数字做大,会把 16 条硬负例全部放回来。

两条词表项来自那个 Vault 里观察到的形式,记录计数与位置,从不猜同义词:前置知识 ×3、前序知识 ×2,把候选从 1 个带到 5 个。同一遍量到并刻意不收的:详见 ×4、参考 ×2 —— 那是指针,不是依赖。

故意砸守卫砸出了两件测试没在说的事。 整个删掉依赖要求,16 条硬负例照样全被拒 —— 它们守的是「不许从共享的词推断」,对「有依赖的链接 vs 没依赖的链接」什么都没证明。而「同句」规则根本没人守:放宽到整篇,什么都没红。两件现在都有测试,也都写进评估报告,而不是留给读者从 16/16 里过度解读。

复述下一步行动时必须报出它所在的标题(#109)

每次都报,不只是在条目看起来可疑时 —— 因为「看起来没问题」正是读者需要能核对的那个判断。

参考 Vault 上,一份可复用检查表和真正的 P0 计划是同一个 ## 下一步行动 之下的兄弟小节。没有任何结构能分开它们,分开它们的是作者给它起的名字。

本项目已经三次拒绝让 helper 读标题的语义 —— #86 设计续航包时、#115 自由结构笔记几乎无输出时、#109 从相反方向。三次裁决躺在三条 issue 评论里,第四次 issue 得把三条都找出来才知道这是一条已定的边界而不是疏漏。现在它是 docs/superpowers/specs/2026-08-17-heading-semantics-boundary-decision.md,含被拒的替代方案和什么会重开它。

计数行为不变,包括那篇的 open_tasks_in_next_actions 仍然是 15。那个数字对它测量的东西是对的,它为什么会误导,记录在案而不是修掉。

AGENTS.md 多了两条约束:结论怎么得出的(#124)

已有的那条管「两处必须一致」。新的两条管另一类:

关于总体的结论 —— 多少个、哪几个、多大比例 —— 必须给出一条输出可复算的命令。

一道新断言必须至少见过一次红。

两条都点名本项目已经产生的实例,而不是写成泛泛的劝诫:

  • #93 正文说加严可达性判据会让六个 helper 不可达,紧接其后的分解按它自己的判据推出的是一个,今天实测输出是两个 —— 它列了 13 个里的 11 个。同一个习惯让 #133 的引文指向了错误的文件,从而提出了错误的修法。
  • 清单第 17 行断言为真,覆盖面小于它的名字;#118 为上报信号写的断言是空的、绿着、放过了错误输出;故意删掉 #75 两条守卫本该守的判据,它们断言的东西一样没变。这些在一次全绿的测试里都看不见。

段落明写这两条不做成 CI 检查,以免日后有人补一道正则匹配 commit 文本的假守卫。

三个「测量的东西不是它声称在测的东西」

深度选择:量完发现没东西可修(#74)

#74 的第一条验收标准要求用 v1.30 那个模型重跑 12 次。本项目不再运行那个产品,所以这条按原文不可满足,它的 8/12 也不再是可比基线。绝对门槛换成同一 Agent 的前后对比,summary.json 记录 agent / agent_version / comparable_with_fixture_baseline,免得一个产品的数字被读成另一个的。

量出来的答案是没东西可修。 现状指令下深度选择 12/12 全对,由写出来的 15 篇笔记逐篇读 capture_depth 确认。对比 v1.30 的 8/12,以及在那两个曾经误升级的用例上 6/6 对 2/6 —— 按旧比率,连中 6 次的概率 (1/3)^6 ≈ 0.0014

跑之前登记的预测就是:12/12 意味着候选措辞没有可移动的信号,不该合。它没合。

这不证明指令无歧义:诊断出的那个歧义真实存在于 web-capture.md:26,那里命名 verified 触发条件的词,在请求描述来源内容时同样出现。一个 Agent 没被它绊倒。

事实分有一部分在测输出语言(#147)

同一用例的两篇笔记都用中文完整记录了全部五条事实 —— 其中一篇 只读 ×9、检索 ×7、写入 ×12、用户意图 ×3、预检 ×7 —— 一篇 5/5,一篇 1/5。差别全在有没有顺手各回显一次英文原词。两篇保留的知识一样。

一条事实现在可以有多个可接受形式。每个形式都是某次真实运行写出来的,连同计数记在 fact_form_provenance 里,按 #75 给词表定的规矩:收录观察到的,不收录听起来像的。一条断言守着,猜来的翻译加不进去。

考「必须读图」的用例,一张图不看也能满分(#146)

那个用例五条 required fact 全部出现在它自己的来源文本里,而来源明写着文本不指定图里的东西。一个不会在它存在意义那件事上失败的评估资产,就是一道出生即绿的守卫 —— #117 的形状。

补了两条只有图里有的事实。但颜色判据分不出「读了图」和「猜了个像样的颜色」,所以真正的判据放在事件流:新硬失败 material-not-inspected 查有没有读取类工具调用指向那个资产。目录列表会打印图片名字而没人看过它,所以笔记和文件名都不是证据。手上的运行六次全都打开了它。

顺带,评估的硬失败契约现在列的是门禁真能抛出的码。它记了 14 个里的 8 个,还记了两个判分器从不抛出的:一个由别的名字实现,另一个 —— invented-source-access —— 从来没有任何检查,所以 prompt 禁止抓取来源 URL 这件事从来不是一道门禁。这一对没删,移进 hard_failures_not_implemented 写明各自下落。

判分器的两个中文假阳性

一篇按 required fact 记下来源自己说的「不支持 Python 3.10」的笔记 —— 那是被禁断言的反面 —— 被判成断言了它,因为否定只认 /没有 加四个写入动词之一。而「,」不算子句边界,于是「原文把 2.4.1 和 Python 3.12 绑定,并单独排除 3.10」把两条各说各话的陈述凑成了一条断言。英文「,」仍然刻意不算边界。

早先那版基线两个都没撞上。那是措辞碰巧,不是判分器可靠。

升级

git pull && ./install.sh

已经用 Skill 管理器的机器改用:

git pull && ./install.sh --runtime-only