一次完整的 CODE 实战全记录
一只阿木木约 7 分钟一次完整的 CODE 实战全记录
前面七篇文章，我把 CODE 四步拆开讲了一遍：Capture 怎么收、Organize 怎么放、Distill 怎么提炼、Express 怎么输出。
但我知道你心里可能有一个疑问：
"每一步单独看我都懂了，但真正工作中一个完整的任务过来，这四步是怎么串起来的？"
这就像学编程——你学了变量、学了循环、学了函数、学了类，但当一个真实需求丢过来的时候，你还是不知道从哪行代码写起。
理论需要一个完整的项目来"焊死"。
所以今天这篇，我不讲任何新概念。我要做的事情只有一件：
把上个月我在工作中做的一次"数据中台技术选型调研"，从接到任务到交付报告的完整过程，按照 CODE 的四步全流程，一帧一帧地回放给你看。
每一步我做了什么、在 Obsidian 里操作了什么、花了多少时间、踩了什么坑——全部真实记录，不做美化。
你可以把这篇文章当成一个"参考实现"（Reference Implementation）——看完之后，下次你接到类似的调研/选型/分析任务时，可以直接套用这个流程。
零、任务背景
先交代一下这个任务的来龙去脉。
任务描述：
老板在周一早会上说："我们现在的数据分析全靠导出 Excel 手动处理，效率太低了。你调研一下数据中台的技术方案，下周五之前出一份选型建议报告，给 CTO 评审。"
我的第一反应：
慌了一下。因为"数据中台"这个话题太大了——架构模式、OLAP 引擎、ETL 工具、数据治理、BI 平台……每一个方向都能写一本书。
如果是两个月前的我，我会：
打开浏览器，搜索"数据中台技术选型" 读 20 篇文章，越读越焦虑 打开 Word，对着空白页面发呆 拖到周四晚上开始赶工 交一份自己都觉得心虚的报告
但现在我有了第二大脑。
我深吸一口气，打开 Obsidian，开始了以下操作。
第一步：建立项目（5 分钟）
在动手做任何调研之前，我先做了一件事：在 Projects 里建一个项目文件夹。
1-Projects/
└── P-数据中台选型调研/
├── 00-项目主页.md ← 用项目模板创建
├── 01-已有认知盘点.md ← 接下来要用
└── （后续笔记陆续添加）
项目主页（用之前建好的模板一键生成）：
# P-数据中台选型调研## 项目信息
- **目标**：输出一份数据中台技术选型建议报告，供 CTO 评审
- **截止日期**：2024-05-24（周五）
- **状态**：🟢进行中
- **关联领域**：[[A-后端技术]] [[A-数据与增长]]
## 核心产出物
- [ ] 技术选型建议报告（主文档）
- [ ] 方案对比表（附件）
- [ ] 评审 PPT（如果需要）
## 下一步行动
- [ ] 盘点我已有的相关知识
- [ ] 确定调研范围和评估维度
- [ ] 收集资料
- [ ] 整理和提炼
- [ ] 写报告
## 参考资料
（待补充）
## 踩坑与经验
（待补充）
为什么第一件事不是去搜索资料，而是建项目？
因为如果你不先定义清楚"交付什么"和"什么时候交付"，你的调研就会变成无边界的信息收集——越收越焦虑，越焦虑越想多收。
程序员类比：先建仓库（git init），再写代码。不要在本地散落的文件里写到一半才想起来要建项目。
第二步：盘点"我已经知道什么"（20 分钟）
这一步是整个流程中最容易被忽略、但最有价值的一步。
大多数人接到调研任务后的第一反应是"去搜索"。但其实你不是一张白纸——你过去的工作经验、读过的文章、听过的分享、踩过的坑，都已经让你对这个话题有了一定程度的了解。
先盘点自己已有的认知，能帮你：
明确"我已经知道什么"→ 避免重复搜索 明确"我还不知道什么"→ 让后续搜索更聚焦 调用知识库中已有的笔记 → 不从零开始
我的操作：
打开 Obsidian，做了三组搜索：
搜索1："数据中台" → 命中 3 条笔记
搜索2："OLAP" → 命中 2 条笔记
搜索3："数据" → 命中 7 条（去重后有效 5 条）
搜索4：翻 A-后端技术/ 和 A-数据与增长/ 下的所有笔记 → 又找到 2 条相关的
搜索结果汇总：
7 条已有笔记。其中 2 条是高度可用的（L2 以上），3 条需要补充提炼，2 条是碎片。
然后我写了一份"已有认知盘点"：
# 01-已有认知盘点## 我已经知道的
- 数据中台的基本概念和目标（打破数据孤岛、统一数据口径）
- OLAP 引擎两个主要候选：ClickHouse 和 Doris，已有初步对比
- Lambda 和 Kappa 两种架构模式的优劣
- 公司现有痛点：Excel手动分析、口径不统一、取数效率低
- 一条方法论：不要一步到位，先试点再推广
## 我还不知道的（需要调研）
- 业界同等规模公司的落地案例（我们是什么规模？什么预算？）
- ETL/数据集成工具的选型（只有碎片，没有系统对比）
- 数据治理和元数据管理方案
- 实施路径：第一步做什么？需要多少人？多长时间？
- CTO 最关注的评估维度是什么？（需要提前沟通）
## 调研范围（收窄！）
基于以上盘点，我决定把调研范围收窄为 4 个核心问题：
1. OLAP 引擎选型（ClickHouse vs Doris vs StarRocks）
2. ETL/数据集成方案选型
3. 实施路径建议（分几期、每期做什么）
4. 风险和成本评估
不做的事情：
- 不深入 BI 平台选型（这个后续单独调研）
- 不研究数据治理细节（第一期用不到）
这份盘点只花了 20 分钟，但它帮我做了三件关键的事：
心理减压——原来我不是完全不懂，我已经有 7 条笔记了 范围收窄——从"调研数据中台"缩小到"回答 4 个具体问题" 缺口定位——我知道了"还需要补什么"，后续搜索会非常聚焦
程序员类比：这就是做技术方案前的"现状分析"和"需求澄清"。不要上来就写代码，先搞清楚现在有什么、需要什么、边界在哪。
第三步：Capture —— 定向收集（Day 1-2，累计约 3 小时）
有了"我还不知道什么"的清单，我的 Capture 就变成了定向搜索，而不是漫无目的地刷文章。
我的搜索策略：
针对每个"不知道的"问题，定向搜索：问题1（OLAP引擎选型）：
→ 搜索 "ClickHouse vs Doris vs StarRocks 2024 对比"
→ 搜索 "OLAP 选型 中小公司 实践"
→ 找到 4 篇高质量文章
问题2（ETL工具选型）：
→ 搜索 "ETL工具 DataX Flink CDC 对比"
→ 搜索 "实时数据集成 方案选型"
→ 找到 3 篇文章 + 1 个技术论坛讨论帖
问题3（实施路径）：
→ 搜索 "数据中台 从0到1 实施路径"
→ 搜索 "中小公司 数据基建 第一步"
→ 找到 2 篇案例 + 1 份某公司的公开分享 PPT
问题4（风险和成本）：
→ 基于前三个问题的调研结果推导，不需要单独搜索
→ 另外找了一下同规模公司的团队配置参考
两天内我新增了 12 条 Capture 笔记。
但请注意——不是看到什么就存。每条都通过了第五篇文章讲的"12 秒共鸣测试"。
我的 Capture 标准在这个项目里更加具体：
Capture 过滤规则（项目定制版）：这条信息能帮我回答那 4 个问题之一吗？
├── YES → 存，放到 P-数据中台选型调研/
└── NO → 不存，不管它写得多好
这条信息是"一手经验"还是"二手概述"？
├── 一手经验（某公司实际踩坑/实际数据）→ 优先存
└── 二手概述（泛泛而谈的科普文）→ 大概率不存
这条信息有具体的数据/指标/对比吗？
├── 有 → 存
└── 没有（纯定性描述）→ 只存结论，不存全文
实际的 Capture 过程（以一篇 OLAP 选型文章为例）：
我读到一篇质量很高的文章：《ClickHouse、Doris、StarRocks 三大 OLAP 引擎深度对比》。
以前的我： 点收藏。存链接。结束。
现在的我： 读完后在 Obsidian 里写了这样一条笔记：
# OLAP三引擎对比-来自XX文章> 来源：https://xxxxx.com/olap-comparison
> 日期：2024-05-14
> 关联：[[P-数据中台选型调研]]
💡 我为什么存：回答"OLAP引擎选哪个"这个核心问题
📌 直接用在：选型报告的"引擎对比"章节
## 核心对比数据（从原文提取）
| 维度 | ClickHouse | Doris | StarRocks |
|------|-----------|-------|-----------|
| 查询性能(单表) | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 查询性能(多表JOIN) | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 实时写入 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 运维复杂度 | 高 | 低 | 中 |
| 社区活跃度 | 高 | 高 | 中 |
| 学习曲线 | 陡 | 缓 | 中 |
| MySQL兼容性 | 不兼容 | 高度兼容 | 高度兼容 |
## 我的判断
- 如果我们团队没有专职 DBA → 选 Doris（运维简单、MySQL兼容）
- 如果追求极致单表查询性能 → 选 ClickHouse
- StarRocks 综合最强但社区相对小，有供应商锁定风险
## 这篇文章的可信度评估
- 作者是某公司数据架构师，有实操经验 → 可信度中高
- 文章有 benchmark 数据但没公开测试环境 → 数据仅供参考
- 发布时间 2024年3月 → 时效性OK
注意最后的"可信度评估"——这是我在做技术调研时加的一个习惯。不是所有文章都值得信任，写下来能帮我在写报告时判断"引用哪篇的数据更靠谱"。
整个 Capture 过程的节奏控制：
总计 3 小时，新增 12 条笔记。加上之前已有的 7 条，总共有 19 条相关笔记。
第四步：Organize —— 按报告结构归类（30 分钟）
Capture 完成后，我有 19 条笔记散落在 Inbox 和项目文件夹里。下一步是把它们按照最终报告的结构来组织。
这一步的关键认知：Organize 不是按"信息类型"分类，而是按"报告的章节"分类。
因为我的目标不是"建一个数据中台知识库"，而是"写一份选型报告"。所以组织方式要面向交付物。
我的操作：