Zod 4.5 正式发布，核心是新的 AOT 预编译 API z.compile()，可将任意 schema 预编译为更快的解析函数，对象、数组、联合类型解析提速约 3–9 倍；配合不再构造 ZodError 的 z.validate()，无效输入路径比 safeParse 快约 16 倍。基准数据显示，在 Moltar parseSafe 上达到 47.5M ops/s，超过 typia 的 45.3M。同时通过将方法迁移到原型并延迟绑定，单个 schema 实例内存占用最高减少 9.8 倍。新版带来多项破坏性变更：字符串长度改按 Unicode 码点计算、z.iso.datetime() 强制要求秒、记录键和交叉类型对齐 TypeScript 语义、全链路剥离 __proto__。适合在服务端校验、表单和数据管道中重度使用 Zod 的 TypeScript 工程团队。
选 LLM 看起来是单次决定，实则要随新模型和产品演化反复重做。本文把选型拆成五个问题：开源还是闭源、成本、延迟、性能、上下文窗口。开源模型需要自行托管或走 API 供应商（Hugging Face、Groq），闭源模型由模型厂商托管，按 token 计费，价格战愈演愈烈。延迟的测量要看 TTFT 和 TPOT；性能先参考公开榜单（Chatbot Arena、Open LLM Leaderboard），但榜单存在过拟合风险，真正的验证只能在应用内用自建 evals 进行。推理模型（如 o1）在编程和数学上更强，但要付出更高的 token 成本和更长响应时间。上下文窗口同时计入输入与输出 token，RAG 中的 chunking 等模式就是在有限的窗口里塞进更多信息。适合刚开始做模型选型的 AI 应用开发者。
Jeff Dean 在 Google 最后一天前夕接受 YC 访谈，承认一年前对 AI 能力的预测仍偏低：模型处理复杂任务的增长速度快于预期，基于 Agent 的系统已能连续运行数周。他将推理专用硬件比作 2001 年“把搜索索引装进内存”的转折时刻，并给出具体数字：50 倍延迟改善、30-80 倍能效提升；做一次计算约消耗一皮焦耳，而搬运数据的能耗是其 1000 倍，这决定了 batching 的必要性。访谈还讨论了上下文工程取代纯模型缩放成为新前沿、TPU 由“餐巾纸数学”催生的历史，以及给创始人的测试：用当前最强通用模型测目标领域，成功率 0% 或 1% 是好信号，20% 则是危险信号。他认为当 Agent 写完代码后，“品味”（知道该让 Agent 解决什么问题）将成为稀缺技能。适合 AI 基础设施工程师、Agent 开发者和 AI 创业者阅读。
本文介绍一套五层工具与自定义 Hook 配合的分层 token 节省方案：用 CBM 知识图谱替代文件检索（可省 99% token），以 context-mode 管理大输出延长会话 6 倍，RTK 压缩 shell 输出，Headroom 在 API 边界再次压缩，Caveman 限制模型回复冗长度。整套方案通过 Pre/PostToolUse 等 Hook 实现强制执行，最终将代码探索 token 从 ~400K 降至 ~3.4K，会话时长从 30 分钟延至 3 小时以上。
Anthropic 发布 Claude Opus 5，性能接近最强模型 Fable 5 但价格减半。在编码（Frontier-Bench v0.1 超越所有模型，性能是 Opus 4.8 的两倍以上）和知识工作（ARC-AGI 3 得分是次优模型的 3 倍）上达到新 SOTA，但网络安全任务仍落后于 Mythos 5。模型支持 effortless 设置以平衡成本与智能，客户反馈在软件开发、金融、法律等领域表现显著提升。安全对齐更好，但故意未训练网络攻击能力，且安全拦截比 Fable 5 减少约 85%。定价与 Opus 4.8 相同，提供 Fast 模式。
作者曾安装 23 个 Claude Code 插件，发现会话启动前基线就吃掉 62,000 tokens（窗口的 31%）。周末清空所有插件后，会话时长延长 3 倍、输出质量提升、token 支出减半。本文逐一介绍替换掉每个插件的内置命令：/context 诊断上下文占用、/compact 压缩对话、/resume 恢复会话、双 Esc 恢复检查点、/cost 实时计费、/model 按需切换模型、/init 生成项目配置、/review 内置审查、自定义 /.claude/commands/ 零开销建立工作流。最终仅保留 3 个精选扩展，基线开销降至 6k tokens。适用于所有 Claude Code 用户，尤其是被插件拖慢的开发者。
Cloudflare 发布 Workers Cache，在 Worker 前端增设一个分层缓存层，仅需在 wrangler.jsonc 中添加一行 `"cache": { "enabled": true }` 即可开启。命中时 Worker 完全不运行，CPU 不计费；未命中时才执行 Worker 并回填缓存。支持 stale-while-revalidate，过期后首先返回过期内容，同时在后台刷新。缓存可基于 Vary 头为同一 URL 存储多个变体；通过 ctx.props 实现多租户隔离，不同用户的缓存条目互相隔离。缓存属于 Worker 而非 Zone，因此不论部署在自定义域名、workers.dev 还是 Workers for Platforms 都能工作。更关键的是，缓存在每个 Worker 入口点之前生效，包括 service binding 和 ctx.exports 的调用，使得开发者可以将应用拆成多个入口点，对每个入口点独立控制是否缓存。Astro 等框架已原生集成。
这篇文章反思了现代软件为什么在硬件飞速进步的时代反而变得臃肿缓慢。作者以 Java 组件启动 Spark 集群为例指出，工程师习惯性地给内存和 CPU 加上“以防万一”的缓冲，而这些临时补丁很快固化成了默认配置。JVM 会读取容器分配的空闲空间自动扩大堆大小，GC 也随之变得懒惰，资源就这样被浪费掉了。作者认为，硬件变得便宜且容易预配，让“加机器”成了解决问题的默认动作，但真正的问题在于——我们不再追问“这笔开销到底买了什么”。文章提出“资源预算”的思路：为每个组件设定明确的内存、启动时间、容器大小上限，一旦超限就必须解释具体换了什么、换来什么。核心不是让大家穷着过日子，而是让每个 trade-off 显式化，告别“迷信式分配”。推荐给所有在云上跑服务的后端工程师、SRE 和平台工程团队。
Addy Osmani 提出「编排税」概念：启动 AI 代理很便宜，但验证、合并、做判断的环节是串行的——你的认知带宽无法并行化。他用 Amdahl 定律和 Python GIL 做类比：你就是系统中的单线程瓶颈，代理再多也只能排队等待你的判断。文章给出了具体应对策略：按 review rate 限制并行数、把任务分成「可异步委托」和「复杂判断」两类、批量做代码审查、让代理自证而非靠你验证。适合已经在日常使用 AI 代理、感到「忙但不出活」的一线工程师。
Anthropic 工程师分享 Claude Code 中优化提示缓存的实际经验。提示缓存基于前缀匹配，缓存从请求头到每个 breakpoint 的内容，因此 prompt 各部分的顺序至关重要：遵循“静态在前、动态在后”原则，能最大化跨会话的缓存命中。文章给出多条反直觉教训：用消息传递更新信息而非修改系统提示；不要在会话中切换模型或增减工具，这会立刻导致缓存全部失效；压缩（compaction）时复用父会话前缀避免缓存丢失。每条建议都附带具体实现策略（如 system-reminder 标签、EnterPlanMode/ExitPlanMode 作为工具、defer_loading 机制）。适合正在构建长运行 Agent 产品的工程师参考。
这篇长文系统梳理了大模型训练的全链路，核心观点是：2026年模型效果的真正差距并不在预训练阶段，而在后训练、评测、奖励、Agent训练与蒸馏等「后半段」。文章以工序化的方式拆解了从预训练底座到数据配方、系统架构、四阶段后训练流水线（SFT冷启动—GRPO推理RL—拒绝采样微调—对齐RL）、Grader/Reward设计、Agent训练（包括PARL架构与Meta-Harness优化）、蒸馏部署等完整流程。其中着重分析了DeepSeek-R1的公开配方、GRPO相比PPO的工程优势、PRM与ORM的优劣、以及Agent从优化答案扩展到优化环境Harness程序的趋势。适合需要理解大模型能力来源于哪些具体工程环节的系统/数据/工具工程师。
个人实操总结 23 条 Claude 省 token 习惯：上传前转文本、用 Chat 规划再进 Cowork、编辑消息替代追加、语音输入减少轮次等。依据 Anthropic 文档与实测数据（如单页 PDF 消耗 1500–3000 token），帮助 Claude 付费用户大幅降低额度消耗，从每天超限降至每月一次。适合 Claude/Anthropic 重度用户。
OpenAI 与 Thrive Holdings 联合为希腊克里特岛会计网络开发 Tax AI，基于 Codex 驱动自改进循环。系统处理 7,000 份税表，准确率达 97%，吞吐量提升 50%，将一位高级会计师的税务准备时间从 180 小时降至 15 小时。核心设计三支柱：从业者反馈、生产轨迹（从原始文件到最终申报的结构化流程）、Codex 迭代循环。以租赁房产表格为例，详细展示了从业者修正如何转化为评估目标，再由 Codex 分析根因并提出补丁。适合在专家知识密集型领域构建自进化代理的团队。
ClickHouse解决方案架构师分享十大可落地的最佳实践，涵盖主键设计、数据类型、分区策略、跳过索引、JSON类型、数据摄取、物化视图、系统表、ReplacingMergeTree与JOIN优化。每条实践都基于Amazon评论数据集（1.5亿行）的基准测试，给出量化性能差异：主键顺序错误导致全表扫描，优化后扫描量减少347倍；不必要分区让查询慢46倍；恰当的数据类型压缩存储12%、提速2倍；跳过索引减少80%扫描量；字典查找比常规JOIN快近3倍。全篇强调理解ClickHouse存储与合并机制，用实际数据验证设计决策的影响，适合正在或计划在生产环境使用ClickHouse的工程师对照优化。
Vercel 将 10+ 年 React 与 Next.js 优化经验沉淀为 react-best-practices 仓库，包含 8 大类 40+ 规则，按影响度排序（从消除异步瀑布到 JavaScript 微优化）。每条规则配影响评级和代码修复示例，并生成 AGENTS.md 供 AI 代理查询。适用：需要系统化前端性能优化的团队与将 LLM 用于代码审查的工程师。
本文对比了 OpenTelemetry Collector 与 Rotel 在向 ClickHouse 写入追踪数据时的性能。在相同 8 核主机上，Rotel 实现每秒 370 万 trace span 的吞吐量（每核 46.25 万），是 OTel Collector 的 4 倍以上。性能提升源于三项关键优化：RowBinary 格式下的 JSON 列二进制编码，降低序列化开销；将反序列化迁移至共享线程池，消除 Tokio 任务阻塞及 glibc 内存分配器锁争用；启用快速 LZ4 压缩。测试还揭示了 OTel Collector 在反压下静默丢数据的缺陷。适合大规模可观测性数据管道的架构师与 SRE 参考。