“那不是我说的用AI的意思”——使用AI开发软件的不同方法分类

# 我说“用AI”不是那个意思 来源：https://mudlej.com/articles/ai-development-approaches/ 文章 在软件开发中使用AI的不同方法分类 作者：Mudlej | 阅读时间：11分钟 | 2026年7月30日 目录1. 0\. 传统开发 (https://mudlej.com/articles/ai-development-approaches/#0-traditional-development) 2. 1\. 有机开发（OD） (https://mudlej.com/articles/ai-development-approaches/#1-organic-development-od) 3. 代理开发（AD） (https://mudlej.com/articles/ai-development-approaches/#agentic-development-ad) 4. 2\. 评审型代理开发 (https://mudlej.com/articles/ai-development-approaches/#2-reviewed-agentic-development) 5. 3\. 引导型代理开发 (https://mudlej.com/articles/ai-development-approaches/#3-guided-agentic-development) 6. 4\. 完全代理开发 (https://mudlej.com/articles/ai-development-approaches/#4-fully-agentic-development) 7. 5\. 氛围编程（Vibe Coding）/ 合成开发 (https://mudlej.com/articles/ai-development-approaches/#5-vibe-coding--synthetic-development) 8. 总结 (https://mudlej.com/articles/ai-development-approaches/#summary) 9. 它们并非互斥 (https://mudlej.com/articles/ai-development-approaches/#they-are-not-mutually-exclusive) 10. 结论 (https://mudlej.com/articles/ai-development-approaches/#conclusion) 听两位开发者争论AI在软件开发中的使用，你常常会听到一些奇怪的现象：两人都在提出合理的观点，都有证据，却都无法理解对方为何会相信自己所相信的东西。 一位说AI生成的代码是未经审查的垃圾，会腐化你的代码库。另一位说他一周内就交付了一个可运行的产品。两人说的都是实话。只是他们描述的不是同一件事。 开发者在使用AI开发软件时，体验可能天差地别，这取决于他们采用的方法。本文是我尝试对1 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-1)这些不同方法进行归类、解释并赋予各自名称。 无论你喜欢AI还是不喜欢，我们首先需要知道我们在谈论什么。在开展有意义的讨论之前，需要先有共同的词汇。 我把大部分**个人观点**放在这种默认折叠的提示框中，如果你愿意，可以主要阅读分类部分。 ## 架构、详细设计与实现 为了避免使用那些对不同读者可能含义不同的术语，我想用一个简单的例子来说明我所指的意思。 1. **架构**： - 选择哪种编程语言？为什么？ - 使用哪个框架或库？为什么？ - 系统的组件有哪些？它们之间如何通信？ - 数据如何建模？存储在哪里？ 2. **详细设计**： - 组件如何执行计算/业务逻辑？ - 每个组件的公共函数是什么？ - 我们如何传递数据？ - 错误如何处理？ 3. **实现**：——实现详细设计的实际代码。 ## 0\. 传统开发 开发者拥有架构、详细设计和实现，其工作方式与过去几十年基本一致：在IDE中编写代码，使用编译器、静态分析、文档和常规工具。AI并不是该过程中的重要部分。 权衡 - **优点：** 开发者对代码库有深入理解和最大控制权。 - **缺点：** 受限于开发者的速度，尤其是在探索、调试和样板代码编写方面。 ## 1\. 有机开发（OD） 开发者仍然在代码编辑器中**手动**完成几乎所有工作，包括编码。但他可能偶尔使用AI来：研究领域或工具、完善设计、调试问题、解释不熟悉的代码、或审查变更。 开发者甚至可能使用AI起草小段代码片段，例如向AI聊天机器人提问或使用AI内联自动补全来帮助编写代码片段，然后手动将其集成到代码库中，通常还会进行一些调整和编辑。**这与过去开发者使用Stack Overflow的方式很接近**。 在此，AI像一个**随叫随到的队友**，但人类仍然是所有开发任务的核心。 权衡 - **优点：** 在保持人类完全主导权的同时，以更好的速度、反馈和准确性改进了传统开发。 - **缺点：** 与其他方法相比，生产力提升可能有限，因为开发者仍然直接完成大部分工作。 关键系统可能应该继续使用这种方法，至少目前如此。 示例 本文就是有机写作的。我花了几天时间完全手动完成。**在**我觉得已经把想说的都说了之后，我才把AI当作研究员，看看别人对这个话题说了什么，并作为审阅者挑战我所写的内容。不过，我从工程师同行那里得到的反馈比任何AI反馈都更有洞察力。 ## 代理开发（AD） 代理开发**至少有三种方法**，它们可能差异很大。它们的共同点是代码由AI生成，而非开发者直接编写。 AD通常通过终端使用命令行工具完成，如Claude Code、Codex、OpenCode以及类似的代理。从事AD的开发者会花费大量时间在这些工具中。 开始时间 代理开发在2025年末的**November Inflection** (https://martinfowler.com/bliki/NovemberInflection.html)（大约在Opus 4.5和GPT-5发布时）之后开始成为一种严肃的选择。2 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-2) 学习成本 所有类型的代理开发都有学习曲线。AD引入了许多学校或训练营中未教授的概念：上下文窗口、代理、子代理、团队、Agent SDK、技能、命令、记忆、**Harness Engineering** (https://martinfowler.com/articles/harness-engineering.html)等等。 ## 2\. 评审型代理开发 在评审型AD中，开发者： - 定义架构。 - 定义详细设计。 - **提示AI代理生成代码**。 - **逐行审查生成的代码**。 人类仍然拥有架构和详细设计，但将实现委托给AI，同时仍仔细审查生成的代码，通常将其推回自己偏好的形状。这通常通过终端或IDE聊天完成。 AI在此像一个不知疲倦的**初级开发者**，其输出需要仔细审查。 在AI生成代码的方法中，这种方法与**氛围编程（Vibe Coding）** (https://mudlej.com/articles/ai-development-approaches/#5-vibe-coding--synthetic-development)相反。 权衡 - **优点：** - 对代码库有高信心和理解。 - 使开发者能够参与相邻的语言、框架或代码库。2 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-2) - **缺点：** - 缓慢且繁琐3 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-3)。 - 人的审查速度成为瓶颈。 评审型AD与有机开发的比较 一些读者可能觉得评审型AD和有机开发之间的界限模糊：在OD中，开发者可以使用AI自动补全然后审查建议，就像在评审型AD中一样。但区别更大。 在OD中，开发者生活在IDE中：浏览代码库，设计接口，编写实现。开发者通过劳动获得深刻理解和“顿悟时刻”。他从内部了解代码库，并理解他所写代码中所蕴含的决策。当AI在此处帮助实现时，感觉更像是寻求在线论坛的帮助，而不是将任务外包给AI。 在评审型AD中，开发者主要与AI对话并编写规范。他不是直接编辑代码库的人，因此他是事后才了解实现。因此，他**不是做出那些小的实现决策的人**。AI做出这些决策，开发者试图理解它们。4 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-4) ## 3\. 引导型代理开发 在引导型AD中，开发者： - 定义架构。 - 定义详细设计。 - **提示AI代理生成代码**。 - **跳过逐行审查代码**。 开发者拥有架构和详细设计，但信任代理能够正确实现该设计。人类可能会浏览代码，检查重要部分，运行测试，并审查行为，但不会阅读每一行或理解每一个小的实现选择。 重点从代码编写转向设计、约束、验证和结果检查。 AI在此像一个**中级开发者**。你与它一起思考设计，然后信任其实现，并通过其他方式进行验证。 权衡 - **优点：** - 比之前的方法快得多。5 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-5) - 人类花费更多时间在那些代理难以做对的决策上。 - **缺点：** - 开发者不完全理解实现。 - AI所做的小实现决策可能会累积并影响非功能性需求，如可维护性、性能、安全性或可观测性。 Harness Engineering 从这一点开始，**Harness Engineering** (https://martinfowler.com/articles/harness-engineering.html) 成为系统的重要组成部分。 ## 4\. 完全代理开发 在完全AD中，开发者： - 定义架构。 - **将详细设计和实现委托给AI**。 开发者拥有高层架构：主要组件、它们的职责、它们如何通信、数据存储在哪里，以及广泛的技术方向。 AI在此像一个**高级开发者**。你与它一起思考架构，然后信任其设计和实现技能。 这仍然与下一种方法不同，因为在完全AD中，开发者关心技术方面：系统形态和代码库方向。 权衡 - **优点：** 可能是开发非平凡软件最快的方式。 - **缺点：** - 没有非常强的防护措施会很危险。 - 代理可能侵蚀边界，引入不一致的设计，违反架构约束，并产生即使对AI也难以维护的代码。 ## 5\. 氛围编程（Vibe Coding）/ 合成开发 这是指提示者**完全停止思考技术方面**，并将注意力完全转向产品的UI/UX。 该术语由Andrej Karpathy在2025年2月于X (https://x.com/karpathy/status/1886192184808149383)上的一篇帖子中提出： > 有一种我称之为“氛围编程”的新式编程，你完全沉浸在氛围中，拥抱指数增长，忘记代码的存在。 此方法中的架构、详细设计和代码实现完全由AI合成开发。 使用AI的人可能不是程序员，也可能不关心系统内部是如何设计的，只要它看起来能工作就行。 AI在此是你的**整个技术团队**，而你是产品经理。 权衡 - **优点：** 对于开发脚本、原型、实验、个人工具、演示、探索产品想法非常有用且极其快速。 - **缺点：** - 用于严肃系统时风险太大。 - 如果在架构中被忽略，可扩展性、安全性、隐私、可靠性、合规性和可维护性等质量属性在后期很难添加。 - 通常完全忽略代码质量。 - 难以处理新颖的想法。6 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-6) ## 总结 | 方法 | 架构 | 设计 | 实现者 | 代码审查者 | 人类拥有 | |------|------|------|--------|------------|----------| | 传统开发 | 人类 | 人类 | 人类 | 人类 | 一切 | | 有机开发 | 人类 | 人类 | 人类 | 人类与AI | 一切 | | 评审型AD | 人类 | 人类 | AI | 人类，逐行 | 实现选择 + | | 引导型AD | 人类 | 人类 | AI | AI | 详细设计 + | | 完全AD | 人类 | AI | AI | AI | 架构 | | 氛围编程 | AI | AI | AI | AI 或无 | 产品 | ## 它们并非互斥 团队可能会根据任务、代码库、风险级别以及可用的Harness和防护措施，在不同方法之间切换。 例如，一个项目可能在架构成形时从有机开发开始。当设计更清晰后，团队可能在早期实现中使用评审型AD。随着信心增强，他们可能转向引导型AD。 对于代码库中边界明确的任务，如果Harness强健，完全AD可能是安全的。 氛围编程对于开发开发工具以及在投入正式设计前快速尝试某个想法也仍然有用。 ## 结论 现在让我们回到开头的两位开发者。 那位称AI代码为未经审查垃圾的人，可能想象的是这样的场景： - 将氛围编程用于生产环境的严肃系统 - 在没有Harness的系统中使用完全AD - 在敏感/脆弱的代码库中使用引导型AD 在这些情况下，他可能是对的：大多数当前的AI模型会在这里腐化代码并损害产品。 那位一周内交付产品的人，可能说的是： - 对一个小的工单使用评审型AD - 在具有良好定义模式的成熟代码库中使用引导型AD - 在具有检查各方面（包括代码质量）的Harness的成熟代码库中使用完全AD - 对个人项目或生产原型使用氛围编程 在这些情况下，他可能是对的：大多数不错的模型可以很好地处理这些情况。 他们各自指向了使用AI的不同方式。给他们这些名称： - 有机开发， - 评审型AD， - 引导型AD， - 完全AD， - 氛围编程， 现在我们可以提出一个更有用的问题：**这种方法对于这个任务、这个代码库、这个风险级别是否有效？** 它不一定能解决谁对谁错。但它告诉你们实际在争论什么，而任何关于AI和软件工程的真正对话都必须从这里开始。7 (https://mudlej.com/articles/ai-development-approaches/#user-content-fn-7) 1. 此分类基于控制权、决策所有权和代码审查深度在人类与AI之间如何划分。↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-1) 2. 评审型AD让开发者有效参与相邻语言、框架或他们不太了解的代码库。由于AI处理第一遍实现，开发者只需足够的流利度来理解、审查和引导生成的代码，前提是定义了架构和设计。↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-2) 3. 评审型AD可能因以下原因变得困难且令人沮丧： - 许多编码代理优化为自主工作，因此以严格控制的逐步工作流使用它们可能感觉像在与工具对抗。 - 许多模型迭代速度慢，这意味着开发者要求的任何更改可能需要几分钟的等待。 - ↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-3) 4. 我认为这没什么不好。许多开发者很高兴避免那些小的实现细节。但重要的是要认识到你将控制权转移出去了。↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-4) 5. 这显然是巨大的生产力提升。但同时，你可能以牺牲理解力为代价来换取速度。↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-5) 6. 因为你很少能促使AI突破它训练数据中的限制。↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-6) 7. 感谢Martin Fowler、Jill Long和其他几位同事对早期草稿的反馈。↩ (https://mudlej.com/articles/ai-development-approaches/#user-content-fnref-7)