讲清输入、输出，以及用户仍需负责的工作

把能力名称改成能尝试的任务

“AI 文档智能”没有告诉买家该拿什么来试。更具体的任务可以是：从支持格式的发票中提取供应商、发票号和明细。写落地页前，先说明输入格式、输出内容和人工检查步骤。

给 Afield 当前产品事实与样例，也说明不支持的格式和需要人工复核的情况，避免草稿把有限能力写成无所不能。

发票只是说明演示设计的例子，并不是 Afield 的产品功能。最终演示应使用你自己产品经过测试的样例。

买家可能还要知道结果怎样进入已有系统、工具需要哪些权限，以及失败怎样处理。让 Afield 查找与该流程相关的公开讨论，区分从业者经验和厂商介绍。

再围绕一个实际评估问题完成页面。涉及数据处理或集成范围时，依据产品文档和当前约定写，不让文案自行编出令人安心的答案。

假设产品从发票提取字段。干净样本只能说明系统能产出结果。买家更需要看的是模糊情况：一张发票有两个日期，一张是贷项通知单，还有一个供应商名称与旧记录很相似。先确定用户需要审核什么，再解释自动化能帮到哪一步。

可以让 Afield 准备演示 brief 和说明，但要提供实际支持的行为与允许公开的样本。要求把输入、结果字段、未解决项和用户纠正过程串在一起。不要为了让故事完整，就虚构置信分数或产品里没有的审核按钮。

日期需要确认时，展示真实产品怎样表达这个不确定性，再解释原文中哪一处能解决它。文章要区分“提取出了一个值”和“判断这个值在业务中意味着什么”，不能把两步混为一次成功。

开头可以直接写：“这个例子包含开票日期和服务日期。我们展示它们分别进入哪个字段，以及审核者在哪里确认对应关系。”正文必须把这一例子做完，而不是再次重复自动化财务的价值。

有的买家在意纠错工作量，有的需要导出到既有系统。这是不同的后续内容。保留原例子，补上对应的下一步，不要每次都把演示扩成更多功能名词。

如果展示测量结果，要保留样本、原来的做法和审核工作。提取更快不一定代表审核后的处理更快，尤其当异常需要更多人工时。官网应把测量的任务讲清楚，让读者判断是否类似自己的情况。

截图应清楚展示相关控件或输出，流程图可以说明交接。不要把虚构评分、无来源准确率或装饰性仪表盘做成实测结果的样子。

要求完整演示脚本，并对照产品逐项检查。试用检查表（英文）帮助组织评估；逐条检查文案主张（英文）帮助修掉空泛承诺。