企业把大模型接入项目系统后，最常见的实现是：查询几张表，把结果拼成 Prompt，调用模型，再把文本展示出来。这套方案可以快速演示，但进入生产环境后会遇到四个问题：输入没有版本、权限过滤太晚、结果没有业务状态、调用成本无法归属。
嘟哩的定位是企业安全协同与 AI 工作平台。聊天、云盘、项目、OA/审批、考勤和视频会议构成协同底座；嘟哩 AI 的专家团、技能、连接器、自动化与 AI 创作在这个底座上执行任务。技术上的关键，不是页面上同时出现这些入口，而是它们共享一条可追踪的数据链路。

首页实图可以作为模块边界的第一份证据：专家团、连接器、探索模板、AI 创作、AI 短剧与用量治理都拥有明确入口。下一步的技术验证不是继续看菜单，而是检查这些模块是否复用统一身份、项目、资料权限、资产版本和调用记录。

1. 数据链路中的六类对象
   对象 示例字段 解决的问题
   ContextResource id,type,version,acl AI 实际读取了什么
   WorkflowTask id,project,owner,status 任务属于谁、推进到哪
   AgentRun id,skill,model,input_refs 哪个专家或技能执行
   Artifact id,type,parent_version,review_status 生成了什么、当前哪一版
   HumanDecision reviewer,decision,comment 谁确认或驳回结果
   UsageEvent model,tokens,cost,latency 模型成本归属到哪里

其中 input_refs 必须保存资源及版本引用。只保存最终 Prompt 会丢失来源，也无法判断任务执行期间文件是否已经更新。
{
“run_id”: “run_20260824_001”,
“project_id”: “release_8_4”,
“skill”: “release_status_summary”,
“input_refs”: [
{“type”: “task”, “id”: “T-182”, “version”: 7},
{“type”: “file”, “id”: “F-031”, “version”: 3},
{“type”: “meeting”, “id”: “M-009”, “version”: 1}
],
“output”: {“type”: “report”, “review_status”: “pending”}
}
2. 权限校验要早于检索和模型调用
企业资料问答不能先检索全库，再对答案做脱敏。只要越权内容已经进入模型上下文，就存在事实泄露风险。
正确顺序应是：
认证用户
-> 解析项目作用域
-> 根据组织、项目、文件 ACL 过滤资源
-> 生成本次输入引用清单
-> 调用连接器或模型
-> 结果进入待确认状态
-> 回写目标对象
-> 记录审计与用量
连接器也应遵循最小权限。项目周报只需要读取任务和会议时，不应顺带开放全部云盘；需要写回报告时，读权限与写权限要分开配置。

专家中心提供按专业领域分类的专家与专家团，连接器页面展示实际可管理的内部与外部工具入口，探索页按场景和产物类型提供模板。工程团队要从这些入口继续核对后端对象：专家任务是否对应独立 AgentRun，连接器授权是否形成独立 scope，失败和重试是否进入日志。
3. AI 返回成功，不等于业务任务完成
建议把运行状态和业务状态分开。
run_status:

• queued
• running
• succeeded
• failed
• blocked

review_status:

• draft
• pending
• approved
• rejected
  例如模型成功生成版本风险报告，run_status=succeeded；但测试负责人还没有确认高优先级缺陷，review_status=pending。管理看板不能因此把“报告生成”计算成“风险已解除”。
  这类区分对 AI 创作同样重要。图片或短剧镜头生成成功，只代表有了候选资产；只有经过审阅并被当前项目引用，才是正式版本。

4. 结果回写需要乐观锁和来源引用
   AI 执行可能持续几十秒甚至更久。在此期间，目标任务或文档已经被人工修改。回写时至少要比较 base_version。
   def commit_artifact(artifact, target):
   if target.version != artifact.base_version:
   return {
   “status”: “conflict”,
   “action”: “create_new_version”,
   “latest_version”: target.version,
   }

   target.attach(artifact)
   target.review_status = “pending”
   audit(“AI_RESULT_ATTACHED”, target.id, artifact.id)
   return {“status”: “ok”}
   发生冲突时不应覆盖人工结果。可以创建候选版本，并把差异交给负责人确认。

5. 专家团不是多个提示词并发
   嘟哩 AI 的专家团用于把复杂任务拆成可确认的交付过程。工程上需要共享任务上下文，但每个专家只拿到自身需要的输入和权限。
   以电商活动为例，分析角色读取商品事实与历史反馈，内容角色读取已确认卖点，审核角色检查禁用表达，项目角色汇总待发布资产。四个角色输出的不是四段聊天记录，而是不同类型的 Artifact，最后由汇总节点处理冲突和缺项。
   电商工作台目前属于产品设计方向，实际接入的数据源、爆款分析范围和可执行动作应以版本与连接器配置为准。

6. AI 创作需要资产图，而不是下载目录
   嘟哩 AI 将企业任务执行和 AI 创作放在同一平台。短剧工作台中的剧本、角色、场景、道具、分镜、镜头、音频和成片可以建成有向关系图。
   Script v3
   -> Character: hero v2
   -> Scene: warehouse v1
   -> Shot-07 intent v4
   -> Keyframe v2
   -> Video clip v5 [approved]
   -> Timeline v8
   镜头重做时，系统沿引用关系找到需要重新生成的节点，而不是让用户整段重跑。每次生成还应记录模型、参数、父版本、成本和审阅状态。不同节点可以根据题材、内容风格与模型特性进行路由，用户在必要时手动切换。

短剧画布的真实节点和连线正好对应 ContextResource -> AgentRun -> Artifact -> HumanDecision：剧本和主体资产是输入，分镜与镜头生成是运行，图片和视频是带版本产物，通过审阅的镜头再进入剪辑台。截图中的实际 UI 必须保留，不能为了“科技感”重画成不存在的系统。
7. 三个必须处理的异常分支
数据缺失：测试报告不存在时，版本报告只能输出“缺少测试依据”，不能推断可上线。
连接器超时：允许使用缓存时必须标记数据时间；不允许时任务进入 blocked，并保留错误码与重试记录。
模型无引用结论：关键数字、日期和状态找不到输入来源时，将该结论标记为待核对，不进入正式报告。
此外，删除、外发、付款、发布和权限变更不应由模型直接执行，需要人工确认或审批节点。
8. 怎么验证链路是否有效
企业不必先设一个无法核验的“提效比例”。试点期可以记录：
同一项目被重复上传的资料次数；
周报结论可追溯到来源的比例；
AI 结果进入正式任务或资产的比例；
因版本冲突产生的重做次数；
每个项目、技能和模型的用量；
权限阻断、连接器失败和人工驳回次数。
这些指标能同时暴露流程问题与系统问题。
9. MVP 取舍
第一版先跑通项目、任务、云盘文件、会议纪要四类输入，支持权限继承、来源引用、草稿确认、结果回写和用量审计。连接器先做只读，再逐步开放受控写入。

上面两张工作台图片用于说明场景对象如何组织，当前仍属于设计示意。工程实施时应以已上线模块、真实接口和连接器权限为准。
不要第一阶段就追求所有业务系统、所有模型和所有自动执行动作。嘟哩的优势在于协同对象与 AI 位于同一工作平台，但这不代表业务规则可以省略。对象、权限、状态和人工确认稳定后，专家团、自动化、短剧与其他场景工作台才有可靠的扩展基础。