标签
一位从业者报告称，他在生产环境里数百万行代码的日常软件工程工作中使用 GLM-5.3 Flash，表示其速度并未以牺牲能力为代价，在仓库探索、重构和功能实现方面表现超出对前沿模型的预期。
一篇观点文章，论证 Common Lisp 现在是最好的编程语言，因为大语言模型将瓶颈从编写代码转向了快速反馈循环、基于实时镜像的开发、交互式调试器，以及通过宏驱动的领域特定语言来削减代码量和 token 成本。
# 当 AI 能一夜之间生成可运行代码——重读 Brooks 的《人月神话》 *一篇在 AI 时代重新审视经典之作的反思文章：AI 或许能迅速生成可运行的代码，但真正的瓶颈，正在从「人的协调」转移到「大规模软件系统的规格定义与验证」。* --- ## 一、一本被反复引用、却很少被真正消化的书 1975 年，Frederick P. Brooks 发表了《The Mythical Man-Month》，其中最著名的论断莫过于 Brooks's Law：**向一个已经延期的项目增加人手，只会让它更加延期**。这句话几乎出现在每一场工程管理的讨论里，也几乎总是被当作一个关于「沟通开销随人数平方增长」的注脚。 但如果今天重新翻开这本书，你会发现 Brooks 谈的其实远不止于此。他谈论的是**概念完整性（conceptual integrity）**，是一个软件系统应该像一部小说那样拥有「一个头脑、一种愿景」；他谈论的是外科手术团队式的组织方式；他谈论的是「第二个系统效应」，以及为什么最危险的系统往往不是第一个，而是紧随其后的那个。 在 AI 能够生成可运行代码的今天，这些观点不仅没有过时，反而变得更难被绕过。 ## 二、AI 确实改变了什么 必须诚实地承认 AI 带来的变化。过去需要一名工程师数周才能完成的胶水代码、数据清洗脚本、测试桩和样板工程，现在往往在几分钟内就有了第一版可运行的结果。软件的**产出速度**——严格来说，是「初版代码」的产出速度——已经不再是瓶颈。 这意味着 Brooks 时代里许多与「人力吞吐量」有关的论断，在表层上被削弱了。你不再需要为「缺人写代码」而焦虑，也不再需要在招聘、外包和多团队并行之间反复权衡。 然而，代码只是软件的表层形态。软件真正的本质，是**在一个约束条件下解决问题，并且长期可靠地解决它**。当表层的产出速度被无限拉高，瓶颈只会向更深处移动。 ## 三、真正的瓶颈一：规格（Specification） Brooks 在书中反复强调：软件开发最大的困难不是实现，而是**决定该做什么**。他引用了 Dijkstra 的名言，并指出软件工程师的工作可以粗略分为「想清楚」和「写出来」两部分——而前者才是稀缺且昂贵的。 AI 加速了后者，却丝毫没有降低前者。 一个大型软件系统里最难的部分从来不是「把一个函数写对」，而是： - **需求的边界在哪里**？哪些约束是真实的，哪些只是历史遗留？ - **各个组件之间的契约如何定义**？当两个子系统各自演化时，谁有权决定语义？ - **性能、可靠性、安全性的隐含假设是什么**？这些假设是否被所有人共同理解？ 在这些层面，AI 能够做的是把你已经模糊想清楚的东西快速具体化——但它同样擅长把「你以为想清楚了、其实并没有」的东西写成一份看起来无懈可击的文档。**它不降低规格的难度，它只是提高了错误规格的产出速度**。 ## 四、真正的瓶颈二：验证（Verification） 如果说规格是「决定做什么」，验证就是「确认做出来的东西确实是那个东西」。 这里存在一个容易被忽视的不对称：**生成代码的成本正在趋近于零，但验证代码的正确性并没有**。甚至在某些维度上，验证变得更难了——因为代码可能来自一个你自己无法逐行审阅其推理过程的来源。 在大规模系统中，验证从来不等于「单元测试通过」。它包括： - 不变式（invariants）在跨服务边界时是否仍然成立； - 数据迁移是否真的保持了语义一致性； - 故障场景下的行为是否符合预期； - 以及最困难的一点：**系统是否在它被要求解决的问题上长期有效**。 Brooks 把软件工程类比为医学：他要求工程师像医生一样，既尊重严谨的诊断流程，又保留人性化的判断。当验证的压力从「人力不足」转为「验证成本远高于生成成本」时，这个类比比以往任何时候都更贴切。 ## 五、人的协调问题并没有消失，只是换了一副面孔 需要特别澄清的是：Brooks's Law 并没有失效。它只是换了一个表现形式。 AI 可以同时给多个团队、多个代码库、多个产品线生成方案。当这些方案彼此之间存在隐含的、未被明示的冲突时，协调成本会以平方级增长——与 Brooks 在 1975 年描述的现象完全一致，只是冲突发生的层级从「谁去写这段代码」上移到了「谁来决定系统的行为契约」。 概念完整性仍然是稀缺品。AI 能让每个团队都「跑得很快」，但它无法替整个组织决定：**这个系统在五年后应该长成什么样**。 ## 六、一些可能的回应 如果要从这篇反思中提炼出实践层面的建议，大概会是这几条： 1. **把规格当作一等公民**。在引入 AI 加速之前，先花大力气把约束、不变式和契约写清楚。AI 是放大器，它会同样地放大精确与含混。 2. **把验证能力当作投资**，而不是成本。当生成变得廉价，能够「证明某件事是对的」的那部分能力就是核心竞争力。 3. **保护概念完整性**。仍然需要少数人、以接近外科手术团队的方式，对系统的整体形态保持持续的、集中的关注。 4. **重新理解 Brooks's Law**。它讨论的从来不只是沟通开销，而是**决策集中化与规模化之间的张力**——这一点在多 agent 并行生成的场景下只会更加尖锐。 ## 七、结语 五十年后，Brooks 仍在描述着软件工程的真实形状。AI 没有推翻这本书，它只是把书中的问题从「人手够不够」推进到了「我们知道到底要什么、以及怎么证明我们做到了」。 生成会越来越快，这几乎可以确定。但软件工程的天花板，始终悬在规格与验证那一侧——而那里，仍然需要清醒的人类判断。 --- *本文为重新阅读 Frederick P. Brooks《The Mythical Man-Month》后的个人反思，不构成对任何特定 AI 编码工具的评价。*
本文拆解了 Uber 等公司如何打造“AI 原生软件工厂”——围绕 Claude Code、Codex 等外购编码智能体，构建云端基础设施、模型网关和智能体编排体系——并为其他工程组织提供六大核心模块的搭建步骤图和落地推广方案。
一位用户称赞了 Cognition 的 AI 软件工程师 Devin，表示它现在进步巨大，而且营销广告准确描述了它的能力。
博客文章指出整数与浮点算术遵循不同范式：整数运算需在灾难发生前预防溢出，而 IEEE-754 浮点运算中的 NaN 与无穷值会自然传播，不应照搬预防式检查（如用零分母或 FLT_EPSILON 守卫），这些检查在多数场景下无效且被 LLM 频繁写错。
Atlassian 发布了其 AI SDLC 转型手册，分享了在整个软件开发生命周期——从规划、设计到代码审查和维护——中以企业规模部署 AI 的最佳实践。
一位开发者提问：如何防止 AI 辅助编码的项目迅速退化为不可维护、质量低下的代码——这是人们对 AI 工具下代码质量普遍存在的担忧。
这是一期 Computerphile 视频的中文文字稿，深入讲解了软件中「撤销/重做」功能的实现原理，涵盖撤销粒度的用户预期、用栈（两个栈）实现多级撤销、以及位图编辑中内存开销与快照存储的挑战。
DHH 认为逐行审查 AI 智能体生成的代码是不可持续的，未来在于对抗式智能体审查加自动化测试；而 @msimoni 则持反对态度，表示对由 AI 编写、且无人真正阅读过的软件缺乏信任。
研究提出将智能体记忆类比 Git 仓库，通过 commits 与 branches 管理任务版本，使智能体能丢弃过期需求并从正确版本恢复。方法 GitHarness 在全部 30 个测试设置中优于普通续跑，某设置下编码任务 token 消耗减少 73.6% 且得分更高。
Gergely Orosz 讨论了引入和偿还技术债务的经济学发生了巨大变化，并质疑在 AI 时代，技术债务对软件工程团队还有多大意义。
Gergely Orosz 透露，Uber 在 2026 年运行的微服务数量比 2020 年还要少，延续了行业向规模适中的“宏服务”（macroservices）转变的趋势，以降低维护负担。更多细节将在约两周后与 Uber 工程师 Uday Kiran Medisetty 的播客对话中揭晓。
宝玉点评 Lauren Tan 与 Matt Pocock 的播客访谈：Lauren 在 SpaceXAI 做 Grok Bot，一个月合并 2500 个 PR 却不逐个 Review，而是靠 AI 自动验证、代码规范约束和名为 pstack 的开源 Skill 体系来保证质量。文章提醒读者别急着照搬，要先弄清她能这么做的前提条件——足够强的模型、Token 成本、AI 验证的局限，以及自己专业方向的把控。
Wavestone AI Lab 拆解了 11 个编码智能体——包括 Claude Code 和 Codex——发现它们都遵循一套共通的 7 部件框架（循环、LLM 层、工具、记忆、安全、编排、扩展），最终提炼出一个可复用的 90 行框架和 18 条设计建议。
一条推文指出，未来的 AI 模型在删除和简化代码方面将表现出色，对开发者来说正是时候。
一位拥有 Microsoft 和 Google C/C++ 经验的工程师，在真实 PR 上开展了 12 次 AI 代码审查实验，发现：不带任何共享上下文的全新审查 agent 能发现多得多的缺陷；要发现逻辑 bug，执行代码（而不只是阅读）是必不可少的；而模型的选择对性价比的影响，远大于对绝对能力的影响。
本文认为，每家 SaaS 公司最终都会演变为围绕无状态 LLM 的「套壳框架」（harness）——从没有框架，到个人操作框架，再到个人编排框架，最终由框架编排人——把公司本身变成模型基础设施，人类负责提供上下文、品味与审查。
来自 Meta、Stanford、Harvard 和 UW 的研究人员发布了 SWE-sweep——一个开源基准测试，用于检验语言模型智能体能否在大型代码库中主动发现并修复尚未被发现的漏洞。测试结果显示成绩远低于预期，而 Luna xhigh 在成本效率方面表现出色。
一篇观点文章，认为智能体编程正在引发四大问题——令人望而却步的“slop”代码、工程师对自己手艺的疏离感、代码库质量的退化，以及团队所有权的削弱——而目前几乎看不到任何解决方案的曙光。