Codex 产品原型能不能从一句话开始？我用一个登录页做了次完整实验：从 PRD、可交互页面，到自动测试和真实浏览器验收，都交给 Codex 一步步完成。

这是我发给 Codex 的第一句话。

我想要准备一个登录的页面和登录的 PRD。

一开始，我准备直接去 GitHub 找一个现成登录页，再补一份 PRD。很快我发现，这个顺序有问题：页面已经带着既定的业务规则，后写的 PRD 只能去解释已有实现，两者很难完全对应。

于是我调整了任务：先让 Codex 明确需求、生成 PRD，再按照确认后的 PRD 实现原型。接下来的过程也按这个顺序展开——收敛范围、固定数据、实现交互，最后用自动测试和真实浏览器验收。

一、先让过程可以检查和回退

方向确定后，我先约定工作方式：

一步一步来，而且这些文件由你生成和创建。

我把本地文件夹交给 Codex，并允许它创建 Git 仓库。这样做是因为后面需要比较 PRD 删减前后、页面修改前后以及测试结果。如果内容只留在聊天窗口里，就无法确认哪一版需求对应哪一版原型。

Codex 随后建立执行计划，将 PRD 和过程文档放进 docs/，将原型与验证脚本放进 web/，并为关键阶段保留 Git 提交。目标、文件和顺序确定以后，后续对话可以很短，产品经理也能在每一步结束时检查结果。

二、第一版 PRD，先做减法

Codex 生成的第一版 PRD 包含很多常见登录场景。我先给出方向：

检查这个 PRD，砍掉很多余的内容。

第一轮删减后，账户状态和异常处理仍然超出这次演示的目标。我继续明确：

账户锁定、账户停用、网络异常去掉。

这些功能适合生产系统，却会增加账号数据、错误分支和 Mock 规则。当前演示只需要稳定呈现登录成功、密码错误和邮箱不存在三种结果。

第三次减法针对需求编号：

REQ-01，就直接改成 01 即可，为什么要 REQ？

文档中只有一种需求类型，REQ 没有增加识别信息。Codex 随后将编号统一为 01 到 08，并同步更新相关检查。

几轮删减后，PRD 的边界变得清楚：

项目	最终决定
平台	只做桌面端
登录方式	只做邮箱和密码
登录结果	成功、密码错误、邮箱不存在
找回密码	只实现入口，不实现邮件流程
后端	使用本地 Mock，不连接真实数据库
不包含	注册、验证码、第三方登录、二次认证和生产安全方案

这三次反馈分别删掉了内容、场景和形式上的冗余。判断依据始终围绕三个问题：它是否服务演示目标，用户能否观察和验收，它会不会引入新的外部依赖。

三、为演示限定边界

PRD 精简后，我需要决定原型做到什么程度：

首先需要有个可交互登录界面。

PRD 已经规定了用户行为，原型还需要把输入、中间状态和结果真实呈现出来。可交互页面让这些需求变得可以操作和验收。

我随后确认只做桌面端，并将验收视口固定为 1440×900。移动端适配会增加布局状态和验收工作，对这次实验没有额外帮助。

为了让每次演示得到相同结果，Codex 在 PRD 中固定了三组 Mock 数据：

场景	邮箱	密码	结果
正常登录	active@example.com	Demo123!	登录成功
密码错误	active@example.com	Wrong123!	邮箱或密码错误
邮箱不存在	unknown@example.com	Demo123!	邮箱或密码错误

固定数据让 PRD、原型、自动测试和浏览器演示共享同一套事实，每个状态都能通过明确输入重复触发。

四、让关键需求真正跑起来

在 8 条需求中，需求 06 最能体现页面如何从静态界面变成可交互原型。它要求用户可以点击按钮或按 Enter 提交；登录期间显示“登录中…”、禁用表单控件，并阻止重复请求。

我重点检查这条需求，因为它同时包含触发条件、中间状态、限制条件和恢复路径。原型需要覆盖点击登录、Enter 提交、Loading、控件禁用、防重复提交，以及失败后的再次尝试。

范围、终端和演示数据都确认后，Codex 根据 PRD 完成了可交互原型，并为输入校验、会话状态和页面交互补充自动测试。

根据最终 PRD 完成的桌面端登录原型。

产品经理在这一阶段需要检查的，是每个动作从哪里开始，成功和失败后进入哪里，以及用户如何恢复到可以继续操作的状态。

五、把验收放进真实浏览器

单元测试和 PRD 检查通过后，我继续要求：

可以，下一步真实用浏览器在本地打开。

真实浏览器可以继续暴露点击区域、遮挡、滚动、布局和控制台错误。这一步确实发现了组件测试遗漏的问题：“记住我”的自定义方框挡住了原生复选框，页面状态看起来正确，用户却无法完成点击。

Codex 扩大了原生复选框的命中区域，并让装饰层不再接收鼠标事件。这个问题区分了两层证据：组件状态正确，说明代码逻辑成立；用户在浏览器中点得到，说明交互真正成立。

最终，原型通过了 16 条单元与组件测试、6 条 PRD 检查和 6 条 Chromium 浏览器流程。浏览器中还检查了桌面布局、字段错误、登录中、凭证错误、成功跳转、状态恢复和退出。

六、一句模糊反馈带来的返工

功能验收完成后，我开始删减页面上的演示信息：

“安全登录”“服务正常”“01 / AUTHENTICATION”“09:42”“DEMO”“演示账号 active@example.com · 密码 Demo123!”这些文字都去掉，登录的绿色浮动都去掉。

这些辅助标签会分散用户对登录表单的注意力，登录按钮下面的绿色错位阴影也显得过重。问题出在“绿色浮动都去掉”：页面里同时存在按钮阴影、左侧绿色协作卡片和轨迹，Codex 按照字面范围把它们全部删除了。

我看到结果后马上纠正：

左侧绿色浮动卡片、轨迹不需要删除啊。

Codex 随后恢复左侧卡片和轨迹，继续保留辅助文字和按钮阴影的删除结果。这次返工提醒我，视觉反馈需要同时写清四件事：

• 删除什么。
• 保留什么。
• 哪些内容不能改变。
• 用什么结果验收。

“绿色浮动”描述了外观，却没有指向唯一对象。产品经理需要明确视觉修改的边界，Codex 才能稳定执行。

最后，一套可以直接复用的工作流

1. 定义任务：写清使用场景、交付物和工作方式。
2. 建立项目：让 Codex 创建文件，并用 Git 保存阶段结果。
3. 生成 PRD：先形成初稿，再由产品经理检查。
4. 主动做减法：删除不服务当前目标的功能。
5. 固定数据：让演示、实现和验证共享同一套事实。
6. 梳理状态：明确触发条件、结果和恢复路径。
7. 要求证据：运行测试，并在真实浏览器中验收。
8. 收敛视觉：同时说明删除、保留、不改和验收标准。

结语

这次实践中，真正有价值的提示都对应一个明确决策：改变任务方向、收缩 PRD、限定演示范围、要求浏览器证据，或者纠正视觉边界。

产品经理负责给出这些判断，Codex 负责把判断落实为文件、代码、测试和可见结果。沿着这条路径，需求、PRD、原型和验证结果才能使用同一套事实。