Notion 四件套（知识捕获 / 会议智能 / 研究文档 / spec 转实施）+ GitHub 两件（处理 PR review 意见 / 修挂的 CI）——知识从对话沉淀到文档、再从文档驱动工程的闭环。
一句话定位
知识的一生被切成四段接管：聊完的东西进 Notion（捕获）、开会前后有备料与纪要（会议智能）、跨源研究写成文档（研究文档）、文档里的 spec 变成实施计划与任务跟踪（spec 转实施）；GitHub 两件把 review 与 CI 的苦活接走。
Notion 四件套
notion-knowledge-capture · 知识捕获
- 对话与决策→结构化 Notion 页面；把聊天/笔记变成 wiki 条目
- 知识管理的第一公里：不沉淀的对话是组织的失忆
notion-meeting-intelligence · 会议智能
- 会前：Notion 上下文 + Codex 研究→议程与材料
- 会后：决策回写——会议的开与收都接在知识库上
notion-research-documentation · 研究文档
- 跨 Notion 检索 + 综合研究→结构化文档
- 多源综合的 Notion 版实现
notion-spec-to-implementation · spec 转实施
- Notion 里的 PRD/功能 spec→实施计划、任务与进度跟踪
- 文档与工程的断点（「写了没人做」）被显式缝合
GitHub 两件
gh-address-comments · 处理 review 意见
- 开 PR 分支上的 review/issue 评论逐条处理；先验证 gh 认证
- review 回复是开发者的「日常税」——技能按 PR 模板惯例逐条消化
gh-fix-ci · 修挂的 CI
- GitHub Actions 挂了→
gh查日志→定位→修 - 与 oncall-kit 的事故循环异曲同工，粒度更小（单 PR 级）
方法论精华
1. 知识链的「断点缝合」设计：四件套各自缝合一个断点——对话↔文档（捕获）、会议↔知识库（智能）、研究↔产出（文档）、spec↔工程（实施）。组织的知识流失都发生在断点上，技能按断点组织而非按功能组织。
2. spec 转实施是文档的「出口」：多数团队的 spec 死在写完那天；转实施技能让文档直接生成任务与跟踪——文档没有工程出口就不该写。
3. 小粒度自动化：gh 两件都是「十分钟苦活」级别——自动化的价值密度与任务大小无关，与频率和烦人程度正相关。
编者注
Notion 四件套加上 cowork 插件的 productivity（两层记忆），恰好拼出完整的「个人/团队知识基础设施」：一边是 Claude 的记忆，一边是 Notion 的沉淀。对一人公司：捕获 + spec 转实施两件就够用。