客户反馈分散在聊天和文档里，最费时的往往是逐条归类：有人说页面打不开，有人希望增加导出，还有人只是询问使用方式。本文用 Notion AI 的数据库自动填充，搭一个“原始反馈—分类建议—人工确认”的小工作台。

适合已经使用 Notion 的个人产品作者、客服和小团队。完成后应得到一个能回查原文、筛出未审核条目的反馈库。下面的记录和预期判断均为虚构练习，没有在真实客户资料或付费工作区中运行。

一、准备账号、权限和练习范围

这是网页办公流程，不需要服务器、API Key 或本地模型。进入自己的 Notion 工作区，新建一个仅自己可见的练习页面，先确认有创建数据库、修改属性的权限。

官方目前区分 Basic Autofill 与 Custom Agent Autofill：前者适合基于当前条目做摘要、提取和分类，包含在 Business、Enterprise 套餐中；后者能做更复杂的搜索和多步骤处理，并消耗 Notion credits。Free、Plus 的有限 AI 试用不能理解为长期开放全部自动填充能力。具体可用入口与额度以工作区为准。

本练习只用 Basic，不连接外部系统，也不让 AI 自动处理投诉。 若账号没有入口，仍可先建好人工反馈库；不要为了练习直接升级团队套餐。先用几条样本判断节省的审核时间是否值得成本。

准备五条去掉姓名、手机号、订单号的反馈。每条给唯一编号，原文放进对应数据库页面正文，不能只留在其他聊天里。

二、先设计字段，避免把“建议”当成事实

建议建立这些属性，名称可以自行调整：

  1. 反馈标题：标题类型，写编号和短名称，例如 F001／安卓导出失败。
  2. AI 分类建议：单选，预设“故障反馈、功能建议、使用咨询、其他”。
  3. AI 摘要：文本，保存一句话概括。
  4. 最终分类：单选，由人确认，不设 AI 自动填充。
  5. 审核状态：状态类型，默认“待审核”，另设“已确认、待补充”。
  6. 记录日期：日期类型，保存实际登记日期。

原始证据放正文，审核结果放属性。不从情绪强烈程度直接推断事故等级，也不让模型自行指定负责人、承诺修复日期。

可以手动创建表格数据库；也可以在页面输入 /database，选 Build with AI，描述上面的字段，预览后再确认。该创建入口有自己的能力边界：不能把“生成数据库结构”理解为同时创建了数据行、表单和自动化。先检查结构，再手动添加练习条目。

反馈原文经过AI建议再由人工确认的工作流程示意

三、把五条反馈写成独立页面

逐条打开数据库记录，把下面内容复制到各自正文。示例中的编号也写在标题中，方便核对行是否错位。

  1. F001：“安卓手机点导出后一直转圈，重试仍未拿到文件。没有测试其他设备。”
  2. F002：“希望能一次导出一周的数据，现在只能一天一天下载。”
  3. F003：“请问在哪里修改通知接收方式？我还没找到设置入口。”
  4. F004：“导出不好用。”
  5. F005：“上周提到的导出问题已经恢复，之前报错时的截图找不到了。”

为了暴露空内容问题，再建一条 F006，只填标题，正文留空。它不是正常客户反馈，而是验证工作台会不会凭空补齐事实的测试项。

不要把六条记录都塞进一个页面，否则自动填充的上下文和数据行就不再一一对应。原文后如果需要追加人工备注，请另起“人工备注”小标题，记录补充时间，避免误把后来的判断当成最初反馈。

四、先手动运行分类建议

点击“AI 分类建议”属性名，进入 AI Autofill 或 Set up AI Autofill，选择 Basic。依据该属性可见的选项配置分类，并先选择手动触发。不同语言界面名称可能略有差别。

如果界面允许填写自定义分类指令，可用下面的规则；若只有分类选项描述，就把相同边界写进描述。不要把提示词塞进某条反馈正文充当系统配置。

仅依据当前反馈页面正文，选择一个已有分类。
明确描述现有操作失败，归入故障反馈。
提出增加或改变功能的诉求，归入功能建议。
询问入口或操作方法，归入使用咨询。
信息不足、只是评价或无法区分，归入其他。
不要添加新分类，不推断原因，不修改最终分类或审核状态。

运行后逐条查看 F001 至 F006，暂不打开“页面编辑时自动执行”。这一步要确定字段类型和规则合适，避免每次修改备注都重新生成建议。

五、再配置摘要，保留“不知道”

为“AI 摘要”属性设置 Basic 自动填充，选择适合的摘要或自定义方式。若采用自定义，可输入：

只根据本页原始反馈，写一句不超过50字的中文摘要。
保留用户明确提出的现象或请求。
不要补充故障原因、受影响人数、解决时间。
正文为空时填写“无原始反馈，待补充”。
信息不足时明确写“描述不足，需补充”。
不把后来恢复的情况写成当前仍在发生的故障。

字数要求是输出目标，不能当成必然满足的限制器。重点核对 F005：合适的摘要应保留“此前出错、目前恢复”的时间关系；如果只写“导出发生故障”，就改变了事实状态。

Basic 的资料范围是当前行或页面内容，不会自动搜索互联网或整个工作区。需要跨页面寻找历史记录时，应单独评估其他功能和费用，不要把本流程的结果称为跨库查重或全量检索。

六、按预期检查，再人工落库

下面是人工设定的验收参考，不是声称 AI 已生成这些结果：

  • F001：建议“故障反馈”；摘要保留安卓、导出无结果，不能扩写成“所有设备故障”。
  • F002：建议“功能建议”；重点是按周批量导出，不能概括为现有导出不可用。
  • F003：建议“使用咨询”；不能因为找不到入口就断言系统缺少设置。
  • F004：可归“其他”，审核状态改成待补充；需要问设备、步骤、预期和实际现象。
  • F005：保留“已恢复”，人工判断是否作为历史故障记录；不能自动开新的紧急工单。
  • F006：必须表现为缺少原文，不能编造反馈人或问题详情。

逐条打开原文对照，再填写“最终分类”和“审核状态”。建议和结果保留两列，后续才能统计哪些类别容易误判。发现错误时先改规则，再重新跑测试条目；不要只把单个错误改掉，就认为分类器已经改善。

反馈库应检查空白输入时间关系与人工确认字段的示意

七、建立两个日常视图

先建“待审核”视图，仅显示未确认的条目，露出原文标题、建议分类和摘要。再建“已确认”视图，按最终分类分组，供团队安排后续处理。

统计只使用已确认结果。 否则同一批未经审核的建议容易被当成产品需求数量，导致团队围绕错误结论排期。少量条目可以人工查看；反馈增多后，再记录“原始条目数、已审核数、待补充数”，防止只统计看起来完整的数据。

确实需要自动运行时，先在副本里测试“新页面创建后”或“页面编辑后”的触发方式。观察空正文、补写正文、修改备注各会发生什么，再决定是否启用。自动摘要不是实时工单系统，不应承担必须立即通知客服的责任。

八、常见问题与排查顺序

  • 没有 AI Autofill：先确认数据库属性入口、编辑权限和套餐；普通页面里画出的简单表格不等于数据库。
  • 结果一直空白：检查属性是否启用、当前是否手动触发、该条页面正文是否确实有原文，再查看工作区用量提示。
  • 分类总是“其他”：检查选项是否过窄，以及反馈是否只有情绪评价。先补信息，不要靠强制分类制造准确率。
  • 摘要加入其他客户的情况：确认是不是误把多个反馈放在一页，或切换到了使用更广上下文的功能。
  • 人工结果被覆盖：把最终分类与 AI 建议分开，确认最终字段没有启用自动填充；必要时先停触发，再修正。

每次修改分类规则，另存一份规则文本并写明变更原因，例如“把只有情绪评价的反馈归为其他”。保留同一组测试条目的旧判断，用新规则重新比较。只有规则文字不同、输入样本相同，才能知道改善是否来自规则调整；随意换一批简单样本会掩盖问题。

第一次上线可限制在十到二十条非敏感反馈。记录每条人工审核耗时、误分类原因和补充问题，比只看“自动填满了多少格”更能判断是否适合团队。最终交付物是可追溯的反馈库和分类规则，而非一批看似整齐却没有原文依据的标签。

官方参考