Python in Excel不访问本地环境、不能返回VBA，连SQL都连不上，到底能干嘛？

一、导语：被误读的“能力清单”

任何一项新工具进入成熟生态时，最先被传播的往往不是它能做什么，而是它做不到什么。PiE 的舆论轨迹颇具代表性：社区讨论中高频出现的三个否定句——“不访问本地环境”“不能返回 VBA”“连 SQL 都连不上”——几乎构成了公众对它的第一印象。然而这三个否定句描述的并不是缺陷，而是设计约束。理解约束的动机，比罗列约束本身更有价值。

从产品定位看，PiE 面向的是“电子表格用户的计算增强”，而非“开发者的通用运行时”。微软在官方文档中将其描述为在 Excel 网格内使用 Python 分析数据的方式，计算在 Microsoft Cloud 中完成，结果以值或 Python 对象的形式返回工作表（Microsoft Learn, 2024）。这一定义已经隐含了后续所有限制：云端执行意味着无法触达本地文件系统；值回写意味着不产生可执行宏；托管网络策略意味着出站连接受控。本文评述：把这三条当作“产品缺陷”来批评，本质上是用桌面脚本的语义去衡量一个公式级组件，属于范畴错误。

更有价值的提问方式是：在一个“输入来自单元格、输出回到单元格、执行环境不可变、网络受限”的约束集合下，什么样的计算任务反而更适合放在这里？本文的回答是：那些需要 Python 生态的统计与建模能力、但又不希望引入本地环境依赖、且对结果可复现性有要求的任务。这条主线将贯穿后文所有章节。

二、背景与问题定义：三条限制的真实成因

2.1 不访问本地环境：托管容器与安全边界的必然结果

PiE 的 Python 代码并非在用户机器上执行，而是在微软托管的容器中运行。官方文档说明，计算通过 Excel 与 Microsoft Cloud 之间的安全通道完成，Python 运行时由 Microsoft 提供并维护（Microsoft Learn, 2024）。这意味着 open('C:/data.csv') 这类调用在语义上就是无效的——容器里没有用户的 C 盘。

这一约束的直接后果是：所有数据必须经由 Excel 网格或受支持的连接器进入 Python。反过来看，它也消除了“本地环境漂移”这一长期困扰数据分析复现的顽疾。传统桌面脚本的复现失败，很大比例源于解释器版本、包版本、系统库差异；托管容器把这一层收敛为单一受控镜像。本文评述：“不能访问本地”与“环境不可漂移”是同一枚硬币的两面，前者是用户体验上的损失，后者是工程治理上的收益，二者不可分割地绑定在一起。

2.2 不能返回 VBA：值语义与宏语义的隔离

PiE 的输出是“值”或“Python 对象”，而不是可执行代码。用户在单元格中看到的是计算结果，公式栏中保留的是 =PY(...) 调用。它不会、也不应该在打开工作簿时触发宏。这一设计与 Excel 的宏安全模型直接相关：VBA 宏长期是恶意文档的主要载体之一，微软在信任中心文档中持续强调宏的启用风险（Microsoft, 2023）。若 PiE 能生成并返回 VBA，等于在云端计算与本地执行之间打开一条任意代码通道，安全模型将彻底失效。

因此，“不能返回 VBA”不是能力缺失，而是刻意维持的语义隔离：云端负责计算，本地负责呈现，二者通过值传递而非代码传递耦合。笔者认为，这一隔离恰恰是 PiE 能被企业 IT 接受的前提——它把“云端代码”降级为“云端数据”，从而绕开了宏信任链的复杂性。

2.3 连不上 SQL：网络策略与连接器分工

关于“连不上 SQL”，需要区分两种情形。其一，在 Python 代码中直接使用 pyodbc 或 sqlalchemy 建立任意数据库连接，在托管沙箱的受控网络策略下通常不可行，官方文档对网络访问有明确限制说明。其二，通过 Excel 原生的“获取数据”能力（Power Query）先把数据引入工作表或数据模型，再交给 Python 处理，这条路径是完全可行的。

本文评述：把“Python 不能直连 SQL”解读为“PiE 无法处理数据库数据”，是一种典型的层次混淆。在微软的数据栈设计中，连接与抽取本就属于 Power Query 的职责，Python 的职责是抽取之后的变换与建模。强行让 Python 承担连接器角色，既违背分层原则，也会把凭据管理、网络策略等本应由平台处理的问题重新抛给脚本作者。后文第 4.2 节将给出这条“连接器 + Python”组合路径的具体操作步骤。

三、原理与技术路线：沙箱、计算图与确定性边界

3.1 执行模型：从单元格到容器的数据流

PiE 的执行可以抽象为一条单向数据流：单元格区域经序列化后上传至云端容器，容器内的 Python 运行时反序列化为 DataFrame，执行用户代码，再将结果序列化回传，最终以值或对象形式落入目标单元格。官方文档指出，Python 代码在 Microsoft Cloud 中运行，结果返回工作表（Microsoft Learn, 2024）。这条链路的关键性质是无状态与幂等：每次计算都从单元格的当前值出发，不保留上一次执行的进程内状态。

无状态设计带来两个直接推论。第一，代码不能依赖“上次运行留下的变量”，所有输入必须显式来自网格；第二，同一份代码加同一份输入，必然得到同一份输出（在依赖随机数时需固定种子）。本文评述：这实际上把 PiE 单元格变成了一个纯函数节点——输入确定、输出确定、无副作用。纯函数性质在桌面脚本中需要靠工程纪律维持，而在 PiE 中由运行时强制保证，这是它相对桌面 Python 的结构性优势。

3.2 计算图视角：公式依赖即数据依赖

Excel 的重算引擎本质上是一个依赖图（dependency graph）求值器：单元格之间的引用关系构成有向无环图，任一单元格变化触发其下游重算。PiE 单元格是这个图中的一个节点，其上游是作为输入的单元格区域，下游是引用其输出的公式。当上游数据更新时，PiE 节点会被重新求值，云端计算随之触发。

这一视角解释了 PiE 的一个常被忽视的特性：它天然继承了 Excel 的增量重算语义。用户不需要手写“监听数据变化—重新执行脚本”的调度逻辑，依赖图已经承担了调度职责。笔者认为，这是 PiE 与 Jupyter Notebook 最本质的差异：Notebook 的执行顺序由用户手动维护，容易出现“隐藏状态”导致结果不可复现；而 PiE 的执行顺序由依赖图决定，复现性由结构保证。当然，代价是用户失去了对执行时机的细粒度控制，长耗时计算可能拖慢整表重算——这是后文 5.3 节讨论的性能边界之一。

3.3 确定性边界：随机性、时间与外部状态

纯函数性质并非无条件成立。三类因素会破坏确定性：其一，未固定种子的随机数生成；其二，读取当前时间的调用（如 datetime.now()）；其三，任何依赖外部网络状态的调用。前两类在代码层面可控，第三类则被沙箱网络策略直接阻断。

因此，工程上应把 PiE 代码约束在“显式输入 + 确定性变换”的范式内：随机过程必须显式设定种子，时间戳应作为单元格输入而非在代码中读取，外部数据应预先经连接器落入网格。本文评述：这三条约束看似繁琐，实则是把“可复现性”从口头承诺变成了结构保证。在受监管行业（金融、医药、审计）中，这种结构保证的价值远高于脚本编写的便利性。

3.4 对象模式与值模式：两种回写语义

PiE 支持两种输出形态。值模式将计算结果直接写入单元格，适合最终报表；对象模式保留 Python 对象引用，使下游 PiE 单元格可以继续以该对象为输入，适合多步管道。官方文档对两种模式均有说明（Microsoft Learn, 2024）。对象模式的意义在于避免中间结果的反复序列化：一个 DataFrame 在多个 PiE 单元格间传递时，若每步都转为值再转回，既损失类型信息又增加开销。

笔者认为，对象模式是 PiE 从“单点计算”走向“管道编排”的关键机制。它使得一条完整的分析链——清洗、特征、建模、评估——可以在多个单元格间以对象引用串联，而每个环节仍保持独立可读、可审计。这与传统 VBA 中“一个巨型 Sub 包办一切”的风格形成鲜明对比。

# 单元格 A1：读取网格区域，返回 DataFrame 对象
df = xl("RawData[#All]", headers=True)

# 单元格 A2：以 A1 的对象为输入，做清洗
clean = df.dropna(subset=["amount"]).assign(
    amount=lambda d: d["amount"].clip(lower=0)
)

# 单元格 A3：以 A2 的对象为输入，做建模
from sklearn.linear_model import LinearRegression
model = LinearRegression().fit(clean[["x"]], clean["amount"])

# 单元格 A4：输出系数，值模式回写
model.coef_

四、关键数据与案例：四类可落地的工程模式

4.1 模式一：统计推断与假设检验的“公式化”

Excel 内置的统计函数覆盖了常见分布与检验，但在多组比较、稳健标准误、非线性模型等场景下能力有限。PiE 可以直接调用 statsmodels 与 scipy.stats，把完整的回归摘要、置信区间、诊断统计量回写到网格。其价值不在于“能算”，而在于把统计过程固化为一列可复用的公式：数据更新，检验结果自动重算，方法与参数留在公式中可被审计。

操作路径可归纳为四步：第一步，用命名区域或表格结构化输入数据；第二步，在 PiE 单元格中以 xl() 读取区域；第三步，调用统计库完成估计与检验；第四步，将关键统计量以值模式回写，将模型对象以对象模式保留供下游使用。本文评述：这一模式的最大收益是审计友好——审阅者无需运行脚本，只需查看公式与输入区域，即可判断方法是否恰当。

4.2 模式二：连接器 + Python 的数据库分析链

针对“连不上 SQL”的约束，正确路径是把连接职责交给 Power Query。具体步骤：第一步，在“数据”选项卡中使用“获取数据—来自数据库”，配置数据库连接与查询；第二步，将查询结果加载到工作表或数据模型；第三步，在 PiE 单元格中读取该区域，执行 Python 变换；第四步，将结果回写并用于报表。整条链路中，凭据由 Power Query 管理，网络策略由平台处理，Python 只负责变换与建模。

这一分工的工程意义在于职责单一化。若强行在 Python 中直连数据库，凭据将出现在代码或环境变量中，审计困难且易泄露；而 Power Query 的连接配置可被集中治理。笔者认为，把“连接”与“计算”分离，是微软数据栈一以贯之的设计哲学，PiE 只是这一哲学在公式层的延伸。关于 Power Query 的官方入门资料，可参考 Microsoft Learn 的 Power Query 文档。

4.3 模式三：机器学习原型的“表格化”交付

PiE 预置了常用科学计算库，用户可在公式中直接调用 scikit-learn 完成分类、回归、聚类等任务。其适用场景不是生产级模型服务，而是分析交付物中的可复现原型：分析师把特征工程、模型训练、评估指标全部写在公式链中，业务方打开工作簿即可看到“输入—方法—结果”的完整链条。官方文档列出了 PiE 支持的库集合，包括 pandas、matplotlib、scikit-learn 等（Microsoft Learn, 2024）。

需要强调边界：受沙箱资源与重算机制限制，PiE 不适合训练大规模模型或执行长耗时超参数搜索。工程上应把模型规模控制在“秒级重算可接受”的范围内，超出部分应下沉到专门的计算平台。本文评述：把 PiE 定位为“原型与交付层”而非“训练层”，是避免误用的关键。

4.4 模式四：可视化与报表的自动化拼装

PiE 可调用 matplotlib 等绘图库生成图像并回写到工作表。与 Excel 原生图表相比，其优势在于复杂统计图形的表达能力，如残差诊断图、相关性热力图、分布对比图。操作上，绘图代码在 PiE 单元格中执行，图像以对象形式返回并锚定在单元格附近，随数据更新而重绘。

但需注意，图像回写是“快照”而非“活图”，交互能力弱于原生图表。因此合理的做法是：需要交互与钻取时用原生图表，需要统计诊断与定制样式时用 PiE 绘图。二者互补而非替代。关于 matplotlib 的官方教程，可参考 Matplotlib 官方教程；pandas 的入门材料可参考 pandas 用户指南。

五、对比与局限：与 Power Query、VBA、Office Scripts 的分工

5.1 四种自动化手段的能力矩阵

Excel 生态中同时存在多种自动化手段，各自的语义边界不同。Power Query 面向数据抽取与变换，声明式、可刷新；VBA 面向本地过程自动化，命令式、可触达对象模型；Office Scripts 面向云端自动化，TypeScript 编写、可被 Power Automate 调用；PiE 面向公式级计算，纯函数、可审计。混淆四者的边界，是许多工程问题的根源。

本文评述：选择哪种手段，应以其执行位置与副作用语义为首要判据。需要触达本地文件与界面时用 VBA；需要跨平台云端调度时用 Office Scripts；需要连接与变换数据时用 Power Query；需要统计建模与科学计算时用 PiE。四者不是替代关系，而是分层协作关系。

5.2 局限一：重算成本与资源边界

由于 PiE 计算在云端完成，每次重算都涉及数据上传、容器执行、结果回传。当工作簿包含大量 PiE 单元格或大区域输入时，重算延迟会显著上升。官方文档对计算配额与限制有说明（Microsoft Learn, 2024）。工程上应遵循“少而重”的原则：把复杂逻辑集中在少数 PiE 单元格，避免把简单运算拆散到大量单元格中。

本文评述：这一局限本质上是分布式计算的固有代价，而非实现缺陷。理解这一点，就不会试图用 PiE 去替代本应在本地完成的逐行计算。合理的架构是“本地做轻量逐行、云端做重量整体”。

5.3 局限二：依赖管理与版本漂移

PiE 的 Python 运行时与库版本由微软统一维护，用户不能自行安装任意第三方包。这保证了环境一致性，但也意味着某些小众库或特定版本无法使用。官方文档列出了支持的库集合。工程上应在设计阶段就核对依赖是否在支持列表内，避免开发后期返工。

笔者认为，这一约束与容器化部署的理念一致：牺牲部分灵活性，换取可复现性与可维护性。对于以交付与审计为导向的分析场景，这一交换是划算的；对于依赖特定版本行为的科研复现，则需谨慎评估。

5.4 局限三：协作与治理

PiE 代码随工作簿分发，审阅者需要相应许可与运行时支持才能查看结果。这在跨组织协作中可能造成障碍。治理上应建立规范：PiE 单元格集中放置、输入区域命名清晰、关键参数以单元格而非硬编码形式给出。这样即使审阅者无法执行，也能通过公式与输入理解计算逻辑。

本文评述：治理问题的根源不在 PiE 本身，而在于电子表格长期缺乏代码审阅文化。PiE 把 Python 引入网格，反而提供了一个契机：让公式级代码也接受与软件代码同等的审阅标准。关于 Excel 中 Python 的官方介绍，可参考 Microsoft 支持页面的 Python in Excel 说明。

六、结论与展望：从公式节点到可审计计算资产

回到开篇的提问：不访问本地环境、不能返回 VBA、连不上 SQL，PiE 到底能干嘛？本文的答案是：它能干的是把 Python 生态的统计与建模能力，封装为公式计算链中确定性、可审计、可复现的纯函数节点。这一能力看似狭窄，却精准命中了分析交付中长期存在的痛点——方法散落在脚本里、结果无法复现、审阅者无从判断。PiE 用运行时约束把这些痛点转化为结构保证。

展望未来，随着 Microsoft 365 生态的演进，PiE 有望与 Power Query、Office Scripts、Power Automate 形成更紧密的编排关系：连接由 Power Query 承担，调度由 Power Automate 承担，计算由 PiE 承担，呈现由原生图表承担。本文评述：这一分工若能落地，电子表格将从“个人计算工具”进一步演化为可审计的计算资产载体。对从业者而言，重要的不是争论 PiE 缺什么，而是理解它在分层架构中的位置，并据此设计可维护、可复现的分析管道。

实践建议：先用一个真实报表做小范围试点，把其中最复杂的一段统计逻辑迁入 PiE，验证重算延迟与协作体验，再决定推广范围。切忌一开始就全面替换现有脚本。