今天这几帖凑在一起，说的其实是同一件事的不同侧面：当一件事的成本掉到接近于零，真正的约束就换了个位置。RL 训练的收益集中在极少数几个岔路口，写代码的时间省下来了但估工期反而更难了，堆功能变得廉价之后堆功能就不再是护城河，查一次车牌几乎不要钱于是查询本身失控了。省下来的部分不会自己变成价值，它只是把账单挪到了别处。
论文称强化学习只改动了 1~3% 的 token，用 1/1000 的算力就能复现
r/LocalLLaMA 上热度最高的是一篇 arXiv 论文（2605.06241）。作者在多个模型家族和多种 RL 算法上做 token 级别的对比，结论是：RL 带给推理能力的好处，是一种稀疏且可预测的修正，集中发生在模型不确定该往哪个分支走的高熵决策点上；只有 1~3% 的 token 位置真的被改动了，而且被抬上来的那个 token 几乎总在基座模型自己的 top-5 候选里。既然如此，他们干脆绕开 RL，用大约千分之一的算力复现了同等增益。
评论区分成挑刺和补证据两派，而且两边都挺硬。挑刺最狠的一条直接冲着「总在 top-5 里」这句话去：高熵分布下 top-10 的概率经常几乎相等，跑足够多样本一定能找到反例，说「always」纯属吹牛。紧接着有人翻到论文后面的表格回了一句——Qwen2.5-7B 上是 99.99%，为一个词就掀桌子有点早。另一条更实在的质疑来自方法论：主要测的是那些本来就做过 RL、或者众所周知在 RL 上有毛病的模型，拿 Qwen 2.5 7B math 当主力被认为是「只在几个怪模型上成立」的信号，而且基准只有数学题，跟 RL 实际被用到的那些任务不是一回事。
“I find it completely impossible to believe that tokens promoted by RL always lie within the top-5 as claimed here. There’s absolutely no way this is true.”
— u/-p-e-w-，原帖评论
“According to a table further on in the paper 99.99% in the top-5 for Qwen2.5-7B. Falling over one word is always a little premature.”
— u/PinkysBrein，原帖评论
补证据的那一派把论文引言里的文献综述拎了出来：这个方向其实已经有一串工作在指向同一结论——RL 提升的是 pass@1，但基座模型在大 K 的 pass@k 上反而更高，说明正确解本来就在采样分布里，RL 只是把它提上来；也有人证明过二元奖励的那几种 RL 算法本质上都退化成对「答对概率」的某种单调变换做随机梯度上升，只有当基座模型已经能非平凡地答对时才划算。还有一条冷静的提醒被顶得很高：这里省下来的是训练算力，不是推理算力，别指望它让你手上的显卡跑得更快。串起这些之后，热闹里最有意思的一条其实是在谈别的——语言模型里 token 数量和难度几乎不相关，「我走到了一个岔路口，我应该往」这十几个 token 全是废话，真正承载整个决策的是下一个「左」或「右」，而算力在这两者上花得一样多。
我觉得这条讨论比论文本身更值得读。如果 RL 的作用真的只是在为数不多的岔路口上把第二名换成第一名，那「推理能力」这件事在工程上就更像是一个采样与选择问题，而不是一个需要天量算力去重新雕刻权重的问题。对国内做后训练的团队来说，这至少提示了一个便宜的实验：先量一量你的 RL 到底动了多少个 token 位置、动的是不是都在高熵点上，再决定要不要继续烧那份算力。
AI 时代还怎么估工期：一个 9 年老兵的困惑
发帖人在一家大厂做了九年，好不容易练出了估算的手感——初始估算乘 1.5、扣掉被杂事吃掉的比例、给测试留 buffer。现在这套全废了。团队接了个「半年期」项目，上面压着要一个半月交出核心。他没有硬顶回去，而是花了一天时间给 agent 写好设计、约束和调研，周五扔过去要一个跑得起来的 demo，中途只纠正了三次，周末就拿到了成品——而这块活团队原本估的是三个人两周。他自己也清楚这离上线还差得远：安全、性能、真实数据接入一样没做。问题是，当最耗时的那部分变成了近乎免费，另一部分却纹丝不动，这两块该怎么加权？
评论区最漂亮的回答不是技巧，而是一句重新定义问题的话：AI 改变的不是你的均值，是你的方差。那些已知的、无聊的活变得基本免费，未知的活一点没变；于是原本均匀摊在整个任务上的风险，现在全都挤到了你还看不见的那几个点上——这正是「乘以 1.5」失效的原因，因为那个乘数成立的前提是不确定性被均匀涂抹在所有工作上。另一条高赞则更直接：代码生成从来就不是瓶颈，而 agent 干的恰好就是代码生成；理解问题、搞清楚它怎么塞进现有代码库、为将来的变化做架构，这些才是时间的去处。这位还给了套实战话术：不硬顶，改成「我们可以用 agent 加快编码，但前提是先有一份完整的 spec」，或者「可以更小步地迭代交付价值，但那部分就没法那么 AI 驱动」。
“The thing AI actually changed is not your average, it is your variance. It made all the known, boring work basically free and did nothing to the unknown work.”
— u/kaushalrola，原帖评论
“Code generation was never the bottleneck, and agents are doing code generation.”
— u/TheTacoInquisition，原帖评论
其余的建议五花八门但各有各的道理。有人主张彻底放弃估算，改用看板的 cycle time 和吞吐量来推算 epic 需要多久，前提是把故事拆到不能再拆、并且有一套完整的 feature toggle 体系；有人建议给每个估算附一个 1 到 10 的置信度，第一次报永远是 5，等把开放问题聊到 8 分再开工；还有人提议干脆给两个估算——一个正常质量可维护的，一个 AI 快糙猛的，让业务方自己选。发帖人对最后这条的回应很真实：他们一定会选第二个，然后在应用不稳定的时候来怪工程师。也有人当场质疑他那个 demo 的成色，他倒是坦率——那就是个用完即弃的东西，目的是消除歧义、把系统设计放到一个小样本上压一压，顺便让没有产品经理的团队早点看到真实交互，能跑的应用总比线框图强。
对国内团队来说，最值得抄走的是那句「方差」。以前排期表里的缓冲是给整体不确定性留的，现在应该明确地留给集成、真实数据和安全这三块——它们不但没变快，还因为前面那 80% 来得太快而显得格外突兀。顺便说一句，用两周的预算换来一个三天就跑通、且明确准备扔掉的原型，本身就是笔划算的买卖，只要别把它当成生产系统的地基。
「我们团队到底哪儿出了问题」：对手是一个不懂技术的 vibe coder
一位 7 年经验的工程师在软件外包公司，7 个人的团队同时做 3 个客户的项目。他现在也重度用 AI，有自己的一套验证流程，仓库里有 gold standard 的那类功能能一次成型。让他难受的是竞争对手：一个甚至不在 IT 行业的人，靠 vibe coding 往自己的应用里猛塞功能，功能都很简单也很不完整，但市场就是买账。管理层震怒——你们一群工程师产出居然比不过那个人。他提议先把功能做成阉割版上线再慢慢补，得到的回复是：人家已经有了，所以我们要有更多。他真心在问：是不是我们哪里做错了，是不是干脆别看代码了。
评论区几乎一边倒地告诉他：问题不在工程，在管理层把「能出功能」当成了价值本身。最狠的一条指出，如果你的护城河退化成「谁上功能快」，那你就没有护城河了——agent 把写软件的能力扩散到所有人手上之后，这条河已经被填平了。另一条更冷静：产品管理同时想要「功能全」和「每个功能都成熟」，这两件事不兼容，他们得自己选一个。也有人从历史里找参照：这场争论跟当年「找便宜外包快速堆功能」的争论是同一场，很多公司试过，然后发现几年后的技术债更贵；当然也有公司就这么凑合着活得挺好。还有人给了个略带幸灾乐祸的建议——等对手的意大利面代码把他自己缠住、几个客户就耗光他全部时间的时候，你的机会就来了。
“It turns out being able to produce features was never inherently valuable. Thinking it is will kill your business.”
— u/TheOwlHypothesis，原帖评论
最让人心里一沉的是另一条。一位同处类似环境、原本非常在意架构和整洁代码的工程师说，他已经放弃了：现在就是把管理层要的东西一路狂奔做完，扫一眼就点合并，反正最终一定会走到那个显而易见的结局——一堆没人看得懂的、动弹不得的软件。他说自己现在只是为了那份工资待在这儿，本来不想变成这样。
“I hate to say it but I’ve given up and am just speed running whatever management wants and just clicking merge with a cursory glance.”
— u/Ok_Reaction_4340，原帖评论
这一帖和上一帖其实是同一枚硬币的两面：上一帖问的是「省下来的时间怎么算进排期」，这一帖问的是「省下来的时间被拿去干了什么」。答案往往是拿去堆更多功能，而不是拿去做更少但更对的事。真正可操作的部分在于把讨论从工程拉回业务：那些缺的功能到底跟收入有没有关系，老功能能不能下线，客户对质量的容忍度到底在哪一档。如果这些问题没人回答，加班堆出来的功能数量永远追不上一个不看代码的人。
美国车主现在能查到自己的车牌被警察搜过多少次
Flock 是美国铺得最广的车牌识别摄像头厂商，警方每查询一次都要在系统里填写「查询理由」。现在有人把 6,586 个执法机构的审计日志汇总成了一个网站，输入车牌就能看到自己被搜过几次、每次填的理由是什么。这条帖子在 r/technology 上炸开，很大程度上是因为大家真的去查了。
评论区最有分量的内容是亲历者。一位用户说自己被两个警察搜过：一个在几分钟内查了他 14 次，理由填的是「犯罪」；另一个在几小时内查了 17 次，理由是「毒品」——两次都发生在他去上班的路上，下午一点。别人追问「犯罪」和「毒品」是什么意思，回答是：那个「查询理由」栏就是个自由填空，警察填的都是没有任何细节和指向的通用词。还有人补了一句更黑色幽默的观察：词云上占比最大的那个「理由」，是空白。
“I’ve been flocked by two cops. One used flock to look me up 14 times in the span of a few minutes…”
— u/tanneruwu，原帖评论
“There’s a “reason for request” field they have to fill when doing a search in the database. They’re using generic reasons without detail or specificity”
— u/somuchbacon，原帖评论
另一条讨论线是关于这个查询网站本身安不安全，吵得挺凶。反对的人认为你输入车牌这个动作本身就是在给自己贴标签，IP、设备、车牌一关联，将来「反对监控的人」名单现成就有了。支持的一方说这是典型的 Reddit 式被害妄想：车牌是全美最容易买到的个人信息之一，站点由非营利机构运营且声明不留存数据，真正该担心的是每一次 Flock 查询本身。也有人提出了那个绕不开的问题——你信任的是现在的运营者，那未来的所有者呢？此外还有一条提醒了误报的代价：曾有车辆被 Flock 判定为失窃，原因只是车牌号跟另一个州一辆失窃摩托车重号，结果一位母亲带着孩子被从车里拽了出来。
“There was a thing just recently where Flock flagged a vehicle as stolen, because the plate matched a stolen vehicle - but the stolen vehicle was a motorcycle from a different state, and the mom and her kids got dragged out of their car over it.”
— u/demonfoo，原帖评论
值得注意的是，Flock 这套系统在设计上其实是「有约束」的：每次查询都要填理由，全部动作都记审计日志。问题在于，只要理由栏是自由文本、没人事后核对，约束就退化成了摆设——直到有人把审计日志公开出来，才让摆设重新长出牙齿。这里对中文读者的启发倒不在于美国警察，而在于一个普遍的设计原则：任何权限系统里，「记录了什么」远不如「谁在事后看这些记录」重要。日志的价值不来自它被写下来，而来自它会被读。
一个小手艺：先写 typing.Protocol，再写满足它的类
r/Python 上一位开发者分享了自己的习惯：当他要把一个实现从一堆调用点后面抽出来时，先写 typing.Protocol，再写满足它的类。先把接缝定义出来，用它去标注所有调用点，跑一遍 mypy，于是所有形状不对的地方在新代码写出来之前就全暴露了。他的理由挺 Python 特有：鸭子类型意味着隐式接口就是调用方碰巧用到的那些东西，散落在若干文件里，压根没东西可供评审；把它写下来，同事才有一个能读、能反对的对象。他也诚实地列了缺点——这一切在运行期毫无约束力，PEP 544 不施加任何运行时语义，即使加了 runtime_checkable，isinstance 也只检查属性名存在，不检查签名；而且没有任何机制强迫 Protocol 跟着实现一起改，两者会漂移。
这帖回复不多但都在点子上。最直接的一条反问：如果满足协议的类是在协议之后才写的，这多半是在误用 Protocol——那种情况写个基类不就完了？Protocol 存在的意义是覆盖那些你改不了的类，比如标准库里的类型。另一条则从 Go 的实践给了答案（针对原帖最后那个问题：Protocol 该放在消费方还是实现方旁边）：放消费方，这是 Go 里 DDD 风格的通行做法，也意味着通常不该去继承这个 Protocol。还有人泼了盆冷水：这么搞很容易陷入「为了将来可能的扩展而不停造新 Protocol」的螺旋，一个 SettingsFetcher 引出一个 HTTPClient，再引出一个 SecretClient——底下立刻有人接了句「这听着像 Java」。
“If the class that satisfies the protocol is written after the protocol, then this is probably a misuse of protocols. Why not just write a base class instead?”
— u/NeilGirdhar，原帖评论
“Consumer, but that’s cause it’s the common practice in Go, DDD style. This also means you generally don’t inherit from the Protocol.”
— u/flangust，原帖评论
顺带一提，原帖中间插了一句自家工具的软广，读起来有点营销味，不过这不影响那个手艺本身的价值。放在今天这组帖子里看，它反而是个有意思的对照：写代码这件事已经便宜到不值得省了，真正稀缺的是「把打算怎么做写成一段别人能反对的文字」。先写 Protocol 之所以有用，不是因为 mypy 能多抓几个错，而是因为它把一个原本只存在于你脑子里的接口，变成了一个可以被同事在动工前拍砖的东西——这跟上面那位工程师说的「用 agent 加速前先要有完整的 spec」，其实是同一个道理。