夜雨聆风接手新项目，飞书云文档里躺着上百份技术文档。以前要花一周翻完，这次我让WorkBuddy连上飞书，半小时就搞定了。
上周三下午，组长找到我。
说另外那个项目要加人，你下周开始跟。
我当时还挺高兴。毕竟是核心产品线，能参与进来是好事。
然后他发给我一个飞书链接。
我点开一看，云文档里整整齐齐摆着上百份文档。开发规范、架构设计、接口文档、部署手册、踩坑记录、代码review标准、数据库设计、安全方案，光是目录就翻了好几屏。
我当时心里就咯噔了一下。
说实话，接手新项目最痛苦的不是写代码。
是看文档。
你不知道哪份文档是最新的，哪份已经过时了。你不知道哪些规则是必须遵守的，哪些只是建议。你不知道前人踩过什么坑，哪些设计是刻意为之的，哪些是历史遗留没人敢动。
每一份文档都得打开看一遍。看完还不一定记得住。
我以前接过一个项目，光读文档就花了一周。读完之后发现有些文档是两年前的，里面写的方案早就推翻重做了。
这次我不想再来一遍。
我寻思了一下，WorkBuddy不是能连飞书吗。
之前用它做PPT的时候我就注意到，它的连接器列表里有飞书。但当时没试，因为用不上。
现在用上了。
我打开WorkBuddy，找到连接器，点飞书，授权登录。
整个过程比我想的简单。没有复杂的配置，按照默认配置授权即可，只是需要企业管理员审批。
连上之后，WorkBuddy能看到飞书云文档里的所有文件夹和文档。
我盯着那个文档列表看了一会儿。
上百份文档，如果一份一份打开看，每份平均花5分钟，那就是8个小时。还不算来回切换、做笔记的时间。
我跟WorkBuddy说了一句话。帮我把这个项目文件夹下所有的开发规范、技术文档和经验总结都读一遍，给我整理出一份上手指南。
然后它就开始读了。
我没有一份一份地指定文档，就让它自己遍历整个文件夹。
它先是把所有文档的标题列了出来，大概分了几类。开发规范类的、架构设计类的、部署运维类的、接口文档类的、经验总结类的。
然后它开始逐份读取。
我能看到它在后台一份一份地打开文档，提取内容。这个过程大概持续了十几分钟。
说实话等待的时候我有点焦虑。不是焦虑它能不能读懂，是焦虑它读完之后给我的东西到底有没有用。以前用别的AI工具总结文档，经常是给你一大段正确的废话，看着什么都说了，其实什么都没说。
十几分钟后，它给我出了一份东西。
我打开看了一下。
它给的不是一份简单的文档摘要。
是一份完整的上手指南。
开头是是开发规范部分。它把散落在五六份文档里的规则整合到了一起，分成了几个板块。
代码规范方面，后端用的竟然是Go，不是我以为的Java。有一套团队统一编码规范，服务组件也分了层，公共服务、任务执行、算法服务、网关、实验管理、资源管理、认证服务，七个微服务各管一摊。前端用的Qiankun微前端架构，Main UI、RBAC UI、Chaos UI、CMDB UI四个子应用，Vue加Element UI，JavaScript。
版本管理方面，文档里标了v4.0和v4.1两个大版本的迭代规划。每个版本有自己的项目设计文档、WBS计划、自测问题集，甚至还有发布会记录。提交信息倒没有硬性规定编号，但版本发布前的评审流程写得很详细。
数据存储方面，这个项目不只是用MySQL。InfluxDB存时序监控数据，Redis做缓存，MinIO存对象，Elasticsearch做日志搜索，RabbitMQ负责消息队列。七种存储各司其职，文档里把什么数据放哪个库说得挺清楚，但分布在四五个文档里。
这些信息我在飞书上翻了半天都没翻全，因为它分散在不同文档的不同章节里。WorkBuddy把它们全捞了出来，放在了一起。
顺着上面的再聊聊。
它让我印象最深的不是开发规范，是经验总结那部分。
项目文件夹里有一个子目录叫「踩坑记录」，里面是团队成员平时踩坑后写下的备忘。我之前最怕看这种东西，因为每个人的写法不一样，有人写得很详细，有人就写一句话，排版也乱七八糟。
WorkBuddy把这些全都读了，然后整理出了一份「常见问题与避坑指南」。
比如Nacos作为微服务注册中心，在Pod环境部署时配置刷新会偶发失败。这个坑的解决方案是加一个重试机制，写在了一份不起眼的运维备忘录里。
比如新增原子故障的时候，chaos_library和chaos_script两张表都可能配参数的默认值。如果你两张表都配了，而且值不一致，前端展示会出bug。这个问题在一份叫「故障开发避坑」的文档里写了，但标题取得太模糊，不搜"避坑"两个字根本找不到。
比如chaos-daemon在执行故障注入时，如果目标Pod刚好被重启了，labels还没就绪，注入会静默失败，错误信息也不明确。这个坑记录在一份只有几行字的流水账里，藏在一个叫「运维记录」的文件夹深处。
这些零散的经验，WorkBuddy全都捞出来了，按类型整理好了。
坦率的讲，这些东西比开发规范更重要。开发规范你可以慢慢学，但踩坑记录是前人用血泪换来的，能帮你省掉大量调试时间。
还有一个让我觉得有点意思的地方。
它不光整理了规则和经验，还帮我做了一件事，把架构设计文档里的关键信息抽出来，画了一张系统的全景图。
不是真的画了一张图，是用文字描述了整个系统的架构层次。
四层架构。最上面是前端层，Qiankun微前端加Vue加Element UI。往下是API层，Restful加WebSocket，跟Kubernetes CRD交互。再往下是应用层，LoadBalancer、Nginx、Ingress、VIP、K8s Service，流量接入和负载均衡都在这一层。最下面是基础设施层，MySQL、RabbitMQ、InfluxDB、Redis、MinIO、Prometheus、Elasticsearch，七种存储和监控组件，加上Nacos做注册中心。
他还把核心服务组件一个个拆了出来。istorm-chaos-operator是Portal端跟K8s集群的沟通枢纽，管资源的CRUD和监听。chaos-agent-operator在Agent端监听ChaosEngine这个CRD，负责发起创建、恢复、终止实验。chaos-daemon是故障注入的真正执行者，以DaemonSet方式部署，每个节点上跑一个。还有一个workflow-controller，基于Argo控制整个实验流程，注入和恢复各走一个Pod。
这个信息在架构设计文档里都有，但那份文档写了四层架构加七个核心组件的交互关系，我翻到CRD和Operator那部分就被绕晕了。
但我得说一个让我不太满意的地方。
它读接口文档的时候，整理出来的东西有点鸡肋。
接口文档本身就有格式化的结构，请求方法、URL、参数、返回值，已经很清晰了。WorkBuddy把它重新整理了一遍，但说实话没有比原文好多少，甚至还丢了一些细节。
比如有个接口的返回值里有个嵌套对象，原文档里有完整的字段说明，但WorkBuddy在整理的时候把这个嵌套对象简化成了一行描述。如果你要对接这个接口，还是得回去看原文档。
这让我意识到一个事。AI整理文档的价值，跟文档本身的质量有很大关系。
如果是那种散乱的、写法不统一的、信息分散在多份文档里的内容，AI整理的价值很大，因为它能帮你从一堆乱麻里抽出线索。
但如果是本身就结构清晰的文档，比如接口文档、API文档，AI整理的边际收益就很小。这种文档你直接看原文反而更快。
做完这件事之后，我回头想了一下整个过程。
以前接手新项目，最耗时间的环节不是写代码，是建立对项目的整体认知。你得知道这个项目的规矩是什么，架构长什么样，前人踩过什么坑，哪些东西能动哪些不能动。
这些信息都在文档里，但文档是人写的，人写东西不会按你需要的顺序来。开发规范可能放在三份不同的文档里，踩坑记录可能藏在某个角落的备忘录里，架构设计可能是一份60页的长文。
你要做的事情，其实就是在几十份文档里找到你需要的那部分信息，然后串成一份你能用的知识。
这恰恰是AI最擅长的事。它不会替你写代码，不会替你做架构决策，但它能帮你把散落在各处的信息捞起来，按你需要的方式摆好。
回到最开始那个问题。
接手新项目，文档太多看不完怎么办。
我以前的答案是硬看。花一周时间，一份一份翻，做笔记，画思维导图。
现在我多了一个选项。让AI连上飞书，把所有文档读一遍，给你出一份上手指南。你拿着这份指南，知道去哪找什么，知道什么该注意什么可以跳过，然后再有针对性地去看原文档。
不是AI替你读文档，是AI帮你先过一遍筛子。
这个区别很重要。过完筛子之后，你还是得自己读原文。但你读的时候心里有底了，知道这份文档在讲什么，在整个项目里处于什么位置，哪些部分跟你手头的任务相关。
而不是像以前一样，打开一份60页的架构文档，从头开始翻，翻了20页还不知道自己在哪。
说到这个我想多聊两句。
很多人对AI辅助工作的理解还停留在「让AI帮我干活」这个层面。让它帮我写代码，帮我做PPT，帮我写文档。
但这次的经历让我觉得，AI最被低估的能力其实是「帮你快速建立认知」。
进入一个新领域、新项目、新团队，最痛苦的不是做事，是你不知道你不知道什么。你不知道有哪些规矩，不知道有哪些坑，不知道前人已经解决了哪些问题。
这些信息不是秘密，都在文档里，在聊天记录里，在某个人的脑子里。但它们是分散的，是无序的，是不为你准备的。
AI能做的事情，就是把这些分散的、无序的信息，临时为你整理成一份有序的、你能用的知识。
这跟「帮你干活」不一样。帮你干活是替代你做事，帮你建立认知是让你做事的时候不再两眼一抹黑。
后者可能比前者更有价值。
最后说一点实操层面的感受。
WorkBuddy连飞书这个功能，适合的场景很明确。就是你需要在短时间内了解大量已有文档的内容，而且这些文档分散在多个文件夹里。
如果你只需要看某一两份文档，直接打开看就行，没必要绕一圈让AI帮你读。
但如果你接手新项目、做技术调研、或者需要对某个领域做系统性的了解，这个功能的效率优势就出来了。几十份文档扔给它，它十几分钟读完，给你一份整理好的指南。你自己翻，可能要一周。
另外有一点要注意。AI给你的整理结果，是帮你快速建立全局认知用的，不是让你拿去当唯一依据的。具体到某一条规范、某一个接口、某一步部署操作，还是要回去看原文档。AI会遗漏细节，尤其在处理格式化文档的时候。
把它当成一个帮你快速过筛子的助手，而不是一个替你读文档的替代品，你就能把它的价值最大化。
觉得有用的话，帮忙三连支持一下：
👍点赞— 让更多人看到这篇实测
⭐在看— 你的"在看"是我持续更新的动力
🔁转发— 分享给身边也在用AI工具提效的朋友
你的每一次互动，都是我继续写下去的动力。感谢支持！❤️
