
Lightdash Learn 课程覆盖率契约用自动化审计守护应用内 Walkthrough 的发布质量【免费下载链接】lightdashAgentic BI. Analytics at the speed of code ⚡️项目地址: https://gitcode.com/GitHub_Trending/li/lightdashLearn 是 Lightdash 内置的应用内培训体系它在每个组织里创建一个基于示例数据的训练项目并为每项权限scope提供可点击操作的引导式 Walkthrough。本篇文章围绕仓库中的 docs/learn/content-coverage.md 展开讲清楚 Learn 的覆盖率契约Curriculum Coverage Contract如何定义一课到底算不算已交付、六种范围处置disposition如何分类、严格发布审计如何拦截缺口并结合 scripts/scope-tours/coverage.ts、packages/frontend/src/features/learn/comingSoon.ts 与配套命令给出可复现的审计实操与源码级原理。读完本文你将掌握 Learn 课程目录的验收标准、审计命令的用法以及如何为新增权限补充 Walkthrough 或显式处置以通过发布门禁。一、覆盖率契约要解决什么问题Learn 提供两类学习形态生成式应用内 Walkthroughgenerated in-app walkthroughs与被禁用模块上的Coming Soon 卡片。契约的第一条硬性规定是阅读确认reading acknowledgments不计入 Walkthrough 完成。也就是说读过一页文档不能替代在真实产品里亲手完成一次操作。docs/learn/walkthrough-priorities.md 中多次强调只有通过真实交互、在一次性训练副本disposable training copy中完成任务并获得可见结果才算是完成一个实操型 scope 的教学目标。在现状上文档给出了两组精确数字目录中现有41 个 Walkthrough scope 条目对应39 条不同的点击路径即两条路径被复用24 个 Coming Soon scope 条目全部显式列在packages/frontend/src/features/learn/comingSoon.ts中。覆盖率审计coverage audit负责将三方面输入对齐getTrainingProjectScopes()——训练副本实际授予的权限集合定义于 packages/common/src/authorization/roleToScopeMapping.ts显式的分析与 Agent 文档义务analytics 与 agent-document obligations生成的SCOPE_TOURSpackages/frontend/src/features/scopeTours/generated.ts以及 scripts/scope-tours/coverage.ts 中的处置表。审计只做覆盖核算不改变任何权限授予。另外带修饰符的权限变体modifier variants如self、space会被过滤掉——它们在目录中与基础权限共享同一条教学路径不再单独计数这与目录的统计口径保持一致。二、六种范围分类与发布门禁覆盖率契约的核心是一张分类表它决定了某个 scope 当前处于什么交付状态、是否阻塞发布分类含义是否阻塞发布generated在该精确 scope key 下已存在一个 Walkthrough否comingSoon显式登记的不受支持模块以 Coming Soon 卡片展示否related有其他教程与之相关但该权限的教学结果未经验证是pending存在未经批准的内容缺口或前置条件缺口是excluded已登记的基线/背景权限或产品表面不存在的权限否unclassified该 scope 既没有 Walkthrough也没有任何处置是注意related与pending的语义差异related意味着有相关内容可学但这门课还没有真正验证该权限的教学效果pending则代表内容或前置条件上存在明确的缺口。两者都会阻塞发布这正是严格审计的价值所在——不允许差不多的状态溜进发布线。在源码层面scripts/scope-tours/coverage.ts中的auditCoverage()函数实现了这套逻辑它输出一个CoverageAudit结构包含六类计数之外还额外跟踪四类异常staleDispositions处置表中登记的 scope 如今已有 Walkthrough或该 scope 已不存在处置表过期missingTours处置声明引用了不存在的 tourdisposition.tour指向的键不在SCOPE_TOURS中invalidDispositions处置本身非法——reason为空、ticket不匹配/^CS-\d$/必须指向合法的 Linear 工单号、status不在pending/excluded/related/coming-soon四值之内或related状态未附带tourunclassified训练权限集合中既没有 tour 也没有处置的 scope。最终ok判定要求unclassified、staleDispositions、missingTours、invalidDispositions全部为空若开启严格模式strict还额外要求pending与related均为空。审计命令带--release参数即进入严格模式见下文命令一节。三、Coming Soon 是产品决策而非权宜之计文档特别强调Coming Soon 是 2026-09-10 确认的产品决策。不支持的模块保持可见以卡片形式呈现而新的交互式交付格式将在独立工单中另行设计。由此带来三点行为约束Coming Soon 不计入已生成内容、不计入已完成学习、也不计入可用的推荐项除显式登记的 Coming Soon 条目外其他不支持模块不得以未支持模块名义上线本次变更没有创建新的交付格式工单CS-212 仍是课程目录的父级参考工单parent curriculum reference。目录中有5 项显式排除excluded理由在SCOPE_DISPOSITIONS中逐一登记view:Project基线项目访问权限没有独立成课的产品表面view:Job、view:JobStatus后台任务类权限没有独立的学习者操作表面view:SemanticViewer、manage:SemanticViewer目录中未记录对应产品表面。这 5 项共同说明一条重要原则某权限没有课和某权限缺失处置是两种状态。前者只要显式登记即可通过审计后者未分类会直接失败。因此任何删除 Walkthrough 的操作如果不同时补充显式处置都会导致审计不通过——这是防止悄悄砍课的硬性防线。四、审计命令与可复现操作在仓库根目录使用固定的 Node 版本运行以下三个命令均定义在根 package.json 中pnpm scope-tours:coverage pnpm scope-tours:coverage:test pnpm scope-tours:release-check它们的内部实现分别是scope-tours:coverage→tsx scripts/scope-tours/coverage.ts直接执行审计输出 JSON 报告并以退出码表达结果ok为真时退出码 0否则为 1scope-tours:coverage:test→tsx scripts/scope-tours/coverage.test.ts运行覆盖审计的单元测试见 scripts/scope-tours/coverage.test.tsscope-tours:release-check→tsx scripts/scope-tours/coverage.ts --release与第一条相同但传入--release进入严格模式——此时任何pending或related都会导致失败适用于发布前的门禁检查。从源码看审计的输入拼接是auditCoverage( [...getTrainingProjectScopes(), ...ADDITIONAL_CONTENT_SCOPES], // 训练副本权限 显式内容义务 Object.keys(SCOPE_TOURS), // 已生成的 Walkthrough 键 SCOPE_DISPOSITIONS, // 处置表 process.argv.includes(--release), // 是否严格 )其中ADDITIONAL_CONTENT_SCOPES指训练角色之外仍需显式跟踪的三项内容义务view:Analytics、view:AiAgentDocument、manage:AiAgentDocument。必须清醒认识审计的边界——文档明确警告生成内容的存在并不能证明浏览器端执行成功、教学质量、种子数据可用性或训练文案隔离。这些都需要单独的检查浏览器执行由 smoke 驱动pnpm scope-tours:smoke验证教学文案仍由规范文档通过前端标记与scope-tours:generate供给无需单独的阅读生成器。五、二十四项 Coming Soon 的构成与特例packages/frontend/src/features/learn/comingSoon.ts显式列出全部 24 项 Coming Soon scope。按 docs/learn/walkthrough-priorities.md 中的归类其中 21 项尚未排期具体构成是12 项 embedding 类view:EmbedDashboardFilters、view:EmbedDashboardFilterAddition、view:EmbedDashboardParameters、view:EmbedCsvExport、view:EmbedImageExport、view:EmbedPagePdfExport、view:EmbedDashboardCsvExport、view:EmbedDateZoom、view:EmbedExplore、view:EmbedUnderlyingData、view:EmbedDataApps、view:EmbedAiAgent3 项 content-as-code 类view:ContentAsCode、create:ContentAsCode、manage:ContentAsCode2 项 promotion 类promote:SavedChart、promote:Dashboardvalidation 类manage:Validationanalytics 类view:Analytics2 项 agent-document 类view:AiAgentDocument、manage:AiAgentDocument。此外还有view:Document、manage:Document两项以及一项特殊处理manage:DeletedContent。manage:DeletedContent值得单独说明它的 Walkthrough 曾通过 Browse 菜单入口和一条为 Learn 单独添加的独立路由standalone route进入最近删除Recently deleted页面——但这两者都是在没有产品决策的情况下添加的现已全部移除。CS-311 负责在与产品团队就最近删除功能入口位置达成一致后再让该 Walkthrough 回归。在代码里它同样被列为 coming-soon但处置原因reason明确写为Walkthrough withdrawn已撤回。这些模块之所以是 Coming Soon 而非直接生成 Walkthrough是因为它们的执行环境与访问约束需要单独工作embedding 需要嵌入式宿主环境、content-as-code 涉及代码仓库交互等新的交互式格式将以独立工单形式陆续交付。六、应用内课程优先级九条已生成的 Walkthrough2026-09-09 确认的课程方向是优先覆盖已有应用内路径in-app paths的权限。Learn 的教学目的始终是让学习者通过真实产品交互、在一次性训练副本中学会对应权限——阅读确认不能算完成实操目标。当前共有9 个 scope 使用生成式应用内 Walkthrough7 条新路径 2 条复用路径取代了原先的阅读回退方案其余 21 个 scope 条目改为显示 Coming Soon。阅读式交付已于 2026-09-10 移除。九条教学目标的优先级、工作内容与验收结果如下表顺序Scope工作内容必需的教学结果1manage:CustomSql检查并复用 CS-224 中已有的 SQL Runner 保存流程学习者保存一个 SQL 图表并看到已保存的图表2view:ContentVerification复用或扩展 CS-220检查验证指示器学习者在已验证内容上定位到该指示器2manage:VerifiedContent扩展验证教学加入对已验证内容的编辑学习者看到编辑对验证状态的文档化影响仅完成验证不满足该目标3manage:ChangeCsvResults扩展导出流程与 PR #28911 的变更对齐学习者更改导出选项并获得对应结果仅解释是不够的4view:SpotlightTableConfig增加管理列可见性的路径学习者检查已保存的目录列配置4manage:SpotlightTableConfig切换一列并在学习者副本中保存配置变更后的可见性在刷新该副本后仍然保持5manage:VirtualView用 Explorer 菜单的编辑路径扩展虚拟视图创建学习者编辑一个一次性虚拟视图并看到变更生效5delete:VirtualView增加删除一次性虚拟视图学习者删除该视图并验证其已移除仅创建不满足该目标6manage:DeletedContent检查最近删除可用性并增加恢复一次性图表的路径被恢复的图表出现在其所在空间若教学永久删除则使用单独的一次性条目注意表中的验收措辞反复出现alone does not satisfy this outcome仅……不满足该目标——例如仅验证内容不算完成manage:VerifiedContent仅解释导出选项不算完成manage:ChangeCsvResults仅创建视图不算完成delete:VirtualView。这再次印证覆盖率契约的核心立场教学结果必须以可观察的产品状态变化为准。七、交付标准与验证要求每条 Walkthrough 的交付必须遵守以下标准优先复用现有控件与锚点而非新增控件scope 映射只有在其动作与观察到的结果确实能教授该 scope时才允许复用既有 tour步骤由前端标记生成、文案取自规范文档遵循.claude/skills/add-scope-walkthrough/SKILL.md的流程使用现有的学员权限trainee permissions——如果缺少路由、功能开关、fixture 或可访问的控件那是需要调查的显式依赖而非临场加权限的理由每条流程必须在全新训练副本中用录制者账号验证包括可见结果、与共享源的隔离以及副本清理不支持的模块显示 Coming Soon内容存在性与已验证的实操完成在覆盖率与报表中严格区分。验证的可执行细节每条 Walkthrough 必须满足在全新训练副本中、仅使用高亮控件即可完成检查持久化结果、与共享训练项目的隔离以及在返回图书馆时副本被删除。验证使用专用账号walkthrough-recorderlightdash.com——这样一次冒烟运行smoke run不会误删真实用户的活跃训练副本。scope-tour 冒烟驱动器scripts/scope-tours/smoke.ts在允许完成前会先检查已保存的 metrics-tree 结果画布导出与已验证图表的回归测试还会额外检查异步完成与保存就绪状态。但请记住生成式 Walkthrough 存在 覆盖率审计通过 ≠ 浏览器流程成功后者必须由冒烟单独验证。权限测试必须区分组合训练角色与单个授权两种情形原始验证者verifiers可以保存并重新验证自己的内容原始删除者deleters可以恢复自己的内容虚拟视图更新在后端检查create:VirtualViewmanage:ChangeCsvResults在前端门控导出选项。课程本身不改变这些授权规则——覆盖率审计只核算覆盖状态权限授予逻辑保持独立对应 packages/common/src/authorization/roleToScopeMapping.ts 与 packages/backend/src/models/UserModel.ts 中的实现。八、后续工作与课程边界当前课程还有两部分处于待办状态21 项 Coming Soon 模块的执行环境与访问约束需要单独工作新交互格式将作为独立工单交付阅读式交付已彻底移除课程还包含查看与构建已保存 metrics tree、查看 AI Agent、查看数据应用等范围其前置条件包括 metrics-tree 的种子数据与复制、教学样本的保留、以及表单恢复能力。九、延伸阅读docs/learn/walkthrough-priorities.md——应用内课程优先级、九条目标的验收要求与验证细节docs/learn/architecture.md——Learn 的架构级视图训练项目类型、权限层、训练副本生命周期与 Walkthrough 生成机制docs/learn/maintaining-walkthroughs.md——产品变更导致 Walkthrough 损坏时的维护流程、smoke 运行方法与 CI 失败排查scripts/scope-tours/coverage.ts——覆盖率审计的完整实现处置表、auditCoverage与严格模式packages/frontend/src/features/learn/comingSoon.ts——24 项 Coming Soon scope 的显式清单packages/frontend/src/features/learn/catalogue.ts——Learn 图书馆目录的构建逻辑分组、门控、可用性与排序。【免费下载链接】lightdashAgentic BI. Analytics at the speed of code ⚡️项目地址: https://gitcode.com/GitHub_Trending/li/lightdash创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考