当生成变便宜之后

今天 HN 上几篇文章很适合放在一起读。

第一篇是论文《Do Transformers Need Three Projections?》。它问了一个看似很底层的问题：Transformer attention 真的需要独立的 Q、K、V 三个投影吗？作者系统测试了几种投影共享方式，结果发现，至少在一些语言模型和视觉任务上，共享 key-value 的 Q-K=V 变体可以接近标准 QKV 的效果。在语言模型里，这种方式能把 KV cache 减少 50%，困惑度只退化约 3.1%。更有意思的是，它还能和 GQA、MQA 叠加：Q-K=V 加 GQA-4 可减少 87.5% cache，和 MQA 组合甚至达到 96.9% 的 cache reduction。

第二篇是华为 CSL 的 KVarN。它也是围绕 KV cache，但路径不同。KVarN 不是减少结构里的投影，而是把已经生成的 KV cache 量化得更好。它用 Hadamard rotation 扩散 channel outlier，再用类似 Sinkhorn 的方差归一化把 tile 内误差压平，最后用低 bit 存储。它宣称在 Qwen3-32B 等场景下能获得 3 到 5 倍 KV cache 容量，吞吐甚至高于 FP16，同时保持接近 FP16 的准确率。无论最终实测如何，它抓住的瓶颈很明确：长上下文和 agentic workload 不是只缺模型能力，而是缺可承受的记忆带宽和缓存容量。

第三篇是 Anthropic 开源的 defending-code-reference-harness。它把 AI 漏洞发现拆成 recon、find、verify、report、patch 几个阶段，强调这是 reference harness，不是拿来即用的万能产品。它内置 threat modeling、vuln scan、triage、patch 等 Claude Code skills，也强调真正会执行目标代码的自动 pipeline 必须放在 gVisor sandbox 里，限制挂载和网络出口。这里的重点不是"AI 能不能找漏洞"，而是把发现、验证、补丁和隔离做成一条可审计流程。

第四篇是 Ashby 的工程文化文章。它说，从 2025 年 8 月开始，Ashby 生产系统里超过一半新增代码由 AI 生成，但客户问题没有明显恶化。他们的结论不是"工程师不重要了"，而是相反：工程师的判断、品味、对客户问题的理解变得更重要。文章里有一句很实在的话：你对自己发布的东西负责，不管每一行是手写的，还是 LLM 生成的。AI 让无脑推进变得很容易，所以工程师反而要更努力地思考。

这几篇材料的共同点，是都在回答同一个问题：当生成变便宜之后，什么会变贵？

答案不是单一的。对模型推理来说，记忆变贵。对软件工程来说，判断变贵。对安全团队来说，验证变贵。对组织来说，责任边界变贵。

过去我们常把 AI 进步理解成"生成能力提升"。模型会写更多代码，会读更多文档，会生成更长答案，会并行跑更多 agent。但生成只是系统的一段。生成之后，内容要被保存、检索、验证、合并、回滚、解释、归责。生成越便宜，下游越容易被淹没。

KV cache 是这个问题最物理的一面。长上下文推理时，模型每生成一个 token 都要保留前面 token 的 key 和 value。上下文越长、并发越高、模型越大，KV cache 越快成为显存瓶颈。于是 QKV projection sharing 和 KVarN 看起来像底层优化，其实是在争夺 AI 系统的默认运行边界：同一块 GPU 能容纳多少上下文，能服务多少并发，agent 能记住多少历史，成本能不能进入可用区间。

这和昨天写到的"字节预算"有连续性。不同的是，今天的字节不只是网络包和 cache line，而是模型的工作记忆。上下文窗口看起来越来越大，但真正决定系统可用性的不是最大窗口，而是单位请求的记忆成本。一个 agent 如果每轮都把所有历史、所有工具输出、所有检索块塞进上下文，就像把冷字段塞进热路径。模型也许还能跑，但成本和延迟会悄悄吞掉产品边界。

所以 QKV 共享和 KV cache 量化的价值，不只是"省显存"。它们在重新定义哪些信息必须保留高精度，哪些信息可以压缩，哪些结构本来就冗余。Q-K=V 的论文有一个关键观察：keys 和 values 可能处在相似的表示空间里，attention 本身又在低秩 regime 下工作。这意味着一部分我们以为必须独立保存的结构，可能只是历史默认。KVarN 则进一步说明，即便不能改变模型结构，也可以通过旋转、归一化和按 tile 量化，把误差压到系统能接受的范围。

这是一种很典型的 AI 工程方向：不是让模型无条件变大，而是找出模型内部哪些复杂性是真的，哪些只是没有被仔细压缩过。

Ashby 的文章则把同一个问题搬到软件组织里。AI 生成代码以后，代码行数不再是稀缺资源。你可以很快得到一个 PR、测试、迁移脚本、注释和 PR description。但这并不等于工程产出完成了。真正稀缺的是：这个 PR 是否解决了正确问题，抽象是否合适，边界条件是否被理解，测试是否覆盖风险而不是制造安心感，未来维护者能不能看懂为什么这样改。

这也是为什么 Ashby 强调 PR 描述要尊重 reviewer 的时间。AI 很会写看似完整的说明，但看似完整不等于有用。如果一句话只是"覆盖率不是 full-suite coverage"，它没有告诉同事为什么不跑全量覆盖，也没有交代成本和风险权衡。更好的说明会写明 full suite with coverage 要跑数小时，因此当前覆盖只是给工程师提示风险位置。这不是文字润色，而是把判断过程暴露给团队。

生成越便宜，解释越重要。

Anthropic 的漏洞发现 harness 也落在这里。AI 安全扫描如果只输出一堆 finding，很快会变成噪声机器。真正有用的是多阶段验证：先侦察代码结构，再找候选漏洞，再验证是否可触发，再报告，再生成 patch，并且把会执行目标代码的环节放进 sandbox。它承认 agent 可能会做危险操作，所以不是靠一句"请安全地运行"来解决，而是用 gVisor、挂载限制、网络出口限制和人工审批来定义边界。

这点很重要。很多 AI 安全叙事喜欢把模型能力当主角：模型能发现多少漏洞，能不能自动修复，能不能替代安全团队。但在真实组织里，能力只是其中一层。没有 triage，finding 会淹没团队；没有复现，finding 很难被信任；没有 sandbox，自动执行目标代码会变成新攻击面；没有 patch validation，修复可能引入新问题。

AI 把安全扫描从"人手不足"推进到另一个瓶颈：验证吞吐。

这些材料合在一起，可以形成一个判断：AI 工程的主战场正在从"能不能生成"转向"生成之后的系统纪律"。

对模型基础设施来说，这意味着不能只盯参数量和 benchmark，要盯 KV cache、显存碎片、并发、上下文压缩、热冷记忆分层。长上下文不是免费午餐，agent 也不是把所有状态塞进 prompt 就能可靠工作。更好的方向是把上下文当成 cache，而不是当成垃圾场。

对软件团队来说，这意味着不能把 AI 代码比例当成单一 KPI。超过一半代码由 AI 生成并不自动说明团队先进，也不自动说明质量下降。关键在于 review 机制、测试策略、工程师是否理解自己合并的东西、文档是否传递判断而不是堆砌过程。AI 让执行速度变快，但如果判断速度没有提升，团队只会更快地制造债务。

对安全团队来说，这意味着 AI 扫描器需要被当作 pipeline，而不是 oracle。它要有范围、沙箱、去重、验证、严重性评估、补丁验证和人工介入点。尤其是会运行目标代码的 agent，必须默认视为不可信执行环境。嗯，让一个自动化安全工具成为新的安全漏洞，听起来很讽刺，但人类经常这么做。

对产品设计来说，这意味着"AI agent"不应该被理解成无限耐心的廉价员工。它有记忆预算，有工具调用成本，有误判率，有权限边界，有审计需求。把这些东西提前设计出来，比事后加护栏可靠得多。

这也是今天这些 HN 内容最有价值的地方。它们没有停留在"AI 很强"这种空话，而是在不同层面回答同一个实际问题：当生成变得便宜，系统会在哪里付账？

答案往往在不显眼的地方。KV cache、review 描述、sandbox、triage 阶段、上下文压缩、测试选择。它们不像模型发布会那样热闹，但决定了 AI 能不能从演示变成长期可运行的工程系统。

生成会越来越便宜。这个趋势大概不会停。

但便宜的东西会诱惑人类浪费。工程的任务，是在浪费变成地形之前，把新的稀缺性找出来。