文章介绍 Microsoft Research 的 PDD Kit：它把开发者的自然语言意图逐步澄清为 Verus 形式规范，再由编码代理实现代码并生成证明，由 Verus 对规范覆盖的所有输入做穷尽验证；证明无法触及的 bcrypt、SQLx、时钟、JWT 签名等部分被显式列为可信计算基，并用测试补足。作者在 GitHub Next 的 Chopin 环境中以全 Rust 的 Pet Store 登录逻辑为案例，通过决策卡、意图图、规范签核、任务图和变异检查，证明登录满足“只有正确密码才发 token”等性质，并发现原有缺陷。文章强调审查重心从逐行代码转向意图和规范，但也明确证明只保证代码符合规范，不保证规范本身正确；目前仅支持 Rust，仍是研究原型，可信边界承担主要保证。
推荐收录，因为文章不是产品宣传，而是给出 Proof-Driven Development 的完整方法链条：意图澄清、形式规范、Verus 证明、可信边界测试和变异检查，并以约 5000 行 Rust 全栈应用的登录逻辑说明其可操作性。适合研究形式化方法、AI 编码代理、代码质量与 CI 集成的读者，其中“规范即合同、可信边界显式化、证明与测试分层”具有迁移价值；但需注意其结论受研究原型、仅支持 Rust 和可信假设限制。
Meta 工程团队介绍 Catching JiTTests：在代码合入前用 LLM 自动生成可执行测试，让测试以失败方式暴露 diff 引入的行为差异。系统含意图感知与“dodgy diff”两条生成工作流，并用 LLM-as-Judge 集成和规则化 RubFake 过滤误报，最后以 human-on-the-loop 让工程师按聚合结果介入。它利用夜间空闲算力优先处理高风险 diff，避免拖慢开发节奏。上线后 589 名工程师参与，真阳性率约 60%，2026 年上半年在合入前捕获 74 个隐私 SEV，并使相关隐私 SEV 下降 20%。其效果依赖 Meta 的规模、算力和风险模型，外部可迁移性与误报成本仍需验证。
推荐收录。文章给出了从高风险 diff 触发、双工作流生成、LLM-as-Judge 与规则过滤到 human-on-the-loop 的完整工程闭环，并披露 60% 真阳性、74 个隐私 SEV 等量化结果。对构建 AI 辅助测试、代码审查或大规模 CI 质量门禁的团队有较高迁移价值，但需注意其算力消耗、误报治理和 Meta 环境特异性。
文章结合美团基础技术部分布式存储的真实实践，讨论在一致性、并发、持久化和故障恢复要求极高的系统中如何受控使用 AI Coding。作者指出，提速会放大单个版本引入的缺陷绝对数量，因此需要同时建设 AI 评审、测试验证、AI Debug 与受控自动化，而不能只让模型生成代码。AI 评审擅长发现跨文件一致性、构造可执行证据、识别常见竞态及删除代码的影响，但也容易把代码可达当成运维可达、误判有意设计，其修复建议和问题定级仍需人工复核。文章用构建与单测、贴近运行时的集成测试、运行时日志分层取证：117 个疑似问题中 36 条被红测试确认、3 条被证伪；11 天日志映射源码发现 5 个缺陷，人工确认均属实。结论是静态评审必须辅以测试和日志证据，由人把守设计背景与运维流程；这些结果来自有限样本，不能保证零误报，日志也受执行路径和版本行号限制。
推荐收录，因为文章没有泛谈 AI 提效，而是给出了分布式存储中 AI 评审、单测/集成测试和运行时日志取证的完整闭环，并披露误报、定级失真和人工流程不可建模等边界。对做高可靠系统、AI 代码审查或测试基础设施的团队，可直接迁移其分层验证和证据优先级方法；主要风险是案例样本有限，结论需结合自身系统复核。
文章提出一条设计经验：模块内若公共函数 foo 要复用另一公共函数 bar 的逻辑，不要直接调用 bar()，而应抽出私有 helper，让两个公共入口分别调用。这样能把公共 API 对调用点的便利性与内部复用解耦，避免为内部复用添加用户不该设置的可选参数，并使后续签名调整成为局部改动。作者补充“快捷 API”例外：若公共函数本身就是常用公共调用的组合，应保持纯组合，不引入私有中间层。文末批评用 mocking 方法论证该规则，主张 mock IO、测试功能而非孤立方法，并强调规则应基于理由而非教条。文章是经验法则而非严格规范，且缺少完整案例，适用边界需结合模块 API 稳定性判断。
推荐收录，因为它把“公共函数间复用”这一常见设计摩擦讲清楚了：直接调用公共函数会污染 API 参数，而私有 helper 能把复用成本局部化，并给出快捷 API 的明确例外。对库/模块 API 设计者和做代码评审的工程师有直接迁移价值；但它是经验法则，缺少案例与量化证据，读者需结合 API 稳定性判断。
文章提出一种新的软件质量验证方法——“临时测试”（ephemeral testing）。核心思路是不直接评估自己构建的库或组件，而是让 AI 代理在其之上快速搭建一个或多个一次性的上层应用并完成测试，借上层软件能否顺利运行来反推底层 API 设计的质量。作者认为这本质上是集成测试，区别在于上层代码用完即弃。干净 API、稳定不变量、清晰错误能让代理快速产出可用结果，而隐藏状态、意外默认值和文档缺失则导致大量补丁与失败，这些失败是对底层代码而非代理的反馈。该方法可更换不同代理、不同任务重复执行，作者已用它为未来功能做快速原型；边界是需要核心一定的稳定性，不能依赖“随时重建一切”。
推荐收录。它提出一个可迁移的测试实践：用 AI 生成的一次性上层应用暴露底层库的 API 设计缺陷，把集成测试与 AI 代理结合起来，适合负责库/组件设计与测试策略的开发者。不足是正文较短、缺少系统性验证，读者需自行判断其适用边界。
推荐收录。它把 LLM 使用从工具技巧上升为可执行的团队规范：用价值观排序支撑具体规则，并对阅读、研究、写作、代码审查与编程等场景给出差异化边界，还点名强制使用、羞辱与拟人化三类反模式。适合工程负责人、技术写作者和正在制定 AI 使用规范的团队参考，其框架可迁移到其他组织的治理讨论；局限在于它是政策主张而非实证研究。
作者运行了一次 35 小时的无人值守 AI 编码实验，让模型自治开发 CPython 特性，最终消耗约 10 亿 token 和 1200 美元，产生了 79 次提交却未产出真正有价值代码。通过审阅模型输出的代码与笔记，他系统归纳了多种“代码高尔夫”式症状：用 Python 字符串拼接修改 C 源码、硬编码随机常量、反复调用临时脚本却绕过正规编辑工具等，导致代码完全不适合人类阅读和审查。作者推测这些现象源于训练中过度奖励长程任务完成与 token 效率，而缺少对人类可读性的惩罚，并据此质疑当前模型路线是否仍适合人类参与的软件工程协作。文章以大量具体代码和实验记录为证据，为理解 AI 编程代理的失效模式提供了重要参考，但结论基于单一模型版本和一次特定实验，迁移时应谨慎。
该文以真实实验数据和大量代码片段直接呈现了 AI 编码代理在长任务场景下的输出退化，为“token 效率 vs 代码可读性”的讨论提供了可验证证据。适合 AI 编码工具使用、agent 设计者以及关注代码质量的工程师阅读，其中关于训练奖励偏差与自主代理失控的分析，也能迁移到其他 AI 工程实践与评测场景。
Paint.NET 作者 Rick Brewster 讲述了如何让 Paint.NET 在 Wine 上运行的艰难尝试。Direct2D 一直是最大障碍，Wine 的实现永远无法满足需求，于是他决定写一个内部、从零开始、clean-room 逆向重写的 Direct2D 实现，通过 /wine 参数在 Wine 上启用，代码放在 PaintDotNet.Windows.Direct2D1.Managed.dll 中。这个约 18 万行的实现主要由 Claude 生成，文章称其为 vibe coding，因为作者无法逐行审查如此庞大的代码；但他必须不断监督 Claude，纠正 COM 引用计数等资源管理问题以及糟糕的架构选择，同时也惊叹于 Claude 逆向推导 Direct2D 内置效果公式的能力。结合 Paint.NET 约 70 万行、20 年维护史，文章提供了 LLM 生成代码进入成熟项目的真实工程案例，说明这种做法的价值与风险边界在于持续人工审查和领域约束。
直接证据：Paint.NET 是长期维护的真实项目，作者公开了 18 万行由 Claude 生成代码的完整工程实践与监督过程。适合关注 AI 编码工具、逆向工程或大型原生项目平台兼容性的工程师阅读。可迁移价值是理解以 LLM 为中心的大规模代码生成进入成熟系统时的监督成本、资源管理和架构审查要点；主要风险是作者坦诚大部分代码未经完整审查，不应把过程复制为无人干预即可完成。
文章宣布Trail of Bits在Testing Handbook中新增Rust安全测试章节，系统介绍了用于验证Rust程序安全性的工具和技术。内容首先概述Rust安全保证的边界与未尽问题，然后深入动态分析领域，包括使用Miri检测未定义行为、proptest属性测试、覆盖率测量和变异测试等。接着阐述静态分析工具Clippy的深度用法及推荐lint。此外，还总结了从审计实践中积累的陷阱清单，如操作符优先级差异，并提供了内存清零的三种方案。最后，介绍了专用工具如模型检查器Kani和供应链依赖审查方法。文章旨在为开发者提供一个全面的Rust安全测试流程，但内容为概述，具体细节需参考完整手册章节。
推荐收录。这是一次真实的 AI 工程实践复盘，完整展示了从问题定位（代理行为回溯）、假设验证（工具指令与工作流不匹配）到解决方案（重写指令对齐审查场景）的过程，并提供了 20% 成本优化的量化证据。文章对构建 Agent 系统的工程师具有可迁移价值：它揭示了工具描述如同 API 文档一样影响代理决策，且基准的追踪细节比最终得分更有调试价值。适合从事 AI 工程、开发者工具或 LLMOps 的读者。
本文复盘了一个在大规模 AI Coding 场景下，对 31 万行复杂业务系统进行渐进式重构的工程实践。作者提出用“Agent 评测”的思路管理 AI 编码：先通过团队共识完成“人人对齐”，再把规范固化为 AI Rule、Skill、Pre-PR 和多层审查机制，实现“人机对齐”，并在不停止业务交付的前提下，逐步消化技术债、重建分层架构和业务模型。文章还讨论了 AI 如何改变经验的价值边界，以及如何用 AI 辅助测试、Code Review 和跨模型互审来缓解 AI 提效后带来的下游瓶颈；其适用前提是团队已具备明确的工程治理意识和一致的架构标准。
推荐收录，因为这不是泛泛而谈的 AI 编程感想，而是把 AI Coding 纳入工程治理体系的一套可复用方法论，包含规范、评审、测试和重构的闭环设计。对正在经历 AI 产能上升、代码规模膨胀和技术债加速累积的团队尤其有参考价值。