夜雨聆风Codex 可以帮你写代码，但不能替你决定第一版到底要解决什么问题。
前面四篇，我们做了准备。
我们知道了软件不只是页面，也知道了产品、设计、前端、后端、测试、运维分别在关心什么，还知道了 Codex 不是普通聊天工具。
现在终于进入实战。
我们的起点是一句话：
我想做个待办 App。
这句话很自然。
但对 Codex 来说，它太模糊了。
什么人用？什么时候用？第一版要哪些功能？哪些功能先不做？怎样算完成？
这些问题不说清楚，Codex 也能开始写。
但它会替你做很多默认选择。
而默认选择，不一定是你真正想要的。
需求分析不是写大文档
很多小白听到“需求分析”，会以为要写几十页 PRD。
不用。
对我们的个人待办应用来说，需求分析先回答五个问题就够了：
• 谁用？ • 在什么场景用？ • 第一版必须有什么？ • 哪些以后再说？ • 怎样算完成？
这五个问题答清楚，就已经比“帮我做个待办 App”强很多。
先说谁用、什么时候用
我们先给这个应用起个临时名字：
小事清单。
一句话描述：
一个能在电脑和手机上同步使用的个人待办事项应用，帮助用户记录、安排、完成和复盘每天的小事。
目标用户可以先写成三类：
• 上班族：记录工作和生活待办。 • 学生：记录课程、作业、考试准备。 • 自由职业者：管理多个小项目的任务。
使用场景也要具体：
• 在电脑上整理今天的任务。 • 在手机上查看临时事项。 • 完成一件事后打勾。 • 晚上回顾今天完成了什么。
这些描述看起来简单，但很有用。
它们会影响后面的功能选择。
如果主要在电脑上整理，就要重视列表效率。
如果经常在手机上打勾，就要重视移动端操作。
如果想复盘，就不能让已完成任务直接消失。
把功能分成三类
新手最容易犯的错误，是第一版什么都想要。
提醒、日历、团队协作、AI 自动规划、番茄钟、统计报表、应用商店上架。
听起来都不错。
但第一版太大，很容易做不完，也很难验收。
所以我们把功能分成三类。
这张表非常重要。
它不是限制想象力。
它是在保护第一版。
第一版的目标不是“什么都有”。
第一版的目标是：
能记录、能保存、能完成、能在电脑和手机上看到同一份数据。
用用户故事写需求
接下来，把功能写成用户能理解的句子。
可以用一个简单模板：
作为一个[用户]，我希望[完成动作]，这样我可以[获得价值]。
例如：
作为一个上班族，我希望在电脑上快速新增任务，这样我可以把临时想到的事情记下来。
作为一个手机用户，我希望在手机上标记完成，这样我可以随时清理待办。
作为一个经常忘事的人，我希望任务有截止时间，这样我可以优先处理快到期的事情。
作为一个只给自己用的用户，我希望我的待办不会和别人混在一起，这样我的数据是安全的。
这些句子不复杂。
但它们会让 Codex 更容易理解功能背后的目的。
验收标准：怎样算完成
需求不能只写“支持新增任务”。
还要写怎样算完成。
比如新增任务的验收标准可以是：
• 输入标题后点击添加，列表中出现新任务。 • 标题为空时不能添加，并提示原因。 • 添加后刷新页面，任务仍然存在。 • 在手机打开同一账号，也能看到这条任务。
标记完成的验收标准可以是：
• 点击勾选后，任务状态变为已完成。 • 已完成任务能在筛选中看到。 • 刷新后完成状态仍然保留。 • 在另一台设备上也能看到完成状态。
验收标准的作用是：
不让“看起来做了”冒充“真的完成了”。
给 Codex 的需求分析提示词
现在，你可以把需求交给 Codex。
但不要让它立刻写代码。
可以这样说：
我想做一个个人待办应用，临时命名为“小事清单”。
目标用户是上班族、学生和自由职业者。
第一版目标：能新增、查看、完成、编辑、删除、筛选、搜索待办，并支持电脑和手机看到同一份数据。
请先不要写代码。
请先帮我整理一份小白可读的需求文档，包括：
1. 用户和使用场景
2. 必须有 / 以后再说 / 明确不做
3. 用户故事
4. 每个核心功能的验收标准
5. 你认为还需要向我确认的问题注意最后一句：
你认为还需要向我确认的问题。
这很关键。
好的需求不是你一次说完。
而是让 Codex 先帮你找出不清楚的地方，再继续补。
结尾：先说清楚，再动手
需求分析不是流程表演。
它是在减少后面返工。
你不需要一开始写专业文档。
但你至少要说清楚：
• 谁用。 • 什么时候用。 • 第一版做什么。 • 什么先不做。 • 怎样算完成。
当这些问题清楚以后，Codex 才不容易把你的想法做成另一个东西。
下一篇，我们继续往前走：
不会设计，怎么让 Codex 帮我先做出能讨论的界面？