# Research Deliberation / 研议 ## 产品需求文档 PRD v0.3 > 文档类型：Product Requirements & Design Specification > 文档状态：Draft for Review > 产品阶段：MVP 需求定义 > 文档依据：基于早期目标用户访谈与产品立项阶段需求整理 > 相关文档：产品实际迭代、架构演进与评测结果另见《Research Deliberation AI PM Case Study》 --- # 0. 一页产品摘要 ## 0.1 用户是谁 核心用户是正在准备以下材料的人文社科博士生与青年研究者： - 博士开题报告； - 论文研究设计； - 项目或基金申请中的研究方案； - 投稿前的完整论文框架。 他们已经形成初步研究问题，也通常使用过 ChatGPT、Claude、Gemini 等通用大模型，但仍无法稳定判断： - 研究设计到底哪里出了问题； - 哪些问题只是表达不清，哪些问题会导致项目站不住； - 不同学术位置会如何评价同一份提案； - 应该局部修补，还是重构研究方向； - 哪些 AI 判断可以相信，哪些需要核验。 ## 0.2 用户问题 > 我隐约知道这份 proposal 不对，但我说不清根本问题在哪里，也不知道应该先改什么。 ## 0.3 产品定义 Research Deliberation 是一款面向人文社科研究者的研究设计预审产品。 它读取用户提供的研究提案及相关材料，从整体研究设计、广域学术意义、领域专业性和答辩/拒稿风险等不同评议位置审查同一研究项目，并对高风险事实和文献判断进行必要核验，最终交付一份可追溯、可分层阅读、能够转化为修改行动的评议结果。 ## 0.4 核心价值 产品不只是告诉用户“哪里有问题”，而是要回答： 1. 这些问题是否来自同一个根因； 2. 哪些问题最严重； 3. 哪些判断来自不同学术位置； 4. 哪些事实与文献已经核验； 5. 用户下一步最应该做什么。 ## 0.5 MVP 要验证什么 MVP 不预设某一种 Agent 架构是正确答案。 它首先验证四个问题： 1. 多视角评议是否比通用模型单次回答发现更多重要问题； 2. 产品是否能把零散症状归因到少数结构性根因； 3. 用户是否能根据评议形成明确修改计划； 4. 产品是否能在可接受的成本、时延和信息负担下完成一次预审。 --- # 1. 用户研究与机会发现 ## 1.1 访谈对象 前期访谈对象为一名国际关系方向的人文社科博士生。她已经较频繁地使用 Claude、ChatGPT、Gemini 等产品处理文献、初稿和一般性研究任务，对大模型能力有基本理解，也清楚不同模型的优劣。 她不是“第一次接触 AI”的用户，而是已经开始把 AI 纳入研究流程的高认知用户。 ## 1.2 已经被通用模型部分满足的需求 访谈显示，以下任务已经被通用大模型较好覆盖： - 文献摘要； - 基础文献梳理； - 初稿生成； - 语言润色； - 一般性问题清单； - 从审稿人角度给出基础批评。 这些任务仍有价值，但已经很难构成一个独立产品的核心差异化。 ## 1.3 尚未被满足的高价值需求 ### 需求一：AI 能否真正挑战用户 用户认为许多 AI 过于谄媚，能够指出一些局部问题，但不愿意或不能够否定用户的根本假设。 她不希望 AI 成为“另一个自己”。 她希望系统： - 理解她的研究方向； - 掌握必要领域知识； - 但仍然保持外部性； - 能指出她没有意识到的盲点； - 能从不完全相同的学术位置提出质疑。 ### 需求二：用户缺少稳定的评议位置 现实中，用户可以接触导师和同门，但难以随时获得： - 大同行式的理论意义判断； - 小同行式的领域与文献判断； - 匿名审稿人式的拒稿风险判断； - 长期、稳定、不受人情关系影响的尖锐反馈。 ### 需求三：判断必须有依据 对于期刊适配、研究贡献、文献缺口、创新性和方法可行性等问题，用户不会仅凭一句 AI 结论改变研究方向。 高判断型产品必须提供： - 判断依据； - 材料出处； - 文献与事实核验状态； - 不确定性； - 可复核路径。 ### 需求四：用户缺少的不是更多意见，而是根因诊断 通用模型可以列出许多问题，但研究者真正困难的是： - 这些问题是否来自同一个根因； - 哪一个问题最先解决； - 修复某一条后，其他问题会不会自动消失； - 项目应该继续、缩小、重构还是暂停。 ## 1.4 机会空间 ```mermaid flowchart TD A[目标用户访谈] --> B[文献与初稿已被通用模型部分满足] A --> C[选题与研究判断仍然薄弱] A --> D[AI容易迎合用户] A --> E[缺少稳定的同行与盲审反馈] A --> F[高判断结论缺少可追溯依据] B --> G[不优先做普通写作助手] C --> H[判断型科研任务机会] D --> H E --> H F --> H H --> I[研究雷达] H --> J[选题生成与辩论] H --> K[期刊画像] H --> L[研究设计预审] H --> M[论文盲审与修改] ``` ## 1.5 为什么选择“研究设计预审”作为首个切口 访谈本身没有直接给出“做一个 Research Deliberation 产品”的答案。产品需要在多个机会中做取舍。 首个切口选择研究设计预审，理由如下： ### 用户价值高 如果研究设计从根本上不成立，越早发现，越能避免后续在田野、数据、档案、编码和写作上的无效投入。 ### 痛点清晰 用户能够明确感知“我觉得不对，但不知道哪里不对”，也能判断一份评议是否提供了真正的新洞见。 ### 角色稀缺 研究设计预审天然需要多种学术位置，而这些位置很难由单一导师或同门稳定提供。 ### 可建立明确 Baseline 可以直接与“把同一份 proposal 交给一个通用大模型进行评审”比较。 ### 可评测 可以比较： - 重大问题覆盖； - 无依据批评； - 问题之间的归因； - 角色互补； - 用户采纳； - 修改行动； - 成本与时延。 --- # 2. 替代方案与产品空位 本节不试图证明所有现有产品都不够好，而是回答：用户已经有哪些选择，Research Deliberation 仍然位于哪一层。 | 方案类型 | 代表形态 | 主要价值 | 主要局限 | Research Deliberation 的空位 | |---|---|---|---|---| | 通用大模型 | Claude、ChatGPT、Gemini | 快速问答、通用评审、对话与生成 | 易产生清单式批评，意见来源与任务边界不稳定 | 为研究设计诊断定义明确任务、角色来源、证据状态与优先级 | | 文献研究工具 | Elicit、Consensus 等 | 文献检索、证据综合、研究现状梳理 | 主要回答“已有研究说什么” | 回答“这份研究设计是否成立” | | 引文与证据核验工具 | Scite 等 | 检查论文如何被引用、支持或反驳 | 处理局部论据与引用关系 | 处理整份研究设计的结构性问题 | | 学术写作工具 | Paperpal 等 | 写作、润色、引用、投稿准备 | 更靠近成稿和表达层 | 更靠近研究投入前的设计诊断层 | | 真人反馈 | 导师、同门、审稿人 | 高质量、领域化、具有权威性 | 稀缺、慢、有时间和人情成本 | 在正式寻求真人意见前提供低成本预审 | | 单次审稿 Prompt | 用户自建 Prompt | 成本低、使用简单 | 结果稳定性、过程可追溯性和多视角互补难保证 | 将评议组织成可复用、可评测的产品流程 | ## 2.1 产品空位 > Research Deliberation 不替代文献检索、论文润色和真人导师。它定位在研究设计投入前的诊断层：帮助用户判断项目为什么站不住、不同学术位置如何质疑，以及下一步应改什么。 --- # 3. 核心问题与任务边界 ## 3.1 核心问题定义 > 当人文社科研究者已经形成初步研究提案，但尚未投入大量执行成本时，他们缺少一种及时、系统、可追溯的方式，判断研究设计是否成立、根本问题在哪里，以及下一步应继续、修改还是暂停。 ## 3.2 核心任务 Research Deliberation 首先解决： > 对一份已经成形但尚未定稿的研究提案，进行研究设计层面的预审。 产品需要帮助用户回答： 1. 研究究竟要解释什么； 2. 研究问题、理论、概念、案例、材料和方法是否互相支持； 3. 研究贡献是否真实存在； 4. 最强的反对意见是什么； 5. 哪些问题是 Fatal、Major、Moderate； 6. 哪些结论需要外部核验； 7. 下一步应该先改什么； 8. 用户是否需要局部修补、范围收缩或方向重构。 ## 3.3 不解决什么 MVP 不承担： - 代写论文； - 自动生成完整文献综述； - 完整选题生成； - 全流程科研项目管理； - 全量学术知识库建设； - 自动决定用户最终采用哪种方案； - 证明某个选题绝对创新； - 替代导师、开题委员会或期刊审稿人； - 覆盖所有学科和方法。 --- # 4. 产品定位 ## 4.1 产品定义 Research Deliberation 是一个 AI 驱动的研究设计预审系统。 它不是普通论文写作助手，也不是单纯的审稿 Prompt。 它将同一份研究提案放在多个互补的评议位置下进行审查，对关键事实和文献判断进行必要核验，并把评议结果整理为用户可以理解、追问和采取行动的结构化输出。 ## 4.2 核心价值 ### 从症状清单走向根因诊断 系统不仅列出问题，还需要解释： - 为什么多个问题会同时出现； - 哪个问题是上游根因； - 哪些是下游症状； - 修复顺序是什么。 ### 提供现实中稀缺的评议位置 系统需要模拟互补而非重复的学术视角： - 整体研究设计； - 广域学术意义； - 领域专业判断； - 答辩与拒稿风险。 ### 让判断可追溯 系统必须区分： - 用户材料支持的判断； - 已外部核验的判断； - 模型的一般性推理； - 尚待验证的检索线索。 ### 把诊断转化为行动 系统不能停留在“这份研究有问题”。 它需要帮助用户区分： - 必须先改； - 可以后改； - 暂时不要做； - 需要用户和导师共同决定。 ## 4.3 与通用大模型的差异假设 产品不假设通用大模型能力弱。 相反，它承认裸模型已经能够完成高质量评审。 Research Deliberation 需要证明的不是“AI 能评审论文”，而是： > 经过明确任务分解、证据约束、意见来源保留和结果组织后，系统能否稳定提供通用模型单次回答之外的增量。 --- # 5. 用户故事 ## 5.1 开题前诊断 **作为**一名准备博士开题的研究者， **当**我已经完成一版 proposal，但隐约觉得研究问题、理论和方法接不上时， **我希望**获得一次不迎合、能够指出结构性问题的预审， **以便于**在进入开题委员会前决定应该局部修改还是重构研究设计。 ### 验收标准 - 系统能够识别研究项目要解释的核心对象； - 能区分结构性问题与表达问题； - 能给出最严重的三到五个风险； - 能说明问题之间的关系； - 能提出至少一种可行修改方向； - 不把所有问题都包装成同等严重。 ## 5.2 投稿前盲审 **作为**一名准备投稿的论文作者， **当**我的论文已经基本完成，但缺少真正以拒稿为目标的外部反馈时， **我希望**获得匿名审稿人式的最强反对意见， **以便于**在投稿前发现可能导致拒稿的问题。 ### 验收标准 - 系统能够提出明确的拒稿理由； - 每条理由标记严重程度； - 能说明什么证据或修改可以解除质疑； - 不重复一般性润色建议； - 不为了显得尖锐而制造无依据批评。 ## 5.3 研究中途方向校正 **作为**一名已经投入部分研究工作的用户， **当**我发现数据获取、案例选择或理论解释出现问题时， **我希望**系统帮助我判断是执行困难还是设计错误， **以便于**决定收缩范围、调整方法或重新定义研究问题。 ### 验收标准 - 系统能够读取现有材料和用户现实约束； - 能区分学术最优方案与现实可行方案； - 能给出最小验证步骤； - 不默认用户具备高级方法或无限时间。 --- # 6. 用户旅程 ```mermaid flowchart LR A[感觉研究方案不对劲] --> B[选择评议场景] B --> C[上传提案与相关材料] C --> D[说明研究阶段与现实约束] D --> E[确认评议目标] E --> F[系统执行预审] F --> G[先看总体判断] G --> H[查看关键问题与角色意见] H --> I[查看依据与分歧] I --> J[认同、反驳或追问] J --> K[形成修改计划] K --> L[导出或进入下一轮复审] ``` ## 6.1 关键用户节点 ### 材料上传 用户需要知道： - 什么材料是必须的； - 什么材料是可选的； - 材料是否足够支持深度判断； - 未发表内容如何被处理。 ### 现实约束说明 系统需要主动收集： - 距离开题或投稿还有多久； - 用户的研究方法能力； - 数据是否可获取； - 是否允许改变研究范围； - 用户最担心的问题。 ### 结果阅读 结果需要分层展示： 1. 总体判断； 2. 最重要问题； 3. 共识与分歧； 4. 角色摘要； 5. 完整评议； 6. 证据核验。 ### 用户回应 用户可以： - 认同； - 部分认同； - 不认同； - 请求依据； - 补充材料； - 说明现实限制； - 要求重新生成修改路径。 --- # 7. AI 任务流程 PRD 定义的是 AI 必须完成的认知任务，不预设这些任务一定由独立 Agent、单模型多轮调用或其他架构实现。 ```mermaid flowchart TD A[材料接收与完整性检查] --> B[整体研究设计诊断] B --> C1[广域学术意义评议] B --> C2[领域专业评议] B --> C3[答辩与拒稿风险评议] C1 --> D[高风险事实与文献核验] C2 --> D C3 --> D D --> E[共识与分歧整理] E --> F[问题严重度与优先级排序] F --> G[生成分层评议结果] G --> H[用户反馈与约束补充] H --> I[生成修改路径] ``` ## 7.1 任务节点说明 ### Intake：材料接收与完整性检查 目标： - 识别材料类型； - 判断是否足以完成评议； - 获取用户研究阶段和现实约束； - 建立材料清单； - 标记无法读取或缺失的信息。 输出： - 材料清单； - 缺失信息； - 评议范围； - 风险提示。 失败条件： - 文件无法解析； - 缺少研究问题或研究设计； - 材料过少，不足以作出结构性判断； - 用户请求超出产品边界。 ### Overall Diagnosis：整体研究设计诊断 目标： - 识别研究项目的解释对象； - 判断问题、理论、概念、案例、材料和方法是否一致； - 找出少数决定项目能否成立的结构性问题； - 建立问题之间的因果关系。 输出： - 总体判断； - 三到五个核心问题； - 问题因果链； - 需要其他评议位置重点挑战的判断。 ### Peer Challenges：多视角挑战 目标： - 从不同学术位置挑战整体诊断； - 发现整体诊断遗漏的问题； - 验证是否存在过度友好、过度狭窄或方法偏见； - 保留真正的意见分歧。 输出： - 各视角新增问题； - 对整体诊断的支持、修正或反对； - 需要核验的高风险判断。 ### Verification：高风险核验 目标： - 核验可能影响最终结论的事实与文献； - 避免虚构文献、错误年份和过度创新性声明； - 区分“已验证”与“仅为模型推断”。 输出： - 已验证事实； - 未能验证的信息； - 证据状态； - 对评议结论的影响。 ### Deliberation：共识、分歧与优先级整理 目标： - 去除重复； - 保留不同角色的独特判断； - 区分诊断共识与方案共识； - 不制造虚假统一意见； - 给出修改顺序。 输出： - 共识； - 关键分歧； - 必须先处理； - 可以后处理； - 暂时不要做； - 需要用户决定。 ### Action Planning：修改路径 目标： - 根据用户时间、能力和资源约束生成行动建议； - 区分学术最优方案与现实可执行方案； - 给出最小验证步骤。 输出： - 短期行动； - 中期重构； - 可选路线； - 每条路线的成本、风险和前提。 --- # 8. MVP 参考实现路径 本节为开发对齐提供一条可行路径，但不把它定义为唯一正确架构。 ```mermaid flowchart TD A[用户上传材料] --> B[Orchestrator 创建 Case Context] B --> C[整体诊断任务] C --> D1[广域意义任务] C --> D2[领域专业任务] C --> D3[盲审风险任务] D1 --> E[汇总待核验 Claims] D2 --> E D3 --> E E --> F[Verification] F --> G[Synthesis] G --> H[Final Packet] H --> I[用户反馈] ``` ## 8.1 参考执行顺序 1. Orchestrator 解析材料并生成统一 `CaseContext`； 2. 整体诊断任务读取完整材料，形成初始问题图； 3. 三个补充评议任务分别挑战初始判断； 4. 系统汇总所有待核验声明； 5. Verification 对高风险声明进行检索与状态标记； 6. Synthesis 去重、保留分歧并生成优先级； 7. 生成用户可见 `FinalPacket`； 8. 用户反馈后，系统可生成修改路径。 ## 8.2 待比较的实现方案 MVP 研发阶段应至少比较以下方案： - 单模型单次综合； - 单模型同一上下文分阶段执行； - 多上下文独立执行； - 模型评议加人工核验。 实现选择由 Eval 决定，不由 PRD 预设。 --- # 9. AI 任务故事 ## 9.1 整体研究判断任务 ### 场景 用户上传一份初步研究提案，希望判断研究设计是否从根本上成立。 ### 所需上下文 - 完整提案； - 研究阶段； - 学科和研究方向； - 目标用途； - 用户上传的补充材料； - 用户时间、能力和数据约束。 ### 需要完成的能力 - 识别解释对象； - 判断研究问题是否可回答； - 判断理论与材料是否匹配； - 判断案例选择是否自我证实； - 判断方法是否能够支持主张； - 区分根因与症状； - 给出问题严重程度。 ### 输出约束 - 总体判断必须明确； - 核心问题不超过五个； - 每个问题说明“为什么重要”； - 每个问题指向材料依据； - 不以通用清单代替整合判断； - 允许输出“材料不足，无法判断”。 ### 禁止行为 - 不直接代写研究报告； - 不把格式问题当成结构性问题； - 不为了显得严格而扩大风险； - 不虚构领域知识或文献； - 不假设用户拥有未提供的方法能力。 ## 9.2 广域学术意义评议任务 ### 场景 整体诊断已经形成，需要判断研究是否具有超出具体案例的学术意义。 ### 所需上下文 - 用户材料； - 整体诊断； - 研究问题与理论主张； - 目标学科和可能的学术受众。 ### 需要完成的能力 - 判断研究问题是否值得更大范围关注； - 判断案例新颖性是否被误当成理论贡献； - 判断研究是否能进入更大的学术对话； - 识别理论 ambition 过低或过高。 ### 输出约束 - 必须指出新增价值； - 若无重大新增意见，应明确说明； - 不重复整体诊断中的方法问题； - 不要求所有研究都追求宏大理论。 ## 9.3 领域专业评议任务 ### 场景 需要判断研究是否真正理解所在领域及其已有研究。 ### 所需上下文 - 提案； - 关键文献； - 用户提供的领域材料； - 可访问的外部文献检索。 ### 需要完成的能力 - 检查概念使用； - 识别最接近文献； - 发现关键遗漏； - 判断材料、案例和方法在该领域是否可行； - 识别领域内部的隐性标准。 ### 输出约束 - 具体文献必须标记核验状态； - 不得以模型记忆证明“无人研究”； - 不应只列文献清单； - 必须解释遗漏如何影响研究判断。 ## 9.4 答辩与拒稿风险评议任务 ### 场景 需要模拟开题委员会或期刊审稿人的最强反对意见。 ### 所需上下文 - 完整提案； - 前序判断； - 目标用途； - 可能的答辩或投稿标准。 ### 需要完成的能力 - 提出最强质疑； - 判断问题严重程度； - 说明解除质疑需要的证据； - 判断哪些问题会导致拒稿或无法通过开题。 ### 输出约束 - 每条风险标记 Fatal、Major 或 Moderate； - 每条风险必须给出解除条件； - 不使用人身化、羞辱性或情绪化语言； - 不制造无依据的“致命问题”。 ## 9.5 证据核验任务 ### 场景 评议中出现具体文献、创新性、事实或案例判断。 ### 所需上下文 - 待核验声明； - 用户材料； - 搜索工具和数据库； - 允许访问的外部来源。 ### 需要完成的能力 - 检索； - 元数据比对； - 来源质量判断； - 区分全文、摘要和线索； - 识别无法验证的信息。 ### 输出约束 - 不得编造 URL； - 不得把搜索不到等同于不存在； - 必须记录核验状态； - 核验结果应说明是否改变原判断。 ## 9.6 综合与行动任务 ### 场景 多个评议位置已经完成，需要生成用户可理解的最终结果。 ### 所需上下文 - 所有评议输出； - 核验结果； - 用户现实约束； - 用户目标。 ### 需要完成的能力 - 去重； - 保留独特判断； - 解释分歧； - 排优先级； - 生成修改路线； - 区分学术最优与现实可行。 ### 输出约束 - 不得把单一意见包装成共识； - 不得抹掉少数但重要的反对意见； - 不得仅按出现频率决定优先级； - 必须让用户知道下一步先做什么。 --- # 10. 人机协作与决策边界 ```mermaid flowchart LR subgraph AI负责 A[读取与整理材料] B[识别结构性问题] C[提出多视角挑战] D[核验高风险事实] E[整理分歧与修改选项] end subgraph 用户负责 F[确认评议目标] G[补充现实约束] H[判断意见是否成立] I[选择研究方向] J[决定是否采纳修改] end F --> A A --> B --> C --> D --> E E --> G G --> H --> I --> J ``` --- # 11. 输出与交互设计 ## 11.1 输出原则 ### 分层阅读 第一层：10 分钟内理解总体判断。 第二层：看每个评议位置的核心观点。 第三层：按需阅读完整评议和证据。 ### 诊断与行动并列 用户既要知道： - 为什么错； - 也要知道接下来怎么做。 ### 保留意见来源 每条重要判断需要显示来自： - 整体诊断； - 广域学术意义； - 领域专业； - 盲审风险； - 证据核验。 ## 11.2 输出 Mockup 以下示例展示一份 proposal 进入产品后的最低可见结果。 --- ### 总体判断 **建议：重大修改后继续** 当前项目的首要问题不是研究范围太大，而是尚未明确需要解释的结果变量。三个研究问题因此形成并列描述，而不是一条能够被理论和方法共同支持的解释链。 ### 三个最重要问题 1. 因变量缺失； 2. 案例选择存在循环论证风险； 3. 研究方法先于理论问题被选中。 ### 三个立即行动 1. 明确最终需要解释的可观察变化； 2. 重写三个研究问题之间的逻辑关系； 3. 暂停增加案例和网络指标，先完成一个最小 pilot。 ### 暂时不要做 - 不继续扩展全球全类型网络范围； - 不在数据与因变量未明确前写政策建议； - 不把“尚未有人画过这张图”直接写成理论贡献。 --- ### 问题卡片 P1 **标题：因变量缺失** **严重程度：Fatal** **性质：结构性根因** **来源：整体诊断、广域意义评议** **置信度：高** **判断** 提案分别讨论网络结构、关键节点和政策效能，但没有定义一个贯穿三层问题的被解释对象。 **为什么重要** 如果没有明确的结果变量，案例选择、假设、方法和政策结论无法围绕同一个理论任务展开。其余多个问题会因此同时出现。 **材料依据** - 提案第 3.1 节：描述网络结构； - 提案第 3.2 节：识别关键节点； - 提案第 3.3 节：讨论政策效能； - 三节之间未给出明确解释关系。 **建议行动** 先回答： > 本研究最终希望解释哪一种可观察变化？ 在答案明确前，不继续增加案例、网络指标或预测任务。 **解除条件** - 给出可操作化的结果变量； - 说明三个研究问题如何共同服务于该结果变量； - 说明现有数据是否能支持该解释。 **用户操作** `认同` `部分认同` `不认同` `查看原文依据` `发起追问` --- ### 角色摘要：大同行 **本角色关注** 研究是否提出了一个超出具体案例的理论问题。 **核心判断** 当前创新性主要来自“新的时间段和数据对象”，但尚未说明这一案例为何能够改变我们对全球气候治理的既有理解。 **新增价值** 该问题不是方法错误，而是研究贡献定位不足。即使数据收集与 SNA 执行全部成功，项目仍可能只形成描述性地图。 **建议展开阅读** 是。若用户正在准备开题或基金申请，理论意义判断属于高优先级。 --- ### 共识与分歧 **共识** - 研究设计缺少明确的解释对象； - 当前范围过大； - 数据方案不足以支持预测性主张。 **分歧** - 整体诊断认为应转向因果检验； - 领域专业评议认为历时比较案例设计可能更符合用户当前能力； - 系统不替用户裁决，应同时展示“学术最优方案”和“当前可执行方案”。 --- ## 11.3 最终输出层级 1. 决策摘要； 2. 问题卡片； 3. 共识与分歧； 4. 角色摘要； 5. 完整角色评议； 6. 证据与核验附录。 --- # 12. 核心数据结构 以下 Schema 用于产品、工程和测试对齐。完整 API 设计不属于本 PRD 范围。 ## 12.1 CaseContext ```json { "case_id": "case_001", "review_scenario": "proposal_review", "discipline": "international_relations", "research_stage": "proposal", "target_use": "doctoral_defense", "deadline_days": 30, "user_constraints": { "method_capabilities": ["qualitative", "basic_sna"], "data_access": "uncertain", "scope_change_allowed": true, "preferred_language": "zh-CN" }, "materials": [ { "material_id": "m001", "type": "proposal", "filename": "RP.docx", "parse_status": "success" } ] } ``` ## 12.2 ReviewIssue ```json { "issue_id": "P1", "title": "因变量缺失", "severity": "fatal", "issue_type": "structural", "root_or_symptom": "root", "claim": "提案没有定义贯穿三个研究问题的被解释对象", "evidence_refs": ["m001#3.1", "m001#3.2", "m001#3.3"], "raised_by": ["lead", "broad_field"], "confidence": 0.86, "verification_status": "not_required", "removal_condition": "定义可操作化结果变量并重写研究问题之间的逻辑关系" } ``` ## 12.3 PeerPosition ```json { "review_role": "broad_field", "agreement_with_lead": "partial", "new_issues": ["P4"], "supported_issues": ["P1"], "challenged_issues": ["P3"], "verification_requests": ["V2"], "summary": "案例新颖性正在替代理论贡献" } ``` ## 12.4 VerificationClaim ```json { "claim_id": "V2", "claim_text": "CONNECT 已经使用 SNA 研究气候治理网络", "risk_level": "high", "source_type": "external", "status": "verified", "source_refs": ["url_or_doi"], "impact_on_review": "削弱提案的首创性声明" } ``` ## 12.5 FinalPacket ```json { "decision": "major_revision", "top_issues": ["P1", "P2", "P3"], "consensus": ["P1", "P3"], "disagreements": [ { "topic": "推荐方法路线", "positions": ["causal_design", "comparative_case_design"] } ], "do_now": ["A1", "A2", "A3"], "do_later": ["A4", "A5"], "do_not_now": ["A6", "A7"], "user_visible_roles": ["lead", "broad_field", "specialist", "blind_reviewer"] } ``` --- # 13. Scope Cut 与功能优先级 ## 13.1 最小可验证闭环 ```mermaid flowchart LR A[上传一份 Proposal] --> B[填写研究阶段与评议目标] B --> C[生成整体诊断与补充评议] C --> D[综合问题与优先级] D --> E[输出 Markdown Review Packet] ``` MVP 的目标不是一次做完整科研平台，而是验证： > 结构化多视角预审是否相对于裸模型产生稳定增量。 ## 13.2 P0：首版必须具备 1. 单份 DOCX、PDF 或 Markdown 输入； 2. 用户填写研究阶段、目标用途和基本现实约束； 3. 材料解析与基本完整性检查； 4. 整体研究设计诊断； 5. 三类补充评议； 6. 共识、分歧与优先级综合； 7. Markdown 输出； 8. 基础运行日志； 9. 与裸模型对照所需的固定输入和版本记录。 ## 13.3 P0 中可人工完成的环节 为控制首版复杂度，以下环节可以先通过人工或半自动方式完成： - 测试案例准备； - 专家 Gold Issue Set 整理； - 高风险文献核验； - Word 转换； - 用户反馈记录； - 运行成本汇总。 ## 13.4 第一批砍除项 如果开发资源不足，按以下顺序砍除： 1. 用户逐条认同/反驳交互； 2. Word 导出； 3. 自动外部文献核验； 4. 自动修改计划； 5. 快速/深度/核验三种模式； 6. 长期用户背景； 7. 修改前后复审； 8. 登录、支付与团队协作。 ## 13.5 不可砍除项 以下三项构成核心产品假设，不能砍： 1. 整体诊断； 2. 互补评议； 3. 综合保留共识与分歧。 如果砍掉任何一项，产品将退化为普通审稿 Prompt。 --- # 14. 质量标准与 Eval Protocol ## 14.1 Eval 的作用 Eval 不是产品完成后的验收装饰，而是用于决定下一轮产品和架构选择。 PRD 定义“准备如何测”；实际 V1、V2、V3 评测过程与结果进入 Case Study。 ## 14.2 Baseline 必须设置通用大模型直接评审作为 Baseline。 对照应尽量保持： - 相同输入材料； - 相同任务目标； - 相同或同等级模型； - 固定并记录 Prompt； - 输出来源对评分者隐藏； - 记录 Token、时延和长度； - 不只比较格式美观度。 ## 14.3 Gold Issue Set 构建 ### 专家数量 每个测试案例至少由两名具备相关研究经验的评议者独立阅读。 ### 标注任务 每位评议者分别标记： - Fatal 问题； - Major 问题； - Moderate 问题； - 可接受但需说明的问题； - 误判风险。 ### 合并方法 1. 两名评议者独立标注； 2. 产品负责人合并同义问题； 3. 对存在分歧的条目，由第三名评议者裁决； 4. 形成该案例的 `Gold Issue Set`； 5. 保留每条 Gold Issue 的定义、严重程度和判断依据。 ## 14.4 核心指标定义 ### 重大问题召回率 Major Issue Recall ```text 重大问题召回率 = 产品命中的 Gold Fatal/Major 问题数 ÷ Gold Fatal/Major 问题总数 ``` 命中由语义而非字面一致判断。模糊匹配需人工裁决。 ### 重大问题精确率 Major Issue Precision ```text 重大问题精确率 = 产品提出且被专家认定成立的 Fatal/Major 问题数 ÷ 产品提出的 Fatal/Major 问题总数 ``` 该指标用于防止系统为了提高召回而制造批评。 ### 角色新增价值率 Unique Contribution Rate ```text 角色新增价值率 = 某评议位置新增且被认定有效的问题数 ÷ 该评议位置提出的问题总数 ``` 若某角色长期只重复其他角色，则该角色不应保留。 ### 摘要信息保留率 Compression Retention ```text 摘要信息保留率 = 最终摘要保留的有效 Fatal/Major 问题数 ÷ 完整评议中的有效 Fatal/Major 问题总数 ``` 用于检查综合环节是否抹掉关键判断。 ### 无依据批评率 Unsupported Critique Rate ```text 无依据批评率 = 无法从材料、方法逻辑或已核验证据中获得支持的问题数 ÷ 产品提出的问题总数 ``` ### 行动可执行率 Actionability Rate 由目标用户逐条判断建议是否具备： - 明确动作； - 可理解前提； - 可判断完成状态； - 与当前问题直接相关。 ```text 行动可执行率 = 被用户认定可执行的建议数 ÷ 建议总数 ``` ### 用户采纳率 Adoption Rate ```text 用户采纳率 = 用户计划采用或已实际采用的建议数 ÷ 用户认为成立的建议数 ``` ### 单个有效重大问题成本 Cost per Valid Major Issue ```text 单个有效重大问题成本 = 单次运行总 API 成本 ÷ 被专家认定有效的 Fatal/Major 问题数 ``` ## 14.5 评价主体 组合使用： - LLM-as-a-Judge：用于统一 Rubric 下的初筛； - 产品负责人人工复核：用于错误归因与版本比较； - 目标用户反馈：用于理解度、行动性与采纳； - 领域研究者匿名排序：用于判断实际学术价值； - Gold Issue Set：用于重大问题召回和精确率。 ## 14.6 初始测试集 初始测试集至少覆盖： - 质性研究； - 历史研究； - 比较案例； - 定量研究； - 实验或准实验研究。 每个案例应保留： - 原始输入； - Baseline 输出； - 产品输出； - 评分表； - Judge 结果； - 人工复核； - 版本和模型； - Token、长度和时延。 ## 14.7 评测阶段设计 ### Eval 0：Baseline 回答： - 裸模型已经能做到什么； - 产品至少必须超过哪一条基准。 ### Eval 1：产品增量 回答： - 多视角结构是否提高重大问题覆盖； - 是否只是输出更长。 ### Eval 2：回归测试 回答： - 新补丁是否改善目标问题； - 是否损害其他方法类型或案例。 ### Eval 3：架构消融 回答： - 同一上下文与独立上下文的差异； - 角色数量是否必要； - Verification 是否值得成本； - 综合环节是否保留信息。 ### Eval 4：真实用户验证 回答： - 用户是否理解； - 是否采纳； - 是否形成修改计划； - 是否愿意再次使用或付费。 ## 14.8 失败条件 产品需要被判定为“没有增量”的情况包括： - 输出只是更长； - 多视角大量重复； - 综合环节抹掉关键判断； - 无依据批评过多； - 用户看完仍不知道先做什么； - 发现的问题不如裸模型； - 角色数量增加但 Unique Contribution 没有提高； - 成本和等待时间远高于用户可接受范围。 --- # 15. 主要风险与失败处理 ## 15.1 模型给出看似深刻但错误的判断 处理： - 显示依据； - 标记置信度； - 允许用户反驳； - 对高风险判断核验； - 提醒关键方向调整需要真人确认。 ## 15.2 多视角退化为重复输出 处理： - 为每个评议位置定义清晰责任； - 评测新增价值； - 允许“无新增意见”； - 不以角色数量作为成功标准。 ## 15.3 综合环节制造虚假共识 处理： - 区分共识与分歧； - 保留意见来源； - 不按多数票自动裁决； - 对关键少数意见单独展示。 ## 15.4 输出过长 处理： - 分层阅读； - 摘要优先； - 问题卡片化； - 允许跳过非关键部分； - 后续提供快速和深度模式。 ## 15.5 学术最优方案不可执行 处理： - 提前收集用户能力、时间和数据限制； - 同时给出学术最优与现实可行方案； - 提供最小验证步骤； - 不默认高级方法能力。 ## 15.6 文献与事实幻觉 处理： - 高风险判断进入核验； - 显示核验状态； - 不把检索不到写成“不存在”； - 允许用户查看来源。 ## 15.7 隐私泄露 处理： - 公共代码与私有案例分离； - 默认不公开用户材料； - 明确保留周期； - 提供删除； - 后续探索本地或私有部署。 ## 15.8 执行能力不可用 当外部检索、文件解析或多任务执行不可用时： - 明确告知降级； - 标记未完成环节； - 不假装完成深度评议； - 允许用户选择继续基础评议或终止。 --- # 16. MVP 验收标准 MVP 进入 Beta 测试前，应满足： 1. 能上传并解析一份研究提案； 2. 能收集用户研究阶段与现实约束； 3. 能形成明确的整体诊断； 4. 能提供多个可区分的评议位置； 5. 能展示共识与分歧； 6. 能生成有优先级的问题清单； 7. 能导出 Markdown Review Packet； 8. 能记录单次运行的模型、时延、Token 与失败情况； 9. 至少完成一次与通用大模型的对照测试； 10. 至少一名真实用户能够据此形成修改计划。 注意： > 验收标准定义产品是否具备被测试的资格，不预设其一定优于 Baseline。 --- # 17. 开放问题 1. 核心用户是否需要进一步收窄到博士开题？ 2. 用户更需要快速检查还是完整预审？ 3. 外部核验是否默认开启？ 4. 不同学科是否需要不同评议标准？ 5. 多视角应该由什么架构实现？ 6. 如何控制更多 Token 对评测结果的影响？ 7. 用户愿意等待多久？ 8. 用户愿意为一次评议支付多少？ 9. 如何处理中文与英文文献语境差异？ 10. 用户背景如何参与评议，又不削弱 AI 外部性？ 11. 什么信息值得长期记忆？ 12. 最终交付单位应是一份报告、一组问题卡片还是一次持续对话？ --- # 18. PRD 与 Case Study 的边界 本 PRD 只定义： - 用户问题； - 产品切口； - 目标任务； - AI 能力要求； - 参考实现； - 交互与交付； - 数据结构； - Scope Cut； - Eval Protocol； - 待验证假设。 以下内容进入后续 Case Study： - 第一版实际采用了什么实现； - 单体多角色为何部分弱于裸模型； - Lead 保护补丁为什么产生回归； - 为什么改为独立子 Agent； - 最终如何形成 Research Review Packet； - 真实三轮 Eval 结果； - 运行成本和时延； - 用户与专家反馈； - GitHub 发布； - 下一轮产品判断。 ```mermaid flowchart LR A[用户访谈与问题选择] --> B[建立裸模型 Baseline] B --> C[V1 单体多角色] C --> D[部分案例退化] D --> E[V2 Lead保护补丁] E --> F[回归进一步扩大] F --> G[V3 独立评议架构] G --> H[Research Review Packet] H --> I[用户、专家、成本验证] I --> J[产品重新定义与下一步] ``` > PRD 展示产品定义与开发对齐能力；Case Study 展示实验、判断和迭代能力。