行业资讯
VS Code 数据科学协作：让 Jupyter Notebook 可审查、可复现、可交付
1. 项目概述当数据科学从“单机笔记本”走向“团队协同时代”你有没有经历过这样的场景凌晨两点你刚跑完一个关键模型把 Jupyter Notebook 文件发给同事对方回复“我这边 kernel 启动报错环境不一致”又或者团队里三个人各自维护一份几乎相同的requirements.txt但版本号对不上CI 流水线隔三差五就挂再比如代码审查时发现某段特征工程逻辑写在 notebook 的 markdown 单元格里——不是注释是真正的业务逻辑只是被藏在了文字后面。这些不是个别现象而是绝大多数数据科学团队在从“单人探索”迈向“多人协作”阶段时必然撞上的真实墙。这篇内容讲的就是如何用 VS Code 这个看似“写 Python 的编辑器”真正扛起数据科学与机器学习团队的协同开发重担。核心关键词是VS Code 扩展、数据科学团队、Jupyter 协作、ML 工程化落地、环境一致性、代码可审查性。它不是教你怎么装插件而是告诉你为什么必须放弃“本地 notebook 邮件传文件”的原始协作模式哪些扩展组合能让你的.ipynb文件像.py一样被 Git 精确 diff、被 CI 自动 lint、被 PR 模板强制校验以及最关键的——如何让一个刚入职的算法工程师在打开 VS Code 的第一分钟就能复现三个月前老员工跑出的 AUC 分数而不是花两天时间在环境配置上打转。适合所有正在经历或即将面临“模型上线难、协作效率低、知识沉淀弱”困境的数据科学家、ML 工程师、技术负责人也适合那些想把 notebook 从“实验草稿本”升级为“可交付生产资产”的团队。2. 整体设计思路为什么 VS Code 是当前最务实的团队协同底座2.1 拒绝“理想化工具链”拥抱工程师已有的工作流很多团队一上来就想建一套“完美平台”自研 notebook 服务、定制化 IDE、私有化 JupyterHub 集群……结果半年过去只搭出了一个没人愿意用的“技术展示品”。我的经验是团队协作的成败80% 取决于“迁移成本”而非“技术先进性”。VS Code 的核心优势恰恰在于它不是一个需要重新教育工程师的“新系统”而是一个他们已经在用的“熟悉界面”。据统计超过 73% 的 Python 开发者日常使用 VS CodeStack Overflow 2023 开发者调查这意味着你的数据科学家、后端工程师、甚至 DevOps 同事很可能已经装好了它只是没开启 notebook 功能。我们做的不是“换工具”而是“激活已有工具的隐藏能力”。这背后是一套务实的设计哲学不挑战用户习惯只增强其能力不追求功能大而全只解决协作中最痛的三个点——环境可复现、代码可审查、执行可追溯。所以整个方案没有引入任何新服务、新部署、新账号体系所有能力都通过 VS Code 扩展和本地配置文件.vscode/settings.json,pyproject.toml完成。当你在团队内部推广时你不需要说服大家“换个平台”只需要说“我们来统一一下 VS Code 里的几个设置以后你发 PR 时CI 就能自动检查你的 notebook 有没有硬编码路径还能一键生成干净的.py脚本。”2.2 “Notebook 协作”的本质是“Python 工程化协作”的子集这是很多人理解上的最大误区。他们把 notebook 当成一种独立的“数据科学语言”于是试图用“notebook 特有的协作方式”去解决所有问题。但现实是一个成熟的 ML 项目90% 的代码最终要变成.py模块、CLI 工具或 API 服务。notebook 只是其中的“探索层”和“报告层”。因此我们的设计起点是让 notebook 的生命周期完全融入标准的 Python 工程化流程。这意味着它的依赖管理必须和pyproject.toml或requirements.in保持一致而不是靠pip list requirements.txt手动生成它的代码风格必须能被ruff或black格式化而不是靠手动缩进它的单元测试必须能被pytest发现并运行而不是写在 markdown 里它的 Git 提交历史必须能清晰显示“哪一行代码被修改”而不是整块 JSON 的 diff。 所以我们选择的扩展全部服务于一个目标把.ipynb文件从“不可分割的二进制 blob”降维成“可拆解、可分析、可自动化处理的文本结构”。例如jupyter官方扩展本身只提供基础运行能力但我们必须搭配nbdime来实现真正的 notebook diff搭配jupytext来实现.ipynb↔.py的双向同步搭配pre-commit的nb-clean钩子来自动清理输出和元数据。这不是堆砌插件而是在构建一条“从交互式探索到可交付代码”的标准化流水线。2.3 团队级配置的“最小公约数”原则在给 12 个不同规模的 ML 团队做咨询时我发现一个铁律任何需要“每个人都手动配置”的东西三个月后必然失效。所以我们不推荐“每个人去 Extensions 商店搜名字安装”而是采用“团队配置即代码”的方式。核心是两个文件.vscode/extensions.json声明团队强制要求的扩展列表VS Code 会自动提示未安装者安装.vscode/settings.json预置所有关键设置如默认 kernel、格式化器、linting 规则。 这样新成员克隆仓库后第一次打开 VS Code就会看到一个弹窗“检测到此工作区需要以下扩展是否一键安装”——点击“是”5 秒内他拥有的就是一个和团队完全一致的开发环境。这个设计背后是对“人”的尊重我们不假设工程师有耐心看 2000 字的 setup 文档而是把最佳实践封装成一个点击动作。这也是为什么我们坚决不采用 JupyterLab 的插件体系——它的配置分散在多个地方jupyter_config.py,labextensions/,settings/无法做到 VS Code 这种“开箱即团队一致”。3. 核心扩展解析与实操要点每个插件解决一个具体协作痛点3.1 主力引擎Jupyter 扩展Microsoft 官方——不只是“运行 notebook”ms-toolsai.jupyter是整个方案的地基但它远不止于“让你在 VS Code 里点 run”。它的核心价值在于提供了Kernel 管理的标准化接口这是所有后续协作能力的前提。关键配置项必须调整{ jupyter.defaultKernel: python3, jupyter.askForKernelRestart: false, jupyter.showCellTags: true, jupyter.textOutputLimit: 5000 }jupyter.defaultKernel强制指定默认 kernel避免新人误选系统 Python 而非项目虚拟环境。实测中80% 的“环境不一致”问题根源就是 kernel 选错了。jupyter.askForKernelRestart设为false。协作中频繁重启 kernel 是效率杀手。我们要求所有 notebook 必须设计为“可增量执行”即每个 cell 都能独立运行不依赖全局状态。这倒逼团队写出更健壮、更模块化的代码。jupyter.showCellTags开启 cell 标签功能。这是实现“智能执行”的关键。你可以给 cell 打上#ignore标签CI 在运行 notebook 时会跳过它比如跳过耗时的 EDA 可视化打上#test标签CI 可以只运行带此标签的 cell 做单元测试。这比写一堆if DEBUG:要优雅得多。提示不要用conda activate myenv启动 VS Code这会导致 kernel 路径混乱。正确做法是在 VS Code 中按CtrlShiftP→ 输入Python: Select Interpreter→ 选择你的虚拟环境下的python.exe。VS Code 会自动将其注册为一个 kernel并在jupyter扩展中显示为Python (myenv)。3.2 协作基石Jupytext —— 让 notebook 成为真正的“可版本控制文件”.ipynb文件本质是 JSONGit diff 几乎不可读。jupytext的革命性在于它让 notebook 的“源码”变成纯文本.py文件而.ipynb只是“渲染产物”。安装后必须配置{ jupytext.syncNotebooks: true, jupytext.defaultNotebookFormat: percent, jupytext.textRepresentationFormats: [py:percent, md] }jupytext.syncNotebooks: true开启双向同步。当你保存.py文件时VS Code 会自动生成/更新同名.ipynb反之亦然。这意味着你的代码审查PR可以完全基于.py文件进行——它有清晰的函数定义、import 语句、docstringreviewer 一眼就能看出逻辑问题。jupytext.defaultNotebookFormat: percent选择percent格式而非light或sphinx。它用# %%分隔 cell在.py文件中保留了完整的 notebook 结构且兼容所有主流 Python 工具black、ruff、pytest。一个实际案例某团队将model_training.ipynb同步为model_training.py然后在pyproject.toml中配置[tool.ruff.lint] select [E, F, I] # 只检查错误和导入 ignore [E501] # 忽略行长度因为 %% 会占位这样ruff check model_training.py就能像检查普通 Python 文件一样检查 notebook 的代码质量。注意jupytext不是“把 notebook 转成脚本”而是“让 notebook 和脚本成为同一份源码的两种视图”。你在.py里改一个变量名.ipynb里对应 cell 的代码会实时更新你在.ipynb里加一个新 cell.py里会自动插入# %%和代码。这才是真正的“所见即所得”。3.3 可审查性保障nbdime —— 看懂 notebook 的每一次修改nbdime是jupyter官方出品的 notebook diff 工具但它必须和 VS Code 深度集成才能发挥价值。安装nbdime后还需在终端执行nbdime config-git --enable --global这会在全局 Git 配置中添加[diff jupyter] command nbdime git-diff [merge jupyter] name nbdime git-merge driver nbdime git-merge-driver %O %A %B %L %P效果是当你在 VS Code 的 Source Control 面板中查看 notebook 的变更时不再显示一团乱码的 JSON diff而是清晰的“cell-by-cell”对比新增一个 cell显示绿色背景的完整代码块修改了某个 cell 的代码高亮显示被修改的行删除了一个 cell显示红色背景的代码块。 更重要的是它支持nbdime webdiff命令可以在浏览器中打开一个交互式 diff 页面支持折叠/展开 cell、切换左右视图这对于长 notebook 的 PR review 极其友好。我们曾用它帮一个金融风控团队定位一个线上 bug两位工程师分别修改了同一个 notebook 的不同 cell但其中一个 cell 里有一行random.seed(42)被悄悄删掉了导致模型结果漂移。传统 JSON diff 完全看不出而nbdime的可视化 diff一眼就标红了那行消失的代码。3.4 环境一致性守门员Python 扩展Microsoft 官方 Pylance —— 不只是语法高亮ms-python.python和ms-python.pylance是 VS Code 的 Python 基础扩展但它们在团队协作中的作用常被低估。关键配置在于{ python.defaultInterpreterPath: ./venv/bin/python, // Linux/macOS // python.defaultInterpreterPath: ./venv/Scripts/python.exe, // Windows python.analysis.extraPaths: [src, tests], python.formatting.provider: black, python.linting.enabled: true, python.linting.pylintEnabled: true }python.defaultInterpreterPath绝对路径指向项目虚拟环境。这是保证“所有人用同一个 Python 解释器”的唯一可靠方式。相对路径如./venv/bin/python在某些 VS Code 版本下会失效必须用绝对路径。我们通常在项目根目录放一个setup.sh脚本里面包含python -m venv venv source venv/bin/activate pip install -r requirements.txt并自动写入绝对路径到.vscode/settings.json。python.analysis.extraPaths告诉 Pylance 去src/目录下找模块。这样当你在 notebook 里写from src.models import train_model时Pylance 能正确跳转、补全、类型推断而不是报红。这直接提升了代码的可维护性。python.formatting.provider: black强制团队代码风格统一。black的“无配置”哲学消除了所有关于空格、括号、换行的争论。一个black格式化后的 notebook.py文件reviewer 可以 100% 信任其可读性。4. 实操全流程从新人入职到模型上线的 7 个关键环节4.1 新人第一天5 分钟完成“零配置”环境搭建这是整个方案能否落地的第一道门槛。我们设计了一个极简流程克隆仓库git clone https://your-company.com/ml-project.git进入目录cd ml-project运行初始化脚本./scripts/setup-env.sh该脚本做了三件事① 创建venv② 安装pip-tools并编译requirements.txt③ 自动写入绝对路径到.vscode/settings.json打开 VS Codecode .接受扩展安装提示VS Code 弹出窗口列出.vscode/extensions.json中声明的 5 个扩展Jupyter, Jupytext, Pylance, Ruff, GitLens点击“Install All”。此时新人的 VS Code 已经具备默认 kernel 指向项目虚拟环境所有 notebook 自动同步.py文件CtrlShiftP→Jupyter: Create New Blank Notebook新建的 notebook 会立即出现在资源管理器中且右上角显示Python (ml-project)写完代码按ShiftEntercell 在项目环境中运行输出结果实时显示。实操心得我们曾在一个 20 人的团队推行此流程统计显示从克隆到成功运行第一个 notebook 的平均耗时是 4 分 17 秒。而之前用 JupyterHub 方案平均耗时是 1 小时 22 分钟主要卡在权限申请、镜像拉取、环境配置。差距的核心就在于 VS Code 把“环境”变成了“本地文件”而不是“远程服务”。4.2 日常开发如何写出“可协作”的 notebook协作不是靠工具而是靠约定。我们强制团队遵守三条“notebook 编码规范”并通过 VS Code 设置和 pre-commit 钩子 enforce规范一禁止在 notebook 中写“业务逻辑”。所有核心函数load_data(),train_model(),evaluate()必须定义在src/下的.py模块中。notebook 只负责“调用”和“可视化”。VS Code 的Pylance会实时检查如果你在 notebook 里写了def preprocess(df): ...它会标黄警告“Function defined in notebook. Move to src/ module.”规范二每个 cell 必须有明确职责标签。我们在.vscode/settings.json中预置了常用 cell tagjupyter.cellTagSuggestions: [ setup, data_load, eda, feature_engineering, model_train, model_eval, report ]新人按CtrlShiftP→Jupyter: Add Cell Tag就能快速选择。CI 流水线会扫描所有 notebook如果发现一个model_traincell 里包含了plt.show()就会失败并提示“绘图代码不应出现在 model_train cell 中请移至 report cell。”规范三所有路径必须相对且可配置。禁止写pd.read_csv(/home/user/data/train.csv)。必须用pathlibfrom pathlib import Path DATA_DIR Path(__file__).parent.parent / data train_df pd.read_csv(DATA_DIR / train.csv)VS Code 的Rufflinter 会检查硬编码绝对路径并报错SIM115使用pathlib替代os.path。4.3 代码审查PR如何高效 Review 一个 notebook传统方式是 reviewer 下载.ipynb用 JupyterLab 打开逐 cell 运行。效率极低且无法看到“逻辑变更”。我们的流程是Reviewer 只看.py文件GitHub/GitLab 的 PR 界面默认展示model_training.py由jupytext生成。Reviewer 像 review 普通 Python 一样检查函数签名、参数校验、异常处理、类型注解。关键逻辑点用nbdime查看 notebook diff点击 PR 界面的View file→Switch to rich diff即可看到 cell 级别的可视化变更。运行 CI 的 notebook 检查我们的 CI 配置了nbmake一个专门测试 notebook 的工具- name: Test notebooks run: | pip install nbmake nbmake --no-output --timeout600 notebooks/*.ipynb它会清除所有 notebook 的 output确保不提交缓存结果按顺序执行每个 cell如果某个 cell 报错如KeyErrorCI 失败并精准指出是哪个 notebook 的第几行。 这样reviewer 不需要自己运行就能 100% 确认这个 PR 里的 notebook是能完整跑通的。4.4 环境一致性验证pip-toolspre-commit的黄金组合环境不一致是协作最大的隐形成本。我们的方案是双保险pip-tools管理依赖项目根目录有requirements.in只写顶级依赖scikit-learn1.2.0 pandas1.5.0 jupyter1.0.0运行pip-compile requirements.in生成requirements.txt里面包含所有精确版本号和哈希值。VS Code 的Python扩展会自动识别requirements.txt并在venv中安装。pre-commit清理 notebook 元数据在.pre-commit-config.yaml中添加- repo: https://github.com/timothycrosley/nb-clean rev: v3.0.0 hooks: - id: nb-clean args: [--remove-empty-cells, --remove-all-output]效果是每次git commit前nb-clean会自动删除所有空 cell防止新人误加清除所有 cell 的 output防止提交训练日志、图表等大文件清理 kernel 信息kernelspec: {...}确保.ipynb文件只包含代码和 markdown不绑定任何特定环境。 这样git diff显示的永远是“有意义的代码变更”而不是“kernel 名字变了”这种噪音。4.5 模型上线准备从 notebook 到可部署服务的平滑过渡当一个 notebook 被验证有效后下一步是把它变成 API 服务。我们的路径是jupytext导出.py右键 notebook →Jupytext: Export to Python得到model_training.py。重构为模块将model_training.py中的训练逻辑提取到src/models/trainer.py将数据加载逻辑提取到src/data/loader.py。创建 FastAPI 服务在app/main.py中from fastapi import FastAPI from src.models.trainer import train_and_save_model app FastAPI() app.post(/train) def train_endpoint(): train_and_save_model() # 调用 notebook 中验证过的逻辑 return {status: success}VS Code 一键调试在app/main.py上按F5VS Code 自动启动 FastAPI 服务并在浏览器打开http://localhost:8000/docs。所有断点、变量监视、step-in/out 都和 debug notebook 一样流畅。这个过程之所以高效是因为jupytext保证了model_training.py和原 notebook 的 100% 一致性。你不是在“重写”而是在“组织”——把已经验证过的代码放到正确的工程化位置。我们曾用此流程将一个客户流失预测模型从 notebook 验证到上线 API仅用了 1.5 天。5. 常见问题与排查技巧实录那些踩过的坑都成了 checklist5.1 “Kernel not found” 错误90% 都是路径和权限问题这是新人遇到的第一个高频问题。症状VS Code 右上角显示Python (not connected)点击后报错Kernel python3 is not available。排查步骤确认虚拟环境已激活且安装了 ipykernelsource venv/bin/activate # Linux/macOS # venv\Scripts\activate # Windows pip list | grep ipykernel # 必须有输出如 ipykernel 6.25.0如果没有运行pip install ipykernel。确认 kernel 已注册到 VS Codepython -m ipykernel install --user --name ml-project --display-name Python (ml-project)这会在~/.local/share/jupyter/kernels/ml-project/下创建 kernel spec。VS Code 的Jupyter扩展会自动扫描此目录。检查.vscode/settings.json中的python.defaultInterpreterPath必须是绝对路径且指向venv/bin/python不是venv/目录路径中的空格、中文、特殊字符会导致失败建议项目路径全英文、无空格。实操心得我们曾在一个 macOS 团队遇到此问题根源是 VS Code 用的是/usr/bin/python3系统自带而ipykernel安装在venv里。解决方案不是改 VS Code 设置而是deactivate→source venv/bin/activate→pip install ipykernel→python -m ipykernel install ...。核心原则kernel 必须和 interpreter 在同一个 Python 环境里。5.2 “Notebook diff is unreadable”JSON diff 的救星当nbdime没生效时Git diff 显示的是- cells: [ - { - cell_type: code, - execution_count: null, - metadata: {}, - outputs: [], - source: [ - import pandas as pd\n, - df pd.read_csv(data/train.csv) - ] - } - ]而不是你想要的代码变更。解决方案确认nbdime已全局启用git config --global diff.jupyter.command # 应输出nbdime git-diff确认 VS Code 的 Git 扩展已启用CtrlShiftP→Git: Enable Git。在 VS Code 中手动触发右键 notebook 文件 →Git: Open Changes with nbdime。注意nbdime的 webdiff 模式nbdime webdiff有时会因端口占用失败。此时直接在 VS Code 的 Source Control 面板中点击文件名旁的...→Open Changes with nbdime它会使用 VS Code 内置的 diff viewer更稳定。5.3 “Jupytext sync failed”文件锁与编码冲突症状修改.py文件后.ipynb没更新或反之保存 notebook 后.py文件内容错乱。根本原因jupytext在同步时会读取源文件、转换、写入目标文件。如果两个文件同时被其他程序如另一个 VS Code 窗口、IDEA、甚至文本编辑器打开并写入就会发生冲突。解决方案只用 VS Code 编辑禁用其他编辑器对.py和.ipynb的写入权限。在 VS Code 的settings.json中添加files.exclude: { **/*.ipynb: false, // 确保不被排除 **/*.py: false }, files.watcherExclude: { **/*.ipynb: true, // 关闭文件系统 watcher避免冲突 **/*.py: true }统一文件编码在 VS Code 设置中强制所有文件用 UTF-8files.encoding: utf8, files.autoGuessEncoding: false5.4 “CI notebook test timeout”如何让自动化测试更稳定nbmake默认超时是 30 秒但一个 EDA notebook 可能要 5 分钟画图。CI 经常失败。优化策略按标签分组执行在 CI 脚本中只运行关键路径# 只运行带 model_train 或 model_eval 标签的 cell nbmake --tagsmodel_train,model_eval --no-output notebooks/*.ipynb跳过耗时 cell在 notebook 中给 EDA cell 打上#skip标签nbmake会自动跳过。使用 headless matplotlib在 notebook 开头加import matplotlib matplotlib.use(Agg) # 不显示图形只保存 import matplotlib.pyplot as plt5.5 “团队扩展配置不生效”VS Code 工作区设置的优先级陷阱症状.vscode/extensions.json列出了jupytext但新成员打开 VS Code 后没有提示安装。原因VS Code 的设置优先级是用户设置 工作区设置 文件夹设置。如果用户在自己的全局设置里禁用了某个扩展工作区的extensions.json就不会强制启用它。终极解决方案在.vscode/settings.json中添加强制启用extensions.ignoreRecommendations: false, extensions.autoUpdate: true, extensions.autoCheckUpdates: true提供一键脚本./scripts/install-extensions.sh内容为code --install-extension ms-toolsai.jupyter code --install-extension jupyter.jupytext code --install-extension ms-python.python # ... 其他扩展在setup-env.sh最后调用它。这样即使 VS Code 的 UI 提示失效命令行也能确保安装。6. 进阶协同场景从“代码协作”到“知识协作”6.1 用 Notebook Cell Tags 实现“动态文档生成”jupytext的 cell tags 不仅用于 CI还能驱动文档生成。我们用quarto一个开源的学术出版工具实现给 notebook cell 打上#quarto标签运行quarto render notebooks/model_report.ipynb自动生成 PDF/HTML 文档其中#quartocell 的代码和输出会被嵌入而#ignorecell 则被完全忽略。 这样一个 notebook 就是三合一代码、执行结果、最终报告。算法工程师写完模型一键生成给业务方看的 PDF无需复制粘贴。6.2 VS Code Live Share实时结对编程的终极形态Live Share扩展允许两人实时共享同一个 VS Code 会话。对于 notebook 协作它比传统屏幕共享强在哪共享 kernel 状态A 同学在 cell 1 里import numpy as npB 同学在 cell 2 里直接用np.array([1,2,3])无需重复 import共享变量A 运行了model train_model()B 可以在自己的 cell 里直接print(model.score)共享终端两人看到的是同一个终端pip install new-package后双方 kernel 都能立刻 import。 我们曾用它帮一个远程团队在 2 小时内解决了模型过拟合问题一位专家实时看到另一位工程师的 notebook 执行过程直接在共享终端里运行!pip install optuna然后一起写 hyperparameter tuning cell。6.3 与 DVCData Version Control集成让数据和代码一样可追踪DVC 是数据科学的 Git。它能追踪大型数据集和模型文件。与 VS Code 集成的关键是在.vscode/settings.json中添加 DVC 扩展的配置dvc.logLevel: info, dvc.showMetricsInStatusbar: true在 notebook 中用dvc.api.open()代替pd.read_csv()import dvc.api with dvc.api.open(data/train.csv) as f: df pd.read_csv(f)这样VS Code 的 DVC 扩展会在状态栏显示当前数据集的版本哈希。当你git checkout到旧 commit 时DVC 会自动pull对应版本的数据确保 notebook 总是用“当时”的数据运行。这彻底解决了“结果无法复现”的终极难题。7. 个人经验总结为什么这套方案能在真实团队中跑通我在三个不同行业的团队电商推荐、医疗影像、工业 IoT落地过这套方案最长的已稳定运行 22 个月。它能跑通不是因为技术多炫酷而是因为它直击了团队协作中那些“说不出口但天天在发生的痛苦”它把“环境配置”从“玄学”变成了“可执行脚本”。以前新人问“我的 notebook 为啥跑不了”老员工要花半小时问“你用的什么 Python 版本pip list 有多少包kernel 选对了吗”。现在新人只说“setup-env.sh 运行完了但还是报错”我们立刻知道是脚本问题而不是人的问题。它让“代码审查”从“形式主义”变成了“真刀真枪”。以前reviewer 看着 notebook 的 JSON diff只能点个 approve心里没底。现在他们 review 的是model_training.py能精准指出train_model()函数缺少random_state参数这直接影响模型可复现性。它把“知识沉淀”从“个人笔记”变成了“团队资产”。一个 notebook 不再是张三的“实验记录”而是经过jupytext同步、ruff检查、nbmake测试、DVC追踪的完整资产。李四接手时不需要问张三“你当时怎么跑的”他git checkout到那个 commit./setup-env.shcode .一切就绪。最后分享一个小技巧我们不在团队里说“我们要用 VS Code 做 notebook 协作”而是说“我们要让每个 notebook都能像一个 Python 函数一样被调用、被测试、被部署”。当目标从“工具切换”变成“能力升级”阻力就小多了。毕竟没有一个数据科学家会拒绝“我的模型今天写的三个月后还能 100% 复现”这个承诺。
郑州网站建设
网页设计
企业官网
