用AI稳定交付高质量产品的9步实战流程

为什么AI能写代码，却交付不出好产品？

很多人都经历过这样的场景：AI生成的代码看起来没问题，但你不敢用、不敢交付，甚至不敢在它上面继续改。这位B站UP主在总结了大量踩坑经验后提出一个核心判断——AI编程的关键已经从"提示词写得好不好"转移到了另外两件事：范围是什么，以及什么叫做完了。

过去几年，行业讨论AI编程的焦点一直集中在提示词工程。但真正区分一个人能否用AI稳定交付产品的，不是提示词技巧，而是能否清晰定义任务的边界与完成标准。这个判断构成了整套方法论的主线。

AI交付失败的三类落差与根源

以一个熟悉的场景举例：让AI帮你做一个"文档转换工具"，把PDF转成Markdown。你只说一句"给我做一个文档转换工具"，代码一定生成得出来，但会出现三类落差。

方向错：你心里想的只是把手头几份PDF转干净，AI却端出一个带云同步、历史版本、协作空间的文档管理平台。功能很多，但都不是你要的。

细节错：方向对了，确实是PDF转Markdown，但表格全错位、格式丢失，排版稍复杂就散架。功能都在，用起来却不顺手。

质量差：格式也对了，可你扔进几十页的文档它就卡死，小文件没问题、真实文件一上来就崩。

UP主强调，这三类落差不是偶然，而是必然，它们的根不在模型，而在三个信息缺失：你没说清楚要什么（"干净"是有具体形状的，但你没写出来，模型只能靠概率猜）；你没让规则常驻（表格结构要保留这类约束，每轮都得重新叮嘱，AI上一轮说好的事下一轮就忘）；你没定义什么叫做完（AI写完就交给你，把全部验证工作转移到了你身上）。

换句话说，看似是模型能力不足，本质是你提供的信息和约束不足——而这三样缺失全在流程里，不在模型里。

工具与模型：解耦决策，不绑定单一Agent

在选择编程Agent时，UP主给出的默认答案是从 Codex 开始，认为它安全、功能完整、没有明显短板，可以开箱进入后续流程。同类可选的还有 Claude Code、OpenCode、Cursor 等。

更关键的是两条原则：

原则一：工具与模型分开决策。 选Agent和选模型是两个独立问题。你完全可以用Codex的工作流搭配国产模型（如DeepSeek^广告、GLM、Kimi），这在工程上完全成立。差别主要在成本和配置，而非"谁更聪明"，因为大部分开发任务当前模型都能胜任。

原则二：不要依赖单个Agent的独有功能。 读仓库、写规则文件、讨论设计、生成demo、分段实现——每一步各家都有通用能力。不绑定独有功能不是洁癖，而是保险：工具会迭代、涨价、被替代，今天最好用的明年可能就不是了，但整套开发流程才是你能带走的资产。

Codex 是 OpenAI 推出的云端代码执行 Agent，能在沙箱环境中运行代码、读写文件、执行终端命令，并通过多轮对话完成复杂的开发任务。与早期仅负责代码补全的 Codex 模型不同，当前版本更接近一个能自主规划、分步执行的开发助手。Claude Code 是 Anthropic 推出的同类产品，以擅长长上下文理解和遵循复杂指令著称。Cursor 则是一款深度集成了 AI 能力的代码编辑器，优势在于对本地代码库的实时感知。这些工具的底层都可以切换不同的语言模型，这正是"工具与模型解耦"这一原则的工程基础——Agent 负责执行环境和工作流编排，模型负责语言理解与代码生成，两者是可以独立替换的不同层次。

九步流程：定方向、定实现、定交付

UP主把开发流程拆成九步，归为三个阶段：

定方向（第1-4步）——决定质量

1. 选择Agent：无偏好推荐Codex。
2. 环境搭建：只做一件事，把规则写进 agents.md 文件让它常驻。比如"每次改动测试跑通后再交付""需要详细代码注释"，写一次之后每轮自动带上，不用重复叮嘱。
3. 产品设计：先讨论要做什么，把需求梳理成文档，锁定第一版范围。
4. Demo验证：让它先做一个简单前端demo，目的是试错而非做产品，先看看大概长什么样、能交互即可。

这一段错了，后面全部推倒重来，是UP主最想让大家重视的部分。

定实现（第5-7步）——决定速度

5. 技术方案：确定技术栈、依赖模块，其余不管。
6. 任务拆解：拆成能独立验证的小任务，否则出问题不知道错在哪一段。
7. 分段实现：明确告诉它"不要顺手实现其他功能"。Agent有很强的"顺手多做一点"倾向，而超范围改动是最难审查、最容易埋雷的地方。

定交付（第8-9步）——只能自己拍板

8. 验收：自己动手跑流程、试边界情况，对着设计文档逐条核对。
9. 迭代：根据验收结果让AI修复，若AI走偏及时把它带回正轨。

agents.md（或类似命名的规则文件，如 Cursor 中的 .cursorrules、Claude Code 中的 CLAUDE.md）是 AI 编程工作流中的持久化约束载体。由于大多数 AI Agent 本身不具备跨会话记忆，每次新对话都从零开始，开发者需要将项目级别的约束——代码风格、测试要求、技术栈限制、禁止行为——写入一个固定文件，Agent 在每次执行任务前会自动读取它，从而让规则"常驻"于整个项目生命周期，而不是依赖开发者在每轮对话中反复重申。这个机制本质上是在弥补 AI 上下文窗口有限、无持久记忆的固有缺陷，将口头约定转化为可版本管理的工程制品。

实战演示：从零做一个txt转Markdown工具

视频用一个真实案例串起整个流程。先创建项目文件夹，在Codex中添加项目，然后让它创建 agents.md 写入规则（详细注释、测试通过后才交付）。

接着进入产品设计环节，把需求"我想做一个文档转换工具"抛给AI，让它思考第一个小版本该有哪些功能。AI给出了文件上传、转换设置、核心转换、进度、结果预览、错误与边界处理等，并主动列出"第一版建议不要实现"的内容。为了最小可用，UP主进一步收窄范围到"只支持txt转md"。

随后让AI生成产品说明文档和一个HTML验证页面，再基于文档确定技术方案。这里出现了典型的"超范围"现象——AI自作主张加了桌面应用、用了Node.js，UP主随即纠正："暂时不做桌面应用""后端需要使用Python实现"，并在 agents.md 补上第三条规则"按产品说明文档开发，不要顺手实现其他功能"。

最终AI用Python搭建后端（FastAPI），生成完整功能。实测新建txt文件、写入内容、转换、下载Markdown全流程跑通，验证成功。

FastAPI 是 Python 生态中一个高性能的 Web 框架，专为构建 API 而设计。它基于 Python 的类型注解自动生成接口文档，语法简洁，启动速度快，非常适合作为 AI 生成代码中的后端选型——模型对它的训练数据覆盖充分，生成的代码质量相对稳定，出错率低。在 AI 辅助开发场景中，选择文档完善、社区活跃、模型熟悉度高的主流框架，而非冷门或过于新颖的技术栈，能显著降低 AI 产生幻觉或生成错误依赖的概率，这也是技术方案阶段需要人工介入确认的原因之一。

流程能不能简化？分清"表达形式"与"控制机制"

面对"流程是不是太重"的质疑，UP主给出判断标准：能省的都是表达形式，不能省的都是控制机制。

绝对不能省的三项：环境搭建（规则不常驻就得每轮重复叮嘱）、人工验收（只有你知道想要什么产品）、与AI讨论设计（消除你和AI之间的意图隔阂，不讨论就是在赌）、任务拆解（改动太大可控性骤降）。

可以酌情简化的：产品设计文档（脑中范围足够清楚时可省，核心职责是锁定范围）、Demo验证（看后端成本，后端越重越该早做以提前发现方向错误）、技术方案（小项目可省，但涉及架构选型时不要省）。

值得留意的是，能省掉的全是"写在什么载体、用什么形式确认"，没有一项是"要不要确认"——控制机制一个都没动。

UP主最后用一句话收尾，也点破了整套方法论的内核：

Agent能验证代码是否符合它自己的理解，却无法验证它的理解是否符合你的预期。

所以"定义清楚什么叫做完，并自己手动验一验"这一步，永远绕不过去。