我给 AI 写了一套“规矩“：数仓开发骨架 Ware-Smith 的设计思考（五）

系列五知识是长出来的——从团队经验到企业资产传统思路的陷阱很多数据治理项目的思路是“先花三个月梳理全量知识再上系统。”结果呢三个月过去文档写了一堆没人用因为太长了不知道从哪看半年后过期因为业务变了没人更新彻底失效又变回靠人脑记忆问题出在哪把积累知识当成了一个独立项目而不是日常工作的副产品。Ware-Smith 的方式做项目就是积累知识知识从零开始在项目中自然生长项目 1制造域·工单产出 → 沉淀良率口径 SAP 双表合并 pattern 3 个词根 项目 2制造域·设备稼动率 → 沉淀稼动率口径 班次时间规则 停机分类维度经验 项目 3制造域·物料报废分析 → 沉淀报废类型状态机 2 个新案例 ── 三个项目后制造域能力包自然覆盖了 80% 的常见场景 ──不需要专门投入知识梳理项目——做项目本身就是积累知识的过程。门槛极低的录入方式如果让数据开发者按格式填 YAML门槛已经太高了。Ware-Smith 提供了 knowledge-curator Skill——你只需提供素材帮我把这段会议纪要里的经验整理到能力包 这个项目上线后踩了个坑记一下 我们组新定了一个指标口径录入进去 把这份源系统对接文档提取成知识AI 自动完成识别知识类型 → 提取结构化内容 → 匹配目标文件 → 生成变更 → 你确认 → 写入。支持任意形式的素材飞书文档、本地文件、截图、对话描述、Word/Markdown。把积累知识的成本降到了做完项目说一句话。从团队到企业每个团队维护自己的 知识互不影响单独看每个目录是一个团队的领域知识。合在一起看这就是整个企业的数仓知识资产不是某个人脑子里的不是 Wiki 上过期的是活的、每天被 AI 使用的、随项目自然增长的知识体系这也解释了为什么骨架要设计成团队各自维护、互不影响降低起步门槛不需要等全公司对齐一个团队做一个项目就能开始避免阻塞不需要中央审批才能加知识自然汇聚各团队独立生长最终自然形成全景知识的生命周期产生 → 录入 → 使用 → 验证 → 修正 → 沉淀 │ │ │ │ │ │ 项目 curator Skill 闸门 人 版本化 实践 自动 自动 自动 确认 提取 加载 检验关键设计产生在真实项目中不是臆想使用每次 Skill 执行都会加载不是躺着的文档验证闸门会检查知识是否被正确应用修正发现问题时更新文件下次自动生效沉淀版本化可审计、可回滚可视化看见你的知识资产当能力包积累到一定程度你可能想看看我们到底沉淀了什么。Ware-Smith 提供自动生成的知识地图HTML指标图谱三层关系力导向图表血缘 DAG对 AI 说生成可视化即可浏览器直接打开。总结我学到的几件事回顾整个设计过程几条可迁移的经验1. AI 的问题不是不够聪明是没有纪律GPT-4 / Claude 的推理能力足够做数仓设计了。它们失败的原因几乎都是不遵守你的规范、不记得你的口径、不知道哪些变更是危险的。解决信息问题告诉它规范比解决能力问题让它更聪明有效 10 倍。2. 给 AI 的约束要和给人的约束一样设计闸门、命名规范、安全评估——这些都是人类团队已有的管理手段。把它们 formalize 成文件AI 就能遵守。不需要发明新东西需要把已有的好实践对 AI 可理解地表达出来。3. 知识是长出来的不是规划出来的不要试图一次性梳理全量知识。做一个项目积累一点三个项目下来就够用了。起步门槛越低积累速度越快。5. LLM 会换代知识文件不会过期今天用 Claude明天可能用 GPT-5后天可能用开源模型。词根词典、指标口径、设计模式——这些知识不依赖任何模型。骨架与 LLM 零耦合模型换代时迁移成本为零。它还不是什么诚实地说当前的局限不是生产级平台它是一个骨架Skeleton需要接入数据平台 API 才有完整体验不是 Auto-Pilot每道闸门都需要人确认AI 不会自己上线不是银弹复杂的业务判断“这个指标该不该建”仍然需要人的决策依赖 AI IDE当前实现基于 Kiro Skill 体系移植到其他 IDE 需要适配写在最后回到系列开头的问题当你把数据开发交给 AI 时如何保证它不乱来我的答案是不是给它一个更好的 Prompt而是给它一套可执行的工程纪律——用知识文件定义什么能做、什么不能做、什么必须问、什么必须查。这就是 Ware-Smith一套让 AI 像老师傅一样做数仓开发的骨架。不是让它更聪明是让它更靠谱。