我们做的是什么，
为什么现在值得做

互联网时代做的事情，本质上是从无到有。操作系统、办公软件、CRM、项目管理、会议、文档、网盘……几十年里，工具一个接一个被发明出来，百花齐放。每个工具解决一个具体环节，价值在于「多」——你能想到的事，几乎都有一个软件在做。

大模型时代的动作，方向反过来了：收敛。模型可以直接替代大量单一工具所做的事——写、查、总结、分析、翻译、生成，甚至写代码——用更低的成本、更高的效率完成。过去要装五个软件才能串起来的事，现在一个对话框可能就够了。价值从「多」转向「少」。

但「少」并没有自动解决「多」留下的问题。

大模型替代的是工具的能力，没有替代工具里的数据，也没有替代工具之间的壁垒：你的资料在网盘、在本地、在邮箱、在聊天记录、在十个不同的系统里；格式不同、命名不同、口径不同。模型再强，也读不到它没被喂进去的东西。

所以业内现在的方向是：用知识库 + 记忆系统做一个大统一的体系，把所有工具的能力与数据都融合进模型。这个方向是对的。

但注意力的落点在平台与基础设施：比谁的向量库更好、谁的记忆架构更完整、谁的智能体框架更通用。这些是高速公路。

缺的是接入——把真实场景里那些格式各异、命名随意、散落各处的数据，真正接进来的那一步。这一步没有捷径：要处理格式、要归一化、要建立结构、要能对上业务语义。

弈枢选择提前把这件事做好。我们把模型、记忆系统、知识库做成可插拔的：不绑定某一家知识库，不绑定某一种记忆系统，也不绑定某一个模型。前提是先把前期的数据处理与归一化做扎实——只有数据被整理成模型读得懂的样子，接进去之后，它才能更精准地执行、理解与分派。

也正因如此，我们的产品不是从「聊天」做起，而是从「把资料接进来」做起：自动找库、自动建库、目录树与知识图谱、带出处问答。先把接入层修好，再谈上层能力。

不是没有人发现，也不是没有人做。是解决成本高于收益。把数据接进来、真正用起来，过去横着三道墙：

会议现场是这三道墙的压力测试：会中实时辅助＝听懂 + 检索 + 判断 + 提示，要求在秒级完成。互联网时代技术上不成立，只能会后人工整理，而时效性已经丢了。

更根本的：这笔痛没有被记账

只讲「成本高」还不完整。成本高的事情多的是，真正让它一直没变成需求的，是这笔痛从来没有被记到对的账本上：

• 记在个人头上，不记在组织账上。老手自己扛得住，组织就不觉得疼。同一个人既是受害者，也是解药，所以他不需要求助。
• 记成「能力问题」，不记成「基础设施问题」。新人成长慢，被归因为「不主动、不灵光」。归因指向人，就不会指向工具。
• 记成「偶发事故」，不记成「结构性损耗」。丢单、返工、项目延期被当成运气，因为没有人做对照，看不出是同一个原因在重复发生。
• 成本延迟兑现。今天的省事，三个月后变成返工。归因链太长，人脑接不住。
• 替代方案社会可接受。「经验靠悟」「多跟几个项目就会了」成了默认，缺口就这样被合理化了。

对照一下过去的替代方案，就更清楚了：

三个变量同时变化：

• 信息量在涨，人的处理带宽没涨——缺口的绝对值越来越大；
• 决策窗口在缩短、单次决策的代价在变大——商机、交付、方案汇报，错一次的代价不可逆；
• 组织记忆在断层——老手经验留不住，新人接不上，人员流动让「上一次是怎么做对的」失传。

痛感因此发生了性质变化：从「慢一点」的焦虑，变成「判断错」的焦虑。没有知识体系、没有知识库的支撑，我们寸步难行——做不出良好的决策，做不出精准的判断，也就没有办法跟社会竞争。

与此同时，大模型把三道成本墙同时打穿：构建靠自动解析与建图谱，寻址靠语义检索，判断靠结合上下文的推理。痛点上了一级，解法成本下了一级。过去算不过来的那笔账，现在第一次算得过来。

这也是一个时间窗：平台层正在被大厂和创业公司挤满，接入层却很少有人认真做——因为它脏、累、不体面，要钻进一个个具体场景里处理格式与口径。但恰恰是这一段，决定了模型能不能真的被用起来。

但大模型没有消灭信息过载，它换了一种过载方式

这是当下最真实的一层痛：过去是「找不到资料」；现在是模型一次推给你一堆方案、一堆资料，让你自己看、自己碰运气。推荐三个方案给你，可这三个到底哪个好、在规范性与便捷性上差在哪，还是要你自己掂量。

信息过载从「找」转移到了「读」和「选」。这也正是业内开始集中讨论「驾驭工程」（harness engineering）的原因——模型的能力已经足够，缺的是如何驾驭它。

痛点不是一个抽象概念。它在职业生涯的三个阶段，以完全不同的样子出现。

我们不做纯工具（只提效，不解决判断），也不做纯聊天（只给信息，不落到执行）。我们做的是一条链：

这是弈枢AI工作台（Easur Work）的产品形态。任务闭环八环已经全部打通；会议辅助是产品内的功能，而不是另一个独立产品。

其中知识底座不是一座封闭的库，而是一层可插拔的接入：既能自建库，也兼容不同的知识库与记忆系统；先把数据归一化，再谈上层能力。

与之对应的两句原则，正好是这条链的结论：

• AI 出产能，人出判断——机器负责识别、分析、推荐、执行；要不要做、先做哪个，判断权始终在人。
• 工具等你开口，伙伴先你一步——在你还不知道要问什么的时候，把该问的端到你面前。

更根本的差别不在功能，在站位：业内主要在建平台——更强的知识库、更完整的记忆系统、更通用的智能体框架；我们做的是接入层——把真实场景里的数据归一化，再可插拔地接进这些平台。平台层比的是模型与架构，接入层比的是谁更懂那些脏活。

市面上的产品，每一家都在把一个点做深：会议记录做一个点，知识库做一个点，任务管理做一个点，AI 助手再做一个点。它们在各自的单点上做得比我们深，这一点必须承认。

但它们的共同特征是——纵向很深，横向不连：会议记录不产生任务，任务不回流知识库，知识库不进入下一场会。

而这件事真正的难点，恰恰在衔接处。单一产品解决的是某一个单方面的问题，但它始终没有解决整体的融合、整体的效率与便捷。

所以我们做的不是第五个点，而是把这些点接成一条线的那个东西。可讲的融合价值只有三条，且都要能被演示：

1. 会议里的一句话，能直接变成带上下文的待办，而不是复制粘贴；
2. 做完的成果，能自动回到项目与知识库，而不是再手动上传一次；
3. 下一场会开始时，上一场的结论已经在场，而不是靠人记得。

这一段最难回答，也最容易被回答成「我经验丰富」。我们尽量把它说具体。

广度，而不是深度

12 年工作经验，全部在一线：产品经理 → 项目经理 → 项目总监 → 分公司总经理。接触过项目实施、交付、方案编制、商务沟通与洽谈，横跨项目商机管理的全生命周期。

2019 年公司刚起步，我一个人在贵州同时跟进十来个项目。前面理顺的还好，难的是跟进阶段：今天一点事、明天一点事，单件都不大，但很杂、很乱。那时候没有归档，基本靠记忆。后来有人来接手，我才发现——我不知道该交接什么。

2023 年做分公司总经理，要经常跟客户讲公司做过的案例。有一次讲到细节卡住了，客户当场问：「你们是真做了，还是假做了？是不是在吹牛？」那句话很难堪，但更让我难受的是，客户可能问得对——我们确实做过，可我们拿不出证据链。

三段岗位，各练出一种能力

第三行是最特别的一层：我做过「能力怎么从一个人身上传到另一个人身上」这件事，而且是在组织层面做，不只是自己会。这件事的产品形态，就是把经验做成可复用的技能与模板——不是替代人，是不让能力只长在某一个人身上。

技术平权改变了等式

过去，一个有这些想法的人，卡在同一个地方：想得到，做不出。要建知识库要有技术团队，要做客户端要有工程能力，要接模型要有算法。

大模型带来的技术平权改变了这个等式：一个既做产品、又管项目、还带过分公司的人，第一次同时具备了产品定义能力和解决技术底座的能力。

我一直在市场上找一款能装下这套想法的产品，一直没有找到。技术平权之后，我发现我可以自己解决这个问题。

前面讲的是「做什么」和「为什么值得做」，这一节讲「我们用什么做、怎么把它做出来」。

底座：DeepSeek Harness

我们不自己造模型，也不自己重写一套智能体引擎。客户端与智能体运行时采用 DeepSeek Harness 作为底层架构，并全面采用它插件式、可插拔的设计理念：模型可以换、技能可以加、工具可以接、知识库可以替换，系统不把自己锁死在任何一个组件上。

这和我们前面说的「接入层」是同一套思路：​不绑定任何一家，才有资格做中间那一道门。只有当模型、记忆系统、知识库都能被替换，用户的数据与经验才真正属于用户，而不是被某个平台扣住。

具体来说，这四个「可替换」不是口号：模型可换，不同任务可以用不同模型；技能可加，新能力以插件形式加入；工具可接，已有的系统通过适配接进来；知识库可替换，自建库或已有库都能用。

边界也要说清楚：我们不重造驾驭引擎。模型调度、工具协议这些交给底座；我们做的是接入、归一化，以及在具体场景里把判断递到人面前。

开发方式：AI 原生

我们不是用传统软件工程的流程去「套」一个 AI 应用，而是用开发 AI 应用的方式开发 AI 应用——需求讨论、设计核查、业务逻辑、原型、开发、测试、审查、上线，八个阶段都有智能体参与；人只出现在判断点：要不要做、做成什么样、能不能发。

这就是我们说的「AI 原生」：不是给旧流程加一个 AI 助手，而是让 AI 成为流程里的执行者，让人退回到判断者的位置。

判断点具体落在六处：提问、确认、拍板、验收、复核、批准。其余环节，尽量交给智能体。

这条路的意义有三层。插件式让我们不被任何一家模型或工具绑住；AI 原生让我们用做 AI 的方式做 AI，而不是用做软件的方式做软件；两者合起来，才让一个小团队能把一条跨端、跨场景的链路做出来。

业内越来越一致的说法是：模型的能力已经足够，缺的是驾驭。怎么组织输入、怎么约束输出、怎么编排工具、怎么让人做最终选择——这层工程叫驾驭工程。

我们的三条主张是：

一、不把信息倒给人，只把判断点递给人

模型看到的是全部资料，人看到的应该是最值得你注意的那一个点，以及为什么。压缩比本身就是产品能力。

二、永远给选项，不替人拍板

至少两个方案，讲清各自的代价与适用条件；人做选择题，不做判断题。这与「AI 出产能，人出判断」是同一条原则。

三、规范与灵活的边界要设计

哪些环节必须标准化（归档、纪要结构、任务卡字段），哪些必须留白（判断、措辞、取舍）。难点不在全自动，在该管的管住、该放的放开。

我们不重造驾驭引擎——模型调度与工具协议交给底座。我们做的是驾驭工程里离人最近的那一段：喂什么、压成什么、怎么让人选。

这一段恰恰是现在做得最差的：大家都在比模型多强，很少有人认真设计「人看到的最后那一屏」。

接入层决定模型能看到什么，驾驭工程决定人最终看到什么。两者合起来，才是「AI 出产能、人出判断」的完整链路。