30 天导入 AI 分析的合理目标，不是让全员都开始问 AI，而是用一个真实、风险可控且会被追问的分析，验证资料范围、Plan 审阅、SQL evidence、Report 与权限流程。月底应得到可否扩大的证据与失败清单，而不是一场看起来顺利的 demo。
第 1–3 天：选对场景与 owner
好试点同时具备四项：
- 资料已存在，且范围能锁定；
- 问题曾有口径争议或需要重跑；
- 答案有实际用途，但错误不会立刻造成不可逆损失；
- 有一位业务 owner 与一位分析 reviewer 愿意参与。
适合例子是季度 onboarding 复盘、退款原因分布或既有活动成效回顾。不适合的第一案是薪资、授信、法遵判定、医疗决策，或跨数十系统但没人说得清口径的专案。
产物是一页试点章程：决策问题、资料来源、禁止范围、owner、成功标准与退出条件。
第 4–7 天：建立最小品质底线
先定义团队对「正式分析」的最低契约：
- Execute 前 Plan 必须有人审；
- Plan 至少写分母、grain、时间窗、join key 与 checkpoint；
- 关键数字能回到 SQL evidence；
- Report 必须含具体数字与 limitations；
- Quick 结果需标示为探索，不直接对外。
再准备两组测试：一组资料品质检查（NULL、duplicate key、日期新鲜度），一组指标验收（与既有可信结果比对、抽查个案）。NIST AI RMF 将风险管理定位为设计、开发、使用与评估的持续工作；试点的品质底线应能实际被观察与记录，而不是只是一句「需人工监督」。NIST AI RMF
第 8–14 天：跑第一个真实案例
让使用者从自然语言需求开始，但不要直接要最后答案：
目标：找出 onboarding 最大流失点，供下季改善排序。
对象：7 月首次启用试用的 account。
要求：先探索 schema 并起草 Plan；在我核准前不要跑正式分析。
审 Plan 时，刻意邀请非 SQL 的业务 owner 留至少一条口径批注。执行后核对：SQL 是否对应 Plan、checkpoint 是否真的跑过、Report 是否把观察与推论分开、限制是否具体。
这周不要只记成功画面。记录每次人工介入、口径修正、查询错误、工具失败与重跑原因。
第 15–18 天：专门审失败，而不是急着扩大
把问题分成四类：
| 失败类型 | 例子 | 优先修正 |
|---|---|---|
| Context | 不知道退款定义 | 补 Reference／专案知识，不只是改 prompt |
| Data | key 重复、日期缺漏 | 资料品质 checkpoint、缩小结论 |
| Workflow | 未审 Plan 就引用结果 | 权限、状态与交付规则 |
| Interpretation | 把相关写成因果 | Report 模板与人工 reviewer |
若错误来自缺乏业务定义，就把定义连同来源与适用范围沉淀；若定义仍有争议，不要直接存成 Agent 的长期真理。修复的是资讯与工作环境，不是无限加长一条 prompt。
第 19–23 天：定义权限、观测与复原
先回答「谁能做什么」：
- 谁能看哪些 workspace／资料来源；
- 谁能建立 artifacts 或执行正式查询；
- 谁能核准 Plan、管理连线或汇出结果；
- 活动纪录保留什么、多久、谁查看；
- credential 如何 expiry、rotate、revoke；
- Agent 中断或 writer conflict 如何处理。
若使用外部 Agent，第一次先走最小 scope 与低权限；不要因 demo 顺利就长期留下 Admin。MCP 官方安全指南建议最小预设权限、明确授予额外能力，并限制本机 server 的档案、网路与系统资源。MCP Security Best Practices
第 24–27 天：用第二个案例测可重复性
第二案不要复制第一案资料，但应使用相同品质规则。选另一位使用者、相邻问题，观察：
- 他能否理解何时用 Quick、何时用 Project；
- Plan 模板是否真的降低漏项；
- 没有原作者在场时，SQL 与 evidence 能否被接手；
- 同一问题重跑时，口径与限制是否一致。
如果流程只在原试点 champion 陪同时成立，代表还不能扩大。
第 28–30 天：用四组指标做决策
不要只量「省了几分钟」。建议保留：
- 品质：Execute 前口径修正数、checkpoint 发现数、Report 退回原因。
- 可重现性：重跑时间、接手者找到 evidence 的时间、缺失 artifact 数。
- 交付可用性：Report 中可直接采用比例、limitations 完整度、owner 是否愿意签收。
- 治理：权限例外、失败撤销、writer conflict、敏感内容进 log 的事件。
月底决策可以是扩大、保留小范围、补强后再试，或停止。停止也可能是成功的试点结果：它证明目前资料与责任机制尚未适合放大。
Lantide Data 如何支援这条路线
Lantide Data 是 local-first 的桌面 SQL 分析 IDE 与 Agent runtime。Quick／Project 双轨避免小问题过度流程化；正式分析以 Plan、批注、使用者 Approve & Execute、SQL evidence 与 Report 推进；Agent Memory 的知识先进 Queued Knowledge 再由人核准；外部 Agent 则可透过本机 MCP Server 受 workspace scope 与 Observe／Execute／Admin 限制。可搭配 产品试点与推广路线。
它适合本机表格资料、adhoc SQL 分析与需要审阅交付的小型团队。它不是 ETL scheduler、多人 BI server、企业 IAM 或自动决策系统；资料是否送往外部模型与 connector 的条件，也仍须依实际设定与供应商逐一检查。
30 天完成定义
月底应至少留下：两份真实 Executed Report、对应 Plan 与 SQL evidence、一份失败分类、最小权限表、撤销演练纪录、扩大／暂停决策。缺少这些，就算 demo 很流畅，也只能证明工具会动，尚未证明工作流能被治理。
结语
30 天的重点是把一次 AI 成功回答，转成团队可重复、可审阅、可停止的流程。从一个有价值但可控的问题开始；先找到失败，再决定是否扩大，通常比追求第一周的「全自动」更接近真正采用。