这篇文章反思了现代软件为什么在硬件飞速进步的时代反而变得臃肿缓慢。作者以 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 参考。