很多企业的指标越做越多，决策却越来越慢：会上报数热闹，真正的“下一步做什么”说不清。根因往往不是数据不够，而是缺少一套能对齐战略、解释因果、嵌入节奏的产品指标体系。本文用一套“5步法”把北极星、指标树、漏斗、治理与看板串成可执行路径，让指标从“汇报材料”变成“决策语言”。

关键词聚合：产品指标体系｜北极星指标（North Star Metric）｜指标树（Driver Tree/KPI Tree）｜AARRR 漏斗（Pirate Metrics）｜HEART 体验指标｜OKR｜指标口径｜数据治理｜数据质量｜数据看板/仪表盘（Dashboard）

为什么你的指标越做越多，决策却越来越慢？

我在不同规模的组织里反复见到一个现象：指标体系做得很“全”，管理却做得很“虚”。 每个部门都能拿出一组“看起来不错”的数字，但一旦追问“这些数字如何改变用户价值、如何影响长期收入”，讨论就会迅速滑向口径争执、责任推诿，最后以“下次再看”收场。

更棘手的是，一些“可展示但不可驱动”的指标会天然占据汇报舞台：曝光、下载、浏览量、粉丝数……它们往往能让人产生“我们在变好”的错觉，却很难直接导向下一步行动。组织越依赖这类指标，越容易陷入“报数化”，决策反而越来越慢。

所以问题不在于缺指标，而在于缺一套能把“指标—行动—结果—复盘”真正连起来的产品指标体系。当指标只用来展示，它会越来越像装饰；当指标用来决策，它才会成为组织能力。

方法论：一套好的产品指标体系，至少解决三件事

关键定义：什么是“产品指标体系”？

产品指标体系不是一张报表，也不是 KPI 清单，而是：

一套围绕“用户价值与业务价值”建立的指标结构（指标分层+指标口径+数据治理+看板节奏），用于支持决策、资源配置与持续改进。

它至少要同时解决三个问题：方向是否一致、原因是否可解释、行动是否能闭环。

1）对齐：让“用户价值”和“业务价值”说同一种话

中高层最怕的不是指标不好看，而是组织努力方向不一致：产品追功能，运营追热度，销售追签约，最后用户体验与续费被牺牲。我通常建议用“北极星指标（North Star Metric）”做对齐：用一个最核心的指标把方向统一，避免资源在部门之间相互抵消。

2）可解释：从“指标清单”升级为“因果链条”

有数字不等于有洞察。你需要的不是几十个 KPI，而是一棵能解释“为什么上升/下降”的指标树（Driver Tree / KPI Tree）：把结果指标拆解为可影响的驱动因素，帮助团队定位杠杆、做资源配置。

3）可运营：把指标嵌入节奏，而不是只在月底出现

指标体系发挥作用，靠的是机制：看板怎么设计、例会怎么开、异常怎么处理、动作怎么验证。否则指标会退化成“月度PPT”。这里要特别警惕一个规律：当指标被当作硬目标与奖惩绑定时，人会“优化指标”而不是“优化系统”。

5步法：从“定方向”到“能落地”的产品指标体系搭建路径

一页速览（可直接做成内部共识页）
1）定北极星（方向） → 2）搭指标树（因果） → 3）串漏斗（旅程） → 4）建治理（可信） → 5）上看板（闭环）

第一步：定北极星——先把“我们到底要变好什么”说清楚

北极星指标怎么选？一句话答案：选“最能代表用户核心价值、且能牵引长期业务结果”的那一个。

北极星三条硬标准（评审时直接照此打分）

• 代表用户核心价值（不是内部产出）
• 与商业结果强相关（能解释留存、续费、复购、成本效率等）
• 不能被短期手段直接拉动：如果一个指标能被刷量、活动堆资源迅速抬高，它往往不适合作为北极星（会把组织带偏）。

常见误选（也是中国企业最常见的“走歪点”）

• 误把“营收/签约额”当北极星：这是结果，但难指导产品日常动作；
• 误把“DAU/访问量”当北极星：易被流量手段劫持，且未必代表价值达成；
• 误把“上线功能数/迭代次数”当北极星：这是输出不是结果，容易把组织带向“忙而无功”。

产出物（务必落在纸面）

• 北极星指标（1个主选+1个备选）
• 3~5个输入指标（能被日常工作影响）
• 关键假设清单（本季度必须验证的因果假设）

落地提示：北极星与关键假设最怕“只在会议上存在”。实践里我更建议把它们沉淀成可追溯、可讨论、可复用的“产品共识页”（例如 PRD/策略说明/指标定义页），并允许后续迭代版本化。像 ONES Wiki 这种知识库工具支持富文本/Markdown、评论讨论、版本记录与回滚，也支持把文档与项目任务关联起来，便于“战略—需求—迭代”同源追踪。

第二步：搭指标树——把结果拆到“可被影响”的驱动指标

指标树怎么画？一句话答案：把滞后结果拆成领先杠杆，让团队能“事前纠偏”而不是“事后复盘”。

我在项目里常用一句话提醒团队：

只看结果，你永远在解释过去；有领先指标，你才可能改变未来。

拆解三条纪律（避免“拆得很细但毫无行动价值”）

• 可控性：拆到团队能影响的层级，否则只是压力传导；
• 可解释性：每条分支必须讲得清“为什么会影响上层指标”；
• 可验证性：允许被数据检验，避免拍脑袋“伪因果”。

一个通用指标树骨架（可直接复用）

北极星（结果）：每周/每月“价值达成”的客户或用户规模

• 覆盖：进入价值路径的比例（从“进入”到“达成”）
• 深度：价值行为频次/协作深度（从“能用”到“用好”）
• 稳定：关键流程成功率/性能/缺陷（从“可用”到“可靠”）
• 留存：次周/次月留存、续费前置信号（从“发生”到“持续”）

指标卡片（Metric Card）：口径统一的最低成本做法

每个关键指标至少写清：

• 指标定义（口径）｜计算公式｜数据来源（埋点/表/系统）
• 更新频率｜Owner（业务Owner）｜使用场景（用于什么决策）

检查点：如果会开到最后仍在争“活跃到底怎么算”，说明你缺的不是分析能力，而是指标卡片与口径库。

落地提示：指标卡片不是“数据团队的文档”，而是产品团队的“决策字典”。我见过做得比较顺的团队，会把指标卡片放在知识库里，同时在需求/用户故事/实验任务上引用同一口径，避免“文档一套、执行一套”。ONES Wiki 支持文档关联项目任务、并能嵌入工作项列表；ONES Project 则覆盖需求管理、迭代管理等场景，能把“要改什么”直接落到工作项上。

第三步：串漏斗——把“增长与留存”讲成同一种语言

漏斗怎么定义？一句话答案：把用户从“进入—首次价值—持续使用—付费/续费”的关键路径，用事件+时间窗固化为可运营指标。

在B2B/复杂产品里，漏斗最容易失败的两件事

• 激活定义含糊：只写“完成注册”，没有“首次价值达成”；
• 没有时间窗口：不规定“7天内/14天内”，漏斗就无法比较、无法运营。

推荐做法：把“激活”定义为“首次价值达成（First Value）”。B2B 常见示例：

• T天内完成关键配置 / 跑通关键流程一次
• 首次协作达成（≥2角色、≥1流程闭环）
• 首次产出可交付结果（报表/审批/工单闭环等）

产出物

• 关键路径（用户旅程）图
• AARRR 各阶段的“决策级指标”（每段1~2个）
• 每个指标对应的“可运营动作库”（触达、引导、产品改造、质量改进）

落地提示：漏斗不是“画出来”，而是“跑起来”。所以建议你把每个漏斗节点的改进动作拆成可执行的产品工作项：比如“激活引导改版”“关键任务模板”“首个价值路径埋点补齐”“新手引导实验A/B”等，并按优先级进入需求池。比如 ONES Project 提到其支持建立需求池、规划迭代，并可通过看板、燃尽图等跟踪进度——这类能力更适合承载产品团队“从漏斗诊断到迭代交付”的连续动作。

第四步：建治理——口径统一、数据可信、权责闭环

治理怎么做？一句话答案：把指标当“管理资产”来管，像管需求一样管口径、质量与变更。

很多企业的产品指标体系失败，不是方法错，而是“治理缺席”：同名不同口径、数据延迟、指标无人负责，最后只能“用感觉决策”。

治理四件套（PMO 最适合牵头）

• 指标口径库：统一定义、统一版本、可追溯
• 数据质量红线：准确性、完整性、一致性、及时性（不达标必须标注风险）
• Owner机制：业务Owner 对指标解释与改进负责（数据同学负责“数的正确”）
• 变更控制：口径/埋点/报表变更必须评审、公告、可回溯

检查点：如果一个指标没有Owner，就没有人对“为什么变动、下一步怎么改”负责——它迟早变成“会议装饰”。

落地提示：很多产品团队在“指标治理”上忽略了一件事：指标体系不仅要管增长，也要管质量与体验。一个常见闭环是：需求→开发→测试→缺陷→复盘，如果链条断了，你会在“指标下降”时找不到可修复的抓手。ONES TestCase 支持测试用例与需求/任务关联、测试计划与迭代关联，并可由未通过用例快速创建缺陷任务；ONES Project 也与 TestCase 数据互通、可一键提 Bug 并跟踪缺陷。对产品团队而言，这意味着“漏斗问题”可以更快落到“版本质量与缺陷修复”的可执行闭环。

第五步：上看板——用“看板+例会+复盘”把指标变成组织习惯

看板怎么做？一句话答案：看板不是展示页，而是“决策清单”——每次例会都要产出动作与验证方式。

三层看板（与组织层级匹配）

• 经营层看板：北极星 + 关键结果（季度视角）
• 产品层看板：指标树主干 + 漏斗关键节点（双周/月度节奏）
• 专项看板：版本/实验/活动（短周期验证，明确假设与样本）

OKR 如何衔接指标体系？

• OKR 的 KR 要“可衡量、可复盘、能驱动对齐”。因此我建议的硬规则是：
• KR 优先来自“指标树主干 + 漏斗关键节点”；
• 每个KR必须对应：动作（做什么）+ 证据（怎么证明有效）；
• 复盘只讨论：事实—解释—动作，避免变成表态会。

落地提示：

产品经理常见痛点是：单个迭代看得清，多项目/多团队协同就看不清（依赖、资源、节奏容易失控）。在这种情况下，除了迭代看板，还需要“产品线/项目集”层面的汇总视角。ONES 的项目集管理解决方案强调为管理者提供全局视角、支持跨项目制定迭代计划；同时 ONES Project 也提供看板、燃尽图与多种报表来呈现项目表现。你不需要把看板做得花，关键是把它绑定到“例会—异常—动作—验证”的固定节奏上。

如果你还想把“指标体系”落实到更稳定的度量面（交付效率、交付质量、资源效率等），ONES Performance 提到其建立多维度效能度量实践体系，并提供仪表盘模板与多维分析能力，可用于跨团队的趋势复盘。

常见误区：产品指标体系最怕“越努力越错”

误区1：指标越多越安全
指标多往往意味着焦点分散。建议先把“决策级指标”控制在 10~20 个，其他作为诊断指标按需展开。

误区2：只盯增长，不看体验与质量
如果产品进入长期经营阶段，建议把体验纳入指标体系。HEART 框架提供五类 UX 指标：Happiness、Engagement、Adoption、Retention、Task Success，并强调不必每次都用全量指标，应按目标选择组合。

误区3：把指标当考核“唯一答案”
当指标直接绑定奖惩，人会优化指标而不是优化系统，这是典型的古德哈特风险。
更成熟的做法是：指标用于“方向与学习”，考核看“过程合规 + 结果趋势 + 关键里程碑”，避免单点指标绑架组织。

常见问题 FAQ：

Q：北极星指标可以有两个吗？
A：强烈建议“一条业务线一个北极星”，否则对齐会被稀释；若多业务线，可采用“业务线北极星 + 集团约束指标”。

Q：指标树拆到多细才算够？
A：拆到“团队可控、可行动、可验证”为止；再细会变成噪音。

Q：产品经理最容易把哪一步做成形式？
A：第三步与第五步——漏斗没变成需求池动作、看板没绑定复盘节奏，最后都会退化成“好看的图”。

一套真正有效的产品指标体系，最终在提升一种组织能力：

• 用北极星对齐方向，减少内耗；
• 用指标树解释因果，把结果变成可驱动的杠杆；
• 用漏斗运营旅程，把增长与留存放到同一条价值路径上；
• 用治理保证可信，让复盘基于同一套事实；
• 用看板与 OKR 固化节奏，把学习变成组织习惯。

当指标从“月底报表”走向“日常决策”，管理不会更冷，反而更诚实：因为每一次取舍，都能被解释、被验证、被复盘。对中高层与 PMO 来说，这才是指标体系真正的价值——把组织从“讲故事”带到“做学习”。

供应链、交付、现金流压力一上来，很多公司才发现：ERP不是“有没有”，而是“能不能在手机上把事办完”。
移动ERP选对了，核心是让审批、开单、库存、对账这些高频动作随时闭环。

一、主流移动ERP系统详细盘点

1、支道

支道是“一站式业务管理平台”，而不是那种固定菜单的传统ERP：你可以用它把采购、销售、项目、费用、审批、数据看板等流程按自己业务搭起来，然后在移动端跑起来。支道官方站点与App信息里都明确提到其以低代码/aPaaS等方式提供业务全流程数字化管理能力，背后主体为浙江支点数字科技有限公司。

如果你们的痛点是“流程散、表格多、跨部门全靠催”，支道通常比换一套重ERP更快见效。

推荐理由：

1、适合“业务变化快”的团队：流程、表单、权限经常要调整，不想每次都找开发改系统。

2、移动端上手快：App商店可查，适合把填报、审批、协同、数据汇总搬到手机上处理。

产品特色：

1、流程能“按你公司习惯走”：不是让你适应系统，而是系统更容易贴合你的流程。

2、数据能汇总到一处：减少“同一份数据多处填、多版本对不上”的情况。

3、适合先从一个部门/一条流程试起：跑通后再扩，不容易翻车。

适合场景/行业：

项目型/专业服务类公司、以及需要快速搭建内部流程的成长型企业。

2、金蝶

金蝶在小微与中小企业的移动端体验上做得比较成熟，尤其是“金蝶云星辰”这类产品，官方页面强调覆盖采购、销售、库存、资金等链路；同时其App商店信息也强调移动端经营看板、开单、审批等能力

1、推荐理由：想用手机把生意管住（开单/库存/资金），金蝶这条线比较稳。

2、产品特色：进销存与资金链路打通，移动端可做经营与待办处理。

3、适合场景：小微工贸、零售商家、轻量制造或商贸企业。

4、可能的局限：更偏“经营执行与老板看数”，复杂集团多业态要看更高阶产品与实施能力。

3、用友

用友体系里，“友空间”作为移动协同与门户入口，官方页面直接写到：一个App访问多系统、移动快捷审批、实时处理业务；App商店也强调可按组织/角色配置移动门户。

1、推荐理由：如果你们审批链条长、跨部门多，用友的“移动入口+审批”更容易打通。

2、产品特色：移动工作台、待办审批、业务单据一键访问。

3、适合场景：成长型企业、集团型组织的移动协同与业务处理。

4、可能的局限：体系更大，落地往往更依赖实施与规划。

4、鼎捷

鼎捷“掌上易助”页面写得很直白：提供易助小程序，用于满足ERP用户移动化需求；同时易助ERP介绍中也强调其面向中小微制造企业，覆盖财务、进销存、生产等模块。

1、推荐理由：制造企业经常是“人不在电脑前”，小程序入口更容易推广。

2、产品特色：面向中小微制造的ERP体系 + 移动端应用入口。

3、适合场景：机械、五金、汽配、电子加工等中小制造。

4、可能的局限：如果你是多工厂、多语言、多币种的全球化集团，需要评估更高阶产品线。

5、浪潮

浪潮移动ERP在App商店描述中明确写到：提供移动首页、功能中心、移动审批、协同消息等，并可接入后台业务系统。

1、推荐理由：你要的是“统一移动入口+审批协同”，浪潮这类更对路。

2、产品特色：移动首页、功能中心、待办审批、协同消息等。

3、适合场景：高端集团企业移动化协同场景。

4、可能的局限：更偏“集团移动门户”，中小企业如果只要轻量进销存，可能会显得偏重。

6、网上管家婆

网上管家婆官网与App商店信息都提到：移动版为中小微打造，覆盖采购、销售、库存、财务等；并支持电脑、手机、平板、PDA多终端数据同步。

1、推荐理由：商贸批零电商最常见的诉求是“开单快、盘点快、对账清楚”。

2、产品特色：多终端同步、扫码操作、进销存+财务基础闭环。

3、适合场景：批发、零售、电商等。

4、可能的局限：更强在执行层，复杂制造/项目型的深度协同要另评估。

二、6款移动ERP对比表

三、选型建议与关键知识

移动ERP成不成功，不取决于“功能多不多”，取决于“用的人愿不愿意天天用”。

1、先定“移动端三大高频动作”

（1）审批：合同/付款/报销/采购申请

（2）业务动作：开单、查库存、对账、收发货

（3）现场回填：项目进度、巡检、异常上报

2、再看“供应商/协作方是否好用”

（1）入口轻不轻，有没有App、小程序、网页

（2）操作顺不顺，能不能3步以内完成常用动作

3、再看“你现有系统怎么接”

（1）已有财务/ERP/OA？优先选接口开放、能集成的。

（2）用友/金蝶生态用户，走原生或强集成路线通常更省心。

4、最后算总成本，不只看软件费

（1）实施、培训、对接、运维、人力配合成本都要算进去。

（2）最稳的做法：先做PoC，拿你们真实单据和流程跑一遍。

总结：如果你只想先把“移动闭环”跑起来，支道确实应该先看

很多企业的真实情况是：流程不标准、变化快、协同靠人盯。这个时候，支道这种更偏“可搭建、可迭代”的路线，往往更容易先拿到效果，再逐步扩到更完整的管理体系。

作者：齐海智

在 618 大促的技术战场上，每一行代码、每一个配置都影响着一线的实实在在的业务。一次看似平常的发版，却意外暴露了我们系统中的定时任务管理短板，这促使我们深入剖析分布式任务调度中异常重试机制的技术细节，并最终将其转化为守护系统稳定性的坚固防线。​

一、异常事件回溯：隐藏在发版背后的定时炸弹​

发版次日，业务部门反馈商家未收到门店收货明细邮件，导致门店收货业务收到影响。技术团队迅速启动应急流程，通过全链路日志追踪和系统状态分析，发现了问题的根源是：发版过程中，由于服务重启，中断了定时任务进程，正在执行的邮件发送任务被意外终止。而该任务在管理平台上并未配置任何重试策略，业务代码上也没有进行相关的检测和重试，这就导致任务失败后无法自动恢复执行，也未被及时感知到，进而引发业务阻断。​

为解决燃眉之急，研发人员立即登录任务管理平台，手工触发邮件发送任务，确保业务及时恢复。但这次事件给我们敲响了警钟：在分布式任务调度场景下，面对网络抖动、进程异常终止等场景，异常重试机制是保障业务可靠性的关键。​

二、重试策略设计：从理论到代码的深度解析​

2.1 验证EasyJob的重试策略

在复盘问题的过程中，我们发现了EasyJob分布式任务是具有重试策略的，只是默认不开启，而不是默认开启。





该策略以三个核心参数为基础：首次重试间隔时间 F、重试间隔乘数 M 和最大重试次数 C。

通过这三个参数的组合，我们可以灵活控制任务重试节奏，平衡系统负载与任务恢复效率。​

例如：配置t=10s, M=2, C=10，则间隔时间依次是：

验证日志：

21:45:29.990 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:45:40.204 [main-schedule-worker-pool-1-thread-2] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:46:00.674 [main-schedule-worker-pool-1-thread-3] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:46:41.749 [main-schedule-worker-pool-1-thread-4] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:48:02.398 [main-schedule-worker-pool-1-thread-5] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务
21:50:43.008 [main-schedule-worker-pool-1-thread-1] INFO  cn.jdl.tech_and_data.EmailSendingTask - 开始执行发送邮件任务

与上面计算的一致。

验证方案：

1、实现接口：com.wangyin.schedule.client.job.ScheduleFlowTask，并设置任务返回失败：





2、创建CRON触发器





3、设置自动重试参数





4、暂停任务并手工触发一次



2.2 实现一个简单的重试策略

根据上述策略，简单实现了一个灵活可配置的任务重试机制。

public class TaskRetryExecutor {
    @Getter
    private final ScheduledExecutorService executor = newScheduledThreadPool(10);
    private final long firstRetryInterval;
    private final int intervalMultiplier;
    private final int maxRetryCount;

    public TaskRetryExecutor(long firstRetryInterval, int intervalMultiplier, int maxRetryCount) {
        this.firstRetryInterval = firstRetryInterval;
        this.intervalMultiplier = intervalMultiplier;
        this.maxRetryCount = maxRetryCount;
    }

    public void submitRetryableTask(Runnable task) {
        executeWithRetry(task, 1);
    }

    private void executeWithRetry(Runnable task, int currentRetryCount) {
        executor.schedule(() -> {
            try {
                task.run();
                log.info("任务在第{}次尝试时成功执行", currentRetryCount);
            } catch (Exception e) {
                log.error("任务在第{}次尝试时执行失败", currentRetryCount, e);
                if (currentRetryCount <= maxRetryCount) {
                    long delay = calculateRetryDelay(currentRetryCount);
                    log.info("计划在{}毫秒后进行第{}次重试", delay, currentRetryCount);
                    executeWithRetry(task, currentRetryCount + 1);
                } else {
                    log.error("超过最大重试次数。任务执行最终失败。");
                }
            }
        }, currentRetryCount == 1 ? 0 : calculateRetryDelay(currentRetryCount), TimeUnit.MILLISECONDS);
    }

    public long calculateRetryDelay(int retryCount) {
        if (retryCount == 1) {
            return firstRetryInterval;
        } else if (retryCount > 1 && retryCount <= maxRetryCount) {
            long previousDelay = calculateRetryDelay(retryCount - 1);
            return previousDelay * intervalMultiplier;
        }
        return -1; // 超出最大重试次数，返回错误标识
    }
}

​在上述代码中：

1.TaskRetryExecutor类封装了任务重试的核心逻辑。构造函数接收三个关键参数：firstRetryInterval、intervalMultiplier和maxRetryCount，用于配置重试策略，对应于EasyJob的F、M、C参数。

2.submitRetryableTask方法接收一个可执行任务，并启动重试流程。它调用executeWithRetry方法，初始重试次数为1。

3.executeWithRetry方法是重试逻辑的核心。它使用ScheduledExecutorService来调度任务执行：

◦如果任务执行成功，记录成功日志。

◦•如果任务执行失败且未超过最大重试次数，计算下一次重试的延迟时间，并递归调用自身进行重试。

◦•如果超过最大重试次数，记录最终失败日志。

4.calculateRetryDelay方法实现了重试间隔的计算规则：

◦第一次重试使用firstRetryInterval。

◦之后的重试间隔是前一次间隔乘以intervalMultiplier。

◦如果超出最大重试次数，返回-1表示错误。

通过这种设计，我们实现了一个可复用、可配置的任务重试机制。它能够根据配置的参数自动调整重试间隔，在任务失败时进行有策略的重试，同时避免无限重试导致的资源浪费。

详细代码可在以下Git仓库中找到：mailto:git@coding.jd.com:newJavaEngineerOrientation/TaskRetryStrategies.git

2.3 重试策略的理论分析

2.3.1 EasyJob对乘数和最大重试次数的限制

在对EasyJob也进行了重试的验证中发现：

1.每次重做的乘数取值范围是[1,8]，可以是具有一位小数位的浮点数，比如3.5，

2.最多重做次数是[1,16]间的整数，第一次重试的间隔没有限制，单位是秒。



2.3.2 梯度分析

通过上面的验证和重试相关概念的定义，可以得到：第n次重试的间隔时间=第一次间隔时间*乘数^(n-1)，即：

其中：



对乘数M的梯度：

对重试次数n的梯度：



详细推导： http://xingyun.jd.com/codingRoot/newJavaEngineerOrientation/T...

从下图可以看出，重试次数n较大时（比如8），乘数 M 的细微变化都会导致，任务的间隔时间发生剧烈变化，因此n超过8之后，M基本不可调。



同样的，从下图可以看到，乘数M较大时（比如4），n的细微变化也会导致任务的间隔时间爆发式的增加。



1、乘数在1.5-4 的合理性

过小乘数 (<1.5) 的问题：

当乘数 = 1.2，重试 10 次的间隔时间是：1次:1, 2次:1.2, 3次:1.44, ..., 10次:5.16，

10 次重试总间隔仅 5 倍，接近固定间隔，可能导致 "惊群效应"（大量请求同时重试）。

过大乘数 (>4) 的问题

当乘数 = 8，重试 5 次的间隔时间：1次:1, 2次:8, 3次:64, 4次:512, 5次:4096

5 次重试后间隔已超 1 小时（假设初始间隔时间是最小的1s，4096s>1小时），可能导致请求长时间等待，用户体验差。

因此，乘数 = 1.5-4 在 "退避效率" 和 "资源消耗" 间取得平衡，一般取乘数= 2 （标准指数退避）。

行业实践：AWS SDK 默认乘数 = 2，Google gRPC 重试策略推荐乘数 = 1.5-3，多数 HTTP 客户端库 (如 requests) 默认乘数 = 2。

2、最大重试次数3-10的合理性

假设单次重试成功概率为P（比如网络/服务临时故障，重试成功概率通常较高），重试 n次至少成功 1 次的概率为：



当 p=0.5，（单次重试 50% 成功概率）：

n=3 时，成功概率 =1−(0.5)^3=87.5%

n=5 时，成功概率 =1−(0.5)^5=96.875%

n=10 时，成功概率 =1−(0.5)^10≈99.9%

实际场景中，临时故障的单次成功概率远高于 50% （比如网络抖动重试成功概率可能达 80%）

若 p=0.8，n=3时成功概率已达 1−0.2^3=99.2%几乎覆盖所有临时故障。

因此，3 - 10 次重试，能以极高概率（99%+）覆盖“临时故障”场景，再增加次数对成功概率提升极有限（边际效应递减）。

因为已知的任务延迟时间的公式是：

n从1到C进行累加得到总耗时:

，

根据等比数列求和公式可以得到：



令 M=2（常用乘数），F=1 秒（最小可能值）：

n=3时，T=（2^3-1）/（2-1）=7秒

n=5时，T=(2^5-1)/(2-1)=31秒

n=10时，T=2^10-1=1023秒≈17分钟

n=13时，T=2^13-1≈2.3小时

n=15时，T=2^15-1≈9.1小时

当n超过10后，每次增加都会导致总耗时急剧增长，很容易超过业务的容忍上限（具体业务具体分析），也可能因为重试过多，导致被调用的系统压力增加，甚至造成系统崩溃。

故：3 - 10 次重试可将总耗时控制在“业务可接受范围”（几秒到十几分钟），同时避免资源过载。

行业实践：Kafka 消费者重试：默认 10 次、Redis 客户端重试：默认 5 次、Hadoop 任务重试：默认 3-5 次、RFC 建议：RFC 6582（HTTP 重试）建议：3-5 次重试。

3、最佳实践速查表

三、经验沉淀：异常重试机制的设计原则​

通过这次实践和对行业方案的研究，我们总结出异常重试机制设计的四大核心原则：​

1.动态适应性原则：重试策略应支持参数化配置，根据业务场景和系统负载动态调整重试间隔和次数，避免 “一刀切” 的重试策略对系统造成冲击。​

2.幂等性保障原则：确保任务在多次重试过程中不会产生重复数据或副作用，通过唯一标识、状态机等技术手段，实现任务的幂等执行。​

3.故障隔离原则：将重试逻辑与业务逻辑分离，通过消息队列、异步调度等方式，降低重试操作对主线程的影响，避免因重试失败导致系统整体崩溃。​

4.可观测性原则：建立完善的监控和告警体系，实时追踪任务重试状态，在达到最大重试次数时及时发出告警，便于运维人员快速定位和解决问题。​

四、结语：以技术沉淀筑牢大促防线​

这次线上异常事件，犹如一面镜子，让我们清晰地看到了系统中的潜在风险，也为我们提供了一次宝贵的技术提升机会。通过对异常重试机制的深入研究和实践，我们不仅解决了当前问题，更将这些经验转化为团队的技术资产。在未来的 618 大促及其他关键业务场景中，我们将以更完善的技术方案、更严谨的设计原则，守护系统的稳定运行，为业务发展提供坚实的技术保障。

作者：蔡欣彤

项目说明

这是一个同时支持stdio，streamableHttpless和sse三种协议的MCP-Server的框架（ts语言）。

为什么我想做这个框架呢？因为随着AI发展，现在越来越多业务需要和AI相结合。而我在做AI应用中发现，MCP服务在AI方向的业务使用频率很高，但随着业务的加深，发现存在以下痛点：

1.针对不同业务，对于mcp-server需要的类型不同，有的就需要stdio，有的需要网络请求

2.不同平台对MCP服务协议要求不同，有支持streamableHttp，有仅支持sse的。

这两种情况，会出现相同功能重复开发，重复造轮子，浪费时间成本

3. 此外，有些研发人员目前并不了解MCP，在业务开发时候需要现学

而这会让研发周期加长，时间成本耗费过多

所以为了解决以上痛点，我从0-1搭建了这个框架。这个框架特点：

1.同时支持stdio，streamableHttpless和sse三种模式，实现一次开发支持三种模式

2.所有功能都拆分为独立模块。这样即使不懂的人，只要在指定的文件里面编写业务逻辑，就可以创造自己的mcp服务

3.支持环境变量，可通过环境变量配置域名，服务地址，端口和host，真正适用于生产使用

4.切换模式也很简单，只要在启动脚本根据需要，切换启动命令即可，改动成本近乎无

5.添加日志模块，方便查阅启动和服务调用情况

6.同时添加行云脚本，支持行云部署

github地址：https://github.com/XingtongCai/mcp-server-ts

coding地址： http://xingyun.jd.com/codingRoot/jdcloud-fe/mcp-server/tree/m...

内容介绍

整个框架的结构很简单，就如下这些：

## 目录结构
- build: 编译之后的文件
- src
 -- router: 配置streamableHttp和sse协议的路由
   -- index.ts: 注册streamableHttp路由入口
   -- mcp.ts: streamableHttp的配置路径，具体为`process.env.MCP_BASE_PATH`的路径请求,如果没有配置，默认/mcp。如果有需要添加二级路径，例如 /mcp/event，需要在这里面添加一下/event,如果一级不用动
   -- sse.ts: sse的配置路径，具体为`process.env.MCP_BASE_PATH`的路径请求,如果没有配置，默认/mcp。如果有需要添加二级路径，例如 /mcp/event，需要在这里面添加一下/event,如果一级不用动
 -- tools: mcp的工具 
   -- index.ts: 注册工具
   -- mockFunc.ts: 模拟一个工具写法 - 这部分需要根据业务开发
 -- cli.ts: 命令行解析工具
 -- index.ts: 总入口
 -- server.ts: 创建Mcp服务
 -- sse.ts: 运行sse模式
 -- stdio.ts: 运行stdio模式
 -- streamableHttp.ts: 运行streamableHttp模式
- xingyun/bin : 是根据我们业务使用的部署工具开发的部署脚本 - 这部分需要根据实际部署平台更改，我这个支持行云部署
- build_xingyun.sh: 是根据我们业务使用的部署工具开发的部署脚本 - 这部分需要根据实际部署平台更改，我这个支持行云部署

启动服务方式

a.本地启动

1.启动stdio: npm run start 是默认启动stdio

2.启动StreamableHttp: npm run start:http 是默认启动端口3001

3.更改端口启动StreamableHttp: npm run dev:http 或者 npm run start -- -t http -p 3001

-t httt: 代表启动StreamableHttp

-p 3001: 代表启动端口3001

4.启动sse: npm run start:sse 是默认启动端口3001



b.部署启动

我在 xingyun/bin/control.sh中写的启动脚本，这段代码是启动streamableHttpless的，如果需要启动sse，需要改为 npm run start:sse

start(){
    npm run start:http
    sleep 3
    status
}

生产环境配置

# 监听特定内网IP（例如：192.168.1.100）
export MCP_HOST=192.168.1.100
export MCP_PORT=3001

# 使用内网域名（可选）
export MCP_DOMAIN=mcp-server.internal.com

# 修改基础路径（可选，默认是 /mcp）
export MCP_BASE_PATH=/api/mcp

<!---->

### 端口配置优先级
1. 环境变量 `MCP_PORT`（最高优先级）
2. 命令行参数 `--port` 
3. 默认值：3001端口

### 访问地址优先级
1. 环境变量 `MCP_DOMAIN`（最高优先级）
2. 环境变量 `MCP_HOST`
3. 默认: localhost

<!---->

### 内网访问方式
假设你的内网服务器IP是 `192.168.1.100`，端口是 `3001`：

**基础访问：**
```
http://192.168.1.100:3001/sales
```

**带域名的访问：**
```
http://mcp-server.internal.com/sales
```

**自定义路径：**
```
http://192.168.1.100:3001/api/mcp



项目关键代码说明

这个是package.json文件，也是我们一开始要看的，cli.js这个文件是我们启动文件，也是解析命令行的工具，真实区分的地方在index.ts文件中

"scripts": {
    "build": "tsc && chmod 755 build/src/index.js  build/src/cli.js",
    "start": "node ./build/src/cli.js",
    "start:http": "node ./build/src/cli.js --transport http",
    "start:sse": "node ./build/src/cli.js --transport sse",
    "dev:http": "node ./build/src/cli.js  --transport http --port 3002",
    "stop": "pkill -f "demo" || true",
    "restart": "npm run stop && npm run start:http",
    "inspector": "npx @modelcontextprotocol/inspector"
  },

index.ts 的关键代码，在这区分不同模式，然后进入到各自的处理模块。各自模块就是调用sdk，配置域名等操作，代码过长，不展示了，但是这几个文件不用动。




StreamableHttp.ts我支持的是less，就是我不需要sessionId，如果有需要的，这块需要再自己改一下！！





server.ts 是创建mcp服务，同时注册tools工具，三个模式都需要使用的公共文件



tools/index.ts, 作为工具入口，一个工具一个注册



router文件夹下路由注册，是为了sse和streamableless的路由。



其中streamable的index.ts文件里面关键内容，其中basePath就是你的基础路径，通过定义指定访问路径。





sse的在sse.ts文件中，定义了get和post的方法





其实整个框架到这关键的代码就说完了。剩下xingyun的就是在行云平台部署和启动需要的脚本，这里就不介绍了



成果展示

1.stdio - 发布了依赖包，并用joycode成功联通

https://npm.m.jd.com/package/@jd/demo-mcp-server





2.streamableHttp - joycode成功联通并且可以运行





3.sse - autobots支持sse模式，用这个框架开发了在业务中使用的 权限拦截MCP,并成功在autobots引入



作者：齐海智

大促备战中的代码评审困境与破局

双十一大促是系统稳定性的终极“大考”。为规避上线风险，技术侧会启动系统封板管控，主动将非紧急需求的发布窗口前置。这一举措在保障系统稳定性的同时，也必然导致研发需求的前置与集中，使得封板前的代码评审任务量显著增加。我们面临着一个严峻的“量与质”的挑战：

如何在时间紧、任务重的双重压力下，确保代码评审的效率与质量，从而前置发现潜在风险，有效拦截线上BUG？

传统的代码评审模式在此场景下效率低、质量差（风险遗漏的可能性高），而现有的AI辅助工具又因误报率高而陷入尴尬：产生的多数评审意见并无实质帮助，工程师仍需花费大量时间进行判断与筛选。

正是在此背景下，【供应链技术部-商家导入研发组】在AI代码评审方面进行了一些探索，尝试将知识工程代码知识检索能力与AutoBots（已更名为：JoyAgent）知识库检索能力相结合，构建了一套代码评审系统。这套双RAG架构为我们的代码评审工作提供了一些新思路，在此分享出来，希望与各位同行交流探讨，共同进步。

现有技术方案的局限性

技术1：基于流水线的AI代码评审方案

核心技术路径： 在通过公共流程（Webhook触发、解析MR、获取Diff）得到代码变更内容后，该方案的核心处理流程如下：

1.文件类型过滤：仅保留.java、.yaml和.md文件进行后续分析，并明确优先级的处理顺序。

2.上下文截断：为避免触及大模型上下文窗口上限，采用了一种基于固定行数的上下文截断策略。该策略仅截取代码变更处附近预设行数（如10行）的文本内容。

3.Prompt驱动评审：将经过过滤和截断后的代码片段，与预设的评审规则Prompt组合，发送给通用大语言模型。

4.输出评审意见：解析大模型的返回结果，通过coding平台API将评审结果添加到MR中。

核心问题识别：

1.全局上下文缺失：其采用的“固定行数截断”策略是导致问题的根本原因之一。这使得评审完全丧失了项目架构、模块依赖和完整业务逻辑的视野，如同“管中窥豹”，评审深度和准确性受到严重制约。

2.提示词天花板：所有评审规则与知识硬编码于Prompt中，规则膨胀后极易触及模型上下文长度上限，可维护性与扩展性差。

3.知识无法沉淀：效果提升完全依赖于“更换更强的基础模型”与“调整Prompt”，自身缺乏可持续积累、沉淀和复用领域知识的机制。

技术2：基于JoyAgent知识库的RAG代码评审

核心技术路径： 在通过公共流程获取代码差异后，该方案的核心流程如下：

1.知识归纳：将格式化后的Diff内容发送给JoyAgent，由LLM智能体对其进行初步的“知识归纳”，以理解此次变更的核心意图。

2.规则检索：基于归纳出的知识，通过RAG机制从自定义知识库中召回相关的代码评审规则。此知识库支持在线文档（Joyspace）、离线文档（PDF/Word）等多种格式。该方案的核心灵活性在于其“自定义知识库绑定”机制。接入者可以在JoyAgent平台上自定义智能体，通过工作流绑定自定义知识库。这使得在召回评审规则时，系统能动态地查找并应用接入者自定义的评审规则，从而实现了无需修改Prompt即可定制评审规则的能力。

3.行级评审：JoyAgent将代码Diff与召回的具体规则相结合，再次调用LLM进行精确评审。利用Git Diff信息中包含的代码行信息，能够将评审意见精准关联到具体的代码行。

4.输出结果：直接使用JoyAgent的输出结果，通过coding平台API将评审结果添加到MR中。

核心问题识别：

1.知识归纳失真：核心问题源于其“知识归纳”步骤。该步骤依赖底层大模型对Code Diff进行总结，此过程不稳定，经常遗漏或曲解原始代码变更的关键上下文，导致后续流程建立在一个不完整或失真的信息基础之上。

2.检索与生成联动失效：基于失真的知识归纳结果进行RAG检索，导致召回的规则与真实代码场景匹配度低。此外，检索结果未经有效的重排序，直接与不完整的代码上下文一并送入大模型，这使得模型缺乏进行准确判断的可靠依据，最终必然生成大量不可靠甚至错误的评审意见。

从线上问题到技术突破

问题1：三方系统空值处理异常

示例：

// 问题代码：三方系统地址编码字段处理
request.setAddressCode(String.valueOf(address.getCode()));
// 当address.getCode()为null时，String.valueOf(null)返回"null"字符串
// 导致三方系统Integer.parseInt("null")抛出NumberFormatException

技术1的问题：

理论上，可以通过在Prompt中硬编码“三方接口地址编码须为数字类型字符串” 的规则来识别此问题。然而，随着业务场景增多，所有规则都被挤压在有限的上下文窗口内竞争。当代码变更触发自动压缩（如截断至10行）时，被保留的上下文具有极大的随机性，与当前评审强相关的评审规则很可能被其他无关规则挤掉或因自动压缩而被截掉，导致其无法被稳定触发，从而漏报。

技术2的问题：

该方案虽然理论上能够通过知识库检索到相关规则，但其不稳定的知识归纳过程导致代码上下文的理解时好时坏，使得规则检索的准确性波动较大。同时，未对检索结果进行重排序，进一步放大了这种不确定性。最终，由于缺乏稳定、可靠的上下文支撑，系统无法持续、准确地识别此类问题，其评审结果表现出显著的随机性。

问题2：EDI项目中的语法错误

示例：

<!-- 错误：使用变量而非字面常量 -->
<case value="${orderType}">
<!-- 正确应使用字面值：<case value="NORMAL"> -->

EDI平台介绍：

EDI（电子数据交换）是用来解决京东物流与多样化商家系统间的对接难题的技术，其关键功能包括协议转换、数据格式转换、数据校验和流程编排。这意味着EDI配置文件必须严格遵守预定义的语法和标准，任何偏差都可能导致平台的核心转换与校验功能失效。

技术1的问题：

由于其缺乏对EDI配置语法与规范的领域知识，如果自定义规则，会遇到问题1一样的提示词天花板和上下文截断的问题。

技术2的问题：

除了上面提到的知识归纳过程的不稳定问题，技术2也面临一个更前置的的挑战：它缺乏对项目身份的感知能力。系统在处理一个XML配置文件时，无法自动识别它隶属于“EDI项目”而非普通Java应用。因此，在后续的RAG检索过程中，它极有可能使用通用的Java代码评审规则，而无法精准命中“EDI专用配置规范”这一关键上下文，导致检索方向错误，最终无法识别出必须使用字面常量这一特定于EDI领域的合规性要求。

解决方案：双RAG架构

1. 识别项目类型

•特征识别：基于文件扩展名（.flow, .dt）进行精准判断。

•优先级设定：EDI项目识别优先于普通JAVA项目，确保领域特殊性得到优先处理。

•策略影响：项目类型直接决定后续评审规则的选择与RAG知识库的检索策略，从源头保障了评审的针对性。

2. 代码分块处理

2.1 Token估算算法

由于我们使用的底层大模型是JoyAI，并没有公开tokenizer的细节，根据官网文档提供的token计算API： http://api.chatrhino.jd.com/api/v1/tokenizer/estimate-token-c...

测试了几组数据：

推导过程

通过分析测试数据，我们发现了以下关键规律：

1.基础系统开销：所有请求都有63 tokens的固定开销

2.英文单词分级：

◦1-5字符单词 = 1 token（"a"、"hello"、"code"）

◦6-10字符单词 ≈ 2 tokens（推测值）

◦11+字符单词 = 3 tokens（"programming"）

3.中文分词规则：每2个中文字符 = 1 token

4.空格处理：空格作为分隔符，不增加额外token

5.混合内容：按字符类型分段计算后求和

基于上述规律，我们构建了以下估算公式：

总Tokens = 63 + ∑(单词token)

单词token计算：
- 单字符单词: 1 token
- 英文单词(≤5字符): 1 token  
- 英文单词(6-10字符): 2 tokens
- 英文单词(≥11字符): 3 tokens
- 中文文本: (字符数 + 1) / 2 tokens
- 混合内容: 分段计算后求和

2.2 分块阈值与安全设计

•触发阈值：当预估Token数 > 100,000时，自动触发分块处理流程。

◦JoyAI的上下文窗口是128K，由于JoyAI没说明1K是1024还是1000，保守估计使用1000

◦128K = 128000，为了避免超过上下文窗口，留个富余量，使用80%，12800*0.8=102400 ≈100000



•单块容量：设定 MAX\_TOKENS\_PER\_CHUNK = 60000，为模型输出及上下文预留40%的安全余量。

•设计理念：通过严格的容量控制，确保单次处理负载均在模型窗口的安全范围内。

2.3 智能分块策略

系统采用两级分块策略，确保代码语义的完整性：

2.3.1 文件级分割

通过git diff指令识别文件边界，确保单个文件的代码完整性，避免跨文件分割。

Pattern.compile("diff --git a/(.+?) b/(.+?)\n") 

2.3.2 代码结构感知分割

利用方法签名模式识别代码结构边界：

Pattern methodPattern = Pattern.compile(
 "([+-]\s*((public|private|protected)\s+)?(\w+\s+)?\w+\s*\([^)]*\)\s*\{)",Pattern.MULTILINE);

在方法或类的自然边界处进行分割，最大限度保持代码块的语义完整性。

3. RAG增强与重排序机制

3.1 基于知识工程的代码片段、业务上下文的检索

在 RAG增加服务中实现多维度检索增强：

•业务领域识别：基于代码内容识别是仓业务（WMS）、仓配接入业务（ECLP）、转运中心业务（TC）等。

•关键词提取与过滤：从变更文件中提取并净化关键术语。

•通过执行语义搜索。

重排序优化：对检索结果使用BGE模型进行重排序，提升相关性。

3.2 重排序

在RAG系统中，检索（召回）这一步通常使用向量相似度搜索。这种方法追求的是高召回率——即尽可能不遗漏任何可能相关的文档。但这就带来了一个问题：

◦数量过多：可能会返回大量候选文档，全部送入大模型会导致超过上下文窗口限制，成本高昂且速度慢。

◦质量不均：向量搜索是基于语义相似度，但“相似”不一定等于“有用”。它可能会召回一些：

▪主题相关但内容泛泛的文档。

▪包含关键词但逻辑不匹配的文档。

▪相关性排名不高但实际至关重要的“珍宝”文档。

例如检索“如何做番茄炒蛋”，向量相似度查询结果可能会找到：

◦《番茄炒蛋的最正宗做法》 （极度相关，排名第一）

◦《100道家常菜谱》 （相关，但范围太广）

◦《鸡蛋的营养价值》 （部分相关）

◦《番茄种植指南》 （仅关键词相关，实际无用）

如果不经处理，把这四篇文档塞给大模型，模型需要费力地从大量文本中辨别哪些是真正有用的信息，不仅增加了Token消耗，更严重的是，无关信息会形成“噪声”，干扰模型的判断，导致生成质量下降——模型幻觉。

为了节省成本，我们使用了本地重排序方案：

◦模型文件: bge-reranker-base.onnx (BGE重排序模型)

◦分词器: HuggingFaceTokenizer

◦运行时: ONNX Runtime Java API

// 核心流程
public List<Map.Entry<String, Float>> rerankBatch(String query, List<String> documents) {
 // 1. 文本预处理和分词
 // 2. 构建查询-文档对
 // 3. ONNX模型推理
 // 4. 相关性评分计算
 // 5. 按分数降序排序
 // 6. 返回排序结果
}

示例：



4. 实际应用效果验证

案例1：成功预防空值处理事故



案例2：EDI配置规范检查



总结与展望

我们探索出的双RAG架构，其价值核心并非追求极致的简单或敏捷，而是它既能像资深的一线研发一样，深度理解业务及代码变更的具体语境与潜在影响，又能像严谨的架构师一样，严格遵循成文的规范与最佳实践。

通过结构化的协同机制，系统将两种不同质、不同源的知识（深度的代码语义与精准的评审规则）进行融合，实现了 “1+1 > 2” 的智能涌现，从而具备了识别并预防那些复杂、隐蔽代码缺陷的深度推理能力。这正是我们在高并发、高可用要求极为严苛的大促等场景下，为夯实系统稳定性基石所做出的关键性架构决策。

这一成功实践，为我们奠定了代码评审工作中坚实的技术基石，并清晰地指明了未来的演进路径：

1.迈向多模态代码理解：从纯文本代码评审，扩展至对架构图、时序图等非结构化设计产物的理解与合规性检查。

2.构建全域业务知识库：自动抓取并融合产品经理的历史PRD、设计文档等非技术知识，将其转化为知识工程中的关键上下文。这使得AI在评审时，不仅能理解“代码怎么写”，更能判断“代码为何而写”，实现对业务意图的精准校验，从源头规避偏离产品设计的实现。

3.实现需求上下文的自动关联：通过规范研发流程，约束在提交代码时于commit信息中嵌入需求编号。系统在评审时自动提取该编号，并主动获取对应的PRD详情。这使得每一次代码评审都能够在完整的业务背景中进行，AI能够直接对照需求文档，判断代码实现是否完整、准确地满足了所有功能点与业务规则，提供前更加精准的上下文。

虽然探索的道路并非坦途，我们曾在具体的技术细节中陷入困境，例如，为了在 CentOS 7.9 的环境中支持高版本 ONNX 运行时以启用重排序功能，不得不手动编写docker脚本从源码编译高版本的cglib依赖。这段经历，恰恰印证了弗雷德里克·布鲁克斯在《人月神话》中所揭示的那句箴言：

The only way to accelerate software work is to simplify the product and the process, and to face the essential complexity of the software task itself with courage and skill.

Zabbix 介绍

Zabbix 是一个开源的企业级监控解决方案，它可以监控各种网络参数，服务器健康状态，应用程序性能等，并提供灵活的告警机制和丰富的报表功能。

1、Zabbix Server

• 核心组件，负责接收和处理所有监控数据，生成报警和报表。
• 需要一个数据库来存储所有配置和监控数据。

2、Zabbix Agent

• 部署在被监控的设备上，负责收集本地资源和应用数据，并发送给 Zabbix Server。
• 支持多种操作系统，包括 Linux、Windows 和 Unix。
• 其中 Agent 分为 Zabbix Agent 和 Zabbix Agent 2，后者是增强版 Agent，支持插件，适合大规模监控。

3、Zabbix Proxy

• 用于分担 Zabbix Server 的负载，尤其适用于大规模分布式监控。
• 可以在远程网络中收集数据并转发给 Zabbix Server。

4、Zabbix Web Interface

• 基于 PHP 的 Web 界面，用于配置、管理和查看监控数据。
• 提供用户管理、权限控制、仪表盘和报表等功能。

5、数据库

• 存储所有的配置、监控数据、历史记录等。
• 支持多种数据库，如 MySQL、PostgreSQL、Oracle、SQLite。

观测云

观测云是一款专为 IT 工程师打造的全链路可观测产品，它集成了基础设施监控、应用程序性能监控和日志管理，为整个技术栈提供实时可观察性。这款产品能够帮助工程师全面了解端到端的用户体验追踪，了解应用内函数的每一次调用，以及全面监控云时代的基础设施。此外，观测云还具备快速发现系统安全风险的能力，为数字化时代提供安全保障。

部署 DataKit

DataKit 是一个开源的、跨平台的数据收集和监控工具，由观测云开发并维护。它旨在帮助用户收集、处理和分析各种数据源，如日志、指标和事件，以便进行有效的监控和故障排查。DataKit 支持多种数据输入和输出格式，可以轻松集成到现有的监控系统中。（注意，请安装完整版 DataKit，Lite 版本 DataKit 没有 Zabbix 相关采集器。）

登录观测云控制台，在「集成」 - 「DataKit」选择对应安装方式。这里使用主机方式安装。

复制一键安装命令，登陆到目标服务器执行该命令即可实现一键安装。

执行 datakit monitor 命令查看 DataKit 运行状态。

指标数据采集

Zabbix API 方式（zabbix >= 5.0)

DataKit 方式

1、配置 pythond 配置文件

进入 DataKit 的配置文件目录 conf.d，进入 pythond 目录，复制 pythond.conf.sample 为 pythond.conf, 修改如下配置：

[[inputs.pythond]]
  # Python input name
  name = 'zabbix_collect'  # required

  # System environments to run Python
  #envs = ['LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH',]
  envs = ['ZABBIX_HOST=http://127.0.0.1/zabbix', 'ZABBIX_USER=Admin', 'ZABBIX_PASSWD=zabbix', 'ZABBIX_VERSION=7.0', 'COLLECT_TYPE=api']

  # Python path(recomment abstract Python path)
  cmd = "python3" # required. python3 is recommended.

  # Python scripts relative path
  dirs = ["zabbix"]

其中 ZABBIX_HOST，ZABBIX_USER，ZABBIX_PASSWD，ZABBIX_VERSION 填写实际 Zabbix 的地址用户名密码和版本。

保存并退出。

2、复制脚本

进入 DataKit 目录，进入 python.d 目录，创建 zabbix 目录，点击下方链接下载脚本到 zabbix 目录下：

https://static.guance.com/integrations/zabbix/zabbix-collecto...

3、重启 DataKit

datakit service -R

4、检查采集任务，出现 zabbix_collect 任务则说明采集任务开启成功

datakit monitor

Func 方式

1、安装采集脚本

登录 Func，点击「脚本市场」，选择预装脚本市场，点击管理按钮，进入预装脚本市场的脚本列表页。在过滤搜索框中输入 ，过滤出 zabbix 采集脚本。

点击安装按钮，并在弹出的确认框点击确认按钮。点击确认后，在弹出的部署对话框中输入 zabbix 的地址，用户名，密码，以及版本号。确认信息无误后，点击部署启动脚本，即可完成脚本的部署以及采集任务的创建。

2、查看采集结果

登录观测云，点击「指标」 - 「指标管理」，查找 zabbix 指标，看是否采集到。

Streaming 方式（zabbix >= 6.4）

该方式类似于 Prometheus 的 Remote Write，由 zabbix server 主动将数据打给 DataKit，有较高的时效性。

HTTP Server

DataKit 方式

1、配置 pythond 配置文件

进入 DataKit 的配置文件目录 conf.d，进入 python.d 目录，复制 pythond.conf.sample 为 pythond.conf，修改如下配置：

[[inputs.pythond]]
  # Python input name
  name = 'zabbix_collect'  # required

  # System environments to run Python
  #envs = ['LD_LIBRARY_PATH=/path/to/lib:$LD_LIBRARY_PATH',]
  envs = ['ZABBIX_HOST=http://127.0.0.1/zabbix', 'ZABBIX_USER=Admin', 'ZABBIX_PASSWD=zabbix', 'ZABBIX_VERSION=7.0', 'COLLECT_TYPE=stream', 'STREAM_LISTENER_PORT=8000']

  # Python path(recomment abstract Python path)
  cmd = "python3" # required. python3 is recommended.

  # Python scripts relative path
  dirs = ["zabbix"]

其中 ZABBIX_HOST，ZABBIX_USER，ZABBIX_PASSWD，ZABBIX_VERSION 填写实际 Zabbix 的地址用户名密码和版本。

注意，COLLECT_TYPE 必须为 stream， 可根据需要调整 STREAM_LISTENER_PORT 的值。

保存并退出。

2、复制脚本

进入 DataKit 目录，进入 pythond 目录，创建 zabbix 目录，点击下方链接下载脚本到 zabbix 目录下：

https://static.guance.com/integrations/zabbix/zabbix-collecto...

3、重启 DataKit

datakit service -R

4、检查采集任务，出现 zabbix_collect 任务则说明采集任务开启成功

datakit monitor

5、创建 Zabbix 连接器

登录 Zabbix，点击管理 -> 常规 -> 连接器，点击创建连接器，URL处输入 DataKit 的地址以及 zabbix stream 的监听端口（默认8000），信息类型选择数字和浮点数，点击添加。

6、修改 zabbix_server.conf，修改 StartConnectors 为10，保存并重启 zabbix-server 服务

7、验证指标采集结果

Func 方式

1、安装采集脚本

登录 Func，点击「脚本市场」，选择预装脚本市场，点击管理按钮，进入预装脚本市场的脚本列表页。在过滤搜索框中输入zabbix Stream ，过滤出zabbix Stream采集脚本。点击安装即可。

2、创建URL

登录 Func，点击「管理」 - 「同步 API」（建议使用异步API）- 「新建」， 执行一栏选择刚导入脚本中的 Zabbix Receiver 方法，在参数指定中配置采集任务相关的配置，需要指定 zabbix_host，zabbix_user，zabbix_passwd，zabbix_version 为实际的值，base64 为 Zabbix 入参，此处填 INPUT_BY_CALLER，点击保存，并复制 url。

3、创建 Zabbix 连接器

登录 Zabbix， 点击管理 -> 常规 -> 连接器，点击创建连接器，URL 处输入上一步创建的 url，信息类型选择数字和浮点数，点击添加。

4、修改 zabbix_server.conf，修改 StartConnectors 为10，保存并重启 zabbix-server 服务

5、验证指标采集结果

Kafka

该方式原理同 HTTP 方式消费指标数据，区别在于该方法引入了 Kafka 组件，需部署一个 HTTP 服务用于接收 Zabbix 的 stream 输出并将消息发送到 Kafka 中，详见https://git.zabbix.com/projects/ZT/repos/kafka-connector/browse，再由消费者订阅 Kafka，进行数据消费。

指标治理

Zabbix 指标数据结构

Zabbix 以主机为维度统计指标和告警。所以所有的指标必然包含主机信息。主机往往绑定一个或多个接口。

Zabbix 的指标（item key） 的形式为 key[param1,param2,param3]。其中 params 分为静态值和变量两种。

如 vfs.fs.size[{#FSNAME},pused]。其中 key 为 vfs.fs.size，{#FSNAME} 是动态参数，指实际文件系统名，pused 为静态参数，指使用量。

上述采集方式中 zabbix api，Streaming，Zabbix Agent 2 三种采集方式均默认使用该规则进行指标映射。

建议的指标治理规则

由于 Zabbix 的数据结构跟观测云存在较大差异，为方便指标的使用与管理，结合实际企业用户的部署经验，对于 API 和 Streaming 的采集方式，我们建议 Zabbix 指标数据上传到观测云时按如下规则进行转换：

• measurement (指标集)：zabbix key 第一个 '.' 前的内容。
• fields (指标)：zabbix key + 所有静态参数。如 vfs.fs.size[{#FSNAME},pused]，就会变成 vfs.fs.size.pused，system.cpu.load[all,avg1]，就会变成system.cpu.load.all.avg1。
• tags (标签)：zabbix item key 中的所有动态参数小写。同时会添加 host，ip 以及 item 的 tags。如：vfs.fs.size[{#FSNAME},pused] 的 tag 为 fsname。

Example：

使用 Pipeline 的 reference table 实现自定义 Tag

场景：对于已有 CMDB 的客户，希望将主机的一些字段富足到指标 Tag 中。如应用、负责人信息等。

方式：使用 Pipeline 的 refertable 功能。

具体步骤：

1、使用 Func 创建一个脚本用于组装 reference table 数据，并发布。数据结构类似于：

{
"table_name": "zabbix-refer-table",
"column_name": ["itemid", "host", "ip", "itemkey"],
"column_type": ["string", "string", "string", "string"],
"row_data": [["1001", "host-1", "10.0.0.1", "vfs.fs.size"], 
    ["1002", "host-2", "10.0.0.2", "vfs.fs.size.pused"], 
    ["1003", "host-3", "10.0.0.3", "vfs.fs.size.pfree"]]
}

更多 reference table 用法，可参考：https://docs.guance.com/datakit/datakit-refer-table/

2、创建同步 API

登录 Func，点击「管理」 - 「同步 API」，点击 新建，在添加同步 API 对话框执行一栏中选择 zabbix-reference-table 获取脚本，点击确定保存脚本，并点击示例，获取请求 API。

3、编辑 DataKit 的配置文件

登录 DataKit 所在服务器（容器部署DataKit 参考官方文档），进入 DataKit 配置目录 /user/local/datakit/conf.d，编辑 datakit.conf 文件，修改 [pipeline] 选项下的 refer_table_url 的值为上一步复制的 Func 接口地址。DataKit 会将 refertable 数据预先加载到本地的 sqllite 中，可以根据 refer table 大小灵活选择是否使用内存模式的 sqllite。保存后重启 DataKit 生效。

4、编辑 Pipeline

登录观测云，点击「管理」 - 「Pipelines」- 「新建 Pipeline」，这里给到一个参考 Pipeline，可根据实际业务情况和 refertable 数据结构灵活调整。

5、查看指标 Tag

超大数据量采集优化策略

• 对于 Export Directory 方式，可以增加独立的高速 SSD 磁盘，增加单独的 zabbix server 用于数据导出（由于需要访问 zabbix API 和数据库，DataKit 采集 ExportDirectory 会比较占用 zabbix 资源）。调低 ExportFileSize 大小。
• API 采集方式，可以通过分页查询，减少查询关联表，多线程查询等方式。
• HTTP stream 方式，可以引入队列进行异步消费或使用异步方法。支持采样收集等方式。
• 指标治理应先将映射关系生成后存入缓存或内存中，方便快速匹配。为减少 redis 读写压力可以考虑分片缓存或缓存压缩等方法。

各采集方式对比

总结

监控数据的集成是一个复杂的综合性工作，本文所展示方案所适用场景需相关运维工程师根据实际情况进行调整。

很多人以为在大厂工作，就是不停地写代码、解决技术难题。

但事实是：真正成功的工程师并不是那些代码写得最好的人，而是那些解决了代码以外事情的人。

本篇和你分享 21 条职场教训。

这些教训，有的能让你少走几个月的弯路，有的则需要数年才能完全领悟。

它们都与具体的技术无关，因为技术变化太快，根本无关紧要。

但这些教训，项目换了一个又一个，团队换了一批又一批，始终在重复上演。

希望能帮助到你：

1. 最优秀的工程师都痴迷于解决用户问题

很多人容易爱上一项新技术，然后到处找地方用它。

我干过，你肯定也干过。

但真正创造最大价值的工程师是反过来的：

他们专注于深入理解用户问题，并让解决方案从这种理解中自然而然地涌现。

以用户为中心意味着花时间处理支持工单，与用户沟通，观察用户遇到的困难，不断追问“为什么”，直到找到问题的症结所在。

真正理解问题的工程师往往会发现，优雅的解决方案比任何人预想的都要简单。

工程师如果一开始就想着如何解决问题，往往会为了寻找理由而人为地增加复杂性。

2. 正确很容易，共同达成正确才是真正的挑战

即使你在技术上胜券在握，最终也可能输掉项目。

我曾亲眼目睹一些才华横溢的工程师，自诩为房间里最聪明的人，但总是默默地积攒怨气。最终表现为“莫名其妙的执行问题”和“莫名其妙的阻力”。

关键不在于证明自己正确，而在于参与讨论以达成对问题的共识。

为他人创造发言空间，并对自己确信的观点保持怀疑。

3. 行动优先，先做，再做对，再做好

追求完美会让人停滞不前。

我曾经见过工程师花几周讨论一个从没建过的东西的理想架构。

但完美的方案很少从思考中产生，它都是从与现实的碰撞中产生。

先做出来，再做对，再做得更好。

把丑陋的原型放到用户面前，写出乱糟糟的技术文档初稿，发布那个让你有点尴尬的 MVP。

从真实反馈中学到的内容，哪怕只有一周，也远比一个月的理论辩论多得多。

4. 代码清晰远比炫技重要

我知道你想要写出酷炫的代码，那可以证明自己很牛逼。

但项目往往不止你一个人，以后还有其他同事要维护。

优化时要考虑他们的理解能力，而不是你的代码是否优美。

5. 谨慎选择新技术

新技术就像贷款，你要用 bug、招聘困难和认知负担来还。

关键不在于“永远不要创新”，而在于“只在因创新可以带来独特报酬的领域进行创新”。其他的一切还是应该回归平庸。

6. 你的代码不会替你说话，但人会

刚开始工作时，我相信是金子总会发光。

但我错了。

代码静静地躺在仓库里。你的领导在会议上提到你，或者没提。同事推荐你参与项目，或者推荐了别人。

在大公司，决策是在你没被邀请的会议上做出的，用的是你没写的总结，由只有五分钟时间和十二件事要处理的人做出的。

如果你不在场时没人能清楚说出你的价值，那你的价值就等于可有可无。

这不是让你鼓吹自己，而是告诉你：你需要让你的价值被所有人看到。

7. 最好的代码是你根本不用写的代码

工程师文化崇拜创造。

没有人会因为删除代码而获得晋升，即使删除代码往往比添加代码更能改进系统。

因为你不写的每一行代码，都意味着你永远不必调试、维护或解释。

在动工之前，先仔细思考一下：“如果我们不做这件事会发生什么？” 有时答案是“没什么坏处”，那就是你的解决方案。

问题不是工程师不会写代码，而是我们太会写了，以至于忘了问：该不该写？

8. 大规模时，连你的 bug 都有用户

用户多的时候，连你的 bug 都会有用户，这产生了一个职业级洞察：

你不能把兼容性工作当“维护”，把新功能当“真正的工作”。兼容性就是产品。

所以把你的“废弃”做成“迁移”，带上时间、工具和同理心。

9. 慢实际上是因为不协调

项目进展缓慢时，人们的第一反应往往是责怪执行：员工不够努力、技术不成熟、工程师人手不足。

但通常来说，这些都不是真正的问题所在。

在大公司，团队是并发执行的基本单位，但随着团队数量的增加，协调成本呈几何级增长。

大多数效率低下实际上源于目标不一致——人们在做错误的事情，或者以不兼容的方式做正确的事情。

所以高级工程师花更多时间澄清方向、接口和优先级，而不是“写代码更快”，那些才是真正的瓶颈所在。

10. 专注你能控制的，忽略你无法控制的

在大公司，无数的变数都超出你的掌控——组织架构调整、管理决策、市场变化、产品转型等等。

过度关注这些因素只会让你焦虑不安，却又无能为力。

所以高效的工程师，会锁定自己的影响圈。你控制不了是否会重组，但你能控制工作质量、如何应对、学到什么。

这并非被动接受，而是策略性关注。

把精力浪费在无法改变的事情上，就等于浪费了原本花在可以改变的事情上的精力。

11. 抽象并不能消除复杂性

每一次抽象都是一种赌博，赌你不需要理解下面是什么。

有时候你会赢，但总会有漏洞，一旦出现漏洞，你就需要清晰地知道你站在什么上面。

所以高级工程师即使技术栈越来越高，也要持续学习“更底层”的东西。

12. 写作让表达更清晰，以教带学是最快的学习方式

写作能带来更清晰的表达。

当我向别人解释一个概念——在文档里、演讲中、代码评审评论里、甚至和 AI 聊天，我都会发现自己理解上的不足。

所以如果你觉得自己懂了什么，试着简单地解释它。卡住的地方，就是你理解肤浅的地方。

13. 注重粘合性工作

粘合性工作——例如写文档、帮新人上手、跨团队协调、流程优化——至关重要。

但如果你总是无意识地做这些，反而可能会拖慢技术成长，把自己累垮。

陷阱在于把它当“乐于助人”的活动，而不是当作有边界的、刻意的、可见的影响力。

尝试给它设时限，轮换做，把它变成产出物：文档、模板、自动化。

让它作为“影响力”被看见，而不是作为“性格特点”。

14. 如果你赢得每一场辩论，你很可能是在积累无声的阻力

当人们不再和你争，不是因为你说服了他们，而是因为他们放弃了。

但他们会在执行中表达分歧，而不是在会议上。

所以真正的共识需要更长时间。你得真正理解别人的观点，吸收反馈，有时候需要你当众改变主意。

短期“我是对的”的快感，远不如长期和心甘情愿的合作者一起建设的现实来得珍贵。

15. 当衡量标准变成目标时，它就停止了衡量

你暴露给管理层的每个指标，最终都会被博弈。

不是因为恶意，而是因为人会优化被度量的东西。

追如果你追踪代码行数，你会得到更多的代码行数。如果你追踪开发速度，你会得到过高的估算值。

高手的做法是：对每个指标请求都提供一对指标。一个用于衡量速度，一个用于衡量质量或风险。然后，坚持解读趋势，而不是盲目追求阈值。

目标是洞察，而非监控。

16. 承认自己不知道的事情比假装自己知道更能带来安全感

资深工程师说“我不知道”并不是示弱——他们是在鼓励大家坦诚面对。

当领导者承认自己的不确定性时，就等于在暗示其他人也可以这样做。如果不这样的话，就会形成一种人人假装理解、问题被掩盖直到爆发的文化。

我见过团队里最资深的人从不承认自己不明白，我也见过由此造成的后果。问题不被问出来，假设不被挑战，初级工程师保持沉默因为他们以为别人都懂。

17. 你的人脉关系比你拥有的任何一份工作都更长久

职业生涯早期，我专注于工作本身，忽视了人脉经营。回头看，这是个错误。

那些注重人脉关系的同事，在接下来的几十年里都受益匪浅。他们最先了解机会，更快地建立人脉，获得职位推荐，和多年来建立信任的人一起创业。

你的工作不会永远持续下去，但你的人脉网络却会一直存在。

以好奇心和慷慨的态度去拓展人脉，而不是抱着功利主义的心态。

当需要向前迈进的时候，往往是人际关系打开了这扇门。

18. 大多数绩效的提升来自于减少工作量

当系统变慢时，人们的第一反应往往是加东西：加缓存、并行处理、使用更智能的算法。

有时候这样做是对的。

但我发现，通过询问“我们计算了哪些不必要的东西？”往往能带来更多性能提升。

删除不必要的工作几乎总是比更快地完成必要的工作更有成效。最快的代码是永远不会运行的代码。

所以在进行优化之前，先问问自己这项工作是否真的应该存在。

19. 流程存在的目的是为了减少不确定性，而不是为了留下书面记录

最好的流程是让协调更容易、让失败成本更低。

最差的流程是官僚主义——它的存在不是为了帮忙，而是为了出事时推卸责任。

如果你无法解释一个个流程如何降低风险或提高清晰度，那么它很可能只是增加了额外开销。

如果人们花在记录工作上的时间比做工作的时间还多，那就说明出了大问题。

20. 最终，时间会比金钱更有价值

刚开始工作的时候，你用时间换钱——这没问题。

但到了某个阶段，情况就完全不同了。你会开始意识到，时间才是不可再生资源。

我见过一些高级工程师为了晋升而累垮自己，只为了多拿几个百分点的薪酬。有些人确实升职了，但事后大多数人都在反思，自己放弃的一切是否值得。

答案不是“别努力工作”，而是“知道你在交易什么，并深思熟虑地进行交易”。

21. 没有捷径，但有复利

专业技能源于刻意练习——略微超越现有水平，然后不断反思，不断重复。年复一年，没有捷径可走。

但令人欣慰的是：学习的进步在于创造新的选择，而不仅仅是积累新的知识。

写作——不是为了吸引眼球，而是为了清晰表达。构建可复用的基础模型。将过往的经验总结成行动指南。

所以如果工程师把职业生涯看作是复利投资，而不是彩票，那么他最终往往会取得更大的成就。

22. 最后

21 条听起来很多，但它们可以归结为几个核心点：保持好奇，保持谦逊，记住工作始终是关于人的——你的用户、你的队友。

工程师的职业生涯足够长，可以犯很多错误。我最钦佩的工程师，不是那些什么都做对的人——而是那些从错误中学习、分享发现、并坚持不懈的人。

本篇整理自《21 Lessons From 14 Years at Google》，希望能帮助到你。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。

随着 AI 在开发者工具领域的迅速发展，Claude Code 已成为越来越多程序员、技术团队的重要助手。它不仅能理解自然语言，还能根据指令生成代码、调试、分析项目结构等，提高编程效率。然而，对于中国大陆的开发者来说，如何合法、安全、稳定地使用 Claude Code呢？有哪些方法？

本篇内容为大家介绍 Claude Code是什么、国内怎么用、合规网络环境、会员要求以及风险等问题，一起往下看看吧。

一、Claude Code 是什么?

Claude Code 是由美国 AI 公司 Anthropic 推出的智能编程助手工具，通过 Claude 模型(如 Sonnet、Opus)为开发者提供：

代码生成
代码修复与调试
代码上下文理解
自然语言指令驱动编程任务
它的定位是 “AI 编程伙伴”，适合从个人开发者到技术团队辅助开发和自动化脚本等广泛场景。相比一些传统代码补具，Claude Code 更强调对整个代码库的理解和对复杂任务的自然语言响应能力。

二、Claude Code 在国内可以使用吗?

答案是：可以使用，但有一些地区和网络限制。

Anthropic 的服务在全球范围内提供，但部分地区的访问可能受限或不稳定。对于中国大陆境内用户，由于国际访问网络限制和政策原因，直接访问 Claude Code 的官网或命令行服务可能会遇到：

网络阻断或延迟高
注册/订阅页面加载失败
个人/企业用户被限制访问
因此，想要在国内顺畅使用 Claude Code，需要提前准备好合规、稳定的网络工具，没有的话可以使用OSDWAN，提供稳定、合规的跨境网络专线。

三、Claude Code要会员吗?

需要付费订阅才能使用Claude Code，Claude本身有免费计划，但免费版不支持 Claude Code。

根据官方定价页面，Anthropic 提供了多个付费版本：

目前没有免费版 Claude Code，免费账户能使用 Claude AI 的基本聊天或简单能力，但无法用于完整的代码生成/执行任务。

四、Claude Code网络怎么解决？如何合法使用 Claude Code？

由于 Claude Code 是国外服务，对于国内用户来说，建议使用合法合规的网络来访问。

1. 使用合规、安全的网络通道

要在国内访问国外服务，需要一个合法、稳定的国际出口网络：

传统国际网络专线
SD-WAN国际网络专线
SD-WAN专线是目前企业和专业开发者最主流、最稳定的方式，用合规的国际网络专线，把国内访问“直接接入”到海外网络环境。

避免使用未授权、风险高的私人代理或翻墙工具，因为这可能违反当地政策，也可能导致账号不稳定或者封号风险。

下面以OSDWAN为例，如何开通合法的SD-WAN专线：

开通流程一般是：

联系顾问 → 说明用途（访问Claude 或者其它/ 个人还是企业等）
选择线路节点（美国、新加坡、日本等）
开通账号，下载软件并登录OSDWAN
选择合适的模式（使用海外AI工具，可选择开发科研模式），连接即可使用了。
连接之后就可以稳定访问Claude Code了，以及其它海外AI工具，比如ChatGPT、Gemini、Github。

2. 购买和使用 Claude Code会员

步骤大致如下：

注册 Claude 官方账号(可以使用Gmail邮箱注册)
登录官网或 app 进入 pricing/订阅页面
根据需求选择 Pro 或 Max 套餐购买
完成支付
激活订阅后即可使用 Claude Code
五、Claude Code 有没有封号风险?

很多人在国内使用国外 AI 工具时最担心的一个问题就是 账号会被封禁。

如何规避封号风险：

遵守官方使用规则和服务条款
不使用未授权破解工具
使用稳定网络避免异常访问行为
不转售账号或共享账号
只要按照官方规则使用，并保证网络与付费的合法性，一般不会轻易触发封号行为。

六、合规网络专线哪家好？

OSDWAN 是目前很多技术团队的选择之一，主要优势以下：

1、纯净度高

精准定位市场，提供纯净的原生住宅IP地址，真实原生网络环境，避免因IP不纯净导致被网站标记而封号。

2、节点覆盖全球

覆盖全球200+国家和地区，包括美国、日本、新加坡、东南亚等主流区域。

3、连接稳定

OSDWAN是国内专业跨境网络专线的服务商，是基于SD-WAN技术和SaaS技术的一款产品，支持cpe设备和软件连接，可访问国外任何网站，避免Claude登录中断。

4、使用灵活

多设备支持连接，Windows/安卓/苹果等都可以连接使用，独享专线企业可基于APP随时管理，比如上网日志审查、加密、终端管理、员工管理等各项操作。

七、常见问答

Q1：Claude Code 有没有免费使用方式?

答：不提供完整免费的 Claude Code 功能。目前付费订阅(如 Pro 或 Max)才包含 Claude Code 权限。免费账户仅能访问基础聊天和有限功能。

Q2：我能在国内直接用手机访问 Claude Code 吗?

答：可以尝试，但由于网络直连可能不稳定，建议使用合规网络加速服务以提升访问稳定性。

Q3：：Claude Code 会随时封号吗?

答：只要你遵守官方条款、合理使用，并使用安全网络，封号风险较低。违规、多账号共享或自动化滥用更容易被封禁。

总结

要在国内合法、安全地使用 Claude Code：

使用官方账号并购买付费订阅(Pro/Max)
使用合法稳定的国际网络通道
遵守服务条款，避免异常访问或滥用
如果你正在考虑长期在国内将 Claude Code 用于开发、调试或生产力提升，这是完全可行的——前提是使用安全、合规、稳定的跨境网络专线。

OSDWAN作为国内专业的跨境网络服务商，为出海企业提供合规、高速、稳定的网络解决方案，支持硬件、软件方案灵活部署。

OSDWAN在全球的数据中心节点50个，POP节点超过200个，可以为出海企业提供海外加速、SaaS加速、SD-WAN组网、跨境组网、云专线等产品服务，助力中国企业开拓国际市场。

哈喽，我是老刘

2025年已成过往。随着iOS、Android、桌面端、Web与各类小程序的持续发展，原生开发的高墙已难以维系，成本与效率的矛盾达到顶峰。

跨平台不再只是备选项，而是个人和团队的必选项。但面对Flutter的全平台一致体验、React Native的新架构性能突破、uni-app x的原生编译能力、KMP的Compose全栈统一，究竟谁才是2026年的最优解？

如何在这个AI重塑代码的时代，把有限的资源发挥出最大的效率？

老刘每个月为大家画出最新的跨平台技术选型地图，帮你快速做决策。

本月，各大框架在“原生体验”与“AI提效”上都有重磅更新。

1. 2025年跨平台技术简单总结

• 性能仍是核心

2025年，各个框架都在寻找性能的突破点。

Flutter全面普及Impeller引擎，解决了最后一公里的卡顿问题。

uni-app x和KMP则选择了另外一条路，通过编译为原生代码（Native Compilation），直接从物理层面消除了性能鸿沟。

RN则全面切换到新架构来实现性能的突破。

性能上向原生看齐是2025年跨平台技术的一个重要趋势。

• 平台拼图补全

框架们不再满足于能跑，而是追求各个平台的完美适配。

Flutter在桌面端和Web端（Wasm）持续发力，真正实现六端同源。

KMP推出了Kotlin-to-Swift导出功能，让iOS开发者也能优雅地接入，填补了跨平台在iOS原生生态上的最后一块拼图。

• AI与框架深度融合

AI不再只是外部辅助，而是开始进入框架内部。

Flutter推出的Dart MCP Server让AI能直接理解项目结构和组件树。

MAUI也在不断完善其AI功能，如Copilot Agent，试图通过AI赋能来改善开发者体验。

应该说我们离描述即应用的时代不远了。

2. 最新技术动态

2.1 React Native 新架构全面启用

React Native 0.83 发布日志: https://reactnative.dev/blog

React Native 0.83 版本随 Expo SDK 55 正式到来。新架构（New Architecture）已成为默认标准，遗留架构代码正在被加速移除。新版本集成了 React 19.2，并在构建时间和应用体积上取得了显著优化。开发者现在可以享受到更接近原生的性能体验，以及更强大的 DevTools 支持。

2.2 Kotlin Multiplatform 生态成熟加速

Kotlin 2.3.20-Beta1 新特性: https://kotlinlang.org/docs/whatsnew-eap.html

Kotlin 2.3.20-Beta1 于本月发布，标志着 KMP 生态的进一步成熟。

Compose Multiplatform for iOS 已经稳定，越来越多的团队开始从原生转向 KMP。

K2 编译器的全面普及以及 JetBrains 在 AI 辅助开发（如 Koog 和 Mellum）上的投入，使得 KMP 的开发效率达到了新高度。

2.3 .NET MAUI 企业级发展

.NET MAUI Roadmap: https://github.com/dotnet/maui/wiki/Roadmap

.NET 11的规划和早期迭代正在进行中。当前重点依然是提升产品质量和性能稳定性。微软正在深度集成 GitHub Copilot 和 Copilot Agent，试图通过 AI 赋能来改善 MAUI 的开发者体验。尽管社区仍有关于稳定性的讨论，但其在企业级市场的地位依然稳固。

2.4 Flutter 平台更新

Flutter 最新动态: https://docs.flutter.dev/release/whats-new

虽然社区对 Flutter 4.0 充满期待，但截止 2026 年 1 月，Flutter 3.38 仍是官方维护的最新稳定版本。目前的更新重点在于 Impeller 渲染引擎 的进一步优化与稳定性提升，该引擎现已在 iOS 和 Android 上默认启用，彻底解决了 shader 编译造成的卡顿问题。此外，Flutter 团队修复了 Android 端 Activity 销毁时的内存泄漏问题，并对 Android 15 的 16KB Page Size 提供了完整支持，继续巩固其在跨平台渲染一致性上的优势。

2.5 uni-app x 进展

uni-app x 更新日志: https://uniapp.dcloud.net.cn/release.html

近期 uni-app x 迎来了一系列重要更新（v4.87）。核心亮点包括：

• 多线程能力增强
  新增 uni.createWorker API，正式支持 Worker 线程，显著提升复杂计算场景下的性能表现。
• 鸿蒙生态深度适配
  将逻辑层 JSVM 迁移至独立子线程，彻底解决主线程阻塞问题；新增微信登录、分享及屏幕亮度调节等原生能力。
• 新设备与系统兼容
  修复 Android 16KB 页大小模式下的录音问题，并提前适配 iPhone 17 系列机型。

2.6 Valdi 进展

Valdi GitHub 仓库: https://github.com/Snapchat/Valdi

本月Valdi框架没有新的进展，最新发布版本仍然是beta-0.0.1

接下来老刘按照跨平台技术框架的三种路线，分别介绍一下目前主流的跨平台技术。

3. 自渲染类框架

简单来说，就是框架自己携带渲染引擎，自己画界面，不用系统提供的组件。

这样做有什么好处？

• 界面完全一致
  UI渲染不依赖系统组件，多端展示效果完全统一。
• 性能媲美原生
  跳过系统UI层直接操作GPU绘制，架构与原生一致。
• 无兼容性Bug
  不调用系统原生组件，规避了因系统差异导致的兼容性问题。

3.1 Flutter

2024年Stack Overflow调查显示，Flutter是最受欢迎的跨平台框架。

全球有超过500万开发者在使用。

连阿里巴巴、腾讯、字节跳动都在使用Flutter。

为什么这么多大厂选择Flutter？

• 性能强劲
  切换Impeller引擎后，Flutter性能已与原生应用一致。
• 开发高效
  热重载实现秒级预览，Dart语言在功能性与复杂度间达成完美平衡。
• 生态成熟
  pub.dev拥有超4万插件，涵盖地图、支付等各类功能，开箱即用。
• 测试友好
  拥有客户端领域最佳的单元测试支持，是TDD及敏捷团队的最优选择。

• 拥抱AI

  • AI Toolkit

  集成Gemini API，快速实现聊天、识别等功能。

  • 本地部署

  支持TensorFlow Lite/ONNX，保障隐私安全。

  • Dart MCP Server

  让AI助手直接理解项目，辅助编码与调试。

4. 中间层类框架

简单来说，就是在你的代码和系统原生组件之间，加了一个"翻译官"。

比如你用JavaScript写界面逻辑，框架帮你翻译成原生的Button、TextView。

核心特点：

• 成熟的开发体验
  复用React/Vue/C#等生态成熟的开发思路，上手快，学习成本低。
• 原生组件渲染
  最终映射为系统原生组件，UI符合平台规范，质感原生。
• 桥接性能损耗
  通过中间层与原生通信存在"翻译"开销，交互密集场景性能稍弱，常规界面无感知。

4.1 React Native

React Native是第二受欢迎的跨平台框架，是Facebook开源的项目。

为什么这么多人选择React Native？

核心优势：

• 零门槛上手
  React开发者可直接复用JSX、组件化及状态管理经验，一周即可转型。
• 生态庞大
  npm拥有超15万相关包，共享Web生态，导航、支付等库应有尽有。
• 动态热更新
  支持不发布新版本App直接在线更新，无需发版即可修复Bug或上线新功能，迭代极快。
• 架构升级
  Meta持续投入，新架构引入Fabric和TurboModules，性能提升30%，旧架构已退役。

4.2 .NET MAUI

2024年5月，微软正式停止了Xamarin的支持，.NET MAUI（Multi-platform App UI）成为微软官方的跨平台解决方案。

核心优势：

• 企业级保障
  微软提供长期技术支持（LTS），确保企业应用所需的稳定性。
• 数据处理强
  C#擅长处理复杂业务逻辑，特别适合金融、ERP等数据密集型应用。
• 生态深度集成
  与Azure、SQL Server等微软全家桶无缝对接，集成体验最佳。

5. 转译类框架

简单来说，就是把你写的高级语言代码，"翻译"成目标平台的原生代码。

比如你用Kotlin写业务逻辑，框架帮你"翻译"成iOS的Swift代码。

或者你用类TypeScript的语法写界面，框架帮你"翻译"成Android的Kotlin和iOS的Swift。

核心特点：

• 性能接近原生

因为最终运行的就是原生代码，没有任何中间层损耗。

就像你直接用Swift写iOS应用，用Kotlin写Android应用一样。

• 能享受原生生态

转译后的代码可以直接调用平台的所有API。

• 转译效果可能不完美

毕竟是机器"翻译"的代码，有时候可能不如手写的原生代码优雅。

特别是复杂的业务逻辑，转译后的代码可能需要人工优化。

但这个问题随着AI技术的发展，正在快速改善。

5.1 Kotlin Multiplatform (KMP)

KMP的核心用法：业务逻辑用KMP共享，UI用Compose Multiplatform统一开发

这是KMP的最新发展方向，结合了Compose Multiplatform的强大能力。

一套Compose代码可以运行在Android、iOS、Desktop、Web等所有平台。

KMP的特点

• 真正的一套代码多平台

不仅业务逻辑共享，UI也可以共享，开发效率大幅提升。

• 保持原生性能

  Compose Multiplatform在各平台都编译为原生代码，性能接近原生应用。

• 技术栈统一

全部使用Kotlin生态，学习成本更低，团队协作更高效。

• 渐进式迁移

你不需要重写整个应用，可以先从一个模块开始。

比如先把网络层用KMP重写，然后逐步迁移UI到Compose Multiplatform。

• 生态仍需完善

生态仍在加速建设，注意版本兼容与插件成熟度，第三方库相对较少，但发展很快。

5.2 uni-app / uni-app x

传统uni-app
基于Vue.js + JavaScript，更适用于小程序开发

uni-app x
全新架构，使用UTS语言，性能达到原生级别

uni-app x的技术特点

• 平台支持最全

一套代码可以发布到：iOS、Android、Web、各种小程序、快应用、鸿蒙...

总共支持14+个平台，这是其他框架做不到的。

• 小程序优先的设计理念

如果你的产品需要同时支持App和小程序，uni-app几乎是唯一的选择。

其他框架都是App优先。

• 国产化支持

对鸿蒙、信创等国产化平台支持最好。

这对国内企业来说非常重要。

• uni-app的局限

  生态相对封闭
  主要依赖DCloud的生态
  国际化程度低
  海外开发者使用较少
  技术栈绑定
  主要适合Vue技术栈

5.3 Valdi

Valdi的核心思路属于转译方案的范畴，但是并发代码级转译。

它采用了介于转译和中间层之间的混合架构，将UI组件树编译为原生组件并交由C++引擎管理生命周期，同时保留业务逻辑在TS层（Worker）运行，从而实现无JS Bridge的高性能渲染。

这样的好处是在一定程度上避免了转译类方案代码翻译不到位造成的一些问题。

但是仍然会有中间层方案在高UI交互场景下的性能问题，这部分就需要把处理逻辑放到C++/Swift/Kotlin编写的Polyglot模块解决。

站在纯粹客户端跨平台开发的角度，转译类方案老刘目前更推荐KMP。

Valdi可以作为一个有潜力的备选，等生态更加成熟后再重新考虑。

6. 技术选型指南

看了这么多技术栈，是不是更晕了？老刘把复杂的选型逻辑浓缩成一份实战决策指南，帮你快速拍板。

6.1 核心推荐：Flutter (通用首选)

对于 90% 的新启动 App 项目，Flutter 是当前版本的最优解。

• 性能强悍
  自带 Impeller 渲染引擎，不依赖系统组件，体验无限接近原生。无论是复杂的动画还是高性能列表，都能轻松驾驭。
• 效率极高
  Hot Reload (热重载) 让改代码像刷新网页一样快。一套代码覆盖 Android、iOS、Web 甚至桌面端，研发成本降低 40% 以上。
• AI 友好
  作为 Google 亲儿子，Cursor、Claude 等 AI 工具对 Dart/Flutter 的支持极为成熟，能自动生成高质量 UI 代码。

⚠️ 避坑提示
如果你的应用极度依赖原生比如有大量历史遗留的原生代码，或对包体积有苛刻要求 (<10MB)，需谨慎评估。

6.2 潜力观察：Kotlin Multiplatform (KMP)

极度依赖原生的最佳选择。

• 核心定位
  逻辑共享，UI 原生。
  它不强求 UI 统一，而是让 Android 和 iOS 共享数据层、网络层和业务逻辑代码。

• 适用场景

  • 已经在原生层面积累了大量的UI组件和功能模块，可以逐步把业务逻辑切换到KMP。
  • 应用强依赖系统底层能力 (蓝牙、NFC、深度硬件交互)，同时又希望保持跨平台的优势。
• 现状判断
  技术理念先进，但第三方生态仍在爬坡期。2026 谨慎全量 All-in。

6.3 谨慎评估需求：App + 小程序 ≠ 一套代码

一个产品有App和小程序不代表他们的业务逻辑是完全一致的，小程序在产品定位上不应该是App的简化版。

• 最佳实践：App和小程序承担不同的产品职责

  • App (Flutter/原生)
    负责沉浸式体验、复杂交互、高粘性留存 (如阅读、创作、社交)。
  • 小程序 (原生/Uni-app)
    负责营销裂变、即用即走、低成本获客 (如分享落地页、简单工具)。
• 决策依据
  只有当功能重叠度 > 80% 且交互极其简单 (如纯展示类新闻、简单电商) 时，才推荐使用 Uni-app/Taro 等方案同时生成 App 和小程序。

6.4 决策速查表

7. 总结与建议

写了这么多，老刘最后给你一个终极建议。

2026年跨平台开发，记住这三个关键词：务实、聚焦、长期主义。

7.1 务实

软件开发没有银弹。

Flutter性能好但包体积大，React Native动态性好但有桥接损耗，KMP接近原生但生态不成熟。

选择技术的核心是：在当前约束条件下，哪个方案的收益最大。

7.2 聚焦

没有项目需要超过2种跨平台框架同时使用。

同样也不推荐团队同时在多个不同的跨平台框架上投入时间和精力。

建议：选定一个主力技术栈，最多再备一个备选方案。

7.3 长期主义

真正决定项目生死的，是你选定技术栈之后做的那些事。

• 架构设计够不够清晰？
• 开发流程够不够规范？
• 代码规范够不够严格？
• 技术债务管理够不够及时？

选定技术栈不是终点，而是起点。

做好这些基础建设，才是项目能持续健康演进的根本。

否则，再好的技术栈也救不了你。

最后，希望这篇跨平台开发地图能帮你避开那些坑，找到最适合你的路。

如果看到这里的同学对客户端开发或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

覆盖90%开发场景的《Flutter开发手册》

中央音乐学院联合研究：视频自动配乐还卡点

论文标题: Video Echoed in Music: Semantic, Temporal, and Rhythmic Alignment for Video-to-Music Generation

作者团队: 中央音乐学院、北京大学、阿里巴巴等

发布时间: 2025年11月12日

🔗 Github地址: https://vem-paper.github.io/VeM-page/
🔗 Lab4AI链接: https://www.lab4ai.cn/paper/detail/reproductionPaper?utm_sour...

✨ 研究背景:

视频配乐要同时"贴"内容、跟段落、能卡点。但自动配乐常出现情绪不匹配、分镜节奏不同步、转场对不上鼓点，导致视听割裂。

✨ 研究内容:

论文提出VeM: 以潜空间音乐扩散模型为主干，把视频先做"分层解析"再作为条件输入生成过程。

✨ 具体包括:

• 分层视频解析: 同时提取全局语义/情绪、分镜级语义与时长结构、帧级转场时间点，把视频从"一个整体特征"变成可控的结构化条件。
• 分镜引导对齐: 在扩散网络中用分镜条件做交叉注意力，引导音乐跟随镜头段落推进，并通过位置/时长编码保持时间同步，使音乐的主题与段落变化更贴视频。
• 转场—节拍精细同步: 将转场序列与节拍信息对齐，构造节奏约束特征，再用适配器注入扩散过程，强化"转场落在节拍边界附近"的卡点效果。

DeepSeek提出mHC，改造何恺明残差连接

大模型实验室Lab4AI论文阅读

✔️研究背景

深度学习中，残差连接 是 ResNet、Transformer 等架构（含 LLM）的基础，其恒等映射特性保障了大规模训练的稳定性与效率。Hyper-Connections（HC）通过扩展残差流宽度、多样化连接模式提升模型性能，但因连接无约束，破坏了恒等映射特性，导致训练不稳定、扩展性受限，且存在显著内存访问与通信开销，这一问题限制了 HC 在大规模训练中的实际应用，形成研究缺口。

✔️研究目的

本文解决 HC 架构存在的训练不稳定性、扩展性差及系统开销大的核心问题，同时保留 HC 扩展残差连接带来的性能优势，提出一种兼顾稳定性、扩展性与效率的通用残差连接框架，支撑大规模深度学习模型（尤其是 LLM）的高效训练。

✔️核心贡献

提出 Manifold-Constrained Hyper-Connections（mHC）框架，通过将 HC 的残差映射投影到双随机矩阵流形（Birkhoff 多面体），恢复恒等映射特性，保障信号传播稳定性；
对输入 / 输出映射施加非负约束，避免信号抵消，同时通过核融合、选择性重计算、DualPipe 通信重叠等基础设施优化，降低系统开销；
实证验证 mHC 在大规模预训练中的有效性，为深度网络拓扑架构设计提供新视角，推动基础模型的演进。

✔️研究方法

• 1）核心方法论：采用 Sinkhorn-Knopp 算法将残差映射 H_res 熵投影到双随机矩阵流形，对 H_pre 和 H_post 用 Sigmoid 函数施加非负约束；
• 2）基础设施优化：基于 TileLang 实现混合精度核融合，通过选择性重计算降低内存占用，扩展 DualPipe 调度实现通信与计算重叠；
• 3）实验设计：在3B至27B参数的语言模型上进行预训练实验，对比基线、HC和mHC的稳定性、下游任务性能及缩放特性。

✔️研究结果

• 1）稳定性提升：mHC在27B模型训练中消除HC的损失突增现象，梯度范数保持稳定（对比HC的3000倍信号增益峰值，mHC最大增益仅1.6倍）。
• 2）性能优势：在推理、阅读理解、数学问题解决等任务上全面优于基线和 HC，27B 模型在 BBH 上较 HC 提升 2.1%；
• 3）扩展性与效率：支持模型规模与训练数据量的高效扩展，n=4 时仅增加 6.7% 时间开销，显著降低内存访问与通信成本。

爬虫代理IP是爬虫技术中很常用的一种方法，方便于隐藏爬虫的真实IP地址，防止被目标网站识别并封锁。可是，在实际应用中，爬虫代理IP可能会因为很多原因而失效。下面是一些很常见的让爬虫IP代理失效的因素：

一、代理服务器问题

代理服务器故障：

代理服务器可能因硬件故障、软件错误或网络问题而暂时或永久失效。

代理服务器负载过高：

当代理服务器处理的请求量超过其处理能力时，可能会导致请求处理延迟增加，甚至请求被拒绝。

代理服务器被封锁：

目标网站可能已经识别并封锁了某些代理服务器的IP地址，导致通过这些代理服务器发出的请求被直接拒绝。

二、网络环境问题

网络延迟与不稳定：

网络延迟或不稳定可能导致请求无法及时到达目标服务器，或响应无法及时返回给爬虫。

网络配置错误：

爬虫或代理服务器的网络配置错误可能导致连接问题，如错误的端口号、IP地址或路由设置。

三、目标网站策略

动态IP封锁：

目标网站可能采用动态IP封锁策略，根据请求的特征（如请求频率、请求头信息等）来识别并封锁代理IP。

验证码验证：

当目标网站检测到异常请求模式时，可能会要求用户通过验证码验证来确认身份，从而阻止爬虫继续访问。

用户行为分析：

目标网站可能通过用户行为分析（如点击模式、停留时间等）来识别爬虫，并采取相应的封锁措施。

四、爬虫自身问题

请求频率过高：

如果爬虫发送的请求频率过高，可能会触发目标网站的防爬虫机制，导致代理IP被封锁。

请求头信息不当：

如果爬虫在请求头中包含了与目标网站不兼容的信息（如错误的User-Agent、Referer等），可能会导致请求被拒绝。

爬虫策略不当：

爬虫的策略（如访问顺序、访问间隔等）如果设计不当，也可能导致代理IP被封锁。

五、其他因素

代理IP质量：

低质量的代理IP（如共享IP、频繁更换的IP等）可能更容易被封锁。

第三方服务限制：

如果爬虫使用了第三方提供的代理服务，这些服务可能有限制（如请求次数、请求速度等），超过限制可能导致代理失效。

爬虫代理IP失效可能由很多原因引起，为了防止这种情况，爬虫开发者需要密切关注代理服务器的状态、网络环境的变化、目标网站的策略调整以及爬虫自身的行为模式，并采取相应的措施来优化爬虫策略和增加代理IP的有效性。