迭代篇:Excel 专家 4.29,AI 强不强不在记忆,在文档——6,250 页 VBA、770 页 PQ、510 页 DAX,400 个 MCP 函数真不够看

上一篇迭代篇，我拆了一个 400+ 函数的 Excel MCP。 这一篇，我把它甩得更远了。 不是因为我多写了几百个函数，是因为我想明白了一件事： AI 强不强，不在训练后的记忆，在它手边有没有足够充足、经过验证的文档。 人现场写代码，没有文档也难一步到位；AI 也一样。

一、先交代：上一篇之后，我又做了什么

上一篇迭代篇，写到 4.11.x。

那一版的核心，是语料、沙箱、公式层：

• 11 + 5 个 om_* 语料模块，约 215 个公开函数；
• 318 项 corpus 断言；
• 手写 COM 先沙箱，再动真表；
• 09a-09h 公式层，30 条配方。

那一版，我已经觉得"挺能打"了。

但这两天，从 4.12 到 4.29，我又走了 19 个版本节点。

两天，19 个版本。

不是我闲着没事刷版本号，是因为每补一层，就发现下一层还有洞。

举个例子：

补了 VBA 文档，发现"文档有，但签名没有"——于是做 4,888 张签名卡；

补了签名卡，发现"签名有，但没实测"——于是做 4,788 API × 2 宿主实测；

补了实测，发现"Excel 通过，WPS 不通过"——于是做双宿主兼容；

补了双宿主，发现"函数有，但版本不对"——于是做 DAX 版本矩阵、PQ #shared 探针。

一层套一层，不是堆功能，是补漏洞。

这一版补的，不是"更多函数"，是更多文档、更多验证、更多边界：

• VBA 官方文档 6,250 页，全量入库；
• Power Query 官方文档 770 页，667 个 M 函数页；
• DAX 官方文档约 510 页；
• 4,888 张晚绑定签名卡；
• 398 个枚举、4,172 个常量；
• 4,788 个 API × 2 个宿主，全量实测；
• 12,407 个散页，收进 4 个资源包；
• 55 个脚本、36 篇参考文档；
• 390+ 项 corpus 断言，Excel / WPS 双宿主全绿。

几个关键节点：

• 4.15：VBA 官方文档 6,250 页入库；
• 4.17：4,888 张晚绑定签名卡；
• 4.18：4,788 个 API × 2 宿主，全量实测；
• 4.21：数据模型 / Power Pivot 语料；
• 4.24：Power Query 文档 770 页；
• 4.25：DAX 文档 510 页 + DAX 查询通道；
• 4.29：DAX 488 函数版本矩阵 + PQ #shared 探针。

上一篇，是给 AI 一套语料。

这一篇，是给 AI 一座图书馆，外加一套查法、一套验证。

二、AI 强不强，不在记忆，在文档

先说一个我越来越确信的判断：

AI 强不强，不在它训练完之后记住了多少，在它手边有没有足够充足、经过验证的文档。

这句话，不是替 AI 找借口。

你想想人。

一个做了二十年 Excel 的人，你让他现场写一段复杂的 COM 代码，不许查文档、不许搜索、不许看示例，纯手写，一步到位——他也很难。

不是他不会，是人脑不存那么细的东西。

比如 Worksheets.Add 的 After 参数。

你记得它叫 After，但你记得它是第几个位置参数吗？记得它在晚绑定下传命名参数会被静默忽略吗？记得 WPS 下它可能按活动单元格重建表吗？

比如 Range.Find。

你记得 LookAt 怎么传，但你记得它在晚绑定下会失效吗？

比如 Slicers.Add。

你记得它有几个参数，但你记得它只接受单参数吗？

这些不是"知识"，是"细节"。

细节不靠记，靠查。

参数是第几个、枚举值是多少、这个属性在晚绑定下会不会失效、这个方法在 WPS 里是不是另一个行为——这些不是"知识"，是"细节"。

细节，要靠文档。

AI 也一样。

而且 AI 比人更危险：人会承认"我记不清了，我查一下"；AI 不会，它会一本正经地凭记忆编。

AI 的记忆，有三个问题：

第一，压缩。训练时把海量文本压成参数，细节会被抹平。

第二，模糊。它记得"大概是这样"，不等于"参数就是这个"。

第三，过时。Office 在更新，WPS 在更新，模型的知识截止日期不会跟着更新。

所以它写出来的代码，最容易"看起来对，跑起来错"。

编出来的代码，语法可能对，参数可能错；跑起来可能报错，也可能不报错但结果不对。

所以我不再指望"模型记住"。

我做的是：把文档放到它手边，把查法写进路由，把验证做成闸门。

三、把"原典"搬进来：VBA、Power Query、DAX

这次最大的一块，是文档库。

VBA：6,250 页官方文档，全量入库

我把 MicrosoftDocs/VBA-Docs 的 Excel 子集，全量搬了进来：

• api/Excel.* 5,996 页：方法、属性、事件、枚举、对象主页；
• api/Office.Mso* 146 页：共享枚举；
• excel/ 108 页：概念篇。

合计约 6,250 页，27MB。

不是"下载下来放着"，是接进了检索：

• vba_doc_search.py --id Excel.Range.Merge：查签名、参数、Remarks；
• --const xlUp：查枚举值；
• --enum XlDirection：查枚举成员；
• 命中成员时，同时显示签名卡路径。

在此基础上，又生成了 4,888 张晚绑定签名卡：

每个 Excel 成员 API 一张卡，含官方摘要、Python 晚绑定调用形式、参数表、关联枚举、实测状态。

签名卡长什么样？

• 官方摘要：这个 API 是干什么的；
• Python 晚绑定调用形式：位置参数优先，命名参数风险单独标注；
• 参数表：必选/可选、类型、说明；
• 关联枚举：参数里引用的 Xl* / Mso* 枚举，带样例数值；
• 原文 Remarks 入口；
• 实测状态：official-doc 起步，sig_test_runner.py 实测后升级。

AI 写代码前，先查卡；卡上有调用形式，就照着抄，不凭记忆拼。

比如 Range.Find：

• 官方签名：Find(What, After, LookIn, LookAt, SearchOrder, SearchDirection, MatchCase, MatchByte, SearchFormat)；
• 晚绑定风险：LookAt 在部分宿主/场景下失效；
• 签名卡会标：参数顺序、必选/可选、晚绑定风险、关联枚举。

AI 一看卡，就知道怎么传；不看卡，就会按记忆传。

按记忆传，十次对八次；那两次，就是事故。

AI 写代码前，先查卡，不凭记忆。

还有 398 个枚举、4,172 个常量，生成 xl_constants.py：

晚绑定直接 from xl_constants import xlUp，不用再猜 -4162 还是 -4163。

Power Query：770 页官方 M 参考

Power Query 这块，之前只有语料，没有原典。

这次补了 pq-docs/：

• M 语言规范 13 节；
• 概念篇；
• 667 个 M 函数页，25 类；
• 枚举、常量、动态值参考。

合计 770 页，0 失败。

检索脚本 pq_doc_search.py 支持四种查法：

• --fn：精确查函数；
• --category：按分类查；
• --kw：关键词；
• --full：读全文。

比如 AI 要写"按条件合并多个查询"，先 --kw combine，看到 Table.Combine、Table.CombineColumns、Table.NestedJoin 的签名和示例，再决定用哪个。

不是"我记得有个函数"，是"我查到了这个函数，参数是这样"。

同时，PQ 语料从 282 行扩到 430 行，补了刷新、合并、装载、诊断的写法。

AI 写 M，最容易犯三种错：

第一，函数名不对。Power Query 的函数是 Table.Combine、Table.NestedJoin，不是 SQL 的 JOIN，也不是 pandas 的 merge。

第二，参数顺序不对。Table.Combine({t1, t2}) 传的是表列表，不是两个表；Table.AddColumn 的第二个参数是列名，第三个才是函数。

第三，步骤顺序不对。先筛后合并，和先合并后筛，结果可能一样，性能差很多。

这三种错，文档里都有；但 AI 不查，就会凭记忆编。

现在 770 页文档在本地，pq_doc_search.py --fn 一查，签名、参数、示例全出来。

DAX：约 510 页官方参考 + 488 函数版本矩阵

DAX 这块，做了两件事。

第一，dax-docs/：learn.microsoft.com 官方 DAX 参考，约 510 页，函数 25 类 + DEFINE / EVALUATE 语句 + 最佳实践。

第二，om_datamodel_ops 新增两个通道：

• dax_query(wb, dax, dest)：对已有模型执行 EVALUATE 查询；
• dax_dmv：DMV 元数据查询，列度量值清单。

第三，版本矩阵。

DAX 的坑，不是"会不会写"，是"这个函数在你的版本里有没有"。

所以我抓了 dax.guide（SQLBI）的逐函数兼容矩阵：

• 488 个函数；
• Excel 2016 / 2019 / Microsoft 365 × Power BI × SSAS；
• 版本区间 + 首发日期。

生成 dax_version.py：

• --fn X --excel 2019：单函数判定；
• --newer-than 2019：版本代差清单。

实测样例：ACCRINT 首发 2020-06-21，Excel 只有 Microsoft 365 有，2016/2019 没有。

这就是要拦的场景：AI 不能默认"函数存在"。

AI 写 DAX，最容易犯三种错：

第一，函数版本不存在。ACCRINT 在 Excel 2016/2019 没有，只有 Microsoft 365 有；AI 不查版本，写出来就是 #NAME?。

第二，关系没建。DAX 不是 SQL，它依赖数据模型里的关系；关系没建，RELATED 就取不到值。

第三，上下文不对。行上下文、筛选上下文、CALCULATE 的上下文转换，是 DAX 最容易错的地方；AI 不查最佳实践，就会写出"看起来对、算出来错"的度量值。

这三种错，靠"记忆"解决不了。

现在是：版本矩阵查函数、文档库查写法、dax_query 跑一遍看结果。

Power Pivot / 数据模型：也能碰

om_datamodel_ops.py 覆盖：

• model_available：WPS 门禁；
• model_inventory：表、列、记录数、关系、连接、度量值；
• model_add_measure_via_vba：加度量值；
• model_refresh：刷新；
• pivot_from_model：从模型建透视；
• cube_write：CUBEVALUE 写回；
• load_to_model_guidance：装载指引。

这块有一个实测结论：程序化"播种"数据模型不可行——Connections.Add/Add2 本机一律错误 5，Model.CreateModelWorkbookConnection 会崩 Excel 进程。

所以定位很清楚：对已存在的模型，做全套读改；不负责从零造模型。

这不是偷懒，是边界。

四、文档不是抄的，是测出来的

你可能会问：文档搬进来，就准了吗？

不一定。

文档是人写的，人写的时候，和真实使用可能有差距。

这种差距，通常有三种：

第一，漏。官方文档写了参数，没写"晚绑定下会失效"；写了方法，没写"WPS 下行为不同"。

第二，错。文档版本和实际版本不一致；示例代码是旧版本的写法；参数说明和真实签名对不上。

第三，过时。Office 在更新，WPS 在更新，文档的更新节奏跟不上。

这三种差距，靠"读文档"是填不平的。

只能靠"跑一遍"。

所以这次，我把"测试"看得比"文档"还重。

4,788 个 API × 2 个宿主，全量实测

我写了 sig_test_runner.py：

• 在一次性沙箱工作簿里，批量实测签名卡；
• 属性扫描：35 个夹具对象 × "读 → 标量写回当前值"幂等 round-trip；
• 方法配方：50 条 recipe，安全实参 + 独立读回校验；
• 证据逐 API 落 vba-docs/evidence/；
• --report 汇总差异表。

定稿轮结果：

• Excel / WPS 各 4,788 项；
• call-fail 归零；
• call-ok 45、get-ok 1,091 / 1,121、no-recipe 1,186、no-context 2,286、manual 7、blocked 4。

不是"都能调"，是"知道哪些能调、哪些没配方、哪些没上下文、哪些要手工"。

这里还有一条纪律：证据等级。

• official-doc：官方文档写了，但没实测；
• verified-host：本机实测通过；
• verified-both：Excel + WPS 双宿主都通过。

AI 写代码，优先用高等级证据；低等级证据，先在沙箱试。

这不是"多此一举"，是"不让文档的错，变成你的错"。

这比"400 个函数都能调"细在哪？

• call-ok 45：有配方、调用成功；
• get-ok 1,091 / 1,121：属性读取成功；
• no-recipe 1,186：没有安全配方，不盲调；
• no-context 2,286：没有夹具上下文，不乱测；
• manual 7：需要手工确认；
• blocked 4：宿主限制。

这不是"成功率高"，是"边界清楚"。

AI 最怕的，不是"不会"，是"不知道自己不会"。

这套实测，就是把它"不会"的地方，标出来。

这比"400 个函数都能调"细得多。

302 项单侧失败，判读成"六族"

实测里，有 302 项稳定单侧失败。

第一反应是"是不是功能缺失"。

逐项 3 次复测、多数决之后，判读成六大会话态读取受限族：

• Chart 渲染族；
• Axis 刻度族；
• PivotCache 连接族；
• PivotField / PivotTable 高级族；
• Range 透视关联族；
• Shape-Series 冷门族。

不是功能没有，是需要特定布局才可读。

这些问题，文档不会告诉你；只有实测 + 复测，才能判清楚。

六族是什么意思？

• Chart 渲染族：图表没渲染出来，读不到某些属性；
• Axis 刻度族：坐标轴刻度要特定布局才可读；
• PivotCache 连接族：透视缓存要连接建立后才可读；
• PivotField / PivotTable 高级族：高级字段布局才可读；
• Range 透视关联族：区域和透视的关联要上下文；
• Shape-Series 冷门族：形状和系列的冷门属性要特定对象。

不是功能缺失，是"会话态受限"。

你把它们当成"没有"，就会误判；你标出来，AI 就知道"先建布局，再读"。

这就是实测的价值：不是"证明我行"，是"知道哪里不行、为什么不行、怎么才行"。

官方文档没写的坑，实测抓到了

举几个例子。

Range.Find 的 LookAt，在晚绑定下失效。

官方文档写了参数，没写"晚绑定会失效"。

实测抓到，写进语料和陷阱表。

WPS 的 ListObjects.Add 忽略命名参数。

它会按活动单元格重建表，把表头改写成"列1/列2/列3"。

这是数据破坏级；修法是统一走位置参数。

WPS 的 CommentsThreaded 迭代会死锁。

for x in coll 会卡在类型信息解析。

这是进程挂死级；修法是先取 Count，再按索引访问。

dax.guide 解析器首版，把全部函数误标成 Deprecated。

原因是侧栏筛选的 <option> 被当成了正文标记。

修正解析锚点后才对。

这些坑，不是"看文档"能看出来的。

是"文档 + 实测"才能填平的。

文档漂移检查

还有一件事：文档会漂。

SKILL.md 说 34 篇 references，实际 33 篇；某个脚本没进路由；某个文档引用了不存在的路径。

我写了 check_docs_drift.py：

• references 计数 vs SKILL.md 宣称；
• SKILL.md / 17 号提到的每个脚本与文档必须存在；
• scripts / references 下每个文件必须在 SKILL.md 路由；
• SKILL.md 超 800 行告警。

首跑就抓到 3 项真实漂移：

• SKILL.md 说 34 篇 references，实际 33 篇；
• 某个脚本没进 SKILL.md 路由；
• 某个文档引用了不存在的路径。

这三项，靠人眼很难发现；有了自检，提交前就能拦住。

这不是"洁癖"，是"文档库大了之后，必须有自检"。

五、语料库膨胀：12,407 页、4 个包、55 个脚本、36 篇文档

文档库大了，新问题来了：分发。

12,407 个散页，打包、传输、解压，都是灾难。

所以我做了资源化：

• 12,407 页是什么概念？

不是"一万个文件"，是"一万个可查的知识点"。

• 一个 API 一页：签名、参数、返回值、Remarks；
• 一个枚举一页：成员、数值、适用对象；
• 一个 M 函数一页：语法、示例、分类；
• 一个 DAX 函数一页：语法、版本、兼容性。

这些页面，平时躺在微软的文档站里；AI 要查，得联网、得翻页、得碰运气。

现在，它们在本地，按需取。

12,407 个散页，收进 4 个 resource/*.zip；

• 体积从 18.8MB 降到 11.3MB；
• 分发从"1 万多个文件"变成"4 个包"；
• 用户首跑，一次性解压，约 10 秒；
• 之后全是散文件，全文搜索、Grep、读原文，零复杂度。

这不是"技术炫技"，是"让用户装得下、跑得动"。

现在这套 Skill 的规模是：

• 55 个脚本；
• 36 篇参考文档；
• 13 个 om_* 对象模型语料模块：Range、Sheet、Workbook、Table、Pivot、Chart、CF、Format、Name、Print、Analysis、VBA、DataModel；

每个模块，都是逐函数实跑验证；不是"示例代码"，是"能抄的语料"。

• 390+ 项 corpus 断言，Excel / WPS 双宿主全绿；
• 205 / 199 项 smoke，12 / 12 项 e2e，24 / 24 条 CLI 子命令。

这些数字，不是拿来说"你看我多努力"。

它们能成立，靠的是"渐进式披露"。

• SKILL.md 739 行，只放路由、红线、优先级链；
• 36 篇 references/，按需读，不一次塞进上下文；
• 55 个 scripts/，按需查，命中就抄；
• 12,407 页文档，按需检索，不整库加载；
• profile 默认拆包，主文件只放总览、样本、路由。

AI 不是"一次读完一座图书馆"，是"用到哪层，取哪层"。

这就是 Skill 和"把知识全塞进提示词"的区别。

你可能会说：36 篇文档、55 个脚本，也不算多。

对，单看数量不多。

但它们不是"一次全读"。

SKILL.md 只有 739 行，AI 先读它；需要哪块，再读哪篇；需要哪个函数，再查哪个模块；需要哪个 API，再查哪张卡。

就像你去图书馆，不是把整座馆搬回家，是先看索引，再借你要的那一本。

这才是"大"的正确用法。

塞进去，上下文会爆；按需取，才能又大又轻。

是拿来说：它查得到、跑得通、错不了。

六、为什么不用 MCP：框架决定上限

上一篇，我拆了一个 400+ 函数的 Excel MCP。

这一篇，我可以把话说得更直白：

现在再回头看那 400 多个封装函数，拿望远镜都看不上。

不是数量问题，是框架问题。

MCP 的做法，是"封装函数"：

• 把常见动作封装成 400 多个函数；
• AI 需要什么，就调用对应函数；
• 优点是开箱即用：装上就能用，常见读写、格式、图表都能覆盖；
• 对 80% 的日常需求，它确实够用；
• 缺点是：函数是枚举的，对象模型是组合的。

你不可能把 Excel 的所有组合，提前封装成函数。

透视表 + 切片器 + 条件格式 + 图表 + 数据模型 + 版本差异 + WPS 差异——这些组合是无限的。

400 个函数，覆盖不了。

这不是数量问题，是框架问题。

MCP 的知识，长在"函数"里：加一个能力，就要加一个函数、改一次代码、发一次版。

Skill 的知识，长在"文档 + 语料 + 路由"里：加一个能力，加文档、加语料、加路由，不改框架。

一个是"把知识焊死在代码里"，一个是"把知识放进图书馆，按需取"。

时间越长，差距越大。

所以我没有选 MCP。

我选了 Skill 的渐进式披露：

• SKILL.md 只放路由、红线、优先级链；
• 具体知识，按需读 references/；
• 具体代码，按需查 scripts/om_*；
• 官方原典，按需查 vba-docs/、pq-docs/、dax-docs/；
• 版本差异，按需查版本矩阵、跑 #shared 探针；
• 上下文不塞满，用到哪层取哪层。

这就是"渐进式披露"：不是把一座图书馆塞进 AI 的脑子，是给它一张借书证，再告诉它去哪一排。

Skill 的优势，不只是"知识多"，是"知识能生长"。

• 加 VBA 文档：加 6,250 页，不改一行框架代码；
• 加 PQ 文档：加 770 页，不改一行框架代码；
• 加 DAX 矩阵：加 488 个函数，不改一行框架代码；
• 加版本探针：加一个脚本，接进路由；
• 加新语料：加一个 om_* 模块，跑 corpus，接进索引。

这就是"渐进式披露"的威力：框架稳定，知识可以一直长。

MCP 是"给你一把瑞士军刀"。

Skill 是"给你一座工具图书馆，外加一位知道去哪找的师傅"。

日常拧螺丝，瑞士军刀够用。

但要做"全能专家"，你得有图书馆。

七、Office 三件套：同一套方法，迁移到 Word 和 PPT

这套方法，不只用在 Excel。

同样的框架，我已经迁移到了 Word 和 PPT：

• Excel 专家：4.29，55 个脚本、36 篇文档、VBA/PQ/DAX 全量文档库；
• Word 专家：2.8.0，40 条规则、8 种文种、9 份公文国标细分模板；
• PPT 专家：1.2.1，45 条规则、9 种场合、两套分数。

它们共享同一套骨架，但各有各的"专家层"：

• Excel 的专家层，是对象模型 + VBA/PQ/DAX 文档 + 版本矩阵；
• Word 的专家层，是文种 + 样式 + 公文国标 + 交付清理；
• PPT 的专家层，是九型 + 45 条规则 + 两套分数 + 视觉抽查。

骨架是：

• 先分型：这是什么文种、什么场合、什么工作簿；
• 再对齐：Gate 1 先问清楚，不迎合；
• 再体检：规则、分数、证据；
• 再开方：分档、按顺序、一次一档；
• 再执行：沙箱、快照、回读；
• 再交付：verify、抽检、偏差披露；
• 底层：渐进式披露 + 文档库 + 语料 + 验证。

这不是"抄 Copilot"。

Copilot 是"AI 助手"：你给指令，它生成内容；生成完，你自己判断能不能用。

这套 Skill 是"专家系统"：先问清楚、再分型、再体检、再开方、再执行、再验收；每一步都有证据，每一步都能回滚。

不是"生成一段文字"，是"按标准交付一份作品"。

三件套共享的，不只是骨架，还有边界：

• Windows 专属；
• 先打开文件；
• COM 唯一写通道；
• 写前快照；
• 沙箱第 0 条；
• 不替业务判断。

一套纪律，三件套通用。

这是两件事。

Copilot 有很多值得敬佩的专家，但它的专家，停留在"AI 助手"。

我想做的，是把 Office 三件套的专家判断，提炼成一套可执行、可验证、可交付的 Skill。

现在，这三件套，是真的能打。

而且，它们不是三个孤岛。

Excel 里做好的图表，可以进 PPT；Word 里的报告，可以引用 Excel 的数据；PPT 里的数据，可以回到 Excel 更新。

它们共享同一套"先问、再分型、再体检、再开方"的骨架，所以迁移成本很低。

今天做 Excel，明天做 Word，后天做 PPT，不是从零开始，是同一套方法换一个专家层。

八、边界与门槛：我把丑话说在前面

第一，它仍然是 Windows 专属。

COM 是 Windows 的能力，Mac 上跑不了。

第二，它需要你本机安装 Excel 或 WPS，并且先打开目标工作簿。

它不会自建隐藏实例动你的数据。

第三，它只做"当前打开的工作簿"的实时操作。

批量处理磁盘文件、交付 .xlam / .xll 插件，不是它的活。

第四，文档库很大，但首跑要解压。

12,407 个散页，收在 4 个包里；首跑一次性解压约 10 秒，之后全文可搜。

第五，文档是文档，不是保证。

官方文档也可能漏、也可能错；所以每一条关键写法，都要过实测。你看到的数字，是实测出来的，不是抄出来的。

第六，文档库有版权，也有边界。

VBA 文档来自 MicrosoftDocs/VBA-Docs，CC BY 4.0；PQ / DAX 文档来自 Microsoft Learn。

原典保留署名，页面内容零修改；Skill 只做本地检索，不搬运文字进推文。

第七，它不替你做业务判断。

措辞、标题、口径、哪些数据能用、哪些不能用——这些只给建议，你点头才动。

第八，文档库不是万能。

它解决的是"查得到"，不解决"想清楚"。

一份 PPT 讲什么、一份公文怎么措辞、一张报表怎么解释——这些是业务判断，文档不会替你做。

所以这套 Skill 的 Gate 1，永远是先问，不是先查。

第九，版本是 4.29.0。

55 个脚本、36 篇文档、390+ 项断言、VBA 6,250 页、PQ 770 页、DAX 510 页、4,888 张签名卡、4,788 API × 2 宿主实测。

这些数字不是拿来撑门面的，是拿来证明：它查得到、跑得通、错不了。

九、写在最后：框架很重要

回到那句话：

AI 强不强，不在记忆，在文档。

更准确地说，在文档 + 框架 + 验证。

• 没有文档，AI 只能凭记忆编；
• 没有框架，文档只是一堆文件；
• 没有验证，文档可能把人带进坑里。

这三样，才是"专家"的底子。

所以，别再问"AI 记住了没有"。

要问：它手边有没有文档？有没有路由？有没有验证？

这三样有了，AI 就能从"凭记忆编"，变成"按证据写"。

人也一样。

一个真正的高手，不是"什么都记得"，是"知道去哪查、知道怎么验、知道什么不能做"。

我这套 Skill，做的就是这件事：

把专家的判断，写成路由； 把专家的知识，写成文档； 把专家的经验，写成语料； 把专家的底线，写成红线； 把专家的验证，写成闸门。

这里的"框架"，不是代码框架，是知识框架。

它决定四件事：

• AI 去哪查：路由、索引、文档库；
• AI 怎么用：优先级链、渐进式披露、按需加载；
• AI 怎么验：证据等级、沙箱、corpus、双宿主；
• AI 怎么生长：加文档、加语料、加探针，不改骨架。

框架对了，知识可以一直长；框架错了，知识越多越乱。

400 个封装函数，是一张菜单。

6,250 页 VBA、770 页 PQ、510 页 DAX、4,888 张签名卡、390+ 项断言，是一套能力。

菜单会吃腻，能力会生长。

这就是我为什么没有选 MCP，选了 Skill。

也是我为什么，把同一套方法，迁移到了 Word 和 PPT。

Office 三件套的专家，不在别处。

在我这里，被我一点一点提炼出来了。

我这里说的"专家"，不是一个人，是一套可执行、可验证、可交付的 Skill。

它不是替代专家，是把专家的判断，提炼出来，复制给更多人。

这才是"专家在我这里"的意思。

叫上身边的人，一起来把 AI 编程玩转。

想体验全套免费 Skill？欢迎加好友进入免费社群，关注公众号，后台回复「Skill」，不要理会AI自动回复，等我发联系方式，加好友进群自助获取。