2025 年 2 月Andrej Karpathy 创造了vibe coding氛围编程这个词描述你想要什么让 AI 写代码然后忘掉代码的存在。它迅速走红。每个人都想相信编程已经变得像说话一样简单。一年后Karpathy 给它改了名。新术语是“agentic engineering智能体工程” 。他的解释很尖锐。用’工程’来强调其中存在艺术、科学和专业技能。“他在几周内从 80% 手动编码转为 80% 智能体编码并痛苦地发现模型是参差不齐的”——在难题上表现出色却在显而易见的地方栽跟头。数据支持他的观点。GitClear 的 2025 年代码质量研究 发现AI 共同撰写的 pull request 比纯人工 PR 的问题多 1.7 倍。复制粘贴的代码行从 2021 年的 8.3% 上升到 2024 年的 12.3%。与此同时AI 现在撰写了 GitHub 上 41% 的代码Copilot 付费订阅者达到 470 万。我们产出的代码比以往任何时候都多。它也从未如此充满 bug。这不是生产力的繁荣。这是以复利利率增长的技术债务。Matt Pocock 在他的 AI Hero 大会演讲中直言不讳“代码并不廉价。糟糕的代码从未如此昂贵。”他的理由是如果你的代码库难以修改你就无法吸收 AI 的输出。每一个建议、每一个生成的函数、每一个自动重构都会撞上糟糕架构的摩擦。AI 不会修复结构性问题。它会放大它们。核心论点是AI 是乘数不是魔杖。它会放大你放在它面前的任何架构。好的结构在每次交互中都能带来更多价值。坏的结构在每个提示中都会加速腐烂。五项软件基础原理将那些自信交付的团队与那些淹没在 AI 生成意大利面条代码中的团队区分开来。没有一项是新的。它们从未如此重要。1. 构建前先对齐Karpathy 指出了 AI 编码智能体的四种结构性失败模式。第一种模型会替你做出错误假设然后不加检查地继续执行。你以为自己只是要一个简单的 API 端点。AI 却构建了一个包含认证、速率限制和你从未提及的数据库迁移的微服务。问题不在于 AI 的能力。而在于你和 AI 没有共享关于你正在构建什么的思维模型。Frederick Brooks 在The Design of Design中写过这个问题。他称之为设计概念——关于你正在创造的东西的隐性的、共享的理论。它不是文档。不是规格文件。它是合作者之间关于他们正在构建什么以及为什么构建的理解。当两个人结对编程时他们通过对话自然地建立这种理解。当你向 AI 发出提示时这种共享理解默认不存在。Pocock 的解决方案是一个他称之为grill me拷问我的 Claude Code skill。整个指令只有两行无情地就这个计划的每个方面采访我直到我们达成共同理解。沿着设计树的每个分支走下去逐一解决决策之间的依赖关系。它迅速走红。GitHub 上获得了 97,000 多颗星。AI 会提出 40、60、有时甚至 100 个问题才满意。它将智能体变成一个不会让你跳过思考的对手。原理不要让 AI 开始编码直到你们共享了思维模型。写好简报定义约束先回答难题。你花 20 分钟对齐节省的是 3 小时撤销错误假设的时间。2. 说同一种语言如果在计划上对齐了但你和 AI 用同一个词表达不同的意思那还是不够的。Karpathy 的第二种失败模式“过度复杂的解决方案。要一个 10 行的函数得到一个 200 行的企业级框架。”AI 不是恶意的。它只是不知道你的词汇表。当你说handler时你是指 HTTP handler、event handler还是 log handler当你说service时那是微服务、后台 worker还是一个类AI 会猜。它猜错了。然后它建造了一座 200 行的错误猜测纪念碑。这是软件工程 20 年前就解决的问题。Eric Evans 在 2003 年出版了Domain-Driven Design核心概念就是ubiquitous language通用语言——开发者、领域专家和代码库本身都一致使用的共享词汇。每一次对话、每一个变量名、每一个 API 端点都用相同的术语表达相同的意思。Evans 最近告诉 InfoQ在限定上下文的通用语言上训练语言模型相比使用通用 LLM对特定需求要有用得多。你的领域词汇表现在成了提示工程的资产。Pocock 也为此构建了一个 skill。他的ubiquitous language通用语言 skill 扫描你的代码库提取术语并生成一个充满定义表格的 markdown 文件。他报告说通过阅读 AI 的思考轨迹通用语言不仅改善了规划。它让 AI思考得更简洁。更少的 token 浪费。更准确的实现。生成的代码真正匹配了计划。DDD 的限定上下文在这里也适用。在多智能体设置中不清晰的术语所有权会导致上下文泄漏——智能体互相踩到对方的领域重复逻辑或者输出相互矛盾。Evans 20 年前在人类团队中描述的相同失败模式现在在智能体编排中重现。原理构建一个词汇表。精确定义你的领域术语。在你的项目文档和提示中引用它。如果 AI 知道order在订单管理上下文中意味着客户承诺而不是排序指令它就会停止猜测开始生成适配的代码。3. 先测试小步交付你们已经在计划上对齐了。你们说着同一种语言。AI 构建的正是你要的东西。但它不工作。这是最耗时的失败模式因为代码看起来是对的。读起来不错。变量名有意义。但一运行就崩溃因为 AI 一次性产出了 400 行代码没有检查其中任何一行。The Pragmatic Programmer称之为超出你的车灯范围。反馈速率是你的速度限制。开得比车灯照得远你就会撞上没看到的障碍。AI 智能体默认是关灯驾驶的。它们产出大量代码然后才想起来验证。Anthropic 的 最佳实践 推荐 writer/reviewer 模式“一个 Claude 写测试另一个写代码来通过测试。” OpenAI 的 Codex 文档 说得更直白“没有测试Codex 用自己的判断来验证工作。测试创造了外部真相来源。”两个平台得出了相同的答案测试驱动开发。不是作为哲学。而是作为强制 AI 小步前进的机械约束。先写测试。让 AI 让它通过。重构。Red-green-refactor 不是敏捷时代的遗物。它是防止熵增的反馈循环。每个循环的成本只是大批量重写的一小部分无论是 token、上下文窗口空间还是你自己的审查时间。2025 年 5 月的一篇 arXiv 研究 发现随着智能体从独立脚本转向多模块系统代码异味密度增加。没有测试边界腐烂会随着代码库规模扩大。有了它们每个模块保持诚实。原理与 AI 一起编码时TDD 不是可选的。它是保持输出可信的速度限制器。写测试让智能体实现验证重复。小循环高信心。4. 建深不建宽即使测试通过了正确的东西也在构建中随着代码库增长还是会出现结构性问题。AI 开始迷路。它找不到正确的文件。它误解依赖关系。它做出的改动会破坏三个模块之外的东西。John Ousterhout 在A Philosophy of Software Design中描述了这个问题。他区分了 deep modules深模块和 shallow modules浅模块Deep modules 在简单接口后隐藏了大量功能。你不需要理解内部就能使用它们。Shallow modules 则相反功能不多但接口复杂迫使你理解底层的一切。AI 智能体特别擅长生成 shallow modules。大量小文件每个做一件小事每个暴露多个函数每个依赖另外三个小文件。看起来干净。代码审查时读起来不错。但它给下一次 AI 会话创造了导航噩梦因为智能体必须遍历几十个相互连接的 blob 才能理解你的代码实际在做什么。Pocock 在演讲中直观地展示了这一点。充满 shallow modules 的代码库看起来像散落的点之间有纠缠的箭头。同样的代码重组为 deep modules 后看起来像几个大块顶部有简单的连接。AI 在第二种结构中导航并生成更好的代码因为它可以推理接口而不必将每个实现细节加载到上下文窗口中。关于 AI 生成代码异味的 arXiv 论文 也实证证实了这一点。随着智能体从独立脚本转向多模块系统代码异味密度增加。LLM 在推理时不会跟踪架构复杂性。你的模块结构越碎片化AI 的输出就越差。这里也有市场信号。TypeScript 在 2025 年 8 月成为 GitHub 排名第一的语言。部分原因是类型良好、结构良好的代码让 AI 辅助开发更可靠。开发者正在自我选择那些能放大 AI 回报的架构就像多元化投资组合能放大市场回报一样。那些固守无类型、碎片化代码库的人正在返工中付出代价。原理审计你的代码库中的 shallow modules。将相关代码包装成具有简单接口的 deep modules。在边界处测试。AI 不需要看到一切。它需要看到正确的接口。5. 设计接口委托实现如果前四个原理保护 AI 输出的质量这一个保护你自己。如果你在使用 AI 编码工具后感到比以往任何时候都更精神疲惫请举手。你不是一个人。Pocock 在大会上问了同样的问题。几乎所有人都举了手。疲惫来自于试图审查一切。每一个生成的函数、每一个重构的类、每一个智能体创建的新文件。你正在交付比以往更多的代码但你的大脑仍然是理解所有代码的瓶颈。Kent Beck 的建议“每天投资于系统设计。”specs-to-code 运动做的是相反的事。它从设计中撤资。它将代码库视为从提示中重新生成的可丢弃输出。这就是你最终审查 400 行你没写过且几乎跟不上的代码的原因。替代方案是灰盒模型。你拥有接口。你拥有边界处的测试。你让 AI 处理模块内部的内容。对于非关键模块你不需要审查每一行实现。你需要验证契约是否工作。这就是 Karpathy 所说的新核心技能是判断力——委托什么、如何指定、如何快速审查。你写更少的代码不是因为懒。你写更少的代码是因为你把时间花在了架构、接口和验证上。战略层面。Pocock 将其框定为战术程序员和战略程序员之间的区别。AI 是战术程序员是地面上的中士做出代码改动。你是思考系统设计、模块边界以及各部分如何组合的人。这不是降职。这是升职。Anthropic 的内部数据显示在大规模重构任务上有 2-3 倍的生产力提升。但这些提升来自那些足够信任架构从而自信委托的团队而不是那些审查每一行生成代码的团队。原理写接口。指定契约。将实现委托给 AI。通过测试验证而不是逐行代码审查。你的工作是系统设计。让智能体处理其余部分。6、工具包从原理到实践没有工具的 principles 只是建议。以下是你今天就能安装的东西。Pocock 将他的 skills 作为 开源仓库 发布。每一个都直接映射到上述原理grill-me在 AI 写任何东西之前强制共享理解原理 1ubiquitous-language扫描你的代码库并构建领域词汇表原理 2tdd在每个模块上强制执行 red-green-refactor 循环原理 3improve-codebase-architecture识别 shallow modules 并将它们包装成 deep ones原理 4writer-prd在 PRD 中指定模块变更和接口契约原理 5但这些原理不只是某个开发者的个人意见。主要平台独立构建了基础设施来强制执行相同的理念。Anthropic 的 Claude Code 使用 CLAUDE.md 作为对齐契约支持将子智能体限定在具有干净上下文窗口的隔离任务中并推荐 writer/reviewer 模式一个智能体写测试另一个写实现。OpenAI 的 Codex 出于相同目的使用 AGENTS.md带有明确的done when标准强制智能体在认为任务完成之前进行测试验证。GitHub Copilot 的 agent mode 构建了你仓库的语义索引比 2025 年初的检索准确率高 37.6%并支持自定义智能体和提示文件作为可复用的蓝图。三个平台。相同的结构性答案。对齐文档、测试循环、模块边界。它们都趋同因为它们都撞上了同一堵墙模型能力不是瓶颈。代码架构才是。7、贯穿始终的主线Brooks 在 1975 年写了关于共享设计概念的内容。Evans 在 2003 年出版了通用语言。Ousterhout 在 2018 年画出了深模块图。Beck 几十年来一直在说每天投资于设计。Karpathy 在几周内在压力下使用地球上最强大的 AI 模型进行构建时发现了同样的教训。Pocock 将它们提炼成 skills这些 skills 之所以走红是因为成千上万的开发者认出了自己的痛苦。这些都不是新知识。这就是重点。一个聪明的提示给你一次好的输出。一个结构良好的代码库给你一千次。每一个干净的接口、每一个强制的测试边界、每一个深模块都会放大之后的每一次 AI 交互的价值。跳过架构你就是在复利债务。代码并不廉价。你的架构就是你的 AI 策略。原文链接用软件工程放大你的 AI 产出 - 汇智网
用软件工程放大你的 AI 产出
发布时间：2026/6/5 14:43:54
2025 年 2 月Andrej Karpathy 创造了vibe coding氛围编程这个词描述你想要什么让 AI 写代码然后忘掉代码的存在。它迅速走红。每个人都想相信编程已经变得像说话一样简单。一年后Karpathy 给它改了名。新术语是“agentic engineering智能体工程” 。他的解释很尖锐。用’工程’来强调其中存在艺术、科学和专业技能。“他在几周内从 80% 手动编码转为 80% 智能体编码并痛苦地发现模型是参差不齐的”——在难题上表现出色却在显而易见的地方栽跟头。数据支持他的观点。GitClear 的 2025 年代码质量研究 发现AI 共同撰写的 pull request 比纯人工 PR 的问题多 1.7 倍。复制粘贴的代码行从 2021 年的 8.3% 上升到 2024 年的 12.3%。与此同时AI 现在撰写了 GitHub 上 41% 的代码Copilot 付费订阅者达到 470 万。我们产出的代码比以往任何时候都多。它也从未如此充满 bug。这不是生产力的繁荣。这是以复利利率增长的技术债务。Matt Pocock 在他的 AI Hero 大会演讲中直言不讳“代码并不廉价。糟糕的代码从未如此昂贵。”他的理由是如果你的代码库难以修改你就无法吸收 AI 的输出。每一个建议、每一个生成的函数、每一个自动重构都会撞上糟糕架构的摩擦。AI 不会修复结构性问题。它会放大它们。核心论点是AI 是乘数不是魔杖。它会放大你放在它面前的任何架构。好的结构在每次交互中都能带来更多价值。坏的结构在每个提示中都会加速腐烂。五项软件基础原理将那些自信交付的团队与那些淹没在 AI 生成意大利面条代码中的团队区分开来。没有一项是新的。它们从未如此重要。1. 构建前先对齐Karpathy 指出了 AI 编码智能体的四种结构性失败模式。第一种模型会替你做出错误假设然后不加检查地继续执行。你以为自己只是要一个简单的 API 端点。AI 却构建了一个包含认证、速率限制和你从未提及的数据库迁移的微服务。问题不在于 AI 的能力。而在于你和 AI 没有共享关于你正在构建什么的思维模型。Frederick Brooks 在The Design of Design中写过这个问题。他称之为设计概念——关于你正在创造的东西的隐性的、共享的理论。它不是文档。不是规格文件。它是合作者之间关于他们正在构建什么以及为什么构建的理解。当两个人结对编程时他们通过对话自然地建立这种理解。当你向 AI 发出提示时这种共享理解默认不存在。Pocock 的解决方案是一个他称之为grill me拷问我的 Claude Code skill。整个指令只有两行无情地就这个计划的每个方面采访我直到我们达成共同理解。沿着设计树的每个分支走下去逐一解决决策之间的依赖关系。它迅速走红。GitHub 上获得了 97,000 多颗星。AI 会提出 40、60、有时甚至 100 个问题才满意。它将智能体变成一个不会让你跳过思考的对手。原理不要让 AI 开始编码直到你们共享了思维模型。写好简报定义约束先回答难题。你花 20 分钟对齐节省的是 3 小时撤销错误假设的时间。2. 说同一种语言如果在计划上对齐了但你和 AI 用同一个词表达不同的意思那还是不够的。Karpathy 的第二种失败模式“过度复杂的解决方案。要一个 10 行的函数得到一个 200 行的企业级框架。”AI 不是恶意的。它只是不知道你的词汇表。当你说handler时你是指 HTTP handler、event handler还是 log handler当你说service时那是微服务、后台 worker还是一个类AI 会猜。它猜错了。然后它建造了一座 200 行的错误猜测纪念碑。这是软件工程 20 年前就解决的问题。Eric Evans 在 2003 年出版了Domain-Driven Design核心概念就是ubiquitous language通用语言——开发者、领域专家和代码库本身都一致使用的共享词汇。每一次对话、每一个变量名、每一个 API 端点都用相同的术语表达相同的意思。Evans 最近告诉 InfoQ在限定上下文的通用语言上训练语言模型相比使用通用 LLM对特定需求要有用得多。你的领域词汇表现在成了提示工程的资产。Pocock 也为此构建了一个 skill。他的ubiquitous language通用语言 skill 扫描你的代码库提取术语并生成一个充满定义表格的 markdown 文件。他报告说通过阅读 AI 的思考轨迹通用语言不仅改善了规划。它让 AI思考得更简洁。更少的 token 浪费。更准确的实现。生成的代码真正匹配了计划。DDD 的限定上下文在这里也适用。在多智能体设置中不清晰的术语所有权会导致上下文泄漏——智能体互相踩到对方的领域重复逻辑或者输出相互矛盾。Evans 20 年前在人类团队中描述的相同失败模式现在在智能体编排中重现。原理构建一个词汇表。精确定义你的领域术语。在你的项目文档和提示中引用它。如果 AI 知道order在订单管理上下文中意味着客户承诺而不是排序指令它就会停止猜测开始生成适配的代码。3. 先测试小步交付你们已经在计划上对齐了。你们说着同一种语言。AI 构建的正是你要的东西。但它不工作。这是最耗时的失败模式因为代码看起来是对的。读起来不错。变量名有意义。但一运行就崩溃因为 AI 一次性产出了 400 行代码没有检查其中任何一行。The Pragmatic Programmer称之为超出你的车灯范围。反馈速率是你的速度限制。开得比车灯照得远你就会撞上没看到的障碍。AI 智能体默认是关灯驾驶的。它们产出大量代码然后才想起来验证。Anthropic 的 最佳实践 推荐 writer/reviewer 模式“一个 Claude 写测试另一个写代码来通过测试。” OpenAI 的 Codex 文档 说得更直白“没有测试Codex 用自己的判断来验证工作。测试创造了外部真相来源。”两个平台得出了相同的答案测试驱动开发。不是作为哲学。而是作为强制 AI 小步前进的机械约束。先写测试。让 AI 让它通过。重构。Red-green-refactor 不是敏捷时代的遗物。它是防止熵增的反馈循环。每个循环的成本只是大批量重写的一小部分无论是 token、上下文窗口空间还是你自己的审查时间。2025 年 5 月的一篇 arXiv 研究 发现随着智能体从独立脚本转向多模块系统代码异味密度增加。没有测试边界腐烂会随着代码库规模扩大。有了它们每个模块保持诚实。原理与 AI 一起编码时TDD 不是可选的。它是保持输出可信的速度限制器。写测试让智能体实现验证重复。小循环高信心。4. 建深不建宽即使测试通过了正确的东西也在构建中随着代码库增长还是会出现结构性问题。AI 开始迷路。它找不到正确的文件。它误解依赖关系。它做出的改动会破坏三个模块之外的东西。John Ousterhout 在A Philosophy of Software Design中描述了这个问题。他区分了 deep modules深模块和 shallow modules浅模块Deep modules 在简单接口后隐藏了大量功能。你不需要理解内部就能使用它们。Shallow modules 则相反功能不多但接口复杂迫使你理解底层的一切。AI 智能体特别擅长生成 shallow modules。大量小文件每个做一件小事每个暴露多个函数每个依赖另外三个小文件。看起来干净。代码审查时读起来不错。但它给下一次 AI 会话创造了导航噩梦因为智能体必须遍历几十个相互连接的 blob 才能理解你的代码实际在做什么。Pocock 在演讲中直观地展示了这一点。充满 shallow modules 的代码库看起来像散落的点之间有纠缠的箭头。同样的代码重组为 deep modules 后看起来像几个大块顶部有简单的连接。AI 在第二种结构中导航并生成更好的代码因为它可以推理接口而不必将每个实现细节加载到上下文窗口中。关于 AI 生成代码异味的 arXiv 论文 也实证证实了这一点。随着智能体从独立脚本转向多模块系统代码异味密度增加。LLM 在推理时不会跟踪架构复杂性。你的模块结构越碎片化AI 的输出就越差。这里也有市场信号。TypeScript 在 2025 年 8 月成为 GitHub 排名第一的语言。部分原因是类型良好、结构良好的代码让 AI 辅助开发更可靠。开发者正在自我选择那些能放大 AI 回报的架构就像多元化投资组合能放大市场回报一样。那些固守无类型、碎片化代码库的人正在返工中付出代价。原理审计你的代码库中的 shallow modules。将相关代码包装成具有简单接口的 deep modules。在边界处测试。AI 不需要看到一切。它需要看到正确的接口。5. 设计接口委托实现如果前四个原理保护 AI 输出的质量这一个保护你自己。如果你在使用 AI 编码工具后感到比以往任何时候都更精神疲惫请举手。你不是一个人。Pocock 在大会上问了同样的问题。几乎所有人都举了手。疲惫来自于试图审查一切。每一个生成的函数、每一个重构的类、每一个智能体创建的新文件。你正在交付比以往更多的代码但你的大脑仍然是理解所有代码的瓶颈。Kent Beck 的建议“每天投资于系统设计。”specs-to-code 运动做的是相反的事。它从设计中撤资。它将代码库视为从提示中重新生成的可丢弃输出。这就是你最终审查 400 行你没写过且几乎跟不上的代码的原因。替代方案是灰盒模型。你拥有接口。你拥有边界处的测试。你让 AI 处理模块内部的内容。对于非关键模块你不需要审查每一行实现。你需要验证契约是否工作。这就是 Karpathy 所说的新核心技能是判断力——委托什么、如何指定、如何快速审查。你写更少的代码不是因为懒。你写更少的代码是因为你把时间花在了架构、接口和验证上。战略层面。Pocock 将其框定为战术程序员和战略程序员之间的区别。AI 是战术程序员是地面上的中士做出代码改动。你是思考系统设计、模块边界以及各部分如何组合的人。这不是降职。这是升职。Anthropic 的内部数据显示在大规模重构任务上有 2-3 倍的生产力提升。但这些提升来自那些足够信任架构从而自信委托的团队而不是那些审查每一行生成代码的团队。原理写接口。指定契约。将实现委托给 AI。通过测试验证而不是逐行代码审查。你的工作是系统设计。让智能体处理其余部分。6、工具包从原理到实践没有工具的 principles 只是建议。以下是你今天就能安装的东西。Pocock 将他的 skills 作为 开源仓库 发布。每一个都直接映射到上述原理grill-me在 AI 写任何东西之前强制共享理解原理 1ubiquitous-language扫描你的代码库并构建领域词汇表原理 2tdd在每个模块上强制执行 red-green-refactor 循环原理 3improve-codebase-architecture识别 shallow modules 并将它们包装成 deep ones原理 4writer-prd在 PRD 中指定模块变更和接口契约原理 5但这些原理不只是某个开发者的个人意见。主要平台独立构建了基础设施来强制执行相同的理念。Anthropic 的 Claude Code 使用 CLAUDE.md 作为对齐契约支持将子智能体限定在具有干净上下文窗口的隔离任务中并推荐 writer/reviewer 模式一个智能体写测试另一个写实现。OpenAI 的 Codex 出于相同目的使用 AGENTS.md带有明确的done when标准强制智能体在认为任务完成之前进行测试验证。GitHub Copilot 的 agent mode 构建了你仓库的语义索引比 2025 年初的检索准确率高 37.6%并支持自定义智能体和提示文件作为可复用的蓝图。三个平台。相同的结构性答案。对齐文档、测试循环、模块边界。它们都趋同因为它们都撞上了同一堵墙模型能力不是瓶颈。代码架构才是。7、贯穿始终的主线Brooks 在 1975 年写了关于共享设计概念的内容。Evans 在 2003 年出版了通用语言。Ousterhout 在 2018 年画出了深模块图。Beck 几十年来一直在说每天投资于设计。Karpathy 在几周内在压力下使用地球上最强大的 AI 模型进行构建时发现了同样的教训。Pocock 将它们提炼成 skills这些 skills 之所以走红是因为成千上万的开发者认出了自己的痛苦。这些都不是新知识。这就是重点。一个聪明的提示给你一次好的输出。一个结构良好的代码库给你一千次。每一个干净的接口、每一个强制的测试边界、每一个深模块都会放大之后的每一次 AI 交互的价值。跳过架构你就是在复利债务。代码并不廉价。你的架构就是你的 AI 策略。原文链接用软件工程放大你的 AI 产出 - 汇智网
