夜雨聆风内容摘要
1、AI Coding 让我开始理解产品如何被搭建，但它并不等于完整的 AI 工作流。
2、非技术人员真正要建立的，不只是工具使用能力，而是工具组合能力和数据流意识。
3、微信读书项目和邮件处理项目，表面不同，底层都指向同一个问题：如何让分散的数据变成可被 AI 理解、调用和复用的知识资产。
（全文约 7300 字，建议阅读时间 19 分钟）
前段时间，我很迷恋 AI Coding。
那种感觉确实很迷人：
一个想法，从一句提示词开始，慢慢变成页面、按钮、数据库、接口，最后变成一个能跑起来的小产品。
对一个非技术背景的人来说，这是一种很强烈的成就感。
因为过去我总觉得，软件开发是技术人员的事情。
前端、后端、数据库、API、服务器、部署、域名、HTTPS……这些词听起来就像一堵墙。
但 AI Coding 让我第一次真正看见：
原来一个产品并不是一个神秘的整体，而是由很多模块组成的系统。
前端负责展示，后端负责处理，数据库负责存储，API 负责连接，服务器负责运行，部署让它被别人访问。
这段经历对我很重要。
它让我不再只是站在产品外面想象技术，而是开始理解一个产品如何被搭起来、跑起来，最后被别人访问和使用。
但最近，我的关注点发生了一些变化。
我不再只迷恋“从 0 到 1 做一个系统”。
我开始越来越关注另一个问题：
AI Coding 之后，非技术人员真正应该继续学习什么？
我现在的答案是：
要学习工具组合能力，也要理解数据流。
因为我慢慢意识到，AI 时代真正改变普通人的，不只是“不会写代码的人也可以写代码”。
更大的变化在于：
很多过去只有技术人员才能完成的事情，正在被大厂和平台封装成工具、Skill、Connector 和 Agent。
非技术人员的机会，正在从“会不会写代码”，转向：
能不能理解目标。
能不能设计流程。
能不能组合工具。
能不能让数据在不同系统之间流动起来。
这篇文章，我想用自己真实探索过的两个项目来讲这件事。
一个是微信读书项目。
一个是邮件处理项目。
它们看起来完全不同，但底层都指向同一个问题：
我的数据，如何从分散的系统里流动出来，变成可以被 AI 理解、调用和复用的个人知识资产？
01
AI Coding 很重要。
尤其是对非技术背景的人来说，它的价值不只是“帮我写代码”。
更重要的是，它让我们第一次有机会接近软件产品的真实结构。
过去，我看到一个网页或者一个工具，只能看到表面的功能：
这个页面能不能点？
这个按钮有没有反应？
这个表单能不能提交？
这个系统好不好用？
但经过 AI Coding 的实践后，我开始理解：
一个产品背后其实有不同层次。
页面是前端。
逻辑是后端。
数据要存进数据库。
系统之间要通过 API 连接。
产品要部署到服务器或云平台上，用户才能访问。
这些概念过去听起来很遥远，但在真实实践中，它们开始变得具体。
AI Coding 让我知道，一个产品并不是凭空出现的。
它是由很多模块组成，并且通过一套流程被组织起来的。
这一点对非技术人员很重要。
因为当我们理解了前端、后端、数据库、API、云服务和部署，就能更准确地向 AI 提需求，也能更清楚地判断一个产品问题到底卡在哪里。
但 AI Coding 也有它没有解决的问题。
它主要解决的是：
如何从 0 到 1 搭建一个系统。
而真实工作里，很多问题不是搭出一个系统就结束了。
真正复杂的问题往往是：
已有数据在哪里？
这些数据如何进入系统？
AI 如何理解这些数据？
处理后的结果放在哪里？
后续能不能持续复用？
整个流程能不能长期运行？
这就是 AI Coding 和 AI 工作流之间的区别。
AI Coding 让非技术人员理解产品如何被搭建；工具组合能力则决定这些产品能力能不能进入真实工作流。
举个简单的例子：
如果我要做一个个人知识库，做出一个页面并不难。
真正难的是：
我的阅读记录从哪里来？
我的邮件信息从哪里来？
我的网页收藏能不能归档？
我的文件资料能不能被解析？
这些信息如何被 AI 理解？
最后如何沉淀成可搜索、可分析、可复用的知识资产？
所以我现在越来越觉得：
AI Coding 是入口，但不是终点。
它帮我跨过了“看不懂技术”的第一道门槛。但下一步，更重要的是理解数据流、工具边界和系统组合。
02
在我现在的理解里，AI 时代的工具组合能力，不是简单地“会用很多工具”。
它更像是一种系统设计能力。
工具组合能力，是指围绕一个真实目标，把不同平台、数据源、AI 能力和存储工具连接起来，形成可持续工作流的能力。
比如：
你不只是会用 ChatGPT、Coze、Supabase、GitHub。
你还要知道：
它们分别处在数据流的哪个位置。
它们适合承担什么角色。
它们之间能不能连接。
它们组合之后，能不能解决一个真实问题。
所以，AI 时代的工具组合能力，本质上不是“工具清单”。
而是：
围绕目标，设计数据如何进入、如何处理、如何沉淀、如何再次被调用。
以前我看到一个工具，会问：
这个工具有什么功能？
现在我更愿意问：
这个工具能连接什么数据？
能不能被 AI 调用？
能不能输出结构化结果？
能不能写入我的知识库或数据库？
它在整个工作流里处于哪个位置？
这种问题的变化，说明我已经不再只是从功能角度看工具，而是开始从系统角度看工具。
这也是我最近非常明显的认知变化。
我不再只关心“工具能不能用”。
我更关心：数据能不能流动。
03
我在微信读书里加书，通常不是随便收藏。
很多时候，是因为我正在关注一个具体问题。
比如最近我关注软件工程、计算机基础、系统架构、AI 产品开发，我就会在微信读书里搜索相关关键词，然后从返回的书单里筛选，看哪些书和我正在思考的问题有关。
这其实是一种问题导向的阅读方式。
我不是为了把书架填满，而是希望每一本书都能回答我当下的某个问题。
但问题也随之出现了。
人的时间总是有限的，而问题又会在学习和反思中不断冒出来。
于是，书架里的书越积越多。
虽然阅读没有停止，但我经常会忘记：
这本书是什么时候加入书架的？
当时为什么加它？
它对应的是我哪个问题？
我后来有没有读？
读完之后有没有留下笔记、评论和收获？
所以，我真正想解决的，不只是“记录书单”。
而是三个层面的问题：
换句话说，我不是在收藏书。
我是在围绕一个个真实问题，建立自己的知识资产。
如何把微信读书里的书架、阅读记录、笔记和评论，转化为 AI 可以理解和调用的个人知识库？
于是，我开始了微信读书项目的探索。
最早的时候，我在 GitHub 上搜索过微信读书相关项目。
当时看到一些方案，是通过获取 Cookies，模拟登录微信读书网页版，再使用第三方脚本批量获取书架、笔记、阅读记录等数据。
大致路径是这样的：
从技术角度看，这个方案当然很酷。
但对非技术人员来说，它并不轻松。
它涉及 Cookies、脚本运行、环境配置、数据清洗，而且 Cookies 并不稳定，需要定期更新。
我当时也跟着一步步模仿，但整个过程并不顺滑。
数据明明是我的，但要把它取出来，却像是在翻一座技术围墙。
这也是很多非技术人员在做个人自动化、个人知识库、数据分析时都会遇到的问题。
不是没有需求。
不是没有想法。
而是卡在了“连接数据”的第一步。
个人知识库的第一道难题，往往不是整理知识，而是连接数据。
后来，我开始使用飞书多维表格。
飞书多维表格里有字段捷径，也有识图能力。
于是我设计了一个更轻的方案：
这个方案比 Cookies + 脚本轻很多。
我不再需要折腾 Cookies，也不需要运行第三方脚本。
只要把感兴趣的书籍封面通过表单提交，多维表格就能提取出书名和作者。
但新的问题是，这个交互仍然不够顺手。
每次都要打开飞书、点开链接、上传封面、提交表单。
刚开始还能坚持，时间久了，就会慢慢停下来。
工具能用，不代表流程能坚持。真正好的工作流，必须足够顺手。
很多自动化项目失败，不是因为逻辑不成立。
而是因为它太麻烦。
只要一个流程每次都要人多做几步，它就很难长期运行。
再后来，我开始使用扣子。
扣子的变化在于，我可以直接把书籍封面发给智能体。
因为扣子已经获得了我飞书多维表格的权限，所以它可以完成一整套动作：
这一阶段的体验明显变好了。
因为我不再只是把信息填进表格，而是在和 AI 对话。
AI 不仅能识别封面里的文字，还能联网搜索、补全背景信息，并结合我的关注方向给出推荐理由。
AI 不只是帮我录入信息，而是开始理解信息、补全上下文，并解释它为什么对我有价值。
但它仍然有局限。
扣子解决的是“这本书是什么”，但还没有解决“我和这本书发生了什么”。
也就是说，它可以帮我把一本新书录入数据库，但无法实时更新我的阅读状态、阅读进度、评论和收获。
这些仍然需要我手动维护。
AI 帮我解决了“这本书是什么”，但还没解决“我和这本书发生了什么”。
到了现在，微信读书官方 Skill 出现后，事情又发生了变化。
通过在终端安装，不管是在 ima 还是扣子等环境里，都可以直接调用微信读书的数据。
它可以获取我的书单、阅读进度、最新加入书架的情况等信息。
这意味着什么？
过去我需要：
手动截图↓上传封面↓AI 识别↓写入表格↓手动维护阅读状态现在可以变成：
对话调用↓直接获取微信读书数据↓查看书架、书单、阅读进度↓基于真实数据做分析这是体验上的真正跃迁。
因为数据获取不再依赖我手动搬运，而是通过官方能力直接调用。
当平台把数据接口、权限认证和调用能力封装成 Skill，非技术人员就不再需要从底层重新造桥。
我们可以把更多注意力放在这些问题上：
这些数据要怎么用？
要怎么分析？
要怎么沉淀？
要怎么转化成内容、复盘和决策？
非技术人员的机会，不是绕开技术，而是站在被封装好的技术能力之上，重新组合工具。
04
第二个项目，是邮件处理。
我的邮箱里有三类长期需要处理的信息。
第一类，是工作邮箱里的工资单邮件。工资单目前是以图片形式呈现的。我希望从图片中提取自己关注的数据，比如工资、社保、公积金、个税、实发金额等，并沉淀到自己的数据库中。
第二类，是 Google 邮箱里的海外高质量信源。我关注了一些国外的 newsletter 和文章推送，但里面经常夹杂低质量营销信息。我希望系统能够自动识别、排序和筛选，判断哪些邮件和我近期关注的话题相关，并给出推荐理由，同时剔除低价值信息。
第三类，是 163 邮箱里的股票账号对账单。这类邮件通常以附件形式呈现。我希望从附件中提取持仓、交易、资金变动、收益情况等关键数据，并沉淀到自己的数据库中，用于后续投资复盘和风险管理。
所以，我真正想做的不是“收邮件”。
我真正想做的是：
邮件表面上是消息。
但从个人知识资产的角度看，它其实是一个长期被低估的数据入口。
AI 邮件自动化的核心价值，不只是自动收取邮件，而是将邮件正文、图片和附件中的关键信息提取出来，转化为可分析、可检索、可复用的结构化数据。
最早的时候，我尝试过用影刀这类 RPA 工具来手动获取邮件。
也想过从 0 到 1 搭一个系统，通过 POP3 或 IMAP 协议获取邮件。
当时我的想法很直接：
既然邮件在邮箱里，那我能不能通过协议把它读出来？
但实际做起来就发现，事情没有这么简单。
邮箱涉及鉴权、安全设置、授权码、协议配置。
即使拿到了邮件，后面还要处理图片、附件、字段提取、分类判断和数据库写入。
大致链路是这样的：
这条链路非常长。
任何一个环节出问题，整个流程就跑不通。
我原本以为难点是“读邮件”，后来发现真正难的是：安全地拿到邮件、理解邮件、筛选邮件，再把它变成可用的数据。
表面上看是一个小需求，背后却牵涉数据连接、权限认证、内容解析、结构化处理和后续存储。
最近，扣子上线了邮箱功能。
这个变化对我来说非常关键。
现在我可以把收到的邮件自动转发到扣子的专属邮箱，再让扣子按照我的要求进行处理和分析。
路径变成了：
这和早期方案最大的不同是：
我不再需要从底层协议强行连接邮箱，而是把邮件变成了一个可以被 AI 接收和处理的输入流。
AI 可以先帮我判断：
哪些邮件重要？
哪些邮件可以忽略？
哪些字段需要提取？
哪些信息值得进入我的个人数据库？
哪些内容可以作为未来选题、研究材料或投资复盘依据？
这一步非常重要。
因为它让 AI 从“回答问题的工具”，变成了“信息进入系统前的第一道筛选器”。
我越来越觉得，未来很多人的个人知识库，不一定是从手动整理开始的。
它可能从每一个入口开始：
阅读入口。
邮件入口。
聊天入口。
网页入口。
文件入口。
数据库入口。
AI 的价值，就是在信息进入个人系统之前，先帮我们完成识别、筛选、解释和结构化。
05
微信读书项目和邮件项目，看起来完全不同。
一个关于阅读。
一个关于邮件。
但它们背后的结构高度一致：
微信读书项目解决的是：
我主动选择的信息，如何沉淀成知识资产。
邮件处理项目解决的是：
外部推送给我的信息，如何经过 AI 筛选后进入个人系统。
一个是主动输入。
一个是被动输入。
但最终都指向同一个目标：让分散在不同系统里的数据，变成可以被 AI 理解、调用和复用的个人资产。
如果把这两个案例抽象成一个通用模型，我会这样理解：
这张表让我更清楚地看到：
所谓 AI 工作流，不是把一个工具用得很熟。
而是让每一个工具在数据流里有明确位置。
这也是为什么我现在不再只迷恋 AI Coding。
AI Coding 很重要。
它让我理解一个产品如何跑起来，也让我看懂前端、后端、API、数据库、云服务这些概念。
但现在我越来越意识到：真正改变工作方式的，不只是从零写出一个系统，而是让不同系统之间的数据开始流动。
06
很多非技术人员一听到“数据流”，可能会觉得这是技术人员才需要理解的概念。
但我现在越来越觉得，恰恰相反。
在 AI 时代，非技术人员更需要理解数据流。
因为 AI 要发挥作用，必须先接触到合适的信息。
如果信息只停留在聊天记录里、邮件里、书架里、网页收藏里、文件夹里，AI 就很难持续调用它们。
只有当数据能够被连接、读取、理解、结构化和存储，它才可能变成长期资产。
数据流并不是一个冰冷的技术概念。对普通人来说，它可以理解为：你的信息从哪里来，经过什么处理，最后沉淀到哪里，并在未来如何再次被调用。
比如：
一本书从微信读书书架进入知识库。
一封邮件从邮箱进入 AI 筛选流程。
一篇 newsletter 从收件箱变成选题素材。
一份对账单从附件变成投资复盘数据。
一段阅读笔记从碎片记录变成公众号文章素材。
这些都是数据流。
理解数据流，不是为了让非技术人员变成程序员。
而是为了让我们更清楚地知道：
AI 到底可以在哪一步帮我们。
工具应该在哪一步接入。
数据应该在哪一步沉淀。
最后如何形成真正可持续的个人系统。
回头看这段探索，我最大的成长，不是学会了某个工具。
而是从功能视角，走向了系统视角。
过去我看到一个工具，会问：
它有什么功能？
它能不能帮我完成某件事？
现在我会问：
它能连接哪个数据源？
它能不能被 AI 调用？
它能不能输出结构化结果？
它能不能写入我的数据库？
它在整个工作流里处于哪个位置？
它能不能和其他工具组合起来？
这就是我最近最明显的变化。
我不再只关心“工具能不能用”。
而是关心“数据能不能流动”。
我不再只关心“能不能从 0 到 1 做出一个系统”。
而是关心“能不能用已有能力组合出一个可持续的工作流”。
AI Coding 让我理解“产品如何被搭建”。而工具组合能力让我开始理解“AI 如何进入真实工作流”。
这两者不是替代关系，而是递进关系。
07
这一年持续探索下来，我越来越觉得：
未来也属于那些能够理解业务目标、驾驭 AI、组合工具，并让数据在不同系统之间流动起来的人。
这不是说代码不重要。
恰恰相反，正是因为我经历过 AI Coding，理解过前端、后端、API、数据库、部署和云服务，才更明白：
技术不是目的。
工具组合只是手段。
真正重要的是，我们能不能让信息进入系统、被理解、被沉淀、被调用，并最终产生新的价值。
对我来说，微信读书项目和邮件处理项目，都还没有结束。
它们只是两个入口。
一个入口通向阅读和知识。
一个入口通向邮件和信息。
但它们共同指向一个更大的方向：
建立一个属于自己的、AI 可理解、可调用、可持续进化的个人知识资产系统。
这也是我理解的 AI 原生进化论：
不是让 AI 替我们做所有事。
而是让 AI 帮我们重新组织信息、工具、流程和自己。
