产品评审和技术评审不能只留一份会议纪要

“会议已评审”不等于需求可以开发。产品评审要确认用户问题、范围和验收标准；技术评审要确认方案、依赖、数据、风险和测试影响。结论必须改变需求状态，未决项必须有负责人和期限，纪要只作为证据。落地时每个结论都要回到版本、需求、用例、缺陷或知识库证据，AI只负责分析、解释和提醒。

评审会开了一个小时，会议纪要写了三页，需求状态却直接从“待评审”改成“待开发”。开发做到一半才发现接口未定，测试发现验收规则没写，产品说“会上讨论过”。这类问题不是没有记录，而是记录没有变成约束。

会议纪要适合保留讨论过程，评审结果必须结构化地回到需求：通过什么、拒绝什么、还有什么没定、由谁在何时补齐。

一句“评审通过”里，可能藏着三个还没有解决的条件

评审会上，产品确认了业务流程，后端提出老数据需要迁移，客户端提出鸿蒙端暂时不支持某控件，测试要求先提供脱敏数据。会议纪要最后写了“方案通过，以上问题后续跟进”。一周后，三个问题都没有负责人，但需求状态已经进入开发。

评审会的目的不是生成纪要，而是产生会改变需求状态的决定。如果条件、驳回原因和待确认项不能驱动状态，会议纪要再详细也会被进度绕过。

产品评审先回答值不值得做

产品评审至少确认用户和场景、问题证据、版本目标关联、交付范围、不做范围、原型、业务规则与验收标准。不能回答这些问题，需求就不应进入技术评审。

“原则上同意”需要拆开：哪些内容已同意，哪些待补材料，哪些明确不做。否则团队会默认全部进入开发，再在排期时争论。

技术评审回答能不能稳定交付

技术评审关注架构影响、接口与数据、权限、安全、兼容、依赖、灰度、回退和测试范围。输出不是一份长方案，而是关键决策、风险清单、任务拆分依据和待验证项。

涉及外部接口时，要标明是否已经开通、测试环境是否可用、限流和失败策略是什么。写着“对接ERP”但没有账号和字段，不能算技术方案完成。

评审结论要驱动状态

建议只有三种结论：通过、有条件通过、不通过。有条件通过必须列未决项、负责人和完成时间；未决项关闭前，需求不能进入相应阶段。结论改变时保留版本和批准人。

评审中新增或修改的验收标准应同步触发用例更新，架构和接口文档绑定到需求知识库。这样测试、开发和AI读取的是同一版结论。

纪要的正确位置是证据库

录音、AI听记和会议纪要可以放进项目知识库，并绑定当前需求和版本。AI从纪要提取决定与待办，负责人确认后写入结构化字段。原始纪要保留上下文，结构化结果负责驱动工作。

不能反过来让所有人每次重新阅读纪要找结论。那相当于把信息整理责任推给后续每一个人。

嘟哩里的页面应怎么落

需求详情增加产品评审和技术评审记录，展示评审人、结论、时间、未决项、关联资料和状态变化。项目知识库保存PRD、原型、技术方案和接口文档，并标记有效版本。

嘟哩AI可以根据资料生成评审检查清单、识别缺失项和整理纪要，但不能自动把需求判为通过。评审是组织承诺，必须由指定角色确认。

产品评审和技术评审要留下不同结论

评审	必须回答	可选结论	通过后影响什么
产品评审	用户是谁、问题是什么、范围和验收标准是否清楚	通过/附条件通过/驳回	决定需求是否可进入技术方案
技术评审	数据、接口、权限、性能、兼容、迁移和回退是否可交付	通过/附条件通过/需补方案/驳回	决定是否可拆成开发任务

“附条件通过”不能只存一段文字。每个条件要有对象、负责人、截止时间和证据；关键条件未关闭时，系统不允许进入下一阶段。例如“脱敏测试数据准备完成”必须附数据集链接和测试负责人确认，不能只把条件写在纪要里。

嘟哩项目中可以把评审记录作为需求下的结构化对象：参会人、评审版本、检查项、结论、条件、附件和状态变更全部关联。会议纪要继续保留讨论上下文，但不再承担流程状态。

用一条“条件未完成”测页面

在测试项目中，让技术评审附条件通过，但故意不上传数据迁移回退方案。检查需求能否被错误拆任务、概览页是否显示风险、AI 是否会错误总结为“评审已通过”。这比检查会议纪要是否生成更能验证闭环。

评审纪要要落到决策和风险，不是只存会议记录

技术评审会讨论了接口改造、灰度方案和性能风险，最后只留下一份“会议纪要”。两周后出现问题，大家记不清当时为什么选了这个方案，也找不到谁负责补压测。

环节	要记录什么	通过标准
产品评审	需求范围、交互变化、验收标准、业务风险	争议项有结论
技术评审	方案、接口、数据、性能、安全、回退	风险有负责人
待办	评审后补充资料、验证任务、截止时间	不能只写在纪要里
知识绑定	关联需求、版本、设计文档、接口文档	后续 AI 可引用

嘟哩项目要把评审做成功能对象：结论、风险、待办和资料绑定。会议纪要可以存在，但不能替代结构化评审结果。

怎么验收

验收时问 AI：这个需求为什么采用当前方案、还有哪些未关闭风险。答不出引用来源，就说明评审数据没有沉淀。

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

项目经理进入嘟哩项目生命周期页面时，第一眼应该看到一个真实版本的当前状态，而不是一段功能介绍。入口动作也要直接：从新建版本开始补目标、人员、需求、用例和知识库绑定。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
产品评审	需求范围、交互变化、验收标准、业务风险	当前状态、责任人、来源链接、更新时间	AI 检查“争议项有结论”，并给出缺口待办
技术评审	方案、接口、数据、性能、安全、回退	当前状态、责任人、来源链接、更新时间	AI 检查“风险有负责人”，并给出缺口待办
待办	评审后补充资料、验证任务、截止时间	当前状态、责任人、来源链接、更新时间	AI 检查“不能只写在纪要里”，并给出缺口待办
知识绑定	关联需求、版本、设计文档、接口文档	当前状态、责任人、来源链接、更新时间	AI 检查“后续 AI 可引用”，并给出缺口待办

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

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

边界说明

产研工作流的前置条件是项目对象要结构化。目标、验收标准、用例、缺陷和发布检查没有补齐时，AI 只能提示缺口，不能替管理者做上线判断。

读者真正会感受到的变化

以前项目经理靠群里追问版本状态；现在从版本目标、需求、用例、缺陷和发布检查里直接看结论。产品知道本版重点，测试知道验收边界，研发知道阻塞是谁，管理者不用再把任务数量当成上线依据。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

产品评审和技术评审可以合并吗？

小团队可以同场进行，但两组问题和结论仍要分别记录，避免价值判断被实现细节掩盖。

评审纪要是否需要所有人签字？

不一定。应由产品、技术和测试等关键责任人确认对应结论，具体按企业流程配置。

AI听记能否直接生成评审结论？

可以生成草稿和待办，最终结论、范围和责任人需要人工确认后写入系统。