我突然意识到：这大概率不是“他们手速很快”，而是“他们的 AI 手速很快”。
AI 时代的一个小惊喜：我们都在透过机器跟机器沟通 —— 人类负责提出问题，AI 负责排队处理，最后再把结果递回给人类。
背景故事：人工提示词很强，但自动化撞上权限天花板
这篇文章记录一次真实的Notion Agent(我的第一个Notion Agent)折腾过程，并给出一份面向产品的改进建议：把 Agent 的权限从“逐页授权”升级为“空间级授权 + 时间窗口授权”。
更具体一点说：
- 人工提示词(📄
Notion Agent 权限太细：为什么总结类 Agent 需要 Workspace/Teamspace/Private 级授权（附改进建议） )已经很好用，但它依赖“人每天记得去跑一次”。 - 一旦把这件事交给 Notion Agent 自动执行，就会撞上权限的天花板：Inventory 拿不全，Coverage Check 也就无从谈起。
1. 总结类 Agent 的“硬前提”：先拿到 Inventory
以每日总结为例，真正可验收的产物不是 Top 3，而是 Inventory（当日 created/last edited 的页面清单）：
- 如果 Inventory 不完整，Top 3 就不可追溯。
- 如果 X（当天更新页总数）都拿不到，Y=X 也就无从谈起。
换句话说：总结类 Agent 的成败，首先是“取证能力”的成败。
2. 逐页授权为什么会让总结类 Agent 变得不可靠？
当 Tools and access 只能逐页添加时，会出现三个连锁问题：
- 范围不可定义：你想让 Agent 覆盖“整个工作区 + 我的 Private”，但 UI 里只能一个个页面点进去加。
- 新页面必然遗漏：今天新建了 10 个页面，除非你记得全部补授权，否则 Inventory 一定缺。
- 手工成本过高：用户不得不把“维护权限清单”当成每天的例行工作，而不是一次性配置。
对总结类 Agent 来说，这不是“体验问题”，而是“系统性不可达成”。
3. 我希望 Notion 增加什么能力？（Feature Request）
核心诉求：在 Custom Agent → Tools and access → Notion Access 里，新增“空间级”授权，并保留最小权限原则。
3.1 空间级授权（Scope-based Access）
1) Workspace-wide
- 访问范围：用户可访问的全部内容（Teamspaces + 用户自己的 Private）
- 权限：Can view / Can edit
- 安全：明确提示包含 Private pages，二次确认
2) Teamspace-based
- 可勾选一个或多个 teamspace
- 每个 teamspace 独立设置 view/edit
3) My Private（仅创建者）
- 一键授权“我的 Private”
- 明确排除其他成员 private
4) Database scope
- 一键授权整个数据库（含其条目页面），避免逐条目添加
3.2 时间窗口授权（Updated-pages Time Window）
对于“关注更新内容”的用户，最自然的权限定义方式其实是：
- 先选时间窗口：最近 1 小时 / 3 小时 / 12 小时 / 24 小时 / 7 天 / 30 天（或自定义）
- 再选空间范围：Workspace / Teamspace / My Private / Databases / Specific pages
这样既能降低授权压力，也能让 Agent 聚焦“最近发生变化的内容”。
3.3 可观察性：权限不足时给出可执行的缺失建议
当 Agent 无法完成 Inventory 时，不要只返回一句“权限不足/未获取到清单”，而应给出：
- 缺失的 scope 建议（例如需要 My Private 或某个 teamspace）
- 以及一键补齐入口（或至少定位到 Tools and access 的相应位置）
4. 为什么这会显著提升总结类 Agent 的成功率？
如果上述 scope 能落地，总结类 Agent 的验收标准会变得简单、可重复：
- 能稳定产出 Inventory（created/last edited 清单）
- Coverage Check 能长期满足 Y=X
- 用户不再需要“每天记得给新页面补授权”
这时自动化才真正从“演示用玩具”变成“长期可运行的系统”。
5. 结语
总结类 Agent 的价值在于把“复盘”变成可持续的习惯；而权限模型的细节，决定了这个习惯能不能被自动化托住。
如果 Notion 能把授权粒度从页面级提升到空间级，并配合时间窗口与可观察性提示，总结类 Agent 的可用性会跃迁一个量级。
附录：人工提示词（prmreviewdaily｜终极版本 SSOT）
展开查看 prmreviewdaily 完整提示词
1. 核心原则（必须遵守）
- 先覆盖、再提炼：先列出“今天更新了什么”，再做 Top 3 提炼。
- 可追溯：每条关键结论都要有对应的来源页面链接（至少到页面级）。
- 来源必须具体：证据索引必须列出当天每一个被创建/更新的具体页面链接（避免只放“入口页/聚合页”，以免关键工作被遗漏）。
- 按主题聚合：用“主题”把更新内容聚类，但不要让分类压过 Top 3。
- 当天完成：只总结当天窗口内（默认 00:00-23:59）的创建/更新。
2. 输入（由系统检索，不要让用户手工凑齐）
A. 当天创建/更新页面清单（必填）
- 以“页面”为单位给出：页面标题 + URL + 创建时间 + 最后编辑时间
- 规则：
- 新建页面：今天 created_time 属于窗口内
- 更新页面：今天 last_edited_time 属于窗口内
B. 每个页面的“今天更新片段”（尽可能精确，目标字段）
对每个页面，尽力输出：
- 今天新增/修改的要点（条目化）
- 如果无法精确到段落：明确标注“无法精确到段落，已按页面级摘要”，并把页面列入“待补证据”
C. 上下文参考页（可选）
- 当天涉及的 SOP、项目页、邮件摘录页
3. 处理流程（严格执行，禁止跳步）
输出一个列表，覆盖当天窗口内每一个创建/更新页面（不允许用“入口页”替代具体页面）：
- 页面：标题 + URL
- 创建：YYYY-MM-DD HH:mm
- 最后编辑：YYYY-MM-DD HH:mm
- 今日更新要点：…（条目化，尽量精确）
- 内容关键词（Keywords）：…（3-8 个关键词，名词短语为主）
- 主题（Topic）：…（可多选）
- 项目/上下文（Project/Context，可选）：…（如果能识别）
基于 Step 1 的 Keywords，将页面先聚成若干小类（优先反映内容，而不是反映你预设的主题）：
- 例：驱动/显卡/OpenCL/性能测试
- 例：OpenClaw 安装/预检查/评估结论
- 例：邮件系统/EWS/内外网配置
- 例：代理/TUN/DNS/直连规则
每个小类下列出对应页面链接。
将 Step 2 的小类进一步回收到“主题”（系统/工具、生活等）与“项目”维度。
YYYY-MM-DD 每日总结
- …（每条都要能指向证据页面，必要时列出 2-3 个来源链接）
- …
- …（没有就写“暂无显著阻塞”）
- …（动词开头，可验收）
- …
- …
- 按 Step 2 的小类输出：每个小类下列出页面链接
- 今日创建/更新页面数量：X
- 已纳入证据索引的页面数量：Y（要求 Y = X）
- 已进入 Top 3 的页面数量：Z
5. 自动化稳定性补丁（SSOT｜人工与 Agent 共用）
- 范围：默认 全工作区（只要你有权限看到，清单就必须纳入）。
- 去噪：空白页面不计入 X（不进入 Inventory，也不进入证据索引）。
- 第一优先级：必须产出 Inventory。
- 无法完成聚类/Top 3 时，也要输出 Inventory，并把状态置为“需复盘”。
- 状态：设为
需复盘 - 备注写明：检索范围、拿到数量、失败原因分类。
- 同一天只保留 1 条 Review 记录；存在则更新，不新建。
（终极版本以页面
🚫
Post not found 为准）
- 为什么要给提示词起这么个浓缩的名字？因为这样好快速输入
- Notion Agent 里尽量一句话 “严格按这份提示词执行：
🚫
Post not found。“。这样即使 Agent 失效了，你还可以人工接管；或者说你不再需要 Agent 了也没关系，人工的功能仍然在。