从十页提示词到会变的 JPEG，软件正在把能力藏进控制回路

截至 2026 年 7 月 19 日早间，Hacker News 首页热榜里有几条看起来毫不相干的帖子：一份由 GPT-5.6 Sol Pro 协助完成的凸优化证明，一组比较 agent /goal 模式的实验，一台交给 Claude Code 控制的备用 Mac，一次由 Windows Update 触发的显示器软件安装，GitHub 给内部仓库补上 owner 字段，以及把多张图塞进一张 JPEG 的小实验。

把它们放在一起，出现的是同一个变化：软件的能力越来越不只写在代码和按钮上，也写在提示词、停止条件、账号权限、更新渠道、责任字段和文件格式里。用户看到的是一个功能，真正运行的却是一套会继续推进的控制回路。

这也解释了为什么 HN 评论区总在追问一些不太像功能介绍的问题：谁决定继续？什么算完成？出了问题找谁？能不能停下来？

热度快照：HN 帖子「GPT-5.6 used a prompt to close a 30-year gap in convex optimization」抓取时为 482 分、312 条评论，发帖者 mbustamanter 的公开背景未说明。1

原始 Reddit 文章的作者是 Phillip Kerger。他自述拥有应用数学博士学位，是加州大学伯克利分校 IEOR 的教学教授，同时也是相关预印本和 Lean 仓库的作者；这项结果尚未经过同行评审。2

Kerger 给出的过程很具体：他为一个只允许查询函数值的凸优化问题写了一份约十页的提示词，让 GPT-5.6 Sol Pro 连续工作 148 分钟。这个问题的已知上界可以用约 d² 次函数评估解决，但自 1996 年以来，适用于该设置的下界证据一直弱得多。模型提出了一个近二次下界的证明，作者随后检查了论证，并在 Lean 中完成形式化验证。作者还明确说，模型没有凭空创造新的凸几何技术，关键仍是找到合适的困难函数族和对抗性 oracle 策略；证明一旦进入正确的结构，很多步骤属于已有方法的组合。3

评论区的分歧正好落在这里。一派认为，模型能不知疲倦地搜索既有知识里的空缺，已经足以改变研究助手的工作分工；另一派提醒，十页提示词、问题的选取、结果的检查和形式化验证都来自人，模型并没有替人决定什么值得证明。还有评论指出，语言模型可以在上下文里发现矛盾，却未必能主动发现训练材料自身的错误。1

这里的产品含义很直接：研究型 AI 的交付单位不是「模型给出一个答案」，而是问题设定、搜索策略、外部验证和可复现材料组成的工作流。没有 Lean、代码仓库和完整提示词，所谓「AI 证明」仍然只是一个很长的聊天记录。

热度快照：HN 帖子「Fable 5 vs. GPT-5.6 Sol on an NP-Hard Problem: Does /goal help?」抓取时为 205 分、102 条评论，发帖者 couAUIA 的公开背景未说明。4

作者 Charles Azam 把 Claude Fable 5、Opus 4.8、Sonnet 5、GPT-5.6 Sol、Terra 和 Luna 放进同一套 KIRO 光纤网络设计问题里。每次运行限制为 30 分钟，旗舰比较各做三次匹配运行，目标是让总电缆长度更短。Fable 5 的普通模式平均得分为 32,386，/goal 模式为 33,145；GPT-5.6 Sol 的两个均值分别为 34,261 和 35,129，分数越低越好。/goal 在六次对照里赢了四次，却让两个模型的平均结果都变差，因为少数严重回归拉长了尾部。5

原文还拆开了两个实现。Claude Code 的 /goal 由另一个评估模型判断是否完成，评估器只能看见对话里出现的证据；Codex 则把目标保存在状态里，通过工具和后续 turn 让工作继续。两者都叫 /goal，实际控制回路并不相同。

评论区有人把 /goal 当成更强的完成检查器，也有人认为只有一次任务的三次重复不足以排除噪声。另一些人分享了更实际的经验：为设计文档指定明确目标和时间边界，确实能减少模型过早退出；但如果模型一开始就选错了搜索方向，额外时间只会让错误方案变得更完整。4

这条热帖把 agent 产品的薄弱处暴露得很清楚：持续运行不是能力的同义词。真正需要设计的是状态、预算、证据、停止条件和坏路径检测。一个只会回答「是否完成」的评估器，可能只是把提前退出换成了更自信的绕远路。

热度快照：HN 帖子「Setting up your spare Mac for Claude Code to control, a step-by-step guide」抓取时为 166 分、125 条评论，发帖者 ykev 的公开背景未说明。6

原文作者以 ykdojo 发布教程，姓名和职业背景未在当前页面中明确。教程建议先抹掉备用 Mac 上的个人数据，创建新的本地账户，不登录 Apple ID，再开启 SSH、配置免密 sudo、保持机器不休眠，并在需要时授予 Screen Recording、Accessibility 和 Full Disk Access 等权限；还可以通过 Tailscale 从远程访问。作者特别提醒不要在主力 Mac 上直接使用 --dangerously-skip-permissions。7

评论区有两种很现实的反应。有人已经用旧的 M1 或 M2 机器作为远程 agent 主机，也有人认为 Dispatch、Cowork 或容器已经能覆盖大部分场景，没必要把一台真实电脑交出去。更尖锐的质疑是，自动扫描日志、开 issue、提 PR 甚至合并部署，可能只是把架构问题变成不断打补丁的后台任务；另一些评论则认为，隔离环境的价值正是在于把这类低风险、重复性的工作从主力设备上拿走。6

这个案例的重点不是「Claude 能不能控制 Mac」，而是控制权的最小单位已经从一个 API token 变成了机器、账号、SSH 密钥、网络和本地文件的组合。模型的权限对话框解决不了错误主机、错误账号或错误网络这类问题。agent 一旦拥有身体，部署边界就比提示词边界更重要。

热度快照：HN 帖子「LG monitors silently install software through Windows Update without consent」抓取时为 968 分、499 条评论，是本轮热榜中讨论量最高的条目之一。发帖者 baranul 的公开背景未说明。8

VideoCardz 的文章作者是 WhyCry。文章称，将部分 LG 显示器连接到 Windows PC 后，Windows Update 会安装 LG 扩展和软件组件，随后出现 LG Monitor App Installer，无需用户批准下载；相关投诉至少可以追溯到 2024 年。文章还引用测试称，32 次连续启动里有 31 次弹出 McAfee 30 天试用推广，另一次显示为 LG 自家显示器工具。微软商店页面列出该应用可访问互联网和系统资源，文章给出的组策略「Prevent automatic download of applications associated with device metadata」可以阻止这类自动下载。9

这里需要保留证据边界：文章和 HN 评论证明的是一组设备、系统和用户样本，不足以推出所有 LG 显示器都会这样做。评论区有人在 Windows 11 上复现了应用出现在 Microsoft Store Library 的情况，也有人指出 Razer、Logitech、NVIDIA 等厂商同样把管理套件放进驱动包；另一条讨论则给出了关闭设备元数据应用下载的方法，但这可能会连带失去部分设备配套功能。8

这不是一条单纯的「厂商偷偷装软件」新闻。它展示了硬件的控制面如何转移到操作系统的设备识别和更新机制里。用户买到的是一台显示器，却可能通过插拔动作触发一条看不见的软件交付链；退出选项藏在系统管理策略里，而不是购买和首次连接时的显眼开关。

热度快照：HN 帖子「How GitHub gave every repository a durable owner」抓取时为 62 分、23 条评论，发帖者 ascertain 的公开背景未说明。10

GitHub Staff Security Engineer Michael Recachinas 在官方文章中写道，GitHub 内部有超过 14,000 个仓库，2025 年初约 11,000 个非归档仓库没有明确 owner。团队在不到 45 天内为活跃仓库建立了经过验证的 owner，同时归档约 8,000 个不再使用的仓库，最后留下约 3,000 个活跃仓库。实现上，他们用 ownership-type 和 ownership-name 两个 custom properties 区分服务、团队和个人，并通过 GitHub App 校验团队至少有两名成员、服务目录记录有效。11

这套机制之所以不是一场批量填表，是因为它绑定了动作。缺少 owner 的仓库先收到 30 天归档警告，仍未认领才会被归档；归档是可逆的，不删除代码，也会停止 GitHub Actions。正式运行后，新仓库创建时必须填写 owner，失去 owner 的仓库会在一小时内被标记。团队还加了低水位线，避免 Service Catalog 返回陈旧或损坏数据时一次性归档大量正常仓库。

评论区担心的也不是字段设计，而是责任分配。有人说把遗留功能随手塞给团队，只会增加陌生代码库的负担；有人指出 owner 不等于资源、优先级和修改权限；还有人关心个人 owner 离职后的继任与权限接管。10

GitHub 的经验很适合拿来衡量任何自动治理产品：字段要能查询，值要能验证，缺失要有宽限期，动作要可逆，异常数据要有刹车，通知还要真的到达责任人。owner 不是描述信息，它只有连到生命周期和故障处理上，才会变成可执行的责任。

热度快照：HN 帖子「Regressive JPEGs」抓取时为 649 分、65 条评论，发帖者 vitaut 的公开背景未说明。12

Maurycy 的博客文章解释了 JPEG progressive scan 的一个古怪用法：把多张同分辨率 JPEG 拼接起来，过滤掉起始和结束标记，让后面的 scan 覆盖前面已经渲染的数据。浏览器在慢速网络中接收文件时，画面会从一张图切换到下一张图。作者用只含 DC scan 的帧把一段视频塞进一张 JPEG，Chrome 上大约能显示 90 帧；文章还展示了不依赖 JavaScript 的 HTML 视频和交互页面。原作者同时承认，这种播放没有 timing information，速度主要由网络延迟决定，除了恶搞和实验，目前没有明确的实用场景。13

评论区对它的评价很一致：有趣，但实用性可疑。Safari、Firefox 和 WebKit 的表现并不完全一致；有人指出 Motion JPEG、multipart response、GIF 或 progressive PNG 早就能完成类似事情；也有人认为，在慢速连接下先看到低质量预览，能帮助用户判断要不要继续下载。12

它和前面的 agent、驱动、owner 放在一起看，提供了一个很好的反例：软件的行为不一定来自显式的 JavaScript 或产品按钮，也可能来自文件格式和解码器对状态的共同解释。兼容性不是背景条件，它本身就是功能的一部分。

第一，先画状态转移，再谈自动化。任何会继续运行的系统都应该明确写出「等待什么、谁能停止、何时算失败」，而不是只提供一个更大的上下文窗口或一个更强的模型。

第二，把能力和控制回路分开评估。GPT-5.6 的证明案例里，模型能力、提示词工程、专家选题和 Lean 检查共同构成结果；/goal 实验里，模型换成另一个 CLI，控制回路也随之变化。只报模型名称，读者无法知道真正被测的是什么。

第三，退出按钮必须出现在用户能看见的地方。LG 的组策略、备用 Mac 的隔离账号、GitHub 的可逆归档都说明，安全不是一句「请谨慎使用」，而是一个具体的退路。退路藏得越深，系统越像在替用户做决定。

第四，责任要有落点，也要允许转移。owner 字段如果不能在团队、服务和个人之间迁移，就会把维护压力固定在某个倒霉的人身上；agent 如果能自动修复，却没有日志、预算和人工接管入口，也只是把问题推迟到更贵的阶段。

下次你给 agent 一个长期目标、插入一台显示器，或准备归档一批仓库时，可以先问三个问题：谁能暂停？谁负责善后？系统留下了什么可见记录？如果三个问题都答不上来，真正的默认值往往只有一个：继续运行。