用 Codex 从模糊想法到可部署 MVP：一套实战工作流
从问题验证到部署上线：用客户反馈箱案例，拆解 Codex、Skill、MCP、设计工具与技术架构如何协作。
做 MVP 最容易犯的错，是把“最小可行产品”误解成“功能少一点的完整产品”。结果往往是：用户还没出现，后台、通知、深色模式和会员体系已经排队上线。
更有效的方式，是把 Codex 当成一位速度很快、但需要清晰边界的研发搭档：你负责判断什么值得做、什么算完成；它负责理解项目、拆解任务、实现功能并暴露遗漏。
可部署的 MVP，不是功能看起来像产品，而是你能把链接发给第一个用户，并知道他为什么会用、如何使用、出了问题去哪里看。
先把工具放在正确的位置
Skill 是可复用的方法，MCP 连接外部信息与系统，设计工具负责把需求变成流程和界面，框架与架构才负责承载产品。它们不是一套必须集齐的装备；问题还没验证时，先装数据库和消息队列，只会让焦虑更有技术含量。
阶段 | 核心交付物 | Skill / Codex | MCP、设计与技术示例 |
|---|---|---|---|
发现问题 | 问题卡与访谈摘要 | 需求澄清、调研摘要 | Notion MCP、浏览器连接器、FigJam |
验证需求 | 表单数据与用户证据 | 数据归纳、假设检验 | Notion / Sheets MCP、Figma / Stitch 原型 |
定义 MVP | 核心路径、验收条件、非目标 | 产品需求卡 | FigJam 用户故事地图 |
实现功能 | 一条可运行的业务链路 | nextjs-best-practices、domain-modeling | Next.js、NestJS、PostgreSQL、Context7 |
测试上线 | 验证记录、预览链接、回滚方案 | code-review、vitest、diagnosing-bugs | GitHub、Sentry、Vercel / Docker |
1. 发现问题：先确认它真的是问题
以“团队客户反馈箱”为例。别急着说“做个反馈系统”，先问目标用户：他们现在怎么记录客户问题？最痛的是遗漏、重复，还是无法确认有没有人处理？
交付物：一页问题卡，写清用户、场景、现有替代方案、损失与待验证假设。
工具：用调研摘要 Skill 让 Codex 整理访谈；访谈记录在 Notion 时连接 Notion MCP；用 FigJam 画出现有工作流；界面方向可以先用 Figma 或 Stitch 快速探索。
技术选择：暂时不需要。原型、表单甚至人工流程都比一套未验证的服务端更诚实。
2. 验证需求：先验证，再自动化
先用表单、表格或可点击原型模拟流程，观察用户会不会提交、提交什么、是否需要查看处理状态。验证标准不是“用户觉得不错”，而是有人完成了关键动作，并提出了真实的下一步需求。
当信号足够明确，再把第一版压缩成一条路径：已登录成员进入 /feedback，填写客户名称、问题描述和优先级；提交后在自己的列表中看到它，刷新页面后数据仍存在。
同时写下非目标：不做搜索、评论、通知、附件和后台管理。MVP 的价值不在于功能少，而在于它有一条完整、可验收、可交给用户的路径。
3. 技术决策：选择最短的交付路径
个人或极小团队、追求速度时，可以用 Next.js App Router + Supabase。已有前后端分离项目时，使用 Next.js App Router + NestJS + PostgreSQL 更容易保持业务边界清楚。
Next.js：页面渲染、SEO 与表单交互。
NestJS：鉴权、反馈业务规则与 API。
PostgreSQL：保存反馈记录。
架构采用模块化单体即可：前端按 feedback 业务域组织，后端建立 FeedbackModule，数据库先只保留满足当前流程的表。不要为了“未来可能一千万用户”先拆微服务；未来的用户还没欠你这份复杂度。
4. 让 Codex 先读项目，再改一条链路
第一轮不要让 Codex 直接改代码。先让它阅读项目指引文件，定位认证与数据访问方式，说明影响范围，给出实施计划、风险和验证方式。
目标：为已登录成员实现 /feedback 页面，可创建并查看自己的反馈。
范围：复用现有认证、异常处理和数据访问方式；不修改登录；不做搜索、评论、通知、附件和后台管理。
验收：未登录不可访问；空描述不能提交；提交后列表立即可见；刷新后数据仍存在。
完成后：列出修改文件、关键数据流、测试命令与已知限制。项目指引文件适合保存目录约定、构建命令和评审要求；Skill 适合封装重复流程；MCP 适合连接 Figma、GitHub、Notion 等系统。分工清楚，Codex 才不会把每一次协作都当成考古现场。
5. 理解与测试：让每次改动都可解释
先看数据从哪里进来、保存到哪里，身份在哪里验证。
用 code-review 检查改动范围；用 vitest 或 frontend-testing-debugging 验证核心流程。
至少覆盖空描述、未登录、提交成功与刷新后仍可见四个场景。
6. 部署上线：把真实体验当作最后一轮测试
部署前检查环境变量、数据库迁移、生产构建、真实账号流程、日志和回滚方案。
首版优先使用托管部署，把时间留给用户，而不是服务器。GitHub、Sentry、Vercel 等已授权 MCP 可以分别帮助查看改动、错误和部署状态。上线后先看用户有没有完成核心动作，再决定要不要做“标签体系 2.0”。
结语
好工作流的标准，不是装了多少 Skill、连了多少 MCP，而是每个工具都让下一步更清楚：问题更真实、范围更小、改动更可控、上线更有底气。