想象一个产品页面，开头列出十二项功能：Webhooks、自定义字段、重试控制、审计日志、可视化映射器、调度面板。商家浏览列表，却仍答不上一个问题：昨天的订单会到达正确的客户记录吗？
页面是示例。失败之所以熟悉，是因为功能清单从机器内部描述机器，而读者在外面，有工作需要做完。
一段关于产品传播的简短对话指出基本做法：先描述使用后发生什么，再介绍部件。这不是隐藏部件，而是给读者一个查看部件的理由。
说出能看见的变化
“连接全部数据”太宽泛，无法测试。“把一笔新的 Shopify 订单送入匹配的 Brevo 联系人记录”则给了读者一条可以检查的记录。它明确了之前的状态、动作和之后的状态。
成果句可以按这个形式写：
当这个事件发生，这个系统中的这条记录发生变化，于是这个人可以完成下一项任务。
对同步来说，事件可能是订单更新，记录可能是联系人属性，下一项任务可能是向同意接收营销信息的客户发送与购买相关的消息。每个名词都迫使做选择：哪笔订单？哪个联系人？哪个属性？怎样才算同意？
这些问题就是工作本身。“统一客户数据”轻易滑过它们。
Brevo 集成指南介绍设置和映射，也问每个字段由哪个系统负责、结果如何检查。产品页面可以用一句话先回答读者的第一个问题，待他们需要时再链接到更深处。
- 订单变化客户事件源事件
- 匹配并映射身份 · 字段 · 许可目标状态
- 检查联系人看得见的结果
把证据放在承诺旁边
成果优先的文案也可能成为另一种迷雾。“每周节省十小时”因有数字而显得具体；没有测量工作和基线，数字只是换了衣服。
合理的质疑是：“购买者需要功能和规格，只说成果无法判断是否适配我的系统。”没错。成果说明为何值得看，规格说明是否值得继续。
使用一条短证据链：
| 读者需要什么 | 页面可以展示什么 |
|---|---|
| 工作 | 一条记录的前后对比 |
| 机制 | 涉及的触发条件、映射与目标系统 |
| 边界 | 支持的对象、时效和许可要求 |
| 证据 | 测试路径、文档或测量结果 |
如果声称“一笔订单进入匹配的联系人”，就展示示例输入和预期的目标字段。说明这是文档化能力、示例工作流，还是与客户实测的结果。它们是不同种类的证据。
对选择连接器的商家，Brevo 连接器指南深入讲身份、同步状态与上线后可能的失败。功能清单在那里有用，问题是何时展示。读者尚未认出自己的工作时，还无法判断取舍。
功能是手段，不是借口
看同一个可能工作流的两种描述，两者都是示例。
功能优先：“具有版本化配置、事件路由和重放控制的可视化字段映射器。”
变化优先：“订单变化时更新正确的联系人。首次发送前审查字段映射，检查任何失败的记录。”
第二种说法更窄，也让产品承担更严格的义务：必须真的识别正确联系人，保持映射可审查，并暴露失败记录。好的文案让缺失的工作无处可藏。
因此，页面不能从“有重试”跳到“订单绝不会丢失”。重试可能失败；获接受的 API 调用可能留下错误字段。有关结果的承诺，需要检查结果，而不是背诵组件。
成本先于收益：以成果组织的页面，需要有人准确说明哪些行为已支持、哪些仍在计划中、哪些取决于客户设置。这比从路线图收集功能名称难。
文案无法删除任务步骤
本文讨论产品页面的说明。另一个产品问题是：用户看到结果前，是否必须打开新看板、授予额外权限、完成五步设置？清楚的文案不会缩短漫长的工作流。
第一项业务自动化指南从一项流程和一次成功检查入手。页面也应如此：选一项任务，解释变化的状态，让读者能找到测试方法。
然后留意下一个问题。如果读者反复问“我在哪里看结果”，成果仍太抽象；如果问“支持我的自定义字段吗”，页面已完成第一步，他们开始评估机制了。
先展示变化，再展示使它成真的部件。
常见问题
产品页面应该先说成果还是功能？
先说用户能识别的具体变化，再展示让它可信的功能和证据。详细规格仍是评估所需，应该容易找到。
怎样写成果而不作无依据的承诺？
明确起始状态、用户动作和可观察结果。区分已支持的产品行为和假设的客户收益，避免未经测量的数字。
成果优先的文案能让界面更简单吗？
不能。文案能解释结果，任务却仍可能有太多步骤。要单独测试达到结果的实际路径。