工程实践 GitHub Engineering 2026/09/25
GitHub 团队复盘了将 Primer 设计系统及 dotcom 前端从 CSS-in-JS 迁移到 CSS Modules 的多年实践。起因是组件激增导致客户端样式初始化、SSR 样式收集和样式更新成本恶化。团队按组件增量迁移，新增 CSS Modules 文件，并以特性开关、视觉回归测试、逐级灰度和包装层兼容旧 sx。到 2024 年底 Primer 组件全部迁移，SSR 时间降 55%、组件初始化降 25%；随后全站迁移数千 sx，借助 codemod、VS Code 插件和 Copilot coding agent 移除 sx、styled-components 与 styled-system，完成主题解耦，2026 年实现 100% CSS Modules。该经验适合大型设计系统与前端性能治理，但依赖长周期、强测试和灰度基础设施。
推荐收录。该文提供了完整的工程迁移证据：组件级 CSS Modules 迁移、特性开关、视觉回归和灰度发布，以及 SSR 下降 55%、组件初始化下降 25%、sx 从约 7760 到 0 的具体指标，对前端架构、设计系统和性能治理团队有直接参考价值。其风险在于迁移周期长达数年，依赖设计系统、测试与灰度基础设施，直接照搬需评估组织规模和协作成本。
个人心得 Simon Willison 2026/09/06
文章是作者Simon Willison对“代码能坏到什么程度”讨论的评论，聚焦于大型系统因技术债过深而从零重写为何常常失败。作者指出旧系统仍在支撑核心业务因而持续变动，开发者缺乏维护动力导致债更深；新团队虽速度快但难以完整理解被替代系统的全部行为和范围，最终新系统只能覆盖部分功能，不得已与旧系统并行上线，形成两套系统僵持的局面。作者引用Will Larson关于“迁移是唯一可扩展的技术债解法”的观点，提出应对重度技术债的更稳妥路径是在旧系统上补足自动化测试、做定向重构，而不是被绿地重写的诱惑带走。该文是一线工程经验判断，适合架构师或技术负责人在规划重大重构时参考。
推荐收录：文章没有停留在“重写难”的直觉，而是拆解了新系统推进中来自业务变动、团队激励、范围理解的多重阻力，并给出可执行的替代策略——用测试和定向重构加固现有系统。读者若在技术债清理或重构启动会议上做判断，可把文中风险清单和Will Larson的迁移框架当作决策依据。风险是内容篇幅短，缺少具体案例数据，但对长期参考仍具有很好的情境提醒价值。
工程实践 知乎 - 腾讯技术工程 2026/08/07
文章以一个小程序教育平台的重构实践为例，系统阐述了如何通过AI上下文工程将历史债务沉重的项目转变为AI可维护的项目。核心路径包括：从AGENTS.md构建静态上下文索引，移除不再运行的死代码做减法，简化过度设计的架构（如将OT协同降级为HTTP同步），制定页面布局、组件与交互规范约束边界，搭建单测、E2E及视觉回归自动化测试流水线并嵌入MR检查，最终将债务治理融入日常迭代。文章详细记录了每一步中AI角色的变化与引导方法，展示了从AI频繁误判到能主导方案落地的过程，并指出关键在于持续沉淀可复用的上下文知识而非一次性建设。
本文提供了将AI嵌入遗留系统重构的完整案例，覆盖上下文建设、架构简化、规范制定和自动化质量门禁等环节，实操性强。文中拆解的步骤与AI引导策略可直接迁移至其他需要历史债务治理的工程场景，适合希望提升团队工程效能与AI融合度的开发者及技术管理者参考。
工程实践 Simon Willison 2026/07/08
本文详述了Bun从Zig全面重写为Rust的过程，核心驱动是内存管理难题（如use-after-free、double-free）和崩溃导致的维护负担。作者借助Claude驱动的AI代理，利用TypeScript测试套件作为一致性验证，通过动态工作流、对抗性代码审查和流程修复机制，在11天内自动化完成了百万行代码的移植，并已平稳运行一个月。文章展示了代理工程在超大规模代码迁移中的完整工作流程，包括成本（$165K API消耗）、质量保障和实际效果，也讨论了语言选择从单向决策变为可逆决策的范式转变，但强调该方法高度依赖高质量测试套件和大量模型输入。
推荐收录，因为该案例系统展示了利用前沿AI模型进行超大规模代码重写的完整实践，从动机、方案设计、自动化执行到质量控制和上线验证，证据链完整。尤其适合关注AI工程化、编程语言迁移、测试驱动开发或开源项目维护的读者，文中关于一致性套件驱动、流程修复而非手工修代码的理念具有很强的可迁移性，但需注意其成功依赖高质量测试资产和充足的模型交互预算。
工程实践 美团技术团队
本文复盘了一个在大规模 AI Coding 场景下，对 31 万行复杂业务系统进行渐进式重构的工程实践。作者提出用“Agent 评测”的思路管理 AI 编码：先通过团队共识完成“人人对齐”，再把规范固化为 AI Rule、Skill、Pre-PR 和多层审查机制，实现“人机对齐”，并在不停止业务交付的前提下，逐步消化技术债、重建分层架构和业务模型。文章还讨论了 AI 如何改变经验的价值边界，以及如何用 AI 辅助测试、Code Review 和跨模型互审来缓解 AI 提效后带来的下游瓶颈；其适用前提是团队已具备明确的工程治理意识和一致的架构标准。
推荐收录，因为这不是泛泛而谈的 AI 编程感想，而是把 AI Coding 纳入工程治理体系的一套可复用方法论，包含规范、评审、测试和重构的闭环设计。对正在经历 AI 产能上升、代码规模膨胀和技术债加速累积的团队尤其有参考价值。
工程实践 知乎 - NGINX洪志道 2026/05/31
文章以 nginx 的 proxy HTTP/2 支持重构为例，讨论如何把一个承载请求状态、解析状态、stream 状态、connection 状态和控制帧临时状态的巨大 ctx 结构拆分为 frame_parse、stream、connection 与请求编排层。作者详细解释了为什么旧设计在单连接单请求时代“能工作”，却在 HTTP/2 单连接多请求和后续功能扩展下暴露出边界混乱、职责耦合和维护成本上升的问题。文章还给出了一套用 AI 辅助重构的实操方法：先明确边界，再按小步改动、逐步编译测试、查看 diff 并独立提交，借此把 AI 的执行力限制在正确的设计框架内。
推荐收录，因为它不是泛泛谈“AI 写代码”，而是基于真实 nginx 代码库展示了如何用重构重新整理核心抽象和模块边界。对做后端、基础设施或大型遗留代码维护的读者来说，文章提供了可迁移的拆分思路、变更节奏和验证方式。
工具笔记 知乎 - NGINX洪志道 2026/05/28
这篇文章记录了作者用 AI 辅助真实编程的一套实用方法，核心包括优先使用能力更强的大模型、用测试用例约束 AI 输出、频繁重构、以及通过“明确目标—拆小任务—让 AI 实现—自己理解 diff—写/跑测试—继续迭代”的循环推进开发。作者强调代码本身应当成为设计载体，而不是只依赖文档式 SPEC，同时认为真正有价值的经验来自在复杂、真实的任务中持续实践。
推荐收录，因为它给出了一套可直接迁移到日常开发中的 AI 编程工作流，而不是停留在抽象的“怎么问 AI”。其中关于测试、重构、理解 diff 和代码驱动的建议，对使用 AI 提升交付质量和保持代码可维护性都有长期参考价值。
学习路线 知乎 - NGINX洪志道 2026/05/24
这篇文章讨论的是完成编程入门后的下一步该如何自学，核心建议是先继续巩固数组等基础数据结构，再通过经典书籍建立更长期的代码质量与软件设计意识。作者强调自学在编程中的重要性，并建议优先阅读《重构与模式》《敏捷软件开发》《领域驱动设计》，《深入理解计算机系统》可作为能力提升但非必读的补充。文章的边界也比较明确：它不是系统课程表，而是面向初学者的阶段性选书与学习方向建议。
推荐收录，因为它给出了入门之后很实用的自学顺序和阅读取舍，适合刚接触编程、正在从“会写语句”过渡到“会组织代码”的学习者。文章虽然简短，但对基础巩固、代码重构意识和长期自学心态的建议具有可迁移价值。
技术文章 Go Blog 2026/03/10
文章介绍 Go 1.26 新版 go fix 中的 source-level inliner：它把函数调用按源代码层面展开，并通过 //go:fix inline 指令，让库作者为旧 API、重命名接口和类型/常量迁移提供“自助式”现代化方案。文中以 ioutil.ReadFile 迁移到 os.ReadFile、oldmath 包重构为例，说明 go fix 与 gopls 如何自动提示并批量改写调用点。作者进一步剖析了实现难点：参数消除、求值副作用顺序、可能在编译期失败的常量表达式、名字遮蔽、未使用变量以及 defer 作用域。文章强调该工具追求的是“可证明不改变语义”的整洁改写，因此在批处理场景会比人类更保守，甚至拒绝某些需要函数字面量包裹的情况。
文中直接展示了 //go:fix inline 的迁移用法，并系统解释了源级内联器如何处理语义边界，是理解 Go 代码改写与编译器式重构工具的可靠材料。适合做语言工具、重构引擎或 API 迁移方案的参考，但也要注意它在副作用和 defer 等场景下会刻意保守。
工具笔记 Go Blog 2026/02/17
本文介绍 Go 1.26 中重写后的 go fix：它可按包模式批量应用现代化修复，支持 -diff 预览、按分析器选择性启用，并会跳过生成文件与不匹配的构建配置。作者用 minmax、rangeint、stringscut 和 newexpr 等例子说明，go fix 不只是修 bug，更是在把旧写法迁移到更新的语言/标准库习惯上，甚至能跨包替换“new-like”辅助函数。文章进一步解释了 go vet 与 go fix 统一到 Go analysis framework 后的架构：分析器、驱动、事实传递、gopls/staticcheck 等复用同一套基础设施。它也强调多次运行可产生协同修复，但仍可能出现语义冲突、未使用变量或需要手工处理的边界。最后提出“self-service”静态分析设想，希望未来能让第三方 API 和组织规则也像标准库现代化一样自动推广。
推荐收录，因为文章直接给出了 go fix 的使用方式、分析器机制和典型修复案例，证据充分且不是产品宣传。适合 Go 开发者、工具链维护者和静态分析作者阅读，其中关于批量重构、安全修复与分析框架复用的经验具有较强迁移价值。
工程实践 Blender Developers Blog 2026/02/16
这篇文章回顾了 Blender 在 2025—2026 冬季进行的“质量季”工作，重点不是新功能，而是围绕稳定性、缺陷修复、测试补强和技术债清理展开。两个月内修复了 350+ 个用户报告的问题，并按动画、建模、节点、渲染、界面、视口等模块给出分布，说明质量投入是按子系统推进的。正文还列出多项结构性工作，例如将代码从旧式 C 接口迁移到更现代的 C++ 风格、补充自动化测试、优化性能、完善文档，以及完成 Mesh 属性存储格式切换等。文章也展示了缺陷分流和 triage 的进展，未分配问题显著下降，说明质量治理不仅是修 bug，也包括流程改进。其边界在于这是项目回顾而非深入技术复盘，很多条目只给出结果和方向，缺少实现细节与量化对比，但仍适合作为开源大型工程做稳定性治理的参考案例。
推荐收录，因为它明确给出了 350+ 缺陷修复、自动化测试补强、代码现代化和 triage 流程改进等直接证据，体现了大型开源项目如何系统性提升质量。适合做开源维护、稳定性治理和技术债清理的参考，但读者需注意它偏项目总结，细节深度有限。
工程实践 Instacart Tech Blog 2026/02/03
文章复盘了 Instacart Caper 智能购物车 Android 应用从 Fragments/XML 迁移到 Jetpack Compose 的全过程。作者将迁移拆成四阶段：先用隐式 Fragment host 承接 Compose 页面，再把导航图迁到 Kotlin DSL 与类型安全路由，随后把存量 Fragment 逐步改造成纯 Compose，最后切换到 Compose Navigation。文中最有价值的部分是 AI 辅助重构方法：通过 Git 历史提供上下文、实时纠错、持续更新迁移指南，并把 17 步流程固化为 AI skill。作者给出了 5–7 倍提速、节省约 300–350 工时的结果，但也强调在高风险硬件场景中必须保留截图对比、测试和人工验证。整体结论是：AI 适合重复性强、边界清晰的大规模现代化改造，但前提是先定义好架构目标、约定和检查点。
收录价值明确：文章不仅描述了 Compose 迁移路径，还给出可复用的 AI 辅助重构工作流、检查点和度量结果，属于可迁移的工程经验。适合做 Android 现代化、存量代码重构和 AI 提效实践的参考，但读者需要注意其前提是明确的迁移规范与严格的人为验证。