最近在写一个监控港股异动的小工具，后端是用 Python 写的。在对接行情数据时，遇到了不少网络编程的经典问题，特此记录一下。

问题背景： 需求很简单：订阅大概20只港股科技股的实时价格，一旦涨跌幅超过阈值就报警。 一开始用了简单的 requests 轮询，结果发现要想达到实时的效果，请求频率太高，很容易触发服务端的 Rate Limit（速率限制），IP 直接被 Ban。

技术选型： 既然轮询行不通，那就必须上 WebSocket。这需要服务端支持主动推送。找了一圈，发现支持 WebSocket 的港股数据源并不多（大部分还是传统的 REST API）。最后锁定了 AllTick 的接口进行调试，文档写得比较清楚，鉴权方式也标准。

踩坑与填坑：

1. JSON 解析错误：服务端推送的数据并不总是完美的 JSON，有时候网络包截断会导致 json.loads 抛出异常。解决：加 try-catch，对于解析失败的包直接丢弃，保证主线程不挂。
2. 僵尸连接：有时候网络实际上已经断了，但客户端没有收到 Close 帧。解决：必须在应用层实现心跳检测（Ping/Pong），或者设置 socket 的超时时间。

代码实现： 这是我封装的一个健壮的 WebSocket 客户端类（伪代码结构）：

import websocket
import json
 
def on_message(ws, message):
    data = json.loads(message)
    print(data)
 
def on_error(ws, error):
    print(error)
 
def on_close(ws, close_status_code, close_msg):
    print("Closed")
 
def on_open(ws):
    print("Connected to the WebSocket")
 
ws_url = "wss://api.alltick.co/realtime/marketdata"
ws = websocket.WebSocketApp(ws_url, on_message=on_message, on_error=on_error, on_close=on_close)
ws.on_open = on_open
ws.run_forever()

def process_data(data):
    symbol = data['symbol']
    price = data['price']
    change = data['change']
    print(f"Stock: {symbol}, Price: {price}, Change: {change}%")
 
def on_message(ws, message):
    data = json.loads(message)
    process_data(data)

数据清洗 Tip： 拿到的原始数据通常包含很多冗余字段。为了减轻后续处理压力，建议在 process_data 函数里只提取 symbol, last_price, timestamp 这几个关键字段。

最终效果： 目前这个脚本跑在我的阿里云服务器上，内存占用不到 100MB，非常稳定。

在嵌入式系统、边缘节点或资源受限设备中IP查询库占用几十MB内存，是一个非常现实的工程挑战，最近我们需要在嵌入式设备上实现"IP属地与风险基础判断"，来做日志标记和简单策略决策，正好时机合适，我就我对比实测了两类方案：
一种是“10KB左右IP离线库”，另一种是“约50MB左右IP离线库”。两者在能力、代价和适用场景上差异非常明显。
问题是在嵌入式环境中，选型时的约束情况：

• 内存可能只有几十MB，甚至更低
• Flash/ROM空间有限
• 设备需要7×24小时运行稳定
• 升级和维护成本极高
  在这种前提下，任何一个第三方库，都要永久占用系统资源的一部分，包括IP查询库。

方案A（轻量级IP离线库约10KB）方案B（完整型IP数据库（约50MB）对比

示例一：10KB IP离线库

初始化（启动时加载到内存）

#include "ipdb_lite.h"

static ipdb_ctx_t ipdb_ctx;

int ipdb_init_once(void) {
    // 离线库以数组或小文件形式内嵌
    return ipdb_lite_init(&ipdb_ctx);
}

特点：

• 无文件IO或极少IO
• 常驻内存占用约10KB
• 启动时间几乎为0

IP查询（Bid/日志/策略路径）

ip_result_t result;

if (ipdb_lite_lookup(&ipdb_ctx, ip_str, &result) == 0) {
    // 基础属地
    printf("country=%s, province=%s\n",
           result.country,
           result.province);

    // 风险或类型标签
    if (result.is_proxy) {
        mark_ip_risk(HIGH_RISK);
    }
}

返回结构克制

typedef struct {
    char country[3];      // CN / US
    char province[16];    // 省级即可
    uint8_t is_proxy;     // 0 / 1
} ip_result_t;

总结，相对适合：

• 嵌入式设备
• 边缘网关
• SDK/Agent
• 只做基础判断的系统

示例二：50MBIP地址库

启动加载（文件/mmap）

#include "ipdb_full.h"

static ipdb_full_t *db;

int ipdb_init(void) {
    db = ipdb_full_open("/data/ipdb_full.bin");
    if (!db) {
        return -1;
    }
    return 0;
}

典型问题：

• 文件体积大
• 启动慢
• 设备 Flash / ROM 压力大

查询（字段多，但成本也高）

ipdb_record_t rec;

if (ipdb_full_query(db, ip_str, &rec) == 0) {
    printf("country=%s, province=%s, city=%s, isp=%s, asn=%d\n",
           rec.country,
           rec.province,
           rec.city,
           rec.isp,
           rec.asn);

    if (rec.risk_score > 80) {
        mark_ip_risk(HIGH_RISK);
    }
}

典型返回结构：

typedef struct {
    char country[8];
    char province[32];
    char city[32];
    char isp[32];
    int  asn;
    int  risk_score;
} ipdb_record_t;

问题不是“能不能查”，而是：

• 这些字段在嵌入式里是否真的用得上？
• 是否值得用 50MB 内存换？

——根据实际业务进行判断

从工程实践来看，在嵌入式和边缘设备场景中，IP查询库并不是“功能越全越好”，而是需要在内存占用、稳定性和实际使用价值之间做取舍。10KB级别的轻量IP离线库，虽然字段有限，但在资源受限环境下反而更符合系统长期运行的现实需求，但是如果追求长远，或者本身/短期内会达到一定资源数据，也可以选择数据库进行一步到位的策略。

五、工程层面的隐藏成本

除了内存占用，50MB 方案还带来了额外的工程复杂度：

• 文件分发和版本管理成本高
• OTA 升级时风险更大
• 数据损坏或加载失败影响面更广

相比之下，10KB 级别的 IP 查询库，在部署、升级、回滚和排查问题时，都明显更可控。

六、最终选择与经验总结

综合评估后，我们最终在嵌入式场景中选择了轻量级IP离线查询方案，并准备在后续稳定下来后在进行替换，在实际落地过程中，我们使用的是 IP 数据云提供的 IP 离线库方案。其特点是数据体量控制得相对克制，在嵌入式和边缘设备上内存占用极低，同时更新节奏和解析准确性也能满足业务需要。

本文以“收集—澄清—评审—排序—拆解—变更—验收”的全链路视角，实测对比 12 款需求管理系统/需求管理软件：ONES、Tower、Jira、Azure DevOps、YouTrack、GitLab、Aha! Roadmaps、Jama Connect、Polarion、IBM DOORS Next、Perforce Helix ALM、codebeamer，帮项目经理按场景做更稳的选型。

所谓需求混乱，底层都是需求没有一个“共同真相源”。没有共同真相源，项目经理就会被迫做“人肉同步器”——不断解释、不断对齐、不断背锅。久了不是效率问题，是信任被消耗：大家开始怀疑“说清楚有没有用”，然后用各自的方式留证据，系统就更碎了。

选一个合适的需求管理系统，并不是为了“更高级”，而是为了让团队在同一张地图上走路：需求从哪里来、怎么被理解、怎么被决定、怎么被交付、怎么被验证——都能留下痕迹。这才是项目能稳的基础。

怎么测评

我不太喜欢只看“功能清单”。项目里真正贵的，是需求在生命周期里不断失真造成的成本：返工、延期、争吵、质量事故，甚至客户关系受损。所以这次我用 6 个问题做对比——它们几乎对应项目里最常见的 6 类损失。

1）收集：需求从哪来，能否沉淀上下文？

好的需求管理工具要能记录来源（客户/一线反馈/运营数据/内部提案）与背景，否则需求只剩一句话，就会被不同角色各自解读。

2）澄清：需求“写清楚”了吗？

我把“清楚”拆成需求卡片五要素（也适用于 PRD/用户故事/需求条目）：

• 背景与目标（为什么做）
• 范围边界（做什么/不做什么）
• 验收标准（怎样算完成）
• 依赖与风险（会卡在哪）
• 版本与优先级（何时做、先做谁）

能承载这五件事，需求才更像“工程对象”，而不是“聊天记录”。

3）评审与排序：Backlog 是否可治理？

排序不是“谁声音大谁先做”。我更关心系统能否支持：需求评审记录、优先级字段、排序规则、路线图/迭代/里程碑，以及对“紧急插单”的可见化。

4）拆解与执行：需求是否能稳定落到任务与交付证据？

项目经理最怕“计划里很美，落到执行就断”。需求管理系统要能把需求拆到可执行单元（任务/子任务），并能回看进度与阻塞原因。

5）变更管理：有没有“基线 + 影响分析 + 例外机制”？

变更不可怕，可怕的是变更没有代价、没有痕迹。成熟团队通常会建立：

• 基线：某个时点的范围冻结版本
• 影响分析：影响模块/测试/排期/风险
• 例外机制：紧急变更走快速通道，但代价必须显性化

系统能否承载这套机制，是“能不能长期稳”的分水岭。

6）验收闭环：需求是否能连到测试、缺陷与发布说明？

如果需求无法关联验证证据，最后总会落到“感觉差不多”。对质量敏感的团队，需求—测试用例—缺陷—发布说明的链路是减少扯皮的现实办法。

2026年需求管理系统推荐清单：12款工具全流程实测

我会尽量把每个工具放回“需求生命周期”里说：它在哪些环节特别强、在哪些环节需要补方法或配套。

1）ONES：适合做全流程闭环的需求管理系统

ONES 属于研发项目与需求协同的一体化需求管理平台。把需求变成可流转、可拆解、可验证的工作项，你可以建立需求池，编写需求并自定义需求状态与属性，再把需求与相关任务规划到迭代中并分配负责人；同时通过看板、燃尽图等视图掌握进度，避免需求只停留在“提出”阶段。更关键的是，它把质量闭环放在同一条链路里：缺陷管理与 TestCase 数据互通，支持一键提 Bug，让需求的交付质量与进度能在同一套体系里被观察到，推动测试与研发高效流转。

在需求管理的关键环节上，ONES 的强项是把收集—澄清—评审—拆解—验收串得比较顺：在敏捷场景中，它支持用工单收集和整理各方反馈，产品负责人可以按优先级把需求规划到迭代，并与团队对齐需求评审与验收标准；在阶段性交付或瀑布项目里，ONES 更强调计划与变更的可视化，支持用项目计划创建 WBS 分解结构、设置任务依赖，用里程碑标记关键节点，同时也提供版本对比与变更追溯的思路，让“变更发生过什么、影响了什么”更可复盘。

ONES 的可配置空间很大，意味着你可以做出符合团队的需求模板、字段与流程，比较适合中小到中大型研发团队、既有敏捷迭代又有阶段性交付，希望减少跨系统断点、让需求可追踪可验收的团队。

2）Tower：轻量协作型需求管理系统

Tower 的定位更接近协作型需求管理系统，在软件研发场景下，Tower 支持迭代计划、需求管理、Bug 管理等，并能拆分和规划任务、分派负责人、跟踪进度，帮助团队实践敏捷研发；在产品设计场景也强调从产品路线规划到需求管理、评审协作都能在同一平台推进。

从需求管理能力上看，Tower 更擅长的是前半段：收集与协作澄清。你可以把需求以任务/条目的形式沉淀下来，让讨论、补充材料、责任人分配都发生在同一处。它同时提供多视图（列表、日历、看板、甘特等）来帮助不同角色用自己习惯的方式理解进度：产品可能更关注需求队列与优先级，研发更关注看板流转，项目经理更关注甘特与节点。

对于需求量不大、变更代价不高的团队来说，这种轻量方式反而更容易落地，因为需求管理系统最大的敌人往往不是功能不够，而是团队不愿意维护。如果团队还处在“先把需求讲清楚、让协作透明起来”的阶段，Tower 的门槛优势会比较明显。

3）Jira：研发执行型需求管理系统

Jira 把需求以 issue 的形式进入系统，通过 backlog 排序、迭代装载和流转状态来推动交付。Scrum board 的 backlog 会把项目的 issues 按 backlog 与 sprint 分组，你可以创建/更新 issue，通过拖拽排序，或把 issue 分配给 sprint、epic 或 version，并管理 epics 等。对项目经理来说，这一套机制的价值很直白：需求优先级不会只存在于口头讨论里，而是固化成可见的排序；迭代边界也不会只存在于 PPT 里，而是固化成 sprint 的装载内容。

它的局限也很典型：写清楚需求往往要靠团队自己建立模板与门禁，否则 story 很容易沦为“标题 + 一句描述”，最后验收时仍旧争执。换句话说，Jira 作为需求管理系统更像“执行与透明度引擎”，但“需求澄清质量”需要方法配套：验收标准、范围边界、非目标、依赖风险这些字段是否必须填，评审是否作为状态门禁，决定了 Jira 最终是“需求管理系统”还是“任务派发系统”。

4）Azure DevOps

Azure DevOps 的核心特点是把“需求工作项”与研发交付链路更紧地放在同一生态里，强调团队可以在 Kanban board 上管理工作项、跟踪进度，并将 work item 分配到不同层级（如 epics、features、stories）；这使得需求不仅可以被拆解，而且可以在板上被持续推进与可视化。

在“需求澄清”与“变更控制”上，Azure DevOps 同样需要方法配套：工作项字段、模板、审批门禁是否建立，决定了它是“需求管理系统”还是“工程任务管理系统”。实际体验里，一个常见的风险是：业务侧或非工程角色觉得入口偏工程化，导致需求仍旧先在系统外形成，再由项目经理/产品经理“搬运”进来。解决办法不是换工具，而是把入口做得更友好：例如用表单化/模板化方式强制写清验收标准与边界，把“需求写清楚”嵌入流程，而不是靠人盯。

5）YouTrack

当优先级变化、需求改变或某任务不再紧急时，YouTrack 可以把 issue 从 board 移回 backlog，保持团队当前工作聚焦；同时它支持在 backlog 里进行优先级处理（包括手动重排、保存搜索下的排序规则等），并且强调团队在评审、grooming/refinement 时可以直接在 backlog 中添加 issue。

当然它也有一定的局限性：当组织进入多团队、多项目组合管理或强合规审计时，YouTrack 作为需求管理系统更适合“团队级需求治理”，而不是“企业级需求工程平台”。但如果你的目标是提升团队协作质量、让需求不再靠口头对齐，YouTrack 往往是一个性价比高、落地阻力相对小的选择。

6）GitLab

GitLab 的需求管理系统能力，分两条线：一条是“工程合规意义上的 Requirement”，另一条是“产品/项目层面的 Epic 与 Roadmap”。在 Requirements Management 文档中，GitLab 明确说明：你可以创建 requirement 来反映行业标准要求的特性或行为；当不再需要时可以归档；requirements 是长期存在的，不会自动消失，除非手动清理。这个定位非常像“需求工程对象”：强调长期、可追踪、可管理生命周期。

GitLab 的独特优势在于：由于它本身就是开发协作与交付平台，需求条目（requirements/issues）、实现（merge request）、流水线与发布更容易在同一上下文里形成证据链。对于需要“从需求到交付证据”的团队，这种内聚性很有价值。但局限也很现实：它更偏工程语境，业务侧提需求的门槛可能更高；如果组织没有设计好“需求入口（表单/模板/桥接流程）”，需求仍会先在系统外形成，最终又回到项目经理搬运与对齐。作为需求管理系统，GitLab 适合“以代码为中心、强调可追溯与证据”的团队，但仍需要方法把“写清楚需求”这件事落到模板与评审门禁上。

7）Aha! Roadmaps

Aha! Roadmaps 更像“产品侧的需求管理系统”：它擅长把需求从“想法/方向”推进到“可规划的路线图对象”，并把不同阶段的协作与决策记录下来。在路线图层面，Aha 提供 features roadmap：可以在 Roadmaps -> Features 中查看即将进入各个 release 的 features，并通过过滤器调整视角，以适配不同受众或问题（例如只看某条产品线、某个团队、某个主题）。对需求管理系统来说，路线图是“排序决策的载体”：它把需求不再只视为 backlog 里的条目，而是视为对外承诺与对内协作的节奏安排。

局限也需要明确：Aha 更强在上游（需求成型、路线图、对齐价值），而研发执行与交付闭环通常需要对接 Jira、Azure DevOps、GitLab 等工具。换句话说，它常常是“需求管理系统（上游）+ 执行系统（下游）”的组合。项目经理要提前约定：哪些字段在哪边是主数据、状态如何映射、变更如何同步，否则会产生双系统维护成本。

8）Jama Connect

Jama Connect 的需求管理系统能力，核心关键词是 Traceability（追溯） 与 Verification（验证）。在变更场景中，Jama 的关系机制也强调“上游变化如何波及下游”：当条目被连接，它们的关系用于建立追溯；上游条目变化时，可以检查所有下游相关条目是否仍然准确，以验证需求的完整性。这种“变更影响检查”的思路，是合规与高风险行业团队最需要的“提前发现代价”。

这类工程级需求管理系统通常对流程纪律要求更高——你需要把需求拆分粒度、评审门禁、基线与验证策略跑起来，否则工具会显得“重、慢、难坚持”。但反过来，一旦团队真的需要面对审计、事故风险或复杂系统协同，Jama 的价值往往是“把隐性风险显性化”，让争论从情绪回到证据。

9）Polarion

Polarion 的定位更接近“组织级需求管理系统”：它强调在复杂系统的全生命周期里进行需求收集、编写、审批与管理，并以安全、透明的协作方式让分析、工程、QA、DevOps 等角色实时沟通。它把协作、追溯与工作流作为核心原则，并强调通过对每条需求的自动变更控制来支持审计、合规或监管检查——这意味着需求变更不是随手改一行，而是被流程化记录、可回溯、可证明。

Polarion 的适用场景多为：多项目多团队并行、需要统一口径与权限治理、且对追溯与审计有刚性要求的组织。局限同样是“平台型”代价：落地周期长、治理成本高，适合先从关键项目/关键模块试点，把需求分类体系、评审门禁、变更规则跑顺，再扩展到组织级统一。

10）IBM DOORS Next

DOORS Next 的核心能力围绕“追溯（traceability）”展开：官方明确提到可以用追溯来评估需求变更（或拟议变更）的影响与成本，并在引入 suspect indicators（可疑标记）后，当链接的工件发生变化会产生提示，提醒团队关注潜在影响、暴露隐藏成本，让追溯成为谈判与决策的基础。这对项目经理非常关键：当你处在接口多、依赖多、变更代价高的项目里，最怕的不是变更，而是“变更没有影响评估”。

另外，在 DOORS 的需求管理语境里，链接不仅提供追溯，也用于变更管理，帮助快速找出变更对项目的影响。适用场景多见于系统工程、嵌入式、软硬结合与高合规行业。局限是上手与推广成本较高：如果组织还停留在“需求一句话就开干”，DOORS Next 往往会被误解为文档负担；更合理的落地方式是先用它管理关键需求（法规/接口/安全），把追溯与影响分析跑起来，再逐步扩面。

11）Perforce Helix ALM

Helix ALM（Perforce ALM，原 Helix ALM）适合把需求管理当成“闭环系统”来做，它的需求管理模块用于在开发生命周期中跟踪需求，实现自动、持续的可追溯；覆盖需求全生命周期，包括规划、工作流、追溯、评审、变更管理与报告。

综合来看，Helix ALM 的需求管理系统能力更适合“质量闭环要求明确”的团队：你不仅要管理需求，还要把需求落实到测试计划、缺陷流转与质量报告里。它的局限与前提同样明显：套件化工具最怕“只用其中一小块”，导致闭环断开；要发挥价值，团队需要愿意把验收标准固化为可执行的测试资产，并建立基本的变更与基线纪律。对于软硬结合、对质量/合规更敏感的团队，这类需求管理系统通常能显著提升“可证明的交付”。

12）codebeamer

codebeamer 的核心功能点非常直接：端到端追溯与合规落地。PTC 的说明强调它不仅具备强需求管理能力，还内置风险与测试管理，并通过与 Jira、GitHub 等工具的可靠集成来确保完整需求追溯；对项目经理来说，这类工具的价值在于把需求、风险、验证证据放到同一张网里：当需求变了，你不仅要知道“谁改了什么”，更要能回答“影响了哪些风险项、哪些测试、哪些交付承诺”。

codebeamer 的适用场景常见于汽车、工业设备、医疗器械、航空航天等系统工程环境，以及软硬件协同开发。局限也同样典型：工程级平台对流程成熟度要求高，上线后必须配套需求分类、基线策略、评审与变更控制，否则团队会感到“重”；更稳的做法是从关键链路试点，把端到端追溯用起来，再扩大范围。

常见问题 FAQ：

Q1：需求管理系统和项目管理系统有什么区别？
A：项目管理更关注“按计划推进”，需求管理系统更关注“需求从收集到验收的证据链”。当需求失真是主要矛盾时，需求管理系统往往更能止血。

Q2：小团队需要上需求管理系统吗？
A：需要，但不一定要重。小团队的关键是“一个入口 + 写清楚 + 可追踪”，工具轻一点反而更容易落地。

Q3：需求变更管理一定要做吗？会不会太重？
A：不做也会发生，只是变更代价被隐藏在加班与返工里。轻量做法是“基线 + 影响分析一句话 + 谁拍板谁承担代价”。

Q4：怎么判断工具有没有“需求追溯能力”？
A：看它能不能把需求稳定关联到：任务/代码/测试用例/缺陷/发布说明，并且能一键反查“这个需求为什么变、谁批准、验证证据在哪”。

Q5：我们已经有很多工具了，还要再加一个需求管理系统吗？
A：不一定加，先判断是否存在“共同真相源”。如果需求在多个地方各写一份，项目经理长期做人肉同步器，那才是需要调整的信号。

过去几年，OCR（光学字符识别）正在从「字符识别工具」快速演进为以视觉—语言模型为核心的通用文档理解系统。在 Microsoft、Google 等全球性企业持续投入的同时，百度、腾讯、阿里云等中国头部厂商也在密集布局，推动市场从规则驱动的 OCR 向融合人工智能与自然语言处理的智能文档处理（IDP）快速升级，并在金融、政务、医疗等真实业务场景中不断深化应用。

伴随产业需求的持续拉动，OCR 的研究重心也发生了显著变化：模型不再只追求「识别准确率」，而是开始系统性地解决复杂版式、多模态符号、长上下文建模以及端到端语义理解等更具挑战性的问题。如何高效编码二维视觉信息、更高效解析文本信息，以及如何让模型的阅读顺序更贴近人类的认知逻辑，正成为学术界与工业界共同关注的核心议题。

正是在这种高度互动的背景下，持续追踪并梳理最新的 OCR 学术论文，对于把握技术前沿方向、理解产业真实挑战、乃至寻找下一阶段的范式突破，都显得尤为关键。

*本周， 我们为大家推荐的 5 篇 OCR 的热门 AI 论文*，涵盖 DeepSeek、腾讯、清华大学等团队，一起来学习吧 ⬇️

此外，为了让更多用户了解学术界在人工智能领域的最新动态，HyperAI超神经官网（hyper.ai）现已上线「最新论文」板块，每天都会更新 AI 前沿研究论文。

最新 AI 论文：https://go.hyper.ai/hzChC

本周论文推荐

1

DeepSeek-OCR 2:

Visual Causal Flow

DeepSeek-AI 研究人员在 DeepSeek-OCR 的基础上进一步提出 DeepSeek-OCR 2，如果说 DeepSeek-OCR 是对通过二维光学映射压缩长上下文可行性的一项初步探索，那么 DeepSeek-OCR 2 的提出旨在探究一种新型编码器——DeepEncoderV2——在图像语义驱动下动态重排视觉标记（visual tokens）的可行性。DeepEncoder V2 被设计为赋予编码器因果推理能力，使其能够在基于 LLM 的内容理解之前，智能地重新排列视觉标记，取代僵化的光栅扫描处理方式，从而实现更接近人类、语义连贯的图像理解，提升 OCR 与文档分析能力。

论文及详细解读 ： https://go.hyper.ai/ChW45

DeepSeek-OCR 2 架构示例

训练数据集由 OCR 1.0、OCR 2.0 和通用视觉数据组成，其中 OCR 数据占训练混合数据的 80%。评估时，使用 OmniDocBench v1.5，该基准包含 1,355 页中英文文档，涵盖杂志、学术论文与研究报告，共 9 个类别。

2

LightOnOCR: A 1B End-to-End

Multilingual Vision-Language Model

for State-of-the-Art OCR

LightOn 研究人员推出了 LightOnOCR-2-1B，这是一款紧凑的 10 亿参数多语言视觉-语言模型，可直接从文档图像中提取干净、有序的文本，在性能上超越更大模型，同时通过 RLVR 增加图像定位能力，并通过检查点合并提升鲁棒性，模型与基准测试已开源。

论文及详细解读 ： https://go.hyper.ai/zXFQs

一键部署教程链接： https://go.hyper.ai/vXC4o

LightOnOCR 架构示例

LightOnOCR-2-1B 数据集结合了来自多个来源的教师标注页面，包括扫描文档以增强鲁棒性，以及用于版式多样性的辅助数据。包含由 GPT-4o 标注的裁剪区域（段落、标题、摘要）、空白页样例以抑制幻觉，以及通过 nvpdftex 流程从 arXiv 获取的 TeX 衍生监督。添加公开 OCR 数据集以增加多样性。

3

HunyuanOCR Technical Report

本文提出 HunyuanOCR，这是一个由腾讯及合作者开发的 10 亿参数开源视觉-语言模型，通过数据驱动训练和新颖的强化学习策略，采用轻量级架构（ViT-LLM MLP适配器）统一了端到端的 OCR 能力——包括文本定位、文档解析、信息抽取和翻译，性能超越更大模型和商业 API，实现了工业与科研应用中的高效部署。

论文及详细解读： https://go.hyper.ai/F9fni

一键部署教程链接： https://go.hyper.ai/C4srs

HunyuanOCR 架构示例

本文实验使用 HunyuanOCR 在 OmniDocBench 上评估文档解析性能。取得 94.10 的最高总分，超越所有其他模型（包括更大模型）。

HunyuanOCR 实验结果示例

4

PaddleOCR-VL:

Boosting Multilingual Document

Parsing via a 0.9B Ultra-Compact

Vision-Language Model

百度团队提出 PaddleOCR-VL，一种资源高效的视觉-语言模型，融合了 NaViT 风格的动态分辨率编码器与 ERNIE-4.5-0.3B 模型，实现了多语言文档解析的最先进性能，能够准确识别表格、公式等复杂元素，在保持快速推理能力的同时，优于现有方案，适用于真实场景的部署。

论文及详细解读 ： https://go.hyper.ai/Rw3ur

****一键部署教程链接： https://go.hyper.ai/5D8oo

PaddleOCR-VL 框架示例

本文实验在OmniDocBench v1.5、olmOCR-Bench 和 OmniDocBench v1.0 上评估页面级文档解析，于 OmniDocBench v1.5 上取得 92.86 的最先进总体得分，优于 MinerU2.5-1.2B（90.67），在文本（编辑距离 0.035）、公式（CDM 91.22）、表格（TEDS 90.89 与 TEDS-S 94.76）和阅读顺序（0.043）方面均领先。

PaddleOCR-VL  表格识别结果示例

5

General OCR Theory: Towards

OCR-2.0 via a Unified

End-to-end Model

StepFun、旷视科技、中国科学院大学和清华大学的研究人员提出 GOT，一个 5.8 亿参数的统一端到端 OCR-2.0 模型，通过高压缩编码器和长上下文解码器，将识别能力从文本扩展到多种人工光学信号——如数学公式、表格、图表和几何图形，支持切片/整页输入、格式化输出（Markdown/TikZ/SMILES）、交互式区域级识别、动态分辨率和多页处理，显著推动了智能文档理解的发展。

论文及详细解读 ： https://go.hyper.ai/9E6Ra

一键部署教程链接： https://go.hyper.ai/HInRr

GOT 架构示例

本文实验在 8×8 L40s GPU上 完成三阶段训练：预训练（3 轮，批量大小 128，学习率 1e-4）、联合训练（1 轮，最大 token 长度 6000）、后训练（1 轮，最大 token 长度 8192，学习率 2e-5），前一阶段保留 80% 数据以维持性能。

GOT 在 ChartQA-SE 与 PlotQA-SE 两个基准测试结果示例

以上就是本周论文推荐的全部内容，更多 AI 前沿研究论文，详见 hyper.ai 官网「最新论文」板块。

同时也欢迎研究团队向我们投稿高质量成果及论文，有意向者可添加神经星星微信（微信号：Hyperai01）。

下周再见！

回看中国大数据产业走过的第一个十年，真正经得起时间检验的，并不只是概念创新或阶段性风口，而是那些在基础技术与产业实践中长期投入、持续演进的选择。随着产业逐步进入深水区，一些曾经并不喧哗、却始终指向长期价值的技术路线，开始被重新审视与确认。

近日，在上海举行的 2025 第八届金猿大数据产业发展论坛上，TDengine 创始人 & CEO 陶建辉入选「2025 中国大数据产业年度趋势人物 · 十年先锋人物」榜单。该榜单由金猿组委会联合数据猿、上海市数商协会、上海大数据联盟等机构发布，面向中国大数据产业发展第一个十年，对在关键技术方向和产业实践中产生持续影响的代表人物进行集中评选。

本届论坛以“数据有猿·智见十年”为主题，在上海市数据局指导下举办。论坛围绕中国大数据产业自 2015 年上升为国家战略以来的发展脉络，从技术演进、产业落地、组织形态与商业模式等多个层面，对过去十年的实践经验与未来趋势进行了系统性讨论。作为论坛的重要组成部分，金猿榜单通过初审、公审与终审等多轮评选机制，最终形成涵盖人物、产品、技术、应用及国产化方向的八大类年度榜单。

「十年先锋人物」榜单，侧重考察候选人在较长时间尺度内，对产业方向的判断能力与持续投入情况。评审重点并不局限于单一成果或阶段性成绩，而是关注其在关键技术路径上的长期实践，以及对行业发展的现实影响。

陶建辉长期从事基础软件与时序数据相关技术研发，是开源时序数据库 TDengine TSDB 的主要作者。自 2017 年创办涛思数据以来，他持续聚焦时序数据在工业、能源、物联网等场景中的规模化应用问题，围绕高并发写入、长期存储、实时分析与成本控制等核心挑战，推动相关技术体系不断演进，并逐步从单一数据库能力，向更完整的工业数据管理体系延伸。

在此次金猿榜给出的趋势观点中，陶建辉提出，随着 AI 技术在各行业的加速落地，时序数据库的角色正在发生变化。未来的时序数据系统，将不再局限于“存好数据、查快数据”，而是需要在数据库能力之上，进一步整合数据采集、建模、治理、计算、分析与可视化等关键环节，形成端到端的数据处理与价值输出能力。正是在这一背景下，工业数据管理平台 TDengine IDMP 被提出。TDengine IDMP 构建在 TDengine TSDB 之上，面向已经高效接入并存储的时序数据，提供统一的数据建模、治理与分析支撑能力，并通过引入 AI 原生的数据消费与决策辅助方式，使时序数据在业务侧和智能应用中被更高效、更直接地使用。

论坛期间，金猿榜同步举行了颁奖仪式，相关入选人物与机构获颁荣誉奖杯。榜单及评选结果将通过数据猿及多家行业媒体渠道对外发布，面向金融、工业、能源、医疗、政务等多个领域，集中展示中国大数据产业在技术融合与实际应用层面的阶段性进展。

对陶建辉而言，此次入选并非一个阶段性的终点，而更像是对过去十年技术判断与长期投入的一次集中回望。随着大数据与 AI 技术进一步走向融合，时序数据作为底层基础能力的重要性仍在不断放大，而围绕其在工业与真实业务场景中的持续演进，也仍将是一条需要耐心与长期主义支撑的技术道路。

一、项目管理工具选型决定团队效能天花板

在数字化协作成为企业基础设施的今天，项目管理软件已从单纯的任务登记工具进化为组织效能的核心枢纽。面对混合办公模式的常态化与敏捷开发理念的普及，选对一款与团队基因契合的管理工具，往往能让项目交付效率获得指数级提升。

本文立足2026年市场格局，深度剖析十款在各自细分领域建立标杆地位的项目管理解决方案。分析维度覆盖从传统瀑布流管理到敏捷开发的完整光谱，既有国际巨头的成熟生态，也有本土厂商的深耕创新。全文秉持中立客观立场，不做简单的优劣判定，而是通过还原每款产品的设计逻辑与最佳实践场景，为不同规模、不同行业特性的团队提供精准的选型参考坐标。

二、十款主流项目管理软件深度解析

（一）禅道（ZenTao）—— 国产研发管理的方法论践行者

公司背景
禅道由青岛易软天创网络科技有限公司于2009年推出，是国内最早专注于研发项目管理领域开源解决方案的服务商。经过十六年迭代，已从单一工具发展为覆盖软件研发全生命周期的综合管理平台，累计服务超过100万家企业，在本土开发者社区拥有极高声量。

产品介绍
禅道是一款基于Scrum敏捷开发思想设计的项目管理软件，集产品管理、项目管理、质量管理、文档管理、组织管理于一体。其设计理念深度契合中国软件企业的管理习惯，既支持传统的瀑布式开发流程，也完整覆盖敏捷迭代模式，是国内少有的同时适配CMMI和敏捷双模管理的综合性平台。

适用场景
中小型软件研发团队、互联网产品部门、IT外包服务企业、需要严格遵循研发流程规范的传统企业数字化部门。

功能深度
核心优势在于对研发全流程的精细化管控：需求池管理支持优先级矩阵与影响分析；任务拆解可细化到小时级工时统计；测试管理模块内置用例库与Bug生命周期追踪；代码集成支持与SVN、Git等版本控制系统深度对接。开源版本功能已能满足基础研发管理需求，企业版则提供更强的报表分析与自定义工作流能力。

适用行业
软件开发、互联网产品、系统集成、嵌入式开发、金融科技研发部门。

核心功能
产品路线图规划、迭代（Sprint）管理、测试用例库、Bug追踪与解决流程、代码审查集成、工时统计与成本核算、多项目资源调配看板。

客户群体
从5人规模的创业技术团队到5000人以上的大型软件企业均有覆盖，典型客户包括用友网络、海康威视、国家电网等企业的数字化部门，以及大量中小型互联网公司和外包服务商。

（二）Jira —— 全球敏捷开发的事实标准

公司背景
由澳大利亚Atlassian公司于2002年推出，经过二十余年发展，Jira已成为全球软件研发团队的首选工具。Atlassian作为协作软件领域的巨头，旗下还拥有Confluence、Bitbucket等明星产品，形成了完整的研发协作生态。

产品介绍
Jira最初定位为Bug追踪系统，现已进化为支持任意类型项目管理的可配置平台。其最大特点是极高的自定义能力，通过灵活的工作流引擎、字段自定义与插件市场，能够适配从简单任务跟踪到复杂企业级项目组合管理（PPM）的各种需求。

适用场景
技术驱动型团队、采用敏捷（Scrum/Kanban）或DevOps实践的研发部门、需要跨部门协作的中大型企业、对流程自动化有复杂需求的组织。

功能深度
在敏捷方法论支持上无人能及：原生支持Scrum板、看板、路线图（Roadmaps）等多种视图；Advanced Roadmaps功能可实现跨团队项目组合管理；Automation引擎允许零代码设置复杂规则（如状态变更自动通知、父子任务联动）；与Bitbucket、GitHub等代码托管平台无缝集成，实现从需求到代码的完整追溯链。

适用行业
互联网科技、金融服务（需配合合规插件）、游戏开发、电信软件、电商平台开发、SaaS服务商。

核心功能
敏捷看板与燃尽图、自定义工作流引擎、高级路线图规划、自动化规则配置、服务台（Service Desk）模块、强大的权限与角色管理体系、超过3000个第三方插件集成。

客户群体
全球超过7万家企业用户，包括Spotify、Airbnb、Cisco等科技巨头，以及国内出海企业的技术团队。适合已具备一定敏捷实践基础，希望深度定制管理流程的技术组织。

（三）Trello —— 可视化协作的开创者

公司背景
同样隶属于Atlassian公司，Trello于2011年上线，由Fog Creek Software团队开发。其简洁直观的看板式界面迅速风靡全球，2017年被Atlassian收购后进一步强化了与Jira等产品的生态协同。

产品介绍
Trello采用Kanban方法论的极致简化理念，以看板（Board）、列表（List）、卡片（Card）三层结构构建所有项目视图。这种极低的学习成本设计使其成为非技术团队入门项目协作的首选工具，同时通过Power-Ups插件系统扩展功能边界。

适用场景
内容创作团队、市场运营部门、个人项目管理、轻量级敏捷团队、需要快速上手无需培训的临时项目组、跨部门需求收集与流转。

功能深度
优势在于零门槛与极致灵活：拖拽式操作直观自然；卡片可承载清单、截止日期、附件、标签等多重信息；Butler自动化工具支持基于规则或触发器的自动化；视图支持日历、时间轴、仪表板等多种展示方式。但对于需要复杂工时统计、资源平衡或财务跟踪的重度项目管理场景支撑较弱。

适用行业
广告营销、媒体出版、教育培训、初创企业通用管理、非营利组织、电商运营、活动策划。

核心功能
可视化看板视图、卡片清单与Checklist、内置自动化（Butler）、Power-Ups插件市场（支持与Slack、Google Drive等集成）、移动端体验优化、团队协作评论与@提及功能。

客户群体
全球超过200万用户，涵盖从个人自由职业者到大型企业的混合使用场景。尤其适合追求极简操作、无需复杂汇报层级的小型团队或部门级协作。

（四）Asana —— 任务流管理的精细化标杆

公司背景
2008年由Facebook联合创始人Dustin Moskovitz和工程师Justin Rosenstein创立，旨在解决组织内部的"工作混乱"问题。Asana目前是硅谷估值最高的生产力工具独角兽之一，服务于全球数万家企业。

产品介绍
Asana定位于"团队任务操作系统"，在保持简洁体验的同时提供了惊人的功能深度。其设计哲学强调" clarity of plan"（计划清晰），通过多维度任务分解、时间线规划与智能自动化，帮助团队将战略目标层层分解为可执行动作。

适用场景
中大型跨职能团队、需要OKR对齐的组织、市场营销与产品规划部门、远程协作团队、对任务依赖关系与关键路径有明确管理需求的项目。

功能深度
里程碑与投资组合管理是其特色：时间线（Timeline）视图类似Gantt图但更易用；工作负载（Workload）功能可可视化团队成员的任务饱和度，避免资源冲突；规则构建器支持自动化常规流程；表单功能允许外部人员提交工作请求并自动转为任务。在复杂任务关系管理与跨项目资源视图方面表现卓越。

适用行业
科技互联网、专业咨询、金融服务、零售电商、医疗健康运营、教育机构行政管理。

核心功能
列表/看板/时间线/日历多视图切换、任务依赖与关键路径标记、目标（Goals）与OKR跟踪、工作负载均衡视图、自定义字段与模板、审批工作流、智能对抗截止日期冲突的调度建议。

客户群体
包括亚马逊、日本航空、维亚康姆CBS等大型企业，以及快速成长的中小型企业。适合需要平衡灵活性与结构化的现代化知识工作团队。

（五）Monday.com —— 可定制工作系统的视觉化先锋

公司背景
2012年成立于以色列特拉维夫（原名dapulse），2017年更名为Monday.com并在2021年纳斯达克上市。作为近年来成长最快的Work OS平台，以其色彩鲜明的高度可视化界面著称。

产品介绍
Monday.com自称为"Work Operating System"（工作操作系统），采用类似电子表格的行列表格作为基础交互范式，但赋予其强大的数据库功能与自动化能力。其核心理念是让用户无需编程即可构建定制化的工作流应用，覆盖从项目管理到CRM、HR、设备管理等多种业务场景。

适用场景
需要可视化追踪多维数据的团队、非技术背景用户主导的项目管理、跨部门流程标准化建设、创意与设计团队、销售管道管理、库存与资产管理。

功能深度
积木式模块构建是核心优势：列类型（Column Types）支持文本、数字、状态标签、人员分配、时间线、公式计算等20余种数据格式；视图可一键切换为甘特图、看板、日历、地图或表单；Dashboard功能允许拖拽式创建实时数据仪表板；自动化食谱（Recipes）覆盖从通知触发到跨平台数据同步的多种场景。学习曲线比Trello陡峭，但远低于Jira。

适用行业
广告与创意机构、建筑施工管理、房地产、制造业供应链、教育机构、婚庆与活动服务、法律事务所案件管理。

核心功能
可视化工作板块构建、多视图甘特图与日历、自动化工作流食谱、Dashboard数据仪表板、文档协作与文件版本管理、时间跟踪与计费、Guest权限管理供外部协作。

客户群体
服务超过15万家企业，包括康卡斯特NBC环球、联合利华、Adobe、可口可乐等品牌。特别适合厌倦了传统项目管理工具僵化结构、希望按自身业务逻辑灵活定制管理视图的团队。

（六）Notion —— 全能型知识工作空间

公司背景
2016年在美国旧金山成立，由Ivan Zhao和Simon Last创立。Notion以其"All-in-one"的产品理念重新定义了生产力工具，2021年估值达到100亿美元，成为知识管理领域的现象级产品。

产品介绍
Notion本质上是一个灵活的协作空间，模糊了笔记、数据库与项目管理之间的界限。用户可以通过拖拽块（Block）的方式自由构建页面，既可以作为Wiki知识库，也可以转化为具有关系型数据库功能的项目管理系统。其模块化设计允许团队从零开始搭建完全定制化的工作空间。

适用场景
知识密集型团队、需要强大文档管理与项目跟踪结合的场景、初创公司搭建内部知识库、产品需求文档（PRD）管理、个人知识管理与项目看板整合、远程团队的文化建设。

功能深度
数据库功能的灵活性无与伦比：Database支持表格、看板、日历、时间轴、画廊、列表六种视图；页面间可建立双向链接与关系引用；公式功能支持复杂计算；模板库丰富且社区活跃；近期推出的Notion AI进一步增强了智能总结与内容生成能力。但作为纯项目管理工具，其任务依赖、资源分配、高级报表等功能不如专用软件深入。

适用行业
互联网科技与产品团队、媒体编辑与内容创作、高校研究团队、设计工作室、咨询公司知识管理、个人生产力进阶用户。

核心功能
Block-based富文本编辑器、关联型数据库（支持Relation与Rollup）、多维视图切换、模板系统与社区画廊、Wiki与文档协作、Notion AI集成、与Slack、GitHub等工具的API集成。

客户群体
全球超过3000万用户，包括Figma、Pixar、Match Group等创新企业。适合将知识沉淀与项目执行视为同等重要的团队，以及追求高度定制化工作流的技术型团队。

（七）Tower —— 本土协作的简洁派代表

公司背景
由成都滴墨科技有限公司于2012年推出，是国内最早专注于云端项目协作的SaaS产品之一。经过十余年本土化迭代，Tower在中文用户体验与即时通讯集成方面形成了独特优势，2021年被企业微信生态深度整合。

产品介绍
Tower定位于"简单好用的团队协作工具"，摒弃了复杂的功能堆砌，专注于任务管理的核心循环：创建-分配-跟踪-完成。其界面设计遵循极简主义，通过清晰的任务分组与进度可视化，帮助团队快速建立协作秩序。

适用场景
中小型互联网团队、市场运营与活动策划部门、教育培训机构、律师事务所案件协作、轻量级软件研发、设计项目交付跟踪。

功能深度
在中文场景优化上尤为突出：任务讨论原生支持中文@提及与 Markdown 语法；与微信生态深度打通，支持微信端实时通知与快速操作；支持任务的多级检查项（Checklist）与多维度标签筛选；甘特图视图可直观展示任务时间线与依赖关系。但在复杂权限控制、多项目管理、高级报表分析等方面功能相对精简。

适用行业
互联网初创公司、广告营销机构、教育培训、新媒体运营、咨询服务、文创设计工作室。

核心功能
任务看板与列表视图、甘特图时间规划、多层级任务结构、微信生态深度集成、文件共享与版本管理、日程安排与提醒、团队知识库（Docs）模块。

客户群体
累计服务超过百万个团队，涵盖从自由职业者组合到数千人规模的企业。特别适合重视移动办公体验、依赖微信沟通、追求快速上手无需复杂培训的中文用户群体。

（八）Teambition —— 阿里生态的数字化协作中枢

公司背景
2011年在上海创立，由齐俊元等人创办，是国内最早的SaaS协作工具之一。2019年被阿里巴巴集团全资收购，现已深度整合进钉钉生态，成为阿里系企业数字化办公的核心组件，同时保持独立版本的运营。

产品介绍
Teambition采用"项目-任务-文件"的三层架构，强调以项目为单元的集中式协作。其产品设计高度符合中国企业的管理习惯，在任务流转的灵活性、项目模板的丰富性以及与国内云服务的集成度上表现突出。

适用场景
使用钉钉作为办公平台的企业、需要强文件管理与任务流结合的团队、敏捷开发团队、市场与销售部门的项目协作、教育科研项目管理、建筑工程现场管理。

功能深度
与阿里生态的无缝协同是核心壁垒：与钉钉日程、审批、IM消息深度打通；支持自定义项目模板与工作流，适应不同行业场景；提供统计视图可查看项目健康度与成员贡献；知识库功能支持多人实时编辑；近期强化了表格视图与自动化工作流能力。对于非阿里生态用户，其独立版本的竞争力主要体现在界面友好度与功能完整性平衡上。

适用行业
互联网与软件开发、电商运营、新零售、教育培训、建筑设计、制造业项目管理、政府与事业单位数字化部门。

核心功能
项目看板与多视图切换（看板/列表/时间轴/日历）、自定义工作流与字段、钉钉生态深度集成、企业级文件管理与在线预览、工时登记与统计、项目风险预警、自动化规则配置。

客户群体
服务超过千万用户，包括小米、海尔、滴滴出行、哔哩哔哩等知名企业。特别适合已采用钉钉作为统一办公入口、希望项目管理工具与即时通讯无缝衔接的中大型企业。

（九）ClickUp —— 全能型生产力套件的黑马

公司背景
2017年在美国旧金山成立，由Zeb Evans创立。ClickUp以"One app to replace them all"的激进定位迅速崛起，通过极高的功能密度与激进的免费策略，在短短几年内跻身行业第一梯队，2021年估值达40亿美元。

产品介绍
ClickUp是一款功能极其丰富的生产力平台，几乎整合了项目管理、文档协作、白板、聊天、目标跟踪、时间管理等多种工具的能力。其设计理念是让用户无需在不同应用间切换，在一个平台内完成所有知识工作。

适用场景
工具整合需求强烈的团队、Remote-first的分布式团队、对功能丰富度要求高于易用性的用户、需要内置白板与思维导图的产品团队、希望替代多种单一工具的成本敏感型组织。

功能深度
功能覆盖面广到令人惊讶：Everything视图可跨所有层级查看任务；白板（Whiteboards）功能支持无限画布协作；文档（Docs）支持嵌入任务与数据库；原生支持Email集成可直接将邮件转为任务； even内置屏幕录制与截图标注功能；自动化与集成功能同样强大。但 learning curve 较陡峭，功能过多可能导致新手困惑，移动端体验相对桌面端薄弱。

适用行业
科技初创公司、数字营销机构、产品设计与研发、咨询服务、电子商务运营、自由职业者工作室。

核心功能
多层级任务结构（Spaces/Folders/Lists/Tasks）、Everything全局搜索与视图、内置白板与思维导图、文档与维基、目标（Goals）与OKR跟踪、屏幕录制与剪辑、原生聊天与评论、超过1000个集成与强大的原生自动化。

客户群体
拥有超过1000万用户，包括Google、Airbnb、Netflix、Nike等企业的团队。适合愿意投入时间学习、希望用单一平台替代Asana+Notion+Slack多个工具的技术驱动型团队。

（十）Microsoft Project —— 经典项目管理的权威标杆

公司背景
作为微软Office家族历史最悠久的成员之一，Microsoft Project自1984年推出首个DOS版本以来，一直是专业项目管理领域的黄金标准。历经近四十年演进，现已发展为涵盖桌面端、云端（Project for the Web）与企业级项目组合管理（PPM）的完整解决方案。

公司背景
作为微软Office家族历史最悠久的成员之一，Microsoft Project自1984年推出首个DOS版本以来，一直是专业项目管理领域的黄金标准。历经近四十年演进，现已发展为涵盖桌面端、云端（Project for the Web）与企业级项目组合管理（PPM）的完整解决方案。

产品介绍
Microsoft Project代表了传统瀑布式项目管理的最高水准，以强大的甘特图功能、资源管理与财务跟踪能力著称。最新版本已与Microsoft 365生态深度整合，提供更现代的协作体验，同时保留了专业项目经理所需的复杂排程与关键路径分析能力。

适用场景
大型复杂项目（如工程建设、制造业研发）、需要严格遵循PMI项目管理规范的组织、专业项目经理主导的环境、多项目资源池管理、有复杂财务预算与成本控制需求的项目、 waterfall 模式为主的政府与企业项目。

功能深度
在企业级功能上无可匹敌：支持任务分解结构（WBS）与多级里程碑；资源管理支持工时、材料与成本资源的混合调配；内置挣值分析（EVM）用于项目绩效评估；Project Online支持项目组合优化与战略对齐；与Power BI集成提供高级商业智能分析。但协作体验相对现代SaaS工具较重，敏捷支持是后期补充功能而非原生设计。

适用行业
建筑工程与房地产、能源与公用事业、航空航天与国防、政府公共项目、金融服务IT、大型制造业、专业项目管理咨询。

核心功能
专业级甘特图与网络图、资源池与资源平衡算法、多项目组合管理（PPM）、财务跟踪与预算管理、挣值管理（EVM）、与Teams/SharePoint集成、Power BI高级报表、桌面端与云端混合部署。

客户群体
全球财富500强企业中的主流选择，广泛应用于政府工程、大型基建、制药研发等重监管行业。适合拥有专业项目管理办公室（PMO）、需要严格方法论与合规性的大型组织。

三、选型决策框架：如何匹配最适合的工具

面对十款各具特色的产品，决策不应基于简单的功能对比，而需建立系统性的评估框架：

1. 方法论适配性优先

敏捷导向团队（Jira、禅道、Trello）与瀑布式管理（Microsoft Project）有着截然不同的底层逻辑。若团队采用Scrum或Kanban，应选择原生支持敏捷框架的工具；若为传统工程建造类项目，甘特图与关键路径分析能力更为关键。

2. 团队规模与复杂度曲线

• 5-20人初创团队：Trello、Tower、Teambition的轻量级特性更能降低管理 overhead
• 50-200人成长期企业：禅道、Asana、Monday.com的平衡性更优
• 500人以上复杂组织：Jira、Microsoft Project、ClickUp的企业级功能不可或缺

3. 生态系统考量

评估工具与现有技术栈的集成深度：钉钉生态优先考虑Teambition；企业微信用户适合Tower；Microsoft 365重度用户选择Microsoft Project或Asana；开发者团队则需考察与Git、CI/CD工具的集成能力。

4. 总拥有成本（TCO）评估

除订阅费用外，需计算学习成本（ClickUp、Jira配置复杂）、迁移成本（历史数据导入难度）与定制开发成本（开源禅道的二次开发潜力 vs SaaS工具的API限制）。

四、结语

项目管理软件的选择本质上是一次组织工作方式的数字化映射。禅道以其对本土研发管理场景的深刻理解与开源灵活性，在国产替代浪潮中持续领先；Jira、Microsoft Project等国际产品则在方法论成熟度与生态广度上保持优势；而Monday.com、Notion、ClickUp等新兴力量正在重新定义"工作操作系统"的边界。

没有完美的工具，只有最契合的匹配。建议团队从实际痛点出发，利用各产品提供的免费试用期进行POC（概念验证），让最终用户参与决策过程。当工具的使用逻辑与团队的协作节奏形成共振时，效率的"起飞"便不再是营销话术，而是可感知的生产力解放。

在数字化转型深水区的2026年，项目管理工具的选型能力本身，已成为组织核心竞争力的重要组成部分。愿这篇分析能为您的决策提供有价值的思考锚点。

当 ChatGPT、AI 设计工具、智能数据分析系统等技术工具逐渐普及，创业领域正迎来一场前所未有的效率革命。「一台电脑 + AI 工具 = 一家公司」 的口号在创投圈流传，北京中关村 AI 北纬社区等创业孵化地也涌现出不少单人创业案例。一时间，「一人公司（OPC，One-Person Company）」似乎成为打破传统创业高门槛的新范式，让无数怀揣创业梦想的人看到了低成本启动项目的可能。

而近期爆火的 Clawdbot（现已更名为 Moltrbot），更被视作 2026 年革新生产力的开源个人助理。这款 AI 智能体以「长了手的顶尖 LLM」爆红硅谷，发布仅 3 日，GitHub stars 即狂飙至 57.5k。它打破传统 AI「只说不做」的局限，可通过多渠道实时响应指令，在本地设备上完成安装软件、整理文件、生成内容等实操任务。作为 7×24 小时待命的「全栈式数字分身」，它将团队级流程压缩为单人可承接的轻量化操作，精准契合「一人公司」降本提速需求，为「一台电脑+AI = 一家公司」提供了扎实技术支撑。

更值得关注的是，这一创业新形态已获得政策层面的积极回应。早在 2016 年，《国务院关于促进创业投资持续健康发展的若干意见》就明确提出，鼓励具有资本实力和管理经验的个人通过依法设立一人公司从事创业投资活动。进入 2025 年末至 2026 年初，上海、江苏、深圳等多地更是密集出台政策，探索 「单人 + AI」 创业模式：深圳发布专项行动计划，从办公空间、人才补贴、创业资助到算力支持，提供全周期政策保障。政策红利的持续释放，为 「一人公司」 的发展注入了强劲动力。

国务院关于促进创业投资持续健康发展的若干意见

但看似前景大好的热潮之下，理性的审视也必不可少。在 AI Agent 技术尚未成熟的当下，「一人公司」 真的能取代团队协作，成为未来创业的主流趋势吗？

笔者认为答案是否定的。AI 确实降低了创业的执行门槛，政策也为其提供了成长土壤，却无法消解商业本质中的核心挑战；单人创业模式虽有其独特价值，却难以承载规模化、系统化的商业需求。

AI + 政策双重赋能：单人创业的 「低门槛革命」

过去，创业往往意味着 「组队、融资、囤资源」 的复杂流程。组建核心团队需要耗费大量时间筛选磨合，筹备启动资金可能面临借贷压力或股权稀释，对接供应链、渠道等资源更是难上加难。高门槛之下，许多优质创意被埋没，不少创业者在起步阶段就遭遇挫折。

而 AI 技术的爆发与政策的精准扶持，共同打破了这种困境，让「单人启动项目」从理想变为现实。

从技术赋能来看，AI 工具的全面覆盖让个体能够承接过去小团队的工作，内容生产端，AI 文案、设计、剪辑工具可批量产出宣传素材，无需专业技能即可完成品牌推广；业务执行端，智能客服 7x24 小时响应咨询，数据分析工具快速处理市场数据，替代了部分专员职能；产品开发端，AI 代码助手、原型工具降低了技术门槛，使得非技术背景创业者也能推进项目落地。

政策层面的支持则进一步降低了单人创业的成本与风险。以中国深圳为例，其推出的 OPC 创业生态行动计划明确，入驻 OPC 社区的创业者可享受低成本办公空间、最高 10 万元入户补贴、租金 60% 的过渡性住房，以及最高 60 万元个人创业担保贷款、1,000 万元 「训力券」 等多重支持；江苏在 「人工智能＋」 行动方案中明确支持人工智能 「一人公司」 创新创业；上海浦东新区则聚焦特定赛道，开展针对性职业技能培训，助力一人公司模式落地。

这些政策精准对接了单人创业的核心需求，从资金、空间、技术到人才培养全方位赋能，让 「低成本、低风险」 创业成为可能。

深圳市工信局《深圳市打造人工智能OPC创业生态引领地行动计划（2026—2027年）》

更重要的是，「一人公司」 填补了打工与大规模创业之间的空白，成为政策鼓励的 「中间创业层级」，个体无需融资、无需管理团队，就能实现 「小而美」 的商业闭环。

根据 Carta 2025 年的最新数据，已有超过三分之一的新公司由单人创始人创办。并且从 2019 年的 23.7% 到 2025 年上半年的 36.3% ，独立创始人创立公司的比例在六年间增长了 53% 。

2019-2025 年一人公司的占比趋势 ，图片来源：solofounders.com

一人公司的概念似乎正在重塑着创业的定义。

现实桎梏：「一人公司」 难成主流的三大核心瓶颈

尽管 「单人 + AI + 政策」 创业模式亮点纷呈，但这并不意味着它能完全取代团队协作，成为未来创业的主流形态。深入其商业本质不难发现，当前 AI 技术的能力边界、个体精力的局限性以及商业规模化的内在需求，依旧是「一人公司」模式下难以逾越的三座大山，即便是政策扶持也无法从根本上消解。

首先，AI 的能力边界决定了其无法替代团队协作的核心价值。当前的 AI 工具本质上是 「高效执行者」，而非 「战略决策者」，更难以替代人际协作中的深度互动与创造性输出——可生成逻辑文案却缺品牌调性与情感共鸣，能提供数据建议却难碰撞颠覆性创意，可处理标准化咨询却无法精准应对复杂场景的个性化需求与共情沟通。

其次，个体精力的局限性与业务扩张的矛盾，让 「一人公司」 难以形成可持续的商业模式。冷启动阶段，AI 分担重复劳动、政策补贴缓解成本，个体尚能兼顾多环节；但业务增长后，订单激增、需求多样、流程复杂，个体精力上限凸显，一人需兼顾对接、修改、售后等事务。根据 Winsavvy 创业数据显示：有 2–3 人团队的创业成功概率比单人高约 163%，并且更容易获得资本与规模支持。

Winsavvy 统计影响创业公司成败的因素，来源：winsavvy

这种困境本质是个体难破 「多线程工作」 瓶颈：人类注意力有限，频繁切换职能会降低效率，使创业者被琐事占据，无力聚焦产品迭代、市场拓展等核心问题。且业务扩张后，供应链管理、财务合规等专业环节需求凸显，其专业性强、容错率低，仅靠个体与 AI 难以应对，核心专业缺口仍需团队协作填补。

最后，从商业本质来看，主流创业趋势需要具备规模复制性，而 「一人公司」 的模式天然缺乏这种属性。传统企业的演进逻辑，始终是朝着分工细化、系统化运营的方向发展 —— 从单一产品到多元业务矩阵，从几人团队到多层级组织架构，正是这种规模化、系统化的能力，让企业能够抵御市场风险，实现长期发展。

而 「单人 + AI」 模式受限于个体精力与能力边界，很难实现大规模复制。即使是成功的单人创业案例，大多也局限于小众细分赛道，服务特定人群，难以覆盖更广泛的市场需求。在 2024 年的创业统计中，只有约 17% 的风险投资投给单人创业公司，团队结构仍显著更受 VC 认可。「一人公司」 作为孤立的商业节点，很难融入复杂的商业生态，更难以形成可持续的价值创造闭环。从现有政策文本与导向来看，政策扶持更倾向于培育创业生态，而非让 「一人公司」 停留在小规模生存状态，这也从侧面说明，规模化发展仍需依托团队模式。

写在最后：「AI + 小团队」政策加持下的创业 「最优解」

尽管「一人公司」难成主流，但 AI 技术与政策支持正催生更高效的「AI+小团队」新模式——既吸纳 AI 效率优势与政策红利，又保留团队协作核心价值，成为平衡创业门槛与发展潜力的最优解，渐成未来创业主流。

其核心逻辑是「人机协同、人尽其才」：AI 承接重复劳动与数据处理，3-5 人精悍团队聚焦核心环节，效率堪比传统 20 人团队，且能享受各地算力补贴、场景开放等政策支持。一篇题为「Intuition to Evidence: Measuring AI’s True Impact on Developer Productivity」的研究论文揭示：AI 平台显著提高生产力，包括将拉取请求（PR）审查周期时间整体缩短了31.8%。使用率最高的开发人员将推送到生产环境的代码量增加了 61%，代码交付量整体增加了28%。

PR 审核时间分析示意图

这一模式重构了创业「最小可行单元」：无需完整团队覆盖全职能，AI 替代非核心工作，小团队聚焦核心岗位，降低成本且决策灵活。但它并非简单减员，而是要求成员「一专多能」、高效协同，创业门槛从「资金资源」转向「核心能力与协同效率」。

未来，AI Agent 技术成熟与政策深化将进一步拓展人机协同边界，AI 可承接更复杂工作，专项补贴、人才支持等政策也将助力小团队成长。但团队协作的创意碰撞、风险共担、资源整合等核心价值，仍是 AI 无法替代的规模化发展支撑。

AI 技术正在重构创业生态，政策支持正在培育创业土壤，但它们从未改变商业的本质。无论是 「一人公司」 的补充价值，还是 「AI + 小团队」 的主流趋势，创业的核心始终是为市场创造价值。在技术红利、政策支持与市场竞争并存的时代，唯有把握人机协同的核心逻辑，平衡效率与创新、灵活与规模的关系，才能在创业赛道上站稳脚跟，实现从 0 到 1 的突破与成长。

参考资料：\
1.https://www.gov.cn/zhengce/content/2016-09/20/content%5F51099...\
2.https://www.sz.gov.cn/cn/xxgk/zfxxgj/tzgg/content/post_126026...\
3.https://medium.com/@gemQueenx/clawdbot-ai-the-revolutionary-o...\
4.https://arxiv.org/abs/2509.19708

看了 https://modelscope.cn/models/Qwen/Qwen3-ASR-0.6B 这个教程, 运行下面的命令报错了

qwen-asr-demo \
  --asr-checkpoint Qwen/Qwen3-ASR-1.7B \
  --aligner-checkpoint Qwen/Qwen3-ForcedAligner-0.6B \
  --backend vllm \
  --cuda-visible-devices 0 \
  --backend-kwargs '{"gpu_memory_utilization":0.7,"max_inference_batch_size":8,"max_new_tokens":2048}' \
  --aligner-kwargs '{"device_map":"cuda:0","dtype":"bfloat16"}' \
  --ip 0.0.0.0 --port 8000

报错如下：

    config_dict, kwargs = cls._get_config_dict(pretrained_model_name_or_path, **kwargs)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pon/.local/share/virtualenvs/modelscope_example-DACykz4b/lib/python3.11/site-packages/transformers/configuration_utils.py", line 721, in _get_config_dict
    resolved_config_file = cached_file(
                           ^^^^^^^^^^^^
  File "/home/pon/.local/share/virtualenvs/modelscope_example-DACykz4b/lib/python3.11/site-packages/transformers/utils/hub.py", line 322, in cached_file
    file = cached_files(path_or_repo_id=path_or_repo_id, filenames=[filename], **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pon/.local/share/virtualenvs/modelscope_example-DACykz4b/lib/python3.11/site-packages/transformers/utils/hub.py", line 553, in cached_files
    raise OSError(
OSError: We couldn't connect to 'https://huggingface.co' to load the files, and couldn't find them in the cached files.
Check your internet connection or see how to run the library in offline mode at 'https://huggingface.co/docs/transformers/installation#offline-mode'.

所以怎么办？

关键词：Clawdbot 更名 Moltbot；

Giants

马斯克停产 Model S/X 冲刺机器人量产；腾讯元宝派正式杀入 AI 社交赛道

Meta 裁员千人，战略重心从 VR 转向 AI 与智能眼镜

Meta 上周裁减了 Reality Labs 部门 10%的员工，涉及岗位接近 1000 个，其中大量集中在 VR 相关项目，包括 Quest VR 头显以及虚拟社交平台 Horizon Worlds。自 2020 年底以来，Meta 旗下的 Reality Labs 部门累计亏损已超过 700 亿美元。Meta 公司发言人表示，公司正在重新分配 Reality Labs 的资源，将更多投入放在 AI 和可穿戴设备上，例如与依视路陆逊梯卡联合推出的 Ray-Ban 智能眼镜产品线。这一调整标志着 Meta 战略重心从元宇宙向 AI 的转移，VR 行业可能正在进入一段"寒冬期"。

马斯克冲刺机器人量产，停产 Model S/X 为擎天柱让路

在最新财报电话会议上，马斯克宣布特斯拉将在 2026 年第二季度停产豪华车型 Model S 和 Model X，目的是给特斯拉机器人擎天柱（Optimus）让出生产线。马斯克透露，在把特斯拉加州弗里蒙特工厂的 Model S/X 生产线改造成擎天柱生产线后，其机器人的产量将达到每年一百万台。特斯拉 2026 年资本支出将"规模空前"，超过 200 亿美元，是 2025 年 85 亿美元的 2 倍多。此外，特斯拉已在 2026 年 1 月 16 日签署协议，将在 xAI 最新一轮融资中向其投资 20 亿美元。

蚂蚁具身智能明牌：做大脑，与宇树错位竞争

蚂蚁集团正式公布其具身智能战略：不做机器人本体，而是专注于打造"大脑"系统。蚂蚁灵波团队负责人表示，公司选择与宇树科技等机器人硬件厂商错位竞争，专注于开发能够控制多种机器人平台的智能系统。这一战略定位意味着蚂蚁将避开硬件制造的激烈竞争，转而提供跨平台的 AI 解决方案，为不同机器人厂商提供统一的智能控制层。

腾讯元宝派正式杀入 AI 社交赛道

2026 年，腾讯正式推出基于 AI 的社交产品"元宝派"，标志着这家社交巨头正式进入 AI 社交领域。元宝派结合了腾讯在社交网络和 AI 技术方面的双重优势，旨在通过 AI 增强用户的社交体验。该产品能够智能匹配用户兴趣、生成个性化内容，并提供 AI 辅助的社交互动功能，代表了社交网络向智能化方向发展的新趋势。

Models & Applications

DeepSeek-OCR 2 开源；Clawdbot 爆火更名 Moltbot；Kimi K2.5 开源炸场

DeepSeek-OCR 2 开源，实现视觉编码范式**转变

DeepSeek 发布 DeepSeek-OCR 2，通过引入 DeepEncoder V2 架构，实现了视觉编码从"固定扫描"向"语义推理"的范式转变。该模型将原本基于 CLIP 的编码器替换为轻量级语言模型（Qwen2-500M），并引入了具有因果注意力机制的"因果流查询"。这种设计打破了传统模型必须按从左到右、从上到下的栅格顺序处理图像的限制，赋予了编码器根据图像语义动态重排视觉 Token 的能力。在 OmniDocBench v1.5 评测中，其综合得分达到 91.09%，较前代提升了 3.73%。模型仅需 256 到 1120 个视觉 Token 即可覆盖复杂的文档页面，显著降低了下游 LLM 的计算开销。

*Clawdbot 爆火后被强制更名 Moltbot，*Mac mini 销量激增

开源 AI 助手 Clawdbot（现更名为 Moltbot）近期爆火，带火了 Mac mini 销量，有用户甚至一次性购买 40 台 Mac mini 来运行该应用。Clawdbot 是一个可以在本地运行的开源 AI 助手，能够直接住进常用聊天软件如 WhatsApp、Telegram、iMessage、Slack、Discord 中，具备持久记忆、主动行为、可扩展技能以及自托管可控性。然而，由于名称与 Claude 相似，Anthropic 公司强制要求其更名。开发者 Peter Steinberger 最终将其更名为 Moltbot，取自龙虾的蜕壳行为。该应用 GitHub 上的 Star 量已经超过 72.2k，被称为"开源贾维斯"，能够完成整理邮件、管理日程、读 PPT、写代码、发推文等各种任务。

Kimi K2.5 正式发布并开源，推新 Agent 集群与编程工具

月之暗面正式发布并开源其新一代大模型 K2.5。该模型被宣称为迄今最智能和全能的开源模型，在 Agent、代码、图像及视频理解等多类基准测试中达到先进水平。K2.5 的核心突破在于首次引入“Agent 集群”能力，可自主创建多达 100 个“分身”组成团队，并行处理复杂任务，效率提升最高达 4.5 倍。同时，其强大的多模态能力显著降低了使用门槛，用户可通过拍照、截图或录屏与 AI 交互，甚至直接生成前端代码。同期，专为开发者打造的编程工具“Kimi Code”正式发布。

Qwen3 超大杯推理版正式上线，刷新全球 SOTA

阿里千问发布 Qwen3-Max-Thinking 正式版，在涵盖科学知识、数学推理、代码编程的 19 项权威基准测试中，赶上甚至超越 GPT-5.2-Thinking、Claude-Opus-4.5 和 Gemini 3 Pro 等 TOP 闭源模型。该模型总参数超万亿（1T），预训练数据量高达 36T Tokens，通过引入自适应工具调用和测试时扩展两项技术创新，显著提升了推理性能和调用工具的原生 Agent 能力。在启用工具的"人类最后的测试"HLE 中，Qwen3-Max-Thinking 得分 58.3，超过 GPT-5.2-Thinking 的 45.5，以及 Gemini 3 Pro 的 45.8，刷新 SOTA。千问 APP PC 端和网页端已上新这一 Qwen 系列最强模型，API 也已开放。

百川 M3 Plus 首创"证据锚定"，医疗 AI 幻觉率降至 2.6%

百川智能发布医疗大模型 Baichuan M3 Plus，首创"证据锚定"技术，将医疗 AI 的幻觉率降至 2.6%，刷新全球纪录。该技术通过将模型输出严格锚定在医学证据和权威指南上，确保生成的医疗建议具有可靠的科学依据。M3 Plus 在多个医疗专业评测中表现优异，特别是在诊断准确性和治疗建议的可靠性方面显著超越同类产品。这一突破为 AI 在严肃医疗场景中的应用扫清了关键障碍。

蚂蚁开源比肩 Genie 3 的世界模型 LingBot-VLA

蚂蚁灵波开源具身智能基座模型 LingBot-VLA，采用了 20000 小时真实机器人数据，是目前开源的最大规模真实机器人数据之一。该模型在权威评测中全面超越了此前公认最强 Physical Intelligence 的π0.5，以及英伟达 GR00T N1.6 等国际顶尖模型。LingBot-VLA 采用专家混合 Transformer 架构，包含大脑（视觉语言模型）和小脑（动作专家模块）协同工作的系统，通过共享的自注意力机制进行深度耦合。模型展示了强大的跨本体泛化能力，在 9 种机器人数据上预训练后，在 3 种未见过的机器人平台上依然表现优异。

3D 领域的 NanoBanana HYPER3D 发布，万物皆可用嘴操控

3D 领域的 NanoBanana HYPER3D 正式发布，这是一个能够通过自然语言指令操控 3D 场景的 AI 系统。用户可以通过语音或文本描述来创建、编辑和控制 3D 对象，实现"万物皆可用嘴操控"的交互体验。该系统结合了 3D 生成、物理模拟和自然语言理解技术，能够理解复杂的空间关系和物理约束，为 3D 内容创作和虚拟环境交互提供了革命性的工具。

全球AI政策与市场简讯

魔法原子冲击 IPO*，将登央视春晚展示具身智能*

江苏具身智能新贵魔法原子（Magic Atom）联合创始人披露，公司计划在今年冲击 IPO，并将登上央视春晚展示其最新具身智能技术。该公司专注于开发面向消费级市场的具身智能产品，已获得多轮融资。魔法原子的技术特点是能够实现低成本、高可靠性的机器人控制，目标是将具身智能技术带入普通家庭。

LeCun 创业公司**估值 35 亿美元，官宣世界模型核心方向

图灵奖得主 Yann LeCun 离开 Meta 后创立的 AMI Labs（Advanced Machine Intelligence）本周确认核心方向：开发世界模型（world models），以此构建能够理解现实世界的智能系统。公司估值达 35 亿美元，正在洽谈新一轮融资。LeCun 长期以来对现有大语言模型持怀疑态度，认为仅靠预测下一个 token 的生成式模型无法真正理解现实世界。他提出的世界模型应同时具备四项关键能力：理解真实世界、拥有持久记忆、能够进行推理与规划、可控且安全。AMI Labs 将专注于工业流程控制、自动化系统、可穿戴设备、机器人与医疗健康等高可靠性要求领域。

以上所有信息源自网络

THE END

关于 GMI Cloud

由 Google X 的 AI 专家与硅谷精英共同参与创立的 GMI Cloud 是一家领先的 AI Native Cloud 服务商，是全球七大 Reference Platform NVIDIA Cloud Partner 之一，拥有遍布全球的数据中心，为企业 AI 应用提供最新、最优的 GPU 云服务，为全球新创公司、研究机构和大型企业提供稳定安全、高效经济的 AI 云服务解决方案。

GMI Cloud 凭借高稳定性的技术架构、强大的GPU供应链以及令人瞩目的 GPU 产品阵容（如能够精准平衡 AI 成本与效率的 H200、具有卓越性能的 GB200、GB300 以及未来所有全新上线的高性能芯片），确保企业客户在高度数据安全与计算效能的基础上，高效低本地完成 AI 落地。此外，通过自研“Cluster Engine”、“Inference Engine”两大平台，完成从算力原子化供给到业务级智算服务的全栈跃迁，全力构建下一代智能算力基座。

作为推动通用人工智能（AGI）未来发展的重要力量，GMI Cloud 持续在 AI 基础设施领域引领创新。选择 GMI Cloud，您不仅是选择了先进的 GPU 云服务，更是选择了一个全方位的 AI 基础设施合作伙伴。

如果您想要了解有关 GMI Cloud 的信息

请关注我们并建立联系

在低代码开发中，表单数据回显是实现数据预填充的核心功能。它能让用户在使用表单时快速获取并展示相关数据。
在JVS低代码平台主要有以下4种设置方式：默认值公式，数据联动，回显设置以及默认修改详情表单回显。
注意表单数据回显的优先级：公式>联动>回显>默认

表单数据回显

公式回显
在表单设计中，设置组件默认值通过配置公式获取，如下图所示

数据联动
根据其它组件的数据值作为查询条件，在其它数据模型中进行搜索，关联查询出某个字段的值，显示在当前组件
如下图所示：
1、在表单中单行文本组件，配置关联模型

2、配置单价根据产品名称联动回显

回显设置
配置业务逻辑用于表单第一次打开时直接回显相关业务数据。，配置入口如下图所示

表单默认回显
列表页中默认行内按钮打开有修改和详情表单，这两个表单打开会默认回显列表页行数据。

在线demo：https://app.bctools.cn
基础框架开源地址：https://gitee.com/software-minister/jvs

本文将讲解 MindSpore 中两个高频核心知识点：

• Stop Gradient 梯度截断：屏蔽指定张量的梯度回传，消除无关张量对梯度计算的影响；
• has_aux 辅助数据参数：自动处理多输出函数的梯度计算，无需手动截断梯度；
• 这两个知识点是解决复杂场景梯度计算的核心。

问题引入：多输出函数的梯度计算陷阱

默认情况下，如果前向函数只返回 loss 一个值，mindspore.grad 只会计算「loss 对指定参数的梯度」，这也是我们训练模型的核心诉求。

但如果前向函数返回多个输出项（如 loss + logits 预测值），MindSpore 的微分函数会默认计算：所有输出项对指定参数的梯度之和，这会导致最终的梯度值失真，与我们需要的「仅 loss 求梯度」的结果不一致！

实战验证：多输出函数的梯度失真问题

# 定义返回 loss + z(预测值) 的多输出函数
def function_with_logits(x, y, w, b):
    z = ops.matmul(x, w) + b
    loss = ops.binary_cross_entropy_with_logits(z, y, ops.ones_like(z), ops.ones_like(z))
    return loss, z  # 输出项1：loss，输出项2：预测值z

# 生成微分函数，依旧对w(2)、b(3)求导
grad_fn = mindspore.grad(function_with_logits, (2, 3))
grads = grad_fn(x, y, w, b)
print("多输出函数的梯度值：\n", grads)

运行结果：

多输出函数的梯度值：
(Tensor(shape=[5, 3], dtype=Float32, value=
[[ 1.32618928e+00, 1.01589143e+00, 1.04216456e+00],
[ 1.32618928e+00, 1.01589143e+00, 1.04216456e+00],
[ 1.32618928e+00, 1.01589143e+00, 1.04216456e+00],
[ 1.32618928e+00, 1.01589143e+00, 1.04216456e+00],
[ 1.32618928e+00, 1.01589143e+00, 1.04216456e+00]]), Tensor(shape=[3], dtype=Float32, value= [ 1.32618928e+00, 1.01589143e+00, 1.04216456e+00]))

结果对比：

• 单输出函数（仅 loss）：w 的梯度值约为 0.326、0.0159、0.0422；
• 多输出函数（loss+z）：w 的梯度值约为 1.326、1.0159、1.0422；
• 梯度值完全不同，这就是「多输出项梯度叠加」导致的失真，这不是我们想要的结果！

解决方案一：Stop Gradient 手动梯度截断【核心 API】

Stop Gradient 核心作用

• MindSpore 提供 mindspore.ops.stop_gradient 接口，是梯度计算中的「截断利器」，核心功能有 3 个：
• 对指定 Tensor 进行梯度截断，消除该 Tensor 对梯度计算的所有影响；
• 屏蔽无关输出项的梯度回传，让微分函数只计算「目标项（loss）」的梯度；
• 阻止梯度从当前 Tensor 流向计算图的上游节点，不改变 Tensor 的数值，仅改变梯度传播属性。
• 核心特性：stop_gradient(z) 只会修改 z 的梯度传播标记，不会改变 z 的数值本身，我们依然可以正常获取和使用 z 的值，只是它不再参与梯度计算。

实战：使用 Stop Gradient 修正梯度计算

只需要对不需要参与梯度计算的输出项（本例中的 z）包裹stop_gradient，即可实现「仅 loss 求梯度」：

def function_stop_gradient(x, y, w, b):
    z = ops.matmul(x, w) + b
    loss = ops.binary_cross_entropy_with_logits(z, y, ops.ones_like(z), ops.ones_like(z))
    return loss, ops.stop_gradient(z)  # 对z进行梯度截断

# 生成微分函数并求梯度
grad_fn = mindspore.grad(function_stop_gradient, (2, 3))
grads = grad_fn(x, y, w, b)
print("梯度截断后的梯度值：\n", grads)

运行结果：

梯度截断后的梯度值：
(Tensor(shape=[5, 3], dtype=Float32, value=
[[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02]]), Tensor(shape=[3], dtype=Float32, value= [ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02]))

结果验证：此时的梯度值与「单输出函数仅返回 loss」的梯度值完全一致，问题完美解决！

解决方案二：has_aux=True 自动处理辅助数据【推荐最佳实践】

辅助数据（Auxiliary data）定义

• 在 MindSpore 的自动微分体系中，辅助数据 特指：前向函数中「除第一个输出项外的其他所有输出项」。
• 行业通用约定：前向函数的第一个返回值必须是损失值 loss，其余返回值均为辅助数据（如预测值、中间特征、准确率等）。
• 我们训练模型的核心诉求永远是「求 loss 对参数的梯度」，辅助数据只是为了监控训练过程，不需要参与梯度计算。

has_aux 参数的核心能力

• mindspore.grad 和 mindspore.value_and_grad 都提供了 has_aux 布尔型参数，当设置 has_aux=True 时：
• 自动将函数的「第一个输出项」作为梯度计算的唯一目标（仅求 loss 的梯度）；
• 自动对「所有辅助数据」执行梯度截断（等价于手动加stop_gradient）；
• 微分函数的返回值会拆分为「梯度结果 + 辅助数据元组」，无需手动处理；
• 语法更简洁，无需修改原函数的返回逻辑，是处理多输出函数的最优解。

实战：has_aux=True 优雅实现梯度计算 + 辅助数据返回

# 复用未做任何修改的多输出函数 function_with_logits
def function_with_logits(x, y, w, b):
    z = ops.matmul(x, w) + b
    loss = ops.binary_cross_entropy_with_logits(z, y, ops.ones_like(z), ops.ones_like(z))
    return loss, z

# 仅需添加 has_aux=True，无需手动截断梯度
grad_fn = mindspore.grad(function_with_logits, (2, 3), has_aux=True)
grads, (z,) = grad_fn(x, y, w, b) # 解构：梯度 + 辅助数据
print("梯度值（与单输出一致）：\n", grads)
print("辅助数据z（预测值）：\n", z)

运行结果：

梯度值（与单输出一致）：
(Tensor(shape=[5, 3], dtype=Float32, value=
[[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02],
[ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02]]), Tensor(shape=[3], dtype=Float32, value= [ 3.26189250e-01, 1.58914644e-02, 4.21645455e-02]))
辅助数据z（预测值）：
[ 3.8211915 -2.994512 -1.932323 ]

两大方案对比与选型建议

• Stop Gradient：适合「精细化梯度控制」，比如只对函数中某一个中间张量截断梯度，而非所有辅助数据；灵活性高，适合复杂场景；
• has_aux=True：适合「标准多输出场景」，只要满足「第一个返回值是 loss」的约定，无脑使用即可；简洁高效，推荐优先使用；

核心总结

• 多输出函数的默认梯度计算是「所有输出项梯度之和」，会导致梯度失真，必须做梯度截断处理；
• stop_gradient 是梯度截断的基础 API，核心是「消除指定 Tensor 的梯度影响，不改变数值」；
• has_aux=True 是辅助数据的最优解，自动截断辅助数据梯度，推荐在标准场景中使用；
• 梯度截断的核心目的：让模型的梯度计算始终围绕「损失函数」展开，保证参数更新的正确性。

小T导读：在福州水务统一物联网接入平台项目中，基于 TDengine TSDB，我们实现了水厂、管网等多源水务数据的统一存储与管理，并同时满足了水表平台、产销差系统等多业务系统对数据的高效检索与共享需求。TDengine TSDB “一个采集点一张表” 的建模方式完美契合物联网平台对设备级数据的统一管理需求，其卓越的读写性能与数据压缩能力，有效应对了百万设备数据管理的技术挑战。此外，其还支持标准 SQL，简化了应用开发；具备多副本高可用机制，保障业务连续性；并提供多数据源的零代码写入与数据同步功能，为平台业务拓展与平台间数据同步提供了技术基础。本文将结合项目的具体实践，与大家分享 TDengine TSDB 在福州水务统一物联网接入平台中的应用经验与成效。

项目背景

水务数据是一种重要的公共数据，规模大、社会关注度高，而且来源多，种类繁杂，不易收集和管理。实现“智慧水务”理念的前提是统一管理分布在各个水厂、各个供/排水环节的众多设备数据，只有将数据接入到统一的物联网平台后，才能在此基础上开发水务生产环节的各个功能，从而建立信息互通平台，实现水务统一平台、统一管理、统一数据、统一服务，避免重复建设，打破数据壁垒，保障数据资源的高效使用和安全可靠。

为此，我们结合福州水务发展战略与实际业务的需求，建设了福州水务统一物联网接入平台，为供排水业务提供统一数据接入与设备管理能力。

存在问题

统一物联网接入平台面临如下技术难题：

标准不统一，设备管理割裂，建模难度大

在统一物联网平台建设前，设备管理主要依赖各厂家自建平台，管理割裂、数据分散。

统一物联网平台要完成供水、排水、重点工程项目等相关设备数据的统一存储，具体包括：

• 供水水厂、增压站数据
• 供水/排水管网监控数据
• 二次供水泵房数据
• 水表数据
• 雨污泵站数据
• 污水厂数据

这些设备类型繁多、协议标准不统一，且缺乏统一的全生命周期管理机制。数据源分散在多个系统中，与平台“统一管理全部数据”的目标形成天然矛盾。如何通过合理的数据建模，在单一框架下兼容多种设备类型，并同时满足后续灵活的检索与分析需求，成为项目面临的主要挑战。

超百万设备数据持续写入，带来性能挑战

福州有多个水厂，设备数量达到百万级，统一管理这些设备就意味着要承载所有设备不间断的数据写入压力，而且新设备随时可能接入，平台很难提前对所有设备建表，这对平台的写入能力以及建模灵活性提出了很高的要求。

海量数据长期存储带来的存储成本压力

平台需要接入上百万设备的数据并实现长期存储，这些数据量级很大，价值密度却很低，既需要尽可能降低存储成本，还要在进行长期统计计算时保障数据查询时效性，平台要设法兼顾这两方面的需求。

系统大数据量查询，面临性能瓶颈

平台需要为水表平台、产销差系统、综合调度系统、智慧水厂等系统提供实时数据查询、历史数据查询、页面展示、统计报表等业务支持，大量业务应用的并发访问，对底层数据系统的承载能力而言是很大的挑战。二供（二次供水）平台之前使用的 InfluxDB 就曾因查询压力过大导致延迟过高，影响了业务应用。

解决方案

为解决上述问题，统一物联网接入平台不仅需要良好的顶层设计，还需要功能性能强大且稳定可靠的专业数据库提供底层数据能力支撑。水务设备数据是典型的时序数据，因此我们的数据库选型目标定为时序数据库。

经过对大量时序库的调研，综合考虑成本、功能、性能、稳定性等各个方面，我们最终选择了 TDengine TSDB 作为统一物联网接入平台的时序数据管理引擎。

TDengine TSDB 是一款专为物联网、工业互联网等场景设计与优化的大数据平台，其诸多特性恰好能够解决我们在统一物联网平台建设中遇到的痛点问题：

1. 其特有的 “一个采集点一张表” 建模理念，简直是为解决多系统数据统一建模问题量身定制
2. 其高写入性能以及无模式写入功能，使得百万设备数据写入带来的技术问题迎刃而解
3. 其针对时序数据的高效压缩能力解决了百万级设备数据长期存储的成本难题
4. 其高效查询性能解决了对统一物联网平台而言极为关键的查询性能问题

多系统数据统一管理 —— 一个采集点一张表

我们首先参考福州地标、企标，建立了统一的数据接入协议标准，包含供水领域水厂、管网、水表、二供泵房、加压泵站、排水泵站、排水管网检测设备、水质监测设备等设备设施类型。如下图所示，红框标注的是一部分已标准化的协议。

标准化协议解决了统一接入的问题，下一步就是统一建模。

虽然平台接入的设备种类繁杂型号多样，但只要是设备数据，其数据结构就存在共性：每个设备都有采集的物理量以及设备自身的描述信息（标签）。物理量会随着时间不断变化，而标签数据则是静态的不会随时间变化。

TDengine TSDB “一个采集点一张表” 的数据建模方法正是针对设备数据的特点而设计：每个设备对应一张表，设备采集的物理量对应表的数据列，设备自身信息例如设备编号则对应标签（TAG）列。把静态的标签数据与动态的采集数据分开，任何设备都可套用这个建模方法，极大降低了我们的数据建模难度。

采用上述方法，数据库中要创建上百万张表来对应上百万的设备，当需要对同类型设备进行聚合查询时显然会十分不便。TDengine TSDB 的 “超级表-子表” 设计解决了这个问题：对于同一类设备，提取其数据结构创建一张 “超级表” ，具体的设备数据则记录在该超级表名下的对应“子表”中，当需要对某类设备进行聚合查询时，直接查询其对应的超级表即可，避免了多表之间的重复查询和拼接等操作，十分高效便捷。超级表-子表的关系如下图所示。

在福州水务统一物联网接入平台项目中，我们共计创建了 1 个业务 DB 名为 fziot，一百余张超级表，超过 190 万张子表。统一物联网平台接入的设备数量目前还在一直增长，设备总数已经超过 100 万，增长变化量如下图所示：

百万级设备数据写入 —— 高性能与无模式写入功能

高性能

TDengine TSDB 的核心竞争力在于其卓越的写入和查询性能。相较于传统的通用型数据库，TDengine TSDB 充分利用了时序数据的时间有序性、连续性和高并发特点，自主研发了一套专为时序数据定制的写入及存储算法，“一个数据采集点一张表” 的设计不仅有利于设备建模与管理，还能大幅提升写入性能。

• 自研的行列格式数据结构，能够更充分利用时序数据的特点，实现高性能与低空间占用；
• 单表的数据按块连续存储，数据块内采取列式存储，保证单个数据采集点的插入和查询效率最优；
• 由于不同数据采集点产生数据的过程完全独立，每个数据采集点的数据源唯一，一张表只有一个写入者，可采用无锁方式写入，从而性能大幅提升；
• 对于一个数据采集点而言，其产生数据是按照时间排序的，写操作可用追加方式实现，进一步大幅提高数据写入速度。

极高的数据写入性能使得 TDengine TSDB 能够轻松承接统一物联网平台的数据写入压力，自投入使用以来，从未因写入性能不足出现阻塞与延迟。

无模式写入

物联网平台的数据来自多个系统，设备的数量一直在动态变化，因此无法提前为所有设备创建好对应的表，这就要求数据库能够在数据写入时自动判断并建表。

TDengine TSDB 提供无模式（schemaless）写入方式，无需预先创建超级表或子表，TDengine TSDB 会根据实际写入的数据自动创建相应的存储结构。此外，在必要时，无模式写入方式还能自动添加必要的数据列或标签列，确保写入的数据能够被正确存储。

无模式写入示例如下，TAG 列、数据列、主键时间戳之间用空格分开：

properties_testabc1,deviceId=testdevice1   createTime=1746669509685i,temperature=38.5 1746669509684000000

该写入语句，可向名为 properties\_testabc1 的超级表写入数据，TAG 列 deviceId，赋值为 testdevice1，两个数据列分别为 createTime、temperature，赋值为 1746669509685i、38.5 ，最后一个数字是这一条记录的时间戳。如果该子表已经存在（TAG 列内容完全一致），则自动写入已存在子表中，若不存在，则自动创建新子表并写入。

海量数据长期存储 —— 专业压缩算法

TDengine TSDB 是专门为时序数据管理打造的大数据平台，对数据压缩进行了特殊设计：

• 在存储架构上采用了列式存储技术，与传统的行式存储不同，列式存储与时序数据的特性相结合，尤其适合处理平稳变化的时序数据；
• 为了进一步提高存储和数据压缩效率，TDengine TSDB 采用了差值编码技术，通过计算相邻数据点之间的差异来存储数据，而不是直接存储原始值，从而大幅度减少存储所需的信息量；
• 在差值编码之后，TDengine TSDB 还会使用通用的压缩技术对数据进行二次压缩，以实现更高的压缩率。

针对性的存储技术以及两级数据压缩，使得 TDengine TSDB 对时序数据的压缩效率显著高于其它产品

统一物联网平台从 2023 年 8 月正式投入使用，至今还在不断增加接入的设备数量，目前已经接入了超过 100 万各型设备，TDengine TSDB 三节点三副本集群，目前共计使用磁盘空间 8.1 TB （截至 2025 年 5 月），相比市场上同类产品，数据压缩率优势明显。

多系统数据大数据量查询 —— 高性能查询

为实现海量数据规模下的高性能查询，TDengine TSDB 从多个维度进行了精心的设计：

1. 采用分片策略，充分利用了硬件资源。TDengine TSDB 按照分布式高可靠架构进行设计，通过节点虚拟化并辅以负载均衡技术，将一个 dnode 根据其计算和存储资源切分为多个 vnode，对于单个数据采集点，无论其数据量有多大，一个 vnode 都拥有足够的计算资源和存储资源来应对，能最高效率地利用异构集群中的计算和存储资源降低硬件投资。
2. 采用分区策略，按时间条件检索时避免了遍历过程。除了通过 vnode 进行数据分片以外，TDengine TSDB 还采用按时间段对时序数据进行分区的策略。每个数据文件仅包含一个特定时间段的时序数据，避免了遍历，简化了数据管理，还便于高效实施数据的保留策略。
3. 标签数据与时序数据完全分离存储，显著降低标签数据存储的冗余度，实现了极为高效的多表之间的聚合查询。在常见的 NoSQL 数据库或时序数据库中，一般采用 Key-Value 存储模型，导致每条记录都携带大量重复的标签信息，如果需要在历史数据上增加、修改或删除标签，就必须遍历整个数据集并重新写入，TDengine TSDB 通过将标签数据与时序数据分离存储，有效避免了这些问题，大大减少了存储空间的浪费，并降低了标签数据操作的成本；在进行多表之间的聚合查询时，TDengine TSDB 首先根据标签过滤条件找出符合条件的表，然后查找这些表对应的数据块。显著减少了需要扫描的数据集大小，从而大幅提高了查询效率。
4. 采用了 LSM 存储结构，进一步优化读写性能。时序数据在 vnode 中是通过 TSDB 引擎进行存储的。鉴于时序数据的海量特性及其持续的写入流量，若使用传统的 B+Tree 结构来存储，随着数据量的增长，树的高度会迅速增加，这将导致查询和写入性能的急剧下降，最终可能使引擎变得不可用。鉴于此，TDengine TSDB 选择了 LSM 存储结构来处理时序数据。LSM 通过日志结构的存储方式，优化了数据的写入性能，并通过后台合并操作来减少存储空间的占用和提高查询效率，从而确保了时序数据的存储和访问性能。
5. 时序数据文件内部进行了针对性优化。data 文件是实际存储时序数据的文件，在 data 文件中，时序数据以数据块的形式进行存储，每个数据块包含了一定量数据的列式存储。根据数据类型和压缩配置，数据块采用了不同的压缩算法进行压缩，以减少存储空间的占用并提高数据传输的效率。每个数据块在 data 文件中独立存储，代表了一张表在特定时间范围内的数据。这种设计方式使得数据的管理和查询更加灵活和高效。通过将数据按块存储，并结合列式存储和压缩技术，TSDB 引擎可以更有效地处理和访问时序数据，从而满足大数据量和高速查询的需求。

统一物联网平台，不仅把多系统的数据集中统一管理，也同时承接了多系统的数据应用业务，过去分散在各个系统的业务访问压力现在都集中到了一起。

使用 TDengine TSDB 带来的性能提升十分明显，例如二次供水泵房数据数据过去存储在二供平台，大数据中心向二供平台抽取生产数据用于分析应用，当时二供平台采用的底层时序库是 InfluxDB，大数据中心每小时抽取一次二供数据，结果由于压力过大，导致 InfluxDB 延迟现象严重，影响到了正常业务运行。

数据抽取 SQL 如下：

 "sql":"select \"time\",\"cid\",\"devid\",\"tag\",\"value\" from (select mean(value) as value  from \"raw\" where time >= #influx_start_time# and time < #influx_end_time# group by *,time(1m))"

在统一物联网平台建设完成后，统一使用 TDengine TSDB 支持各个系统的数据查询业务，同样的业务，在使用 TDengine TSDB 后只需 1 分多钟即可抽取完毕，且能够持续稳定运行。

使用 TDengine TSDB 后的抽取 SQL：

SQL
select last(_ts,`createTime`,`numberValue`,`value`),`deviceId`,`property` from fziot2.properties_egbf_new where _ts >= #ts_start# and _ts < #ts_end# and `createTime` >= to_unixtimestamp(#createtime_start#) and `createTime` < to_unixtimestamp(#createtime_end#) partition by `deviceId`,property  interval(1h)

定时抽取业务运行情况如下，可见稳定且高效：

TDengine 带来的其它优势

依托强大的功能与性能优势，TDengine TSDB 成功应对了上述技术难题。作为一款分布式大数据引擎，其还具备很多传统数据库软件不具备的特殊功能，给我们带来了意料之外的优势。

支持 SQL 语句，应用开发十分便利

与实时库需要开发者专门学习数据库特有 API 不同，TDengine TSDB 支持标准 SQL ，开发人员不需要太多学习成本就能上手使用，TDengine TSDB 还针对时序数据特点提供了许多特色查询 SQL ，对我们开发新功能、新应用提供了很大的便利。

支持高可用，保障了业务稳定性

对于水务系统的数据平台而言，业务的持续性十分重要。TDengine TSDB 作为分布式时序数据库，支持高可用特性，基于 RAFT 协议的标准三副本方案，能够保障集群中有 1 个节点损坏时，业务不受影响，这对我们而言十分有必要。

支持多种数据源零代码接入

TDengine TSDB 支持以零代码方式将来自不同数据源的数据无缝导入，而且无需额外部署 ETL 工具，即可对数据进行自动提取、过滤和转换。不同 TDengine TSDB 集群之间也可以很方便地通过 taosX 进行数据同步。这为我们将来进行多数据平台数据统一管理，以及平台间数据同步等工作提供了技术基础，使得数据平台的可拓展性大大提高。

展望

统一物联网接入平台实现了数据的统一采集汇聚分发、设备生命周期管理、实时预警信息推送等功能，加快公司信息化建设速度，减少重复数据建设造成的成本浪费，提升工作效率。

福州水务统一物联网接入平台目前接入的设备数量已经超过 100 万且还在增长，TDengine TSDB 作为底层支持系统表现优异。未来我们将和 TDengine 一起，为水务领域的企业数字化建设做出更多的贡献。

关于城建数智科技

福州市城建数智科技有限公司于 2022 年 7 月成立，是福州城建设计研究院有限公司的全资子公司，重点服务于水务企业，提供咨询规划、软件开发、运维保障等技术服务工作，公司以水务 GIS 平台、大数据平台、物联网平台、水务智慧大脑为核心。提供供水和排水一体化解决方案，并逐步扩展供排水硬件设备的供应业务，发展自动化控制，提供设备安装、检修、校验等服务，更好地对外输出水务领域的数字化解决方案以及相关的软、硬件产品。

作者信息

本文作者：陈欣

Microsoft Word 的“修订”功能可以记录文档中的修改、校对、更正，以及他人添加的建议和批注。当你收到一份开启了修订模式的 Word 文档时，可以根据需要选择拒绝这些修改以保留原始内容，或者直接接受所有修改。本文将演示如何使用 Spire.Doc for .NET，通过代码的方式批量接受或拒绝 Word 文档中的所有修订内容。

安装 Spire.Doc for .NET

首先，需要将 Spire.Doc for .NET 包中的 DLL 文件添加为 .NET 项目的引用。你可以通过官网下载对应的 DLL 文件，手动添加到项目中；也可以使用 NuGet 方式进行安装，更加方便快捷。

PM> Install-Package Spire.Doc

在 Word 文档中接受所有修订

具体操作步骤如下：

1. 创建一个 Document 对象。
2. 使用 Document.LoadFromFile() 方法加载示例 Word 文档。
3. 调用 Document.AcceptChanges() 方法，接受文档中的所有修订内容。
4. 使用 Document.SaveToFile() 方法将处理后的文档保存为新的文件。

具体示例代码如下：

using Spire.Doc;

namespace AcceptTrackedChanges
{
    class Program
    {
        static void Main(string[] args)
        {
            // 创建 Document 对象
            Document doc = new Document();

            // 加载示例 Word 文档
            doc.LoadFromFile("test.docx");

            // 接受文档中的所有修订
            doc.AcceptChanges();

            // 保存结果文档
            doc.SaveToFile("AcceptTrackedChanges.docx", FileFormat.Docx);
        }
    }
}

在 Word 文档中拒绝所有修订

具体操作步骤如下：

1. 创建一个 Document 对象。
2. 使用 Document.LoadFromFile() 方法加载示例 Word 文档。
3. 调用 Document.RejectChanges() 方法，拒绝文档中的所有修订内容。
4. 使用 Document.SaveToFile() 方法将处理后的文档保存为新的文件。

具体示例代码如下：

using Spire.Doc;

namespace RejectTrackedChanges
{
    class Program
    {
        static void Main(string[] args)
        {
            // 创建 Document 对象
            Document doc = new Document();

            // 加载示例 Word 文档
            doc.LoadFromFile("test.docx");

            // 拒绝文档中的所有修订
            doc.RejectChanges();

            // 保存结果文档
            doc.SaveToFile("RejectAllChanges.docx", FileFormat.Docx);
        }
    }
}

申请临时许可证

如果你希望移除生成文档中的评估提示，或解除功能上的限制，可以申请一份有效期为 30 天的临时许可证进行使用。