Part 1: 开场与开源理念
AI炼金术士的介绍与BISHENG的开源理念
核心内容
核心主旨/议题: AI 在 2B 企业中的落地与应用
- 关键论点/分论点:
BISHENG 的定位与演进
开源模式的优势与挑战
企业级 AI 应用的特殊性
- 重要观点/洞察:
企业级 AI 应用需要咨询和实施服务
开源模式能快速获取用户反馈
产品团队主导的标品更有利于吸引人才
- 论据/例证:
BISHENG 的发展历程
客户对开源产品的积极反馈
- 关键定义/概念解释:
企业级 DeFi (企业级的开源平台)
Agentic Workspace (企业的一个开源的 Agentic Workspace)
实用性与关联性
- 行动建议/方法论:
- WorkSmart (帮组织把 AI 用好,让它真正能够产生价值)
- 提及的资源:
BISHENG (企业级的开源平台)
DeFi (去中心化金融)
Langchain
- 不同观点/争议点:
开源环境的挑战 (国内开源环境较差)
是否应该做定制化 (以产品团队为主导的标品)
- 结论/总结:
- 开源模式在 2B 领域具有独特优势,但需要结合咨询和服务才能真正落地。
- 行动建议/方法论:
BISHENG
- 产品定位:
企业级 DeFi
开源的 Agentic Workspace
- 核心价值:
帮助企业落地 AI 应用
提供咨询和实施服务
- 开源优势:
快速获取用户反馈
提升知名度,便于获客
产品团队主导,吸引人才
- 商业模式:
上门安装 (基础)
咨询和实施服务 (核心)
- 产品定位:
开源的商业价值与企业级市场的需求
开源的价值
加速客户反馈
更多用户使用,更快发现 Bug
用户反馈不占用团队时间
打造标杆产品
吸引人才
- 吸引对开源项目感兴趣的人才
盈利模式
线上用户使用后提出定制化需求
原厂提供升级或咨询服务
节省营销渠道费用
开源项目热度的原因
满足企业未被满足的需求
与 DeFi 等项目的差异化
团队更擅长企业服务市场
时间节点:大模型是底层动力
企业级市场的差异化需求
模块缺失
- DeFi 等项目不关注企业级需求
数字化转型需求
数据统计大屏
展示 AI 使用情况
统计 Token 消耗
应用节省时间
为领导汇报提供数据支撑
Part 2: 企业AI Agent应用场景
企业AI Agent落地的主要应用场景:问答
应用场景分类
问答类
审核类
写报告类
智能问数类
其他 (不好归类的)
问答类应用场景
基础应用:
汇聚企业内部非结构化文档数据到一个平台
- 各业务系统沉淀的合同、审批、科研、情报等
特色应用:
芯片制造:
AI服务客户,解答芯片SDK文档问题
优化:代码以ID形式存储,保证代码准确性
客服场景(民航领域):
服务全国机场和航空公司
关注确定性,保证准确性
以QA库为准,AI做前期多轮引导
理解用户问题,从QA库找到相关问题,反问确认
无法在QA库找到的问题转人工,积累QA库
新兴应用:
降低知识库构建周期,提升用户体验
模仿腾讯iMark,强调文档产品逻辑
建立知识库,甩入文档,邀请共享共建
方便管理外部文章和内部文件
部门间共享资料,方便查询
关键点
传统IT转型未完成:企业内部文档数据分散
确定性/准确性:面向客户场景的核心需求
用户体验:一线业务人员对体验关注度高
知识库构建周期:降低构建周期是新趋势
知识库问答的确定性问题与审核场景的挑战
问答场景 (客服)
核心问题:确定性与准确性
确定性:难以保证100%确定性,命中率通常在80%以上
准确性:即使命中,也需要人工确认,难以达到100%准确
解决方案
QA库:依赖人工审核过的QA库
意图补全:大模型帮助补全用户不准确的提问意图
人工Check:最终依赖人工check问题是否匹配
竞争与市场
垂直领域竞争:存在专注于客服领域的2B服务商
市场定位:不追求垂直深入,构建通用底层能力,服务大型定制化客户
客户类型:
非目标客户:预算有限的小型客户,建议使用SaaS服务
目标客户:预算充足的大型企业,需要定制化服务
产品核心:交付工具,提高交付效率
审核场景 (文件审核)
核心逻辑:预制审核逻辑 (几十项至上百项)
审核维度:合同审核、消费者保护审核等
审核顺序:各项审核逻辑存在先后顺序
示例:合同首页与尾页甲乙方名称一致性
挑战:需求不明确与迭代
需求不全:用户最初提供的需求往往不完整
迭代周期长:需要多次迭代才能完善
业务信任:需要取得业务部门的信任
需求变化:用户后续测试可能发现新问题
价值:
快速实现:在需求不明确的情况下,快速实现并与用户共同打磨
电子化代码:业务价值清晰后,可形成电子化代码
优势:
流程植入:可植入业务流程,自动审核,提高使用率
风险提示:提示风险,供参考
关键:业务部门的配合程度
共同点与思考
Palantir模式:构建底层能力,服务大型客户
持续学习:不断学习和改进
业务人员的配合问题与报告场景的介绍
挑战:业务人员的配合
口头配合,实际抵制
危机感
解决方案:笨办法
陪同业务人员
- 一点一点磨合
企业服务的重要性
深入业务
共同配跑
Agent RL 的技术方向
让 Agent 在环境中学习
- 学习规则或提示词
产品形态:灵思
SOP 指导模型
自动探索审核流程
NDA 审核案例
法务同事的痛点:每天看 NDA 看疯了
解决方案:AI 辅助
收集批注和文件
AI 识别规则
生成 Prompt
达到七八十分的效果
适用场景:非重要合同
- 容错率高
应用场景
问答
审核
报告生成的溯源问题与智能问数场景的谨慎态度
报告类型与场景
国央企内部报告
规划报告
中期报告 (季度、半年、年度)
对外输出报告
金融机构研报 (债券、证券等)
银行禁交报告
交通规划报告
事故报告
大模型在报告生成中的应用
报告框架搭建
基于过往文档格式
数据来源与分析思路
内容生成
数据段落描述转换
变量形式引用 (在线 Word 模板)
产品差异化与挑战
差异化
在线 Word 模板,变量引用
工作流中间用户输入与反馈
挑战
报告内容溯源 (系统查询、中间过程)
在线核验与修改
投资 Memo 生成场景
需求
整合多来源信息 (录音、财报、PDF)
自动生成 Memo 或根据提问生成
大模型能力
目前可生成 Memo
支持工作流中间用户输入与反馈
风险分析与判断
版式固定、逻辑固定的报告
- 简单,但可能低于用户预期 (希望复制粘贴)
Memo 风险分析
大模型可提供意想不到的风险点
挑战:用户前期沟通可能未提及所有分析角度
落地方法论
目标
让业务人员喜欢并使用产品
在使用过程中记录专家 know-how (SOP)
步骤
历史文档分析
使用时呈现 SOP,而非前期咨询
智能问数的挑战与成功案例
核心观点:问数场景谨慎,成功案例少
相对最谨慎的场景
成功案例少,多为劝退
客户提出需求,评估风险后决定是否进行
成功要素:数据治理水平和认知
数据治理水平
- 客户有决心做数据治理
对准确率的认知
接受非100%准确率
通过交互方式补偿准确率缺失
成功案例:大宗贸易领域顶级单位
背景:商情数字化需求
领导每周开周会 review 各业务线
希望更快看到一手数据,而非汇报结果
解决方案:
将非结构化数据转为结构化数据,再变成图表
数据逻辑面向业务导向和应用决策导向
数据并非直接从 SAP 或 OA 系统接数据库
具体细节:
指标变频:每日、每周、每月、每季、每年
维度扩展:同比、环比、过去十年最高/最低/平均
索引全扩展,一阶查询,提高准确率
失败案例:项目管理系统
场景:工程项目管理(盖房子、修路等)
- 项目阶段、材料采购、供应商情况等
问题:
直接接入原始业务软件的表
数据原始,业务链路长
尝试:
腾讯音乐开源的 Super Sonic (语义层)
在原始表上建立字段语义和指标
失败原因:
系统变得非常复杂,难以使用
最终发现不如直接建立新表
数据治理的重要性
数据治理不足导致自然语言 to SQL 无法实现问数
原始数据表结构复杂,语义不清晰
建议:面向业务需求,建立新的数据表,而非依赖原始表
Part 3: 企业AI落地与业务参与
数据治理的重要性与企业AI落地的四个阶段
数据与模型挑战
表间关系混乱
缺乏统一ID关联
数据结构复杂
历史遗留问题
字段含义不清
多表查询 vs 单表查询
多表查询对模型能力要求更高
非模型不可解问题
场景误区与务实选择
问数(数据看板)
领导关注,易立项
基建要求高,数据治理是关键
IT领导与业务领导认知需一致
酷炫 vs 实用
避免过度追求技术
关注用户实际需求
高频实用场景
知识库问答 (类似IMA)
用户视角出发
使用率高
情报类应用 (类似ChatGPT Pause)
自动爬取信息
部门相关信息过滤
信息来源多样 (部委、公众号、论文库)
替代人工筛选
实施难点与经验教训
业务理解深度
低估业务复杂性
真实世界复杂性
人的配合
业务沟通
需求确认
企业AI落地的四个阶段与业务人员的参与
阶段一:玩具阶段 (发烧友拥抱)
技术人员 (发烧友) 拥抱
觉得技术厉害,想赋能业务
业务感知不强,被动状态
阶段二:通用场景喜爱 (业务人员开始使用)
业务人员日常工作中使用
使用频率和 Token 消耗量增加 (DeepSeek, 豆包, Manus)
解决工作问题,感受模型价值
关键:业务人员主动参与
产生体感和热情
主动寻求合作
挑战:企业内网环境
不涉密信息使用公网模型
涉密信息使用企业内系统
改进方向:提升 2B 平台用户体验
- 关注用户感受,缩小与 C 端产品差距
阶段三:垂直 Agent 落地 (业务深度参与)
真正意义上的垂直 Agent 落地
业务人员深度参与场景打造
联合 IT 人员共同构建场景
阶段四:数字员工 (自主智能体)
Agent 作为自主智能体
无需人工构建测试场景
在企业内部自主工作 (如:查询 HR 信息、研发规范等)
游刃有余地完成工作
核心观点
不要高估短期变化,低估长期变化
产品落地需要用户认知和长期使用
甲乙方都不能太着急,避免透支信用
业务参与是本质关键
如何吸引业务人员参与与BISHENG的社区关注度
大模型落地现状
MIT 报告解读
5% 企业真正拥抱大模型 (存在断章取义的可能)
大量员工使用公共工具,体验优于企业内部工具
企业自建 GPT 的问题
体验不如 ChatGPT
员工倾向于私下使用公共工具
大模型落地挑战
甲乙方认知差异
业务人员参与度低
IT 部门难以推动
业务人员体感的重要性
需了解大模型在业务场景中的表现
能够判断模型优劣,提高效率
调量不足的问题
部分企业搭建后使用率不高
需深入挖掘业务需求,持续迭代
如何吸引企业用户
安全性考虑
担心数据泄露
内部部署可解决安全问题
体验至上
提供与 ChatGPT/DeepSeek 相似的体验
交互体验、推理速度等
工作流搭建
拖拽式工作流
降低使用门槛
用户使用情况
自主搭建为主
大量用户自行搭建工作流
付费用户享受定制服务
技术天花板高
领导和一线员工都愿意投入
掌握下一代生产力
学习意愿强
与 OCR 等技术相比,大模型更具吸引力
提升个人价值,增加择偶权/加工资机会
社区关注度获取
未进行营销推广
开源项目评测
早期与博主合作,免费推广
口碑传播,持续吸引用户
报告生成
- 较早支持报告生成功能
Part 4: 商业模式与转型建议
中国2B市场的盈利问题与BISHENG的客户筛选策略
核心观点
中国 2B 市场潜力巨大,并非不能盈利。
关键在于筛选客户、做正确的项目、与客户达成共识。
开源社区带来的良性循环是成功的关键因素之一。
盈利模式
- 筛选正确的客户
通过开源社区吸引客户,减少销售成本。
避免说服不认可的客户,节省精力。
- 做正确的项目
拒绝不合理预期或不具备数据基础的项目。
避免做错误的项目导致亏损和用户不满意。
- 与客户达成共识
目标是客户成功,建立在共同预期之上。
即使超出预期,也要关注项目是否能产生业务价值。
不过度计较成本,着眼于长期合作和二三期项目。
- 筛选正确的客户
开源社区的价值
- 吸引开发者
开源项目吸引大量开发者关注。
开发者来自大企业 IT 部门,带来销售线索。
- 建立信任
真诚表达项目预期,避免过度承诺。
类似“学佛老师”的例子,不夸大效果,反而更受信赖。
- 形成良性循环
客户预期合理,项目更容易成功。
成功案例带来更多客户,进一步巩固优势。
- 吸引开发者
风险与挑战
- 不能依赖现有模式
当前阶段是“发烧友市场”,面临新的挑战。
需要观察市场变化,持续满足用户需求。
- 技术形式的局限性
“拖拉拽”形式不够优雅,可能不是最佳终局。
需要探索更先进的技术和解决方案。
- 不能依赖现有模式
经营策略
- 账期管理
账期是经营的关键因素,不同行业账期不同。
账期越长,可以考虑更高的利润率。
根据自身情况选择合适的行业。
- 账期管理
传统企业AI转型的建议与模型能力的诚恳认识
转型困境与挑战
传统企业普遍面临转型难题
吆喝多年,转型效果不佳
踩坑无数
常见心态
有钱但抠门
希望见到效果再付费
对AI落地效果持怀疑态度
AI落地现状
技术本身并非确定性技术
尚未掌握最优落地实践方案
仍处于探索阶段
- 逐渐从第一阶段(拔苗助长)转向第二阶段(诚恳认识模型能力)
转型建议:心态与方法论
心理挑战:坦诚认识模型能力
- 甲方和乙方都需要
关注点:提升业务人员的AI体验
- 解决落地卡在业务人员没感觉的问题
方法论:
缩短交付项目周期
降低试错成本,鼓励业务人员上手
避免长时间沟通后交付效果不佳导致信心受挫
具体行动建议
- 第一阶段:通用能力认知
部署开源AI工具(如BISHENG.ai)
提供咨询服务
举办内部比赛,鼓励业务人员使用
利用日常对话模式、通用知识库、商情订阅等
使用零丝(企业版Manas)进行更复杂的Agentic操作
- 第三阶段:垂直应用(针对已具备通用能力认知企业)
核心:底层数据质量和交付工具效率
类似于Palantir模式
快速、低成本地满足客户定制化需求
避免推诿
- 第一阶段:通用能力认知
产品与服务
BISHENG.ai
企业统一的AI入口(工作台)
多种Flow选择
类似DeepSeek的对话界面
临时模式(企业版Manas)
企业内部上下文的重要性与Palantir的底层逻辑
大模型落地挑战与误解
落地成本:
并非开箱即用,需要成本投入。
需要考虑硬件、软件、维护等方面的成本。
学习成本:
模型需要学习企业内部的业务流程和上下文。
业务人员需要指导模型,并提供必要的知识和信息。
期望过高:
期望模型在没有业务人员参与的情况下,能够独立完成任务。
忽略了模型需要学习和适应企业特定需求的过程。
宣传与现实差距:
媒体宣传过于夸大模型能力,导致不切实际的期望。
企业内部为了拿下项目,可能存在不合理的描述。
企业内部上下文的重要性
专家知识:
业务专家的知识和经验是模型达到预期效果的关键。
需要将专家的品味和偏好融入到模型中。
企业数据语义层:
需要一个智能、干净、统一的语义层,让业务人员和工程师可以共享数据。
Palantir 的成功在于其构建的数据语义层,为大模型应用奠定基础。
Ontology 与低代码:
Ontology 的作用是将数据进行结构化和语义化。
低代码工具可以帮助业务人员更方便地使用 Ontology 中的数据。
未来业务软件的演变
数据湖与智能体:
未来可能出现一个大的数据湖,上面运行着强大的智能体。
智能体可以直接与底层数据交互,无需与传统软件交互。
业务软件的折叠:
随着智能体的发展,传统业务软件可能会被折叠。
用户更关注结果,而非具体的操作步骤。
技术角度的解释:
- 智能体可以直接调用底层数据,减少了中间环节,提高了效率。
Palantir 的案例分析
长期积累:
Palantir 多年来的积累,为大模型的应用做好了准备。
其 CEO 认为,终于等到了大模型时代的到来。
产品架构:
核心概念:对象、连接、动作。
Object
广告机会与BISHENG的目标用户画像
核心议题
AI 在企业落地的挑战与机遇
BISHENG.ai 的定位与服务
目标用户画像与合作模式
关键论点/分论点
- 企业 AI 转型的需求与痛点
缺乏清晰的落地场景
对 AI 能力的认知不足
预算与企业规模的匹配问题
- BISHENG.ai 的解决方案
开源 AI 平台 BISHENG.ai
提供企业 AI 转型咨询与落地服务
撮合 BISHENG 达人提供低成本部署服务
- 目标用户画像
细分领域头部企业
中型企业,预算几十万到几百万
愿意尝试开源技术
务实,对 AI 有合理预期
- 合作模式
与 ISV 合作,提供 AI 模块
发展城市合作伙伴,提供本地化服务
BISHENG.ai 转商机给合作伙伴
- 企业 AI 转型的需求与痛点
重要观点/洞察
- 避免“不就是”的思维陷阱
- 对复杂技术保持谦逊和学习的态度
- Palantir 的启示
- 学习其产品文档的易懂化
- 开源项目的价值
吸引潜在客户
建立社区生态
- 找到正确的客户
- 匹配企业需求与服务能力
- 避免“不就是”的思维陷阱
行动建议/方法论
- 企业 AI 转型
从小规模试点开始
关注细分领域的应用场景
寻求专业咨询与技术支持
- 使用 BISHENG.ai
访问 BISHENG.ai 官网
在 GitHub 上 star 项目
加入社区群,与核心成员交流
- 企业 AI 转型
提及的资源
BISHENG.ai 开源 AI 平台 (BISHENG.ai)
BISHENG.ai GitHub 仓库
BISHENG.ai 社区群
广告机会
企业 AI 转型咨询与落地服务
BISHENG 达人部署服务
IS


