04｜甲方回答了，怎样知道已经问清楚？

本章任务：把甲方的回复记明白，继续追问没答全的地方，写清这次要做什么、做到什么样算合格。
准备材料：甲方最初的要求、上一章的问题清单，以及这次收到的回复。
本章产出：一份甲方确认过的规则、一份这次要做和暂时不做的清单，还有能拿来逐项检查的办法。

先看一个容易误会的回复

图解：问清条件、动作和结果。 查看大图

甲方回你：“先收申请，审核通过才占名额。不同后台账号只看各自的活动。报名可以取消。”

你觉得这回总算清楚了。可真要做取消按钮，又发现：审核通过还能取消吗？截止以后呢？取消一个，名额要不要空出来？

这跟网购退款一样。“可以退款”没说清是发货前能退、收货后也能退，还是得先把东西寄回去。只记三个字，动手时还是得猜。

别把“收到了回复”当成“每个问题都有答案”。 接下来要做的，就是把答过的记下来，把没答全的继续问。

照着做：把回复处理成四份短记录

第一步：对应问题记录答案，先解决矛盾

打开上一章的问题清单，把甲方的回答放到对应问题下面。顺手记日期，保留原话或截图，别只留一句“按最新说的做”。

例如，第 1 个问题是名额怎么算，已经明确答了；第 3 个问题是取消规则，只答了“能取消”，还缺什么时候能取消。

你可以直接写“已经说清楚”“只答了一半”“还没答”。没有答案的，别让 AI 顺手补一个。

如果甲方上次说“提交就占名额”，这次又说“通过才占”，拿两句话请他确认：是不是准备改掉上次的说法？还是两次说的并不是同一种情况？

为什么要多问这一句？不问，AI 可能按旧话做，你按新话检查。最后两边都觉得有理，已经写好的代码还要重改。

仅作为示例，不建议作为实际项目中的提示词使用。

请把甲方的每句回复放到对应问题下面，保留原意和日期。分开写：哪些答清楚了，哪些只答了一部分，哪些还没答。如果两句互相矛盾，请指出来，不要自己选一个。先挑会影响主要功能的问题，帮我改成可以继续问甲方的话。

第二步：把口头表达拆成业务规则

“业务规则”就是事情实际按什么规矩办。例如网购退货“收到退回的商品以后再退款”，就是一条；这里“审核通过才占名额”也是一条。

我们把确认过的规则编上号，是为了以后能准确指出“哪一条要做、哪一条没做好、哪一条改了”，不用每次重新讲一大段。

下面假设又沟通了几轮，甲方确认了这些做法。它们只是这个虚构项目的答案，不是所有报名项目的标准。

编号	说好的规则	还要注意
第 1 条	提交报名后是“待审核”，不占名额	截止后不收新报名；名额满了但还没截止，仍然可以提交
第 2 条	只有审核通过，才占一个名额	就算只剩一个名额，同时审也不能超过
第 3 条	截止之前，待审核的和已通过的都能取消	已经通过的取消掉，名额要还回来
第 4 条	同一个人对同一个活动，只能有一条有效报名（“待审核”和“已通过”都算有效）	取消以后、截止之前可以再报；被拒绝以后能不能再报，还没确认
第 5 条	后台账号只能动自己被授权的活动	不能只在页面上藏按钮，后台也要拒绝

“有效报名”就是目前仍算数的那一条。这里把待审核、已通过算进去。例如你已经有一条待审核申请，就不能再提交一条同活动申请。

表里的“授权”，就是明确允许。比如后台账号被允许处理活动甲，不代表它也能处理活动乙。这个允许范围要问清楚，不能凭“都是后台账号”就全部放开。

写规则时，试着检查一句话有没有说到三件事：什么时候、做什么、做完变成什么。

比如别只写“能取消”，而是写“截止前，已通过的报名能取消，取消后把名额还回来”。到了写按钮、存记录和检查结果时，你才不用继续猜。

还有一些看起来小的问题也会改变结果。例如截止时间写晚上八点，是按哪个地方的时间？正好八点点提交算不算超时？甲方决定系统应该怎么表现，具体代码怎样保证，再放到后面讨论。

第三步：圈定本期，给额外想法一个去处

“本期”就是这一次约定要交的东西，不是将来所有想做的功能。

这个例子可以先做查看活动、报名、取消、发布、审核，以及必要的账号限制。候补、积分、邮件通知先放在“以后再考虑”，甲方确认要做时再安排。

别只列功能名，还要问：从手机哪里打开？电脑要不要用？已有名单要不要导进来？做好后由谁放到能访问的地方，要不要写使用说明？

像网购买家具，“买到桌子”和“送上楼、组装好”不是同一件事。项目也一样，先说清这次包含哪些工作，别等最后才发现双方想的不一样。

甲方说“顺便加个按钮”，先别立刻答应日期。按钮背后可能要多存数据、多改页面，还得检查原来的地方有没有被弄坏。先记下来，说明要看哪些地方，再讨论什么时候做。

第四步：给规则配上验收条件

图解：规则有条件，验收有预期。 查看大图

“验收条件”就是做到什么样算合格。例如买手机时约好“收到后能正常开机”，你就有一个具体检查；只说“质量不错”，就不知道怎么判断。

项目里也一样。每条至少写清：开始时是什么情况，你怎样操作，应该看到什么，还要检查哪些记录。

拿第 2 条来试：

• 一共 30 个名额，已有 29 条通过。再通过一条以后，应变成 30 条。
• 已有 30 条通过时，再点通过应该被拒绝，那条申请仍保持待审核。
• 只剩一个名额时，两次不同的审核几乎同时点下去，最后也不能变成 31 条通过。

第三种不需要你现在就会制造。后面可以请 AI 带着用工具检查，但你要先知道这也是系统必须做到的事，不能因为手动不好试就当它不存在。

第 5 条则要更小心：页面没显示按钮，不代表真的不能操作。

后端就是接收页面发来的操作、处理数据的那部分程序。例如你点退款，页面负责展示，后端还得判断这笔订单是不是你的、现在能不能退。不能因为页面上没有退款按钮，就默认别人没有办法发来退款请求。

“请求”可以理解为页面发给程序的一次要求。例如“帮我取出这条报名记录”，就是一次请求。检查第 5 条时，就要试着用未被允许的后台账号索取其他活动的数据，确认它确实拿不到，也改不了。

仅作为示例，不建议作为实际项目中的提示词使用。

请按甲方确认过的每条规则，整理可以照着做的检查步骤。写清开始需要什么数据、点什么或做什么、应该看到什么结果。除了正常成功，也要考虑失败、重复操作、没有查看或修改资格的情况。能自己试的和要工具帮忙的分开。没确认的答案继续留着，别替甲方决定。

怎样确认这一轮可以结束？

把说好的规则、这次做哪些、几条重要检查发给甲方看。别塞一堆技术说明，先让甲方确认“实际用起来是不是这样”。

保存一份带日期的当前记录。例如“11 月 14 日确认版”。以后不是不能改，而是改的时候要知道原来约好什么、新的改成什么。

有些未知会挡住后面的工作，就明确写出来：登录入口没定，登录部分先不能做；按钮文案没定，不一定要让整个项目都停住。

速度也别只约“流畅”“很快”。像外卖写“尽快送达”，你还是不知道等多久算正常。可以和甲方商量在什么网络、多少记录的情况下，主要页面要多快打开，再决定怎样量、怎样检查。没有试过的数字，不要随口保证。

需求变了，怎样处理？

图解：甲方确认业务，不等于授权操作线上数据。 查看大图

下面单独练习一次“甲方改主意”。它不改变上面那张表，后面的例子仍按原规则走。

假设甲方说：“已经通过的报名，取消以后也别还名额了。”这就要改第 3 条。

你先记下原来怎样、现在想怎样，再让 AI 帮你看：剩余名额怎样显示？审核判断要不要改？以前写的检查还对不对？已经取消过的记录要不要处理？会多花多少时间？

拿到这些信息，再跟甲方讨论这次做，还是以后再做。别听到一句新想法就直接让 AI 改完，最后才说要延期或加钱。

还有一件事要分开：同意新规则，不等于同意你直接改真实数据。

像网购退货规则变了，不能顺手把已经办完的退款也改掉。已经存在的记录怎样处理，要另外说清楚；你没有得到允许，就先别动。

决定改了以后，记规则的地方、页面草图、开发方案和检查步骤都要一起更新。只改一段聊天，新会话拿到旧资料，还是会按旧说法做，又白花一次时间和调用费用。

本章练习

甲方追加一句：“截止以后，后台还能帮忙新增报名。”

先不要实现，写出至少三个要继续问的问题，再想想上面哪条规则和哪些检查要变。

可以从这些方向想：所有后台账号都能加吗？只能加自己负责的活动吗？仍受名额限制吗？加完以后，报名端能看见吗？需要留下谁在什么时候做过的记录吗？

这些方向不是答案。“后台可以”不能被你理解成“所有后台账号都随便加”。

怎样判断本章完成了？

• [ ] 每个重要答案都找得到对应问题和甲方原始回复。
• [ ] 哪些已经说清楚、哪些还缺答案，分开记着。
• [ ] 这次要做和暂时不做的东西，双方都看过。
• [ ] 重要规则有具体检查步骤，不只看页面好不好看。
• [ ] 改主意时知道要更新哪些资料，没有几份互相打架的说法。

卡住了怎么办？

甲方拿不定主意，就拿具体情况比较：如果 40 人申请 30 个名额，这种做法会怎样，那种做法会怎样。少给几个清楚的选项，比一次扔十几个问题有用。

甲方让你决定，也要问清让你决定哪几件事。让你选页面颜色，不代表你可以决定取消后是否退名额。

如果你不知道怎样保证两次审核不会多占名额，或怎样拦住不该看的账号，把说好的规则、具体例子和拿不准的地方整理好，找有相关经验的人问。技术上怎么做可以请教，甲方想要什么仍要甲方确认。

本章带走： 已确认的规则、这次要做的清单、逐项检查办法，以及仍要继续问的事。下一章用页面草图和讲述，让甲方提前试着走一遍。