企业接入 AI 前，为什么要先整理工作上下文

项目经理问“这个版本能不能上”，AI如果只看一份周报，只能复述汇报；只有同时读取版本目标、需求、缺陷、测试结论和发布检查，答案才有依据。企业接入AI前，先整理工作上下文，比先比较模型参数更重要。文中给出可执行的检查方式，并明确真实数据、权限配置、责任人和审计记录必须同时成立。

如果项目经理每天傍晚都要在群里问一遍“这个版本到底还能不能上”，先别急着给他加一个 AI 助手。AI 能不能回答，不取决于它会不会写周报，而取决于版本目标、需求、测试、缺陷和发布材料是不是同一条数据链。

很多企业已经有聊天、云盘、项目系统和知识库，但这些工具只是在“同时存在”。需求在项目里，验收口径在会议纪要里，测试结论是一张截图，回退方案还在某位工程师的电脑上。人都要反复追问，AI 更不可能凭空知道事实。

先看一次典型的“AI 误判”

周一 9:20，项目经理让 AI 回答“V8.5.2 本周能不能上线”。他上传了一份周报和两张缺陷截图，AI 根据“已完成 18 项，剩余 3 项”给出了乐观判断。但真正阻断上线的，是一条没有写进周报的登录数据迁移问题，以及还没有确认的回退方案。

这不是模型“不够聪明”，而是它只看到了被上传的文件。版本目标在项目页，验收标准在需求评审群，缺陷在测试系统，回退方案还在运维的本地文档里。输入不完整，结论再流畅也不能用。

工作上下文不是把所有文件喂给 AI

工作上下文至少包含五类对象：谁在发起任务、他有权看什么；当前处理的是哪个项目或客户；任务走到了什么状态；结论由哪些文档和数据支撑；AI可以读取、生成还是回写。

这五类对象缺一块，回答就会变形。只有资料没有状态，AI不知道哪份是最新版；只有任务没有验收标准，AI无法判断是否完成；只有连接器没有权限继承，AI可能读到不该出现的数据；只有聊天记录没有业务对象，历史讨论很难被可靠引用。

先整理高频问题，再整理数据

不要一上来做“全公司知识工程”。先收集管理者和一线员工反复问的问题，例如：本周有哪些延期、客户最新确认了什么、哪个版本有阻断缺陷、这份报价是否已审批、直播间高频异议是什么。

每个问题都倒推四件事：答案来自哪里，哪个字段代表当前状态，谁有权查看，回答后要不要触发动作。这样整理出来的是可工作的上下文，不是一个看似庞大的资料仓库。

以版本上线判断为例，最低输入应包括版本目标、范围内需求、验收标准、测试用例执行结果、未关闭缺陷、测试结论、发布说明和回退方案。AI的职责是汇总证据、指出缺口并给出引用，而不是替负责人批准上线。

嘟哩的价值在于让上下文留在工作现场

嘟哩已有聊天、云盘、项目、知识库、组织权限以及嘟哩AI入口。合适的做法，是让项目资料继续归项目、云盘资料继续受原权限控制，再通过连接器和应用助理把可用数据交给AI。员工不需要把文件下载后重新上传，也不需要在不同对话里重复解释背景。

这里要分清现有能力和工作流建设。云盘、项目、专家团、技能、连接器提供底座；版本目标、需求验收、测试用例、发布检查等结构化数据，需要在具体场景中持续补齐。没有后者，AI项目只能做摘要，不能给出可靠的上线判断。

一个小试点就能看出差别

选一个正在推进的真实版本，连续运行两周。要求所有需求写明验收标准，测试结论绑定版本，发布材料进入知识库；然后让嘟哩AI回答三类固定问题：当前目标是什么、卡点在哪里、能否上线以及依据是什么。

验收不看回答写得多漂亮，只看四项：有没有引用来源，能不能指出缺失数据，是否遵守查看权限，生成的待办能否回到负责人。四项都成立，AI才开始进入工作，而不是多了一个聊天窗口。

把“工作上下文”整理成可执行的数据链

不要从“把公司所有文件导入知识库”开始。先选一个每周都会问的问题，再倒推它必须依赖哪些对象。以“版本能否上线”为例：

必须读取的对象	最低完整度	AI 能做的事	缺失时必须怎么做
版本目标	有范围、不做范围、负责人	判断新增需求是否偏离重点	明示“无法判断目标达成”
需求与验收标准	每条关键需求有可验证结果	核对用例覆盖和未验收项	给产品负责人生成补录待办
用例与缺陷	状态、严重级、关联需求齐全	识别阻断上线的影响链	不用任务完成率代替质量结论
发布检查	测试结论、发布说明、回退方案有负责人	生成可上线/附条件/不可上线摘要	将缺失材料列为阻断项

在嘟哩的实际试点中，当前已有的项目、云盘、知识、聊天和组织权限可以先作为上下文底座；版本目标、验收标准、用例和发布门禁属于需要在产研工作流中补齐的结构化对象。这两类能力不应写成同一个“已经完成”的功能。

验证时不看文笔，看引用和缺失提示

准备 10 个管理者真实会问的问题，逐个核对：答案是否指向正确版本，是否引用了具体需求/缺陷/文档，权限不足时是否拒答，数据不全时是否明确说“还不能下结论”。这四项比回答速度更接近企业 AI 的真实价值。

把 AI 接入前的上下文整理成一次验收

可以选一个脱敏的真实版本做试点。项目经理在周一上午只问一句“这个版本今天能不能进入发布准备”，但不允许临时上传资料。系统必须从版本目标、需求、缺陷、测试结论和知识库绑定里找依据。

环节	要记录什么	通过标准
版本目标	范围、负责人、不做范围、完成条件	目标缺失时直接提示不能判断
需求	验收标准、产品负责人、测试负责人、状态	没有验收标准的需求不得计入已完成
资料	云盘文件、评审纪要、知识库条目、有效版本	AI 只引用当前版本绑定资料
结论	可上线、附条件上线、不可上线、阻断项	每个阻断项都有负责人和完成时间

这个试点的价值不在于让 AI 写出更漂亮的周报，而是逼团队把“判断版本状态需要哪些数据”说清楚。若某项资料只存在聊天截图里，就把它登记为流程缺口，而不是让 AI 根据截图猜。

怎么验收

验收时看三件事：AI 是否引用具体对象，缺资料时是否拒绝下结论，生成的待办是否能回到项目。三项都通过，才说明上下文整理真的进入工作流。

真正落到产品页面时，要看到这些东西

信息化负责人进入嘟哩 AI 工作台时，第一眼应该看到一次内部 AI 试点的当前状态，而不是一段功能介绍。入口动作也要直接：从一个真实业务问题新建任务，不从空白对话开始。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
版本目标	范围、负责人、不做范围、完成条件	当前状态、责任人、来源链接、更新时间	AI 检查“目标缺失时直接提示不能判断”，并给出缺口待办
需求	验收标准、产品负责人、测试负责人、状态	当前状态、责任人、来源链接、更新时间	AI 检查“没有验收标准的需求不得计入已完成”，并给出缺口待办
资料	云盘文件、评审纪要、知识库条目、有效版本	当前状态、责任人、来源链接、更新时间	AI 检查“AI 只引用当前版本绑定资料”，并给出缺口待办
结论	可上线、附条件上线、不可上线、阻断项	当前状态、责任人、来源链接、更新时间	AI 检查“每个阻断项都有负责人和完成时间”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

这一类文章涉及的是平台落地方法，不能写成嘟哩已经接入所有外部系统。外部系统暂未接通时，应先用脱敏文件或人工导入跑试点，并在页面上明确标注数据缺口。

读者真正会感受到的变化

以前是把资料临时丢给 AI，让它尽量回答；现在是先把问题、资料、权限和输出位置定清楚，再让 AI 工作。一线人员少做复制粘贴，管理者看到的是有来源的判断，安全负责人也能追踪一次调用经过了哪些边界。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

工作上下文和企业知识库有什么区别？

知识库主要保存可复用资料；工作上下文还包括当前项目、状态、责任人、权限、截止时间和执行记录。知识库是其中一部分，不是全部。

是否需要先把所有历史资料清洗完？

不需要。先围绕一个真实问题整理最近、有效、有负责人的资料，跑通后再扩大范围。历史文件可以分批治理。

AI能否直接替管理者判断项目结果？

AI可以根据已记录证据给出风险提示和建议结论，但上线批准、客户承诺和费用支出等关键决定应保留人工确认。