摘要：一个 AI 功能从单次对话走向团队使用，需要补齐任务模型、知识来源、权限、版本、额度和可观测性。本文给出一套简洁的产品化检查框架。
关键词：AI 产品设计、AI 工作台、企业 AI、任务编排、AI 可观测性、知识库权限
一个文本框、一个提交按钮和一段流式输出，足以证明模型能完成某项任务。但当多个成员开始反复使用，同一个功能很快会遇到新的问题：任务跑到哪里了？用了哪些资料？谁能看到结果？模型升级后旧成果是否还能复现？失败一次算不算消耗额度？
这些问题与提示词技巧关系不大，却决定了 AI 功能能否成为稳定的团队工具。
图 1：AI 能力按任务组织，并同时展示资料状态、额度和最近任务。截图取自标脉云的真实业务界面。
第一件事：把对话变成任务
对话界面适合探索，但企业流程更需要明确的任务对象。一个任务至少应包含类型、输入、创建人、状态、版本、结果和错误信息。
常见状态可以保持简单：
DRAFT -> QUEUED -> RUNNING -> SUCCEEDED-> FAILED
SUCCEEDED -> REVIEWED -> APPROVED
状态机让前端不必猜测“模型是不是还在处理”，也让异步重试、通知和审计有统一依据。对于耗时较长的文档任务，关闭页面后任务仍应继续，用户回来时可以恢复查看。
失败也要有稳定语义。用户输入错误、资料解析失败、模型服务超时和系统内部异常不应混成同一个“生成失败”，因为它们对应不同的下一步动作。
第二件事：让知识来源成为一等对象
团队 AI 的回答通常依赖企业资料。资料不能只是上传目录，还要有解析状态、批准状态、版本和访问范围。
图 2：资料总数、可使用状态和批准状态被分别管理。
一个实用原则是：未经批准的资料不进入正式分析范围；已经被替代的版本不再参与新任务；每次任务记录实际使用的资料 ID 和版本。这样，用户才能解释同一个问题为什么在不同时间得到不同结果。
知识来源还包括业务数据、外部公开信息和用户临时上传文件。不同来源需要不同的保留策略。临时文件可以随任务过期，企业资料则需要长期版本管理，公开信息还要保留来源和更新时间。
第三件事：权限要覆盖输入、任务和成果
只保护文件下载地址是不够的。权限检查需要贯穿整个链路：用户能否选择某份资料、能否启动某类任务、能否查看其他成员的任务、能否导出最终成果。
对于团队产品，RBAC 是清晰的起点。角色决定基本能力，项目或组织范围决定数据边界，必要时再增加资源级授权。检索和模型调用前必须应用权限过滤，避免无权内容进入上下文。
同时要考虑成果继承权限的问题。AI 输出如果引用了受限资料，结果本身也应该受到相应限制，不能因为变成一段新文本就自动获得更宽的可见范围。
第四件事：版本化输入与输出
AI 结果并不像普通数据库查询那样天然可复现。模型、提示模板、检索索引和输入资料任意一项变化，都可能导致不同答案。
不必保存所有底层细节，但至少应记录：
- 模型与参数版本；
- 提示模板版本；
- 资料与业务数据版本；
- 用户原始输入；
- 初始输出和人工修改；
- 生成时间与任务 ID。
当用户编辑 AI 成果时，建议保留新版本，而不是直接覆盖。这样既支持回退，也能区分模型生成内容与人工确认内容。
第五件事：额度和可观测性必须一致
按次数、Token 或计算时长计费都可以，但用户看到的额度必须与后台计量一致。任务创建、执行失败、自动重试和人工重新运行分别如何计费，需要有确定规则。
可观测性也不只是统计调用次数。产品团队至少需要知道：
- 各任务类型的成功率与耗时；
- 失败原因分布；
- 平均检索片段数与空召回率；
- 用户重新生成和人工修改比例；
- 从生成到批准的时间；
- 单次有效任务的成本。
这些数据能够帮助判断问题究竟来自模型、资料、交互还是流程设计。没有这层观测，团队很容易把所有反馈都归结为“模型不够好”。
一套不过度设计的实现顺序
AI 产品化并不意味着第一天就建设庞大的编排平台。更简单的落地顺序是：
- 先建立统一任务表和清晰状态；
- 再把知识来源做成带版本和权限的资源；
- 为高风险任务增加人工复核状态；
- 记录模型、模板和输入版本；
- 最后根据真实使用量完善额度、队列和成本优化。
每一步都解决已经出现的具体问题，也为下一步保留清晰接口。不要为了未来可能存在的十种模型，提前写一个无人能维护的通用编排系统。
结语
AI Demo 证明的是模型“可以做”；团队工作台要证明的是系统“可以持续、可控地做”。
任务状态、知识来源、权限、版本和可观测性，是这个转变中最基础的五块拼图。补齐它们之后，模型能力才真正进入了软件工程的范围。