01 原始约束
知识在多处、身份只有一套、口径不能错
| 类型 | 具体表现 |
|---|---|
| 组织 | 知识分散在部门系统、公文、制度文件与个人手里，没有统一出口 |
| 技术 | 已有统一身份认证体系，新系统必须对接 SSO，不能另建账号体系 |
| 合规 | 数据不出校；不同身份可见的知识范围不同，权限必须在服务端收口 |
| 业务 | 教师使用习惯差异大，无法要求全员学习一个通用工具 |
| 运维 | 校方希望后续能自行上架新智能体，而不是每个需求都排期 |
02 被排除的路径
三条最省事的路，都会在半年内失败
它们不是技术问题，是采纳问题与责任问题。
排除 01
先做一个通用聊天入口，再逐步加功能
老师不知道一句话该问谁；命中不了专项能力时，回答会滑向泛泛而谈，几周后就不再有人打开。
入口统一了，场景没有
排除 02
直接采购外部 SaaS 模型
数据出校、口径不受控、无法按校内身份收口。一旦出现「答案说错了」的情况，学校无法自证知识来源。
省了部署，丢了可解释性
排除 03
做一个大而全的万能对话框
没有场景边界就没有验收口径：做完了也无法回答「它到底替老师省了多少事」。
无法验收，就无法移交
03 实际切口
一句入口 + 多个场景工作台 + 一个可增长的广场
先让高频场景跑出采纳，再谈生态。顺序反过来，项目会变成一次性的演示。
切口
- 统一入口：首页提问或上传文件，自动路由到对应的专项助手
- 场景工作台：出题、备课、评课、公文检索、项目预审各成独立工作台
- 知识边界：答案只来自校内知识库与公文，逐条可回溯到原文段落
- 身份收口：对接统一身份认证，权限判断在服务端完成，前端只负责呈现
- 可增长：智能体广场按教学 / 办公 / 科研 / 生活四类持续上架
代价
- 先做场景意味着前期覆盖的功能看起来不「全」，推广时要解释取舍
- 每个新场景都需要整理对应的知识源，这部分工作在校方一侧
- 上线节奏受知识治理进度约束，比「先接模型再看效果」慢
04 可验证结果
能公开的部分
使用量与采纳率等运营指标未经校方授权，不在此展示。
| 项目 | 结论 | 证据状态 |
|---|---|---|
| 落地形态 | PC 端 + 移动端 AI 校园门户，对接学校统一身份认证 SSO | 公开信息 |
| 场景覆盖 | 智能体广场按教学 / 办公 / 科研 / 生活四类持续上架 | 公开信息 |
| 教师采纳率 | 含各场景活跃数据 | 未公开 |
| 答案溯源命中率 | 含抽样评估结论 | 未公开 |
05 能力移交
校方要能自己上新智能体
如果每加一个场景都要找我们排期，这个平台就退化成了一个外包项目。
移交包
- 智能体配置手册：提示词、工具、知识源如何绑定
- 知识源接入 SOP：新文件如何入库、如何做权限标记
- 权限矩阵说明：不同身份可见范围的配置方式
- 运营手册：智能体广场的上架、下架与效果回看
时间线
- 交付期内完成校方信息中心的操作培训
- 由校方独立完成一个新智能体的上架作为验收演练
- 此后我们退为二线支持与版本升级评审
06 复用资产
沉淀下来的四样东西
智能体编排模板
场景工作台的通用骨架，新场景可在模板上配置而非从零开发。
知识源接入适配器
文档、公文与业务系统三类接入方式，复用至其他高校。
身份鉴权中间件
与统一身份认证对接的标准件，可复用到政务与企业场景。
判断规则
答案没有出处就不上线；权限判断只在服务端做，前端不承担鉴权。
07 退出条件
客户什么时候不再需要我们
三条同时成立，我们退出日常在场。
退出判定
- 校方信息中心可独立新增智能体、接入新知识源，无需我们介入
- 权限变更与身份对接调整由校方独立完成
- 智能体广场的运营与效果回看由校方独立承担
此后伊索只保留模型与平台升级评审、疑难问题二线支持。
你们的知识，准备怎么让模型看得懂？
电话里说说你的知识源与权限结构，我们可以先判断：哪些场景能先跑出采纳。