分析师脑中的口径，如何变成 AI 可验证的上下文？Nodal 的领域访谈工作流
AI 能写出语法正确的 SQL，却仍可能答错业务问题：收入究竟按下单还是回款计算？哪个表才是权威来源？某个筛选条件是否必须保留？这些知识通常散落在分析师经验里，单靠数据库 schema 很难还原。
Nodal Context 试图把这类隐性知识转为可审阅、可版本管理的分析上下文，并让 AI 工作流在回答前规划、执行后验证。它不是一个替代数据仓库的语义层，也不是自动把模型生成内容当成事实的工具；核心环节仍由领域分析师确认。
先访谈一个业务领域，而不是一次建完整公司知识库
Nodal 建议按业务领域逐步推进。团队先选一个边界清楚的领域，例如订阅收入，再由熟悉该领域的分析师参与访谈。工具可结合查询历史、dbt 项目等证据，帮助发现常见问题、表关系和可能的业务定义；但定义是否正确，仍需要负责人确认。
这种渐进方式很实际：先验证一个领域的答案是否可靠，再扩展到其他领域，而不是一开始就要求全公司完成语义迁移。上下文以 Markdown、YAML 等可读文件保存于团队控制的仓库，便于审阅、版本追踪与协作。
工作流：定义、回答、验证
仓库提供一组面向 AI 编码 Agent 的 skills。整体思路可以概括为三步：
- 先规划：把业务问题转成自然语言计划，明确指标、数据源、筛选条件和不确定点，交给提问者确认。
- 再执行：通过团队自行配置、采用只读身份的数据连接执行查询。Nodal 的说明明确要求只读访问，不应把它当作数据库写入工具。
- 最后核验：检查实际执行是否符合已确认的计划，并对答案的不确定性作出说明；必要时可以进一步进行对抗式复核。
这与“让模型直接生成 SQL 并给出数字”不同：关键价值是把口径决策留在可检查的过程中，而不是隐藏在一次提示词里。
快速开始与权限边界
仓库 README 给出的安装方式按宿主 Agent 区分。以 Claude Code 为例：
claude plugin marketplace add nodal-data/nodal-context claude plugin install nodal-analytics@nodal
Codex 可使用其 plugin 命令；兼容 skills.sh 的宿主也可以通过 npx skills@latest add nodal-data/nodal-context 安装。应按所用宿主选择一种安装路径，不要把插件和 skills 副本同时装入同一环境，以免工作流重复出现或调用产生歧义。安装命令以项目 README 为准，更新前也应查看当前文档。
使用前，团队还需准备一位可确认业务定义的专家，以及经批准的只读数据访问。查询历史能帮助访谈发现真实工作负载，但权限不足时只能得到不完整样本；不能把“未看到某类查询”误解成“业务中不存在这种需求”。
项目也强调数据流边界：开源包由用户自己的 Agent 环境运行，不会把仓库、查询结果或凭据发送给 Nodal 服务。数据访问经由用户自行设置的 MCP 服务及只读身份完成。不过，Agent 本身仍由所选模型提供商处理其读取到的内容；“Nodal 不接收数据”并不等于数据不会离开本机，部署前仍须按组织策略评估模型提供商的数据处理条款。
让上下文接受回归检查
业务口径会变化，单有文档并不能保证答案持续正确。Nodal README 描述了可选的评估流程：为上下文建立评估问题，在加入上下文前后比较结果；也可以把模板接入用户自己的 GitHub Actions，在上游数据模型变化时重新运行检查。若配置 API 密钥，工作流还可请求模型协助提出上下文变更建议；建议仍应由人审阅，而不能自动视为批准。
因此，较稳妥的落地顺序是：先挑一个能由专家确认、数据权限明确的小领域；记录定义及其证据；建立少量代表性问题作为回归样例；再评估上下文是否改善答案。不要在没有权限核验、基准问题或责任人的情况下，把生成的口径直接推广给全组织。
Nodal 更适合已有数据仓库、拥有业务分析负责人，并愿意维护版本化上下文的团队。若组织尚无数据负责人，或期望工具自动发现并裁决所有业务定义，它并不能消除这些治理工作。它提供的是一套把“分析师知道但系统不知道”的规则显式化、可复查化的工作方法。