我们为什么做 AI-My-Chats：用 AI 沉淀企业碎片化知识的实践

先说一个数字：我们这支 20 多人的团队，每个月用 AI-My-Chats 处理 100 多条碎片化知识，模型成本只要约 5 美元。这篇文章讲的，就是这背后的思考。

一、为什么要做这件事

企业知识沉淀的思考

最近，我在 Reddit 上分享了 AI-My-Chats 的使用思路。很多用户对此很有共鸣，也提出了两个很实际的问题。

第一个问题是，企业每天都会在邮件、即时通信、会议记录和项目讨论中产生大量有价值的信息，包括文字、截图、日志、附件和临时判断，但真正被整理进项目管理系统或知识库的内容很少。

企业并不是没有知识，而是信息进入知识体系的摩擦太大。重新阅读上下文、提炼重点、整理格式，再写入相应系统，需要持续投入大量人工。很多信息不是没有价值，而是整理成本太高，最终只能散落在不同工具和个人手中。

第二个问题是数据敏感性。如果这些内容涉及企业内部项目、技术细节和业务数据，是否适合交给 OpenAI、Anthropic 等外部模型服务处理？

这个担忧完全合理，也是 AI-My-Chats 重点回应的问题。

AI-My-Chats 不会自动读取全部聊天内容，而是由用户主动选择值得沉淀的信息，再由系统结合上下文完成整理。在模型层面，AI-My-Chats 也不绑定单一厂商。企业可以根据效果、成本和数据安全要求，选择商业模型、开源模型，也可以接入部署在本地或私有云中的模型。

目前，我们主要使用 DeepSeek V4 Pro 处理文本理解与总结，使用千问 3.6 Pro 处理图片和上下文。这只是我们当前使用的模型组合，并不是产品的固定限制。

AI-My-Chats 背后的开源项目 Devify 已经集成了可配置的模型接入能力。企业更换模型时，不需要重新设计整个 Workflow。

Gartner 在《Token Costs Escalate and AI Sovereignty Concerns》（G00852160）中提到，“Where AI runs is becoming as important as what AI can do”——AI 部署在哪里，正在变得和 AI 能做什么同样重要。该报告援引的 2026 年 CEO 调查显示，70% 的 CEO 认为技术主权是执行委员会共同关注的议题，90% 的 CEO 正在为此加大地理战略投资。随着开源模型和私有化部署能力逐渐成熟，模型选择权和数据控制权会成为企业 AI 基础设施的重要组成部分。

我们想解决的，就是在企业掌握数据、模型和处理流程的前提下，降低信息沉淀为知识的成本，把零散内容转化为可追踪、可执行、可复用的企业知识。

从快速响应到知识沉淀

OneProCloud 主要从事云原生迁移和云原生灾备业务，服务以海外市场为主，也包括一部分国内客户。

我们的云迁移产品是 HyperMotion，云灾备产品是 HyperBDR。目前，两款产品已经适配国内外主流公有云和私有云平台，基本覆盖企业常见的异构云环境。

HyperMotion 和 HyperBDR 强调简单、高效和高度自动化。以主机迁移和灾备为例，用户不需要提前在目标云上手动创建主机、磁盘等资源，系统可以根据源端配置自动完成目标资源编排，实现一键式迁移、灾备演练和业务接管。

不过，一次完整的云迁移或灾备，通常会涉及源端环境、网络、存储、操作系统和目标云平台。客户遇到的问题未必来自 HyperMotion 或 HyperBDR，也可能来自源端或目标端的外部依赖。

从产品边界看，其中一些问题并不属于我们的处理范围。但客户更关心的是整个迁移或灾备目标能否顺利完成。因此，在过去几年的项目支持中，只要有助于推进项目，我们通常都会和客户一起分析和解决。

很多客户认可 OneProCloud，不只是因为产品简单好用，也因为我们关注的是客户最终能否把事情做成。

随着用户规模扩大，我们开始思考，如何在保持快速响应的同时，把支持过程中形成的经验、需求和技术判断沉淀下来。因为当用户规模扩大几倍之后，单纯依靠增加人力，很难继续维持同样的服务质量和响应速度。

我们希望利用 AI，在不增加额外流程负担的情况下，把这些碎片化信息转化为可追踪、可复用的企业知识，并逐步让系统基于持续积累的知识，直接帮助用户分析和解决问题。

二、我们是怎么设计的

为什么我们没有直接接入聊天平台

最初，我们研究过一些直接接入即时通信平台的方案，也看过 WeChaty 这类项目。

这类方案可以通过协议模拟、Hook 或其他非官方方式获取消息，但通常存在稳定性、合规性和账号安全风险，很难作为企业长期使用的基础设施。

更重要的是，我们后来意识到，自动读取所有沟通内容并不是一个理想方案。

企业的日常沟通中包含大量临时信息，并不是每一条都值得沉淀。如果把全部内容交给系统，不仅会产生大量噪声，也会带来更明显的数据敏感性问题。

因此，我们更倾向于由企业内部人员主动判断：哪些内容值得保留，哪些问题需要继续跟踪，哪些经验应该进入知识体系。

后来，我们发现即时通信平台可以把选定的内容转发到邮件。这给了我们一个更加简单、可控的方式：不直接接入聊天平台，也不自动采集全部信息，而是让用户主动选择有价值的内容，并提交到后续处理流程中。

这个动作看起来很简单，却解决了两个关键问题。

第一，用户的主动提交本身就是一次信息筛选。

第二，系统只处理企业明确提交的内容，数据边界更加清晰。

但仅仅把内容转发到邮件还不够。

如果不能把背景、要点和后续动作理清，信息就很难进入后续流程，也无法在以后被检索、跟踪和复用。我们的目标不是把信息从一个工具搬到另一个工具，而是把零散表达整理成团队能够直接接手和持续使用的知识条目。

从碎片化信息到知识沉淀

确定主动提交的方式之后，我们接下来要解决的，是如何把这些零散信息转化为可以管理和复用的企业知识。

当时 OneProCloud 内部主要使用 Jira 管理研发和问题跟踪，所以 AI-My-Chats 第一版的目标很直接：接收企业内部主动提交的内容，利用 AI 完成整理，再将结构化结果写入 Jira。

在最初的版本中，我们使用 GPT-4.1 mini 处理文本，并结合微软 OCR 识别截图。系统收到邮件后，会提取正文、图片和附件，再结合上下文生成标题、问题背景、需求描述、已有判断和后续 To-do。

后来，随着 GPT-5 nano 发布，我们在保证处理效果的前提下，逐步将文本处理切换到 GPT-5 nano，以进一步降低单位处理成本。

最近几个月，我们又开始逐步引入 DeepSeek、千问等开源模型。经过实际测试，我们发现，开源模型在我们的文本理解和多模态场景中已经能够满足使用要求。既然效果差距不再明显，成本、可控性和部署灵活性就变得更加重要。

因此，目前我们主要使用 DeepSeek V4 Pro 处理文本理解与总结，使用千问 3.6 Pro 处理图片和上下文。

这个演进过程并不是为了追逐某一个模型。模型始终只是可以替换的能力组件，真正重要的是让整套知识处理流程稳定、可控，并能够长期运行。

这里的重点也不只是自动创建一条 Jira 任务。

原本分散在邮件、截图和日常沟通中的信息，经过整理后，会形成一条保留问题背景、当前判断和后续动作的结构化记录。后续的处理过程和最终结论，也可以继续补充到同一条记录中。

这样，即使问题已经解决，相关过程和经验也不会随着聊天结束而消失，而是可以继续被检索、追溯和复用，逐渐成为团队知识体系的一部分。

Gartner 在《AI Inference’s Financial Reckoning》（G00847756）中提出了类似的判断：企业 AI 的价值正在从一次性、资本性支出的模型训练，转向持续、运营性支出的推理消耗，这从根本上改变了 IT 负责人的财务测算方式；报告同时预计，到 2030 年，超过 80% 的 AI 优化 IaaS 支出将用于支撑推理负载。这意味着，当 AI 真正进入企业流程后，不能只关注模型能力，还必须同时评估效果、单位处理成本和实际价值。

对我们来说，一个 AI Workflow 能否长期运行，首先要看它能不能把事情做好，其次要看它能否以稳定、可控的成本持续完成任务。

在我们这支 20 多人的云迁移与云灾备产品团队中，每个月通过 AI-My-Chats 处理的问题、需求和知识记录超过 100 条，模型成本大约只有 5 美元，折合人民币不过三四十元。

过去，这些信息通常需要人工重新阅读、理解上下文、提炼重点，再整理成可以进入后续流程的内容。AI-My-Chats 基本省去了这个人工中间环节。

按照每条内容节省 15～30 分钟计算，每个月大约可以释放相当于一个人一周的工作量。

也就是说，每个月只投入约 5 美元，我们就可以完成 100 多条碎片化信息的分析和整理，让它们既能进入当前的执行流程，也能沉淀为后续可以查询和复用的企业知识。

这个数据对我们最大的意义，不只是节省了一些费用，而是证明了这类知识处理流程可以在很低的单位成本下稳定运行，并具备进一步扩大使用规模的基础。

从识别图片到理解上下文

第一版主要依靠 OCR 识别截图中的文字，但实际使用后我们很快发现，很多问题并不是识别出图片里有哪些字就能解决。

用户在一段讨论中插入图片，真正重要的是他为什么要在当前上下文里发这张图片。

单纯的 OCR 很难理解图片和前后讨论之间的关系。因此，我们后来转向多模态模型，让系统同时理解图片内容和完整上下文。

这带来的变化，不只是图片识别能力更强，而是系统能够更准确地判断问题背景、用户意图和后续动作。

从这一步开始，AI-My-Chats 处理的不再只是文字和图片本身，而是这些信息在完整业务上下文中表达的含义。

三、从单一产品到可扩展的知识平台

从单一目标到可扩展的知识流转

第一版中，整理后的内容主要写入 Jira，方便研发团队继续跟进。

但随着使用深入，我们发现，同一份信息往往不只有一个用途。

一个产品问题可能需要研发继续跟踪，也可能适合整理成对外 QA，直接帮助客户解决类似问题；一项需求可能需要进入飞书多维表格统一管理，也可能需要同步到 GitHub Issues，进入项目协作流程。

因此，我们开始把 AI 的整理过程和最终的知识落点拆开。

AI 先负责理解上下文、清洗信息并生成结构化内容，再根据实际用途，把结果写入不同的企业系统。

在这个基础上，我们陆续增加了对飞书多维表格和 GitHub Issues 的支持，后续也可以继续接入更多知识载体。

信息来源同样可以继续扩展。除了企业主动提交的聊天片段、邮件、截图和附件，会议记录、项目讨论以及其他碎片化信息，也可以进入同一套处理流程。

这也是我们对 AI-My-Chats 可扩展性的理解：它不是把一段信息固定转换到某个系统，而是先把碎片化内容整理成有效知识，再让这些知识进入企业真正需要它们的地方。

让企业自己的 Skills 参与判断

下一步，我们希望把企业内部已经沉淀下来的 Skills 引入 AI-My-Chats。

这里的 Skills 不只是技术脚本，也包括团队在长期项目中形成的判断标准、处理原则和业务经验。

过去，这些判断往往依赖少数有经验的人。未来，我们希望系统在整理信息时，也能够参考企业已有的知识和规则，做出更符合企业自身习惯的分析和归类。

这样，随着使用不断增加，系统沉淀下来的就不只是零散记录，而是越来越贴近企业自身运作方式的知识。

把验证过的 Workflow 做成 APP

随着使用场景增加，我们也开始思考：企业需要的，究竟是一个通用的智能体编排工具，还是一个已经能够解决具体问题的应用？

企业内部人员通常最了解自己的业务，但了解业务，并不等于能够把经验、规则和协作方式转化为一套稳定有效的 AI Workflow。

很多时候，真正困难的并不是模型能否理解一句话，而是流程应该如何拆分、判断标准如何确定、最终结果应该进入哪里。

因此，我们逐渐形成了一个比较直接的判断：

越通用，越没用。

这并不是否定底层的通用能力，而是说，企业真正需要的不是无限的组合方式，而是针对具体问题、经过验证并且能够直接使用的产品。

我们的选择，是把反复验证过的 Workflow 封装成一个个具体的 APP。模型、知识库、权限和基础组件可以保持灵活，但真正决定效果的业务流程，应该由产品提前完成设计和验证。

用户不需要从零开始设计提示词和 Workflow，只需要根据自己的环境做必要配置，就可以直接使用。

这也让我们重新思考 FDE，也就是 Forward-Deployed Engineer 的价值。

过去的软件交付，通常有两种方式：要么从零开始理解需求并进行定制开发，要么拿一套现成软件去套用户的流程。前一种方式成本太高，后一种方式又很难真正解决客户的问题。

AI 提高了开发和调整流程的效率，也带来了一种新的可能：先把一个已经验证过、能够覆盖大部分场景的产品和 Workflow 做出来，再由 FDE 到客户现场，根据企业的数据、规则和实际流程进行调整。

它有点像"预制菜"式的软件交付。核心能力和主要流程已经跑通，到了客户环境中，再完成最后的配置、微调和集成，最终交付一套真正能够解决问题的系统。

AI-My-Chats 希望探索的正是这种模式。它背后的核心能力通过开源项目 Devify 提供，FDE 可以在成熟、开源、可调整的产品基础上完成现场适配，而不是每次都从零开发。

从这个角度看，FDE 的价值不只是帮助企业开发新的 AI 应用，更是在成熟产品和企业实际需求之间，完成最后一公里的连接。

如何体验 AI-My-Chats

AI-My-Chats 背后的核心能力已经通过开源项目 Devify 开源在 GitHub（https://github.com/cloud2ai/devify）。如果你想快速体验，我们提供两种方式。

方式一：SaaS 直接体验

打开 https://aimychats.com 注册即用，无需部署，适合个人开发者或小团队快速验证整个链路。整体链路：聊天工具（微信 / WhatsApp / Slack）→ 转发邮件 → AI-My-Chats 自动处理 → 结构化结果（Bug / ToDo / 任务 / 总结）→ 同步到 Jira、GitHub Issues、飞书多维表格等系统。

方式二：本地 / 企业私有部署（推荐）

适合对数据安全和系统集成有要求的团队。Devify 支持完全本地化部署，最简单的方式是 Docker：

git clone https://github.com/cloud2ai/devify.git
cd devify
cp env.sample .env   # 复制模板，按需修改
docker compose up -d

⚠️ 仓库提供的是模板 env.sample，而 Docker Compose 默认读取 .env。启动前务必先执行 cp env.sample .env 并填好配置，否则服务无法启动。

启动后用浏览器打开 Devify 界面，注册并登录管理员账号。之后所有配置都在网页中完成，无需再碰命令行，只需两步即可跑通：

第一步 · 接入 AI 模型： 进入「管理控制台 → 模型配置」，添加模型（填写服务商 API Key、接口地址、模型名称），并在应用设置中设为默认。支持 OpenAI、通义千问、OpenRouter 等主流服务商，也支持本地模型。

第二步 · 配置邮件接收（IMAP）： 进入「设置 → 邮件」，选择 IMAP 拉取方式，填写企业邮箱的服务器地址、账号、密码、SSL 端口和收件文件夹。之后系统会定时拉取邮件并自动处理。

两步完成后整条链路即打通：聊天工具 → 转发到企业邮箱 → IMAP 拉取 → AI 处理 → 结构化结果，同步到 Jira / GitHub Issues / 飞书多维表格。

加入 AI-My-Chats 开源交流群

如果你在体验过程中遇到问题，或者想参与共建、交流开源经验，欢迎扫码加入微信群。