全栈工程师怎么接需求？从一句「加个功能」聊到能开发、能验收

「大额退款要主管审核。」

听到这句话，可以很快拆出一个申请页面，再接一套审核接口。把它交给 AI，也可以继续讨论字段和代码。

但这里还缺几个会改变实现的答案。大额按单次申请计算，还是按订单累计计算？主管通过以后，系统直接退款，还是等申请人再次操作？支付请求超时，页面该显示什么？

我认为，接需求时应当先做成一件事。

先把用户的建议变成可验证的业务约定，再交给 AI 实现。

这里的业务约定，要能说清在什么条件下，用户做什么，系统应该给出什么结果，失败后怎样继续。业务方用这组场景确认预期，研发和测试据此实施与验收。

建议提出一种可能的做法，比如加审核、显示已读，或者增加确认弹窗。业务约定则需要把具体条件和预期结果写下来，并由相关人员确认。

下面假设双方已经确认了相应规则，看看两种写法的差别。每个例子只摘取一部分约定，实际需求还需要补齐其他场景。

用户提出的建议	讨论后形成的业务约定示例
大额退款要主管审核	同一订单已退款金额加本次申请金额达到 1000 元时，申请进入待审核，由有退款审核权限的主管处理。审核通过后允许执行退款，渠道确认成功后才显示退款成功。
消息发出去后加一个已读回执	收件人成功打开通知详情后，系统记录阅读时间，发送者可以查看阅读状态。通知要求的事项是否办完，单独记录处理结果。
发布前加一个二次确认弹窗	用户点击发布后，先展示发布账号与可见范围，并提供内容摘要。用户确认后才提交发布；取消时保留草稿，发布失败时保留内容并显示失败原因。

第一行可以直接拿来检查边界。如果此前已退款 600 元，本次申请退款 400 元，合计达到 1000 元，就应进入待审核。开发和测试据此能给出同一个结果；只写"大额退款要审核"，还无法判断这次申请该怎样处理。

已读回执的例子确定了什么时候记录已读，以及已读和处理完成分别表示什么。发布确认的例子则说明用户确认的内容，以及取消或失败后的结果。

具体描述还要经相关人员确认，才能作为实施依据。AI 可以帮忙起草这些场景，金额阈值和状态含义等规则要由相关人员作决定；还没有答案的地方，继续标为待确认。

如果「超过多少算大额」还没有答案，让 AI 自行补一个判断分支，就会把未经确认的规则写进代码。后面再检查代码写得对不对，也需要先回答这个问题。

下面回到退款规则尚未确认的时候，看看怎样逐步形成这样的约定，以及每一步可以怎样和 AI 配合。

先确认用户遇到了什么问题

接到「大额退款要审核」的建议，可以先请业务方回放一次具体操作。申请人在哪里提交，审核人看到了什么，最后由谁执行退款？哪一步出了问题，又是怎样处理的？

这一步要确认增加审核希望改变什么结果。如果业务担心退款风险，就需要继续讨论金额口径和审批权限；如果问题来自申请积压，还要检查等待发生在哪一步。多加一次审核，也可能让申请等得更久。

同样一个按钮，在不同目标下可能需要不同的方案。

把操作经过记下来时，事实和猜测要分开。记录显示申请长时间停在待审核，可以确认它还没往下走；至于是审核人没收到通知，还是缺少材料，需要核实。别把「应该是通知没到」写成问题原因。

然后用一句话复述目标，请业务方纠正。可以说清谁在什么场景下遇到了困难，希望哪种结果发生变化。暂时拿掉「增加审核按钮」这类方案词，看看目标是否仍然讲得通。

这一轮也可以让 AI 帮忙整理，给它真实的操作记录，以及你已经问到的答案。

我正在梳理退款需求，这一轮只讨论，不修改代码。
用户提出"大额退款要主管审核"。下面是已有的操作记录和访谈笔记。

请复述你理解的问题与目标，每个判断注明材料依据。
推断单独列出，缺少信息的地方保留未知。
先问会影响方案选择的几个问题，说明每个问题会影响什么。
不要自行补审核规则，也不要把用户的建议当成已经确定的方案。

[在这里粘贴记录，并注明哪些结论已由业务方确认]

如果 AI 能读取项目代码，还可以让它查现有流程。业务描述里的「审核通过」，和系统字段里的同名状态，未必包含完全相同的后续动作。

请沿着现有退款入口，检查页面提交、服务端校验和执行记录。
说明当前金额口径、状态含义以及权限在哪里校验，并给出文件位置。
找不到依据的内容标为未知。现有代码行为与新需求的待定规则分开写。
这轮只定位，不修改代码。

代码回答系统现在怎么做，业务方确认这次希望怎么做。查到现有实现按单次金额判断，只能作为讨论依据，不能自动成为新需求的结论。

用同一组场景，把规则确定下来

目标确认以后，再讨论「大额」这样的词。它需要落实到输入和结果，才方便判断实现是否正确。

假设审核阈值为 T，可以先摆出这张表。

场景	必须确定的结果
单次退款小于 T	是否免审，有没有其他条件？
单次退款恰好等于 T	进入审核，还是允许直接执行？
单次退款大于 T	交给谁审核，申请进入什么状态？
同一订单两次退款都小于 T，合计大于 T	按单次判断，还是累计判断？
等待审核时修改金额	原审核继续有效，还是需要重新审核？
审核通过后重复点击退款	怎样识别同一笔操作，避免重复退款？

直接问「超过阈值要不要审核」，容易漏掉累计口径。把两次小额退款摆出来，大家才能确认拆分申请后的结果是否符合业务目标。

反例也要从另一边找。规则有没有拦住业务认为合理的操作？如果需要例外，谁有权决定，能跳过哪条限制？「主管可以强制处理」还需要落实到具体权限，服务端也要校验，不能只隐藏页面按钮。

这时可以请 AI 找遗漏，但表里每个预期结果仍然需要依据。假设业务方已经确认按同一订单累计退款金额判断，下一轮可以这样继续。

业务方已确认按同一订单累计退款金额判断是否需要审核。
恰好等于阈值时怎样处理，以及审核期间改金额的处理方式，仍未确认。

请更新场景决策表，只给已有结论的场景填写预期结果。
其余场景保留待确认，注明缺哪条规则、会影响什么。
找出当前规则可能违背业务目标的反例，供我们带回业务方核实。
不要替待定场景选择默认答案。

读 AI 的回答时，要核对它有没有前后矛盾。表里写着累计金额，接口建议就不能悄悄换回单次金额。发现矛盾，指出具体两处，让它按已确认的规则修正。

表里答不出来的项，写明由谁确认。别用「按正常逻辑处理」填过去，正常逻辑正是大家还没达成一致的地方。

失败后的处理，也是这份约定的一部分

金额规则定了，退款流程还需要走到结果。

申请人提交材料，系统分配审核人。审核通过以后执行退款，最后查询结果。可以用几个页面方框，把这条路径画出来，写上用户看到的状态和可以操作的按钮。

接着故意在中间停下来。审核人不在怎么办？材料退回后，能不能在原申请上补充？遇到支付请求超时，用户下一步在哪里处理？

审核通过说明这笔退款获得了批准，退款成功还需要实际执行结果。如果页面把两者合成一个状态，客服就可能把尚未成功的退款告知消费者。

超时又有不同的问题。本次调用没拿到确定结果，渠道仍有可能已经执行成功。仅凭超时，不能判断退款失败。

如果前端显示「失败，请重试」，后端却还在等待成功回调，用户就可能再次发起退款。是否允许重试，需要连同幂等处理一起设计，页面也要表达结果尚未确定。

流程演练因此不能停在「提示错误」。要继续确定查询在哪里进行，谁负责查明结果，以及原申请如何更新。如果提供重试按钮，还要明确它沿用原申请，还是创建新的申请。

也可以让 AI 沿着这张流程图逐步检查，尤其关注每个失败点是否有下一步。让它说明哪里缺少约定，先别用一句「增加重试机制」把问题带过去。

技术实现可以根据现有系统选择。能不能再次执行退款，以及何时向消费者告知成功，则需要相关人员共同确认。这些决定会改变用户实际得到的结果。

验收场景确定以后，再授权 AI 实现

前面的规则和恢复路径，可以直接写成验收场景。「退款异常处理正确」太宽泛，下面这份约定就能实际检查。

验收部分	具体约定
给定条件	申请已审核通过，尚未确认退款成功，当前操作人有执行权限
执行动作	发起退款，支付渠道返回超时
页面结果	不显示退款成功，说明结果待确认，并给出约定的查询或处理入口
系统保证	保留申请与执行记录，重复操作不能造成重复退款
后续恢复	查明渠道结果后更新状态，再次执行的条件和权限按已确认规则处理

产品检查用户能不能看懂、找到后续入口。研发确认系统能否保证这些结果，测试据此准备数据和异常场景。

这样写，讨论中的空缺也会显出来。恢复路径如果还写着「后面再看」，就需要先确定上线后由谁处理未知结果。

交给 AI 开发时，把已确认的场景和本期范围一起提供。讨论过程中出现过的候选方案，不要全部混进实施要求。

下面这份需求说明和场景表已确认，本次只实施其中列明的范围。
请先检查已有能力能否复用，给出涉及的文件和定向验证方式。
实现后按场景表核对，说明实际执行了哪些检查，哪些仍需人工验收。

局部、可逆且不改变业务语义的实现细节，可以按项目规范处理。
如果发现缺失规则会改变金额结果或权限，暂停依赖它的部分，说明影响。
其余不依赖该问题的工作可以继续。遵守项目已有的修改和确认规则。

[在这里粘贴已确认的需求说明和场景表]

不必让 AI 每改一行都问。确认应当集中在会改变业务结果的决定上，其余实现细节按项目约定推进。

检查实现时，仍然沿用前面确认的场景。不要因为某个分支不好实现，就让 AI 修改验收结果；测试通过，也要说清覆盖了哪些约定，页面演练或外部渠道验证有没有实际完成。

功能验收以后，还要观察原始问题。如果需求来自退款积压，就检查等待是否缩短；如果目标是控制退款风险，就核对已确认的风险场景是否按约定处理。审核量增加，不能单独说明问题解决了。

把讨论结果留在一份需求说明里

接需求时，可以只维护一份说明。开始记录操作经过，随后补入场景表，最后确定恢复路径和验收。AI 可以协助整理，每条结论都要保留确认依据。

# 需求名称

## 问题与依据
谁在什么场景下遇到了困难？现有记录能证明什么？

## 目标与方案
希望改变什么结果？本期选择哪种做法，依据是什么？
什么情况会让我们重新考虑这个方案？

## 已确认规则
记录范围与计算口径，说明状态含义。
附上场景决策表，明确操作权限，并注明确认依据。

## 操作与恢复
正常流程如何完成？失败或结果未知时，用户下一步怎么做？
需要人工承接的环节，由谁负责？

## 验收场景
写出操作前提、用户动作和可观察结果。
上线后用什么口径观察原始问题是否改善？

## 范围与待定项
本期做到哪里？哪些问题需要谁确认，会影响哪部分实现？

这份说明也可以用来检查 AI 有没有理解需求。请它按文档走一遍正常退款，再演练一次超时，看看它给出的结果是否符合已经确认的规则。

如果它仍然把超时写成退款失败，或者替金额边界补了答案，就先纠正它对规则的理解。会改变退款结果的规则还没确认，可以继续整理材料和定位代码，等业务方给出答案后，再实施依赖它的部分。

附一份可以直接用的需求澄清 skill

把下面的内容保存为 clarify-requirements/SKILL.md，放到所用 AI 工具支持的 skill 目录里。它会引导 AI 按前面的方式梳理需求，最后交付场景表和验收约定。

如果工具不支持加载 skill，也可以把正文作为对话指令，再补上实际需求与已有材料。

---
name: clarify-requirements
description: 将功能建议整理为可确认、可验收的业务约定。用于接需求、核对模糊规则或准备交给 AI 实施；已有约定充分的局部修复，无需重新进行完整需求访谈。
---

# 从建议到业务约定

把用户提出的做法转成具体场景，明确操作条件与预期结果，保留待确认的问题。

## 使用已有材料

先检查用户提供的记录和已确认约定，已有答案不重复询问。区分观察事实与原因推断；建议中的按钮或流程作为候选方案，不能直接当成业务目标。

需要了解当前系统时，在具备访问能力的前提下定位相关实现，注明文件位置。现有代码行为和新需求的期望分开记录，找不到依据就标为未知。

## 找到会改变方案的问题

用已有材料复述谁遇到了什么困难，希望改变什么结果。推断注明依据，请用户核对。

优先询问会改变业务结果、实施范围或验收的问题，说明答案影响什么。每轮集中处理少量相关问题；不影响当前方案的细节可以按现有约定提出建议，无需全部追问。

## 写出场景并检查反例

用场景表记录条件、动作、预期结果及确认依据。没有结论的行保持待确认，注明需要谁决定及影响范围，不自行补默认规则。

根据实际风险检查金额边界或累计口径，关注权限和状态变化。找出按规则允许却可能违背目标的反例，也检查合理操作是否被过度限制，不要求穷举无关组合。

## 演练到完成或恢复

沿着用户操作走一遍正常流程，再检查相关的失败或等待场景。说明用户看到什么、下一步在哪里处理，以及系统需要保留什么记录。

涉及外部调用时，区分失败与结果未知。讨论重试要同时明确操作身份和幂等要求，不能仅凭超时判断业务失败。需要人工承接的环节写明责任人。

## 整理成实施依据

用给定条件、执行动作和可观察结果写验收场景，与前面的规则保持一致。注明本期范围，记录方案依据和重新考虑方案的条件。

交付一份简洁的需求说明，附场景表和关键验收场景。待定项保留确认人及影响，建议与已确认规则分开写；用户未要求写文件时，在对话中交付即可。

进入实施前，检查前后是否矛盾，不能将候选方案自动加入开发范围。仅要求梳理时不修改代码；已有明确实施授权时遵守该授权和项目规则，不重复确认。发现缺失规则会实质改变业务结果时，暂停依赖它的部分，其余工作继续推进。

使用时，把用户原话和已有记录一起提供。比如可以这样开始。

请使用 clarify-requirements 帮我梳理下面的需求，先讨论，不修改代码。

用户提出"大额退款要主管审核"。
目前金额口径和审核后的执行流程还没确认。
请先复述你理解的问题，指出影响方案的缺口，再和我逐项核实。

我会补充操作记录、现有流程，以及业务方已经确认的答案。

AI 给出的第一版场景表，需要对照实际材料阅读。看到它替待定规则选了答案，就指出那一行，让它恢复为待确认，再把问题带回业务方。双方确认以后，把答案更新到同一份约定里，下一轮继续使用。