2026年4月

刚刚，DeepSeek 在官方公众号发文宣布，全新系列模型 DeepSeek-V4 的预览版本正式上线，并同步开源！

 

DeepSeek-V4 拥有百万字超长上下文，在 Agent 能力、世界知识和推理性能三大维度上均实现了国内与开源领域的领先。

 

秉承 DeepSeek 一贯的开放精神，本次发布的模型按大小分为两个版本，欢迎开发者、研究者和企业用户前往体验和下载。

 

模型按大小分为两个版本：

  • DeepSeek-V4 模型开源链接：

https://huggingface.co/collections/deepseek-ai/deepseek-v4

https://modelscope.cn/collections/deepseek-ai/DeepSeek-V4

  • DeepSeek-V4 技术报告：

https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf

 

Pro 版本面向的是高性能，Flash 版本则主攻性价比。

 

API 服务已同步更新，通过修改 model_name 为 deepseek-v4-pro 或 deepseek-v4-flash 即可调用。

 

从技术报告来看，有一点特别值得注意，DeepSeek V4 并不是只在 NVIDIA 体系内做优化，而是明确将细粒度专家并行（EP）方案同时在 NVIDIA GPU 和华为 Ascend NPU 上完成验证，这说明其推理路径已经具备跨算力平台的适配能力。但在开源层面，当前释放的仍主要是基于 CUDA 的 MegaMoE 和 DeepGEMM，底层实现深度绑定 NVIDIA 工具链。

 

另外，官方 API 页面还提到，受限于高端算力，目前 V4-Pro 的服务吞吐仍有限，预计下半年昇腾 950 超节点批量上市后，Pro 价格会大幅下调。这意味着，DeepSeek 一边在现有 CUDA 生态内持续做极致优化，一边也在为华为 Ascend 等多算力环境预留空间，开始尝试把模型运行时从单一硬件依赖中解耦出来。

DeepSeek-V4-Pro：性能比肩顶级闭源模型

  • Agent 能力大幅提高：相比前代模型，DeepSeek-V4-Pro 的 Agent 能力显著增强。在 Agentic Coding 评测中，V4-Pro 已达到当前开源模型最佳水平，并在其他 Agent 相关评测中同样表现优异。目前 DeepSeek-V4 已成为公司内部员工使用的 Agentic Coding 模型，据评测反馈使用体验优于 Sonnet 4.5，交付质量接近 Opus 4.6 非思考模式，但仍与 Opus 4.6 思考模式存在一定差距。

 

  • 丰富的世界知识：DeepSeek-V4-Pro 在世界知识测评中，大幅领先其他开源模型，仅稍逊于顶尖闭源模型 Gemini-Pro-3.1。

 

  • 世界顶级推理性能：在数学、STEM、竞赛型代码的测评中，DeepSeek-V4-Pro 超越当前所有已公开评测的开源模型，取得了比肩世界顶级闭源模型的优异成绩。

 

DeepSeek-V4-Flash：主攻性价比

 

  • 相比 DeepSeek-V4-Pro，DeepSeek-V4-Flash 在世界知识储备方面稍逊一筹，但展现出了接近的推理能力。而由于模型参数和激活更小，相较之下 V4-Flash 能够提供更加快捷、经济的 API 服务。

 

  • 在 Agent 测评中，DeepSeek-V4-Flash 在简单任务上与 DeepSeek-V4-Pro 旗鼓相当，但在高难度任务上仍有差距。

 

百万上下文已成标配

 

官方公众号文章中介绍，DeepSeek-V4 开创了一种全新的注意力机制，在 token 维度进行压缩，结合 DSA 稀疏注意力（DeepSeek Sparse Attention），实现了全球领先的长上下文能力，并且相比于传统方法大幅降低了对计算和显存的需求。

 

从现在开始，1M（一百万）上下文将是 DeepSeek 所有官方服务的标配。

 

DeepSeek-V4 和 DeepSeek-V3.2 的计算量和显存容量随上下文长度的变化

 

值得注意的是，DeepSeek-V4 还针对 Claude Code 、OpenClaw、OpenCode、CodeBuddy 等主流的 Agent 产品进行了适配和优化，在代码任务、文档生成任务等方面表现均有提升。下图为 V4-Pro 在某 Agent 框架下生成的 PPT 内页示例：

 

目前，DeepSeek API 已同步上线 V4-Pro 与 V4-Flash，支持 OpenAI ChatCompletions 接口与 Anthropic 接口。访问新模型时，base_url 不变, model 参数需要改为 deepseek-v4-pro 或 deepseek-v4-flash。

 

V4-Pro 和 V4-Flash 均提供 1M 上下文长度，并同时支持非思考模式与思考模式。后者可通过 reasoning_effort 参数调节思考强度（可选 high 或 max）。对于复杂的 Agent 类任务，建议启用思考模式并将强度设为 max。具体调用方式及参数设置请查阅 API 文档。

 

需注意：旧接口中的 deepseek-chat 和 deepseek-reasoner 两个模型名将于 2026 年 7 月 24 日 停止使用。过渡期内，它们分别指向 deepseek-v4-flash 的非思考模式与思考模式。

拆解关键技术创新

混合注意力机制

 

CSA 与 HCA 是关键创新是 V4 系列最关键的创新之一。传统注意力机制处理长序列时，每个 token 都需要与所有历史 token 计算注意力，导致计算量随序列长度平方增长。V4 设计了两种互补的压缩注意力架构：

 

压缩稀疏注意力（CSA）：首先将每 m 个 token 的 KV 缓存压缩为 1 个条目（m=4），然后使用 DeepSeek 稀疏注意力，每个查询 token 仅需关注 k 个压缩后的 KV 条目（k=512~1024），引入 Lightning Indexer（轻量索引器）高效选出重要的压缩块，整体将序列长度压缩至 1/m。

 

高度压缩注意力（HCA）：采用更激进的压缩率（m'=128），将每 128 个 token 压缩为 1 个，保持稠密注意力（不稀疏），适用于信息密度较低的场景，CSA 与 HCA 以交错方式堆叠，兼顾效率与表达力。

 

工程亮点：支持 RoPE 部分位置编码（仅最后 64 维），维持相对位置信息；引入滑动窗口注意力分支捕获局部依赖；采用 Attention Sink 技术让注意力得分总和可以不为 1。

 

此外，Engram 和 mHC 两个版块上的创新也同样很关键。

Engram 记忆模块

 

首先是 Engram (条件记忆模块)：这是 DeepSeek 创始人梁文锋署名论文中的核心概念。它试图解决传统 Transformer 架构将记忆与推理混为一谈的根本问题，模型既需要用注意力去“检索”知识，又需要用注意力去“推理”。

 

工作原理是 Engram 将模型能力从连续的神经计算转移到确定性的哈希查找。它将那些固定的、需要记忆的模式（如实体名、固定搭配）存入一个类似“字典”的查找表中，使模型能以 O(1) 的复杂度快速调用，而无需消耗大量算力去“计算”记忆。

 

实际效果：这使得模型能将宝贵的注意力资源解放出来，专注于复杂的组合与推理任务。在实验阶段，一个集成了 270 亿参数 Engram 的模型，在参数和浮点运算次数（FLOPs）同等的情况下，性能超过了纯 MoE 模型。

mHC 流形约束超连接

 

mHC (流形约束超连接，Manifold-Constrained Hyper-Connections)：这是一个旨在解决极深网络训练不稳定性的创新。传统 Transformer 模型在堆叠到很深的时候，容易出现梯度爆炸或消失等信号 degradation 问题。

 

通过将连接矩阵约束在双随机矩阵流形上，mHC 确保了信号增益在每一层都保持稳定（约 1.6 倍），从而让深层表示得以保留。这使训练更深、更强的模型成为可能，将计算利用率从行业平均的约 60%提升到了 85%以上，同时减少了 30%+的原始计算依赖。

 

除了核心架构的创新，V4 在训练和推理工程层面也进行了大量优化。

Muon 优化器：万亿参数的新训练范式

V4 首次在万亿参数 MoE 模型上大规模采用 Muon 优化器。

 

团队设计了一套混合 Newton-Schulz 迭代策略：前 8 步使用快速收敛系数，后 2 步切换为稳定系数，在正交化精度与收敛速度间取得最优。为解决 ZeRO 并行与 Muon 需要完整梯度矩阵的矛盾，团队设计了混合 ZeRO 分配策略——稠密参数限制并行度并用背包算法负载均衡，MoE 专家参数独立展平后均匀分布。进一步地，MoE 梯度在同步前以随机舍入方式量化到 BF16，通信量减半；同时采用“all-to-all + 本地 FP32 求和”规避低精度加法器的累积误差。

FP4 量化：无损压缩与推理加速

V4 在 MoE 专家权重和 CSA 索引器的 QK 路径上应用了 FP4 量化感知训练。一个关键发现是：FP4 到 FP8 的解量化是无损的——因为 FP8 拥有更大的动态范围，FP4 子块的细粒度尺度信息可以被完全吸收。这使得整个量化流程可以无缝复用现有的 FP8 训练框架。

在推理和 RL rollout 阶段，直接使用真实 FP4 权重，实现实时的显存节省和计算加速。对索引器分数的 FP32→BF16 量化更是带来了 2 倍加速，同时保持 99.7%的召回率。

专家并行：通信-计算深度融合

MoE 模型的专家并行受限于跨节点通信。传统方案中，Dispatch 和 Combine 阶段是纯通信瓶颈。V4 的创新是将专家切分为“波”——每个波包含一小部分专家。当波内专家的通信完成后，计算立即开始，无需等待其他专家。稳态下，当前波的计算、下一波的 token 传输、已完成专家的结果发送三者同时进行。这一细粒度流水线在 NVIDIA GPU 和华为昇腾 NPU 上实现 1.5~1.73 倍加速，在 RL rollout 等高敏感场景下可达 1.96 倍。

 

团队还提出了硬件设计建议：当前每 GBps 互联带宽足以覆盖 6.1 TFLOP/s 的计算需求，盲目增加带宽会带来收益递减。这一洞察对未来 AI 加速器设计具有指导意义。

确定性内核：大规模训练的可复现性保障

训练万亿参数模型时，非确定性行为可能导致难以调试的 loss 尖峰。

V4 实现了全面的批量不变性和确定性：任何 token 的输出不因 batch 内位置而改变；每次运行的梯度累积顺序保持一致。技术难点包括：注意力反向传播中放弃 split-KV 方案，改用双核策略（满波时单 SM 处理、部分波时多 SM 协作但保证累积顺序）；MoE 反向传播通过 rank 内 token 顺序预处理加 rank 间 buffer 隔离解决竞争；mHC 中小矩阵乘法（输出维度仅 24）被迫使用 split-k 时，先输出各 split 部分再通过专用核确定性归约。

这些工程打磨使得大规模训练的可复现性达到新高度。

TileLang DSL：高性能内核的高效开发

为支撑数百个融合核的开发，V4 团队采用 TileLang 领域特定语言，并实现了主机代码生成——将数据类型、形状约束等元数据嵌入生成的 launcher 中，运行时验证开销从数十微秒降至 1 微秒以下。同时集成 Z3 SMT 求解器进行形式整数分析，支持向量化优化、屏障插入等高级编译优化。严格对齐数值精度与 CUDA 工具链，保证 bit 级可重现性。

训练稳定性：预知路由与 SwiGLU 钳位

万亿 MoE 模型的训练稳定性是一大挑战。V4 识别出 loss 尖峰与 MoE 层异常值的强相关性，且路由机制会加剧异常值。为此设计了预知路由：在 step t 使用历史参数θ_{t-Δt}计算路由索引，当前参数仅做特征计算，通过管线执行与通信重叠将额外开销控制在 20%，且仅在尖峰发生时动态激活。

 

配合 SwiGLU 钳位（线性分量钳位到[-10,10]，门控分量上界钳位到 10），有效消除了异常值，且不影响性能。

框架层优化：长上下文 RL 落地

V4 的框架优化覆盖了训练与推理全流程：

 

  • 上下文并行适配：两阶段通信策略解决压缩边界跨 rank 的问题，每个 rank 发送最后 m 个未压缩 KV，all-gather 后融合为完整序列。

  • 张量级激活检查点：扩展自动微分框架，支持对单个张量标注重计算，框架自动计算最小重计算子图，释放显存并复用指针，开发者无需关心底层内存细节。

  • 异构 KV 缓存管理：分离状态缓存（SWA+未就绪压缩 token）和经典 KV 缓存，支持磁盘存储以实现共享前缀请求的零重复预填充。

后训练范式：同策略蒸馏

V4 的后训练采用“独立专家训练→同策略蒸馏”两阶段范式。首先针对数学、代码、Agent、指令跟随等领域独立训练专家模型，每个专家经过 SFT 和 GRPO 强化学习，支持三种推理模式（Non-think/Think High/Think Max）。

 

特别地，使用了生成式奖励模型替代传统标量奖励模型，模型的 actor 与 judge 角色统一，将推理能力内化到评估中。

 

然后通过同策略蒸馏将十多个专家融合到一个统一模型。采用逆向 KL 散度作为目标，并使用全词表 logit 蒸馏（而非 token 级 KL 估计），梯度估计更稳定。工程上，教师权重 offload 到分布式存储，仅缓存最后一层 hidden states，训练样本按教师索引排序确保每个教师头只加载一次，使得在万亿参数级别进行多教师蒸馏成为现实。

 

不得不说，DeepSeek-V4-Pro-Max（最大推理强度模式）在多项基准上重新定义了开源模型的天花板：

 

  • 知识：SimpleQA-Verified 达到 57.9%，远超前代开源模型（约 30%）；

  • 编程：Codeforces Elo 3206 分，排名人类第 23，首次有开源模型在该任务上追平 GPT-5.4；

  • Agent：SWE-Verified 80.6%，接近 Claude Opus 4.6 的 80.8%；Terminal Bench 2.0 67.9%，与 GPT-5.4 的 68.5%持平；

  • 中文任务：功能性写作以 62.7%的胜率优于 Gemini 3.1 Pro，创意写作在写作质量维度达到 77.5%胜率。

 

V4-Flash-Max 则以极低成本实现了与 GPT-5.2 和 Gemini 3.0 Pro 相当的推理性能，证明了高效架构的可行性。

过去一年 DeepSeek 重要发布回顾

 

2025 年除夕夜，当大多数用户还沉浸在年味中时，DeepSeek 低调发布了DeepSeek-R1。没有发布会、没有铺天盖地的宣发，但几天之内，这个模型迅速在技术社区、研究圈与开发者社群中扩散开来。事后来看，R1 更像是一个信号：推理模型，开始从“研究话题”走向“工程现实”。

 

DeepSeek 发布了在数学、代码编写和逻辑推理方面表现卓越的 DeepSeek-R1 模型。其性能直追 OpenAI o1，并能够展示详尽的思维链。该模型通过 MIT 协议开源了相关权重和代码，不仅产生了深远的技术影响，更直接重塑了全球开源与商业大模型，乃至中美大模型的技术竞争格局。

 

R1 之后：持续迭代，而非“一次性爆款”。

 

3 月 25 日，DeepSeek V3 模型已完成小版本升级，欢迎前往官方网页、APP、小程序试用体验（关闭深度思考），API 接口和使用方式保持不变。

 

DeepSeek 反馈称此次 DeepSeek-V3 的小版本升级，版本号为 V3-0324，主要聚焦于体验优化和性能提升。在官方网页、App 和小程序中，用户关闭“深度思考”功能，可获取更快的响应速度，适合对实时性要求高的场景（如简单问答、代码片段生成）。

 

5 月 28 日，DeepSeek R1 模型已完成小版本升级，版本为 DeepSeek-R1-0528。这款开源大模型支持 128K 超长上下文，中文能力超越 GPT-4-Turbo 登顶 SuperCLUE 榜首，代码性能媲美顶级闭源模型。亮点包括：处理整本小说/超长文档的"大海捞针"能力、MIT 开源协议支持商用、免费开放使用。适用场景涵盖企业文档分析、教育科研、编程辅助等。

 

8 月 21 日，DeepSeek-V3.1 正式发布。本次升级包含以下主要变化：

 

  • 混合推理架构：一个模型同时支持思考模式与非思考模式；

  • 更高的思考效率：相比 DeepSeek-R1-0528，DeepSeek-V3.1-Think 能在更短时间内给出答案；

  • 更强的 Agent 能力：通过 Post-Training 优化，新模型在工具使用与智能体任务中的表现有较大提升。

 

官方 App 与网页端模型已同步升级为 DeepSeek-V3.1。用户可以通过“深度思考”按钮，实现思考模式与非思考模式的自由切换。

 

DeepSeek-V3.1 上下文已扩展为 128K。同时，API Beta 接口支持了 strict 模式的 Function Calling，以确保输出的 Function 满足 schema 定义。

 

9 月 22 日，DeepSeek-V3.1 已更新至 DeepSeek-V3.1-Terminus 版本。据 DeepSeek 介绍，此次更新在保持模型原有能力的基础上，针对用户反馈的问题进行了改进，包括：语言一致性：缓解中英文混杂、偶发异常字符等情况。在 Agent（智能体）能力方面，进一步优化 Code Agent 与 Search Agent 的表现，DeepSeek-V3.1-Terminus 的输出效果相比前一版本更加稳定。

9 月 29 日，DeepSeek 发布 DeepSeek-V3.2-Exp 模型，这是一个实验性（Experimental）的版本。

 

作为迈向新一代架构的中间步骤，V3.2-Exp 在 V3.1-Terminus 的基础上引入了 DeepSeek Sparse Attention（一种稀疏注意力机制），针对长文本的训练和推理效率进行了探索性的优化和验证。

 

DeepSeek Sparse Attention（DSA）首次实现了细粒度稀疏注意力机制，在几乎不影响模型输出效果的前提下，实现了长文本训练和推理效率的大幅提升。

 

12 月 1 日，DeepSeek 官方同时发布两个正式版模型：DeepSeek-V3.2 和 DeepSeek-V3.2-Speciale。

 

DeepSeek-V3.2 的目标是平衡推理能力与输出长度，适合日常使用，例如问答场景和通用 Agent 任务场景。

 

在公开的推理类 Benchmark 测试中，DeepSeek-V3.2 达到了 GPT-5 的水平，仅略低于 Gemini-3.0-Pro；相比 Kimi-K2-Thinking，V3.2 的输出长度大幅降低，显著减少了计算开销与用户等待时间。

 

DeepSeek-V3.2-Speciale 的目标是将开源模型的推理能力推向极致，探索模型能力的边界。

V3.2-Speciale 是 DeepSeek-V3.2 的长思考增强版，同时结合了 DeepSeek-Math-V2 的定理证明能力。该模型具备更好的指令跟随、数学证明与逻辑验证能力，在主流推理基准测试上的性能表现媲美 Gemini-3.0-Pro。

 

V3.2-Speciale 模型成功斩获 IMO 2025（国际数学奥林匹克）、CMO 2025（中国数学奥林匹克）、ICPC World Finals 2025（国际大学生程序设计竞赛全球总决赛）及 IOI 2025（国际信息学奥林匹克）金牌。其中，ICPC 与 IOI 成绩分别达到了人类选手第二名与第十名的水平。

DeepSeek 官方表示，在高度复杂任务上，Speciale 模型大幅优于标准版本，但消耗的 Tokens 也显著更多，成本更高。目前，DeepSeek-V3.2-Speciale 仅供研究使用，不支持工具调用，暂未针对日常对话与写作任务进行专项优化。

 

再然后到了 2026 年 1 月 13 日，喜欢闷声做大事的 DeepSeek 再次发布重大技术成果，在其 GitHub 官方仓库开源了新论文与模块 Engram，论文题为 “Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models”，梁文锋再次出现在合著者名单中。

 

与传统的大模型架构相比，该方法提出了一种新的“查—算分离”机制，通过引入可扩展的查找记忆结构，在等参数、等算力条件下显著提升模型在知识调用、推理、代码、数学等任务上的表现。代码与论文全文均已开源。

 

论文地址：https://github.com/deepseek-ai/Engram/blob/main/Engram_paper.pdf

代码地址：https://github.com/deepseek-ai/Engram

 

这种查和算分离的 Engram 新方法的整体架构如下图所示：

 

我们为什么需要 Engram ？

 

目前主流的大语言模型架构依然基于 Transformer 和 Mixture-of-Experts（MoE）结构。MoE 是目前推进参数规模和能力扩展的关键技术之一，通过动态路由机制，只激活部分参数以降低计算成本，同时在任务容量方面实现大规模扩展。DeepSeek 自家系列模型（如 DeepSeek V2、DeepSeek V3 等）也采用了先进的 MoE 方法进行扩展训练。

 

但在这些传统的 Transformer 架构（无论是 Dense 还是 MoE）中，模型的参数实际上承担着两种截然不同的角色：

 

事实性记忆（Memorization）： 存储海量的知识事实。例如，“法国的首都是哪里？”、“世界最高的山脉是哪座”等。这类信息相对死板，更多依赖于“查表”式的检索。

 

逻辑推理与计算（Calculation）： 负责复杂的逻辑链条、多步推理和情境理解。例如，“根据这段代码的逻辑推导可能的 Bug”、“解析一段复杂的哲学论证”。

 

目前的大语言模型倾向于将这两者混在一起。当你试图让模型记住更多知识时，你不得不增加参数量。而在传统的 Dense 模型中，参数量增加意味着前向传播时的计算量（FLOPs）也会同步激增。MoE 架构虽然通过稀疏激活解决了“算力随参数同步爆炸”的问题，但 DeepSeek 研究发现，MoE 专家在处理“死记硬背”的任务时依然不够高效。

 

神经网络本质上是连续的数学变换，用高昂的矩阵运算去模拟简单的“查表检索”，本身就是一种极大的浪费。DeepSeek 的 Engram 正是为了打破这一困境——“该查表的查表，该算的算”。

参考链接：https://mp.weixin.qq.com/s/8bxXqS2R8Fx5-1TLDBiEDg

今日，DeepSeek-V4-Pro 1.6T 旗舰模型(1.86 万亿参数）及 DeepSeek-V4-Flash 284B 高效模型（2840 亿）正式发布。由智源研究院牵头研发的众智 FlagOS 第一时间对两个“巨无霸”模型进行全量适配，已经完成 DeepSeek-V4-Flash 在 8 款以上 AI 芯片上的全量适配与推理部署，包括海光、沐曦、华为昇腾、摩尔线程（FP8）、昆仑芯、平头哥真武、天数、英伟达（FP8）等芯片。FlagOS 同时正在推进 DeepSeek-V4-Pro 模型在多个芯片的迁移适配，后续即将开源。

首先完成在八款芯片适配的 DeepSeek-V4-Flash 采用混合专家（MoE）架构，总参数量 284B，激活参数仅 13B，支持 100 万 token 上下文长度。该模型在架构上引入了混合注意力机制（结合压缩稀疏注意力 CSA 与高度压缩注意力 HCA，大幅提升长上下文效率）、流形约束超连接（mHC，增强跨层 信号传播稳定性）以及 Muon 优化器（加速收敛、提升训练稳定性）。预训练数据超过 32Ttoken，后训练采用两阶段范式——先通过 SFT 和 GRPO 强化学习独立培养领域专家，再通过在线策略蒸馏将多领域能力统一整合到单一模型中。在最大推理力度模式（Flash-Max）下，给予更大思考预算使其推理能力可接近 Pro 版本水平；受限于参数规模，在纯知识类任务和最复杂的 Agent 工作流上略逊于 Pro。

 

围绕 DeepSeek-V4-Flash 多芯适配，此次 FlagOS 系统软件技术栈突破了三大关键技术：FlagGems 全算子替代（实现多芯片统一适配）、为 o-group 采用独立张量并行策略解锁更多低显存场景、以及“FP4+FP8 混合精度”的原生权重到 FP8/BF16 的精度路径转换。当下国内出货的 AI 芯片，都没有 FP4 的支持。英伟达也只有在 Blackwell 及之后的高端芯片才支持 FP4。这三项关键技术，使得 DeepSeekV4 能够在当前各种厂商的主流 AI 芯片上稳定运行，而非仅限于支持 FP4 和大显存的少数高端 AI 加速卡。

三大技术突破：为什么对支持多种 AI 芯片十分重要

突破一：FlagGems 提供支持 8 种以上芯片的全算子替代——真正意义上的跨芯方案

本次 DeepSeek-V4-Flash 的适配，FlagGems 实现了模型推理链路中全部算子的替代。这意味着：

  • 彻底脱离 CUDA 算子依赖：DeepSeek-V4-Flash 的 MoE 专家调度、Attention 计算、RMSNorm、TopK 路由等全部核心计算模块，均由 FlagGems 基于 Triton/Triton-TLE 语言重新实现，不调用任何 cuDNN/cuBLAS 等 NVIDIA 私有库。

  • 无需芯片厂商逐一适配：传统模式下，每款新模型上线，芯片厂商需要投入工程团队做算子适配。现在通过 FlagGems+FlagTree 编译器的组合，新模型的算子可以直接编译到多款芯片后端，芯片厂商不需要做任何额外工作。

  • 新算子即时可用：DeepSeek-V4-Flash 引入的新计算模式（如 o-group 相关的分组路由机制），FlagGems 已经实现了对应的新算子，并通过 FlagTree 编译器统一编译到所有支持的芯片后端。

FlagGems 作为全球最大的 Triton 单一算子库，已拥有超过 400 个大模型常用算子，并已正式进入 PyTorch 基金会生态合作项目。在 40 个主流模型上，推理任务算子覆盖度达到 90%~100%，完整支持 DeepSeek-V4-Flash 的全部计算需求。

突破二：为 o-group 采用独立并行策略——解除张量并行最多单机 8 卡限制

DeepSeek-V4-Flash 为了进一步降低计算开销采用了分组输出投影技术（Grouped Output Projection），配置为 o-group=8，这导致在传统的张量并行时候，最多切 8 份。而当前一些主流国产芯片的单卡显存为 32GB 或 64GB，尤其在 BF16 格式情况下，需要张量并行大于 8 份才能放的下。

为了解除这个限制，FlagOS 专门针对 o-groups 进行了单独张量并行策略设计和实现，确保 o-groups 切分不超过 8 份的前提下，能够让模型其他部分还采用经典的张量并行策略，并且实现超过 8 份的切分。通过不同的张量并行策略组合，能够实现多于 8 台设备的张量并行运行。

 

FlagOS 团队对 o-group 张量并行改动包括：

  • 独立的并行策略：独立于已有的张量并行通信组之外，为 o-group 单独构建所需要的张量并行通信组，确保其他模型结构张量并行切分超过 8 的情况下，o-group 的张量并行在 8 以内。

  • 参数转换调整：对 o-group 相关的参数，也进行了对应单独的张量并行切分处理，以确保在新的独立张量并行策略下，也能够被正确加载。

  • 覆盖面扩展：这一优化能够将 DeepSeek-V4-Flash 在单独采用张量并行策略下，将可运行芯片范围从"仅限单机 80GB 以上显存的个别高端卡"扩展到"多机 64GB/32GB 的更多主流国产芯片"，包括海光、沐曦、天数智芯等厂商的主力产品线。

突破三：从“FP4+FP8 混合精度” 到 BF16 的精度转换——打通主流芯片的计算路径

DeepSeek-V4-Flash 模型发布时首次采用 FP4+FP8 混合精度，该精度只有在 Blackwell 及之后的英伟达最新硬件上才有支持，但当前所有国内非英伟达 AI 芯片都未能支持，只有摩尔线程原生支持了 FP8，其余依然以 BF16 为主。

FlagOS 完成了从 FP4 到 BF16 的完整精度转换：

  • 权重反量化：将 FP4 量化权重转换为 BF16 格式。这不是简单的类型转换，而是需要根据 DeepSeek 的量化方案进行逆量化计算，确保数值精度。

  • 计算路径重建：FP4 和 BF16 在底层计算上有本质差异——FP4 的动态范围更窄，累加精度、溢出处理策略均不同。FlagOS 对推理链路中的 GEMM、Attention、MoE 路由等关键计算节点逐一适配了 BF16 路径。

  • 精度对齐验证：经过标准评测集验证，BF16 版本与 FP4 原生版本在核心能力指标上保持对齐，确保精度转换不引入业务层面的效果损失。

本次，FlagOS 推出了 FP8 和 BF16 两种适配版本，让 DeepSeek-V4-Flash 不再是“只有最新 NVIDIA 卡才能跑”的模型，而是真正可以部署在 FP8 及 BF16 生态的主流国产芯片上。

FlagGems 开源高性能新算子全面支持 DeepSeek-V4-Flash

本次新发布的 DeepSeek-V4-Flash 共有大约 67 个算子，FlagGems 已全量支持。新支持了 Act Quant、hc_split_sinkhorn、FP8 MatMul、Sparse Attention、Hadamard Transform 等 5 个新算子，实现了对 DeepSeek-V4-Flash 的全面支持，也为跨芯适配打下重要基础。

FlagGems 支持 DeepSeek-V4-Flash 新算子的性能对比

为了支持更多 AI 芯片的使用，FlagOS 对 DeepSeek-V4-Flash 中使用的新算子使用 Triton 语言进行重新实现，基于 FlagTree 统一编译器，性能全部超过原生性能。

C++ Wrapper 技术是 FlagOS 技术社区专门为提升基于 Triton 语言的算子内核调用效率而打造的技术。目前已经支持了该技术的芯片包括华为昇腾、寒武纪、摩尔线程、平头哥真武、及英伟达等。使用了 C++ Wrapper 技术，在普通的 Transformers 框架下，可以显著提升使用了 Triton 算子的模型的端到端效率，实现跨芯普适、和高效推理的双重目标。通过端到端效果评测（NV H20，DeepSeek-V4-Flash FP8），C++ Wrapper + Triton 比 TileLang 快 11%，比 Python Wrapper 版快 39%。

开发者体验优化：“发布即多芯” + “极简部署”

1. 核心能力与原生版本对齐

经 GPQA_Diamond、AIME 等权威评测集验证，FlagOS 适配后的 DeepSeek-V4-Flash，在语言理解、复杂推理、代码生成、数学计算等核心能力上，与 CUDA 原生版本对齐，可放心应用于金融、教育、政企服务、代码开发等场景，无需担心适配导致业务效果折损。

评测数据：

注：本测试结果仅用于对迁移前（Nvidia-Origin）和迁移后（-FlagOS）版本的互相对齐验证，并不代表 DeepSeek 模型的官方性能，DeepSeek 模型的官方性能以 DeepSeek 官方公布数据为准。

 

2. 极简部署：开箱即用，底层优化无感知

FlagOS 将核心算子库、编译器等技术组件前置内置到 DeepSeek-V4-Flash 代码框架中，开发者加载模型时，底层优化代码自动生效，无需手动添加任何 FlagOS 初始化代码。同时，基于 FlagRelease 直接提供了多芯片版本的 DeepSeek-V4-Flash-FlagOS 模型版本，标准化 Docker 镜像 + 一键加速命令，解决了开发者最头疼的环境配置、效果对齐、性能优化等问题。

昨天问大家怎么去养虾，或者是养 Hermes agent ，大家都给我推荐说用笔记本或者是 Mac Mini ，我今天上班拿同事的 MacBook 试了一下，感觉踩了很多坑，刚开始用着感觉挺好用，但是让他执行一些复杂的任务就会失联，甚至崩溃，大家有什么方法吗？感觉这个入坑需要很大的技术难度，有没有什么产品适合小白，直接安装导入 key 就好了？

今天看到 DeepSeek 4.0 刚发布，顺手接到自己这边跑了下，还可以，免费给佬友蹬
https://openaiapi.xyz
key：sk-n9pAA64de311VINBWrIq3n3RISyjelnZuojtvowE3DMTCSvo
模型名：deepseek-v4-flash ，deepseek-v4-pro
免费，免费，蹬完截止

随着混合办公模式的全面常态化与企业数字化转型的持续深入，文档这一基础信息载体正在从“静态记录工具”向“动态协作枢纽”演进。在日常办公中，用户不仅需要基础的打字排版，还面临跨地域实时共编、公文版式固化与防篡改、历史扫描件数字化转换、业务系统文档能力集成等多元需求。

传统文档处理工具常在“易编辑”与“保格式”之间难以兼顾。流式文档（如Word）便于修改，但在跨设备流转时可能出现格式错乱；版式文档（如PDF、OFD）能精准呈现，但二次编辑效率较低。流式与版式之间的割裂，以及协作效率与格式准确性之间的矛盾，仍是当前文档处理领域的常见痛点。以“格式精准、云端协同、流版融合”为特点的新一代智能文档工具正逐步进入市场。

基于2026年多款文档处理软件的功能表现、技术架构与用户反馈，本文从中立角度对部分工具进行简要梳理，供个人及企业在选型时参考。

一、综合办公与云端协作类

  1. WPS 智能文档系列
    该产品支持本地文档与在线文档的格式转换，协作过程中格式与数据的丢失率控制在较低水平。权限管控方面提供仅查看、可评论、可编辑等细粒度设置，并与智能表单功能联动。适用于校园团队及中小型企业的信息收集与多人协编场景。其云端存储与历史版本回溯功能也较为完整，可满足日常办公的基本协作需求。
  2. Microsoft 365（Word Online）
    在流式文档编辑的流畅度与格式兼容性方面表现稳定。云端版本支持多人实时共编，与本地客户端的衔接较为顺畅，编辑内容可实现近乎实时的同步。该产品提供标准的评论、批注及任务分配功能，适用于对文档排版要求较高、以国际交流为主的团队。对于已经部署微软生态的企业，其单点登录与权限继承的便利性较为突出。

二、流版融合与文档中台类

  1. 安证通·在线AI Office

该产品将AI能力嵌入在线文档编辑流程，支持流式文档的协同编辑与格式调整。用户可在浏览器中创建或上传文档，完成文本输入、图片插入、表格绘制、字体段落设置等基础操作。其差异化功能体现在AI辅助方面：在撰写合同、报告、通知等常见公文时，系统可自动识别条款风险并给出修改提示；选中一段文字后，可一键提取其中的金额、日期、人员姓名等关键信息并结构化展示；支持与AI对话式交互，输入自然语言指令（如“写一份会议通知”“总结这段内容”），AI生成的内容可直接插入文档。此外提供拼写与语法纠错、排版优化建议，并内置电子签章功能，保障文档签署安全与法律效力。适用于日常文档起草、修改与信息整理，同时具备流式文档与版式文档的切换能力。

  1. 安证通·版式阅读器
    该产品专注于PDF、OFD等版式文件的阅读、注释与轻量编辑、电子签章。支持高保真渲染，确保文档在不同设备上显示效果一致。提供附注、高亮、删除线、下划线等文本注释工具，以及直线、椭圆、矩形、多边形、箭头等图形注释工具。内置动态水印、打印控制、下载控制、复制控制等安全防护机制。用户可在版式文档上进行手写签批，手写笔迹可识别为文本并归档。适用于党政机关、企事业单位对版式文档的受控阅读与批注场景。
  2. 安证通·智能文档中台
    该产品将文档处理能力封装为中台服务，提供标准化的API接口，便于集成至企业现有的OA、ERP、CRM等业务系统。中台涵盖文档在线编辑、版式预览、格式转换、电子签章、批量套红、自动比对等功能，可实现文档从起草、审核、定稿到归档的全流程自动化。对于希望将文档能力嵌入自有业务系统的企业，该产品可减少重复开发成本。
  3. 福昕OFD版式办公套件
    在版式文档特别是OFD国产标准领域，福昕提供了较为完整的工具链。其阅读器加载速度较快，支持OFD与PDF双格式的解析与相互转换。内置电子公章、动态水印、阅后即焚等安全保护机制，并兼容信创环境下的多种操作系统。该产品适用于党政机关、事业单位及国有企业等对版式文档合规性有明确要求的场景。

三、文档转换与OCR识别类

  1. 迅捷PDF转换器（及在线端）
    该工具提供多功能格式转换与OCR识别服务，覆盖PDF与Word、Excel、PPT、图片等多种文件格式的互转。其桌面端支持多核处理与一键批量操作，在线端则提供云端识别选项，可处理较大体积的文件。对于需要频繁将扫描件、纸质文稿转换为可编辑文本的用户而言，其识别速度与准确率能够满足日常办公的基本要求。
  2. 安证通·文档转换软件
    作为安证通文档处理系列的独立模块，该转换软件专注于流式文档与版式文档之间的高保真互转。在处理包含复杂排版、嵌套表格、数学公式、印章图片等元素的文档时，转换后的结果能够较好地保留原有布局与内容样式。支持常见格式如DOC、DOCX、WPS、PDF、OFD、图片等之间的双向转换，并提供批量转换接口。该服务可被单独调用，也可集成至智能文档中台，适用于对转换质量要求较高的业务场景。
  3. 在线扫描PDF转换工具（轻量级网页端）
    该类工具无需安装客户端，支持单文件200MB、最多600页的超大文档在线解析。其OCR识别准确率标称较高，对复杂表格和公式的排版保留能力较强。转换后支持实时编辑与校对，并提供临时云端存储。适用于偶发性的重度转换需求，如处理历史档案、扫描版书籍等，用户无需购买长期授权即可按次使用。

四、智能排版与行业合规类

  1. KMERIT AI智能文稿
    该产品面向金融、法律等对合规性要求较高的行业。依托大模型技术，提供智能排版、智能核稿与智能比对功能。其内置金融专有词库与法律术语库，能够审查术语错误、逻辑连贯性及格式规范。支持完全本地化部署，核心业务数据可在企业内网环境中处理，无需上传至公有云。适用于金融机构处理合同、研报、招股说明书等高密级文档，也适用于律师事务所的文书审阅。
  2. 永中Web Office
    该产品在政务与教育领域有较多应用案例。支持多人同时编辑同一文档，编辑视图实时同步，并提供完善的批注、修订记录与版本对比功能。对于需要组团备课、公文联合起草、政策文件协同修订的团队而言，其协作流程设计较为贴合国内用户的使用习惯。同时，永中Web Office提供私有化部署选项，可满足部分单位的数据安全要求。

结语

文档处理已从单纯的“打字排版”逐步演变为企业数字化基础设施的组成部分。从上述工具中可以看到，文档处理软件正朝着智能化、平台化与生态化方向发展。流式与版式之间的技术边界正在消融，“编辑即固化、固化可再编辑”逐步成为可能。无论是关注格式准确性、云端协作效率，还是文档中台建设，基于自身业务场景选择匹配的工具，有助于在数字化环境中释放文档的数据价值与协作能力。

值得注意的是，不同工具在不同版本、不同部署方式下的实际表现可能存在差异。建议用户在正式选型前，结合自身文档样本进行实测，以验证格式还原度、转换准确率、协作响应速度等关键指标。

互联网时代，电子邮件早已成为各行各业进行商务沟通的核心载体，具备庞大的商业价值。正因如此，邮件安全事故频频出现：或伪造企业领导邮件骗取财务进行转账，或利用邮箱窃取合同附件，甚至利用员工身份发送非法链接进行钓鱼攻击……一系列攻击事件的背后，不仅体现了电子邮件的价值，也暴露出企业对此缺乏安全认知，未对邮件进行数字签名和加密保护。S/MIME证书可对邮件进行数字签名，确保发件人的身份真实，确保内容有效未被篡改，同时可对信息进行加密处理，确保指定的收件人才能阅览。对于企业而言，选择合适的邮件签名证书，才是真正发挥电子邮件价值的关键。

选邮件安全证书的核心标准

验证强度：优先选择组织验证型证书，可在邮件客户端显示企业名称，提升品牌辨识度，增加收件方信任。
兼容表现：邮件证书需被主流邮件客户端（Outlook、Foxmail、腾讯邮箱等）广泛信任，根证书预置范围越广，兼容表现越好。
算法支持：支持RSA/ECC国际算法，若国内企业有合规需求，最好支持SM2国密算法。
密钥管理：可硬件令牌存储私钥，实现邮件客户端自动配置，丢失后支持密钥恢复。
技术支持：机构是否提供中文技术支持，能否自动续期，避免证书过期导致拒收。

邮件签名证书的作用与需求

防范钓鱼攻击：经过签名的邮件自带安全标识，收件人可直接确认发件人真实身份，有效杜绝伪造。
保护商业机密：对邮件进行数字加密后，该邮件仅目标收件人可以阅览，即使邮件被中途截取，也无法解密。
满足合规需求：GDPR、等保2.0等法规均要求对商业邮件进行加密，部署邮件安全证书满足合规需要。
提升品牌形象：与高等级SSL证书一样，签名邮件可展示经过认证的企业信息，树立品牌权威可信的形象。

全球主流CA证书能力对比

Digicert：S/MIME提供端到端加密，防范网络钓鱼、篡改和中间人攻击，确保发送或接收的每封邮件都能安全传送，不会受任何操纵。

JoySSL：邮件签名证书可验证发件人真实身份，避免邮件欺诈；同时邮件传输过程中受非对称加密保护，确保邮件的安全性，防止恶意篡改。

Sectigo：通过数字签名消息，验证发件人真实身份，S/MIME可防止未经授权的访问，确保消息的安全性，并保护敏感信息免受网络威胁。

CFCA：支持所有主流浏览器，可对邮件地址拥有者进行身份标识，用于邮件发送过程中的数据加密和签名。

邮件安全证书标准选择方案

选择邮件证书不能只关注价格，需综合评估身份验证强度、客户端兼容、国密支持以及技术服务。国际品牌Digicert、Sectigo具备全球兼容和自动化优势；而CFCA与JoySSL具有国密算法支持，满足合规要求，适合国内企业。

“Claude 变笨了。”

Anthropic 正面回应模型“变笨”：三处优化导致的

 

过去一段时间，这个声音在 Hacker News、Reddit 以及 X 上此起彼伏。尤其是在万众瞩目的 Opus 4.7 发布后，不少老用户反馈 Claude Code 变得健忘、重复且废话连篇。

 

 

作为目前全球最强梯队的编程模型，Claude 的口碑滑坡让 Anthropic 压力倍增。

 

所以今天一早，Claude Code 研发团队打破沉默，发布了一篇看起来诚意十足的分析文章，名为《An update on recent Claude Code quality reports》，他们在文章中坦言，用户反馈的“降智”并非错觉，而是源于三处看似合理、实则导致连锁反应的产品优化。

 

没错，Claude Code 真的“变笨”了。

 

研发团队表示，目前 Anthropic 已修复全部漏洞，并宣布重置所有订阅用户的使用限额以示诚意。

 

截至 4 月 20 日（版本 v2.1.116），这三个问题均已修复。在这篇文章中，他们详细阐述了发现了什么、修复了什么，以及今后将如何改进，避免类似问题再次发生。

三处优化细节详述

 

事件的起因，源于产品团队对“用户体验”的过度优化。经过调查，Claude Code 团队找出了三个不同的问题：

 

第一个优化发生在 3 月 4 日。通常来说，模型思考时间越长，输出效果越好。当时，不少用户吐槽 Opus 模型思考时间太长，甚至导致 UI 卡死。为了缩短延迟、节省 Token，团队私自将默认推理强度（Reasoning Effort）从“高”降到了“中”。

 

在产品层面，团队再从中选一个点作为默认值，并通过 Messages API 的 effort 参数传递该值；同时，团队还将其他可选强度通过 /effort 命令提供给用户。

 

内部评估认为，“中”等强度能以极小的智能损失换取显著的速度提升。然而，真实环境中的开发者并不买账，上线后不久，就有用户反映 Claude Code 感觉变笨了。对 AI 而言，“多思考一秒钟”往往意味着从“生成垃圾代码”到“产出优雅重构”的跨越。

 

在听取更多客户的反馈后，团队做了多次设计迭代，让当前的推理强度设置更清晰，以便提醒用户可以更改默认值（例如启动时弹出提示、增加内联的强度选择器、恢复“ultrathink”选项），但大多数用户仍然保留了“中”等推理强度默认值。

 

4 月 7 日，团队在意识到这种取舍逻辑的错误后，将默认强度重新调回了“高”，并在 Opus 4.7 上默认开启了“极高”模式。此问题影响的模型是 Sonnet 4.6 和 Opus 4.6。

 

第二个优化发生在 3 月 26 日。当 Claude 执行一项任务并进行推理时，这些推理内容通常会被保留在对话历史中。这样，在后续的每一轮交互中，Claude 都能了解自己之前为何做出某些编辑和工具调用。

 

3 月 26 日，团队针对这一功能上线了一项本意是提高效率的优化，有点类似于“自动清理历史思考内容”的功能。他们利用提示缓存（prompt caching）来降低用户连续 API 调用的成本并加快速度。Claude 在发起 API 请求时将输入 token 写入缓存；如果一段时间没有活动，该提示就会被从缓存中逐出，为其他提示腾出空间。

 

原本的设计应该很简单：如果会话空闲超过一小时，系统会剪除旧的推理信息以节省成本。为此，团队使用了 clear_thinking_20251015 这个 API 头部，并配合 keep:1 参数。

 

但代码中隐藏的一个漏洞：它并没有只清除一次思考历史，而是在会话后续的每一轮中都进行清除。一旦跨过空闲阈值，后续每一轮对话都会触发清理。这意味着 Claude 只能记住最近的一句对话，它彻底忘记了自己当初为什么要修改代码。在用户眼中，Claude 开始重复啰嗦、胡言乱语。这种“健忘”不仅损害了智能，还因为频繁的缓存未命中（Cache Miss）导致用户的使用额度被光速消耗。

 

据悉，该漏洞的发现过程较为曲折，由于 Anthropic 内部两个互不相关的实验干扰，导致漏洞难以复现——一个是仅用于服务端、涉及消息队列的内部实验，另一个是在思考内容展示方式上的正交改动，该改动在大多数 CLI 会话中掩盖了漏洞，使得外部构建测试时未能发现问题。

 

此外，该漏洞处于 Claude Code 的上下文管理、Anthropic API 和扩展推理三个模块的交汇点，相关变更已通过多轮人工和自动化代码审查、单元测试、端到端测试、自动化验证及内部试用，且仅在陈旧会话这一边缘情况下出现，因此 Anthropic 花费超过一周时间才找到并确认其根本原因。

 

值得注意的是，在调查过程中，团队使用 Opus 4.7 对有问题的拉取请求进行了反向的“代码审查”测试。当提供了获取完整上下文所必需的代码仓库后，Opus 4.7 发现了该漏洞，而 Opus 4.6 未能做到。

 

为防范此类问题再次发生，Anthropic 目前正增加对更多代码仓库作为代码审查上下文的支持，该漏洞也已经在 4 月 10 日 v2.1.101 版本中修复好了。此问题影响的模型是 Sonnet 4.6 和 Opus 4.6。

 

第三个优化发生在 4 月 16 日。Anthropic 曾为降低 Claude Opus 4.7 版本的冗长程度，修改了系统提示语。据悉，Claude Opus 4.7 相较于前代，明显更加“啰嗦”，虽能在困难问题上表现更出色，但会生成更多输出 token。

 

在该版本发布前几周，Anthropic 便开始对 Claude Code 进行调整，综合运用模型训练、提示语优化、思考体验改进等多种方式降低冗长程度，其中新增的一条系统提示语——“长度限制：在工具调用之间的文本控制在 25 个单词以内。最终回复控制在 100 个单词以内，除非任务确实需要更多细节”，对 Claude Code 的智能产生了过大影响。

 

该提示语经过数周内部测试，在 Anthropic 运行的评估集上未出现性能退化，因此于 4 月 16 日随 Opus 4.7 版本一同上线。

 

但在后续调查过程中，Anthropic 通过更广泛的评估集开展更多消融测试（即从系统提示中逐行删除以理解每行影响），发现 Opus 4.6 和 4.7 版本均出现 3%的性能下降。

 

为此，Anthropic 在 4 月 20 日的发布中，立即撤销了该条系统提示语。该优化受影响的模型包括 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

未来如何改进？

为了避免再次出现这些问题，Claude Code 团队表示将从下面三个方面进行改进：

 

首先，是内部全员强制使用公共构建版，确保开发者与用户“同频感同身受”。

 

Claude Code 团队将推动内部使用版本的统一，确保更大比例的内部员工使用 Claude Code 的精确公共构建版本，而非用于测试新功能的内部版本，以此更贴近普通用户的实际使用场景，提前发现潜在问题。同时，团队将对内部使用的代码审查工具进行改进，并计划将优化后的代码审查工具同步提供给客户，助力客户提升使用体验。

 

其次，是引入更严苛的提示语审计工具，对系统提示语的每一行修改进行持续的消融测试。

 

在系统提示语管理方面，Claude Code 团队将增加更严格的控制措施。对于每一次系统提示语的更改，团队都会针对每个模型运行广泛评估，持续开展消融测试以明确每一行提示语的具体影响；同时，已构建新的工具，让提示语的修改更易于审查和审计。

 

第三，是增加“浸泡期”，对于任何可能牺牲智能换取性能的改动，采取逐步上线的流程。

 

团队已在自身的 CLAUDE.md 文件中新增指导原则，确保针对特定模型的更改仅限定在该模型范围内，避免跨模型影响。对于任何可能牺牲智能换取其他收益的改动，团队将增加“浸泡期”，扩大评估集范围，并采用逐步上线的流程，以便更早发现并规避问题。

 

在用户沟通与反馈渠道方面，Claude Code 团队近期已在 X（原 Twitter）平台创建 @ClaudeDevs 账号，用于深入解释产品决策及其背后的原理，同时会在 GitHub 的集中讨论帖中同步相关更新，提升产品决策的透明度。

分析报告没有让用户满意

 

当 Anthropic 试图用一份详尽的技术报告挽回 Claude 的口碑时，它可能低估了开发者积压已久的怒火。

 

在官方承认由于“推理强度下调”、“缓存漏洞”和“提示语冗长控制”导致 Claude 性能大幅下滑后，社交媒体上的评论呈现出一边倒的抨击。

 

对于众多支付高额订阅费的专业开发者来说，这份迟到的“真相”不仅没能平息焦虑，反而因补偿方案的敷衍和官宣时机的微妙被质疑在“作秀”。

 

在 X 上，一位网友反馈称，即使在重置后，流量消耗速度依然惊人：“我用了 5 个小时，x20 的套餐就烧掉了 64% 的流量，而我什么特别的事都没做。情况正在变得越来越糟。”

 

还有 X 用户愤怒地表示：“这简直是胡说八道！过去两周，我一直在反思是不是自己的提示词或工作流程出了问题，甚至怀疑过自己都没怀疑过 Claude，结果发现是你们的漏洞吞噬了我的历史记录。把重置当作道歉？这才是真正侮辱人的地方。”

 

该用户还表示：“过去一年我为 Anthropic Max 支付了约 2400 美元，为 OpenAI 支付了 0 美元。过去 48 小时我切换到 OpenAI 的Codex感觉真的非常棒，我正严肃考虑彻底更换系统。失去最忠实用户的方式，不是因为模型出 Bug，而是因为糟糕的道歉。”

另一位网友则精准补刀：“你们总是在每周限额到期前两小时宣布‘重置’，这根本不叫重置，这叫敷衍。”

 

最令社区玩味的是本次公告发布的时间点——恰逢 OpenAI 发布GPT-5.5的当天。有部分 X 用户认为，这样的做法是在分散人们对于 GPT 5.5 发布的关注。

 

有 X 用户质疑道：“几个月来你们一直坚称‘模型没有退化’，现在却在 GPT-5.5 发布的当天突然官宣漏洞分析，这很难不让人怀疑是在转移注意力。更讽刺的是，你们声称‘用 Claude 开发 Claude’，结果长达 15 天的严重漏洞竟然在内部完全没被发现？”

 

这场风波正在引发连锁反应：核心用户的忠诚度降至冰点。也让一部分人从 Anthropic 转向了 OpenAI。

 

对于 Anthropic 而言，这次危机揭示了一个残酷的现实：在大模型竞争进入白热化的今天，技术领先只是入场券，透明度与对用户时间的尊重才是留住开发者的护城河。

参考链接：

https://x.com/ClaudeDevs/status/2047371123185287223

https://www.anthropic.com/engineering/april-23-postmortem

2025 年端午节假期，李志飞把自己关在房间里，每天从早上 9 点干到凌晨 1 点。他在用 Cursor 手搓了一个“AI 时代的飞书”，十几万行代码，一天烧掉 300 美元的 Token。三天后产品跑起来了，他的腰也坏了。

他把这段经历搬到公司的小型发布会，语气里难掩兴奋：“我们从一个有想法、有工程能力、但没有执行能力的团队，变成了一个超级个体。”那段时间他四处分享，在公司里讲，在湖畔大学讲，在朋友圈里讲。

“超级个体“成了 AI 圈最具诱惑力的叙事。几乎每位从业者，都被“一人顶一个团队”、“一夜重构产品”的故事撩拨过。

但这份狂热，只持续了一两个月。很快，李志飞发现了一个吊诡的事实：他自己确实变强了，但出门问问作为一家公司，却依然原地踏步。员工还是按旧方式开会、提需求、做文档、等排期、催研发。

“这只是超级个体的进化，但团队还是在旧有的工作方式里空转。”2025 年下半年，这位刚上市一年多的 AI 公司 CEO 第一次意识到：“超级个体在组织里，可能是一场灾难。”

不到一年后，出门问问交出了新答卷，企业级 AI 原生协作平台 CodeBanana。它的思想底座，源自于李志飞与高佳（出门问问首席战略官）合著的《超级组织》方法论：企业如何从“以人为核心”走向“智能体协同”。而 CodeBanana，正是这一理念的产品化落地。

这一次，他想讲的已经不再是“一个人怎么变强”，而是指向一个更具挑战性、也更现实的命题：当 AI 已经能让个体长出翅膀，组织又该如何一起变强？

一、CodeBanana 先是一场内部实验

CodeBanana 的核心理念，被李志飞浓缩成一句话：沟通发生在哪里，执行就发生在哪里。

这句话听起来有点像口号，但落到产品结构里，逻辑就比较清晰了。

在 CodeBanana 里，最基本的单元不是文档，不是会议，也不是单条任务，而是“项目”。每个项目同时包含三层结构：群聊、Agent 和独立 Workspace。群聊承载人际沟通，Agent 负责调度执行，Workspace 沉淀上下文与资产。

换言之，它不是在传统协作软件里外挂一个 AI 助手，而是从项目创立之初，就把 Agent 当作正式成员编入阵型。

这套设计如果只停留在发布会 Demo 里，难免显得像在谈概念。但 CodeBanana 真正有说服力的地方在于：它最早并非对外售卖的标品，而是出门问问在自己身上做出来的内部工具与工作法则。

从 2025 年 8 月开始，李志飞先在研发团队下了一道近乎极端的铁律：禁止手写一行代码。哪怕改一个变量名，也必须用自然语言指挥 AI。有工程师觉得职业价值被怀疑，有人因此离开。

到 2025 年底，研发团队基本完成蜕变。李志飞给出了一组数字：研发效率飙升至从前的 4-5 倍，工程师从前端、后端、iOS 等细分工种，逐渐演变为全栈执行者。同年，出门问问孵化出两款体量不小的新品（TicNote 录音硬件与 CodeBanana），按以往的研发节奏，这基本无法实现。

更关键的是，这套方法随后被推向了非研发团队。

李志飞在群访中透露，最近三四个月他们将 AI 协作延展至非技术岗，十人中大概有三名达到了他定义的“超级个体”标准：市场人员能做 Dashboard、能爬数据、能自己搭系统；销售甚至自己搓出了一个 CRM。

“目前 Token 成本已经占公司人力成本的 15%，平均每个员工每月 Token 支出两三千美元。”一家 AI 公司在自己身上做了 18 个月的实验，有数字、有案例、有阻力、有筛选。这便是 CodeBanana 作为产品能否打胜仗的第一份答辩。

发布会上，李志飞用几轮实时 Demo 将这些场景拉得更具体。

昔日，销售接到客户需求，需与工程师反复拉扯，折腾数日方能拼出标书；如今，制作 Word 文档、处理图标等复杂流程被封装成 Skill，销售开完会直接在群里 @Agent，十几分钟内就能生成几十页文档。

市场岗的同事，搭起了一个覆盖数据爬取、竞品分析、ROI 计算和传播规划的网站；招聘场景下，一个岗位就是一个项目，简历流入后，AI 一分钟内完成评估、打分与排名，后续的面试提问与评价也由 AI 深度参与。

这些案例比 Demo 更有分量。

因为它们印证了 CodeBanana 的真正野心：它要解决的不是“AI 能不能写段代码”，而是要把“执行权能否归还需求方”。销售最懂客户要什么，市场最懂投放要什么，HR 最懂岗位要什么。过去他们手握需求，却无执行能力；如今，他们能通过 Agent 调度执行力。

二、不想打“协同办公”这场旧仗

真正让 CodeBanana 跳出“又一个协作工具”叙事的，是李志飞对竞争身位的重新定义。

面对飞书、钉钉、Notion 都在重兵投入 AI 集成，CodeBanana 的护城河在哪？

李志飞的回答很直接。他认为，飞书、钉钉争夺的是企业协作管理市场，而 CodeBanana 做的是“协作管理 + 执行”，切走的是劳动力市场的 Token 预算。他进一步将这个市场推演为：中国 8000 万知识工作者，如果工资的 15% 转化为 Token，这将是一个完全不同量级的蓝海。

这个回答包含两层深意。

第一层是差异化。CodeBanana 无意在传统协同办公的红海里肉搏。它不想做更聪明的群聊、更会总结的文档工具，而是试图向下穿透，直抵“任务如何被执行”的底座。

第二层是野心。它将自己的市场，不再定义为办公软件市场，而是知识工作中日益膨胀的 AI 执行成本与 AI 劳动力调度市场。

所以，CodeBanana 的功能设计并不是围绕“消息效率”展开，而是围绕“组织可控的执行”展开。

比如， Team Agent 与 Private Ask。前者面向团队共享，执行过程可见、可介入、可叫停；后者偏向个人私密，只读不写。

再比如，项目之间默认是独立文件空间，互不可见。若需跨项目协作，必须通过 A2A（Agent to Agent）的方式完成。企业若要沉淀公共知识库，可以单独建项目，再让其他项目的 Agent 来调用。

这和个人 AI 工具的逻辑完全不同。

Cursor、Claude Code 追求的是“个体如何更快闭环”；CodeBanana 追问的则是：当 AI 开始替团队干活，组织能否看清它在干什么、谁授权了它、它的边界在哪、结果如何复用、出了岔子谁来叫停？

这也解释了为何发布会要反复强调权限、跨项目调用、Skill 复用和定时任务。老板临时改期，工程师可将开发 Agent 的编辑权限开放给老板；老板在筹备群里直接 @Agent，页面主视觉、票务信息、倒计时同步刷新；后续“日程变更通知全员”的流程，还能被沉淀为 Skill 供下次复用。

这里真正有价值的不是网页生成，而是需求、权限、执行和复用被放进了同一个系统。

当然，这也意味着 CodeBanana 面对的问题会比普通 AI 工具更复杂。

大量项目并发时，如何防止 Agent 重复工作、越权？

李志飞没有把话说满。他承认系统仍在完善，目前先靠权限卡口，未来需解决排队通知机制。至于一个产品该建几个项目、哪些任务该并行、哪些该同组，眼下仍需 CEO 或产品经理在顶层设计时想清楚。未来，系统会尝试根据企业的人员构成与工作流，反向建议“该建几个群、谁该在群里”。

这种坦诚反而划清了产品的边界：CodeBanana 绝非开箱即用的效率魔法，而是一套需要重塑认知的组织工作系统。 它要真正跑通，企业买的不只是工具，更是对项目、权限、文件、人员与 Agent 之间关系的重新理解。

三、结语：真正被重写的，是工作系统

CodeBanana 尚不能被写进一份已充分验证的标准答案里。它仍需在真实组织的泥沼中跋涉，经受并发、权限、成本、可靠性及习惯迁移的考验。

但它值得关注的地方，也正在这里。

出门问问并非简单发布了一款 AI 协作产品，而是将过去一年多的组织实验进行了产品化：先让 CEO 自己蜕变为超级个体，再将这种能力溢向研发团队，最终推至销售、市场、HR 等非研发岗。

这也是 CodeBanana 最核心的叙事：AI 不再只是插在工具栏里的外挂，而是开始嵌入组织的骨架。

如果说超级个体解决的是“一个人怎么变强”，那么 CodeBanana 和“超级组织”想回答的，是那个更艰难的命题：当一群人和一群 Agent 混编作战，组织怎样才能不被新的效率反噬？

真正的竞争，或许并不发生在“谁的协作文档更好用”的层面。而是另一个维度：谁能率先把 AI 从工具栏里拿出来，放进公司的工作系统里。

由于最新的 bitwarden 插件会严重影响 Chromium 内核的浏览器，但不用不行，因此只能用之前的版本 brave

但是 brave 会在后台自动更新，参考网上教程在 Windows 的 Service 中关闭了 Brave 的两个服务（ Brave & BraveElevationService ）。再点开关于页面，就会提示更新失败了

但是今天一看又提示我进行更新了，蒙了，还有什么地方少关了吗？或者要做什么 hosts 才能彻底防止更新？

4月21日，第五届中国国际软件发展大会在北京国家会议中心开幕。本次大会以“人工智能与软件变革——AI融合与数智出海新机遇”为主题，汇聚了全球软件产业的顶尖智慧与创新力量。作为中国开源生态的重要力量，OpenAtom openKylin（以下简称“openKylin”）社区受邀参会，凭借扎实的品牌实力与持续的技术创新，一举斩获“2025年软件和信息技术服务业明星开源社区”行业荣誉。

同时，由麒麟软件联合国防科技大学、北京航空航天大学、工信部电子五所、中国科学院软件研究所、上海交通大学、国家工业信息安全发展研究中心、国网湖北公司及openKylin社区等多方共同承担的国家重点研发计划阶段性核心成果——“链源罗盘”开源供应链综合评估平台也在大会上正式发布。

全链路安全守护：“链源罗盘”正式亮相
当前，全球开源生态发展迅猛，主流代码托管平台上开源项目数超4亿。以操作系统、数据库、AI框架等为代表的基础软件生态加速成熟，开源软件在信息技术创新技术体系中正成为关键支撑底座。然而开源组件质量参差不齐、依赖关系复杂、合规风险、安全漏洞等隐患日益突出，开源软件供应链的安全形势愈发严峻。
在本届中国国际软件发展大会上，“面向开源软件全生命周期的供应链综合评估平台——链源罗盘”作为重要成果发布。该平台是业界首个面向开源软件全生命周期的供应链综合评估平台，覆盖了软件质量、安全性、合规性、可持续性和可信度5大评估模型，助力开源供应链更透明、更安全、更可持续的演化。

中国软件行业协会常务副秘书长陈宝国、麒麟软件副总经理李祥凯、北京航空航天大学软件学院院长胡春明、中国科学院软件研究所副所长武延军、工信部电子五所北京中心主任冯冠霖、国防科技大学计算机学院某中心主任余杰、openKylin社区生态委员会主任李震宁出席发布仪式。

为落实国家《“十四五”软件和信息技术服务业发展规划》中“提升软件供应链安全保障能力”的号召，openKylin社区深度参与国家重点研发计划《开源开放社区软件供应链生态分析》项目，围绕开源软件供应链生态问题开展应用验证。“链源罗盘”正是该项目的阶段性核心成果。

一键评估，多维分析
链源罗盘平台支持输入开源软件名称，一键生成供应链可靠性评估报告。报告从组件依赖关系、代码与依赖质量、供应链抗风险能力、合规与法律风险、开发者活跃度与项目更新等多个维度进行综合评估开源项目的整体可靠性，为企业核心组件选型、社区开源治理、供应链风险审计等场景提供关键支撑。

全面覆盖，全程守护
目前，平台已基于Github、Gitee等代码托管平台主流开源项目形成150万条依赖关系、33万条漏洞信息收录、200万+开发者画像分析，3万+项目综合评估，并构建openKylin和openEuler 2个可信仓库，实现了“源代码分析—二进制文件评估—可信仓库构建—商业发行版构建”的全流程闭环。

目前，开源模式已成为全球技术创新的主流方向，中国开源项目数量已位居全球第二，供应链安全正成为行业关注的焦点。“链源罗盘”的发布，将汇聚政府、企业、高校及科研机构等多方力量，为提升国内开源生态成熟度及全球影响力提供坚实支撑，推动开源软件使用向安全化、合规化、自主化迈进。

openKylin社区荣膺“2025年明星开源社区”
在本次大会的表彰环节，openKylin社区凭借在开源生态建设、技术创新、社区治理及产业协同等方面的突出表现，被授予 “2025年软件和信息技术服务业明星开源社区” 称号。这一荣誉不仅是对社区过去工作的肯定，更彰显了openKylin在推动中国开源软件供应链安全、构建可信开源基础设施方面的重要贡献。

作为中国领先的智能操作系统开源社区，openKylin社区始终秉持“开源、自愿、平等、协作”的理念，持续汇聚开发者、企业和科研机构的力量。未来，openKylin将继续深化开源软件全生命周期的安全治理，助力开源生态向更安全、更合规、更自主的方向迈进，为全球开源创新贡献中国智慧。

一直是两个 gpt plus 混用，除了缓存，没遇到任何问题。
今天升级了一下 codex 。
功能改完后，想改一下风格，发完这句话以后，A 账户返回额度耗尽

然后我换 B 账户，跟 B 账户对话前，我"git inti ➡ git add .➡ git commit -m" 提交了版本。B 账户改的面目全非，我 git 还原

奇怪的事情来了：git 历史变成了变得文件夹的文件。。最重要的是，B 账户告诉我，现存文件的 1893 行和 3675 行与我的要求没有任何关联。。也就是我所有我改好的代码，在我切换账户后，他凭空消失了。。。

2026.4.24
生活随笔日记 16 没约会还是写一些

上次被要穿战袍鸽子以后，第二天准备继续约
她微信上突然问我，知不知道她是什么身份
我说来了以后在告诉我
她说她是 ts （听到这个我人傻了，不懂 ts 是什么意思的自行了解）
还好那天放鸽子了，我只在徐师傅的视频里面了解过这群人群，没现实接触过，可能是基因，也可能是外界环境导致了他们这样，说实话我很尊重他们，就像我之前说的大大方方做自己，我也很佩服他们。但我肯定不能忍受跟他们有亲密接触的，可以跟一个男生做朋友，但要去跟一个男的舌吻，我很难去想象这样的画面，毕竟我爱好女。

2026.4.23 大雨

今天其实约了女生的，还不止一个，但是下雨，车都不好打，回到家已经很晚了，加上变天天气很冷，没什么状态了，我算是直接鸽了女生。

我直接微信问她要不要来我家 hh ，别人肯定是拒绝的。

回家途中还有点后悔自己省钱租了一个离公司太远的地方，影响到工作日约会了，但回到家看到我温馨小屋，躺床上也能看到一点窗外景色感觉也没那么后悔了


这周六，二约了一个，一个月前左右约过的一个女生，蜕变日记（约会日记） 6 里第二个之前做过护士，销售又没上班了的，没仔细去描写过。上次我还是新手阶段没拿下，这次狠狠拿下。

从毕业到现在都工作 4 年多，简单概括整个工作生涯，工作上也没啥特别高深技术，就很纯粹的业务 Boy 。最近投了大半个月简历，且 op 都是专挑外包岗位去投，对面招聘 HR 拿完我信息就没后续了，面试机会也很少。前几天倒是有两三个电话面试打过来，都是问一些八股文，整体面试过程，我都浅略回答面试官问题。（后续估计也悬了）。还有就是前段时间还收到什么帮忙代面电话，挺无语的，我还问他们，谁把我信息卖给你们，之后他们就草草挂断电话了。

八股文也看了，但是每到面试时候都会忘得七七八八，即使自己知道的，不知道怎么组织语言，表达逻辑不流畅？

为什么我感觉职业生涯到期？主要以下几点：

个人情况：OP 乡镇，二本毕业，26 岁，性格较为内向，家庭一般。

  1. 刚毕业那段时间，找工作，与面试官聊着聊着，拿着我简历说到“哎，原来你是本科的，xxx”。陷入自我怀疑状态...（省内公办本科毕业，遇到不少于过两次，搞得我很自闭）

  2. 实习时候。因为疫情和学校诸多强制事情，找实习推迟了。后续在找实习时候，迟迟找不到实习，差不多找了 4 个多月。那时候每次笔试和面试失败都会进行复盘，以为是不是要价太多了和知识储备太少了。价格上，每次找实习一直压低价格；知识上，什么八股文，JVM 一堆八股文往上套，死劲背，leetcode 狂刷题，到最后被问到的公司没要我，倒是没被问到通过了。最终以 2k 月薪，能接受大小周，在一线城市小公司工作实习。我还记得当时入职时候，对面 HR 说到：“我们这边 2k 也是给得起的”，“你这边生活费够用？”。差不哦多 10 年前初中时候，我在当地进厂打暑假工，也 3k+了，当时又深深自我怀疑...。从那时候起，我非常厌恶八股文，但是找工作又不得不看它，唉...。还有个小插曲：当时为了那实习证明，工作几个月就溜走了，等我回到学校问道同学们，他们实习证明要不是让父母盖章，或者亲戚内推，或者淘宝买了，就只有我们几个真的招实习工作，感觉我还是太老实了...

  3. 现在大环境差，学历一般，以往工作背景没啥亮点（有外包经历），感觉估计也要凉了。本还想能干到 35 岁就知足了，回头想想，除了程序员，我都不知道我能干啥。还有一件小事情，每次找工作都会有代面，培训机构（刚出来毕业工作时候经常收到的）问我要不要尝试一下，太恶心了。

回顾整个求职和工作生涯，诸多不顺。

今天思绪有些散，乱想了一通，有感而发，随手记下，回头读着不太顺畅，也凑合吧。

根据Gartner《2026年全球AI驱动项目管理软件市场趋势报告》显示，2026年全球该领域市场规模已突破160亿美元，AI功能的实用性、与业务的适配度成为企业选型的核心考量。本文基于2026年市场实测数据、行业专家评审及海量用户反馈，筛选出排行榜前十的产品，以中立视角解析每款产品的核心优势，结合平台工具特性与用户思维给出选型参考，助力各类团队精准匹配需求。

一、2026年AI驱动项目管理软件排行榜前十权威解析

（一）禅道

作为国内开源AI项目管理软件的标杆，禅道2026年全面升级AI能力，深耕研发项目管理领域，兼顾敏捷与传统管理模式，适配多行业研发团队，核心优势集中在三大板块：

  • ​AI赋能全流程研发闭环​：新增AI智能需求解析功能，可自动识别需求文档中的核心要点并转化为可执行任务，结合Scrum、Kanban等敏捷框架，实现需求管理、迭代规划、缺陷跟踪的AI辅助闭环，大幅减少人工录入成本，适配研发团队全链路需求。
  • ​开源灵活且AI适配性强​：提供开源版、企业版多版本选择，开源版不限人数、免费使用，支持私有部署保障数据安全；AI模块支持自定义训练，可对接Git、Jenkins等开发工具，通过API接口扩展AI功能，尤其适合预算敏感的中小型研发团队。
  • ​AI可视化效能度量​：内置AI驱动的研发效能分析模块，可自动生成30+项度量指标，通过可视化图表直观呈现项目进度、团队效率瓶颈，还能给出AI优化建议，帮助管理者实现数据驱动的管理决策。

（二）Jira

Jira作为全球知名度最高的AI驱动项目管理软件之一，2026年升级AI预测模型，深耕IT研发领域，功能强大且生态完善，适配中大型企业及复杂项目，核心优势如下：

  • ​AI迭代风险精准预测​：基于历史项目数据训练的AI模型，可精准预估项目延期风险、资源缺口，自动给出资源调整建议，帮助团队提前规避风险，尤其适合复杂迭代项目的精细化管理。
  • ​AI生态集成能力突出​：与Atlassian生态下的Confluence、Bitbucket无缝衔接，同时支持与Slack、Microsoft 365等第三方工具集成，AI模块可跨平台同步数据，打通研发、协作、沟通全链路，解决“信息孤岛”问题。
  • ​AI自定义工作流​：支持通过AI生成自定义字段、工作流及仪表盘，可根据企业业务需求快速搭建专属管理模块，丰富的AI插件市场可覆盖测试管理、时间跟踪等场景，满足中大型企业多样化需求。

（三）Asana

Asana以“AI驱动任务协作”为核心，2026年优化AI轻量化适配能力，界面简洁、操作便捷，适配营销、运营、研发等多团队场景，核心优势如下：

  • ​AI任务智能管理​：支持AI任务拆分、优先级自动排序，可根据团队成员工作量智能分配任务，结合截止日期设置AI提醒，避免任务遗漏，降低团队沟通成本。
  • ​轻量AI适配性强​：无需复杂培训即可上手，AI看板视图可直观呈现任务流转状态，自动识别任务瓶颈并提醒，适配小型敏捷团队快速迭代，同时满足非研发团队的轻量管理需求。
  • ​AI跨团队协同​：支持多团队、多项目管理，AI可自动同步跨部门任务进度，与Slack、Google Workspace深度集成，实时推送任务更新，提升跨团队协作效率。

（四）Trello

Trello以“极简AI看板”为核心特色，2026年新增AI辅助功能，轻量易用、灵活度高，适合小型团队、初创团队及个人管理，核心优势如下：

  • ​AI简易操作赋能​：保留卡片式看板设计，新增AI语音创建任务、卡片智能分类功能，拖拽式操作结合AI辅助，新手可快速上手，极大降低学习成本。
  • ​轻量AI场景适配​：专注简单迭代管理，AI可自动识别任务标签、同步进度，支持Kanban框架，适合需求简单、迭代周期短的项目，兼顾轻量性与实用性。
  • ​AI扩展灵活​：通过Power-Ups扩展AI功能，可添加AI时间跟踪、文件智能整理等模块，与Google Drive、Slack等工具集成，根据用户需求灵活适配。

（五）Monday.com

Monday.com以“AI可视化工作流”为核心，2026年推出AI Agents功能，模块化设计、灵活度高，适配多行业、多规模团队，尤其适合非研发团队，核心优势如下：

  • ​AI Agents协同赋能​：支持接入ChatGPT、Gemini等主流AI代理，可自动组织项目、更新 workflows、生成报告，实现人机协同办公，大幅提升工作效率。
  • ​AI可视化自定义​：提供多种AI优化视图（看板、日历等），支持模块化拖拽配置，AI可根据业务流程自动推荐工作流模板，直观呈现项目进度与任务流转。
  • ​AI集成生态丰富​：拥有1800+应用集成生态，AI模块可与Zoom、CRM工具等无缝衔接，打通项目管理、客户管理全链路，满足企业多样化协作需求。

（六）ClickUp

ClickUp以“AI全功能集成”为特色，2026年升级AI智能生成功能，兼顾敏捷管理与通用项目管理，性价比高，适配各类规模团队，核心优势如下：

  • ​AI全功能覆盖​：整合AI任务管理、文档协作、时间跟踪等功能，可自动生成任务描述、拆分用户故事，根据会议纪要创建待办事项，无需额外搭配工具。
  • ​AI模板智能适配​：提供丰富的AI敏捷模板，可根据团队类型自动优化模板内容、工作流，快速适配不同团队的管理模式，提升项目启动效率。
  • ​AI高性价比优势​：多种定价方案兼顾各类团队，AI功能免费嵌入基础套餐，2026年用户性价比评分达4.9/5.0，是初创企业与中小型团队的优选。

（七）Basecamp

Basecamp以“AI简化协作流程”为核心，2026年优化AI沟通辅助功能，风格简洁，适配远程团队与中小型企业，核心优势如下：

  • ​AI任务与沟通一体化​：整合AI任务管理、沟通功能，可自动汇总任务评论、生成沟通纪要，直接在任务页面开展AI辅助沟通，简化协作流程。
  • ​AI远程协作适配​：支持跨时区协作，AI可自动同步不同时区任务进度、发送截止日期提醒，移动端适配完善，支持AI离线操作提醒，提升远程协作体验。
  • ​AI简易操作无门槛​：界面简洁直观，AI功能隐藏在核心操作中，无需专业培训，团队成员可快速上手，专注核心协作需求，适合注重简洁高效的团队。

（八）Microsoft Project

Microsoft Project作为企业级AI项目管理软件代表，2026年升级Copilot功能，兼顾传统与敏捷管理，稳定性强，适配大型企业及复杂项目，核心优势如下：

  • ​AI Copilot智能规划​：Copilot功能可根据项目名称和描述自动生成工作分解结构（WBS），分析风险登记册并给出缓解措施，自动生成项目状态报告，节省管理者时间。
  • ​AI生态紧密集成​：与Office 365、Microsoft Teams无缝衔接，AI可同步文档、沟通数据，契合大型企业现有办公生态，降低工具切换成本，提升协同效率。
  • ​AI企业级数据分析​：提供AI驱动的多维度报表，可直观呈现项目进度、资源利用率、成本消耗，自动给出优化建议，适配企业级管理决策需求。

（九）Smartsheet

Smartsheet以“AI数据驱动管理”为特色，2026年升级AI数据处理能力，兼顾敏捷管理与数据处理，适配数据密集型项目与企业，核心优势如下：

  • ​AI数据处理能力突出​：采用电子表格逻辑设计，AI可自动录入、筛选、分析复杂数据，关联项目任务与数据，适合财务、供应链等数据密集型项目管理。
  • ​AI敏捷与传统融合​：支持Kanban看板、甘特图等视图，AI可自动切换管理模式，根据项目需求推荐最优管理方式，适配既有敏捷又有传统规划需求的企业。
  • ​AI集成能力优秀​：与Excel、Power BI深度集成，AI可快速导入导出数据并进行智能分析，同时支持与Microsoft 365等工具衔接，打通数据与项目管理链路。

（十）Zoho Projects

Zoho Projects作为Zoho生态下的AI驱动工具，2026年搭载Zia Agents功能，性价比高、生态适配性强，适配中小型企业，核心优势如下：

  • ​AI生态兼容度高​：搭载Zia Agents AI解决方案，可与Zoho生态全系应用（CRM、Mail等）无缝衔接，实现项目管理与客户管理、邮件沟通的AI一体化协同。
  • ​AI基础功能完善​：支持Scrum、Kanban框架，AI可辅助任务管理、迭代规划、缺陷跟踪，功能实用无冗余，满足中小型企业基础AI管理需求。
  • ​AI高性价比优势​：定价低于市场均值30%，提供AI功能低价套餐，支持按需付费，同时提供完善的AI技术支持，适合预算敏感的中小型企业。

二、2026年AI驱动项目管理软件核心总结

本次榜单基于2026年市场实测、专家评审及用户反馈筛选，10款产品各有侧重、无绝对优劣，核心差异集中在AI功能适配性、生态集成及定价上，结合平台工具与用户思维可总结为两大核心视角：

从平台工具视角来看，所有产品均以“AI赋能效率”为核心，差异化体现在三个方向：一是全功能AI集成（如ClickUp、Microsoft Project），侧重AI覆盖项目全流程；二是轻量AI适配（如Trello、Basecamp），聚焦核心场景的AI简化操作；三是生态型AI赋能（如Monday.com、Zoho Projects），依托自身生态实现AI协同。所有产品均具备基础敏捷框架与AI结合的能力，稳定性与扩展性各有侧重。

从用户思维视角来看，选型核心是“AI功能与需求匹配”而非“功能越多越好”：中小型研发团队优先选禅道（开源AI）、Zoho Projects（高性价比AI）；非研发团队可选Asana、Monday.com（轻量AI+多场景适配）；大型企业优先选Microsoft Project、Jira（企业级AI+生态衔接）；数据密集型团队首选Smartsheet（AI数据处理）；初创团队可选Trello、ClickUp（轻量AI+低成本）。

三、实用FAQ（结合全文核心内容）

FAQ1：中小型研发团队，预算有限，想选AI功能实用的软件，优先选哪款？

优先选择禅道（开源版）或Zoho Projects。禅道开源版免费、无人数限制，支持私有部署，2026年升级的AI需求解析、效能分析功能完全适配研发团队，仅需少量技术维护成本；Zoho Projects搭载Zia Agents AI功能，基础AI管理功能完善，定价亲民，适合预算敏感、无需复杂AI功能的中小型研发团队。

FAQ2：非研发团队（如营销、运营），不懂复杂AI操作，适合哪款AI驱动项目管理软件？

适合，非研发团队的“快速迭代、任务零散”特点与AI驱动的轻量管理理念高度契合。优先选择Asana、Trello或Monday.com：Asana AI任务管理简易，无需复杂操作即可上手，适合跨部门协作；Trello AI功能轻量化，卡片式操作+AI辅助，适合小型非研发团队快速协作；Monday.com的AI Agents可自动完成基础操作，可视化界面简洁，适配营销、运营多场景。

FAQ3：大型企业有复杂项目管理需求，需AI赋能且衔接现有办公生态，该如何选型？

优先选择Microsoft Project或Jira。Microsoft Project的Copilot AI功能可实现复杂项目规划、风险预警与报告生成，与Office 365、Teams等微软办公生态无缝衔接，契合大型企业现有办公模式；Jira的AI风险预测、自定义扩展能力突出，可与Atlassian生态及第三方工具衔接，适合大型企业研发类复杂项目，同时支持AI与业务流程深度融合，满足多样化需求。

DuckDB-paimon 是由 PolarDB 团队开发的一款 DuckDB 扩展插件，让 DuckDB 能够直接读取和查询 Apache Paimon 格式的数据湖表，无需任何 ETL 搬运，无需 Flink/Spark 集群，打开 DuckDB Shell 即可对 Paimon 表执行 SQL 分析。

技术交流钉群：164165020808

DuckDB-paimon核心能力

直接读取 Paimon 表
无需任何中间转换，直接通过 SQL 查询 Paimon 表数据：

-- 通过完整路径读取
SELECT * FROM paimon_scan('./data/testdb.db/testtbl');
-- 通过 warehouse / database / table 三段式读取
SELECT * FROM paimon_scan('/warehouse', 'mydb', 'orders');

远程 OSS 存储支持
通过 DuckDB 的 Secret 机制，安全配置阿里云 OSS 访问凭证，直接查询存储在 OSS 上的 Paimon 数据湖：

-- 配置 OSS 访问凭证
CREATE SECRET paimon_oss (
TYPE paimon,
key_id 'your-access-key-id',
secret 'your-access-key-secret',
endpoint 'oss-cn-hangzhou.aliyuncs.com'
);
-- 直接查询 OSS 上的 Paimon 表
SELECT COUNT(*), region
FROM paimon_scan('oss://my-bucket/warehouse', 'sales_db', 'orders')
GROUP BY region
ORDER BY COUNT(*) DESC;

Projection Pushdown（列裁剪下推）

查询时只读取 SQL 中实际用到的列，大幅减少 I/O 开销，在宽表场景下效果尤为显著：

-- 只会读取 order_id 和 amount 两列的数据文件，其余列不会被读取
SELECT order_id, amount FROM paimon_scan('oss://...', 'db', 'orders');

作为 Catalog 挂载（ATTACH）
将 Paimon warehouse 作为一个完整的 Catalog 挂载到 DuckDB，像操作本地数据库一样浏览 Paimon 的 Schema 和表结构：
•

ATTACH 'oss://my-bucket/warehouse' AS paimon_lake (TYPE paimon);

SHOW ALL TABLES IN paimon_lake;
DESCRIBE paimon_lake.sales_db.orders;

DuckDB-paimon核心能力

实时湖仓的轻量即席查询
数据由 Flink 实时写入 Paimon，分析师用 DuckDB + Duckdb-paimon 直接在 OSS 上做即席（ad-hoc）查询，无需启动任何计算集群，查询延迟从分钟级降至秒级。
数据验证与质量检查
在 CI/CD 流水线中，用 DuckDB 对 Paimon 表做数据质量断言，验证 Flink 作业的输出结果是否符合预期，轻量、快速、无依赖。
数据探索与调试
数据工程师在开发 Flink 作业时，随时用 DuckDB Shell 查看 Paimon 表的当前状态，快速定位数据问题，效率远超启动 Flink SQL Client。
跨格式数据联邦查询
DuckDB 天然支持查询 Parquet、CSV、JSON、Iceberg 等多种格式，结合 Duckdb-paimon，可以将 Paimon 表与其他数据源做联邦 JOIN，无需数据搬运：
•

-- Paimon 订单表 JOIN 本地 CSV 维表
SELECT o.order_id, o.amount, c.customer_name
FROM paimon_scan('oss://...', 'db', 'orders') o
JOIN read_csv('customers.csv') c ON o.customer_id = c.id;

快速上手

构建
•

git clone --recurse-submodules https://github.com/polardb/duckdb-paimon.git
cd duckdb-paimon
GEN=ninja make

--recurse-submodules 会同时拉取 DuckDB 和 paimon-cpp 子模块，是构建所必需的。

运行
•
./build/release/duckdb

查询本地 Paimon 表
•

SELECT * FROM paimon_scan('./data/testdb.db/testtbl');

查询 OSS 上的 Paimon 表
•

CREATE SECRET my_oss (
TYPE paimon,
key_id 'your-ak',
secret 'your-sk',
endpoint 'oss-cn-hangzhou.aliyuncs.com'
);
SELECT * FROM paimon_scan('oss://your-bucket/warehouse', 'your_db', 'your_table');

我上周开源了一个项目，发了帖子，直接 0 回复 。www.v2ex.com/t/1205971

投稿了阮一峰的科技周刊，登上了才有一点人气。

这个项目主要开发给自己用，所以我没对它抱有太多的“推广”期待。但是关注这么低，我确实是没想到的。
v2 这里基本都是 AI 的重度使用者，使用 AI 的时候不会担心上传一些敏感信息吗。
尤其我在尝试用小龙虾整理笔记，我觉得有些信息，是不能上传大模型厂商的（虽然说不会用于训练，但，规则是防君子不防小人

楼主背景：牡丹，魔羯座，没有感情经验，又单身太多年，一是不知道怎么有效感情升温，二是怕用力过猛导致妹子不适facepalm求大家支个招
妹子背景：金牛座，暂时没有具体感情信息，但根据相处感觉和穿搭，妹子应该没谈过或者很少，属于安静朴实型的，也比较独立，不太喜欢麻烦别人和欠别人。

我和这个妹子加微信有快一年了，打球认识的，前期打了几回球就没再联系了，我对她还是有好感的，当时我找她要的微信，四五月的时候我邀请她出来玩，她没出来，就没下文了，主要也不知道妹子对我的感觉。（中间有一次打完球吃饭，妹子带我去一个她平常去的苍蝇馆子，对她印象比较好，能看出来是勤俭型的）

之前看到她发朋友圈，对看比赛比较感兴趣，我这个月邀请了一下，她同意了，当天她做地铁两个小时来看比赛，我给她带了小礼物，她很惊喜，估计没想到我会给她准备礼物，其实我也是试一试，如果妹子态度没什么回应，我估计也就算了。庆幸的是，当天回去给我发了微信说我很 nice，一顿夸夸。我觉得有戏。

前几天平安夜，我工作日打球刚结束，发现她在球馆，下班专门坐地铁来球馆给我送圣诞节礼物，一些糖果、苹果，一个小兜提着很可爱。

最新进展：上周去看阿凡达，我买了电影票，她提前去买了炸鸡咖啡吃的，看完一块走夜路走了不到一个小时，边散步边聊，送她到地铁站，分开前她说 要抱抱吗？我也不扭捏，直接大手一抱。

计划：元旦放假见两次面，一天打球+吃饭，一天晚上去看脱口秀，妹子已经同意了。

后面应该怎么逐渐升温，每次见面抱一抱吗？去看脱口秀那天准备牵手试试。

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. ...
  8. 110