把 AI 装进企业的业务流程，不是给企业一个聊天窗口。
| 节点 | 做什么 | 什么算过 | 客户得到什么 |
|---|---|---|---|
| 需求交流 | 聊业务，不聊技术 | 找出一件真实的、值得先做的事 | 一次不带销售目的的对话 |
| AI 诊断 | 梳理流程、数据、人员、系统现状 | 产出诊断结论与场景优先级 | 一张 AI 现状图 |
| Demo | 针对选定场景做可运行原型 | 在真实数据上跑得通 | 看见所选场景实际运行的效果 |
| 小型 POC | 限定范围、限定时间上线试运行 | 业务方真的在用 | 一个能日常使用的东西 |
| 正式项目 | 扩大范围、接入更多系统 | 纳入正式业务流程 | 稳定运行的业务能力 |
| 复制 | 把验证过的做法推向其他部门或单位 | 第二个场景不从头开始 | 边际成本下降 |
节点走到最后一步，问题就变成：这套东西交到客户手里，能不能自己转下去。
系统是活的，会长、会变，交付只是起点。
底座和第一块能力搭好调通，先见效果、先受益。这一步风险最低，也最容易让人信。
客户侧同步留一到两个能跟着项目实操长起来的人。边做项目边带，等我们撤了，运营能力已经养在客户内部。
维护和配置的活儿交给客户团队，规则自己改，模块自己加。
系统自己演化，决策权在客户，我们转成兜底和陪跑。
内核为谁设计，决定系统长什么样。
过去四十年的企业软件（ERP、HR、CRM），内核都是为"人填表"设计的。界面是主体，逻辑藏在表单字段背后，接口是后来补的，智能体是最后硬塞进去的。
| 传统路径 | AI 原生路径 | |
|---|---|---|
| 构建顺序 | 界面 → 接口 → 硬接 Agent | Agent 引擎 → 工具集 → 最薄的界面 |
| 内核为谁设计 | 为人操作设计，AI 是附加功能 | 为 AI 理解设计，界面是接入层 |
| 交互方式 | 坐在电脑前填表单 | 说话、表单、手机、电脑都行，内核不动 |
| 数据怎么用 | 沉睡在库里，靠人导出做分析 | 业务一发生即整理成结论，主动推送 |
| 改流程 | 重做前端，慢且贵 | 流程变了系统跟着变 |
业务规则、单据流转由智能体直接驱动，不依赖人手动录入；数据从产生那一刻就是结构化、可计算的。
为什么：AI 能读懂的内核，人自然也能读懂；反过来不成立。
不再等人导表做透视。业务一发生，系统自动整理成管理者该看的结论，主动推到面前。
为什么：数据的价值在"发生时"最大，滞后即贬值。
界面是可插拔的接入层——说话、表单、移动端、PC 端都能用。今天用表、明天用对话，内核不动。
为什么：交互方式会变，内核不该跟着变。
功能模块装上去，界面自动长出来；流程变了系统跟着变，不用为每次调整重做前端。
为什么：企业流程本就在变，系统不该是变化的瓶颈。
管物（ERP 那一极）和管人（HR 那一极），过去是两套系统、两套语义、两个数据库，管理者被迫在中间补缝。AI 原生用一个底座同时承载两极，语义在底层打通。不是把两套系统集成起来，是从一开始就是一个系统。
底座立住之后，长在上面的第一块能力是智能体。它不是助理，是分身。
"AI 助理"这个说法有个隐含前提：它是另一个人。只要是另一个人，就躲不掉信息衰减、理解偏差、沟通损耗。
分身的定位是注意力副本：它跟随同一个人的关注点，判断标准与本人一致。与其说它在代替人做事，不如说本人的注意力被复制了一份，在更多地方同时生效。
三层能力缺一不可：
意图、上下文、权限边界。
拆解任务、规划步骤、调用工具。
写回系统、触发动作、全程留痕。
市面上多数"智能体"停在前两层。看起来聪明，做不成事。差的是第三层——能不能真的把结果写回业务系统，而不是吐一段建议让人自己去执行。
多数团队在模型之上做应用。我们在下面还铺了一层：Agent 原生互联数仓。
它连接 IM、CRM、ERP、MES、OA，但不持有任何一个系统的数据库凭据。原始数据留在原处，进来的是摄入快照；消化之后沉淀下来的，是带判断的认知，不是又一份拷贝。
三个设计取舍：
不在信息价值最低的时刻，做关于它未来价值的最重要决定
客观事实只提取一次、不可修改，不同视角的判断建在同一块地基之上。
重点结论主动呈现，其余内容全覆盖留痕、随时可回溯。
完整展开是另一场的内容。
长在 IM 里（企业微信、飞书），不另造一个要登录的网页。
人在哪里办公，智能体就在哪里。多一个系统就多一道门槛，多一道门槛就少一半使用率。
智能体要干活，得有东西可查。知识库常被理解成"上传文档 + 问答"，那只是检索。
检索和记忆不是一回事：搜索每次从头来过，没有积累；记忆是平时持续消化，问的时候先调已有的总结，需要了再回溯原文。
人回答"上周二群里聊了什么"，靠的不是重读一遍聊天记录，而是调取当时就形成的印象。知识库要做的是后者。
检索解决"查得到"，知识库要解决"用得上"。做到后者，要做六件事：
| 要解决的 | 具体是什么 | 常见做法的问题 |
|---|---|---|
| 多源接入 | 文档、表格、图片、录音、系统里的数据 | 只接了 PDF 和 Word |
| 结构化抽取 | 把非结构化内容变成对象、属性、关系 | 把文档切成块就当处理完了 |
| 权限分级 | 谁能看什么，跟组织架构对齐 | 全员可见，涉密内容不敢放 |
| 溯源引用 | 每句话能查到出处 | 答得很流畅，没人知道依据在哪 |
| 持续更新 | 知识会过期，要有更新机制 | 一次性导入，半年后全是旧内容 |
| 业务挂载 | 接进流程里，不是孤立的问答窗 | 单独的网页，没人打开第二次 |
其中有一条最容易被忽略：文档切碎之后，上下文拼不回来。常见做法是把文档切成小块再向量化，检索确实方便。但语音的语气停顿、PDF 的签章排版、Excel 的颜色标注，格式本身就是信息的一部分。切分是消化的活儿，不该在存储阶段干。
权限在这套系统里不是附加功能，而是从第一天起就贯穿全线的架构约束。新数据源接进来默认无人可见，任何"可见"都必须是显式授权的结果——不存在默认权限，也不继承原系统的权限设置。对数据敏感的企业，这不是加分项，是入场券。
数据不搬家这条，在知识库上照样成立。少一个副本，就少一个攻击面。
底层只保留三个概念——对象、属性、链接，具体语义由场景定义。
这是 Palantir 本体论（Ontology）的做法。早期他们给"人"建一张表、给"资金"建一张表，很快就发现换个客户就不通用，于是把抽象层级拉高，让每个客户的场景自己去定义语义。
我们沿用这个思路。生产条线的"工单""设备""工艺卡"和管理条线的"岗位""项目""考核记录"，在底层是同一套结构，差别只在场景定义的语义层。这也是为什么一个场景做通之后，能复制到下一个场景。
工艺文件、设备手册、质检记录、历史工单 → 知识库 → 专业 Agent → 检索、比对、辅助判断
制度规范、项目复盘、客户资料、内部经验 → 知识库 → 专业 Agent → 检索、比对、辅助决策
企业管理透明化平台（HR 动态管理套件），落在"人"这一极。已在一家芯片封测企业上线一期，四类角色全流程贯通。
规范动作写进制度不难，难的是它们有没有按时发生、做到什么程度，长期没人说得清。这套平台要解决的正是这一点：让制度里要求的每个管理动作按时触发、过程留痕、结果可评。
传统 HRM 管的是人事信息，这套平台管的是管理行为。差别不在功能多少，在观察对象换了：
| 传统 HRM | 本平台 | |
|---|---|---|
| 管什么 | 人事信息：档案、考勤、薪资、社保 | 管理动作：访谈、辅导、转正、调薪有没有发生 |
| 谁在用 | 主要是 HR 部门 | 高层、中层、HR、员工四类角色 |
| 何时介入 | 事后统计与审批 | 节点前置，窗口到期前触发待办 |
| 流程怎么改 | 固化在系统里，调整需要开发 | 规则可视化配置，业务自己改 |
| 角色 | 打开看到 | 得到什么 |
|---|---|---|
| 高层 | 组织透明驾驶舱：各团队动作完成率、闭环率、逾期分布 | 管理者干多干少，第一次可评价 |
| 中层 | 下属卡片：每个人的下一个关键节点 + 待办角标 | 从"靠脑子记"到"系统催办" |
| HR | 全员动态档案 + 规则引擎：转正、调薪、晋升窗口自动预警 | 从报表里解放出来，做人才策略 |
| 员工 | 个人工作台：待办、指派任务、成长档案 | 成长路径清晰，贡献被记录 |
部署上支持私有化，数据归企业自己。
同一副骨架不只承载一个条线。销售、交付、售后，业务内容不同，底下是同一类东西：任务的规范执行与协同——谁负责、什么节点、怎么流转、有没有闭环。规则换一套，就能扩进这套体系。
功能可以外包，能力不能。判断一套系统最终属于谁，看的是项目结束时，什么留在了企业内部。
担心的：数据被搬走，多一个副本多一个敞口，换供应商时说不清。
怎么保证：原始数据留在原系统，进来的是摄入快照；底座不持有任何系统的数据库凭据；支持私有化部署。
依据：「原始数据留在原处，进来的是摄入快照」「少一个副本，就少一个攻击面」
担心的：沉淀下来的认知长在服务商那边，人一换、合作一停，认知跟着走。
怎么保证：认知沉淀在企业自己的知识库里，带出处、带分级；谁能看什么由企业授权，不继承原系统的权限设置。
依据：「新数据源接进来默认无人可见，任何可见都必须是显式授权」「消化之后沉淀下来的，是带判断的认知，不是又一份拷贝」
担心的：AI 替人下判断，出事之后责任链断了。
怎么保证：智能体只做呈现，不做决策；关键节点由人确认拍板；每一次动作全程留痕，可回溯到依据。
依据：「不做决策，只做呈现」「重点结论主动呈现，其余内容全覆盖留痕、随时可回溯」
担心的：规则改不动，加一个字段要等排期，最后离不开服务商。
怎么保证：规则可视化配置，业务自己改、模块自己加；配置与运维能力移交给企业团队，我们退到兜底与陪跑。
依据：「决策权与系统演化在客户，执行与运维兜底在我们。房子是客户的，物业帮打理。」
担心的：第二个场景从头再来，上一轮的投入归零。
怎么保证：底层不预设对象类型，只保留对象、属性、链接，语义由场景定义；底座立住之后按需加能力，一个场景做通即可复制到下一个。
依据：「搭积木，不推倒重来」「一个场景做通之后，能复制到下一个场景」
管家模式的四步，换个角度看就是主权的移交曲线：能力在前面长，我们在后面退。
| 阶段 | 挪到企业手里的 | 我们退到哪一步 |
|---|---|---|
| 托管跑起来 | 用起来的能力，与第一批沉淀下来的数据 | 站在系统后面，随叫随到 |
| 同步培养内部人手 | 一到两个能动手改的人 | 从「我们做」变成「一起做」 |
| 逐步移交 | 配置权、规则权、模块增删权 | 只在异常和升级时介入 |
| 自主运营 | 系统演化的决定权 | 转成兜底与陪跑，可随时退出 |
主权不是交付那天交出去的，是每一轮交付都往企业手里挪一点。挪得动的叫能力，挪不动的叫依赖。
企业最终握住的不是一个系统，是三件东西：改得动、换得掉、带得走。