技能介绍

要解决的具体问题

团队在做数据相关的决策时，常常在没有想清楚"数据到底要驱动什么决策"之前，就已经签下了多年期的基础设施合同、启动了模型训练、或者把客户数据包装成了产品。等到发现方向不对时，迁移成本和沉没成本已经很高了。另一个常见问题是招聘顺序颠倒——先招了数据科学家，却没有先到位数据工程师，结果新员工花了大量时间做基础设施的活儿，生产力大打折扣。

技能如何工作

/cs:cdo-review 在任何涉及数据策略的承诺之前，提出六个压力测试问题，覆盖决策价值、合规来源、架构选型、并购准备、依赖风险和人才匹配六个维度。

核心逻辑是逐项否定式的追问：

数据驱动什么决策——如果答案只是"以后可能用得上"或"感觉像护城河"，那根本不是决策
每个数据源的同意链路是什么——第一方 TOS 的授权强度远不如明确的 opt-in，捆绑式 TOS 通常覆盖不了用 PII 训练基础模型这种新用途
内部有多少个功能域在消费——少于 5 个消费者用仓库就够了，5 到 25 个可能需要湖仓，25 个以上且文化偏向联邦式才考虑网格架构
并购尽职调查时是否准备好了——文档化的匿名化流程、训练数据来源日志是否齐全、客户合同里有多少 MSA 的 carve-out
能否在不依赖某个特定数据源的情况下重新训练或发布——这决定了你对单一数据源的依赖程度
解锁当前决策的岗位是什么——需要把决策需求映射到具体角色，并确认前置角色已经到位

适用边界与注意点

这套问题适用于"承诺之前"的决策节点，不是日常运营工具。如果你已经进入执行阶段，比如基础设施已经部署、模型已经在生产环境跑起来了，这时候再问这些问题，更多是复盘而非决策。另外，它的输出是问题列表而非完整方案——它帮你做判断，但不会替你做判断。对于纯粹技术性的数据管道优化、性能调优等不含业务决策的场景，这套框架并不合适。如果决策涉及产品化或授权路径，可以路由到 /cs:gc-review；如果涉及架构变更，则应该用 /cs:ciso-review。