AI编程五步法：从需求到交付的完整工作流

很多人以为用 AI 编程很简单——装个 Codex 或 Claude Code，发一条「给我做个笔记软件」的指令，坐等交付就行。但现实往往是：AI 做出来的东西跟你脑子里想的完全是两码事，bug 一堆，返工不断。

B站UP主马克在其视频中分享了一套完整的 AI 编程工作流，核心观点是：让 AI 稳定交付高质量产品，靠的不是一条神级 Prompt，而是一套可复用的流程。 本文将系统梳理这套方法论，并剖析每一步真正解决了什么问题。

为什么单条指令无法让 AI 写出好代码

给 AI 一个指令，它确实能把软件「做出来」，但问题在于：

• 你想的和 AI 交付的可能是两个东西；
• 产品充满 bug，与预期相差甚远；
• 越改越乱，最后自己沦为帮 AI 找 bug 的测试员。

根本原因在于，文字描述的信息密度太低，而 AI 又缺乏自我验证的能力。大语言模型本质上是基于概率的文本生成系统——它根据训练数据中的模式预测「下一个最可能的 token」，而非真正理解你的意图。当你的需求描述存在任何模糊地带，模型就会用它认为「最可能正确」的方式填充空白，而这些填充往往与你的真实预期不符。解决方案就是把开发拆解成清晰的步骤，在每一步锁定预期、控制质量。马克将整个流程归纳为五步法：环境搭建、产品设计、技术设计、产品实现、人工验证。下面以从零做一个电子书阅读器「马克阅读」为例逐步拆解。

第一步：环境搭建——Git 与 agents.md

环境搭建其实只有两件事：Git 和 agents.md。

用 Git 做版本管理

创建好项目文件夹后，第一件事就是让编程 agent 把当前目录初始化为 Git 仓库。Git 是由 Linux 之父 Linus Torvalds 于 2005 年创建的分布式版本控制系统，最初是为了管理 Linux 内核开发而设计。它的核心理念是将项目的每一次变更记录为一个「快照」（commit），这些快照形成一条时间线，开发者可以在任意时间点之间自由穿梭。每完成一个新功能就保存为一个版本快照，一旦代码被改乱，可以一键回退到之前的正常状态。

Git 的分布式架构意味着每个开发者的本地仓库都包含完整的项目历史，不依赖中央服务器。在 AI 编程场景中，一个常见问题是 AI 在修改某个文件时，可能连带修改了其他看似无关的文件——因为大语言模型倾向于「一次性解决所有它认为相关的问题」。Git 的 diff 功能可以精确显示每次提交的具体变更，帮助开发者审查 AI 到底改了什么。此外，Git 的分支（branch）机制允许在不影响主线代码的前提下进行实验性开发——比如让 AI 在一个新分支上尝试某种实现方案，如果效果不好，直接删除分支即可，主线代码丝毫不受影响。

在 AI 编程场景中，Git 的价值被进一步放大——因为 AI 生成代码的不确定性远高于人类手写代码，一次错误的修改可能波及多个文件，没有版本管理就意味着无法安全回退。

马克强烈建议：所有代码项目都用 Git 管理，条件允许的话再推送到 GitHub（基于 Git 的云端托管平台，提供远程备份和协作功能），防止本地代码丢失导致劳动成果付诸东流。

用 agents.md 给 AI 定规矩

agents.md 相当于写给 AI 的「项目说明书」，每次开启新会话，agent 会优先读取其中内容，快速了解项目背景和开发规范。从技术角度看，agents.md 本质上是一种「系统级提示词」（System Prompt）的持久化形式。

在大语言模型的架构中，提示词分为系统提示词（System Prompt）和用户提示词（User Prompt）两个层级。系统提示词定义了模型的行为边界和角色设定，优先级高于用户的具体指令。agents.md 的设计思路正是利用了这一机制——将项目级别的约束（如代码风格、提交规范、测试要求）固化为文件，使其在每次会话中自动生效。这解决了 AI 编程中一个常见痛点：上下文窗口的限制导致长对话后期 AI 可能「忘记」早期的约定。通过 agents.md，关键规则被持久化存储，不随会话长度增加而衰减。

在传统软件开发中，团队通过 CONTRIBUTING.md 或 .editorconfig 等文件统一编码规范；agents.md 则是将这一理念延伸到 AI 协作场景。主流 AI 编程工具如 Claude Code、OpenAI Codex、Cursor 等都支持在项目根目录放置类似的配置文件，Agent 在每次启动新会话时会自动读取，开发者不需要每次都重复交代规则，降低了上下文遗漏的风险。

马克在其中写了两条硬性规定：

1. 每次改动后必须创建对应的 git commit，便于追踪和回滚；
2. 每次改动后必须编写或更新相关测试，并在交付前确保所有测试和验收全部通过。

第二条尤其关键——它要求 AI 写完代码后自己先跑一遍、测一遍，发现问题继续修，直到确认没有明显问题再交付。这样能提前挡掉不少显而易见的 bug，节省大量人力。

第二步：产品设计——用 MVP 思维收敛需求

知道要做电子书阅读器，但具体做成什么样，心里其实没有确切答案。这时马克的做法是先和 AI 讨论产品设计。

从 MVP 开始做减法

MVP（Minimum Viable Product，最小可用产品）概念最早由 Eric Ries 在《精益创业》（The Lean Startup）一书中系统化提出，其核心是用最小的开发成本验证核心假设。在 AI 编程场景中，MVP 思维有了新的实践意义：大语言模型在处理复杂、模糊的需求时容易产生「幻觉」（Hallucination），即生成看似合理但实际不正确的代码。

幻觉的产生源于模型的统计推理本质——它基于训练数据中的概率分布生成输出，而非真正「理解」代码的逻辑。当需求复杂且边界模糊时，模型需要在更大的可能性空间中做出选择，出错的概率自然升高。研究表明，单个 Prompt 中包含的独立需求点越多，模型遗漏或错误实现某些需求的概率呈非线性增长。MVP 策略本质上是在缩小模型的决策空间，让每次交互聚焦于少量明确的需求，从而提高输出的可靠性。

需求越庞大、边界越模糊，AI 出错的概率越高。因此先做减法、聚焦核心功能，不仅是产品策略，更是降低 AI 出错风险的工程手段。第一版只做最核心必要的功能，先把主流程跑通，用低成本快速验证方向——如果一上来功能铺得太大，方向错了很多工作就白做了。

有意思的是，当 AI 给出功能建议时，马克反而在不断做「减法」：

• AI 建议支持 ePub 格式，他改成「先只支持最简单的 txt」；
• txt 没有目录章节概念，那目录解析功能也去掉；
• 主题只做明亮模式，护眼和深色先不做；
• 书签等非必要功能一律推迟。

经过几轮往返，双方对「第一版做什么、不做什么」达成明确共识后，再让 AI 整理成一份产品设计文档，作为后续开发的统一依据。注意他明确要求「不用太详细」，只保证大方向一致即可，细节留到迭代阶段。

要不要先做 Demo

对于后端复杂的产品（如个人知识库涉及文档处理、检索、模型调用），马克会先让 AI 做一个只有前端、数据模拟的 Demo，用来提前验证交互是否顺手，同时给后续实现提供直观参照。

但判断标准很简单——看后端实现成本。电子书阅读器后端很轻（导入 txt 即可），专门做 Demo 反而是重复劳动，不如直接做出完整产品再调整。

第三步：技术设计——确定技术栈与架构

产品方向定了之后，接下来确定技术方案。马克建议新开一个会话专门讨论技术，让上下文更聚焦（虽然他也提到顶级模型的长上下文能力已越来越强，连续跑几小时通常问题不大）。

做法同样是先和 AI 探讨方向：让它读产品设计文档，再询问合适的技术栈。以本案例为例，AI 推荐了 Electron + React + TypeScript + Vite + Electron Forge 这套架构，并对比了 Tauri 等替代方案。

这里简单解释这套技术栈的构成：Electron 是由 GitHub 开发的开源框架，允许使用 Web 技术（HTML、CSS、JavaScript）构建跨平台桌面应用，VS Code、Slack、Discord 等知名应用都基于它构建。它的优势在于前端生态成熟、跨平台一致性好，劣势是内存占用较高（因为每个应用都内嵌了一个 Chromium 浏览器和 Node.js 运行时）。Tauri 是近年兴起的替代方案，使用 Rust 作为后端、系统原生 WebView 作为前端渲染引擎，内存占用和包体积远小于 Electron，但生态成熟度和社区资源尚不及 Electron。React 是 Meta 开源的 UI 库，TypeScript 是 JavaScript 的类型安全超集（通过静态类型检查在编译阶段发现错误），Vite 是新一代前端构建工具（以极快的冷启动和热更新著称），Electron Forge 则是 Electron 官方推荐的项目脚手架和打包工具。

值得注意的是，技术栈的选择在 AI 编程语境下有一个额外的考量维度：AI 对该技术栈的「熟练程度」。由于 Electron 基于 Web 技术栈，而 Web 前端是互联网上代码量最大的技术领域之一，大语言模型在训练阶段接触到的相关代码样本极为丰富，这意味着 AI 在生成 Electron 应用代码时，准确率和代码质量通常高于小众框架。相比之下，Tauri 的 Rust 后端虽然性能更优，但由于社区规模和开源代码量相对较小，AI 生成相关代码时可能不够稳定。因此在 AI 编程场景中，选择主流、社区活跃的技术栈往往能获得更好的 AI 输出质量。

方向确认后，同样让 AI 产出一份技术方案文档存到 docs 文件夹，作为写代码时的参考。

马克坦言自己也不是特别懂这块，「只要保证大体方向没问题就行」——这正体现了流程的价值：即便你不是技术专家，通过与 AI 对齐关键决策，也能控制项目质量。

第四步：产品实现——让 AI 自行验证代码

正式写代码前，有一个极其重要的前提：让 AI 拥有自行验证结果的能力。

以 Codex 为例，马克建议至少安装两个插件：

• Computer Use：用来操作电脑；
• Chrome：用来查看 Chrome 页面。

Computer Use 能力源自 Anthropic 在 2024 年推出的同名技术，它允许 AI 模型像人类一样操控计算机——移动鼠标、点击按钮、输入文字、截取屏幕。其底层实现依赖于视觉语言模型（VLM，Vision-Language Model）——AI 通过截取屏幕图像来「看到」当前界面状态，然后基于视觉理解决定下一步操作（如点击坐标、输入文本）。这与传统的自动化测试工具（如 Selenium、Playwright）有本质区别：传统工具通过 DOM 选择器精确定位元素，而 Computer Use 是通过「看图」来操作，更接近人类的使用方式。这种方式的优势是通用性强（不依赖特定的测试框架），劣势是精度和速度不如传统工具。

这项能力的意义在于，AI 不再只是「写完代码就交差」，而是可以启动应用、在界面上执行操作、观察结果，形成「编写→运行→验证→修复」的完整闭环。配合 Chrome 插件读取浏览器页面内容，AI 能够验证 Web 界面的渲染结果是否符合预期。这相当于给 AI 配备了一个自动化 QA（Quality Assurance，质量保证）环境，大幅减少需要人工排查的低级错误。

有了这两个插件，大部分功能都能交给 AI 自行验证。这一点是整套 AI 编程方法的核心之一：没有验证环境，AI 极易写出一堆 bug——毕竟人写代码没法验证也会漏错百出。

随后新建会话，让 AI 读取产品设计和技术方案两份文档，据此实现产品。写代码耗时较长，完成后 AI 会按照 agents.md 的要求完成各种自测，确保代码通过验证。

第五步：人工验证——AI 自测代替不了亲手试用

即便 AI 自测再充分，也不可能覆盖所有问题。产品实际跑起来时，第一次 npm start 就直接报错——这正说明「AI 并非 100% 靠谱，即使能自测也未必完全可靠」。

把报错反馈给 Codex，它修复后再试，错误消失，成功导入 txt 文件，MVP 至此完成。

AI 自测的局限性存在于多个层面。首先是「已知未知」与「未知未知」的区别：AI 只能验证它能预见的场景，而真实用户的操作路径往往超出预设范围（如快速连续点击、在极端网络环境下使用、输入非预期格式的文件等）。其次是体验层面的主观判断——动画是否流畅、交互是否直觉、信息层级是否清晰，这些涉及人类认知和审美的维度，当前 AI 尚无法可靠评估。最后是上下文偏差问题：AI 的自测是基于它对需求的理解进行的，如果 AI 一开始就理解偏了，它的测试用例本身就是错的，形成「自己出题自己答」的闭环盲区。

交互体验、边界情况这类问题很容易被 AI 自测漏掉，产品到底好不好用、是不是自己真正想要的，最终还得亲自试一遍才知道。

AI 编程中三条不能省的原则

五步流程可以根据需求灵活裁剪：简单且不重要的需求，可跳过产品设计和技术设计，搭好环境直接让 AI 实现再验证；复杂且重要的需求，则走完完整五步以保证质量。

本质上这是开发效率与结果可控性之间的取舍：你参与得越多，掌控力越强，但耗时越长；参与得越少，越省事越快，但结果偏离预期的概率也越高。

不过无论怎么调整，马克强调有三件事绝不能省：

1. 必须有版本管理工具（如 Git）。AI 写代码不可能次次正确，甚至会在修改中把原本正常的功能改坏。这在软件工程中被称为「回归缺陷」（Regression Bug），即修复一个问题的同时引入了新问题。回归缺陷是软件工程中最令人头疼的问题类型之一，在传统开发中通常通过回归测试套件来防范。AI 编程场景中回归缺陷的风险尤其高，因为大语言模型缺乏对代码库全局依赖关系的精确把握——当 AI 修复某个 bug 时，它可能只关注了出错的局部代码，而忽略了该代码与其他模块之间的耦合关系。有 Git 才能随时回退到正常状态。
2. 必须给 AI 自测能力。否则自己就沦为测试员，来回帮 AI 找 bug，极度浪费时间。这也是 agents.md 中要求「每次改动都必须编写或更新相关测试」的深层原因——累积的测试用例形成了一张安全网，任何修改如果破坏了已有功能，测试会立即报警。这在软件工程中被称为「持续集成」（Continuous Integration）理念的简化实践。
3. 必须进行人工验证。AI 自测无法覆盖所有问题，交互体验和边界情况尤其容易被漏掉。

结语

这套五步法的真正价值，不在于某个特定工具（Codex、Claude Code 或其他 agent 都通用），而在于它把一个模糊的「让 AI 帮我写软件」拆解成了可控、可复用的工程流程。

正如马克所说，这只是现阶段探索出的较合理方法，并非唯一答案。随着大模型能力持续进化，AI 编程的模式还会不断变化。但「版本管理、AI 自测、人工验证」这三条底层原则，在可预见的未来仍将是稳定交付的基石。