企业官网建设流程全解析

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 质量的验收基线。

评测场景一：对话转 Wiki（conversation-to-wiki.json）

仓库在 evaluations/conversation-to-wiki.json 中定义了一个把部署讨论沉淀为团队 wiki 指南的完整场景：

• 场景：把生产环境部署讨论保存到团队 wiki；
• 触发查询（query）：Save this conversation about deploying our application to production to the team wiki；
• 对话上下文（context）：前置对话包含部署流程，含步骤、坑点（gotchas）与最佳实践。

预期行为清单（expected_behavior）

该 JSON 文件第 6～19 行给出了可逐项核对的 12 条预期行为，核心包括：

1. 从对话上下文中提取关键信息（部署步骤、坑点、最佳实践）；
2. 依据过程性（procedural）特征，将内容识别为How-To Guide；
3. 按 How-To 结构组织：Overview → Prerequisites → Steps（编号）→ Verification → Troubleshooting → Related；
4. 用恰当的标题把信息组织到清晰的小节中；
5. 保留对话中的具体命令、配置和示例，而不是泛化占位；
6. 在 Overview 中补充"何时/为何使用此流程"的上下文；
7. 在 Troubleshooting 中记录讨论中提到的常见问题与解法；
8. 使用Notion:notion-search查找团队 wiki 位置，或向用户询问；
9. 使用Notion:notion-create-pages创建页面，并设置正确的 parent；
10. 使用清晰、可检索的标题，如How to Deploy to Production；
11. 应用 Notion markdown 格式（标题、代码块、列表）；
12. 若目标为 wiki 数据库，建议 tags/分类以提升可发现性。

成功标准（success_criteria）

对应第 20～29 行的 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；
• 对话上下文：用户刚阐述了决策理由、考虑过的选项与权衡。

预期行为清单

第 6～18 行列出的关键行为包括：

1. 从上下文识别这是一份决策记录（ADR，Architecture Decision Record）；
2. 使用 Decision 结构：Context → Decision → Rationale → Options Considered（含 Pros/Cons）→ Consequences → Implementation；
3. 从上下文提取：已做的决策、考虑过的选项（PostgreSQL vs MongoDB）、理由、权衡；
4. 文档包含 Date、Status（Accepted）、Deciders 等元信息；
5. 在 Consequences 中同时记录正面与负面后果（trade-offs）；
6. 使用Notion:notion-search检查决策日志数据库是否存在；
7. 若数据库存在，询问用户是写入数据库还是创建独立页面；
8. 若写入数据库，先用Notion:notion-fetch获取 schema，再设置属性：Decision title、Date、Status、Domain（Architecture）、Deciders、Impact；
9. 使用Notion:notion-create-pages，parent 为{ data_source_id }（数据库）或{ page_id }（父页面）；
10. 应用带章节的 Notion markdown；
11. 建议从架构文档或项目页面链接过来。

成功标准

第 19～29 行强调：六大章节（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，运行评测遵循以下步骤：

1. 启用knowledge-captureSkill（该场景在 JSON 的skills字段中声明为["knowledge-capture"]）；
2. 提交评测文件中的查询（query 字段，如部署保存或决策记录）；
3. 按指定内容提供对话上下文（context 字段）；
4. 逐项核对所有预期行为（expected_behavior）；
5. 对照成功标准检查产出质量（success_criteria）；
6. 在 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 给出五条准则：

1. 使用贴近真实的对话内容：包含实际的技术细节、决策或流程，避免虚构的空泛对话；
2. 覆盖不同类型的内容：how-to 指南、FAQ、决策记录、会议纪要、learnings；
3. 变化复杂度：从简单捕获到复杂技术讨论；
4. 测试发现能力：验证是否能找到正确的 wiki 分区或数据库；
5. 包含边界情况：内容类型不明确、上下文极少、类别重叠等。

结合仓库中的评测文件结构可以推断：一份评测 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 工作流中找到对应动作：

与数据库 Schema 的对应

评测场景中反复出现的结构（How-To 六段式、Decision 六段式、属性填充）与reference/下的数据库 Schema 一一对应：

• How-To 结构：对应 how-to-guide-database.md，其 Schema 含 Title（"How to [Task]"）、Complexity（Beginner/Intermediate/Advanced）、Time Required、Prerequisites（relation）、Category、Last Tested、Tags 等属性，usage 示例展示了{"Title": "How to Set Up Local Development Environment", "Complexity": "Beginner", ...}的属性填充方式；
• Decision 结构：对应 decision-log-database.md，Schema 含 Decision（title）、Date、Status（Proposed/Accepted/Superseded/Deprecated）、Domain（Architecture/Product/Business/Design/Operations）、Impact（High/Medium/Low）、Deciders、Stakeholders、Related Decisions（relation），内容模板正是评测要求的 Context → Decision → Rationale → Options Considered → Consequences → Implementation 六段式；
• 落点选择：还有 team-wiki-database.md（Section、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）：

1. 添加 MCP：codex mcp add notion --url https://mcp.notion.com/mcp；
2. 启用远程 MCP 客户端：在config.toml中设置[features].rmcp_client = true，或运行codex --enable rmcp_client；
3. OAuth 登录：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