今天这几帖有个共同的暗线：都在算「省掉的那一步」的账。省掉自己写 150 行代码，换来的是一条你根本没写进 Cargo.toml 的传递依赖把你的构建投了毒；省掉理解和测试的时间，换来的是下一次故障；省掉把问题想清楚的过程，换来的是一个你看不懂也不敢改的实现。有意思的是，说这些话的人没一个是技术保守派——他们大多每天都在用 AI、每天都在装依赖，只是被账单教育过。
一个 150 行的 crate 掀翻了半个图形生态，于是有人重提 Ctrl-C Ctrl-V
u/grg994 发了一条不算长的提醒：几十年前那种「把别人的代码抄进自己项目，附一行注释写明出处和许可证」的做法，其实一直有效，而且现在可能又该拿出来用了。触发他这么想的是最近被投毒的 arrayref——一个不含注释和测试只有约 150 行、提供 4 个宏、两年没有任何改进的包，却顺着依赖链把 winit 和 wgpu 一起拖下水。他强调这不适用于大型依赖，只是想让大家在 cargo add 之前多问自己一句：这段代码是不是几下 Ctrl-C Ctrl-V 就能解决？
“The recently compromised arrayref was a single file, (without comments and tests) 150 lines of code crate, containing 4 public macros, seeing no improvements since 2 years - and managed to indirectly subvert winit and wgpu.”
— u/grg994（原帖作者），原帖
第一条高赞回复很自然：那你锁版本不就行了，写成 arrayref = "=1.2.3"。楼主的反驳是整个帖子里技术含量最高的一段——等号只锁住直接依赖，锁不住依赖的依赖。你的 crate 死锁 alpha 1.2.3，可 alpha 自己写的是 beta = "0.1.2"，那么 beta 发布带毒的 0.1.3 之后，一次 cargo update 照样把它拉进来。有人接着问：Cargo.lock 不是存了每个传递依赖的内容哈希吗？u/A1oso 解释了那个微妙之处：lock 文件只保护你已经解析出来的那份快照，下一次新增依赖重新求解时，看的仍然是 Cargo.toml 里的版本区间。
想把整棵树钉死当然可以，代价是所有依赖也得跟着钉死，而 Cargo 只允许同一个包的不同大版本共存、不允许两个不兼容的精确小版本共存——u/SkiFire13 补了一句大实话：真那么干，祝你有本事把任何一个非玩具项目编译出来。也有人指出，抄代码和锁版本在这件事上其实同构：
“Either it’s a package without deps. Then using an
=dep is equivalent to copying code, with the small caveat that you may end up with dep conflicts in the presence of other deps using the same crate.”— u/Manishearth，原帖评论
反方的意见同样成立：依赖总要更新，更新时你凭什么判断它没被动手脚？抄进来的代码同样有这个问题，只是把责任从工具转移到了人。评论区最后收敛出的最优解不是抄也不是钉，而是一个更朴素的东西：
“The better way is to use a minimum release age, which is coming to cargo soon.”
— u/DrLuckyLuke，原帖评论
最小发布年龄——只用发布满 N 天的版本。绝大多数投毒事件在几小时到几天内就会被发现并下架，靠时间差就能挡掉。这个思路值得国内团队直接抄：npm、pip、Maven 私服都能用镜像同步延迟实现类似效果，成本几乎为零，比让每个人去审计 diff 现实得多。另外楼主那句「先问自己能不能抄」也有个副作用是好的——它逼你真的看一眼那 150 行代码。很多依赖之所以危险，恰恰是因为从来没人看过里面写了什么。
上午 11 点半派活，下午 5 点交付，理由是「你有 Claude」
u/throwaway-well 说自己是真心喜欢这份工作的，但排期的方式正在慢慢杀死这份喜欢。经理的原话大意是：这最多两小时的事，用 Claude 搞一下，五点前给我。而他实际要做的是理解需求、做方案、改代码、拉集群、部署、完整测试，最后还得写文档。他后来在评论里补了一句更具体的：任务是上午 11 点半才派下来的。
“But task is given at 11:30 PM, where I have to understand the task,plan everything, make code level changes, create cluster, deploy changes then test everything properly and make documention out of it. Everything by 5 PM.”
— u/throwaway-well（原帖作者），原帖评论
评论区给出的建议大致分三层。最实用的一层是「把估时拆开报」：AI 能压缩的只是写代码那一段，别让它替整条流程背书。
“Claude can shorten part of implementation, but it doesn’t remove the time to understand the change, fit it into the system, test it, and have a rollback plan.”
— u/UkrMalt，原帖评论
有人给了更细的话术模板：不要说「我尽量」，因为在层层上报的过程中「我尽量」只会被压缩成「行」，剩下的全是噪音；要说的是「可以，但请你确认接受以下风险」，把决定权连同责任一起推回去。还有人搬出了三点估算法（最好、最坏、现实三个数，加权平均 E=(best+4×realistic+worst)/6），主张跟不懂技术的管理者对话必须带着能摆上桌的数据，而不是感受。
最扎心的一条来自一位已经离职的同行，他描述的那种管理者现在恐怕不算罕见：
“I had a manger who was like this too, clueless about the work and when we asked him for technical advice, he pasted our question into Claude and sent us the response.”
— u/burntoutdev8291，原帖评论
更麻烦的是后半段：这位经理自己 vibe coding 出了错，下属指出问题时他还要争辩，因为「Claude 说这样是对的」。评论者的形容很准——这跟对着一个正在幻觉的模型讲道理是一回事，区别只是你不能冲它骂脏话。
楼主后来透露公司是家创业公司，口头禅是「今天必须做完，通宵也得做完」，团队里已经有三个人因此离职了。到这一步其实问题已经不是估时技巧了。我想说的是另一层：AI 真正改变的往往不是产出速度，而是老板对速度的想象力，而这两条曲线之间的差额，最后是由具体的人用睡眠时间垫上的。国内很多团队现在正在经历同一件事，只是关键词从 Claude 换成了别的名字。能拉住这个差额的只有一样东西——把「实现」和「交付」在排期表上拆成两行，白纸黑字写清楚后者包含什么。
八成开发者觉得 AI 编程上瘾多过有用，而最好的一条评论是关于没发出去的 prompt
一份被搬到 r/technology 的调查说，约八成开发者认为 AI 编程带来的「上瘾感」超过了实际帮助；受访者担心的是习惯性依赖正在削弱自己的问题拆解能力、反而扩大了工作量，并且让人和工作的关系变得不健康。这类标题很容易滑向「AI 让人变蠢」的口水战，评论区前半段也确实吵了起来：一方说这就是智力上的懒惰，另一方回敬说「如果它不是问题，那它就不是问题」这种论证方式本身就是在回避现实。
真正有价值的是跑题的那一支。有人提到 AI 其实很适合当小黄鸭，然后话题就拐进了一个大家心照不宣但很少说出口的现象：
“Many prompts, I stopped writing and never sent because it was a good rubber duck”
— u/mintmouse，原帖评论
底下立刻一片附和，其中一条把机制讲得更清楚，还顺手推到了写规格文档这件事上：
“I feel like most of the time if I start writing a clear description of my problem, I’ll have an aha moment before I have a chance to finish the prompt.”
— u/PlacidTurbulence，原帖评论
他接着说，有一半时间如果真把规格写到详尽且无歧义，反而会觉得不如一开始就直接写代码——代码本来就是（基本上）无歧义的。这句话其实同时解释了 AI 编程的爽点和坑点：把问题描述清楚这件事，一直是编程中最难也最有价值的部分；AI 的存在给了你一个必须描述清楚的理由，这是它的正面作用，而它随时能替你把话接完，则是它的负面作用。
顺带一提，这条线还引出一个小小的时代切片：有人贴出一段精心设计的「你是一位资深工程师，请用五个为什么引导我」的长提示词，马上被问「现在还有人这么写提示词吗，我一年前就不写了，模型自己会读上下文」。回答也很有意思——不是不写了，是搬家了，搬进了自定义指令文件、skill 文件和专职子 agent 的系统提示里。提示工程没有消失，它只是从聊天框沉降成了配置。
有人在《植物大战僵尸》里挖出梅森旋转，评论区吵起了要不要劝新手别造轮子
u/JizosKasa 写了篇逆向笔记：在一个十五年前的游戏二进制里，靠那几个标志性的魔数认出了梅森旋转算法的实现，并顺着追出了游戏里颜色生成的那套逻辑。作者自己对这件事的定位很清醒——查了几个常量、跟了一遍逻辑，好玩而已。
“I never said it’s a giant achievement or whatever, I know I just looked up some constants and traced the logic of them.”
— u/JizosKasa（原帖作者），原帖评论
第一批评论是玩梗的（「你没必要管《植物大战僵尸》叫十五年前的老游戏，我受到了攻击」，以及一句更狠的提醒：《上古卷轴 5》再过几个月也满十五年了）。但有两条泼冷水的评论把话题引向了更值得讨论的地方——有人开始反思技术社区那句默认口头禅「别重复造轮子」正在被滥用。u/Sloogs 的说法是：在工作上没时间重造整个世界，这没问题，但它不该成为你对一个想搞懂难题的爱好者的第一反应；想成长为好程序员，恰恰需要一种不设心理路障的好奇和玩心。
“Yeah man if someone wanted to roll their own at work you’d tell them not to. Leave the students and hobbyists alone.”
— u/gimpwiz，原帖评论
另一条把两种立场调和得最好，我觉得应该抄下来贴在每个技术群的公告栏上：
“But spending a few hours of your own time on a toy version of the things it does will make your use of said library 10 times more effective.”
— u/LordoftheSynth，原帖评论
这话在今天格外应景。放回本期第一帖的语境里看，这场关于造轮子的争论其实和依赖投毒是同一个问题的两面：一个团队里如果没人手写过哈希、没人自己实现过一遍随机数生成器，那么当依赖出问题时，也就没人有能力判断那 150 行代码到底正不正常。玩心在这里不是消遣，是储备。
论文说 Reddit 正在变得越来越负面，评论区当场完成了复现
一项研究的结论被搬上了 r/technology：整个 Reddit 的情绪随时间在整体变负，而且社区存在得越久越负面，一条评论串拖得越长也越负面。第一条高赞评论完美地示范了论文的第三点：
“This article is awful and I hate everything about it.”
— u/PLEASE_PUNCH_MY_FACE，原帖评论
“thats the spirit”
— u/BotOrNot_1337，原帖评论
接下来这条串就非常自觉地一路滑下去：有人问「怎么能在这么负面的帖子下这么正能量」，有人宣布「我们已经走到该叫人滚蛋的那个阶段了」，有人自愿献身，还有人问需不需要他先管谁叫希特勒来把气氛彻底炒热。全程带着自嘲，反而是今天最好笑的一段。
另一支评论则提供了一个论文之外的解释变量：有人注意到这是个两个月新号发的转帖，怀疑是养号的机器人在刷 karma，养熟之后卖给做营销的。如果这个猜测成立，那么「社区越老越负面」里可能有相当一部分不是人的情绪衰减，而是内容生态的稀释——高互动的负面内容更容易被自动化账号复读，久而久之改变的是平台的分布，而不只是用户的心情。
这对中文互联网的启示是现成的。我们习惯把某个社区「变味」归咎于用户素质下降或者人多了，但在把锅扣给人之前，值得先问几个更机械的问题：推荐权重是不是在奖励冲突？转帖和搬运账号占了多大比例？评论区的排序是按赞数还是按争议度？平台情绪往往是被排序算法排出来的，不是被用户吵出来的。