2026-第四十四周

该周报主要为各个地方内容的汇总整理

技术

软件慢是因为设计糟糕，而不是语言慢

文章核心观点是：软件性能通常由设计决定，而非编程语言速度。大多数真实程序受 I/O 限制，重写成 C、Rust 或汇编只能优化局部 CPU 热点，难以带来数量级提升；更有效的做法是通过剖析与重新设计减少工作、缓存、异步、并行和优化查询。AI 应帮助发现热点并提出重构方案，而不是盲目重写语言。

• 🧠 软件慢往往源于糟糕设计，而不是使用了“慢语言”；语言速度并非性能主导因素。
• ⏳ 多数真实程序是 I/O-bound，时间主要花在数据库、第三方 API、磁盘和网络等待上。
• 📉 重写成 C/Rust 只能加速非 I/O 部分，受 Amdahl 定律限制，整体收益通常有限。
• 📚 慢语言常已通过 C 扩展和成熟库委托高性能工作，如 Python 的机器学习库、Markdown 渲染库。
• 🔍 真正有效的提速通常来自重新设计：缓存、异步/后台任务、并行、合并 SQL、消除 N+1、跳过不必要操作。
• 🎯 只有少数真正 CPU-bound 且无法减少工作的热点，才适合用更快语言重写局部代码。
• 🤖 使用 AI 优化软件时，应让代理做性能剖析、定位热点、建议重构，而非一开始就要求用 C/Rust/汇编重写。
• 💬 评论区争议包括 CRUD 是否真为 I/O-bound、CPU-bound 程序占比、语言生态对设计难易度的影响；作者仍坚持设计优先。
• 🧩 换语言对可移植性、效率、可维护性有价值，但若目标是原始速度，应优先优化程序设计与工作方式。

抱歉，但你还是得思考 | 一切都关乎比特

文章以 DHH 用 AI 代理把 Campfire 从 Rails 改写为 Rust（后又改写为 Elixir、Go）为例，讨论“不读代码、依赖 AI 编程”的局限：提示含糊会让模型隐含决定关键取舍，不同改写结果因而不可直接比较；性能基准常只测单一指标，真实系统必须在兼容性、延迟、吞吐、内存和失败模式之间权衡。结论是编程并未被“解决”，开发者仍需理解代码、系统约束与权衡。

• 🤖 DHH 让 AI 代理将 Campfire 改写为 Rust，并扩展到 Elixir、Go；作者借此观察“不读代码”的 AI 编程结果。
• ⚖️ 提示不够具体时，许多设计问题没有唯一答案，模型会替开发者隐含决定向后兼容、延迟/吞吐、内存上限、通知丢失等取舍。
• 🧩 Rust 版为缓存方便放弃 CSRF token、用进程内队列替代 Redis；Elixir 版更接近 Rails 原作；约束不同使语言间性能比较失真。
• 🧵 代码层也有问题：Elixir 版用单进程串行处理 SQL 查询；Rust 版部分数据库操作非 async、使用同步锁，在协作式调度下会阻塞 worker。
• 📊 基准测试本身也不可靠：Zach Daniels 发现 Rust 版重载下新消息通知投递成功率仅约 1%，只测吞吐会掩盖其他系统属性。
• 🔁 闭环基准测“单位时间能处理多少请求”，但真实高负载常来自大量用户同时操作，恒定的请求到达率更能模拟这类场景。
• 🧪 以 100 POST/s 重跑：Rust 事件送达约 14% 且无 HTTP 错误；Elixir 约 60%，但约 23% HTTP 请求超时，最差事件延迟接近 180 秒。
• 📉 Rust 大量丢消息的根因是 tokio::sync::broadcast 容量仅 256，接收端落后会触发 Lagged；调到 16384 后送达率升至约 90%，但延迟从 11 秒升到 130 秒以上，未必更好。
• 🧠 Elixir 的 GenServer 邮箱默认无界，压力测试中内存达 1.8GB；不设边界可能遇到外部限制，需在丢消息与 OOM 之间权衡。
• ✅ 最终结论：仍要批判性思考、理解自己在做什么，不要用单一指标判断语言优劣；可靠系统需要明确失败模式与取舍，而基准测试很难。

用 small-change 加速代码审查 | 非理性繁荣

文章介绍了 Imprint 在 PR 合并量大幅提升、质量改善的同时，代码评审时长从 33 分钟升至 77 分钟并成为瓶颈；团队因此推出 small-change 机制，通过 CICD 检查、AI 评审和作者经验等条件筛选低风险小改动，用自动化技能快速批准，并把由此引发的错误视为系统级问题。文章还讨论了“meat proxy review”反模式和集中式 harness fleet，早期约 10% 变更符合 small-change，最终成败取决于验证能力的持续扩展。

• 📈 工程效率显著提升：Imprint 平均工程师的 PR 合并量是两年前的 4 倍，两个团队达到 10 倍，个别工程师达到 25 倍。
• ✅ 质量同步改善：事故半年环比下降 42%，严重事故下降 78%，说明质量与速度并非简单取舍。
• ⏱️ 评审成为瓶颈：PR 评审中位数从两年前的 33 分钟增至 77 分钟，且与合并 PR 数量高度相关。
• 🧭 重新审视评审目的：知识共享、防错、防恶意行为和合规；现代开发范式下，部分目标可用更好机制替代逐 PR 人工评审。
• 🧩 small-change 资格标准：少于 1000 行代码、AI 评审无 p1/p2 问题、作者在相关服务有 10+ 合并经验、影响服务数少于 N（前端为 1，后端为 3），共享库和工具文件不适用。
• ⚙️ 执行机制：CICD 生成 GitHub check 决定资格，标签仅用于可见性；Slack reacji 标识状态；仓库内 .small_change 支持按路径定制。
• 🤖 自动化技能：review-small-change 只批准或忽略、不发表评论，避免“meat proxy review”；review-pr-cluster 批量识别共性问题。初版约两天完成上线，后续长期调参。
• 🧠 文化原则：任何由 small-change 引发的错误都应在系统层解决，改进 AI 评审、验证机制、CICD 和 harness。
• 🚫 “meat proxy review”反模式：让 harness 生成大量评论、再用 harness 回复，形成没有学习价值的评审幻觉；应投资集中评审机制并直接批准。
• ☁️ fleet：集中编排的云端 harness，用独立评估决定所需评审人数，安全变更可仅需 1 人评审。
• 📊 早期结果：约 10% 变更符合 small-change，可获得快速批准，除非涉及安全或资金等敏感主题；未来需扩大比例并增强验证。
• 💬 接受度：变革让部分人不适，需要持续重新评估长期最佳实践是否已变成教条。

工具

更新

设计

其他

我现在面试时会问的九个问题，真希望五年前就问过

面试本应是双向选择，但多数候选人把它当成考试；文章主张拒绝这种框架，利用面试尾声“你有什么问题”的环节反向考察公司。此时对方往往在回答而非评估，能暴露晋升路径、团队稳定性、诚实度、管理方式、招聘计划、未来同事、成败标准、重组历史和岗位空缺原因等关键信息；若公司因提问而抵触，反而用最低成本暴露了问题。

• 🎯 转变心态：面试不是单向考试，而是双向选择；有资历和选择权的候选人应主动“面试公司”。
• 📈 晋升路径：问最近一次晋升的具体案例、标准和时间；回答含糊或“近期没有”说明晋升路径不清晰。
• ⏳ 任期与去向：问该岗位任职最久的人待了多久、现在做什么，以判断人员流动和内部发展机会。
• 🕳️ 真实短板：问团队真正不擅长什么；具体诚实的回答比“凡尔赛式缺点”更有信息量。
• 🗣️ 分歧处理：问团队如何应对领导层决策分歧；健康团队有表达和反馈流程，而非一味“相信领导”。
• 👥 招聘计划：问未来 12 个月编制计划；不确定或未获批可能意味着团队未来仍在高层博弈。
• 🤝 未来同事：问最常合作的人是谁，并请求在流程中与其交流；安排是否顺畅本身就是信号。
• 🎯 成败定义：问六个月成功与失败分别是什么样；失败答案常暴露岗位的真实模糊性、政治性或倦怠风险。
• 🔄 重组历史：问最近一次重组时间与触发原因；频率和原因反映组织稳定性。
• ❓ 岗位空缺原因：直接问“为什么这个职位开放”；区分增长、补缺、重组，并注意回答是否迟疑。
• 🚪 反向筛选：若公司因这些问题不悦、敷衍或让你觉得自己“难搞”，说明它不愿被面试，应果断放弃。