1. 先讲清楚这个系统到底要解决什么1.1 项目背景与定位先说结论这是一个基于大语言模型的多人讨论辅助系统但它的核心约束很简单——AI 不排序、不打分、不判谁赢。它只做三件事把参与者的观点拆开、重新表述、再拉回讨论现场。整个系统的设计目标不是“得出一个最优答案”而是“让讨论本身不塌掉”。我最初想搭这套东西是因为团队里每次用 AI 辅助做决策讨论最后都会滑向同一个结果AI 输出一份带排名的结论清单比如“方案 A 9.2 分方案 B 8.6 分建议优先考虑方案 A”。这个结果看起来高效但它其实杀死了讨论。因为一旦 AI 给出分数和排名大家就会围着那个分数争论而不是继续挖掘彼此观点里真正有价值的东西。而且分数是最容易被操纵的——换个提示词换个温度参数甚至换个模型版本同一场讨论的排名就可能翻转。所以这个项目从立项开始就给自己定了一条硬规矩AI 只能当“讨论的催化剂”不能当“讨论的裁判”。这个定位听起来简单真正落实到系统设计里牵扯到的东西比我预想的多得多。1.2 这个系统不做什么才是它的核心大部分 AI 讨论工具做的事情是输入一堆材料输出一个结论。而这个系统刻意反着来——输入是参与者的发言输出是新的发言、新的问题、新的视角而不是结论。说得更直白一点不排序永远不会出现“观点排名”“关注度排行榜”这类输出不打分不会给任何一个观点打“重要性分”“可行性分”“创新分”不判谁赢不管参与者之间分歧多大系统都不会判定谁更有道理、谁的逻辑更严密这三条约束写出来很容易但在技术上实现“克制”比实现“生成”难得多。因为大模型的天性就是给你一个确定的、闭合的答案你要让它忍住不闭合、不收敛、不输出结论性内容得在架构层面做很多干预。这个系统适合谁适合那些真的需要把讨论进行下去的团队比如产品方案评审、技术选型争论、多利益相关方的需求梳理。它不适合谁不适合只想要一个“标准答案”的人。如果你开会的目的是让 AI 替你做决定那你根本不需要这套系统直接问 GPT、Claude、文心一言任何一个都行。2. 三条核心约束是怎么落到系统设计里的2.1 约束一不排序究竟意味着什么排序这个动作在传统决策系统里太常见了。常见的做法是给每个方案打一个综合分按分数从高到低排出来。这个动作看起来客观实际上把讨论里的三种信息全毁掉了。第一种被毁掉的信息是“权重偏好”。团队里 A 重视成本B 重视可维护性C 重视交付速度。同一个方案三个人心中的评分逻辑完全不同。一旦合成一个总分这三套权重逻辑就被压扁了大家再也没机会去讨论“为什么我们重视的东西不一样”。第二种被毁掉的信息是“隐性上下文”。很多观点之所以有价值不是因为那个观点本身多聪明而是因为它背后连接着具体的操作经验。比如有人说“这个方案在数据迁移的时候会出问题”这句话如果被抽象成一个分数“方案可行性 -2 分”那背后的坑就丢了。系统要做的是把这个坑从经验里挖出来放到所有人面前看。第三种被毁掉的信息是“顺序相关”。方案 A 在讨论前提出来和讨论了半小时后提出来大家对它的接受度完全不同。排序系统会把 A 在某个时间点上的得分当成它的固定属性但真实讨论里观点是动态的是被其他观点影响着的。我最终用到的实现办法是每次收到参与者的发言先做一次信息抽取把发言拆成“主张”和“依据”两个部分。主张不打分、不排序依据也不做权重计算。它们只是被结构化地记录下来然后交给下一轮的生成模块作参考。2.2 约束二不打分那用什么来衡量讨论质量既然不打分你总要有个手段来反馈讨论的质量。我的选择是用“分歧分布图”代替“分数表”。我系统里有一个模块专门负责观察讨论中出现的分歧类型。它把分歧分成几类事实分歧双方对事实的认知不一样、标准分歧双方认可事实但认为重要的维度不一样、方案分歧目标一致但路径选择不一样、价值分歧底层价值观不一样。这个分类也不打分只是标记类型。这个模块输出的不是“谁对谁错”而是一句话形式的观察比如“目前在场讨论似乎存在一个标准层面的分歧一方更关注长期维护成本另一方更关注上线速度”。这句话会被发送回讨论流程里但不会附上任何权重建议。这样做的好处是参与者能感觉到系统真的在听他们说话同时不会感觉被审视。我实测过当参与者发现系统不会给他们打分之后发言的戒备心明显降低了很多一开始藏在客气话里的真实顾虑反而敢拿出来说。2.3 约束三不判谁赢那分歧怎么解决这是整个系统里最反直觉的部分它不解决分歧它只让分歧被充分理解。传统系统拿到分歧会尝试消解它或者找一个“折中方案”结束争论。这个系统反着来——分歧暴露得越充分越好因为很多争论到最后发现是概念定义不一致或者是目标里隐含的优先级不一致。一旦这些暴露出来团队自己会找到方向根本不需要 AI 来裁决。我实际用到的策略是“分歧重述”当两个参与者明显对立时系统会生成一段中立的重述把双方的核心逻辑放在一起对照。它不评判哪一方更有依据只是把两套逻辑结构清晰地展示出来让参与者自己看。举个例子如果 A 说“我们应该自研这部分因为第三方方案太封闭”B 说“我们应该买现成的因为自研周期太长”系统重述出来是这样的“A 的顾虑集中在长期扩展性B 的顾虑集中在交付周期。如果把交付周期挤压两周A 是否愿意接受自研方案如果把扩展性风险用契约方式约束住B 是否愿意考虑购买方案”这就是把双方拉到同一个平面上看问题而不是替他们选一个赢家。2.4 三条约束汇聚出来的讨论“形状”不去裁判之后讨论的推进方式反而更清晰了。系统为自己定义了一个“理想讨论状态”每次讨论结束时留下的不是最终方案而是一张“分歧地图”上面标注清楚了有哪些分叉路口、每个路口各自通向什么顾虑、哪些顾虑背后的事实是待验证的。这也导致这套系统的会话界面跟主流的 AI 聊天界面长得不一样。主流聊天界面是一问一答、一条一条消息往下堆。这个系统里讨论的推进单位是“子议题”每次讨论结束界面会把子议题按主题归类展示。没有优先级没有时间戳排序只有主题归属。我一开始也觉得这个设计太“野”但跑了一段时间后我发现真正有价值的产出恰恰是这种“非收敛”的结构。它让团队在第二次碰头的时候可以直接按主题继续深挖而不是重新开一场全新的讨论。3. 技术架构与工作流设计3.1 整体结构四个模块轮流驱动讨论这套系统的技术实现说不上复杂核心是四个模块会话管理器、观点处理器、分歧观察器、讨论推进器。四个模块串成一条流水线每一步的输出作为下一步的输入。会话管理器记录讨论当前状态包括已讨论的子议题、参与者的发言序列、待探索的分歧点。观点处理器把发言文本结构化切成“事实声明”“经验主张”“价值判断”“疑问”四类。分歧观察器对比结构化后的观点识别相同点与分叉点生成简短观察。讨论推进器根据当前讨论状态生成下一轮引导问题或转换视角但不给出结论。各模块间通过一个内存中的会话对象传递数据会话对象本质上是一棵议题树每个节点挂载参与者发言的结构化数据和分歧观察器的分析结果。我验证过的关键点是四个模块的提示词必须严格分离。我最开始偷懒把它们合成一个大提示词结果模型经常从“讨论推进器”的性格滑向“裁判”的性格开始输出“综合来看方案 A 更优”这类话。拆开之后每个模块只负责一类行为行为漂移的问题大幅减少。3.2 会话管理器讨论从哪里开始、怎么演进讨论的开始不是从一段空白提示词出发我从实际使用中提炼出一套“开场初始化”流程设定议题边界。比如“今天我们只讨论推荐算法的排序特征不讨论基础设施迁移”这会写入系统提示词的固有一层。收集参与者的“初始立场”。注意这里不用“观点”这个词而是用“立场”因为观点可能模糊、可能摇摆立场只是此刻的位置。把初始立场交给观点处理器生成结构化版本。让分歧观察器先跑一遍看看开局就存在的分歧点有哪些这个信息会作为讨论推进器第一轮提问的依据。这里有一个容易被忽略的设计点会话管理器必须支持“讨论回跳”。实际讨论中经常出现的情况是队伍聊到后面发现前面某一句假设是错的。传统聊天界面只能向上翻聊天记录但这套系统会把“已确认事实”作为单独一层存下来如果后续有人提出反例系统不只是记录反例而是把受影响的旧节点全部标记为“待复查”。这样做有个直接好处讨论不会因为一个旧有错误前提而整体崩塌而是沿着受影响的节点局部修正。我实测过一个三小时的讨论中间改了两个前提整个讨论主线没有断只在那两个节点上重新展开了一层子讨论。3.3 观点处理器与“重述”机制观点处理器在技术上是纯粹的文本分类加信息抽取任务但在模型选择上有讲究。我实测下来那种参数特别大、推理能力极强的新模型反而不适合做这个任务因为它们太容易在抽取过程中“润色”原始观点把 A 说的“我觉得这个方案太复杂”润色成“用户指出方案在操作流程上存在复杂度隐患”这个润色过程在无形中改变了原始立场的情感强度。我最终选用的是轻量级模型做原始拆分保留原句语气和用词只是做结构切分。重述工作则交给更强的模型但加了严格限制重述必须包含双方原文里的关键名词不允许引入新的类比和新的例子。这里给想复现的读者提个醒重述的好坏几乎决定整场讨论的质量因为它是最容易被参与者当成“客观事实”的文本。系统生成的重述如果引入任何超出原文的倾向性词语立刻就会被某一方抓出来当靶子打。所以重述提示词里我专门写了一段负面案例告诉模型哪些词禁用包括“显然”“无疑”“更好”“更合理”等等。观点处理器输出的最终格式大致是这样的{ speaker: 参与者在系统里的身份ID, text: 原始发言文本, claims: [ { type: fact, content: 第三方方案在2024年已上线多租户支持, certainty: verified_by_speaker } ], stance: 支持自研方案, mentioned_topics: [扩展性, 多租户, 交付周期] }这个结构不包含任何评分字段也没有优先级权重就是纯记录。4. 关键实现细节提示词、上下文与记忆4.1 提示词里不能出现“裁判指令”这是我在实验过程中吸取的最大教训。什么叫裁判指令就是你在提示词里写的任何暗示模型需要“评估哪一个更好”的措辞。哪怕你在系统提示词里写“请帮助参与者理清思路”模型也极大概率把“理清思路”理解成“比较一下哪个思路更好”。我在实际操作中总结了一个负面列表这些词在提示词里基本不能出现更好、最优、推荐、优先级、重要程度、侧重点、值得注意、相比之下。用这些词的变体也会踩雷比如“你认为关键点是……”模型会把“关键点”自动升维成“最重要的一点”接着就开始排序了。真正的写法是让模型做空间展开而不是做线性收敛。同样一句话裁判式提示词会写成“请评估各位参与者的观点并指出哪个更有说服力”非裁判式提示词我试下来最好用的是“请把当前议题向三个不同的方向展开每个方向都至少考虑一个参与者的原话”。再比如“如果乙方反对这个方向他们最可能拿出的理由是什么请用乙方已表达过的立场来推导但不要判断这个理由是否成立。”我把这套写作手法叫作“平等的完成度要求”每轮生成的每组备选思路都需要同等篇幅、同样格式、同等级别的细化程度这样模型就不会因为某个选项的内容更丰富而显得像推荐它。4.2 记忆机制不是存储对话而是存储“分歧地图”讨论系统的记忆层和聊天系统的记忆层有本质区别。聊天系统的记忆是为了让 AI 不忘记用户说过什么讨论系统的记忆是为了让讨论不会原地打转。我的实现方案是两层结构。第一层存储“事实协议区”记录全体参与者没有异议的陈述。这部分内容被标记为“暂时稳定”后续如果出现反证就会被移出。第二层存储“分歧地图”记录争议焦点以及各方典型表述。这层每轮讨论后都会增量更新。这里有个设计上的细节非常关键分歧地图上的每个节点必须能够回溯到原始发言。也就是说系统可以展示“参与者 B 在 17 分钟前提到过对数据迁移风险的担心”但不能展示“参与者 B 的风险意识较强”这类的演绎。我反复校准过这个边界——这个系统里允许更准确的语言保存文本原文的那一刻用抽象概括来记录的可能是非常大的描述偏差。为了做到这一点我用了非常朴素的工程手段每个节点挂一个 UUID节点内容修改时生成新版本旧版本仍保留引用路径。讨论推进器每次生成新引导语时都必须引用至少一个节点 ID不能凭空生成。4.3 转向策略讨论卡住了怎么办所有讨论系统都得面对一个終极问题大家聊了 20 分钟还是各自重复立场。传统系统在这个时候会给一个模板化的干预“大家意见不一建议投票决定”。这个系统不能这么干因为投票本质上就是裁判机制。我设计了三种转向策略每种策略对应一种卡死状态第一种是“概念澄清转向”。如果观察器发现大家的发言越来越多地在使用同一个模糊词比如“可持续性”“用户体验”“质量”但这个词在不同人嘴里含义不同就插入一轮专门的概念澄清。对话推进器这一轮只提问禁止陈述自己的观点。第二种是“维度换位”。如果参与者都咬死在同一个维度上比如都在争论成本系统会提出一个相对陌生的换位思考维度。但注意它不是随意提而是基于某一方发言里隐含的、但尚未被展开的信息点。比如有人提过一句“我们团队对这个技术栈比较熟”就可以绕着这条线生成一轮“如果我们把团队熟悉度作为核心前提讨论会怎么变化”的引导。第三种是“暂停策略”。如果讨论在 15 分钟内没有任何新的事实被提出也没有任何新的维度被展开系统会主动建议休息或者换一个子议题而不是强行继续。这个策略看起来简单但实际用起来效果很好——它让 AI 的“不作为”变成了一种可以接受的系统行为用户开始承认“确实该停一停”。这里有一个我特别想强调的经验AI 讨论系统的价值不是体现在它能回答多少问题而是体现在它对“什么时候不回答”的判断。我在早期版本里总想让每一轮都产出内容结果整个讨论变成了 AI 自言自语。后来加了暂停和三轮无新信息自动收敛的机制整体质量反而提升了。5. 踩坑实录从第一版到能用的版本5.1 坑一AI 太喜欢总结“共识”第一版系统上线不到半个小时就暴露了一个大问题每轮讨论结束后AI 都会在界面底部生成一个“小结框”把当前局面概括成一组共识。这个小结框不是我要的但模型自己加了。这个行为的危害在于参与者看到小结框之后会把里面的内容当作既定事实后续讨论就被锚定了。如果小结框写的是“大家一致认为需要优先解决数据质量问题”即便这句话只是模型对讨论的粗泛归纳也会让有些人不再继续强调自己真正关心的、但尚未被吸收的点。解决方法比较粗暴我干脆删掉了所有连续文本小结的生成入口只保留结构性总结也就是前面说的分歧地图。我允许参与者点开一个节点看到完整脉络但不允许任何瀑布流式的一段话总结出现在界面顶部。结构性问题用结构化方式展示叙事性内容一律不生成。5.2 坑二角色一旦固定就变成“辩论秀”我在第二版加入了一个“参与者画像”机制想让模型记住每位参与者的背景结果效果非常差。一旦模型记住了“这是个前端工程师”或者“这是倾向于风险规避的负责人”它就自动把这个人往一个方向推。前端工程师被分配了所有体验相关发言的生成权风险规避者被要求每次都必须指出风险。这让讨论变成了一出固定的“辩论秀”每个角色各自唱自己的台词互不交锋。原本系统应该促进的真实讨论反而被这个画像机制锁死了。我最后把画像去掉了改为只保留“本次讨论中的实际立场”作为动态角色。参与者说自己支持什么模型就基于这个立场帮他派生论据如果有人中途改变立场系统也跟着改而且还会问“你是否确认立场调整”这个动作本身就是对讨论的推动。5.3 坑三上下文一长就变“一锅粥”这是所有大模型应用的经典问题。讨论进行到 40 分钟以上历史消息可能超过八万字再强的模型也会出现上下文碎片化。表现是它会记住开头和最后几轮发言把中间的讨论完全忽略掉然后生成一个跟中间讨论无关联的问题。我第一反应是截断上下文只保留最近 N 轮但这样会让讨论失忆经常出现半小时前定下的共识被推翻也没人注意到。最终解决方案是引入两层上下文管理。第一层是前面的“事实协议区”加“分歧地图”这两块数据永远完整保留而且用紧凑的结构化格式呈现。第二层是最近的全文发言记录但截断到最近十五分钟。也就是说模型永远带着完整的结构记忆和最新的对话流而不是试图把所有历史塞进一个上下文。结构记忆的最大好处是它天然是去冗余的。分歧地图里的每个节点都是经过结构化抽取的不需要保留原始对话里那些寒暄、重复、跑题的段落。实际的 token 消耗大概只有全文存储的六分之一而讨论信息的覆盖率比全文存储还高。5.4 坑四多语言混用导致的立场偏移这个属于比较冷门但真实存在的坑。团队讨论经常中英混用比如中文本体夹着“API 设计”“compliance check”这些词。我发现模型在处理混用文本时会出现一种倾向性把英文术语当成更技术性的“硬意见”把中文表述当成偏主观的“软意见”。同一句话用中文说“我担心迁移成本”和用英文说“I have concerns about the migration cost”在观点处理器里被归类出来的立场强度不一样。解决方法是把观点处理器的输入文本做一次前置规范化所有语言统一转换成结构化帧格式术语保留原语言但情感色彩量词全部归一化。这个处理发生在分类之前模型根本看不到原始的情感词汇差异分类就不会被带偏。6. 分支方向上的一些教训与个人方法如果你也想复刻这套思路我给一个建议流程。第一步先别碰代码把你的讨论流程在纸面上画清楚你希望每一个讨论阶段让 AI 扮演什么角色这个角色的行为边界是什么。第二步再去看提示词提示词的作用是驯服模型但结构设计才能保证系统不跑偏。第三步才是做原型原型阶段优先做一个闭环角一个简单议题三个参与者,跑十轮人工检查每一轮的输出是否触犯了三条约束把违例案例贴回提示词作为负面示例。我在实际使用中还有一个比较主观的经验这个系统最好的搭档不是那种“脱口而出型”的大模型而是更偏向“深思熟虑型”的模型。因为讨论推进器生成的问题本身需要一定的延迟和斟酌那些涌现能力强的模型反而会让系统显得过于激烈动不动就抛出让人“眼前一亮”但其实是噪音的问题。我一度非常喜欢那种输出但后来发现讨论系统的用户需要的是稳定、连贯的引导而不是一联串的“灵感火花”。另外一个学习到的小技巧是每当讨论中出现了很高质量的产出系统会自动把那段对话存进“高质量片段”集合。这个集合不做排名只标记来源上下文。下次拉开角度相似的讨论时系统会把这段历史作为一个可选的参考案例推给参与者并明确告诉参与者“这是上一场讨论的片断仅供参考”。很多人以为这个功能是要“拿历史经验压人”但实际它是反过来它让参与者知道同样的问题此前已经有个深入的思考样本你们可以站在这之上也可以推翻它。最后再分享一个关于“AI 不做裁判”这件事的体会。技术层面上让大模型不裁判相对容易提示词和架构约束就够用了。难的是让参与者真的不用 AI 的裁判身份去逃避自己的判断。系统一上线总有人会问“所以你觉得哪个方案更好”我的统一回答是这系统存在的目的就是让问不出这个问题的人有勇气自己回答。讨论系统最好的结果是参与者看完分歧地图自己说“我们得在这两个问题上拿主意”而不是等系统给一句话带到终点。