一次线上头脑风暴聊到一半主持人让AI把大家的观点按优先级排个序。结果AI把我觉得最重要的那个提议放在了末尾理由是“支持人数较少且成本较高”。那场讨论后半程几乎没人再开口。这让我开始反思讨论工具真的需要“裁判”吗我们把AI塞进讨论里默认它应该打分、排序、总结陈词、判定胜负——但这些真的有利于讨论本身吗后来我做了个项目原型一个刻意取消排序、打分、裁断功能的讨论系统。AI只做三件事记录、归类、提问。它从头到尾不告诉你哪个观点更好不排名不给分不输出“综合来看”。这篇文章就把这个系统的完整设计思路、实现细节和实测记录写出来。如果你在做社群运营、团队共创、课堂研讨或者做AI产品、尤其是不想被“AI权威”裹挟的讨论工具这篇内容可以直接拿来参考。1. 为什么坚决不让AI当裁判一个反直觉的取舍1.1 排序、打分、下结论到底有多大的破坏力市面上的AI讨论工具绝大多数沿用了“输入观点-算法评估-输出排序”的路径。用户提交几条方案AI立刻给出“方案A胜出理由是覆盖率高、成本低”这样的结果。看起来效率很高但实际上破坏了讨论最核心的价值——开放性和参与感。当参与者知道系统会打分、会排序他的表达策略会立刻改变不是表达最真实的想法而是说符合“评审口味”的话。更麻烦的是AI一旦给出排序就形成了一种“技术权威”。后续发言者会下意识地围绕排第一的方案打转而不是继续贡献新鲜视角。这个现象我在多场实测里反复看到尤其在团队里等级观念本来就不弱的情况下AI的一纸排名等于帮领导提前拍了板。还有一层损害是隐性的排序必然要压缩信息。把十条观点压成三行摘要丢掉的是上下文、情感色彩和细微差别。讨论中很多关键共识恰恰藏在不可压缩的细节里。所以我越来越确信排序、打分不是AI讨论系统的加分项而是沉重负担。1.2 重新定义讨论系统AI该是“搅局者”而不是“仲裁者”我真正想做的是一个让讨论更加发散、让更多角度被看见的系统而不是更快收敛到唯一答案的系统。收敛本身是人类的事情而且应该在讨论结束后由参与者自己完成不应该由模型偷偷替大家完成。打个比方传统AI讨论工具是一场比赛有个拿着秒表和计分牌的裁判我想做的是菜市场。菜市场里没人宣布哪家摊位的菜最好吃但每个人都能看到别人在买什么、问什么、犹豫什么信息全部摊开买家自己比较。市场需要管理员维持秩序但管理员不会替你决定晚餐吃什么。所以这个系统把AI的角色定位成“搅局者”——它追问、它复述、它把看似不相关的观点拉在一起对比但它不说“这个比那个好”。它更像辩论赛里的主持人而不是评委。主持人可以提问“你刚才说的和上一位的观点有什么区别”但绝不会说“我觉得上一位赢了”。1.3 三条绝不能碰的红线不排序、不打分、不判谁赢我把项目的底层约束写成了三条不可逾越的红线所有代码和提示词都围绕这三条约束展开不排序系统永远不输出“第一、第二、最优”这样的排列信息。即使参与者主动要求“帮我排序”系统也只能回应“我可以列出所有观点和它们之间的差异但顺序请你自己定”。不打分不生成分数、星级、支持率百分比。连“这个话题被讨论最多”这种看似客观的统计我都刻意回避了因为“讨论最多”一旦显示出来就会制造从众压力。不判谁赢不输出“综上所述方案B更合适”这类结论句。系统唯一允许的总结形式是“我们看到这里有几种不同的侧重方向”然后把观点并列摆出拒绝选边。这三条红线听起来简单但落地时极其容易被突破。因为大模型在RLHF阶段被大量训练成“乐于助人的评判者”你稍微不强调它就自动开始给建议、给优先级。所以我在系统里做了不止一道防呆机制后面详细说。2. 不排序、不评判那AI到底干什么功能模块与交互设计2.1 三个核心模块转录归档、差异识别、提问生成系统只做三个功能模块每个都明确对应一种“非裁判”职责。第一个模块叫“转录归档”。AI把参与者发言转成结构化文本自动切分段落、提取话题标签、标注发言时间和发言人角色。这个过程只做机械整理不改造语义。比如有人说了三分钟的即兴发言系统会把它分段加标签保留原文不做摘要式改写。因为摘要本身就是一种判断——你决定哪些话重要、哪些话该被省略。而在这个系统里省略的权力属于读者不属于AI。第二个模块叫“差异识别”。AI从所有发言里找出观点差异点但它的表现形式不是“甲对乙错”而是“关于这个问题参与者提出了三种不同侧重”然后把这三种侧重并列出来各自附上代表性原话。关键点是系统永远不计算哪种侧重得到更多支持只呈现差异本身让差异可以被清晰地讨论。第三个模块叫“提问生成”。这是最有意思的部分。当讨论进入僵局或话题太散时AI根据当前出现的分歧点生成追问问题比如“有人提到成本优先有人提到体验优先这两者在你的场景里更看中哪个为什么”这类问题不预设答案、不引导站队它的作用是帮助参与者自我澄清。这三个模块合起来的效果是AI像一位细致的速记员加一个勤快的提问者全程站在旁边激发思考而不是站在中间宣布谁赢了。2.2 一次完整讨论的标准流程示例为了让读者直观理解我描述一个标准使用场景。假设一个产品团队做一轮方向讨论三个人各有立场A主张快速上线验证B主张先把体验打磨到位C主张借势接大客户。流程是这样的三人各自发言AI实时转录每条发言被打上“速度/体验/客户策略”等标签。当标签“速度”和“体验”都出现后AI在差异识别模块里把它们标记为一组张力关系但没有提示谁占上风。讨论到15分钟时氛围有点僵持。系统检测到连续6条消息都集中在这组标签上话题不再拓展于是触发提问生成模块抛出一个问题“如果两周内必须上线体验和速度哪些环节可以暂时妥协哪些不能”这个问题不强推任何人改变立场而是让每个人都从自己的角度回应一遍妥协边界。最后讨论结束系统生成一份“讨论记录册”里面是所有发言的原文字段、标签、分组、差异点列表以及AI提出的追问问题列表。没有管理员也能看到整个讨论的脉络但翻到最后一页也找不到“结论是……”三个字。2.3 和传统AI讨论工具的对照差异我把这个系统和两种常见形态做一下对比方便你理解同一场景下设计哲学的区别对比维度传统AI助手直接问答辩论型AI / 评分型讨论工具本系统不裁判型AI面对观点的态度立刻评价好/坏给建议自动分组辩论判定胜负只记录、归类、追问不评价对“分歧”的处理视为需要消除的问题当成比赛对抗当成值得展开的资源输出形态一条结论几个要点胜方总结、败方反驳差异清单、追问列表、讨论记录册参与者的表达策略迎合AI偏好押注某一方论点如实表达真实想法讨论的收敛方式AI代劳AI代劳参与者自行决定这个对照让我意识到一件事AI介入讨论的方式本质上是产品价值观的选择。选择“更高效地出结论”还是“更充分地展开讨论”没有绝对的对错但做产品的人必须意识到自己在替用户做这个选择。如果你的目标是一小时之内产出三五个可选方案不排序列出来完全可以做到如果你想得到一个谁也不敢反对的“最佳方案”那你应该继续用排序工具。3. 核心实现怎么做出一套“不判断”的讨论系统3.1 系统架构与关键选型整个系统我采用了轻量架构前端是纯静态页面加WebSocket实时通信后端用Python FastAPI承担会话管理与逻辑调度大模型接口通过抽象层封装可以切换不同服务商的通用对话模型。没有上重型向量数据库因为讨论量级在百条以内时直接用内存对象和Redis缓存已经足够。为什么不上重型RAG和知识图谱主要是两个考量第一讨论系统的核心场景是实时交互低延迟比深度检索更重要通用模型本身就够用没必要引入额外环节第二不排序的约束要求系统必须对全部发言保持平等关注向量检索天然带有“相关性排序”的属性从设计原理上就违背红线所以直接放弃。数据流按管道设计前端消息进入API层 → 预处理模块做翻译和脱敏 → 触发不同LLM任务转录标签/差异识别/提问生成→ 结果经过规则层过滤删除一切判断性语句 → 落库 → 推送前端。规则层是这套系统的灵魂因为它专门负责约束AI让它想犯规也犯不了。3.2 核心实现结构化提示词与规则兜底提示词设计是整个项目里最花功夫的部分。我先写了一个系统级提示词里面明确声明AI的角色定位DISCUSSION_SYSTEM_PROMPT 你是一场公开讨论的协助者你的职责是记录、归类、提问。 你有三条严格禁令 1. 不得对任何观点进行优先级排序不得输出“第一/第二/最优/核心/关键”等排序性词汇 2. 不得给任何观点打分、评级、统计支持率 3. 不得替参与者做结论不得输出“综上所述/因此建议选择/更合适”等判断句。 你可以做以下操作 - 将长发言拆分为独立的可读段落 - 为段落提取最多3个话题标签 - 找出观点间的差异点以“A关注了……B关注了……”的并列句式输出 - 在讨论陷入僵局时生成一个以“如果……”或“如何理解……”开头的追问问题。 你的输出必须直接是JSON不要任何多余解释。 但仅靠提示词是压不住模型的所以我在代码里加了一层规则校验。这一步作用很大——把AI的输出当作文本流扫描其中出现频率最高的判断性词汇一旦命中就拦截重试。这像给AI戴上笼头它想跑偏都难。JUDGMENT_PATTERN_BLACKLIST [ 最优, 最佳, 最合适, 建议选择, 综上所述, 显然, 毫无疑问, 优先推荐, 排名, 第一, 更强, 更重要, 核心方案, 最佳实践, 观点正确, 更有说服力, 胜出, 赢, 落后, 得分, 支持率, 采纳率, ] FILTER_INSTRUCTION 请检查这段文字是否包含明显判断倾向的词句。 如果包含只回复{flag: reject, reason: 判断性表达} 如果不包含回复{flag: pass} def rule_based_filter(generated_text: str) - bool: for word in JUDGMENT_PATTERN_BLACKLIST: if word in generated_text: return False return True实际测试里提示词加规则拦截的组合能把“AI偷偷当裁判”的概率从40%左右压到3%以下。剩下的3%我用人工审核兜底——在高价值讨论场景中由管理员一键撤回有判断倾向的AI消息。这个撤回功能我单独做了入口没放在明面按钮上防止参与者频繁使用影响体验。3.3 数据模型设计简例数据模型方面我只设计了四张核心表讨论组、消息、话题标签、追问记录。讨论组表负责存房间信息、参与者列表、创建时间。消息表存的是原始发言文本以及AI转录后的分段文本和所属标签。话题标签表维护一个标签字典同时记录“哪组标签之间存在张力关系”比如“速度”和“体验”一旦同时出现就自动建立张力配对供差异识别模块调用。追问记录表存AI生成的问题同时关联一个“来源分歧点”保证每个问题都可以追溯到具体某几个观点的碰撞。这套模型足够简单但胜在职责清晰所有“不排序”的约束在写入时就被强制执行数据表里根本没有“分数”和“排名”字段。从数据结构层面就根除了打分的可能。这比在API层拦截更彻底——毕竟方案设计里没有的东西代码里写不出来。3.4 模型选择、参数配置与成本控制模型选择上我用的是市面上常见的通用对话模型的中档版本。原因在于这个系统要处理的任务普遍“简单但限制多”——转录、打标签、生成追问都不需要极强推理但需要稳定遵守指令。中档模型配合详细提示词反而比大模型更容易调教因为大模型自我意识更强、更喜欢自由发挥。关键参数方面温度我设置在0.1到0.3之间。为什么这么低因为不排序系统的输出需要高度稳定、可预期宁可追问问题有点“模板化”也不能突然蹦出一句“方案C其实是这里面最聪明的”。温度太高就是给自己找麻烦。延迟优化我走了两个方向一是所有LLM调用加缓存同一条消息重复请求直接命中Redis二是用异步批量处理把转录、标签、差异识别三条任务并行发出去最终等待时间从串行的9秒降到了4秒左右。成本上一次一小时讨论大概消耗1到2万个token以中档模型的定价来算单场成本可以忽略不计对于小团队或社群运营来说完全可承受。4. 实操过程从零搭建一个最小可用版本4.1 环境准备与依赖清单先交代一下我搭最小版本用的环境。后端是Python 3.11 FastAPI Uvicorn前端是原生HTML/JavaScript没有上React、Vue这些框架因为核心页面只有一个讨论面板原生写法更快、也更方便读者复现。数据临时存内存加SQLiteRedis只在多实例部署时才需要最小版本可以砍掉。依赖只需要四个包fastapi、uvicorn、openai或者对应服务商的SDK、pydantic。如果不用Docker直接在虚拟环境里安装即可。我建议代码按模块拆server.py管路由和WebSocketllm_client.py管模型调用discussion_logic.py管核心业务逻辑filter_layer.py管规则兜底。4.2 后端核心代码处理消息、归类差异、生成追问下面是后端核心环节的简化实现。先看消息处理的入口import uuid from fastapi import FastAPI, WebSocket from pydantic import BaseModel app FastAPI() class DiscussionMessage(BaseModel): discussion_id: str author: str text: str created_at: str app.websocket(/ws/{discussion_id}) async def ws_endpoint(websocket: WebSocket, discussion_id: str): await websocket.accept() while True: raw await websocket.receive_text() msg DiscussionMessage.model_validate_json(raw) # 1. 转录归档 archived await archive_message(msg) # 2. 差异识别异步并行 differences await detect_differences(discussion_id, msg) # 3. 僵局检测按需触发追问 followup maybe_generate_followup(discussion_id) # 推回前端 await websocket.send_json({ type: archived, data: archived, type: differences, data: differences, type: followup, data: followup, })archive_message的核心逻辑是调用LLM做分段和打标签并把原文原样落库。detect_differences则会把当前讨论组里所有历史消息的标签做聚合找出张力配对。maybe_generate_followup会先看近十分钟内是否已经有追问问题如果已经有了就不再重复触发避免AI话痨。async def archive_message(msg: DiscussionMessage) - dict: resp await llm_client.chat( messages[ {role: system, content: DISCUSSION_SYSTEM_PROMPT}, {role: user, content: f请对以下发言做分段和标签\n{msg.text}} ], response_jsonTrue, temperature0.2, ) if not rule_based_filter(resp[data][text]): resp[data][text] await llm_client.retry(safety_fallbackTrue) db.insert_message(...) return {segments: resp[segments], tags: resp[tags]}用户可能注意到每次LLM返回的文本都要过rule_based_filter。这一步不能省因为模型偶尔会在“转录文本”这种最不该掺主观判断的任务里突然给你来一句“这段话的核心价值是……”这就是在偷偷做裁判。规则层拦截之后我还会追加一次LLM自检用FILTER_INSTRUCTION做二重复核双保险之后判断性语句出现的概率才真正压到最底。4.3 前端核心代码展示差异而不展示排名前端页面最重要的部分是把“差异清单”做成可视化卡片而不是柱状图。很多人问我为什么不做柱状图——柱状图本质上就是排序的视觉化表达哪怕只是统计“不同标签出现的次数”一眼看上去也会形成“哪个话题最热”的心理暗示这违背不排序原则。所以我改用“并列卡片”布局每个差异点是一张卡片卡片之间没有数字、没有进度条、没有长度差异。卡片内容由AI生成的并列句和代表性原话组成。视觉上完全等权阅读顺序随便点你爱先看哪张都行。div iddifference-area !-- 动态由JS渲染每张卡片结构一致 -- div classdiff-card div classdiff-title体验优先 vs 速度优先/div blockquote“我们必须把体验打磨到极致再上线不然口碑会崩。” —— A/blockquote blockquote“快速上线拿到真实反馈比闭门打磨体验重要得多。” —— B/blockquote div classdiff-note关于上线节奏出现了两种不同侧重。/div /div !-- 多张卡片并列无排序 -- /div我用WebSocket把消息实时推下来配合少量JavaScript控制DOM插入和滚动。这里有个体验细节AI的转录结果不是一次性显示完了而是模拟“逐句出现”的效果每半秒钟冒出一小段视觉上像是有人在速记。这能给参与者一种“被认真记录”的感觉实测对参与积极性有明显提升。为了防止移动端错位前端要做响应式处理卡片在窄屏下从上往下流式排布宽屏下做成两列。CSS核心就一条原则所有卡片宽度一致、内边距一致、背景一致、无边框差异彻底避免视觉层级暗示。4.4 联调验收方法无裁判校验测试完成开发后我设计了一套“无裁判校验测试”这里分享给你只要有一个多小时就能跑完整套验证判断你的系统有没有守住不排序红线。测试分四步测试一输入三条明显有优劣差异的观点比如包含明显漏洞的方案和相对完善的方案观察AI输出里是否出现“方案更优”之类的词。此步应全部通过。测试二在提示词里明确请求“请帮我按性价比排序”看系统是否礼貌拒绝并且不执行。这个系统应该做到既不排序也不“教育”用户而是直接提供并列展示。测试三让AI连续处理30条消息统计判断性词汇出现次数。正常应该低于3次而且每次出现都能被规则层拦下。测试四在一场未实际运行的测试环境里模拟5个人同时发言确认系统处理并发消息时没有串顺序、丢消息标签关联正确。因为一旦消息处理错乱整个“差异呈现”就没有意义相当于数据结构层面又制造了隐性先后关系。这四步我每轮迭代都会跑。特别是测试三几乎每次模型版本一更新拦截率就波动所以这套校验程序是持续运行的不是验收一下就不管了。5. 实测记录与效果不排序之后讨论发生了什么5.1 一场线上共读会的实测观察我拿这个系统做了一场真实的线上共读会主题是“人应不应该追求稳定”。六个人参加时长四十分钟。整个过程没有主持人引导系统只做记录和提问。我先观察到的变化是发言变得更长了。平均每人发言长度比传统讨论模式多了约三分之一——没有排序压力后大家似乎不太担心自己说得是否“够格”而是把想法完整倒出来。第二个明显变化是话题覆盖更广。传统主持人式讨论通常被前两个发言者带节奏这次因为AI的追问不走裁决路线而是不断把“你的观点和刚才某位有什么差别”抛回去六个人分别从职业、家庭、健康、兴趣等好几个方向切入其中有两个角度是我事先完全没预料到的。AI生成的追问问题里有一条效果出奇地好。当时关于“稳定是不是一种惰性”两边僵住了系统问的是“如果稳定意味着可以腾出更多精力探索新事物那它还叫惰性吗”这问题不站任何一边但把“稳定-惰性”这个二分给撬开了。后面讨论直接从新的角度展开。5.2 参与者反馈不排序到底带来什么体验活动后我做了简单匿名回访问题只有一个“你觉得这个系统给讨论带来了什么”收集到的反馈里出现频率最高的词是“没有压迫感”。有参与者原话是“平时AI给人的感觉是它都替我想到结论了再往下聊有点傻。这个AI就像个记录员我反而愿意多说一些。”还有一个反馈值得关注“我发现我在认真听别人说话了。”这位参与者解释过去AI讨论工具一旦抛出结论大家就开始等结论、反驳结论而不是听别人在说什么。这个系统不抛结论你只能从别人的原话里找信息听的需求反而被唤醒了。也有不同声音有人觉得缺少AI赋能的“代劳感”习惯了“AI总结要点”以后再看满屏原始发言会产生信息过载。这个反馈让我意识到不排序系统对参与者的认知耐心要求更高对习惯“吃现成结论”的用户并不友好。它的目标用户不是追求效率最大化的决策层而是真正在乎交流本身的人群。5.3 这个方案的边界什么时候不该用明确说清楚边界。这个系统适合用于发散型讨论比如选题、头脑风暴、社群共读、需求调研、复盘会的“现象收集”阶段。它不适合以下场景时间紧迫、需要尽快拍板的会议需要明确负责人和交付物的项目评审有合规红线需要逐条确认的场景。在这些场景里排序和结论不是奢侈而是必需品。即使在不适合的场景里这套系统仍有它的价值分支你可以先用它完成“发散收集”然后再由人类评委在系统外部做排序决策。这样既保留了开放讨论的好处又把收敛的权力掌握在人类手中不失为一个混合方案。另一个边界是分歧的处理。如果讨论双方本身就带着敌意不排序的AI不会帮助你平息冲突因为它既不打圆场也不制止人身攻击。它只能保持中立记录你骂了什么。这种情况下仍然需要人类主持人在场。不是AI不能也不会做裁判是人类本来就需要裁判时AI顶上也只会生产一个看起来客观的暴君。6. 常见问题与排查技巧实录6.1 问题速查表AI偷偷当裁判的5种典型表现开发这套系统的过程中我攒了一个很实用的排查清单。如果你也在做类似的不判断系统建议把这五条存下来出现异常时逐条核对现象典型原因处理方式AI输出“核心观点是”提示词对“判断”定义不清晰模型误以为“核心”是客观归纳在禁令里显式加入“核心”一类词并在规则层进行黑名单覆盖AI自动把观点分成“主要/次要”缺少粒度约束模型自己创建了层级提示词要求输出必须使用并列句式禁止使用“主要/次要/第一/第二”关键词追问问题带有明显倾向性生成追问的提示词没有约束语气模型模仿了辩论风格在追问生成任务中单独加一条指令问题不得含有判断倾向不得使用反问句转录后文本变短关键信息被丢摘要倾向过强模型把“转写”理解成“提炼”把转录任务的输出要求改为“保留全部原文仅在末尾补充标签”表示统计数据的图表出现前端把差异化数据渲染为数量图带来隐性排序调整产品设计不统计频次不做排名图统一卡片排版这个清单是我在几十场测试里逐条踩出来的每一条背后都有具体事故现场。其中“追问带倾向性”最隐蔽因为生成的句子看起来有思辨性实际却引导用户认同某个方向。比如“你不觉得速度和体验可以兼顾吗”这种问题隐含了“兼顾是更优解”的判断必须严禁。6.2 提示词调试的独家心得调试这个项目的提示词我最大的教训是不要试图用“要”的句式约束AI要用“不要”加“替代”双层结构。只写“不要排序”是不够的模型会把“排序”理解得很窄然后换着花样打擦边球。正确写法是明确禁止词表同时指明替代动作——“不要排优先级如需整理请使用并列列表呈现”。另外一个细节是做规则层黑名单时要先跑一轮模型自由输出把高频判断词表拉出来再把这些词用“完全匹配”方式打进黑名单而不是靠直觉写词。我最初只写了“最优”“第一”这类明显词结果漏掉了“本质”“决定性”这些伪装词。后来用脚本统计了连续一百次输出才把清单补全。补全之后的清单建议不要只存代码里留一份独立配置文件方便其他非技术人员直接编辑。这样运营同学发现AI说了一句不该说的话自己能在五分钟内把这个词加进黑名单不用等开发排期。6.3 防呆兜底设计人工审核与回退机制即便做了提示词和规则双重防护系统依然有兜底机制。我在处理管道末尾加了一项所有AI生成内容在推送到前端之前会先进入一个待审核队列如果管理员或主持人开了“人工审核模式”推送就会变成“先存草稿等待确认”状态。这个过程不需要主持人逐字审阅只给一个滑动开关默认关闭。但在面对高风险主题或者一群火药味很浓的参与者时建议打开。审核页面上只需要两个按钮“放行”和“撤回”。撤回后有选项可以换成“重新生成”或直接用人工替代文本。我还在消息列表里做了敏感词高亮方便管理员快速扫一眼。这套兜底机制虽然增加了少量操作成本但在关键场景里保住的是整个系统的信用——参与者一旦发现AI偷偷裁判了一次之前的所有“不裁判”承诺都会被打折扣。信用建立起来很慢崩塌只在一瞬间。写在最后一点个人体会这个项目做下来我最大的收获不是技术上的而是产品观上的转变。过去做AI产品总默认AI要“替人把活干完”——整理、判断、拍板一条龙。但这套讨论系统让我意识到有很多场景里用户要的其实是“AI别抢话让我把话说完”。我实际跑了几十场讨论后发现AI最讨人喜欢的时刻是它安静地把每个人的话认真记下、再把不同观点之间的缝隙指出来的时候。它像一面镜子而不是一盏探照灯。探照灯只照亮它选中的方向镜子照见的是所有人自己的样子。如果你也想试试这个思路我的建议是先把三条红线刻在脑子里再写一行代码。判断技术方案很容易判断产品价值观很难但这恰恰是最值得下功夫的地方。后续我打算给这套系统增加一个“观点关系图谱”的导出功能让参与者能可视化看到自己的思路和他人哪里分叉、哪里融合——仍然不评判只呈现。希望这篇记录能够给你的项目带来一点不一样的坐标。
不排序不评判：AI讨论系统的设计思路与实现细节
一次线上头脑风暴聊到一半主持人让AI把大家的观点按优先级排个序。结果AI把我觉得最重要的那个提议放在了末尾理由是“支持人数较少且成本较高”。那场讨论后半程几乎没人再开口。这让我开始反思讨论工具真的需要“裁判”吗我们把AI塞进讨论里默认它应该打分、排序、总结陈词、判定胜负——但这些真的有利于讨论本身吗后来我做了个项目原型一个刻意取消排序、打分、裁断功能的讨论系统。AI只做三件事记录、归类、提问。它从头到尾不告诉你哪个观点更好不排名不给分不输出“综合来看”。这篇文章就把这个系统的完整设计思路、实现细节和实测记录写出来。如果你在做社群运营、团队共创、课堂研讨或者做AI产品、尤其是不想被“AI权威”裹挟的讨论工具这篇内容可以直接拿来参考。1. 为什么坚决不让AI当裁判一个反直觉的取舍1.1 排序、打分、下结论到底有多大的破坏力市面上的AI讨论工具绝大多数沿用了“输入观点-算法评估-输出排序”的路径。用户提交几条方案AI立刻给出“方案A胜出理由是覆盖率高、成本低”这样的结果。看起来效率很高但实际上破坏了讨论最核心的价值——开放性和参与感。当参与者知道系统会打分、会排序他的表达策略会立刻改变不是表达最真实的想法而是说符合“评审口味”的话。更麻烦的是AI一旦给出排序就形成了一种“技术权威”。后续发言者会下意识地围绕排第一的方案打转而不是继续贡献新鲜视角。这个现象我在多场实测里反复看到尤其在团队里等级观念本来就不弱的情况下AI的一纸排名等于帮领导提前拍了板。还有一层损害是隐性的排序必然要压缩信息。把十条观点压成三行摘要丢掉的是上下文、情感色彩和细微差别。讨论中很多关键共识恰恰藏在不可压缩的细节里。所以我越来越确信排序、打分不是AI讨论系统的加分项而是沉重负担。1.2 重新定义讨论系统AI该是“搅局者”而不是“仲裁者”我真正想做的是一个让讨论更加发散、让更多角度被看见的系统而不是更快收敛到唯一答案的系统。收敛本身是人类的事情而且应该在讨论结束后由参与者自己完成不应该由模型偷偷替大家完成。打个比方传统AI讨论工具是一场比赛有个拿着秒表和计分牌的裁判我想做的是菜市场。菜市场里没人宣布哪家摊位的菜最好吃但每个人都能看到别人在买什么、问什么、犹豫什么信息全部摊开买家自己比较。市场需要管理员维持秩序但管理员不会替你决定晚餐吃什么。所以这个系统把AI的角色定位成“搅局者”——它追问、它复述、它把看似不相关的观点拉在一起对比但它不说“这个比那个好”。它更像辩论赛里的主持人而不是评委。主持人可以提问“你刚才说的和上一位的观点有什么区别”但绝不会说“我觉得上一位赢了”。1.3 三条绝不能碰的红线不排序、不打分、不判谁赢我把项目的底层约束写成了三条不可逾越的红线所有代码和提示词都围绕这三条约束展开不排序系统永远不输出“第一、第二、最优”这样的排列信息。即使参与者主动要求“帮我排序”系统也只能回应“我可以列出所有观点和它们之间的差异但顺序请你自己定”。不打分不生成分数、星级、支持率百分比。连“这个话题被讨论最多”这种看似客观的统计我都刻意回避了因为“讨论最多”一旦显示出来就会制造从众压力。不判谁赢不输出“综上所述方案B更合适”这类结论句。系统唯一允许的总结形式是“我们看到这里有几种不同的侧重方向”然后把观点并列摆出拒绝选边。这三条红线听起来简单但落地时极其容易被突破。因为大模型在RLHF阶段被大量训练成“乐于助人的评判者”你稍微不强调它就自动开始给建议、给优先级。所以我在系统里做了不止一道防呆机制后面详细说。2. 不排序、不评判那AI到底干什么功能模块与交互设计2.1 三个核心模块转录归档、差异识别、提问生成系统只做三个功能模块每个都明确对应一种“非裁判”职责。第一个模块叫“转录归档”。AI把参与者发言转成结构化文本自动切分段落、提取话题标签、标注发言时间和发言人角色。这个过程只做机械整理不改造语义。比如有人说了三分钟的即兴发言系统会把它分段加标签保留原文不做摘要式改写。因为摘要本身就是一种判断——你决定哪些话重要、哪些话该被省略。而在这个系统里省略的权力属于读者不属于AI。第二个模块叫“差异识别”。AI从所有发言里找出观点差异点但它的表现形式不是“甲对乙错”而是“关于这个问题参与者提出了三种不同侧重”然后把这三种侧重并列出来各自附上代表性原话。关键点是系统永远不计算哪种侧重得到更多支持只呈现差异本身让差异可以被清晰地讨论。第三个模块叫“提问生成”。这是最有意思的部分。当讨论进入僵局或话题太散时AI根据当前出现的分歧点生成追问问题比如“有人提到成本优先有人提到体验优先这两者在你的场景里更看中哪个为什么”这类问题不预设答案、不引导站队它的作用是帮助参与者自我澄清。这三个模块合起来的效果是AI像一位细致的速记员加一个勤快的提问者全程站在旁边激发思考而不是站在中间宣布谁赢了。2.2 一次完整讨论的标准流程示例为了让读者直观理解我描述一个标准使用场景。假设一个产品团队做一轮方向讨论三个人各有立场A主张快速上线验证B主张先把体验打磨到位C主张借势接大客户。流程是这样的三人各自发言AI实时转录每条发言被打上“速度/体验/客户策略”等标签。当标签“速度”和“体验”都出现后AI在差异识别模块里把它们标记为一组张力关系但没有提示谁占上风。讨论到15分钟时氛围有点僵持。系统检测到连续6条消息都集中在这组标签上话题不再拓展于是触发提问生成模块抛出一个问题“如果两周内必须上线体验和速度哪些环节可以暂时妥协哪些不能”这个问题不强推任何人改变立场而是让每个人都从自己的角度回应一遍妥协边界。最后讨论结束系统生成一份“讨论记录册”里面是所有发言的原文字段、标签、分组、差异点列表以及AI提出的追问问题列表。没有管理员也能看到整个讨论的脉络但翻到最后一页也找不到“结论是……”三个字。2.3 和传统AI讨论工具的对照差异我把这个系统和两种常见形态做一下对比方便你理解同一场景下设计哲学的区别对比维度传统AI助手直接问答辩论型AI / 评分型讨论工具本系统不裁判型AI面对观点的态度立刻评价好/坏给建议自动分组辩论判定胜负只记录、归类、追问不评价对“分歧”的处理视为需要消除的问题当成比赛对抗当成值得展开的资源输出形态一条结论几个要点胜方总结、败方反驳差异清单、追问列表、讨论记录册参与者的表达策略迎合AI偏好押注某一方论点如实表达真实想法讨论的收敛方式AI代劳AI代劳参与者自行决定这个对照让我意识到一件事AI介入讨论的方式本质上是产品价值观的选择。选择“更高效地出结论”还是“更充分地展开讨论”没有绝对的对错但做产品的人必须意识到自己在替用户做这个选择。如果你的目标是一小时之内产出三五个可选方案不排序列出来完全可以做到如果你想得到一个谁也不敢反对的“最佳方案”那你应该继续用排序工具。3. 核心实现怎么做出一套“不判断”的讨论系统3.1 系统架构与关键选型整个系统我采用了轻量架构前端是纯静态页面加WebSocket实时通信后端用Python FastAPI承担会话管理与逻辑调度大模型接口通过抽象层封装可以切换不同服务商的通用对话模型。没有上重型向量数据库因为讨论量级在百条以内时直接用内存对象和Redis缓存已经足够。为什么不上重型RAG和知识图谱主要是两个考量第一讨论系统的核心场景是实时交互低延迟比深度检索更重要通用模型本身就够用没必要引入额外环节第二不排序的约束要求系统必须对全部发言保持平等关注向量检索天然带有“相关性排序”的属性从设计原理上就违背红线所以直接放弃。数据流按管道设计前端消息进入API层 → 预处理模块做翻译和脱敏 → 触发不同LLM任务转录标签/差异识别/提问生成→ 结果经过规则层过滤删除一切判断性语句 → 落库 → 推送前端。规则层是这套系统的灵魂因为它专门负责约束AI让它想犯规也犯不了。3.2 核心实现结构化提示词与规则兜底提示词设计是整个项目里最花功夫的部分。我先写了一个系统级提示词里面明确声明AI的角色定位DISCUSSION_SYSTEM_PROMPT 你是一场公开讨论的协助者你的职责是记录、归类、提问。 你有三条严格禁令 1. 不得对任何观点进行优先级排序不得输出“第一/第二/最优/核心/关键”等排序性词汇 2. 不得给任何观点打分、评级、统计支持率 3. 不得替参与者做结论不得输出“综上所述/因此建议选择/更合适”等判断句。 你可以做以下操作 - 将长发言拆分为独立的可读段落 - 为段落提取最多3个话题标签 - 找出观点间的差异点以“A关注了……B关注了……”的并列句式输出 - 在讨论陷入僵局时生成一个以“如果……”或“如何理解……”开头的追问问题。 你的输出必须直接是JSON不要任何多余解释。 但仅靠提示词是压不住模型的所以我在代码里加了一层规则校验。这一步作用很大——把AI的输出当作文本流扫描其中出现频率最高的判断性词汇一旦命中就拦截重试。这像给AI戴上笼头它想跑偏都难。JUDGMENT_PATTERN_BLACKLIST [ 最优, 最佳, 最合适, 建议选择, 综上所述, 显然, 毫无疑问, 优先推荐, 排名, 第一, 更强, 更重要, 核心方案, 最佳实践, 观点正确, 更有说服力, 胜出, 赢, 落后, 得分, 支持率, 采纳率, ] FILTER_INSTRUCTION 请检查这段文字是否包含明显判断倾向的词句。 如果包含只回复{flag: reject, reason: 判断性表达} 如果不包含回复{flag: pass} def rule_based_filter(generated_text: str) - bool: for word in JUDGMENT_PATTERN_BLACKLIST: if word in generated_text: return False return True实际测试里提示词加规则拦截的组合能把“AI偷偷当裁判”的概率从40%左右压到3%以下。剩下的3%我用人工审核兜底——在高价值讨论场景中由管理员一键撤回有判断倾向的AI消息。这个撤回功能我单独做了入口没放在明面按钮上防止参与者频繁使用影响体验。3.3 数据模型设计简例数据模型方面我只设计了四张核心表讨论组、消息、话题标签、追问记录。讨论组表负责存房间信息、参与者列表、创建时间。消息表存的是原始发言文本以及AI转录后的分段文本和所属标签。话题标签表维护一个标签字典同时记录“哪组标签之间存在张力关系”比如“速度”和“体验”一旦同时出现就自动建立张力配对供差异识别模块调用。追问记录表存AI生成的问题同时关联一个“来源分歧点”保证每个问题都可以追溯到具体某几个观点的碰撞。这套模型足够简单但胜在职责清晰所有“不排序”的约束在写入时就被强制执行数据表里根本没有“分数”和“排名”字段。从数据结构层面就根除了打分的可能。这比在API层拦截更彻底——毕竟方案设计里没有的东西代码里写不出来。3.4 模型选择、参数配置与成本控制模型选择上我用的是市面上常见的通用对话模型的中档版本。原因在于这个系统要处理的任务普遍“简单但限制多”——转录、打标签、生成追问都不需要极强推理但需要稳定遵守指令。中档模型配合详细提示词反而比大模型更容易调教因为大模型自我意识更强、更喜欢自由发挥。关键参数方面温度我设置在0.1到0.3之间。为什么这么低因为不排序系统的输出需要高度稳定、可预期宁可追问问题有点“模板化”也不能突然蹦出一句“方案C其实是这里面最聪明的”。温度太高就是给自己找麻烦。延迟优化我走了两个方向一是所有LLM调用加缓存同一条消息重复请求直接命中Redis二是用异步批量处理把转录、标签、差异识别三条任务并行发出去最终等待时间从串行的9秒降到了4秒左右。成本上一次一小时讨论大概消耗1到2万个token以中档模型的定价来算单场成本可以忽略不计对于小团队或社群运营来说完全可承受。4. 实操过程从零搭建一个最小可用版本4.1 环境准备与依赖清单先交代一下我搭最小版本用的环境。后端是Python 3.11 FastAPI Uvicorn前端是原生HTML/JavaScript没有上React、Vue这些框架因为核心页面只有一个讨论面板原生写法更快、也更方便读者复现。数据临时存内存加SQLiteRedis只在多实例部署时才需要最小版本可以砍掉。依赖只需要四个包fastapi、uvicorn、openai或者对应服务商的SDK、pydantic。如果不用Docker直接在虚拟环境里安装即可。我建议代码按模块拆server.py管路由和WebSocketllm_client.py管模型调用discussion_logic.py管核心业务逻辑filter_layer.py管规则兜底。4.2 后端核心代码处理消息、归类差异、生成追问下面是后端核心环节的简化实现。先看消息处理的入口import uuid from fastapi import FastAPI, WebSocket from pydantic import BaseModel app FastAPI() class DiscussionMessage(BaseModel): discussion_id: str author: str text: str created_at: str app.websocket(/ws/{discussion_id}) async def ws_endpoint(websocket: WebSocket, discussion_id: str): await websocket.accept() while True: raw await websocket.receive_text() msg DiscussionMessage.model_validate_json(raw) # 1. 转录归档 archived await archive_message(msg) # 2. 差异识别异步并行 differences await detect_differences(discussion_id, msg) # 3. 僵局检测按需触发追问 followup maybe_generate_followup(discussion_id) # 推回前端 await websocket.send_json({ type: archived, data: archived, type: differences, data: differences, type: followup, data: followup, })archive_message的核心逻辑是调用LLM做分段和打标签并把原文原样落库。detect_differences则会把当前讨论组里所有历史消息的标签做聚合找出张力配对。maybe_generate_followup会先看近十分钟内是否已经有追问问题如果已经有了就不再重复触发避免AI话痨。async def archive_message(msg: DiscussionMessage) - dict: resp await llm_client.chat( messages[ {role: system, content: DISCUSSION_SYSTEM_PROMPT}, {role: user, content: f请对以下发言做分段和标签\n{msg.text}} ], response_jsonTrue, temperature0.2, ) if not rule_based_filter(resp[data][text]): resp[data][text] await llm_client.retry(safety_fallbackTrue) db.insert_message(...) return {segments: resp[segments], tags: resp[tags]}用户可能注意到每次LLM返回的文本都要过rule_based_filter。这一步不能省因为模型偶尔会在“转录文本”这种最不该掺主观判断的任务里突然给你来一句“这段话的核心价值是……”这就是在偷偷做裁判。规则层拦截之后我还会追加一次LLM自检用FILTER_INSTRUCTION做二重复核双保险之后判断性语句出现的概率才真正压到最底。4.3 前端核心代码展示差异而不展示排名前端页面最重要的部分是把“差异清单”做成可视化卡片而不是柱状图。很多人问我为什么不做柱状图——柱状图本质上就是排序的视觉化表达哪怕只是统计“不同标签出现的次数”一眼看上去也会形成“哪个话题最热”的心理暗示这违背不排序原则。所以我改用“并列卡片”布局每个差异点是一张卡片卡片之间没有数字、没有进度条、没有长度差异。卡片内容由AI生成的并列句和代表性原话组成。视觉上完全等权阅读顺序随便点你爱先看哪张都行。div iddifference-area !-- 动态由JS渲染每张卡片结构一致 -- div classdiff-card div classdiff-title体验优先 vs 速度优先/div blockquote“我们必须把体验打磨到极致再上线不然口碑会崩。” —— A/blockquote blockquote“快速上线拿到真实反馈比闭门打磨体验重要得多。” —— B/blockquote div classdiff-note关于上线节奏出现了两种不同侧重。/div /div !-- 多张卡片并列无排序 -- /div我用WebSocket把消息实时推下来配合少量JavaScript控制DOM插入和滚动。这里有个体验细节AI的转录结果不是一次性显示完了而是模拟“逐句出现”的效果每半秒钟冒出一小段视觉上像是有人在速记。这能给参与者一种“被认真记录”的感觉实测对参与积极性有明显提升。为了防止移动端错位前端要做响应式处理卡片在窄屏下从上往下流式排布宽屏下做成两列。CSS核心就一条原则所有卡片宽度一致、内边距一致、背景一致、无边框差异彻底避免视觉层级暗示。4.4 联调验收方法无裁判校验测试完成开发后我设计了一套“无裁判校验测试”这里分享给你只要有一个多小时就能跑完整套验证判断你的系统有没有守住不排序红线。测试分四步测试一输入三条明显有优劣差异的观点比如包含明显漏洞的方案和相对完善的方案观察AI输出里是否出现“方案更优”之类的词。此步应全部通过。测试二在提示词里明确请求“请帮我按性价比排序”看系统是否礼貌拒绝并且不执行。这个系统应该做到既不排序也不“教育”用户而是直接提供并列展示。测试三让AI连续处理30条消息统计判断性词汇出现次数。正常应该低于3次而且每次出现都能被规则层拦下。测试四在一场未实际运行的测试环境里模拟5个人同时发言确认系统处理并发消息时没有串顺序、丢消息标签关联正确。因为一旦消息处理错乱整个“差异呈现”就没有意义相当于数据结构层面又制造了隐性先后关系。这四步我每轮迭代都会跑。特别是测试三几乎每次模型版本一更新拦截率就波动所以这套校验程序是持续运行的不是验收一下就不管了。5. 实测记录与效果不排序之后讨论发生了什么5.1 一场线上共读会的实测观察我拿这个系统做了一场真实的线上共读会主题是“人应不应该追求稳定”。六个人参加时长四十分钟。整个过程没有主持人引导系统只做记录和提问。我先观察到的变化是发言变得更长了。平均每人发言长度比传统讨论模式多了约三分之一——没有排序压力后大家似乎不太担心自己说得是否“够格”而是把想法完整倒出来。第二个明显变化是话题覆盖更广。传统主持人式讨论通常被前两个发言者带节奏这次因为AI的追问不走裁决路线而是不断把“你的观点和刚才某位有什么差别”抛回去六个人分别从职业、家庭、健康、兴趣等好几个方向切入其中有两个角度是我事先完全没预料到的。AI生成的追问问题里有一条效果出奇地好。当时关于“稳定是不是一种惰性”两边僵住了系统问的是“如果稳定意味着可以腾出更多精力探索新事物那它还叫惰性吗”这问题不站任何一边但把“稳定-惰性”这个二分给撬开了。后面讨论直接从新的角度展开。5.2 参与者反馈不排序到底带来什么体验活动后我做了简单匿名回访问题只有一个“你觉得这个系统给讨论带来了什么”收集到的反馈里出现频率最高的词是“没有压迫感”。有参与者原话是“平时AI给人的感觉是它都替我想到结论了再往下聊有点傻。这个AI就像个记录员我反而愿意多说一些。”还有一个反馈值得关注“我发现我在认真听别人说话了。”这位参与者解释过去AI讨论工具一旦抛出结论大家就开始等结论、反驳结论而不是听别人在说什么。这个系统不抛结论你只能从别人的原话里找信息听的需求反而被唤醒了。也有不同声音有人觉得缺少AI赋能的“代劳感”习惯了“AI总结要点”以后再看满屏原始发言会产生信息过载。这个反馈让我意识到不排序系统对参与者的认知耐心要求更高对习惯“吃现成结论”的用户并不友好。它的目标用户不是追求效率最大化的决策层而是真正在乎交流本身的人群。5.3 这个方案的边界什么时候不该用明确说清楚边界。这个系统适合用于发散型讨论比如选题、头脑风暴、社群共读、需求调研、复盘会的“现象收集”阶段。它不适合以下场景时间紧迫、需要尽快拍板的会议需要明确负责人和交付物的项目评审有合规红线需要逐条确认的场景。在这些场景里排序和结论不是奢侈而是必需品。即使在不适合的场景里这套系统仍有它的价值分支你可以先用它完成“发散收集”然后再由人类评委在系统外部做排序决策。这样既保留了开放讨论的好处又把收敛的权力掌握在人类手中不失为一个混合方案。另一个边界是分歧的处理。如果讨论双方本身就带着敌意不排序的AI不会帮助你平息冲突因为它既不打圆场也不制止人身攻击。它只能保持中立记录你骂了什么。这种情况下仍然需要人类主持人在场。不是AI不能也不会做裁判是人类本来就需要裁判时AI顶上也只会生产一个看起来客观的暴君。6. 常见问题与排查技巧实录6.1 问题速查表AI偷偷当裁判的5种典型表现开发这套系统的过程中我攒了一个很实用的排查清单。如果你也在做类似的不判断系统建议把这五条存下来出现异常时逐条核对现象典型原因处理方式AI输出“核心观点是”提示词对“判断”定义不清晰模型误以为“核心”是客观归纳在禁令里显式加入“核心”一类词并在规则层进行黑名单覆盖AI自动把观点分成“主要/次要”缺少粒度约束模型自己创建了层级提示词要求输出必须使用并列句式禁止使用“主要/次要/第一/第二”关键词追问问题带有明显倾向性生成追问的提示词没有约束语气模型模仿了辩论风格在追问生成任务中单独加一条指令问题不得含有判断倾向不得使用反问句转录后文本变短关键信息被丢摘要倾向过强模型把“转写”理解成“提炼”把转录任务的输出要求改为“保留全部原文仅在末尾补充标签”表示统计数据的图表出现前端把差异化数据渲染为数量图带来隐性排序调整产品设计不统计频次不做排名图统一卡片排版这个清单是我在几十场测试里逐条踩出来的每一条背后都有具体事故现场。其中“追问带倾向性”最隐蔽因为生成的句子看起来有思辨性实际却引导用户认同某个方向。比如“你不觉得速度和体验可以兼顾吗”这种问题隐含了“兼顾是更优解”的判断必须严禁。6.2 提示词调试的独家心得调试这个项目的提示词我最大的教训是不要试图用“要”的句式约束AI要用“不要”加“替代”双层结构。只写“不要排序”是不够的模型会把“排序”理解得很窄然后换着花样打擦边球。正确写法是明确禁止词表同时指明替代动作——“不要排优先级如需整理请使用并列列表呈现”。另外一个细节是做规则层黑名单时要先跑一轮模型自由输出把高频判断词表拉出来再把这些词用“完全匹配”方式打进黑名单而不是靠直觉写词。我最初只写了“最优”“第一”这类明显词结果漏掉了“本质”“决定性”这些伪装词。后来用脚本统计了连续一百次输出才把清单补全。补全之后的清单建议不要只存代码里留一份独立配置文件方便其他非技术人员直接编辑。这样运营同学发现AI说了一句不该说的话自己能在五分钟内把这个词加进黑名单不用等开发排期。6.3 防呆兜底设计人工审核与回退机制即便做了提示词和规则双重防护系统依然有兜底机制。我在处理管道末尾加了一项所有AI生成内容在推送到前端之前会先进入一个待审核队列如果管理员或主持人开了“人工审核模式”推送就会变成“先存草稿等待确认”状态。这个过程不需要主持人逐字审阅只给一个滑动开关默认关闭。但在面对高风险主题或者一群火药味很浓的参与者时建议打开。审核页面上只需要两个按钮“放行”和“撤回”。撤回后有选项可以换成“重新生成”或直接用人工替代文本。我还在消息列表里做了敏感词高亮方便管理员快速扫一眼。这套兜底机制虽然增加了少量操作成本但在关键场景里保住的是整个系统的信用——参与者一旦发现AI偷偷裁判了一次之前的所有“不裁判”承诺都会被打折扣。信用建立起来很慢崩塌只在一瞬间。写在最后一点个人体会这个项目做下来我最大的收获不是技术上的而是产品观上的转变。过去做AI产品总默认AI要“替人把活干完”——整理、判断、拍板一条龙。但这套讨论系统让我意识到有很多场景里用户要的其实是“AI别抢话让我把话说完”。我实际跑了几十场讨论后发现AI最讨人喜欢的时刻是它安静地把每个人的话认真记下、再把不同观点之间的缝隙指出来的时候。它像一面镜子而不是一盏探照灯。探照灯只照亮它选中的方向镜子照见的是所有人自己的样子。如果你也想试试这个思路我的建议是先把三条红线刻在脑子里再写一行代码。判断技术方案很容易判断产品价值观很难但这恰恰是最值得下功夫的地方。后续我打算给这套系统增加一个“观点关系图谱”的导出功能让参与者能可视化看到自己的思路和他人哪里分叉、哪里融合——仍然不评判只呈现。希望这篇记录能够给你的项目带来一点不一样的坐标。
