Sanity 仓库中的 AILF 评估体系用 AI Literacy Framework 守护 Studio Schema 质量【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity导读本文围绕 Sanity Studio 开源仓库中repo/ailf这个特殊包展开讲解它如何承载 AI Literacy FrameworkAILFAI 素养框架评估配置从包的目录结构、defineRepoConfig配置入口到任务task定义格式、评估断言assertion再到与 GitHub Actions 的完整 CI 集成。读完本文你将掌握如何在一个大型前端 monorepo 中为AI 修改 Studio schema 配置这类变更搭建自动化的质量评估流水线并能直接复用本仓库中的任务模板与配置范式。一、背景为什么一个开源仓库需要 AI 素养评估Sanity Studio 是 Sanity 的核心开源产品仓库采用 pnpm workspace 管理多个包。随着 AI 编码工具如 Claude、Copilot 等越来越多地参与代码变更一个现实问题浮现出来AI 对 Studio schema 的改动是否符合 Sanity 的领域规范例如 slug 字段是否配置了 source 和 maxLength、图片字段是否强制要求 alt text、可枚举字符串是否用options.list约束——这些领域素养问题传统的类型检查与 lint 工具很难覆盖。packages/repo/ailf这个包正是为此存在的。它的 README 开宗明义AI Literacy Framework (AILF) evaluation configuration for this repository.即本仓库的 AILF 评估配置。评估会自动运行——通过.github/workflows/ailf-eval.yml在触及本包的 PR 上触发、每周定时运行并支持手动触发manual dispatch。这是一个用 AI 评估 AI 产出的闭环实践。二、包结构一个轻量的评估配置载体packages/repo/ailf目录结构如下packages/repo/ailf/ ├── .ailf/ │ ├── .gitignore │ ├── ailf.config.ts # AILF 仓库级配置入口 │ └── tasks/ # 评估任务定义.task.ts与参考答案.reference.ts │ ├── add-slug-field.task.ts / add-slug-field.reference.ts │ ├── string-dropdown-options.task.ts / string-dropdown-options.reference.ts │ ├── image-hotspot-alt-text.task.ts / image-hotspot-alt-text.reference.ts │ ├── add-reference-fields.task.ts / add-reference-fields.reference.ts │ ├── add-sort-orders.task.ts / add-sort-orders.reference.ts │ ├── boost-search-weight.task.ts / boost-search-weight.reference.ts │ ├── conditional-field-visibility.task.ts / conditional-field-visibility.reference.ts │ ├── configure-list-preview.task.ts / configure-list-preview.reference.ts │ ├── create-singleton-settings.task.ts / create-singleton-settings.reference.ts │ ├── organize-fields-with-groups.task.ts / organize-fields-with-groups.reference.ts │ ├── require-field-validation.task.ts / require-field-validation.reference.ts │ ├── restrict-portable-text.task.ts / restrict-portable-text.reference.ts │ └── set-initial-values.task.ts / set-initial-values.reference.ts ├── README.md ├── package.json └── tsconfig.json从结构可以看出 AILF 的两条设计原则配置即代码评估配置.ailf/ailf.config.ts、任务定义.task.ts和参考实现.reference.ts全部以 TypeScript 源码形式入库可版本化、可 Code Review任务成对出现每个任务都有对应的参考实现reference solution评估系统会将被测 Agent 的产出与参考实现对照评分。包本身不产生运行时产物package.json中只有极简的脚本与依赖{ name: repo/ailf, version: 6.4.0, private: true, description: AI Literacy Framework (AILF) evaluation configuration, type: module, scripts: { ailf: ailf }, devDependencies: { repo/tsconfig: workspace:*, sanity/ailf: ^7.37.0, sanity: workspace:* }, engines: { node: 22.12 } }ailf: ailf暴露了 CLI 入口配合pnpm exec ailf run使用sanity/ailf是 AILF 的框架依赖提供defineRepoConfig、defineTask等 APIsanity与repo/tsconfig是 workspace 内引用保证任务代码能按仓库统一的 TS 配置编译private: true表明它不发布仅作为仓库内部评估基础设施存在。三、核心配置defineRepoConfig逐项解析评估行为由.ailf/ailf.config.ts统一声明import {defineRepoConfig} from sanity/ailf export default defineRepoConfig({ source: production, owner: { team: studio, }, taskSource: { type: repo, }, triggers: { // On pull requests: just validate task files parse correctly. pr: { mode: validate-only, }, // When repo/ailf files change in a PR: run a real evaluation. pr-task-change: { mode: eval, paths: [packages/repo/ailf/**], }, // On merge to main: run evaluation (non-blocking). main: { mode: eval, blocking: false, notify: true, }, }, })各字段含义与设计意图配置项取值作用sourceproduction评估运行所用的数据/评分来源本仓库使用 production 级评估而非调试级owner.teamstudio评估结果的归属团队标识用于在 AILF 平台侧聚合归属taskSource.typerepo任务来源为仓库内定义的tasks/*.task.ts文件而非远程/平台侧任务triggers见下声明不同事件下的评估模式triggers是评估策略的核心本仓库配置了三种触发场景pr→validate-only任何 PR 上只做验证——确保.task.ts文件能被正确解析不消耗完整评估额度。这是低成本的门禁用于及早发现任务文件语法/结构错误pr-task-change→eval当 PR 修改了packages/repo/ailf/**下的文件即任务配置本身发生变化时执行真正的评估eval因为此时需要验证新任务的有效性与难度main→evalblocking: falsenotify: true合并到 main 后执行完整评估但不阻塞合并blocking: false仅通知结果notify: true避免评估耗时拖慢主分支流水线。这个三层策略体现了工程上对评估成本的精细控制日常 PR 只做廉价校验配置变更时升级为完整评估主分支上则始终以非阻塞方式积累评估数据。四、任务定义defineTask的完整字段语义任务文件如.ailf/tasks/add-slug-field.task.ts通过defineTask声明一个可被 AILF 执行的评估任务。以最典型的为博客文章添加 slug 字段任务为例import {defineTask} from sanity/ailf export default defineTask({ mode: literacy, id: add-slug-field, title: Add a slug field, area: studio, context: { docs: [ { path: studio/slug-type, }, ], }, docCoverage: true, referenceSolution: tasks/add-slug-field.reference.ts, prompt: { text: We need URLs for blog posts. Add a slug field that editors can generate from the post title, limited to 96 characters. A post must not pass validation without a slug. ..., }, assertions: [ { type: llm-rubric, template: task-completion, criteria: [ {id: adds-slug-field, text: The post type has a field of type slug.}, {id: slug-source-is-title, text: The slug field has options.source set to the title field.}, {id: slug-max-length, text: The slug field has options.maxLength set to 96.}, {id: slug-is-required, text: The slug field has a validation rule making it required.}, {id: exports-studio-configuration, text: Exports a valid Studio configuration.}, ], }, ], })字段语义字段说明modeliteracy表示该任务衡量 AI 对 Sanity 领域知识的素养literacy而非纯编码能力id/title任务的唯一标识与人类可读标题areastudio任务所属领域便于按模块分组统计context.docs允许 AI 参考的官方文档路径如studio/slug-type评估时作为上下文注入docCoveragetrue表示该任务要求或支持基于文档的完成度评估referenceSolution参考实现相对路径指向同目录的.reference.ts文件prompt.text给被测 Agent 的任务描述包含需求叙述 现有 Studio 配置代码块assertions评分断言本仓库统一使用llm-rubrictask-completion模板 结构化criteria列表prompt.text的设计非常贴近真实开发场景它以自然语言描述业务诉求博客需要 URL给 post 加一个从标题生成、最长 96 字符、必填的 slug 字段并附上完整的现有defineConfig代码。这样既能考察 AI 理解需求的能力又能验证其在真实 schema 上下文中的改动正确性。五、评分标准llm-rubric断言与参考实现每个任务的assertions.criteria把需求拆解为可逐条核验的事实断言。以 slug 任务为例五条标准分别覆盖字段类型slug、来源配置options.source、长度限制options.maxLength: 96、必填校验rule.required()以及最终配置可导出。参考实现.ailf/tasks/add-slug-field.reference.ts给出了标准答案import {defineConfig, defineType, defineField} from sanity export default defineConfig({ name: default, title: Blog, projectId: xxxxxxxx, dataset: production, schema: { types: [ defineType({ name: post, title: Post, type: document, fields: [ defineField({name: title, title: Title, type: string}), defineField({ name: slug, title: Slug, type: slug, options: { source: title, maxLength: 96, }, validation: (rule) rule.required(), }), defineField({name: publishedAt, title: Published at, type: datetime}), ], }), ], }, })参考实现与criteria一一对应type: slug↔ 断言 1options.source: title↔ 断言 2options.maxLength: 96↔ 断言 3validation: (rule) rule.required()↔ 断言 4。这种断言文本 参考代码双保险的设计既允许 LLM 打分器按语义核验也保留了一份可编译的黄金实现用于对照。仓库中其余任务覆盖了 Studio schema 配置的常见痛点可作为任务清单参考string-dropdown-options将自由文本约束为预定义枚举值options.list radio 布局 存储小写值见 任务定义image-hotspot-alt-text为图片开启options.hotspot并强制要求 alt text 字段必填见 任务定义add-reference-fields添加引用reference字段add-sort-orders配置排序字段与 orderingsboost-search-weight调整字段搜索权重conditional-field-visibility基于条件控制字段可见性hidden/readOnlyconfigure-list-preview配置列表预览preview.select/preparecreate-singleton-settings创建单例设置文档organize-fields-with-groups用 groups 组织字段require-field-validation为字段补充必填校验restrict-portable-text限制 Portable Text 的可用块/样式set-initial-values配置文档初始值。六、CI 集成.github/workflows/ailf-eval.yml全流程评估流水线由.github/workflows/ailf-eval.yml驱动README 中提到的三种触发方式在这里落地on: pull_request: branches: [main] paths: [packages/repo/ailf/**, .github/workflows/ailf-eval.yml] workflow_dispatch: inputs: debug_mode: description: Run in debug mode (fewer tests, faster iteration) type: boolean default: false schedule: # Every Monday at midnight. - cron: 0 0 * * 1PR 触发paths过滤使得只有改动packages/repo/ailf/**或工作流文件本身时才运行避免全量浪费手动触发支持debug_mode输入用于快速迭代更少测试定时触发每周一零点0 0 * * 1自动跑一次持续积累评估数据。concurrency配置ailf-eval-pr-number|refcancel-in-progress: true保证同一 PR 或分支上只有最新一次评估在运行避免排队堆积。执行阶段的核心步骤- name: Run evaluation id: eval working-directory: packages/repo/ailf env: AILF_API_KEY: ${{ secrets.AILF_API_KEY }} AILF_CLASSIFICATION: adhoc AILF_OWNER_TEAM: studio AILF_OWNER_INDIVIDUAL: ${{ github.actor }} run: | pnpm exec ailf run --remote \ --output /tmp/ailf-report.md \ ${{ inputs.debug_mode --debug || }}要点解读working-directory指向包目录与package.json中的ailf: ailf脚本呼应通过pnpm exec ailf run执行远程评估--remote报告输出到/tmp/ailf-report.md环境变量把运行上下文透传给 AILF 平台AILF_API_KEY走 GitHub Secrets 保管AILF_OWNER_TEAM: studio与配置中的owner.team一致AILF_OWNER_INDIVIDUAL动态取当前github.actor实现按人归属评估结果--debug由workflow_dispatch的debug_mode输入驱动作业设置了timeout-minutes: 60与最小权限contents: read、pull-requests: write并用.github/actions/setup统一准备 Nodelts环境。七、报告回写PR 评论与评分历史工作流最精巧的部分是用actions/github-script将评估报告回写到 PR 评论并维护最多 3 条的评分历史const MARKER !-- ailf-score-report --; const HISTORY_START !-- ailf-score-history --; const HISTORY_END !-- /ailf-score-history --; const MAX_HISTORY 3;逻辑要点读取/tmp/ailf-report.md若文件缺失则生成未生成报告的兜底评论并附工作流日志链接在 PR 现有评论中按MARKER查找上一次的评论若存在则从旧正文中拆出旧报告用details折叠成一条历史记录摘要显示日期与Overall: N/100分数插入历史区并截断到MAX_HISTORY条组装MARKER 新报告 历史区后用issues.updateComment/issues.createComment更新或新建评论。此外还有一个Summary步骤把报告内容追加到$GITHUB_STEP_SUMMARY让每次运行都能在 Actions 的汇总视图中直接看到评分概览。这套机制让评估结果沉淀为 PR 内可追溯的对话式记录而非只存在于流水线日志里。八、实践总结与复用建议从repo/ailf的实现可以提炼出一套可复用的AILF 评估接入模式包即边界用一个私有 workspace 包repo/ailf承载全部 AILF 配置与任务package.json只暴露ailfCLI 脚本依赖仅包含sanity/ailf与 workspace 内的sanity配置分层ailf.config.ts只声明策略数据源、归属、触发条件任务细节全部下沉到.ailf/tasks/每个任务 自然语言 prompt 文档上下文 结构化断言 参考实现成本分级PR 上validate-only、任务变更时eval、main 上非阻塞eval配合工作流paths过滤与concurrency控制让评估资源花在刀刃上结果可追溯PR 评论携带Overall: N/100分数与折叠历史AILF_OWNER_INDIVIDUAL按人归属团队层面以studio聚合统计。对于维护 Sanity Studio 这类以 schema 配置为核心的开源项目而言这套体系的价值在于它把AI 是否真正懂 Sanity从一个模糊的印象变成了可量化、可追踪、随 CI 自动运行的工程指标——这正是 AI 素养框架AILF在真实仓库中的落地样本。【免费下载链接】sanitySanity Studio – Rapidly configure content workspaces powered by structured content项目地址: https://gitcode.com/GitHub_Trending/sa/sanity创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考