2026年4月

JeecgBoot AI专题研究 | 把 Claude Code 接入 DeepSeek V4-Pro 的真实体验与避坑记录

本文记录我将 Claude Code 对接 DeepSeek 最新模型(V4-Pro)后的真实体验,测试了 Skills 自动化查询和积木报表 AI 建表两个场景——有惊喜,也踩到了一个藏在 "1M 超长上下文" 光环下的巨坑。


背景:为什么要替换掉原生 Claude?

Claude Code 是目前公认最强的 AI 编程工具之一,但原版的 Anthropic API 费用不低——Opus 4.6 的输入价格高达 $15 / 百万 tokens。作为一个每天重度使用 Claude Code 的开发者,API 账单是绕不开的问题。

今天 DeepSeek 在 Hugging Face 发布了 V4 系列预览版,包含 V4-Pro(1.6T 参数 / 49B 激活)和 V4-Flash(284B 参数 / 13B 激活),并且提供了兼容 Anthropic 协议的 API 端点。这意味着:理论上只需改一行配置,就能用 DeepSeek 驱动 Claude Code。

我立刻动手试了。


配置过程:1 分钟完成接入

核心配置其实非常简单,DeepSeek 提供了完整的 Anthropic API 兼容层,只需要在 Claude Code 的配置文件中修改几个环境变量:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "${DEEPSEEK_API_KEY}",
    "API_TIMEOUT_MS": "3000000",
    "ANTHROPIC_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_SMALL_FAST_MODEL": "deepseek-v4-flash",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
    "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-v4-pro",
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  },
  "model": "deepseek-v4-pro"
}

逻辑非常清晰:重量级任务(复杂代码、深度推理)走 V4-Pro,轻量任务(工具调用、文件读写、快速问答)走 V4-Flash。两档模型分工明确,既保住能力上限,又控制成本。

配置完成后,Claude Code 启动界面上已经清楚地显示 deepseek-v4-pro · API Usage Billing,问它 "你是什么模型",回答干脆利落:

我是 DeepSeek V4 Pro 模型。

身份确认,接下来是正题——实际测试。


测试一:Skills 自动化查询敲敲云安装量

测试目标:让 Claude Code 调用预设的 Skills 脚本,查询敲敲云产品近 7 天的安装量数据,并给出分析。

这类任务考验的是模型的工具调用能力数据理解能力——要能正确执行脚本、读懂返回数据、输出有意义的分析。

结果令人满意。指令下达后,模型迅速调用了 scripts/query_setup_stats.py,脚本执行完成后,它直接输出了结构清晰的统计表格:

日期Docker 安装直装模式小计
04-18123
04-19538
04-20134
04-2161117
04-227916
04-237714
04-24527
合计323769

模型随即给出分析:近 7 天累计 69 次安装(IP 去重),4/21–4/23 是高峰期,日均 15+ 次;今天(4/24)数据 7 次,还在增长中。

整个过程速度很快,数据完全正确,没有幻觉,没有多余废话。V4-Pro 在这类结构化数据处理 + 工具调用场景下表现非常稳。

测试二:积木报表 AI 建表——盲猜出了正确答案

测试目标:让 Claude Code 调用积木报表(JiMu Report)的 AI 建表 Skills,自动创建一张员工信息纵向分组报表,要求按部门分组并显示小计。

这个任务比第一个复杂得多——它涉及报表 DSL 配置的生成,需要模型理解 "分组报表"、"纵向合并"、"小计行" 等专业概念,并且输出格式精确到位。

第一轮:报表出来了,但合计行是空的

模型第一次生成配置后,报表渲染出来,结构基本正确——按部门(人事部、市场部、研发部)纵向分组,每个部门内的员工明细都显示出来了。但有一个明显问题:合计行完全是空的,年龄、人数、薪资的小计数据一个都没有显示。

我把截图发给它,配上一句描述:"合计值配置不对。"

第二轮:看不见图,却猜对了病根

这里出现了一个既尴尬又有趣的细节。

模型收到截图后,在界面上诚实地打印出一行字:

我无法直接查看图片,但根据已知的纵向分组合计坑点,问题应该是数值列(薪资、年龄)缺少显式的聚合属性。让我获取报表当前设计并修复。

没错——它看不见图片,但它没有放弃,而是调用工具读取了报表当前的 JSON 配置文件,然后凭借对 "纵向分组报表合计行常见问题" 的领域知识,直接定位到了问题:小计行的字段缺少 sumavgcount 等聚合表达式绑定,导致渲染时数据为空。

它重新生成了配置,在合计行的对应字段上补充了聚合属性,再次渲染后:

  • 人事部合计:年龄均值 33.5,人数 2,薪资合计 33,000 ✓
  • 市场部合计:年龄均值 27.33,人数 3,薪资合计 39,000 ✓
  • 研发部合计:年龄均值 29.33,人数 3,薪资合计 52,000 ✓

所有小计全部正确。

这一幕揭示了什么

这个过程的关键不是 "修好了",而是修好的方式——它没有依赖视觉信息,而是通过读取配置文件 + 领域知识推断,独立完成了诊断和修复。换句话说,即便图片这条路走不通,它还能找到另一条路绕过去。

这是 Agent 能力的体现,也恰好暴露了接下来要说的那个坑。


巨坑预警:1M 上下文 ≠ 支持图片

DeepSeek V4-Pro 最亮眼的规格之一是 1,000,000 tokens 的超长上下文,乍一看比 Claude 原版还要豪横。但当我发送截图时,才发现了这个藏在光环下的盲区:

V4-Pro 当前版本是纯文本模型,完全不支持图片输入。

Claude Code 在发送图片时,V4-Pro 会收到一个占位符 [Image #1],但对实际图像内容毫无感知。所以你看到的那句 "我无法直接查看图片" 不是谦虚,是真的看不见。

对于日常编程工作流,这个限制影响面相当广:

  • 截图报错让模型分析 → ❌ 看不见
  • 发 UI 设计稿让模型写代码 → ❌ 看不见
  • 发报表渲染结果让模型诊断问题 → ❌ 看不见
  • 粘贴终端截图 → ❌ 看不见

1M 上下文能塞进去整个代码仓库,但塞不进去一张 PNG。

目前的折中办法:当需要处理图片时,临时去掉 ANTHROPIC_BASE_URL 配置,让请求回落到 Anthropic 原生 API,用完再切回来。麻烦,但能用。DeepSeek V4 的 Vision 模式已经在规划中,API 开放后这个问题会从根本上解决。


综合感受

经过这两轮测试,对 Claude Code + DeepSeek V4-Pro 的组合有几点直观感受:

表现亮眼的地方:

  • 兼容性几乎无感:配置完成后,Claude Code 的所有功能正常运行,Skills、工具调用、多步骤 Agent 任务都能跑通,完全感受不到 "换了模型"。
  • 工具调用稳定:脚本执行、文件读写这类结构化任务,V4-Pro 准确率高、响应快,没有废话也没有幻觉。
  • 领域推理能力强:即使在无法看图的情况下,模型能通过读取配置文件 + 领域知识推断定位到问题,这种 "绕路解决" 的能力很实用。
  • 成本压缩明显:相比原生 Claude Opus,API 成本预估节省 90%+。

需要踩坑提前知道的:

  • 🚨 不支持图片(重要):1M 上下文是真的,但图片输入不支持。Claude Code 里发截图,模型只会收到占位符,完全看不见内容。这是目前最影响日常使用的限制。
  • 部分复杂任务需要引导:像报表建表这类专业 DSL 任务,第一次不一定配置到位,但接受反馈后自修正能力很强。
  • 超时要设长一点:V4-Pro 在 max effort 模式下推理时间较长,API_TIMEOUT_MS 建议设 600000(10 分钟)以上。

总结

把 Claude Code 对接 DeepSeek V4-Pro,配置成本极低,三分钟搞定,换来的是开源最强 Agent 编程模型 + 极低 API 成本 + 完整的 Claude Code 工具链

但有一点要想清楚再切换:如果你的工作流依赖截图、UI 稿、图片输入,现在切换会很痛。等 DeepSeek V4 的 Vision 模式开放 API,这套方案才算真正补全了最后一块拼图。

在那之前——纯代码任务、脚本自动化、文本推理,放心用;涉及图片的,暂时留一个 Claude 原生的后路。


测试环境:Claude Code v2.1.119,DeepSeek V4-Pro(deepseek-v4-pro),2026-04-24

本文为 JeecgBoot AI 专题研究系列文章。

在跨境出海需求持续升温的当下,开发者在对接商家跨境建站需求时,常常陷入两难:海外建站工具(如Shopify)源码封闭、二次开发成本高、中文技术支持薄弱,无法灵活适配国内商家的定制化需求;传统开源建站方案(如WordPress+WooCommerce)需手动部署、插件兼容繁琐,运维成本高,且难以快速对接跨境支付、物流等核心模块。
作为长期深耕跨境开发领域的开发者,笔者测试过多款建站工具后发现,Taoify以“0佣金国产Shopify平替”为定位,兼顾低代码便捷性与API全开放性,既适合新手开发者快速交付项目,也能满足资深开发者的深度定制需求,成为对接跨境建站需求的高效工具,今天结合实操场景,和思否的开发者们详细拆解其技术优势与落地玩法。
不同于传统建站工具“要么封闭难定制,要么开源门槛高”的痛点,Taoify以“开发者实操友好”为核心,构建了“低代码拖拽+API全开放”的双重模式,精准覆盖前端、后端、全栈开发者,以及需要对接跨境需求的技术服务商,同时兼顾商家的成本与合规需求,实现开发者效率与商家体验的双重提升。
一、核心差异化:开发者视角下的Taoify优势拆解
站在开发者角度,一款优质的跨境建站工具,核心要解决“对接快、定制活、运维省”三个核心需求,而Taoify的四大核心壁垒,恰好精准命中这些痛点:

  1. 技术适配壁垒:API全量开放,兼容多语言开发栈
    Taoify支持API接口全量开放,提供完善的接口文档、调试工具与开发示例,兼容PHP、Python、Node.js等主流开发语言,适配Vue、React等前端框架,开发者可快速对接商家现有ERP、CRM、库存管理系统,实现订单、客户、商品数据实时同步,无需重构技术体系,大幅降低对接成本。同时支持WebHook回调,可灵活配置事件触发逻辑,满足定制化业务需求。
  2. 开发效率壁垒:低代码+定制开发并行,交付周期缩短60%
    针对不同开发场景,Taoify提供双重开发模式:新手开发者可借助无代码拖拽编辑器,300+跨境专属模板一键套用,快速调整页面布局、交互逻辑,10分钟完成基础建站,无需编写复杂代码;资深开发者可基于API进行深度二次开发,自定义页面组件、支付流程、物流对接逻辑,甚至开发专属插件,灵活适配3C、家居、工业用品等不同行业的定制化需求,将项目交付周期缩短60%以上。
  3. 运维成本壁垒:企业级SaaS架构,免部署免维护
    Taoify采用企业级SaaS架构,基于全球CDN分布式部署,提供HTTPS加密、PCI支付认证、数据备份等全方位安全保障,系统在线率达99.9%,开发者无需投入服务器部署、环境配置、安全运维等成本,只需专注于业务逻辑开发与定制,大幅降低运维压力。同时系统每周迭代更新,自动适配跨境合规政策与第三方接口升级,无需开发者手动同步。
  4. 成本与服务壁垒:0佣金+中文技术支持,降低合作门槛
    相较于Shopify 2%+的交易抽成,Taoify实行永久0佣金+低月租模式,无任何隐形消费,既降低商家运营成本,也让开发者在对接客户时更具竞争力。更重要的是,配备7×24中文一对一技术客服,针对接口对接、二次开发、bug排查等问题,响应速度快、解决效率高,彻底告别海外工具“邮件慢响应、语言不通”的痛点,贴合国内开发者沟通习惯。
    二、实操落地:开发者如何用Taoify快速对接跨境建站需求
    结合实际开发场景,笔者总结了Taoify的核心实操流程,从接口对接、定制开发到项目交付,全程简洁高效,适合各类开发者快速上手:
  5. 前期准备:快速完成API接入与环境配置
    开发者注册Taoify开发者账号后,可在后台获取专属API密钥与接口文档,文档包含详细的接口说明、参数示例、错误码解释,支持在线调试,无需额外搭建测试环境。同时提供Postman接口合集,可直接导入使用,快速完成接口联调,降低接入成本。针对新手开发者,还提供中文技术教程与视频指导,助力快速上手。
  6. 核心开发:低代码+API结合,灵活适配需求
  7. 基础建站场景(快速交付):无需编写代码,通过Taoify无代码编辑器,拖拽式添加商品模块、支付入口、物流查询组件,套用跨境专属模板,快速完成多语言、多货币适配,10分钟即可上线基础版本,适合新手开发者对接小型商家需求。
  8. 定制开发场景(深度适配):基于API接口,开发者可实现多维度定制:自定义商品详情页布局、开发专属支付逻辑、对接小众物流服务商、集成TikTok/FB广告追踪模块,甚至开发专属会员体系与私域运营工具,满足中大型商家、工厂的个性化需求。例如,对接工厂ERP系统时,可通过API实现库存数据实时同步,避免超卖、缺货问题。
  9. 运维交付:一键部署+全程技术支持,降低售后压力
    项目开发完成后,可通过Taoify后台一键部署上线,无需手动配置服务器、域名解析,系统自动完成SSL证书配置与CDN加速,保障海外访问速度。交付后,开发者可借助后台数据统计接口,实时监控网站运行状态、订单数据、流量来源,快速排查异常问题;同时依托Taoify的7×24技术支持,无需单独承担售后运维压力,大幅提升客户满意度。
    三、场景化适配:不同开发者的落地玩法
    Taoify的灵活性,可适配不同类型开发者的需求,实现技术变现与效率提升:
  10. 前端开发者:可借助无代码编辑器快速搭建响应式页面,结合API对接前端交互逻辑,无需关注后端部署与运维,专注于页面体验优化,快速交付跨境建站项目;
  11. 后端开发者:可基于API进行深度二次开发,对接第三方系统、定制业务逻辑,开发专属插件,提升项目定制化能力,拓展服务范围;
  12. 全栈开发者:可兼顾低代码便捷性与定制开发灵活性,快速完成从前端搭建到后端对接的全流程开发,缩短项目交付周期,提升接单效率;
  13. 技术服务商:可依托Taoify的API开放能力,为多个商家提供批量建站与定制服务,降低运营成本,同时借助0佣金优势,提升客户留存率。
    四、开发者赋能:Taoify的额外支持的体系
    为助力开发者提升竞争力、实现技术变现,Taoify还提供了完善的开发者支持体系:
  14. 技术支持:提供一对一技术对接、接口调试指导、bug快速响应,定期更新API文档与开发教程,助力开发者解决开发过程中的各类问题;
  15. 合作通道:开放开发者合作计划,开发者可通过定制开发、模板开发、插件开发等方式,借助Taoify平台获取收益,拓展业务渠道;
  16. 案例参考:提供覆盖10+行业的开发案例与解决方案,开发者可参考行业最佳实践,快速对接同类需求,提升交付质量;
  17. 合规支持:适配跨境电商合规要求,提供数据加密、隐私保护等相关技术支持,开发者无需额外投入合规开发成本,助力商家合规出海。
    五、总结:开发者对接跨境建站需求的优选工具
    对于思否社区的开发者而言,跨境建站需求的核心痛点,在于“效率、成本、灵活性”的平衡,而Taoify以“API全开放+低代码+0佣金”的核心优势,恰好解决了这些痛点——既降低了开发与运维成本,也提升了项目交付效率,同时兼顾定制化需求,适配不同类型开发者的落地场景。
    相较于海外封闭型工具与传统开源方案,Taoify更贴合国内开发者的操作习惯与商家的实际需求,无论是新手开发者快速接单,还是资深开发者深度定制,都能找到适配的解决方案。2026年,跨境出海技术赋能趋势凸显,选择一款适配性强、效率高、成本低的建站工具,不仅能提升开发效率,更能拓展自身的业务边界,而Taoify,无疑是开发者对接跨境建站需求的优选之选。

在 PowerPoint 中,组合图表是一种将两种或多种不同图表类型合并到同一图表中的图表形式。它可以在一个图表中展示多组数据,使不同变量之间的对比和分析更加直观。在本文中,你将学习如何通过编程方式在 PowerPoint 演示文稿中创建组合图表。

环境准备

在开始之前,你需要在 .NET 项目中添加相关组件作为引用。这些组件可以通过下载安装包获取,也可以通过 NuGet 进行安装。

PM> Install-Package Spire.Presentation

在 C# 和 VB.NET 中创建 PowerPoint 组合图表

在 PowerPoint 中,可以先向幻灯片中添加一种基础图表类型,然后将其中某个数据系列更改为另一种图表类型,从而实现组合图表的效果。下面是将柱形图与折线图组合的基本步骤:

  1. 创建一个 Presentation 实例。
  2. 获取指定的幻灯片,并向其中添加一个柱形图。
  3. 创建一个 DataTable 对象并填充数据,然后将数据导入到图表中。
  4. 设置图表标题、分类标签、系列名称以及系列数据。
  5. 将第二个数据系列的图表类型修改为带数据标记的折线图。
  6. 将第二个数据系列设置为使用次坐标轴进行绘制。
  7. 设置次坐标轴的数字格式和网格线样式。
  8. 保存生成的演示文稿。

示例代码如下:

using Spire.Presentation;
using Spire.Presentation.Charts;
using Spire.Presentation.Drawing;
using System;
using System.Data;
using System.Drawing;

namespace CombinationChart
{
    class Program
    {
        static void Main(string[] args)
        {
            // 创建一个 Presentation 实例
            Presentation presentation = new Presentation();

            // 在第一张幻灯片中添加一个簇状柱形图
            RectangleF rect = new RectangleF(80, 120, 550, 320);
            IChart chart = presentation.Slides[0].Shapes.AppendChart(ChartType.ColumnClustered, rect);

            // 设置并格式化图表标题
            chart.ChartTitle.TextProperties.Text = "Monthly Sales Report"; // 月度销售报告
            chart.ChartTitle.TextProperties.IsCentered = true;
            chart.ChartTitle.Height = 30;
            chart.HasTitle = true;

            // 创建一个 DataTable 并添加数据
            DataTable dataTable = new DataTable();
            dataTable.Columns.Add(new DataColumn("Month", Type.GetType("System.String"))); // 月份
            dataTable.Columns.Add(new DataColumn("Sales", Type.GetType("System.Int32"))); // 销售额
            dataTable.Columns.Add(new DataColumn("Growth rate", Type.GetType("System.Decimal"))); // 增长率
            dataTable.Rows.Add("January", 200, 0.6);
            dataTable.Rows.Add("February", 250, 0.8);
            dataTable.Rows.Add("March", 300, 0.6);
            dataTable.Rows.Add("April", 150, 0.2);
            dataTable.Rows.Add("May", 200, 0.5);
            dataTable.Rows.Add("June", 400, 0.9);

            // 将 DataTable 中的数据导入到图表
            for (int c = 0; c < dataTable.Columns.Count; c++)
            {
                chart.ChartData[0, c].Text = dataTable.Columns[c].Caption;
            }
            for (int r = 0; r < dataTable.Rows.Count; r++)
            {
                object[] datas = dataTable.Rows[r].ItemArray;
                for (int c = 0; c < datas.Length; c++)
                {
                    chart.ChartData[r + 1, c].Value = datas[c];
                }
            }

            // 设置系列标签
            chart.Series.SeriesLabel = chart.ChartData["B1", "C1"];

            // 设置分类标签    
            chart.Categories.CategoryLabels = chart.ChartData["A2", "A7"];

            // 为系列赋值
            chart.Series[0].Values = chart.ChartData["B2", "B7"];
            chart.Series[1].Values = chart.ChartData["C2", "C7"];

            // 将第二个系列的图表类型改为带数据标记的折线图
            chart.Series[1].Type = ChartType.LineMarkers;

            // 将第二个系列绘制在次坐标轴上
            chart.Series[1].UseSecondAxis = true;

            // 设置次坐标轴的数字格式
            chart.SecondaryValueAxis.NumberFormat = "0%";

            // 隐藏次坐标轴的网格线
            chart.SecondaryValueAxis.MajorGridTextLines.FillType = FillFormatType.None;

            // 设置图例位置
            chart.ChartLegend.Position = ChartLegendPositionType.Top;

            // 设置柱形图重叠比例
            chart.OverLap = -50;

            // 设置柱间距
            chart.GapWidth = 200;

            // 保存结果文档
            presentation.SaveToFile("CombinationChart.pptx", FileFormat.Pptx2010);
        }
    }
}

结语

总的来说,组合图表是一种非常实用的数据可视化方式,能够在同一图表中同时展示不同类型的数据,从而提升信息表达的清晰度和对比效果。通过本文的示例,可以看到,在 PowerPoint 中实现柱形图与折线图的组合并不复杂:核心思路是先创建基础图表,再对特定数据系列调整图表类型,并结合次坐标轴来呈现不同量级的数据。

整个过程涵盖了数据准备、图表配置以及样式优化等关键步骤,不仅可以满足基础的数据展示需求,还能通过标题、图例、坐标轴等细节设置提升图表的可读性和专业度。掌握这种方法后,你可以根据实际业务场景灵活扩展,构建更符合需求的数据可视化效果。

SentiPulse(思维光谱)旗下 AI Agent 产品 SentiCat 于 4 月 23 日正式开启公测。产品核心定位为 “任务执行+情感陪伴” ,即在执行任务的基础上,加入长期交互与情感陪伴能力。
image.png

公测机制

  • 申请方式:官网排队预约,审核制发放体验码。
  • 额度:通过官方审核的用户赠送 100 元 Token 初始额度,后续按用量充值。
  • 系统要求:当前仅支持 Windows。

技术点速览

  • 自研架构:系统架构为团队自主搭建,非基于 OpenClaw 等现有 Agent 框架二次封装,覆盖上下文管理、任务执行到记忆系统的完整链路。
  • 多模型接入:同时接入 MiniMax、通义千问、智谱、豆包、DeepSeek、Kimi、小米共 7 款国内主流大模型,支持在设置中手动切换,不绑定单一基座。
  • 扩展能力:支持安装 Skill 与接入外部 MCP 服务器,提供定时任务、自定义脚本(自然语言生成脚本)、AI 配图等系统能力。
  • 初始化流程:首次安装有 Onboarding 环节,授权后生成用户画像,用于后续交互的偏好适配。

三大核心应用场景

  • 办公自动化:以自然语言驱动 PPT 自动生成、Excel 数据处理及 Word 文档排版。
  • 深度研究:输入主题后,系统自动完成多源数据整合、信息搜集与深度分析,交付研究报告。
  • 代码开发:覆盖代码编写、Bug 定位及项目重构等完整开发链路。

数据安全

采用本地优先设计原则:聊天记录、个人偏好及文件资料均存储在用户设备中,默认不上传云端。API 密钥加密处理,代码执行与插件运行引入沙盒机制。仅在调用云端模型时发送必要信息,用户可随时查看、管理与删除本地数据。

链接:SentiCat 官网可查看详情并排队申请。

4 月 24 日 - 4 月 26 日,新一届 2050 大会将在云栖小镇如期举行。期间,少数派将会组织《少数派的共创时代》社区交流活动,围绕 AI 降低创造门槛后,从想法到产品落地的真实路径展开讨论。

以下是活动的详细信息:

  • 时间:4 月 25 日 13:00
  • 地点:杭州 · 云栖小镇国际会展中心(2050 大会现场)A 区一楼贤云厅
  • 名额:100 人,请填写表单预约,以后续确认通知为准
  • 入场:需持有效 2050 PASS,活动详见 2050.org
  • 门票:¥330 元(3 天),点击购买活动门票
  • 注意:购票后需实名认证,入场必须携带本人身份证

购买门票后,可扫码入群。作为福利,到场参加参加本活动的少数派用户,可获赠一年期少数派会员(价值 365 元)。

我们的活动分两个环节:

  1. 首先,我将会分享少数派在产品共创上的实践:我们是怎么把社区里的想法变成真实产品的,过程中走过哪些弯路,AI 工具在哪些环节真正帮上了忙;
  2. 之后,我们打算邀请几位真实创作或开发经历丰富的,有影响力的嘉宾,各自讲讲从一个想法走到真实用户手中的故事,包括——
    • 老麦(少数派创始人);
    • 陶新乐(「白描」应用开发者、优零科技 CEO);
    • 佑酱(汽车博主、风光摄影师、独立开发者);

当然,我们也会给到场的少数派用户提供现场交流和沟通的机会,大家可以一起畅谈创作和创造的经验,一起碰撞灵感的火花。


2050 大会」是国内科技圈里一个非常独特的存在。

这是由中国工程院院士、阿里云创始人王坚博士,通过杭州市云栖科技创新基金会,发起的一项非营利科技活动。每年 4 月最后一个完整周末,来自世界各地的科技爱好者会自发聚集到杭州云栖小镇,度过三天两夜。

为什么叫「2050」?王坚博士当初的解释很朴素:2050 年是我们大多数人都能活到的年份,既不太远也不太近,既是对未来的一个锚点,也是一种承诺——这个大会要一直办到 2050 年。云栖小镇至今还立着一个以秒为单位的倒计时装置,从九亿多秒开始倒数。

2050 大会最让我着迷的地方,是它的组织方式。这里没有传统意义上的组委会,没有主办单位和指导单位的层层 logo 墙,甚至没有全职工作人员。所有参与者,无论是来做分享的科学家、来展示项目的创业者,还是来报道的媒体记者,统一称为「自愿者」,人人都要买票入场。

在 2050,任何人或团体都可以申请成为「召集人」,自行组织一场团聚活动,主题和形式完全自定。例如,去年大会期间,就有超过 100 场论坛、400 多场分享同时进行,总到场人数近万人,还有一颗从文昌跨越 2050 公里运来的 SAR 对地观测卫星。

今年 4 月底,新一届 2050 大会将在云栖小镇如期举行,少数派也将成为其中的一份子,并且邀请你一起参与。


少数派做了十四年,核心只有一件事:找到那些对工具和创造有热情的人,提供一个可以交流和被看见的地方。从最早的内容社区,到后来的付费栏目、开发者扶持,再到现在的硬件共创,形式一直在变,但底层逻辑没变:我们相信好东西是被真实需求和社区反馈「养」出来的,不是闭门造出来的。

过去两三年间,AI 正在把写代码、出设计、跑原型的门槛急剧拉低。一个没有开发背景的人,周末就能把一个产品想法跑起来,这在之前几乎不可想象。创造这件事,正在从少数人的技能特权,变成每个人的选项。

但工具能解决的只是「怎么做」。更关键的问题是:这个东西值不值得做?用户真正需要的是什么?怎么在产品还没成型的时候,就找到愿意和你一起打磨它的人?这些问题,仍然只能靠人与人之间真实的碰撞来回答。而这恰恰是少数派社区十几年来一直在做的事,也是 2050 大会最打动我的地方。

2050 没有固定主题,没有组委会,也没有嘉宾工作证。这种不设前提、让人和想法自然碰撞的氛围,和少数派社区里每天都在发生的事情非常像:有人在评论区随手提了一个需求,结果真的有人把它做了出来;有人写了一篇工作流分享,引发了一串完全意料之外的讨论。

所以我们决定,今年在 2050 大会上开一个属于少数派的「蜂巢」,用来和大家面对面聊聊,在 AI 降低了创造门槛之后,一个普通人从「有想法」到「做出来」再到「被人用」,中间到底会经历什么。

如果你对独立开发、产品共创、AI 工具感兴趣,或者只是想认识一群同样在动手创造的人,期待 4 月 25 日杭州见。

填写意向报名表

购买 2050 活动门票

    目前版本更新到 v0.2.13 了(基本是周一到周五每天都会更新)和 WorkBuddy 越来越像了。

    1. 新版中和 WB 一样,增加了【专家】替换掉了原来的【灵感】

    image

    1. 连接应用管理增加了很多

    image

    1. 对话信息流比以前方便很多,如:文件直接显示图标,点击即可打开;侧边栏打开可以看到任务背景、文件、专家等关键信息

    image

    1. 增加了【文件】标签,找相关文件方便了

    image

    1. 增加了一些高级功能设置

    image

    下面再说说不好的地方

    6.和 WB 一样,计量单位从【token】变成了【积分】,原来每天 4000 万 token,现在是 800 积分。主页面也不显示用量了,但是免费的大模型倒是可以自选了,费率不同。

    image

    image

    7.存在【抱歉,这个问题我暂时无法解答,让我们换个话题吧~】,之前都是正常的,个人也没觉得这是敏感的内容。

    image

    总结:总体来说还是进步明显,帮我做了很多工作中低质量又不得不做的内容,完成的相当好,稳定性也提高了很多,和 WorkBuddy 还是有一些侧重上的差异,下次分享另一个的感受。

    引言:金融服务领域的一个隐性难题

    在银行与金融科技领域,技术规划通常聚焦于 API、实时处理、云迁移及人工智能驱动的数据分析。然而,大量核心业务流程仍依赖企业系统中结构化程度最低的文件格式——PDF。银行对账单、交易报告、监管披露材料、开户资料以及客户上传文件不断以 PDF 的格式流入。这些文档需要为分析平台、风险模型、合规审核及客户视角分析提供数据支撑。

    关键挑战在于 PDF 的结构。PDF 的设计初衷是保证视觉保真度,而非承载语义化数据。表格很少以标准表格对象的形式呈现,列靠间距来体现,行靠对齐来区分。页眉、页脚、免责声明、横幅等版式元素还经常会打断交易数据区域。这种情况在金融服务行业尤为突出,主要原因包括:对账单来自多家机构与供应商、模板会无预警发生变更、旧版对账单多为扫描图片,以及交易记录经常跨行显示或包含合并单元格。

    在生产环境中,信息提取失败并不是个小问题。解析错误可能会传导至偿付能力核查、贷款审批及监管报告等环节,而这些场景均对可审计性和可重复性有严格要求。本文将阐述 PDF 表格提取在规模化应用中失效的原因,说明单一策略的 Java 实现为何在真实业务环境中难以稳定运行,并介绍如何通过架构化方法提升可靠性。

    第一种实现方案:流式解析一度有效

    在设计银行数据处理流程时,提取金融对账单的需求看似简单:只需要抽取交易表格并映射为相应的数据结构。对于文本型 PDF,常用方案是采用流式解析器,先提取带坐标信息的文本片段,按纵向坐标将片段归为一行,再根据横向区间将行拆分为列,最后将列映射为 DateDescriptionAmountBalance 等字段。

    举个简单的例子:

    在开发环境中,这种方法或许够用。但在生产环境中,初期暴露的问题往往不是异常或崩溃,而是看似正常、实则列分配错误的数据行。一个典型问题是:当对齐出现微小偏差时,金额与余额列会发生互换,而系统仍正常运行,下游业务也继续信任这个输出。这让我们意识到,PDF 提取并非传统意义上的解析问题,而是输入可靠性问题,我们在设计阶段就必须明确考虑可靠性。

    为何流式提取在生产环境中处理对账单会失效

    在处理真实的对账单格式时,同样的失效问题会反复出现。这类问题并不限于某一家银行,而是在多家机构和不同的 PDF 生成工具中普遍存在。

    布局漂移和不稳定的列边界

    流式解析的前提是假设各列拥有固定的横向坐标边界。而在真是的对账单中,横向位置常会因以下原因发生变化:字体与渲染差异、摘要内容宽度不固定、模板更新以及不同的 PDF 生成工具或导出设置的影响。

    对人工阅读来说,表格依然清晰可读。但对于依赖横向坐标聚类的解析算法而言,哪怕微小的位置偏移都可能导致数值超出预设的列边界。在实际应用中,仅仅几像素的偏差就会让数据被错误归到其他列中。

    跨多行交易记录

    交易记录通常并非单行显示,常见的格式包括:

    • 第 1 行(日期 + 描述 + 金额)

    • 第 2 行(描述续行(无日期/金额))

    • 可选第 3 行(参考信息、汇率注释、地点或元数据)

    如果把每一行物理行都当作一条交易记录,就会把一笔交易拆分成多条;可如果过度合并,又可能把相邻的交易混在一起。无论采用哪种方式,都需要有明确的多行处理逻辑与校验机制。

    混合内容与多类表格区域

    对账单中通常还包含其他对齐区域,例如账户摘要、费用明细、利息说明、合计数据或营销横幅。其中不少内容在视觉上与表格相似,若解析器仅依靠对齐方式判断,很可能将其误判为交易表格。对于这种情况,提取过程需要结合语义校验(如页眉识别、字段类型、行数据规律),而不能只依赖几何位置信息。

    扫描版 PDF:OCR 让提取变成另一个问题

    扫描版对账单没有可直接读取的文本层,流式解析无法奏效,因为不存在可选中的文本和坐标信息。这时必须依赖 OCR,但 OCR 也会带来新的问题,包括:字符识别错误(如 0/O1/l 混淆、小数点丢失)、文本框噪声干扰行列划分、文档倾斜或旋转导致的对齐偏差,以及压缩失真产生的虚假线条或原线条出现断裂。对于这种情况,仅“提取文本”远远不够,还需要从图像像素中重建表格结构,并与 OCR 结果对齐。

    首次架构调整:引入 Python(Camelot)

    在监管严格的环境中,一种常见的短期方案是在已有的 Java 服务之外引入基于 Python 的提取 API(Camelot),并结合使用面向图片类 PDF 的 OCR 流程。这个工具能够优化部分文档的提取效果,帮助团队判断针对不同类型的 PDF 应该采用哪种提取策略更为合适。

    但这种架构需要付出相应的代价,主要包括:额外的运行环境与部署流程、重复的依赖治理和漏洞管理、多服务可观测性与调试开销上升,以及敏感文档在多组件间流转所带来更严苛的处理要求。

    这并不是说引入 Python 工具是错误的,而是说提取的可靠性不能只靠选择某一个工具来解决。系统需要一套合适的架构,既能在文档格式多变的情况下稳定运行,又能降低运维成本。

    重构方案:基于验证与降级的策略选择

    关键的改进在于将“选择最优解析器”的思路转变为“在运行时选取最优结果”,同时绝不隐藏低置信度结果。这种方法需要具备三项能力:

    • 多种提取策略,包括流式提取、表格格线式提取,以及 OCR 处理的变体

    • 可对错误输出进行早期检测的验证与评分机制

    • 明确且可审计的回退行为

    这就是构成生产级流水线的架构。

    强化的流式解析

    流式解析在处理文本型 PDF 时依然有效,区别在于将流式输出视为必须经过验证的候选结果。参考如下伪代码:

    流式提取流程

    // PSEUDOCODEList<TextBox> boxes = pdfTextExtractor.extract(page);List<Line> lines = clusterByY(boxes);Header header = headerDetector.find(lines); // keyword scoring: Date, Amount, Balance, etc.ColumnModel columns = columnInferer.infer(lines, header);Table table = rowAssembler.assemble(lines, columns);ValidationScore score = validator.score(table);return ExtractionResult.of(table, score, Strategy.STREAM);
    复制代码

    重要的验证信号

    典型验证项包括:页眉检测(或强页眉信号识别)、日期解析成功率、金额与余额列的数值解析成功率、行一致性校验(即预期应填充的列数),以及合理性检查(例如余额解析结果以数值为主,不应被非数字文本主导)。

    我们的目标并非追求完美,而是捕捉那些表面有效、实则结构错误的失效模式。

    格线解析:有线/扫描表格的网格式抽取方法

    对于扫描版对账单与带框线表格,格线解析能够有效提升识别可靠性,原因在于它使用的是视觉结构(边框线条)进行解析,而非依赖文本对齐。参考如下伪代码:

    格线提取流程

    // PSEUDOCODEBufferedImage image = renderer.render(page);GridLines lines = lineDetector.detect(image);      // horizontal + vertical linesCellMatrix cells = gridBuilder.build(lines);       // joints/intersections -> cell gridList<OcrBox> ocrBoxes = ocrEngine.extract(image);  // text + bounding boxesTable table = cellAssigner.assign(cells, ocrBoxes);ValidationScore score = validator.score(table);return ExtractionResult.of(table, score, Strategy.LATTICE);
    复制代码

    格线失效模式

    格线解析并非万能,它在多种场景下均可能失效,例如:无网格线的空白分隔表格、线条断裂或不完整(如缺少连接点)、水印或阴影产生的干扰线条、存在合并单元格需进行跨列/跨行检测,以及多页表格宽度不一致等。与流式解析同理,关键在于对格线解析的输出结果进行校验,并将其作为候选方案,而非绝对正确的结论。

    混合解析:选取最优结果,而非最优解析器

    混合解析是面向真实场景多变性而设计的生产级策略。在生产环境中,我们的目标并不是要判定哪种解析技术最优,而是对多组抽取结果进行评估与打分,返回针对当前文档最可靠的结果,并在置信度较低时提供清晰的降级回退方案。参考如下伪代码:

    编排器

    // PSEUDOCODEExtractionResult stream = streamParser.tryExtract(pdf);ExtractionResult lattice = latticeParser.tryExtract(pdf);ExtractionResult best = chooseBest(stream, lattice);if (!best.score().isAcceptable()) {    return fallbackHandler.lowConfidence(pdf, stream, lattice);}return best;
    复制代码

    评分输入示例

    评分模型不需要太复杂也能达到很好的效果。常见的输入包括:页眉匹配度(关键词与列数匹配情况)、日期和数值列的解析成功率,以及行数是否合理(行数过少或过多)。

    实用的设计思路是让评分具备可解释性。当抽取结果被驳回时,系统应明确说明原因(例如日期解析率低于 60%、未检测到页眉、行与行之间列数不一致)。

    最重要的原则:绝不隐藏低置信度结果

    在金融系统中,提取错误比未提取到结果的后果更为严重。当置信度低于设定阈值时,处理流程应执行以下操作:仅返回带有明确标识的部分结果、转入指定的人工审核或异常处理流程、存储非敏感诊断信息用于问题排查,并在低置信度结果数量激增时触发格式漂移告警。

    这种响应措施可以防止数据被静默损坏。

    机器学习辅助布局检测:窄场景使用,强约束保障

    部分 PDF 可能会同时让流式解析与格线解析失效:这类文件没有清晰的网格线、页面为复杂多栏布局、混杂叙述文本块,还可能带有印章、旋转角度或使用非常规模板。

    针对这类情况,机器学习可作为区域分割工具,主要用于检测潜在的表格区域。更稳妥的模式是:由机器学习给出表格边界框,再对框内区域进行解析(结合 OCR 与格线解析或流式解析),随后校验输出结果,若校验不通过则自动触发回退机制。

    但在受监管的业务流程中,机器学习不能作为不经核实就直接采信的提取工具。它的作用是缩小搜索范围、优化定位精度,而非绕过确定性校验环节。

    Java 优先解决方案的重建:生产级摄入子系统

    最终的架构不是一个解析器,而是一个职责分离明确的摄入子系统:

    • 文档分类:文本/扫描件、质量特征值以及页面辅助信息

    • 流式解析器:带有对齐逻辑的文本层提取

    • 格线解析器:带有 OCR 对齐的网格检测

    • OCR 模块:适用于扫描文档的统一文本框接口

    • 混合编排器:运行时策略选择

    • 验证器/评分器:可解释的质量门控

    • 诊断/可观测性:指标、失败原因和可追溯性

    输出约定同样关键。我们统一规范了一个标准数据结构,包括:

    transactions[](结构化行);

    strategyUsed

    confidenceScore

    warnings[]

    parsingDiagnostics(非敏感摘要)。

    这种结构让下游调用方将抽取结果视为概率性、可审计的数据,而非盲目采信的结果。

    最后,这种设计模式可通过纯 Java 实现,无需引入额外的运行时。例如,我开源了 Java 库 ExtractPDF4J,通过融合多种互补解析策略(流式、格线/OCR)并输出便于校验的结果实现了文中所述的生产环境多变性处理方案。

    Java 架构师构建文档摄入管道系统的经验

    这些是在生产环境中效果最为显著的实践::

    • 将 PDF 抽取视为可靠性与验证问题,而非单纯的文件格式问题

    • 避免采用单一解析策略;采用流式解析 + 格线/OCR 互补方案

    • 尽早实现验证与评分机制,并保证可解释性

    • 使用明确的回退机制与人工审核通道;不隐藏低置信度结果

    • 完善可观测性(如成功率、置信度分布、主要失败原因及格式漂移告警)

    • 仅在小范围场景使用机器学习做区域分割,且必须经过确定性验证把关

    • 优先优化长期运营成本(安全审查、治理、部署与调试流程),而非只追求抽取准确率

    结论:为置信度而设计,而非追求完美

    生产环境中 PDF 表格提取失效根源在于金融文档本身存在多变、老旧且格式不统一的问题。常见误区是把它当成只需要更好的工具就可以解决的工程问题。而在实际应用中,系统的可靠性源自整体架构设计:包括分层解析策略、校验机制、评分体系以及明确的回退处理逻辑。

    对于银行及金融科技团队而言,目标并非单纯从 PDF 中提取表格,而是确保下游系统能够信任提取的数据,并且知道何时不可信任。这正是演示案例与生产级摄入管道系统的核心区别。

    【声明:本文由 InfoQ 翻译,未经许可禁止转载。】

    查看英文原文:https://www.infoq.com/articles/redesign-pdf-table-extraction/

    各位Cder好,我是长期混迹在金融系统开发前线的一名后端工程师。最近在帮业务线排查一个网络IO问题时,我发现了一个非常有意思的现象:每逢法定长假,我们接入的A股实时行情服务就会大量爆出超时日志,甚至引发上游服务的雪崩。经过深入的源码级排查,我意识到这不仅仅是简单的网络问题,而是业务场景与网络协议之间的碰撞。今天就来和大家硬核分享一下。

    实时金融数据流的严酷要求

    在我们这套架构里,我们需要通过WebSocket建立长连接,以极低的延迟接收股票的实时Tick信息。这对于需要进行实时计算的服务来说是刚需。但大家都知道,A股的运行时间是由各种法定节假日和调休决定的。这就意味着,我们的长连接在某些特定的日子里,会面临比平日里更早结束或者更晚开始的数据流阻断。

    撕开网络底层的痛点表象

    当我们用技术视角去透视这个问题时,节假日前后的异常其实可以归结为以下几个技术痛点:

    1. 连接的“假活”状态:A股节前提前休市后,服务端不再下发业务数据包。由于缺乏业务层的交互,如果客户端没有实现完善的应用层心跳(Ping/Pong),TCP连接很容易被沿途的路由器NAT表老化剔除,导致连接名存实亡。
    2. 重连风暴(Thundering Herd):节后开市的瞬间,如果大量断开的客户端同时发起重连请求,极易压垮行情源的网关,造成大面积的503错误。
    3. 数据反序列化地雷:由于休市期间数据管道可能会被用来做测试或重置,节后收到的首个JSON payload结构体可能发生变化,导致程序内抛出空指针或解析异常。

    优秀的API是如何做产品隔离的?

    要解决这些痛点,除了客户端要做防御外,服务端API的设计也至关重要。我查阅了多款行情API的官方文档,发现高标准的接口服务在休市状态机的处理上有一套成熟的逻辑。例如之前接入的AllTick API,在其服务端就实现了优雅的降级策略。在节后重启数据流时,它不会一上来就猛灌实时数据,而是先推送一个经过特殊标记的静态历史快照,用于验证连接质量并同步客户端状态,之后才开始稳定分发流式Tick。

    来看看底层是怎么建立这套监听机制的:

    import websocket
    import json
    
    def on_message(ws, message):
        data = json.loads(message)
        print("收到tick数据:", data)
    
    ws = websocket.WebSocketApp(
        "wss://apis.alltick.co/stock/subscribe",
        on_message=on_message
    )
    ws.run_forever()

    工程应用中的最终解决方案

    作为工程师,我们绝不能把系统的稳定性寄托在外部接口的完美无缺上。针对节假日造成的断流,我在中间件层做了如下重构:
    第一步:基于时间的黑白名单拦截。通过接入开源的交易日历库,精确计算当前是否处于开盘时间。在非交易时段,主动断开WebSocket连接,释放系统句柄资源。
    第二步:实现带有退避的重连状态机。利用指数回退(Exponential Backoff)算法处理节后开盘的重连,有效规避惊群效应。
    第三步:强类型的数据校验与缓冲。对所有通过WebSocket推过来的文本进行严格的JSON Schema校验。对于节假日异常期可能出现的缺失字段,利用本地的历史Redis缓存进行字段补齐。
    搞定这些,你就再也不用在假期结束前一晚,提心吊胆地盯着监控大屏了。

    Ubuntu 26.04 LTS (Resolute Raccoon) 正式版发布 - 现代化的企业与开源 Linux

    Ubuntu 26.04 LTS (Resolute Raccoon) GA release Apr 2026

    请访问原文链接:https://sysin.org/blog/ubuntu-2604/ 查看最新版。原创作品,转载请保留出处。

    作者主页:sysin.org


    Ubuntu 桌面

    Ubuntu 26.04 LTS 正式版发布

    Ubuntu 26.04 LTS Apps

    2026-04-23,Ubuntu 26.04 LTS 正式版按计划如期发布。

    Ubuntu 26.04 LTS 搭载 Linux 内核 7.0 和 GNOME 50 桌面环境,都是两个优雅的整数版本。

    以下是笔者对 Ubuntu 26.04 LTS(Resolute Raccoon)发布摘要总结,对比 Ubuntu 24.04 LTS (Noble Numbat) 的更新内容:

    桌面环境(Desktop)

    • 应用更新:Firefox 更新至 149/150,LibreOffice 24.2 → 25.8,Thunderbird 更新至 140 “Eclipse”,GIMP 2.10 → 3.0。
    • GNOME 50:从 46 升级至 50。支持登录后自动启动应用、优化分数缩放以减少模糊、默认等宽字体大小与 UI 字体匹配、默认安装 Sysprof 性能分析工具。
    • 默认应用替换: 文档查看器由 Evince 替换为 Papers(基于 GTK4 和 Rust)。图像查看器由 EOG 替换为 Loupe(Rust + Glycin)。终端由 GNOME Terminal 替换为 Ptyxis。视频播放器由 Totem 替换为 Showtime。音视频缩略图生成器由 Totem 缩略图器替换为 gst-thumbnailers(Rust GStreamer + Glycin)。
    • 搜索与索引:Tracker Miners 重命名为 LocalSearch(3.8.2 → 3.11),索引特定文件需勾选安装第三方软件或手动安装提取器。
    • 显示会话:Ubuntu 桌面会话仅运行在 Wayland 后端(GNOME Shell 不再支持 X.org),X11 应用可通过 XWayland 运行,其他桌面(KDE on X11, Xfce, MATE, i3 等)仍可使用 X.org。Nvidia 显卡现已完全支持 Wayland。
    • 软件管理:默认不再包含“Software & Updates”应用(可手动安装);App Center 改进(支持安装进度、自更新、Snap 消息、管理页直接卸载、触屏滚动、第三方 Deb 安装);新增 Security Center(支持家目录权限提示实验功能),附带 prompting-clientsnap。
    • 电源与性能:Power Profiles Manager 改进 (sysin),支持新硬件(尤其 AMD)、多优化驱动、电池感知(仅电池时自动提高优化级别);新增 NTSYNC 驱动,提升 Wine/Proton 上 Windows 游戏性能。
    • 安装与镜像:新增通用 ARM64 桌面 ISO(支持 VM、ACPI+EFI、骁龙 WoA 设备,含骁龙 X Elite 初始硬件支持);改进 BitLocker 保护下的 Windows 双启动体验(支持在旁安装、加密安装等高级选项)。
    • 格式与编解码:原生支持 JPEG XL;默认通过 VA-API 为 AMD 和 Intel 用户提供硬件加速视频编解码;安装时可选第三方软件包集更新(含蓝牙 AAC 编解码器)。
    • 更新与无障碍:系统更新不再弹窗抢焦点,改为通知+系统托盘图标;安装程序修复了大量屏幕阅读器无障碍问题。
    • 遥测:Ubuntu Insights 将取代 Ubuntu Report,提供对非个人识别系统指标的控制,且为选入制(之前同意不会沿用)。

    服务器与常见组件

    • OpenSSH:9.6p1 → 10.2p1;弃用 SHA1 SSHFP DNS 记录警告、移除弱 DSA 签名算法支持、新增 PerSourcePenalties、默认支持 mlkem768x25519-sha256 后量子密钥交换、新增 invalid-user 匹配选项、sshd.service 别名为 ssh.service、新增 openssh-client-gssapi 和 openssh-server-gssapi 包、不再生成主机 DSA 密钥、服务器自 1:9.6p1-3ubuntu17 起不再读取 ~/.pam_environment。
    • 时间同步:Chrony 取代 systemd-timesyncd 作为默认时间守护进程(新安装),支持 NTS(认证加密 NTP),配置片段位于 /etc/chrony/sources.d/ubuntu-ntp-pools.sources
    • ClamAV:更新至 1.4.3,新增 OneNote 附件扫描、UDF 分区提取、HTML CSS 内嵌图像提取、alz/lha(lzh) 归档提取、图像模糊哈希开关、Office 文档 VBA 提取改进、--cache-size 自定义清理文件缓存、systemd.timer 用于 freshclam、大文件限制处理改进、私有 Freshclam 镜像客户端证书认证、病毒数据库最小年龄等。
    • Django:4.2 → 5.2 LTS。
    • PHP:更新至 8.5,包含属性钩子、非对称可见性、更新 DOM API、新 URI 扩展、管道运算符、Clone With、#[\NoDiscard] 属性、常量表达式中的闭包和一等可调用对象、持久 cURL 共享句柄、array_first() 和 array_last() 等。
    • Dovecot:更新至 2.4.2(配置格式有重大变更)。
    • Postfix:默认不再以 chroot 安装,且仅有有限的 chroot 支持。
    • RabbitMQ:无法直接升级 (sysin),需手动步骤(因特性标志)。
    • Samba:更新至 4.23 版本,默认启用 SMB3 Unix 扩展、禁用 NetBIOS,并包含大量 AD/DC 相关改进、功能移除及包结构变化,升级前需注意 AD DC 组件与 i386 支持情况。。
    • Squid:6 → 7.2;新增 tls_key_log、key-extras、doh_query、cache_peer tls-client-cert-switch;移除 client_delay_access、ftp_epsv、cache_peer no-netdb-exchange、client_persistent_connections、server_persistent_connections。
    • SSSD:2.12 版本,现以 sssd 用户(而非 root)运行,需确保其可访问密钥等。
    • strace:支持彩色输出(--color、STRACE_COLORS、NO_COLOR)。
    • HAProxy:更新至 3.2 LTS;有破坏性变更(如 Runtime API 多命令检测、dynamic server 拒绝 enabled 关键字、非标准 URI 更严格解析、tune.ssl.ocsp-update 重命名为 tune.ocsp-update)。
    • DocumentDB:新增,0.108-0 版本(基于 PostgreSQL 的 MongoDB 兼容文档数据库)。
    • MySQL:8.0 → 8.4 LTS(8.4.8),移除 32 位 Server 支持(仍提供 armhf/i386 的客户端和客户端库)。
    • MySQL Shell:8.0 → 8.4。
    • PostgreSQL:更新至 18(新 I/O 子系统、虚拟生成列、uuidv7()、OAuth 2.0 认证等)。
    • Valkey:更新至 9.0.3(原子槽迁移、哈希字段过期等)。
    • 容器栈:containerd 和 runc 采用定期最新或稳定更新策略。
    • 高可用与集群:kpartx-boot 包停用(功能并入 kpartx);dmraid 包移除(建议用 mdadm 替代);Pacemaker 更新至 3。

    开发工具链

    • GCC 14 → 15.2,binutils 2.42 → 2.45,glibc 2.39 → 2.42。
    • Python 3.12 → 3.13.9(3.14 也可用)。
    • LLVM 18 → 21。
    • Rust 1.75 → 1.93(1.91、1.92 也可用)。
    • Golang 1.22 → 1.25。
    • Zig 新增,默认 0.14.1。
    • OpenJDK 21 → 25(LTS 8/11/17/21 仍可用,含 26、27 preview),其中 OpenJDK 25 在 AMD64/ARM64/s390x/PPC64EL 上 TCK 认证。
    • Spring® snaps:Gradle 和 Maven 插件可用于构建 Java 应用 ROCK 镜像。
    • GraalVM snap:支持 JDK 21/24/25。
    • .NET 8 → 10(并扩展至 IBM Power 平台),且有新版 .NET Snap。
    • PowerShell snap:扩展至 arm64、s390x、ppc64el 架构。

    企业相关

    • authd(云认证)更新:EntraID 提供器修复与改进、新增 Google 提供器、支持 EntraID 设备注册、新增 authctl 命令行工具、UID/GID 处理等修复。
    • ADSys:Active Directory Group Policy 客户端支持最新 Polkit,改进证书注册。

    安全

    • AppArmor:新增多个应用沙盒配置文件(可能需报 bug 调整)。
    • TPM 全盘加密:支持密码短语管理与恢复密钥再生、更好固件更新集成。
    • OpenSSL:支持 QUIC、后量子密码算法(ML-KEM、ML-DSA、SLH-DSA)、更广 EVP 覆盖及性能改进。
    • cargo-auditable:Launchpad 上构建的 Rust 包可选启用,二进制内嵌入依赖元数据供漏洞排查。

    硬件支持

    • NVIDIA Dynamic Boost:在支持的 N 卡笔记本上默认启用(仅通电且 GPU 负载足够时生效,电池不生效)。
    • Intel 显卡:支持 Core™ Ultra Xe2 集成 Arc™、Arc™ B580/B570 Battlemage 独立 GPU;Blender 等光线追踪性能提升;Battlemage 上 AVC/JPEG/HEVC/AV1 硬件加速编码;Intel® Compute Runtime 新 CCS 优化;调试支持;oneAPI Level Zero Ray Tracing 提升 AI/ML(Embree on SYCL)。
    • Nvidia 挂起恢复:专有驱动中启用 suspend-resume 以防唤醒时损坏和冻结。
    • ARM64 桌面平台:linux-generic 内核提供更广 UEFI 启动兼容 (sysin)。
    • Raspberry Pi:新启动分区布局(测试新启动资源再提交,要求固件较新);Pi 桌面镜像改为基于 desktop-minimal 种子(默认应用更少,列出移除清单并可手动清理);swap 由 cloud-init 处理;RISC-V 仅支持 RVA23S64 ISA(无硬件时仅 QEMU -cpu rva23s64)。
    • IBM Z:最低要求 z15(不支持 z14/LinuxONE II 及更旧),z15 及更新性能提升。

    通用/底层变化

    • sudo-rs:成为默认 sudo 提供器;原 sudo 重命名为 sudo.ws;sudo-ldap 包移除(建议用 PAM 做 LDAP 认证)。
    • rust-coreutils:操作系统核心工具(如 base64 等)默认由该包提供(性能提升),同时仍提供经典 GNU coreutils 并可切换。
    • Linux 内核:6.8 → 7.0;新增 sched_ext(eBPF 调度策略)、linux-lowlatency 包退休(改用 linux-generic + lowlatency-kernel 调 GRUB)。
    • systemd 255 → 259:26.04 是最后支持 System V 服务脚本兼容的版本;默认使用上游 tmp.mount 单元(/tmp 现为 tmpfs)。
    • Netplan 1.0 → 1.2:自定义 systemd-networkd-wait-online 逻辑、SR-IOV embedded-switch-mode 改进、解析器跳过损坏配置、ProtonVPN/Azure Linux 修复、wpa-psk-sha256 WiFi、NetworkManager 后端 routing-policy、非标准 OVS 设置支持。
    • APT 2.7 → 3.1:新依赖求解器、TLS/哈希从 GnuTLS/gcrypt 切换到 OpenSSL、apt(8) 增加自动分页器、apt-key 移除(直接用 gpgv)。
    • Dracut:取代 initramfs-tools 作为默认 initramfs 基础设施(仍支持 initramfs-tools 并可切换)。

    Ubuntu Desktop 简介

    安全、现代,被数百万人使用的操作系统

    全球数百万 PC 和笔记本电脑正在使用的第一开源操作系统。

    专业开发者的首选

    每次 Ubuntu 发布都会带来最新的应用程序、库和工具链。Ubuntu 是主要 IDE、游戏开发工具和 AI/ML 软件的首要平台。

    满足你日常使用的所有需求

    Ubuntu 提供网页浏览、通讯、游戏与内容创作的必备应用,包括 Firefox、Chrome、Discord、Steam 和 OBS Studio,满足你日常计算的所有需求。

    为隐私与安全而设计

    通过定期更新和内置安全功能,Ubuntu 优先保护用户隐私与系统完整性,是注重数据安全用户的可靠之选。

    深度集成企业工具

    Ubuntu 无缝集成企业环境。通过 Ubuntu Pro 订阅,你可以获得运行 Ubuntu 于高安全环境所需的所有工具:安全修补、设备管理等。任何人都可以免费在最多 5 台设备上使用 Ubuntu Pro,企业用户可免费试用 30 天

    完全开源

    Ubuntu 始终免费供下载、使用与分享。我们相信开源的力量;如果没有全球志愿开发者社区,就不会有 Ubuntu。

    Ubuntu Server 简介

    借助 Ubuntu Server 实现横向扩展

    Ubuntu Server 为企业数据中心(无论是公有云还是私有云)提供经济性与技术性的可扩展能力。无论你是要部署 OpenStack 云、Kubernetes 集群,还是一个拥有 50,000 个节点的渲染农场,Ubuntu Server 都能提供业界领先的高性价比横向扩展性能。

    性能与多功能性

    Ubuntu Server 获得领先硬件厂商(OEM)认证,提供精简的初始部署,并包含集成的部署与应用建模工具,因此你可以最大化利用基础设施资源——无论你在部署 NoSQL 数据库、Web 集群,还是云环境 (sysin)。

    可靠的发布周期

    Ubuntu Server 的长期支持(LTS)版本默认为 Ubuntu Main 软件仓库中约 2,500 个软件包提供五年的标准安全更新。每六个月发布一次的中期版本带来新功能,而硬件支持更新则为所有受支持的 LTS 版本提供最新机器的兼容支持。

    最广泛使用且值得信赖的平台

    根据 OpenLogic 2025 开源生态支持报告,Ubuntu 是私有云实施的基础,也是全球使用最多的 Linux 发行版(连续第三年位居第一)。

    下载地址

    Ubuntu 26.04 LTS (Resolute Raccoon) GA, 2026-04-23

    • Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit PC (AMD64 x86_64) desktop image
    • Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit PC (ARMv8 AArch64) desktop image
    • Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit PC (AMD64 x86_64) server install image
    • Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit ARM (ARMv8 AArch64) server install image
    • 请访问:https://sysin.org/blog/ubuntu-2604/

    虚拟机模板下载:


    更多:Linux 产品链接汇总

    各位老哥们好,我是一个毕业工作 2 年的新人,最近领导在给我安排工作的时候我之前的工作喜欢和工作方式好像和他期待的不太一样。想发出来让大家分析下是我太学生思维了吗?


    事件一 机器人验证

    最近公司买了个机器人,他安排我去研究下,然后跑一个案例,能让他动起来。当时的原话是“你去跑一下网上这个案例,然后了解下他是怎么驱动起来的”

    然后我就正常的跑官方案例,中间遇到很多环境,沟通的问题。重点是我对他的了解 可能只在表面,就是他是个什么,有哪些重要技术实现,然后基础的操作逻辑是什么。

    但是事后领导让我分享的时候,会问的非常非常细致,比如这个技术 ROS 现在市场上使用情况怎么样,有没有其他控制方式,机器人我们如果自己独立二开应该是什么流程。

    我总结一下是,我收到的消息是干 A 然后我根据字面意思理解为要做的任务,加一些必要的基础了解作为任务去做。
    如果完全懂是 100 分,我感觉根据我的理解和他给我干的天数我做这个任务是 30 分。

    但是他的要求和提问的内容我觉得算是 80 分。

    事件二 硬件加速卡

    最近让我调用一个 CGRA 的基础技术卡,
    然后我就去看了下但是我只看了具体型号的卡,他的核心创新是什么,里面很多专有名词,我只理解个大概没有很深入的理解。

    后面他问的时候就问的非常深入和广,比如这个 CGRA 技术实现原理,和 gpu ,ASIC 对比有什么优缺点,现在市场上还有谁在用。等等。


    由此我有一个疑问,他交给我的任务可能是一句具体的话“跑下这个案例”“调研下 xxx 加速卡” 我理解的是字面意思+一些基础的必要知识信息。

    但是他后续给我的资源(天数比较少)和要求给我的感觉是他需要一个很懂,或者是至少是 70 分的理解水平,不只是任务本身,他的生态,原理,对比起等.....

    所有我想问下大多数工作都是这样的吗?是我太学生思维了还是一般情况下都会明确的告诉你你要干到是什么程度....

    期望各位工作久了的前辈解惑下

    看到很多 V 友发帖说 claude 账号被封问题,我目前是使用 GooglePlay 订阅的 20 美元的 Pro 套餐,已经稳定订阅一年左右了。
    目前感觉额度不够用,想升级到 5X 的 MAX(对应官网是 100 美元的)。
    请问下,之前出现封号的都是 MAX 套餐的吗?是 100 美元还是 200 美元的封号概率大些,还是说只要升级到任意 MAX 套餐都会有大概率被封。
    目前我使用的是台湾住宅 IP(购买 IP 时人家是这样宣传的)

    除了做 demo ,任何一个需要稳定性的系统都不应该使用 vibe coding 实现。全黑盒,完全不可控。
    之前的一家公司,PM 开始自己 vibe coding ,推到上线后结果完全不可维护,到最后还是研发来擦屁股。产品爽了,最后烂摊子研发全接走?

    https://developers.openai.com/api/docs/pricing?latest-pricing=standard

    Model Input Credits Output Credits
    GPT-5.3-Codex 43.75 350
    GPT-5.4 62.50 375
    GPT-5.5 125 750

    天塌了啊,最新 openai 的模型越来越贵,穷人要用不起了啊

    看 gpt5.5 的 token 价格翻倍了感觉不妙,结果一看 codex 消耗果然相比 5.4 也翻倍了

    本来 codex 的 credit 计算规则改了后就明显消耗量加快了,结果现在 5.5 用量还翻倍了

    然后 codex 中 5.5 默认的推理强度还是 extra high 。。。。。

    当作和 opus 一样的高级模型好了。。。。

    感觉很复杂,现在工作难度、工作强度相比之前大幅下降,但是工作内容的边界借助 AI 大幅拓展了,工作中的成就感其实是上升的,看到各种新模型的能力,也会觉得很欣喜

    另一方面也确实会有一点被全面替代,无力抵抗的焦虑

    好在目前这些感受还不影响我

    简单试了下天气卡片,中文英文都试了,太简陋了:
    图片.png

    中文:

    创建一个包含 CSS 和 JavaScript 的单一 HTML 文件,用于生成动画天气卡片。卡片应该通过不同的动画直观地表示以下天气状况:
    
    风:(例如,移动的云朵、摇摆的树木或风线)
    
    雨:(例如,下落的雨滴、形成的水坑)
    
    阳光:(例如,闪耀的光线、明亮的背景)
    
    雪:(例如,下落的雪花、积累的雪)
    
    所有天气卡片应并排显示,卡片应该有深色背景。
    
    在这个单一文件中提供所有 HTML 、CSS 和 JavaScript 代码。JavaScript 应该包含一种切换不同天气状况的方式(例如,一个函数或一组按钮)以展示每种天气的动画效果。
    

    英文:

    Create a single HTML file containing CSS and JavaScript to generate an animated weather card. The card should visually represent the following weather conditions with distinct animations: Wind: (e.g., moving clouds, swaying trees, or wind lines) Rain: (e.g., falling raindrops, puddles forming) Sun: (e.g., shining rays, bright background) Snow: (e.g., falling snowflakes, snow accumulating) Show all the weather card side by side The card should have a dark background. Provide all the HTML, CSS, and JavaScript code within this single file. The JavaScript should include a way to switch between the different weather conditions (e.g., a function or a set of buttons) to demonstrate the animations for each.
    

    现在很多社会现象我觉得不好,但是往往它却很流行很潮流。下面列几个
    1 无论男女,裤子前面的绳子,都快拖到地上了,这不是夸张,当然多数没那么长,但是我看起来总有违和感。我也有这样的裤子,每次我都塞到裤子,外面看不到。我依稀记得,在我小时候,村子里的傻子会把裤腰带这么松松垮垮的挂在那里。
    2 有的男的跑步,穿紧身裤,胯下之物就那么突兀显现着。虽然女的的漏 b 的没那么违和,但是男的这样我真的不忍直视。

    平时有不少,真的行之为文的时候,又想不起来了。 那就这些吧。

    各位老哥们好,我是一个毕业工作 2 年的新人,最近领导在给我安排工作的时候我之前的工作喜欢和工作方式好像和他期待的不太一样。想发出来让大家分析下是我太学生思维了吗?


    事件一 机器人验证

    最近公司买了个机器人,他安排我去研究下,然后跑一个案例,能让他动起来。当时的原话是“你去跑一下网上这个案例,然后了解下他是怎么驱动起来的”

    然后我就正常的跑官方案例,中间遇到很多环境,沟通的问题。重点是我对他的了解 可能只在表面,就是他是个什么,有哪些重要技术实现,然后基础的操作逻辑是什么。

    但是事后领导让我分享的时候,会问的非常非常细致,比如这个技术 ROS 现在市场上使用情况怎么样,有没有其他控制方式,机器人我们如果自己独立二开应该是什么流程。

    我总结一下是,我收到的消息是干 A 然后我根据字面意思理解为要做的任务,加一些必要的基础了解作为任务去做。
    如果完全懂是 100 分,我感觉根据我的理解和他给我干的天数我做这个任务是 30 分。

    但是他的要求和提问的内容我觉得算是 80 分。

    事件二 硬件加速卡

    最近让我调用一个 CGRA 的基础技术卡,
    然后我就去看了下但是我只看了具体型号的卡,他的核心创新是什么,里面很多专有名词,我只理解个大概没有很深入的理解。

    后面他问的时候就问的非常深入和广,比如这个 CGRA 技术实现原理,和 gpu ,ASIC 对比有什么优缺点,现在市场上还有谁在用。等等。


    由此我有一个疑问,他交给我的任务可能是一句具体的话“跑下这个案例”“调研下 xxx 加速卡” 我理解的是字面意思+一些基础的必要知识信息。

    但是他后续给我的资源(天数比较少)和要求给我的感觉是他需要一个很懂,或者是至少是 70 分的理解水平,不只是任务本身,他的生态,原理,对比起等.....

    所有我想问下大多数工作都是这样的吗?是我太学生思维了还是一般情况下都会明确的告诉你你要干到是什么程度....

    期望各位工作久了的前辈解惑下