AI不做裁判:不排序不打分的讨论系统设计实践
1. 这个系统的原点我们为什么受够了裁判式AI去年年底我参与了一个群组讨论工具的改造最初的需求非常简单让AI把大家的发言“梳理清楚”。但产品会上有人加了一句——“顺便给每个方案打打分排个序评出最优解”。当时我没觉得有问题直到我们真的把排序功能上线整个讨论的气质立刻变了大家不再围绕问题本身展开而是开始揣测“AI到底喜欢哪个方案”有人看到自己的观点排在后面直接开始阴阳怪气还有人为了让AI给高分把发言改成了“投其所好”的营销话术。那一次经历让我意识到一件很反直觉的事——排序和打分表面上是在“帮助”讨论实际上是在慢性杀死讨论。因为它们把一场本来应该开放的探索硬生生改造成了一场竞技比赛。所以我们后来做了这个“讨论系统”的项目它的核心路线就是标题里那句话AI不做裁判不排序、不打分、不判谁赢。这个系统的定位很明确它不是ChatGPT那种“你问我答”的助手也不是带排行榜的社区问答产品而是一个让多个人围绕复杂问题持续对话、AI只负责整理和辅助理解、但绝不裁决的讨论基础设施。适合三种人来参考一是做协作工具、社区产品的产品和开发者二是研究AI对话交互的算法/PM三是团队里负责引入AI工具、但又担心AI带偏决策的管理者。这篇文章会把设计思路、核心机制、实现过程和踩坑记录全部摊开来讲。2. 整体设计与核心思路为什么“不排序”反而更难做2.1 从“给答案”到“维持讨论场”的范式转换传统AI助手在讨论场景里默认角色是“解答者”甚至“仲裁者”。你抛一个问题过去它给你一段总结通常会自动带出“综合来看方案B更具优势”这类结论。这是大模型的惯性——因为训练数据里充满了“最佳实践”“最优解”的表述模型天然倾向于收敛。但真实的开放性问题往往没有标准答案。产品方向、公共政策、团队管理、技术选型……这些议题的特点是信息不完备、价值取向多元、利益相关方不同。在这种场景下强行收敛本质上是让AI用它的偏好替代群体的思考。所以我们做这个系统时把目标函数从“给出最优解”换成了“让讨论更充分、让分歧更清晰”。这个转换带来了一系列连锁反应。首先我们需要重新定义“信息组织”——不按优劣组织而是按时间脉络、主题关联、立场分布来组织。其次我们需要重新定义“AI输出”——不输出评价而是输出中性重构。最后我们需要重新设计交互——不能让用户觉得“没被排序就是没被重视”。2.2 三条铁律不排序、不打分、不判谁赢先说“不排序”。这里要澄清一个容易误解的点时间序也是一种排序。我们的系统默认所有观点按发言时间先后排列不做“热度优先”“赞同优先”“AI认为最有价值优先”这类价值排序。如果讨论量太大需要概览允许用户按“关联度”查看——这里查询的是语义相关性用的是嵌入向量的相似度排序它回答的是“哪些发言在说同一件事”而不是“谁的发言更好”。再说“不打分”。系统里没有任何地方会给单个观点输出1到10的评分也没有“质量分”“专业分”。AI在整理讨论时可以标注“这条观点属于事实陈述”“这条观点属于价值判断”“这条观点的依据是个人经验”这些都是描述性标签不是评价性打分。就像图书管理员给书贴分类标签但不判断哪本书更值得读。最后是“不判谁赢”。任何总结性输出都必须是“观点中立”的AI可以说“有8位参与者提到了成本问题其中5位认为成本可控”但绝不能说“因此成本方案是更优选择”。系统中甚至专门设置了一个差异化的总结模板我们在后文会详细拆解。2.3 与其他常见AI产品的对比对比维度传统AI助手社区问答平台本讨论系统AI的角色答案提供者内容分类器排序、精华讨论维系者整理、观察观点处理收敛为单一结论排序/采纳/折叠平行呈现、保留张力核心输出结论排行榜/最佳答案议题地图、分歧图谱用户感知“AI告诉我答案”“大家选出了答案”“AI帮我们看见彼此”系统风险偏见放大、过早收敛沉默螺旋、从众效应失焦、事实核查负担这个对比也解释了为什么“不能靠提示词解决”。很多人会说那你为什么不直接给大模型加一条“请勿评价”的system prompt我试过效果很差。原因有二一是大模型的“评价冲动”根深蒂固一条指令管不了长对话二是即使AI不主动打分用户也会追问“你觉得呢”于是评价又从后门溜回来了。所以必须从产品机制上做约束而不是靠对话技巧。3. 核心机制拆解这套系统具体是怎么运转的3.1 观点容器讨论的最小单元整个系统的数据基础不是“聊天记录”而是一套结构化观点节点。每条发言被拆解为四种类型观点表达立场或主张。“我们应该用开源方案。”依据为观点提供支撑。“数据表明开源方案三年总成本低40%。”反例提供反驳或边界条件。“但开源方案在合规审计上会花更多时间。”追问提出需要进一步澄清的问题。“成本数据包含迁移期的人力损耗吗”为什么要做这种拆分因为在真实讨论中人们经常把“观点”“依据”“质疑”混在一起说导致讨论看似在交锋实则各说各话。AI的第一层工作就是做语义分类把混在一起的成分拆开。这层不涉及任何价值判断纯粹是结构整理。我们在prompt里明确要求“你正在整理一场讨论你的职责是帮助参与者看清问题结构不输出任何倾向性意见。”这里有一个实操经验AI的分类准确率大概在85%左右剩下15%需要人来确认。我们在界面上做了“标签修正”入口允许参与者把自己发言的类型从“依据”改成“质疑”。这是很重要的信任建设——如果用户发现系统误解了他的意图必须随时能改回来。3.2 不排序的呈现引擎呈现层是整个系统最容易“破功”的地方因为哪怕你后端没有排序逻辑前端一个“最多认可”按钮就能把价值排序偷渡回来。所以我们做了几条硬约束默认视图是“时间线视图”按发言时间升序排列不做任何加权“相关视图”允许用户选择一条观点系统检索出语义相近的观点按相似度降序展示——但这个排序是相关性不是价值我们会在界面标题上明确写“与这条观点相关的讨论”不提供“赞同数”“热度”“精华帖”等任何虚拟货币类信号如果讨论人数超过20人自动切换为“主题聚类视图”把讨论按主题分组展示组内依然是时间序。技术上主题聚类我们用了一次简单的embedding加聚类具体做法是把每条发言用SentenceTransformer编码成向量然后用HDBSCAN做密度聚类。这里要注意聚类参数要调得保守一些宁可不聚类也不要错聚类因为分错组的代价远大于分粗的代价。我最初把min_cluster_size设得偏小结果一个话题被拆成了七八个碎片小组反而更乱。后来调大了参数让每组至少有5条以上发言才形成独立主题效果明显更好。3.3 不打分的分析层这是系统最核心的一块也是设计难度最高的。AI虽然不给观点打分但它要做大量**“看似在评价、实则是在描述”**的工作。我们把它拆成三个子功能立场识别判断一条发言总体上支持、反对还是中立。这不是给发言“定性”而是帮大家看清“谁站在哪一边”。有一个细节立场识别不能只发生在单条发言层面最好做“立场演化”——追踪某个人在不同时间点的立场变化。这在很多讨论里是隐藏信息与会者表面上各执一词实际中途有人已经松动只是碍于面子没明说。AI把这些变化中性展示出来往往比打分更能推动讨论。偏见暴露不做裁判不代表不指出问题。系统会给每条“依据”做可核查性标注区分“有数据支撑”“有引用来源”“仅为经验之说”。这个功能很有效它不是对发言者的否定而是把讨论中的证据链透明化。大家可以看到哪些争论是建立在扎实证据之上的哪些其实只是印象流。这比AI直接说“你错了”要温和得多也更促进理性讨论。情绪极性检测技术上我们确实做了VADER情绪分析但检测结果只展示给讨论主持人不会出现在公共讨论区。原因很简单把“你的发言情绪偏负面”扔到屏幕上几乎必然引发反感这本质上是某种变相的打分惩罚。但主持人需要了解讨论气氛比如当负面情绪浓度快速上升时可能需要介入喊停。3.4 不判谁赢的结论机制讨论总要有一个产出。我们设计了一个非常独特的“双区结论结构”系统在每次讨论停滞时让AI生成两种完全不同的总结分别放在共识区和分歧区。先说共识区。AI提取所有参与者真正达成一致的部分——“所有参与者都同意成本是重要指标”“没有人反对需要在一季度内完成评估”。这里有一个严格约束共识区只能放无人反对的内容AI不能因为“大多数人同意”就写入共识。意见领袖的影响力在这里被有效抑制了。再说分歧区。AI把讨论中最关键的争议维度列出来每一条都带有相互对立的双方观点。例如“关于部署方式一方认为云部署便于运维另一方认为私有化部署满足数据合规要求。”AI在生成分歧描述时必须做到两边措辞的“力量对称”——不能让甲方读起来显得有理有据乙方读起来像无理取闹。最有意思的是第三个区域——盲区。AI会列出讨论中曾经提起但缺乏证据或还没有被充分展开的话题。这个设计是为了对抗“幸存者偏差”一群人很容易在自己熟悉的领域里打转盲区列表会温和地提醒大家“我们是不是漏了什么”。很多用户反馈盲区是整个系统里对他们启发最大的输出因为它提供了一个独立于讨论者认知边界的第三视角。4. 实操过程与核心环节实现4.1 从需求到原型的迭代记录这个系统的第一版是个非常失败的产品。我们当时的做法是直接拿一个开源聊天室改让AI在后台监听所有对话遇到“你觉得哪个好”这类问题时偷偷把答案分发给用户。结果上线一周就翻车了——AI的分发机制被用户摸清后聪明的人开始给AI塞“预览版”“内部资料”来影响判断劣币驱逐良币大家不再认真讨论转而讨论“怎么骗AI”。第二版我们做了一个关键转变从后台干预走向前台机制。不再试图让AI“聪明地”判断谁对谁错而是把讨论的透明度做到极致。所有AI的分析结果对所有人可见所有标签都是可修正的所有总结都按共识/分歧/盲区三区输出。这个版本上线后讨论质量才真正稳定下来。这个迭代过程给我的核心教训是讨论类AI产品不怕“笨”怕的是“暗箱”。AI只要还有一丁点不透明的裁决权用户就会把精力从讨论本身转移到影响AI上。透明化看似牺牲了效率实际上挽救了信任。4.2 数据模型与后端查询逻辑具体实现时我们用的是一张很简单的核心表。这里给出简化的schemaCREATE TABLE nodes ( id BIGINT PRIMARY KEY AUTO_INCREMENT, discussion_id BIGINT NOT NULL, parent_id BIGINT NULL, node_type VARCHAR(20) NOT NULL, -- opinion, evidence, counter, question author_id BIGINT NOT NULL, content TEXT NOT NULL, stance VARCHAR(10) NULL, -- support, oppose, neutral sentiment_score FLOAT NULL, -- 仅内部使用不下发展示 embedding VECTOR(768) NULL, -- 仅用于相关视图查询 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE INDEX idx_nodes_discussion ON nodes(discussion_id, created_at); CREATE INDEX idx_nodes_parent ON nodes(parent_id);这里有几个设计上的考虑。第一默认的列表查询永远按created_at升序绝不允许JOIN一个“赞数表”之后再按赞数排序。当时有同事提出“要不搞个内部热度分至少帮用户找到好内容”被我连着否了三次——任何内部热度分最后都会变成外部可见的排名。第二如果用户问“讨论里哪个观点支持率最高”我们的系统拒绝直接回答数字排名而是生成一张“立场分布图”展示每个子议题上支持和反对的人数比例并且把每个立场列的代表性发言都并列展示。它回答的是“大家怎么看”而不是“谁是对的”。第三关于聚类和相关视图的查询我们用了向量检索库。要注意的是不要把聚类结果当排序来用——聚类只是分组组内顺序依然是时间来定。很多人在实现时下意识会在组内按“代表性强弱”排序这个冲动必须掐死。4.3 前端交互与视觉设计要点交互设计对这套系统的成败影响被严重低估。我们做了几个很特别的决定视觉上没有排行榜。整个页面不出现“最”“第一”“领先”等字样甚至数字角标都尽量减少。讨论列表就是一条条干净的卡片卡片上显示发言人、时间、发言类型标签。没有点赞按钮取而代之的是“我同意/我不同意”的立场按钮而这个按钮的功能是让AI知道立场分布而不是给发言热度刷数据。界面顶部有一个“议题健康度”的可视化组件但它不是分数而是一个维度雷达图参与度、观点多样性、证据丰富度、情绪平稳性、话题集中度。注意雷达图不是给这场讨论打总分而是让参与者一眼看到“我们现在的讨论在哪个维度存在风险”。比如话题集中度很高、观点多样性很低说明大家可能在“回声室”里打转。这个设计的妙处在于它把AI的观察变成了一面镜子而不是一把尺子。关于“讨论存档”我们做了一个“讨论回放”功能。当讨论结束后系统生成一份简报时间线完整保留。简报的目录不是“最佳发言”而是那张共识/分歧/盲区三区图。评论区里很多人说这个简报很像“会议纪要的民主版”我觉得这个评价挺准。5. 避坑指南常见问题与排查实录5.1 场景一用户直接问“那到底哪个方案好”这是最常遇到的灵魂拷问。我们的标准回复原则是AI不回答“哪个好”只回答“大家的分歧在哪”。系统会生成这样的回答“关于方案A和方案B的选择讨论中出现了三个关键分歧。第一成本测算口径甲组使用的是包含迁移人力的全成本乙组只计算了license费用。第二合规时间窗口甲组认为6个月可完成认证乙组认为至少9个月。第三团队学习成本有经验数据的发言提到内部团队平均需要3周熟悉新框架。目前未发现能让三方达成一致的新证据。**这个回答有意思的地方在于它把“谁对谁错”转化成了“哪里没对齐”。用户在阅读过程中会发现原来双方的分歧根源在于口径和时间假设不同而不是目标不同——这种发现比“AI选A”有意义得多。5.2 场景二AI模型自己忍不住打分我们用的底层大模型经常在总结中不自觉带上“整体而言方案B更符合多数人利益”这种话。排查后发现问题出在两个方面一是prompt措辞不够强硬二是模型自身的“总结欲”太强。我们的解决方案是双保险。第一道是系统提示词我们放了一段很长的“不裁决声明”你是一个讨论结构的整理者不是决策者。你的任务是帮助参与者看清分歧与共识 不是帮他们做选择。严禁使用更好更优应当建议等措辞评价某个观点。 当你发现自己想要评价时改为描述部分参与者认为……另有部分参与者认为……第二道是输出后审查。我们用一个小分类模型专门检测AI生成的总结里是否包含“评价性措辞”一旦检出自动打回重新生成。这个审查模型的训练数据是从第一季度的AI输出中人工标注的。5.3 场景三冷启动时讨论不起来不排序、不打分的系统在内容从零开始时有一个天然的劣势——大家看不到“热门”也就不知道说什么。去掉排名机制后最初的讨论容易冷场。我们的对策是做“议题预设结构”。在讨论开始前系统先根据讨论主题生成一个“议题框架”把可能涉及的角度列出来。比如主题是“要不要远程办公”框架会列出效率、沟通、协作工具、企业文化、招聘范围、数据安全等维度。参与者不需要自己扯开话题直接选择维度发表观点即可。实践下来有框架和无框架的讨论有效发言数量差了3倍以上。5.4 场景四讨论逐渐失焦没有裁判意味着没人“叫停”讨论容易越跑越远。我们的侦测方案是话题漂移检测系统每隔一段时间计算新发言与当前主话题的相关度当连续几条发言都偏离主话题时AI会插入一条温和的“设问”“我们现在似乎聊到了员工福利这和远程办公的沟通问题有什么关系吗”AI不做裁判但可以做导航仪——它提醒你偏离了航线但不会判断你偏离得对错。5.5 常遇问题速查表症状原因排查与修复AI总结出现“建议方案A”提示词约束失效检查是否是长对话导致提示词被稀释增加输出后审查模型用户发言中频繁出现“AI觉得”用户对系统角色认知错误在产品介绍中明确“本系统不提供AI推荐”主持人引导说明相关视图出现语义错误分组聚类参数过小调大min_cluster_size降低聚类敏感度讨论区氛围激烈、人身攻击增加情绪极性检测触发但无人介入设置阈值当连续3条发言为高负面情绪时通知主持人用户反馈“没排名我不会玩了”用户习惯了排行榜式交流这是预期管理问题需要在引导文档中解释平行讨论的价值共识区出现“大多数人同意”条目AI的少数保护机制未生效严格限定共识区写入条件必须是“无反对”不能是“多数同意”5.6 关于历史消息与长对话的四点排查经验当讨论持续数天、发言超过几百条之后系统会出现一些新的问题这里单独补几条排查经验。第一注意向量检索的索引过期问题。新增发言后如果没有及时更新embedding索引相关视图会出现“搜不到刚说的内容”的现象。我们后来设置了一个定时任务每5分钟重新索引新发言。第二立场识别在长对话中会漂移。参与者的观点可能在讨论中逐步转变单条识别模型常常忽略这种“旧发言与新立场不一致”的情况需要在立场演化模块中做时间窗口比较。第三上下文窗口溢出几乎必然发生。我们的方案是把讨论切片按主题分组后分别总结再逐层汇总而不是一次性把所有发言塞给大模型。第四中文与英文混合讨论时情绪识别准确率会明显下降。这种情况不要依赖VADER这类英文工具改用多语言分类模型并且把结果标注为“参考”而非“确定”。6. 一些真实体会这个系统上线后的一个小插曲让我印象很深。一个用户在我们的feedback群说“以前我用AI讨论工具总觉得AI像个老师时不时给我打分导致我不敢说太尖锐的话。在这个系统里我第一次觉得AI是我的同事它不知道答案但它帮我把桌子擦得很干净。”我觉得“擦桌子”这个比喻比我们所有的产品文档都准确。讨论系统里的AI最好的角色不是桌子上的裁判而是那个默默把桌面整理好、让大家都有位置坐下来说话的人。最后分享一个技术之外的观察不排序不是反效率而是反偏颇。排行榜和打分天然带来信息茧房因为高的越显眼、低的越沉默。我们把价值排序去掉之后系统里的观点多样性指标提升了将近40%。这让我确信很多时候我们以为需要AI替我们分辨好坏实际上我们更需要的是一个不弃置任何声音的容器。如果这篇文章能让你在下次设计AI功能前多问一句“这里真的需要打分吗”那它就达到了目的。

相关新闻

Linux 6.6内核内存管理深度解析(三):页表与缺页处理 — 虚拟地址怎么按需映射到物理页

Linux 6.6内核内存管理深度解析(三):页表与缺页处理 — 虚拟地址怎么按需映射到物理页

〇、全景:页表 缺页 按需分配 进程看到的是一整片连续的虚拟地址空间,但实际内存是"按需分配"的——大部分地址只是"承诺"了,访问到的那一瞬才真正映射物理页。实现这个机制靠两样东西: 多级页表&#xff1…

2026/10/15 19:33:28 阅读更多 →
fastjson 1.2.84 能在 JDK 7 上跑吗?实测:编译能过,一启动就 UnsupportedClassVersionError

fastjson 1.2.84 能在 JDK 7 上跑吗?实测:编译能过,一启动就 UnsupportedClassVersionError

最近后台看到有人搜「fastjson1.2.84能在jdk1.7环境运行吗」。我拿一台 JDK 7 实际跑了一遍。 先说结论 JDK 8 及以上:没影响。 同一段代码在 JDK 8 上跑 1.2.83 和 1.2.84 都正常。JDK 7:1.2.84 起不来。 javac 只给 5 条警告、退出码是 0,所以构建不会失败;程序一运行就抛 …

2026/10/15 19:33:28 阅读更多 →
品牌被跟卖?eCommerce-Skills如何用AI技能抵御劫持、假货与违规定价

品牌被跟卖?eCommerce-Skills如何用AI技能抵御劫持、假货与违规定价

【免费下载链接】eCommerce-Skills E-commerce skills for AI agents — product research, marketing automation, supply chain optimization, and business analytics for online sellers across Amazon, Shopify, Etsy, TikTok Shop, and all platforms. 项目地址&#xff…

2026/10/15 19:33:28 阅读更多 →

最新新闻

SQL LIMIT 分页查询完全指南:语法、陷阱与性能优化

SQL LIMIT 分页查询完全指南:语法、陷阱与性能优化

1. 先把语法记牢:LIMIT 的两种写法和常见数据库差异LIMIT 看起来就是“截断结果集”这么简单,但实际用起来,不同数据库、不同写法、不同参数语义之间还是有很大差别的。我在帮业务方排查一个后台报表接口时,看到同事写了这么一句&…

2026/10/16 4:10:15 阅读更多 →
矩阵快速幂模板详解:从单位矩阵到__int128防溢出实战

矩阵快速幂模板详解:从单位矩阵到__int128防溢出实战

1. 从“矩阵快速幂不会”到“力扣模板直接秒”先说一下我为什么要写这题。去年某次集训,队友随机抽了一道信奥题让我讲,抽到的就是 P3390 模板。当时我第一反应是“这题不是背模板就行了吗”,结果真让我手写的时候,居然卡在了单位…

2026/10/16 4:10:15 阅读更多 →
PostgreSQL pg_hba.conf 配置实战:认证方式、IP限制与安全策略详解

PostgreSQL pg_hba.conf 配置实战:认证方式、IP限制与安全策略详解

数据库搞到一半连不上,连上来了密码报错,密码对了又被地址拒掉,好不容易调完规则发现又不生效——如果你也对pg_hba.conf有过这样的经历,那这篇内容就是为你准备的。作为 PostgreSQL 访问控制的第一道闸门,pg_hba.conf…

2026/10/16 4:10:15 阅读更多 →
Spring整合Kafka实战指南:核心原理、配置要点与常见坑全解析

Spring整合Kafka实战指南:核心原理、配置要点与常见坑全解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/16 4:10:15 阅读更多 →
轻量级Python OCR验证码识别模型:ResNet18+CTC端到端方案

轻量级Python OCR验证码识别模型:ResNet18+CTC端到端方案

简介:本资源是一套面向Python开发者与信息安全从业者的高精度验证码OCR识别解决方案,聚焦网站自动化登录、爬虫反反爬绕过等实际场景,适合具备基础图像处理与机器学习知识的中高级开发者学习与二次开发。压缩包共76个文件,含47个核…

2026/10/16 4:10:15 阅读更多 →
STM32F407单相PWM整流器实现单位功率因数与能量回馈

STM32F407单相PWM整流器实现单位功率因数与能量回馈

简介:本资源是针对2022年全国大学生电子设计竞赛A题「单相交流电子负载」的完整嵌入式实现方案,面向STM32初学者、电赛备赛学生及电力电子方向实践者,重点解决单相系统下高精度锁相与PWM整流控制这一核心难点。工程基于STM32F407VET6主控&…

2026/10/16 4:09:14 阅读更多 →

日新闻

个人 AI Agent 平台接入 TaoToken:统一 Key 与 API 通道的配置大纲

个人 AI Agent 平台接入 TaoToken:统一 Key 与 API 通道的配置大纲

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/16 0:00:05 阅读更多 →
信号与系统频域分析作业解题指南

信号与系统频域分析作业解题指南

1. 作业背景与核心要求解析信号与系统作为电子信息类专业的核心基础课,其作业设计往往直接关联课程的核心知识框架。2026年春季第六次作业的布置,通常对应着课程进展到频域分析的关键阶段。根据常规教学进度推测,本次作业可能涉及以下核心内容…

2026/10/16 0:00:05 阅读更多 →
Django MVT实战:从零构建图书借阅系统,彻底搞懂Model-View-Template分层

Django MVT实战:从零构建图书借阅系统,彻底搞懂Model-View-Template分层

1. 从一个"四不像"的练手项目说起如果你已经看完了Django的官方教程前几章,跟着敲完了投票应用,大概会有一种"我好像会了,又好像什么都不会"的割裂感。教程里每个知识点都是拆开的——这一章讲模型,下一章讲视…

2026/10/16 0:00:05 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/15 16:18:54 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/15 19:41:51 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/15 13:48:15 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 0:14:36 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/16 3:49:43 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 9:49:14 阅读更多 →