今天有三条技术消息，单看都不算大众热点。

一条是 WASTE 推理引擎，可以通过 NVMe 流式加载专家权重，在有限内存下运行完整 Kimi K3。

一条是 JFrog 发现，某些看起来严重的 SQLite CVE，很可能是 LLM 生成的虚假漏洞报告。

还有一条，是开发者重新批判 SwiftUI 七年发展，吐槽它在复杂场景里依然让人不得不找 UIKit 或 AppKit 兜底。

这三件事看起来不在一个频道。

但我越看越觉得，它们其实指向同一个结论：

AI 工具越厉害，越不能省掉人的工程判断。

能跑，不代表能用得爽

先看 WASTE。

HuggingFace 讨论区里，作者 Marco Bambini 介绍，Kimi K3 有 2.78 万亿参数，权重大约 1.42TB。WASTE 把 Kimi K3 转成 982GiB 容器，在 64GB MacBook Pro 上跑完整模型，4K 上下文下测得最低内存需求约 29GB，速度约 0.32 到 0.34 token 每秒。

这很厉害。

但作者也说得很清楚，这还不是交互式体验。

也就是说，真正有价值的不是“我能不能硬跑起来”。

而是你能不能判断：

这个方案适合什么场景？

瓶颈在哪里？

速度能不能接受？

硬盘读写、缓存命中、内存压力，会不会让它在真实工作里掉链子？

这就是工程判断。

技术突破很酷，但交付不是截图。

能跑起来，只是入场券。

能稳定、可控、可维护地跑，才是生产力。

看起来严重，不代表真的有漏洞

再看 JFrog 的 CVE 事件。

JFrog 研究人员调查 CVE-2026-51302 时发现，相关 SQLite 漏洞描述存在明显问题。文章说，一些 CVE 可能属于 LLM slop，也就是由大模型生成的看似合理但事实不成立的内容。

更吓人的是，他们审计同一 GitHub 账号发布的 55 个 advisories，发现 54 个完全是编造的，另 1 个包含真实 bug 但混入了未经验证的 CVE 元数据。

这件事对安全团队很麻烦。

因为 CVE 原本是用来帮大家识别风险的。

如果虚假 CVE 大量进入下游数据库和企业扫描器，安全团队就会被迫花时间排查不存在的问题。

AI 如果再接入自动修复流程，风险会更大。

它可能会根据不存在的函数、错误的版本范围、虚构的漏洞细节去生成补丁。

你会发现，这已经不是“AI 答错一道题”。

这是 AI 把错误包装成流程，进入了企业的安全系统。

所以，越自动化，越需要验证。

越像真的，越要查证。

好框架，也要留逃生舱

SwiftUI 的争议也类似。

SwiftUI 是 Apple 2019 年推出的声明式 UI 框架，目标是让开发者用更现代的方式构建 Apple 平台界面。

但七年过去，开发者社区对它的评价仍然分裂。

有人觉得它足够高效，能完成全新应用。

也有人觉得复杂场景下更新行为、性能表现、底层控制仍然不够稳，很多时候还得回到 UIKit、AppKit、Metal 或 Core Animation。

这类争论其实特别真实。

新工具不会因为理念先进，就天然适合所有场景。

声明式很好。

自动化很好。

AI 生成也很好。

但真正做项目的人，必须知道什么时候顺着工具走，什么时候停下来，什么时候回到底层。

我做工程监理其实也有类似感受。

现场不是图纸说什么就一定按什么走。

定额也不是万能答案。

遇到非常规工艺组价，既要懂规则，也要懂现场成本，还要能和业主、施工单位沟通清楚。

工具给你的是路径。

判断给你的是边界。

普通人别急着全自动

现在很多人一提 AI，就想全自动。

自动写代码。

自动修漏洞。

自动跑模型。

自动生成报告。

这当然是方向。

但你要知道，自动化不是把人拿掉。

自动化是把人放到更关键的位置。

以前人做重复动作。

以后人做判断、验收、取舍和兜底。

AI 工具越强，越会把低层动作变便宜。

但同时，它也会把错误放大得更快。

一个本地推理引擎跑起来了，你要判断它是否值得用于真实任务。

一个 CVE 出现在数据库里，你要判断它是否有供应商证据和可复现依据。

一个框架看起来现代，你要判断它是否适合当前项目复杂度。

这不是保守。

这是成熟。

未来普通人用 AI 做事，真正该练的不是“全部交给 AI”。

而是三种能力：

会验证事实。

会评估边界。

会设计兜底。

AI 不是让工程判断消失。

AI 是把工程判断推到了更显眼的位置。

谁能判断，谁就能交付。

谁只会相信，谁就容易踩坑。