使用 Vibe Coding 从零开发论坛：用 AI 指挥需求收敛与验收

• 本文导读
• 学习目标
• 技能目标
• 10.1 需求分析
  • 10.1.1 背景与动机
  • 10.1.2 效果与功能
  • 10.1.3 哪些功能在电子资料中可查
  • 10.1.4 哪些功能接下来展示，为什么选它们
• 10.2 完成 MVP
  • 10.2.1 背景与动机
  • 10.2.2 完整实战对话
  • 10.2.3 小结
  • 10.2.4 成果展示
  • 10.2.5 总结

本文导读

AI可以在很短时间内交付一个完整论坛，也可以让15个没有执行断言的测试全部显示「通过」。

如果连「已完成」和「测试通过」这2个字都不能相信，用户到底该如何指挥AI，把一个项目真正送到线上？

本文用一个真实的论坛案例，从需求讲到部署，讲4件事：需求收敛、部署验证、3层证据验收、持续纠偏与独立复验。我们不教论坛代码怎么写，只教用户怎么指挥AI把论坛做出来。这套方法换个项目一样能用。

表 10-1 本文学习路线图

学习目标

（1）掌握用AI做需求分析与功能拆解的方法，从一句话需求，到功能范围拆解与架构决策。

（2）理解Issue（可跟踪的任务项）驱动开发的完整工作流：需求、拆解、Brief（结构化任务说明）、智能体执行、行为驱动开发（Behavior Driven Development，BDD）验证、端到端（End-to-End，E2E）验证、M阶段手动测试、R阶段反思、S阶段保存、沉淀。

（3）学会部署后的工程化验证方法：部署检查清单、回归验证、本地/生产数据隔离。

（4）理解AI自报通过不等于真通过，掌握独立复验与假绿识别的方法。

技能目标

（1）能通过feat skill（新增功能的技能包）的头脑风暴与方案确认步骤，引导AI产出功能范围、Specs（功能行为契约）与数据模型。

（2）能调用skill驱动智能体完成一次功能迭代，并用BDD/E2E/手动测试3层证据验收。

（3）能执行部署后回归验证，识别并修复部署环境问题。

（4）能识别测试假绿并独立复验，能对多轮纠偏做出产品判断。

10.1 需求分析

10.1.1 背景与动机

项目启动第一天，我们接到的原始需求只有一句话：「游戏官网需要一个论坛，让玩家反馈Bug和建议。」

这句话背后的真实情况是，游戏玩家原本挤在贴吧、QQ群里交流，反馈Bug、提建议都散落在聊天记录里，既不沉淀也没法搜索。我们想要一个自己的论坛，能按标签分区、能搜索，把玩家的反馈变成可管理的数据。

在讲「怎么指挥AI做」之前，先把论坛完成的最终效果展示出来，让读者先有个整体印象，这样读者可以挑感兴趣的知识阅读，不用从头看到尾。这也是AI编程的第一个要诀：先让AI把「成品长什么样」说清楚，再谈怎么做。

10.1.2 效果与功能

论坛上线后，玩家打开的是一个深色主题的社区首页：顶部是导航栏和搜索框，左侧是按标签分区的侧边栏，中间是帖子列表（如图 10-1 所示）。游客可以直接浏览所有帖子，登录后可以发帖、回帖、给帖子打标签。

图 10-1 论坛首页：顶部导航与搜索栏、左侧标签分区、中间帖子列表

点开任意一条帖子进入详情页：顶部是标题，中间是Markdown正文，正文下方是评论区与回复框（如图 10-2 所示）。

图 10-2 帖子详情页：标题与Markdown正文、评论区、回复框

论坛最终的功能可以分成几类。

• 人人都能用的基础功能：游客浏览帖子、按标签分区浏览、站内搜索、移动端适配。
• 需要登录才能用的核心功能：发帖（Markdown编辑器、可配图）、回帖（支持引用式回复）、帖子状态管理（Bug帖的打开/关闭）。
• 版主和管理员才有的管理功能：置顶、精华、状态变更。
• 上线后才逐步加上的增强功能：通知系统、帖子订阅、优先级排序、SEO、免登录、粘贴图片。

可以发现，这些功能不是一次全做出来的，而是分批出现的：先做让论坛能跑通的那一小批，再一批批往上加。这个「先做哪批、后做哪批」的分类，就是10.2节要重点讲的方法。现在只需要记住一点：一个项目里，总有一小部分功能是「没有它项目就立不住」的，剩下的是「有了更好」的。

10.1.3 哪些功能在电子资料中可查

论坛从立项到生产稳定，经历了约30个工作日的持续迭代，功能远不止上面列的这些。为了不让正文变成流水账，我们只挑最有教学价值的几段展开。其余功能（点赞切换、表情支持、用户名自动翻译、分享按钮、注册提示等）的完整开发记录，全部整理在随书电子资料里，读者可以按需查阅。

10.1.4 哪些功能接下来展示，为什么选它们

本文接下来深入展示4段过程。

• 10.2完成最小可用产品（Minimum Viable Product，MVP）：从一句话需求到最小可用版本，展示「需求收敛」的完整方法，这是所有项目的起点。
• 10.3部署上线：展示「部署成功」和「交付成功」的区别，这是最容易出错的一步。
• 10.4加入通知：展示一个完整功能的feat全流程验收，这是「证据驱动」最完整的一课。
• 10.5持续改进：展示2个最容易骗过AI「自报通过」的问题，优先级排序4轮才改对、集成测试15/15全绿却是假的。

选这4段，是因为它们各自对应一个跳不过去的核心方法：需求收敛、部署验证、3层证据验收，以及持续纠偏与独立复验。学会这4件事，指挥AI开发的主干就掌握了。

10.2 完成 MVP

10.2.1 背景与动机

项目需求只有一句话：「游戏官网需要一个论坛，让玩家反馈Bug和建议。」

这句话过于模糊。如果直接对AI说「写吧」，AI会错意，凭空补出需求中并不存在的功能：完整的账号注册登录、站内信、积分系统、敏感词过滤。这就是AI幻觉，即AI编造出需求里并不存在的内容。此时AI写出的每一行代码，都建立在错误的理解之上，写得越多，错得越远。

我们期望的是把这一句话变成一份用户可验收、AI可执行的方案。做法是调用feat skill（一个「新增功能」的技能包，把「提问、产出、验收」的固定流程固化成一个可反复调用的命令），让AI先头脑风暴提问，再逐层收敛，最后产出方案与Specs。到这一节末尾，还会调用另一个技能，E2E自动测试skill，把论坛的E2E测试场景搭起来，供后续每次迭代复用。

10.2.2 完整实战对话

下面这段对话是真实案例的教学性重组：为了讲清楚每个步骤，我们把几十轮对话压缩成5轮，每轮都保留「用户提示词 + AI回复/产出」的完整结构，因果关系不变。

这里先说一个贯穿全章的对话轮次合并规则：只要中间没有用户参与、AI自动进入下一个工作流步骤，就把这些步骤合并到同一轮对话里；只有用户重新说话（提新需求、确认方案、反馈问题、决策）时，才开启新的一轮。理解了这条规则，才能看懂feat skill每一步是怎么一次推进的。

第一轮对话（feat skill头脑风暴步骤 + Issue创建步骤 + 方案产出与方案确认提问）

用户调用feat skill，只说了那一句话：

用户：「给游戏官网加个论坛，玩家能反馈Bug和建议。」

AI没有直接写代码，而是反问了一串问题：

AI（头脑风暴步骤）：「先别急着写代码。我需要先搞清楚几个边界。第一，要不要建立自己的账号体系，还是复用游戏已有的登录？第二，游客能看帖吗，还是必须登录才能看？第三，需要几级管理角色？第四，要做双语吗，还是只做中文？」

AI的第一个问题是「要不要建立自己的账号体系」。这是后面所有问题的伏笔，先记住它。

用户用口语化方式回答：

用户：「不建账号系统，直接用游戏已有的登录就行，论坛只需要一个用户资料表。游客可以看。角色就普通用户和版主两级……算了，加一个管理员，三级。中英双语都要。」

AI追问了第二个维度，优先级：

AI（头脑风暴步骤）：「明白了。那MVP阶段先做哪些？哪些可以放到第二批？比如搜索、置顶、精华这些，是第一批就要，还是后面再加？」

用户最终答复：

用户：「先跑通浏览、发帖、回帖这三件事，标签分区也要，移动端得能用。搜索、置顶、精华、Bug管理这些放第二批。」

到这一步，一句话需求变成了2批清晰的清单：第一批（先做）是浏览、发帖、回帖、标签、移动端；第二批（后做）是搜索、置顶、精华、Bug管理。

头脑风暴到这里结束。接下来中间没有用户参与的断点，AI自动连续完成了2件事，先创建Issue，再产出方案：

AI（Issue创建步骤）：「已根据我们的对话自动创建Issue『论坛项目MVP』，包含三部分：① 需求描述：复述我们确认过的一句话需求和边界；② 功能范围：第一批、第二批清单；③ 待澄清项：把还没有决策的细节（比如标签具体分哪几类）列出来，方便后续补。后续所有执行和验收，都挂在这条Issue下面推进。」

AI（方案确认步骤·自动产出方案）：「方案已经成型，共两份：① 方案文档：功能范围、系统架构、数据模型设计；② Specs（功能行为契约）：把每个功能写成『给定/当/那么』的可测条款，共9个feature。功能范围分两级：P0（最高优先级，第一批必须完成）：游客浏览、用户鉴权、发帖、回帖、标签分区、移动端适配；P1（次优先级，第二批完成）：搜索、置顶、精华、Bug管理。此外，方案里还明确写了一条『MVP外不做』清单：附件上传、私信、管理员后台、投票、游戏内集成、历史数据迁移。为了便于用户确认，这里先把方案的要点列出来：① 范围：第一批做P0的6项（游客浏览、用户鉴权、发帖、回帖、标签分区、移动端适配），第二批做P1的4项（搜索、置顶、精华、Bug管理）；② 账号：复用游戏已有登录，不另建账号系统，只维护一个用户资料表；③ 数据：用文档型数据库，帖子与评论等集合由数据模型统一规划，并配套初始化脚本；④ 边界：『MVP外不做』清单里的6项一律不做。用户看清这4条要点即可决定是否确认，若需要细节再打开完整方案文档。」

AI（方案确认步骤·请用户决策）：「有两件事需要决策。第一，不建立独立账号系统，这是架构决策，不是小事。论坛不维护账号表，只维护一个 forum_users 资料表，用户名直接复用游戏里注册的用户名。第二，确认上面的『MVP外不做』清单：拒绝就是边界，比要什么更能防止我过度设计。」

这里有2个关键认知。

第一，Issue不是用户手动写的，是AI根据对话自动创建的。用户的职责只是确认它有没有理解错，而不是从零手写任务单。AI编程里，「任务从哪来」和「任务怎么追踪」都被AI接管了，用户省下的时间用来做真正重要的事，判断AI有没有会错意。

第二，方案文档和Specs都是AI在头脑风暴结束后自动连续产出的。头脑风暴、Issue创建、方案产出这3个步骤之间没有用户参与，所以合并成了同一轮。这引出贯穿本文的2个新概念，后面会反复出现：

• 方案文档：描述「做什么、不做什么、怎么架构」，是用户和AI对齐的总纲。
• Specs（功能行为契约）：把每个功能翻译成机器可验证的行为描述。后面可以看到，当Specs自己内部出现矛盾时，用户怎么处理。

这2个概念在「谁来确认」上并不一样：方案需要用户确认，用户一般看AI列出的方案要点就能决定是否确认，需要完整信息时也可以查看完整方案文档；而Specs一般不需要用户确认，它是给AI在实现和测试时遵守的行为基准，用户在方案方向确认时顺带扫一眼即可。

表 10-2 第一轮对话 AI 产出

表 10-3 第一轮对话 问题与经验教训

第二轮对话（feat skill方案确认步骤：用户确认 + 数据库选型咨询）

上一轮AI在产出方案后，把「不建账号系统」和「确认MVP外不做清单」这2个关键决策单独列出，请用户决策。现在轮到用户回应。

用户确认了这2条，但对方案里「数据到底存哪、要不要碰服务器」这一点仍有疑问。于是用户主动把话题转向数据库，这一次不是AI来引导，而是用户先开口咨询：

用户（数据库选型咨询）：「数据库这块我不太懂。我想用国内的云数据库，比如腾讯云的，请根据我们这个项目的情况，帮我推荐一下到底该用哪种？」

AI没有直接替用户决策，而是把可选方案和各自的取舍摊开，让用户先看清选项再下决定：

AI（方案确认步骤·选型对比）：「好，我把可选方案按『要不要自己维护服务器』分两类说清楚。第一类是自建数据库：在云服务器上装关系型数据库MySQL，它事务强、擅长多表关联查询，但需要自己买服务器、装环境、做备份、管扩容，维护成本高。第二类是无服务器（Serverless）托管数据库，典型的是腾讯云的文档型数据库（CloudBase TDS），不需要管服务器，数据库按用量计费、自动伸缩，数据是文档结构，天生适合帖子、评论这种『一条数据包含所有字段』的场景；缺点是它不像关系型那样擅长跨集合的复杂关联查询。把约束告诉我，我再帮你收敛。」

用户补上了最关键的一条项目约束：

用户：「我不想碰服务器，也不想去管什么运维、备份、扩容，最好直接用现成的、国内的、免维护的。论坛这种帖子和评论的结构，是不是文档结构就够了？」

这条约束一出来，推荐结果就收敛了。AI给出结论，用户决策：

AI（方案确认步骤·选型收敛）：「如果要求免运维、免碰服务器，那Serverless托管数据库是唯一舒服的选择，关系型自建方案直接被排除。结合论坛的数据结构（帖子和评论本身就是文档结构，查询也是按标签、按时间这类简单模式），我推荐腾讯云的文档型数据库（CloudBase TDS）。决策后，我再额外列出『安全规则可能拦截哪些操作』，把风险前置暴露。」

用户决策文档数据库。这一步的要点是：AI列对比、用户补约束、用户决策，技术选型的责任没有外包给AI。用户虽然不懂服务器，但他清楚自己的底线（「不碰服务器、免运维、用国内的」），这一条底线就足以让AI把范围收敛到正确的选项上。它和「确认方案」处在同一个用户参与的时刻，所以属于同一轮。

表 10-4 第二轮对话 AI 产出

表 10-5 第二轮对话 问题与经验教训

第三轮对话（feat skill执行步骤：数据建模 + 代码实现 + 代码审核 + BDD验证）

用户决策方案和数据库之后，中间不再有用户参与，AI自动从「方案确认」进入「执行」，一次跑完后面一整段流程。先看数据建模：

AI（执行步骤·数据建模）：「数据模型已生成，共6个集合：forum_users（用户资料）、forum_tags（标签）、forum_posts（帖子）、forum_comments（评论）、forum_search_index（搜索索引）、forum_images（图片元数据）。每个集合都定义了字段、类型和索引：比如帖子集合有『按标签 + 时间』的核心查询索引、『置顶优先 + 最新回复』的首页索引。同步生成了一份初始化脚本，第一次部署时一键建好所有集合和索引，不用事后手动补。」

这里有个细节值得记住：初始化脚本随数据模型同步生成，而不是等开发到一半才想起来补。AI会主动把「建模」和「落地」绑在一起，这是它的强项，用户只需确认集合划分和索引是否覆盖了核心查询。

数据模型和初始化脚本就位后，紧接着冒出2个和数据库直接相关的问题。

第一个问题藏在CloudBase文档型数据库的集合权限里。集合建好后，默认权限并不开放读写，前端一访问就会被拦。AI尝试通过CloudBase Node SDK设置集合权限，多次尝试均不生效。最后由用户亲自在腾讯云控制台里找到「权限设置 → 编辑」，手动把权限改成 {"read": true, "write": true}，数据库才真正连通。

TODO [图片描述：权限设置→点击「编辑」按钮]

第二个问题更凶险，出在建索引这一步。初始化脚本按数据模型建索引时，AI建完索引后一查，集合里原有的数据全不见了，查询返回空结果。建索引这个操作疑似触发了集合重建，把已有数据删了。好在当时集合基本是空的，损失不大，但这个教训被记了下来：索引操作是危险操作，必须先备份，或者干脆在空集合上建索引。

TODO [素材锚点: 索引致数据丢失的具体出处需在每日开发记忆中进一步搜索确认]

这2个问题的共同教训是：凡是涉及数据库结构、权限、索引这类基础设施级操作，AI的自动执行都可能出错，而且出错的往往涉及关键数据。权限这种「在控制台点击按钮」的配置，用户直接操作更快；索引这种「可能改动数据」的操作，用户应先拦截、确认有备份再放行。

数据模型就位后，智能体按Brief（结构化任务说明）实现代码：

AI（执行步骤·代码实现）：「MVP代码已按方案实现完成：前端是React界面（组件层、页面层），中间是数据操作API（应用编程接口）层，底层对接文档数据库。发帖、回帖、标签分区、游客浏览、移动端适配都已落地，共9个功能对应的代码全部就位。」

代码产出后，进入代码审核步骤。这一步由AI自动进行：AI把生成的代码逐项审一遍，产出一份审核报告，列清发现的问题与建议，然后停下来等用户确认。用户此时只需确认一件事，审核结果要不要落实到代码里；用户确认后（比如选择全部修改），AI才去落实修改。所以代码审核虽然由AI自动完成，但「改不改、改哪些」的决策仍在用户手里。这是单独的一步，不是可有可无的。

AI（代码审核步骤·审核报告）：「审核了两类问题。第一类，检查代码有没有越界实现『MVP外不做』清单里的功能，果然在浏览功能里混进了半套站内信的逻辑，已标记删除；第二类，检查数据操作是否都走了API层、没有页面直接操作数据库。两处越界建议全部退回修正。以上是审核报告，请确认是否全部落实到代码里。」

回想一下：头脑风暴时AI第一个问题就是「要不要建账号系统」，现在执行阶段它又在浏览功能里塞进了站内信。AI有强烈的「做加法」惯性，总想把功能扩成完整系统，用户必须反复把范围拉回来。这就是为什么要有一条白纸黑字的边界清单，并且要在代码审核这个单独步骤里拿它逐项核对。

代码就位并通过审核，验证自动跟进。这一轮先只跑1层，BDD验证，功能级证据。BDD不是一句「我测过了」的空话，而是落到2个具体文件上的自动化测试用例：

AI（BDD验证步骤）：「发帖功能的行为契约是：「给定用户已登录 / 当用户提交一个含标题和正文的帖子 / 那么该帖子出现在对应标签的帖子列表中」。BDD测试用例由两类文件组成：① .feature 文件：行为契约，用『给定/当/那么』把每个功能应该怎么表现写成用户能读懂的条款，是『功能该长什么样』的书面合同；② .steps 文件：测试步骤实现，把 .feature 里每一句自然语言条款翻译成真正可执行的测试代码，机器靠它去实际点击、断言、比对数据。.feature 管『测什么』，.steps 管『怎么测』，两者一一对应。智能体跑完9个feature全部通过，意味着9个功能各自的行为都符合契约，而且这些契约都有对应的 .steps 真实执行过断言，不是空口说通过。」

这一轮没有跑E2E验证。不是漏了，是故意跳过的：E2E验证需要场景，也就是事先定义好「要测哪些用户路径」。现在是第一次开发，一套E2E场景都还没有，无场景可测，所以先跳过E2E，等这一节末尾专门把E2E场景搭起来再补。这个「先跳过、后补上」的安排，本身就是一种工程节奏：不要让一个还不具备前置条件的步骤卡住整条流程。

这一整轮，数据建模、代码实现、代码审核、BDD验证，AI都是自动从一个步骤进入下一个步骤，中间没有用户参与，所以合并成了同一轮。

TODO [素材锚点: 论坛项目方案 §1 §2 §3 §7]

表 10-6 第三轮对话 AI 产出

表 10-7 第三轮对话 问题与经验教训

第四轮对话（feat skill M阶段手动测试 + R阶段反思 + S阶段保存）

BDD验证通过后，AI没有停在原地，而是自动进入了M阶段（手动测试阶段）。feat skill在功能开发收尾时由3个阶段组成：M阶段（手动测试）由用户亲手在生产环境点一遍；R阶段（反思）负责归因、修复；S阶段（保存）负责提交代码、沉淀经验。三者依次进行，缺一不可。M阶段不是用户下命令开启的，是AI在验证完成后自动进入的。它会主动停下来，把线上验收这一步交给用户：

AI（M阶段）：「功能级验证（BDD）已通过。现在进入M阶段，需要亲手在线上点一遍：用真实浏览器打开线上论坛，用测试账号走一遍游客浏览、登录发帖、回帖、切换标签、移动端布局。这一层我替不了，只有亲眼在生产环境点过，才能确认真机上真的能用。」

用户按AI给出的路径在线上点了一遍。用户的反馈有个习惯值得记住：一般只会说「都正常」，而不会把每个正常的功能一一枚举；只有当某个功能有问题时，才会单独把它列出来。所以这一轮的反馈很简短：

用户（M阶段实测）：「都正常，可以上线。」

这一步为什么不能省？BDD是在测试环境跑的，只有用户亲手在生产环境点过，才能验证「真机上真的能用」。这是体验级证据，也是3层证据的最后一道。

在这个MVP里，M阶段没有发现问题，于是AI自动进入R阶段（反思）和S阶段（保存），中间没有用户参与。R阶段是「反思」，S阶段才是「保存」，两者是不同的阶段，不可混为一谈。R阶段也不是走过场式的空反思，它要把本轮遇到的问题复盘一遍，并把能落实的改进自动落实到代码、脚本或检查清单里：

AI（R阶段·反思并落实）：「本轮M阶段虽未发现新问题，但执行阶段踩过2个坑，一并复盘并落实：① CloudBase集合权限默认不开放读写，用SDK多次设置不生效，最后需在腾讯云控制台手动改权限，已把『建集合后要在控制台手动设读写权限』写进部署检查清单；② 建索引疑似触发集合重建、导致已有数据丢失，已把『建索引前先备份，或在空集合上建』写进检查清单，并在初始化脚本里补上先备份再建索引的步骤。教训均已落实，后续同类操作按清单执行。」

AI（S阶段）：「已保存并提交：代码 + 初始化脚本 + 方案文档 + 9个Specs，全部归档到这条Issue下面。同时把这次的关键决策（不建账号系统、文档数据库选型、P0/P1范围、M阶段测试路径）沉淀进项目笔记，方便下一次迭代复用。MVP迭代完成，feat skill流程到此结束。」

这就是M阶段之后还有R和S阶段的含义：M阶段不是最后一步。手动测试发现问题，R阶段负责反思（找到根因并修复）；反思完，S阶段负责保存代码、沉淀笔记。3步一气呵成，属于同一轮。10.4节会展示一次「真的在M阶段发现问题」的完整M+R+S演示。

表 10-8 第四轮对话 AI 产出

表 10-9 第四轮对话 问题与经验教训

第五轮对话（E2E自动测试skill E2E场景搭建）

feat skill结束后，还剩最后一件收尾的事：把E2E测试场景搭起来。前面第三轮之所以跳过E2E，就是因为缺这套场景。现在把它补上，目的是让后续每一次feat skill调用时，都能直接跑E2E测试。

这一步调用的是另一个技能，E2E自动测试skill（一个「自动跑端到端测试」的技能包）。它和feat skill有一个不同的特点：用户不需要写任何提示词，直接调用技能即可，技能会自己引导用户走完「定场景 → 生成场景 → 运行」的流程：

用户直接调用E2E自动测试skill（不写提示词）。

AI（E2E自动测试skill·询问场景）：「我是E2E自动测试技能。E2E测试需要先定『要测哪些场景』。希望覆盖哪些用户路径？是要把全部功能都测一遍，还是先测最小核心路径？」

用户没有贪多，而是指明先测最小核心路径。核心路径覆盖了论坛最关键的用户行为，也是最容易出回归问题的地方：

用户：「先测最小核心路径：从游客浏览，到登录发帖、回帖，能走通一条完整链路就够了。」

AI据此生成对应的场景，并向用户确认：

AI（E2E自动测试skill·生成场景）：「已按最小核心路径生成场景：打开首页 → 点击标签进入标签帖子列表 → 点开帖子详情 → 登录后点击发帖 → 填写标题和正文 → 提交 → 回到列表确认新帖子出现。这套场景会作为后续每次E2E回归的固定脚本，保证每次验证的是同几条真实链路。确认一下？」

用户确认了这套场景。AI把场景落成固定的场景JSON，并运行E2E自动测试：

AI（E2E自动测试skill·运行）：「场景JSON已生成并跑起来了。第一轮跑下来，中间有一步的校验没通过，我定位后自己修正，重跑后整条链路通过：从首页到发帖再到回列表确认新帖子出现，全部正常。这套场景已固定为后续每次E2E回归的基准脚本。」

这套E2E场景从此固定下来，成为后续所有迭代的E2E回归基准。之所以把E2E场景搭建单独提出来、放在feat skill结束后做，是因为「测什么」本身需要用户来决策：AI能跑测试，但「哪些用户路径值得反复测」取决于产品判断。场景一旦定下来，就变成了后续所有E2E验证的基准，所以值得为它单开一轮。（E2E的具体实现细节会在前面的理论章节说明，这里不展开。）

到这里，正好把BDD和E2E的分工说清楚，因为后面每一轮迭代都会反复用到：

• BDD测试由AI全权负责：AI生成BDD的 .feature（行为契约）和 .steps（测试步骤实现）并自动运行，用户几乎不用参与。
• E2E测试的场景由用户来定：AI负责跑，但「测哪几条用户路径」要用户来指定。

为什么E2E的场景不能像BDD一样直接交给AI？2个原因。第一，E2E测试较重，它要启动真实浏览器、走完整用户链路，不可能像BDD那样把所有路径全量测一遍，只能挑重点路径来测，而「哪条路径是重点」是产品判断，得用户来定。第二，E2E测试容易出问题，它要调用浏览器、Playwright这类外部工具，环境一抖动就容易失败，出问题时需要用户来纠正AI，判断到底是真的bug还是测试环境问题。

表 10-10 第五轮对话 AI 产出

表 10-11 第五轮对话 问题与经验教训

10.2.3 小结

这一节的核心，是让一句话需求收敛成可执行的方案并完成首次验证。下面把这一节的要点梳理一下。

表 10-12 本节知识要点

10.2.4 成果展示

这一节真正交付的，是可运行的MVP。所谓「可运行」，指的是下面这些真实效果（本文不贴代码，只看效果）：

• 论坛首页：打开就是深色主题的帖子列表，顶部搜索栏、左侧标签侧边栏、中间帖子卡片（标题、作者、预览、评论数）。TODO [图片描述：论坛首页截图：标签分区、帖子列表、搜索栏]
• 发帖功能：登录后点「发帖」，进Markdown编辑器，填标题、选标签、写正文、可配图，提交后帖子立刻出现在对应标签的列表里。TODO [图片描述：发帖页截图：Markdown编辑器、标签选择器]
• 回帖功能：帖子详情页底部有评论框，支持引用式回复（@用户名），评论以楼层形式展示在正文下方。
• 功能范围清单：P0（6项）/ P1（4项）的完整对照表，以及「MVP外不做」清单。TODO [图片描述：功能范围P0/P1表截图]
• E2E场景基准：一套覆盖「首页浏览→标签筛选→帖子详情→发帖→回列表」最小核心路径的E2E场景JSON，作为后续所有迭代回归的固定脚本。

要理解这背后发生了什么，记住一句话：以上全部效果，是用「一句话需求 + 几轮口语化回答」换来的。AI产出了方案文档、9个Specs、数据模型、初始化脚本和E2E场景JSON，而用户只做了一件事，在关键处决策和把关。

10.2.5 总结

这一节的实战流程，可以用下面的流程图来回顾：

flowchart TB subgraph 行1[ ] direction LR A[一句话需求] --> B[头脑风暴提问] --> C[口语化回答] --> D[2批清单] --> E[自动创建Issue] end subgraph 行2[ ] direction LR F[自动产出方案<br/>文档与Specs] --> G[用户确认方案<br/>与数据库选型咨询] --> H[数据建模与<br/>初始化脚本] --> I[智能体执行] --> J[代码审核] end subgraph 行3[ ] direction LR K[BDD验证] --> L[M阶段手动测试] --> M[R阶段反思] --> N[S阶段保存] --> O[E2E场景搭建] end E --> F J --> K

• 经验总结：AI编程的第一步，不是让AI写代码，而是让AI理清「到底要做什么、不要做什么」。这一步花的时间，会在后面执行和验收阶段加倍省回来。AI写代码极快，快到改错的成本远高于想清楚的成本。