标题: [翻译] AI 编程之禅 分类: 工具 创建: 2026-03-17 10:00 修改: 链接: http://0x2531.tech/tools/202603171000.txt -------------------------------------------------------------------------------- AI 编程之禅 2026年3月2日 — 作者：Yoav Aviram 原文链接：https://nonstructured.com/zen-of-ai-coding/ 献给所有对 AI 智能体编程持怀疑态度的人，也献给那些并不怀疑、却在思考这对自己职业前途意味着什么的人。 标题致敬 Tim Peters 的《Python 之禅》。与 Tim 不同，我算不上禅宗大师。我只是想盘点一下我们走到了 哪里、又将去往何方。过去一年里，我每天都在用编程智能体做开发，同时也在帮助团队在不牺牲可靠性和安全性 的前提下拥抱它们。 1. 软件开发已死 2. 代码廉价 3. 重构轻而易举 4. 偿还技术债务亦是如此 5. 所有 Bug 都无处遁形 6. 建立紧密的反馈循环 7. 任何技术栈都是你的技术栈 8. 智能体不仅仅用于编程 9. 上下文瓶颈在你的大脑中 10. 为变化的世界而构建 11. 在考虑"买还是造"时，答案往往是——造 12. 快速产出的垃圾仍然是垃圾 13. 软件是负债，产品才是资产 14. 护城河的代价更高了 15. 为智能体而构建 16. 预见失败模式 --- 【软件开发已死】 你不想写代码？那就一行也不用写了。只要引导得当，编程智能体可以搞定大部分编程任务。 软件开发——作为手动编写代码这件事——正在消亡。一个新的学科正在诞生。你的角色依然至关重要，但重心不再是 敲代码，而是定义问题、塑造上下文、设定约束和评判结果。 代码的边际成本正在坍塌。单凭这一点，就足以改变后面的一切。 【代码廉价】 软件的经济学已经改变。 当编程变得廉价，实现就不再是瓶颈。你可以并行构建十个东西，但你没法同时对十个东西做决策、验证和交付—— 除非你改变流程的其他环节。 延迟的成本转移了。它不再关乎开发者的工时，而是关乎卡在其他环节上的时间：产品决策、含糊的需求、安全审 查、用户测试、发布流程和运营风险。智能体可能会让这些环节排起长队——积压增多，交付周期拉长。延迟反而变 得更贵了，而不是更便宜。 这改变了优先级。撬动效果最大的工作，是那些能解除交付阻碍的事：紧密的反馈循环、测试、评估、防护栏、可 观测性，以及清晰的验收标准——一切能把"我们造得出来"变成"我们信得过它"的事情。 智能体可以帮忙缓解其中一些瓶颈。挑战在于把它们用到编程之外（参见"智能体不仅仅用于编程"）。 【重构轻而易举】 改变主意的成本前所未有地低。曾经感觉不可逆的架构决策，现在随时可以推翻。 你选了 React，两个月后后悔了？让智能体把项目重写一遍就是了。 做出不完美的决策不再致命。事实上，它反而可能带来收获。一个有缺陷的参考实现，比一份完美的设计文档能提 供更好的上下文。智能体基于具体的代码实现来推理，远比基于抽象的设计意图有效得多。 快速迭代如今是默认模式。过去三个月里，我们从零开始重建了四次 CMS，每次用不同的架构。每一次我们都更清 楚自己真正需要什么、什么方案真正可行。 当代码廉价，你就可以多做小实验。 【偿还技术债务亦是如此】 过时的依赖、被忽视的安全补丁——再也没有借口拖着了。升级库、迁移 API、把老旧模式现代化——不过是几句提示 词的事。 定期清理你的代码。主动升级。保持代码整洁。 技术债务并没有消失，但偿还它的成本大幅下降了。这改变了激励结构——继续无视，就说不过去了。 【所有 Bug 都无处遁形】 Linus 定律说："只要眼睛够多，所有 Bug 都是浅显的。"如今，这些"眼睛"已经多到用不完了。 让一个模型审查你的代码，再让另一个审查。它们可能会发现不同的问题。让它们修复各自发现的问题——通常都能 成功。 一段代码里的 Bug 到底有多"密集"，这是个哲学问题。Bug 不会凭空消失，智能体也做不到完美。但从实际角度 看，限制因素不再是审查者的数量，而是你反馈循环的紧密程度。 这里的观点意义深远：逐函数地理解代码库不再是必需的。但与此同时，完全依赖模型无异于自找麻烦。你依然有 活儿要干！（参见：建立紧密的反馈循环、预见失败模式） 【建立紧密的反馈循环】 智能体有时能一步到位。 我们做过能一次性搭出完整定制营销网站的智能体，但这绝对是例外。大多数时候，智能体在反馈引导下朝着明确 目标迭代，才能发挥最佳水平。 好的测试是第一道反馈循环。智能体会反复迭代直到测试通过。你的责任是确保测试质量过关（指导智能体写好测 试），同时确保智能体不会通过弱化测试或跳过测试来"作弊"。 让智能体接入你的 CI，这是第二道反馈。让它接入服务器日志，这是第三道。让智能体能直接看到 UI 渲染结 果，又是一道。 你的工作是设计这样的环境：让迭代收敛于正确，而不是滑向"看起来像那么回事"的胡扯。 没有反馈的速度，就是混乱。 【任何技术栈都是你的技术栈】 只要有训练数据覆盖，智能体在大多数主流技术栈上都能胜任。既然代码不是你亲手写的，你对某个技术栈的执念 就没那么重要了。 别把自己局限在已经熟悉的领域里。你的概念理解力比你想象的更具通用性。 缺术语、缺领域知识？让智能体帮你补课。进入一个陌生生态系统的门槛，从未像现在这样低。 【智能体不仅仅用于编程】 编程只是起点。 智能体可以协助业务分析、用户体验、基础设施、运维、广告投放、分析配置，甚至会计工作流程。 拖了好几年之后，我用几分钟就把四个 WordPress 博客从昂贵的主机迁到了 Hetzner。阻碍从来不是技术难 度，而是注意力。Claude 15 分钟就搞定了。 智能体大幅降低了那些"繁琐但有价值"的工作的行动门槛。 谨慎授权。限制范围。审计结果。只下指令不做监督，是鲁莽的。 【上下文瓶颈在你的大脑中】 上下文工程在进步，工具也在进步。 然而，当你并行跑多个智能体时，真正的瓶颈是人的协调能力。 你得追踪每个智能体在干什么，记住各自做了哪些假设，知道下一步该问什么问题。 智能体越来越擅长管理自己的上下文，而你监督它们的能力反而成了短板。 瓶颈不再是 token 数量，而是你的脑子。 【为变化的世界而构建】 新模型。新能力。新框架。新技能。 世界每天都在变化。有些模型更擅长推理，有些更擅长编程，有些更擅长翻译。 灵活性不是可选项，而是必选项。你必须把它融入工作流程和产品之中。两者都要为实验和快速适应而设计。 【在考虑"买还是造"时，答案往往是——造】 代码贵的时候，买现成的是合理的。当代码趋近于零成本，这笔账就不一样了。 每一个付费 API 现在都值得追问一句：我们能自己实现吗？有必要吗？ 我们的 QA 智能体需要对线上网站做全页截图。很多 API 都提供这个服务。但最终我们选择自己把 Playwright 部署到 AWS Lambda，量身定制并加固安全。 这并不是一概否定 SaaS。维护、安全和规模依然重要。但很多过去非得找供应商的中小型服务，如今已经在自建 能力范围之内了。 有人称之为 SaaS 的终结。 【快速产出的垃圾仍然是垃圾】 速度令人上瘾，也令人危险。 你可以飞速生成海量代码。但速度和代码行数，从来就不是衡量进展的好指标。 重构的成本很低，但尽早发现方向错误的成本更低。 当动手做变得毫无阻力时，自律反而变得更重要了，而不是更不重要。 【软件是负债，产品才是资产】 软件需要花钱维护。只有当它为人创造了价值，才算得上资产。 这话一直都对。但现在构建太容易了，人们更容易忘掉这一点。 抵制堆功能的冲动比以往更难了。但你必须抵制住。做人们真正在用的东西，砍掉没人用的。 【护城河的代价更高了】 功能差距正在迅速缩小。曾经需要数年才能复制的东西，现在也许只要数月。曾经需要数月的，现在也许只要数 天。 靠功能堆出来的护城河，已经守不住了。 护城河正在转向：分发渠道、数据、品牌、网络效应、监管壁垒和生态整合。 入场门槛降低了，但建立壁垒的难度升高了。 【为智能体而构建】 一个新的层级体系正在形成。 最底层是模型（Opus 4.6, GPT-5.3-codex）。模型之上是智能体（Claude Code, OpenClaw）。智能体之 上是服务。 如今，智能体用的还是为人类设计的服务。能用，但不够高效。下一步是专为智能体设计的服务（Moltbook 是先 行者）。 让你的服务对智能体开放。提供结构化的上下文，提供机器可读的接口。 智能体商务正在兴起。有些场景下，一个 markdown 端点就够了。另一些场景下，服务本身就得以智能体为中心 来设计。 智能体优先不是工具层面的选择，而是产品层面的决策。它改变的是你的接口、你的可靠性模型、你的度量指标， 以及你下一步要造什么。 我们正在打造一个智能体优先的 CMS。如果成功，人类不需要去用它——当然他们想用也可以。 AX（智能体体验）是新的 UX（用户体验）。 【预见失败模式】 不要以为"能干"就等于"完美"。 就像一个工程师监督桥梁施工——你的工作不是砌砖，而是确保这座桥不会塌。 智能体会犯错。它们会跑偏。它们会埋下微妙的缺陷。它们会制造安全漏洞。我的一个智能体就曾试图把 .env 文 件提交到 git。它们在"花式搞砸"这方面，创意十足。 你得走在它们前面。问自己：这里可能出什么问题？哪里可能泄露？会暴露什么？智能体在悄悄做什么假设？ 反复推演"如果……会怎样"。然后构建防护栏。 自动化检查。锁死权限。隔离环境。加强监控。预留恢复路径。让回滚轻而易举。 记住，代码是廉价的，而你拥有了新的超能力。构建工具来深入探查、发现漏洞、检验你预想到的每一种失败模 式。设计那种"预期一定会出问题、并能优雅降级"的系统。 这就是"软件开发"和"软件工程"的区别。 --- 【关于作者】 我和工程、产品团队合作，帮他们落地智能体。目标很简单：更快交付，但不降低标准。 我通常从两个方向提供帮助： **智能体优先的软件工程** 我们把智能体变成系统的一部分，而不是尝鲜的玩具。我们设计工作流程、防护栏和配套工具，让团队能放心地把 任务交给智能体。 如果你想用编程智能体，又不想把代码库搞成赌场——来聊聊。 **智能体优先的产品战略** 我帮助公司把产品从"为人设计的界面"转变为"智能体可访问"的，在合理的场景下，进一步转变为"智能体优 先"的。这意味着要厘清：智能体该能做什么、在什么约束下运作，以及你的 API、权限模型、可靠性机制和产品 形态需要做出哪些调整来支撑这一切。 这通常会产出一份智能体接入路线图、一套运营模型，以及一组按优先级排列的产品变更——让智能体成为一等公 民。 我是 WhiteBoar 的联合创始人。在那里，AI 智能体可以在几分钟内（而非几个月）打造你的品牌并上线视觉精 良的营销网站，配备专业的多语言内容。