作为运维工程师，在多年的系统维护工作中保险行业的见得也不少。其中，理赔环节的反欺诈工作一直是技术对抗的前沿阵地。当遇到用户报案IP与事故地点不符，我们如何通过IP地址查询定位技术辅助调查。

传统的人工审核依赖纸质材料和主观判断，效率低下且容易漏检。而数字化报案系统虽然提升了效率，却也给欺诈分子提供了新的作案空间。我们团队常用IP数据云作为IP地址数据分析工具，其核心目标正是通过精准的IP地理位置定位和风险画像分析，帮助保险公司识别虚假报案、团伙作案等行为。

一、报案IP异常典型特征

1. 跨地域异常报案：事故发生在A地，但报案IP显示在B地，且两地距离遥远，不符合正常的交通逻辑

2. 网络隐匿伪装：欺诈分子使用网络隐匿服务隐藏真实位置，企图制造虚假的事故现场

3. 团伙作案特征：多个不同事故的报案来自同一IP地址或同一IP段，暗示可能存在有组织的欺诈团伙

4. 时间逻辑矛盾：报案时间与事故发生时间存在不合理的时间差，结合IP位置分析可发现矛盾

二、实操方案：构建基于IP地址的智能反欺诈系统

1. 实时IP验证与风险评分

在报案系统接入环节，实时调用IP数据云的API接口，对报案IP进行多维度的风险评估：

# 简化示例：报案时IP风险验证流程
def validate_claim_ip(ip_address, accident_location):
    # 获取IP详细信息
    ip_info = ipdatacloud.query(ip_address)
    
    # 基础验证：地理位置一致性
    if ip_info.location != accident_location:
        risk_score += 30
    
    # 代理/VPN检测
    if ip_info.is_proxy or ip_info.is_vpn:
        risk_score += 40
        
    # 风险标签分析
    if ip_info.risk_tags.contains('数据中心', '恶意历史'):
        risk_score += 30
        
    return risk_score, ip_info

2. 多维度关联分析

单纯的IP位置比对可能产生误报，需要结合其他维度进行综合分析：

• 设备指纹关联：同一设备在不同事故中出现的频率
• 行为模式分析：报案时间、操作习惯的异常模式
• 历史记录比对：该IP地址过往的报案记录和理赔结果
• 社交网络分析：报案人之间的关联关系网络

3. 动态规则引擎配置

根据不同类型的保险产品和风险等级，设置差异化的IP风险规则：

表：基于IP风险的差异化处理策略

4. 案例回溯与模型优化

建立案例库，定期分析成功识别的欺诈案件特征，持续优化IP风险评估模型。也就是说，当我们发现某些地区的特定IP段频繁出现问题，就可以将这些IP段加入高风险监控名单。

三、技术实施要点与挑战

在实际部署IP地址反欺诈系统时，需要特别注意以下几个技术要点：

数据质量保障：IP地理位置数据库的准确性和时效性直接决定风控效果，因此必须选用精度高、更新及时的数据源。

系统性能考量：理赔高峰期面临高并发查询，需确保IP查询服务满足毫秒级响应，以支持实时风控决策。

隐私合规要求：处理用户IP数据须严格遵守《个人信息保护法》等法规，确保合法、透明，并落实数据安全保护。

误报率控制：应通过A/B测试等方式持续优化风控规则与阈值，在防范风险与保障用户体验之间取得平衡。

结语

处理保险理赔反欺诈这类工作，很大程度上就是看谁的技术工具更趁手、更精准。报案IP与事故地点不符只是冰山一角，但其背后隐藏的风险却值得注意。通过IP数据云这样的专业工具，我们能够将看似简单的IP地址信息转化为风险情报，为保险公司的风险核查工作提供有力的数据支撑。

作为技术从业者，我深刻体会到，真正的风控不是简单的规则堆砌，而是对数据的深度理解和应用。IP地址作为用户在数字世界的"位置指纹"，其价值远超出传统的地理位置查询。

本文为 《深入理解 Apache DolphinScheduler：从调度原理到 DataOps 实战》 系列专栏第五篇，将以 Apache DolphinScheduler 为例，解析调度系统中的失败重试、手动重跑与补数回填机制，澄清调度语义中的 Exactly Once 含义，并总结常见误用场景与实践建议，帮助构建稳定可靠的数据调度体系。

在数据平台的日常运行中，任务失败几乎是不可避免的。网络抖动、资源不足、下游依赖异常、代码 Bug……都可能导致调度任务执行失败。面对失败，很多团队通常依赖 自动重试、手动重跑或补数回填 来恢复数据。

但一个经常被忽视的问题是：

调度系统中的失败重试、手动重跑与补数回填，其语义其实完全不同。

如果理解不清，很容易导致 重复数据、数据错位甚至数据污染。本文将结合 Apache DolphinScheduler 的设计机制，深入解析调度系统中最常见但也最容易被误解的三种能力：失败重试、手动重跑与补数回填，并进一步探讨 调度系统中 “Exactly Once” 的真实含义。

一、失败重试 vs 手动重跑：两种完全不同的恢复机制

在调度系统中，失败任务通常有两种恢复方式：

1. 自动重试（Retry）
2. 手动重跑（Rerun）

很多人认为两者只是触发方式不同，但实际上它们在 执行语义 上有本质差异。

1 自动重试：同一次实例的再次执行

在 Apache DolphinScheduler 中，每一次调度都会生成一个 Workflow Instance（流程实例），实例中包含多个 Task Instance（任务实例）。

当某个任务失败时，如果配置了 Retry Times，系统会在同一个任务实例下触发自动重试。

其特点是：

• 属于同一次工作流实例
• 保持相同的调度时间（Schedule Time）
• 依赖关系不会改变
• 仅重新执行失败任务

执行流程示意：

自动重试的设计目标是：

解决瞬时失败（Transient Failure）

例如：

• 网络波动
• 临时资源不足
• 外部系统短暂不可用

在这种情况下，自动重试通常可以快速恢复任务。

2 手动重跑：创建新的实例

与自动重试不同，手动重跑会生成新的实例。

在 Apache DolphinScheduler 中，用户可以选择：

• 重跑失败节点
• 从当前节点开始重跑
• 从头重跑整个流程

这时系统会生成一个新的 Workflow Instance。

示意：

这意味着，两个实例 可能处理同一时间的数据，下游任务 可能重复写入数据。

如果任务不是 幂等（Idempotent） 的，就可能导致 重复数据问题。

二、补数与回填：调度系统中的时间重建

在数据仓库场景中，补数（Backfill）是一项非常常见的操作。例如：

• 新建任务后需要补历史数据
• 某天任务失败，需要补跑
• 上游数据延迟，需要回填

在 Apache DolphinScheduler 中，补数通常通过 Backfill Run 实现。

1 补数的本质：生成多个历史实例

假设一个任务是 每日调度。

补数区间：

2025-03-01 → 2025-03-05

系统会创建多个实例：

Instance (2025-03-01)
Instance (2025-03-02)
Instance (2025-03-03)
Instance (2025-03-04)
Instance (2025-03-05)

每个实例都有：

• 独立执行状态
• 独立依赖关系
• 独立参数

调度时间会被设置为历史时间。

2 补数的关键：调度时间 vs 执行时间

在调度系统中，有两个非常重要的概念：

调度时间（Schedule Time）

数据逻辑时间

执行时间（Execution Time）

任务实际运行时间

例如：

Schedule Time : 2025-03-01
Execution Time: 2025-03-10

如果 SQL 使用的是：

WHERE dt = ${schedule_time}

补数是安全的。

但如果使用：

WHERE dt = today()

补数就会产生 错误数据。

这也是很多数据问题的根源。

三、调度系统中的 Exactly Once：真实含义是什么？

在流处理系统中，例如 Apache Flink，Exactly Once 通常意味着：

每条数据只被处理一次。

但在调度系统中，Exactly Once 的含义完全不同。

调度系统并不能保证任务不会被重复执行，也无法保证数据不会被重复写入。这是因为自动重试可能重复执行，手动重跑可能重复执行，以及补数会重复执行历史逻辑。

因此，调度系统中的 Exactly Once 更接近于：

同一个调度时间只生成一个逻辑实例。

但任务本身仍然可能执行多次。

因此真正的 Exactly Once 需要 任务逻辑保证幂等。

常见实现方式包括：

1 覆盖写入

INSERT OVERWRITE TABLE

2 基于分区写入

partition dt='${schedule_time}'

3 去重写入

MERGE INTO

四、常见误用场景

很多数据事故其实都来自于对调度语义的误解。

1 使用当前时间作为数据日期

错误示例：

dt = today()

正确方式：

dt = ${schedule_time}

2 非幂等写入

例如：

INSERT INTO table

如果任务重跑：

数据会重复

3 手动重跑整个流程

很多用户习惯：

失败 → 从头重跑

但实际上更安全的方式是：

只重跑失败节点

五、最佳实践建议

结合 Apache DolphinScheduler 的使用经验，可以总结出几个重要实践：

1 任务必须设计为幂等

所有任务都应该允许：

重复执行

不会影响数据正确性。

2 数据逻辑必须基于调度时间

避免使用：

now()
today()

统一使用：

${schedule_time}

3 合理使用重试策略

建议配置：

Retry Times: 1~3
Retry Interval: 1~5 min

避免无限重试。

4 补数要控制并发

补数区间过大时：

一次性生成大量实例

可能导致：

• 调度队列阻塞
• 集群资源耗尽

建议：

分批补数

结语

在数据平台中，调度系统往往被认为只是“任务触发器”。但实际上，它承担着 时间管理、依赖控制和故障恢复 的核心职责。

通过理解 失败重试、手动重跑与补数回填 的真实语义，我们才能真正构建 稳定、可靠的数据生产系统。

像 Apache DolphinScheduler 这样的现代调度系统，已经提供了非常完善的机制。但最终决定数据质量的，仍然是：

正确理解调度语义 + 设计幂等的数据任务。

只有这样，数据平台才能在面对失败时依然保持 可恢复、可追溯、可重建。

• 前文回顾：
  第 1 篇 | 调度系统，不只是一个“定时器”
  第 2 篇｜Apache DolphinScheduler 的核心抽象模型
  第 3 篇｜调度是如何“跑起来”的？
  第 4 篇｜状态机：调度系统真正的灵魂
• 下篇预告：
  第 6 篇｜Apache DolphinScheduler 多租户与资源隔离设计

万界星空科技--2026精密仪器行业AI+MES全景解决方案

针对精密仪器制造业，2026年的AI+MES（制造执行系统）解决方案已从单纯的“流程记录”进化为具备主动决策能力的“智能工厂大脑”。精密仪器行业具有多品种小批量、高精度要求、工艺复杂、追溯性极强等特点，因此其解决方案核心在于利用AI解决质量波动、设备微停机及排程柔性问题。

一、基础核心功能模块：这是万界星空MES系统的骨架，确保生产流程的规范化、透明化和可追溯性。
1、生产计划与排程管理 (APS Lite)
工单管理：支持从ERP自动同步或手动创建生产工单，支持拆单、合并、暂停、急单插单。
有限产能排程：基于设备实际负荷、人员技能矩阵、物料齐套情况，生成日/班次作业计划。
可视化甘特图：拖拽式调整排程，实时查看设备占用情况和订单进度。
缺料预警：根据BOM和当前库存，提前预测未来24-72小时的物料缺口。
2、工艺管理与执行 (Process Execution)
电子SOP (e-SOP)：工位屏幕自动推送当前产品的作业指导书、图纸、视频，版本自动管控，防止误用旧版。
防错机制 (Poka-Yoke)：通过扫码枪/RFID强制校验物料批次、工装夹具型号、设备参数，错误则锁定设备无法启动。
参数下发：将标准工艺参数（如扭矩、温度、压力、测试电压）直接下发至PLC或智能仪表，减少人工设置误差。
首件检验管理：强制执行首件三检（自检、互检、专检），合格后方可批量生产。
3、质量管理 (QMS Integrated)
全过程质检：支持IQC（来料）、IPQC（制程）、FQC（终检）、OQC（出货）的全流程数据录入。
SPC统计过程控制：自动生成X-bar R图等控制图，实时监控关键质量特性（CTQ），超差自动报警。
不合格品管理 (NC)：记录不良现象、代码、原因，触发返工、报废或特采流程，形成闭环。
校准管理：针对精密仪器特有的量具、测试设备，管理校准周期，过期自动锁定禁止使用。
4、设备与工装管理 (Equipment & Tooling)
设备台账与履历：记录设备全生命周期信息（采购、维修、保养、改造）。
状态监控：实时采集设备运行状态（运行、待机、故障、停机），计算OEE（设备综合效率）。
保养计划：自动生成日点检、周保养、月维护任务，支持移动端扫码执行并拍照上传。
工装/模具寿命管理：记录冲次或使用时长，达到寿命阈值自动提示更换或保养。
5、仓储与物流管理 (WMS Lite)
线边库管理：实时监控产线旁物料消耗，触发拉动式补货（Kanban）。
批次/序列号追踪：建立“一物一码”，记录每个精密仪器从原材料到成品的完整血缘关系。
AGV调度接口：与AGV系统对接，实现物料自动配送至指定工位。
先进先出 (FIFO)：系统强制管控物料出库顺序，防止呆滞料。
6、人员绩效管理
技能矩阵：管理员工的上岗资质、培训记录，系统自动匹配工位所需技能。
工时采集：自动记录员工在各工位的作业时间、等待时间、加班时间。
计件/绩效统计：实时统计个人/班组产量、良率，作为绩效考核依据。
7、报表与看板 (BI Dashboard)
车间大屏：实时展示产量、良率、设备状态、异常报警等关键指标。
多维报表：自动生成日报、周报、月报，支持按产品、工序、班组、时间段钻取分析。
追溯报告：一键生成单台仪器的全流程质量档案（含人、机、料、法、环数据），支持导出PDF。
二、AI增强功能模块：利用大数据和机器学习解决传统MES无法处理的复杂问题。
1、AI智能视觉质检
微缺陷识别：利用深度学习算法，识别微米级划痕、异色、装配间隙等肉眼难辨的缺陷。
自适应阈值：系统根据历史良品/不良品数据，自动调整检测灵敏度，减少误判和漏判。
缺陷分类自学习：随着数据积累，自动优化缺陷分类模型，无需频繁重新训练。
2、AI工艺参数自优化
黄金参数推荐：分析历史最佳生产批次的数据，结合当前环境（温湿度）和物料批次差异，实时推荐最优设备参数设定值。
动态补偿：在加工过程中，根据实时监测到的偏差趋势，自动微调设备参数（如激光功率、进给速度），将误差控制在公差中心。
3、AI预测性维护
故障预判：采集设备振动、电流、温度、声纹等多维数据，利用时序预测模型，提前数天甚至数周预警主轴磨损、轴承失效等隐患。
根因分析：当故障发生时，AI自动关联当时的工艺参数、操作记录和物料信息，快速定位根本原因。
备件需求预测：根据设备健康度预测，自动生成备件采购建议，避免紧急缺货。
4、AI智能高级排程
多目标优化：同时考虑交付期、换线成本、设备负载均衡、能耗等多个目标，利用强化学习算法秒级生成全局最优排程。
动态重排：当发生急单插入、设备突发故障、物料延迟时，系统在几分钟内自动重新计算并调整后续所有计划，评估对交付的影响。
瓶颈预测：提前识别未来一周的生产瓶颈工序，建议提前备料或调整班次。
5、自然语言交互助手
语音/文字查询：管理人员可通过手机或电脑输入“昨天A产线的良率为什么下降？”，系统自动调取数据并生成分析报告。
异常自动推送：当检测到重大异常时，AI助手自动通过微信/钉钉推送告警，并附带初步的原因分析和处理建议。
三、系统架构与技术要求 (2026标准)
云边端协同：

端：工业平板、PDA、传感器、智能仪表。
边：边缘计算网关，负责高频数据采集、实时AI推理（如视觉检测）、协议转换。
云/私有服务器：负责大数据存储、复杂模型训练、全局排程、多工厂协同。

低代码开发平台：

提供拖拉拽式的表单设计器、流程引擎、报表设计器，让业务人员能快速响应工艺变更。

开放API生态：

提供标准的RESTful API、WebSocket接口，无缝集成ERP (SAP/Oracle/金蝶/用友)、PLM、WMS、SRM及各类自动化设备。

高安全性与合规性：

符合ISO 27001信息安全标准。
内置FDA 21 CFR Part 11（电子签名、审计追踪）模块，满足医疗仪器合规要求。
数据加密传输与存储，细粒度的权限控制。

四、实施路线图：对于精密仪器企业，建议分三步走：
**第一阶段（基础数字化，3-6个月）：上线基础核心模块（计划、执行、质量、设备、追溯），实现无纸化，打通数据孤岛，确保数据准确。
第二阶段（互联互通与可视化，6-12个月）：深度集成设备自动化，实现SCADA/MES互联，完善BI看板，引入SPC进行质量管控。
第三阶段（智能化升级，12个月+）：部署AI模块（预测性维护、智能排程、视觉质检、工艺优化），构建数字孪生，实现从“描述性分析”到“指导性/预测性分析”的跨越。**

这套方案既保证了当下的管理落地，又为未来的智能化演进预留了充足的空间，项目合作可以私信。

点赞 + 关注 + 收藏 = 学会了

💡整理了一个 NAS 专属玩法专栏，感兴趣的工友可以戳这里关注 👉 《NAS邪修》

Redink（红墨） 是一个专门为小红书玩家打造的图片生成工具。

你只需要输入一个主题，它就能帮你生成爆款大纲、正文润色，甚至连配图都一并搞定。

其实部署红墨不难，难的是如何找到稳定且免费的“大模型脑子”。

我在绿联 NAS 部署 Redink，用其他品牌的工友也可以跟着操作，步骤差不多的。

打开「文件管理」，找到 docker 文件夹，在里面创建一个 redink 文件夹。

然后在 redink 里创建2个文件夹：output 和 history

打开「Docker」应用，切换到 项目，创建一个新项目。

• 项目名称：reding
• 存放路径：/docker/redink

Compose配置如下：

services:
  redink:
    image: histonemax/redink:latest
    container_name: redink
    ports:
      - 8010:12398
    volumes:
      - ./output:/app/output
      - ./history:/app/history
    restart: always

8010 这个端口可以自定义。

项目构建成功后，在浏览器输入 NAS_IP:8010 就可以使用 Redink 了。

红墨只是一个“外壳”，要让它干活，要在“系统设置”这里配置 文本生成配置 和 图片生成配置。

文本生成配置 我薅的是 LongCat 羊毛（https://longcat.chat/platform），这是美团的，不需要魔法也能用，写本文时 LongCat 每天能免费刷新5500万 token 给我用。

图片生成配置 我薅的是 Pollinations.AI 的羊毛（https://pollinations.ai/），但这个要魔法，我还做了层转发，比较麻烦。

如果舍得花💰的话可以去买其他平台的服务，想用 Nano Banana 但又没有魔法的可以去买中转站的服务，比如：

• https://www.ohmygpt.com/i/V1DXSDZA
• https://linoapi.com.cn/register?aff=KzYJ

大模型的服务配置完成后，回到首页就可以让 Redink 开始干活了。

比如我输入的提示词是：推荐在NAS部署Redink

它首先会调用文本生成的模型，生成一堆大纲。

如果你觉得大纲没问题，点击右上角“开始生成图片”这个红色按钮，就开始生成小红书封面图了。

生成的图片质量取决于你所使用的模型。

正如开头所说，部署和使用 Redink 是没啥难度的，难的是找免费的大模型服务😭

如果你有免费模型推荐，欢迎在评论区分享一下💗

以上就是本文的全部内容啦，你有好玩的镜像推荐吗？欢迎在评论区留言讨论！

想了解更多NAS玩法记得关注《NAS邪修》👏

往期推荐：

• 『NAS』PS平替！群晖部署Photopea
• 『NAS』XMind平替，群晖部署思维导图工具
• 『NAS』群晖部署OmniTools，一款图片视频PDF编辑神器

点赞 + 关注 + 收藏 = 学会了

企业在成都做网站托管，到底能获得哪些实际好处?作为西南地区的数字枢纽，成都的IDC服务这几年越来越成熟，不少本地和外地企业都愿意把网站和业务系统放在成都的机房。那具体来说，成都的IDC服务商是怎么帮企业解决网站稳定性、访问速度和数据安全这些核心问题的?

服务器托管在成都，对企业竞争力提升其实挺直接的。一方面，成都作为全国骨干网节点之一，BGP多线接入能力强，无论用户是从华南、华北还是西南访问，延迟都相对较低;另一方面，本地IDC服务商——比如极云科技——提供的机柜环境和电力保障都比较到位，2N市电+UPS+柴油发电机的冗余配置，让服务器几乎不会因供电问题掉线。网站打开快了、稳定了，用户体验自然上去，转化率也会跟着提高。

那在成都选网站托管服务商，为什么要看极云科技?首先我们在成都自建了Tier III+级别的数据中心，网络架构全冗余，带宽资源充足，能应对突发流量;其次从硬件到系统都有完善的安全防护，包括DDoS高防、Web应用防火墙和定期漏洞扫描，数据安全这块不用企业操心;另外我们的运维团队都经过严格培训，响应速度快，小问题在线解决，大问题15分钟上架处理。

如果不想自购服务器，成都地区的服务器租用也是个高性价比选择。极云科技提供多种配置的云服务器和物理服务器租用，CPU、内存、硬盘和带宽都可以按需调整，企业不需要一次性投入大量硬件成本，也能快速上线业务系统。尤其对中小企业和初创团队来说，这种模式既控制了前期开支，又保证了服务品质。

说到底，网站托管不是光找个地方放服务器那么简单，它关系到企业在线业务的连续性和用户体验。成都作为西南地区的数字经济发展重心，IDC基础设施和服务能力已经相当成熟。极云科技在这边深耕多年，从托管租用到安全加速，都能提供符合企业实际需要的解决方案。

如果你正在成都或周边地区寻找靠谱的网站托管与服务器租用服务，欢迎来极云科技看看。我们有专业的团队和扎实的基础设施，帮你把服务器环境部署稳、维护好，让你的网站真正成为业务增长的平台。

编者按： 在大模型技术狂飙突进的今天，市面上层出不穷的 AI 产品，究竟有多少是真正跑通了商业闭环的“硬通货”，又有多少只是包装精美的“伪需求”？

我们今天为大家带来的文章，作者给出了一个犀利而冷静的判断：在喧嚣的 AI 热潮背后，目前真正行之有效的大语言模型产品仅有 Chatbots、智能补全产品和智能体这三类。

文章深入剖析了这三种产品形态的生存逻辑与潜在困境：作者指出，Chatbots 虽然受众最广，但面临着“与模型本体竞争”的尴尬局面，且聊天界面在特定场景下的交互效率远逊于传统 UI；智能补全产品（如 GitHub Copilot）则通过“无感嵌入”工作流获得了成功，证明了不改变用户习惯才是最佳的赋能方式；而作为新秀的智能体，正在编码等领域通过自主规划与执行展现出巨大的潜力。此外，作者还前瞻性地探讨了 AI 生成的信息流与 AI 游戏作为未来形态的可能性，并犀利地指出了当前行业大量资源仍耗在同质化竞争中的现状。

作者 | Sean Goedecke

编译 | 岳扬

首款基于大语言模型的产品 ChatGPT，其功能只不过是^1（译者注：文中出现的数字，为注释上标，文末可看到对应的注释内容，后同）与模型本身进行对话：换句话说，就是一个纯粹的 chatbot。时至今日，它仍然是最受欢迎的大语言模型产品，且遥遥领先。

事实上，考虑到该行业已投入的资金规模，有一点令人非常震惊，竟有如此多“新 AI 产品”只不过是 chatbot 而已。据我所知，目前真正可行的 AI 产品仅有三类。

01 Chatbots

在 AI 热潮兴起的最初那几年，所有大语言模型产品本质上都是 chatbots。它们虽然被贴上了五花八门的标签，也许这个 LLM 能读取你的邮件，那个能处理公司的客服文档，但核心功能始终没变：用自然语言跟模型聊上天。

chatbots 的困境在于：最好的 chatbots 产品，其实就是模型本体。 用户想跟 LLM 对话，绝大多数需求都是通用的：问个问题、求点建议、倾诉心事，或者干点其他一百种跟你这个具体产品毫无关系的事。

换句话说，你的用户转头就会去用 ChatGPT^2。AI 实验室相比你有两个决定性优势：第一，他们总能比你更早用上最前沿的模型；第二，他们能在训练模型的同时，同步打磨配套的聊天框架（比如 Anthropic 会专门针对 Claude Code 的使用场景来微调模型，OpenAI 也会为 Codex 做类似的适配）。

1.1 露骨的、成人向的角色扮演

你的 chatbots 产品要想胜过 ChatGPT，有一条路：去做 OpenAI 不愿碰的事 —— 比如扮演 AI 男友，或者生成成人内容。目前这类产品已经形成了一个利润可观的小众市场，它们通常依赖能力稍弱但限制更少的开源模型。

这类产品当然也存在我前面说过的那些问题。但关键在于：当你的需求就是露骨的、成人向的 AI 角色扮演，而 ChatGPT 和 Claude 又坚决不碰这块时，它们能力弱一点也无妨 —— 你能用上，就已经够了。

我个人认为，这类产品存在严重的伦理争议。但即便抛开道德层面，单从商业角度来看，随着大型 AI 实验室在成人内容边界问题上越来越“放得开”，这个细分领域也很可能被它们逐步蚕食。Grok Companions[1] 已经在朝这个方向探索，而 Sam Altman 也公开表示[2]，未来 OpenAI 的模型会对生成成人内容持更开放的态度。

1.2 带工具的 Chatbots

chatbots 还有一个变体：给模型配备上“工具”。这样一来，你就不只是能和日历闲聊，还能让 chatbots 帮你安排会议等等。这类产品通常被称作“AI 助手”。

但这类产品往往效果不佳，因为精明的用户总能想办法“诱导” chatbots 调用工具。 所以你永远不敢给客服 chatbots 真正的客服操作权限，比如“给客户退款” —— 一旦你这么做了，成千上万的人立刻会摸索出越狱话术，让机器人乖乖给他们打钱。最终，你只能给 chatbots 配备那些用户自己也能完成的操作，可这样一来，你的 chatbots 其实是在跟你自家产品的原生体验竞争，而且大概率会输。

为什么你的 chatbots 会输？因为聊天本身就不是个好用的交互界面。当用户只需按下“Ctrl+加号”或点一下按钮3就能放大字体时，他们真的懒得敲一句“嘿，能帮我把字体调大点吗”。

我觉得这对工程师来说是个挺难接受的教训。我们很容易产生一种错觉：既然 chatbots 的能力提升了 100 倍，那它在很多任务上应该已经是最佳的交互方式了吧？可惜事实是，它们在一开始比传统用户界面差了 200 倍，所以即便进步神速，现在依然还是差劲一倍。

02 智能补全产品

第二款真正意义上的 AI 产品其实比 ChatGPT 问世还早：GitHub Copilot。最初，Copilot 产品（以及所有模仿者，比如 Cursor Tab）的核心理念是：使用一个快速的 LLM 充当智能自动补全工具。通过将用户实时输入的代码喂给模型，代码编辑器可以给出自动补全建议，甚至直接帮用户写完剩余的函数（或文件）。

这类产品的高明之处在于，用户根本无需与模型对话。 正如我前面所说，以纯文本对话为核心交互方式的产品界面并不是个好用的用户界面。由 LLM 生成的补全内容让用户无需改变现有工作流的任何环节，就能享受到 AI 模型的能力：他们看到的只是编辑器原本就会提供的自动补全建议，只不过强大得多。

令我有点惊讶的是，基于补全的产品在编程领域之外并没有火起来（在编程领域，它们可是一下子就创造了一个价值数十亿美元的市场）。Google Docs 和 Microsoft Word[3] 都有类似的功能。为什么这东西没引起更多轰动？

• 也许答案是，使用这类产品的人并不活跃于 AI 在线社区，只是默默在使用产品？
• 也许是普通的专业内容写作有什么特性，导致它不如代码适合自动补全？但我对此表示怀疑，因为那么多普通的专业内容写作，本来就是直接从 ChatGPT 窗口复制粘贴的。
• 也可能是因为代码编辑器本来就有自动补全功能，用户对此已经很熟悉了。我敢打赌，对许多 Word 用户来说，自动补全完全是个非常新鲜且令人困惑的东西。

03 智能体

第三款真正意义上的 AI 产品是编码智能体（coding agent）。这个概念大家已经讨论了好几年，但直到 2025 年，支撑编码智能体的技术才真正变得可行（得益于 Claude Sonnet 3.7，以及后来的 GPT-5-Codex）。

智能体在交互形式上有点像 chatbots —— 用户同样通过输入自然语言与之沟通。但关键区别在于：你只需下达一次指令，模型就会带着你的初始需求“离开”，自主完成需求实现、测试等全套流程。

智能体能跑通，而“带工具的 chatbots”却屡屡受挫，核心区别在于：前者是让 LLM 自主规划并执行一整套复杂操作，后者只是让它帮你点一个按钮。 虽然单独的操作对人类来说更容易执行，但如今的智能体 LLM 已经足够聪明，能够接管整个流程。

编码智能体之所以能成为 AI 智能体的理想应用场景，有两个原因：

• 通过运行测试或检查代码能否编译，可以很方便地验证修改结果
• AI 实验室有强烈动机打造高效的编码模型，以加速自身研发进程

在我看来，当下这个价值数十亿美元的问题是：AI 智能体能否在编程以外的任务中发挥作用？别忘了，Claude Sonnet 3.74 发布至今还不到九个月。在这段时间里，科技行业已经成功围绕“自己领域内的工作”构建出了智能体产品。而面向其他任务的智能体产品，才刚刚起步。它们最终能否成功、又会以什么形态出现，仍有待观察。

3.1 研究智能体（research agent）

还有一类智能体不涉及编码：研究智能体（research agent）。LLM 特别擅长处理这类任务，比如“快速浏览十页搜索结果”，或者“在海量数据集中使用关键词检索某一主题的相关信息”。我自己就经常用这个功能处理各种事情。

目前已有一些基于此能力打造的 AI 产品，比如 Perplexity[4]。在大型 AI 实验室内部，这类功能往往被整合进了 chatbots 产品线：例如 OpenAI 的“深度研究”（deep research）就从独立功能，演变成了 GPT-5-Thinking 自动执行的操作。

我认为，在特定垂直领域（比如医疗或法律）打造专属的研究智能体，几乎肯定存在潜力。

04 信息流

如果说智能体是最近成功的 AI 产品，那么 AI 生成的信息流可能就是即将问世的那一个。各大 AI 实验室目前正在尝试为用户打造无限滚动、高度个性化的内容流：

• Mark Zuckerberg 曾谈及用自动生成内容填满 Instagram
• OpenAI 最近推出了基于 Sora 的视频生成信息流
• OpenAI 还开始引导用户使用“Pulse” —— 一种 ChatGPT 产品内的个性化每日内容摘要
• xAI 正致力[5]于在 Twitter 中植入无限图片和视频信息流

虽然现在这些 AI 信息流产品还没做成，但因为大家本来就爱刷手机，所以这条路只要走通了，前景就很大。在我看来，五年后大多数互联网用户每天花大量时间刷 AI 生成的信息流，这完全是有可能的。

与基于智能补全的产品类似，信息流的优势在于用户无需与 chatbots 交互。模型的输入来自用户与信息流的互动方式（点赞、滚动速度、在某条内容上停留的时间等）。用户无需改变任何消费习惯，就能体验使用 LLM 生成信息流的好处（如果有的话）。

支撑当前人类创作型无限信息流背后的技术，本身就是前沿机器学习的成熟应用。当你刷 Twitter 或 LinkedIn 时，你其实已经在和一个模型交互 —— 只不过它生成的不是文本，而是生成包含他人帖子的列表。换句话说，现有信息流系统已经能精准构建你个人偏好的高维嵌入（embedding）。从“用该嵌入表征推荐相关内容”到“用该嵌入表征生成相关内容”，这一步可能非常短。

我对 AI 生成的无限视频信息流持相当怀疑的态度，但我确实认为其他类型的无限信息流是一种未被充分探索的产品形态。 事实上，我自己就做了一个基于信息流的业余项目，叫做 Autodeck[6]5。其理念是用 AI 生成的信息流来制作间隔重复卡片用于学习。效果相当不错！至今仍有不少用户通过我的博客找到它并持续使用（当然，还有我和我伴侣自己也在用）。

05 游戏

另一种被讨论了多年的 AI 生成（AI-generated）产品形态，是基于 AI 的视频游戏。这方面最大胆的尝试是构建完整的世界仿真系统，比如 DeepMind 的 Genie[7]；但也有人探索用 AI 生成游戏的局部内容，例如纯文本冒险游戏 AI Dungeon[8]，或者这个为《上古卷轴》添加 AI 生成对话（AI-generated dialogue）的模组[9]。更多游戏开发者则选择将 AI 生成的美术或音频素材融入自己的作品中。

有没有可能诞生一款真正将 LLM 深度融入游戏玩法、从而带来变革的游戏产品？我不认为《ARC Raiders》仅仅因为用了 AI 配音就能算作“AI 产品”，而那些更具野心的项目，目前也还没真正跑起来。原因何在？

第一个原因可能是：游戏本身的开发周期就长得惊人。2016 年《星露谷物语》风靡全球时，我曾以为会立刻涌现出大量像素风农场模拟游戏，但这类作品真正集中出现其实是 2018、2019 年的事 —— 做一款游戏，就是这么耗时！所以，即便现在有人已经有了绝佳的 LLM 游戏创意，我们可能还得再等一两年才能玩到。

第二个原因是：不少玩家对 AI 其实相当反感。在游戏里加入生成式 AI，几乎注定会引发争议（虽然看样子未必致命，《ARC Raiders》的商业成功就是例证）。如果有游戏开发者干脆觉得“为 AI 创意冒这个险不值”，我一点也不会意外6。

第三个原因或许是：生成式内容本身和游戏机制就不太搭。诚然，ChatGPT 式的对话塞进大多数游戏里都会显得格格不入。AI 聊天机器人也不太擅长“挑战用户” —— 它们的后训练目标全是“尽快让用户满意”7。不过，我倒不认为这是无法攻克的技术难题。你完全可以朝另一个方向对语言模型做后训练（只是游戏公司可能还没拿到做这件事所需的资源）。

06 总结

据我统计，目前真正跑通的大语言模型产品只有三类：

• Chatbots，比如 ChatGPT，已有数亿用户用它处理各种各样的任务
• 基于智能补全的编码产品，比如 Copilot 或 Cursor Tab，受众虽小但能即刻带来价值
• 智能体类产品，比如 Claude Code、Codex、Cursor 以及 Copilot 的 Agent 模式，这类产品真正可用也就是最近六个月的事

除此之外，还有两类基于 LLM 的产品目前还没完全跑通，但可能很快会有突破：

• LLM 生成的信息流
• 基于 AI 生成内容的视频游戏

市面上几乎所有的 AI 产品本质上还是 chatbots（比如 AI 客服）。这类产品面临两个困境：一是得和 ChatGPT 这个更通用的“全能选手”直接竞争；二是没法放心赋予强大的工具权限，因为用户很容易就能越狱模型。

智能体类产品还很新，但在编码领域已经取得了巨大的成功。它们在其他领域会呈现什么形态，目前还不好说，但我们几乎可以肯定会在法律等垂直领域看到专属的研究型智能体。编码领域的研究智能体其实也已经有一些成功案例（比如代码审查或自动化安全扫描类产品）。

无限滚动的 AI 生成信息流目前还没真正成功，但已有数亿美元资金正在涌入这个方向。OpenAI 的 Sora 会成为 Twitter 或 Instagram 的真正竞争对手吗？还是说这些平台会推出自己的 AI 生成信息流产品吗？

基于 AI 生成内容的游戏听起来是个好主意，但到底该怎么把 LLM 融入游戏玩法，目前还没有清晰的可行路径。纯世界模型，即整个游戏逐帧由 AI 生成，如果只是作为技术演示确实很酷，但距离成为产品还有很长的路要走。

还有一件事我没提到：图像生成。这算 chatbots 产品的一部分，还是一个独立工具？坦白说，我觉得 AI 图像生成目前更像玩具而非产品，但确实有大量用户在用。如果能有产品成功区别于 ChatGPT 内置的图像生成功能，这里或许还有值得挖掘的机会。

整体来看，这种感觉很像互联网的早期时代。LLM 潜力巨大，但我们大部分时候还在重复造同样的轮子。肯定存在一些极其简单的产品创意，等它们出现后，我们会回头感慨：“这道理多明显啊，怎么当初没人立刻去做？”

这篇文章在 Hacker News 上收到了不少评论。有读者认为我的分类过于宽泛，这个批评很中肯：就像说“电力产品”只有两类 —— 一类让电机转动，一类让导线发热。

也有读者指出我漏掉了文本摘要、便捷翻译和语音转文字这些产品。我不同意这个看法：你自己有没有专门买过某款基于 LLM 的摘要、翻译或转录软件？大概率没有吧 —— 你直接用 chatbots 就搞定了，对吧？所以我认为这些是 chatbots 产品的功能特性，而非独立产品。

还有一位读者提到[11]，可能有一大批“零热度”产品正在默默发展、未被大众关注。这话说得确有道理！我不知道的我确实不知道。

• • *

1 当然，这里的“不过是”一词背后，其实涵盖了训练更强模型的大量进展，以及 RLHF 方面的真正创新，正是这些才使得与纯 LLM 对话成为可能。

2 这是大多数 AI 企业项目失败的一个重要原因[12]。根据我的观察，我听到了许多对企业定制 chatbots 的不满。大家只想用 ChatGPT！

3 如果你不信，随便拿一个你用得顺手的设备（比如你的手机、汽车、微波炉），想象一下必须把每一条指令都打出来。也许非常优秀的语音识别能解决这个问题，但我对此表示怀疑。

4 我起初误写成了“3.5 Sonnet”。感谢一位读者的指正。

5 我在这里[13]写过相关介绍，顶部导航栏里也有链接。

6 不过，这可能会被另一种力量所抵消，因为我确信高管们会强烈施压要求入局，“用 AI 做点什么”。

7 如果你曾试着让 ChatGPT 给你当 DM，你就会有切身体会：模型会立刻试图向你展示很酷的东西，从而跳过了那些营造紧张感和真实感所必需的枯燥铺垫。

END

本期互动内容 🍻

❓你见过哪些“看似创新、实则只是 Chatbot 套壳”的 AI 产品？它卡在哪个环节没能跑通？

文中链接

[1]https://tremendous.blog/2025/07/15/grok-companions-elons-ai-g...

[2]https://www.theverge.com/news/799312/openai-chatgpt-erotica-s...

[3]https://support.microsoft.com/en-us/office/editor-text-predic...

[4]https://www.perplexity.ai/

[5]https://www.testingcatalog.com/grok-will-get-infinite-image-g...

[6]https://www.autodeck.pro/

[7]https://deepmind.google/blog/genie-3-a-new-frontier-for-world...

[8]https://aidungeon.com/

[9]https://www.nexusmods.com/skyrimspecialedition/mods/98631

[10]https://www.polygon.com/arc-raiders-ai-voices-the-finals-emba...

[11]https://news.ycombinator.com/item?id=45946498

[12]https://www.seangoedecke.com/why-do-ai-enterprise-projects-fail

[13]https://www.seangoedecke.com/autodeck

本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。

原文链接：

https://www.seangoedecke.com/ai-products/

01. 引言：被“神化”的 Fixture

在自动化测试圈，Playwright 的出现几乎是降维打击。而其官方文档最引以为傲的特性，莫过于 Fixtures（固件）。

官方告诉我们：“忘掉那些手动初始化 Page Object 的繁琐代码吧，把它交给 Fixture，你会得到最优雅的依赖注入。”

初看确实如此。但当你进入腾讯、阿里或字节跳动等大厂的复杂业务线，面对 1000+ 页面对象、5000+ 测试用例 的超大型项目时，你会发现，当初觉得“优雅”的 Fixture，正在悄悄变成项目的“维护噩梦”。

为什么很多架构师在后期选择了回归“懒加载（Lazy Approach）”？这篇文章带你拆解其中的工程化真相。

02. Fixture 模式：优雅的代价是“黑盒”

首先，我们必须承认 Fixture 的强大。它本质上是一种依赖注入（Dependency Injection）。

// 官方推崇的模式：声明式注入
export const test = base.extend({
  userPage: async ({ page }, use) => {
    await use(new UserPage(page));
  },
  orderPage: async ({ page }, use) => {
    await use(new OrderPage(page));
  },
});

// 在用例中使用：看起来非常干净
test('下单流程', async ({ userPage, orderPage }) => {
  await userPage.login();
  await orderPage.create();
});

为什么它受宠？

• 代码脱水：测试脚本里没有一句多余的 new。
• 生命周期自动闭环：Fixture 可以在 use() 之后自动执行清理逻辑。

为什么大厂架构师开始皱眉？

当项目规模爆炸时，Fixture 会带来 “注册表膨胀”。

1. 难以追踪的来源：当你解构出 10 个 Fixture 时，你想跳转到某个 Page Object 的定义，IDE 有时会迷失在复杂的 extend 链条中。
2. 强制性的初始化逻辑：即便 Playwright 声明是按需加载，但在大型工程中，Fixture 之间的层层嵌套依赖，常会导致为了用一个 A，被迫触发了 B 和 C 的 Setup，增加了不必要的隐性复杂度。

03. 懒加载模式：回归“显式”的力量

懒加载（Lazy Approach）主张：只有在用到 Page Object 的那一刻，才去实例化它。

// 架构师偏爱的模式：显式实例化
test('下单流程', async ({ page }) => {
  const userPage = new UserPage(page);
  await userPage.login();

  // 只有登录成功，才加载订单页
  const orderPage = new OrderPage(page);
  await orderPage.create();
});

为什么它在大型项目中更稳健？

1. 完美的类型推导：new UserPage(page) 是标准的 TypeScript 行为，IDE 的跳转、重构、属性提示永远是秒回，不会因为复杂的类型注入而“卡死”。
2. 零副作用：没有隐藏的 extend，没有复杂的配置文件。每个用例用到了什么、初始化了什么，一目了然。
3. 条件分支友好：如果你的测试逻辑中有一个 if (discountAvailable)，懒加载可以让你只在条件成立时才初始化“优惠券页面”对象，节省内存和潜在的初始化耗时。

04. 深度对比：工程化视角的博弈

05. 进阶方案：架构师的“秘密武器” —— Container 模式

如果既想要 Fixture 的简洁，又想要懒加载的稳健，大厂架构师通常会封装一个 Page 容器 或 App 对象。

代码实现：

// 这是一个“页面工厂”容器
export class App {
  constructor(private readonly page: Page) {}

  // 使用 Getter 实现真正的懒加载
  get loginPage() { return new LoginPage(this.page); }
  get cartPage() { return new CartPage(this.page); }
  get paymentPage() { return new PaymentPage(this.page); }
}

// 在 Fixture 中只注入这一个 App 容器
export const test = base.extend<{ app: App }>({
  app: async ({ page }, use) => {
    await use(new App(page));
  },
});

// 最终的用例：兼顾简洁与控制感
test('完整购物流', async ({ app }) => {
  await app.loginPage.goto();
  await app.cartPage.addItem('MacBook');
  await app.paymentPage.pay();
});

这种模式的妙处在于：

• 收拢入口：所有的页面对象都在 App 类里管理，不再有零散的 Fixture。
• 按需实例化：只有当你访问 app.cartPage 时，对象才会被创建。
• IDE 极其友好：输入 app.，所有的页面对象都会自动弹出，支持一键跳转。

06. 总结：你该如何选择？

官方推荐 Fixture，是因为它在演示和中小型项目中能提供极致的“代码美感”。 但在大厂的生产环境中，“稳定”和“可维护性” 永远高于“美感”。

• 如果你的项目页面少于 50 个，且成员对 Playwright 非常熟悉，坚持使用 Fixture，它很快。

• 如果你正在构建一个企业级测试平台，或者团队中有大量初中级开发者，请优先考虑懒加载或 App 容器模式。

  • 记住： 优秀的架构不是用最炫的特性，而是用最简单、最透明的方式解决最复杂的问题。

Apache DolphinScheduler 社区近日正式发布 3.4.1 版本。作为 3.4.x 系列的一个维护版本，本次更新重点围绕 调度稳定性提升、任务运行控制能力增强以及系统问题修复展开。

新版本不仅引入了 任务分发超时检测机制 和 任务最大运行时间控制能力，还修复了多项调度逻辑、插件功能以及 API 行为中的问题，同时对系统文档、开发流程和工程结构进行了优化。

• 更多详情请查看 Release Note：https://github.com/apache/dolphinscheduler/releases/tag/3.4.1

• 源码下载：https://dolphinscheduler.apache.org/zh-cn/download/3.4.1

  核心亮点

新增任务分发超时检测机制

在 Master 调度模块中，系统新增了 任务分发超时检查逻辑。当任务被调度到 Worker 执行时，如果出现 Worker Group 不存在或没有可用 Worker 节点的情况，调度器能够在一定时间内检测到分发异常并进行处理，从而避免任务长期处于等待状态，提升系统在资源异常场景下的容错能力（#17795，#17796）。

支持配置工作流与任务实例最大运行时间

新版本支持为 工作流实例（Workflow Instance）和任务实例（Task Instance）配置最大运行时间。用户可以为任务或工作流设置最大执行时长，当任务运行时间超过设定阈值时系统能够触发超时处理，从而避免任务卡死或异常占用资源，提高系统整体运行可控性（#17931，#17932）。

关键修复和优化

调度系统稳定性修复

• 修复任务超时告警未触发的问题（#17820，#17818）
• 修复工作流失败策略无法生效的问题（#17834，#17851）
• 当任务执行上下文初始化失败时自动将任务标记为失败（#17758，#17821）
• 修复补数任务并行执行模式下并行度计算错误的问题（#17831，#17853）

数据库与兼容性问题修复

• 修复 PostgreSQL 环境下依赖任务执行 SQL 错误（#17690，#17837）
• 修复数据库表字段 INT/BIGINT 类型不匹配问题（#17979，#17988）

API 与权限相关修复

• 查询工作流实例时移除 WAIT_TO_RUN 状态并新增 FAILOVER 状态（#17838，#17839）
• 为 Workflow API 新增租户校验机制（#17969，#17970）
• 修复非管理员用户无法删除自己 Access Token 的问题（#17995，#17997）

插件与任务执行问题修复

• 修复 Java Task 中 JVM 参数位置错误的问题（#17848，#17850）
• 修复 Procedure Task 参数传递不可用的问题（#17967，#17968）
• 修复 ProcedureTask 无法返回参数及无法执行查询存储过程的问题（#17971，#17973）
• 修复 HTTP 插件无法发送 JSON 嵌套结构的问题（#17912，#17911）
• 修复 HTTP 告警插件中超时单位不一致的问题（#17915，#17920）

UI 与文档问题修复

• 从 UI 中移除任务实例 STOP 状态（#17864，#17865）
• 修复工作流定义列表加载失败时锁未释放的问题（#17984，#17989）
• 修复 Keycloak 登录图标 404 问题（#18006，#18007）
• 修复安装文档中的描述错误（#17901，#17903）
• 修复 SeaTunnel 文档链接 404 问题（#17904，#17905）

深度功能解析

在现代数据平台架构中，调度系统通常作为连接不同计算引擎的重要基础设施，例如 Spark、Flink、Hive 等任务往往通过统一的调度系统进行编排。

然而在生产环境中，调度系统经常面临以下问题：

• Worker 资源异常导致任务无法调度
• 任务运行时间不可控
• 插件执行行为不稳定

本次版本新增的 任务分发超时检测机制，使调度器能够在 Worker 不存在或资源不可用时快速识别异常，从而避免任务无限等待的问题（#17795，#17796）。

同时，新增的 最大运行时间控制能力 为任务执行提供了一种更加灵活的管理方式。通过为 Workflow 或 Task 设置最大运行时间，系统可以在任务异常卡死时及时进行处理，从而避免资源长时间被占用（#17931，#17932）。

这两项能力进一步提升了 DolphinScheduler 在 生产级数据平台环境中的稳定性和可控性。

致谢贡献者

Apache DolphinScheduler 3.4.1 的发布离不开社区开发者的共同努力。感谢发版经理 @ruanwenjun 以及以下贡献者为本次版本提供代码和改进：

• SbloodyS
• njnu-seafish
• Mrhs121
• ylq5126
• qiong-zhou
• XpengCen
• iampratap7997-dot
• yzeng1618
• Alexander1902
• maomao199691
• asadjan4611
• dill21yu

写在最后

Apache DolphinScheduler 3.4.1 是一个以 调度稳定性提升和任务运行控制能力增强为核心的维护版本。通过新增调度容错机制、支持任务最大运行时间控制以及修复多项关键问题，该版本进一步提升了系统在生产环境中的可靠性。

随着社区持续发展，Apache DolphinScheduler 正不断完善其在数据平台调度领域的能力，为企业构建稳定、高效的数据工作流编排系统提供更加可靠的基础设施支持。欢迎更多人加入到我们的队伍中，共同推进 Apache DolphinScheduler 项目及社区的发展繁荣！