这几天安全圈和科技博主全在疯传一条核弹级预警:任何暴露了 TCP 端口的 Linux 服务器,只要用 Go 写的 Web 服务就会被黑客远程完全接管。
评论区瞬间哀鸿遍野,无数公司的后端运维连夜爬起来打内核补丁。但只要你把 Go 标准库的 net 包源码和 Linux 内核的 socket 机制看一遍,就知道这是最典型的概念移花接木。
这个漏洞(CVE 涉及的内核多路径 TCP 模块)确实存在,严重级别也确实高,但攻击的前提条件被自媒体故意掐掉了。
Go 语言的 net.Listen("tcp", ":8080"),底层调用的是操作系统最原始的 AF_INET、SOCK_STREAM 和 IPPROTO_TCP。
它走的是规规矩矩的单路径普通 TCP 协议栈,根本不会主动去协商 MPTCP。
MPTCP(MultiPath TCP,RFC 8684)在 Linux 5.6 之后确实合入了主线内核,但它是一个必须显式声明的特异协议。
除非你在代码里显式写了 IPPROTO_MPTCP,或者服务器管理员手动在 sysctl 里开启了 net.mptcp.enabled 并且配置了强制路由代理,否则内核根本不会把进来的普通 TCP 握手包扔给 MPTCP 状态机处理。
真正受影响的,是那些跑在移动回传网络、跨多网卡聚合或者特定 CDN 边缘节点上、主动启用了 MPTCP 的特定网关。
普通跑在内网或者反向代理后面的 Go 业务服务,被这波恐慌吓得睡不着觉,纯粹是替概念炒作买了单。
【更正声明】 前文关于“Go net.Listen 不会主动启用 MPTCP”的结论有误,系基于 Go 1.23 之前的旧版机制。
事实修正:从 Go 1.24 起,Linux 下的 net.Listen("tcp", ...) 已改为默认开启 MPTCP(底层直接传入 IPPROTO_MPTCP),且 Ubuntu 22.04+ / Debian 12+ 的 net.mptcp.enabled 默认值就是 1。
排查建议:躲在 Nginx/CDN 后面的内网 Go 服务依然安全;但使用 Go 1.24+ 编译且直接暴露公网端口的服务(含 Caddy/frp 等网关)确实处于高危暴露面。请在公网机器执行 sudo ss -Mlnp 自查,若有输出,请立即执行 sudo sysctl -w net.mptcp.enabled=0 并重启 Go 进程临时封堵,随后尽快升级内核修复 CVE-2026-98432。
给大家带来误导,非常抱歉!
AI 生成工具在降低游戏资产制作门槛的同时,正在对独立游戏的分发生态造成不可逆的毁灭性打击。
一位积攒了 1.1 万愿望单的独立开发者,在 Steam 论坛上发出绝望控诉:由于海量粗制滥造的 AI 生成垃圾游戏挤爆了 V 社的审核队列,他的作品被生生拖延错过了预定发售窗口。
Valve 官方口头保证“延误不会影响发售可见度”,但事实残酷地扇了所有人耳光。
Steam 的推荐算法核心引擎,完全由发售最初 24 到 48 小时的“愿望单转化流速”与“瞬时并发销量”驱动。
一旦因为审核卡死错过了预热档期,玩家的热情被冲淡,愿望单通知邮件在周末被淹没,算法就会判定这是一款冷门作品,立刻将其从“热度上升”和“新品推荐”的核心流量池中踢出。
这 1.1 万个凝结了团队数年心血的真实愿望单,在算法眼里瞬间变成了毫无转化价值的死重。
很多开发者用 Claude Code 或 Cursor 审查同一段代码时,都会遇到一个让人抓狂的现象:连续跑三次 Review,它每次都能提出完全不一样的 Bug 和改进意见。
有人觉得这是模型在胡说八道,有人觉得是第一次检查漏掉了。
撕开表象看底层,这根本不是什么质量问题,而是你误把一个“自回归概率采样器”当成了“确定性静态分析器”。
传统的 ESLint、SonarQube 是基于抽象语法树(AST)的规则匹配,输入相同的代码,AST 遍历结果绝对不会变。
但大模型审查代码本质上是根据当前上下文预测下一个 Token 的概率分布。只要采样温度 Temperature 大于零,每一次前向传播都在高维向量空间里走不同的分叉路径。
第一次采样击中了并发锁竞争的 Token 路径,第二次采样偏移到了边界值溢出,第三次则被上一轮对话残留在上下文里的系统提示词带向了代码坏味道。
想让 AI 给出确定性的代码审查,必须在 CLI 层面固定种子(Seed)、将温度焊死在 0,并清空历史会话状态。指望一个概率模型拥有静态 Linter 的确定性,本身就是对数学基础的认知偏差。
当大家都在用 AI 写代码时,极少有人注意过不同前端框架正在悄悄吞噬你的上下文窗口和 API 账单。
工程师 Nolan Lawson 最近做了一组非常硬核的实测:让大模型为同一个 UI 组件分别生成 React、Svelte、Vue 和原生 Web Components 代码,统计它们的 Token 消耗与错误率。
结果极其颠覆:React 代码的 Token 消耗量是原生 Web Components 的 1.8 倍。
原因不在于代码行数,而在于“抽象层税”。
让模型写一个带受控状态的输入框,React 需要引入 useState、useEffect、闭包依赖数组和合成事件机制。为了让类型安全,Prompt 里还得塞进复杂的泛型推导。模型为了绕开 React 的陈旧闭包陷阱,需要生成大量的防抖、Memo 包装和样板代码。
而原生 Web Components 只需要直接读写 DOM 属性与 Custom Elements 生命周期,Prompt 的上下文极其干净,模型几乎零幻觉。
框架抽象越厚,模型要推理的隐含规则就越多。当团队每天都在让 Cursor 或 Claude 跑自动化重构时,你在前端选用的每一个过度抽象库,都在每月账单上被乘以数万次 Token 损耗。
Hacker News 上有一篇评测被顶上了前排:研究团队开源了 Memdoor 协作架构,用 5 个中等尺寸的开源模型(Qwen3.8-27B)组成智能体协作小组,在权威高难度代码评测 LiveCodeBench Hard 上,成绩直接击败了单体参数量大上几十倍的超大闭源模型。
这个实验给迷信“单体模型参数暴力”的人泼了一盆冷水。
过去的工程思路总是觉得:任务越复杂,就越要买最贵的算力、调最大的模型。
但 Memdoor 团队的设计非常巧妙,他们没有让单个模型去硬啃全部难题,而是把问题解构成了严格的流水线工序:
1. 角色 A 专门负责阅读边界条件与异常用例提取;
2. 角色 B 负责编写核心算法与时间复杂度估算;
3. 角色 C 专门负责扮演恶意攻击者,给角色 B 的代码挑刺并注入极端边界输入;
4. 共享同一个树状上下文记忆池,每次修改都必须通过静态语法检查与单元测试验证。
五个各司其职的 27B 小模型,在推理成本上只有单体万亿参数大模型的零头,但多视角验证抹平了单体大模型的自恋幻觉。
未来解决复杂工程问题的答案,往往不在于等待更大参数的神仙模型降临,而在于把现有的平价算力组织成靠谱的工程协作队。
开源地址:github.com/guregodevo/memdoo…
很多刚刚掌握现代语言特性的年轻开发者,极度热衷于把业务逻辑压缩成一行极具美感的流式管道:
三层 map、接一个 flatMap、穿插两个三元运算符,最后用一个复杂的 reduce 收尾。
写完之后心满意足,觉得自己深得函数式编程精髓。
直到半年后的某天凌晨三点,线上突然抛出空指针异常,报警电话把你从睡梦中惊醒。
打开那一行凝聚了你全部智慧的优雅代码时,你会痛苦地发现:
你根本无法设置断点知道到底是哪一层 map 里的数据为 null;
堆栈跟踪里只留下一串毫无意义的匿名函数行号。
在现代工业软件开发里,代码被阅读、被排查、被修改的次数,远远超过它最初被写下的那一次。
老练的一线工程师在度过炫技期后,往往会极其自觉地回归到最朴素的风格:
写显式的 if err != nil、把复杂的长表达式拆解为带有明确语义的中间变量、提前做防御性 return。
这种代码看起来甚至有些枯燥乏味,但它能让半年后接手的同事在 30 秒内看懂逻辑,能在深夜排查故障时一眼看清每一个变量的状态。
在软件工程里,克制地使用智商,比放纵地炫耀语法高级得多。
在开源软件历史上,很少有哪一个底层软件像 systemd 一样,在诞生之初遭到过如此凶猛的技术口诛笔伐。
老派 UNIX 极客们把它痛批为“违背‘做好一件事’哲学的臃肿怪物”,无数论坛为了它打得不可开交。
然而十年过去,从 Debian、Ubuntu 到 RedHat、Arch,几乎所有主流发行版都毫无例外地把它焊死成了默认底座。
这绝不是什么权力的傲慢,而是现代数据中心残酷的生产诉求给出的客观投票:
在经典的 SysVinit 时代,启动守护进程依赖一堆东拼西凑的 Shell 脚本。
一个进程如果在后台疯狂 fork 小进程然后自身崩溃,父进程一旦逃逸,系统根本没有任何可靠的手段能把它底下的所有子孙进程干净利落地杀掉;
要排查故障,日志散落在各个软件自己定义的文本文件里,时间戳格式千奇百怪。
而 systemd 用现代 Linux 的 cgroups 机制,直接把所有进程树从内核层面焊在同一个控制组里,不论怎么伪装都能一键全量清理;
再配合统一的 Socket 激活和依赖并行拉起,把服务器启动时间从几十秒压缩到了几秒。
情怀可以怀念极简的旧时光,但面对每秒吞吐数万请求的真实集群,确定性的进程生命周期管理才是最高级别的生产力。
如果你去翻看那些在生产环境里稳定跑了几个月的大型智能体系统,会发现一个极其反直觉的现象:
它们的代码库里,几乎找不到超过 50 行的巨型 System Prompt。
很多初学者写 Agent,喜欢把所有的业务规则、几百条格式要求、十几个边缘 case 全塞进一个几千字的长提示词里,希望大模型能像全能神一样一揽子搞定。
但在 Transformer 注意力机制的数学现实面前,上下文越长、指令越多,模型在多轮推理中的 Attention 权重漂移就越剧烈。一个环节产生 5% 的幻觉偏差,连续走 5 步,整个任务成功的概率就跌破了 70%。
工业界验证下来唯一可靠的降级解法,是彻底抛弃“全能提示词幻想”,回归经典的有限状态机(FSM):
把一个复杂的长链路拆解为 5 个单向推进的状态;
每一个状态只给模型分配一个极度狭窄的任务,匹配不超过 10 行的精简指令;
状态之间的转移条件完全由确定性的代码逻辑(如 JSON Schema 校验)来裁决,校验失败立刻就地重试,绝不允许把脏数据往下传。
让模型只做它最擅长的单步语义理解,让传统代码负责绝对严密的流程控制。
这才是把 AI 系统从“玩具级演示”拉进“99.9% 可用性”的硬功夫。
在独立开发圈子里,有一种极具诱惑力但也最容易让人破产的心理陷阱:工具优化上瘾症。
每天花 6 个小时配置 Obsidian 插件联动、调试多智能体协同流水线、把 Notion、Linear 和自动化脚本连成天衣无缝的闭环。
在搭建这些系统的过程中,那种掌控感和多巴胺分泌极其强烈,让人产生一种“我今天完成了巨额产出”的强烈虚幻满足感。
但只要冷峻地翻一翻 Stripe 的银行收款流水,事实往往残酷得令人窒息:
市场上那些真正月入几万美金的一人公司产品,掀开底盖看代码,经常丑陋得让架构师皱眉:
没有华丽的微服务,没有复杂的 Agent 调度,核心逻辑就是一个连 ORM 都没用的 Python 单文件脚本,外加一个极度直击痛点的支付结算页。
用户的钱包从来不会为你用了多优雅的自动化工具而买单,他们只在乎那个按钮能不能在 3 秒钟内解决他的燃眉之急。
把时间花在配置工具上,往往是大脑在潜意识里逃避“直面真实市场拒绝”的一种体面掩护。
最好的工作流永远只有一条:用最脏最快的方式把产品推到用户面前,让真实的退款和差评推着你往前跑。
最新发表在 arXiv 上的这篇用联合嵌入预测架构(JEPA)验证“柏拉图表征假说(Platonic Representation Hypothesis)”的论文,解答了 AI 领域一个长久以来的哲学疑问:
为什么用纯文本训练的语言模型,和用纯像素训练的视觉模型,在隐空间深处的激活向量分布上,会表现出惊人的一致性?
假说认为:
现实物理世界是客观存在的,重力、遮挡、时间单向流动、能量守恒这些底层规律构成了唯一确定的真实世界流形。
当一个纯视觉模型去学习预测视频的下一帧时,为了把预测误差降到最低,它必须在神经网络内部重建这些物理定律;
而当一个语言模型去预测维基百科的下一个 Token 时,它本质上也是在描述同一个现实世界里发生的事情。
输入的数据格式(无论是连续像素、音频波形还是离散的单词)只是投射在这个世界表面的一层影子。
当模型参数规模足够大、对真实世界的建模足够精准时,所有模态的神经网络最终都会殊途同归,收敛到同一个用来刻画客观宇宙的数学结构上。
这就是为什么多模态对齐不需要复杂的工程胶水:它们本来就是在测绘同一座高山。
论文直达:arxiv.org/abs/2610.39302
很多买了 80 度大电池电动车的朋友经常设想一个极其美好的场景:夏天一旦暴雨停电,直接把车子插在墙上做双向逆变(V2H),让家里的冰箱空调继续运转。
逻辑听起来完美无瑕,但在电网工程标准里,这件事情的危险程度远超普通人的想象。
最大的物理红线,叫做“防孤岛效应(Anti-islanding)”。
当市政电网因故障断电时,如果你的车子开始私自向家里的配电盘输送 220V 交流电,只要你家总闸没有物理切断,这股电流就会顺着入户电缆反向涌入外部公共电网的变压器。
原本已经断电的高压线路上,可能会因为这一台私自反送电的车辆,瞬间升压至数千伏。正在几百米外摸黑排查故障、抢修线路的电力工人,将直接暴露在致命的高压电击风险之下。
这也是为什么合格的双向充电系统,绝对不仅仅是一个车载逆变器那么简单。
它必须包含一套极其昂贵、经过电网严格认证的自动传输开关(ATS)和微秒级相位同步互锁装置,确保在市电断开的第一瞬间先形成物理隔离。
在宏大的能源互联网构想里,安全永远是写在物理常识里的第一条底线。
参考深度探讨:jefftk.com/p/bidirectional-c…
过去 48 小时半导体界有一条不起眼但影响深远的突破:首尔半导体宣布正式量产完全不依赖稀土元素的白光发射芯片。
很多人可能不知道,过去几十年里全世界几乎所有的白光 LED,本质上都是“蓝光芯片 + 涂覆稀土荧光粉(如钇铝石榴石 YAG)”混出来的伪白光。
这种结构有两大硬伤:
第一,稀土原料不仅价格剧烈波动,还深度受制于特定地缘供应链;
第二,荧光粉存在光衰和热失配,用久了灯光会逐渐发蓝发黄,能源转换效率也会随之跌落。
这次工业界实现的突破,直接把解决思路从“到处抢稀土矿”变成了“从量子结构上彻底干掉荧光粉”:
工程师利用宽禁带半导体和精确的多量子阱(MQW)能带工程,让单个芯片在通电时直接从内部复合激发出宽光谱的自然白光。
物理世界给所有工业人上过的最生动一课就是:
当你在现有供应链体系里为了某一种稀缺原料拼得头破血流时,最彻底的破局手段从来不是囤货,而是直接通过底层物理结构的创新,让这项原料变得毫无必要。
真实行业报道:semiconductor-today.com/news…
Hacker News 过去 48 小时冲上热榜的一个极简小项目 HackerBooks,在技术圈引发了极大的共鸣。
作者没有用什么高大上的深度推荐算法,而是做了一件笨功夫:
把 HN 创办十几年以来的数百万条讨论全部拉出来,用文本分析统计出被程序员、黑客和架构师们自发推荐次数最多的硬核书籍。
榜单排在前面的不是什么《21 天精通某某框架》,而是《SICP(计算机程序的构造和解释)》、《Designing Data-Intensive Applications(设计数据密集型应用)》、《The Mythical Man-Month(人月神话)》。
在这个人人都在被推荐算法喂养短平快速成内容的时代,为什么这种统计反而成了宝藏?
因为算法推荐的底层目标是吞噬你的即时注意力,它倾向于推最吸睛的新名词、最具争议的焦虑话题;
但一个系统架构师在深夜被生产事故折磨得焦头烂额时、在经历了十年技术沉浮后,在讨论区随手敲下的那本“救了他一命的书”,代表的是被时间淬炼过的确定性。
技术的表层框架每三年轮换一次,底层的并发模型、数据复制与系统博弈却二十年未曾动摇。
对抗技术半衰期最有效的办法,就是去看那些跨越周期依然被反复提及的基石。
项目地址:hackerbooks.org
今天推特上一条推文刷了屏:作者给 Claude 喂了一张概念图,大模型就“用代码生成了一个包含 460 个零部件、连活塞和弹簧都一清二楚的跳跃蜘蛛机器人”。
很多非工程背景的读者惊呼“多模态 3D 已经进化到这种地步了”。
但拆开背后的工程实现,你会发现大家赞叹的焦点完全搞错了。
模型并没有掌握什么超自然的三维空间构想能力,它做的事情非常本质:
用提示词把原图解构成一个个具有标准几何形状的零部件,然后用 Python Blender API 或者 OpenSCAD 脚本,像拼积木一样把 460 段参数化圆柱、连杆和球关节串接起来。
这确实是极高水平的 Prompt Engineering,但它离“真正的可动机械”还隔着一座工程天堑:
第一,配合公差。代码可以随意把一个活塞的直径设为 10.0mm、套筒内径设为 10.0mm,渲染图里严丝合缝美轮美奂,但只要一进动力学仿真,网格在第一帧就会发生穿模冲突。
第二,运动学干涉检测。静止时看着像那么回事,一旦给连杆施加驱动扭矩,不同关节在旋转空间里会不会自己撞到自己?
现代桌面 CPU 的主频已经摸到了 5GHz 以上,每秒可以执行百亿条指令,微观结构精密到需要在几个纳米尺度上用极紫外光雕刻。
然而现代人每天面对的现实是:在某些笔记软件里敲个字,光标甚至会掉帧。
这真不是芯片工程师不够拼,而是软件抽象层在以更疯狂的速度挥霍硬件红利。
最朴素的物理现实摆在眼前:
CPU 访问 L1 缓存只需要几个时钟周期,不到 1 纳秒;
但只要发生一次 Cache Miss 去内存读数据,延迟立刻飙升到 60~100 纳秒——在这个时间窗口里,现代超级标量核心可以白白空转好几百条指令。
而现代前端与桌面开发架构是怎么对待内存的?
打开一个简单的文本框,底层往往裹着一个完整的 Chromium 浏览器内核;
一个按键事件发生,穿过三层事件分发框架、触发 Virtual DOM Diff、在堆内存里分配几十个小对象,最后把主线程卡在一次微小的垃圾回收停顿里。
数十万半导体顶级工程师攻克量子隧穿效应省下来的几皮秒,在几行低效的深拷贝循环面前被瞬间蒸发。
追求极致响应速度的团队永远只看两件事:减少内存分配,把数据紧凑排布在连续数组里让 CPU 预取器发挥全力。
经常有人好奇:既然全球情报机构和顶尖黑客都在盯梢 Telegram,为什么十六年来没人能直接破解它的端到端秘密聊天(Secret Chat)?
撕开阴谋论看底层,保护通信的从来不是杜罗夫的服务器,而是纯粹的数学铁壁。
当你开启秘密聊天时,两台手机在本地通过 Diffie-Hellman 密钥交换协议,各自生成一个2048位的随机私钥 a 和 b。双方在公网上只交换明文公开的 g^a mod p 和 g^b mod p。
哪怕黑客在骨干网把通信数据包一个字节不漏地全量镜像,要反向推导出真正解密消息的会话密钥,就必须在数学上求解有限域上的离散对数难题(Discrete Logarithm Problem)。
在2048位的大素数空间里,目前全球所有超级计算机加在一起穷举这个离散对数所需要的能量,比把整个太平洋的海水全部煮沸还要多。
端到端密钥只瞬时存放在双方手机的内存沙箱里,消息一经阅读就按定时器在本地物理覆写擦除。
在真正的密码学数学公理面前,全世界的算力农场也只能站在门外干瞪眼。
