AI 编程全流程：如何让 AI 稳定交付一个「你真正想要的」产品

文章目录一、被高估的「一句话开发」二、第 0 步选一个编程 Agent然后别被它绑住三、第 1 步环境搭建只有两件事3.1 建目录、建项目3.2 Git给 AI 装一张安全网3.3 AGENTS.md写给 AI 的项目说明书四、第 2 步产品设计——先讨论再砍需求最后落文档4.1 从一个开放式问题开始4.2 关键动作逐条砍掉「看起来很合理」的功能4.3 让 AI 补齐你想不到的工程细节4.4 把共识落成产品设计文档五、第 3 步Demo——先把界面画出来5.1 什么是 demo5.2 demo 解决两个真问题5.3 什么时候值得做 demo六、第 4 步从设计到实现——技术方案与任务拆解6.1 技术方案把「怎么做」也先说清楚6.2 任务拆解不要让 AI 一次做完所有事七、第 5 步验收与迭代7.1 验收要自己动手7.2 迭代把砍掉的功能一个个加回来八、哪些环节可以省哪些千万别省九、几个常见的坑十、结语流程才是真正的能力一条指令换不来一个产品。真正决定交付质量的不是你用哪个模型而是你在模型动手之前把多少不确定性提前收敛掉了。一、被高估的「一句话开发」装好 Codex 或 Claude Code敲一句「给我做个电子书阅读器」几分钟后确实会有一堆代码躺在目录里甚至能跑起来。于是很容易得出结论AI 编程已经解决了。但只要你真的把这个流程走完几次就会遇到三类反复出现的落差方向错。你脑子里想的是一个安静的纯文本阅读器AI 交付的是一个带书架、云同步、社交书评的「阅读平台」。功能都实现了但没有一个是你要的。细节错。界面能用但交互处处别扭翻页方式不对、字号调节藏在三级菜单里、导入文件后要手动刷新。质量差。跑十分钟就崩边界情况一碰就炸改一个 bug 冒出三个新的。这三类问题看起来是模型能力不足本质上却是信息与约束不足。模型的代码生成能力已经远超大多数人的手写速度真正的瓶颈在于你没把「想要什么」说清楚模型只能靠概率补全你的意图你没给它可回滚的安全网于是每次修改都是不可逆的赌注你没定义「什么叫做完了」于是它写完就交差验证成本全部转移给你。所以用 AI 做产品的正确姿势不是「更会写提示词」而是给一个高能力、低确定性的执行者搭一套能约束它的流程。下面这套流程我会用一个具体项目走完整遍一个叫「马克阅读」的极简电子书阅读器。每一步我都会说明它到底在解决什么问题、什么时候可以省、什么时候千万别省。整体流程是这样的选 Agent → 环境搭建Git AGENTS.md→ 产品设计讨论 → 砍需求 → 设计文档 → Demo 验证 → 技术方案 → 任务拆解 → 分段实现 → 验收测试 → 迭代看起来步骤不少但真正需要你「动脑」的只有前半段后半段主要是让 AI 按你定好的轨道跑。二、第 0 步选一个编程 Agent然后别被它绑住现在主流的编程 Agent 有 Codex、Claude Code此外还有 OpenCode、Pi、Cursor 等一批工具。如果没有特殊偏好Codex 是一个安全的默认选择功能覆盖比较完整没有明显短板。模型来源上有两条路方式适用场景说明订阅 ChatGPT直接在 Codex 里调用 GPT 系列追求开箱即用、稳定性优先官方组合工具链适配最好接入 DeepSeek / GLM / Kimi 等模型订阅不方便、成本敏感、需要国内网络环境Codex 本身是通用 Agent并未与某个模型强绑定这里有个容易被忽略的判断Codex 是壳模型是芯。大部分主流模型都能接进去用所以「选 Agent」和「选模型」是两个可以分开决策的问题。你完全可以用 Codex 的工作流 国产模型的成本结构。更重要的一条原则是尽量不要依赖某个 Agent 的独有功能。本文后面涉及的所有操作——初始化仓库、写项目规范文件、讨论设计、生成 demo、分段实现——都是通用能力。你换成 Claude Code、Pi 或别的工具流程一模一样。工具会迭代、会涨价、会被更好的替代品取代但流程本身是可迁移的资产。把工作流建立在通用能力上你的迁移成本才接近于零。三、第 1 步环境搭建只有两件事很多人以为环境搭建是装依赖、配环境变量、选框架。在 AI 编程语境下真正必须做的只有两件事Git和AGENTS.md。3.1 建目录、建项目先给产品建一个专属文件夹只放这个项目的代码。以电子书阅读器为例目录就叫mark-reader项目名「马克阅读」。然后在 Codex 里新建项目类型选本地把这个文件夹加进来。这一步看着琐碎但它定义了 Agent 的工作边界。一个干净、独立、单一职责的目录能显著减少 Agent 读到无关文件、误改其他项目的概率。不要把新项目塞进一个已经有五个项目的杂物文件夹里。3.2 Git给 AI 装一张安全网接下来让 Agent 把当前目录初始化为 Git 仓库。指令可以极其朴素帮我把当前目录初始化为一个 Git 仓库。然后自己在终端验证一下不要只信 Agent 的口头汇报cdmark-readergitstatus只要正常返回分支和文件状态、没有报错就说明目录已经被 Git 托管了。Git 的作用在 AI 编程里被放大了不止一个量级。手写代码时你对每一行改动都有心理模型出问题大致知道该往哪看。而 Agent 一次可能改动十几个文件、几百行代码你没有逐行读过。这种情况下版本快照就是你唯一可靠的撤销键。它带来三个具体收益一键回退。第 5 次迭代把代码改乱了直接回到第 4 次的状态不需要让 AI「再改回去」——让 AI 修复自己搞乱的代码往往越修越乱。可读的变更历史。每个 commit 对应一个功能等于给项目自动生成了一份开发日志。给 Agent 的定位线索。当你说「上一版还好的这一版坏了」有 commit 历史的 Agent 可以对比 diff 精确定位问题没有历史的 Agent 只能猜。再往前一步建议把仓库推到 GitHub。理由很实际本地磁盘会坏误删会发生几十个小时的迭代成果不该只存在一台机器上。一句话原则所有代码项目都用 Git 管理没有例外。项目再小也一样因为「小项目」正是最容易被 AI 改崩且最没有备份的那一类。3.3 AGENTS.md写给 AI 的项目说明书第二件事是创建AGENTS.md。你可以让 Agent 自己写这个文件创建一个 AGENTS.md 文件写入下面这些内容最后提交一个 commit。 粘贴文件内容AGENTS.md的定位相当于项目说明书 开发规范。Agent 每开启一轮新会话会优先读取其中内容从而快速建立项目背景和纪律约束。它解决的是 AI 编程里最讨厌的一个特性会话是无记忆的。你在上一轮反复强调过的规则新会话里它一概不知。把规则写进文件等于把「口头叮嘱」升级成「常驻制度」。最小可用的 AGENTS.md 其实只需要两条硬规则# 项目说明 本项目是一个极简电子书阅读器项目名马克阅读。 # 开发规范必须遵守 1. 每次改动之后必须创建一个对应的 git commit以便后续追踪和回滚。 2. 每次改动之后必须编写或更新相关测试在交付给用户之前 必须确保所有测试与自验收全部通过。这两条为什么是「必须」第一条把版本管理变成 Agent 的肌肉记忆。每完成一个功能就顺手存一个快照你不需要每次都提醒。后面哪一步改出了问题能立刻找到最近一个正常版本退回去不必担心代码越改越乱。第二条把验证责任还给 Agent。默认情况下Agent 写完代码就宣布完成测试和试错成本全落在你身上——你打开应用、点点点、发现崩了、截图描述、它再改。这个循环极其昂贵。加上这条规则后它会自己先跑一遍、测一遍发现问题继续修直到确认改动基本没问题才回来汇报。这一条能提前挡掉相当一部分显而易见的 bug节省的是你最贵的资源注意力。创建完记得回去看一眼文件内容是否与预期一致。这个「口头汇报 人工抽查」的习惯贯穿整个流程。到这里环境就算搭好了。总结起来就两件事Git 负责让错误可逆AGENTS.md 负责让规则常驻。四、第 2 步产品设计——先讨论再砍需求最后落文档环境搭好后最容易犯的错误是立刻开始写代码。先停一下你知道自己要做一个电子书阅读器但「具体做成什么样」大概还没有确切答案。这个模糊状态是所有交付落差的源头。而它有个很好的解决办法先跟 AI 讨论设计不要让它写代码。4.1 从一个开放式问题开始第一条指令可以这样问我想做一个电子书阅读器打算先从 MVP 版本开始。 你觉得这一版做哪些功能比较合适呢注意这里明确框定了MVPMinimum Viable Product最小可用产品。含义是第一版只做最核心、最必要的功能先把主流程跑通其他慢慢加。为什么必须从 MVP 起步因为方向错误的成本是指数级的。一开始就把功能铺得很大等到发现方向不对大量工作直接作废——不只是代码还有围绕这些代码写的测试、文档和架构决策。先用最低成本把最基本的体验做出来确认没问题再往上加是把风险控制在可承受范围内的唯一办法。在 AI 编程里MVP 还有一层额外价值代码量越小你越有能力审查它。一旦第一版就生成上万行代码你实际上失去了对项目的控制权只能听 AI 汇报。4.2 关键动作逐条砍掉「看起来很合理」的功能AI 的第一版建议通常是「教科书式完整」的而这恰恰是问题。以电子书阅读器为例它给出的方案大致包含导入本地 EPUB 文件、目录与章节导航、明亮/护眼/深色三主题、书签……每一条都合理合起来就不再是 MVP 了。这时候要做的不是接受而是逐条追问「这个现在真的需要吗」EPUB → TXT。EPUB 是常见电子书格式支持它没错但解析复杂度不低。既然是最小可用版本起步功能越简单越好先只支持最朴素的 TXT 文本文件。去掉目录与章节。这是砍掉 EPUB 后的连带结论纯文本文件本身没有目录和章节的概念即使人工能看出章节划分也没有稳定可靠的通用解析方法。强行做这个功能等于在 MVP 阶段引入一个准确率不确定的启发式模块。只留明亮主题。三套主题意味着三倍的样式维护和视觉验证成本而它们对「能不能读书」这个核心价值毫无影响。先做明亮主题。去掉书签。书签是「好用」功能不是「可用」功能。它涉及持久化存储和状态管理属于典型的可以延后项。这里有个很实用的对话技巧看完整个回答再一起提交意见。AI 的建议往往前后关联砍掉 EPUB 会连带影响目录、章节、进度记忆如果你看到一条就回一条会陷入低效的多轮拉扯而且容易前后矛盾。正确做法是把所有想法先追加到输入框里最后一次性提交我觉得 EPUB 也稍微有些复杂了一开始是不是可以只支持最简单的 TXT 文本文件 如果只做 TXT那也就没有什么目录和章节可言了毕竟 TXT 没有目录和章节的概念这些也不用做。 只做明亮主题就行护眼和深色可以先不做。 书签也可以先不做。 总之我们先做最基本的功能其余功能后面再迭代。 你觉得前面这些想法有没有什么问题呢最后那句「你觉得有没有什么问题」很关键。它把 AI 从「执行者」切换回「评审者」让它有机会指出你砍过头的地方。4.3 让 AI 补齐你想不到的工程细节这一轮回复通常最有价值。确认整体思路没问题之后它会补上几个你大概不会主动想到的点文件编码第一版仅支持 UTF-8。文本编码是中文场景的经典陷阱GBK 文件不做处理就是一屏乱码。明确「只支持 UTF-8」既降低了实现复杂度也定义了清晰的失败边界。阅读方式第一版只做纵向滚动先不做分页。分页涉及文本测量、窗口尺寸响应、断行计算是个隐藏的深坑滚动几乎零成本。大文件提示载入大文件时需要给出加载提示。一个 20MB 的 TXT 一次性渲染会让界面直接卡死而用户看到的只是「这软件坏了」。延后功能清单把砍掉的功能记录下来作为后续迭代的输入。这就是「先讨论再动手」的真正收益你负责收窄范围AI 负责补齐你的知识盲区。两者的信息优势是互补的——你知道自己想要什么它知道这类产品通常会在哪里翻车。讨论到这里第一版的边界已经清楚了维度MVP 做MVP 不做文件格式TXT仅 UTF-8EPUB、MOBI、PDF、其他编码导航纵向滚动分页、目录、章节跳转外观明亮主题护眼、深色、自定义配色状态打开即读书签、阅读进度同步、书架体验保障大文件加载提示虚拟滚动、懒加载优化4.4 把共识落成产品设计文档口头共识会在下一轮会话里蒸发所以必须落成文档我同意你的建议。接下来帮我整理一份产品设计文档吧。 不用太详细把整体方向和主要功能梳理出来就可以。注意「不用太详细」这四个字。这不是偷懒而是有意的权衡文档太长你自己不会仔细读等于没有评审过度细化的规格在第一版就会被现实推翻写得越细返工越多MVP 阶段文档的核心职责是锁定范围不是穷举实现细节。只要大方向和你想的一致就可以推进。真有细节不符合预期后面迭代成本很低。这份文档接下来会成为整个项目的底稿无论是做技术方案还是让 AI 写代码大家都有统一依据。它的实际作用是把「你脑子里的产品」变成一个外部化、可引用、可版本管理的对象——这也是为什么它应该和代码一起提交进 Git。五、第 3 步Demo——先把界面画出来产品设计文档写完还可以再加一个环节让 AI 先做一个可操作的 demo。5.1 什么是 demo这里说的 demo是一个只有前端、没有后端的可交互页面。先明确两个词前端指你看得见、点得到的界面后端指背后真正处理数据、执行功能的逻辑。做 demo 时通常只把前端做出来后端暂时不实现页面里的数据全部是模拟的。举个具体例子。一个「个人知识库」的 demo实际就是一个单独的 HTML 文件双击就能打开左边是文档列表中间给出一些推荐问题点击某个问题它开始「回答」回答完点击引用文件右边展示引用的原文段落。看起来功能齐全但只有界面是真的——回答内容和知识库文件全部是写死的假数据因为后端逻辑压根还没实现。它唯一的目的是让你亲手体验一遍界面交互和操作流程到底顺不顺手。哪里感觉不对就继续让 AI 改这个 demo直到整体体验符合预期。5.2 demo 解决两个真问题第一提前验证产品设计。很多东西光靠文字实在难以想象。文档里写「导入文件后进入阅读界面」你脑子里那一幕是清晰的但真把页面画出来、亲手点一遍你可能立刻发现导入按钮该放哪导入失败怎么提示字号调节要不要常驻在界面上这些问题在纯文字阶段几乎不会浮现在 demo 上五分钟就能全部暴露。发现设计不合理就改 demo同时把产品设计文档一起同步调整——两者必须保持一致否则后面 AI 会在两份冲突的依据之间随机选一个。第二让后续实现更精确。demo 能非常直观地告诉 AI「我最终想要的产品大概就是这个样子」而这是文字描述极难做到的。真正实现时把产品设计文档和 demo 一起交给 AI文档说明做哪些功能demo 说明界面和交互长什么样。两个维度的约束叠加做出来的东西会明显更接近预期。本质上demo 是一种低成本的规格表达。界面这类信息用图形表达的保真度远高于自然语言同一段文字描述可以对应几十种界面实现而一个 demo 只对应一种。5.3 什么时候值得做 demodemo 不是必需环节。判断标准可以非常简单看这个产品的后端实现成本有多高。后端成本高 → 强烈建议做 demo。像个人知识库这类产品后端涉及文档处理、检索策略、模型调用等一大堆逻辑实现周期长、返工代价大。这种情况下先用几乎零成本的前端把设计验证一遍再投入后端性价比极高。后端成本低 → 可以直接开工。如果后端逻辑很轻做 demo 和做真东西的成本差不多那 demo 就成了纯粹的重复劳动直接实现再调整反而更快。这个判断的底层逻辑是demo 的价值等于它避免的返工成本减去它自身的制作成本。后端越重前者越大后端越轻两者越接近甚至倒挂。六、第 4 步从设计到实现——技术方案与任务拆解设计和 demo 确认后才轮到写代码。这里同样不建议一步到位而是再插入两个轻量环节。6.1 技术方案把「怎么做」也先说清楚产品设计文档回答的是「做什么」技术方案回答的是「怎么做」技术栈选型、数据如何存储、模块如何划分、目录结构长什么样。可以让 AI 基于已有文档先给方案你只审几个关键判断技术栈是否过重。一个本地 TXT 阅读器不需要引入完整的前后端分离架构和数据库。依赖是否必要。每一个第三方依赖都是未来的维护负担和安全面。模块边界是否清晰。文件读取、文本渲染、设置管理应当分离否则后面加 EPUB 支持时会牵一发动全身。审技术方案的收益比审代码高得多一个架构决策错误会污染成百上千行代码而在方案阶段改掉它只需要改一段文字。6.2 任务拆解不要让 AI 一次做完所有事把 MVP 拆成一串可以独立验证的小任务每个任务对应一个 commit。以马克阅读为例搭起最小可运行骨架界面能打开支持选择并导入本地 TXT仅 UTF-8文本纵向滚动渲染字号可调大文件加载提示与异常处理明亮主题的样式打磨分段实现的收益是可叠加的每一步都可验证。你在每个节点都能确认「这一段确实是我想要的」问题在产生时就被发现而不是在一堆代码里考古。每一步都可回滚。第 4 步改崩了回到第 3 步的 commit前面的成果毫发无损。上下文压力更小。一次只处理一个任务Agent 的注意力不会被十个并行目标稀释——这是 AI 编程质量的关键变量之一。对应的指令风格也很直接请严格按照产品设计文档和 demo 的界面实现第 2 个任务 支持选择并导入本地 TXT 文件仅 UTF-8。 不要顺手实现其他任务里的功能。完成后按 AGENTS.md 的规范补充测试并提交 commit。最后那句「不要顺手实现其他功能」值得每次都写。Agent 有很强的「顺手多做一点」倾向而超出范围的改动是你最难审查、也最容易埋雷的部分。七、第 5 步验收与迭代7.1 验收要自己动手即使 AGENTS.md 已经要求 Agent 自测你仍然需要亲自验一遍。原因很简单Agent 能验证代码是否符合它自己的理解无法验证它的理解是否符合你的预期。测试全绿和产品可用之间永远存在一段只有人能跨过的距离。验收时重点看三类东西检查项具体动作主流程从打开应用到读完一段文字完整走一遍边界情况空文件、超大文件、非 UTF-8 文件、格式异常的文件与设计一致性界面和交互是否还原了 demo功能范围有没有悄悄膨胀发现问题时描述现象而不是猜测原因「导入 15MB 的 TXT 后界面白屏约 10 秒没有任何提示」远好于「你的渲染逻辑有性能问题」。前者是可靠的观测事实后者是可能误导 Agent 的假设。7.2 迭代把砍掉的功能一个个加回来MVP 跑通之后前面延后的功能清单就是天然的迭代路线图EPUB 支持、目录与章节、深色与护眼主题、书签、阅读进度记忆……迭代的纪律和第一版完全一致只是节奏更快更新产品设计文档新增功能的边界必要时更新 demo界面有明显变化时拆解任务、分段实现自己验收、提交 commit值得强调的是文档必须跟着代码一起演进。一份和代码脱节的设计文档比没有文档更危险——它会持续给 AI 提供过时的依据让它在错误的前提上做出看似合理的决策。八、哪些环节可以省哪些千万别省这套流程不是教条可以按项目规模裁剪。我的判断标准如下环节能不能省判断依据Git 版本管理绝对不能省它是唯一可靠的撤销键成本几乎为零收益无上限AGENTS.md不建议省一次投入、长期生效解决会话无记忆的结构性问题与 AI 讨论设计不建议省这是消除「你想的 ≠ AI 做的」的根本手段产品设计文档玩具项目可简化多轮迭代或多人协作的项目必须有Demo可以省看后端实现成本成本高就做成本低直接开工技术方案小项目可省涉及架构选型、数据存储、外部服务时不要省任务拆解不建议省单次改动越大可控性和可回滚性下降越快人工验收绝对不能省只有你知道自己想要什么可以看到能省的都是「表达形式」不能省的都是「控制机制」。文档可以写薄demo 可以不做但版本可回滚、范围有边界、结果有人验这三件事没有妥协空间。九、几个常见的坑一次性提出全部需求。把十个功能一口气丢给 AI它会全部实现也会全部实现得很浅而且你无法定位是哪一部分出了问题。让 AI 修复它自己搞乱的代码。当同一个 bug 修了三轮还没好正确动作是git reset回到干净版本换一种思路重新描述需求而不是继续在废墟上叠补丁。只看汇报不看结果。Agent 说「已完成并通过所有测试」时去看文件、去跑一遍。抽查成本很低被误导的成本很高。文档写得比代码还细。MVP 阶段的文档只需要锁定范围。过早细化的规格几乎必然被现实推翻。跳过 MVP 直接做完整版。这是所有坑里最贵的一个它把方向验证推迟到了投入最大的时刻。十、结语流程才是真正的能力回过头看这套流程做的其实只有一件事把不确定性从「实现阶段」前移到「设计阶段」。设计阶段的错误改一段文字就行实现阶段的错误要改一堆代码上线之后的错误要改用户的习惯。AI 让写代码的成本急剧下降但它同时放大了方向错误的代价——因为错误的方向现在也能被高效地执行出上万行代码。所以真正的分水岭不在于谁的提示词更花哨而在于谁能把「我想要什么」表达得足够清楚、把「什么叫做完了」定义得足够明确、把「出错了怎么退回去」准备得足够充分。把这三件事做好剩下的交给 AI它大概率能给你一个满意的答案。最后再回到最小可行的那一版实践建议从今天开始给你的每个项目做三件事——初始化 Git、写一份十行的 AGENTS.md、在动手前先跟 AI 聊清楚第一版的边界。这三件事加起来不超过十五分钟但它们能改变你和 AI 协作的全部质量基线。