01
业务描述
流程、例外、数据可信度、真正的决策人，往往无法完整写进需求文档。
ISAAC · ENTERPRISE AI
企业 AI落地服务
把 AI 能力交给最懂业务的人。
从一个可量化的小场景开始。
业务诊断共建落地持续陪跑
业务
人
AI
能力
01 / 14
The real bottleneck
AI 落地最大的损耗，
发生在业务与技术之间
02
技术转译
外部人员重新理解、整理并抽象需求，每一次转译都丢失上下文。
03
系统执行
系统看似完成，实际偏离现场；员工绕开它，项目停在 Demo。
隐性知识持续流失
02 / 14
问题不只是模型能力
Adoption before automation
如果一项技术以
“取代员工”为起点，
落地一定遇到阻力。
“取代员工”为起点，
落地一定遇到阻力。
员工担心岗位、部门担心权责、管理层担心风险。真正的设计对象不只是工作流，还包括组织如何愿意使用它。
使用意愿
权责边界
培训与维护
03 / 14
先建立共同利益
Proof, not promise
先让一个真实任务，变快、变稳、可复用
≈30分钟
原工作流：采集一位肝癌患者的科研数据
→
≈5分钟
优化后：信息识别、结构化与填写形成连续流程
01院内资料采集
02字段识别与校验
03患者院外补充
04科研表格沉淀
案例口径来自既有交付记录；时间为约数，不外推未经验证的财务收益。
04 / 14
可量化的小场景先跑通
A moving foundation
底座像流沙，
能力必须留在企业内部
今天最好的标准方案，半年后可能被新模型重新定义。企业真正需要建立的，是持续发现需求和调整方案的能力。
应用产品 · 变化最快
工作流与工具
模型与能力边界
企业业务知识 · 最稳固
05 / 14
把调整权留给业务现场
Domain experts × AI
专业的事仍交给专业的人。
改变的是他们调用 AI 的方式。
医
医生
最了解诊疗流程、例外情况和数据边界。
采
采购
最了解供应关系、风险与真正的判断标准。
销
销售
最了解客户语境、决策链和成交阻力。
管
管理者
最了解组织实际如何运行、谁能推动改变。
06 / 14
AI 是新的业务表达能力
Four service layers
不是几节课，
是一条从“会听”到“会创造”的路径
01
通识资源层
公开教程、网课、Skill 与 Workflow 资料整理，建立共同语言。
认知地图
02
业务诊断层
进入真实流程，寻找高频、重复、成本高且可量化的任务。
机会清单
03
落地培训层
把业务需求转成 AI 任务，共同完成原型、部署和修改。
可用原型
04
持续陪跑层
随模型更新持续补充方法，让内部人员可以维护和调整。
内部能力
07 / 14
收费价值在结果而非信息
From signal to system
五步，把一个想法变成
企业能自己维护的系统
01
发现场景
观察真实工作，而不是从工具清单出发。
02
计算 ROI
先算时间、频次、成本与边界。
03
原型验证
用真实数据完成小范围闭环。
04
共同搭建
让业务人员参与规则和例外设计。
05
内部维护
留下文档、方法和持续调整能力。
08 / 14
交付的是结果与调整权
The ROI canvas
先问五个问题，
再决定要不要做
?
这项工作现在需要多少人工时间？
?
它每周或每月重复多少次？
?
原型、部署和维护成本是多少？
?
数据、合规和错误风险在哪里？
?
谁使用、谁判断、谁维护？
可持续价值 =
节省时间 × 重复频次 × 采用率
− 搭建与维护成本
节省时间 × 重复频次 × 采用率
− 搭建与维护成本
一个小场景稳定产生正向回报，再扩大投入。比一次性押注“大而全”更容易通过组织和预算验证。
09 / 14
小步验证不是小目标
AI in the physical world
技术不是藏在后台，
它也可以成为现场体验
AI 互动电话亭用算命、过去的自己与未来的自己等叙事，降低用户对信息采集的抵触，同时形成可分享体验。
现场实时字幕主持人讲话，现场观众同步看到内容；可用于大型活动与跨语言沟通。
10 / 14
Breadth with a reason
从硬件到 App，
能力最终要变成用户愿意使用的产品
LingVibe环境识别、智能调香与硬件体验。
游戏地球把内容库变成可探索的 3D 世界。
独立 App从产品开发到上架与支付链路。
11 / 14
作品不是终点，使用才是
Evidence of adoption
不只把产品做出来，
也把人聚到一起
AI Coffee Chat线下小场交流，让需求、产品和合作在真实对话中发生。
4 次上海线下 Coffee Chat，在连续组织中验证主题与人群。
20 / 1600入选红杉资本 14 天孵化营；该期 1600 个团队申请，20 个入选。
12 / 14
真实反馈比假设更快
Why Isaac
懂技术，但从采用与结果出发
I
“只有真正有人愿意使用、愿意付费，一个东西才成为产品。”
能直接完成原型、前端、部署与技术判断，减少二次转译。
独立开发并上架 App Store，跑通支付与运营链路。
理解 Workflow 进入医院、活动和企业现场时的实际约束。
把员工培训、办公室政治、担心被替代等阻力放进方案设计。
通过公开内容、线下社群和孵化营持续验证需求。
先判断是否真的需要昂贵部署，再选择最小可行的解决路径。
13 / 14
技术能力服务于业务结果
Start with one real task
带着一个
高频任务来。
不用先买一个大系统。先选一个重复、耗时、可量化的场景，用四周验证它是否值得继续投入。
14 / 14