VS Code 数据科学协作工程化：从 Notebook 到可复现团队工作流

1. 为什么一个数据科学家会把 VS Code 当成“团队作战指挥中心”

我第一次在团队里提交完一份 Jupyter Notebook 后，被组长叫去喝了杯咖啡。他没提代码逻辑，也没问模型效果，而是推过来一台新配的笔记本电脑，说：“你先装个 VS Code，把 notebook 拆成.py文件，再配好 gitignore。”我当时心里直犯嘀咕：不就是跑个 pandas 和 sklearn 吗？写 notebook 不香吗？画图点几下就出来，调试按个Shift+Enter就行，哪来这么多规矩？

但三个月后，我彻底改口了——不是因为 VS Code 多炫酷，而是因为它让“协作”这件事从玄学变成了可执行、可追踪、可复现的工程动作。这不是工具升级，是工作范式的切换：从“我写完能跑通就行”，变成“别人拉下来三分钟就能复现、五分钟后就能改、十分钟就能合进主干”。

你可能也经历过这些场景：

• 你发给同事的 notebook 里有一段plt.show()，结果对方环境里没装 matplotlib，报错卡死；
• 你本地用pandas==2.0.3跑得好好的，CI 流水线却用pandas==1.5.3直接崩在pd.concat(..., ignore_index=True)上；
• 你改了模型超参，在 notebook 里随手加了个# best so far注释，结果两周后自己都忘了这句注释对应哪次实验；
• 团队四个人同时改同一个 notebook，git diff 出来全是{"cells": [...]}的 JSON 差异，根本看不出谁动了哪行代码。

这些问题，Jupyter Notebook 本身不解决，它设计初衷就不是为多人协同而生的。它像一本手写实验记录本——适合你自己边想边记，但不适合四个人轮流在同一页上批注、修订、签名、归档。

VS Code 不是替代 notebook，而是给 notebook 装上工程底盘：它让你继续用.ipynb写探索性分析，但背后自动帮你管理 Python 环境、版本依赖、代码结构、Git 提交粒度、实验元数据，甚至让队友能实时看到你正在改哪一行、为什么改、改之前是什么状态。

所以这篇文章不讲“VS Code 多好用”，而是聚焦一个更实际的问题：一个真实运转的数据科学/ML 团队，每天高频使用的那十几个 VS Code 扩展，它们各自解决什么具体协作痛点？为什么非得是这个扩展，而不是另一个？配置时哪些参数必须调，哪些可以跳过？踩过哪些坑，才总结出这套组合拳？

关键词里提到的 “Towards AI - Medium”，其实恰恰说明这类内容的价值所在——它不是官方文档的复述，而是从真实项目泥潭里捞出来的经验结晶。下面我就按我们团队日常协作的真实动线，一条条拆解这些扩展怎么用、为什么这么用、不这么用会掉进什么坑。

2. 核心协作能力拆解：从“能跑”到“可协同”的四层跃迁

我们团队把协作能力分成四个递进层级，每个层级对应一类核心扩展。不是所有扩展都同等重要，有些是“基础生存包”，有些是“效率加速器”，有些则是“规模化护城河”。理解这个分层，才能避免一上来就堆满插件，反而拖慢开发节奏。

2.1 第一层：环境与代码的“可信基线”——让所有人从同一块石头出发

没有这一层，后面全是空中楼阁。所谓“可信基线”，指的是：无论你在 macOS、Windows 还是 Linux，无论你用 conda、venv 还是 pipenv，只要打开这个项目，VS Code 就该自动识别并激活正确的 Python 解释器，加载正确的依赖，显示正确的 lint 错误，运行正确的测试。这不是理想，是我们每天早会前必须确认的底线。

• Python 扩展（含 Pylance）是这一层的绝对核心。它不只是语法高亮，而是整个 Python 生态在 VS Code 里的“操作系统内核”。Pylance 提供的类型推断，让df.groupby('category').agg({'sales': 'sum'})这种链式调用也能精准提示sales列的 dtype，而不是泛泛地告诉你agg返回DataFrame。这点对新人尤其关键——他们不用翻 pandas 文档猜返回值，IDE 就直接标出来了。

• 为什么必须关掉 Pylance 的python.analysis.typeCheckingMode默认值？
  默认是"basic"，它只检查明显错误（比如调用不存在的方法）。但我们团队统一设为"basic"+ 手动开启"python.analysis.extraPaths"指向src/目录，并在pyrightconfig.json里加：

  { "typeCheckingMode": "strict", "reportUnusedVariable": true, "reportGeneralTypeIssues": true }

  这样做的代价是首次索引变慢 2~3 秒，但换来的是：当有人把def train_model(data: pd.DataFrame)误写成def train_model(data: list)时，保存即报错，而不是等训练跑完才发现data.head()报 AttributeError。我们算过账：一次线上模型训练失败排查平均耗时 47 分钟，而这种类型错误占其中 31%。严格模式多花的 2 秒，一年省下 200+ 小时。

• Python Indent 扩展看似鸡肋，实则暗藏玄机。Python 靠缩进来定义作用域，但 notebook 里常混用空格和 tab，导致if块看起来对齐，实际缩进层级错乱。这个扩展强制统一为 4 空格，并在状态栏实时显示当前缩进宽度。我们曾发现一个“神隐 bug”：某次 AUC 突然下降 0.03，最后定位到是 notebook 里一段for循环末尾多了一个 tab，导致model.fit()被错误地缩进进循环体，每轮都重训模型。Indent 扩展开启后，这种问题在编辑时就标红，根本进不了 Git。

提示：不要依赖 VS Code 自带的“格式化”功能处理 notebook 缩进。.ipynb是 JSON 格式，格式化会破坏 cell metadata。Python Indent 只作用于.py文件和 notebook 的 code cell 内容，这才是安全的。

2.2 第二层：实验与数据的“可追溯凭证”——让每一次结果都有据可查

数据科学家最怕的不是模型不准，而是“上次那个 0.89 的 AUC 是在哪次 commit、哪个参数、哪份数据上跑出来的？” 在 notebook 时代，答案往往是“我好像记得是上周五下午……”；在 VS Code 协作体系里，答案必须是“git show abc1234 -- src/train.py | grep 'lr=0.001'”。

• DVC（Data Version Control）扩展是这一层的基石。它不是 Git 的替代品，而是 Git 的“数据增强包”。Git 管代码，DVC 管数据、模型、指标、图表。我们团队规定：所有超过 10MB 的文件（原始数据集、预训练模型、大尺寸特征矩阵）必须用dvc add加入追踪，而不是直接git add。原因很简单：Git 仓库体积爆炸，clone 一次要 40 分钟；而 DVC 只存元数据，实际文件存在远程 S3 或 MinIO，dvc pull按需下载。

• DVC Dashboard 的真实用法，不是看图，而是“反向溯源”。
  比如你在 Dashboard 上看到experiment-20240715-1422的 AUC 是 0.892，点击进去，它自动展示：

  • 对应的 Git commit hash（f8a2c1e）
  • 使用的 data version（dataset-v3.2.1）
  • 训练脚本路径（src/train.py）
  • 关键参数（--lr 0.001 --batch-size 64）
  • 生成的模型文件（models/best_v3.2.1.pth）
    这时你右键models/best_v3.2.1.pth→ “Reproduce this stage”，VS Code 就自动 checkout 到f8a2c1e，dvc pull下dataset-v3.2.1，然后运行python src/train.py --lr 0.001 --batch-size 64。整个过程无需人工拼凑命令，杜绝了“我记得参数是 0.001，但 config.yaml 里写的是 0.01”的乌龙。

• Kedro 扩展解决的是另一类追溯问题：pipeline 结构变更的可审计性。
  Kedro 强制把数据处理流程拆成nodes（原子函数）和pipelines（有向无环图）。Kedro 扩展在 VS Code 里提供：

  • 右键任意 node → “Show dependencies”：立刻画出这个函数依赖哪些输入数据、产出哪些输出；
  • 修改conf/base/catalog.yml后，自动高亮所有引用该数据集的 nodes；
  • kedro run --pipeline=feature_eng时，终端实时显示 pipeline 执行顺序和每个 node 的耗时。
    我们曾用这个功能揪出一个性能瓶颈：某个clean_textnode 耗时 12 秒，但它的输入数据集raw_tweets.csv实际只有 500 行。追查发现是catalog.yml里误配了layer: raw，导致 Kedro 每次都从 S3 重新下载全量数据，而非读取本地缓存。Kedro 扩展的依赖图一眼就暴露了这个跨层耦合。

2.3 第三层：代码与知识的“即时共享通道”——让协作发生在敲代码的当下

传统协作是“我写完 → push → 你 pull → 你 review → 你 comment → 我改”，中间隔着至少 15 分钟。而现代数据团队需要的是“你正在改src/featurize.py第 87 行，我看到你删了fillna(0)，我想知道为什么”，这种近乎零延迟的知识同步。

• GitLens是这一层的神经中枢。它远不止于“看谁写了这行”。我们深度定制了它的三个关键能力：

  1. Blame Annotations on Hover：鼠标悬停代码行，左侧 gutter 立即显示作者、commit 时间、commit message 摘要。如果 message 是 “fix typo in docstring”，你知道这行无关紧要；如果是 “refactor feature scaling to handle NaN properly”，你就该点开 commit 看 diff。
  2. Code Authorship Heatmap：在侧边栏打开 GitLens → “Authors”，它用颜色深浅显示每个文件的修改密度。我们发现src/models/目录里lstm.py的红色最深，但transformer.py却是灰色——原来后者是实习生写的初版，没人敢动。这直接触发了一次技术债清理会。
  3. Compare with Previous Version：右键任意文件 → “GitLens: Compare with Previous Version”，它自动对比上一次 commit，且高亮显示语义差异（比如df.dropna()→df.fillna(method='ffill')），而不是逐行比对 JSON。

• Live Share的正确打开方式，不是“一起写代码”，而是“一起 debug”。
  我们约定：当某人卡在某个 bug 超过 20 分钟，必须发起 Live Share。发起者共享自己的终端、调试器、甚至浏览器（用于看 TensorBoard）。关键在于：发起者永远是 host，控制权在他手里；加入者是 guest，只能观察、发言、请求控制权。这避免了“两人同时敲键盘”的混乱。最有效的一次是排查 PyTorch 分布式训练 hang 住的问题：host 启动torch.distributed.launch，guest 实时看到nvidia-smi显示 GPU 显存占用正常但ps aux | grep python显示进程卡在ncclCommInitRank。我们立刻意识到是 NCCL 环境变量未同步，host 在.bashrc里补上export NCCL_SOCKET_TIMEOUT=600，guest 立刻验证生效。整个过程 8 分钟，比各自折腾快 5 倍。

2.4 第四层：洞察与决策的“低门槛入口”——让非工程师也能参与数据对话

一个健康的数据团队，不能只有工程师懂代码。产品经理需要快速验证“如果把用户停留时长阈值从 30s 改成 60s，转化率会怎么变？”；业务方想知道“上个月流失用户的地域分布和本月有什么不同？”。他们不需要写 Python，但需要能自助探索。

• Data Wrangler是这一层的破壁者。它把 Pandas 操作翻译成可视化界面：上传 CSV → 点击“Remove Duplicates” → 它自动生成df.drop_duplicates()代码并执行；拖拽“Age”列到“Histogram”面板 → 自动生成df['Age'].hist(bins=20)并渲染图表。关键在于：所有操作都实时生成、可编辑、可导出为.py脚本。我们团队的新成员入职第一周任务，就是用 Data Wrangler 清洗一份模拟销售数据，然后把生成的脚本提交 PR。这比直接教pandas.read_csv()有效得多。

• SandDance解决的是“高维数据直觉缺失”问题。传统散点图最多展示 3 维（x, y, color），而 SandDance 允许你把 10+ 个字段拖进画布，用“旋转”、“缩放”、“聚类”、“时间轴”等交互方式，瞬间感知数据结构。比如我们分析用户行为日志时，把country,device_type,session_duration,page_views,is_paying全部拖进去，开启“聚类”后，发现一个异常簇：country=US,device_type=mobile,session_duration<10s,page_views=1,is_paying=False—— 这明显是爬虫流量。我们立刻把这个 pattern 写进清洗规则。这种洞察，靠写 SQL 或 Pandas groupby 要反复试错半小时，SandDance 30 秒搞定。

注意：SandDance 对数据量敏感。我们测试过，超过 50 万行时交互会卡顿。解决方案是：先用df.sample(n=10000)采样，探索出关键维度后，再用完整数据跑精确统计。这是工具理性——不是追求“全量”，而是追求“有效”。

3. 实操配置详解：从零搭建团队级 VS Code 数据工作站

光知道扩展名字没用，关键是怎么配、配什么、为什么这么配。下面是我团队标准化的settings.json核心片段，每一条都经过至少 3 个项目验证。你可以直接复制粘贴，但建议先理解背后的协作逻辑。

3.1 全局基础配置：让每个人打开项目就“感觉一样”

{ "editor.tabSize": 4, "editor.insertSpaces": true, "editor.formatOnSave": true, "editor.formatOnType": true, "files.trimTrailingWhitespace": true, "files.insertFinalNewline": true, "files.trimFinalNewlines": true, "python.defaultInterpreterPath": "./.venv/bin/python", "python.testing.pytestArgs": [ "tests/" ], "python.testing.pytestEnabled": true, "python.linting.enabled": true, "python.linting.pylintEnabled": false, "python.linting.flake8Enabled": true, "python.formatting.provider": "black", "python.formatting.blackArgs": [ "--line-length=88" ], "workbench.editor.enablePreview": false, "explorer.compactFolders": false, "git.autofetch": true, "git.suggestSmartCommit": false }

• "python.defaultInterpreterPath": "./.venv/bin/python"：这是协作信任的起点。我们强制要求所有项目根目录下必须有.venv/，且requirements.txt里明确指定python>=3.9,<3.11。VS Code 读到这个路径，就自动激活虚拟环境，不再弹窗问“选哪个解释器”。如果路径不存在，它会清晰报错：“No Python interpreter found at ./venv/bin/python”，而不是静默 fallback 到系统 Python 导致依赖混乱。

• 为什么禁用 Pylint，启用 Flake8？
  Pylint 规则过于学术化（比如强制要求模块 docstring 必须包含:param:），而 Flake8 更贴近工程实践（重点检查E501行太长、F401未使用导入、E722模糊的 except）。我们团队的setup.cfg里还加了：

  [flake8] max-line-length = 88 ignore = E203, W503 select = B,C,E,F,W,T4,B9

  这些是经过血泪教训定下的：E203（冒号前空格）和W503（行尾反斜杠换行）在 Black 格式化后必然触发，必须忽略；B9是 Bandit 安全检查，防止eval()、exec()等危险函数被误用。

• "workbench.editor.enablePreview": false：这是提升协作效率的隐藏技巧。默认开启 preview，意味着你双击一个文件，它在 tab 里是临时预览态（斜体），只有真正编辑或右键“Keep Open”才固定。这导致一个问题：当你想对比train.py和evaluate.py时，预览态的train.py会在你打开evaluate.py后自动关闭。关掉 preview 后，每次双击都是固定 tab，团队成员共享屏幕时，能清晰看到“他打开了哪几个文件”，而不是“他刚刚点过哪个文件”。

3.2 Notebook 专项配置：让.ipynb既保持交互性，又不失工程性

{ "jupyter.askForKernelRestart": false, "jupyter.defaultCellLanguage": "python", "jupyter.experiments.optInto": ["pythonInteractiveWindow"], "jupyter.notebook.cellToolbarLocation": { "viewType": "notebookEditor", "section": "status" }, "jupyter.textOutputLimit": 10000, "jupyter.askForKernelRestart": false, "jupyter.runStartupCommands": [ "%matplotlib inline", "import numpy as np", "import pandas as pd", "import matplotlib.pyplot as plt", "import seaborn as sns" ] }

• "jupyter.runStartupCommands"：这是消除“环境认知差”的关键。每个新 notebook 打开时，自动执行这几行，确保np,pd,plt等常用别名已导入，%matplotlib inline已启用。这样，当新人看到老同事的 notebook 里直接写sns.histplot(df['age'])，他不会困惑“为什么没 import seaborn？”，因为环境已经帮他预置好了。这比写 10 行 README 更有效。

• "jupyter.textOutputLimit": 10000：防止 notebook 被大输出撑爆。我们曾遇到一个 notebook，某次df.describe()输出了 5000 行，导致 VS Code 卡死 3 分钟。设上限后，超出部分显示为[... output truncated ...]，点击可展开。更重要的是，这个设置会同步到 Git：当output字段被截断，diff 里就不会出现海量数字，而是干净的"[... output truncated ...]"，review 时一目了然。

• "jupyter.notebook.cellToolbarLocation"：把 cell toolbar（运行、中断、清除输出按钮）移到状态栏右侧。为什么？因为团队共用一套快捷键，而状态栏位置固定，不会因窗口大小变化而消失。当远程 pair programming 时，对方说“点右边那个三角形”，你永远知道是哪个按钮；如果说“点 cell 工具栏”，你得先找 toolbar 在哪——这在小屏幕笔记本上尤其痛苦。

3.3 DVC 与 Kedro 深度集成：让数据和 pipeline 成为一等公民

{ "dvc.showMetricsInStatusBar": true, "dvc.showExperimentsInStatusBar": true, "dvc.showRemoteInStatusBar": true, "kedro.showPipelineGraph": true, "kedro.pipelineGraphLayout": "hierarchical", "kedro.showCatalogInExplorer": true, "kedro.catalogExplorerLayout": "tree" }

• 状态栏三件套（Metrics/Experiments/Remote）：这是 DVC 的“协作仪表盘”。当你的状态栏显示DVC: metrics: auc=0.892 | exp: feat-eng-v2 | remote: s3://my-bucket，你无需打开终端，就知道：

  • 当前工作区的最新指标值（auc=0.892）；
  • 最近一次实验名称（feat-eng-v2），方便快速dvc exp apply；
  • 远程存储位置（s3://my-bucket），确保dvc push不会误传到错误 bucket。
    这个信息对 PM 和 QA 极其友好——他们不需要懂 DVC 命令，看一眼状态栏就知道“今天最好的模型 AUC 是多少”。

• Kedro Pipeline Graph 的布局选择："hierarchical"比默认的"force"更适合团队协作。force布局会把所有 nodes 随机散开，而hierarchical严格按 pipeline 执行顺序从左到右排列（Input → Process → Output）。当我们评审一个新 feature pipeline 时，直接按Ctrl+Shift+P→ “Kedro: Show Pipeline Graph”，整个数据流一目了然：左边是raw_users.csv，中间是clean_users、enrich_features两个 nodes，右边是processed_users.parquet。如果发现enrich_features指向了raw_orders.csv（应该指向processed_orders.parquet），图上立刻暴露依赖错误。

• Catalog Explorer 的 tree 视图："tree"比"list"更能体现数据治理逻辑。它按conf/base/catalog.yml里的layer字段分组（raw,intermediate,features,models），每个 layer 下列出对应数据集。当新人问“用户画像特征在哪？”时，你直接说“看 Catalog Explorer 里的features层”，他点开就看到user_profile_v2、behavior_score等数据集，而不是在几十个 YAML 条目里大海捞针。

4. 团队协作避坑指南：那些没人告诉你的“经验之痛”

这些不是文档里的标准答案，而是我们团队在 12 个数据项目、37 次迭代中，用真金白银买来的教训。有些坑踩一次就够了，有些坑得踩三次才记住。

4.1 Git 与 Notebook 的“甜蜜陷阱”：为什么git add *.ipynb是毒药

新手最容易犯的错误，就是把 notebook 当普通文件git add。表面看没问题，但埋下三个雷：

• 雷一：JSON Diff 不可读
  git diff notebook.ipynb输出的是：

  - "outputs": [ - { - "output_type": "display_data", - "data": { - "text/plain": [ - "<Figure size 640x480 with 1 Axes>" - ],

  而不是AUC increased from 0.85 to 0.89。Code Review 时，Reviewers 只能盲信“他改了 notebook，应该没问题”，无法验证逻辑。

• 雷二：输出污染仓库
  notebook 里plt.show()生成的图表、print(df.head())的表格，都会作为 base64 编码存进 JSON。一个 10MB 的图表，会让仓库永久膨胀 10MB。我们曾有个项目，因为频繁 commit notebook 输出，三年后仓库体积达 2.3GB，clone 一次要 1 小时。

• 雷三：合并冲突地狱
  两人同时修改同一个 notebook，Git 无法理解 cell 结构。冲突标记可能是：

  <<<<<<< HEAD "cell_type": "code", "execution_count": null, "metadata": {}, ======= "cell_type": "markdown", "metadata": {}, >>>>>>> feature/add-customer-segment

  你根本不知道这是改了 cell 类型，还是改了 cell 内容。

我们的解法：.gitattributes+nbstripout
在项目根目录创建.gitattributes：

*.ipynb filter=nbstripout

然后全局安装nbstripout：

pip install nbstripout git config filter.nbstripout.clean 'nbstripout clean' git config filter.nbstripout.smudge 'nbstripout smudge' git config filter.nbstripout.required true

效果：git add notebook.ipynb时，自动剥离所有outputs,execution_count,metadata（除了kernelspec和language_info），只保留纯代码和 markdown。git status显示的是：

modified: notebook.ipynb (content changed)

而 diff 是：

- # Old analysis - df.groupby('region')['revenue'].sum() + # Updated with new region mapping + df.groupby('region_mapped')['revenue'].sum()

这才是工程师该有的 diff。

提示：nbstripout不影响本地运行。你依然能看到图表、能Shift+Enter，只是 Git 不存它们。这是完美的“本地体验 vs 协作纯净”平衡。

4.2 DVC 的“大文件幻觉”：为什么dvc add bigfile.zip后git status还是untracked

新手常困惑：“我dvc add了，为什么 Git 还说没跟踪？” 这是因为 DVC 的设计哲学：DVC 管理的是“指针”，不是文件本身。

当你dvc add bigfile.zip：

1. DVC 把bigfile.zip计算 SHA256，存到.dvc/cache/；
2. 在项目里生成bigfile.zip.dvc文件（纯文本，内容是deps: [{path: bigfile.zip}]和outs: [{path: bigfile.zip, md5: xxx}]）；
3. bigfile.zip本身被git rm --cached，不再由 Git 跟踪；
4. bigfile.zip.dvc被git add，由 Git 跟踪。

所以git status显示bigfile.zip.dvc是 new file，bigfile.zip是 deleted。这是完全正确的！bigfile.zip的内容在.dvc/cache/里，bigfile.zip.dvc是它的“身份证”。

常见误操作及修复：

• 误操作1：git add bigfile.zip（绕过 DVC）→ 立即git rm --cached bigfile.zip && dvc add bigfile.zip && git add bigfile.zip.dvc；
• 误操作2：dvc add bigfile.zip后忘记git add bigfile.zip.dvc→git add bigfile.zip.dvc，否则队友git pull后dvc pull会找不到指针；
• 误操作3：dvc push失败（网络问题）→dvc push会重试，但若中途 Ctrl+C，cache 里文件可能不完整。此时dvc status -c会显示not in cache，执行dvc gc -c清理坏 cache，再dvc push。

4.3 Live Share 的“权限迷雾”：为什么你共享了，队友却看不到终端

Live Share 默认只共享“编辑器”，不共享终端、调试器、浏览器。这是安全设计，但新手常以为“共享了整个 VS Code”。

必须手动开启的三项：

1. 共享终端：Host 点击终端窗口右上角⋯→ “Share Terminal”；
2. 共享调试器：Host 在调试视图（Ctrl+Shift+D）右上角⋯→ “Share Debug Session”；
3. 共享浏览器：Host 打开浏览器（如 TensorBoard 页面），右键标签页 → “Share This Tab”。

更关键的是权限控制：Guest 默认只有“View”权限。Host 必须主动授予“Edit”或“Debug”权限。方法是 Host 点击右下角 Live Share 状态栏 → “Manage Permissions” → 勾选 Guest 的权限。我们团队规定：Debug 权限只在排查生产级 bug 时授予，且 Host 必须全程监控 Guest 的调试操作（如 step into、set breakpoint），防止误操作。

4.4 Data Wrangler 的“采样幻觉”：为什么生成的代码在全量数据上跑不通

Data Wrangler 默认对大数据集自动采样（df.sample(n=10000)），以保证 UI 流畅。但它生成的代码是：

# This code was generated by Data Wrangler df = df.sample(n=10000, random_state=42) # ← 这行是陷阱！ df = df.drop_duplicates(subset=['user_id'])

如果你直接复制这段代码到生产脚本，drop_duplicates只在 10000 行上运行，漏掉全量数据的重复项。

安全做法：

• 在 Data Wrangler 界面右上角，点击齿轮图标 → “Settings” → 关闭 “Auto-sample large datasets”；
• 或者，复制代码后，手动删除df.sample(...)这一行，只保留真正的清洗逻辑；
• 最佳实践：把 Data Wrangler 当作“探索沙盒”，最终清洗脚本必须用pandas-profiling或great-expectations做全量数据验证。

5. 常见问题速查表：团队内部高频问答实录

我们把过去一年 Slack 频道里最常被问的 15 个问题，整理成这张表。每个问题都附带“一句话答案”、“深层原因”和“团队标准操作”。