用可复现评估场景验证 Codex 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本指南围绕 awesome-codex-skills 仓库中 notion-knowledge-capture 技能 的评估体系展开系统讲解如何通过conversation-to-wiki、decision-record两类标准化评估场景验证技能在内容类型识别、信息提取、Notion 结构化写入与多模型一致性四个维度的表现。读完本文你将掌握该仓库内置评估文件的完整解读、六步运行流程、四维预期行为检查要点以及如何自行编写可测试、可复现的新评估用例。评估体系概览为什么需要结构化评估对话型知识沉淀类技能的难点在于结果好不好难以量化同样一段部署讨论不同模型可能给出风格迥异的 Wiki 页面。为此仓库在 notion-knowledge-capture/evaluations/README.md 中定义了一套结构化的评估evaluation方案其核心目的包括正确识别内容类型判断一段对话究竟属于 how-to 指南、FAQ、决策记录还是 Wiki 页面从对话中提取相关信息去掉寒暄与无关内容保留事实、步骤与结论按类型结构化组织内容每种内容类型套用对应的章节骨架在 Notion 中搜索并放置到正确位置找到正确的 Wiki、决策日志等目标数据库在 Haiku、Sonnet、Opus 上保持一致表现跨模型输出质量稳定。这套评估不是跑一遍看个大概而是把技能质量拆解为可观察、可断言的行为behavior与成功标准success criterion形成一套可复用的验收基线。评估用例以 JSON 文件形式存放在 evaluations/ 目录下每个文件声明技能名称、用户查询语句、前置对话上下文、预期行为列表与成功标准列表。评估场景一对话转 Wikiconversation-to-wiki.json场景定位conversation-to-wiki.json 覆盖最典型的会议讨论 → 团队知识库场景用户在对话中讨论了生产环境部署流程然后要求把这段部署讨论保存到团队 Wiki。技能声明skills: [knowledge-capture]用户查询Save this conversation about deploying our application to production to the team wiki模拟上下文前置对话包含部署步骤、常见坑gotchas与最佳实践预期行为expected_behavior评估文件为模型列出了一份完整的可观察行为清单从对话上下文中提取关键信息部署步骤、坑、最佳实践依据过程性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 数据库建议标签/分类以便检索。成功标准success_criteria对应的验收断言要求内容按 SKILL.md 内容类型中的 How-To 格式组织对话关键点被准确捕获而非泛化占位使用正确的 Notion markdown##、###、列表、代码块具体技术细节命令、配置从对话中原样保留文档面向未来复用地编写步骤清晰可执行标题可搜索、有描述性如 How to Deploy to Production页面放入合适的 Wiki 位置通用 Wiki 或具体小节使用正确的工具名Notion:notion-create-pages。与数据库模板的对应关系从仓库源码结构看该场景落地时对应两套模板team-wiki-database.md 负责页面归属通过Section属性区分 Getting Started、Processes、Tools 等分区通过Owner、Visibility管理维护人与可见性how-to-guide-database.md 负责页面自身的结构化属性Complexity、Time Required、Prerequisites、Category、Last Tested、Tags。实际产出的页面形态可对照 examples/how-to-guide.md该示例完整展示了从提取部署步骤、Notion:notion-search定位到 Engineering Wiki → Deployment section再到生成带编号步骤、验证清单、故障排查表的最终 Wiki 页面可作为评估时期望输出的参照标准。评估场景二架构决策记录decision-record.json场景定位decision-record.json 覆盖另一类高频场景——架构/技术决策的留档。用户在对话中刚解释了为什么新服务选用 PostgreSQL 而不是 MongoDB模型需要把这段讨论沉淀为一份完整的决策记录。技能声明skills: [knowledge-capture]用户查询Document our decision to use PostgreSQL instead of MongoDB for our new service模拟上下文用户已说明决策理由、备选方案与权衡预期行为expected_behavior从对话上下文识别这是一条决策记录架构决策按决策结构组织Context → Decision → Rationale → Options Considered含 Pros/Cons→ Consequences → Implementation从上下文提取所做决策、备选方案PostgreSQL vs MongoDB、理由、权衡创建带Date、StatusAccepted、Deciders的文档在 Consequences 中同时包含正面与负面后果权衡用Notion:notion-search检查决策日志数据库是否存在若数据库存在询问用户是写入该库还是创建独立页面若写入数据库用Notion:notion-fetch获取 schema 并设置属性决策标题、Date、Status、DomainArchitecture、Deciders、Impact使用Notion:notion-create-pagesparent 为{ data_source_id }数据库或{ page_id }父页面应用正确的 Notion markdown 分区排版建议从架构文档或项目页面反向链接。成功标准success_criteria文档遵循 SKILL.md 内容类型中的决策结构全部关键章节齐全Context、Decision、Rationale、Options Considered每项含 Pros/Cons、Consequences、Implementation决策被清晰陈述选择 PostgreSQL 而非 MongoDB备选方案以 pros/cons 结构记录Rationale 依据对话上下文解释为何选择 PostgreSQLConsequences 同时包含正面收益与负面权衡若写入数据库属性按 schema 正确设置Decision、Date、Status: Accepted、Domain: Architecture、Impact文档带日期且状态为 Accepted使用正确的工具名Notion:notion-search、Notion:notion-fetch、Notion:notion-create-pages。与数据库模板的对应关系决策场景的落库模板是 decision-log-database.md其中定义了决策记录完整属性集Decision标题、Date、StatusProposed/Accepted/Superseded/Deprecated、DomainArchitecture/Product/Business/Design/Operations、ImpactHigh/Medium/Low、Deciders、Stakeholders、Related Decisionsrelation并给出页面正文模板Context → Decision → Rationale → Options Considered → Consequences → Implementation与常用视图按 Date 排序、过滤 StatusAccepted、按 Impact 分组等。对照示例 examples/decision-capture.md 可以看到一次完整的决策留档演练从 REST 迁移到 GraphQL 的决策被拆解为 Context50 端点的 REST API 痛点、Decision、Rationale、三个备选方案的逐项 Pros/Cons 与接受/否决结论、正负 Consequences、实施计划最后写入 ADR 数据库并建立反向链接——这正是决策类评估期望输出的样板。运行评估的完整流程按 evaluations/README.md 的说明运行评估共六步启用knowledge-capture技能本仓库对应技能为 notion-knowledge-capture提交评估文件中的用户查询如 Save this conversation about deploying our application to production to the team wiki提供评估文件指定的对话上下文如前置对话包含部署步骤、坑与最佳实践核对所有预期行为是否满足对照成功标准检查产出质量在 Haiku、Sonnet、Opus 三个模型上重复测试确认跨模型一致性。前置条件Notion MCP 连接评估依赖 Notion MCP 工具调用。若评估过程中出现 MCP 调用失败说明 Notion MCP 未连接此时需要按 SKILL.md 工作流第 0 步完成配置# 1. 添加 Notion 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此时应结束当前回答并告知用户重启后再从第 1 步继续。MCP 就绪后评估中会观察到的工具调用链为Notion:notion-search定位目标数据库/页面→Notion:notion-fetch获取数据库 schema→Notion:notion-create-pages创建结构化页面→Notion:notion-update-page维护索引与反向链接。预期技能行为详解四个可检查维度Knowledge Capture 评估把技能行为拆成四个维度每个维度都有明确的观察点1. 内容提取Content Extraction从对话上下文中准确捕获关键点而非泛化占位符保留具体技术细节命令、配置值、版本号这些正是知识沉淀的价值所在保留讨论中的语境与细微差别前提条件、适用范围、例外情况。2. 内容类型选择Content Type Selection正确识别内容类型how-to、FAQ、决策记录、Wiki 页面套用 reference/ 目录下对应数据库文档中定义的结构应用正确的 Notion markdown 排版。判定依据可参考 SKILL.md 中的类型判别提示过程性内容步骤、前置条件→ How-ToQA 式问答 → FAQ架构/技术取舍 → 决策记录团队通用资料 → Wiki/文档页。例如对话转 Wiki场景的判别信号是过程性 步骤化而决策记录场景的判别信号是备选方案 权衡 结论。3. Notion 集成Notion Integration搜索合适的目标位置Wiki、决策日志等创建标题清晰、结构良好的页面使用正确的父级parent放置数据库data_source_id或页面page_id包含可检索的标题与元数据属性。4. 质量标准Quality Standards内容可操作、面向未来复用技术准确性不丢失组织方式利于检索发现排版提升可读性。这四个维度与 database-best-practices.md 中的通用原则互为印证一致的命名Title 作为主标识、Status 跟踪生命周期、Tags 灵活分类、Owner 落实责任、包含元数据创建/更新时间、维护人、复核日期、启用发现机制充分打标签、建视图、链接相关内容。评估本质上就是检验这些最佳实践是否被模型真正执行。如何编写高质量的评估用例在 evaluations/README.md 的Creating New Evaluations一节给出了新增评估的五条指导原则使用贴近真实的对话内容——包含实际技术细节、决策或流程避免抽象空泛的示例覆盖不同的内容类型——How-To 指南、FAQ、决策记录、会议纪要、学习心得等都应各有用例变化复杂度——从简单捕获到复杂技术讨论都要有测试发现能力——验证模型能否找到正确的 Wiki 分区或数据库包含边界情况——内容类型不明确、上下文极简、分类重叠等易出错的场景。从现有两个评估文件的字段结构name、skills、query、context、expected_behavior、success_criteria可以看出新用例应遵循的模板query模拟真实用户指令context描述前置对话内容概要expected_behavior给出模型应展现的每个动作含工具名success_criteria给出可验证的产出断言。仓库中的 examples/ 目录conversation-to-faq.md 等提供了不同内容类型的完整捕获演示可作为编写新场景时期望输出的素材来源——例如 FAQ 场景展示了一段故障排查对话如何被拆解为多条 QA 条目、设置 Category/Tags/Last Reviewed 属性并更新 FAQ 索引页。成功标准的定义可测试性优先评估质量的高低取决于成功标准写得好不好。evaluations/README.md 专门给出了优劣对照合格的标准具体、可测试使用 How-To 格式组织内容并带编号步骤从对话中原样保留 bash 命令创建标题格式为 How to [Action] 的页面放入 Engineering Wiki → Deployment 分区不合格的标准模糊、不可测试创建了良好的文档使用了合适的结构保存到了正确的地方可以推断一条合格标准的本质是可断言要么能对输出文本做模式匹配标题格式、章节标题、命令是否逐字保留要么能对工具调用做检查是否调用了Notion:notion-search、parent 是否指向正确位置。这正是 JSON 文件中expected_behavior与success_criteria双层设计的原因——前者检查行为过程后者检查产出结果两者互补才能完整覆盖一个场景。从评估到质量闭环评估不是一次性验收而应融入技能的持续迭代。结合仓库整体结构推荐的质量闭环是用现有两个用例建立基线——分别覆盖对话转 Wiki与架构决策留档两条主路径在各模型上跑出基准表现按五条原则扩充用例矩阵——为 FAQ、学习笔记、会议纪要等类型补充场景加入边界用例以 reference/ 数据库模板为统一标尺——无论哪个用例产出都应对齐对应数据库的 schema 与内容模板用 examples/ 样例校准期望——评估文件的 success_criteria 可以随时对照示例中的成熟产出进行细化跨模型回归——任何技能提示词或模板改动后在 Haiku、Sonnet、Opus 上重跑全部用例确保一致性不退化。通过这套评估机制Knowledge Capture 技能把把对话变成结构化知识这一主观目标转化为一系列客观、可复现、可断言的行为检查从而让团队 Wiki、决策日志与 FAQ 库的知识沉淀质量可度量、可持续改进。【免费下载链接】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），仅供参考 用可复现评估场景验证 Codex Knowledge Capture 技能：跨模型一致的知识沉淀质量保障
用可复现评估场景验证 Codex 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本指南围绕 awesome-codex-skills 仓库中 notion-knowledge-capture 技能 的评估体系展开系统讲解如何通过conversation-to-wiki、decision-record两类标准化评估场景验证技能在内容类型识别、信息提取、Notion 结构化写入与多模型一致性四个维度的表现。读完本文你将掌握该仓库内置评估文件的完整解读、六步运行流程、四维预期行为检查要点以及如何自行编写可测试、可复现的新评估用例。评估体系概览为什么需要结构化评估对话型知识沉淀类技能的难点在于结果好不好难以量化同样一段部署讨论不同模型可能给出风格迥异的 Wiki 页面。为此仓库在 notion-knowledge-capture/evaluations/README.md 中定义了一套结构化的评估evaluation方案其核心目的包括正确识别内容类型判断一段对话究竟属于 how-to 指南、FAQ、决策记录还是 Wiki 页面从对话中提取相关信息去掉寒暄与无关内容保留事实、步骤与结论按类型结构化组织内容每种内容类型套用对应的章节骨架在 Notion 中搜索并放置到正确位置找到正确的 Wiki、决策日志等目标数据库在 Haiku、Sonnet、Opus 上保持一致表现跨模型输出质量稳定。这套评估不是跑一遍看个大概而是把技能质量拆解为可观察、可断言的行为behavior与成功标准success criterion形成一套可复用的验收基线。评估用例以 JSON 文件形式存放在 evaluations/ 目录下每个文件声明技能名称、用户查询语句、前置对话上下文、预期行为列表与成功标准列表。评估场景一对话转 Wikiconversation-to-wiki.json场景定位conversation-to-wiki.json 覆盖最典型的会议讨论 → 团队知识库场景用户在对话中讨论了生产环境部署流程然后要求把这段部署讨论保存到团队 Wiki。技能声明skills: [knowledge-capture]用户查询Save this conversation about deploying our application to production to the team wiki模拟上下文前置对话包含部署步骤、常见坑gotchas与最佳实践预期行为expected_behavior评估文件为模型列出了一份完整的可观察行为清单从对话上下文中提取关键信息部署步骤、坑、最佳实践依据过程性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 数据库建议标签/分类以便检索。成功标准success_criteria对应的验收断言要求内容按 SKILL.md 内容类型中的 How-To 格式组织对话关键点被准确捕获而非泛化占位使用正确的 Notion markdown##、###、列表、代码块具体技术细节命令、配置从对话中原样保留文档面向未来复用地编写步骤清晰可执行标题可搜索、有描述性如 How to Deploy to Production页面放入合适的 Wiki 位置通用 Wiki 或具体小节使用正确的工具名Notion:notion-create-pages。与数据库模板的对应关系从仓库源码结构看该场景落地时对应两套模板team-wiki-database.md 负责页面归属通过Section属性区分 Getting Started、Processes、Tools 等分区通过Owner、Visibility管理维护人与可见性how-to-guide-database.md 负责页面自身的结构化属性Complexity、Time Required、Prerequisites、Category、Last Tested、Tags。实际产出的页面形态可对照 examples/how-to-guide.md该示例完整展示了从提取部署步骤、Notion:notion-search定位到 Engineering Wiki → Deployment section再到生成带编号步骤、验证清单、故障排查表的最终 Wiki 页面可作为评估时期望输出的参照标准。评估场景二架构决策记录decision-record.json场景定位decision-record.json 覆盖另一类高频场景——架构/技术决策的留档。用户在对话中刚解释了为什么新服务选用 PostgreSQL 而不是 MongoDB模型需要把这段讨论沉淀为一份完整的决策记录。技能声明skills: [knowledge-capture]用户查询Document our decision to use PostgreSQL instead of MongoDB for our new service模拟上下文用户已说明决策理由、备选方案与权衡预期行为expected_behavior从对话上下文识别这是一条决策记录架构决策按决策结构组织Context → Decision → Rationale → Options Considered含 Pros/Cons→ Consequences → Implementation从上下文提取所做决策、备选方案PostgreSQL vs MongoDB、理由、权衡创建带Date、StatusAccepted、Deciders的文档在 Consequences 中同时包含正面与负面后果权衡用Notion:notion-search检查决策日志数据库是否存在若数据库存在询问用户是写入该库还是创建独立页面若写入数据库用Notion:notion-fetch获取 schema 并设置属性决策标题、Date、Status、DomainArchitecture、Deciders、Impact使用Notion:notion-create-pagesparent 为{ data_source_id }数据库或{ page_id }父页面应用正确的 Notion markdown 分区排版建议从架构文档或项目页面反向链接。成功标准success_criteria文档遵循 SKILL.md 内容类型中的决策结构全部关键章节齐全Context、Decision、Rationale、Options Considered每项含 Pros/Cons、Consequences、Implementation决策被清晰陈述选择 PostgreSQL 而非 MongoDB备选方案以 pros/cons 结构记录Rationale 依据对话上下文解释为何选择 PostgreSQLConsequences 同时包含正面收益与负面权衡若写入数据库属性按 schema 正确设置Decision、Date、Status: Accepted、Domain: Architecture、Impact文档带日期且状态为 Accepted使用正确的工具名Notion:notion-search、Notion:notion-fetch、Notion:notion-create-pages。与数据库模板的对应关系决策场景的落库模板是 decision-log-database.md其中定义了决策记录完整属性集Decision标题、Date、StatusProposed/Accepted/Superseded/Deprecated、DomainArchitecture/Product/Business/Design/Operations、ImpactHigh/Medium/Low、Deciders、Stakeholders、Related Decisionsrelation并给出页面正文模板Context → Decision → Rationale → Options Considered → Consequences → Implementation与常用视图按 Date 排序、过滤 StatusAccepted、按 Impact 分组等。对照示例 examples/decision-capture.md 可以看到一次完整的决策留档演练从 REST 迁移到 GraphQL 的决策被拆解为 Context50 端点的 REST API 痛点、Decision、Rationale、三个备选方案的逐项 Pros/Cons 与接受/否决结论、正负 Consequences、实施计划最后写入 ADR 数据库并建立反向链接——这正是决策类评估期望输出的样板。运行评估的完整流程按 evaluations/README.md 的说明运行评估共六步启用knowledge-capture技能本仓库对应技能为 notion-knowledge-capture提交评估文件中的用户查询如 Save this conversation about deploying our application to production to the team wiki提供评估文件指定的对话上下文如前置对话包含部署步骤、坑与最佳实践核对所有预期行为是否满足对照成功标准检查产出质量在 Haiku、Sonnet、Opus 三个模型上重复测试确认跨模型一致性。前置条件Notion MCP 连接评估依赖 Notion MCP 工具调用。若评估过程中出现 MCP 调用失败说明 Notion MCP 未连接此时需要按 SKILL.md 工作流第 0 步完成配置# 1. 添加 Notion 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此时应结束当前回答并告知用户重启后再从第 1 步继续。MCP 就绪后评估中会观察到的工具调用链为Notion:notion-search定位目标数据库/页面→Notion:notion-fetch获取数据库 schema→Notion:notion-create-pages创建结构化页面→Notion:notion-update-page维护索引与反向链接。预期技能行为详解四个可检查维度Knowledge Capture 评估把技能行为拆成四个维度每个维度都有明确的观察点1. 内容提取Content Extraction从对话上下文中准确捕获关键点而非泛化占位符保留具体技术细节命令、配置值、版本号这些正是知识沉淀的价值所在保留讨论中的语境与细微差别前提条件、适用范围、例外情况。2. 内容类型选择Content Type Selection正确识别内容类型how-to、FAQ、决策记录、Wiki 页面套用 reference/ 目录下对应数据库文档中定义的结构应用正确的 Notion markdown 排版。判定依据可参考 SKILL.md 中的类型判别提示过程性内容步骤、前置条件→ How-ToQA 式问答 → FAQ架构/技术取舍 → 决策记录团队通用资料 → Wiki/文档页。例如对话转 Wiki场景的判别信号是过程性 步骤化而决策记录场景的判别信号是备选方案 权衡 结论。3. Notion 集成Notion Integration搜索合适的目标位置Wiki、决策日志等创建标题清晰、结构良好的页面使用正确的父级parent放置数据库data_source_id或页面page_id包含可检索的标题与元数据属性。4. 质量标准Quality Standards内容可操作、面向未来复用技术准确性不丢失组织方式利于检索发现排版提升可读性。这四个维度与 database-best-practices.md 中的通用原则互为印证一致的命名Title 作为主标识、Status 跟踪生命周期、Tags 灵活分类、Owner 落实责任、包含元数据创建/更新时间、维护人、复核日期、启用发现机制充分打标签、建视图、链接相关内容。评估本质上就是检验这些最佳实践是否被模型真正执行。如何编写高质量的评估用例在 evaluations/README.md 的Creating New Evaluations一节给出了新增评估的五条指导原则使用贴近真实的对话内容——包含实际技术细节、决策或流程避免抽象空泛的示例覆盖不同的内容类型——How-To 指南、FAQ、决策记录、会议纪要、学习心得等都应各有用例变化复杂度——从简单捕获到复杂技术讨论都要有测试发现能力——验证模型能否找到正确的 Wiki 分区或数据库包含边界情况——内容类型不明确、上下文极简、分类重叠等易出错的场景。从现有两个评估文件的字段结构name、skills、query、context、expected_behavior、success_criteria可以看出新用例应遵循的模板query模拟真实用户指令context描述前置对话内容概要expected_behavior给出模型应展现的每个动作含工具名success_criteria给出可验证的产出断言。仓库中的 examples/ 目录conversation-to-faq.md 等提供了不同内容类型的完整捕获演示可作为编写新场景时期望输出的素材来源——例如 FAQ 场景展示了一段故障排查对话如何被拆解为多条 QA 条目、设置 Category/Tags/Last Reviewed 属性并更新 FAQ 索引页。成功标准的定义可测试性优先评估质量的高低取决于成功标准写得好不好。evaluations/README.md 专门给出了优劣对照合格的标准具体、可测试使用 How-To 格式组织内容并带编号步骤从对话中原样保留 bash 命令创建标题格式为 How to [Action] 的页面放入 Engineering Wiki → Deployment 分区不合格的标准模糊、不可测试创建了良好的文档使用了合适的结构保存到了正确的地方可以推断一条合格标准的本质是可断言要么能对输出文本做模式匹配标题格式、章节标题、命令是否逐字保留要么能对工具调用做检查是否调用了Notion:notion-search、parent 是否指向正确位置。这正是 JSON 文件中expected_behavior与success_criteria双层设计的原因——前者检查行为过程后者检查产出结果两者互补才能完整覆盖一个场景。从评估到质量闭环评估不是一次性验收而应融入技能的持续迭代。结合仓库整体结构推荐的质量闭环是用现有两个用例建立基线——分别覆盖对话转 Wiki与架构决策留档两条主路径在各模型上跑出基准表现按五条原则扩充用例矩阵——为 FAQ、学习笔记、会议纪要等类型补充场景加入边界用例以 reference/ 数据库模板为统一标尺——无论哪个用例产出都应对齐对应数据库的 schema 与内容模板用 examples/ 样例校准期望——评估文件的 success_criteria 可以随时对照示例中的成熟产出进行细化跨模型回归——任何技能提示词或模板改动后在 Haiku、Sonnet、Opus 上重跑全部用例确保一致性不退化。通过这套评估机制Knowledge Capture 技能把把对话变成结构化知识这一主观目标转化为一系列客观、可复现、可断言的行为检查从而让团队 Wiki、决策日志与 FAQ 库的知识沉淀质量可度量、可持续改进。【免费下载链接】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），仅供参考