内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
软件工程师 Hillel Wayne 做了一场演讲，主题是如何在系统还没真正建好之前，就提前发现那些会导致故障的架构问题。他借用形式化方法里的一些思路，比如属性强度、状态空间验证和环境假设，帮助大家更早地揪出关键 bug。他提出“对抗式非确定性”这样的实用思维模型，用来推理并发、边界情况和分布式系统故障，而且不需要复杂的数学工具。对普通开发者来说，这意味着可以更早发现隐患、少走弯路，降低后期返工的风险。
提供的材料未提及具体可用工具。
Anthropic 的前沿红队用约 825 美元买了 15 台杂牌安卓电视盒子，把它们拼成一个小集群来跑 AI 模型，速度只有每秒 0.39 个词，慢得没法聊天，但适合那些不着急、没人等的后台任务。他们周一发布研究，认为小体积的开源模型可能再过几个月就能在廉价联网设备上自我复制，不再依赖数据中心。不过他们并没有做出能在公网上自行传播的 AI 蠕虫，实验是在受控环境里、并开了一些方便复制的后门。普通人可以留意：一旦这类能力成熟，海量廉价设备被悄悄用来跑 AI 并非不可能。
GitHub 改进了它用来扫描代码里密钥、密码等敏感信息的检测方式。以前用大型语言模型来判断，误报多、速度慢、成本高，因为很多看起来像密钥的字符串其实是测试用占位符或校验码。现在 GitHub 换成两段式流程：先用规则快速找出所有可疑字符串，再用一个专门训练的小模型 ModernBERT 结合文件路径、变量名和周围代码判断它是不是真的密钥。结果是用户接受警报的比例提高了 11.5%，扫描中位耗时降低 86%，服务器成本降低 98% 以上，并且这套方法已经用在提交前的拦截保护里。
EVE Online 的工程师 Nicholas Herring 在一场演讲中，介绍了这款已有 20 年历史的网游是如何做分布式追踪和可观测性的。难点在于游戏服务器实时处理海量事件，如果样样都记录，数据量太大、成本高，还可能拖慢游戏本身。他们的做法是在追踪一开始就决定采不采样（头部采样），并配合动态指数移动平均（EMA）和确定性采样，在保证数据能反映真实运行情况的同时控制开销。对做大型在线系统的读者来说，这是一套在“看得清”和“跑得快”之间取平衡的实战经验。
提供的材料未提及具体可用工具。
有人对比了 Delta Lake 上三种数据布局方式：Liquid Clustering、ZOrdering 和分区。所谓数据布局，就是数据在存储里怎么摆放，摆得好查询就快。作者在四类典型工作负载上做了测试，发现两个此前没被记录过的失效模式，可能已经影响到现在的生产系统。文章最后给出了一套选择布局策略的决策框架，帮助工程师按自己的场景挑合适方案。
Meta、MIT 和华盛顿大学的研究人员提出了一种叫“上下文语言模型”（CLM）的新方法。过去，语言模型的长上下文通常靠事先定好的规则来总结、压缩和检索信息，不够灵活。这次让模型自己决定怎么管理和修改上下文内容。研究人员表示，这种做法在性能和计算效率上都有明显提升。对读者来说，这意味着未来 AI 处理长对话、长文档时可能更聪明，同时更省算力，不过目前还只是研究阶段。
提供的材料未提及具体可用工具。
Matthew Liste 总结了他 20 多年做关键任务基础设施的经验，提出构建可扩展、可靠平台的 12 条核心原则。这些原则针对企业技术团队常见的问题：技术债越积越多、旧功能下线难、工程文化薄弱。他讲的是怎么设计基础设施平台，让系统更简单、开发流程更顺，并且能长期产生价值。对资深架构师和工程负责人来说，这是一份经验性的设计参考。
提供的材料未提及具体可用工具。
Red Hat 的 AI 安全团队做了一次横向对比，把三种安全护栏方案（专用分类器、LLM 当裁判、决策模型）放在同样的测试里跑，看哪一种最能拦住提示注入和有害内容。以前大家要么用专门训练的小分类器，要么花钱调大模型来判断，前者快但不够灵活，后者灵活但慢、贵。这次测试发现，一个约 2 亿参数的小分类器在提示注入上与 35B 大模型几乎打平（准确率 89.01% 对 89.31%），但响应时间只要约 54 毫秒，而大模型要 300 毫秒以上。这对开发者的意义是：如果护栏放在请求路径上，小模型能在普通笔记本 CPU 上跑，既省延迟也省成本。不过内容安全这块，决策模型反而更准，但成绩受提示词写法影响很大，还不能当作定论。Red Hat 计划把这两个分类器作为 OpenShift AI 3.6 的默认配置。
很多工程团队的数据散落在 CI、部署、安全扫描等不同系统里，同一个服务在不同系统中叫不同名字，工程师和 AI 每次问“这次部署为什么失败？”都要手动拼数据，答案还每次都变。文章提出用“软件交付知识图谱”解决：把实体、关系和数据格式用“schema 即代码”明确定义，再统一同步和查询，让跨系统的知识变得可靠、确定。还强调图谱质量取决于数据质量，需要监控数据填充率、记录数据来源、持续评估，否则图谱也会退化。文章以博客形式给出架构和指南，未说明配套产品何时可用。
提供的材料未提及具体可用工具。
AI 让软件开发变快，也让漏洞被找到和利用的速度变快。过去安全团队靠一张表格记录漏洞、按严重程度打分再排优先级，但现在漏洞太多，这种方法很难跟上。文章提出换个问法：不要只问“我们有多少个漏洞”，而要先问“哪些漏洞真的会给我们带来风险”。做法包括：用更干净的基础镜像和代码扫描减少漏洞进入系统，同时持续扫描真正在生产环境里运行的软件，并结合网络可达性判断风险。这样能帮团队少做“表面功夫”，把精力放在真正危险的地方。
提供的材料未提及具体可用工具。
销售副总裁让一个连着 Snowflake 的 AI 智能体查上季度收入，结果数字不对。检查发现管道任务全部按时跑完、日志也没报错，但底层表已经连续好几天少了约 22% 的行，还有三个关键字段几乎一半是空的，全程没有任何告警，等发现时报表和决策已经受影响。这篇文章讲的是：管道跑成功不代表表里的数据是对的，还要直接对表本身做检查，比如数据是否按时刷新、行数是否异常变化、字段空值或分布是否漂移、有没有重复记录，并用管道信息帮忙定位是源头、调度还是转换逻辑出的问题。这样能更早发现“管道正常但数据悄悄变坏”的情况，避免拿错数据做决策。
提供的材料未提及具体可用工具。
Datadog 的工程师把 Apache DataFusion（一个用来执行查询的引擎）从只能在一台机器上跑，改造成了可以跨多台机器跑同一个查询，这个项目叫 Distributed DataFusion。原来他们有很多不同系统各管一摊，数据没法方便地合在一起查，而 DataFusion 虽然好用但只在单机上执行，遇到超大数据量就慢。新框架把查询拆到多台机器上并行处理，同时让数据以流式方式传输，避免中间结果落地，小查询仍留在单机跑以免浪费。代码已开源，用 Rust 写，可在 GitHub 和 crates.io 获取，Apache 2.0 许可；在 12 节点集群的公开测试里，部分重型查询最多快了 10 倍，成本不变。
AI 编程智能体在写接口时，常常只检查“用户登录了吗”，却不检查“这条数据是不是他的”。比如让它写一个按编号查发票的接口，它会验证登录、查不到就返回 404，看起来都对，但任何人只要改一下 URL 里的编号，就能看到别家公司的发票。问题在于“发票属于某个组织、用户只能看自己组织的发票”这条规则存在于产品设计里，代码和提示词里都没写，所以智能体不知道要加。这类问题叫越权访问（BOLA/IDOR），在 OWASP Top 10 中排第一，传统扫描工具因为没有固定特征可匹配，很难自动发现，目前仍主要靠懂产品的人人工审查，或在查询条件里补上组织范围来修复。
提供的材料未提及具体可用工具。
当回答一个问题需要理清多条记录之间的关联时，普通向量检索可能不够用。比如问“哪个团队负责那个用了有漏洞的库的服务、哪些客户受影响、合同要求怎么通知”，向量搜索只能找出语义相近的文档，却无法证明哪些记录真正相关，可能把错误的服务版本或客户关联到一起。Graph RAG 的做法是把这些关系显式建成图：每条记录是一个节点，服务“使用”库、服务“支持”环境、合同“受制于”政策等关系成为带类型和方向的边，每条边都能追溯到来源并带生效日期。这样回答时先定位实体，再沿允许的关系遍历，最后取原文解释细节。两者配合使用，图的职责是回答“谁和谁相连”，原文负责回答“政策到底写了什么”。
一位安全从业者发现，公司员工早就在用各种AI工具干活了，但IT和安全团队根本不知道他们用了哪些工具、接触了哪些数据。问题在于，很多企业只会发文件说“AI该怎么用”，却没有提供一条方便又安全的实际使用路径，结果员工干脆自己找工具，风险反而更大。作者建议安全团队换个思路：先摸清AI在实际中怎么用、能碰哪些数据、能执行什么操作，然后为开发者提供经过审核的组件和隔离环境，把安全做成好用的默认选项，而不是事后审批的关卡。这样企业既能跟上AI落地速度，又不至于让每个新工具变成新的风险。
提供的材料未提及具体可用工具。