版本能不能上线，不能只看缺陷数量
一个版本可能只剩两条缺陷，却缺少回退方案；也可能有十条低风险问题，但关键链路已经验证。上线判断要看问题是否影响版本目标、关键验收是否通过、发布材料是否齐全，以及剩余风险由谁批准。落地时每个结论都要回到版本、需求、用例、缺陷或知识库证据，AI只负责分析、解释和提醒。
“还剩几条缺陷？”是上线前最常见的问题，也是最容易误导的问题。两条缺陷里有一条导致支付失败，版本不能上；十条缺陷都是低频文案问题，未必需要延期。
版本上线不是做一道数量题，而是判断本版承诺是否完成、关键风险是否可接受、出现问题能否处理。
23 条缺陷可以上线，1 条缺陷也可以不能上线
版本 A 还有 23 条界面间距、文案和低频兼容问题，这些问题经评估后可以进下版处理。版本 B 只剩 1 条缺陷，却会让旧用户升级后无法解密本地文件。如果驾驶舱只展示缺陷总数，它会给出完全相反的直觉。
发布判断不是缺陷计数，而是检查本版目标是否达成、关键风险是否被覆盖、未解决问题是否有可接受的绕行方案，以及一旦失败能否恢复。
先看缺陷影响哪个目标
每条P0、P1缺陷都应关联版本、需求和验收标准。负责人打开缺陷时，能看到它是否阻断本版重点、影响多少用户、有没有替代路径。没有这层关系，严重级别容易变成主观标签。
低级别缺陷也不能机械忽略。多个问题集中在同一模块，可能说明测试覆盖或架构稳定性不足，应作为聚合风险进入发布检查。
发布检查至少覆盖六类证据
版本目标和范围已确认；关键需求都有验收标准；关键用例已执行；阻断缺陷已关闭或有批准的豁免；测试结论已上传；发布说明、监控方案和回退方案可用。
发布检查不应由项目经理手工重新抄一遍。每个检查项读取版本、需求、用例、缺陷和知识库的实时状态，并允许点开证据。
结论只保留三种
“可上线”表示必填项通过；“附条件上线”表示存在已知风险，但有负责人、处理时间和批准记录；“不能上线”表示存在阻断项。不要使用“基本可以”“问题不大”这类无法追责的表达。
附条件上线不是降低标准。它要求把风险写明，例如某个非核心浏览器存在样式问题，影响范围、临时方案、修复时间和批准人都记录在案。
测试结论不是一句“测试通过”
测试负责人应说明测试范围、未覆盖内容、执行环境、关键结果和剩余风险。AI可以根据用例与缺陷生成草稿，但测试负责人必须确认。
发布说明和回退方案进入版本知识库，标记负责人和有效状态。文件存在但内容未确认，不能被系统当作检查通过。
嘟哩项目如何落地
版本详情新增发布检查页，默认读取目标、人员、范围、验收、用例、缺陷和资料。未通过项自动带出责任角色，可分配完成时间。附条件上线需要指定批准人。
嘟哩AI负责解释结论：本版为什么不能上、哪个目标受影响、今天谁需要完成什么。回答引用具体检查项，不用聊天摘要替代测试事实。
用一次真实发布验收
在发布前一天，禁止项目经理另做一张线下清单，只允许使用系统检查。记录所有无法从系统获得的信息，再判断应新增字段、绑定资料还是调整流程。
管理者能在一分钟内得到明确结论，并能逐项打开证据，发布检查才真正替代了“到处问”。
发布检查表要给出“结论 + 证据 + 责任”
| 检查类别 | 必须有的证据 | 常见阻断条件 |
|---|---|---|
| 目标与范围 | 目标达成记录、范围变更审批 | 核心目标未验收或关键需求被临时删减 |
| 测试 | 关键用例执行结果、回归范围、测试结论 | 必测用例未执行或结果无法追溯 |
| 缺陷 | 未关闭缺陷的影响、规避方案和接受人 | P0/P1 未关闭且无批准例外 |
| 发布 | 构建物、发布说明、配置变更、负责人 | 构建物与测试版本不一致 |
| 恢复 | 回退脚本、数据备份、恢复演练记录 | 有数据迁移但未验证回退 |
| 运营准备 | 公告、客服口径、监控和应急联系人 | 高影响变更无用户通知和客服预案 |
最终结论保留三种：可上线、附条件上线、不可上线。“附条件”必须写明尚未满足的事、何时检查、谁拥有停止发布的权限。如果只写“风险可控”，结论就不可执行。
让嘟哩 AI 做证据检查，不做无责任的“批准人”
AI 可以根据版本目标、用例、缺陷和发布材料指出缺失项、数据冲突和风险变化，但正式上线确认应由明确负责人执行。验收时故意留一份缺失的回退方案，看 AI 是否仍因为“缺陷较少”而给出乐观结论。
上线判断要看阻断链路，不只看缺陷数量
版本里还有 12 个缺陷，管理者以为风险很高；另一个版本只剩 2 个缺陷，却都卡在支付回调和数据迁移。缺陷数量不能直接回答能不能上线，关键要看严重级、影响范围和是否有回退。
| 环节 | 要记录什么 | 通过标准 |
|---|---|---|
| 缺陷质量 | 严重级、复现率、影响用户、关联需求 | 识别真实阻断项 |
| 复测 | 修复版本、复测人、复测结果 | 不能只看已修复状态 |
| 发布检查 | 测试结论、已知问题、回退方案 | 形成上线门禁 |
| 责任 | 阻断负责人、完成时间、协助人 | 今日行动明确 |
嘟哩项目概览应给出发布结论：可上线、附条件上线、不可上线、未知。未知也是结论，表示资料不完整，不能用乐观话术替代。
怎么验收
拿两个真实版本对比，检查 AI 是否能指出少量但阻断上线的缺陷，而不是按缺陷数量排序。
真正落到产品页面时，要看到这些东西
项目经理进入嘟哩项目生命周期页面时，第一眼应该看到一个真实版本的当前状态，而不是一段功能介绍。入口动作也要直接：从新建版本开始补目标、人员、需求、用例和知识库绑定。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。
| 页面区域 | 业务字段 | 系统状态 | AI 动作 |
|---|---|---|---|
| 缺陷质量 | 严重级、复现率、影响用户、关联需求 | 当前状态、责任人、来源链接、更新时间 | AI 检查“识别真实阻断项”，并给出缺口待办 |
| 复测 | 修复版本、复测人、复测结果 | 当前状态、责任人、来源链接、更新时间 | AI 检查“不能只看已修复状态”，并给出缺口待办 |
| 发布检查 | 测试结论、已知问题、回退方案 | 当前状态、责任人、来源链接、更新时间 | AI 检查“形成上线门禁”，并给出缺口待办 |
| 责任 | 阻断负责人、完成时间、协助人 | 当前状态、责任人、来源链接、更新时间 | AI 检查“今日行动明确”，并给出缺口待办 |
一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。
产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。
边界说明
产研工作流的前置条件是项目对象要结构化。目标、验收标准、用例、缺陷和发布检查没有补齐时，AI 只能提示缺口，不能替管理者做上线判断。
读者真正会感受到的变化
以前项目经理靠群里追问版本状态；现在从版本目标、需求、用例、缺陷和发布检查里直接看结论。产品知道本版重点，测试知道验收边界，研发知道阻塞是谁，管理者不用再把任务数量当成上线依据。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。
常见问题
是否必须关闭所有缺陷才能上线？
不必。应按影响、目标和风险批准处理，但阻断核心流程的问题不能用数量掩盖。
谁拥有最终上线决定权？
由企业流程指定发布负责人或批准人，系统负责提供证据和记录决定。
AI可以自动批准上线吗？
不建议。AI可生成建议结论和缺口，批准属于组织责任，应保留人工确认。