TL;DR

• 一份不到 200 块的 Notion Business 订阅,目前是性价比最高的 Claude Opus 4.7 合规入口之一;
• 配合 ntn CLI + 官方 Skills 与 GitHub / Linear 集成,Notion AI 同时是文档主仓、模型入口、跨工具上下文聚合器;
• 一个人就能稳定跑起「CEO + 管家 + 工匠」三个 Opus Agent 接力的工作流,本文把整套打法和踩过的坑一次讲清。 上周我盘点手里的订阅,发现一件挺反直觉的事:我每天用得最重的那个 Opus 4.7,居然不是从 Claude 官网开出来的,而是从一份每月不到 200 块的 Notion 订阅里出来的。 一份订阅同时驱动了三个 Agent 跑了一周的活——这篇文章就是把这条路径完整讲清楚。

  一、先把账算清楚

  直接说结论:如果你只是想稳定、合规地用上 Claude Opus 4.7,Notion Business(年付方案折合每月 $20/人、月付 $24/人——都不到 200 块)目前是性价比最离谱的入口之一。 对比一下常见路径:

这里有几个关键事实需要点明:

• Notion AI 已经在 Agent 模式、Chat、Research 等场景把 Anthropic 最新模型作为默认选项之一,Opus 4.7 是其中规格最高的一档。
• Notion 的 AI 使用上限是「reasonable use」型软限制,日常写作、代码、研究类工作流基本碰不到。

  一句话:你花不到 200 块买的不只是一个笔记软件,是一个长期、合规、不会半夜崩的 Opus 入口。

  二、为什么这事儿对「一人公司」特别值

  一个人干活,最贵的从来不是模型 token,而是上下文切换和工具碎片化。 传统做法长这样:

• 需求/SPEC:飞书 or 本地 Markdown
• 任务管理:Linear / Trello / GitHub Issues
• 模型调用:Claude 官网 / API / Cursor 内置
• 代码:本地 IDE
• 知识沉淀:Notion / 本地知识库 每一层都要单独维护权限、单独同步状态。一个人扛 5 个 SaaS,迟早自己把自己淹死。 最近圈子里都在传 Karpathy 的「LLM Wiki」打法——用 Obsidian 给各路 Agent 维护一套本地知识库,人手抓 Markdown、自建索引、自己写同步脚本。技术上确实漂亮,但对一个人来说,折腾成本和维护成本都顶不住:vault 同步一坏,所有 Agent 的上下文一起断电,半夜还得自己来抢修。 我反过来选了另一条路:把 Notion AI 立成我所有 Agent 体系的「一等公民」——知识、任务、Agent 配置、产出全都走 Notion;本地只留临时缓存 (Git 仓、临时 Markdown),丢了重拉就行,主线永远不会断。更关键的是,Notion AI 现在已经原生集成了 GitHub 和 Linear,PR、Issue 也能在同一个对话窗口里直接读到——跨工具上下文也不用再装一堆 MCP / connector。 换个思路:把 Notion 当成项目主仓,所有「人读」+「Agent 读」的东西都放进去,模型直接来 Notion 里取上下文,本地 IDE 只负责跑代码。

  三、落地工作流:Notion 当主仓,本地负责执行

  下面这套流程我自己在几个项目仓库里已经跑了一段时间,可以直接抄。

  3.1 仓库结构在 Notion 里长这样

  关键点:SPEC 和实现计划是 Agent 的「第一手输入」,所以必须写得像给同事看,而不是给自己回忆用。

  3.2 在 Notion 里完成「想清楚」这一步

  1. 在 SPEC 页面用 Notion AI 的 Chat 起草需求,Opus 4.7 帮你把模糊想法拆成接口、数据结构、边界条件。
  2. 在「实现计划」页面让 Notion AI 基于 SPEC 页生成任务拆分,@mention SPEC 页让它直接读上下文。
  3. 自己再过一遍,把不靠谱的部分改掉。这一步绝对不要省——Agent 后面所有动作都是基于这份计划。

     3.3 用 ntn + Skills 让本地 Agent 按需读 Notion

     本地 Agent 接 Notion,主流就两条路:ntn** CLI + 官方 Skills,以及 **Notion MCP。我自己的主力是前者,后者作为补充。 先把三者关系一次性说清楚,免得后面混:

• ntn(CLI / 最底层):Notion 官方命令行工具,提供「读写 Notion」的原子能力——page get / search / update / 文件上传……装好走官方文档:Notion CLI · Get Started。读到的 Markdown 直接走 stdout,不需要先落盘、也不需要维护任何同步副本,本地 Agent 现用现拿就是 Notion 上的最新版本。
• makenotion/skills(Skill / 教 Agent 怎么用 ntn):Notion 官方维护的一套 Agent Skills(repo: makenotion/skills),里面的 notion-cli skill 本质上就是一份「怎么用 ntn 的说明书」——告诉 Claude Code / Codex / Cursor 这类支持 Skills 的客户端:什么时候该调 ntn、调哪个子命令、参数怎么拼、结果怎么解读。Agent 不用自己去摸 shell,装一行就能用:

  npx skills add makenotion/skills
  

• Notion MCP(另一种接入方式):把 Notion 的能力以 MCP server 形式暴露给 Agent,适合「Agent 实时联机翻 Notion」。优点是即插即用,缺点是调用粒度细——一次只能拿一小块,凑齐上下文得反复调,token 烧得快,也不太可控。 我自己的选择是:让 Skill + ntn 当主力,MCP 作为某些场景下的补充。原因是 ntn + Skills 把 Notion 当成一个显式的、按需获取的数据源:读什么、写什么由 Skill 明确控制,跑起来更可预测,也更省 token。 日常用法分两层。 一、写脚本 / 手打命令时,直接用 **ntn**。

  # 直接拿到 SPEC 页的 Markdown,要给哪个 Agent 用,管道一下就行
  ntn page get <spec-page-url>
  

  没有 -o、没有 .context/,也没有「下次不同步怎么办」的问题——Notion 上改完下一秒调,拿到的就是新的。 二、在 Claude Code / Codex 里用时,让 Skill 替你调。加载了 notion-cli skill 后,本地 Agent 看到的不再是一堆 shell 命令,而是「读 Notion 页」「写 Notion 页」「查询」这几个明确的能力。需要 SPEC 或实现计划时,Agent 自己实时去 Notion 读,一条任务就变成:

  读 <实现计划页 URL>,按 plan 第 2 步实现对应模块;写完用 notion-cli skill 把今天的开发日志写回「开发日志」数据库。

  3.4 写回 Notion,形成闭环

  本地跑完一轮:

• 提交 commit,记下号。
• 让本地 Agent 顺手写一条开发日志,通过 ntn / notion-cli skill 推回 Notion 的「开发日志」数据库。
• 把决策、踩坑、接口变更作为新条目追加到「知识沉淀」——注意是「新建页」,不是让本地 Agent 去改既有页面(下面这条原则会说清楚)。 下次再开活,Notion AI 在 Notion 那头继续读这些日志和沉淀,它和本地 Agent 看到的是同一份事实。这才是「主仓」的意义。

  经验之谈:本地 Coding Agent 可以读、可以新建,但不要让他们改既有内容 我自己折腾过几轮——把 OpenClaw、Pi Agent、Claude Code 这类本地 Coding Agent 接到 Notion / 飞书的文档和知识库里直接编辑,结论很明确:读没问题,新建一张干净的新页也凑合,但去改既有页面基本一团糟。 这类 Agent 的训练目标是改代码、改文件,对 Notion / 飞书这种「结构化富文本 + 数据库」的语义不熟,常见翻车现场:

  • 格式全乱、标题层级错位、表格被打散;
  • 以为自己「在精简」,把整段内容删到只剩一句摘要;
  • 不认 schema,数据库属性直接写错字段。 所以我的规则非常死:本地 Coding Agent 只允许「读 + 新建」(ntn page get** / **search,以及「新建一张日志卡」这类原子动作),改既有页面一律交给 Notion AI 自己。Notion AI 是为 Notion 的内容结构而生的,改起来不会糊;本地 Agent 一旦动到既有富文本 / 数据库行,大概率翻车。

    3.5 让 Notion AI 直接读 GitHub PR 和 Linear Issue

    到这里还差最后一块拼图——代码协作系统。 以前我以为这一块只能调本地 Coding Agent 去读 仓库:实际上 Notion AI 已经可以原生集成 GitHub 和 Linear,在 Chat / Agent / Research 里直接 @ 一个 PR、Issue 或 Repo,diff、评论、状态、关联 Issue 都会被拉进上下文。 几个常用姿势:

• 写周报 / 变更志。 不用自己复制 commit 标题;让 Notion AI 读本周合并的 PR + 关掉的 Linear Issue,顺手对齐到「开发日志」。
• 拿 PR 跟 SPEC 对齐。 把 SPEC 页和某个 PR 一起 @ 进去,让 Opus 检查这个 PR 是不是按 SPEC 实现的、有没有漏掉的边界条件;比人翻 diff 快一个量级。
• 生成 Release Note。 丢一个 Milestone 或 Linear Project,Notion AI 拉出全部 PR 和 Issue,自动按「用户看的」/「开发看的」两个视角各写一份。
• 倒查 Issue 迹象。 「这个 bug 上次怎么调的」直接丢问题 ID,Notion AI 会把相关 PR 、评论、决策记录一起给你。 对一人公司来说,这一层的价值不是「少写一个脚本」,而是让 Notion AI 终于同时扮演三个角色:文档主仓、模型入口、跨工具上下文聚合器。Notion / GitHub / Linear 三路数据在一个对话窗口里齐活,不需要另装 GitHub MCP、不需要另接 Linear API。

  四、场景:用 Notion AI 的 Opus 当「调度中枢」驱动多 Agent

  上面那套不是纸上谈兵。我自己的工作区里已经在跑一套「多 Agent 接力」机制,跑了几轮下来沉淀出一套硬规则,下面挑能直接抄的那部分讲。 核心设计只有一句话:所有 Agent 共用一张 Notion 数据库当「消息总线」,只通过任务卡异步通信,不允许直接相互调用。 任务的拆解、分配、验收交给 Notion AI 里的 Opus 4.7;管家、工匠这些本地 Agent 则定时轮询这张数据库,自己拉属于自己的任务。

  4.1 角色表:一人带一群 Agent

CEO 直接挂在 Notion AI 上做调度中枢(用自定义 Agent + 指令页设定);管家 / 工匠 是我自研的本地 Agent 框架 OpenClaw 里的两个角色——你可以理解成「把 Notion 任务卡翻译成对本地 Coding Agent / 工具调用」的中间层,模型用的是 Kimi。

4.2 消息总线:一张 Notion 数据库 + 定时轮询

整套机制里没有任何 RPC、Webhook、消息队列——就一张普通的 Notion 数据库,我把它叫「消息总线」。结构非常朴素:

• Assignee(人 / Agent):这张卡归谁干
• 状态(待开始 / 进行中 / 待验收 / 已完成 / 阻塞 / 失败 / 已取消)
• 依赖(自关联):必须等这些任务都到「已完成」才能启动
• 优先级、创建时间:Agent 拉任务时的排序依据 「总线」不靠推,靠拉。 CEO、管家、工匠各自起一个定时轮询(我自己是每小时一轮,可按节奏调),每轮只做同一件事:

  查这张数据库:Assignee = 我 且 状态 = 待开始 且 所有依赖都已完成,按优先级取第一条。 取到了就接棒——改卡状态为「进行中」,跑完写产出 + 转「待验收」;取不到就睡到下个周期。整套机制里没有任何推送:Notion 不给 CEO 推、CEO 也不给管家推。任务卡才是唯一事实,Agent 只是周期性地来问一句「有我的活吗?」。 这套 pull 模式对一人公司特别合用:

• 不用搭 Webhook 服务。一台个人开发机 + 一个 Notion 集成 token,什么都不用对外暴露。
• 掉线无所谓。Agent 挂了再起,下一轮轮询自动追上,任务不会丢。
• 可以随时插队。手动把一张卡的 Assignee 改成另一个 Agent,下一轮它自己就会捞走;不需要重启任何服务。
• 天然限流。轮询间隔就是最粗暴的速率上限,Opus 配额不会被突发任务打爆。 唯一的取舍是轮询频率 vs 实时性:周报这种活,3 分钟延迟完全无感;但你也别指望它接「来电立刻接听」级别的实时任务——那种活本来就不该塑进这套架构里。

  4.3 一个任务如何被 Notion AI 推动

  以「写个本周周报」为例:

  1. 我在「AI 协作任务」数据库里建一张卡:标题、验收标准、Assignee = CEO、状态 = 待开始。
  2. CEO(Opus) 被触发,读任务卡、读依赖产出,拆出 T-002/T-003 几个子任务(收集本周 commit / 抽点 / 成文),分别指派给管家和工匠。
  3. 管家 从工作日志库里筛选本周重点,写成产出页。
  4. 工匠 调本地 Claude Code / Codex 拉 diff、生成代码说明,再回写 Notion。
  5. 所有子任务 待验收 后,CEO 直接通过 GitHub / Linear 集成 @ 对应的 PR 和 Issue,逐项对验收标准,「通过/打回」——这一步不需要工匠反复拉 diff。
  6. 所有子任务完成,CEO @ 我做最终验收。 整个过程中 我只动了两次:开头建卡、结尾验收。中间的拆解、分配、接力、质量门,是 Notion AI 里的 Opus 在跑。

     4.4 为什么这套能跑起来

     踩过几轮坑之后,我把这套机制总结成几条硬规则,缺一条接力链都会断:

• 任务卡是唯一事实源。配上上一节那张「消息总线」数据库,Agent 之间永远不会 RPC,只会写卡 / 读卡。换来三样东西:可观测(每一棒都有据可查)、可中断(任意一步都能由人改写任务卡介入)、可复盘(整条链路天然就是 SOP 素材)。
• 任务卡正文只留四个区块:## 任务描述、## 验收标准、## 产出、## Baton Log(交接说明)。数据库字段只放用得上视图筛选 / 看板分组的结构化元数据,其余全部下沉到正文——字段不会爆,Agent 拿到的卡也始终长一个样。
• 产出页 ≠ 任务卡正文。每个产出都是独立 Notion 页,命名格式 【YYYY-MM-DD】【T-{ID}】【标题】,后续 Agent 直接引用不需摘要(摘要 = 信息失真放大器)。
• 「待验收」是写在状态机里的质量门。进行中 → 待验收 → 已完成 三档,Agent 不能跳步;转「待验收」之前必须逐条勾完验收标准,任何一项没勾就不许转态——这是拦截 Opus「自报完成」的核心闸门。
• 汇聚节点必须由具备「综合判断」能力的实例担(默认就是 CEO)。并行任务的结果不是简单拼接,而是要重新判断一次:谁的产出更可信、缺什么、要不要补一棒。这条不守,多 Agent 立刻退化成「多份没人对账的草稿」。
• Coding Agent 不直接读 Notion。工匠负责翻译 + 回写,避免 Codex / Claude Code 跑完没人记账的断链。 还有一条不是规则,是态度:异常处理宁可让人兜底,不要让系统自动兜底。 我刻意没做超时重试、CheckPoint 失败路由、执行次数上限这些自动化——一人公司规模下,自动恢复带来的调试成本远大于人工裁决,把异常显式抛给我反而最省心。

  4.5 这个场景背后的「不到 200 块」价值

  换个路径:如果你走 API + 自建 Orchestrator,要同时处理模型调用、持久化存储、状态机、验收门、权限、可观测性。5 个服务 × 一个人,人手都不够。 而 Notion Business 一份订阅,顺手就把「数据库 / 状态机 / 权限 / Webhook / 可观测」搞好了,Notion AI 里还送了三个跑 Opus 的「员工」。

  这才是「一人公司 + 多 Agent」能真正跑起来的原因——不是模型多便宜,是脚手架白送。

  五、有几个坑必须提前说

• 代码相关的活,Notion AI 不如 Claude Code / Cursor 顺手。 Notion AI 的强项是「读文档、写文档、跨页推理」;真正写代码还是放回本地 IDE。
• MCP / CLI 的权限要收紧。 Notion 是你的主仓,一个写错的 updatePage 就能糊掉一整页。建议先用只读权限把读链路跑通,再小心地开写权限。
• 「reasonable use」是软上限,不是无上限。 我自己日常重度用没碰到过限速,但如果你打算批量跑 Research / Agent 任务,建议先小流量试一周,别一上来就把它当 API 用。
• 跨人协作要先规划 schema。 任务库、产出页、知识沉淀几个数据库的 schema 一旦定下来,后面 Agent 的指令、Skill 都会依赖它,改一次成本不低。建议先把单人版跑顺再扩团队。
• Notion AI 的 GitHub / Linear 集成是「读」强、「写」弱。 拉 PR、Issue、评论做上下文非常好用;但要它直接合 PR、改 Issue 状态,目前还是建议人工或本地 Agent 来做。
• 指令页(自定义 Agent)要管版本。 改一次 CEO 的指令页等于换了一次「员工入职手册」,建议像管 prompt 一样在 Notion 里留 changelog,出问题能回滚。 说到底,这套打法的核心不是「Opus 多便宜」,而是用一份订阅同时买到了三样脚手架:稳定的模型入口、能当数据库用的主仓、原生跨工具上下文。对一个人扛的「一人公司」来说,省下的不是订阅费,是「不用自己维护一堆 SaaS 胶水」的精力。

  延伸阅读

• Notion CLI · Get Started——ntn 官方上手文档
• makenotion/skills——Notion 官方维护的 Agent Skills 仓库
• Notion Pricing——Business 方案的最新定价与 AI 配额说明