用 Codex 写需求文档,从会议笔记到研发后的更新

做一个新产品，或者给现有产品加功能，我们通常要先了解客户需要什么，再确定方案、写需求文档，交给研发实现。今天这篇，我们来聊聊产品研发中的这段工作，怎样用 Codex 从头串起来。

会开完了，客户也聊了几轮，笔记里已经有不少想法。真到写需求文档时，我们还是要重新想一遍：为什么做、这次做多少、哪些规则已经定了？

等研发做完，又多了一件事：产品变了，文档还停在上一版。

我们可以从会议和客户反馈中整理需求，写出能评审的文档，再根据研发后的代码核对和补充，让文档跟上产品。

我们也可以借这个过程，试着建立一种更适合 AI 时代的产品研发方式：从调研、会议到需求分析、代码开发，让 AI 带着持续积累的背景参与每一步。我们判断需求的价值与取舍，AI 整理、分析、起草和实现，再把新的发现与确认结果留下来，供下一步继续使用。

这也是我们理解的“AI 原生”研发：让资料、决策、文档和代码形成一条能持续衔接的工作流。需求文档就在其中，帮助人和 AI 共享理解，把产品一步步做出来。

先把材料放到一起，让 Codex 知道我们在做什么

我们可以准备一个文件夹，放会议笔记、客户访谈记录、产品现状说明和已有的需求文档。材料不必提前整理得很漂亮，但要告诉 Codex 每份文件是什么，以及这次希望完成什么。

有团队固定的需求模板，也一起给它。先把格式要求交代清楚，后面就少一轮搬家。

像一位刚加入项目的同事，AI 也需要知道客户是谁、产品目前怎样、为什么考虑这个功能、有哪些限制。背景给得清楚，它分析和执行时就有更多依据。资料陆续增加，我们也要告诉它新增了什么、哪些决定已经确认、现在以哪个版本为准。

这套资料可以用 Markdown 保存：有清楚的标题、规则、状态和来源链接，关键内容可以直接读取。再用一份项目说明标出会议记录、客户调研、需求文档和代码的位置。团队需要 Word 或 PDF 时可以另外输出，但要明确哪份内容是有效版本。换了对话，也可以从这些文件接着做，不用赌 AI 还记得之前聊过什么。

比如，我们用一个虚构的团队任务工具来演示，准备增加到期提醒。可以这样开工：

“我们想解决任务到期容易被漏看的问题。这个文件夹里有会议笔记、客户访谈记录和当前页面说明。请先实际阅读材料，整理用户问题、已有决定、候选方案和待确认事项，再按我们的模板写需求文档。输出放到需求文档文件夹，保留原材料。”

这时先看 Codex 怎样理解材料，尤其是它有没有把“我们可以考虑”变成“我们已经决定”。

会上提了邮件提醒，可能只是一个想法；客户说经常忘记截止时间，也没有直接回答提醒应该出现在哪里。把这两句话连起来有价值，具体采用哪种方案，还要往下看。

会议纪要里找线索，客户调研里问清问题

前一篇我们整理了会议纪要，已经把讨论、决定和待办分开。这次可以接着让 Codex 提取需求线索：谁遇到了什么问题、在什么情况下发生、会上明确了哪些限制、还有什么需要去问客户。

如果客户调研还没做，我们可以先让它准备提纲。

“请围绕任务到期被漏看的问题，帮我准备一份简短访谈提纲。先了解客户最近一次遇到这种情况的经历、当时怎么处理、造成什么影响，再了解他们期待怎样改善。”

这里最有用的问题，往往是“上一次具体发生了什么”。

只问“要不要加个提醒”，我们很容易收获一排“可以啊”。继续问下去，才可能发现有人希望每天打开页面就看到待处理任务，有人希望离开产品后还能收到消息，也有人已经有自己的日历提醒。

这些差别会影响方案。

访谈完成后，把真实记录交给 Codex，让它按场景、问题、现有做法、期待结果和来源整理。同一个客户的反馈被转发了三次，不能算三位客户；几份记录里出现的意见，也要保留各自的适用条件。

比如可以这样说：

“请把这些访谈记录与会议纪要放在一起，按用户问题整理需求。每项保留对应来源，区分客户反馈、我们的判断和候选方案。意见冲突的地方列出来，需要补问的问题也一起列。”

我们拿到的就不只是一个功能清单，而是能回头找到依据的需求清单。

从客户诉求里找共性，再判断值不值得做

客户说“每天给我发一封提醒邮件”，是一个具体诉求。我们还要往下理解：他在什么情况下漏掉任务，希望怎样及时发现和处理？

让 Codex 把原话、使用场景、困难和期待结果整理出来，就能继续分析哪些问题是其他客户也可能遇到的，哪些只在特定条件下成立。比如，“及时识别快到期的工作”可以作为待验证的共性需求，邮件是其中一种解决方式；有人可能更适合页面提醒，也有人希望沿用已有工具。

这种提炼需要证据。只有一位客户提出时，就先保留为假设，继续验证。某位重要客户的专属需求也可能值得做，但我们要知道它的价值和维护成本，不能直接说成所有客户都需要。

接下来，让 Codex 帮我们评估：问题有多频繁、影响多大、能覆盖哪些客户、市场上有什么替代方案、与产品方向是否一致，以及大致涉及哪些开发和维护投入。市场资料也要告诉它来源和时间，缺少的信息列出来，需要调查的再去查。

可以这样说：

“请结合客户记录、产品背景和市场资料，分析这项需求的用户价值、覆盖范围、替代方案、差异化机会与投入风险。给出现在做、先验证、后做或不做的建议，说明依据和缺口，由我判断取舍。”

AI 可以把材料、比较和建议写清楚，我们再判断证据是否站得住、收益是否值得投入。这样确定的范围，才有理由带进需求文档。

先确定这次做什么，再写需求文档

有了需求清单，接下来需要我们做取舍。

继续用刚才的演示：本期先在页面内展示即将到期的任务，外部通知暂时放到后续。这样一来，Codex 写文档时就有了明确范围，不会把会上所有想法都装进首版。

范围确定后，还要把影响行为的规则说清楚。

谁能看到哪些任务？“未来七天”包括今天吗？已经完成的任务还显示吗？没有截止日期怎么办？逾期任务放在哪里？

Codex 可以根据材料找出这些缺口，每次问我们几项。已经提供过的信息，就不用从头再回答一遍；暂时没定的，也可以保留在待确认清单里，先推进其他部分。

我们确认后，可以这样交代：

“本期先做页面内的到期任务展示，邮件通知放到后续。请按刚才确认的范围和规则写需求文档，包含背景、用户场景、功能流程、业务规则、异常情况和验收标准。没有依据的指标、工期和责任人保留待确认。”

这一步要看的，是文档里的内容有没有接上。

例如，规则写着“只展示本人负责、尚未完成的任务”，验收里就应该能检查这两个条件：别人的任务会不会出现，任务完成后会不会从列表中移除。

给关键需求、规则和验收项编个号，也方便后面讨论。评审时说“BR-02 需要调整”，比翻半天找“第二页中间那句”轻松不少。

这些编号和明确的规则，也方便后面让 AI 读取文档、实现功能和核对结果。把“什么时候、什么条件、应该发生什么”写清楚，人评审时更容易理解，AI 开发时也少一层猜测。

评审和研发中改了什么，随手带回文档

当代码开发也交给 Codex 时，我们要让它先读取有效的需求文档、决策记录和技术说明，再结合现有代码实现功能。前面为什么做、为什么暂时不做某些内容，已经有资料可查，就不用换到开发阶段再重新讲一遍。

比如可以说：“请先读项目说明和链接的有效 PRD，按已确认范围实现到期任务展示，验证对应验收项。遇到会改变产品行为的问题，给我分析和建议；完成后记录改动、实际测试和未完成项。”

初稿出来，我们先按实际场景走一遍，再交给协作同事评审。

Codex 可以帮忙找前后矛盾、漏掉的异常和没有对应验收的规则。真正的方案取舍、实现可行性和时间安排，仍然需要参与的人确认。

评审意见不要只留在聊天窗口里。

“这次确认把【规则】改成【新规则】，请同步更新相关流程、功能描述和验收标准，记录修改原因。其他还没确认的意见继续保留。”

研发中新增的限制、调整过的范围，也按这个方式补回去。需要时保留上一版文档，方便之后知道这条规则为什么变了。

如果一处修改会影响其他地方，就让 Codex 一起检查。只改了规则表，流程里还是旧写法，评审时我们又得重新解释一遍。

研发完成后，让 Codex 对着代码再读一遍

开发过程中总会出现一些更具体的细节：某个按钮在哪些状态下可用，某个字段怎样处理，失败之后页面显示什么。

这时候，我们可以把需求文档和对应版本的代码一起交给 Codex，让它核对两边。

“项目代码在这个目录，需求基线是这份 PRD。请先了解项目结构，再按需求追踪相关页面、接口、数据处理、权限、异常和测试。整理一份需求与实现对照表，标出代码位置、发现的差异和需要验证的地方。先不要改代码。”

小项目可以阅读全部自有源码；项目大了，就按功能和模块分批读，保留已读范围。我们要知道它看过什么，还有什么没有覆盖。

代码阅读之后，适合跑的现有测试可以继续跑；涉及账号、外部服务或环境配置的部分，也要说明验证条件。读到代码、测试通过和实际页面跑通，是不同层次的证据。

这轮结果里，既可能有可以补回文档的细节，也可能有实现与原需求的差异。

比如，文档约定未来七天的到期任务，代码却只筛选未来三天。我们就需要核对：这是研发中已经确认过的调整，还是实现遗漏？

如果已经确认改成三天，就更新规则、流程和验收，写清变更依据。如果原需求仍然有效，就保留七天要求，把三天实现列为待处理差异。

这样更新后的文档，既能说清我们要做什么，也能说明目前做到了哪里。代码中与需求一致、但文档漏写的细节，可以补回相关章节；没实现或还没验证的部分，则保留状态，继续跟进。

把这套方法留下来，下次从新材料开始

从会议、调研到文档，再到研发后的核对，这套工作很适合整理成 Skill。

我们可以把材料怎么读、缺项怎么问、需求怎样关联来源、规则怎样对应验收、代码差异怎样处理写进去。下一次有新需求，就沿用这套方法，换上新的材料和约束。

调用时可以简单说：

“用这个需求文档 Skill，读取文件夹里的会议和客户调研材料，先整理需求，再生成 PRD。”

研发后再说：

“用同一个 Skill，核对这版代码与 PRD，补充实现细节，列出尚未确认的差异。”

Skill 保存的是我们认可的做事方法，每个项目的事实和决定仍然来自当次材料。我们也可以只进入其中一步，比如已经有需求文档，就直接做代码核对，不必再从会议笔记开始。

这种更原生于 AI 的产品研发流程，需要我们从调研和会议开始就积累它能读懂的资料，让价值判断、需求、代码和验证结果持续衔接。文档在其中帮助人和 AI 共享背景、接续工作，下一步就能沿着已有信息往前做。

需求文档会随着讨论和产品一起变化。把材料来源、确认记录和实现差异留清楚，下次再打开它，我们就能接着做，而不是重新回忆一遍。

对产品经理来说，借助 AI，我们可以把想法往实现推进一步，做出可讨论的原型，检查规则有没有真正落地。对开发者来说，也可以沿着代码往前多看一步，读懂客户为什么需要这个功能，参与方案和价值的判断。

当两边都能带着背景往前走，协作就多了一层共同理解。我们各有所长，也可以借助 AI 跨过原先不熟悉的环节，更完整地参与一个产品的形成。

岗位各有所长，理解可以向前一步。

AI 帮我们跨过的是动手的门槛，我们要把握的是产品的方向。