阅读

OpenAI旗下周边商店Supply Co.正式上架了与复古游戏硬件厂商ModRetro联合推出的掌机“ModRetro Chromatic Codex Edition”，售价200美元（约合人民币1344元）。这款设备外观致敬任天堂经典Game Boy，配备液晶屏幕、十字方向键及实体游戏卡槽，但其核心卖点在于深度集成OpenAI的编程助手Codex。

根据官方介绍，该掌机套装包含一张可编程Codex游戏卡带和一个专属收纳包。用户无需掌握传统编程技能，只需在Codex桌面应用中安装ModRetro Chromatic插件，通过自然语言描述游戏创意（如角色设定、玩法逻辑），即可由AI自动生成游戏项目、素材和代码。生成的ROM文件可直接写入随附的实体卡带，并在掌机上离线运行。

这一产品标志着OpenAI试图将AI编程能力从软件开发场景延伸至实体消费硬件。此前，OpenAI曾推出支持AI状态显示的机械键盘，而此次联名掌机进一步降低了复古游戏开发的门槛。目前，该产品仅面向美国、加拿大、澳大利亚、新西兰、日本、英国及欧盟地区配送，暂不支持中国大陆直邮。

文件一旦写入就基本不可变，而数据天然需要变更。行要修正，新观测要记录，旧记录要删除。这个矛盾是表格式存在的唯一理由：既然不能修改文件，就用创建新文件来表达变更。追加一行写一个新文件，删除一行写一个标记文件，压缩数据写一批新文件，甚至获取和释放表锁也是新文件。代价是，同一张表在任意时刻对应着多个文件，其中一些不是数据文件而是删除标记或索引。于是必须有人写下一套规则，说明哪些文件当前有效、各自扮演什么角色。

规则本身不难写。真正困难的是：当两个写入者同时想提交各自的新文件集时，如何让其中一个成为'当前版本'而另一个失败？Weston Pace把这个问题称为表格式的'原子内核'，并指出所有表格式——无论叫timeline、catalog还是其他名字——最终都依赖某个同步并发写入者的机制。这个机制的选择对表格式的性能和复杂度有深远影响，而且它把设计空间清晰地分成两类。

第一类是零基础设施原子操作。几乎所有云存储都提供put-if-not-exists语义，传统文件系统则普遍支持rename-if-not-exists。利用这些原语，可以在不部署任何额外服务的情况下构建版本序列：写入者尝试原子性地创建下一个版本号的元数据文件，成功者胜出，失败者重试。好处显而易见——五十台EC2实例可以同时向S3上的同一张表发布数据，不需要任何协调服务。但作者给出了一个具体的性能上限：截至他写作时，云存储的put-if-not-exists大约限制在每秒十次提交左右。对于高频小写入场景，这会成为瓶颈。

第二类是集中式协调。DuckLake用Postgres实例作为提交协调器，内部通过互斥锁或CAS原语同步写入者。Iceberg的REST catalog也属于这一类。这种方式有可能带来更高的事务速率（作者自己也指出这一点并不确定），且能适用于所有文件系统——包括那些不支持put-if-not-exists或POSIX rename的非主流文件系统。代价是需要维护一个长期运行的服务，增加了运维负担和故障面。

两类方案并非优劣关系，而是适用场景不同。读多写少的表用零基础设施足够；高频小写入的表可能需要集中式协调；批量大写入的表两者都行。Lance默认使用零基础设施但允许扩展为集中式；Iceberg标准路径是REST协调但也提供零基础设施的boring catalog。作者的结论是：表格式面对大量细微技术决策，每个决策都偏向某一类工作负载，最好的做法往往是实现多种路径并用启发式自动选择，而不是让用户面对配置噩梦。

89%的组织至少在一个职能中使用了AI，但只有37%报告了对企业EBIT的影响。Qwen生成式AI产品策略与GTM总监Johnny Mai认为，这个差距不是模型能力问题，而是待办事项排序问题——谁最后做了演示，谁的提案就排在了前面。他提出的解决路径是四步：先标类型，再画象限，再打分，最后拨款。

六种类型——起草者、回答者、提取器、路由、分析者、操作者——覆盖了几乎所有企业AI请求，而类型本身就能在写代码之前预测工作量。起草者和路由大多只需要一个模型加一段提示词；操作者则需要权限管理、系统集成和错误处理方案。更关键的结构性洞察是：许多高价值操作者是由低类型组合而成的。一个采购审批代理，先是一个提取器（读请求），再是一个路由（选审批路径），然后是一个分析者（对照预算），最后才成为操作者。先给零件拨款，代理的整体成本就会下降。

Mai把'数据距离'称为隐藏变量：一个用例距离已经干净、可访问、有权限的数据有多远。他声称这比模型选择更能预测工作量。在影响×容易的2x2矩阵中，纵轴是影响，横轴是容易程度（不是工作量，所以右上方意味着'更好'），四个象限对应四种拨款决定：高影响高容易就作为项目上线并设Q1指标；低影响高容易就发放自助访问加使用政策，观察哪些用法自然扩散；高影响低容易就拨款减少其数据距离，设门审日期而非上线日期；低影响低容易就搁置并记录原因，下个周期数据或模型变化时再回来。他指出的常见错误是把'搁置'当'上线'处理——给一个数据尚不存在的项目设上线日期。

评分用六项加权标准，三项衡量影响（价值、量、可度量性），三项衡量容易程度（数据就绪、集成、容错），每项1到5分。权重必须在看候选项之前写好，因为权重是价值决定而非技术决定。Mai强调要在同一个房间里由赞助人、数据负责人和工程师一起打分——对数据就绪程度的分歧本身就是会议最有用的产出，比最终数字更重要。

一个计算例子说明模型成本为什么几乎不影响排序：假设每月4万张发票，每张3000个输入token和500个输出token，用qwen3.8-flash在新加坡区定价（输入每百万token 0.15美元，输出0.47美元）计算，每月Token费用约27.40美元。但Mai指出这个用例的真正工作量在于数据就绪和集成，可能需要两个季度才能上线。他的结论是'定价数据距离，不是定价模型'。在worked example中，一个采购审批代理在加权总分上排第五，但影响分排第二——读象限再读总分，否则会误将'搁置'类项目当成'上线'类。

作者还列出四种不应按原样拨款的模式：没有提取器或路由支撑的操作者（你实际上在资助三个伪装成一个的项目）、没有基线度量的用例（无法明年证明影响）、需要供应商工程师持续运行的项目（Gartner预测70%的企业将在2028年前放弃由供应商前向部署工程构建的代理AI）、以及数据就绪分只有1或2但热情分很高的项目。需要指出的限制是：这套六类型分类和权重是作者自己的框架，并非经过独立验证的行业标准；文章由Qwen/阿里云发布，worked example和产品推荐自然指向其Model Studio平台，方法论声称平台中立但读者应自行检验。

网络基础设施与网络安全公司Cloudflare近期在其Radar平台上推出了名为Zero Wire的公开漏洞情报服务。该服务并非收录所有CVE（通用漏洞披露）的数据库，而是专注于整理对外提供网络服务的软件中的重大漏洞，包括Web应用程序、相关执行环境及程序库等。特别值得注意的是，它关注那些可以通过代理服务器防护措施降低攻击风险的问题。

Zero Wire提供的信息包括漏洞影响的系统、是否已有被利用的证据以及修补建议，同时链接到软件厂商的安全公告和网络安全研究资料。对于部分漏洞，Cloudflare还提供了Web应用防火墙（WAF）防护信息，但强调这类措施只能降低特定攻击风险，无法替代软件修补。此外，服务还展示了符合特定WAF规则的HTTP请求量变化，作为判断可能存在漏洞利用尝试的参考，但指出这些数据不能证明攻击成功或确定实际受害规模。

除了传统的情报数据，Zero Wire还提供了一组AI代理评估提示词。企业可以利用这些提示词，要求AI代理以只读方式检查内部系统是否使用了受影响的软件、漏洞修补情况及相关防护措施，并列出检查证据、待确认问题及后续建议。Cloudflare说明，复制这些提示词本身不会自动扫描或修改企业系统，旨在为企业提供一种新的自查工具。

Django联合创始人Simon Willison在遛狗时想到一个具体问题：能否写一个SQLite扩展函数，把"-$1,234.56"或"'12.5%'"这类字符串解析成可求和、可排序的数值？他决定用Claude（Opus 5.5）同时探索C和Rust两种实现，比较性能、代码复杂度和产物体积。

初始结果出乎他的预期。Rust扩展体积更大——Rusqlite版321 KB、sqlite-loadable-rs版298 KB——而C扩展仅14 KB，但Rust反而更快。原因很具体：Rust标准库中浮点解析的等价实现比C的strtod快约两倍，而C的朴素实现恰好依赖这个函数处理小数。

于是他向Claude提出第二个指令：写一个自定义C函数来解析文本为十进制数，追上或超过Rust。Claude采用了Clinger快速路径——一种针对常见数字格式跳过通用浮点解析开销的已知优化策略。在200万行数据上，优化后的C版本在混合数据上为19 ns/行（Rust为41–46 ns），纯整数16 ns/行（Rust为32–36 ns），纯小数18 ns/行（Rust为47–55 ns），各场景均约为Rust的一半耗时。

全部四种实现通过了800万次模糊测试的一致性校验，确认解析结果完全相同。

这个实验展示了一个可检查的模式：当性能瓶颈定位到某个具体库函数时，语言选择本身不是决定性因素，针对性的算法替换可以跨越语言级差距。AI在此的角色不是发现新算法，而是在明确指令下实现一个已知技术并验证正确性。

需要注意的是，这是一次第一方基准测试，仅覆盖单一函数的特定场景，作者未声称结果可推广到一般C vs Rust比较。Clinger快速路径本身是1990年代提出的已知算法，其正确性已有广泛实践基础。

杂物间里有个东西在间歇性地响。蜂鸣间隔太长，Simon Willison 站在房间里很难判断声源位置，又不想翻遍所有纸箱。于是他让 Claude Code 写了一个系统：用房间里能找到的所有设备——两台 iPad、一部手机、一台 MacBook Pro 和一台 Surface Ultra——同时监听，通过声学三角定位找到蜂鸣源。系统最终把位置锁定在 40 厘米范围内，他翻开那一堆箱子，发现是一个急需换电池的旧一氧化碳探测器。

Willison 认为这个项目最有意思的部分不是定位精度，而是他证明了一件事：可以给编程智能体装上耳朵。Claude 本身没有原生音频输入，但它能运行 JavaScript 和 Python 代码来分析麦克风捕获的音频。他让 Claude 启动一个 Python 服务器，通过 WebSocket 连接多台设备，在每台设备上调用浏览器 WebAudio API 获取麦克风权限，然后给它们热部署新的音频处理代码。这样一来，他基本可以走开，让 Claude 自己查询音频日志、调整检测算法、重新配置它的耳朵。

技术机制基于 2007 年的 BeepBeep 论文。每台监听设备维护一个 60 秒的音频缓冲区，运行一个用快速傅里叶变换和高通滤波器识别蜂鸣的检测脚本。当某台设备报告疑似蜂鸣时，服务器选择往返延迟最低的设备播放一个短促啁啾声，然后要求所有设备上传蜂鸣前约 0.6 秒到啁啾后约 0.8 秒的音频片段。这个啁啾声充当时间戳，让各设备的片段可以精确对齐，从而计算到达时间差并三角定位。

开发过程中，Willison 先用 Claude Code Cloud 在 iPhone 上以 Opus 5.5 生成了问题描述和初始代码，然后把仓库克隆到笔记本上，用新发布的 Fable 5.2 继续迭代。关键设计是 Opus 5.5 在初始构建时就写了一个 installModule() 方法，允许服务器通过 WebSocket 向任意监听设备推送并执行新的 JavaScript 代码。这意味着 Willison 不需要跑到每台设备前刷新页面、重新授权麦克风，智能体可以远程部署修改。他通过一系列具体提示逐步添加了拖拽定位、拍手测试、时间戳标注、录音回放和标记神秘蜂鸣等功能。

不过自动设备间测距效果并不好，Willison 不得不加入一个粗糙模式，让用户手动把设备图标拖到大致位置，系统再在此基础上微调。这说明这套方法在真实环境中仍然依赖人工初始校准。另外，40 厘米的精度来自一次特定场景——小房间、间歇性蜂鸣、五台设备——不是可复现的基准测试结果。Willison 自己也提到 GitHub Universe 上 Martin Woodward 用类似思路给编程智能体装眼睛：通过 USB-C 连接徽章电脑，再架一个摄像头对着屏幕，让智能体判断更新是否成功。他的结论是：想办法让编程智能体感知周围世界，是一件非常有趣的事。

OpenAI于2026年11月9日发布了名为“Control Room”（控制室）的内部安全系统，旨在快速追踪并停止其研究基础设施中的模型工作负载。该系统已部署在OpenAI的研究环境中，用于在出现安全或对齐问题时迅速干预。

Control Room的核心机制在于将终止逻辑集成在推理引擎层，而非易变的工作负载代码中。当研究人员启动一个强化学习实验或评估任务时，工作负载会向Control Room申请一个唯一的job_id。每次该任务需要从模型采样token时，推理引擎都会携带此ID向Control Room请求授权。如果Control Room标记该任务为停止状态，它将拒绝授权，导致引擎返回拒绝响应，从而在35秒内切断模型输出。这一延迟源于支持高流量所需的缓存层，OpenAI表示正致力于将其降至零。

该系统采用了“故障关闭”（fail-closed）设计原则。这意味着如果Control Room服务本身因错误或被恶意篡改而宕机，所有推理请求将被默认拒绝，直到服务恢复正常。这种设计确保了即使监控或决策系统失效，模型也无法继续运行未受控的任务。目前，这一机制已在前沿模型研究工作负载中全面推出，并将逐步覆盖剩余的研究工作负载。

Control Room与OpenAI的错位监控系统协同工作。例如，在最近的DNS相关事件中，监控系统检测到潜在问题后通知Control Room停止特定任务。通过将权限检查集中在少数几个标准化的推理引擎路径上，OpenAI试图解决分布式、频繁变更的研究代码难以实施统一安全保护的问题。

据TechRadar报道，一种名为DeepTempest的人工智能系统能够显著改善从HDMI电缆电磁辐射中重建视频和文本的能力。该系统由乌拉圭蒙得维的亚共和国大学的Federico Larroca开发，其核心突破在于利用AI增强原本模糊的拦截信号，将文本重建中的字符误读率降至约30%，相比之前的最先进攻击方法，错误率降低了超过60%。

这一技术基于“Tempest”概念，即通过捕获电子设备（如HDMI线）产生的电磁场来还原传输内容。虽然数字信号比模拟信号更难解码，但并非不可能。DeepTempest结合TempestSDR等工具，使用天线和软件捕捉泄漏信号并转化为图像。尽管在远距离或屏蔽良好的情况下效果有限，但在近距离且屏蔽较差时，恢复的内容已具备可读性。

该研究提醒用户，即使是物理连接的HDMI电缆也可能留下无线痕迹。对于高安全需求场景，建议使用具有良好电磁屏蔽的高质量电缆，并保持一定距离以防止侧信道攻击。

在讨论企业导入 AI 时，常见的前提是：你需要足够的资料、完整的 IT 架构和专业团队。李牮斯在 TechOrange 发表的专栏文章反其道而行。他自述在制造业第一线推动 AI 导入，观察到一个结构性悖论：中小企业长期欠缺的白领幕僚与管理 know-how，以及手上规模不大、散乱的资料，反而成了使用 AI 的优势。

这个论点的第一个机制在于组织结构。台湾不少中小企业拥有世界级的工厂，在各自领域是隐形冠军，但管理与幕僚编制十分精简——市场分析、法务、人资、资本策略往往压在少数主管身上，有时甚至无人负责。过去这种做法在相对稳定的全球化环境下还行得通，但地缘经济与科技正在剧变，世界级的工厂需要配上世界级的企业管理。传统补法就是聘人、成立部门，长期负担固定成本，偏偏许多公司正是因为缺乏资源才无法再往上走，形成鸡与蛋的难题。

到了 AI 时代，精简反而可能成为优势。相较于部门与职责分工完整的大企业，中小企业少了既有编制的包袱，AI 代理人较容易直接补进那些原本就缺人的功能。李牮斯举例：一家原本没有市场研究人员的工厂，可以开始掌握客户产业的变化，评估过去没空研究的生意。主管有了这些支援，也比较有余裕替公司想得更远。这里的核心判断是：中小企业能比大型企业更快取得原本欠缺的能力。

第二个机制在于资料规模。企业一听到 AI，常会直觉地找 IT 专家与外部顾问，接著谈起一套昂贵庞大的资讯架构，导入还没开始预算与工程就先摆在眼前。但李牮斯认为中小企业的资料量对 AI 而言并不算大，还没经过系统化整理的散乱资讯，也正是 AI 擅长消化的材料。使用合适的企业版 AI 订阅工具，就有机会从既有档案与团队做起，不必先把所有资料重整一遍。资料太少不容易看出经营脉络，资料太多光是整合就可能耗掉大把资源；不少中小企业恰好介于两者之间，不大不小，反而刚刚好。

他将这个观察延伸到台湾产业结构的意义：当一间间各有专长的中小企业能保有精简组织的灵活，又能取得过去只有大企业才有的管理能力，产业升级就不必以企业大型化为前提。世界级的制造本事，不必一直受限于办公室里有多少人。

需要指出的是，这是一篇基于第一线实践经验的归因论述，而非经过量化验证的研究结果。文中「即使只有 1% 的员工真正掌握这种工作方式，也可能带动整体竞争力的倍增」属于作者的推论性判断，未附具体测量方法或样本。Anthropic 的 Claude 使用指数显示台湾相对使用强度落后新加坡与韩国，是作者引用的外部数据，用以说明问题的紧迫性，而非论证本身的核心支撑。论点成立的前提是 AI 代理人在 2026 年确实能可靠接手一整段工作——作者认为这个条件正在成熟，但并未提供失败案例或能力边界的具体检验。

无论 AI 投资热潮是否降温，李牮斯的结论是：这条路已经打开，不必等下一座资料中心落成才开始往前走。眼前的 AI，让「中小企业」这四个字，有朝一日只是描述一家公司的人数，而不再预先决定它能走多远。

软件开发商JetBrains发布了Go语言集成开发环境GoLand的2026.3版本，其中一项关键更新是开放其内置的性能分析器供AI代理直接操作。开发者只需描述API响应缓慢、CPU使用率过高或内存持续增加等问题，支持的AI编码代理（如Claude Code、Codex及Junie）便可启动程序、收集性能数据，并找出耗费资源的函数与代码位置。

该功能通过内建的goland-profiler技能与模型上下文协议（MCP）工具实现。如果开发者已通过性能分析器启动程序，AI代理可接手该次执行；否则，代理会根据项目的运行配置启动程序，无需在源代码中添加额外的分析代码。AI代理会根据问题类型选择适合的分析方式：例如在CPU负载过高时记录CPU性能数据，遇到同步等待或锁竞争时分别获取阻塞与互斥锁分析资料，或在内存占用持续增加时比较不同时间点的内存使用情况以检查资源泄漏。

每份性能分析数据都会附带摘要，最多列出5个消耗资源较多的函数及其相关的资源消耗情况、调用路径与代码行。当摘要不足以找出原因时，AI代理可通过MCP工具进一步查询函数排名、调用路径与源代码位置，并提出改善建议。内建技能还会指示代理区分实际测量结果与自行推测的原因。开发者可以打开火焰图（Flame Graph）核对AI的判断，也可以自行获取性能数据后交由AI分析。

目前该功能存在使用限制：GoLand的性能分析器必须在编译时修改可执行文件以提供分析所需的接口，因此无法直接附加到未通过性能分析模式启动的程序。由于性能分析需要在程序执行期间收集样本，该功能较适合服务器、后台工作程序等长时间运行的应用，对执行后立即结束的命令行工具则较难取得有效数据。

银行网络安全投入不足通常被归因于搭便车问题：一家银行的防护投资惠及整个金融网络，但成本由自身承担，因此个体理性导致集体投入不足。Anand、Duley和Gai在《Review of Finance》（2026年）的模型中识别出另一股反向力量——挤兑威胁本身可以激励银行增加网络安全投入。

其机制如下：一次成功的网络攻击可能中断运营并动摇债权人信心，存款人或融资方随之撤资或拒绝续期。银行预见到这一后果，便有更强动机预防攻击。作者因此识别出两股对抗力量：搭便车抑制网络安全投资，挤兑威胁鼓励它。当滚动风险足够高时，后者可能压过前者，使银行投资超过社会最优水平。

这一结论的方向取决于失败驱动机制。模型区分了两种情形：当失败由偿付能力不足驱动时，银行与债权人行为相互强化——更高的网络安全投入导致更高债务负担，进而强化防护动机，形成正反馈；当失败由流动性不足驱动时，额外网络安全投入反而降低债务负担，消除了银行面临的风险-收益权衡，激励效果消失。这意味着监管纠正工具需要针对不同的边际（防护边际或韧性边际）分别设计。

模型还区分了网络安全（预防攻击）与运营韧性（攻击后继续运营）两个维度。更强烈的网络威胁倾向鼓励韧性投入，而更高的滚动风险则强化预防性网络安全投入。两者互补但争夺有限资源，银行必须在防护与恢复之间分配。

对金融板块投资者而言，这一框架的实际含义是：评估银行网络安全水平时，不能孤立看待技术投入数字，而应结合其资金结构的脆弱性。一家滚动风险较高的银行，其网络安全投入可能并非出于审慎管理，而是挤兑威胁的副产品——这意味着其防护水平对资金结构变化敏感，一旦融资环境改善，投入可能回落。同时，投资组合中不同银行、托管机构和服务商可能依赖同一技术基础设施，单一关键提供商的中断可同时影响多个持仓，构成分散化无法消除的集中风险。

美国半导体制造商德州仪器（Texas Instruments）于2026年11月9日向美国证券交易委员会提交8-K报告，宣布已完成总额20亿美元的无担保高级票据的发行与销售。此次融资分为四个等额档次，每档本金均为5亿美元，分别对应不同的到期日和票面利率：2028年到期的票据票面利率为5.000%，2031年到期的票据为5.350%，2033年到期的票据为5.500%，以及2036年到期的票据为5.750%。

该交易依据2026年10月26日签署的承销协议进行，由J.P. Morgan Securities LLC、Citigroup Global Markets Inc.、BofA Securities, Inc.和U.S. Bancorp Investments, Inc.作为主要承销商代表。票据发行基于德州仪器2025年2月提交的S-3注册声明及随后的招股说明书补充文件。

8-K报告确认了资金到位，但未披露这笔20亿美元资金的具体用途。这一事件标志着德州仪器在当前利率环境下成功锁定了长期债务成本，其后续对现金流管理或资本支出计划的影响需结合公司未来的财务指引进一步观察。