我的 AI 编程全流程：从 Agent 选择到高质量产品交付
很多人把 AI 编程理解成“把需求发给模型，然后等待代码生成”。但一个真正能交付的产品，难点通常不在于模型能不能写出某个函数，而在于能不能把模糊想法逐步变成明确方案，在受控环境中实现，最后用可复现的方式确认结果。
YouTube 视频《我的 AI 编程全流程：如何使用 AI 稳定交付一个高质量的产品》由马克的技术工作坊发布，视频地址为原始视频，公开发布日期为 2026 年 8 月 29 日。视频简介给出的时间轴依次覆盖：挑选编程 Agent、环境搭建、产品方案设计、技术方案设计、产品实现和整体流程回顾。
本文不是视频逐字稿。整理时可以核对到视频标题、频道、发布日期和公开时间轴，但无法通过匿名公开接口稳定获取完整字幕。因此，下面把视频公开主题整理为一套可复用的交付框架；其中“检查清单”“风险边界”和部分工程化表达属于本文编辑归纳，不应当当作视频作者的逐句原话。
一、先看结论：AI 编程的核心不是生成代码，而是稳定交付
AI 编程真正要解决的问题，可以写成一条交付链：
想法
→ 选择适合任务的编程 Agent
→ 准备可恢复的开发环境
→ 冻结产品目标与验收标准
→ 设计技术方案与边界
→ 分阶段实现和验证
→ 复盘、修正、交付
这条链上的每一步都在减少一种不确定性：
| 阶段 | 要减少的不确定性 | 最小产物 |
|---|---|---|
| Agent 选择 | 不知道谁负责什么 | 工具选择理由和任务边界 |
| 环境搭建 | 不知道代码在哪里、如何运行 | 可启动的项目环境 |
| 产品方案 | 不知道做什么才算完成 | 用户流程、范围和验收条件 |
| 技术方案 | 不知道怎样可靠实现 | 模块、数据流和失败处理 |
| 产品实现 | 不知道改动是否有效 | 可运行功能、测试和验证记录 |
| 流程回顾 | 不知道下次如何更快更稳 | 问题清单和可复用规则 |
如果只保留“模型生成代码”这一步，最后往往得到的是一段看起来完整、但无法启动、无法验证，或者与真实需求不一致的代码。
二、第一步不是开工，而是挑选编程 Agent
视频的第一个主题是挑选编程 Agent。选择工具时，容易陷入“哪个模型最强”的比较，但实际开发更应该问：这个工具是否适合当前任务和工作方式。
1. 按任务类型选择，而不是按品牌选择
不同任务对 Agent 的要求不同：
| 任务 | 更重要的能力 |
|---|---|
| 阅读陌生仓库 | 上下文理解、搜索和结构化总结 |
| 修改单个模块 | 文件定位、局部编辑和回归验证 |
| 完成跨文件功能 | 计划能力、依赖追踪和持续执行 |
| 处理长时间任务 | 状态保持、恢复能力和日志可读性 |
| 代码审查 | 关注边界、测试、错误处理和副作用 |
| 快速原型 | 低摩擦交互、快速反馈和界面预览 |
因此，工具选择至少要看四件事：
- 执行面：它是在终端、IDE、桌面应用还是云端运行？
- 上下文面：它能否稳定读取项目规则、相关文件和历史结果？
- 修改面：它能修改哪些文件，是否支持预览、审查和回滚？
- 验证面：它能否运行测试、构建、静态检查并返回清晰结果？
2. 不要把“能写代码”当作“能交付产品”
一个编程 Agent 的价值不只在代码生成质量，还在于它能否参与完整闭环：
理解任务 → 规划改动 → 执行修改 → 运行验证 → 汇报证据
如果工具只能完成中间的“执行修改”，而不能告诉你改了什么、为什么这样改、验证是否通过，那么它更适合做局部辅助，而不适合独立承担交付任务。
3. 选择结果要能被复盘
不要只记录“这个工具好用”。更有价值的记录是：
- 什么类型的任务交给它；
- 它在哪些上下文下表现稳定；
- 哪些操作必须人工批准；
- 哪些失败可以恢复，哪些失败会污染工作区；
- 它需要哪些模型、账号、插件或本地依赖。
这样下一次选择 Agent 时，依据的是任务和证据，而不是一次偶然的成功体验。
三、环境搭建：先让项目可运行，再让 Agent 动手
环境搭建位于视频时间轴的第二个阶段。AI 编程最常见的浪费，不是模型不会写，而是项目本身无法被稳定运行：依赖没有安装、启动命令不清楚、环境变量缺失、数据库状态不一致，或者开发者和 Agent 对项目入口的理解不同。
1. 环境准备的最小清单
在开始实现前，至少确认：
- 项目目录和当前 Git 分支明确；
- 依赖安装命令可执行；
- 开发服务器或测试命令可启动；
- 关键环境变量有安全的示例或说明；
- 当前基线可以通过一次构建或测试；
- 工作区中已有的未提交修改已被识别。
可以先执行一条最短路径：
安装依赖
→ 启动项目
→ 打开核心页面或运行核心测试
→ 记录当前基线
如果基线都无法通过，就不应该把后续失败全部归因于 Agent。
2. 把项目规则放在 Agent 能读到的位置
项目规则应当明确告诉 Agent：
- 哪些目录允许修改；
- 哪些目录属于生成文件或外部依赖；
- 项目使用什么包管理器和验证命令；
- 哪些操作需要人工确认；
- 如何处理已有的未提交变化；
- 完成任务时需要汇报哪些证据。
规则的目标不是写一份很长的说明，而是降低 Agent 做出错误假设的概率。尤其是大型仓库，应该通过入口文档和目录索引告诉 Agent 先读什么、后读什么，避免一开始扫描整个项目。
3. 环境必须支持失败后的恢复
一次成功运行不代表环境可靠。还要提前想清楚：
- Agent 中断后从哪里继续；
- 部分文件已经修改时如何审查；
- 测试失败时如何定位是环境问题还是代码问题；
- 是否可以通过 Git diff、分支或 worktree 回到上一个可用状态；
- 外部服务、数据库和账号操作是否会产生不可逆副作用。
AI 编程的环境不是“让模型开始写代码的地方”，而是让每一次尝试都能被观察、验证和恢复的工作区。
四、产品方案设计：先回答做什么，再回答怎么做
视频把产品方案设计放在技术方案之前，这是一个非常关键的顺序。很多 AI 项目一开始就让 Agent 搭页面、写接口，最后才发现产品目标没有冻结。
1. 把一句想法拆成可验收流程
一个可交付的产品方案至少需要说明：
- 谁使用它；
- 用户从哪里进入；
- 用户提供什么输入；
- 系统返回什么结果；
- 失败时用户看到什么；
- 哪一步必须人工确认；
- 什么条件下可以判断完成。
例如，“做一个 AI 内容工具”不是可执行需求。更接近可实现版本的表达是：
用户粘贴一段主题描述
→ 系统生成三种文章结构
→ 用户选择一个结构
→ 系统生成草稿并标出待核对事实
→ 用户确认后导出 Markdown
这个版本已经包含输入、输出、选择点和交付格式，Agent 才能据此拆分任务。
2. 先冻结最小版本
产品方案不是功能愿望清单。第一版应该明确：
- 必须有的路径；
- 可以暂时手工处理的部分；
- 明确不做的功能；
- 需要真实数据还是可以使用固定样例；
- 先验证价值还是先建设通用架构。
范围越模糊，Agent 越容易主动补充功能，最后产生大量与目标无关的代码。对于 AI 编程，减少首版范围往往比增加模型能力更有效。
3. 把验收条件写成动作
“页面好看”“体验流畅”“结果准确”都太抽象。可以把它们改成可操作的验收动作：
- 输入一个固定样例，得到预期字段；
- 刷新页面后状态仍然存在；
- 错误输入显示明确提示；
- 重复提交不会创建重复记录；
- 在移动端完成核心流程；
- 运行指定命令并得到通过结果。
验收动作越具体，Agent 越容易在实现过程中自检，开发者也越容易判断当前结果是不是“完成”。
五、技术方案设计：把功能拆成可观察的系统
产品方案确定目标后，再进入技术方案。技术方案的目的不是提前写满所有代码，而是把实现过程中的依赖、状态和失败路径显式化。
1. 从数据流而不是页面开始
可以用下面的方式描述一个功能：
输入
→ 校验
→ 业务处理
→ 外部服务或模型调用
→ 结果规范化
→ 持久化或展示
→ 用户确认
每个箭头都应该回答：
- 输入格式是什么；
- 失败会发生什么；
- 是否可以重试；
- 重试会不会造成重复副作用；
- 如何记录日志；
- 如何在本地测试。
2. 先列边界，再列模块
技术方案至少要冻结以下边界：
| 边界 | 需要说明的内容 |
|---|---|
| 输入边界 | 长度、格式、必填项和非法值 |
| 权限边界 | 谁可以读取、写入和触发操作 |
| 网络边界 | 哪些请求依赖外部服务，超时如何处理 |
| 数据边界 | 哪些数据持久化，保存多久，如何迁移 |
| 模型边界 | 模型能做什么，不能保证什么 |
| 交付边界 | 第一版明确不做什么 |
Agent 能够快速生成模块，但如果边界没有冻结，它很可能把“可能需要”实现成“现在必须有”，让项目复杂度在第一轮就失控。
3. 技术方案应该服务于验证
每个模块都要有对应的验证方式：
- 纯函数用单元测试；
- API 用请求样例和错误样例；
- 页面用核心用户路径；
- 数据库用迁移和回滚检查；
- 模型调用用固定输入、输出 schema 和失败分支；
- 外部副作用用 mock、dry-run 或明确审批。
如果一个模块没有清晰的验证方法，就需要重新考虑它的拆分方式，或者先补充验收定义。
六、产品实现：让 Agent 分阶段工作
产品实现阶段最容易出现“一个大提示词交给 Agent，等待它一次完成全部产品”的情况。更稳妥的做法是把实现拆成多个有检查点的阶段。
1. 推荐的实现顺序
可以采用下面的顺序：
- 建立最小骨架，让项目可以启动；
- 先实现一条端到端的最小路径；
- 用固定样例验证输入和输出；
- 补充错误处理、加载态和空状态；
- 再加入持久化、权限和外部服务；
- 最后处理样式、性能和扩展能力。
这不是说界面不重要，而是先确认核心流程能跑通。一个漂亮但无法完成核心任务的页面，不能算作产品交付。
2. 每一轮只交给 Agent 一个清晰目标
一条好的实现任务通常包含：
目标：实现什么
范围：允许修改哪些文件或模块
约束：不能改变什么
验收：运行什么命令、检查什么结果
报告：完成后需要说明哪些改动和风险
例如：
在现有设置页增加 API 地址校验。
只修改设置页组件和对应测试，不改请求层。
输入为空、缺少协议、地址不可解析时显示明确错误。
运行设置页测试并报告修改文件、命令和剩余风险。
这种任务比“把设置页完善一下”更容易得到稳定结果。
3. 让 Agent 先报告，再继续扩大范围
每完成一个阶段，都应检查：
- 实际修改了哪些文件；
- 是否触碰了任务范围之外的文件；
- 测试是否覆盖了新路径；
- 构建是否通过；
- 是否出现了临时方案或硬编码；
- 下一步是否真的依赖当前结果。
如果当前阶段没有通过，就不要让 Agent 继续叠加新功能。先修正当前基线，能明显降低后续定位成本。
七、整体流程回顾：从一次成功变成可重复方法
视频最后安排了整体流程回顾。复盘的重点不是评价“这次生成得好不好”，而是找到下一次可以提前冻结的内容。
1. 复盘四类问题
需求问题
- 哪些需求一开始没有写清楚？
- 哪些功能是 Agent 自行推断出来的？
- 哪些验收条件直到最后才补充？
工具问题
- 当前 Agent 是否适合这个任务？
- 哪些步骤需要更强模型，哪些步骤可以交给快速模型？
- 工具的权限和上下文是否足够，还是过宽？
工程问题
- 哪些失败来自环境而不是代码？
- 哪些测试应该更早运行？
- 哪些模块拆分得太大，导致 Agent 难以定位问题？
交付问题
- 用户是否真的完成了核心任务？
- 结果是否可以复现？
- 失败后是否有人工接管路径？
- 是否留下了下一次能直接使用的文档、测试或模板？
2. 把复盘结果写回项目
一次复盘只有写回项目才会产生长期价值。可以沉淀成：
- 项目规则文件；
- 开发和验证命令；
- 常见故障排查表；
- 任务模板；
- 验收清单；
- 已知限制和不做事项。
这样，下一次 Agent 不是从空白上下文开始，而是站在上一次交付留下的可验证资产上继续工作。
八、适合直接复用的 AI 编程交付清单
开工前
- 已明确用户、场景和第一版范围；
- 已写出输入、输出、失败态和验收动作；
- 已选择适合任务的编程 Agent；
- 项目可以安装、启动或运行基线测试；
- 已识别工作区中的既有修改和敏感操作。
方案阶段
- 产品流程先于技术实现冻结；
- 技术方案画清数据流、权限和外部依赖；
- 每个模块都有对应的验证方式；
- 已明确第一版不做什么。
实现阶段
- 每次只交给 Agent 一个明确目标；
- 修改范围和禁止动作已经写清楚；
- 每个阶段都检查 diff、测试和构建；
- 失败时先恢复当前基线，再继续扩展；
- 外部写入、数据库变更和生产操作有人工确认。
交付阶段
- 核心用户路径已经从头到尾验证；
- 错误、空状态和边界输入已经检查；
- 交付结果包含改动文件、验证命令和剩余风险；
- 复盘结果已经写回项目规则或文档。
最后：把 Vibe Coding 变成可验证的产品工程
这个视频最值得提炼的不是某一个编程 Agent 的品牌，而是它把 AI 编程放回了完整的产品交付流程：先选工具，再搭环境；先做产品方案，再做技术方案；先完成一条可验证路径，再逐步扩展；最后复盘并沉淀规则。
AI 可以显著降低实现成本，但不会自动替团队定义正确的问题、判断产品是否完成，也不会替人承担外部副作用。稳定交付的关键，是让 Agent 始终处在清晰目标、有限权限、可观察过程和可重复验证之中。
这也是 AI 编程从“看起来会写代码”走向“能够持续交付产品”的分界线。
来源与边界
原始视频：我的 AI 编程全流程：如何使用 AI 稳定交付一个高质量的产品，频道为马克的技术工作坊，发布日期为 2026 年 8 月 29 日。
公开视频简介公开列出以下时间轴：00:00 视频内容介绍、01:08 挑选编程 Agent、02:24 环境搭建、06:26 产品方案设计、14:43 技术方案设计、17:17 产品实现、20:15 整体流程回顾。
本文是基于公开视频页可见标题、频道、发布日期和时间轴的结构化整理，不是视频逐字稿。由于完整字幕在整理时无法通过匿名公开接口稳定取得，文中的方法论、检查清单和工程化延伸属于编辑归纳；具体演示、原话和视频中的实际操作请以原视频为准。