内置imagegen生成的概念版画:老式时钟、铜线曲线与抽象工作纸,呼应曲线参数的时间来源;不是实际密码设备、数据图或新闻照片。

DAILY AI INTELLIGENCE

最新日报 历史日历 ↗

2026-10-17 · AI 日报

从时钟重现曲线种子,再追问它为何被选中

7 条精选1 份学习材料资料截至 2026-10-17 08:01(北京时间)

EDITOR’S NOTE

本期导读

密码标准通常会公布一组人人共用的参数,让不同实现可以互通。可把参数写进标准,和留下它们当年怎样产生、为何被选中的记录,是两回事。ECDSA 是广泛使用的椭圆曲线数字签名方法;它的一批标准曲线长期有种子来源不明的问题,过去的查找又受到“短语哈希”传闻影响。

本期先读曲线种子溯源:Anthropic 报告,模型从旧式伪随机数生成器的输出结构恢复状态,再找到对应时间戳。这个办法能把现有参数重算出来,却仍未解释部分可行候选为何被跳过。第一篇观察围绕这段差别展开,把可检验的新关系与尚未恢复的选择历史分开。

接着读量子电路重设计。这里也让模型反复提出候选,但外部程序会核对行为、统计量子比特和门数;一些设计还明确以允许的小概率失败换取资源。两项工作共同提醒我们,理解一次发现,要看清检查究竟承诺了哪些条件,不能只记住“模型找到答案”。

第二篇观察回到自动代码审查。Claude Code 团队不仅回放事故,也让审查器检查已知干净的改动,统计误报是否诱发有害修改;这给上期只看失败回放的疑问补上一种可行办法。再读聊天应用压测,会看到另一类代价:成功送达更多消息,可能只是让用户等得更久。

组合筛选

METHODS & SYSTEMS

技术进展

05
值得读评测与基准 / 推理能力
追踪记录 ↗

时钟生成了曲线种子,仍有候选跳过的原因未明

技术Cryptographic ProvenancePRNG State RecoveryLattice Reduction
可信度
65
重要性
81
新颖度
79

ECDSA 是一类用椭圆曲线完成数字签名的方法。NIST 在2000年发布的标准给出了曲线参数和生成参数的种子,却未解释种子最初如何产生。过去有人沿“幽默短语的哈希”查找;Anthropic 这次报告,内部研究模型换了方向,检查1990年代常用伪随机数生成器留下的位模式。伪随机数由有限内部状态确定,找到状态便能重建整段输出。

模型从部分曲线种子的最高位规律识别出 C 库 lrand48,再枚举隐藏位;对于只保留每次输出一个字节的另一批种子,则用 LLL 格基约简——把整数关系中的隐藏结构找出来——恢复状态。逆推初始化后,十个采用模素数运算的曲线种子对应1997至1998年的时间戳。例如 P-256 对上1997年8月16日的一次初始化及第1842个候选;其公布种子也能与旧标准核对。

这是参数来历的解释。团队没有报告签名被破解,并明确保留未知项:P-256 的更早可行候选为何被跳过、B-163 种子为何不匹配,以及若干基点怎样选择,仍未解释。

lrand48 从48位状态输出31位字,再截取高字节,留下可用于恢复状态的结构。图为作者的方法说明。Anthropic Frontier Red Team · 原文状态位示意 · 原文图表 · 图片出处 ↗

fidotron · 原帖 / 原文

语境:针对同一篇参数来源报告的分析;未提供独立攻击或重建实验。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他认可这确认了产生方式,却认为无法据此说明为何选中这些参数:生成跨越数月,未公开的弃选候选仍不可见。他也不同意“若要制造可信来历,就应当时公布时间戳”是必然推论;保持沉默也可能达到目的。

matthewdgreen · 原帖 / 原文

语境:回应同串关于弱曲线筛选的假设;身份按公开账号记录,不另凭名气提分。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他的反驳是:若这么小的搜索就能遇到可利用的弱曲线,弱曲线类别必须非常多;那将涉及椭圆曲线密码本身更大的问题。该评论给出判断理由,没有提供针对本次曲线的新攻击或完整概率计算。

编辑评读

我认为最有价值的进展,是把一段无法询问原作者的历史变成可核对的生成规则。时间戳、迭代次数与完整种子之间的对应比“模型说自己发现了”更有内容,也不依赖相信其自述思考。但这只重建了一条能得到现有参数的路径,没有恢复所有曾被生成、审查和丢弃的候选。原文承认存在跳过的可行曲线,因而“生成方式简单”还不能自动推出“选择过程没有自由度”。

HN 的 fidotron 强调遗漏的选择记录,matthewdgreen 则认为要靠这种小规模搜索选中弱曲线,需要弱曲线类极多。两人并非在争论数值能否匹配,而是在赋予未见历史不同的先验合理性。前者的反例并未发现后门,后者的判断也不等于完整安全证明。比追随任一极端更有用的后续,是查到当年的筛选条件或新恢复的候选记录;在此之前,把结果用于解释来源,别扩大成新的部署结论。

依据 1 · 依据 2 · 依据 3 · 依据 4

值得读AI 编程 / 评测与基准 / 推理能力
追踪记录 ↗

Claude 重设计量子电路:少存历史,也显式使用失败预算

技术Reversible ComputingQuantum Circuit OptimizationFormal Verification
可信度
65
重要性
83
新颖度
81

量子算法常受制于两种资源:量子比特保存多少中间状态,以及量子门执行多少次操作。可逆计算要求临时信息最终被“反计算”清除,不能像普通程序那样直接覆盖。将经典算法搬进量子电路时,保存每轮分支历史因此可能消耗大量空间。研究团队让 Claude 提出 Python 形式的电路,外部程序检查行为并统计资源,再把反馈交回模型迭代。

论文考察八类基础计算。模型先提出不同算法家族,分别优化,再共享有用方案。七类任务同时减少门数和比特数;椭圆曲线点加法则改善两者的取舍。其关键是重做模逆运算,即求一个数在模运算下的倒数:从当前数值恢复 divsteps 的分支,避免全存历史,并对分支恢复结论进行数值检查和 Lean 证明助手中的形式化检查。与此前最小设计相比,一种方案多用约12%比特、少用约17倍 Toffoli 门;Toffoli 是资源估算中较昂贵的一类逻辑门。

另一例把纠错解码改成更适合固定回合的 Berlekamp–Massey 方法,并恢复多数临时值。在允许约万分之一失败的条件下,只为一个例外值预留空间;整段解码门数约降12倍。这些是电路设计和资源估算,尚非实际量子设备上的应用提速。

作者对解码器定位步骤的资源示意:改变算法减少门数,恢复历史减少辅助比特;有界失败与完整解码结果须另读正文。Gu、Kemeny 等 / Anthropic · 原文图4 · 原文图表 · 图片出处 ↗

keeganryan · 原帖 / 原文

语境:对同一量子电路工作的技术分析;评论本身不是资源结果的复现。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他把工作放在可由经典计算机模拟的量子电路语言背景下:候选能够迅速检查、评分和淘汰,适合让模型反复优化。他认为这类任务很适合自动化,并指向其他电路优化案例;这是对任务结构的解释,不是独立重测本论文。

编辑评读

这项工作的可迁移之处,是给搜索留出结构变化的空间,同时让评估仍有明确对象。只能在已有电路上改门序列,可能找不到“从状态恢复历史”这类架构变化;直接放开任意程序,又会丢掉可检查性。论文选择能在计算基输入上追踪比特串和相位的电路类别,因此能够尝试高层改写。HN 的 keeganryan 强调这一可模拟条件,这有助于理解为什么它适合自动搜索,却不能据此把所有量子算法都归为同样容易验证的任务。

更要区分确定性的分支恢复与用小概率失败换资源。前者需要检查命题及实现范围,后者需要检查允许失败的输入分布和预算如何传到完整算法。两者都可以是有效改进,比较时却不能只剩“少了多少门”。我会优先复核候选列表、相同误差门槛下的资源前沿,以及高层改写在全尺寸输入上的反例。53小时运行说明这次搜索的墙钟时间;没有完整的人力和模型消融,不能把它解释成普遍替代同等研究时间的倍数。

依据 1 · 依据 2 · 依据 3

值得读评测与基准 / 多模态 / 训练与对齐
追踪记录 ↗

OmniVerifier-C1 把图像要求拆开计分;规则任务再提供参考终态

技术Visual VerificationDecomposed RewardsReference-based Evaluation
可信度
65
重要性
76
新颖度
75

图像里颜色正确、位置错误,如果只给“全对或全错”的奖励,训练很难知道哪一步改善了。OmniVerifier-C1 是一个视觉检查模型:先把文字要求或环境规则拆成子问题,逐个判断,再将满足比例汇成连续分数。训练同时约束局部判断和整体评分,避免模型只猜对一个总标签。

它区分两种检查方式。普通文生图通常没有唯一正确图像,因此按要求逐项评分;在迷宫、4×4数独等规则任务中,作者额外提供正确终态图,让检查者直接比较生成结果与参考,省去自己先推导目标的步骤。这里的 pairwise 是“候选与参考状态”的比较,并非两张任意候选图的偏好投票。

以 Stable Diffusion 3.5 Medium 为例,200步强化学习后,GenEval 的组合要求得分从二元奖励方案的0.68到分解奖励的0.77;FLUX.1-dev 对应为0.70到0.79。规则任务也报告参考比较更稳定。实验使用16张 A800;它目前支持的是明确规则和可得参考的受控场景,还没有把开放现实环境都变成可验证问题。

作者训练流程:先学子问题判断与总评分,再用检查器训练生成模型;参考终态仅在可取得时加入。Liu 等 · arXiv:2610.22355v1,图2 · 原文图表 · 图片出处 ↗

编辑评读

将部分正确保留下来是一个合理的训练改进:两个都没全对的图像,可能已经满足完全不同数量的条件,全部归零会丢掉排序信息。但论文关于理想排序的论证,先假设要求能够无损拆解、子问题能正确判定,并以满足项数定义质量。实际分解若漏掉一个关键关系,平均分仍可能上涨;“小错很多”与“一项致命错误”也未必适合等权合成。理论说明了更细反馈的潜力,没有自动验证分解器本身。

参考终态的收益也应归到它真正省掉的工作:目标状态推导。对于能从规则得到明确答案的数独,这是很强的监督;对于多条合法路径的迷宫或开放画面,则要辨认参考代表唯一状态,还是一种有效解。作者已把非唯一真值列为未来工作。因此我会先测“参考不同但都合法”的配对样本,再决定它适合训练进度奖励,还是能承担严格验收。项目讨论区找到的旧加载问题针对前代模型,不能移植为 C1 的失败报告。

依据 1 · 依据 2

值得读评测与基准 / 基础模型
追踪记录 ↗

SAE 重建表现接近,学到的特征仍可能对不上

技术Sparse AutoencodersFeature ReproducibilityActivation Sampling
可信度
65
重要性
73
新颖度
74

稀疏自编码器(SAE)尝试把语言模型一层的激活拆成少数可解释特征,再用这些特征重建原激活。研究者常投入数亿条激活训练,但“重建后模型行为相近”和“再次训练得到同一个特征”是两个目标。这篇研究比较三种语言模型、四类 SAE,将500M激活参考与5M、25M、50M的较小预算对照,并比较随机抽样与优先覆盖差异较大样本的最远点抽样。

作者发现,重建等多项功能指标用较少数据就能接近参考,其他指标并不随数据单调变好。若要确认特征相同,则分别匹配编码器与解码器方向,要求它们指向同一个参考特征,且两侧余弦相似度均超过0.7。这个严格标准下,Gemma-2-2B 的 BatchTopK 从5M预算的2.20%共享特征增至50M的28.86%。

抽样也存在取舍:随机抽样更能保留原激活分布,通常更利于重建;多样性抽样常改善自动解释评分,却会偏向范数较大的激活。结论是按研究目标选择数据预算;不能把少量数据够做一种评测,推广成已经稳定找到了模型内部的同一组机制。

Gemma-2-2B、16k BatchTopK 的功能指标随激活预算变化;各子图纵轴不同,不能把柱高当成统一提升幅度。Ghosh 等 · arXiv:2610.20680v1,图1 · 原文图表 · 图片出处 ↗

编辑评读

这篇工作的贡献是把“便宜地重建”与“把某个潜变量当作科学对象”分开。若任务只是近似保留输入输出表现,两个字典不同未必是缺陷;若要比较某个特征跨训练的因果作用,连指向都不稳定就会影响解释。昨天讨论原生神经元是否清晰,今天的结果也不能直接裁决它:SAE 是额外训练出的表示,字典可重复性和原网络自身结构并非同一命题。

我会对共享特征百分比保持一个具体疑问:分母里的500M参考本身有多稳定?本次读到的表格以它为参照,不等于已知它是唯一正确字典。再训练两个同预算参考,才有机会区分“数据不足”与“不同训练路径本来就有多种解”。原文的理论也需要可辨识性和优化一致性条件,所以不能用渐近结论把这个问题跳过去。同时,更多数据没有让所有功能指标更好,是值得保留的负结果,足以支持按目的分配预算,而非只向最大规模看齐。

依据 1

值得读Agent 系统 / 系统与效率
追踪记录 ↗

Kimi K3 的 AMD 推理优化:缓存要能在同一位置恢复

技术Prefix CachingHybrid AttentionGPU Kernel FusionSpeculative Decoding
可信度
65
重要性
80
新颖度
75

多轮编程 Agent 会重复发送很长的历史,服务端能否复用这些计算,往往比纸面矩阵算力更影响吞吐。Kimi K3 同时有保存压缩历史的 MLA 注意力,以及携带固定大小递归状态的 KDA 层;恢复请求时,两种状态必须停在兼容的位置。文章举例:MLA 已缓存到3072个 token,KDA 检查点却只到2048,仍要从2048继续重算,而非直接接上最后一段。

团队在 vLLM 推理服务框架的 AMD 路径上分散跨卡历史缓存,复用已有通信来去掉重复专家计算,融合内核并删除没有消费者的拷贝。它还把较短的投机验证任务切成更多小工作组,让 GPU 能同时执行足够多的工作。投机解码是先草拟若干 token 再由主模型检查;草稿更长只有在整个循环的时间增幅较小时才划算。

博客采用10月9日的 AgentX 快照:两套八卡完整服务栈在90分位 token 间延迟折算为每用户50 token/s的条件下,MI355X 每卡总吞吐约7567,B300约6083,高24.4%。总 token 包含复用输入,速度口径不含首 token 等待;每美元优势另依赖所有权成本模型。这不是所有真实任务的输出速度或费用比例。

作者示意:MLA缓存到3072而KDA兼容状态只到2048时,需重算1024个位置。数字是解释机制的例子,不是性能实测。AMD、Embedded LLM · vLLM Blog 原文SVG,3倍像素渲染 · 原文示意图 · 图片出处 ↗

edwingao28 · 原帖 / 原文

语境:2026年7月、旧vLLM镜像的MI355X/DSpark故障报告;不是对10月文章版本的重测。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他先确认推荐配置能完成启动和预热,随后补报长上下文分析阶段仍崩溃:两台机器分别在约337K和339K已计算token附近出现硬件异常,缓存占用约16%。他据此认为短请求或预热成功不能说明长轨迹可用,并请求进一步调试建议。

编辑评读

“缓存命中”看起来只是是否有旧数据,但混合架构增加了一个恢复一致性的条件:所有相关层都要能从同一位置继续。这个例子比再报一次压缩比例更有工程含义,因为存下来的字节若不能直接复用,仍要花计算恢复。它也解释了为什么应测整次请求,而不能把多个独立内核实验的百分比相加。

外部检查需要保留时间和版本。InferenceX 当前页已经显示10月14至15日的更新运行,50 token/s目标下数字也不同;那不是博客10月9日比较的第二次独立确认。另读到的7月问题 #50347,先以为启动成功就修好,随后约337K上下文又在两台设备复现失败。这个旧案例支持“长轨迹要单测”,却不证明10月栈仍有同样错误。下一步应在固定镜像、相同会话和完成比例下比较冷缓存、暖缓存、首 token 等待与实际输出质量,尤其不要把合成接受率当成模型对真实文本的表现。

依据 1 · 依据 2 · 依据 3

VOICES & EXPERIENCE

观点与经验

02
值得读Agent 系统 / AI 编程 / 评测与基准
追踪记录 ↗

审查机器人也要会停:Claude Code 团队把误报和循环轮数纳入评估

技术Automated Code ReviewRegression TestingRisk-based Approval
可信度
65
重要性
84
新颖度
76

当 Agent 能连续提交改动,逐行人工审查很容易形成队列。Claude Code 团队介绍的流程是:提交前先运行测试、构建并由新上下文检查;PR 上分别进行缺陷与安全审查;按照改动风险决定需要多少人批准,再通过合并队列、分阶段发布和回滚控制后果。PR 即提交给团队讨论与合并的一组代码改动。这里的自动检查不代替规定的人类批准。

团队还遇到自动审查自身制造的忙碌:一条改动一夜经历五十多轮检查和修复,后来发现约59%的反复发现原本就在代码里。于是给轮数设限,后续集中看新差异,要求一次指出整类问题,并避免重复报告。同批内部前后统计中,平均通过所需审查从2.08轮降到1.32轮。

怎样确认只是少折腾,而非漏查?作者将历史事故和回滚做成每日评测,还检查已知干净的 PR,数清评论是否会诱使人作出有害修改。效果报告来自自家仓库,尚不足以证明相同流程在别的团队同样省人力。

Addy Osmani、Morgan Westlee Lunt、Qing Wang · 原帖 / 原文

语境:原作者描述内部审查迭代;下面是一句实际原文及译文。 · 读取时间:2026-10-17T00:11:19.921551+00:00

中文译文 · 点击句子切换原文

status_quo69 · 原帖 / 原文

语境:针对同一团队文章里按需生成代码解释的安排;属于阅读分析与担忧。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他质疑文章是否真正处理了共享代码知识这个问题:如果只在需要时让模型搜索并解释一个局部,得到的信息仍取决于这次搜索的质量;这不等于人已经形成了对系统的理解。他没有提供该团队因此发生故障的独立证据。

csallen · 原帖 / 原文

语境:同串回应系统无人理解的担忧;表述来自个人经验。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他认为测试和版本历史允许回滚后调查,也认为模型通常能解释自己生成的代码。他说自己的使用中,Claude 会建议把复杂问题拆小;有经验的工程师也会谨慎处理重要代码。这些是他的经验判断,不能作为每次恢复都会成功的保证。

编辑评读

这份材料最值得保留的正面证据,是它没有把“发现更多问题”当成唯一目标。Agent 往往会把轻微建议也落实成修改,一次噪声能触发新提交和新一轮审查。因而控制误报不只是提高评论观感,而是减少系统主动制造的新工作。已知干净的改动和诱发有害修改的计数,补上了只用事故集测召回的盲区。

但是风险分层把判断转移到了另一处:分类器漏判敏感改动,会让后续流程走上较轻的路径。仓库路径规则、明确保留的人类批准和回滚条件才是这个方案的完整上下文。不能把其效果摘出来推广成“代码都可无人审”。HN 的 status_quo69 追问团队怎样保有系统理解,csallen 则认为测试、版本记录与解释能力有助恢复。真正能分辨这两种期待的,是陌生故障发生时谁能找到正确范围、多久定位,以及是否留下不可逆后果。原文的前后统计没有单独识别这些因素。

依据 1 · 依据 2 · 依据 3

值得读AI 编程 / 评测与基准
追踪记录 ↗

Piotr Sarnacki 重测聊天应用改写:送达率上升,也可能只是排队更久

技术BackpressureOpen-loop Load TestingTail Latency
可信度
65
重要性
72
新颖度
54

这篇10月11日的旧文因本周热点再次进入候选。背景是 Campfire 聊天应用被 AI 改写成不同语言后,人们用吞吐或消息送达率判断哪种实现更好。Sarnacki 指出,各版连兼容性和队列策略都不一致,因此性能差异不能直接归到语言。

他进一步把压测从“收到响应再发下一条”的闭环方式,改为固定到达率:外部请求不会因服务变慢而自动放缓。在每秒100次写入请求(POST) 的个人测试中,Rust 版事件送达较少,但没有 HTTP 错误;修正后的 Elixir 版送达较多,同时出现超时和很长尾延迟。作者再改 Rust 广播队列容量,从256增至16384,事件送达率由约14%升至约90%,最坏延迟却由11秒升至130秒以上。

因此他没有宣布 Rust 反超。对聊天客户端,尽快断开落后的连接、重连后拉取最新状态,有时比把事件留在队列等数分钟更合适。背压就是系统在处理不过来时怎样限制、排队或拒绝新增工作;每种选择都要结合用户实际能否看到消息判断。

Piotr Sarnacki · 原帖 / 原文

语境:10月11日个人复测与工程意见,版本及负载限定见正文。 · 读取时间:2026-10-17T00:11:19.921551+00:00

逐句忠实转述(非原文)

他不认同按一次送达率判断语言的优劣。加大队列后Rust的送达率更高,他仍认为该版本可能更糟,因为它让滞后的事件等得太久。他更倾向及时暴露失败,并让浏览器重连拉取更新;同时提醒,无边界的队列最终也会遇到内存限制。

nicfio · 原帖 / 原文

语境:回应同一旧文的HN讨论,提出多模型对抗开发;未给出受控比较。 · 读取时间:2026-10-17T00:15:12.570417+00:00

逐句忠实转述(非原文)

他认为问题也在使用方式:不同模型可能以不同方式推理和犯错,因此建议用至少两个前沿模型相互检验,人再检查输出。他承认不能完全消除错误,并把额外模型费用看作质量投入。这是方案主张,不是已经测出误差独立或最低错误率。

wpld · 原帖 / 原文

语境:同一文章的Lobsters讨论,2026-10-12的个人成功案例;不同项目,不是Campfire复现。 · 读取时间:2026-10-17T00:15:12.570417+00:00

逐句忠实转述(非原文)

他报告自己用claude-code把一个小型Spring Boot应用的前端从Angular改到Vue,API不变,不让工具接触真实数据,并逐步检查输出;Selenium在Firefox的集成测试之外,Chromium仍有日期输入小问题。他认为原先对预期行为和测试的掌握有助于这次改写。

编辑评读

这份复测的好处,是一个容量改动就让同一实现呈现出两种“胜利故事”。送达率上涨可能有价值,但若读者正在等通知,延迟代价不能藏在成功分子背后。闭环与固定到达率各有用途:前者适合固定客户端并发的行为,后者能暴露外部工作持续到来时的积压。选错负载会使系统自动替测试减压,从而漏掉本来关心的故障。

不过这仍是作者在特定改写版本上的个人试验。我们没有重跑其负载,也不把具体比例变成语言优劣结论。最值得借用的是反例构造方式:保持实现基本不变,改变一项资源限制,检查“更成功”是否只是把失败推迟到别处。它与自动审查的关系也很具体:积压的通知和没完的修复都可能把即时进度变成后续等待;共同点是要测终点体验,机制本身不同。

Lobsters 的 wpld 提供了应保留的成功反例:应用较小、API不变、原作者知道原有行为,又逐步检查和运行集成测试。它不能推翻聊天系统里的积压问题,却说明“使用Agent改写”不是足以解释失败的单一变量。另一位 nicfio 建议不同模型互查,但模型不同只提出了潜在的错误差异,还需实测是否互补;不能把增加一个角色直接换算为降低了多少风险。

依据 1 · 依据 2 · 依据 3

LEARN BY DOING

技能学习

每天 1–2 份实践材料

博客 · 项目实践 · Alex Wang

从串扰理解线性层、MLP与注意力的记忆视角

技术Associative MemorySelf-AttentionMLP

从存入键值对后为何互相干扰,逐步推导线性存储、非线性门控和注意力;适合把熟悉的网络模块放到同一问题下理解。

会矩阵乘法、内积与最小二乘的读者。 · 编辑建议:45–75分钟,先读线性存储,再比较非线性门控。

动手试试:自行生成64维随机单位键,逐步增加键值对,比较外积存储和最小二乘的检索误差;再把键改成相关向量,检查原文随机假设失效时会怎样。

CONNECT THE DOTS

把几件事放在一起看

编辑观察
追踪记录 ↗01

重建生成规则之后,选择历史仍可能不可见

参数有了来历,研究就确实前进了一步。ECDSA 曲线种子原先只是标准里的十六进制串,现在可以把生成器状态、时间戳和迭代位置连起来核对。[1][2] 这比一种听起来合理的历史故事更强,因为每个细节都可能对不上。可一旦问题改成“为什么最后选中了它”,同一份结果又显得不够:重建出一条路径,没有告诉我们此前还试过多少条路径。

这不是替后门假设制造证据。原文同时写了两个事实:P-256 的第1842个候选对应公布参数,更早的第876个候选也满足其所列条件;作者不知道跳过的原因。[1] HN 的 fidotron 据此保留选择自由度的疑问,matthewdgreen 则反驳,小规模搜索若能碰到弱曲线,弱曲线必须多到成为整个体系的问题。[3][4] 数值重建可以被共享,关于未知选择历史的解释却依赖额外假设。把这两层分开,才能既承认发现,也不把尚未获得的史料提前写完。

量子电路研究提供了一个不同的对照。它同样反复生成和筛选候选,但筛选目标是预先说明的行为与资源代价。尤其值得读的是允许有界失败的解码器:为极少出现的例外值预留大量量子比特,成本很高;作者利用任务允许的错误预算,只保留很小储备。[5][6] 这不是“检查器没有发现错误”的同义说法,而是对哪些输入允许失败、愿意付出多少资源作出明确承诺。生成器更善于搜索以后,这种承诺就更重要,因为它会找到过去很少有人认真尝试的取舍。

两份工作并没有同一个信任问题。密码参数溯源追问不可回去观察的历史,电路搜索研究未来怎样运行一个实现;一次匹配和一份误差预算不能彼此证明。但它们给出的共同启发是,验收时要把数值对应、允许条件与选择过程放在不同位置。对当前电路,可以要求在相同误差门槛下重新比较;对历史种子,缺失的弃选记录则不能靠多跑几遍现有生成器补出来。这也限制了复现的承诺:重复得到相同输出,不必然识别了产生它的唯一过程。

我会把后续问题留得更具体:是否出现当年的筛选标准、更多恢复的基点或B-163解释;量子电路则检查相同失败预算、不同输入分布下的资源前沿和反例。若多个不同规则都能重建现有种子,它会削弱对唯一历史路径的判断;若有公开史料解释跳过候选,才会真正减少选择过程的空白。这些是编辑提出的区分办法,本期尚未拿到相应新记录。保留空白既不否认可核对的成果,也不把合理怀疑升级为发现攻击。

简单生成器与少量跳过候选也可能完全来自普通实现细节;多次搜索与有意选择则同样不能仅由最终参数排除。

追踪原始筛选史料、B-163和未解释基点;在相同允许错误率下复核量子资源比较。

相关条目:时钟生成了曲线种子,仍有候选跳过的原因未明 / Claude 重设计量子电路:少存历史,也显式使用失败预算

来源 1 · 来源 2 · 来源 3 · 来源 4 · 来源 5 · 来源 6

追踪记录 ↗02

让审查器见到干净改动,也量出停止修改的代价

上期观察发现,Cortex 没保留有害规则,有时只是因为规则没被读到,或回放主要集中在原先就失败的任务;没有保留不能直接当成识别伤害。[1] 今天回读原论文,相关限制仍在,尚未见这一实验被新版本修正。Claude Code 团队的审查文章补充了一个正面办法:除了回放事故,也在已知干净的 PR 上运行审查器,检查它会不会建议有害改动。[2] 这支持把“原先成功”放进测量,但没有解决 Cortex 自身的证据缺口。

这样做会改变优化的目标。若只奖励发现历史事故,增加评论往往容易显得更好;在干净改动上,新增评论也可能消耗人的判断,或者让 Agent 立即改掉本来正确的东西。作者记录过五十多轮自动审查,问题不只是慢,而是每轮都能找到一些旧问题,使停止看起来像不负责任。[2] 把复查集中到新增差异、禁止重复报告,可以限制这个过程。不过,轮数下降只能说明流程收敛更快,要称为改善,还得保持真实缺陷的召回和最终质量。

Sarnacki 对聊天应用的复测,提供的是另一种机制的反例。[3] 他扩大队列后,送达率更高,最坏等待却长了许多;因此没有把高送达率自动解释成更好体验。审查队列不是消息队列,两者不能互相证明性能,但共同提醒我们检查“成功”发生在哪个时点。一个系统可以把失败藏进等待,另一个可以把审查噪声藏进新一轮修复。即时看更忙、更多通过,最终可用结果却可能没有增加。

据此,我会将审查器的比较分成三项:确认问题的能力、诱发新修改的代价、以及遇到变化后的恢复能力。前两项可用固定的事故与干净改动配对记录:同一检查是否读到相关代码,发现是否成立,建议是否导致回归,经过多少轮和多少人力后收敛。第三项要保留新的故障,而非不断在同一回放集上调到满分;否则最初有用的事故库也可能成为被熟记的题目。这是从现有实践推出的实验要求,不是作者已经公开完成的跨团队对照。

反例仍然重要:高风险改动多花几轮检查可能完全划算,不能为追求快速收敛而一律截短;干净 PR 的标签也可能错,把真实缺陷算成误报。[2] 因而本次修正的是旧判断的测量办法,而不是宣布一套审查流程最优。将规则曝光、事故召回、干净样本上的有害建议和最终返工同时留下,才更容易判断哪一次“没改”是克制,哪一次只是漏看。原定10月18日还要继续查 Cortex、MASS 与 DeRef 的新证据,不因今天找到相邻正面案例而延期。

收敛改善可能同时来自改动更小、模型升级、风险分层与团队经验;前后比较没有隔离各项贡献,干净标签也可能有误。

在独立新事故与原先成功的改动上同时测错收、误拒、有害修改、轮数、人力时间及最终回归;核对Cortex后续修订。

相关条目:审查机器人也要会停:Claude Code 团队把误报和循环轮数纳入评估 / Piotr Sarnacki 重测聊天应用改写:送达率上升,也可能只是排队更久

来源 1 · 来源 2 · 来源 3