老板只说列表更好用时，先让 Codex 问出验收标准

教程定位

这篇教程解决什么问题

临时需求最容易让开发者难受的地方，不是它短，而是它短到没有边界。老板在群里说一句“把客户列表做得更好用”，产品还没来得及补说明，销售同事已经开始催上线。你打开页面，能想到很多可能的改法：加搜索、加筛选、调整列宽、固定表头、支持批量操作、优化加载速度、把最近跟进时间放到前面、给重点客户加标记。每一个都像合理方向，但没有一个能证明这次就该做。

这时候不要马上让 Codex “帮我改一下列表体验”。如果开工前没有问清楚成功标准，AI 越能干，越可能把模糊需求推进到错误方向。你会得到一堆看似勤奋的改动：多了筛选器，换了表格样式，加了快捷入口，顺手重构了组件。可老板回来看一眼，可能只说一句：“我说的不是这个，我是想让销售一眼看到今天该跟进谁。”

这篇文章讲一个更稳的用法：当你只拿到一句原始需求时，先让 Codex 帮你把模糊诉求拆成澄清问题和初版验收标准。目标不是产出技术方案，也不是让它决定产品方向，而是把“更好用”翻译成可以确认的事实：谁觉得不好用，在哪个场景不好用，当前卡在哪里，哪些边界不能碰，什么结果算完成，什么结果不算完成。

最终你要拿到两份产物。第一份是需求澄清问题清单，按用户、场景、现状、边界、验收、优先级分组，能直接发给老板、产品或业务同事确认。第二份是初版验收标准，用可观察的行为描述这次改动是否达标。例如“销售在客户列表中能在 10 秒内找到今天需要跟进的客户，并看到客户名称、负责人、最近跟进时间和下一步动作”，这就比“列表更好用”更能指导下一步。

这里的重点是开工前问清楚。不要让 Codex 过早进入“我建议这样实现”的状态。它可以帮你整理上下文、生成问题、补充边界、写验收句子，但最终要由提出需求的人确认。开发者真正节省的时间，不是少写几行代码，而是少做一轮无效返工。

本文会用一个安全虚构的后台客户列表举例。场景是：老板只说“把列表做得更好用”，开发者手上有一句原始需求、当前页面截图的文字描述、已有功能说明和约束条件。我们会让 Codex 先问清楚用户、场景、边界和验收，再整理成可以发出去确认的材料。样例不会包含真实公司、真实客户、真实邮箱、真实手机号、密钥或内部系统信息。

使用场景

什么情况下最适合用这一套

你是一个经常接临时需求的开发者。工作里有很多需求不是从完整 PRD 开始，而是从一句话开始：“这个列表太难用了，优化一下”“导出能不能顺手一点”“搜索结果不太对，改一下”“审批页帮我做得清楚一点”。这些话通常来自老板、业务负责人、运营同事或客户成功团队。他们不是故意不说清楚，而是站在自己的语境里觉得问题已经很明显。

对开发者来说，真正困难的是你无法判断这句话背后的目标。以“把客户列表做得更好用”为例，它可能指至少六种不同问题。

第一种是找不到目标客户。销售每天打开列表，只想先处理今天需要跟进的客户，但页面默认按创建时间排序，新客户和老客户混在一起。此时更好用可能是“默认展示今日待跟进”。

第二种是信息不够。销售看到客户名称，却看不到负责人、客户等级、最近沟通记录和下一步动作。此时更好用可能是“关键列补齐，并把不常用列收起来”。

第三种是操作太慢。每次改客户状态都要进入详情页，改完再返回列表。此时更好用可能是“支持列表内快捷更新状态”。

第四种是筛选条件不符合业务。现在只能按地区筛选，但销售真正想按客户阶段、负责人、最近跟进时间筛选。此时更好用可能是“补充业务筛选项”。

第五种是性能问题。列表加载 8 秒，翻页卡顿，搜索输入后页面停住。此时更好用可能是“加载和搜索响应变快”。

第六种是管理视角不清楚。老板要看团队本周跟进情况，却只能看到单条客户记录。此时更好用可能是“增加团队维度的汇总信息”，而不只是列表本身。

如果你不先澄清，直接开工会很危险。你可能做了筛选器，但真实痛点是默认排序；你可能优化了样式，但真实痛点是加载速度；你可能加了批量操作，但老板真正想解决的是“销售今天不知道先跟谁”。做错方向以后，代码本身可能没问题，但需求仍然没有被解决。

Codex 在这里适合做一件事：把模糊话拆成一组必须回答的问题。它可以根据原始需求、截图描述、已有功能和约束，帮你想到那些容易漏掉的问题。例如谁是主要用户，是销售本人、销售主管，还是运营助理；使用时机是每天早上分配任务、跟进客户前，还是周会复盘；成功标准是找到客户更快、减少进入详情页次数，还是降低误操作；这次不能碰哪些范围，比如不能改数据库结构、不能改权限、不能改变导出字段。

这篇教程尤其适合这些时刻：

它不适合用来替代产品判断。Codex 不能凭空知道老板真正想要什么，也不能替业务负责人决定优先级。它的作用是把含糊的表达变成可确认的问题，把没有边界的诉求变成初版验收标准。人确认以后，再进入方案设计和开发。

1. 需求只有一句话，但你已经被期待开始排期。
2. 提需求的人很忙，不能开长会，但可以回答一组短问题。
3. 页面已经存在，问题不是从零建设，而是“更好用”“更清楚”“更顺手”。
4. 你手上有截图、现有功能说明和一些约束，但缺少验收标准。
5. 团队经常因为“理解不一致”返工，希望把开工前的确认动作固定下来。

材料准备

开始前先把材料和边界备齐

开始前先准备四类材料。材料不需要很多，但要有结构。你可以把它们放在同一个消息里，也可以整理成一个临时文档，再交给 Codex。

第一类是一句原始需求。不要把它美化成你理解后的版本，要保留原话。例如：“老板说客户列表不好用，能不能这周改一下。”原话能保留模糊程度，方便 Codex 判断哪些地方需要追问。如果你已经猜测了原因，也要单独标注为“我的猜测”，不要混进原始需求里。

第二类是当前页面截图的文字描述。Codex 未必能直接看到截图细节，即使能看到，也建议你转写关键元素。写清楚页面现在有什么：列表列名、筛选区、排序方式、按钮、分页、空状态、错误提示、权限差异、用户常用入口。不要包含真实客户名、真实手机号、真实邮箱或内部敏感数据。可以用 `示例客户 A`、`销售甲`、`客户等级：高` 这类占位信息。

第三类是已有功能说明。比如现在已经支持按客户名称搜索、按负责人筛选、分页、导出、查看详情、修改状态。已有功能越清楚，Codex 越不容易提出重复问题。你还可以注明哪些功能已经被验证可用，哪些功能虽然存在但业务同事不常用。

第四类是约束条件。约束比想法更重要。比如这周只能做小改动；不能改后端接口；不能新增复杂权限；不能改变导出字段；不能影响客服团队正在使用的列表；不能动移动端；不能引入新的付费组件；必须兼容现有浏览器；上线前只能做本地和预发验证。约束能帮助 Codex 把问题问在可执行范围内。

建议你在材料里明确本轮目标：

这个边界很关键。很多 AI 工具看到“列表不好用”，会立刻开始建议“增加筛选、固定表头、虚拟滚动、列配置、批量操作”。这些建议不一定错，但它们属于方案层。你现在还不知道问题是否是“筛选不够”。在没有验收标准前，方案越具体，越容易把团队带偏。

准备材料时可以用下面这张小卡片。它不需要完整，但至少能让 Codex 看到需求的来处和限制。

如果你有页面截图，可以在文字描述中补充“截图中可见的痛点”。例如“最近跟进时间列在屏幕右侧，需要横向滚动才能看到”“筛选项默认折叠”“客户阶段颜色区分不明显”。但不要把截图里真实姓名、电话、邮箱、客户合同金额等敏感内容原样输入。

• 只生成澄清问题和初版验收标准。
• 不写技术方案。
• 不设计数据库结构。
• 不估工期。
• 不直接改代码。
• 不替业务方做最终决定。

需求澄清材料包：

原始需求：
老板在周会上说：“客户列表现在不太好用，这周能不能改得顺手一点。”

我的已知背景：
- 使用者主要是销售和销售主管。
- 页面是后台的客户列表页。
- 最近有人反馈每天早上要花时间找今天该跟进的客户。
- 我不确定老板说的“更好用”是否就是这个问题。

当前页面描述：
- 顶部有客户名称搜索框、负责人筛选、客户阶段筛选。
- 列表列包括客户名称、负责人、客户阶段、创建时间、最近跟进时间、操作。
- 默认按创建时间倒序。
- 每页 20 条，有分页。
- 修改客户阶段需要进入详情页。

已有功能：
- 支持按名称搜索。
- 支持按负责人和客户阶段筛选。
- 支持导出当前筛选结果。
- 支持进入详情页查看跟进记录。

约束条件：
- 本周只能做一轮小改动。
- 暂时不能改客户详情页。
- 不新增权限模型。
- 不改变导出字段。
- 不接触真实客户数据。

本轮目标：
请帮我生成需求澄清问题清单和初版验收标准，不要给技术方案。

实操流程

按这套步骤把工作跑起来

第一步，把一句需求拆成“已知事实”和“未知问题”。

你可以先让 Codex 不做任何建议，只从材料中提取事实。例如事实可能是：页面是客户列表；使用者可能是销售和销售主管；已有搜索、负责人筛选、客户阶段筛选；默认按创建时间倒序；最近有人反馈每天早上要找今日待跟进客户；本周只能做小改动。未知问题则包括：老板说的不好用是否指找客户慢；主要服务销售还是主管；成功标准是更快找到客户、减少点击，还是提升列表可读性；是否需要支持移动端；这周的小改动范围有多小。

这一步的价值是防止你把猜测当事实。比如“最近有人反馈找今日待跟进客户慢”只是线索，不等于老板的真实目标。Codex 应该把它标成“可能相关线索”，而不是直接得出“应该增加今日待跟进筛选”。

第二步，让 Codex 按用户角色提问。

“列表更好用”对不同人含义不同。销售关心今天先跟进谁，主管关心团队是否漏跟，运营关心数据是否方便导出，客服可能关心客户状态是否准确。你要让 Codex 先问：这次优先服务谁？如果多个角色都有诉求，第一优先级是谁？

合格的问题应该具体，例如：

不要只问“用户是谁”。这个问题太大，别人容易回答“销售都要用”。要继续追问“哪个角色是本周必须改善的主要角色”。只有主要角色明确，验收标准才不会散。

第三步，让 Codex 按使用场景提问。

同一个列表在不同时间点承担不同任务。早上打开列表安排今天跟进，是一种场景；跟客户通话后更新状态，是另一种场景；主管周五检查团队进展，又是另一种场景。场景不清楚，需求就无法收敛。

你可以要求 Codex 把场景问题写成“时间、触发、目标、当前阻碍”的格式：

这些问题会把“体验不好”拉回真实工作流。不要问太抽象的“你觉得哪里不好”。业务同事常常会回答“整体都不顺”。更好的问法是“昨天你打开这个列表时，原本想完成什么，最后卡在哪一步”。

第四步，让 Codex 按边界和非目标提问。

临时需求必须问边界。否则一句“更好用”会自然膨胀成页面重做、接口改造、权限调整、移动端适配和报表建设。你要让 Codex 生成“本次不做什么”的问题。

边界问题可以包括：

边界不是消极限制，而是保护你不被模糊需求拖进无底洞。尤其当时间被限定为“这周”时，边界问题必须排在技术方案前面。

第五步，让 Codex 按验收口径提问。

验收标准要尽量可观察。不要停在“用户觉得更顺手”。可以追问：

对于临时需求，不一定要有严谨的量化指标，但至少要有行为标准。例如“销售打开客户列表后，能直接看到今天需要跟进的客户，并知道下一步动作”，就比“体验变好”更清楚。再进一步，可以写成“使用示例数据时，销售不进入详情页也能判断前 20 条客户中哪些今天需要跟进”。

第六步，让 Codex 把问题排序。

澄清问题不能一口气发 30 个。提需求的人通常没有时间写长答。你要让 Codex 把问题分成“必须回答”“建议回答”“可以后补”。

必须回答的问题通常包括：主要用户是谁；最重要的使用场景是什么；这次成功标准是什么；不能碰哪些范围；谁确认验收。没有这些答案，开工风险很高。

建议回答的问题包括：是否有样例数据；是否有最近反馈原话；是否有竞品或旧版本参考；是否需要考虑不同权限角色。

可以后补的问题包括：埋点指标、长期改版方向、个性化列配置、多端一致性、详细性能指标。这些可能重要，但不一定阻塞本周的小改动。

排序后的问题更容易被回应。你可以先发 6 到 8 个核心问题，而不是把所有想到的问题都扔出去。

第七步，让 Codex 起草初版验收标准。

验收标准不是等业务方回答完才可以写。你可以让 Codex 根据现有材料先写“待确认版”，并明确标注假设。这样业务方更容易改。比起问“你想要什么验收标准”，给对方一版草稿通常更快。

初版验收标准可以用这样的结构：

注意，这不是技术方案。它没有说要加什么组件、改什么接口、怎么排序、怎么缓存。它只描述完成后的可观察状态。技术方案要等验收标准确认后再做。

第八步，让 Codex 生成一段可以发给业务方的确认消息。

很多开发者卡在“问题整理好了，但不知道怎么问才不显得推脱”。你可以让 Codex 把问题写成礼貌、简短、可回复的消息。语气要像是在加速确认，而不是阻止需求。

例如：

“我先把这次‘客户列表更好用’理解成一个可验收的小目标，麻烦你确认一下：本周是否优先解决销售早上找今日待跟进客户的问题？如果是，我们先不动详情页和导出，只让销售在列表上直接看到今天该跟进谁、负责人、阶段、最近跟进时间和下一步动作。下面 6 个问题确认后我再进入方案。”

这种表达比“需求不清楚，无法开发”更容易推进。它把模糊需求变成了一个可确认的小目标，也给对方留下修改空间。

第九步，人工删减和补充问题。

Codex 生成的问题不一定都适合发出去。你要删掉那些对当前组织不必要、过于产品经理化或明显重复的问题。比如老板只给你 5 分钟确认，你就不要发 20 个开放问题。保留最关键的 6 到 8 个即可。

同时，你要补上组织内真实约束。比如“不能影响客服视图”可能是你知道的内部事实；“导出字段由财务月报依赖”可能是 Codex 不知道的限制；“本周上线窗口只有周四下午”也会影响范围。AI 负责提醒，人负责校准。

第十步，把确认结果再交给 Codex 整理。

业务方回答后，不要直接凭聊天印象开工。把回答贴回 Codex，让它更新验收标准，并列出仍然不清楚的问题。你可以要求它输出三段：已确认事项、仍待确认事项、可以进入方案设计的前提。

当“必须回答”的问题都得到回答，初版验收标准也被确认后，才进入技术方案。这样做看起来多了一步，其实减少了返工。你从一开始就在验证“要解决什么”，而不是先赌一个实现方向。

• 这次优化优先服务一线销售、销售主管，还是运营同事？
• 他们打开客户列表时最常见的任务是什么？
• 哪个任务现在最费时间，能举一个最近发生的例子吗？
• 如果只能改善一个角色的一件事，应该是哪一件？
• 用户通常在什么时候打开这个列表？
• 是被什么事情触发打开，例如早会前、客户来电后、主管检查进度时？
• 打开后他们想完成什么动作？
• 现在完成这个动作需要几步，哪一步最卡？
• 有没有一个具体例子说明“现在不好用”？
• 这周上线的范围是只改客户列表，还是可以影响详情页？
• 能否调整默认排序和默认筛选？
• 能否新增字段展示，还是只能调整现有字段顺序？
• 能否新增后端接口，还是只使用现有数据？
• 是否允许改变导出结果？
• 是否允许影响主管视图或客服视图？
• 哪些现有习惯不能被打断？
• 改完后，用户应该能更快完成哪一个任务？
• 这个任务从哪里开始，到哪里算完成？
• 是否有可以观察的指标，例如点击次数、查找时间、需要进入详情页的次数？
• 哪些信息必须在列表上直接看到？
• 哪些情况出现时，就说明本次没有解决问题？
• 谁来验收，验收时用哪组样例数据？
• 目标用户：一线销售。
• 使用场景：每天早上打开客户列表，找出今天需要跟进的客户。
• 前置条件：使用脱敏样例数据，包含不同负责人、客户阶段、最近跟进时间和下一步动作。
• 可观察结果：用户无需进入详情页，就能识别今天需要跟进的客户及其负责人、阶段、最近跟进时间、下一步动作。
• 边界：本次不改变导出字段，不改变客户详情页，不新增权限。
• 反向验收：如果仍需要逐条进入详情页才能判断是否该跟进，则本次不算完成。

输入示例

可以直接参考的输入材料

下面是一个安全虚构的输入样例。你可以把它改成自己的页面，但不要放真实客户信息、真实联系方式、密钥或内部隐私。

这个输入的重点是把“不要做什么”写清楚。你不是让 Codex 展示它多会做产品设计，而是让它帮你把开工前必须确认的东西问出来。

你是我的需求澄清助手。请不要给技术方案，也不要建议具体实现。
请根据下面材料，把一句模糊需求拆成澄清问题清单和初版验收标准。

原始需求：
老板说：“客户列表现在不太好用，这周能不能改得顺手一点。”

读者背景：
我是负责这个后台的开发者，经常接临时需求。现在还没有完整 PRD。

当前页面截图文字描述：
- 页面标题：客户列表。
- 顶部有客户名称搜索框、负责人筛选、客户阶段筛选、导出按钮。
- 表格列：客户名称、负责人、客户阶段、创建时间、最近跟进时间、操作。
- 默认按创建时间倒序。
- 每页 20 条。
- 最近跟进时间在靠右位置，小屏幕下需要横向滚动才能看到。
- 操作列只有“查看详情”。

已有功能：
- 支持按客户名称搜索。
- 支持按负责人筛选。
- 支持按客户阶段筛选。
- 支持导出当前筛选结果。
- 支持进入详情页查看跟进记录和修改客户阶段。

已知线索：
- 销售同事说每天早上要花时间找今天该跟进的客户。
- 主管有时会问为什么某些客户很久没人跟。
- 我不确定老板说的“不好用”是否指这两个问题。

约束条件：
- 本周只能做一轮小改动。
- 不能改客户详情页。
- 不新增权限模型。
- 不改变导出字段。
- 不接触真实客户数据。
- 不需要现在估工期。

请输出：
1. 已知事实和未知问题。
2. 按用户、场景、边界、验收分组的澄清问题。
3. 必须回答的 6 到 8 个问题。
4. 待确认版初版验收标准。
5. 一段可以发给老板确认的简短消息。

提示词

可复制使用的提示词

下面这段提示词可以直接复制。使用时，把方括号里的内容换成你的实际材料。注意继续使用脱敏样例，不要粘贴真实手机号、邮箱、客户名称、密钥或生产数据。

如果你使用的是 Codex 这类能读取本地代码和文件的工具，也要在提示词里加一句“本轮只读材料，不修改文件”。即使你后面会让它开发，也不要在同一轮里把澄清和开发混在一起。先确认问题，再设计方案，最后才改代码。

你是需求澄清助手，不是方案设计助手。

我的目标：
我收到了一句模糊需求，需要在开工前问清楚用户、场景、边界和验收标准。请只输出澄清问题清单和初版验收标准，不要给技术方案，不要建议具体实现，不要估工期，不要改代码。

原始需求：
[粘贴原话，例如：老板说“客户列表不好用，这周改得顺手一点”]

当前页面或功能描述：
[用文字描述截图中可见的页面结构、按钮、字段、列表列名、筛选项、排序方式、已有入口]

已有功能：
[列出现有功能，例如搜索、筛选、导出、详情页、状态修改]

已知线索：
[列出来自用户反馈、会议、聊天的线索。请标注这是线索，不要当成事实]

约束条件：
[列出本次不能碰的范围，例如不能改详情页、不能改导出字段、不能新增权限、只能做小改动]

请按下面结构输出：
1. 已知事实：只写材料里明确出现的内容。
2. 关键未知：列出如果不确认就会导致返工的问题。
3. 澄清问题清单：按用户、场景、现状阻碍、边界、验收、优先级分组。
4. 必须先问的 6 到 8 个问题：问题要短，方便对方直接回复。
5. 初版验收标准：用“目标用户、使用场景、前置条件、可观察结果、边界、反向验收”的格式写，并标注“待确认”。
6. 给需求提出人的确认消息：语气简短、协作、可回复。

输出要求：
- 不要进入技术方案。
- 不要写“建议增加某某功能”。
- 不要编造没有提供的事实。
- 如果只能推测，请明确写“待确认假设”。
- 验收标准必须描述用户完成了什么，而不是描述系统用了什么技术。

输出样例

AI 应该输出到什么程度

下面是一个合格输出的样子。它没有直接说“应该加一个今日跟进筛选”，而是先把问题和验收标准列出来。

这个输出有几个好处。它把事实和假设分开，把问题按主题分组，把最重要的问题挑出来，并且给了一版可改的验收标准。你可以直接复制“必须先问的 6 个问题”去确认，也可以把“待确认版初版验收标准”发给业务方改。

如果 AI 输出里已经出现“建议增加今日待跟进筛选”“建议加固定表头”“建议优化接口性能”，你要把它拉回来。可以追加一句：“先不要给方案，请把这些方案改写成需要确认的问题和验收标准。”例如把“增加今日待跟进筛选”改写为“用户是否需要在列表中优先看到今日待跟进客户，还是只需要更容易找到长期未跟进客户”。

一、已知事实

1. 原始需求是“客户列表不太好用，这周改得顺手一点”。
2. 当前页面是客户列表页，已有名称搜索、负责人筛选、客户阶段筛选和导出。
3. 表格列包含客户名称、负责人、客户阶段、创建时间、最近跟进时间、操作。
4. 默认排序是创建时间倒序。
5. 最近跟进时间在靠右位置，小屏幕下可能需要横向滚动才能看到。
6. 修改客户阶段需要进入详情页。
7. 已知线索包括销售早上找今日待跟进客户较费时间，主管关注长期未跟进客户。
8. 本周只能做一轮小改动，不能改详情页，不新增权限，不改变导出字段。

二、关键未知

1. 老板说的“不好用”是否主要指销售找今日待跟进客户困难。
2. 本周优先服务一线销售，还是销售主管。
3. 改完后希望用户完成的核心任务是什么。
4. 是否允许调整默认排序、默认筛选或列表列顺序。
5. 本次验收由谁确认，用什么样例数据确认。

三、澄清问题清单

用户：
1. 这次优化优先服务一线销售、销售主管，还是两者都要兼顾？
2. 如果只能先解决一个角色的问题，应该优先谁？

场景：
3. 用户通常在什么时间打开客户列表，是早上安排跟进、客户通话后更新，还是周会检查进度？
4. 能否举一个最近觉得“不好用”的具体例子：当时想完成什么，卡在哪一步？

现状阻碍：
5. 现在最浪费时间的是找不到客户、看不到关键信息、需要频繁进详情页，还是列表加载慢？
6. 当前已有搜索和筛选为什么没有解决问题，是条件不够、默认状态不对，还是信息位置不明显？

边界：
7. 本周是否只允许改客户列表页，不改详情页、导出字段和权限？
8. 是否允许调整列表默认排序、默认展示列或默认筛选条件？

验收：
9. 改完后，用户在列表页至少要直接看到哪些信息，才算能完成任务？
10. 什么情况出现时，说明这次仍然没有解决“不好用”？

四、必须先问的 6 个问题

1. 本周优先解决一线销售的问题，还是销售主管的问题？
2. 老板说的“不好用”，最接近下面哪类：找客户慢、信息不够、操作步骤多、加载慢、管理视角不清？
3. 有没有一个最近发生的具体例子，说明用户打开列表后卡在哪一步？
4. 本次是否可以调整默认排序、默认筛选或列顺序？
5. 本次明确不做哪些范围：详情页、导出字段、权限、移动端是否都不碰？
6. 谁来验收，验收时使用哪组脱敏样例数据？

五、待确认版初版验收标准

待确认假设：
本周优先解决一线销售每天早上在客户列表中找到今日待跟进客户的问题。

目标用户：
一线销售。

使用场景：
销售每天早上打开客户列表，判断今天应该先跟进哪些客户。

前置条件：
使用脱敏样例数据，包含不同负责人、客户阶段、最近跟进时间和下一步动作。

可观察结果：
销售在客户列表页不进入客户详情，也能识别今天需要跟进的客户，并看到客户名称、负责人、客户阶段、最近跟进时间和下一步动作。

边界：
本次不改变客户详情页，不改变导出字段，不新增权限模型，不接触真实客户数据。

反向验收：
如果销售仍然需要逐条进入详情页，才能判断哪些客户今天需要跟进，则本次不算完成。

六、给老板的确认消息

我先把“客户列表更好用”收敛成一个可验收的小目标，麻烦确认一下：这周是否优先解决销售早上找今日待跟进客户的问题？如果是，我先按“不改详情页、不改导出、不新增权限”的边界整理方案。为了避免做偏，想先确认 6 个问题：主要用户是谁、具体卡点是什么、是否允许调整默认排序或列顺序、哪些范围不能碰、谁验收、用什么脱敏样例数据验收。

人工验收

人要怎么检查和改到可用

AI 输出之后，开发者要做一轮人工检查。不要把问题清单原封不动发出去。你要确保它问的是对的人、对的范围、对的时机。

第一，检查有没有把线索当事实。比如材料里写“销售同事说早上找客户慢”，AI 如果直接写“本次目标是解决销售早上找客户慢”，就越界了。更稳的写法是“待确认假设：本次可能优先解决销售早上找今日待跟进客户的问题”。在业务方确认前，所有来自线索的目标都应该标成待确认。

第二，检查问题是否足够短。给老板或业务负责人看的问题，不适合写成长段推理。把问题压缩到能直接回复的程度。比如“这次优化优先服务一线销售、销售主管，还是运营同事？”就比“请从组织目标角度说明本次列表优化的核心用户群体及其任务优先级”更容易得到答案。

第三，检查是否混入技术方案。常见越界表达包括“建议增加一个今日跟进筛选器”“可以用虚拟滚动优化性能”“后端增加一个 nextAction 字段”“把表格组件换成新的”。这些都先删掉或改写成验收问题。比如“是否需要在列表上直接看到下一步动作”是验收问题；“后端增加 nextAction 字段”是方案。

第四，检查边界是否符合真实组织情况。AI 不知道你们的发布窗口、权限审批、依赖团队和历史约定。你要补上这些边界。例如“客服团队也使用同一客户列表，不能影响客服默认视图”“导出字段被月报依赖，本次不能变”“移动端使用另一个页面，本次不覆盖移动端”。这些边界越早确认，后面争议越少。

第五，检查验收标准是否可观察。坏的验收标准是“列表体验明显更好”。好的验收标准是“销售使用脱敏样例数据时，不进入详情页即可判断今天需要跟进的客户，并看到负责人、客户阶段、最近跟进时间和下一步动作”。它不一定精确量化，但必须能被人看见、操作和判断。

第六，检查反向验收是否写清楚。反向验收的作用是说明什么情况下“不算完成”。这能避免上线后陷入主观争论。例如“如果仍需要逐条进入详情页才能判断是否需要跟进，则不算完成”；“如果主管仍无法识别超过 7 天未跟进客户，则不算完成”。反向验收往往比正向描述更能暴露分歧。

第七，检查问题数量。第一轮确认建议控制在 6 到 8 个必须问题。太少会漏边界，太多会让对方不回。你可以把其余问题放到“后续可补充”里。对于临时需求，先确认核心方向，比一次问完所有细节更现实。

第八，检查措辞是否协作。不要把问题写成“需求不清楚无法开发”。可以写成“我先收敛成一个可验收的小目标，确认后就进入方案”。这不是话术包装，而是工作方式的改变：你不是在拒绝需求，而是在降低做偏的概率。

最后，把业务方回答再整理成一个小结，最好包含三块：已确认目标、已确认边界、待后续问题。这个小结可以作为开发前的轻量需求说明，也可以贴到任务卡里。只要这三块明确，后续让 Codex 进入方案或代码阶段才有意义。

失败反例

这些失败反例要提前避开

**反例 1：直接把一句需求变成技术方案。**

错误做法是这样问：“老板说客户列表不好用，请帮我设计一个优化方案。”AI 很可能马上输出一串方案：增加高级筛选、固定表头、列宽拖拽、批量操作、虚拟滚动、快捷编辑、保存视图。看起来很专业，但它跳过了最关键的问题：这次到底要解决谁的什么任务。

为什么会失败：技术方案越丰富，越容易掩盖目标不清。你可能做了很多“列表常见优化”，但没有解决老板说的那个具体痛点。

更好的改法：把提示改成“请不要给方案，先把这句需求拆成必须澄清的问题，并写待确认版验收标准”。如果 AI 已经输出方案，就要求它把每个方案反向改写成验收问题。例如“固定表头”改成“用户是否在滚动列表时仍需要持续看到列名才能完成判断”。

**反例 2：把业务线索当作已确认目标。**

错误做法是看到“销售早上找客户慢”这个线索，就直接写验收标准：“销售早上能快速找到今日待跟进客户。”如果老板真实想解决的是主管看不到长期未跟进客户，这个验收标准就会把团队带偏。

为什么会失败：线索只是可能的解释，不是需求提出人的确认。临时需求常常有多个来源，某个同事的反馈不一定代表这次优先级。

更好的改法：在验收标准前加“待确认假设”。例如“待确认假设：本周优先解决一线销售早上找今日待跟进客户的问题”。同时把它放进必须问题：“老板说的不好用，是否主要指这个问题？”

**反例 3：问题太大，对方无法回答。**

错误问题包括：“你希望列表怎么优化？”“你觉得哪里不好用？”“你想要什么体验？”这些问题看似开放，实际会让对方继续给模糊回答，比如“就更直观一点”“让大家用起来顺手一点”。

为什么会失败：模糊问题会得到模糊答案。对方没有被引导到具体任务、具体阻碍和具体验收。

更好的改法：把问题改成可选择、可举例、可确认。比如“现在最浪费时间的是找不到客户、看不到关键信息、需要频繁进详情页，还是加载慢？”“昨天或最近一次觉得不好用时，用户原本想完成什么，卡在哪一步？”

**反例 4：验收标准写成主观感受。**

错误验收是：“列表更清楚、更顺手，业务方觉得满意。”这句话无法指导开发，也无法验收。上线后每个人都可以说自己觉得不够顺手。

为什么会失败：主观形容词没有观察方式，不能判断是否完成，也不能帮助你决定取舍。

更好的改法：把验收标准写成用户行为。例如“销售在列表页不进入详情，也能识别今天需要跟进的客户，并看到客户名称、负责人、阶段、最近跟进时间和下一步动作。”如果能加上样例数据和验收人，就更稳。

**反例 5：第一轮问题太多，导致无人回复。**

错误做法是让 AI 输出 30 个澄清问题，然后全部发到群里。业务方看到长列表，很容易说“你先看着办”，需求又回到模糊状态。

为什么会失败：临时需求通常时间紧，对方没有耐心完成一份问卷。问题越多，越容易被跳过。

更好的改法：让 Codex 把问题分级，只发 6 到 8 个必须回答的问题。其余放进“后续可补充”。先拿到方向、边界和验收人，再补细节。

主题边界

它和相邻主题的区别

这个主题只解决“开工前如何问清楚验收标准”。它和很多相邻工作很像，但边界不同。

它不是技术方案设计。技术方案会讨论要不要加筛选器、要不要改接口、表格组件怎么调整、性能怎么优化、是否需要埋点。本文不做这些。本文只问：谁用、在哪用、卡在哪、不能碰什么、什么算完成。没有确认验收标准之前，任何方案都只是猜测。

它不是需求文档生成。完整 PRD 可能包含背景、目标、范围、用户故事、流程图、数据定义、异常状态、埋点、排期和发布计划。本文的产物更轻，只是一份澄清问题清单和待确认版验收标准。它适合临时需求的第一轮确认，不替代后续正式文档。

它不是用户研究。用户研究会访谈多位用户、分析行为数据、比较场景差异。本文只处理开发者手上已有的材料：一句原始需求、截图描述、已有功能和约束条件。它能帮你问出下一步该确认什么，但不能替代真实用户反馈。

它不是代码阅读。代码阅读关注当前系统如何实现、入口在哪里、数据如何流转、风险在哪里。本文在更早一步：还没决定要改什么，所以暂时不读代码细节。等验收标准确认后，再让 Codex 进入代码层，才不会把实现能力用在错误目标上。

它也不是项目管理排期。排期需要估算工作量、拆任务、排优先级、协调发布窗口。本文不估工期，只帮你确认“这次做成什么样才算完成”。如果验收标准无法确认，排期只是把不确定性写进日历。

最容易混淆的是“产品建议”和“验收标准”。例如“增加今日待跟进筛选”是产品建议；“销售能在列表上识别今天需要跟进的客户”是验收标准。前者是可能的做法，后者是要达成的结果。本文坚持先写结果，再讨论做法。这样无论最后选择调整排序、补充列、增加筛选，还是改默认视图，团队都知道自己在服务同一个目标。

一句话总结：当一句需求来了，先别让 Codex 显示它多会改代码。先让它问清楚什么叫完成。验收标准一旦清楚，后面的方案、实现和测试才有方向。