惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
SegmentFault 最新的问题
博客园 - 三生石上(FineUI控件)
WordPress大学
WordPress大学
博客园 - 【当耐特】
月光博客
月光博客
Vercel News
Vercel News
D
Docker
I
InfoQ
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 叶小钗
MongoDB | Blog
MongoDB | Blog
GbyAI
GbyAI
有赞技术团队
有赞技术团队
雷峰网
雷峰网
博客园 - 聂微东
小众软件
小众软件
Y
Y Combinator Blog
腾讯CDC
L
LangChain Blog
The GitHub Blog
The GitHub Blog
宝玉的分享
宝玉的分享
Stack Overflow Blog
Stack Overflow Blog
大猫的无限游戏
大猫的无限游戏
T
The Blog of Author Tim Ferriss

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
下一代协作工具的第一用户居然不是人 – 人人都是产品经理,
鸣老师 · 2026-04-27 · via 人人都是产品经理

下一代协作工具正在颠覆传统认知——AI正成为一等用户。这款AI原生协作工具彻底重构了文件组织逻辑,所有存储结构都为机器阅读优化,人类反而退居二线。本文将揭示这种设计范式如何解决飞书在AI协作上的短板,同时剖析其在多模态内容处理和RAG检索上的技术挑战。

你以为协作工具是给人用的对吧。

我之前也这么想。

直到我看到一款新型协作工具,才发现下一代协作工具的第一用户可能不是人,而是AI。

它的一等使用者是AI,人其实能看,但是它主要不是给人看的,主要是给AI看的。

所有文件的组织方式、存储逻辑,全是照着AI好读来设计的。

memory、skill、agent相关的结构直接明明白白摆在那里,方便AI直接调取记忆、用技能、理解整个项目。

人反而变成次级用户了,你甚至不用管那些触发器、底层结构,直接聊天问问题就行。

对比下来飞书反而像个老产品,所有逻辑都是给人设计的,AI最多帮你回答点问题,根本没法自己做事。

这类AI native协作工具是近几个月刚出现的新产品方向。

王自如上周的直播也花了两三个小时讲解相关内容。

我觉得这东西确实是未来的方向,比飞书更先进,目前还有较大创新空间。

但也有问题。

当前团队要做的知识库需要支持文本、视频、音频等多模态内容。

这类AI native协作工具的现有存储逻辑仅适配文本类内容,对需要分镜、预处理的音视频内容适配性差。

它的文件检索逻辑是传统的文件查找、推理、全文搜索模式,而非向量化检索。

对于可能获取的海量爬取数据来说,这种文件存储方式完全不适用,海量数据输入模型还容易引发幻觉。

必须额外增加搜索层做RAG。

多模态内容的存储思路是这样的。

底层存视频的元数据、分类标签和向量,上层仅给人展示需要看的内容。

不需要展示的AI相关结构做隐藏,部分有编辑权限的人可以修改内容。

业务文档可以和飞书做同步,作为业务知识库。

音视频内容的呈现可以通过内嵌链接的方式实现,AI只需要读取对应的元数据和标签即可,不需要读取复杂的交互页面源码。

数据源只能有一份。

要么和飞书实现双向同步,要么规定工具仅作为AI产出的载体,产出内容再同步到飞书。

绝对不能搞两份数据,不然到时候同步乱了要出大问题。

飞书本身比较保守,不会做太激进的AI改造,团队可以自己基于业务需求定制能力,不需要等飞书更新。

产品不需要替代飞书,只需要做飞书的补充。

飞书的文档创作、协作、格式美化、权限管理等体验是无法超越的。

我们聚焦于AI处理文档的场景,解决飞书AI能力弱、无法对接外部数据和自有工作流的问题。

其实我们干掉的是飞书这款产品里面它的AI做得不好的部分。

用户还是在飞书里写文档、做排版、开评审,写完了一键同步到我们的系统,剩下的AI写周报、做规划、拉业务决策这些脏活累活,全交给我们的Agent来干。

知识库采用文件系统的架构,目的是让人可以用自然思维编排内容的检索逻辑。

方便在提示词中指定检索范围,实现可控的RAG检索。

如果不用文件系统的话,我是没有办法告诉AI怎么在RAG里做检索,就没办法控制。

产品替代的是Obsidian这类个人知识管理工具,成为团队级的内容生产集合中心。

企业知识可以分成两类。

一类是经过整理的核心业务「金牌知识」,需要沉淀到专属知识库中。

另一类是泛知识,比如VPN连接方法、基建操作手册等,这类知识无需专人整理,适合通过内网搜索获取。

内容创作仅需要知识库中的精炼核心知识即可,泛搜索对个人办公有用,但不适用于垂类内容创作场景。

本文由 @鸣老师 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议