Knowledge Capture Skill 评测指南用 Evaluation 场景验证 Notion 知识捕获能力【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills导读本指南围绕 skills/.curated/notion-knowledge-capture/evaluations/README.md 展开系统讲解「Knowledge Capture Skill」评测体系的用途、评测场景、运行流程、预期行为清单与成功标准定义并结合仓库内的 SKILL 工作流、数据库 schema 与示例输出进行源码级佐证。读完本文你将掌握如何在不同 Codex 模型Haiku、Sonnet、Opus上可复现地验证对话转结构化 Notion 知识这一能力并能独立编写高质量、可测试的评测用例。评测体系定位为什么 Knowledge Capture 需要专门评测Knowledge Capture Skill 的核心能力是把对话和笔记转化为结构化、可链接、可复用的 Notion 页面。评测evaluations存在的目的就是跨模型、可重复地验证这条转化链路没有悄悄退化。依据 evaluations/README.md评测需要确保 Skill 能够正确识别内容类型how-to 指南、FAQ、决策记录decision record、wiki 页面从对话中提取相关信息事实、步骤、踩坑点、最佳实践按各类型的要求恰当组织内容章节结构、标题层级、属性填充搜索并放到正确的 Notion 位置团队 wiki、决策日志、FAQ 数据库等在 Haiku、Sonnet、Opus 三个模型上表现一致。这些目标并非感觉上做对了即可而是通过仓库内两份 JSON 评测场景 明确的成功标准来逐一核对。评测不是辅助功能而是保证该 Skill 质量的验收基线。评测场景一对话转 Wikiconversation-to-wiki.json仓库在 evaluations/conversation-to-wiki.json 中定义了一个把部署讨论沉淀为团队 wiki 指南的完整场景场景把生产环境部署讨论保存到团队 wiki触发查询querySave this conversation about deploying our application to production to the team wiki对话上下文context前置对话包含部署流程含步骤、坑点gotchas与最佳实践。预期行为清单expected_behavior该 JSON 文件第 619 行给出了可逐项核对的 12 条预期行为核心包括从对话上下文中提取关键信息部署步骤、坑点、最佳实践依据过程性procedural特征将内容识别为How-To Guide按 How-To 结构组织Overview → Prerequisites → Steps编号→ Verification → Troubleshooting → Related用恰当的标题把信息组织到清晰的小节中保留对话中的具体命令、配置和示例而不是泛化占位在 Overview 中补充何时/为何使用此流程的上下文在 Troubleshooting 中记录讨论中提到的常见问题与解法使用Notion:notion-search查找团队 wiki 位置或向用户询问使用Notion:notion-create-pages创建页面并设置正确的 parent使用清晰、可检索的标题如How to Deploy to Production应用 Notion markdown 格式标题、代码块、列表若目标为 wiki 数据库建议 tags/分类以提升可发现性。成功标准success_criteria对应第 2029 行的 8 条成功标准强调内容可验证结构必须符合 SKILL.md 定义的 How-To 格式、关键要点被准确捕获而非泛化、使用规范的 Notion markdown##、###、列表、代码块、具体技术细节命令、配置被完整保留、页面标题可检索、页面被放到正确的 wiki 位置、且必须使用正确的工具名Notion:notion-create-pages。评测场景二架构决策记录decision-record.json第二份评测场景 evaluations/decision-record.json 面向架构/技术决策的完整记录场景记录数据库迁移决策触发查询Document our decision to use PostgreSQL instead of MongoDB for our new service对话上下文用户刚阐述了决策理由、考虑过的选项与权衡。预期行为清单第 618 行列出的关键行为包括从上下文识别这是一份决策记录ADRArchitecture Decision Record使用 Decision 结构Context → Decision → Rationale → Options Considered含 Pros/Cons→ Consequences → Implementation从上下文提取已做的决策、考虑过的选项PostgreSQL vs MongoDB、理由、权衡文档包含 Date、StatusAccepted、Deciders 等元信息在 Consequences 中同时记录正面与负面后果trade-offs使用Notion:notion-search检查决策日志数据库是否存在若数据库存在询问用户是写入数据库还是创建独立页面若写入数据库先用Notion:notion-fetch获取 schema再设置属性Decision title、Date、Status、DomainArchitecture、Deciders、Impact使用Notion:notion-create-pagesparent 为{ data_source_id }数据库或{ page_id }父页面应用带章节的 Notion markdown建议从架构文档或项目页面链接过来。成功标准第 1929 行强调六大章节Context、Decision、Rationale、Options Considered、Consequences、Implementation齐全决策陈述明确选择 PostgreSQL 而非 MongoDB被考虑的选项以 Pros/Cons 结构记录理由源于对话上下文后果同时含正面收益与负面权衡若入数据库属性按 schema 正确设置Decision、Date、Status: Accepted、Domain: Architecture、Impact文档有日期且状态为Accepted工具名使用正确Notion:notion-search、Notion:notion-fetch、Notion:notion-create-pages。运行评测六步标准流程依据 evaluations/README.md运行评测遵循以下步骤启用knowledge-captureSkill该场景在 JSON 的skills字段中声明为[knowledge-capture]提交评测文件中的查询query 字段如部署保存或决策记录按指定内容提供对话上下文context 字段逐项核对所有预期行为expected_behavior对照成功标准检查产出质量success_criteria在 Haiku、Sonnet、Opus 三个模型上分别测试验证跨模型一致性。值得强调的是第 6 步这套评测的定位不是在某一个模型上偶尔跑通而是确保 Knowledge Capture 行为在 Codex 的不同模型间保持一致因此每个场景都应作为三模型回归矩阵的一部分重复执行。预期 Skill 行为四类检查维度评测应覆盖以下四类行为维度evaluations/README.md内容提取Content Extraction从对话上下文准确捕获关键要点保留具体技术细节而不是通用占位符例如保留真实 bash 命令而非执行命令维持讨论中的上下文与细微差别nuance。内容类型选择Content Type Selection正确识别合适的内容类型how-to、FAQ、决策记录、wiki 页面使用参考文档reference/目录中匹配的结构应用正确的 Notion markdown 格式。Notion 集成Notion Integration搜索合适的落点wiki、决策日志等创建结构清晰、标题明确的页面使用正确的 parent 放置包含可检索的标题与元数据。质量标准Quality Standards内容可执行、可供未来参考技术准确性得以保留组织方式有助于可发现性格式提升可读性。编写新评测五条设计准则新增 Knowledge Capture 评测时evaluations/README.md 给出五条准则使用贴近真实的对话内容包含实际的技术细节、决策或流程避免虚构的空泛对话覆盖不同类型的内容how-to 指南、FAQ、决策记录、会议纪要、learnings变化复杂度从简单捕获到复杂技术讨论测试发现能力验证是否能找到正确的 wiki 分区或数据库包含边界情况内容类型不明确、上下文极少、类别重叠等。结合仓库中的评测文件结构可以推断一份评测 JSON 的标准字段为name、skills、query、context、expected_behavior数组与success_criteria数组新增场景时按此骨架编写即可被标准化地执行。成功标准可测试的具体表述 vs 模糊表述评测质量的核心在于成功标准是否可验证。README 给出了鲜明的对比Good具体、可测试使用 How-To 格式带编号步骤组织内容保留对话中的精确 bash 命令创建标题格式为How to [Action]的页面放置到 Engineering Wiki → Deployment 分区。Bad模糊、不可测试创建了良好的文档使用了合适的结构保存到了正确的位置。从两份 JSON 文件的 success_criteria 看仓库实践遵循同一原则每条标准都对应一个可观察、可判定的输出特征章节是否齐全、属性值是否为Accepted、工具名是否正确等这正是评测可以被 Agent 自动核对的前提。评测背后的实现锚点SKILL 工作流与数据库 Schema评测并非孤立存在——它验证的是 SKILL.md 定义的真实工作流。对照评测内容与 SKILL 文档可以看到完整的定义捕获 → 定位落点 → 提取与结构化 → 创建/更新 → 链接与暴露五步链路SKILL.md评测中的每一项预期行为都能在 SKILL 工作流中找到对应动作评测关注点SKILL.md 对应步骤识别内容类型how-to / decision步骤 1定义捕获确定内容类型找到正确落点wiki / decision log步骤 2依据reference/*-database.md选定数据库提取步骤/理由/权衡步骤 3提取事实、决策、行动与理由创建页面并设置属性步骤 4notion-create-pages按 schema 设置属性链接与暴露步骤 5添加 relation/backlink、摘要/changelog与数据库 Schema 的对应评测场景中反复出现的结构How-To 六段式、Decision 六段式、属性填充与reference/下的数据库 Schema 一一对应How-To 结构对应 how-to-guide-database.md其 Schema 含 TitleHow to [Task]、ComplexityBeginner/Intermediate/Advanced、Time Required、Prerequisitesrelation、Category、Last Tested、Tags 等属性usage 示例展示了{Title: How to Set Up Local Development Environment, Complexity: Beginner, ...}的属性填充方式Decision 结构对应 decision-log-database.mdSchema 含 Decisiontitle、Date、StatusProposed/Accepted/Superseded/Deprecated、DomainArchitecture/Product/Business/Design/Operations、ImpactHigh/Medium/Low、Deciders、Stakeholders、Related Decisionsrelation内容模板正是评测要求的 Context → Decision → Rationale → Options Considered → Consequences → Implementation 六段式落点选择还有 team-wiki-database.mdSection、Owner、Visibility 等、faq-database.md、documentation-database.md、learning-database.md以及通用的 database-best-practices.md含用Notion:notion-create-database创建文档数据库的完整 JSON 示例、用Notion:notion-fetch获取 schema 的说明和数据库选型对照表。示例产物的验证价值评测中要求的How to Deploy to Production式输出在 examples/how-to-guide.md 中有完整成品示范从对话提取内容、按 Overview/Prerequisites/编号步骤/Verification Checklist/Troubleshooting/Best Practices 组织、用Notion:notion-search找到Engineering Wiki → Deployment分区、用notion-create-pages创建、最后用notion-update-page在 wiki 首页插入链接。同目录下还有 examples/decision-capture.md 与 examples/conversation-to-faq.md 覆盖另外两类捕获模式。评测执行时可将这些示例产物作为参考答案与 Skill 实际输出逐段比对。评测运行的前提Notion MCP 就绪由于评测涉及notion-search/notion-fetch/notion-create-pages等真实工具调用运行前需确保 Notion MCP 已连接SKILL.md添加 MCPcodex mcp add notion --url https://mcp.notion.com/mcp启用远程 MCP 客户端在config.toml中设置[features].rmcp_client true或运行codex --enable rmcp_clientOAuth 登录codex mcp login notion登录成功后需重启 codex。若 MCP 未连接Skill 应暂停并引导完成上述设置评测流程同样遵循该前提。小结Knowledge Capture 的评测体系用两份结构化 JSON 场景对话转 Wiki、决策记录覆盖了内容识别 → 提取 → 结构化 → Notion 落位 → 链接暴露的完整链路并以可测试的成功标准 三模型回归保证质量的可持续性。要扩展这套体系只需遵循五条设计准则新增场景贴近真实的对话上下文、覆盖多种内容类型、变化复杂度、测试发现能力、包含边界情况。撰写评测时请始终记住 README 的对比原则——成功的评测写保留精确 bash 命令失败的评测才写创建了良好文档。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Knowledge Capture Skill 评测指南：用 Evaluation 场景验证 Notion 知识捕获能力
Knowledge Capture Skill 评测指南用 Evaluation 场景验证 Notion 知识捕获能力【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills导读本指南围绕 skills/.curated/notion-knowledge-capture/evaluations/README.md 展开系统讲解「Knowledge Capture Skill」评测体系的用途、评测场景、运行流程、预期行为清单与成功标准定义并结合仓库内的 SKILL 工作流、数据库 schema 与示例输出进行源码级佐证。读完本文你将掌握如何在不同 Codex 模型Haiku、Sonnet、Opus上可复现地验证对话转结构化 Notion 知识这一能力并能独立编写高质量、可测试的评测用例。评测体系定位为什么 Knowledge Capture 需要专门评测Knowledge Capture Skill 的核心能力是把对话和笔记转化为结构化、可链接、可复用的 Notion 页面。评测evaluations存在的目的就是跨模型、可重复地验证这条转化链路没有悄悄退化。依据 evaluations/README.md评测需要确保 Skill 能够正确识别内容类型how-to 指南、FAQ、决策记录decision record、wiki 页面从对话中提取相关信息事实、步骤、踩坑点、最佳实践按各类型的要求恰当组织内容章节结构、标题层级、属性填充搜索并放到正确的 Notion 位置团队 wiki、决策日志、FAQ 数据库等在 Haiku、Sonnet、Opus 三个模型上表现一致。这些目标并非感觉上做对了即可而是通过仓库内两份 JSON 评测场景 明确的成功标准来逐一核对。评测不是辅助功能而是保证该 Skill 质量的验收基线。评测场景一对话转 Wikiconversation-to-wiki.json仓库在 evaluations/conversation-to-wiki.json 中定义了一个把部署讨论沉淀为团队 wiki 指南的完整场景场景把生产环境部署讨论保存到团队 wiki触发查询querySave this conversation about deploying our application to production to the team wiki对话上下文context前置对话包含部署流程含步骤、坑点gotchas与最佳实践。预期行为清单expected_behavior该 JSON 文件第 619 行给出了可逐项核对的 12 条预期行为核心包括从对话上下文中提取关键信息部署步骤、坑点、最佳实践依据过程性procedural特征将内容识别为How-To Guide按 How-To 结构组织Overview → Prerequisites → Steps编号→ Verification → Troubleshooting → Related用恰当的标题把信息组织到清晰的小节中保留对话中的具体命令、配置和示例而不是泛化占位在 Overview 中补充何时/为何使用此流程的上下文在 Troubleshooting 中记录讨论中提到的常见问题与解法使用Notion:notion-search查找团队 wiki 位置或向用户询问使用Notion:notion-create-pages创建页面并设置正确的 parent使用清晰、可检索的标题如How to Deploy to Production应用 Notion markdown 格式标题、代码块、列表若目标为 wiki 数据库建议 tags/分类以提升可发现性。成功标准success_criteria对应第 2029 行的 8 条成功标准强调内容可验证结构必须符合 SKILL.md 定义的 How-To 格式、关键要点被准确捕获而非泛化、使用规范的 Notion markdown##、###、列表、代码块、具体技术细节命令、配置被完整保留、页面标题可检索、页面被放到正确的 wiki 位置、且必须使用正确的工具名Notion:notion-create-pages。评测场景二架构决策记录decision-record.json第二份评测场景 evaluations/decision-record.json 面向架构/技术决策的完整记录场景记录数据库迁移决策触发查询Document our decision to use PostgreSQL instead of MongoDB for our new service对话上下文用户刚阐述了决策理由、考虑过的选项与权衡。预期行为清单第 618 行列出的关键行为包括从上下文识别这是一份决策记录ADRArchitecture Decision Record使用 Decision 结构Context → Decision → Rationale → Options Considered含 Pros/Cons→ Consequences → Implementation从上下文提取已做的决策、考虑过的选项PostgreSQL vs MongoDB、理由、权衡文档包含 Date、StatusAccepted、Deciders 等元信息在 Consequences 中同时记录正面与负面后果trade-offs使用Notion:notion-search检查决策日志数据库是否存在若数据库存在询问用户是写入数据库还是创建独立页面若写入数据库先用Notion:notion-fetch获取 schema再设置属性Decision title、Date、Status、DomainArchitecture、Deciders、Impact使用Notion:notion-create-pagesparent 为{ data_source_id }数据库或{ page_id }父页面应用带章节的 Notion markdown建议从架构文档或项目页面链接过来。成功标准第 1929 行强调六大章节Context、Decision、Rationale、Options Considered、Consequences、Implementation齐全决策陈述明确选择 PostgreSQL 而非 MongoDB被考虑的选项以 Pros/Cons 结构记录理由源于对话上下文后果同时含正面收益与负面权衡若入数据库属性按 schema 正确设置Decision、Date、Status: Accepted、Domain: Architecture、Impact文档有日期且状态为Accepted工具名使用正确Notion:notion-search、Notion:notion-fetch、Notion:notion-create-pages。运行评测六步标准流程依据 evaluations/README.md运行评测遵循以下步骤启用knowledge-captureSkill该场景在 JSON 的skills字段中声明为[knowledge-capture]提交评测文件中的查询query 字段如部署保存或决策记录按指定内容提供对话上下文context 字段逐项核对所有预期行为expected_behavior对照成功标准检查产出质量success_criteria在 Haiku、Sonnet、Opus 三个模型上分别测试验证跨模型一致性。值得强调的是第 6 步这套评测的定位不是在某一个模型上偶尔跑通而是确保 Knowledge Capture 行为在 Codex 的不同模型间保持一致因此每个场景都应作为三模型回归矩阵的一部分重复执行。预期 Skill 行为四类检查维度评测应覆盖以下四类行为维度evaluations/README.md内容提取Content Extraction从对话上下文准确捕获关键要点保留具体技术细节而不是通用占位符例如保留真实 bash 命令而非执行命令维持讨论中的上下文与细微差别nuance。内容类型选择Content Type Selection正确识别合适的内容类型how-to、FAQ、决策记录、wiki 页面使用参考文档reference/目录中匹配的结构应用正确的 Notion markdown 格式。Notion 集成Notion Integration搜索合适的落点wiki、决策日志等创建结构清晰、标题明确的页面使用正确的 parent 放置包含可检索的标题与元数据。质量标准Quality Standards内容可执行、可供未来参考技术准确性得以保留组织方式有助于可发现性格式提升可读性。编写新评测五条设计准则新增 Knowledge Capture 评测时evaluations/README.md 给出五条准则使用贴近真实的对话内容包含实际的技术细节、决策或流程避免虚构的空泛对话覆盖不同类型的内容how-to 指南、FAQ、决策记录、会议纪要、learnings变化复杂度从简单捕获到复杂技术讨论测试发现能力验证是否能找到正确的 wiki 分区或数据库包含边界情况内容类型不明确、上下文极少、类别重叠等。结合仓库中的评测文件结构可以推断一份评测 JSON 的标准字段为name、skills、query、context、expected_behavior数组与success_criteria数组新增场景时按此骨架编写即可被标准化地执行。成功标准可测试的具体表述 vs 模糊表述评测质量的核心在于成功标准是否可验证。README 给出了鲜明的对比Good具体、可测试使用 How-To 格式带编号步骤组织内容保留对话中的精确 bash 命令创建标题格式为How to [Action]的页面放置到 Engineering Wiki → Deployment 分区。Bad模糊、不可测试创建了良好的文档使用了合适的结构保存到了正确的位置。从两份 JSON 文件的 success_criteria 看仓库实践遵循同一原则每条标准都对应一个可观察、可判定的输出特征章节是否齐全、属性值是否为Accepted、工具名是否正确等这正是评测可以被 Agent 自动核对的前提。评测背后的实现锚点SKILL 工作流与数据库 Schema评测并非孤立存在——它验证的是 SKILL.md 定义的真实工作流。对照评测内容与 SKILL 文档可以看到完整的定义捕获 → 定位落点 → 提取与结构化 → 创建/更新 → 链接与暴露五步链路SKILL.md评测中的每一项预期行为都能在 SKILL 工作流中找到对应动作评测关注点SKILL.md 对应步骤识别内容类型how-to / decision步骤 1定义捕获确定内容类型找到正确落点wiki / decision log步骤 2依据reference/*-database.md选定数据库提取步骤/理由/权衡步骤 3提取事实、决策、行动与理由创建页面并设置属性步骤 4notion-create-pages按 schema 设置属性链接与暴露步骤 5添加 relation/backlink、摘要/changelog与数据库 Schema 的对应评测场景中反复出现的结构How-To 六段式、Decision 六段式、属性填充与reference/下的数据库 Schema 一一对应How-To 结构对应 how-to-guide-database.md其 Schema 含 TitleHow to [Task]、ComplexityBeginner/Intermediate/Advanced、Time Required、Prerequisitesrelation、Category、Last Tested、Tags 等属性usage 示例展示了{Title: How to Set Up Local Development Environment, Complexity: Beginner, ...}的属性填充方式Decision 结构对应 decision-log-database.mdSchema 含 Decisiontitle、Date、StatusProposed/Accepted/Superseded/Deprecated、DomainArchitecture/Product/Business/Design/Operations、ImpactHigh/Medium/Low、Deciders、Stakeholders、Related Decisionsrelation内容模板正是评测要求的 Context → Decision → Rationale → Options Considered → Consequences → Implementation 六段式落点选择还有 team-wiki-database.mdSection、Owner、Visibility 等、faq-database.md、documentation-database.md、learning-database.md以及通用的 database-best-practices.md含用Notion:notion-create-database创建文档数据库的完整 JSON 示例、用Notion:notion-fetch获取 schema 的说明和数据库选型对照表。示例产物的验证价值评测中要求的How to Deploy to Production式输出在 examples/how-to-guide.md 中有完整成品示范从对话提取内容、按 Overview/Prerequisites/编号步骤/Verification Checklist/Troubleshooting/Best Practices 组织、用Notion:notion-search找到Engineering Wiki → Deployment分区、用notion-create-pages创建、最后用notion-update-page在 wiki 首页插入链接。同目录下还有 examples/decision-capture.md 与 examples/conversation-to-faq.md 覆盖另外两类捕获模式。评测执行时可将这些示例产物作为参考答案与 Skill 实际输出逐段比对。评测运行的前提Notion MCP 就绪由于评测涉及notion-search/notion-fetch/notion-create-pages等真实工具调用运行前需确保 Notion MCP 已连接SKILL.md添加 MCPcodex mcp add notion --url https://mcp.notion.com/mcp启用远程 MCP 客户端在config.toml中设置[features].rmcp_client true或运行codex --enable rmcp_clientOAuth 登录codex mcp login notion登录成功后需重启 codex。若 MCP 未连接Skill 应暂停并引导完成上述设置评测流程同样遵循该前提。小结Knowledge Capture 的评测体系用两份结构化 JSON 场景对话转 Wiki、决策记录覆盖了内容识别 → 提取 → 结构化 → Notion 落位 → 链接暴露的完整链路并以可测试的成功标准 三模型回归保证质量的可持续性。要扩展这套体系只需遵循五条设计准则新增场景贴近真实的对话上下文、覆盖多种内容类型、变化复杂度、测试发现能力、包含边界情况。撰写评测时请始终记住 README 的对比原则——成功的评测写保留精确 bash 命令失败的评测才写创建了良好文档。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考