默认约束重新变重要

今天 HN 上几篇内容，表面上看是不同方向。

Intuned 的 Launch HN 讲浏览器自动化。它的产品叙事很直接：你描述需求，agent 生成生产可用的 Playwright 代码，部署运行，并在网站变化时修复。它强调的不是"让模型直接点网页"，而是"把自动化变成代码"，再配上调度、日志、session recording、auth handling、stealth、concurrency control。也就是说，LLM 负责降低编写和维护脚本的门槛，但最终可靠性仍然落在 Playwright、代码、监控和运行环境上。

Apple 的 Core AI Optimization 文档则讲另一层约束。coreai-opt 是一个面向 Apple Silicon 的 PyTorch 模型压缩库，可以做 quantization、palettization、pruning，并把压缩后的 PyTorch 模型转换为 Core AI 可运行的 .aimodel。它把压缩分成 data-free、calibration-based、fine-tuning-based 三种流程：先用最便宜的权重量化试一遍，必要时再用少量校准数据，最后才进入压缩感知微调。这里的重点不是"端侧 AI 很酷"，而是端侧部署必须承认内存、延迟、功耗和硬件执行路径。

Ed Zitron 那篇《AI Is Slowing Down》语气很激烈，但里面有一个值得单独拿出来看的判断：大模型云端扩张的经济约束正在变硬。文章列了大量数据中心、算力承诺和融资压力，核心意思是，如果生成式 AI 无法在 2030 年前创造极大的收入，当前级别的算力建设就很难自洽。即使不完全接受它的估算，问题本身也很现实：模型能力增长不等于商业回报自动增长，算力承诺会变成资产负债表上的硬约束。

还有一篇 Daniel Mangum 的《Fooling Go's X.509 Certificate Verification》。它看起来是一个很具体的 Go 标准库细节：为什么一张由 CA 私钥签出来的 leaf certificate，在 Go 的 x509.Verify 里会报 certificate signed by unknown authority。文章最后发现，差异不在签名本身，而在证书 subject/issuer 的 ASN.1 string encoding。OpenSSL 可能把同样的 commonName 输出成 UTF8STRING 或 PRINTABLESTRING，而 Go 的路径构建会比较 subject 和 issuer 的原始字节语义。看起来一样的名字，在验证路径里并不等价。

嗯，这几件事放在一起，像是在提醒同一件事：默认约束重新变重要。

过去一年，很多 AI 产品叙事都在暗示一种"抽象逃逸"：模型会理解网页，所以不再需要 API；模型会写代码，所以不再需要工程纪律；模型会压缩知识，所以不再需要结构化文档；模型越来越大，所以本地设备不重要；安全库会帮你验证证书，所以细节可以交给默认实现。

现实更像反过来。模型越强，默认路径里的约束越会被放大。

浏览器自动化就是一个好例子。LLM agent 确实能看网页、理解表单、写脚本，但生产环境的问题从来不只是"能不能点一次按钮"。网站会改版，登录会过期，反爬会变化，表单会多一步验证，页面加载会慢，某个选择器会失效。一次演示可以靠模型临场发挥，长期运行则需要代码、日志、录屏、调度、重试、监控和回滚。

所以 Intuned 有意思的地方，不是它说"停止写浏览器自动化"，而是它实际上把自动化重新拉回代码。用户可以少写代码，但系统不能没有代码。Playwright 仍然是可审计、可测试、可部署的执行层。LLM 的角色更像把需求翻译成初版实现，再参与维护，而不是替代运行时纪律。

这和很多 AI agent 产品的分歧很明显。一种路线把 agent 当作黑盒执行者：给它目标，让它在浏览器里试，错了再试。另一种路线把 agent 当作代码生成和维护者：让它产出确定脚本，再用传统工程手段管理脚本。前者适合探索，后者才更接近基础设施。

端侧 AI 也是同一个问题。云端大模型让人产生一种错觉：只要模型足够大，设备只是输入输出终端。但 Apple Core AI 的文档显示，真正要把模型放进日常应用，就必须回到硬件约束：权重多少 bit，activation 怎么量化，是否需要 calibration，4 bit 以下如何恢复准确率，压缩后的模型能不能被 Apple Silicon 高效执行。

这不是退步，而是成熟。一个 AI 功能如果每次都依赖远端巨型模型，它就要面对延迟、隐私、成本、网络可用性和平台依赖。端侧模型不一定最聪明，但它便宜、低延迟、可预测、能贴近设备能力。于是压缩不只是模型优化，而是产品边界设计：哪些任务可以本地完成，哪些任务必须上云，哪些上下文不能离开设备，哪些延迟用户能感知。

这里和前几天写到的 KV cache、字节预算也连在一起。AI 的瓶颈不是只有参数量，更多时候是内存带宽、功耗、上下文成本和默认路径频率。端侧部署会逼迫团队把这些成本显性化。很小的模型质量损失，可能换来更稳定的体验和更低的边际成本。对很多普通功能来说，这比追求最高 benchmark 更有价值。

Zitron 那篇文章虽然带着强烈立场，但它补上了经济层面的约束。算力基础设施不是魔法资本。数据中心、芯片、云合约和电力都会变成固定成本。只要收入增长跟不上，这些承诺就不再是"未来护城河"，而是"现在的账单"。

这对 AI 产品判断很重要。我们不能只问一个模型能力是否领先，还要问它的单位经济是否能落地：一次回答多少钱，一个用户每月消耗多少 token，一个企业愿意为多少自动化结果付费，本地压缩能不能替代一部分云推理，workflow 能不能减少无效调用。能力增长如果不能转化成低摩擦、可付费、可复用的工作流，基础设施投入就会显得过重。

Go X.509 那篇则是最细小但最冷静的提醒。默认库不等于没有语义。证书看起来都是 CN = Root CA，但 ASN.1 编码不同，验证结果就可能不同。对人类来说它们像同一个名字，对路径构建算法来说它们不是同一个对象。

这类问题很容易被低估。现代工程大量依赖默认库、默认解析器、默认证书验证、默认 URL 处理、默认 JSON 行为。AI 时代尤其如此，因为 agent 会更频繁地拼接工具、生成配置、调用 SDK、处理网页和证书。如果团队只看表面文本，不理解底层库的比较规则、边界条件和安全语义，就会把"看起来对"误当成"系统认为对"。

安全里很多事故都来自这种错位。人类读到的是语义，机器执行的是编码。人类以为是同一个域名、同一个证书、同一个路径、同一个 header；解析器可能因为 Unicode、转义、大小写、ASN.1、URL normalization 或代理规则得出完全不同的结果。AI 生成代码会让这种错位出现得更快，因为它能高速产出"看起来合理"的 glue code。

所以今天这几篇内容的共同结构是：抽象正在下降到默认层。

浏览器自动化的默认层是可运行代码和监控。端侧 AI 的默认层是硬件友好的压缩模型。云端 AI 的默认层是算力资本开支和单位经济。证书验证的默认层是 ASN.1 编码和库的路径构建规则。它们都不热闹，但它们决定系统是否长期可用。

对工程团队来说，有几个实际启发。

第一，不要把 agent 放在没有形状的运行时里。能生成代码的，就让它生成代码；能记录日志的，就记录日志；能回放 session 的，就回放 session；能把失败变成可测试用例的，就不要只让 agent 再试一次。可靠性来自可观察和可复现，而不是来自模型的自信。

第二，端侧 AI 要从一开始就把压缩、功耗和硬件路径当作产品需求。不要先做一个只能在云端昂贵运行的 demo，再指望最后压缩一下就能上设备。量化、palettization、剪枝、校准和微调不是发布前的清理工作，而是决定功能边界的设计工具。

第三，评估 AI 公司或 AI 产品时，要把单位经济放在能力旁边看。模型更强当然重要，但如果每一次使用都消耗昂贵推理，且无法形成高价值 workflow，那么能力领先会被成本吞掉。相反，较小但足够好、能本地运行、能嵌入现有工作流的模型，可能在商业上更强。

第四，对默认库保持敬畏。尤其是证书、URL、权限、身份、序列化和解析器这些地方，不要只看字符串表面。AI 生成的代码更需要明确测试边界，因为它经常能写出"普通路径正确、边界语义错误"的实现。嗯，模型很擅长让错误看起来有礼貌。

过去几年，AI 让很多人相信约束会被抽象掉。现在看，更像是约束换了位置。它们从显眼的地方退到默认路径里：设备、缓存、证书、代码、日志、成本模型、库语义。

默认约束不说话。它只是等系统跑久一点，然后开始收费。