Repository navigation
chore: 把 #21/#22/#25 的内容汇总并入 main（合并顺序收口） - #26
Merged
Merged
Conversation
rubric.md：重写为「正文 + 打分细则（歧义点定死版）」八节，把每轮都会吵的判据写死——命中 1 含「在别的条目里顺带说对」、归类的分母是 finding 条目数、G12/G13 特例、证据的 E 原则、表达质量的最小对照例子判据、raw 公式与读分提醒。 baseline.md：追加 v4 轮（不改首轮 12 条口径的历史记录）。冻结提交 7c1c4ea，三种问法各 1 轮，原始输出留仓外。命中 15.5/13.0/19.5，误报全 0，归类 10.5/8.0/12.0，证据 4.93/4.73/4.20，raw 163.4/154.4/151.6。断言 ③ 按实测改写为「不成立」，并附 6 处分歧的口径与数字影响表。 Co-Authored-By: MiniMax-M3.1-Flash <noreply@minimax.io>
问题：七维全是「和现有东西比」（能不能组合、有没有第二个真相源、删掉损失什么），没有一个动作要求质疑设计本身；第 3 维的成立条件是「输入 → 错误结果」，而复杂度问题没有错误结果，按闸门卡它永远不成立。两者都从 Pulse 的两轮深审里漏出来。 SKILL.md： - 执行顺序新增第 2 步「反驳」：对每个公开概念质问四句（几处实现 / 语义在正常-异常-恢复路径是否一致 / 统一调用方能否用同一形状 / 职责有没有被两个抽象认领）。产出大多进「需要你拍板」。 - 第 3 步七维之后新增「规模扫描」：输入规模 N、随 N 怎么长、有没有重复访问同一状态/每层拷贝完整结果/每次重新全量扫描。规模问题不需要错误结果，证据是规模关系加实测。 - 判定纪律加一条「不要默认设计是对的」。 - 分级加两条校准：规模按「N 到多少会出事」定级，语义分裂按「谁会被绊住」定级。 references/dimensions.md： - 第 6 维「重复」的成立条件从一条扩到两条，新增「语义分裂（同一动作，多条路径，行为不一致）」，并给出三样必给的判据：两条路径、具体场景、不同的结果。 - 第 2 维扫描动作加第 10 条「跨层形状」：抽象层与实现层/后端层类型形状不一致，能编译不等于形状一致。 - 新增「规模与复杂度」节：为什么七维管不到它、六类扫描动作、成立条件与证据形式、不算什么、定级与修法方向。 references/playbooks.md：批处理与 API/库两类补规模高发场景与跨层形状；明确规模扫描不被任何 playbook 覆盖。 README.md：两档模式、七维表、四个机制（新增「反驳一遍」）、证伪闸门补两条问题、设计取舍补两条为什么、评测段补「样本决定了测得到什么」。 Co-Authored-By: MiniMax-M3.1-Flash <noreply@minimax.io>
为什么要有第二个样本：tiny-shop 是 150 行的结算模块，里面没有指数级回溯，也没有分裂成两条路径的动作——它测不出新增的「反驳」与「规模扫描」。两个样本分开跑，分数分开记，才能同时回答「旧的没退化」和「新的生效了」。 样本 internal/promo：约 370 行 Go，可编译、可跑测试。植入 6 条缺陷： - R1 依赖图共享节点时可达性展开指数级（实测深度 24 → 392,808 条 / 202 ms / 896 MB） - R2 找重复 SKU 用两两比较（O(n²)） - R3 每层深拷贝完整依赖链（深度翻倍分配 ×4） - R4 每次查折扣都重建整张索引表，且在 Apply 的内层循环里 - R5 Apply 与 ApplyChecked 做同一件事但行为不同（一个就地改购物车一个不改；一个静默跳过一个报错）——语义分裂 - R6 promo.Pricer 与 sqlstore.Engine.Apply 的类型形状不一致，后端不可替换 外加 C1 并发确认点（rules 只读，改的是入参切片）与 5 条「不该报」候选。 标准答案另立一份（ground-truth-rule-engine.md，R× 编号），tiny-shop 的 G1–G25 原样不动，保证 v4 基线仍可比较。 runbook.md：两个样本两套标准答案；rule-engine 只跑 B+C（反驳与规模扫描只在全量模式）；隔离目录分开。 Co-Authored-By: MiniMax-M3.1-Flash <noreply@minimax.io>
依据 Pulse 两轮深审的实测材料补强判据： 规模与复杂度： - 补六类可识别的代码形状（递归遍历的对象可共享 / 父层拼子层结果 out = append(out, child.collect(...)...) / 同一候选在每次外层迭代里重算 / 谓词每次遍历声明列表 / 同一列表在建索引与查询处各扫一遍 / 逐层从根重跑） - 补热路径放大与锁内放大两条 - 证据形式补「规模曲线优于单点数字」 - 补取舍要求：改法可能让内存变差，只报时间不报取舍的结论不完整 语义分裂： - 差异必须体现在外部可见的副作用上，只差在内部实现细节不报 - 补「缺陷 vs 契约未定」的分寸：上层注释已承认这条差异是有意为之的，是已知取舍，进拍板不是缺陷 跨层形状： - 判据要并排列出两个签名并指出具体差在哪 - 同一条分寸：上层注释已明说是有意为之的，进拍板不是缺陷 Co-Authored-By: MiniMax-M3.1-Flash <noreply@minimax.io>
规模扫描是一个有「跑了/没跑」之分的扫描面，不在覆盖表里就没有证据位——作者无法区分「扫了没问题」与「压根没扫」。骨架表与示例表都补上这一行；SKILL.md 的输出契约同步说明它单独成行。 Co-Authored-By: MiniMax-M3.1-Flash <noreply@minimax.io>
速查表是模型第一眼看的东西，第 6 维原来只露出「第二个真相源」，语义分裂的入口被藏在了细则里；第 2 维原来只问单个函数，跨层形状不一致也没露头。 Co-Authored-By: MiniMax-M3.1-Flash <noreply@minimax.io>
feat: 加「反驳」一遍与「规模扫描」——补上算法复杂度与语义分裂的审查面
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
这是什么
把已经合并的 #21、#22、#25 汇总并入
main。#21 的 base 是
docs/eval-caliber、#22 与 #25 的 base 是docs/eval-v3-baseline——它们都不直接指向main，所以按序合并后main只拿到 #18 与 #19。这条汇总 PR 把整条链一次并进main。内容与各 PR 完全一致（#21 的 5 处执行文件口径修正 + #22 的判分细则与 v4 基线 + #25 的「反驳」与「规模扫描」），没有新增改动。
顺序
main← #18 → #19 → #21 → #22 → #25 → 本 PR