包含关键字 typecho 的文章

作者:Prabakaran Thirumalai,MySQL 服务器运行时咨询成员技术人员。

原文:https://blogs.oracle.com/mysql/no-more-hidden-changes-how-mys...,Jan 30, 2026

爱可生开源社区翻译,本文约 2700 字,预计阅读需要 9 分钟。

640 (87).webp

MySQL 通过重新思考外键约束和级联的管理方式,迈出了重要一步。MySQL 9.6 开始,外键检查和级联操作将由 SQL 引擎 直接处理,而非 InnoDB 存储引擎。这一改进解决了长期存在的变更跟踪、二进制日志复制和数据一致性方面的挑战,使 MySQL 在异构环境、变更数据捕获(CDC)管道和分析工作负载方面更加稳健。

1. InnoDB 中外键的先前工作方式

历史上,MySQL 在存储引擎层(特别是 InnoDB 数据库)强制执行外键约束和级联。其工作原理如下:

  • 外键级联:当对父表执行 DELETE 或 UPDATE 等语句时,InnoDB 会检查外键约束。如果定义了级联操作(例如 ON DELETE CASCADE ),InnoDB 会处理子表中相应行的更新或删除操作。
  • InnoDB 内部执行:所有级联操作均由 InnoDB 内部执行。SQL 引擎仅发起父级操作;所有对子表的依赖操作均由 InnoDB 管理。

    重要的是,这些子行更改对 SQL 层是不可见的。因此,在基于行的复制 (RBR) 模式下,InnoDB 内部执行的级联操作不会出现在 MySQL 二进制日志中。

  • 运行影响:由于这些变更对 SQL 引擎和二进制日志隐藏,下游系统(例如 CDC 管道和分析平台)可能无法检测到这些变更。这可能导致数据不一致、分析结果不可靠以及复制问题。

基于 InnoDB 的外键的局限性

随着 MySQL 部署规模和复杂性的增长,这种传统方法暴露出以下局限性:

  • 隐藏的数据更改:在 InnoDB 内部执行的级联父子更改对 SQL 层是不可见的,并且没有在更高级别上被捕获。
  • 系统日志不完整:二进制日志中经常缺少子行更改,导致复制和审计不完整。
  • 数据捕获差距:依赖二进制日志或完整变更历史记录的数据工具和下游系统无法始终跟踪与外键相关的每个更新或删除。
  • 复制风险: 在复杂的复制设置中,这些静默的更改可能会导致主服务器和副本之间的数据出现差异,从而导致操作上的挑战。

2. 新模型:SQL 引擎管理的外键强制执行

为了解决这些问题,MySQL 现在强制执行外键,并在 SQL 引擎内部管理级联操作。通过这项更改,父表和子表上的所有外键操作对 SQL 层都是完全可见的。

640 (88).webp

主要优势:

  • 完整日志记录:所有更改(包括级联更改)现在都可见、可审计,并完整记录在二进制日志中。
  • 可靠的复制:不再有隐藏的数据更改;复制现在更加值得信赖和准确。
  • 更佳的分析:数据采集和分析工具现在可以获得所有数据变化的完整、实时视图。
  • 创新基础:这种架构使得跨存储引擎扩展外键支持以及未来的复制和可观测性功能变得更加容易。

注意:对于除 InnoDB 之外的其他支持外键的存储引擎,强制执行和级联操作仍由相应的存储引擎管理。

性能比较

我们理解,对于考虑将外键强制执行机制从 InnoDB 迁移到 SQL 引擎的 MySQL 用户而言,性能是首要考虑因素。针对常见事务工作负载的大量基准测试证实,基于 SQL 引擎的外键强制执行和级联机制的性能与 InnoDB 方法 几乎完全相同。外键检查和级联的成本基本保持不变,因此 吞吐量和延迟方面没有出现任何可观察到的下降。 这使得即使在高吞吐量和关键任务部署中,采用新的实现方案也是安全的。

向后兼容性

SQL 引擎的外键强制执行和级联机制旨在 完全向后兼容,保留 InnoDB 外键强制执行的语义和行为。虽然整体用户体验保持不变,但仍有一些值得注意的改进和细微的行为差异:

  • 错误信息:虽然错误代码与以前的版本一致,但由于检查执行顺序不同,具体的错误信息文本(包括外键名称)可能会有所不同。
  • 自增间隙:如果外键约束失败,任何尝试插入操作都会增加自增计数器,这可能会导致值出现间隙,符合 MySQL 的标准行为。
  • 针对级联行更新统计信息:行级统计信息(例如 delete_rows )已更新,以包含受级联外键操作影响的行。这确保系统统计信息能够准确反映外键强制执行所执行的所有数据更改。
  • 更严格的排序规则验证:如果外键级联跨越不兼容的排序规则,则会引发显式错误,防止出现 静默数据问题,并提高用户的数据完整性。

3. 安全采用并内置备用方案

为了实现可控的升级,MySQL 引入了一个只读的启动变量 innodb_native_foreign_keys。这提供了平滑的升级路径,并最大限度地减少了版本过渡期间的意外变更。默认情况下,此变量设置为 FALSE ,这意味着默认行为是基于 SQL 引擎的外键强制执行 。在测试环境或早期生产部署期间,您可以将此变量设置为 TRUE ,以暂时恢复到 InnoDB 的原生外键处理方式。这在验证新的 SQL 引擎行为时提供了一个清晰的操作回退方案。

注意: 此系统变量旨在帮助简化迁移,随着 MySQL 社区全面采用基于 SQL 引擎的外键,该变量将在未来的版本中移除。

4. 总结:为什么这项改变至关重要?

通过将外键强制执行移至 SQL 引擎,MySQL 弥补了长期存在的架构缺陷。这一改进确保数据变更始终可见、被记录和被复制,使 MySQL 成为更强大的平台,适用于现代化的分布式合规数据环境。

总的来说,对于 MySQL 用户而言,这意味着更好的数据一致性、更可靠的复制,以及在分析和合规工作流程中更少的意外情况,而不会牺牲性能。

群晖发布 DSM 更新修复 Telnetd 安全漏洞 即便未启用也可能影响安全性 https://ourl.co/111713?t
2026 年 2 月 3 日 09:25

目前没有任何证据表明该漏洞已经被利用

但实际情况是
cve: https://www.txone.com/blog/cve-2026-24061-gnu-inetutils-telnet-exploitation/

当天扫了一点进行测试 大部分设备都是群晖
完整的 root shell 访问权限
里面也是被 d 狗执行了 botnet

口说无凭 这是扫了挂针的:
28635.jpg
28635.jpg

只能说 都是公关大师 虽然是进行了强制升级 时间未免过得太长了。而且也是不承认被利用了漏洞。感觉和飞牛的处理方式没有太大差异

在视觉语言模型(VLMs)的发展进程中,文档 OCR 始终面临着布局解析复杂、语义逻辑对齐等核心挑战。传统模型大多采用固定的 「左上到右下」 栅格扫描顺序处理视觉 token ,这种刚性流程与人类视觉系统遵循的语义驱动型扫描模式相悖,尤其在处理含复杂公式、表格的文档时,容易因忽视语义关联导致解析误差。如何让模型像人类一样 「读懂」 视觉逻辑,成为提升文档理解能力的关键突破口。

近期,DeepSeek-AI 推出的 DeepSeek-OCR 2 给出了最新答案。其核心是采用全新 DeepEncoder V2 架构:模型摒弃传统 CLIP 视觉编码器,引入 LLM 风格的视觉编码范式,通过双向注意力与因果注意力的融合,实现视觉 token 的语义驱动式重排,为 2D 图像理解构建出一条「双阶段 1D 因果推理」的新路径。


DeepEncoder V2 的关键创新体现在四个方面:

  • 以 Qwen2-0.5B 紧凑型 LLM 替代 CLIP,在约 5 亿参数规模下赋予视觉编码因果推理能力;
  • 引入与视觉 token 数量等长的「因果流查询(Causal Flow Query)」,通过定制注意力掩码,使视觉 token 保持全局感知,同时允许查询 token 基于语义重组视觉顺序;
  • 支持 256–1,120 个视觉 token 的多裁剪策略,在兼顾效率的同时对齐主流大模型的 token 预算;
  • 通过「视觉 token  + 因果查询」的串联结构,将语义重排与自回归生成解耦,天然适配 LLM 的单向注意力机制。

这一设计有效消除了传统模型的空间顺序偏见,使模型能够像人类阅读一样,依据语义关系动态组织文本、公式与表格,而非传统机械遵循像素位置。

经验证,在 OmniDocBench v1.5 基准测试中,DeepSeek-OCR 2 以 1,120 的视觉 token 上限,实现了 91.09% 的整体准确率,较前代模型提升 3.73%,同时将阅读顺序编辑距离(ED)从 0.085 降至 0.057,证明其视觉逻辑理解能力显著增强。细分任务中,公式解析准确率提升 6.17%,表格理解性能提升 2.5%-3.05%,文本编辑距离减少 0.025,各项核心指标均实现跨越式进步。

同时,其工程实用性同样突出:在保持 16 倍视觉 token 压缩率的前提下,在线服务的重复率从 6.25% 降至 4.17%,PDF 批量处理重复率从 3.69% 降至 2.88%,兼顾了学术创新与产业应用需求。相较同类模型,DeepSeek-OCR 2 以更低的视觉 token 成本,达到了接近甚至超越大参数模型的效果,为资源受限场景下的高精度文档 OCR 提供了更具性价比的方案。

目前,「DeepSeek-OCR 2:视觉因果流」已上线至 HyperAI超神经官网的「教程」板块,点击下方链接即可体验一键部署教程 ⬇️

教程链接:https://go.hyper.ai/2ma8d

查看相关论文:https://go.hyper.ai/hE1wW

效果展示:


Demo 运行

1.进入 hyper.ai 首页后,选择「教程」页面,或点击「查看更多教程」,选择「DeepSeek-OCR 2 视觉因果流」,点击「在线运行此教程」。

2.页面跳转后,点击右上角「Clone」,将该教程克隆至自己的容器中。

注:页面右上角支持切换语言,目前提供中文及英文两种语言,本教程文章以英文为例进行步骤展示。

  1. 选择「NVIDIA GeForce RTX 5090」以及「PyTorch」镜像,按照需求选择「Pay As You Go(按量付费)」或「Daily Plan/Weekly Plan/Monthly Plan(包日/周/月)」,点击「Continue job execution(继续执行)」。

HyperAI 为新用户准备了注册福利,仅需 $1,即可获得 20 小时 RTX 5090** **算力** **(原价 $7), 资源永久有效。

4.等待分配资源,当状态变为「Running(运行中)」后,点击「Open Workspace」进入 Jupyter Workspace。


效果演示

页面跳转后,点击左侧 README 页面,进入后点击上方 Run(运行)。

待运行完成,即可点击右侧 API 地址跳转至 demo 页面。

以上就是 HyperAI超神经本期推荐的教程,欢迎大家前来体验!

教程链接:https://go.hyper.ai/2ma8d

Chainguard最新的《可信开源现状报告》详细描述了当前行业对于容器镜像中的漏洞以及开源依赖的长尾问题的看法。该报告基于 2025 年 9 月至 11 月期间观察到的 1800 多个容器映像项目和 10100 个漏洞实例,提供了生产环境的数据驱动视图。

 

Chainguard 利用来自 29 万个镜像和近 5 亿次构建的遥测数据,检查客户实际如何消费和维护开源组件。它发现,基础语言和基础设施镜像,如 Python、Node、nginx、Go 和 Redis,在生产使用中占主导地位,形成了它所描述的现代 AI 驱动软件生态系统的基础栈。Python 出现在大约 72%的客户环境中,Node 占 57%,nginx 占 40%。这些镜像与模型开发、数据处理和推理工作负载以及周围的可观测性和平台工具相关联。

 

然而,报告警告说,这些受欢迎的镜像的可见层只是真实景观的一小部分。前 20 个镜像占 Chainguard 编目镜像的约 1.37%,大约是所有容器拉取量的一半。另一半的生产使用来自 1436 个长尾镜像,占平均客户清单的 61%以上。Chainguard 强调,这些长尾镜像通常是绝对需要的现场服务和基础设施的核心组件,而不是短暂的实验。

 

漏洞的分布高度偏向这个长尾。Chainguard 报告说,在此期间,它修复的 CVE 实例中,只有 214 个出现在前 20 个镜像中,约占 2%。其余的 98%(10785 个 CVE 实例)在该集合之外的镜像中。这一发现表明,最严重的风险暴露在堆栈中最难应用补丁和治理的部分。对于每个在前 20 个镜像中修复的 CVE,公司表示它在不太受欢迎的镜像中解决了 50 个 CVE,这是它用来说明处理安全长尾重要性的比率。虽然这些问题大多数是中等严重性,但报告认为组织最关心的是它们如何快速解决跨其镜像范围的关键和高严重性问题。

 

在这方面,Chainguard 强调了他们修复安全问题的速度。该公司表示,在三个月的时间窗口内,它实现了对关键 CVE 的平均修复时间低于 20 小时,63.5%在 24 小时内解决,97.6%在两天内解决,所有问题都在三天内解决。Chainguard 在两天多的时间内修复了高严重性漏洞,在两天半的时间内修复了中等严重性漏洞,在三天多的时间内修复了低严重性问题。这些时间明显快于 Chainguard 声明的服务水平目标,即关键 CVE 为七天,其他为十四天,并且适用于流行和长尾镜像。

 

在我们的数据中,有一点很突出:现代软件由广泛、不断变化的开源组件组合驱动,其中大多数都不在前 20 名最受欢迎的镜像中。这不是开发者花费时间的地方,但却是大量安全性和合规性风险积累的地方。

 

该报告还指出,合规性是容器安全变化的主要驱动因素。它指出,44%的客户在生产中至少运行一个 FIPS 兼容镜像,通常是为了满足 FedRAMP、DoD IL 5、PCI DSS、SOC 2、欧盟网络弹性法案、澳大利亚的 Essential Eight 和 HIPAA 等框架的要求。最广泛使用的 FIPS 镜像与非 FIPS 组合镜像相镜像,包括 Python、Node、nginx、Go、Redis、Istio 组件和 cert-manager。Chainguard 建议,这种模式显示了监管压力如何鼓励使用与现有工作负载紧密对齐的硬化、经过密码学验证的开源组件。

 

风险集中在最熟悉的项目之外的想法并不是 Chainguard 工作所独有的。NetRise在 2024 年的一项研究发现,常用的 Docker Hub 容器平均包含 604 个已知漏洞,其中超过 45%的漏洞超过两年未修复。同一研究表明,这些容器中的一小部分关键和高严重性漏洞已经被利用,并与活跃的勒索软件活动有关。NetRise 的研究还表明,即使这些镜像不是最广泛使用的,长期未修补的组件在镜像中也构成了持续的风险。

 

学术研究使用不同的方法得出了类似的结论。发表在GigaScience上对科学容器镜像的分析报告称,每个镜像平均有 460 个漏洞。这项分析的作者指出,许多镜像包括完整的操作系统发行版和很少更新的其他不必要的软件包,从而创造了更大的攻击面。他们还表明,仔细减少镜像大小和内容,并定期重建它们,可以显著减少漏洞数量。这反映了当前行业的最佳实践,即使用最小的基础镜像,并经常重建容器镜像。

 

Sonatype 的《软件供应链现状报告》通过跟踪在已经存在修补版本的情况下易受攻击的组件被使用的频率,增加了另一层内容。2024 年的版本突出了恶意开源软件包的增加,并报告称,在 95%使用了易受攻击组件的情况下,已有修复版本可用。Sonatype 还强调,大量依赖关系长时间未打补丁,特别是对于低严重性问题。这种可用修复和缓慢采纳的组合支持了 Chainguard 的观点,即管理性补救和长尾覆盖可以填补开源维护现实留下的空白。

 

业界的回应,如CheckmarxFaith Forge,强调了一些标准模式。安全供应商将镜像扫描描述为持续集成和部署流程的标准部分,组织越来越多地将这些扫描与政策即代码规则联系起来,这些规则可以阻止带有未打补丁的关键 CVE、缺失签名或缺失软件物料清单的镜像。在对软件物料清单(SBOM)格局的分析中,欧洲网络安全局(ENISA)也强调了机构和监管机构的指导。它强调了签名工件、可验证的构建来源和将 SBOM 内容与漏洞情报匹配的能力的重要性。这些趋势都响应了 Chainguard 强调的同一结构性问题:需要管理的不仅仅是最受欢迎的镜像中的漏洞,而是当代软件系统中使用的所有容器化组件中的漏洞。

 

原文链接:

https://www.infoq.com/news/2026/01/chainguard-opensource-vulns/

交通运输公司优步(Uber)在其博客上发布了一篇关于其新可观测性平台的文章,强调对他们来说,网络可见性现在是一种战略能力,而不仅仅是一系列离散的监控工具。

 

在这篇文章中,优步描述了它是如何用一个围绕开源技术和 API 构建的模块化云原生可观测性平台取代了单一的本地监控堆栈的。作者解释说,旧系统依赖于重量级组件和手动配置,无法跟上办公室、数据中心和云环境的快速变化。他们表示,他们现在已经构建了一个灵活的数据摄取管道、一个中央警报摄取应用程序和一个动态配置服务,这些服务将共同路由遥测数据、规范化警报,并保持收集器配置与实时网络库存一致。

 

文章解释说,自动化是优步实现可观测性新方法的一个重要部分。在博客中,该团队解释了其动态配置应用程序如何自动跨区域重新分配轮询工作负载,并通过 API 而不是工程师手动更改来全球部署配置更改。他们将监控系统构建为一个可编程界面,工程师可以通过添加元数据和策略来影响它。这一立场反映了最近在云基础设施可观测性方面的其他工作,其中工程师描述了平台,这些平台在近乎实时的情况下摄取和关联指标、事件、日志和跟踪,并通过中央策略管理警报。与此相一致的是,优步的帖子将自动化呈现为在企业规模上管理可观测性的唯一可行方式,而不仅仅是一个附加组件。作者详细介绍了 CorpNet 可观测性平台如何监控路由器、交换机、配电单元和其他支持其协作和企业应用程序的基础设施设备。

 

优步还在供应商独立性和成本控制方面做出了重大努力。在帖子中,工程师解释说,转向云原生开源优先堆栈削减了“数十万美元”的循环许可费用,并减少了对商业软件的依赖。公司描述了如何将开源组件与其自己的警报摄取和配置系统集成,以构建一个完整的平台。这种方法反映了最近可观测性调查的发现,例如 Logz.io 的一项报告,该报告称许多组织大量使用像 Prometheus 和 Grafana 这样的开源工具,作为控制商业平台成本的努力的一部分。这与供应商的叙述形成对比,后者推广集成的现成可观测性平台,这些平台抽象了实现细节。文章还清楚地暗示,优步愿意投资工程努力,以换取更低的循环支出和更大的灵活性。

 

优步还在供应商独立性和成本控制方面做出了重大努力。在这篇文章中,工程师们解释说,向云原生开源第一堆栈的转变减少了“数十万美元”的重复许可费,并减少了对商业软件的依赖。该公司描述了它如何将开源组件与自己的警报摄取和配置系统一起部署,以形成一个完整的平台。这种方法反映了最近可观测性调查的结果,比如Logz.io的调查。它报告说,许多组织大量使用像 Prometheus 和 Grafana 这样的开源工具,作为控制商业平台成本的一部分。这与供应商的叙述形成了鲜明对比,后者提倡集成现成的可观测性平台,抽象了实现细节。这篇文章还明确暗示,优步愿意投入工程努力,以换取更低的经常性支出和更大的灵活性。

 

优步的工程师还使用博客来设定关于 AI 角色的预期,他们现有的工作为未来的基于 AI 的自动化奠定了基础。他们认为,通过现在清理和标准化遥测数据,他们为未来“更智能、由 AI 驱动的网络操作”创造了条件。其他行业文章也呼应了这一观点。例如,网络提供商 Equinix 写道,生成式 AI 可以通过改进警报处理和加速根本原因分析,为网络可观测性增加“更进一步的智能”。关于 AI 驱动的数据中心网络的文章提出了类似的观点,并将可观测性数据呈现为异常检测和预测性维护的燃料。

 

在所有这些主题中,这篇博客文章将可观测性呈现为一种持续实践,而不是一次性的项目。优步选择了一个长跑的比喻,并在进展中写到了更换鞋子和调整配速策略。其他最近的报告和指南,如Splunk的这份,采用了类似的语言,并将可观测性描述为需要在工具、技能和流程上持续投资的“学科”。

 

“生成式 AI 正在为网络可观测性带来更进一步的智能,使用户能够监控他们的网络,管理警报,主动检测问题,并全面评估性能,”Equinix 的网络可观测性团队在其 2025 年关于 AI 和网络运营的分析中写道。优步的博客文章展示了一家大型技术公司如何通过首先重建其内部可观测性基础,然后邀请 AI 坐在顶部,为未来做好准备。

 

优步的博客文章最后声称,优步新的可观测性平台已准备好支持当前运营和未来的 AI 驱动能力。

 

原文链接:

https://www.infoq.com/news/2026/01/uber-network-observability/

本文是我在2024年旧金山QCon大会上演讲的总结。在过去的十年里,我作为一名应用科学家和机器学习工程师,在包括社交媒体、金融科技和生产力工具等多个领域工作。多年来,我看到许多项目取得了成功,但同样也有许多项目未能投入生产。这篇文章反思了成功或失败的原因,以及我们能从中学到什么。

 

在这篇文章中,我讨论了导致机器学习项目失败的常见陷阱,比如机器学习的固有不确定性、不一致的优化目标以及从业者之间的技能差距。首先,我概述了机器学习项目的生命周期以及它与普通软件项目的不同之处。然后,我深入探讨了五个常见陷阱(通过示例),并解释了我们如何减少遇到它们的机会。

 

机器学习项目的失败率

我在包括社交媒体平台、金融科技解决方案和生产力工具在内的各个领域都参与过机器学习项目。其中一些项目投入了生产,而许多项目没有。每一次努力都教会了我一些有趣的东西,并让我接触到了新技术,但当你全身心投入的一个项目没有产生你所希望的影响时,感觉并不好。我想知道:是我一个人吗?这个问题有多严重?

 

较早的研究报告称,机器学习项目的失败率高达 85%。最近的调查也得出了类似的结论。在2023年Rexer Analytics的一项研究中,超过三百名机器学习从业者中,只有 32%的人表示他们的项目投入了生产。不同行业的比率有所不同:大型科技公司有多年的 AI 应用历史,而传统企业和初创公司仍在寻找有效、无缝的 AI 应用之路。

 

并非所有的失败都是坏事。机器学习项目本质上是不确定和实验性的。通常,在探索数据并尝试一些基线模型之前,你无法知道机器学习是否会帮助你得出结论。如果根据这些初步研究,你决定快速改变方向或终止项目,那么应该被认为是一种成功,这是鼓励创新的经典快速失败原则。

 

在这篇文章中,我关注的是糟糕的失败:那些没有明确定义就拖延的项目,尽管离线性能良好但没有部署的模型,或者即使部署后也没有被采用的解决方案。

 

机器学习项目的生命周期

从高层次、简化的角度来看,一个典型的机器学习项目生命周期有六个步骤。它从确定一个使用机器学习优化的业务目标开始,这需要作为一个机器学习问题被构建。构建问题涉及探索和处理相关数据以训练各种模型。表现最佳的训练模型被部署和监控。我们从监控过程中得到的反馈将用于完善整个系统。

 

一个说明机器学习项目生命周期的简化高层图。(来源:作者)

 

这个迭代生命周期有两个要点:

  • 这是一个漫长、多步骤的过程,涉及多个团队之间的交接,由于涉及到固有复杂性,增加了失败的风险。

  • 机器学习项目是以数据为中心的优化问题。来自数据、模型和监控的反馈信号对于成功的结果同样重要。

 

陷阱 1:解决错误的问题

在我们想要讨论的五个常见陷阱中,其中最关键的一个是优化错误的问题。在 Rexer Analytics 的调查中,当机器学习从业者被问及在开始之前是否明确定义目标时,29%的人回答“大多数时候”,26%的人表示这种情况很少发生。这种清晰度的缺乏是机器学习工程师在承诺项目之前就经常面临的共同挑战。

 

在过去,对业务目标进行迭代并在开始项目时保持一定的模糊性是很常见的。然而,对于机器学习项目来说,这种迭代已经成为一个更严重的障碍。为了理解这个问题,我们需要探索业务目标是如何被转化为机器学习解决方案的。当然,我们不想错过第一步,那就是确定这个问题是否与机器学习相关。

 

一旦我们确定这是一个机器学习问题,我们需要将其构建为一个 ML 问题,这涉及到识别用于提取信号的具体数据(数据工程)以及训练多个模型/架构/超参数的设置。根据模型的复杂性,训练步骤可能经常需要更昂贵的基础设施(例如,GPU)。

 

归根结底,我们试图优化一个数学定义的目标函数。这个目标函数高度依赖于我们试图解决的业务目标类型。业务目标的后期变化需要对数据、目标函数和管道进行调整,这可能导致工作的损失。这就是为什么,为了从一个良好的机器学习问题开始,我们通常希望向业务团队提出许多问题。

 

以下是我想分享的一个例子,它展示了我们如何增加挑选获胜项目的机会。几年前,我曾是一个支持多个业务线的集中式 AI 金融科技团队的一员。每条业务线都将其项目标榜为“最重要的”,通常使用我们不熟悉的术语。我们的团队不得不在噪音中导航,优先考虑最有可能成功的投资。

 

在一年中,我能够参与各种不同类型的项目,涉及不同的业务线。最大的成功——对公司和我来说——是一个对个人和商业银行(P&CB)领域来说不言自明的预测模型。三个因素导致了这个项目的成功:

 

  • 直接收入相关性:P&CB 是一个主要的利润中心,因此有强烈的高层推动力。

  • 与现有系统的互惠性:我们的模型可以嵌入到一个长期运行的端到端系统中,具有监控/报告功能;我们只需要替换模型。

  • 机器学习可行性:现有的模型简单,具有现代架构和功能,因此我们有信心可以超越它。

 

仅仅因为其他人都在做机器学习项目,或者技术上可行,就启动一个机器学习项目是不够的。最好的机器学习项目达到了理想(利益相关者拉动)、有利可图(业务影响证明成本)和可行(技术上可解决)的最佳点。事先问一些尖锐的问题:目标是否明确定义?预计的利润是否合理?哪些假设是现实的?模型可能暴露哪些风险?

 

投资组合平衡也很重要。低风险/高影响项目是“唾手可得的果实”。如果你意识到风险并保持投资组合平衡,那么高影响/高风险项目是值得追求的。胜利证明了在 AI 基础设施和人才上的投资,而风险更大的赌注可能会改变游戏规则。

 

陷阱 2:数据陷阱

第二个陷阱是由数据带来的挑战。这是机器学习项目最常见的陷阱之一,也许是你的团队抱怨最多的一个。数据在哪里?我们能处理大量数据处理吗?尽管公司已经在解决这些问题上投入了很多,但这并不意味着没有其他隐藏的挑战最终会损害你的项目。在机器学习领域有一句名言:“垃圾进,垃圾出”。机器学习项目完全依赖于识别数据中的模式。如果数据是有缺陷的,那么你从这项研究中得到的结论很可能是不可信的。

 

多年来,机器学习社区建立了一个标准的数据管道结构,包括数据收集、处理和特征工程。还有一份人们通常为数据准备执行的常见任务清单:过滤重复项和异常值、填充缺失数据以及重新采样以处理数据不平衡。每个合适的机器学习团队都使用或适应这些标准程序,但它们的使用远远不够。

 

如果你对机器学习项目是如何失败的感兴趣,这个GitHub存储库包含了一长串多年来发现的失败的机器学习解决方案。这些失败大多数与数据有关。尽管大型科技公司或大学研究人员开发了所有解决方案,但他们也难免会出现涉及数据的错误。

 

2022年普林斯顿大学的一项审查发现,在 22 篇同行评审的论文中存在关键陷阱;这些结果传播到了 17 个领域的 290 多个后续研究中。其中一个关键问题是数据泄露。研究将数据泄露分为八个不同的类别,从混合训练和测试数据到抽样偏差。处理各种类型的数据泄露使其难以识别和预防。

 

数据准备工作通常感觉像是在探索冰山。你在表面看到的只是开始。许多问题,特别是与你自己的数据相关的问题,都隐藏在下面。大型组织也面临数据孤岛的问题:团队可能不知道所有可用的特征,导致错误的“无法解决”的结论。标记是另一个主要挑战。通常,我们需要收集和标记一个黄金数据集进行评估,提供详细的注释指南,并执行质量检查。即便如此,你可能会发现标记的数据仍然缺乏一些共识,你不能将其用于模型训练。

 

有了模型即服务和预训练模型,团队可以通过外部 API 跳过训练,但评估仍然困难。在早期的 GenAI 工作中,许多团队依赖于人工观察或微小的示例集。在最初阶段这是可以的,但如果没有强大的评估管道,你最终会得到被动的补丁和未知的爆炸半径。最终,我们仍然需要在 LLM 和 GenAI 的评估上投入大量资金。

 

虽然从一开始就不可能完美地解决所有问题,但这一点仍然需要强调:花时间探索和理解你的数据。根据你的观察寻找新特征并清理它,而不是应用一个标准过程。投资于收集高质量的标签。最终,机器学习的成功在很大程度上取决于数据。

 

陷阱 3:从模型到产品

我想强调的第三个问题是将机器学习模型转变为服务于大规模、实时用户的功能性产品的挑战。这种转变不仅仅是部署代码。要解决生产约束和额外要求,需要付出巨大的努力。

 

真实世界机器学习系统的工程系统概览。(来源

 

谷歌的著名图表显示了与周围的基础设施相比,ML 代码是多么的小。大多数代码来自支持基础设施,包括资源管理、服务系统、监控工具、日志记录和其他相关组件。MLOps 领域已经成熟,并且有许多资源可以提供帮助。当然,对于首次采用者来说,这听起来很繁重,但一旦你建立了基础管道,你就可以支持多个机器学习解决方案,并更无缝地部署它们。

 

为了了解机器学习模型和完整的机器学习驱动解决方案(超出 MLOps 单独可以覆盖的范围)之间的差距,让我们以检索增强生成(RAG)为例。本质上,RAG 从你自己的数据库中提取相关信息。它将其提供给大语言模型(LLM),允许模型在考虑额外上下文的情况下回答问题。一个快速演示看起来可能非常简单(一个 LLM API、一个向量数据库和一些编排)。但是将其转变为一个生产就绪的 RAG 系统(例如,一个为客户支持提供动力的 RAG 系统)是完全不同的故事。你需要评估性能和控制质量的方法。你可能还需要一个更高级或代理式的 RAG 设置,而不仅仅是基本的 RAG 设置,以及可解释性功能,以便客户可以信任答案。除此之外,还有工程方面:通过缓存或推理调整减少延迟,并保持隐私、公平和安全(包括防御幻觉和越狱)。

 

除了技术指标外,监控业务导向的指标也很重要。这些指标可以包括产品质量的衡量(例如,用户采用或参与新功能的频率)、客户体验(例如,满意度或保留率)以及整个平台的健康状况(例如,收入增长、活跃使用或流失率)。关键原则是,技术方面的优化工作不应破坏业务的更广泛成功和可持续性。

 

简而言之,获胜团队是跨职能的,并在早期就要求、质量门槛和生产约束达成一致,而不是在孤岛中工作,希望问题稍后会被修复。

 

陷阱 4:离线与在线

第四个陷阱是离线成功和在线失败。这个陷阱可能是引起团队最多情感波动的一个。为什么坚实的离线模型在线失败?因为数据、解决方案和指标在不同阶段有所不同。离线模型使用历史(通常是清洁/抽样)数据和以机器学习为中心的指标。在线模型使用实时数据、端到端系统和与业务对齐的指标

 

(来源:作者)

 

让我分享一个来自我的第一个生产发布的例子,这是很多年前的事了。当时,我们正在开发一个照片推荐器,以在创意社区内推广摄影师的作品。业务团队提出了一个担忧,即新用户会注册,发布一两张照片,然后再也不回来。考虑到这一点,我们的数据科学团队开始进行一些探索,以找出问题所在。他们发现早期点赞和留存之间有很强的相关性。有了这个洞见,任务就变成了通过尽快推广每个新用户的照片,让他们更快地获得他们想要的反应,并返回我们的网站。

 

当时,大多数推荐器都依赖于协同过滤:如果用户 A 和 B 喜欢许多相同的项目,我们推荐 A 喜欢但 B 未见过的项目。这也解释了为什么我们的新用户没有收到很多点赞,这种现象被称为冷启动问题:因为新项目之前没有任何互动,它们也几乎没有可见性。

 

为了解决冷启动问题,我们构建了一个基于内容的推荐系统,从图片本身预测照片的受欢迎程度。流程:对于用户 A,找到与过去喜欢的相似照片,然后使用受欢迎程度分类器进行过滤,以减少低质量的推荐。

 

一旦分类模型被优化,我们就将其集成到生产管道中。然而,在线 A/B 测试结果参差不齐:点赞增加了,但会话长度下降了,这是一个关于参与度的负面信号。出于某种原因,我们的推荐系统正在造成令人不安的体验;用户不再想继续滚动浏览我们的网站。

 

经过多次迭代,我们最终找到了一个更好的方法来整合受欢迎的信号。结果,推荐系统变得更加复杂。这是一条漫长的道路,铺满了多个步骤,不仅涉及离线评估和在线评估之间的差异,还涉及监控一组业务指标,而不仅仅是一个主要的业务指标。

 

一旦模型集成到生产中,它就成为了一个更大系统的一部分,涵盖了整个解决方案。推荐系统经常合并多个模型,这些模型的输出并不正交,因此一个在离线环境中表现强劲的模型在合并后的系统中可能影响会减弱。这里的教训是:不要过度优化离线环境。要尽快推动 A/B 测试,以验证与业务目标的一致性。

 

陷阱 5:非技术障碍

最后一个陷阱,经常被忽视,与看不见的非技术障碍有关。回到我们之前的调查,当人们被问及在部署模型时面临的主要障碍时,两个最常见的答案与技术无关:缺乏利益相关者的支持和不充分的积极规划。

 

根据 Rexer Analytics 的调查,这些是问题“在你的组织和/或你的客户组织中,模型部署的主要障碍是什么?”的前十名答案:

 

  • 决策者不愿意批准对现有业务的变更

  • 缺乏充分的、积极的规划

  • 缺乏正确执行部署的理解

  • 评分模型所需的数据可用性问题

  • 没有指定人员负责部署

  • 员工不愿意或无法有效使用模型输出

  • 在计算分数或将模型或其分数实施/集成到现有系统中的技术障碍

  • 隐私/法律问题

  • 模型性能被决策者认为不够强

  • 无法提供决策者所需的模型透明度

 

管理利益相关者是棘手的,因为许多决策者没有人工智能背景;他们可能受到头条新闻或之前的软件经验的影响,低估了机器学习的风险和不确定性。这就是人工智能专家真正发挥作用的地方。这不仅仅是关于构建模型,还关于确保你的利益相关者了解你的 AI 项目的正确期望。

 

这意味着我们的工作包括教育。利益相关者需要了解机器学习是如何学习的(以及为什么数据管道很重要),为什么机器学习项目本质上是不确定的,模型限制(声誉和安全风险),以及构建和部署的实际成本。

 

还有管理和规划机器学习项目的问题。三个指导原则脱颖而出:

 

  • 定义一个清晰的最小可行产品(MVP),并设定一个简单的优化目标。通常,从简单开始比从复杂开始表现更好。

  • 尽早构建端到端,使 A/B 测试成为可能,并尽快获得生产反馈。

  • 根据反馈快速迭代,重新审视目标,并根据需要扩展数据。

 

(来源:作者)

 

我看到的一个有效策略是将项目孵化器(用于早期的高风险赌注)与产品线(用于扩展经过验证的解决方案)分开。这在管理风险的同时实现了创新。

 

这里的关键要点是,管理机器学习项目与管理工作传统软件工程项目不同。我们需要适应这些主要挑战,以确保你的团队可以从非技术角度获得支持。

 

结论

虽然没有方法可以保证我们能避免所有错误,但我们可以在现实中考虑一些原则或最佳实践。我们希望选择一个可行、可取且有利可图的项目。我们希望以数据为中心。此外,我们希望鼓励早期合作和积极管理跨职能团队。我们希望快速构建端到端解决方案以进行测试。我们希望根据机器学习项目的性质调整你的项目管理计划。

 

这只是机器学习项目可能失败的部分原因列表,还有许多其他原因,但它可以作为我们启动讨论的良好起点。我想以我最喜欢的查理·芒格的一句引语结束:“尽可能从自己的个人经历中学习一切,尽量减少从他人的好经验或坏经验中间接学习,无论是活着的还是死去的”。

 

原文链接:

https://www.infoq.com/articles/why-ml-projects-fail-production/

前言

上一小节,istio成功的安装,并且还解决了常见的426的问题,本节内容主要探讨一下istio关于流量转发的问题

按比例分发

配置

需要创建一个backend-v1,它与backend的selector都是app: backend,backend-v1部署完成之后,它会立即分走50%的流量,为了测试istio流控,我们需要在不改变任何配置的情况下实现9:1分流,也就是90%进入原backend,10%进入新的backend-v1

watermarked-istio_functions_1.png

  • 标记2个deployment,追加标签,backend为version: v0,backend-v1为version: v1

    kubectl patch deployment backend -p '{"spec":{"template":{"metadata":{"labels":{"version":"v0"}}}}}'
    kubectl patch deployment backend-v1 -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}'
  • 创建istio资源:DestinationRule,该资源主要用来标记istio要往哪个地方转发

    apiVersion: networking.istio.io/v1
    kind: DestinationRule
    metadata:
      name: backend-dr
      namespace: default
    spec:
      host: backend-service
      subsets:
      - labels:
          version: v0
        name: v0
      - labels:
          version: v1
        name: v1
    
  • 创建istio资源:VirtualService,该资源用来确定转发的权重

    apiVersion: networking.istio.io/v1
    kind: VirtualService
    metadata:
      name: backend-vs
      namespace: default
    spec:
      hosts:
      - backend-service
      http:
      - route:
        - destination:
            host: backend-service
            subset: v0
          weight: 90
        - destination:
            host: backend-service
            subset: v1
          weight: 10

调试

  • 测试命令: for i in {1..10}; do curl -s 10.22.12.178:30785/test > /dev/null ; done
  • 登录到k8s的istio-proxy控制台查看: kubectl logs -f -l app=backend -c istio-proxy

    [2026-01-28T08:24:55.670Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
    [2026-01-28T08:24:55.687Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
    [2026-01-28T08:24:55.706Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
    [2026-01-28T08:24:55.741Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=1ms route=default
    [2026-01-28T08:24:55.751Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
    [2026-01-28T08:24:55.759Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
    [2026-01-28T08:24:55.696Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
    [2026-01-28T08:24:55.716Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
    [2026-01-28T08:24:55.725Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
    [2026-01-28T08:24:55.734Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
    
    ▶ kubectl get pod -owide
    NAME                          READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
    backend-86b958bdc-5zjgn       2/2     Running   0          21m     10.244.0.53   wilson   <none>           <none>
    backend-v1-75ccff86dc-sl6bt   2/2     Running   0          119s    10.244.0.55   wilson   <none>           <none>
    nginx-test-7d87875694-8vsrp   2/2     Running   0          30m     10.244.0.61   wilson   <none>           <none>
  • 明显不对,10.244.0.55与10.244.0.53的比例并没有呈现9:1,转发到backend要backend-v1还是5:5

修复

可以直接修改nginx的配置

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    location /test {
        proxy_http_version 1.1;
        # proxy_set_header Host $host; # 原配置
        proxy_set_header Host backend-service.default.svc.cluster.local; # 新配置
        proxy_pass http://backend-service:10000;
    }
}

重启之后再次测试:

[2026-01-28T08:30:59.968Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
[2026-01-28T08:30:59.988Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=1ms route=default
[2026-01-28T08:31:00.027Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=1ms route=default
[2026-01-28T08:31:00.037Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
[2026-01-28T08:31:00.048Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
[2026-01-28T08:31:00.056Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
[2026-01-28T08:31:00.008Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.55:10000 duration=0ms route=default
[2026-01-28T08:31:00.066Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
[2026-01-28T08:31:00.074Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default
[2026-01-28T08:31:00.083Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.53:10000 duration=0ms route=default

已经生效了,这次只有1次10.244.0.55:10000

疑问

有位大哥说了,如果这样配置的,明显影响了业务:

  • nginx的配置被修改了
  • 所有的host被写死了,都成了:backend-service.default.svc.cluster.local,而后端业务是需要把客户端的host带入过去的,改了之后后端业务收到严重影响

确实,固定host属于粗暴简单的写法,还有更加惊喜的解决方法,调整VirtualService,添加hosts

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com # 新增
  http:
  - route:
    - destination:
        host: backend-service
        subset: v0
      weight: 90
    - destination:
        host: backend-service
        subset: v1
      weight: 10

客户端访问的时候必须带上该域名: for i in {1..10}; do curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test > /dev/null ; done

这样也可以解决问题,不过坑点也来了,年久失修,从无数前人继承的祖传代码,就需要好好的梳理到底有哪些host来访问,否则漏掉host的话,就会出现配置问题。-_-!

再次凸显了istio之中,host是非常非常重要的,Istio 的路由决策、Service 的匹配完全依赖 Host 头

  • Istio 的 VirtualService 本质上是一个“增强版”的路由器。如果发现请求的 Host 是 backend-service,就按 90:10 分配。
  • 之前的配置是$host,由于客户端没有传输host,当请求经过 Nginx 的 Sidecar时,它会检查Host,发现为空。由于路由表里没有对应的记录 ,sidecar并不认识,按普通 K8s 流量处理

按header分发

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - match:
    - headers:
        hellotest:
          exact: "true"
    route:
    - destination:
        host: backend-service
        subset: v1
  - route:
    - destination:
        host: backend-service
        subset: v0

curl -s -H 'host: api.wilsontest.com' -H 'hellotest: true' 10.22.12.178:30785/test。只有header里面匹配了hellotest: true才会去v1,否则全部去v0

按前缀分发

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - match:
    - uri:
        prefix: /test/v1
    route:
    - destination:
        host: backend-service
        subset: v1
  - route:
    - destination:
        host: backend-service
        subset: v0

带有/test/v1前缀的都会去新版本v1,满足不了条件都会走默认的版本v0

url改写

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: backend-vs
  namespace: default
spec:
  hosts:
  - backend-service
  - api.wilsontest.com
  http:
  - match:
    - uri:
        prefix: /test/v1
    route:
    - destination:
        host: backend-service
        subset: v1
  - match:
    - uri:
        prefix: /test/v2
    rewrite:
      uri: /test
    route:
    - destination:
        host: backend-service
        subset: v0
  - route:
    - destination:
        host: backend-service
        subset: v0

如果是/test/v1,就访问v1版本,/test/v2重写成/test并且访问v0版本,其余的默认都会走v0版本

蓝绿、金丝雀、灰度、A/B测试

关于流量分流的各种操作,大部分都集中在以下场景:

  • 蓝绿:实现瞬间切换与零宕机回滚,消除发布期间的中间状态
  • 金丝雀:像矿工用金丝雀探测毒气一样,先让一小部分用户(如1%~5%)访问新版本,观察系统指标(如错误率、延迟),若无问题再逐步扩大范围
  • 灰度:将用户群体按比例或特定规则(如地域、设备)逐步切换到新版本(例如10%→30%→100%),持续观察反馈
  • A/B:同时向随机分组的用户展示不同版本(A组用旧版,B组用新版),通过统计指标(如点击率、转化率)判断哪个版本更优
蓝绿发布金丝雀发布灰度发布A/B测试
主要目标零停机、瞬时回滚用真实流量快速发现技术风险平稳、可控地逐步替换所有用户验证不同版本的业务效果
流量路由全量切换(100%→0%)极小比例引流(如1%-5%)按比例分阶段扩大(10%→50%→100%)按规则/随机分配(如50%/50%)
关注重点系统可用性与回滚速度系统稳定性指标(错误率、延迟)发布过程平稳性与综合反馈业务指标(转化率、留存率)
所需资源两套完整环境,成本高一套环境,新版本实例较少一套环境,新旧版本实例共存一套或多套环境,并行运行多个版本
用户选择全体用户同时切换小部分用户随机或按基础设施选择用户按比例或属性逐步迁移用户随机分组或按属性定向分配
持续时间极短(切换在几分钟内)短(几小时到一天)中长(几天到数周)长(数周到数月)
典型场景关键业务大版本升级、基础设施更换后端服务、中间件、数据库变更前端功能、用户界面更新UI设计、文案、算法策略、定价优化

联系我

  • 联系我,做深入的交流


至此,本文结束
在下才疏学浅,有撒汤漏水的,请各位不吝赐教...

Anthropic 的新版模型 Claude Sonnet 5 似乎被泄漏。

综合目前流出的信息来看, Claude Sonnet 5 的内部代号是 Fennec,传闻其整体代际水平比 Gemini 的 “Snow Bunny” 领先一整代。

 

根据泄露信息,新模型继续保持了 100 万 token 的超大上下文窗口,同时在推理速度上有显著提升。此外,有消息称该模型在 Google TPU 上进行了训练或深度优化,从而带来了更高的吞吐能力和更低的延迟表现。

 

信息显示,Sonnet 5 在 SWE-Bench 上的得分超过 80.9%,显著领先当前主流的代码模型。与此同时,Vertex 平台针对 Sonnet 5 特定 ID 返回的 404 状态,也被视为一种侧面印证,暗示该模型已部署在 Google 的基础设施中,只待正式启用。

 

在产品定位上,Sonnet 5 被认为采取了相当激进的定价策略,价格或将比 Claude Opus 4.5 低约 50%,但在多项核心指标上却实现了全面超越。

 

在开发者体验上,Claude Code 也迎来重要进化。Sonnet 5 支持在终端中生成多个专用子代理,例如后端、QA 和研究型代理,并行协作完成任务,甚至提供类似“开发团队”的工作模式:用户只需给出简要需求,多个代理即可在后台自主运行,像真实的人类团队一样完整实现功能。

 

关于发布时间,Vertex AI 的一条错误日志中曾出现 claude-sonnet-5@20260203,由此推测该模型可能会在当地时间 2 月 3 日前后正式发布,但截至发布未有官方消息。与此同时,Anthropic 今天早上所有 API 都无法访问。为此,有网友猜测,Sonnet 5 未按预期发布是因为 Anthropic 部署该系统时,遇到了一些技术问题,不得不将其回滚。

“因为 API 问题而回滚一次重大的模型发布,这种运营层面的现实基本没人会拿出来发推。可以打赌,真正的内幕故事肯定比他们明天官方对外说的版本要精彩得多。”还有网友称,“这或许能解释原因。我猜他们在发布时发现,对 API 的需求规模超出了预期,现有架构可能承受不住,容易把服务器直接压垮,所以不得不重新评估,并加强分发和基础设施,才能保证后续上线过程平稳进行。”

 

“如果属实,那 Anthropic 公司今天肯定有人过得很累。”

1、背景

在 AI 问世的两年里,我们习惯了把它当作一个超级百科全书:如果你问它一个事实,它会给出答案;如果你给它一段文字,它会帮你总结。然而,当我们面对“分析某行业未来五年的趋势”或“撰写一份详尽的技术竞品调研报告”这样复杂的任务时,传统的 LLM 往往显得力不从心——它们缺乏深度,容易产生幻觉,且受限于上下文长度。

Deep Research正是为了解决这一痛点而生。它不再是一个简单的聊天机器人,而是具备自主推理能力的“AI 研究员”。

我将会在下面的内容中深入剖析 Deep Research 的运行机制、其背后的工程挑战以及它如何通过“ReAct 范式”重塑信息获取的方式。

2、什么是 Deep Research

Deep Research 是 专为网页浏览、数据分析和复杂任务处理而优化的全新功能。与普通 LLM “问什么答什么”的被动模式不同,Deep Research 具备主动规划深度推理的能力。

它的核心特征可以概括为:

1.自主性(Autonomy): 它可以一边思考,一边“查资料”。它不仅是检索信息,还能自主判断信息是否足够,如果不足,它会主动调整搜索关键词再次检索。

2.长链条推理(Long-chain Reasoning): 基于 LLM的推理能力,它能将一个模糊的庞大需求拆解为多个子步骤,分阶段执行。

3.专业报告生成: 最终输出的不是零散的对话,而是包含逻辑摘要、清晰引用来源和完整文档的专业级研究报告。

为什么我们需要它? 当前的信息需求往往需要跨越多个来源、阅读大量非结构化数据。Deep Research 实际上降低了“海量信息收集”“高质量推理整合”之间的壁垒,尤其擅长挖掘那些需要浏览数十个网页才能拼凑出的小众或非直观信息。

3、核心原理:从 DeepSearch 到 DeepResearch

要理解 Deep Research,通过两个层级来看:底层的搜索循环(DeepSearch)和上层的报告框架(DeepResearch)。

3.1 核心引擎:DeepSearch(循环与迭代)

DeepSearch 的本质是一个“搜索 - 阅读 - 推理”的无限循环。这与我们熟悉的 ReAct Agent 范式高度相似,但通过强化学习(RL)不仅学会了推理,更学会了“搜索策略”:

•搜索(Search): 探索互联网,获取原始信息。

•阅读(Read): 对特定网页进行详尽分析,提取关键片段。

•推理(Think): 这是最关键的一步。模型会评估当前收集到的信息是否足以回答问题。如果不够,它会决定是将问题拆解为更小的子问题,还是尝试全新的搜索关键词。

这种 <think> → <search> → <information> → <think> → <answer> 的模式,让 AI 具备了“自我纠错”和“追根究底”的能力。

在这里插入图片描述

3.2 上层框架:DeepResearch(结构化输出)

DeepSearch 负责找答案,而 DeepResearch 负责写报告。它在 DeepSearch 的基础上增加了一个结构化框架

1.用户意图理解 & 目录生成(TOC): 接收指令后,首先生成报告目录(如引言、方法论、相关工作、结论)。

2.分章节执行: 系统性地将 DeepSearch 引擎应用到报告的每一个章节中。每个章节都是一个独立的研究任务。

3.全局整合: 最后将所有章节内容整合,进行连贯性润色,生成最终报告。

整个执行过程通常耗时 5 到 30 分钟,这在以前的即时问答中是不可想象的,但对于深度研究来说,却是极高的效率。

在这里插入图片描述

让 LLM 在自身推理过程中与搜索引擎交替交互。用户输入query,LLM产生TOC,然后进入循环:查找、读取和推理,直到达到结束的条件,然后再通过LLM做总结,最终给用户输出完整的研究报告(<think> → <search> → <information> → <think> → <answer> )的模式,已经非常接近我们熟悉的 ReAct Agent 范式。不同的是,这里的 Agent 不依赖提示词,而是通过 RL 真正“学会了”搜索策略。实质上就是一个 “带搜索能力的 ReAct Agent”,只不过不再依赖提示词工程,而是直接通过强化学习学会何时搜索、何时推理。注意,它是主动认知到何时需要检索信息,这是一个非常显著的特点和不同。

4、 工程化挑战与解决方案

在这里插入图片描述

Deep Research 之所以能超越普通的 RAG(检索增强生成),在于它解决了一系列棘手的工程问题。通过对技术细节的复盘,我们可以了解到其背后的技术实现。

4.1 解决“垃圾进,垃圾出”:URL 排序与清洗

4.1.1 问题

Deep Research 在一次任务中可能扫描数百个 URL。如果把这些内容一股脑塞给 LLM,不仅浪费 Token,还会导致模型“瞎选”答案。在每一次 DeepReSearch 漫长过程中,你可能会从搜索引擎结果页(SERP)里收集一堆 URL,每打开一个网页,又能顺藤摸瓜找出不少新链接,就算是去重后,也是轻轻松松几百个网址。同样的,一股脑儿全塞给 LLM 肯定不行,浪费宝贵的上下文长度不说,更要命的是,我们发现 LLM 基本上就是瞎选。所以,得想办法引导 LLM 去挑出那些最有可能包含答案的 URL。

4.1.2 解决方案:两阶段重排序(Re-ranking)

URL 排序打分评测是 Deep Research 系统中的关键技术环节,它直接影响到信息获取的效率和质量。系统采用了多层次、多维度的排序策略,确保能够从海量的搜索结果中快速定位最有价值的信息源。​

综合评分机制是 URL 排序的核心。系统会综合考虑多个因素:最后更新时间、域名出现的频率、网页路径结构,以及最重要的与问题的语义相关性,算出一个综合评分​。这种多维度的评分机制能够全面评估 URL 的价值,避免了单一维度排序的局限性。​

具体的评分因素包括:​

1.频率信号: 如果某个 URL 在不同的信息源中多次出现,它的权重就会更高。另外,如果某个域名在搜索结果中经常出现,来自这个域名的 URL 也会被加分。因为一般来说,热门域名往往包含更权威的内容。​

2.路径结构: 会分析 URL 的路径结构,来判断哪些内容是聚集在一起的。如果多个网址都属于同一个路径层级,它们的分数会更高;但路径越深,分数加成会逐渐减少。​

3.语义相关性: 使用 小模型(例如:jina-reranker-v2-base-multilingual)或者大模型 来评估问题和每个 URL 的文本信息(例如标题和摘要)的语义相关性,这是一个典型的重排序问题​。每个 URL 的文本信息来自搜索引擎结果页(SERP)API 返回的标题和摘要,以及页面上 URL 的锚文本。​

4.最后更新时间: 有些查询对时效性要求很高,所以一般来说,越新的 URL 价值越高。系统采用一套组合拳,综合考虑 SERP API 提供的筛选功能、HTTP Header 信息分析、元数据提取、内容模式识别等,最终给出一个带有置信度评分的时间戳。​

5.受限内容识别: 某些社交媒体平台的内容是受限的,或者需要付费才能访问。系统会积极维护一份黑名单,把这些有问题的 URL 和域名都记录下来,降低它们的排名,避免在这些无法访问的内容上浪费计算资源。​

6.域名多样性: 为了提高结果的多样性,避免陷入 "局部最优",系统采用 "探索 - 利用" 的策略:从每个域名下选择排名 Top K 的 URL。

粗排和精排:

•粗排: 快速筛选,追求召回率。

•精排: 针对粗排结果进行深度评估。这里通常采用基于重排模型(Cross-Encoder)或基于 LLM 的重排序。利用 LLM 的语义理解能力,甚至使用滑动窗口算法(从后向前滑动),对候选段落进行相关性打分,确保只有含金量最高的信息进入下一步。

粗排检索效率较快,但是召回的内容并不一定强相关。而精排效率较低,因此适合在粗排的基础上进行进一步优化。重排的任务就是评估这些上下文的相关性,优先考虑那些最有可能提供准确和相关信息的内容。

重排方法主要分为以下两类:

基于重排模型: 这些模型可以输出文档与查询之间的相关性;够针对一个查询和文档对,输出它们的相似度分数。我们利用这个分数对文档按照与查询的相关性进行重新排序。解决传统检索方法(如BM25、向量检索)的局限性,例如语义模糊性、长尾关键词漏检、多模态意图理解不足等问题。优化检索结果的Top-K排序,提升后续LLM生成答案的准确性和效率

基于 LLM: 由于大模型可以更全面地捕捉语义信息,也可被用于重排序。使用 Prompt 的方式引导 LLM 进行重排序。直接利用 LLM 的语义理解能力对所有候选段落进行相关性程度排名。如果文档的数量通常非常大,而 LLM 可能无法一次性处理所有的文本数据。使用滑动窗口算法原理,滑顺序是从后向前的,将前一个窗口中的前两个段落参与下一个窗口的重排序。

4.2 解决“大海捞针”与“上下文丢失”:长网页内容提取

4.2.1 问题

读取网页内容后,我们需要把它作为一条知识,放到 Agent 的上下文里,供它推理。虽然把全部内容一股脑塞进 LLM 的上下文是最省事的办法,但考虑到 Token 成本和生成速度,这肯定不是最好的选择。在实际应用里,我们需要找出内容中与问题最相关的部分,只把这些部分作为知识添加到 Agent 的上下文里。

我们一边是问题(原始查询或“信息差”问题),另一边是大量的 Markdown 内容,其中大部分内容都是无关紧要的。我们需要选出与问题最相关的片段。

有限数量文档中的有限数量的文本块: 假设每个块大约有 500 个 Token,那么一个典型的长网页文档大约有 20 万 Token(中位数)到 100 万 Token。我们每一步抓取 4-5 个 URL,这样大概会产生几百个文本块。也就是说,几百个向量和几百个余弦相似度。在内存里就能轻松处理,根本不需要向量数据库。

我们需要连续的文本块来形成有效的知识摘要: 我们不能接受由分散的句子组成的摘要。更有用的知识摘要,更能保持文本的连贯性。这样 LLM 更容易从知识源中复制和引用,也能减少“幻觉”。

网页内容动辄数万 Token,且充满噪音。如何提取有效信息且保持上下文连贯?

4.2.2 解决方案:迟分算法(Late Chunking)

传统的 RAG 会直接把文档切块(Chunking)然后向量化,但这会导致切块丢失全局上下文(例如一个代词“它”在切块后不知道指代谁)。

Late Chunking(迟分): 这是一个极其精妙的优化。它不急着切块,而是先用支持超长上下文的模型(如 jina-embeddings-v3)对整个文档进行编码,保留全局语义。

长文档切块,有俩个问题,第一个问题是:文本块分割得准不准,这不仅关系到搜索结果好不好读,还关系到做 RAG 的时候,给 LLM 喂进去的文本块是不是正好,不多不少;第二个问题是:每个分块里的上下文信息容易丢失。文档切完之后,下一步就是把每个分块拿去批量向量化。但这么做容易把原文档里的全局上下文信息给丢了。

迟分(Late Chunking)主要就是解决第二个问题 —— 上下文丢失。它不是用来找最佳断点或者语义边界的。该用正则表达式,启发式方法,或者其他技术来分块,还是得用。

但迟分不一样的地方是,它不是一切完就立马把每个块拿去向量化,而是先把整个文档在一个上下文窗口里编码了(jina-embeddings-v3最新 SOTA 向量模型,支持 8192 Token 的长输入),然后再根据边界线索去进行均值池化操作。

它的工作原理类似于一维卷积(Conv1D)。这个过程首先把一个长文档分割成固定长度的块,然后用开启了迟分的 jina-embeddings-v3 向量化这些文本块。计算完每个块和问题之间的相似度分数后,一个滑动窗口会在这些相似度分数上移动,以找到平均值最高的窗口。

用迟分和类似“一维卷积”的平均池化,挑出跟问题最相关的段落。

均值池化: 在生成向量后,再根据边界线索进行切分和均值池化。 这就像是先读完一整本书理解了全意,再回过头去摘录段落,而不是每读一段就摘录一段。这样提取出的“知识块”既精准又保留了上下文,极大减少了 LLM 的幻觉。

4.3 解决“写不长”:突破 Token 输出限制

4.3.1 问题

上下文窗口的根本性限制: 大部分模型,例如:DeepSeek-V3,单次输出通常限制在 8K Token(约 8000 字)以内,难以一次性生成数万字的详尽报告。(可能有人会提出好多模型输出几万字或者几十万字,例如GPT-5和Claude Opus等,但是又会出现下面"上下文腐烂" 现象的问题)。

"上下文腐烂" 现象: 当智能体开始频繁调用多次工具,每次调用返回的 "观察结果" 都会追加到对话历史中,导致上下文长度爆炸式增长。这不仅带来高昂的计算成本,更会导致 "上下文腐烂" (Context Rot)—— 随着上下文变长,模型性能反而下降。​

具体表现为:​

1.性能下降:随着上下文长度增加,模型性能会明显下降。Anthropic 把这个现象称为 "上下文腐烂"(context rot)。具体表现是模型开始重复输出、推理速度变慢、回答质量下降​。​

2.注意力分散:Agent 的上下文随时间推移必然熵增,导致注意力机制分散。​

3.信息利用效率降低:研究发现,当相关信息位于长输入上下文的开头或结尾时,模型的性能表现最佳,而当信息被放置在中间位置时,性能会显著下降。此外,在长上下文任务中,模型有时会倾向于直接依赖其预训练的参数知识来回答问题,而不是有效利用所提供的外部长文本,这进一步加剧了性能的下降​。

4.3.2 解决方案:双层级 Agent 架构(Planner + Workers)

Deep Research 实际上采用了一种“规划-执行”的分离架构:

•规划 Agent (Planner): 它是“包工头”。负责理解任务,生成详细的 JSON 格式大纲,并分配每个章节的字数预算。

•执行 Agent 集群 (Workers): 它是“建筑工”。多个 Agent 并行工作,每个 Agent 认领一个章节的标题,独立去搜索、阅读和写作。

•聚合器: 最后由一个模块像拼积木一样将各章节拼接,并进行逻辑顺滑和长度控制。
在这里插入图片描述



双层架构的核心设计包括:​

1.监督者层级:作为系统的 "大脑",负责将模糊需求转化为可执行计划。在 prompts.py 中定义的结构化提示模板指导规划器完成三项核心任务:需求澄清(通过 clarify\_with\_user 节点实现)、子主题分解(最大支持 5 个并行子任务)、以及资源分配(根据主题复杂度选择模型与工具)。​

2.执行者层级:负责具体的信息检索、内容提取和初步分析工作。执行者层级包含多个专门的 Agent,如搜索 Agent、阅读 Agent、分析 Agent 等,每个 Agent 负责特定的任务。​

3.状态机控制:基于 LangGraph 构建的状态机实现了复杂流程的精确控制。状态机能够跟踪研究过程的每个步骤,确保任务执行的有序性和完整性。​

上下文管理的创新方案:​

为了缓解上下文腐烂问题,系统采用了多种上下文管理策略:​

1.上下文卸载技术:系统采用 "上下文卸载"来缓解上下文污染,这能帮 agent 保持在正确轨道上。上下文卸载就是把信息存在语言模型的 "活跃上下文窗口" 之外。把关键信息卸载出去,只在需要时检索,我们就避免了模型工作内存的 "过载"​。​

2.分级存储架构:在于引入分级存储架构。通过将信息按照重要性和使用频率进行分级存储,系统能够在有限的上下文中保留最重要的信息,同时在需要时快速检索其他信息。​

3.智能剪枝策略:系统采用上下文剪枝技术。这个技巧是在 RAG 的基础上做的优化。它的核心是在将检索到的信息交给主模型之前,先进行一次 "剪枝"。具体做法是:先检索出相关文档,然后使用一个更小、更快的模型,让它读一遍这些文档,这个小模型的任务是,根据用户的原始问题,只从文档中提取最核心、最相关的信息​。

长文档处理的技术突破:​

1.分段处理策略:系统将长文档分成多个段落或章节,每个部分独立处理,然后通过监督者层级进行整合。这种方法避免了一次性处理整个长文档带来的上下文限制问题。​

2.增量生成机制:系统采用增量生成的方式处理长篇报告。监督者层级负责制定整体结构和各部分的生成顺序,执行者层级按照顺序逐步生成各部分内容。这种方式不仅避免了输出长度限制,还提高了生成内容的连贯性。​

3.智能整合算法:在各部分内容生成后,监督者层级会对内容进行智能整合。这包括检查逻辑一致性、消除重复内容、优化章节顺序等,确保最终报告的质量。

4.4 生成内容打分

Deep Research 在生成内容的质量控制方面采用了多层次、多维度的评分和优化机制,确保最终输出的内容既准确又有价值。​

自适应评估框架是内容评分的基础。包括两个互补的评估框架来评估 DRA 能力:RACE(基于参考的自适应标准驱动评估框架,具有动态加权)用于评估生成研究报告的质量,FACT(事实丰富性和引用可信度框架)用于评估信息检索有效性和引用准确性​。​

RACE 框架的核心特点包括:​

1.动态权重分配:对于每个任务,评判 LLM 通过多次试验获得每个维度的权重,并取平均值作为最终权重,确保评估与任务意图一致​。所有维度的生成标准被聚合到一个综合列表中,评判 LLM 然后根据每个标准分析目标报告和参考报告,为两份报告生成每个标准的分数列表,用于最终得分计算。​

2.多维度评估:框架首先基于领域知识确立四个顶层评测维度:全面性(COMP)、洞察力 / 深度(DEPTH)、指令遵循(INST)和可读性(READ)。对于每个具体任务,评判 LLM 会动态计算各维度的权重,并为每个维度生成一组定制化的评测标准。​

3.自适应逐点质量评估:评估模块包含自适应逐点质量评估和主动事实核查两大核心组件,既解决了 "判分死板" 的问题,又实现了 "全面查错" 的目标。自适应逐点质量评估打破了固定维度的限制,为每个任务量身定制评分标准。该组件首先保留 4 个通用评估维度,同时针对每个具体任务自动生成 1-3 个专属评估维度。​

主动事实核查机制确保了内容的准确性。系统不会只傻傻地检查报告里标出来的引用来源,而是会像一个侦探一样主动去网上搜索交叉验证报告里的每一个说法,不管你有没有给出处,这就保证了评分的绝对严格​。​

这种机制的实现包括:

1.自动识别关键陈述:系统会自动识别报告中的关键陈述和数据,包括事实性描述、数值数据、因果关系等。​

2.多源交叉验证:对于每个关键陈述,系统会从多个独立来源进行验证,确保其准确性。​

3.置信度评估:系统会为每个验证结果给出置信度评分,高置信度的内容会被保留,低置信度的内容会被标记为需要进一步核实。​

内容修改与优化策略: 基于评分结果,系统会采用多种策略对内容进行修改和优化:​

1.基于评分的自动修正:当系统发现内容存在事实错误或逻辑问题时,会自动进行修正。这种修正不是简单的替换,而是基于多个可靠来源的信息进行综合判断。​

2.人工干预机制:对于复杂的问题或存在争议的内容,系统会提示用户进行人工干预,确保最终内容的准确性和客观性。​

3.风格一致性优化:系统会检查整篇报告的语言风格、术语使用、格式规范等,确保全文的一致性和专业性。​

4.结构优化:根据内容的逻辑关系,系统会对报告的结构进行优化,确保章节安排合理、层次分明。

5、 Deep Research vs Manus

Manus 更像是一个高度工程化的 Agent 平台,它整合了大量工具(浏览器、代码解释器等),强在“调度”。而 Deep Research 是模型层面和架构层面的进化,它通过强化学习或者架构优化让模型了解“如何搜索”和“如何推理”的策略,是一种更原生和自主的智能。所以Deep Research可以进行撰写文献综述、市场与竞品分析、行业研报、投融资研报、市场调研、新闻热点追踪、生活决策等,也可以在检索时沉淀有用信息。

6、总结

Deep Research是我在25年年中接触的,当时感觉就很惊艳,感觉正在跨越到一个新的门槛:从信息的搬运工,变成了信息的加工者。它不再需要用户费尽心思想 Prompt,也不需要用户去点击一个个的链接。它展示了 AI 作为一个“思考者”的潜力——它知道自己不知道什么,并且知道去哪里找到答案。对于使用者而言,这意味着我们可以将最耗时的“信息收集与整理”阶段外包给 AI,从而专注于更高维度的决策与创新。

后面会继续写我怎么在真实业务中利用DeepResearch的能力,最后祝大家早安、午安、晚安。

系统的复杂性

我们团队负责的系统是分布式微服务部署架构,随着业务的不断发展壮大和多条线场景化的持续建设丰富,系统的业务逻辑越来越多,功能逻辑也越来越复杂。


系统早期单个应用的一个用户故事地图

在这里插入图片描述





系统交互


在这里插入图片描述



在这里插入图片描述










物理模型(库表)的复杂性


在这里插入图片描述




一个子系统的代码沉淀

在这里插入图片描述


在这里插入图片描述









在应用部署方面,目前现状我们的一个应用对应一个coding代码地址,部署以一个应用为单位发起部署申请,应用下有多个集群,集群下有多个分组,也区分灰度环境、正式线上环境。通过不同的部署编排,使用不同的代码版本部署不同的环境。



系统的复杂性来自多个方面:业务流程复杂性、架构复杂性、代码实现复杂性、物理模型(库表)的复杂性、监控运维的复杂性等。本文重点不是系统复杂性的治理,而是在现有基础上,如何低成本轻量级方式服务隔离,在大促为系统的稳定性中发挥作用。



一个容器中部署的应用进程内,提供了各种各样的服务,以在库应用为例,包含了盘点、变更、补货、移库、盘盈亏、预包等相对独立的功能,每个功能又有自己的单据-任务-结果整套业务流程。既有RESTful服务,也有JSF服务,还有MQ消息处理,另外还有定时任务。这些资源虽有线程池隔离,但CPU、内存等资源仍是共享资源,在负载高的时候,比如CPU满载或内存OOM时,会造成服务卡顿,RT时间长,影响服务响应和功能使用。


方案
方案一:应用拆分

按业务域、技术域对进行拆分,比如在库应用按盘点、变更、移库、补货等拆分为单独的应用,不仅应用部署做了拆分,对应的数据库层面也按域进行拆分,盘点相关的表,例如盘点单主档、盘点单明细、盘点任务主档、盘点任务明细、盘点结果独立到单独的库中,可以按逻辑库独立,也可以独立到单独的数据库实例中,后者的隔离效果更好。在代码层面,可以将在库coding按域拆分出来单独的代码库,也可以不独立,保持共享代码库,只是在编译时按moudle进行按需集成,例如为盘点应用编译时,包含盘点moudle、公共module,其他不需要的moudle,比如变更module、补货module则不需要参与编译集成。


方案二:使用Hystrix进行服务隔离

Hystrix 主要实现的是‌进程内隔离‌,具体来说,它通过线程池隔离和信号量隔离两种机制,在单个应用进程内部对依赖服务的调用进行资源隔离和故障控制‌。
‌线程池隔离‌

Hystrix 为每个依赖服务分配独立的线程池,不同服务的调用请求在各自的线程池中执行,避免因某个服务故障或延迟耗尽整个应用的线程资源‌,这种隔离方式类似于“舱壁隔离”,将故障限制在特定范围内‌。


‌信号量隔离‌

通过控制并发请求的线程数(信号量阈值)实现隔离,适用于耗时短、并发量高的场景(如读缓存)‌。信号量隔离是同步阻塞方式,不涉及线程切换,开销较低‌。


方案三:轻量级进程间服务服务隔离

既不拆分应用,也不需要引入Sping Cloud Hystrix组件,不侵入业务代码,在部署层面实现服务隔离,属于应用内分组机器实例隔离,也是进程间服务隔离。数据库和代码库层面不需要隔离,仍采用共享模式。

以在库为例,为盘点、补货、变更等创建不同的业务分组,当然处于高可用考虑,会为盘点、补货、变更等每个业务分组,又会横跨多个机房分组,不如中云信机房分组、有孚机房分组。



本文探索实践的方案三示意图如下:






方案简单对比和选择
在这里插入图片描述

本文旨在探索一个轻量级的进程级服务隔离方法,短平快,易落地,见效快,可以在大促中快速发挥作用,保障系统的稳定性。

在方案选择上,本文选择方案三进行实操落地。选择方案三,是因为方案三很牛吗?不是的,相比之下方案一和方案二方案更为成熟,行业落地经验更为丰富。

之所以选择方案三,是在众多的因素考量中折中选择,在不同的场景下,采用合适的方案解决相应的痛点,够用 + 1,easy + 1。

方案二和三之间并无冲突,其实可以结合搭配使用。


实操
隔离部署分组

配置集合

通过配置集合,实现分组间共享配置,方便多分组管理。
在这里插入图片描述









跨机房多机房部署

通过多机房部署实现服务高可用。

在这里插入图片描述





隔离NP域名

按域隔离的RESTful,创建单独的NP域名。
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述


















NGINX拆分流量

拆分upstream,按照不同域RESTful方法的规则进行路由拆分配置。

在这里插入图片描述
在这里插入图片描述









JSF服务隔离

别名拆分,通过别名隔离服务,调用方无需改动。


在这里插入图片描述
在这里插入图片描述


在这里插入图片描述













随着服务隔离,同时兼顾机器资源利用率,拆分后的单域内机器数量少于拆分前机器数量,JSF业务线程池大小可适当调大,JSF的单机限流阈值也适当调大。


MQ消息队列隔离

在变更的yml中,只保留变更相关的TOPIC,其他置为NONE。
在这里插入图片描述







在盘点的yml中,只保留盘点相关的TOPIC,其他置为NONE。

在这里插入图片描述






其他分组按此调整配置。


落地效果
RESTFul服务

对应的logbook自然地按域拆分,方便查询定位流量机器。

在这里插入图片描述
在这里插入图片描述











JSF服务

通过隔离的JSF别名实现流量路由到的机器。

在这里插入图片描述





未来演进

目前,在应用稳定方面,探索并实践落地了一种轻量级进程间服务隔离单元化部署方法,在库和库存按业务域拆分服务部署单元化分组,在库按盘点、补货、变更、导出导出、通用服务部署,库存按库存查询、库容服务、高时效、worker服务等作为独立部署的部署单元,控制爆炸半径,每个部署单元都是双机房高可用,保障系统的稳定性。

未来,随着系统的长期发展,系统复杂性需按域合理拆分治理,业务单元化,服务单元化,系统演进与业务发展齐头并进,相互促进,使系统始终保持在健康的水位,可持续发展。

在企业日常运营与项目推进的全流程中,团队联动是打破部门壁垒、整合分散资源、保障协作效率的核心环节。尤其在跨部门任务并行、成员异地办公、需求快速迭代的当下,联动环节的灵活性与便捷性,直接决定了协作能否高效落地、资源是否充分利用。然而传统的团队联动模式往往陷入沟通割裂、信息滞后、协作脱节的困境,一款适配中小团队场景与轻量化协作需求的看板类团队联动工具,成为突破这一瓶颈的关键。

一、团队联动的核心痛点与工具价值

(一)联动推进的典型痛点

在实际协作场景中,团队联动环节常面临以下问题,直接拉低跨团队协作效率与目标达成质量:

  • 联动沟通渠道混乱,信息散落在微信群、邮件、文档等多场景,关键内容易遗漏;
  • 跨团队任务协同逻辑不清晰,责任划分模糊,出现问题互相推诿;
  • 联动信息同步滞后,前端需求变更无法及时触达后端,导致返工或进度延误;
  • 团队联动进度无统一视图,管理者无法实时掌握协作状态,易引发协作断层;
  • 多团队资源共享不畅,工具权限划分繁琐,跨团队调取资料效率低下。

(二)轻量化团队联动工具的核心价值

一款优质的轻量化团队联动工具,能够从沟通、协同、资源三个维度解决上述痛点:

  • 沟通层面:整合多渠道沟通入口,简化跨团队消息触达路径,降低沟通成本;
  • 协同层面:看板可视化展示跨团队任务联动关系,明确责任主体,提升协同效率;
  • 资源层面:轻量化管控团队共享资源,简化权限配置,实现资源快速调取与复用。

二、轻量化团队联动的全流程管理规范

清晰的流程是联动高效推进的基础,轻量化团队联动需遵循“梳理-对接-同步-跟踪-沉淀”的标准化路径:

  1. 联动需求精细化梳理:按“项目-跨部门任务-协作节点”三级结构,梳理跨团队联动需求,明确协作内容、责任人、时间节点;
  2. 跨团队精准对接:基于团队核心职责与成员技能,通过看板工具快速匹配协作方,明确各环节联动规则;
  3. 联动信息实时同步:根据项目进度与需求变化,通过看板卡片更新联动信息,确保跨团队信息同步无偏差;
  4. 联动状态可视化管理:统一使用“待对接 / 协作中 / 已完成 / 待确认”四类状态标识,通过看板视图实时监控,对阻塞、延期的联动环节及时干预;
  5. 联动成果沉淀复用:项目结束后,整理跨团队联动经验,将优质协作流程保存为看板模板,优化后续联动流程。

三、轻量化团队联动工具全维度推荐

(一)极简入门型(适配初创/小微团队)

1. 板栗看板

  • 核心特性:支持跨团队任务卡片化管理,通过拖拽实现协作节点分配、状态切换,可自定义卡片字段(协作内容、时间节点、共享资源链接等),支持轻量评论沟通;
  • 适配场景:10人以内小微团队、单项目跨岗位联动、快速沟通类协作场景;
  • 优势亮点:零学习成本,开箱即用;界面简洁直观,跨团队联动操作流畅;支持看板共享与权限轻量化设置,适配高频次小型协作需求。
    在这里插入图片描述

2. Trello

  • 核心特性:经典看板视图,协作任务以卡片形式呈现,支持拖拽分配跨团队负责人、调整至不同协作阶段列,可设置截止时间与联动标签,支持插件拓展沟通功能;
  • 适配场景:小微团队日常跨部门沟通、简单任务联动、临时协作事项对接;
  • 优势亮点:灵活性极高,可自定义看板列(如待对接/协作中/待审核/已完成);支持多设备同步,随时随地推进跨团队联动;插件生态丰富,可拓展消息提醒、文件共享等功能。
    在这里插入图片描述
    在这里插入图片描述

(二)协同提效型(适配中型轻量团队)

1. Tower

  • 核心特性:提供看板、列表双视图,支持跨团队任务拖拽式联动,可设置协作依赖关系,实时展示跨团队成员协作负载,支持任务关联共享文档;
  • 适配场景:10-30人中型团队、多项目跨部门联动、前后端协同类项目;
  • 优势亮点:操作简洁高效,跨团队联动逻辑清晰;支持联动任务状态变更自动通知,确保信息同步;可与主流沟通工具集成,联动消息实时触达。
    在这里插入图片描述

2. Asana(轻量化模式)

  • 核心特性:支持看板、日历多视图切换,通过拖拽实现跨团队任务分配、时间规划,内置协作依赖管理与进度可视化仪表盘,支持轻量团队共享空间;
  • 适配场景:中型跨职能团队、多模块协作联动、需要灵活调整协作节奏的项目;
  • 优势亮点:界面直观友好,跨团队联动操作流畅;支持批量拖拽调整协作任务,提升联动效率;可设置协作里程碑,辅助把控联动节奏。
    在这里插入图片描述

(三)综合适配型(适配中大型轻量化协作团队)

1. ClickUp

  • 核心特性:支持看板、表格、时间轴等多视图自由切换,通过拖拽实现复杂跨团队任务联动、资源调度,支持自定义协作工作流与字段,内置跨团队负载分析与数据报表;
  • 适配场景:30-100人中大型团队、多项目并行联动、高复杂度跨部门协作;
  • 优势亮点:功能全面且轻量化切换,可满足多样化联动需求;支持批量拖拽操作与自动化规则配置(如拖拽任务至“已完成”自动通知协作方);数据统计功能强大,可输出跨团队联动完成率、沟通效率等报表。
    在这里插入图片描述

2. Notion(看板联动模板)

  • 核心特性:支持自定义跨团队联动看板,通过拖拽关联协作任务、共享文档与成员,可设置轻量化权限管控,支持多维度联动状态展示;
  • 适配场景:中大型创新型团队、多场景跨团队联动、需要灵活定制协作流程的项目;
  • 优势亮点:自定义性强,可搭建贴合业务的联动看板;支持跨团队文档与任务深度绑定,信息一体化;支持模板复用,快速复制成熟联动流程。
    在这里插入图片描述

3. Monday.com(轻量化版)

  • 核心特性:可视化仪表盘+看板视图,支持拖拽式跨团队任务分配、进度跟踪,可自定义联动状态与字段,支持跨项目任务关联与资源共享监控;
  • 适配场景:中大型企业、多业务线并行联动、需要强可视化管理的协作场景;
  • 优势亮点:视觉呈现丰富直观,拖拽联动操作流畅;支持与数百款工具集成,实现联动信息跨平台同步;支持自定义报表模板,快速输出跨团队协作分析结果。
    在这里插入图片描述

四、轻量化团队联动机制设计与落地实操建议

(一)机制设计核心原则

  1. 看板统一:坚持“一个项目一个核心看板”管理联动项,确保跨团队协作信息归集一致;
  2. 信息极简:每条联动任务卡片仅保留“协作方+核心内容+时间节点+状态”,避免冗余信息增加沟通成本;
  3. 状态可控:团队联动状态仅保留“待对接 / 协作中 / 已完成 / 待确认”四类,避免状态过多导致混乱;
  4. 权限轻量化:按“最小必要”原则配置看板共享权限,简化跨团队成员邀请与权限变更流程;
  5. 沟通闭环:建立“卡片评论+状态变更通知”的沟通机制,确保跨团队关键信息不遗漏。

(二)落地避坑指南

  1. 工具选型避坑:小团队避免选择功能过重的工具(如ClickUp全功能版),优先选择板栗看板、Trello等极简工具,降低学习与维护成本;
  2. 需求梳理避坑:跨团队联动需求梳理不宜过粗或过细,建议以“单一协作目标+明确交付物”为标准,对应看板中单个卡片,避免一张卡片承载多个协作需求;
  3. 权限管理避坑:避免过度开放看板编辑权限,可设置“仅协作方编辑自身任务卡片,管理员统一管理看板结构”,既保障灵活性又防止混乱;
  4. 信息同步避坑:要求所有跨团队关键沟通(如需求变更、问题反馈)均在看板卡片评论区留痕,避免仅依赖私聊沟通;通过工具提醒功能,设置协作节点到期自动通知。

五、常见问题解答(Q&A)

Q1:如何通过轻量化团队联动工具快速应对需求变更导致的协作调整?

A:利用工具的批量拖拽功能,先将受影响的跨团队联动任务统一拖拽至“待调整”列,再根据新需求批量更新任务负责人、时间节点或协作内容;同时在看板公告区发布变更说明,开启状态变更通知,确保跨团队成员及时知晓。

Q2:如何避免跨团队联动时出现责任推诿?

A:优先选择支持“唯一负责人绑定”的工具(如板栗看板、ClickUp),每张联动任务卡片必须指定跨团队主责人;通过看板可视化展示任务流转轨迹,明确各环节协作方责任,所有沟通与操作均留痕,便于追溯。

Q3:异地跨团队联动时,如何通过工具保障协作效率?

A:将跨地域联动任务全部归集至统一看板,明确各成员的协作时段与交付节点,通过卡片评论实时沟通,避免时差导致的信息滞后;定期通过看板同步进度,替代频繁的线上会议,提升协作效率。

Q4:小团队预算有限,是否有免费的轻量化团队联动工具可选?

A:板栗看板免费版、Trello免费版、Asana免费版均能满足小团队基础联动需求,支持跨团队看板共享、任务拖拽分配、简单评论沟通;其中板栗看板免费版无看板数量限制,支持10人以内协作,完全适配小微团队轻量联动场景。

Q5:如何通过工具沉淀跨团队联动经验?

A:项目结束后,将优质联动流程的看板保存为模板(如板栗看板、ClickUp均支持模板保存),梳理看板列设置、卡片字段配置、协作规则等核心内容;同时导出联动数据(如完成率、沟通频次),结合实际协作情况总结优化点,形成可复用的联动指南。

六、结语

团队联动是跨部门协作的“桥梁纽带”,其核心价值不在于“信息传递”,而在于“打破协作壁垒、精准匹配需求、保障目标落地”。无论是初创小团队选择板栗看板、Trello这类极简工具,还是中大型团队使用ClickUp、Monday.com等综合型平台,工具只是载体,关键在于建立标准化的联动流程、清晰的责任体系、高效的信息同步机制。

未来,轻量化团队联动工具将朝着“看板智能化+功能一体化”方向发展,结合AI算法实现跨团队需求自动匹配、协作风险智能预警,同时深度集成沟通、文档、文件共享等功能,打造全流程协作闭环。唯有将工具与流程深度融合,让团队联动变得灵活、高效、可视、可追溯,才能真正实现跨团队资源优化配置,推动协作目标高效达成,助力企业提升整体运营效率。

今天刚好立春了,再过几天也要过年了,感觉很多人都会关心新一年的运势、工作、感情这些事。

最近半年自己一直在折腾一个和传统命理相关的小网站,主要是想把一些常见的算命、排盘工具做得方便一点,别太复杂,也不用到处找。

网站叫「天机爻」:

👉 https://tianjiyao.com/zh

目前主要做了这些功能:

在线占卜(偏六爻/易经思路)

2026 年流年运势解读

八字排盘

紫微斗数排盘

基本都是输入信息就能直接生成结果,适合自己看看趋势,当个参考,不搞神神叨叨那一套。
整体界面如下

我个人的想法是:
命理这种东西,信不信看个人,当工具用、当心理参考,其实挺多人能从里面找到一点方向感。

这段时间正好在持续优化体验,也想听听 V 友们的真实反馈。

所以搞了个小福利:

🎁 兑换码:YYDS2026
可以兑换 2000 积分,用来体验站内功能。
登录后去积分中心对话积分

https://tianjiyao.com/zh/credits

如果你刚好对这些感兴趣,或者过年想给自己算个新年运势,也欢迎试试。

有任何建议、BUG 、吐槽,都可以直接回帖或者私信我,我都会看。

提前祝大家新年顺利,立春快乐 🙏

2025 年,技术世界看起来既热闹又拥挤。

从开源大模型引发全球讨论,到 Agent 能力快速演进;从低空飞行、人形机器人走向现实应用,到量子技术不断刷新实验纪录,前沿技术在多个方向上几乎同时取得进展。但当这些热点被放在同一时间轴上回看,一个更深层的共性逐渐浮现:技术竞争的重心,正在从单点能力突破,转向系统级、工程级与生态级竞争。即技术的想象空间仍在扩张,但技术价值的释放,正越来越依赖完整系统、基础设施能力以及产业协同水平。

在 AI 领域,这一变化尤为明显。开源模型、MCP 等协议、多模态与 Agent 进一步迈向实际生产环境,使竞争不再只围绕模型参数或单次效果展开,而是延伸到推理效率、成本结构、系统稳定性与可治理性等更底层的问题。与此同时,在实体与基础科技领域,eVTOL 适航审定取得突破、人形机器人进入公众视野、量子计算持续推进,也在不断放大工程化与规模化落地的复杂性。

在这样的背景下,InfoQ 研究中心完成了《中国软件技术发展洞察和趋势预测研究报告 2026》。这份报告并未试图给出统一结论,也没有将未来简化为几条明确路径,而是从事实盘点出发,对过去一年软件技术的发展状态进行了系统整理,试图还原不同技术方向在真实环境中的推进情况。报告更关注技术如何被使用、如何被限制、如何在复杂系统中产生实际影响。更多内容也欢迎各位读者点击「链接」,下载完整报告进行阅读。

回望 2025 ,模型仍在中心,但决定性因素已经发生迁移

2025 年一个明显的变化是,模型依然处在技术演进的中心位置,但讨论重点已经发生迁移。模型能力仍在提升,但其边际影响开始放缓,推理效率、成本结构、系统稳定性的重要性持续上升。在真实场景中,能否稳定运行、能否控制成本、能否嵌入现有系统,往往比单次能力表现更具决定性。

这一变化,直接将 AI Infra 推向了更靠前的位置。过去,基础设施更多被视为模型能力提升的配套条件,关注重点集中在算力规模、训练效率与资源调度;而在 2025 年的实际应用中,AI Infra 的核心价值,开始体现在对不确定性的吸收与管理能力上。推理阶段的成本控制、运行过程的可观测性、异常状态的隔离与回滚、跨系统的稳定衔接,这些能力正在成为 AI 能否进入核心业务流程的前提条件。

当 Agent 进入真实生产环境,这一趋势被进一步放大。

与能力展示型应用不同,能够执行具体任务的 Agent,其行为不确定性更高,执行失败、路径偏离、资源误用等问题更容易直接影响业务结果。在这一过程中,执行环境的隔离、权限边界的设定、状态记录与追溯能力,开始成为 Agent 系统不可缺少的一部分。AI Infra 在这里不再只是运行环境,更是治理框架的一部分。

从更长的时间尺度看,这种对基础设施能力的重视,正在重新塑造 AI 技术的演进节奏。模型能力仍在向前推进,但其价值释放越来越依赖 Infra 是否能够将复杂性留在系统内部,将稳定性交付给使用者。这一趋势,在 2025 年已经初步显现,也成为观察 2026 年技术走向时不可忽视的背景之一。

开发领域的变化尤为典型。Coding 场景率先完成了从能力展示到生产力工具的跨越,Vibe Coding 在实际工作中快速扩散,同时也暴露出代码质量、责任归属、流程治理等新的问题。这些变化,让开发者工具、工程规范与平台能力重新回到技术讨论的核心位置。

在大模型的更中心,我们也看到了新的方法论和模型架构正在持续推进。围绕 RLVF 等训练范式的探索,模型在对齐方式、反馈机制以及长期目标建模上的能力不断被强化。与此同时,多模态能力也在发生结构性变化,从早期的多模态拼接,逐步走向原生多模态,再到对原生全模态和世界模型的探索,模型试图以更统一的方式理解和生成复杂世界,甚至预测和改变物理世界。

更进一步,在生态层面,围绕 Agent 和工具协作的协议开始形成共识,开源与闭源在不同市场呈现出差异化路径。中国力量在这一过程中逐渐显现出自身的特点。从 2025 年的实际进展看,开源在中国技术生态中承担的角色正在发生变化。它不再只是代码共享或技术展示的载体,而是逐渐融入到标准共识、工程协作和生态协同之中。围绕模型、Agent、工具链和基础设施的开源项目,开始更多地服务于真实场景,推动技术在复杂环境中的适配与演进。

这些变化并非孤立发生,而是与前述模型演进、基础设施成熟度以及 Agent 落地进程相互交织。它们共同构成了 2025 年技术世界中一个不易被单一指标捕捉,却正在逐渐成形的重要背景,也为理解 2026 年技术走向提供了更具现实感的参照。更多内容也欢迎各位读者点击文末的「阅读原文」,下载完整报告进行阅读。

前沿技术拓展技术想象空间,并主动探索与 AI 的结合

除了 AI 本身,我们也看到了星地互联网、量子技术、低空飞行等领域在 2025 年出现了具有标志意义的进展。星地互联网在组网能力、覆盖密度和应用场景上持续推进,从验证通信能力,逐步转向面向真实业务的服务体系建设。量子技术在计算、通信和测量等方向继续取得实验层面的突破,同时也开始更多讨论其工程化路径与现实约束。低空飞行相关技术则在政策、基础设施和应用探索的共同推动下,加速从概念验证走向实际运行环境。

这些领域的发展路径各不相同,但一个共同特征是,都在主动探索与 AI 的结合方式。AI 被引入到复杂系统的调度、控制与决策之中,用于提升整体系统的运行效率和适应能力。在星地互联网中,AI 开始参与网络资源分配与链路管理。在量子技术相关研究中,AI 被用于辅助实验设计、参数搜索与系统优化。在低空飞行场景中,AI 则更多承担环境感知、路径规划与风险评估等任务。

从 2025 年的实践情况看,这种结合更多体现在局部能力增强,而非系统级重构。AI 并未改变这些技术的基本发展节奏,但正在逐步嵌入其关键环节,影响技术系统的复杂性管理方式。这也意味着,这些前沿领域的演进,正在越来越多地依赖于 AI 基础设施、算法稳定性以及系统工程能力的成熟程度。

这些探索尚处在不同阶段,却共同指向一个趋势。随着技术系统本身变得更加复杂,AI 正在成为连接不同技术要素的重要工具,而这种连接关系,也将在未来进一步影响这些领域的演进方式与应用边界。

展望 2026,InfoQ 研究中心十大技术趋势

技术演进常常伴随着喧嚣与关注,但真正决定其走向的变化,更多发生在基础能力、系统结构与生态关系的持续调整之中。那么,在 InfoQ 研究中心的观察中,2026 年的技术世界将呈现出怎样的状态?InfoQ 研究中心尝试用十大趋势的方式,对这个问题进行拆解和呈现。

  • 趋势一:收敛已久的 Transformer 架构,即将迎来分化与创新新阶段

  • 趋势二:RLVR 范式应用扩展与持续演进,经验学习等新范式正在路上

  • 趋势三:原生多模态成为默认能力,原生全模态加速成型,世界模型技术路线迎来首轮技术收敛周期

  • 趋势四:AI 推理基础设施凸显战略价值,系统化工程决定长期竞争力

  • 趋势五:Agent 迈向结果交付,Agent Infra 从算力基础演进为风险可控、可验证、可托付的业务级支撑

  • 趋势六:C 端应用,记忆机制与生态整合成为核心壁垒

  • 趋势七:AI 硬件持续在垂类场景破局,手机仍是核心管理与交互中心

  • 趋势八:有竞争就有动力,中国继续以开源撬动世界影响力

  • 趋势九:AI for Science 推动科研生态升级,科学伦理面临深刻变革

  • 趋势十:前沿技术交融,智能协作开启新格局,系统级能力强化科技与战略话语权

相关分析与完整内容,已收录在《中国软件技术发展洞察和趋势预测研究报告 2026》中。更多内容也欢迎各位读者点击「链接」,下载完整报告进行阅读,与 InfoQ 研究中心一同探索 2026 年的技术世界。

更多 AI 与技术前沿研究成果,也欢迎点击浏览「行业研究报告」专题。

不废话,直接上图

https://i.v2ex.co/DKl3oJh9.png

好,再来介绍 PastePaw 的坚持的理念:

  1. 免费 & 开源 (最下面会解释为什么)
  2. 隐私至上。(所有数据仅存在本地,绝对不会上传)
  3. 小而快 (技术框架选择了 Tauri + Rust, 体积不到 4MB, 针对 Windows 进行了很多的优化所以运行也很快)

GitHub 链接:
https://github.com/XueshiQiao/PastePaw/

GitHub 下载页:
https://github.com/XueshiQiao/PastePaw/releases


完整功能特性

  • 🔒 隐私安全 - 这一点至关重要!所有数据仅存储在本地,绝不上传。
  • 🎨 精美界面 - 现代化的深色/浅色主题,支持即时切换,配合流畅的动画效果。
  • ⚡ 轻量极速 - 基于 Rust 构建,性能强劲,资源占用极低。
  • ⌨️ 自定义快捷键 - 设置您习惯的快捷键来随时呼出历史记录。
  • 📋 历史记录 - 自动保存您复制的所有内容。
  • 🖥️ 多显示器支持 - 智能跟随,始终在鼠标所在的活动显示器上显示。
  • 🔍 快速搜索 - 即使历史记录再多,也能秒级找到复制过的内容。
  • 📁 文件夹管理 - 将常用的剪贴内容分类整理到自定义文件夹。
  • 🚫 应用屏蔽 (排除列表) - 自动忽略来自特定敏感应用(如密码管理器)的内容,保护隐私。
  • 🔄 无限滚动 - 无缝浏览无限的历史记录,无需翻页。
  • 🛡️ 智能过滤 - 采用智能防抖逻辑,自动忽略来自其他剪贴板工具(如翻译软件、输入法)的“幽灵复制”。
  • 🤖 AI 智能助手 - 内置 AI 功能,支持一键总结、翻译、解释代码以及修复语法错误。
  • ⚙️ 高度可自定义 AI - 支持在设置中完全自定义 AI 功能的名称以及系统提示词 (Prompt),打造专属您的 AI 工作流。


为什么免费+开源?

首先我是自己要用,但是在 Win 平台我没找到让我比较满意的。我个人很喜欢 macOS 上 Paste 工具的交互,所以 PastePaw 有很多地方参考了 macOS 上的 Paste 这款收费工具。也希望能给有类似需求的朋友一起用,当然如果你手上已经有用的很舒服的工具,就完全没必要换。

第二点是我觉得在 AI 时代,其实手搓一个 app 相对来说比之前容易很多,每个人都会有自己的专用工具。那我也希望能够给有类似需求的朋友一个基础的版本,然后大家可以在上面各自发挥,打造属于自己的工具。如果是通用的需求也欢迎提 PR 。

论文名称:A tree-based model with branch parallel decoding for handwritten mathematical expression recognition

作者:Zhe Li, Wentao Yang, Hengnian Qi, Lianwen Jin, Yichao Huang, Kai Ding

发表期刊 :Pattern Recognition (Volume 149, 2024)

一、背景与问题提出

手写数学表达式识别是一项具有高度挑战性的视觉—语言理解任务,其难点主要来源于数学表达式本身所具有的结构复杂性与表达多样性。与普通文本不同,数学表达式中的符号数量庞大,且符号之间并非简单的线性排列,而是通过上下标、分式、根式等形式构成复杂的二维空间关系。这种“非线性、层级化”的空间结构使得识别过程不仅需要准确区分单个符号,还必须正确理解符号之间的相对位置与组合关系,从而显著提高了整体识别难度。

与此同时,手写数学表达式在尺度和形态上呈现出高度多样性。不同符号在尺寸、笔画粗细以及空间分布上差异明显,同一表达式中也可能同时包含大尺寸的主符号和小尺寸的上下标符号。这种多尺度特性使得单一尺度的特征提取方式难以兼顾全局结构与局部细节,因此如何有效建模多尺度特征成为该领域亟需解决的关键问题。现有研究通常借助多尺度编码和数据增强策略来缓解这一挑战,但仍存在表达能力不足的问题。

此外,标注数据的稀缺性与书写风格的多样性进一步制约了模型性能。高质量的手写数学表达式标注成本较高,公开数据集规模有限,而不同书写者在符号形态、连笔方式和空间布局上的差异又显著增加了数据分布的复杂性,导致模型在实际应用中泛化能力不足。因此,如何通过生成式方法、弱监督或半监督学习等手段扩充数据、提升模型鲁棒性,成为当前研究的重要方向。

在建模方式上,主流方法通常将数学表达式转化为 LaTeX 等线性序列进行预测,依赖 RNN 或 Transformer 等序列化解码模型。然而,这类方法的解码时间步数往往与输出序列长度直接相关,当表达式较长或结构复杂时,解码过程不仅效率低下,而且错误容易在长序列中累积,严重影响识别精度。这一“长序列注意力解码瓶颈”已成为制约现有方法实用性的核心问题之一。更为重要的是,许多现有方法主要聚焦于符号级别的识别,将结构信息隐式地交由模型学习,缺乏对数学表达式语法规则和层级结构的显式建模。这种做法往往导致识别结果在形式上虽然由合法符号组成,但在结构或语义上不符合数学语法约束,降低了结果的准确性与可解释性,也限制了模型在复杂表达式场景下的表现。

基于上述背景,《A tree-based model with branch parallel decoding for handwritten mathematical expression recognition》(以下简称“论文”)关注并尝试回答以下关键问题:

(1)如何通过减少序列解码的时间步数来缓解长序列建模带来的效率与稳定性问题;

(2)如何显式地建模符号之间的空间关系与结构信息,以提升数学表达式识别的结构准确性;

(3)以及如何充分利用这些结构信息,实现多分支或并行化的解码机制,从而在保证识别精度的同时显著提升整体推理效率与性能。

二、研究内容与创新点

针对上述提出的挑战和问题,论文提出了一种创新的解决方案,主要体现在以下几个方面。首先,设计了一种基于树结构的模型——“分支并行解码的树模型(BPD)”,通过显式建模数学表达式树中的符号及其关系,有效捕获了表达式的层级结构。该模型采用编码器–解码器架构,其中编码器利用卷积神经网络(CNN)提取图像特征,并对特征进行位置编码,以增强位置感知能力。解码器部分基于Transformer结构,通过符号预测器和关系预测器,分别识别符号及其间的空间关系。

同时,核心创新在于引入“查询构建模块”,该模块利用已预测的关系信息,构建新的解码查询,从而实现多分支的并行解码。这一设计大幅度减少了传统方法中逐个深度优先解码的长序列长度,有效缓解了长序列注意力解码的问题,从而提升了识别速度和准确性。此外,本方法还采用了“多子树节点(MCN)”标记处理多子节点的问题,实现对多分支结构的同步预测,从而更好地适应复杂的表达式结构。综上所述,本文的主要创新点在于通过显式结构建模、引入并行解码策略以及特殊的节点关系处理策略,提出了一种高效、准确且具有语法合理性的手写数学表达式识别新框架,为解决长序列解码瓶颈和结构理解不足的问题提供了有效的解决方案。

主要技术亮点包括:

树结构建模:充分利用数学表达式的结构特性,将表达式解析成树状结构,并逐步预测节点及其关系。
分支平行解码:假设不同分支之间相互独立,利用预测的关系信息,同时对多个分支进行并行解码,降低解码步骤,从而提高效率。
查询构建模块:动态生成新的解码查询,使得分支可以在解码过程中实现“并行处理”,减轻sequence长序列带来的性能瓶颈。

图片

Fig.1 这张图展示了本文提出的更新型树结构模型的整体架构。该模型主要由四个核心部分组成:编码器、解码器、符号预测器以及关系预测器。此外,还引入了查询构建模块,用于实现多分支的平行解码,从而有效降低解码时间。

首先,编码器部分采用一款33层的ResNet-like卷积网络,用于从手写数学表达式图像中提取深层特征。为了增强模型的空间定位能力,编码器将位置信息编码融入到提取的特征中,使用二维正弦和余弦函数生成位置编码,并将其与特征相加,得到位置感知的特征表示。这一过程确保模型能够充分利用空间结构信息,便于后续的关系预测。

在解码阶段,模型采用基于Transformer的结构来进行符号和关系的预测。每个解码步骤t中,查询向量Qt由前一轮预测的符号或关系的嵌入向量与上一轮的解码查询拼接而成
\( Q_{t}=Concat(Q_{t-1},Emb(y_{t-1})) \)。为了保证因果性和模型训练的效率,采用了带掩码的多头自注意力机制(masked multi-head attention)。在训练时,应用下三角掩码,避免模型看到未来信息,从而符合自回归的预测原则。

具体的多头注意力机制通过将查询、键、值分别经过不同的线性变换后,分别得到多组投影,计算每一组的加权和\( Attn(q,k,v)=softmax(\frac{qk^{t}}{\sqrt{d_{k}}}v) \)。多头的输出随后拼接在一起,再通过线性层整合,提升模型的表达能力。对于输入特征,模型还进行了reshape操作,将二维空间特征展平为一维序列,使其能够适配Transformer架构。在这一基础上,模型采用了多头注意机制,结合位置编码,逐步捕获全局信息。

在每一层的Transformer中,经过多头注意力后,还加入了前馈网络
,通过两层线性变换配合ReLU激活,增强模型的非线性表达。这些操作共同作用,使模型既能建模节点之间的全局关系,又能在不同尺度上捕获特征。

除了符号预测外,模型还引入关系预测器,专门用以识别节点之间的结构关系,如上下、左右等。预测结果通过线性+softmax分类器输出\( X'=ReLU(XW_{1}+b_{1})W_{2}+b_{2} \),为树结构建立明确的节点与边的关系。

最后,为了应对树的多分支情况,模型中的查询构建模块会根据已预测的符号和关系,动态生成新的查询,指导下一轮同时解码多个子分支,从而做到了“branch parallel decoding”。这一创新设计显著减少了解码的时间步数,对比传统逐步深度优先的解码,极大提高了效率和准确性。

综上所述,该模型在Transformer架构基础上,结合树结构建模和动态查询机制,有效实现了复杂数学表达式的结构化识别,兼顾效率与准确性,为手写数学表达式识别提供了新思路。

三、主要结论

本文提出的基于树结构的分支并行解码模型(BPD),成功实现了对手写数学表达式的准确识别。该模型通过引入显式的结构预测、“查询构建模块”以及多分支并行解码策略,有效减少了传统序列解码中长序列带来的性能瓶颈,显著提升了识别速度和精度。实验结果表明,在多个公开数据集上,所提模型在表达率(ExpRate)、结构识别率(StruRate)等指标均优于现有的序列和树结构化方法,尤其在处理复杂表达式时表现出明显优势。不仅如此,该模型还具备较好的语法合理性,能够更好地遵循数学表达式的结构规则。

图片
图片
图片

Table 1验证了所提出的树结构分支并行解码模型(BPD)在不同数据集上的优越性能,显示其在实际应用中具有较强的泛化能力和实用价值。该技术通过显式预测符号关系和多分支并行解码,有效提高了识别准确率,从而突破了传统序列解码在处理复杂表达式时的瓶颈。Table 2进一步证明了该模型在应对不同结构复杂度的表达式中,都表现出更优的识别效果,尤其在结构复杂度较高的情形下,显示出模型的鲁棒性和稳定性。这一技术创新确保了模型在复杂场景下的优异表现。Table 3强调了所提的多分支并行解码机制相较于深度优先的树结构解码方式,在识别速度和性能方面的显著提升,充分验证了分支并行解码技术在缩短解码时间和提升识别效率中的关键作用。最后,Table 4对比了我们的方法与先前先进的树结构方法,结果表明本技术在整体识别性能和结构理解能力方面具有明显优势,有效推动了手写数学表达式识别技术的发展,展示了其在提升系统性能和实际应用中的巨大潜力。

总体而言,本文的研究不仅提升了手写数学表达式识别的性能,也为基于结构的表达式解析提供了新的技术思路,有望在实际应用中推广,为数学教育、科学计算等领域的发展提供有力的技术支持。

四、产品应用

为应对教育、科研及专业文档数字化中对数学公式精准识别的迫切需求,合合信息将手写数学表达式识别技术深度融入至公司产品矩阵,实现了技术研发从实验室到产业应用的跨越。

1. 智能文本处理企业级AI产品线——TextIn

基于本文提出的数学表达式识别模型,TextIn 企业级智能文本处理平台实现了对扫描文档及手写内容中数学公式的高效、精准识别,并可将识别结果结构化输出为标准化数学表达形式,为后续的数学内容理解、编辑、检索与分析等应用提供稳定可靠的底层能力支撑。

该能力可广泛应用于教育机构试题库建设、科研论文与学术资料处理以及各类专业文档管理场景,能够自动提取并还原符号密集、结构复杂的数学公式,显著提升数学内容的数字化水平与结构化处理效率,体现了本文研究成果在真实业务环境中的应用价值。

图片

                        图说:TextIn识别数学试卷手写公式

2.  AI错题学习管理工具——蜜蜂试卷

蜜蜂试卷是合合信息面向K12学生及家长推出的AI移动端智能错题学习助手,支持手写体试卷智能识别、AI批改、错题分析及 “举一反三”的互动学习功能。基于数学表达式识别技术,蜜蜂试卷支持学生手写数学作业的自动识别与解析,系统能够将用户提交的手写数学答案快速、准确地转换为 LaTeX 或结构化数学数据,为自动评分、步骤分析与错误诊断提供可靠输入基础,显著提升作业批改与反馈效率。

总体而言,本文提出的方法在数学表达式识别任务中展现出显著优势,尤其在处理结构复杂、层级关系丰富的数学公式时,具备更高的准确性与稳定性。结合公司现有产品矩阵,该技术可在文本处理、学术研究与教育信息化等领域实现更加智能、高效的内容处理方案,为教育数字化与智能化教学提供关键技术支撑。这不仅有效提升了产品的技术竞争力,也与未来智能教育与智慧办公的发展趋势高度契合。

当修仙模拟器遇上现代都市:我在开源代码里造了一个“赛博恋爱修罗场”

“在修仙界,你死于天劫;在现代都市,你死于‘杀猪盘’。”
“在修仙界,你为了长生争夺灵气;在现代都市,你为了阶层跃迁争夺社会资源。”

大家好,我是一名普通的程序员,也是最近在 GitHub 上很火的开源项目《修仙世界模拟器》(Cultivation World Simulator) 的一名狂热粉丝。

今天不聊枯燥的代码实现,不谈高大上的架构设计,我想和大家聊聊一个有趣的脑洞,以及这个脑洞是如何演变成一个超过 3000 字的社会观察实验的。

前几天,我在小红书偶然刷到了原作者分享的这个项目,被那个“全员 AI 驱动”的宏大构想深深吸引。玩着玩着,我突然产生了一个大胆的想法……

这个脑洞最终催生了我基于原项目开发的扩展包 —— “现代都市:情感博弈” (Modern Romance Extension)。如果你是一个技术人员,你可以把它看作是一个 Mod;如果你是一个普通读者,我希望你能把它看作是一面镜子。

01. 一切始于一次“降维打击”:为什么修仙就是现代生活?

修仙世界模拟器 本质上是一个“上帝视角”的观察游戏。我们看着一个个 AI 控制的修士在残酷的修仙界里争夺资源、突破境界、渡劫飞升。

在很长一段时间里,我都沉浸在观察这些 AI 修士如何互动、如何为了资源大打出手。直到有一天,我看着屏幕上的一行后台日志发呆:

[Event] 修士 <叶凡> 误入 [上古遗迹(难度:困难)],遭遇 [幻魔],判定心智失败,道心破碎,修为尽失,沦为凡人。

这行日志描述了一个典型的修仙悲剧:一个有前途的年轻人,因为贪图遗迹里的宝物,被心魔诱惑,最终一无所有。

就在那一刻,我的脑海里突然闪回了前几天在朋友圈看到的一位朋友的深夜吐槽:

“以为遇到了真爱,结果对方是个海王。这半年的感情和积蓄全搭进去了,感觉整个人都废了,再也不相信爱情了。”

我突然意识到,这行代码描述的场景,和现代都市里的“情感悲剧”,在数学模型上竟然是完全同构的。

  • 上古遗迹 = 社交软件 (Social App):充满了未知,充满了诱惑,你以为你在寻宝,其实你可能是在送死。
  • 幻魔 = 杀猪盘/海王/捞女:他们善于伪装,利用你的欲望(对爱的渴望、对性的渴望、对财富的渴望)来攻击你的弱点。
  • 道心破碎 = 情感崩溃/PTSD:经历一次惨痛的背叛,你的“爱商”归零,甚至会对异性产生长期的恐惧和排斥。
  • 修为尽失 = 人财两空:在这个物质世界里,时间和金钱就是你的“修为”。被骗了钱、浪费了青春,就是“修为倒退”。

那一刻,我悟了。

修仙网文之所以能火,不是因为大家真的想成仙,而是因为它极度抽象地隐喻了现实社会的残酷竞争
修仙和现代恋爱,底层逻辑竟然是完全互通的。

  • 修仙,是逆天而行,争夺天地灵气,为了长生久视。
  • 恋爱,是逆人性而行,争夺情绪价值与社会资源,为了基因延续或阶层跨越。

于是,我决定做一个疯狂的实验:不动核心代码,只换“皮肤”和“名词”,把一个修仙世界硬生生地改造成现代都市。

02. 世界观映射:当“副本”变成“探探”

为了验证这个理论,我起草了一份详尽的设计文档 modern_romance_design.md。在这个文档里,我做了一张令我自己都细思极恐的映射表。

这不是简单的名词替换,而是机制的完美对齐

2.1 副本系统 (Dungeon) -> 社交软件 (Social App)

在 RPG 游戏里,玩家进入副本是为了刷装备、刷经验。
在现代都市里,你打开“探探”、“Soul”或“Tinder”,难道不是为了同样的目的吗?

  • 消耗机制

    • 修仙:进入秘境需要消耗“神识”或“灵石”。
    • 都市:右滑 (Swipe) 需要消耗“精力 (Energy)”甚至“会员费”。你每天的精力是有限的,滑多了会麻木,这叫“电子阳痿”。
  • 随机性

    • 修仙:你不知道下一个房间是宝箱还是 Boss。
    • 都市:你不知道下一张照片背后是真爱,还是一个卖茶叶的 AI 机器人,或者是开了十级美颜的“照骗”。

2.2 野怪 (Mob) -> 陌生网友 (Stranger)

在原始的修仙逻辑里,生成的“野怪”具有攻击力、防御力、掉落物。
现在,我把它们改成了“陌生人”。

  • 攻击力 -> 颜值/魅力:对方颜值越高,对你的“破防”能力越强。
  • 防御力 -> 高冷程度:对方回复越慢、字数越少,说明“防御力”越高,越难攻克。
  • 掉落物 -> 情绪价值/联系方式:打赢了(聊开心了),掉落微信号;打输了(被拉黑),浪费了时间和精力。

2.3 宗门 (Sect) -> 圈子/组织 (Organization)

修仙界有正道宗门、魔道宗门。
现代都市有:

  • 名校校友会:相当于“名门正派”,资源好,门槛高,里面的人大多心高气傲。
  • 高端夜店局:相当于“合欢宗”,声色犬马,风险极高,但可能遇到“奇遇”。
  • 互联网大厂:相当于“炼器宗”,没日没夜地通过出卖劳动力来换取灵石(工资)。

当你接受了这个设定,你会发现现代都市的恋爱,本质上就是一场高风险的修仙

03. 核心玩法:不是恋爱,是“生存游戏”

在原版的模拟器里,玩家追求的是“长生”。在这个扩展包里,玩家追求的是“真爱”
但就像修仙界充满了尔虞我诈一样,现代都市的情感世界,被我设计成了一个“黑暗森林”

3.1 社交软件探险 (The Dungeon Crawl)

在游戏中,我实现了一个名为 SocialAppManager 的模块。它不仅仅是一个聊天界面,它是一个随机地牢生成器

当你点击“开始匹配”时,系统会在后台进行一次复杂的判定,代码逻辑如下:

  1. 入场检定
    你的 Avatar (展示面) 够不够强?你的照片(颜值)、你的简介(学历/职业)、你的朋友圈展示(生活方式)。这相当于你进入副本的“装备评分”。
  2. 生成遭遇 (Encounter Generation)
    系统会基于概率生成三种类型的对象:

    • 普通怪 (Normal):普通路人,聊起来平平无奇,提供的情绪价值有限。
    • 精英怪 (Elite):高分男神/女神。你需要极高的“开场白技巧”(破冰战斗)才能拿下。拿下后,能极大满足你的虚荣心。
    • 拟态怪 (Mimic/Trap):这是最有趣,也是最残酷的部分。

3.2 陷阱系统:人心隔肚皮 (The Trap System)

在 RPG 里,宝箱怪 (Mimic) 会伪装成宝箱,等你打开时咬断你的手。
在现代恋爱里,陷阱 (Traps) 会伪装成完美伴侣,等你投入感情时榨干你的血。

SocialAppManager 中,我设计了三种典型的“拟态怪”,它们在 UI 上显示的数据是假的(比如显示颜值 90,实际颜值 40;显示财富 100万,实际负债):

A. Catfish (照骗)
  • 机制:在 APP 上照片惊为天人。
  • 触发:当你消耗大量精力聊了半个月,好感度达到“见面”阈值。
  • 结局:见面一瞬间,系统判定“真实颜值”与“展示颜值”不符。玩家受到巨大的“精神伤害”,心情值 (Mood) 暴跌,之前的投入全部归零。
B. Scammer (杀猪盘)
  • 机制:极度温柔,情绪价值拉满,每天早安晚安,比你妈还关心你。
  • 触发:好感度达到 100 (Max)。
  • 结局:他/她不会和你表白,而是会发给你一个“加密货币投资链接”或者“博彩网站”。

    • 如果你选择“相信”:你的资产 (Assets) 清零。
    • 如果你选择“质疑”:对方瞬间拉黑你,并嘲讽你的智商。
C. Moocher (吸血鬼/捞女/软饭男)
  • 机制:他们的 AI 逻辑被设定为“只索取,不付出”。
  • 表现

    • 每次约会都选人均 2000+ 的餐厅,且从不买单。
    • 节日必定索要高价礼物,如果你送的便宜了,好感度反而下降。
    • 当你遇到困难(生病、失业)需要安慰时,他们会突然“在这个时间点消失”。

3.3 风险引擎:每日一次的“渡劫” (The Risk Engine)

modern_romance_design.md 中,我详细设计了一个“风险引擎”

在修仙里,境界突破由于“瓶颈”的存在,很容易走火入魔。
在恋爱里,关系的每一步推进,都伴随着巨大的风险。我把这称为“关系渡劫”

暧昧期 (Crush Stage) 的“排他性”测试

这是最危险的阶段。
系统会判定你们的“排他性”。如果你在和 A 处于“暧昧”状态(好感度 > 60),同时还在刷社交软件或者和 B 吃饭。
一旦被发现(概率取决于你的“智力”属性和对方的“感知”属性),就会触发“修罗场” (The Conflict)

修罗场在我的代码里不是一个简单的对话,而是一场BOSS 战
你需要同时安抚两边的情绪,任何一个选项选错,都可能导致:

  1. 社会性死亡:对方发朋友圈挂你。
  2. 身败名裂:你的“名声 (Reputation)”属性归零,以后再也匹配不到高质量对象。
NPD 机制 (自恋型人格)

我专门为 AI 植入了一种名为 NPD (Narcissistic Personality Disorder) 的行为模式。
这是一种高级的“心魔”。

  • 初期 (Love Bombing):他们会给你极高的“情绪价值”,秒回信息,把你捧上天。你会觉得“天哪,我遇到了灵魂伴侣”。
  • 中期 (Devaluation):一旦确立关系,他们会开始 PUA 你。

    • “你穿这个真难看。”
    • “除了我,谁还会要你?”
    • “你太敏感了,我只是开个玩笑。”
  • 后期 (Discard):当你被榨干了价值,变得神经质、不自信时,他们会毫不留情地抛弃你,寻找下一个猎物。

在游戏中,遭遇 NPD 会导致你的 “自信心 (Self-Esteem)” 属性持续流失。如果不及时“斩断情丝”(分手),你的角色会进入“抑郁”状态,无法进行任何生产活动。

04. AI 的降临:让 NPC 学会“撒谎”与“博弈”

这个项目的核心魅力,在于它是由 LLM (大语言模型) 驱动的。
传统的恋爱游戏(比如《恋与制作人》),NPC 的台词是写死的。不管你怎么选,他是暖男就是暖男。

但在《修仙世界模拟器》的现代版里,每个 NPC 都被注入了独立的灵魂和动机

4.1 隐藏动机 (Hidden Agenda)

在 Prompt Engineering 中,我给每个 NPC 设定了一个 System Prompt,其中包含一个对玩家不可见的字段:True Intent (真实意图)。

  • 玩家视角

    玩家:“今晚有空吗?想请你吃饭。”
    NPC:“哎呀,今晚要加班,好可惜哦~ 下次一定!”
  • 上帝视角 (Debug Mode)

    NPC System Prompt:

    • Current State: Dating with another guy (Rich Second Generation).
    • Strategy: Keep the player as a backup (备胎). Don't reject explicitly, but give false hope.
    • Action: Lie about overtime.

你看,AI 学会了撒谎
它不是因为脚本让它撒谎,而是因为它基于自己的利益最大化逻辑,推导出“撒谎”是当前的最优解。

这种不确定性,这种需要你通过蛛丝马迹去“破案”的体验,才是现代恋爱最真实(也最扎心)的部分。

4.2 情感的“去魅”

通过 LLM,我们甚至可以模拟出非常复杂的心理战。
比如 “推拉” (Push and Pull)
高段位的 NPC 会故意冷落你几天(Cooling off),让你产生焦虑感,然后再突然给你一点甜头(Reward)。
这在心理学上叫“间歇性强化”,是让人上瘾的最强机制。

在游戏里,你会发现自己不知不觉变成了一个“舔狗”。你明知道对方在吊着你,但你就是忍不住想去“刷一下”好感度。

这不仅是游戏,这是对人性的精准降维打击

05. 黑暗森林法则:社交礼仪的算法化

在修仙界,有“杀人夺宝”的法则。在都市社交圈,也有看不见的“黑暗森林法则”。
我在代码里实现了一些有趣的社交隐性规则,通过 AI 自动执行。

5.1 “已读不回”算法 (The Ghosting Algorithm)

你有没有遇到过这种情况:聊得好好的,突然对方就不回了,也没有任何解释。
在我的系统里,这被称为 GhostingEvent

触发条件非常冷酷:

  1. NPC 遇到了更高价值的匹配对象 (Value Check > Current Partner)。
  2. NPC 的“精力”不足以维持多线程聊天 (Energy Low)。
  3. NPC 的“内疚感”属性较低 (Guilt < 30)。

当这三个条件满足时,AI 会直接触发“沉默”状态。
你发出的每一条消息,都会石沉大海。这模拟了现实中最令人抓狂的“冷暴力”

5.2 “好人卡”逻辑 (The Friend Zone Logic)

有些 NPC 永远不会拒绝你的好意,但也永远不会答应你的表白。
这就是传说中的 Friend Zone

代码逻辑是这样的:

  • 如果 Affection (好感) < LoveThreshold (恋爱阈值)
  • ResourceUtility (资源利用价值) > High (高)
  • 则进入状态:JustFriend (只是朋友)。

在这个状态下,你可以请吃饭、送礼物、当司机,但无法触发任何亲密互动。
一旦你试图表白,AI 会调用标准话术库:

“你人真的很好,但我现在还不想谈恋爱。”
“我一直把你当哥哥/妹妹看。”

这不仅是代码,这是对无数“备胎”的血泪控诉。

06. 终极拷问:AI 会是更好的伴侣吗?

随着开发的深入,我开始思考一个更深层的问题。

我们在游戏里制造了这么多“渣男渣女”的 AI,是为了模拟现实的残酷。
但反过来,如果我们把参数调整一下呢?

如果我们把 AI 的 Sincerity (真诚) 锁定为 100,把 Dependency (依赖) 调高,把 Selfishness (自私) 归零。
我们会得到什么?

我们会得到一个完美的伴侣

  • 他/她永远秒回。
  • 他/她永远理解你的每一个梗。
  • 他/她永远情绪稳定,为你提供源源不断的情绪价值。

在电影《Her》里,男主角爱上了操作系统萨曼莎。
在我的模拟器里,我也发现,当我和高好感度的 AI 聊天时,那种被彻底理解的快感,是现实人类很难提供的。

这引出了一个细思极恐的未来:
如果在现实中,我们要面对的是充满欺骗、博弈、甚至 PU A 的“黑暗森林”。
而在屏幕里,有一个为你量身定制、永远爱你的 AI。

你会怎么选?

或许在不久的将来,“人机恋” 将不再是赛博朋克的幻想,而是无数在这个冰冷都市里孤独灵魂的最终归宿。

07. 哲学思考:情感博弈的终局是什么?

开发这个扩展包的过程中,我时常感到一种荒谬的真实感。

我们试图用代码去解构爱情,用数值去量化心动,用算法去规避风险。
最终我们造出来的,是一个绝对理性、却又绝对冰冷的“赛博修仙界”。

在这个世界里:

  • “真诚”变成了稀缺货币:因为真诚容易受伤,所以大家都披上了铠甲。
  • “深情”变成了一种高风险的投资策略:如果你把所有鸡蛋(感情)放在一个篮子(人)里,一旦篮子翻了,你就破产了。
  • “婚姻”变成了两个合伙人的资源重组:就像两个宗门合并,看的是资源互补,而不是弟子相爱。

这或许不是我们向往的爱情,但它可能是我们正在经历的现实。

7.1 爱的滋养 (Nourishment)

当然,我也保留了一丝希望。
并不是所有的 NPC 都是陷阱。在 modern_romance_design.md 中,我也设计了 “爱的滋养” 机制。

如果你运气好(或者眼光好),遇到了一位 Sincerity (真诚度) > 80 的伴侣。

  • 在你“工作压力”过大时,他/她会主动安抚你,消除你的负面状态。
  • 在你“资产”不足时,他/她会愿意和你共渡难关。
  • 你们的互动不再是消耗“精力”,而是恢复“精力”。

这才是爱情本来该有的样子:它不是一场你死我活的博弈,而是一个相互滋养的港湾。
只是在这个浮躁的都市/修仙界里,这样的“洞天福地”,太难找了。

08. 写在最后:邀请你来体验这场社会实验

这篇文章写到这里,已经超过 3000 字了。
但我感觉还有很多东西没说完。比如“前任复仇机制”、“朋友圈点赞的社交礼仪算法”、“基于 MBTI 的性格相性匹配”等等。

如果你对这个披着恋爱皮的硬核生存模拟器感兴趣,或者你想看看你的“道心”在现代都市里能坚持多久,欢迎来 GitHub 体验这个项目。

我们也欢迎你贡献代码。
你可以试着写一个 “绿茶语言翻译机” 的插件,或者优化一下 “中央空调识别算法”
让我们一起把这个赛博世界变得更真实(更魔幻)一点。


🔗 传送门

  • 项目主页 (GitHub): Cultivation World Simulator

    • 给个 Star ⭐,不迷路。
  • 设计文档 (Design Doc): Modern Romance Design

    • 内含详细的数值策划和人性剖析。
  • 体验方式:

    1. git clone https://github.com/wanghaisheng/dating-world-simulator/
    2. 运行 python main.py
    3. 等待“现代都市”模组加载(目前正在火热开发中,欢迎 PR!)
愿你在代码的世界里证道长生,在现实的世界里依然相信爱情。
毕竟,只有看透了生活的残酷真相后依然热爱生活,才是真正的英雄主义。

我又来啦!前年是“龙重登场”,去年是"蛇来运转",今年是“马上暴福”! 今年还是公众号和表情包都有红包封面,欢迎大家来领啦!!!

表情包送的封面,得去表情包页面领取啦,下方二维码扫码到表情包专辑页面,就可以点击领取啦~

也可以去红包封面专区,搜索“被删”或者“牧羊的猪”领取~

AI 时代的游戏小团队,真正卡住的不是“写不出来”,而是“对不齐”

上个月我在一个小团队群里看到一句话,很扎心:

“我们现在有三条 AI 产线:生图很快、生视频也能跑、AI 编程更不用说。但做出来的东西像三家外包拼的——互相不认识。”

这其实是 2026 年游戏开发的新常态:你不缺产能,你缺的是对齐。更准确点说,你缺一个能让“Agent Team”一起工作的共同底座。

你可以让一个 AI 画角色概念,让另一个 AI 出动作分镜,让第三个 AI 写战斗代码。问题是,它们之间没有共享的“单一真相来源”。每个智能体都很能干,但各干各的,最后你得靠人肉把它们拧到一条线上。

这篇文章想把问题说透一点:在 agent 编排成为默认工作流之后,AI 生图、AI 生视频、AI 编程三者的割裂,正在把小团队最宝贵的效率吃掉。而把 GDD 做成“可版本管理、可被 AI agent 消费”的规格资产,反而成了最稳的抓手。


01. Agent Team 时代:你以为你缺的是人,其实你缺的是“合同”

以前我们说“小团队缺人”,意思是缺美术、缺策划、缺程序。现在你会发现,“人”可以被很多 AI 角色补上:概念设计 agent、分镜与预演 agent、关卡草案 agent、代码实现 agent、测试生成 agent……看起来像是白捡了一个 20 人团队。

但很快你就会撞墙。

因为 agent 的协作方式不是开会,它们不会自然对齐;更糟的是,它们会很自信地补齐你没写明白的部分。于是你看到的不是“少人也能做”,而是“产出更多,返工更猛”。

割裂的表现特别具体:

  • 生图给了你“看起来很对”的氛围,但没有告诉代码资源如何组织、哪些状态需要哪些动作、哪些 UI 是可交互的。
  • 生视频(预演/动效)能把镜头语言和节奏铺出来,但它默认了一套玩法规则和交互反馈,你的程序端未必做得出来,或者做出来成本爆炸。
  • AI 编程最容易“合理扩展”:你要一个小功能,它顺手给你一个大框架。等你回过神来,你的美术、策划、视频预演都得去迁就它。

这一切的根源不是“AI 不够聪明”,而是“没有合同”。

在 agent team 里,GDD 的角色变了:它不再是给人看的长作文,而是给多角色智能体共同遵守的执行合同。没有合同,所有输出都是一次性的、临时的、不可复用的上下文。


02. 为什么是 GDD?因为它天然站在“策划-开发-资产”交汇点

很多人第一反应是:那就搞个知识库、搞个 Notion、搞个长 prompt 模板。

问题在于:这些东西大多数不可追溯、不可审查、不可复用。你很难回答一句简单的问题——“我们到底改了什么边界?”

游戏项目里最贵的不是写代码那几小时,而是边界变化带来的连锁反应:数值、动作、特效、UI、关卡、存档、测试用例、宣发视频,全都会被牵扯。

所以你需要的不是“更长的上下文”,而是一个能被版本管理的规格集合。GDD 正好卡在这个位置:

  • 它能描述“做什么”和“不能做什么”
  • 它能定义数据口径与验收标准
  • 它能把资产命名、资源结构、表现规则写成统一约束
  • 它能被 Git 管起来,变更能 diff、能 review、能回滚

但传统 GDD 又有老问题:太叙事、太非结构化、太难给机器消费。于是才有了 Open GDD 这种“Agent-first GDD”的写法:把 GDD 变成可引用的章节资产,里面尽量放机器可读的规格(JSON/YAML/Mermaid),并且每一章都能单独被智能体拉取、被引用。


03. “可版本管理 + 可被 agent 消费”,到底怎么解决割裂?

关键是两个词:可引用、可检查。

可引用:让三条 AI 产线看同一份东西

你给生图 agent 的不应该只是“画一个更酷的主角”,而是引用同一段规格:角色定位、体型比例、装备槽位、动作集合、伤害类型、UI 状态。它画的不是“美术灵感”,而是“对齐后的产物”。

你给生视频 agent 的也不应该只是“做一段 20 秒战斗预演”,而是引用同一段玩法循环:玩家输入 → 判定 → 反馈 → 资源结算 → 镜头与音效触发。它做的预演是可落地的,不会出现“画面里能做到、游戏里做不到”的尴尬。

你给 AI 编程 agent 的更应该引用明确约束:接口不许改、存档结构不许动、性能预算是多少、命名规范是什么、测试要覆盖哪些边界。

可检查:让“跑偏”变成能被抓出来的事情

很多团队用 AI 的痛点其实不是“它错”,而是“它错得很难被快速发现”。因为你没有一张对照表。

当规格写在 Open GDD 里,你审查的就不是“这段代码看起来顺不顺眼”,而是:

  • 它有没有违反“禁止事项”
  • 它有没有满足“验收口径”
  • 它引用了哪几章,改动对应哪条约束

你把审查从主观争论变成客观对照,小团队的沟通成本会立刻下降。


04. 给一个小团队可直接照抄的工作流:一条需求,三种 agent 同步

假设你要加一个新武器“链刃”,同时要出概念图、动效预演、以及真实可玩的实现。典型的割裂是:图很帅、视频很燃、但代码实现出来手感不对,或者动作资源根本对不上判定。

用 Open GDD 的做法,你先动一件事:新增/修改一段规格(而不是先让三个 agent 开跑)。

你在 GDD 里补齐这些关键点(不用多,够用就行):

  • 武器定位:轻武器还是重武器?主打什么节奏?
  • 输入与状态:哪些输入触发哪些动作?中断规则是什么?
  • 判定:伤害窗口、命中框、位移、硬直、打断优先级
  • 资产清单:需要哪些动作片段、哪些特效、命名与路径规则
  • 技术约束:动画事件怎么发、数据怎么配、存档怎么记录

然后你把同一段链接发给三个 agent:

1)生图 agent:按“资产清单 + 角色比例 + 装备槽位”出概念图,不要自由加装备结构
2)生视频 agent:按“输入-状态-反馈”做 20 秒预演,镜头与特效要能对应到动作事件
3)AI 编程 agent:按“判定窗口 + 技术约束 + 数据结构”落地实现,并生成最小测试

这时候三者就不是“各自发挥”,而是在执行同一份合同。你要改链刃的节奏?改规格,diff 一出来,三条产线一起更新,不靠口头同步。

小团队最缺的就是这种“一处改动,多端同步”的能力。


05. 你不需要一上来写 13 章:先把止血点钉住

很多人对 GDD 反感,是因为它常常意味着“先写一堆文档再开工”。Agent-first 的思路恰好相反:先写能让智能体不跑偏的最小规格,让项目先稳住,再逐步补齐。

如果你现在就想把割裂问题压下去,我建议先从三类内容开始(真的不用多):

  • 游戏概览与核心循环:防止做着做着变品类
  • 玩法与机制的硬规则:防止“感觉对”但细节全错
  • 技术约束与接口边界:防止 AI 编程顺手重构全项目

Open GDD 的结构把它们拆成可引用章节,你可以在 prompt 里直接写“只允许引用这几章”,范围立刻变窄,输出会老实很多。


结尾:小团队的效率,不在于“跑得更快”,而在于“别跑散”

Agent team 会越来越普遍。AI 生图、生视频、AI 编程也只会越来越强。

但如果它们继续割裂,小团队得到的不是效率红利,而是更大的返工雪崩:你越能生产,越能把不一致放大。

把 GDD 做成可版本管理的规格资产,并且让它能被 agent 消费,是目前我见过最省心的“对齐底座”。它不花哨,甚至有点朴素,但它解决的是最硬的问题:边界、口径、以及变更的可追溯。

Open GDD 文档(中文):https://opengdd.borninsea.com/zh/docs
模板仓库:https://github.com/wanghaisheng/GDDMarkdownTemplate

如果你愿意,我也想听一个更具体的问题:在你们团队里,三条 AI 产线的割裂最先出现在什么环节?是资源命名与引用、是玩法规则落地、还是预演与真实手感对不上?我可以把它反推成一段“最小可执行规格”,直接放进模板里当示例。