钉钉核心AI项目负责人离职了，我连一个文档都复制不了

最近有篇文章在科技圈刷屏了——《置身钉内》。

钉钉核心AI项目"ONE"的产品负责人，在钉钉干了300多天，亲历了这个战略级产品从0到1、从巅峰到收缩的全过程。最近离职了，写了篇万字长文，把钉钉内部的决策逻辑、组织文化、产品哲学扒了个底朝天。

文章写得很深，很真诚。我看完最大的感受是：原来钉钉内部也知道问题在哪。

但更让我耿耿于怀的，是另一件小事。

就在读完《置身钉内》的同一天，一个朋友给我发了个钉钉文档链接。"帮我把这个文档内容提取出来，我要二次加工。"

我说30秒搞定。

然后我折腾了3个小时。

你是访客，你不是人

事情是这样的。

朋友分享了一个钉钉文档给我。链接打开，文档正常显示，内容完整，3000多字。课程大纲、痛点分析、模块设计，写得明明白白。

我想复制。发现不行。

想导出。没这个按钮。

想下载。没这个选项。

我看了看自己的身份——「访客」。

对，我能看，但不能碰。就像博物馆里的展品。隔着玻璃，清清楚楚，但你摸不到。

这让我想起《置身钉内》里写的那个细节：钉钉的产品哲学是「站在发信人一侧」。翻译成大白话——谁有权限谁说了算，接收方、被分享方、访客……你的感受不重要。

产品经理在文章里写得很诚恳："钉钉早年的胜利，给无招留下了一套很深的身体记忆——站在发信人一侧，替组织争取确定性。"

好吧。但我是那个「收到消息」的人啊。发信人分享给我了，我也有正经需求，为什么非要让我这么费劲？

四扇门，全锁着

我有命令行工具。钉钉官方的 dws，配得好好的。

第一条命令，读文档。

"操作者对该文档没有下载权限。"

换下载。

"在线文档不支持直接下载。"

换导出。

这个命令不存在。

换读段落。

"没有权限。"

四扇门，全锁着。

工具链是齐的。身份认证是过的。组织也切对了。但就因为你是访客，API层面一扇门都不给你开。

你不禁要想：不会是钉钉核心项目的负责人都跑去写离职回忆录了，没人做权限设计吧？访客能看不能拿，这个场景钉钉的产品团队自己没遇到过吗？

拿到了一半，还剩一半

API走不通，走浏览器。

我用工具抓取页面的HTML。先抓到的是个空壳——正文在iframe里。找到iframe地址，再抓，拿到了。

3452字节。课程标题、设计逻辑、痛点分析，看着挺全的。

但朋友说不对。"课程包呢？五层课程体系呢？行业定制方案呢？"

我一看……页面只渲染了首屏。你往下翻，新内容才会加载。不翻，它就不生成。

网页已经不是当年的网页了。十年前的网页，服务器把整篇文章都塞进HTML，你看不看是你的自由。现在的网页，你要看什么，它才生成什么。剩下的，藏在虚空里。

剩下2700个字去哪了

那我写脚本。用自动化工具操控浏览器，一页一页往下翻，翻到哪抓到哪。

这个过程极其痛苦。

插件干扰，抓到的是插件侧边栏的文案。重来。翻页时机不对，抓到的永远是同一段内容。重来。

最离谱的是——页面右下角写着"字数 3434"，但我不管怎么翻、怎么等，用尽各种方法，永远只能拿到735个字符。

字是存在的，但它不在HTML里，不在代码里，不在你能摸到的任何地方。它就在屏幕上，像一张贴纸。

我用了React组件树遍历、文本节点动态拦截、DOM属性钩子……黑魔法往上堆，13万字符抓回来了。

全是混淆后的JavaScript代码。

三个小时过去了。

一行代码

就在我准备截图、用OCR识别——最原始的办法——的时候，突然灵光一闪。

渲染引擎是根据窗口大小决定渲染多少内容的。窗口多大，它就渲染多少。那把窗口拉大不就行了？

我把浏览器窗口的高度从900改成了5000。

就一行配置：

viewport: { height: 5000 }

然后重新提取。

4228个字符。五个章节，十六个模块，四个课程包，六个行业方案。

全拿到了。

我盯着屏幕愣了好一会儿。

三个小时。CLI、API、浏览器抓取、DOM拦截、组件树遍历。最后的解决方案，一行代码。

为什么这一行能work

道理很简单。

钉钉文档的编辑器像个勤快人——你只看这一屏，它就只渲染这一屏。窗口高900，就给你900的内容。窗口高5000，它就老老实实给你5000的内容。

写代码的人管这叫"懒加载"。为了省资源，也为了让大文档打开更快。出发点没毛病。

但作为一个访客，你想拿到完整内容，就得知道这扇后门的存在。正常人不会把浏览器窗口拉成五米高，所以没人知道这扇门在哪。

等等，我得说一句不该省略的话

写到这儿，我意识到自己漏掉了一个很重要的问题。

这篇文章的语调，从一开始就是——"我需要，所以我应该能拿。"

但这个文档不是我写的。它是我的AI导师谷燕燕老师，花了心血整理出来的课程体系。她是伯谷金人才科技的创始人，文档里写的每一层课程逻辑、每一个痛点映射、每一个模块设计，都是她的劳动成果。

她把我设成"访客"，不是手滑，也不是产品默认，更不可能只是还没来得及问我需不需要编辑权限，按惯例，她是通过申请权限来看我们究竟有没有认真看过并想真用起来。不管哪种情况，"她没有给我权限"不等于"我可以自己动手拿"。

我爱折腾的性子一来，就干开了，最后我拿回来了。技术上解决了。但拿回来之后呢？

那位老师说她想分享这套课程框架，让更多人借鉴。如果我能拿到编辑权限、正式引用、署名致谢，这篇文章的结尾会完全不一样——它不会是一个"黑客"炫耀他破解了什么，而是一次正常的、体面的知识协作。

所以这里得把话说清楚。

这个方案，只应该在下面这些场景里用：

以下场景，不要用：

技术的边界不是你"能不能做到"。是你"该不该做"。

工具的说明书上不会写这个。但我应该写。

其实最简单的办法，是问一句

我折腾了三个小时。最后发现，如果在打开文档的那一刻，我不是开始敲命令，而是给谷燕燕发一条消息——

"谷老师，这个大纲对我很有启发，能给我开一下复制权限吗？我想引用来做课程设计的参照。"

可能三分钟就解决了。

这不是马后炮。这是我的一个真实反思。《置身钉内》里面有一段话我觉得放在这里特别合适：

"一个产品经理最难摆脱的，往往不是失败，而是成功。因为失败会留下伤口，而成功会留下手感。"

我想加一句——一个技术人最难摆脱的，也不是失败，而是「我能搞定」的惯性。遇到障碍，第一反应是绕过去、破解掉、攻克它。而不是停下来想一想：这个障碍，是不是它本来就应该在那里？

有些人设成访客，是没注意。有些人设成访客，是有意的。不管哪种，先问一句，比先破解要省事——也更体面。

这个方案不完美。它也不应该是你第一个选项

技术上，文档太长窗口得拉更高。不同排版密度得多试几次。提取出来的文本没有格式，换行、缩进、列表全丢，得手动整理。

但更大的不完美是——它跳过了人与人之间最基本的沟通。

所以把这个方案放在这，不是鼓励你去绕权限。是告诉你，如果你真的到了需要这一步的时候（比如自己的文档被锁了），有这么一条路。

但它永远应该是你的最后一个选项，不是第一个。

脚本给你

完整的提取脚本，一个文件，几十行代码。改一下文档URL就能跑。

关注公众号回复「钉钉提取」，我把脚本发你。

写在最后

《置身钉内》里，作者写了一句我反复想了很多遍的话：

"凡历术在于常数，而不在于变行。"编订历法，需要归纳规律性的常数，而不在于一味记载关注短期变化。

这篇文章讲的是一个"变行"——我花了3个小时搞定了某个技术问题。但它背后的"常数"，我觉得是这样的：

技术能解决很多问题，但技术不能替你做人。

先问一句，再动手。先要授权，再引用。先尊重创作者，再谈效率。

这跟钉钉做得好不好、访客权限设计得合不合理，没有关系。

这是你自己决定要成为什么样的人。

你遇到过类似的经历吗？因为"能搞定"而跳过了"该问一下"？

或者你也有一个想引用、想学习、想二次创作的文档，但不知道怎么开口？

评论区聊聊。

关注公众号回复「钉钉提取」，我把脚本发你。也给你准备了一份「引用请求的话术模板」，让你开口的时候不尴尬。