在大模型时代，上下文管理的精准度正成为AI产品的核心竞争力。从飞书AnyShare的生态整合到Mox的AI原生设计，不同路径背后折射出产品战略的根本差异。本文将深度剖析内容创作垂类赛道的机会与挑战，揭示如何在巨头环伺下用技术选型构建护城河。

「context就是一切。」

这是王自如上周直播说的话，我深以为然。

我测试用doubao-seed-2.0-pro配合优质上下文管理和提示词，仅聊了一个小时，就得到了言之有物的内容创作迭代方案。

效果超出预期。

不需要追求超大参数模型，只需要做好上下文管理，普通大模型就能输出有效内容。

跟团队聊产品方向的时候，我们达成了一个共识。

不需要做复杂的文件操作，只需要做好文件读写。

核心是做好上下文管理。

open cloud稳定性差我们不考虑使用，只需要收窄能力聚焦上下文管理就能做出有效价值。

产品落地要先做轻，暂时不做多模态，复用已有平台能力，先拿到业务成果。

说说产品定位的问题。

两个方向二选一。

一个是做大而全的AI版飞书做通用协同。

另一个是先聚焦短视频内容创作的Agent工作台，先跑通业务再扩展。

从当前团队人员配比和公司内部影响力来看，一开始做通用协同直接和飞书竞争不现实。

只能先聚焦内容创作单点，把文件系统做好，底层框架做通用，拿到业务成果让领导看到价值之后再横向扩展。

聊聊飞书AnyShare。

它已经在字节团队内部高频使用，由内部团队开发，按老板账号计算单日token消耗约1000美元。

基于OpenCloud改造，打通飞书线上生态，是飞书原生的Agent应用。

能直接读取飞书群聊内容做总结沉淀到飞书文件系统。

但我发现它的核心思路和已有Agent产品Mox相近，定位偏轻，只是把现有小龙虾能力和飞书文件系统打通，AI还是辅助角色。

而Mox是完全AI友好的文件系统设计，AI是核心主力。

关于竞争关系。

如果下个月飞书AnyShare在携程通过合规审核开放使用，会和我们团队计划做的通用Mox类系统产生直接竞争。

但我进一步拆解差异后发现，飞书AnyShare其实还是在原有给人用的飞书文档体系上做AI接入，没有改变底层结构。

而我们计划做的系统是围绕AI设计，核心壁垒是上下文管理的精准度。

这一块是我们的优势。

飞书AnyShare不会冲击内容创作垂类，只和通用AI文件管理系统有竞争。

再说RAG技术方案选型。

当前核心分歧是直接沿用成熟的ragflow做试点，还是一步到位搭建文件系统，采用卡帕西提出的最新方案。

我明确偏好后者。

传统rag是两年前的老技术，长期来看价值会越来越低。

针对需要精细化内容注入的内容创作场景，传统rag召回精准度不足。

如果同样投入资源，新方案做出来的是更先进、垂直于业务领域、更有竞争力的成果。

传统RAG召回率大概在60%-80%，新方案可以做到90%以上。

有人提出可以先试传统rag flow，发现问题再换方案。

我认为这会浪费时间。

大厂内部决策的普遍痛点是新技术方向因为收益没法精准量化，很难说服老板。

这是大厂掉头慢的核心竞争劣势。

行业里都知道要掉头，都要转一个方向，但是大厂里可能很难决策。

最终方向是往Mox的AI原生设计思路走。

不会纯从内容生产视角设计系统，但第一步要先把内容创作模块做出来。

飞书适配相关优化不是P0优先级，可以延后。

当前核心工作是优化资产库和文件系统的调用能力，建立竞争壁垒。

先做垂类做出成绩，大家知道你AI做的好，然后才能有做通用性的机会。