IT之家 5 月 8 日消息，超频三现已为旗下野兽 F9 R120 工业级 LCP 风扇新增铝合金扇框版本，预计将于近期上市，作为比较， 现款野兽 F9 R120 风扇定价为 179 元 。 ▲ 现款野兽 F9 R120 风扇 该风扇采用了钛灰色阳极喷砂工艺，整体尺寸为 120 x 120 x 30 mm，采用了全铝 CNC 一体精雕框架，核心规格与标准版野兽 F9 R120 风扇大致相同。 具体来看，相应风扇扇叶使用“非连续截面复合弯掠叶形”设计，采用了新型高分子 LCP 液晶聚合物材料，转速范围设定为 500~3000RPM±10%，最大风量为 114CFM，最大风压为 8.2mmH2O。 IT之家附标准版野兽 F9 R120 风扇参数如下：
IT之家 5 月 8 日消息，超频三 (PCcooler, CPS) 现已发布“野兽” F9 R120 风扇的 Metal 版本。这是继 Alphacool Apex Stealth、酷冷至尊 MasterFan 120 后的又一款金属框架风扇。 F9 R120 Metal 拥有 CNC 工艺全铝合金扇框 ，搭配“非连续截面复合弯掠叶形”工业级 LCP 扇叶 ，还具备 NSK 双滚珠轴承和三相永磁电机。此外其集成 恒速闭环控制系统 ，支持三档转速上限调节。 该风扇 尺寸为 12030 ，转速区间 500~3000 RPM (±10%)，最大风量 114 CFM、最大静压 8.2 mmAq、最大噪声 42.7 dB(A)， 享受 5 年质保 。
IT之家 5 月 6 日消息，在接受汽车媒体 Autocar 采访时，项目负责人罗伯 · 格雷（Rob Gray）表示， 红牛先进技术公司已开始总装首款 RB17 超级跑车，并计划在未来 2 年内向客户交付。 IT之家注：汽车总装是汽车制造的最后一道关键工序（四大工艺：冲压、焊装、涂装、总装），组装经过涂装的白车身，以及发动机、变速器、内外饰、线束等 1000-2000 个零部件，打造出完整的成品车。 IT之家援引博文介绍，RB17 是一款纯赛道使用的双座超级跑车，由传奇设计师阿德里安 · 纽维（Adrian Newey）设计，计划限量生产 50 辆，售价高达 500 万英镑（现汇率约合 4639.6 万元人民币），预计 2027 年春季推出，并在随后两年内交付客户。 RB17 车身采用全碳纤维打造，重量控制在 900 公斤，总功率为 1200 马力，其中 1000 马力来自 V10 发动机，另外 200 马力来自电动机，极速可达 220 英里 / 小时。 外观方面，RB17 与 2024 年古德伍德速度节上展示的原型车有较大变化，但尺寸、比例和主要设计元素保持不变。新设计的细长头灯进一步勾勒出车身轮廓，并优化进气口和空气动力学表面，加入了类似 F1 赛车的主动空气动力学部件。 一个引人注目的技术细节是，发动机盖上新增了一条长长的“脊线”，V10 发动机的排气口从中伸出。这种设计能让废气“吹”向尾翼下方，从而增加下压力。
我同事说，好不容易今年五一休假，他这 5 天能都休息，他这 5 天没班 说有点羡慕我今天在上班，因为他好不容易正修了一回，他也不知道干什么 然后说他就像被驯化的野兽 休息了 也不知道干什么 就睡睡觉，然后吃吃饭，看会儿电视剧。他感觉不知道干什么，甚至想回来和我一起一起上班 他觉得他这个样子很可悲 已经被驯化了 除了上班 没什么自己的生活 他说，他这几天起床第一件事情不是想怎么舒服，第一件事情是想是不是闹钟没响，睡过点了 他说他现在天一亮他就醒了，因为他觉得自己要上班了 9 个帖子 - 7 位参与者 阅读完整话题
你没有在做 AI 开发。 你在喂一头失忆的野兽，然后抱怨它咬错了方向。 更糟糕的是，你以为你有计划。 你知道要做计划。这才是问题所在。 你不是不懂计划的重要性。你懂。 你甚至做了计划。第一天，你开了一个新文档，写下了模块划分、接口设计、技术选型。写得很认真，逻辑很清晰，你盯着那个文档看了一会儿，感觉良好，感觉这次不一样了。 然后你打开 Cursor，开始写第一行代码。 三天后，计划文档里有了一些划掉的部分，和一些用红色标注的"待更新"。你心里知道应该同步一下，但手边还有更紧的事，就先放着。 一周后，你打开了新的 session，把计划文档粘进去，Agent 给了你一个方向。你觉得"差不多"。继续往前。 两周后，计划文档已经有了三个版本——第一版是最开始那个，第二版是某次大改之后新建的，第三版是上周你试图重新整理的，写到一半没写完。你不记得哪个是当前状态。你也不太想去对。 一个月后，你已经不打开那个文档了。不是因为你放弃了计划，而是因为你已经不相信它了。文档里写的和仓库里跑的，是两个平行宇宙里的同一个项目。 你靠的是什么在推进？靠记忆，靠感觉，靠每次 session 开始时重新描述一遍你在做什么。每次描述都稍微不一样，Agent 给出的方向也稍微不一样，方向的偏差在积累，但速度还在，所以感觉还好。 这是大多数人用 AI 开发的真实状态： 不是没有计划，是计划成了摆设，而他们仍然以为自己有计划。 这比没有计划更糟糕。因为没有计划的人知道自己没有锚点，会本能地保持警惕。有计划摆设的人以为自己有锚点，会在一个正在漂移的系统里充满信心地往前冲。 这个问题，2011 年就有人解决了。不是为了 AI。 2011 年，一个叫 Michael Nygard 的工程师写了一篇两页纸的博客。那时候没有 ChatGPT，没有 Cursor，没有 Vibe Coding，AI 还是学术圈里的遥远词汇。 但他发现了一个问题，和你今天遇到的，本质上完全相同。 他是这样描述的： 一个新人加入项目，看到一个奇怪的设计决策。他不知道当时为什么这样选。于是他只有两个选择：盲目接受，或者盲目推翻。两种都可能毁掉项目。 他的解法叫 ADR（Architecture Decision Record）——用一种极简的格式，把每一个重要决策的"当时为什么"永久记录下来。不是记录做了什么，而是记录为什么这样做，当时的约束是什么，放弃了哪些选项，以及这个决策会带来什么后果。 这个格式发明出来是为了解决"人和人之间"的认知对齐问题。 但当我第一次读到这篇文章，脑子里浮现的第一个念头不是"这能帮我和同事对齐"——而是： Agent 就是那个永远在第一天入职的新人。 每一个新的 session，它对之前发生的一切一无所知。它不是在继承你的工程，它是在重新发明它。它没有恶意，它没有懈怠，它只是——不记得。 但他和真正的新人不同：他永远不会迷路。 真实的新人会迷茫。 他会在走廊里拦住你问一个问题，会在 PR 评论里写"这里我不太确定"，会在做出一个大决定之前犹豫，会用他的迟疑和困惑告诉你：这里需要注意。 Agent 不会。 它没有迷茫的能力。没有"我不确定"的表情，没有走廊里的迟疑，没有任何信号告诉你它正在偏离。它永远自信，永远流畅，永远在生成方案。它的输出永远看起来是对的，因为它永远是完整的、有逻辑的、有说服力的——即使那个逻辑是建立在一个悄悄漂移的目标之上。 于是你得到的不是"一个需要引导的新人"，而是"一个失忆的、精力无限的、不停往前冲的执行者"。 他走得越快，你离目标越远。 这才是 Vibe Coding 加速腐烂的真实机制。不是 Agent 在犯错——它每一步都执行得无可挑剔。是你的目标在漂移，而它忠实地跟着漂移的目标一路狂奔。你最终得到的，是一个高速运转的、方向飘忽的系统。它每一行代码都是认真写的，整体却是一团没有骨骼的肉。 Prompt 解决不了这个问题。 大多数人遇到这个问题的第一个直觉是：prompt 写得不够好。 于是他们开始打磨 prompt。加上更多约束，写得更精确，把背景交代得更清楚，把要求列得更细致。 这有用。但只在单次对话里有用。 下一个 session，一切重来。新的对话窗口打开，之前所有的 prompt 工程成果蒸发，你又回到了起点，对着一个什么都不记得的 Agent 重新解释你是谁、你在做什么、什么东西不能动。 Prompt 解决的是单次对话的质量。它解决不了跨 session 的漂移。 这是两个完全不同维度的问题。用 prompt 解决漂移，就像用创可贴处理骨折——不是没有在做事，只是做的不是对的事。 你真正需要的，是一个在所有 session 之上都生效的东西。一个不会随着对话窗口关闭而消失的锚点。一个 Agent 在开始任何执行之前必须先读懂的东西。 这才是 ADR 真正的角色。 不是文档，不是日记，不是变更日志，不是给团队看的交代。 是宪法。 宪法。 宪法这个词听起来很重，但它的本质很简单：在所有执行层之上悬浮的、定义边界的东西。 它有几个特征，不是所有人都注意到的。 第一，宪法不是用来描述权力的，是用来约束权力的。 这意味着 ADR 不能在执行 session 里被修改。Session 有权利在约束内做决策，但它没有权利重新定义约束本身。这道墙必须硬，必须在任何执行开始之前就存在，否则每一次执行都在悄悄修宪——而你不知道，因为每次修改都包裹在一个流畅的、有说服力的方案里，看起来完全合理。 第二，宪法保护的不是"正确答案"，而是"讨论正确答案的方式"。 ADR 不是在宣布"我们永远用这个框架"。它是在说：我们当时面对什么约束，我们考虑过哪些选项，我们为什么最终选了这个，以及如果你将来想推翻这个决定，你需要先搞清楚这些。 它保护的是决策的脉络，不是决策的结论。结论可以变，但脉络必须被尊重。没有读懂脉络就推翻结论，和那个盲目推翻决策的新人没有任何区别——只不过速度更快，造成的破坏更彻底。 第三，宪法有修正案机制，而且修正案本身也是宪法的一部分。 决策被推翻不是失败，是演化。系统在成长，约束在变，当初的判断可能真的过时了。这完全可以接受。但推翻必须留下记录，而且这份记录要比原始决策更详细——你需要解释的不只是"新的选择是什么"，还有"为什么原来的选择不再成立，什么改变了"。 旧记录不删，标记为 superseded。这不是强迫症，这是对历史的尊重，也是对未来的投资。知道"我们试过 A，不行，才选了 B"，比只知道"现在用 B"，差了整整一层理解——而那一层理解，往往是在你第三次面对同一个问题时，救你的东西。 第四，没有被执行的宪法，只是一张纸。 ADR 写完放在目录里，没有任何机制保证 Agent 在开始新 session 前读过它——那它就是装饰，让你感觉做了什么，但什么都没有改变。 宪法需要执法机制。在 Agent 工程里，这个机制只有一个形式： ADR 必须是每个 session 上下文注入的一部分，不是可选项，是必选项。 在任何执行开始之前，宪法先读。没有读过宪法的 Agent，不应该被允许开始执行。 但谁来写这部宪法？ 这里有一个真正的悖论。 如果宪法由人来写——人需要读完整个代码仓库，理解所有现有的边界和约束，才能定义什么可以动、什么不能动。这在 AI 时代是退步，是让人去做机器最擅长的事情。 如果宪法由 Agent 来写——Agent 定义了自己的约束，再被这个约束执行。谁来保证这个约束真正符合人的意图？主权在哪里？这是循环依赖，也是在把最关键的判断悄悄外包出去。 两条路都走不通。 但宪法从来不是一个人或一台机器写出来的。历史上任何一部真正有效的宪法，都是充满张力的协商过程的产物。 在 Agent 工程里，这个协商过程是这样的： Agent 去读仓库。不是为了生成计划，而是为了描述现实——这里有什么，这些东西之间是什么关系，现有的边界在哪里隐约存在但从未被明说。这件事 Agent 比人做得更快，也更准，因为它不会因为"这段代码是我三个月前写的"而产生偏见，不会因为熟悉而忽略奇怪的地方。 与此同时，人去翻译意图。不是产品文档里写的那些需求——是真实的、深层的意图。这个系统最终要保护什么？什么东西不能被牺牲？哪些地方的错误是可以接受的，哪些地方的错误是致命的？这些判断没有办法从代码仓库里读出来，只能从人的判断里来。 两件事并行发生。然后， 人做第一轮收敛 。 这一步不能省，不能外包，不能"让 Agent 整合一下看看"。它的本质是：在 Agent 描述的现实和人理解的意图之间，人来决定哪里有矛盾，哪里的矛盾必须现在解决，哪里的矛盾暂时可以带着走。这是判断，不是计算。任何试图把这一步自动化的尝试，都是在悄悄放弃主权。 第一轮收敛之后，真正的协商开始。 Agent 拿着人的结论，继续推演：如果这是边界，那这里会有什么问题？这个约束和那个约束之间有没有冲突？有没有人没想到的边缘情况，在某些极端条件下会让整个系统的假设崩塌？它不是在质疑人的判断，它是在压力测试这个判断——用它读过的所有代码、所有模式、所有它见过的系统失败方式，去问：这部宪法在极限情况下还成立吗？ 人听完，调整，再收敛。这个循环可能跑两次，可能跑三次。但每一次，终审都在人手里。 最终出来的 ADR，不是人写的，也不是 Agent 写的。 它是一份协商记录 ——记录了人的意图、Agent 发现的现实、两者经过几轮摩擦之后沉淀下来的共识，以及那些被刻意排除在外的选项和它们被排除的原因。 这才是一部宪法应该有的质地：不是独裁者的命令，也不是算法的输出，而是张力被处理之后留下来的东西。 Human First，不是说人先动手。是说人拥有每一轮收敛的终审权。这是主权声明，不是操作顺序。只要这个主权在，Agent 参与起草宪法就不是威胁，而是效率。 当一切就位，工作流长这样。 ADR 在最上层，定义约束和边界，不随任何 session 变化。它由人和 Agent 协商写出，但人终审，写完之后它就脱离了任何个体的控制，成为一个独立的存在。 ADR 之下，是被拆解出来的小计划——每个计划都在 ADR 的约束范围之内，不能越界，不能自我扩张。小计划再被拆成独立的 Task，每个 Task 有清晰的输入、输出和边界条件。Task 最终分配给独立的 session 执行。 每一层向上对齐。执行层不能越级修改约束层。Agent 在有界空间里运行——不是因为我们不信任它，而是因为有界的空间让它可以跑得更快、更确定、更少需要被纠正。 速度和确定性不是天然矛盾的。它们之所以在 Vibe Coding 里互相消耗，只是因为缺少了中间那一层。 速度从来不是问题。失忆才是。 Vibe Coding 本身没有错。让 AI 承担更多执行，是对的方向。把意图翻译成代码这件事，交给机器来做，是完全合理的进步。 错的是把"描述意图"当成了工作流的全部。 意图需要被结构化，被记录，被约束，被保护。否则它只是噪声——而 AI 会非常高效地把噪声放大，并且用流畅的方案包装它，让你以为一切都在正轨上，直到某一天你发现，你已经在一个完全不同的地方了。 速度从来不是问题。失忆才是。 参考与延伸阅读 本文核心参考 Documenting Architecture Decisions — Michael Nygard（2011） ：原始 ADR 提案，两页纸，值得每个工程师读一遍。 延伸阅读 Architecture Decision Record — Martin Fowler ：Fowler 对 Nygard 原文的补充，以及 2011 年之后 ADR 生态的演化。 When Should I Write an Architecture Decision Record — Spotify Engineering ：Spotify 内部实践：什么时候该写，什么时候不用写。 Why You Should Be Using Architecture Decision Records — Red Hat ：ADR 在大型工程团队中落地的视角，2018 年 Thoughtworks 将其列入技术雷达 Adopt 区的背景。 作者 RollingTheRock.blog 8 个帖子 - 7 位参与者 阅读完整话题