最近在学 Excel 自动化或者 Power BI 的人，大概率经历过同一个瞬间：Power Query 的教程看着一路畅通，突然弹幕或者评论区甩出三个字——“M语言”，整个人一下就懵了。学吧，怕是个无底洞；不学吧，又怕哪天卡在某个地方绕不过去。
先给不熟悉的朋友补一句背景：Power Query 是 Excel 和 Power BI 内置的数据清洗流水线，从获取数据、清洗、转换到输出，全程点鼠标就能走完，这也是它被叫作"打工人效率救星"的原因。
但正是这条看似纯鼠标操作的路，到处都埋着 M 语言的影子。要不要专门学它？这个问题在网上已经吵出了真火。我把知乎、小红书、B站近半年跟它直接相关的九十多条讨论翻了一遍，发现大家其实分成了四个阵营，而且每个阵营手里都有真实案例。今天把阵营摆清楚、把不学的代价算明白、再给三条不同的路线，你看完知道自己该投多少时间就行。
网上现在吵成四派
背函数派认为 M 语言就该系统学。B站上孙兴华那套 107 集的《Excel Power Query 零基础入门到 M 函数》播放量一百三十多万，刘波波还专门做了"M语言精讲"系列，从排序一路讲到 List.Generate。B站鼠标派观点正好相反，小红书上一篇高热的《PQ和M语言到底啥关系》开篇就给结论：PQ 是工具，M 只是它背后的"隐形脚本"，不用刻意学，也能把 PQ 用得很溜。小红书
AI派更激进，知乎上有人直接回：不要学，拿 Demo 项目上手做，碰到不懂就问 AI。知乎温和一点的版本来自财务圈：可以用 AI 帮忙写 M 代码，Copilot 等工具生成后粘贴进高级编辑器就能用。小红书还有一派是读懂派，不主张从头写，但坚持必须能看懂——知乎专栏作者采悟讲批量合并时就是这个态度：所谓手动合并，相比自动合并，也就是输入一个简短的 M 函数、多点几次鼠标而已。知乎
四派都有道理，也都有幸存者偏差。分歧的根源在于：他们说的根本不是同一个"学"。
M语言的本质：它是鼠标操作的"录像"
想判断值不值得学，先搞清楚它到底是什么。你在 Power Query 编辑器里点的每一步——提升标题行、筛选、改类型——右侧"应用的步骤"里都会多一行，那一行就是自动生成的 M 代码。小红书
换句话说，M 不是你要去写的东西，而是 PQ 替你记下来的操作流水。整个语言的结构也非常简单：一段查询就是一个 `let … in`，let 里是一步步赋值，in 返回最后结果；数据只装在三种容器里——列表 `{}`、记录 `[]`、表 `table`；大量函数里的 `each` 和 `_` 只是"对每一行执行"的简写。在编辑器里输入 `#shared` 回车，还能把全部内置函数列出来随查随用。也就是说，M 的"写"门槛确实低——鼠标点点就有了；但"读"和"改"的门槛一直都在。这正是三笔账的来源。
不懂M要付的三笔账
第一笔：自动合并留下的烂摊子。 这是报表党最常踩的坑。合并文件夹时顺手点"合并并转换数据"，一键是爽了，但查询栏会多出一堆删都删不掉的中间查询；一旦合并结果出错（采悟的原话是"出错的概率很高"），你还得去改示例文件或者那段自动生成的自定义函数代码，初学者基本无从下手。知乎而懂一点 M 的人怎么做？导入后选"转换数据"，选中 Content 列，新建自定义列写一行 `=Excel.Workbook([Content],true)`，展开，完事——查询栏干干净净，第二个参数为 true 时还会自动把第一行提升成标题。所谓"懂一点"，真的只是一行的差距。
第二笔：查询折叠断了，报表从40秒变6分钟。 Power BI 圈子最近流传一个很广的真实复盘：一份销售日报的刷新从 40 秒涨到 6 分 12 秒，IT 和 DBA 查了一圈，发现数据库资源占用不到 15%——问题是 Power BI 每次都把 1200 万行整表拉到本地算。断点在第 4 步：作者加了个自定义列 `Date.Month([OrderDate])`，这个 M 函数没有 SQL 等价物，折叠从这里断掉，后面所有筛选、分组全部转成本地执行。知乎
修复思路就三步：把能折叠的筛选、分组挪到断点前面；把月份做成数据库视图里的普通列；把嵌套 if 换成 SQL 的 CASE WHEN。第二天刷新，51 秒。作者还给了一个很好用的经验判断：步骤超过 15 步、自定义列超过 3 个，折叠大概率已经断了。知乎
第三笔：大小写和 null 这种"鬼错误"。 M 对格式符大小写是敏感的，`Date.ToText` 里大写 `M` 是月、小写 `m` 是分钟，写反了不报错，只是日期悄悄变成一串奇怪的数字；列里混进一个 `null`，文本函数直接罢工，合并展开后整列数据说没就没，这类提问在知乎上常年有人围观。知乎这类问题的共同点是：不懂 M 的人连"错在哪一步、为什么错"都读不出来，只能推倒重来。
真要学，先学哪几个函数
我把几个平台上被反复点名的函数做了个粗略统计。新手侧高频的是 `Excel.Workbook` 和 `Csv.Document`——都是批量合并场景的解析入口，前者第二个参数记得给 `true`，后者处理中文时加上 `Encoding=936` 防乱码。进阶侧出镜率最高的是 `List.Accumulate`，知乎、B站等平台上至少七条被反复传播的内容在讲它；知乎作者"白神"光这一个函数的编号实战案例就写到了第三十五个，连"连续三位数字压缩"这种硬核需求都用它解。知乎
它的作用是把一列值逐步累积成一个结果，很多看起来必须写循环的需求，用它一个函数就收掉。但我的建议是别背清单，`#shared` 加上官方文档随用随查就够了，真正需要先建立的是"读懂一段 M 在干什么"的能力，这比背任何函数都值钱。
三类人，三条路线
报表自动化党（财务、人事、运营，每月固定合并几十个表）：目标定在"读懂级"，预算 3-5 小时。看懂 `let…in` 结构，认识 `Excel.Workbook([Content],true)` 这类合并入口，会改参数（比如编码、分隔符、true/false），就足以覆盖你 90% 的场景。作为参照，一位做 HR 的新手记录过自己学 PQ 的一周：计划五天学完，结果拖到第七天才收尾，网课里很多操作看完不会用——这是把整个 PQ 从头啃一遍的节奏，而"读懂级"只需要其中的一个子集。知乎随便打开一个合并查询，左侧是明细表，右侧"应用的步骤"十几二十步一字排开——你要做的就是看懂这串步骤每一步在干什么，而不是从头写出来。小红书上一篇 340 赞的《Power Query 全流程图解》把从连接到输出的流程画成了一张图，跟着把每个环节对应到"哪一步会生成什么 M 代码"，效率最高。小红书
BI党（用 Power BI 连数据库做报表）：预算 1-2 周，但重点不是函数清单，而是查询折叠。先把折叠指示器打开（文件 → 选项和设置 → 选项 → Power Query 编辑器 → 勾选"查询折叠指示器"），再学会看"查看原生查询"是灰的还是亮的——灰色说明整条链都在本地算。知乎这条路线的回报是直接兑现成刷新时间的。
进阶党（想往数据分析方向走）：可以系统学，手边放一份速查表就行。小红书上 Eric 分享的那份来自 Ivan Bondarenko 的 M 语言指南，覆盖 12 类数据类型、20 多个运算符和常用函数，收藏量比点赞还高，当作字典用很合适。小红书
让AI替你写，但你得会验收
AI 派说的没错，现在让 AI 生成一段 M 代码确实秒出。但 B站讲"让 AI 帮你写 M 函数"的查查老师有句话说得很实在：以前学 M 函数费时费力，有了 AI 容易多了，前提是你对 Power Query 多少要有些熟悉。B站我的用法可以总结成"三问三查"：让 AI 解释每一步在干什么；问它某一列如果出现 null 会怎样；问这段逻辑能不能折叠到数据库。查的话：粘进高级编辑器后对着"应用的步骤"逐步核对、用小样本数据先跑一遍、重点看它有没有偷偷加自定义列。知乎上整理 M 函数知识卡片的答主，如今已经会特意注明内容"包括部分知识通过AI生成，为了便于理解，但进行过验证"——验收意识正在变成社区共识。知乎AI 把"写"的成本打到了接近零，但"验收"的成本没变——而验收能力，就是前面说的"读懂级"。
两个值得留意的变化
一是 WPS 阵营开始跟进。今年 6 月已经有 B站用户实测新版 WPS 支持 Power Query，并跑通了多表合并，虽然功能完整度还在爬坡，但这意味着 PQ/M 这项技能正在从"Excel 专属"变成通用办公技能，学习投入的保值性在变好。B站二是 AI 集成在加速，连 Power BI 生态里的各类 AI 助手都在快速迭代，能连本地报告、能接云端模型。知乎这两个变化指向同一个结论：写 M 的门槛会归零，读 M、验 M 的能力会变成稀缺品。
所以回到最初的问题：M 语言要不要学？如果你只做报表合并，花一个下午学到"读懂级"，这笔投入的回报最快也最稳；如果你做 BI，把预算花在折叠规则上；只有走专业路线的人，才值得系统性地把函数过一遍。别被"背函数"吓退，也别信"完全不用学"——那两拨人，只是恰好站在不同的坑边上。
