Notion 知识库数据库设计最佳实践基于 awesome-codex-skills 的 notion-knowledge-capture 实战指南【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills在 Codex 驱动的知识捕获knowledge capture工作流中数据库Database是承载一切结构化内容的骨架无论捕获的是决策记录、FAQ、How-To 指南还是团队 Wiki最终都要落进一个设计良好的 Notion 数据库。本文以 awesome-codex-skills 仓库中 notion-knowledge-capture 技能 的官方指南 database-best-practices.md 为核心骨架结合仓库内六套参考数据库 schema、真实示例与评估用例系统讲解知识捕获数据库的五大设计原则、用Notion:notion-create-database建库的具体方法、建库前抓取 schema 的关键步骤以及一套可直接照用的数据库选型决策表。读完本文你将能独立设计、创建并长期维护一套可检索、可扩展、可持续演进的团队知识库。一、为什么数据库设计决定知识捕获的成败notion-knowledge-capture 技能的核心工作流是把对话与零散笔记转化为结构化、可链接的 Notion 页面。从 SKILL.md 的流程看一次完整捕获要经历定义捕获内容 → 定位目标数据库 → 提取并结构化 → 创建/更新页面 → 链接与呈现五个阶段其中第二步定位目标数据库直接决定了后续所有页面创建的质量正确的 schema 意味着每次Notion:notion-create-pages写入的属性都能被检索、被过滤、被视图正确归类错误的 schema 意味着知识虽然存进去了但无法通过视图、筛选和关系链接被再次发现沦为数字垃圾场。因此 database-best-practices.md 开篇即给出结论先按通用原则设计好数据库再让 Agent 按 schema 写入这是知识库一次建成、长期可复用的前提。二、五大核心设计原则原文档给出的五条原则是知识库设计的通用纲领每条都对应可落地的操作1. 保持简单Keep It Simple只从核心属性起步例如文档库的Title、Type、Tags、Status、Owner按需增量添加属性而不是一开始就铺满二十个字段避免过度设计Dont over-engineer——每多一个属性Agent 写库时多一分出错可能维护者每季度多一分整理成本。2. 使用一致的命名Use Consistent NamingTitle 属性作为主标识符承载条目的是什么Status追踪生命周期如Draft → Final → DeprecatedTags提供灵活的交叉分类Owner明确责任人保证每一条知识都有人维护。3. 包含元数据Include Metadata创建/更新时间戳Notion 的created_time、last_edited_time可自动填充负责人或维护者最近审查日期Last Reviewed状态指示器Status。元数据的价值在后续运维中体现它支撑了Needs Review需要审查Draft Docs草稿文档这类视图的自动筛选让知识库不会因内容过期而腐烂。4. 提升可发现性Enable Discovery充分使用 Tags允许从多维度切入检索创建常用视图按类型分组、按最近更新排序等链接相关内容用 relation 在条目间建立语义关联使用清晰明确的标题让搜索结果一望即知。5. 为规模做规划Plan for Scale尽早考虑过滤器属性类型的选择select vs multi_select vs relation决定了未来能否高效过滤用 relation 表达连接例如 FAQ 的Related Questions、决策日志的Related Decisions考虑搜索标题措辞、属性命名都要符合团队成员的搜索习惯用分类组织如按部门Engineering/Product/Design或内容类型划分。三、创建数据库Notion:notion-create-database完整实战原文档以团队文档库Team Documentation为例给出了完整的建库 JSON。下面是可直接复制使用的版本其中每一项属性都对应 Notion API 的属性类型{ parent: {page_id: wiki-page-id}, title: [{text: {content: Team Documentation}}], properties: { Type: { select: { options: [ {name: How-To, color: blue}, {name: Concept, color: green}, {name: Reference, color: gray}, {name: FAQ, color: yellow} ] } }, Category: { select: { options: [ {name: Engineering, color: red}, {name: Product, color: purple}, {name: Design, color: pink} ] } }, Tags: {multi_select: {options: []}}, Owner: {people: {}}, Status: { select: { options: [ {name: Draft, color: gray}, {name: Final, color: green}, {name: Deprecated, color: red} ] } } } }对照 documentation-database.md 中的完整 schema 表可以把这个 JSON 中的每个属性类型映射到它的实际用途PropertyTypeOptionsPurposeTitletitle-Document nameTypeselectHow-To, Concept, Reference, FAQ, Decision, Post-MortemCategorize content typeCategoryselectEngineering, Product, Design, Operations, GeneralOrganize by department/topicTagsmulti_select-Additional categorization (languages, tools, topics)StatusselectDraft, In Review, Final, DeprecatedTrack document lifecycleOwnerpeople-Document maintainerCreatedcreated_time-Auto-populated creation dateLast Updatedlast_edited_time-Auto-populated last editLast Revieweddate-Manual review tracking3.1 属性类型选型要点从源码级 schema 可以总结出三条选型经验select 用于有限且稳定的枚举如Type、Status、Category。枚举值在设计时要尽量穷尽因为 Notion 的 select 选项维护成本会随条目增多而上升。multi_select 用于开放标签Tags保持options: []空数组起步让 Agent 在写库时按需自由补充这正是保持简单 灵活分类的平衡点。people 用于责任归属Owner直接绑定 Notion 成员未来可按人筛选出某人名下所有待审查文档。3.2 建库前必须抓取 schema原文档特别强调了一个易被忽略的关键步骤在创建页面之前务必先抓取目标数据库以获取准确 schemaNotion:notion-fetch id: database-url-or-id这一步返回数据库的精确属性名与属性类型。为什么要这样做因为Notion 数据库可能已被团队成员手工修改过新增了Priority、删除了Category与参考文档中的 schema 不再一致属性名拼写错误如把Last Reviewed写成LastReviewd会导致写入失败或属性丢失只有拿到实时 schemaNotion:notion-create-pages才能准确填装属性。这一点在 SKILL.md 的工作流中被固化为固定动作步骤 3 用Notion:notion-search→Notion:notion-fetch拉取上下文步骤 4 再用Notion:notion-create-pages按 schema 建页。示例 conversation-to-faq.md 中Agent 先notion-search找到 Deployment FAQ 数据库再notion-fetch拿到Question/Category/Tags/Last Reviewed的实际属性随后才执行创建——这就是先 schema、后写入的完整闭环。四、数据库选型指南六套参考 Schema 一次讲透原文档的选型表给出了六种典型需求对应的数据库。仓库 reference/ 目录为每种数据库都准备了独立的 schema 与最佳实践文档下表为完整映射链接已转换为仓库根目录相对路径NeedUse This DatabaseGeneral documentationDocumentation DatabaseTrack decisionsDecision LogQA knowledge baseFAQ DatabaseTeam-specific contentTeam WikiStep-by-step guidesHow-To Guide DatabaseIncident/project learningsLearning Database4.1 通用文档库Documentation Database最适合作为团队知识库的起点库承载所有类型的文档。除前文 schema 外documentation-database.md 还推荐了五种内置视图By Type按 Type 属性分组By Category按 Category 属性分组Recent Updates按 Last Updated 降序排序Needs Review筛选 Last Reviewed 距今超过 90 天Draft Docs筛选 Status Draft其中Needs Review视图是元数据驱动运维的典型例子——Last Reviewed是唯一的date手动属性配合 90 天阈值即可让文档审查自动化、常态化。4.2 决策日志库Decision Log / ADR用于记录带上下文的决策其价值在于为什么。核心 schema 见 decision-log-database.mdPropertyTypeOptionsPurposeDecisiontitle-What was decidedDatedate-When decision was madeStatusselectProposed, Accepted, Superseded, DeprecatedCurrent decision statusDomainselectArchitecture, Product, Business, Design, OperationsDecision categoryImpactselectHigh, Medium, LowExpected impact levelDeciderspeople-Who made the decisionStakeholderspeople-Whos affected by decisionRelated DecisionsrelationLinks to other decisionsContext and dependencies每条决策页还应遵循 ADR 内容模板Context为什么需要该决策→ Decision决定了什么→ Rationale为什么选它→ Options Considered备选方案与取舍→ Consequences正负预期结果→ Implementation如何执行。示例 decision-capture.md 完整演示了REST 迁移 GraphQL决策的捕获过程——它甚至把被否决的选项Keep REST、gRPC连同拒绝理由一并记录这正是 ADR 与普通会议记录的本质区别。注意Status枚举中Superseded的存在决策会被新决策推翻用状态而非删除来表达该决策已过时可以保留完整决策历史。4.3 FAQ 数据库用于沉淀高频问题schema 见 faq-database.mdPropertyTypeOptionsPurposeQuestiontitle-The question being askedCategoryselectProduct, Engineering, Support, HR, GeneralQuestion topicTagsmulti_select-Specific topics (auth, billing, onboarding, etc.)Answer TypeselectQuick Answer, Detailed Guide, Link to DocsResponse formatLast Revieweddate-When answer was verifiedHelpful Countnumber-Track usefulness (optional)AudienceselectInternal, External, AllWho should see thisRelated QuestionsrelationLinks to related FAQsConnect similar topicsFAQ 页的内容模板强调先短答后长答Short Answer12 句快速响应→Detailed Explanation完整上下文→ 可选的Steps/Screenshots→Related Questions→Additional Resources。这一结构与 conversation-to-faq.md 中把部署排障对话拆成 3 条 FAQ的实践完全吻合且该示例展示了date:Last Reviewed:start与date:Last Reviewed:is_datetime: 0这种带类型前缀的属性写法是notion-create-pages处理日期属性的关键细节。4.4 团队 Wiki 数据库承接不属于其他库的团队专属内容schema 见 team-wiki-database.mdPropertyTypeOptionsPurposeTitletitle-Page nameSectionselectGetting Started, Processes, Tools, Reference, OnboardingWiki organizationTagsmulti_select-Topic tagsOwnerpeople-Page maintainerLast Updatedlast_edited_time-Auto-trackedVisibilityselectPublic, Team Only, ConfidentialAccess level其最佳实践强调每页必有 Owner与Visibility 分级适合跨团队共享但又需要权限边界的知识场景。4.5 How-To 指南库面向操作流程schema 见 how-to-guide-database.mdPropertyTypeOptionsPurposeTitletitle-How to [Task]ComplexityselectBeginner, Intermediate, AdvancedSkill level requiredTime Requirednumber-Estimated minutes to completePrerequisitesrelationLinks to other guidesRequired knowledgeCategoryselectDevelopment, Deployment, Testing, ToolsTask categoryLast Testeddate-When procedure was verifiedTagsmulti_select-Technology/tool tags两个设计亮点标题强制统一为How to [Task]前缀以保证搜索一致性Last Tested与先验证后发布的纪律配合防止流程文档随环境变化而失效。Prerequisites用 relation 而非纯文本是为了让前置依赖可点击跳转、可反向追踪。4.6 学习/复盘数据库Learning / Post-Mortem用于沉淀事故、项目与实验的经验schema 见 learning-database.mdPropertyTypeOptionsPurposeTitletitle-Event or project nameDatedate-When it happenedTypeselectIncident, Project, Experiment, RetrospectiveLearning typeSeverityselectCritical, Major, MinorImpact level (for incidents)Teampeople-Who was involvedKey Learningsnumber-Count of learningsAction ItemsrelationLinks to tasksFollow-up actions内容模板What Happened → What Went Well → What Didnt Go Well → Root Causes → Learnings → Action Items强调无指责复盘Blameless Approach并把Action Items设计成指向任务库的 relation——让经验最终闭环为改进动作而不是停留在文档里。五、Agent 与数据库交互前的环境准备要在 Codex 中实际执行上述Notion:notion-*工具调用需要先完成 Notion MCP 的连接。根据 SKILL.md 的说明若 MCP 调用失败应按以下顺序排查添加 Notion MCPcodex mcp add notion --url https://mcp.notion.com/mcp启用远程 MCP 客户端在config.toml中设置[features].rmcp_client true或运行codex --enable rmcp_client使用 OAuth 登录codex mcp login notion。登录成功后需要重启 codex 才能继续后续的建库与写库流程。这是 Agent 环境下先连工具、再建库、最后写页面的前置条件。六、长期维护七条实用建议原文档在结尾给出七条维护建议它们共同回答了数据库建好后如何不烂掉从通用文档库起步——它最灵活能覆盖大多数需求避免一开始就陷入多库选型的泥潭按需增加专业数据库——当 FAQ、决策等需求真实出现时再扩展对应上文的选型表用 relation 连接相关文档——把孤立条目编织成语义网络为常见场景创建视图——让最近更新待审查草稿一键可见每季度审查属性——删除没人使用的字段防止 schema 膨胀在数据库描述中记录 schema——新成员和人能快速理解每个属性的含义培训团队——统一属性用法与命名约定避免同一字段出现多种写法。这些建议在 documentation-database.md 的 Best Practices 部分得到呼应也被 evaluations/README.md 中的质量标准所验证——例如使用 How-To 格式与编号步骤组织内容保留对话中的精确 bash 命令以 How to [Action] 作为标题格式都是可测试、可评估的具体行为而非写得好一点这类空话。七、总结数据库是知识捕获系统的地基五大原则简单、一致命名、元数据、可发现性、规模规划定义了好库的评判标准Notion:notion-create-databaseNotion:notion-fetch的先 schema 后写入纪律保证了每次写库的准确性六套参考数据库通用文档、决策日志、FAQ、团队 Wiki、How-To、学习复盘覆盖了团队知识沉淀的绝大多数场景而季度审查、relation 编织与视图建设则让知识库在时间维度上持续保值。把这套方法论接入 notion-knowledge-capture 的五步工作流定义 → 定位 → 提取 → 创建 → 链接你的团队就能把每一次对话与决策沉淀为可检索、可复用、可持续演进的长期资产。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Notion 知识库数据库设计最佳实践：基于 awesome-codex-skills 的 notion-knowledge-capture 实战指南
Notion 知识库数据库设计最佳实践基于 awesome-codex-skills 的 notion-knowledge-capture 实战指南【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills在 Codex 驱动的知识捕获knowledge capture工作流中数据库Database是承载一切结构化内容的骨架无论捕获的是决策记录、FAQ、How-To 指南还是团队 Wiki最终都要落进一个设计良好的 Notion 数据库。本文以 awesome-codex-skills 仓库中 notion-knowledge-capture 技能 的官方指南 database-best-practices.md 为核心骨架结合仓库内六套参考数据库 schema、真实示例与评估用例系统讲解知识捕获数据库的五大设计原则、用Notion:notion-create-database建库的具体方法、建库前抓取 schema 的关键步骤以及一套可直接照用的数据库选型决策表。读完本文你将能独立设计、创建并长期维护一套可检索、可扩展、可持续演进的团队知识库。一、为什么数据库设计决定知识捕获的成败notion-knowledge-capture 技能的核心工作流是把对话与零散笔记转化为结构化、可链接的 Notion 页面。从 SKILL.md 的流程看一次完整捕获要经历定义捕获内容 → 定位目标数据库 → 提取并结构化 → 创建/更新页面 → 链接与呈现五个阶段其中第二步定位目标数据库直接决定了后续所有页面创建的质量正确的 schema 意味着每次Notion:notion-create-pages写入的属性都能被检索、被过滤、被视图正确归类错误的 schema 意味着知识虽然存进去了但无法通过视图、筛选和关系链接被再次发现沦为数字垃圾场。因此 database-best-practices.md 开篇即给出结论先按通用原则设计好数据库再让 Agent 按 schema 写入这是知识库一次建成、长期可复用的前提。二、五大核心设计原则原文档给出的五条原则是知识库设计的通用纲领每条都对应可落地的操作1. 保持简单Keep It Simple只从核心属性起步例如文档库的Title、Type、Tags、Status、Owner按需增量添加属性而不是一开始就铺满二十个字段避免过度设计Dont over-engineer——每多一个属性Agent 写库时多一分出错可能维护者每季度多一分整理成本。2. 使用一致的命名Use Consistent NamingTitle 属性作为主标识符承载条目的是什么Status追踪生命周期如Draft → Final → DeprecatedTags提供灵活的交叉分类Owner明确责任人保证每一条知识都有人维护。3. 包含元数据Include Metadata创建/更新时间戳Notion 的created_time、last_edited_time可自动填充负责人或维护者最近审查日期Last Reviewed状态指示器Status。元数据的价值在后续运维中体现它支撑了Needs Review需要审查Draft Docs草稿文档这类视图的自动筛选让知识库不会因内容过期而腐烂。4. 提升可发现性Enable Discovery充分使用 Tags允许从多维度切入检索创建常用视图按类型分组、按最近更新排序等链接相关内容用 relation 在条目间建立语义关联使用清晰明确的标题让搜索结果一望即知。5. 为规模做规划Plan for Scale尽早考虑过滤器属性类型的选择select vs multi_select vs relation决定了未来能否高效过滤用 relation 表达连接例如 FAQ 的Related Questions、决策日志的Related Decisions考虑搜索标题措辞、属性命名都要符合团队成员的搜索习惯用分类组织如按部门Engineering/Product/Design或内容类型划分。三、创建数据库Notion:notion-create-database完整实战原文档以团队文档库Team Documentation为例给出了完整的建库 JSON。下面是可直接复制使用的版本其中每一项属性都对应 Notion API 的属性类型{ parent: {page_id: wiki-page-id}, title: [{text: {content: Team Documentation}}], properties: { Type: { select: { options: [ {name: How-To, color: blue}, {name: Concept, color: green}, {name: Reference, color: gray}, {name: FAQ, color: yellow} ] } }, Category: { select: { options: [ {name: Engineering, color: red}, {name: Product, color: purple}, {name: Design, color: pink} ] } }, Tags: {multi_select: {options: []}}, Owner: {people: {}}, Status: { select: { options: [ {name: Draft, color: gray}, {name: Final, color: green}, {name: Deprecated, color: red} ] } } } }对照 documentation-database.md 中的完整 schema 表可以把这个 JSON 中的每个属性类型映射到它的实际用途PropertyTypeOptionsPurposeTitletitle-Document nameTypeselectHow-To, Concept, Reference, FAQ, Decision, Post-MortemCategorize content typeCategoryselectEngineering, Product, Design, Operations, GeneralOrganize by department/topicTagsmulti_select-Additional categorization (languages, tools, topics)StatusselectDraft, In Review, Final, DeprecatedTrack document lifecycleOwnerpeople-Document maintainerCreatedcreated_time-Auto-populated creation dateLast Updatedlast_edited_time-Auto-populated last editLast Revieweddate-Manual review tracking3.1 属性类型选型要点从源码级 schema 可以总结出三条选型经验select 用于有限且稳定的枚举如Type、Status、Category。枚举值在设计时要尽量穷尽因为 Notion 的 select 选项维护成本会随条目增多而上升。multi_select 用于开放标签Tags保持options: []空数组起步让 Agent 在写库时按需自由补充这正是保持简单 灵活分类的平衡点。people 用于责任归属Owner直接绑定 Notion 成员未来可按人筛选出某人名下所有待审查文档。3.2 建库前必须抓取 schema原文档特别强调了一个易被忽略的关键步骤在创建页面之前务必先抓取目标数据库以获取准确 schemaNotion:notion-fetch id: database-url-or-id这一步返回数据库的精确属性名与属性类型。为什么要这样做因为Notion 数据库可能已被团队成员手工修改过新增了Priority、删除了Category与参考文档中的 schema 不再一致属性名拼写错误如把Last Reviewed写成LastReviewd会导致写入失败或属性丢失只有拿到实时 schemaNotion:notion-create-pages才能准确填装属性。这一点在 SKILL.md 的工作流中被固化为固定动作步骤 3 用Notion:notion-search→Notion:notion-fetch拉取上下文步骤 4 再用Notion:notion-create-pages按 schema 建页。示例 conversation-to-faq.md 中Agent 先notion-search找到 Deployment FAQ 数据库再notion-fetch拿到Question/Category/Tags/Last Reviewed的实际属性随后才执行创建——这就是先 schema、后写入的完整闭环。四、数据库选型指南六套参考 Schema 一次讲透原文档的选型表给出了六种典型需求对应的数据库。仓库 reference/ 目录为每种数据库都准备了独立的 schema 与最佳实践文档下表为完整映射链接已转换为仓库根目录相对路径NeedUse This DatabaseGeneral documentationDocumentation DatabaseTrack decisionsDecision LogQA knowledge baseFAQ DatabaseTeam-specific contentTeam WikiStep-by-step guidesHow-To Guide DatabaseIncident/project learningsLearning Database4.1 通用文档库Documentation Database最适合作为团队知识库的起点库承载所有类型的文档。除前文 schema 外documentation-database.md 还推荐了五种内置视图By Type按 Type 属性分组By Category按 Category 属性分组Recent Updates按 Last Updated 降序排序Needs Review筛选 Last Reviewed 距今超过 90 天Draft Docs筛选 Status Draft其中Needs Review视图是元数据驱动运维的典型例子——Last Reviewed是唯一的date手动属性配合 90 天阈值即可让文档审查自动化、常态化。4.2 决策日志库Decision Log / ADR用于记录带上下文的决策其价值在于为什么。核心 schema 见 decision-log-database.mdPropertyTypeOptionsPurposeDecisiontitle-What was decidedDatedate-When decision was madeStatusselectProposed, Accepted, Superseded, DeprecatedCurrent decision statusDomainselectArchitecture, Product, Business, Design, OperationsDecision categoryImpactselectHigh, Medium, LowExpected impact levelDeciderspeople-Who made the decisionStakeholderspeople-Whos affected by decisionRelated DecisionsrelationLinks to other decisionsContext and dependencies每条决策页还应遵循 ADR 内容模板Context为什么需要该决策→ Decision决定了什么→ Rationale为什么选它→ Options Considered备选方案与取舍→ Consequences正负预期结果→ Implementation如何执行。示例 decision-capture.md 完整演示了REST 迁移 GraphQL决策的捕获过程——它甚至把被否决的选项Keep REST、gRPC连同拒绝理由一并记录这正是 ADR 与普通会议记录的本质区别。注意Status枚举中Superseded的存在决策会被新决策推翻用状态而非删除来表达该决策已过时可以保留完整决策历史。4.3 FAQ 数据库用于沉淀高频问题schema 见 faq-database.mdPropertyTypeOptionsPurposeQuestiontitle-The question being askedCategoryselectProduct, Engineering, Support, HR, GeneralQuestion topicTagsmulti_select-Specific topics (auth, billing, onboarding, etc.)Answer TypeselectQuick Answer, Detailed Guide, Link to DocsResponse formatLast Revieweddate-When answer was verifiedHelpful Countnumber-Track usefulness (optional)AudienceselectInternal, External, AllWho should see thisRelated QuestionsrelationLinks to related FAQsConnect similar topicsFAQ 页的内容模板强调先短答后长答Short Answer12 句快速响应→Detailed Explanation完整上下文→ 可选的Steps/Screenshots→Related Questions→Additional Resources。这一结构与 conversation-to-faq.md 中把部署排障对话拆成 3 条 FAQ的实践完全吻合且该示例展示了date:Last Reviewed:start与date:Last Reviewed:is_datetime: 0这种带类型前缀的属性写法是notion-create-pages处理日期属性的关键细节。4.4 团队 Wiki 数据库承接不属于其他库的团队专属内容schema 见 team-wiki-database.mdPropertyTypeOptionsPurposeTitletitle-Page nameSectionselectGetting Started, Processes, Tools, Reference, OnboardingWiki organizationTagsmulti_select-Topic tagsOwnerpeople-Page maintainerLast Updatedlast_edited_time-Auto-trackedVisibilityselectPublic, Team Only, ConfidentialAccess level其最佳实践强调每页必有 Owner与Visibility 分级适合跨团队共享但又需要权限边界的知识场景。4.5 How-To 指南库面向操作流程schema 见 how-to-guide-database.mdPropertyTypeOptionsPurposeTitletitle-How to [Task]ComplexityselectBeginner, Intermediate, AdvancedSkill level requiredTime Requirednumber-Estimated minutes to completePrerequisitesrelationLinks to other guidesRequired knowledgeCategoryselectDevelopment, Deployment, Testing, ToolsTask categoryLast Testeddate-When procedure was verifiedTagsmulti_select-Technology/tool tags两个设计亮点标题强制统一为How to [Task]前缀以保证搜索一致性Last Tested与先验证后发布的纪律配合防止流程文档随环境变化而失效。Prerequisites用 relation 而非纯文本是为了让前置依赖可点击跳转、可反向追踪。4.6 学习/复盘数据库Learning / Post-Mortem用于沉淀事故、项目与实验的经验schema 见 learning-database.mdPropertyTypeOptionsPurposeTitletitle-Event or project nameDatedate-When it happenedTypeselectIncident, Project, Experiment, RetrospectiveLearning typeSeverityselectCritical, Major, MinorImpact level (for incidents)Teampeople-Who was involvedKey Learningsnumber-Count of learningsAction ItemsrelationLinks to tasksFollow-up actions内容模板What Happened → What Went Well → What Didnt Go Well → Root Causes → Learnings → Action Items强调无指责复盘Blameless Approach并把Action Items设计成指向任务库的 relation——让经验最终闭环为改进动作而不是停留在文档里。五、Agent 与数据库交互前的环境准备要在 Codex 中实际执行上述Notion:notion-*工具调用需要先完成 Notion MCP 的连接。根据 SKILL.md 的说明若 MCP 调用失败应按以下顺序排查添加 Notion MCPcodex mcp add notion --url https://mcp.notion.com/mcp启用远程 MCP 客户端在config.toml中设置[features].rmcp_client true或运行codex --enable rmcp_client使用 OAuth 登录codex mcp login notion。登录成功后需要重启 codex 才能继续后续的建库与写库流程。这是 Agent 环境下先连工具、再建库、最后写页面的前置条件。六、长期维护七条实用建议原文档在结尾给出七条维护建议它们共同回答了数据库建好后如何不烂掉从通用文档库起步——它最灵活能覆盖大多数需求避免一开始就陷入多库选型的泥潭按需增加专业数据库——当 FAQ、决策等需求真实出现时再扩展对应上文的选型表用 relation 连接相关文档——把孤立条目编织成语义网络为常见场景创建视图——让最近更新待审查草稿一键可见每季度审查属性——删除没人使用的字段防止 schema 膨胀在数据库描述中记录 schema——新成员和人能快速理解每个属性的含义培训团队——统一属性用法与命名约定避免同一字段出现多种写法。这些建议在 documentation-database.md 的 Best Practices 部分得到呼应也被 evaluations/README.md 中的质量标准所验证——例如使用 How-To 格式与编号步骤组织内容保留对话中的精确 bash 命令以 How to [Action] 作为标题格式都是可测试、可评估的具体行为而非写得好一点这类空话。七、总结数据库是知识捕获系统的地基五大原则简单、一致命名、元数据、可发现性、规模规划定义了好库的评判标准Notion:notion-create-databaseNotion:notion-fetch的先 schema 后写入纪律保证了每次写库的准确性六套参考数据库通用文档、决策日志、FAQ、团队 Wiki、How-To、学习复盘覆盖了团队知识沉淀的绝大多数场景而季度审查、relation 编织与视图建设则让知识库在时间维度上持续保值。把这套方法论接入 notion-knowledge-capture 的五步工作流定义 → 定位 → 提取 → 创建 → 链接你的团队就能把每一次对话与决策沉淀为可检索、可复用、可持续演进的长期资产。【免费下载链接】awesome-codex-skillsA curated list of practical Codex skills for automating workflows across the Codex CLI and API.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-codex-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考