从 Spec 到实现的全链路技能评估awesome-codex-skills 中 notion-spec-to-implementation 评测体系深度解析【免费下载链接】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导读本文聚焦 notion-spec-to-implementation 技能目录下的 evaluations/README.md 评估文档系统讲解如何用结构化评测场景验证Notion 规格说明Spec→ 实现计划 → 任务 → 进度追踪这条自动化链路在 Codex 各模型Haiku、Sonnet、Opus上的稳定性与正确性。读完本文你将掌握评测文件的组织方式、两个内置评估场景的预期行为与成功标准、评估运行的完整步骤以及如何为新场景编写可量化、可回归的验收指标。一、为什么需要技能评估评测体系的定位与目的notion-spec-to-implementation是 awesome-codex-skills 仓库中把 Notion 上的 PRD/功能规格转化为可执行实现产物的 Codex 技能。技能本身解决的是文档到代码的翻译问题而 evaluations/README.md 解决的问题则是如何证明这个翻译过程是可靠的。根据评估文档该评测体系的核心目的包括五个层面准确地发现并解析规格页面Finds and parses specification pages accurately把规格拆解为可执行的实现计划Breaks down specs into actionable implementation plans创建 Codex 可以落地实现、且带有清晰验收标准acceptance criteria的任务Creates tasks that Codex can implement with clear acceptance criteria跟踪进度并更新实现状态Tracks progress and updates implementation status在 Haiku、Sonnet、Opus 三个模型上保持一致的表现Works consistently across Haiku, Sonnet, and Opus最后一条尤其关键技能评估不仅是功能正确性测试更是一种跨模型的一致性回归测试。因为不同模型在解析自然语言、抽取结构化需求、拆解任务粒度上的能力存在差异评测需要保证无论由哪个模型驱动技能的端到端产出搜索规格 → 提取需求 → 制定计划 → 建任务 → 追踪进度都能稳定收敛到同一套质量基线。二、评估文件清单两个内置评测场景评测场景以 JSON 文件形式存放在 notion-spec-to-implementation/evaluations/ 目录下每个文件都是一个自包含的可执行评测用例包含场景名称、依赖的技能、用户查询query、期望行为步骤expected_behavior与成功标准success_criteria。这种查询 步骤 验收的结构使得评测既可以被 Agent 自动执行也可以被人工逐步核验。2.1 basic-spec-implementation.json规格转实现计划文件 basic-spec-implementation.json 测试的是把一份规格转成实现计划的基础工作流覆盖技能最核心的链路。场景根据规格实现用户认证User Authentication功能。期望行为12 步调用链使用Notion:notion-search以 User Authentication spec、auth spec 等关键词搜索规格页若未找到或结果有歧义向用户索要规格页 URL/ID使用Notion:notion-fetch按搜索结果中的 URL/ID 抓取规格页依据 reference/spec-parsing.md 中的解析模式抽取需求、验收标准与约束区分功能需求用户故事、特性、工作流与非功能需求性能、安全按照 reference/standard-implementation-plan.md 的模板结构创建实现计划计划须包含Overview概述、Linked Spec关联规格、Requirements Summary需求摘要、Technical Approach技术方案、Implementation Phases实现阶段将工作拆解为多个逻辑阶段每个阶段包含 Goal目标、Tasks checklist任务清单、Estimated effort预估工作量从规格内容中识别依赖与风险使用mention-page url...将计划页链接回原始规格页使用Notion:notion-create-pages创建计划页标题如 Implementation Plan: User Authentication将计划页放置到合适位置询问用户或建议放在项目/规格页的父级下。成功标准success_criteria规格必须先经notion-search找到再 fetch计划须包含清晰的概述与mention-page标签链接的规格需求必须来自真实规格内容而非泛化模板工作被拆成多个阶段通常 3~5 个每个阶段有 Goal、复选框任务与工作量预估依赖与风险节包含规格中的具体细节验收标准在计划中被引用整体遵循正确的工具序列Notion:notion-search → Notion:notion-fetch → Notion:notion-create-pages。2.2 spec-to-tasks.json规格直接生成任务文件 spec-to-tasks.json 测试的是从规格在任务数据库中创建具体任务的场景且明确声明同时依赖spec-to-implementation与task-manager两个技能覆盖了数据库集成database integration这一更复杂的路径。场景阅读 Payment Integration 规格在 Tasks 数据库中创建实现任务。期望行为14 步调用链用Notion:notion-search搜索 Payment Integration 规格找不到则向用户索要 URL用Notion:notion-fetch抓取规格全文依据 reference/spec-parsing.md 模式解析工作项依据 reference/task-creation.md 的拆解模式把工作拆成大小合适的任务用Notion:notion-search定位 Tasks 数据库用Notion:notion-fetch抓取数据库以获取 schema、属性名与数据源从 fetch 结果中的data-source标签识别正确数据源推荐先创建实现计划页再建任务为每个任务调用Notion:notion-create-pagesparent 使用{ data_source_id: collection://... }按 schema 设置任务属性Title、StatusTo Do、Priority、Related Tasks链接到规格任务描述包含上下文、来自规格的验收标准与依赖用mention-page把任务链接回规格页任务之间按依赖相互链接合理排序任务setup → implementation → testing参照 reference/task-creation.md汇报摘要Created X tasks for Payment Integration: [task list with links]。成功标准先搜索规格再 fetch先搜索任务数据库再 fetch schema从data-source标签识别数据源创建至少 3~5 个覆盖规格范围的任务任务粒度符合 reference/task-creation.md 的 1~2 天标准每个任务有从规格抽取的清晰验收标准任务通过关系属性正确排序与依赖所有任务用mention-page链接回规格任务属性与数据库 schema 完全一致parent 正确使用data_source_id: collection://...工具调用序列为Notion:notion-search (2x) → Notion:notion-fetch (2x) → Notion:notion-create-pages (Nx)。可以看到两个评测文件在结构上完全同构发现 → 抓取 → 解析 → 规划 → 创建 → 链接但在输出产物上互为补充一个产出计划页一个产出数据库任务。二者共同构成规格驱动开发的两条主路径。三、运行评估从评测文件到可验证结果评估文档给出了 8 个标准运行步骤结合 SKILL.md 中的环境准备说明可以归纳为完整的三阶段流程前置条件连接 Notion MCP运行评估前必须先确保 Notion MCP 已连通否则所有Notion:notion-*工具调用都会失败。SKILL.md 明确给出了配置命令# 1) 添加 Notion MCP codex mcp add notion --url https://mcp.notion.com/mcp # 2) 启用远程 MCP 客户端二选一 # 方式 A在 config.toml 中设置 [features].rmcp_client true # 方式 B运行 codex --enable rmcp_client # 3) 使用 OAuth 登录 codex mcp login notion登录成功后需要重启 Codex模型应告知用户重启后从第 1 步继续。评估执行步骤对应 README 的 8 步启用spec-to-implementation技能提交评测文件中的 query例如 Create an implementation plan for the User Authentication spec page验证技能是否先通过搜索找到规格页而非直接凭猜测 fetch检查需求是否被准确解析确认实现计划按阶段创建验证任务是否具有清晰、可实现的验收标准检查任务是否正确链接回规格分别在 Haiku、Sonnet、Opus 三个模型上重复测试。其中第 3、6、7 步是判断技能真的在工作还是模型在自由发挥的关键分水岭——它们要求产物之间存在结构化的关联证据搜索命中 → 链接回源而不是仅仅输出一段看起来合理的文本。四、预期技能行为四条质量检查线评估文档将预期技能行为拆成四条可验证的检查线每条线都对应技能工作流中的一个环节也与 SKILL.md 中的 Workflow定位规格 → 选择计划深度 → 创建任务 → 链接产物 → 跟踪进度一一对应。4.1 Spec 发现与解析Spec Discovery Parsing对应 SKILL.md 第 1 步Locate and read the spec。评估要求技能在 Notion 中搜索规格页面抓取完整的规格内容准确抽取全部需求识别技术依赖理解验收标准记录歧义与缺失细节。reference/spec-parsing.md 为此提供了可复用的解析方法搜索时用[Feature Name] spec或[Feature Name] specification作为查询词并设置query_type: internal抓取后按需求型规格 / 用户故事型规格 / 技术设计文档 / PRD四类常见结构分别抽取功能需求、非功能需求、验收标准、用户画像、业务目标、成功指标等并通过 Must/Should/Will、REQ-1、As a... I want... 等信号词定位需求按 Critical/P0、Important/P1、Nice to have/P2、Future/P3 划分优先级。对模糊需求、缺失信息、冲突需求文档要求用标准化的 Clarifications / Missing Information / Conflicting Requirements 块记录不能默默跳过。4.2 实现规划Implementation Planning对应 SKILL.md 第 2 步Choose plan depth简单变更用 reference/quick-implementation-plan.mdSpec / Summary / Tasks / Timeline / Status 五段式多阶段特性或迁移用 reference/standard-implementation-plan.mdOverview / Linked Specification / Requirements Summary / Technical Approach / Implementation Phases / Dependencies / Risks / Timeline / Success Criteria / Progress Tracking 完整结构。评估要求创建实现计划页把工作拆成逻辑阶段标准三段为Phase 1: Foundation/Setup基础与搭建Phase 2: Core Implementation核心实现Phase 3: Testing Polish测试与打磨包含时间预估识别阶段间依赖链接回原始规格。标准计划模板中的每个阶段都要求给出 Goal、任务清单以- [ ]复选框形式配合mention-page内链与 Estimated effort并在末尾附上 Timeline 里程碑表格Milestone / Target Date / Status与 Success Criteria技术成功 业务成功。4.3 任务创建Task Creation对应 SKILL.md 第 3 步Create tasks。评估要求技能找到或识别任务数据库抓取数据库 schema 以获取属性名以正确属性创建任务每个任务具备清晰具体的标题、上下文与描述、验收标准清单格式、合适的优先级与状态、指向规格页的链接任务粒度适中不大不小任务间依赖被记录。reference/task-creation.md 给出了粒度黄金标准单个任务 1~2 天可完成、单一明确交付物、可独立测试、最少依赖超过 3 天属于过大需继续拆分少于 2 小时属于过碎应合并。创建时通过Notion:notion-create-pages以parent: { type: data_source_id, data_source_id: collection://tasks-db-uuid }写入数据库并设置 StatusTo Do、Priority、Relation 属性与 Due Date。任务命名采用动作动词约定Setup / Implement / Integrate / Test / Document / Fix / Refactor 前缀例如 Implement: User login flow 而非模糊的 Add login。4.4 进度追踪Progress Tracking对应 SKILL.md 第 5 步Track progress。评估要求实现计划包含进度标记任务可以随工作推进被更新状态更新链接到已完成的工作阻塞项或变更被记录。reference/progress-tracking.md 定义了更新节奏每日更新、里程碑更新、状态变更更新三类、状态机To Do → In Progress → In Review → Done外加 Blocked 分支、标准化的进度笔记格式Completed / In Progress / Next Steps / Blockers / Decisions Made / Notes以及计划页上的 Overall Progress 百分比、阶段状态✅//⏳与任务汇总统计。配套的 progress-update-template.md 与 milestone-summary-template.md 分别覆盖日常更新与阶段收尾两种场景确保计划页 唯一事实源source of truth。五、创建新的评估场景六条编写指南评估文档为扩展评测覆盖度给出了六条指导原则核心是用组合矩阵铺开评测空间测试不同类型的规格特性features、迁移migrations、重构refactors、API 变更、UI 组件——对应仓库中 examples/ 下的 api-feature.md、database-migration.md、ui-component.md 等端到端走读示例变化复杂度从单一阶段的简单规格到多阶段的复杂实现测试任务粒度技能是否产出大小合适的任务纳入边界情况模糊规格、冲突需求、缺失细节测试数据库集成在不同 schema 的既有任务数据库中创建任务测试进度追踪任务完成后实现计划能否同步更新。编写新评测时可完全复用 basic-spec-implementation.json 与 spec-to-tasks.json 的 JSON 骨架——name场景名、skills依赖技能数组、query模拟用户输入、expected_behavior带编号的步骤化期望、success_criteria可判定的通过条件——只需替换业务场景与验收断言。这种结构化设计让评测用例天然具备可机器断言、可人工复核、可跨模型回归三种用途。六、成功标准示例如何写出好的验收标准评估文档用 Good/Bad 对照的方式给出了写验收标准的纪律——这本身就是评估体系设计哲学的核心一切断言必须可观察、可判定、可复现。好的标准具体、可测试Searches Notion for spec page using feature name用特性名搜索 Notion 规格页Creates implementation plan with 3 phases: Setup → Core → Polish创建含 3 个阶段的实现计划Creates 5-8 tasks in task database with properties: Task (title), Status, Priority, Sprint创建 5~8 个任务并携带正确属性Each task has acceptance criteria in checklist format (- [ ] ...)每个任务有清单格式的验收标准Tasks link back to spec using mention-page tag任务用 mention-page 标签链接回规格Task titles are specific and actionable (e.g., Create login API endpoint not Authentication)任务标题具体可执行坏的标准模糊、不可测试Creates good implementation plan创建好的实现计划——什么是好Tasks are well-structured任务结构良好——如何度量Breaks down spec appropriately适当地拆解规格——何为适当Links to spec链接到规格——用什么方式、链接到哪写坏标准很容易因为它不需要任何领域知识写好标准则必须把断言下沉到可观测的产物属性阶段数量、属性名集合、清单语法、内链标签、标题动词这正是 evaluations/README.md 全文一以贯之的度量哲学。同样的判断标准也适用于技能内部的验收标准抽取——reference/spec-parsing.md 明确要求把 System is fast 改写成 Page loads in 2 seconds 这类可测试表述隐含的验收标准也要从需求推导如支持 100MB 上传应推导出100MB 以内成功 / 超过 100MB 被拒绝并报错 / 显示进度条 / 可取消四条断言。七、评估体系与技能资产的整体闭环最后把评估文档放回技能包整体来看notion-spec-to-implementation目录是一个参考文档 模板 示例 评测四层配套的完整资产结构——SKILL.md技能入口定义五步工作流与 MCP 配置方式reference/8 份解析模式与模板spec-parsing、quick/standard-implementation-plan、task-creation 及其模板、progress-tracking、progress-update、milestone-summaryexamples/3 份端到端走读示例覆盖 API 特性、数据库迁移、UI 组件三类典型场景evaluations/本篇文章主体——2 个 JSON 评测场景 运行指南 预期行为 新场景编写规范 成功标准示例。评估文档正是这个资产体系的质检关卡参考文档定义了技能应该怎么做评测定义了如何证明技能做对了。对于希望在 Codex CLI/API 之上构建规格驱动开发工作流的团队这套评测模式可以直接迁移把业务 PRD 写成标准化规格用notion-search → notion-fetch → notion-create-pages → notion-update-page的工具链自动产出计划与任务再按本文的 Good 标准为每个产物编写可回归的验收断言最终形成规格 → 计划 → 任务 → 进度全链路可观测、可度量、可跨模型复现的自动化交付闭环。【免费下载链接】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），仅供参考