使用Vibe Coding从零开发论坛（下）

目录

• 10.3 部署上线
  • 10.3.1 首次部署
  • 10.3.2 本地/生产数据分离
  • 10.3.3 通过微信对话的 SEO 优化
  • 10.3.4 小结
  • 10.3.5 成果展示
  • 10.3.6 总结
• 10.4 加入通知
  • 10.4.1 背景与动机
  • 10.4.2 完整实战对话
  • 10.4.3 小结
  • 10.4.4 成果展示
  • 10.4.5 总结
• 10.5 持续改进
  • 10.5.1 背景与动机
  • 10.5.2 完整实战对话
    • 问题一：优先级排序4轮纠偏
    • 问题二：集成测试15/15假绿
  • 10.5.3 小结
  • 10.5.4 成果展示
  • 10.5.5 总结
• 10.6 本文小结
• 10.7 课后练习

10.3 部署上线

MVP做完、测试通过，论坛现在只跑在本地。用户心里只有一个模糊的目标：把它放到线上，让别人通过一个URL就能访问。但「部署」具体要做什么、有哪些步骤、要准备什么凭据，用户完全没有概念。

这正是部署阶段的真实处境：用户只知道自己要什么结果（线上能访问），不知道过程（怎么打包、怎么上传、怎么配置）。如果这时候用户自己去查文档、学打包工具、学云平台控制台，学习成本会非常高；如果直接吩咐一句「部署吧」便不再跟进，又会在「部署成功」和「交付成功」之间出错，因为部署环境差异会让本地正常的功能一到线上就白屏、失效。

这一节的核心认知，是把2件事分开：「部署成功」是命令执行的结果，「交付成功」是生产环境真实可用的证据，二者不是一回事。接下来依次讲3件事：第一次部署怎么靠feat skill从头走通、本地与生产的数据为什么要分离、上线后如何继续用feat skill迭代功能并验证部署后证据。

10.3.1 首次部署

这是论坛的第一次部署，用户完全没做过，也不知道具体流程。于是他调用feat skill，让skill从头引导自己走完部署流程。这一次部署，方案不是一轮就出完的，而是拆成3轮：先定技术选型，再出部署方案，最后用户提供凭据。

第一轮对话（feat skill头脑风暴步骤 + 技术选型推荐）

用户调用feat skill，只说了目标：「把论坛部署上线，让别人能通过URL访问。」

AI（feat skill·头脑风暴步骤）：「先确认几个边界，好收敛部署方案。第一，想部署到国内还是国外的平台？第二，能接受自己维护服务器，还是希望完全免运维？第三，部署完成后主要给谁用：公开的玩家，还是内部测试？」

用户：「用国内的，能免运维最好，我不想碰服务器。给玩家公开用。」

边界清楚了，AI没有急着出方案，而是先把「到底选哪个平台」这件事单独列出，请用户决策：

AI（feat skill·技术选型推荐）：「基于『国内 + 免运维』的约束，我推荐腾讯云的静态托管（CloudBase静态托管）。论坛是纯前端项目（React构建出来的静态文件），数据库已经托管在云端，所以部署的本质就是两步：把代码打包成静态文件，再上传到云端的静态托管。腾讯云静态托管免服务器、免运维，直接给一个URL。确认这个技术选型吗？」

用户：「确认，就用腾讯云静态托管。」

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

本轮AI产出

技术选型结论（腾讯云CloudBase静态托管）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	技术选型单独一轮，用户确认了选型再出方案，不应将「选什么」和「怎么做」混为一谈

第二轮对话（feat skill方案产出步骤 + 方案确认步骤）

技术选型定了，AI在这一轮才出部署方案：

AI（feat skill·方案产出）：「选型已定，下面是部署方案文档，共两部分：① 部署策略：构建静态产物 + 上传静态托管 + 配置访问路径；② 配置清单：部署前需要提供的全部配置项，以及部署后要逐项确认的检查项。具体脚本到执行阶段再产出，现在先确认方案方向对不对。」

用户：「方向没问题。需要我提供什么配置，请列出来。」

AI（feat skill·方案确认）：「方案确认。配置清单里，需要从云平台控制台拿到三项配置：① 环境ID；② 访问密钥（Secret ID）；③ 访问密钥（Secret Key）。这三项是访问云平台必需的凭据。其余检查项（构建命令、跨域配置、访问路径）我会在脚本里处理好，不用管细节。」

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

本轮AI产出

部署方案文档（部署策略 + 配置清单）+ 配置项清单（环境ID、Secret ID、Secret Key）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	方案阶段只出方案和清单，不产脚本；「怎么做」和「真的动手做」是2个阶段

第三轮对话（用户提供配置凭据）

用户：「环境ID是xxx、Secret ID是xxx、Secret Key是xxx，开始吧。」

这里需要说明一个容易被忽略的问题：3项凭据为什么由用户自己提供，而不是交给AI去云平台抓？事实上，获取云平台凭据存在2种方法，二者处于不同层次，不能混为一谈。

方法一，直接提供。用户从云平台控制台复制环境ID、Secret ID、Secret Key这3项凭据，交给AI。本例采用的就是这种方法。

方法二，让AI去抓取。AI打开腾讯云控制台，由用户扫码登录，AI再读取页面上配置项的取值。这条路更省事，但现阶段不够稳定：登录态一旦过期、页面结构一旦调整，抓取就可能中断。

2种方法对应工程上的2个阶段：先用手动的方法一（直接提供）把流程跑通，再把跑通后的抓取过程固化成skill（例如「抓取腾讯云配置」skill）。此后AI可以自动抓取，用户连复制粘贴都省去。这就是「先手动跑通，再固化成skill」的通用做法。本例选择方法一，是因为首次部署尚未沉淀出可用的抓取skill，直接提供凭据最稳妥。

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

本轮AI产出

用户提供云平台凭据（环境ID、Secret ID、Secret Key）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	云平台凭据先由用户手动提供跑通，之后再固化成skill自动抓取

第四轮对话（feat skill执行步骤：产出脚本 + Phase C验证，不直接部署）

说明：Phase C（验证阶段）指在真正部署之前，对脚本做的自动校验。

AI（feat skill·执行步骤）：「已进入执行阶段，产出两份脚本：① 打包脚本：把论坛前端构建成静态产物，并处理好资源路径（用绝对路径，避免部署后资源加载错）；② 上传脚本：把产物上传到腾讯云静态托管的指定路径。随后我自动进入Phase C验证：本地先跑打包脚本，确认能构建成功、产物完整；再对上传脚本做空跑校验（不真正上传），确认脚本语法和参数无误。两份脚本都通过验证了，但我还没执行部署，部署是直接改动线上环境的操作，属于危险操作，需要确认后才执行。现在部署吗？」

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

本轮AI产出

打包脚本 + 上传脚本 + Phase C验证结果（构建成功、脚本校验通过）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	脚本在执行阶段才产出；验证（Phase C）与部署分开，部署需用户确认

第五轮对话（用户确认 → 执行部署 + 部署后测试）

用户：「确认部署。」

AI（feat skill·执行部署）：「收到确认，开始执行部署。打包、上传已完成，产物已到腾讯云静态托管。随后我做了部署后测试：访问线上地址，确认首页能加载、资源路径正确。部署完成，这是线上访问地址。」

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

本轮AI产出

部署执行 + 部署后测试 + 线上访问地址

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	命令执行完不算交付，部署后要立刻做一次线上访问验证

第六轮对话（M阶段验收发现白屏 → 自动进入子fix流程）

到这里，AI报告「部署完成」。但按feat skill的流程，命令执行完不等于交付成功，AI自动进入M阶段，把线上验收交给用户：

AI（M阶段）：「请在浏览器打开线上地址，亲手点一遍：首页能不能加载、帖子列表正不正常、能不能正常发帖回帖。」

用户手动验收，结果发现问题：

用户（M阶段实测）：「发现问题：打开线上地址，白屏了。控制台报错 Uncaught SyntaxError: Unexpected token '<'。」

这是第一次部署几乎必然遇到的问题，即部署环境差异。用户没有说「你来修」，只是报告了现象；而feat skill的M阶段已经定义了「发现问题 → 自动进入子fix流程」的机制。这里的子fix（子修复），指的是把单个问题单独拆出来、再走一遍「归因 → 方案 → 修复 → 验证」完整流程的做法。于是AI自动发起一个子fix，作为新一轮对话来处理这个问题。

表 10-23 第六轮对话 AI 产出

本轮AI产出

M阶段验收结论（发现白屏问题）

表 10-24 第六轮对话 问题与经验教训

问题	现象	原因	解决方案	经验教训
部署白屏	打开线上地址白屏，报 Unexpected token '<'	部署环境差异（待下一轮归因）	用户把白屏现象和控制台报错如实反馈给AI，自动进入子fix流程	命令执行完 ≠ 交付成功，要亲手验收

第七轮对话（子fix归因修复，新一轮对话）

AI（子fix·归因）：「子fix已发起。根因找到了：部署路径没有带尾斜杠。/gts_forum/dist 被浏览器当成了文件而不是目录，相对路径解析错了：加载JS时拿到的是HTML（所以报 Unexpected token '<'）。已修正部署路径（补上尾斜杠，并把资源路径改成绝对路径），重新上传，并把『路径是否带尾斜杠』这一项补进了部署检查清单。请再验收一次。」

表 10-25 第七轮对话 AI 产出

本轮AI产出

子fix issue + 白屏根因修复 + 检查清单补项

表 10-26 第七轮对话 问题与经验教训

问题	现象	原因	解决方案	经验教训
部署路径无尾斜杠	白屏，报 Unexpected token '<'	无尾斜杠时浏览器把 dist 当文件，相对路径解析错，JS加载拿到的是HTML	用户把白屏现象和控制台报错反馈给AI，触发子fix，复验确认正常	部署问题用子fix单独挂，不混进主流程；检查清单发现一个问题就补一项

第八轮对话（R阶段反思 + S阶段保存）

用户（复验）：「重新打开，正常了。」

用户复验通过后，AI没有直接收尾，而是自动进入R阶段（反思），把这次白屏的根因和教训复盘一遍，再进入S阶段（保存）：

AI（R阶段·反思）：「白屏问题复盘一下。根因是部署路径缺尾斜杠，属于典型的部署环境差异：本地开发服务器会自动补尾斜杠，云端静态托管不会，所以本地正常、线上才白屏。这类『本地正常、线上失效』的问题，单靠代码逻辑测不出来，只能在部署后检查清单里前置暴露，这次已经把它补进清单了。」

AI（S阶段）：「反思完成，开始保存。重新部署完成，线上地址已可正常访问。已把本次部署的脚本、检查清单和『路径带尾斜杠』这条经验保存下来，沉淀进项目笔记，下次部署直接复用。首次部署完成。」

表 10-27 第八轮对话 AI 产出

本轮AI产出

R阶段反思结论 + 部署脚本 + 检查清单 + 经验沉淀进项目笔记

表 10-28 第八轮对话 问题与经验教训

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	M阶段后还有R（反思）和S（保存），检查清单在实战中不断发现新问题、补进新条目，慢慢长出来

第九轮对话（把部署过程固化成skill）

首次部署走通、白屏问题也补进了检查清单之后，用户没有就此收工，而是把它沉淀成一个可复用的skill。这一步展示的正是「发现一个问题就补一项」的工作流沉淀：第一次手动走完、把问题记下来，第二次就交给一个固化好的skill自动跑：

用户：「部署已经跑通一遍了，把整个部署过程固化成skill·叫『部署论坛到腾讯云』。以后我只要调用这个skill，它就能自动完成打包、上传、验证，不用再像这次一样一轮轮手动走。」

AI（skill固化）：「已把这次部署踩过问题后跑通的完整流程固化成『部署论坛到腾讯云』skill，内容有四步：① 打包：生产构建用绝对路径 /gts_forum/dist/（带尾斜杠），直接规避上次白屏的路径问题；② 上传：把产物上传到腾讯云静态托管；③ 部署后验证：访问线上地址，确认首页能加载、资源路径正确；④ 检查清单：把『路径带尾斜杠』『部署后立刻验证』这些发现一个问题就补一项的经验写死进清单。以后只要说一句『部署论坛』，整个流程自动跑完，不需要再逐项确认，也不需要重新回忆上次踩过什么问题。」

这一步是「先手动跑通，再固化成skill」的完整闭环：第一次部署靠用户逐步确认，遇到问题后把流程与教训一并固化，第二次起只需一句指令。这也是为什么说检查清单会「发现一个问题就补一项」地长出来，它最终会连同打包、上传、验证一起，被收进一个专门负责部署的skill里，成为这个项目专属的「问题防御地图」。

表 10-29 第九轮对话 AI 产出

本轮AI产出

『部署论坛到腾讯云』skill（打包 + 上传 + 部署后验证 + 检查清单）

表 10-30 第九轮对话 问题与经验教训

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	第一次手动跑通、遇到问题后把流程与教训固化进skill，第二次起一句话自动完成

这里有几个关键认知。第一，部署方案不是一轮出完的，而是拆成「选型 → 方案 → 凭据」3轮：选型让用户决策「用什么平台」，方案让用户确认「怎么做」，凭据让用户提供「访问凭据」，每一步用户都只面对一个明确的问题。第二，部署脚本和检查清单是AI按项目配置自动生成的，用户只提供云平台凭据和逐项确认，用户不需要懂打包和上传的细节，只需要懂「要提供什么、要确认什么」。第三，检查清单不是一次写死的，是在实战中不断发现新问题、补进新条目，慢慢长出来的，这次补进去的「路径带尾斜杠」，正是第一次白屏换来的经验。第四，云平台凭据这次由用户手动提供，是为了先跑通；跑通一次后，把整个部署流程连同检查清单一起固化成「部署论坛到腾讯云」skill，以后一句「部署论坛」就能自动完成，连凭据抓取和逐项确认都省了。

TODO [素材锚点: 部署流程套用游戏项目的部署方式：打包 + cloudbase hosting deploy上传；白屏问题见每日开发记忆]

10.3.2 本地/生产数据分离

上线后不久，用户在本地开发时发现一个隐患：本地调试插入的测试数据，和线上真实数据混在同一个数据库里。这不是一次出了bug的抢修，而是一个需要主动补上的能力，把本地开发环境和线上生产环境的数据分开。这是一个「新增/改进」类任务，所以继续调用feat skill（新增功能），和前面部署、SEO走的是同一套流程。

第一轮对话（feat skill头脑风暴步骤 + 方案产出）

用户调用feat skill，描述诉求：「我在本地开发调试时插入的测试帖子、测试评论，跑到线上论坛里去了。给我加上本地开发和线上数据分离的能力，让两边数据隔离开。」

AI（feat skill·头脑风暴步骤）：「先确认两个边界，好收敛方案。第一，隔离粒度要精确到集合（collection）这一层，还是整个环境用不同的数据库实例？第二，切换要不要手动操作，还是希望自动切换？」

用户：「就按集合层隔离，编译期自动切换，别让我手动记着换库。」

AI（feat skill·方案产出）：「方案已成型。开发环境用本地集合后缀 _local 隔离，生产环境用正式集合名，比如本地是 forum_users_local，线上是 forum_users。这样本地读写永远落在带后缀的集合上，碰不到生产数据。同时产出Specs：『本地构建时，所有集合名自动带 _local 后缀；生产构建时，集合名保持正式名不变』，这条会写成可验证的行为契约，作为后续验收的对照基准。」

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

本轮AI产出

环境隔离方案（_local 后缀）+ Specs

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

问题	现象	原因	解决方案	经验教训
测试数据污染生产	本地测试帖、测试评论跑进了线上	本地/生产共用一套云端数据库，无隔离	调用feat skill头脑风暴确认隔离粒度后提出环境隔离方案	新增/改进类任务统一用feat skill；头脑风暴先把隔离粒度和切换方式问清

第二轮对话（feat skill确认 + 执行 + 验收，简略）

用户（确认）：「对，就这样，本地和生产分开。」

AI（feat skill·执行 + 验收）：「已实现编译期环境区分：开发构建时所有集合名自动加 _local 后缀，生产构建用正式集合名。这次产出包括：① 配置分离代码：编译期注入环境标记，运行时决定集合名；② 两份配置JSON：本地配置与生产配置，作为验收对照。按方案定的验收标准复验通过：本地构建的集合名都带 _local 后缀、生产构建保持正式名。本地测试数据从今往后永远进不了生产库。」

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

本轮AI产出

环境隔离配置（编译期 _local 后缀 + 两份配置JSON）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	用集合名后缀做编译期隔离，是最简单可靠的方案

TODO [素材锚点: 本地/生产数据分离方案]

10.3.3 通过微信对话的 SEO 优化

上线后，论坛需要被搜索引擎收录。这一次，用户不再坐在电脑前一步步跟着AI走，而是通过微信远程派任务：在微信里调用feat skill、发一句需求，智能体在后台自己跑完整个feat流程，最后微信收到一条完成回执。用户只需要在微信里确认几个关键点，其余都交给后台执行。

第一轮对话（feat skill头脑风暴 + 方案产出，简略）

先说明微信是怎么调用feat skill的：在提示词里直接写清楚要调用哪个技能、要它做什么，也就是「调feat skill：给论坛加入SEO优化」。技能名和诉求一起写，智能体就会按feat skill的流程跑起来。

用户通过微信调用feat skill，提示词是：「调feat skill：给论坛加入SEO优化。」

AI（feat skill·头脑风暴步骤，微信回复）：「好，SEO优化的范围我先理一理。论坛目前所有页面共用同一个标题，也没有meta描述、OG标签、结构化数据、sitemap。核心要解决的是：让搜索引擎和分享链接能读懂每一页是什么。我确认几个点：第一，要做双语（中英）的SEO标签吗？第二，首页和帖子详情页是重点，标签页和用户页要不要一起覆盖？」

用户（微信回复）：「中英双语都要。首页、帖子详情页、标签页都覆盖。」

AI（feat skill·方案产出）：「方案已成型，产出一份SEO优化方案和Specs：用动态title/meta/OG标签 + JSON-LD结构化数据 + sitemap.xml + robots.txt，覆盖首页、帖子详情页、标签页，并按语言动态切换中英文。执行完成后，我会部署并给出线上验证证据。」

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

本轮AI产出

SEO优化方案 + Specs

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	用户不需要懂技术细节，一句「加SEO」就能交给feat skill

第二轮对话（feat skill执行 + 部署 + 验证，简略）

用户（微信确认）：「就按这个做。另外说明一下：SEO只是配置类改动，不需要BDD和E2E测试，实现完直接部署、做部署后验证就行，别在测试上耗时间。」

用户在微信里确认方案，并主动说明「这只是配置类改动、不需要BDD和E2E」，于是智能体在后台直接跑完实现、部署、部署后验证的整个流程，跳过了BDD/E2E这2层，最后微信收到一条完成回执：

微信回执（AI，feat skill·执行）：「SEO功能已实现并部署。按说明，这是配置类改动，我跳过了BDD和E2E，改做部署后线上验证：访问线上地址，确认首页、详情页、标签页的title/meta/OG标签、结构化数据、sitemap、robots.txt都在生产环境真实生效。」

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

本轮AI产出

SEO实现 + 部署 + 部署后线上验证（配置类改动，跳过BDD/E2E）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	配置类改动可主动说明「不需要BDD/E2E」，跳过重验证直接看线上证据，加快流程

这里展示的是一种异步协作方式：用户通过微信派任务、收回执，关键在于它不需要电脑，直接用手机就行，人即使出门在外，也能通过微信指挥AI干活。它和前面几节「坐在电脑前一轮轮对话」是同一个feat skill流程，只是对话入口从电脑换成了微信。工具和入口会变，但feat skill的流程结构不变。

这里有一个贯穿本文的习惯值得再强调一次：AI说「已完成」，要追问「线上证据呢」。SEO这次按用户判断跳过了BDD/E2E，反而让「线上证据」变得更关键。因为没有测试兜底，唯一能证明「真完成了」的，就是部署后在生产环境逐项核对：首页、详情页、标签页的title/meta/OG标签、结构化数据、sitemap、robots.txt是否都真实生效。部署后证据必须来自生产环境，而不是本地，本地正常、线上失效，正是部署阶段最典型的现象。

TODO [素材锚点: SEO优化方案]

课堂互动：如果是第一次部署，部署清单会漏掉哪一项？试着先列3项，再和本节Checklist里「发现问题后补进去」的项对照。

10.3.4 小结

这一节讲的是如何把本地可运行的项目真正交付到线上，并持续迭代。下面把这一节的要点梳理一下。

表 10-39 本节知识要点

你学到了什么	说明
部署成功 ≠ 交付成功	AI汇报「部署成功」只是命令执行完，打开浏览器线上真实可用才算交付。所以每次部署后都要有回归验证，而不是听一句汇报就收工
首次部署靠feat skill出方案	用户不懂部署没关系，只要调用feat skill、会提供云平台凭据、会逐项确认检查清单，剩下交给AI。用户需要懂的是「要提供什么、要确认什么」，而不是打包上传的细节
方案与脚本分离	方案阶段只出方案文档（策略、选型、配置清单），不产具体脚本；脚本在执行阶段才产出。想清楚「怎么做」和「真的动手做」是2个阶段
验证与部署分开	AI可以先自动验证脚本（Phase C测试），但不直接部署，部署是危险操作，必须用户确认后才执行
Checklist发现一个问题就补一项	部署清单不是一次性写死的，每翻一次车就补一行。用几次之后，它就成了这个项目专属的「问题防御地图」
把流程固化进skill	第一次手动跑通、遇到问题后，把打包 + 上传 + 部署后验证 + 检查清单一起固化成「部署论坛到腾讯云」skill，第二次起一句话自动完成，这是「先手动跑通，再固化成skill」的通用做法
改进类任务也用feat skill	本地/生产数据分离不是「出了bug要修」，而是主动补上的改进能力，继续用feat skill走「头脑风暴 → 方案 → 执行 → 验收」同一套流程。头脑风暴先把隔离粒度（集合层）和切换方式（编译期自动）问清，再出方案
本地/生产数据隔离	本地调试数据和线上真实数据必须分开，否则测试数据会污染生产库，误操作还可能误删线上数据。用集合名后缀做编译期隔离，是最简单可靠的方案
部署后证据来自生产	AI说「SEO已完成」不够，要追问线上证据。证据必须来自生产环境而非本地，因为「本地正常、线上失效」正是部署阶段最典型的现象

10.3.5 成果展示

• 部署脚本 + 部署Checklist：一份由AI按项目配置生成、用户提供凭据并逐项确认、发现一个问题就补一项的部署套件。它的价值不在于「列了多少项」，而在于每一项都是真实翻过车后沉淀下来的。
• 「部署论坛到腾讯云」skill：把上面这套部署套件（打包 + 上传 + 部署后验证 + 检查清单）固化成一个可复用的skill，以后一句「部署论坛」就能自动完成。这是「先手动跑通，再固化成skill」的完整闭环。
• 本地/生产环境分离：开发环境自动使用 _local 后缀集合，从机制上保证本地测试数据永远进不了生产库。
• 部署后线上证据：SEO功能部署后线上验证通过，title/meta/OG标签、结构化数据、sitemap、robots.txt在生产环境真实生效。这个证据必须来自生产环境而不是本地，因为本地正常、线上失效，正是部署阶段最典型的现象。

10.3.6 总结

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

flowchart TB subgraph 行1[ ] direction LR A[首次部署] --> A1[调用feat skill] --> A2[头脑风暴与<br/>技术选型] --> A3[用户确认选型] --> A4[方案产出与<br/>配置清单] end subgraph 行2[ ] direction LR A5[用户确认方案] --> A6[用户提供凭据] --> A7[执行出脚本与<br/>Phase C验证] --> A8[用户确认部署] --> A9[执行部署与<br/>部署后测试] end subgraph 行3[ ] direction LR A10[M阶段验收<br/>发现白屏] --> A11[自动进入子fix] --> A12[子fix归因修复] --> A13[R阶段反思] --> A14[S阶段保存沉淀] end subgraph 行4[ ] direction LR A15[把部署过程<br/>固化成skill] --> B[本地/生产<br/>数据分离] --> B1[feat skill头脑风暴<br/>与方案产出] end subgraph 行5[ ] direction LR C[上线后<br/>SEO功能迭代] --> C1[feat skill与<br/>微信派任务] --> C2[跳过BDD/E2E与<br/>部署后线上证据] end A4 --> A5 A9 --> A10 A14 --> A15 B1 --> C

• 经验总结：部署成功是命令结果，交付成功是生产环境证据；部署完不是结束，验证才是。更进一步，当AI说「已完成」时，养成追问「线上证据呢」的习惯，能拦住大多数「口头完成」。

10.4 加入通知

10.4.1 背景与动机

论坛上线后，出现一个真实的问题：用户发帖或回帖后，对方完全不知道，没有通知，只能靠主动刷新去看有没有用户回自己。于是我们要给论坛加一个通知系统。

这个功能本身不复杂，但它是本文「3层证据验收」最完整的一次演示：从头脑风暴、到BDD/E2E自动验证、再到M阶段用户亲手测试发现问题、再到一个子fix走完整流程。我们特意完整展示它，因为它把feat流程里每一步该怎么用、能抓住什么问题，都演了一遍。尤其是这一次，M阶段真的抓出了问题。

10.4.2 完整实战对话

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

用户调用feat skill，提示词只说了一句：「论坛加个通知功能。」

AI（头脑风暴步骤）：「通知谁？哪些事件触发？自己的操作要通知自己吗？已读怎么算？同一个目标出现多条通知怎么处理？」

用户逐条回答：

用户：「有人发帖就通知帖主，有人评论就通知作者，管理员操作了通知相关的用户；自己操作自己的事不用通知；点开一条，同帖的其他通知都算已读；同一个目标重复通知就只留一条。」

头脑风暴结束，AI自动创建Issue并产出方案（中间没有用户参与）：

AI（Issue创建步骤）：「已根据对话自动创建Issue『论坛通知系统』，并把需求边界和待澄清项整理进去。」

AI（方案确认步骤·自动产出方案）：「方案已成型：Brief（步骤/边界/验收标准）+ Specs（行为契约）。其中Specs里沉淀了这些结构化规则：谁在什么事件下收到什么类型的通知、自操作不通知、同帖已读联动、同一目标去重。」

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

本轮AI产出

Issue『论坛通知系统』、方案（Brief + Specs）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	头脑风暴把「通知谁、何时触发、已读、去重」这些边界先问清楚

第二轮对话（feat skill方案确认步骤）

用户确认方案。这里要强调一个关键点：用户只需要阅读方案产出的markdown文件，确认「方案方向对不对」，不需要读懂Specs这些技术细节。通知功能不涉及新的数据库选型（直接沿用已决策的文档数据库），所以这一轮只做方向确认，没有选型环节。那些结构化规则（谁在什么事件下收到什么通知、自操作不通知、同帖已读联动、同一目标去重）早在上一轮头脑风暴时就被AI沉淀进Specs了，用户不必再逐条过问细节，只要打开方案的markdown文件扫一眼，确认方向没错就行：

用户：「方案没问题，按这个做。」

AI（方案确认步骤）：「确认。规则已经写进Specs，作为后续验收的对照基准。」

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

本轮AI产出

方案方向确认（规则已在头脑风暴中沉淀进Specs）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	用户只需确认方向，Specs这些技术细节由AI负责

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

用户确认后，AI自动进入执行，一次完成实现和2层自动验证（中间没有用户参与）：

AI（执行步骤·代码实现）：「通知的创建、列表、已读逻辑已实现，通知可以点击跳转到对应帖子或评论，未读通知有醒目样式，支持『全部标已读』和『清空』。」

AI（代码审核步骤）：「审核通过：通知写入集中在服务端一条路径，没有绕过API层直接操作数据库的越界实现。」

AI（BDD验证步骤 + E2E验证步骤）：「BDD对通知的4个feature全部通过；E2E按10.2节搭好的现有场景回归通过：游客浏览 → 发帖 → 回帖 → 回列表确认，基本链路无报错。注意，此时E2E场景里还没有通知相关的路径，通知自己的E2E场景下一步再补。」

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

本轮AI产出

通知代码实现 + 代码审核 + BDD（4 feature全通过）+ E2E回归通过（10.2现有场景）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	自动验证通过 ≠ 功能没问题，后面M阶段还会抓出bug（而且不止一次）

第四轮对话（E2E自动测试skill补充通知E2E场景）

通知功能引入了新的用户路径，但10.2节定下的E2E场景基准里还没有通知相关的场景。于是用户调用E2E自动测试skill，补充通知的E2E场景：

用户调用E2E自动测试skill（目标：给通知功能补E2E场景）。

AI（E2E自动测试skill·生成场景）：「已把通知相关的用户路径补进场景JSON：发帖触发通知 → 回帖触发通知 → 打开通知面板 → 点开一条 → 同帖其他通知联动标已读。确认后，这条链路纳入后续所有E2E回归。」

用户：「确认。」

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

本轮AI产出

通知场景补进E2E场景JSON（已读联动链路）

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

问题	现象	原因	解决方案	经验教训
—（本轮无问题）	—	—	—	新功能引入新用户路径，要及时调用E2E auto skill补进场景基准

第五轮对话（feat skill M阶段手动测试）

自动测试都通过了，AI自动进入M阶段，请用户亲手验收。但M阶段（手动测试）用户亲手点一遍，还是发现了一个问题：

用户（M阶段实测）：「发现问题：管理员会收到同一评论的重复通知，有时是2条、有时3条。」

这个问题，自动测试没抓到，因为它在真实数据环境下才暴露，测试数据里没造出「管理员同时是作者」这种交叉身份。这就是M阶段不可省略的原因。发现问题后，feat skill的M阶段机制自动发起一个子fix，作为新一轮对话走完整流程。

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

本轮AI产出

M阶段验收结论（发现重复通知问题）

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

问题	现象	原因	解决方案	经验教训
通知重复	管理员收到同评论2~3条通知	待子fix归因	待子fix修复	自动测试没抓到，M阶段亲手测才暴露

第六轮对话（子fix通知去重，一轮完整流程）

M阶段反馈的重复通知问题，成为子fix的需求输入。AI走完整fix流程，先归因、再出方案、再执行修复、再验证：

AI（子fix·归因）：「重复通知的根因找到了：创建评论时，代码同时走了『内容互动通知』和『管理广播通知』两条路径，没有去重检查。当管理员恰好是帖子作者或被回复评论作者时，就会收到同一条评论的多份通知。修复方案：对同一个目标，只保留优先级最高的通知类型（回复评论 > 评论帖子 > 新评论广播），仅对管理员去重。」

这个子fix里藏着一个更有价值的细节：AI产出的Delta Specs（增量规格，只描述本次新增或变更的行为）里，2个场景的描述自相矛盾，一个场景说「管理员只收1条」，另一个场景说「普通用户收2条共存」，期望相反。用户没有纠结Specs文字，而是以数据结果为准裁决，收敛为「只对管理员去重」。

证据驱动：以数据结果为准，不以Specs描述为准。当文字描述打架时，落到数据上的实际结果才是裁判。

AI（子fix·执行 + 验证）：「已按『对同一目标只保留最高优先级通知类型』修复，并新增Delta Specs覆盖去重场景，回归验证通过。」

修复完成后，子fix进入自己的M阶段，请用户复验：

用户（子fix复验）：「去重生效了，管理员现在只收到一条。」

表 10-50 第六轮对话 AI 产出

本轮AI产出

子fix：根因分析 + 修复方案 + Delta Specs + 回归验证结果 + 复验通过

表 10-51 第六轮对话 问题与经验教训

问题	现象	原因	解决方案	经验教训
通知重复	管理员收到同评论2~3条通知	内容互动通知 + 管理广播通知两路并行，无去重	同一目标只保留最高优先级通知类型	以数据结果为准，不以Specs文字描述为准

第七轮对话（R阶段反思 + S阶段保存）

子fix修复并通过复验后，AI没有直接收尾，而是自动进入R阶段（反思），把这个bug的教训复盘一遍，再进入S阶段（保存）：

AI（R阶段·反思）：「重复通知这个bug复盘一下，它指向一个教训：自动测试全绿不等于线上没问题。重复通知是测试数据里没造出『管理员同时是作者』这种交叉身份，两层自动验证都通过，问题却在真实环境才暴露，所以M阶段亲手点一遍不可省。」

AI（S阶段）：「反思完成，开始保存。子fix已修复并复验通过。已提交代码，并把『以数据结果为准』这条经验写进问题知识库，下次同类问题不再重踩。」

这里的「问题知识库」是项目笔记的一部分，把踩过的问题与解法沉淀成可检索的条目，供后续同类任务直接复用。

表 10-52 第七轮对话 AI 产出

本轮AI产出

R阶段反思结论 + 复验通过 + 代码提交 + 经验写入问题知识库

表 10-53 第七轮对话 问题与经验教训

问题	现象	原因	解决方案	经验教训
—（已在前一轮记录）	—	—	—	M阶段后还有R（反思）和S（保存沉淀），3步一气呵成

TODO [素材锚点: 通知系统、通知去重2个change的方案与反思记录]

10.4.3 小结

这一节完整演示了 feat 流程中3层证据验收的全过程。下面把这一节的要点梳理一下。

表 10-54 本节知识要点

你学到了什么	说明
3层验证闭环	BDD看单个功能、E2E看完整链路、M阶段看真实体验，三者缺一不可。通知系统的重复通知bug就是M阶段才暴露的，自动测试通过 ≠ 功能没问题
证据驱动验收	以数据结果为准，不以Specs文字描述为准。当AI产出的规格自己打架时，落到数据上的实际结果是唯一的裁判
M阶段不可省略	用户亲手在生产环境点一遍，是3层证据的最后一道。通知系统的重复通知问题，就证明了这一步的价值，自动测试在真实数据环境里抓不到它
子fix也是完整流程	发现一个问题，就发起一个子fix，作为新一轮对话走完「归因 → 方案 → 修复 → 验证」。不把修复混进主流程，每个问题独立闭环
M后还有R和S	M阶段不是终点。发现问题后AI自动进入R阶段反思（归因修复）、S阶段保存沉淀，3步属于同一轮，一气呵成

10.4.4 成果展示

• 通知系统可运行效果：发帖/回帖时，相关用户收到可点击跳转的通知；未读有醒目样式；支持全部标已读和清空。这个功能跑了BDD、E2E、M阶段3层验证才落地，不是「写完就交」。

10.4.5 总结

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

flowchart TB subgraph 行1[ ] direction LR A[头脑风暴] --> B[自动创建Issue] --> C[自动产出方案<br/>Brief与Specs] --> D[用户确认方向] --> E[执行代码审核<br/>BDD与E2E<br/>现有场景] end subgraph 行2[ ] direction LR F[调用E2E<br/>auto skill<br/>补通知场景] --> G[M阶段发现<br/>重复通知问题] --> H[子fix去重复验通过] --> I[R阶段反思] --> J[S阶段保存沉淀] end E --> F

• 经验总结：验收不是听汇报，而是主动去找能推翻「已完成」的证据。AI说「通过了」不可信，只有数据结果对照上、用户亲手点过，才算数。

10.5 持续改进

10.5.1 背景与动机

论坛上线并稳定运行后，进入持续迭代阶段。前面几节展示的功能开发基本按计划推进，但真实项目并非总是如此。本节挑出2个影响最深的问题：优先级排序改了4轮才对，集成测试15/15全绿却是假的。这里所谓的「假绿」，指的是测试虽然全部显示通过，但断言实际并未执行。「4轮」指4次形态变更（字符串排序 → 缺索引 → 建索引 → 优先级独立Tab），正文对话压缩为3轮呈现。

这2个问题值得单独讲解，不是因为技术难度高，而是因为它们都属于AI「自报通过」、实际却未真正解决的问题。排序问题暴露的是：AI每一轮都高效地交付了方案，但前几轮解决的是被误解的问题，「高效」用错了方向。假绿问题暴露的是：「测试全绿」本身也可能是假象，断言可能根本没有执行。前者说明动手之前先确认「要解决的究竟是哪个问题」同样重要，后者说明「智能体自报通过不等于真通过」不是一句口号，而必须落实为可执行的验证机制。这两个案例都不是技术难题，而是流程漏洞的典型样本，因此更适合拿来复盘。

10.5.2 完整实战对话

本节的两段过程均为真实案例的教学性重组，大幅压缩了中间轮次，只保留用户提示词、AI回复与关键产出的因果关系。

问题一：优先级排序4轮纠偏

第一轮对话（fix skill方案步骤）

用户调用fix skill（修复已有功能的技能包）提出需求：

用户（调用fix skill）：「bug/建议分区需要按优先级排序。」

fix skill照例要先进入Phase 0阶段（在运行时通过打日志等方式定位根因）。这一次用户在提示词里指明直接跳过Phase 0，理由是：AI应该能自己找到根因，无需在运行时打日志来确定。

AI先给出的是客户端排序的方案：在客户端对当前页的帖子按优先级字段排序。AI一开始选择客户端，是因为它实现快、不用改后端；但排序需要跨页保持顺序，而客户端只能排当前页，这个前提一开始就被忽略了。实现并部署之后，用户在M阶段测试时发现，翻页之后排序会重新打乱。于是发起一个子fix，AI给出下面的方案：

AI（子fix·方案步骤）：「改为服务端增加优先级字段排序，并移除客户端排序。这样高优先级帖子可以全局排在前面，不会因为翻页而被重新打乱。」

用户同意，AI执行并部署。这一版的优先级字段采用字符串（低/中/高）。

第二轮对话（fix skill修复步骤：连续2次归因）

部署后，用户反馈排序仍然错误：

用户（验收反馈）：「排序还是错的，高优先级的帖子排到了低优先级后面。」

AI随即进入修复步骤，自动连续跨过2个转折，中间没有用户参与：

AI（修复步骤·归因一）：「找到了。优先级字段用的是字符串，字符串按字符编码排序，所以『中 < 低 < 高』，与高优先级排在前面的直觉相反。NoSQL的字符串排序规则和预期不一致。」

AI把优先级改成数值字段重新排序，可AI在测试时进行的查询却返回空结果，于是继续归因。这同样是AI的自动修复，无需用户参与：

AI（修复步骤·归因二）：「空结果的原因是缺少数据库索引。改数据模型时我增加了排序字段，但没有同步检查索引需求。没有匹配的复合索引，排序在分页场景下不可靠，甚至会被直接丢弃。」

AI建好复合索引后，排序恢复正确。

第三轮对话（fix skill调整步骤：把优先级改成独立 Tab）

到这一步，排序本身已经正确。但前几轮AI把优先级排序做成了「整个 bug/建议分区强制按优先级排」：无论用户切到哪个排序Tab，服务端都按优先级字段排。于是又冒出一个新问题：「热门」Tab失效了。用户切到「热门」，看到的仍是优先级顺序，而不是热度顺序。这个「强制排序」是AI自己选的实现方式，并不是用户提出的需求：用户要的是「能按优先级看」，而不是「所有排序Tab都被优先级接管」。用户发现后提出调整：

用户（调整反馈）：「我要的是能按优先级排序，不是让所有排序都被优先级接管。把它做成一个单独的排序Tab，我自己切；「最新」「热门」这些还按原来的排。」

AI（调整步骤）：「明白。我在 bug/建议分区新增一个「优先级」排序Tab：只有选中它时才按优先级排；「最新」「热门」「精华」「推荐」恢复各自原有的排序，不再对整个分区强制按优先级排。」

这样，优先级排序从「强制接管整个分区」改成了「用户手动切到『优先级』Tab才生效」：既满足「能按优先级看」的需求，又不干扰其他排序Tab。这一转折值得注意：技术上能排序，不等于就该对所有场景强制排序。AI一开始默认「能替用户多做一点就多做一点」，但「在哪排、怎么排」属于产品判断，只有用户能决定。这也说明，需求一开始并不一定就是用户想要的，需要根据实际情况不断调整。回顾整个过程，每一轮的Brief都写明了上一轮的前提条件，这正是长任务的分阶段交接：把大任务拆成多轮，每轮带着上一轮的前提继续，避免AI在长任务中遗忘前置约束。

4轮下来，排序问题的形态依次是：字符串排序 → 缺索引 → 建索引 → 优先级独立Tab。前几轮AI一直在解决「如何让优先级排序生效」，真正要解决的问题却是「如何让用户按需选择排序」。这提醒我们，AI的「高效」本身不构成正确；方向错了，它只是更快地把事情做错。

表 10-55 问题一 问题与经验教训

问题	现象	原因	解决方案	经验教训
客户端排序翻页错乱	实现客户端排序后，翻页排序重新打乱	客户端只排当前页，跨页无法全局保序	子fix改为服务端排序	排序这类全局需求要放到服务端做
字符串排序错乱	高优先级排到低优先级后面	字符串按字符编码排序，与优先级语义相反	改用数值字段	选型前先让AI列出排序规则的限制
缺索引返回空结果	改数值字段后查询为空	改数据模型时未同步检查索引需求	建立复合索引	模型变更必须检查索引
优先级排序接管了其他排序Tab	切到「热门」Tab仍按优先级排，热度排序失效	AI把优先级做成整个分区强制排序，覆盖了用户的Tab选择	改为独立的「优先级」Tab，用户手动选择	排序要按用户的实际用法设计，不要让一个排序逻辑接管用户对其他Tab的选择

TODO [素材锚点: changes/2026-07-29-forum-priority、changes/2026-07-30-forum-priority-sort、…-round3/specs/root-cause-analysis.md、…-round4/solution.md；逐字对话待补，现为教学性重组]

问题二：集成测试15/15假绿

第一轮（全绿与识破）

一次全量测试矩阵复验中，代码智能体跑出的集成测试15/15全绿，表面上看无可挑剔。但这个「全绿」并没有骗过后续流程：用户在M阶段测试时发现仍然有问题，于是发起子fix；调度智能体接手排查，才发现这是假绿。它做了一次试探：把相关功能替换成空实现（什么都不做的假实现），测试结果竟然仍是15/15全绿，这证明断言从未真正执行。深入排查后，根因浮现：

AI（归因）：「排查结果：测试环境里，数据库模块访问了浏览器对象 window，直接抛出异常，于是数据库被标记为不可用，所有断言都被一行 if (!dbAvailable) return 静默跳过。所谓『全绿』是假的，测试根本没有执行。」

第二轮（修复与固化）

AI（修复）：「已改用内存mock（模拟对象）替代真实数据库依赖，让断言真实执行。现在空实现会真实报错，说明测试有效了。」

从此引入一条铁律：由调度智能体独立复验。代码智能体负责实现，调度智能体负责独立复验：调度智能体不再依赖代码智能体的口头承诺，而是由自己独立地重新跑一遍全量测试矩阵，确认断言真实执行、结果真实可信。环境缺少凭据时，宁可显式失败，也不静默跳过来制造假绿。假绿最危险的地方在于它披着「全绿」的外衣，越到后期越难被发现，所以复验必须由调度智能体独立进行，而不是听代码智能体再汇报一次。修复后的回归结果是：BDD 177/177、集成测试15/15、类型检查通过。这条教训也按「发现一个问题就补一项」的方式，写进了问题知识库。

表 10-56 问题二 问题与经验教训

问题	现象	原因	解决方案	经验教训
集成测试假绿	空实现仍15/15全绿	测试环境访问window抛异常，断言被静默跳过	用空实现试探识破，改用内存mock让断言真实执行	全绿之前先验证断言是否真实执行；由调度智能体独立复验，不依赖代码智能体的口头承诺

TODO [素材锚点: daily/2026-08-05.md L108-145；逐字对话待补，现为教学性重组]

10.5.3 小结

这一节的2个问题，指向同一类风险：AI的自报结果不可直接采信。下面把这一节的要点梳理一下。

表 10-57 本节知识要点

你学到了什么	说明
长任务分阶段交接	优先级排序前后4轮，每一轮的Brief都写明上一轮的前提条件，防止AI在长任务中遗忘前置约束。大任务应拆成多轮，每轮独立立项、带着前提继续
先确认要解决哪个问题	前几轮AI一直在解决「如何让优先级排序生效」，但用户真正要的是「按需选择排序」。方向错了，效率越高偏离越远。动手之前，先确认问题本身
选型前让AI列限制	字符串排序、缺索引这2个问题，本质都是「选型或改模型时没有先问限制」。让AI在动手前列出方案的边界与限制，可以提前避开这类问题
调度智能体独立复验	自报通过不等于真通过。测试全绿也可能是断言没有执行。要由调度智能体独立复验，确认断言真实执行、结果真实可信
假绿防治	测试环境缺少依赖或凭据时，宁可显式失败，也不能静默跳过。跳过会制造「全绿」的假象，让问题被长期掩盖
检查清单持续补项	「建索引前先备份」「模型变更检查索引」「集成测试真实执行断言」这些条目，都是遇到问题后补进清单的。清单随实战不断生长

10.5.4 成果展示

• 优先级排序改为「手动切Tab」：在bug/建议分区新增一个「优先级」Tab，用户手动点它才按优先级排序；点「最新」「热门」「精华」「推荐」则按各自原有规则排序。也就是说，优先级不再接管整个分区，而是变成用户可选的排序方式。这是4轮纠偏后的最终产物。
• 独立复验机制落地：此后每次代码智能体自报「通过」，都由调度智能体独立复验一遍，确认断言真实执行。这是假绿问题沉淀下来的最重要资产。
• 问题知识库补项：集成测试必须真实执行断言、禁止静默跳过，环境无凭据时宁可显式失败。这条经验已写进问题知识库，供后续同类任务直接复用。

10.5.5 总结

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

flowchart TB subgraph 行1[问题一：优先级排序4轮纠偏] direction LR A[用户提出<br/>按优先级排序] --> B[客户端排序方案] --> B2[翻页排序打乱<br/>发起子fix] --> C[服务端排序方案] end subgraph 行2[ ] direction LR C2[部署后排序仍错] --> D[归因一<br/>字符串按编码序] --> E[改数值字段] --> F[查询返回空结果] end subgraph 行3[ ] direction LR G[归因二<br/>缺复合索引] --> H[建立复合索引] --> I[改为可选的<br/>「优先级」Tab] end subgraph 行4[问题二：集成测试15/15假绿（另一独立事件）] direction LR J[全量复验<br/>15/15全绿] --> K[空实现试探<br/>仍全绿] --> L[归因window<br/>未定义<br/>断言被跳过] --> M[改用内存mock<br/>断言真实执行] --> N[调度智能体<br/>独立复验<br/>并固化机制] end C --> C2 F --> G

• 经验总结：真实的项目比顺利的功能更有教学价值。优先级排序与假绿这2个问题，逼出了2条贯穿全章的铁律：动手前先确认要解决的问题；对代码智能体的自报结果要由调度智能体独立复验。前者防止「高效地做错事」，后者防止「被假绿欺骗」。

10.6 本文小结

本文用一个真实的论坛案例，走完了「从一句话需求到生产上线再持续迭代」的完整生命周期。回头看，我们学到的不只是「怎么做论坛」，而是3句可以带走的方法论。

本文讲解了哪些知识点

本文围绕这个真实论坛项目，讲解了以下知识点：如何用AI做需求分析与功能拆解、如何借助AI做技术选型与数据建模、Issue驱动开发的完整工作流（需求、拆解、Brief、智能体执行、BDD验证、E2E验证、M阶段手动测试、R阶段反思、S阶段保存、沉淀）、部署上线的验证与检查清单、本地与生产数据隔离、部署后证据验收、持续改进中的优先级排序4轮纠偏与集成测试假绿识别，以及子fix委派、调度智能体独立复验与反思沉淀。这些方法不依赖具体项目，可以迁移到任意软件项目。

3句方法论金句

（1）「AI是发动机，方向盘在驾驶员手里。」 AI负责分析、列对比、写代码，但需求边界、技术选型、产品判断这些决策，始终由用户来做。

（2）「智能体自报通过，不等于真通过。」 测试全绿可能是断言没执行，AI说「完成」可能是口头承诺。要独立复验，主动找能推翻「已完成」的证据。

（3）「从写代码变成了判断代码。」 角色转型了：不再亲手写代码，而是判断AI产出的代码是否合格、方案是否合理、结果是否可信。

核心工作流回顾

需求 → 拆解 → Brief → 智能体执行 → BDD验证 → E2E验证 → M阶段手动测试 → R阶段反思 → S阶段保存 → 沉淀。这条链路里，前3步（需求、拆解、Brief）是用户和AI对齐的关键，中间3步（执行、BDD、E2E）是AI的强项，最后4步（M阶段、R阶段、S阶段、沉淀）是用户和AI一起补漏、沉淀经验。

10.7 课后练习

完成一次完整的feat skill流程：选一个与论坛类似、但足够简单的小项目（例如留言板、待办清单、个人便签、班级通讯录、读书打卡等），调用feat skill，完整走一遍「头脑风暴 → 方案与Specs → 执行 → BDD/E2E验证 → M阶段手动测试 → R阶段反思 → S阶段保存」的流程。要求：① 记录头脑风暴问答，以及最终的功能范围（P0/P1清单 + 「MVP外不做」清单）；② 让AI产出方案文档和Specs，并检查Specs内部有没有自相矛盾之处；③ 用BDD/E2E/M阶段3层证据验收，记录至少一个遇到的问题及其归因过程。