我做了一个Skill，专门用来对付那些说不清楚的需求

作者：浅木·先生 | 发布时间：2026-06-12

---

我做测试十余年了。从功能测试做到接口、性能、自动化，再到带团队，技术层面的东西一直在变。

但有一件事从来没变过——需求从来就没说清楚过。

这不是吐槽。这是现实。

你在政府财政系统这个领域做测试，碰到的需求是什么样的？

“预算指标下达要支持批量导入。”

“单位资金支付需要加个审批流。”

“我要做一个报表，能看到各单位的执行进度。”

“这个字段加个校验。”

“这个地方加个按钮。”

听起来都挺正常的。但等你往下追——批量导入失败了怎么办？审批节点有几个？报表的数据来源是什么口径？校验规则的业务依据是什么？

十次有八次，答案是：“嗯……这个还没想好。”

然后开发就开始做了。然后测试就开始测了。然后上线了。然后才发现，大家理解的根本不是同一件事。

这不是任何人的错。需求本身就不是一个"一次性说清楚"的东西。它是在一轮一轮的追问和确认中，逐渐变清晰的。

但我一直在想：能不能把"追问"这件事系统化？

能不能在需求还是一句话的时候，就自动把那些"迟早会爆炸的问题"提前摆出来？能不能让测试团队不只是"拿着需求文档去测"，而是参与到"把需求问清楚"这个环节？

所以我做了一个 Skill，叫 fiscal-req-detective，中文叫「财政需求侦探」。

---

它到底干什么

先说清楚它不干什么：

• 不写 PRD。不写 SRS。
• 不帮你画原型、画流程图。
• 不替你做业务决策。

它只干一件事：在你拿到一句模糊需求之后，帮你把它拆成一组可以拿着去跟业务方确认的决策题。

---

它的核心思路：不问"你想怎么做"，而是给选择题

这是我做这个 Skill 最核心的一个转变。

比如业务方说：“预算指标下达要支持批量导入。”

普通的追问可能是：“你想怎么导入？Excel？CSV？直接从系统导入？”

这个问题其实很难回答。业务方的脑子里面没有一个数据导入的完整模型。他不知道导入失败重试是什么意思，不知道数据冲突有几种处理方式。

更好的方式，是给他选择题。

数据冲突时怎么处理？

A：重复导入直接覆盖。好处：操作简单，一次搞定。代价：误操作可能导致数据丢失，无法追溯历史。

B：重复导入提示冲突，逐条确认。好处：数据安全，每笔都有记录。代价：几百条数据时操作量较大。

C：重复行跳过，新增行导入，最终输出成功/失败明细。好处：兼顾效率和安全性。代价：实现复杂度稍高。

你看，问法一变，需求就不再是"做个导入功能"了。

它变成了一个业务选择。 而且每个选择背后都有代价。

这在政府财政系统里尤其重要。因为财政系统的很多业务规则，不是产品经理能拍板的——它背后可能有财政厅的红头文件、国库的清算规则、审计的追溯要求。你给的选项要足够具体，具体到让业务方能对照自己的实际情况做出判断。

---

它的工作方式：三步把一句话需求拆成决策清单

第一步：还原业务场景

不急着写方案。先用自己的话，把业务故事复述一遍。

这段话里必须有五个要素：角色、场景、动作、目标、风险。

预算科的业务经办人，在年初集中下达指标时，面对几百条指标数据。他最关心的是能不能快速完成录入，同时保证数据准确不串行、不遗漏。他最怕的是导入后数据错位，导致后续执行环节对不上，审计追溯时有问题。

比单纯一句"做个批量导入"清楚太多了。这时候你已经知道：这个功能的核心不是"快"，是准。

第二步：按影响范围从大到小，逐步拆解决策题

很多需求讨论最大的问题，就是一上来就陷入细节。

大家花半小时讨论导入按钮放左边还是右边，但数据冲突了是覆盖还是跳过——没人确认。

所以这个 Skill 强制按四层顺序提问：

第一层：业务边界（影响整个系统架构）
    ↓
第二层：流程规则（影响审批、状态流转）
    ↓
第三层：数据与校验（影响字段、必填、格式）
    ↓
第四层：体验与报表（影响提醒、展示、导出）

第一层的问题不确认，第三层的问题根本不应该讨论。

比如"支付申请要加审批"：

• 第一层先问：这个审批覆盖哪些业务类型？授权支付和直接支付都走同一个审批流吗？
• 第二层再问：审批节点有哪些？不同金额级别审批人不同吗？
• 第三层才问：驳回后是否要求填写驳回原因？
• 第四层最后问：是否需要审批超时提醒？

这个顺序很关键。 先确认边界，再讨论流程，最后才到细节。顺序对了，返工就少了。

第三步：输出测试导向的分级任务单

不是把所有东西都写成"必须实现"。

分成两块：

核心确定区：已经跟业务确认过的规则，开发必须严格实现，测试可以直接验证。

假设验证区：当前还不确定，但为了推进项目先按默认方案做——关键是把这些东西标注为"假设"，并且要求系统做成可配置。

比如逾期提醒规则：默认设为"提前1天提醒、逾期当天提醒、逾期3天提醒主管"。但这个规则未来很可能因财政厅通知调整。所以它不是写死在代码里的，而是一个可配的参数。

这对测试特别重要。 因为假设区的东西，测试验证的时候要额外关注——验证"可配置性"本身就是一个测试点。

---

它还内置了一个需求缺陷检测器

做测试久了，你会发现需求有几种经典的"坏法"：

缺陷模式	表现	怎么检测
方案绑架	“加个按钮/加个字段”	追问：这个按钮解决什么业务问题？
场景缺失	只有正向流程	追问：如果失败了会怎样？
边界模糊	“批量/大量/快速”	追问：最大多少？最小多少？
质量空洞	“性能要好”	追问：多少条数据多少秒？
术语歧义	"部门/单位"混用	追问：你说的部门是哪个层级？
范围蔓延	“顺便/也/还/另外”	追问：这是同一个需求还是另一个？

Skill 会在分析需求时自动扫描这些模式，标记出来。

---

它特别适合什么场景

最适合的就是我天天面对的那一类系统：预算管理、执行管理：基础信息、项目库、公务卡报销、政府采购、资产管理——业务规则密、审批流复杂、数据口径严格、审计追溯要求高。

这类系统最怕的不是功能不够多。最怕的是规则没想清楚。 规则没想清楚，页面越多，坑越多。

它也有明确不接的活：

• 纯 UI 体验优化
• 不需要业务规则决策的需求
• 需求已经很清晰、只需要写文档的场景

知道不做什么，比知道做什么更重要。

---

它不能替你决策，但能把问题摆到桌面上

这个 Skill 本质上是一个需求前置澄清工具。

它不会替你做业务决策——决策必须由懂财政业务的人来做。但它会把那些必须决策的问题，一个一个拎出来，摆在你和业务方面前。

而且是用选择题的方式——每个选项都附带利弊分析，让业务方不是凭空想象，而是对照自己的实际场景来做判断。

我做这个东西的出发点很简单：

很多时候，需求不是写出来的。是问出来的。

测试团队的价值，也不仅仅是"验证做对了没"。而是更早地介入，帮大家把"要做的东西到底是什么"问清楚。

---

如果你也经常面对那种一句话需求——“加个审批”、“做个报表”、“这个字段校验一下”——希望能用这个 Skill 帮你把那些迟早会爆炸的问题，提前摆到桌面上。

有需要的留言 “需求澄清工具”