Source: Dev.to

假设清单提示（Assumption Inventory Prompt）

在开始编码之前，捕获隐藏需求是确保项目成功的关键一步。假设清单提示是一种结构化的方法，帮助团队在实际动手之前识别、记录并验证所有潜在的假设。下面，我将介绍该提示的核心概念、使用方法以及实际示例。

为什么需要假设清单？

• 隐藏需求：在需求文档中往往只列出显式需求，未明确的前提条件会在后期导致返工或功能缺失。
• 风险降低：提前发现假设可以在项目早期进行风险评估和缓解。
• 沟通效率：让所有干系人对项目的前提有统一的认识，避免因误解产生的冲突。

假设清单提示的结构

如何在实际工作中使用

1. 召集团队：在需求评审或冲刺规划会议上，邀请产品、设计、开发、测试和业务方。
2. 填写清单：使用上表的模板，逐条列出大家能想到的假设。
3. 分配验证任务：为每个假设指派所有者，并设定验证的时间窗口。
4. 记录结果：在清单中更新验证状态（已验证/待验证/已否定）。
5. 决策调整：根据验证结果，决定是否需要重新定义需求、调整范围或更改技术方案。

示例：构建一个“实时聊天”功能

背景: 为企业内部协作平台添加实时聊天功能
假设 1: 所有用户的网络带宽 ≥ 5Mbps
验证方法: 通过网络监控工具收集过去 2 周的平均带宽数据
影响: 若带宽不足，消息延迟会超过 2 秒，影响用户体验
所有者: 网络运维团队

假设 2: 用户每天至少发送 10 条消息
验证方法: 从现有的内部沟通工具中抽取日志进行统计
影响: 若消息量低，实时聊天的 ROI 可能不足
所有者: 产品分析师

常见误区与避免方法

小结

• 假设清单提示是一套简单却强大的工具，帮助团队在编码前系统性地捕获隐藏需求。
• 通过 结构化记录、明确验证方法和责任人，可以显著降低项目风险。
• 将其嵌入到常规的需求评审或冲刺规划流程中，能够提升沟通效率并确保交付质量。

行动建议：在下一个项目的需求评审会议上，立即尝试使用上述模板，记录并验证至少 3 条关键假设。你会惊讶于它带来的洞察力和风险控制效果。

假设清单提示

你是否有过这样的感觉：以为任务很明确……结果交付的代码在技术上是对的，却完全不符合需求？

通常这不是编码问题，而是假设问题。

当你请求大型语言模型帮助构建某些东西时，它会乐于用合理的默认值填补缺失的需求。人类也是如此，只是事后会争论这些假设。

随着时间的推移，我开始把**“缺失的需求”视为一级错误。我的常用解决方案是一个简单的模式，我称之为假设清单提示**。

它的作用

一个简短的预检查步骤，强制助手：

1. 列出它的假设
2. 标记哪些假设存在风险
3. 提出最少量的问题以消除歧义
4. 在你不想回答问题时提供安全的默认值

收益： 减少重写次数，减少“等等，这不是我的意思”的情况，让获得高质量代码的路径更顺畅。

一句话概括的模式

在生成解决方案之前，先生成一份结构化的假设列表和问题。

这听起来显而易见，但在日常提示中却出奇地少见。大多数提示直接从“做 X”跳到“这里是解决方案”，省略了你实际上需要对 X 的含义达成一致的那一步。

假设清单提示（复制/粘贴）

在任何需求可能模糊的任务中，使用此作为直接前置。

Before proposing a solution, do an Assumption Inventory.

1) Restate the goal in 1–2 sentences.  
2) List assumptions you’re making (at least 8). Group them by:  
   - Product/UX  
   - Data & edge cases  
   - Security/privacy  
   - Performance/scale  
   - Ops/maintenance  
3) For each assumption, label it as Low/Medium/High risk.  
4) Ask up to 5 clarifying questions that remove the highest‑risk ambiguity.  
5) If I don’t answer, propose safe defaults and continue.

Then proceed with the solution.

提示： 限制提问数量。无限提问会导致分析瘫痪。五力优先级。

Concrete example: “Add audit logging to our API”

Prompt: “Add audit logging to our API. We’re using Node.js and Postgres.”

如果没有假设清单，你往往会得到一个通用的日志设置，遗漏重要细节（哪些算作审计事件、保留规则、PII 处理、关联 ID 等）。
使用该模式，助理会把隐藏的决策显现出来。

好的假设清单应该是什么样子

重新表述的目标

• 为敏感 API 操作添加防篡改、可查询的审计日志，供调试和合规使用。

假设（示例）

澄清问题（前 5 条）

1. 在你的业务中，哪些端点/操作被视为 “可审计”？
2. 你需要前后快照，还是仅记录 “事件发生” 即可？
3. 你的保留期限是多久，是否需要不可变存储保证？
4. 哪些 PII 必须脱敏（以及谁有权限查看未脱敏的数据）？
5. 你已经有请求 ID / 跟踪 ID，还是需要我们引入？

安全默认值（如果你未作回答）

• 仅审计特权操作（管理员/计费/角色变更）。
• 存储 event_type、actor、target、timestamp、request_id。
• 对 JSON 字段存差异；避免完整负载日志。
• 脱敏电子邮件/令牌；限制读取权限给管理员。
• 保留 180 天；使用追加写入表并限制 UPDATE/DELETE。

此时，就可以生成代码了。

为什么这样有效（以及它如何节省时间）

1. 它把“隐式上下文”转化为显式决策
   大语言模型是模式匹配器。如果你的提示模糊，模型会用看起来典型的模式填补空白。清单让这些空白变得可见。

2. 它让审查工作大幅简化
   将假设列表粘贴到 PR 描述或工单中并询问：

   • “哪些是错误的？”
   • “哪些我们想要以不同方式决定？”
     这比争论已经完成的实现要好得多的审查对话。

3. 当你赶时间时，它为你提供安全网
   “安全默认”章节常被低估。当你没有时间回答问题时，你需要的默认设置应是：

   • 保守的（避免数据丢失/安全问题）
   • 可逆的（以后容易更改）
   • 可观察的（容易检测默认设置是否错误）

在实践中使用它的两条规则

规则 1：在错误代价高时使用它

我在涉及以下任何事项时都会使用假设清单：

• 认证/权限
• 金钱
• 数据迁移
• 面向用户的流程
• 任何“合规相关”的内容（审计日志、保留、导出）

对于小规模的重构，我会跳过它。

规则 2：让清单紧贴工作

不要让它变成漂移的独立文档。好的保存位置包括：

• 在生成代码的聊天线程顶部
• 在工单描述中
• 在 docs/decisions/ 备注中（如果你的团队有这种做法）

目标是 可追溯性。

我们为什么这样做？ → “因为我们假设了 X，并且该假设被接受了。”

适用于日常提示的轻量版

如果你想要更短的版本，试试这个：

Before you answer, list:
- 5 assumptions you’re making
- 3 things that could go wrong
- 3 questions you’d ask if you had time
Then proceed.

进入全屏模式
退出全屏模式

它没有那么详尽，但速度快，仍能抓住要点。

Closing thought

大多数提示技巧都侧重于让模型产生更好的输出。
这个模式则关注在输出出现之前，实现更好的对齐。

如果你本周尝试使用它，请把它应用在你之前曾因歧义而受挫的任务上。第一次发现自己在做一个“高风险假设”，而你并未意识到自己在做时，它的价值就会显现。

如果愿意的话，回复一个你即将进行的模糊任务，我会展示一个针对它的假设清单会是什么样子。