写好需求简报，不必分享过多信息

最初的请求：文件太多，解释太少

设想一家公司需要协调销售方案的准备工作。团队最先想到的是分享一个装满报价、消息和客户文件的文件夹。接收者需要重新拼凑经过，猜测团队关注什么，还得区分哪种情况属于例外，哪种才是通常的工作方式。

文件夹可能包含理解困难并不需要的姓名、价格、评论或条款，却漏掉关键内容：谁批准变更，下一位参与者又如何得知。选文件之前，先写出材料应帮助回答的问题。本例的问题是：为什么看似准备好的方案，还会回到审核环节？

可以分享的版本：使用虚构数据的简短路径

简报可以描述一个虚构情境：有人申请服务 A；团队准备方案；之后某项条件改变，却没人知道应审核哪个版本。保留顺序、角色和疑问出现的位置，把客户身份与金额换成虚构值，并明确标注。

这不是 Wiwo 的真实案例，也不代表已签约功能，而是用于沟通的材料。它让需要变得清楚，同时避免把虚构数据当作业务事实，也不必提供原始文件的访问权限。

• 情境：一次修改，使已准备的方案需要重新审核。
• 参与者：接收请求的人、准备答复的人，以及确认条件的人。
• 困难：不清楚应该继续使用哪个版本。
• 问题：每个人需要哪些信息，才能识别并审核变更。

保留什么，才能让例子仍然有用

简化并不意味着删除所有差异。如果审核取决于服务类型，应保留这一关系。如果变更需要与另一位同事确认，应说明其何时介入。删除困难产生原因的例子，看起来或许清楚，却无法继续帮助理解工作。

可以附上空白模板或经过检查的示意图，说明各字段代表什么，以及省略了哪些内容。使用截图时，也应检查消息、备注和次要细节。删掉姓名，并不代表其余内容就适合分享。有疑问时，一个更简单的虚构表示，可能足以开始沟通。

把背景、样本和访问权限分开

说出工具名称，有助于解释工作发生在哪里，并不需要因此提供密码。描述所用分类，可以在不交出完整数据库的情况下说明问题。应区分三件事：介绍背景、展示例子，以及授权查看信息或系统。

说明谁有权决定如何处理各项材料。如果后续评估需要更多信息，应询问这些信息有什么作用、由谁使用，以及需要什么授权。Wiwo 的 AI 安全计划公开介绍了人工控制、权限和测试原则。具体项目如何应用这些原则，应与审核范围一同商定。

检查别人是否能理解问题

请一位同事读简报，并解释发生了什么、工作停在哪里，以及还需澄清什么。如果对方只能说出想要的工具，简报可能缺少具体情境。如果必须知道客户身份才能理解路径，应检查身份是否真的重要，还是遗漏了一项相关条件。

注明材料日期，区分当前有效、虚构和仅用于说明的内容。这类简报能给 Wiwo 提供有用背景，用来识别软件、开发或集成方面的问题。第一次沟通可以聚焦困难，其他材料则留到有明确查看理由时再准备。