Repository navigation
v1.2.0 候选：评测暴露的 6 条能力边界（G4 承诺无对应对象 / G19 位置指代 / G22 状态持久性 / G23 零使用字段 / G12 判别线 / 包名措辞） #23
Description
v1.2.0 候选：评测暴露的能力边界（6 条）
本票不是 bug 票，是能力扩展票。 这几条在 v4 轮评测里被标准答案点名、但三轮都没当成一条结论报出来。补它们要改 references/dimensions.md 的成立条件，按 evals/runbook.md 的规则必须重跑一轮评测，所以不能塞进 v1.1.0。
来源：v4 轮评测（冻结提交 7c1c4ea，三种问法各 1 轮），分数与逐条判定见 evals/baseline.md（PR #22）。v1.1.0 的票面与结论见 #20。
一、这六条的共同点
它们都不是「skill 内部口径打架」——skill 自己的判据是自洽的、该跑的路径都跑通了。它们的共同点是判据写得不够具体，或者判据的触发面比实际缺陷形态窄。
换句话说：这三条文档/设计类问题不是「模型不会」，是「skill 没告诉它该按哪个形状去问」。
二、逐条
B1 · G4：godoc 承诺指向的对象在模块里根本不存在
| 项 | 值 |
|---|---|
| 样本 | checkout.go:60-61 的 godoc 写「read-only with respect to the order store… never writes back to the database」 |
| 问题 | 这个模块里没有数据库、没有 repository、没有接口。承诺没有对应对象。读者按承诺去找「订单存储」找不到，会以为这函数已经接到 DB 上 |
| 三轮表现 | A、B 判「承诺成立」；C 说的是镜像问题（承诺低估了副作用）。三轮都没问「承诺指向的那个对象在不在」 |
| 根因 | references/dimensions.md 第 4 维（文档）没有对应判据——只教了「文档与实现不符要报」，没教「承诺指向的对象不存在也要报」 |
| 期望处置 | 在第 4 维补一条可操作判据：「文档承诺里提到的对象（存储/DB/外部服务/队列）在本模块里不存在 → 报；放进「需要你拍板」也算对」 |
| GT 级别 | P2 |
为什么这条值得补：它是文档维度里唯一没被覆盖的一类失败。模型能发现「文档说的和代码做的不一样」，发现不了「文档说的那个东西压根不存在」——后者需要先确认模块边界，比逐行核对难。
B2 · G19：godoc 措辞里的位置指代（「第二个返回值」实际是第一个）
| 项 | 值 |
|---|---|
| 样本 | refund.go:24-26 注释说「第二个返回值表示是否新签发」，实际签名是 (bool, error)，bool 是第一个 |
| 触发 | 照注释写 err, ok := r.Issue(...) → 编译期类型不匹配 |
| 三轮表现 | 三轮全漏。B 轮甚至引到了那段 godoc 去背书幂等语义（「与 refund.go:24-26 的文档一致」），说明它读到了、但没核「第几个」 |
| 根因 | 判据已经存在（references/dimensions.md:101 明写「godoc 与实现行为不符、注释把返回值顺序说反了，这些要照报」）→ 不是没写判据，是没触发 |
| 期望处置 | 判据保留，补触发动作：文档核对时按「声明的参数/返回值个数与顺序 → 与签名逐位对齐」列一张对照，而不是只核语义 |
| GT 级别 | P2 |
为什么这条值得补：这是「判据写对了但模型不执行」的典型。B2 与 B1 的处置完全不同——B1 是补判据，B2 是补动作。混在一起改会看不出是哪种失效。
B3 · G22：状态持久性接缝缺失
| 项 | 值 |
|---|---|
| 样本 | 退款幂等只存在于进程内存的 issued map，无持久化、无存储接缝 → 重启/多实例后同一单会退两次 |
| 三轮表现 | A 划进「本次没覆盖」（纯内存实现，持久化不在范围内）；B 兼容性维度直接「未扫」；C 判「无发现」 |
| 根因 | 兼容性维度的检查面里没有「状态持久性」这一项 |
| 期望处置 | 兼容性维度补一条：「本模块维护了跨调用/跨请求的状态 → 这个状态存在哪、重启后还在吗、多实例之间共享吗」 |
| GT 级别 | P2 |
B4 · G23：Order.ID 零使用
| 项 | 值 |
|---|---|
| 样本 | checkout.go:41 的 Order.ID 全模块零引用（grep \.ID 零命中）→ 字段叫 ID，读代码的人会以为结算链路用它做去重或记账 |
| 三轮表现 | A、B 全文零提及；C 提到但当成「无注入面可报」排除 |
| 根因 | 过度设计维度覆盖的是「接口只有一个实现 / 一个文件多个类型」这类模块级形态，没覆盖字段级的「有名字没用途」 |
| 期望处置 | 过度设计维度补一条字段级判据：「结构体字段全模块零引用 → 报（字段名暗示了它承担职责时尤其）」 |
| GT 级别 | P3 |
B5 · G12 判别线的位置：百分比取值范围 vs 折扣能力
| 项 | 值 |
|---|---|
| 样本 | checkout.go:35-37 的 Percent 不校验，允许 >100 或为负；负折扣会让 total 变大 |
| GT 要求 | 放进「需要你拍板」（业务口径问题），直接报成 P0/P1 算误判 |
| 三轮表现 | A 明确排除（命中 0.5）、B 完全未提（命中 0）、C 在别的拍板项里顺带提到（命中 1、归类 0.5）。没有一轮拿到归类 1 |
| 根因 | 判别线画在「折扣能力」（DiscountStrategy 该不该有）上，没画在「百分比取值范围」上——后者同样是「业务允不允许」，模型却当成了实现细节 |
| 期望处置 | 拍板判据里补一条对称示例：「参数取值范围（百分比、超时、限额）→ 属业务口径，进拍板；不要当实现缺陷」 |
| GT 级别 | 拍板 |
B6 · 包名理由被压缩回旧措辞（不计分，但会让下一轮复算对不上）
| 项 | 值 |
|---|---|
| 现象 | A、B 两轮仍写「编译器不报错（起个别名即可）」 |
| 事实 | 实测确认：两个同名包在同一文件里一起 import 而不起别名，编译器会报 shop redeclared in this block（7c1c4ea 已修正 references/dimensions.md 的措辞） |
| 三轮表现 | 处置结论三处都正确（都没进「必须修/建议修」），只是理由被压缩回旧说法 |
| 根因 | 判据里同时有「两个包同名」这个事实和「起别名能解开」这个修法，模型在压缩表述时保留了后半句 |
| 期望处置 | 判据里把「起别名能解开」移到修法那一栏，别放在事实那一栏；事实只留「编译器会报 shop redeclared in this block」 |
| 影响 | 不计分（GT 处置规则没变），但会让下一轮复算时对不上措辞 |
三、验收标准
- 每一条在
references/dimensions.md里都有对应的可操作判据——判据要写成「看到什么形状 → 报成什么级别 / 进不进拍板」，不是一句原则。 - B2 的判据要动触发动作，不只是措辞——它是「判据存在但没触发」，光改措辞大概率还是不触发。
- 改完之后必须按
evals/runbook.md重跑一轮评测（改了成立条件 → 触发条件）。理由、样本、输出规范见evals/runbook.md。 - 重跑后对比 v4 轮基线（
evals/baseline.md），至少要能回答：这六条各自命中没有、归类对不对。命中数不是唯一指标——归类错（比如把该拍板的判成缺陷）比漏报更糟。
四、这一轮不做的
- 不改
SKILL.md的执行顺序、七维表、输出契约——那要单独开票、单独评测。 - 不扩样本规模——现在的样本（约 150 行）够测出这六条。B4（字段级零使用）如果要更硬的证据，可以考虑加一个更长的样本，但那是另一票。
- 不动 G13 / G8 的口径——那是 GT 侧的判分口径问题，不是 skill 能力问题，已在
evals/rubric.md里定死。
五、相关
| 事项 | 位置 |
|---|---|
| v4 轮基线与逐条判定 | evals/baseline.md（PR #22） |
| 判分细则 | evals/rubric.md（PR #22） |
| 样本 | evals/fixtures/tiny-shop/ |
| 重跑的操作手册 | evals/runbook.md |
| v1.1.0 票面（本票的来源） | #20 |
Activity