编辑：倾倾

【新智元导读】这是一份迟到三年的行业复盘。牛津大学最新的实证研究撕开了那层遮羞布：2022年全球科技大裁员爆发时，ChatGPT甚至尚未发布。周期性缩编被伪装成技术性迭代，AI替资本背了三年的锅，直到今天真相才被彻底复位。

一场幻觉，竟然持续了三年！

2022年11月，ChatGPT横空出世，随后硅谷开启大裁员，程序员和写手哀鸿遍野。

所有人都觉得，因为AI来了，所以我们失业了。

然而，一项由牛津大学和基尔世界经济研究所团队发布的论文却告诉我们，我们恨错了人！

论文地址：
https://arxiv.org/abs/2601.02554

其实早在ChatGPT上线半年前，这些行业的需求已呈现断崖式下跌。

那时，OpenAI还在调GPT-3.5的参数，根本没有功夫抢你的工作。

既然如此，到底谁才是幕后真凶？又是谁让AI成了替罪羊？

一场持续3年的「集体幻觉」

如果真如传言中那样，2022年的岗位需求应该在11月之后断崖式下跌。

然而，数据显示，下跌其实早就开始了。

计算机、商务、金融等高AI暴露率的职业，其失业风险在2022上半年已远超餐饮与建筑业。

但这会儿，奥特曼还在为算力账单发愁，ChatGPT甚至没有出生。

所以，我们不能贸然将失业和AI划等号，就像你无法指控未出世的婴儿杀了人。

为了进一步验证以防误伤，研究团队开始了一场对照试验。

实验组是科技依赖型岗位。2022年上半年，随着「远程办公泡沫」破裂，LinkedIn数据显示远程职位申请竞争度飙升，但招聘需求却从2022年初的峰值开始滑坡。

对照组是非科技依赖型工作，如餐饮、护理等在同一时间不仅没有崩盘，反而因为「后疫情复苏」出现了严重的用工荒。

不同职业从的失业风险变化，颜色的深浅表示职业的暴露度。颜色越深，暴露度越高

如果说GPT的出现取代了人类的工作，那么最开始取代的也应该是低级脑力工作，高级技能岗位依旧保留。

但数据显示的结果是无差别的行业雪崩。不论你是初级码农还是资深架构师，只要身处科技与外包行业，均被无差别清洗。

这就说明，受害者是按照行业资金充裕度划定的，而不是「是否能被AI替代」。

所以，杀死工作的凶手，肯定不是当时的GPT-3.5，它只是经过，就成了替罪羊。

杀死你的不是算法，是周期

既然GPT只是替罪羊，那么，凶手到底是谁？

如果一定要指名道姓，那么凶手应当是美联储主席Jerome Powell，或者说，是那时的宏观周期。

让我们看向更早的时间点——2021年。

那是一个疯狂的年份，全球疫情导致物理隔绝，科技公司以为这种数字化繁荣将成为常态。

于是，巨头和独角兽们开启了一场史无前例的「抢人大战」，钱也慢慢变得不值钱。

只要你会写代码、会画图、甚至只要简历上沾点「数字化」，你就能拿到溢价50%的Offer。

转折点发生在2022年年初，美联储开启暴力加息周期，全球风险投资瞬间腰斩。

根据Crunchbase的统计数据，2022年第三季度的全球风投融资额仅为810亿美元，同比暴跌53%。

市场上流动的「抢人预算」在一夜之间蒸发了一半。

AI只是其中的原因之一，更多是因为初创公司「账上没钱了」，为了生存，只能裁员。

牛津大学的研究进一步证实了这一点。

如果将2022-2025年的「高科技职位招聘需求曲线」拿出来，就能发现，它与纳斯达克指数的走势惊人地重合，却与GPT-4等模型的发布时间点毫无相关性。

利率上行，纳指下挫，招聘冻结——这完全符合宏观经济学模型，与「技术奇点」无关。

我们必须承认，2020-2021年的抢人大战才是异常现象。

那时，因为无限量化宽松，各类科技公司疯狂囤积人才，许多程序员拿着高薪实际上在做着重复的工作。

2022年的惨烈裁员潮，本质上是市场在暴力纠错——从「泡沫逻辑」回归到「商业常识」，而不是技术性淘汰。

借刀杀人：一场蓄谋已久的「洗白」

如前文所述，裁员是宏观经济造成的，为什么所有公司都要把锅甩给AI？

答案很简单：AI是资本市场上最好用的「遮羞布」。

分析师们给这种现象起了一个专属名词——「AI冗余洗白」

假如你是一位纳斯达克上市公司的CEO。在这个资金寒冬里，你的业绩下滑，现金流紧张，必须要裁掉10%的员工来缩减开支。此时摆在你面前的有两份公关稿：

低情商：因为我们前两年盲目扩张、管理不善，导致现在没钱了，被迫裁员。

• 后果：股价暴跌，股东愤怒，董事会质疑你的能力，你可能比员工先卷铺盖走人。

高情商：我们要All in AI，所以要进行战略性组织重构，优化冗余人力，打造更高效的AI驱动型企业。

• 后果：股价大涨，分析师为你鼓掌，称赞你拥有「壮士断腕」的远见卓识。

如果你是CEO，你会选哪一个？答案不言自明。

来看看那些教科书级别的洗白案例：

Dropbox作为最早的「示范单位」，CEO Drew Houston在裁掉16%员工（500人）时，高调宣布：

AI计算时代终于到来了，我们的下一阶段增长需要不同的技能组合。

从物流巨头UPS裁员1.2万人，到各大科技公司如Amazon、Google的滚动式裁员，高管们在解释裁员理由时，「AI」一词的出现频率比「利润」还高。

多项行业调查显示，相当比例的高管承认，将裁员与AI挂钩是为了避免被市场视为「落伍者」。

老板们心里比谁都清楚，现阶段的AI根本干不了那一万名员工的活。

但在资本市场上，只要喊出AI的口号，裁员就不再是「衰退，而是进化。

所以，不是AI抢了你的工作，而是老板借着AI的名义，干掉了那些他早就想干掉、却一直找不到完美理由干掉的人。

从暂时失业到永久出局

既然是经济周期作祟，那是不是只要等到降息、等到经济复苏，属于我们的那个「黄金时代」就会回来？

遗憾的是，这才是本报告最残酷的真相。

经济学中的「疤痕效应」，精准描述了我们此刻的困境：当2024-2025年宏观经济终于开始解冻时，不同行业的命运走向了截然相反的两端。

随着美联储降息预期升温，非科技依赖型行业（如酒店、医疗、建筑）的需求曲线呈现「V型」或「U型」反弹，迅速回到了疫情前的水平。

科技职位信息在 2022 年初之前后翻了一倍以上，但此后已全部回撤，截至 2025 年 7 月 11 日，较疫情前水平低 36%。

然而，高AI暴露职位（文案、初级代码、翻译）的需求曲线却是绝望的「L型」——在经历了2022年的暴跌后，陷入结构性停滞，彻底与经济复苏脱钩。

这就解释了为什么你感觉「经济好像好了，但我的行业还没好」。

因为企业在裁员后发现：虽然当初是因为没钱才裁员，但现在有了AI辅助，似乎确实不再需要把这些人招回来了。

Upwork和Fiverr等前沿市场的数据印证了这种「K型分化」：

• 下行线（K之下）：纯粹的翻译、纯粹的SEO文章写作、纯粹的初级Java外包，需求量几乎归零。
• 上行线（K之上）：标有「AI-Assisted」（AI辅助）、「Prompt Engineering」（提示词优化）或者是能驾驭AI的高级全栈工程师，薪资和需求都在飙升。

如果说美联储是突发性杀手，那么AI就是慢性毒药。

它确保了那些因经济周期消失的岗位，永远不会再回来。它把周期性的「临时失业」，变成了结构性的「永久淘汰」。

2022年，老板因为穷开不起单；2026年，老板因为不需要，所以不开单。

我们耗费三年，将所有焦虑错投给了一个假想敌。

却忽略了在资本寒冬里，真正的生存法则从来没变过：技术只是筹码，谁掌握了资本的流向，谁才拥有定义的权力。

所以，别再问「AI何时会取代我」，这个问题已是过去式了。

你应该问的是：

当所有的借口都被揭穿之后，除了那个随时可以被量化的自己，你手里还有没有底牌？

背景介绍

随着HarmonyOS 的发展，很多开发者将鸿蒙作为重要开发平台，尤其是在华为激励计划的加持下，涌入大量开发者贡献了大量应用，将大量创意带个了鸿蒙生态。

但随着时间推移，许多开发者发现，鸿蒙的应用审核似乎异常“严格”，很多开发者上架提审时被卡在了《审核指南》3.5和3.7项：

• 3.5项的规则是：应用需具备实用价值，能为用户提供实质功能/服务，且需具备创意，不得为纯信息展示，包括但不限于单一图片、单一页面、单一影视剧集类、单一图书单行本类、单一非官方游戏攻略类等。应用不得是简单打包的网站页面或套用模板、内容聚合、罗列链接、广告推广等，或为手机系统自带的简易功能。
• 3.7项的规则是：请避免继续在已有较多类似应用的类别下进行开发，如敲木鱼、随机选择、计算器、手电筒、记事本、记账、天气、数字大小写转换、日历、指南针、智能遥控、镜子、助眠睡眠、证件照、色彩助手、手持弹幕、播放器、万能遥控器、外卖跑腿聚合平台、生鲜买菜服务聚合平台、计时类、Wi-Fi管理类、Wi-Fi搜索连接类、Wi-Fi检测提速类等类别的应用，除非您的应用能够提供独特、高质量的体验，为用户提供多样、优质的功能和服务，否则您的应用可能会被拒绝或移除。
  还有不少开发者反馈，被3.5或3.7规则拒审后，又增加了不少页面和功能还是被以同样的原因拒审，甚至有人再传只要被3.5或3.7基本死刑了，需要重新想创意开发了。小编正好之前被3.5拒审后面通过迭代成功上架打破传言，本文就通过复盘3.5后迭代的经历分享打破3.5魔咒的经验。
  

应用功能介绍

小编开发的应用叫”智能带办“，踩中了个人开发者最常开发的应用清单，是个清单类应用。创意来源于日常生活中自己的痛点，每次出差出远门或者从帝都回老家，都要拉一个单子把所有要带的东西都列出来，大部分情况带的东西都差不多，一般都记录在备忘录中，列清单的时候很耗费精力，想到AI能力越来越强大，可不可以让AI给生成？在AI工具中虽然可以生成清单，但是又没法做勾选等操作，融合操作和AI能力就想到做一个智能生成带办的应用，应用的亮点就是专注解决出行携带难题，通过AI智能生成场景清单，让你告别遗忘，轻松应对每一次出差、旅行、露营与日常外出。

智能带办，让你每一次出发，都底气十足。
告别“忘带焦虑”，从容开始每一段行程。

3.5拒审版本功能盘点

提审被拒绝的版本主要包含四个页面：Chat、历史、我的、详情。在Chat页面输入要办的事情自动生成要带物品清单，勾选物品确认后生成带办清单并自动跳转到详情页，页面效果如下：
Chat页面：

清单页面：

清单展开详情页：

详情页：

新迭代功能

在重新提审的版本对整个代码工程做了重构，UI也进行了优化，包含功能：
推荐：

清单页：

Chat页：

详情页：

碰一碰页：

语音输入：

对比拒审前和拒审后版本功能区别如下：
1、UI美化
2、增加了推荐功能
3、增加了HarmonyOS 系统碰一碰分享能力
4、增加了语音输入功能
5、Chat页输入框上方增加了推荐问题

复盘总结

通过对比被拒版本与最终上架版本，我们可以清晰地看到一个核心转变：从“一个不错的功能点子”进化为“一个完整、独特且有深度的产品”。这不仅是一次功能的叠加，更是对审核规则内涵的深刻理解与主动契合。下面，我将逐点拆解迭代背后的逻辑，还原打破“3.5魔咒”的真实路径。

1. 从“单薄的功能演示”到“完整的用户体验闭环”

   • 原版本痛点：应用流程始于Chat输入，终于清单生成与勾选。这更像是一个AI工具的“功能演示”，用户使用路径短，用完即走，缺乏留存价值和持续使用场景，恰好落入规则3.5所述“功能单薄”的范畴。

   • 迭代策略与效果：

     • 增加“推荐”页：这是本次迭代的“棋眼”。它不再是空白的起点，而是提供了“出差”、“露营”、“健身”等丰富的预设场景。这带来了三大好处：其一，直观证明了应用的“实用价值”和解决多种场景问题的能力，直接回应了审核对“实质功能”的要求；其二，降低了用户冷启动门槛，提升了易用性；其三，构建了内容厚度，让应用看起来像一个精心策划的工具集，而非一个简单的输入框。
     • 结果：应用从一个“AI清单生成器”变成了一个“出行准备助手”，用户体验形成了“浏览场景-选择/自定义-生成-管理”的完整闭环。

2. 从“通用AI套壳”到“彰显HarmonyOS独特性”

   • 原版本痛点：功能完全依赖AI接口，在任何平台均可实现，未能体现鸿蒙生态的独特优势。这容易让审核认为应用是“简单打包”或“套用模板”，缺乏不可替代性。

   • 迭代策略与效果：

     • 深度集成“碰一碰”能力：此功能是彰显“鸿蒙基因”的关键。它不再是简单的文本分享，而是通过系统能力实现了跨设备的无缝清单流转。这充分展示了开发者对HarmonyOS系统级能力的钻研与应用，证明了应用是为鸿蒙原生体验而设计，提供了其他平台难以复制的“独特、高质量的体验”（这也恰好回应了规则3.7的精神）。
     • 结果：应用的核心竞争力从“能生成清单”升级为“能在鸿蒙生态中优雅、便捷地生成和协同处理清单”，差异性豁然开朗。

3. 从“基础交互”到“丰富且人性化的交互维度”

   • 原版本痛点：交互方式仅有文字输入和点击勾选，较为单一。

   • 迭代策略与效果：

     • 增加“语音输入”：这不仅仅是增加一个功能，更是提升了应用的易用性、包容性和现代化程度。在出行准备等双手可能不便的场景下，语音输入尤为实用。它展现了开发者在打磨用户体验上的深度思考。
     • 增加“推荐问题”：在Chat页输入框上方添加推荐问题（如“周末露营带什么？”），极大地引导了用户，丰富了交互的启发性和探索性，让AI工具变得更“聪明”和友好。
     • 结果：应用提供了文字、语音、预设场景选择、碰一碰分享等多种交互路径，功能层次变得更加立体和丰满，彻底摆脱了“单一页面”、“简单操作”的观感。

4. UI美化：不仅是“面子”，更是“里子”的体现

   • UI重构与美化：这常常被开发者视为“表面功夫”，但在审核视角中，精致的UI是应用“高质量”和“完成度”最直观的外在表现。一个粗糙的界面会强化“敷衍”、“模板化”的印象；而一个设计精良、符合鸿蒙设计规范的界面，则传递出开发者认真打磨产品、尊重用户的积极信号。本次的UI优化，与功能深化同步，共同塑造了一款成熟应用的质感。

核心经验提炼：给开发者的避坑指南

1. 超越功能点，思考用户旅程：不要只满足于实现核心功能。问自己：用户从哪里来（入口引导）？核心功能之后还能做什么（场景延伸/分享/管理）？如何让他下次还想用（留存价值）？构建闭环。
2. 拥抱系统能力，打造生态差异化：在鸿蒙上开发，务必主动探索并集成Kit能力（如碰一碰、原子化服务、卡片等）。这是证明你为鸿蒙而来、并能为鸿蒙生态增色的最强证据。
3. 叠加交互维度，展现思考深度：在主流程上，思考是否能提供更便捷（如语音）、更引导（如推荐）、更趣味（如动效）的交互方式。丰富的交互是“功能深度”的体现。
4. 用视觉品质为产品背书：将UI/UX视为产品不可或缺的一部分。高质量的设计能无形中提升审核对应用整体质量的评价。

结论

“智能带办”通过审核的经历证明，规则3.5并非“死刑判决”，而是一道清晰的“产品成熟度”分水岭。被拒不是创意的终结，而是产品打磨的开始。关键在于，开发者必须跳出“我明明有这个功能”的委屈心态，转而以审核规则为镜，以更高标准审视自己的应用：它是否构成了完整服务？是否具备生态特色？交互是否丰满精致？当你的应用能从这些维度展现出独特价值和用心之处时，“3.5魔咒”自然不攻自破。

标题：从“人巡”到“智巡”，人力减 60%：TDengine 助力桂冠电力实现 AI 智能巡检

logo：

小T导读：为推进 “数智运营” 转型，广西桂冠电力携手涛思数据，采用 TDengine 时序数据库构建智能巡点检系统，融合 AI 与智能终端打造“终端—边缘—云端”协同架构，破解水电巡检效率低、安全风险高等难题。TDengine 在其数据湖中承担 OT 数据核心存储角色，通过“一个设备一张表”“超级表”等设计简化架构，凭借内置时序计算与订阅机制显著提升效率。系统投运后，单机机组增效 2–5%，年增发电量约 3 亿 kW·h，监盘工作量减少超 60%，助力桂冠电力迈向 AI 驱动的数智运营新阶段。

业务背景：电力巡检 + AI

在水电行业从“传统运维”迈向“数智运营”的关键阶段，桂冠电力率先打破依赖人工的巡点检模式，携手涛思数据（TDengine）创新研发水电站智能巡点检系统。该系统融合无人机、机器人等智能终端与 AI 技术，构建“终端—边缘—云端”协同架构，实现巡点检作业覆盖率显著提升、故障响应更迅速、人力成本大幅降低，有效破解了水电行业巡检效率低、安全风险高的长期难题。

在 AI 的赋能下，我们实现了智能巡盘、智能告警、智能预警、智能处置等多项 AI 功能，把巡检工作从“人工主导”升级为“机器主导”的自动化监控模式。借助高级逻辑判断与辅助处置机制，系统能将设备事故处置由被动应对转化为主动预警，提前识别潜在风险并同步提供操作指导与优化方案，既显著提升机组运行的安全性与经济性，又大幅减轻运行人员的监屏劳动强度和心理压力。

同时系统的实施使得发电效率也得到显著提升：单台机组的增效约为 2-5%。主要水电机组应用后，每年可增加发电量约 3 亿 kW.h。系统的智能监盘功能实现了适用于少人、无人监盘的模式，减少了监盘 60% 以上的工作量，大幅减轻了运行人员的工作强度，进一步提高了监盘的准确性和响应速度。

本文将与大家分享 TDengine TSDB 在我们数据湖建设中发挥的关键作用。

业务上的具体应用实践

简化数据湖的存储架构

在数据湖当中，TDengine TSDB 作为数据湖的贴源层，支撑了全部 OT 数据的存储。如下表所示，OT 数据与 IT 数据之间有着明显的区别：

为在 OT 与 IT 数据上实现最佳性能，我们分别采用某关系型数据库与涛思数据 TDengine TSDB 作为 IT 层与 OT 层的存储组件，构建分层存储体系。架构图如下图所示：

在当前架构当中，TDengine TSDB 所具有的特性，使得海量 OT 数据的存储更加便捷：

• “一个设备一张表”的设计，非常直观地映射到 IoT 中各类设备的采集值模型；
• 超级表的设计，使得一次查询多个测点变得非常简单；

• 分布式的架构设计，可以支持横向扩展和纵向扩展，在同一层无需多集群；

  • 虚拟分区策略，可以充分利用每一个节点的资源；
  • 动态调整数据分布，可以避免单点资源瓶颈带来的业务阻塞；
• 特色的时序计算函数，使得大部分业务计算可以直接获取，同一区域内无需分层存储。

业务建模的约束设计

基于“一个设备对应一个子表”的建模原则，我们对设备及其点号的数据进行建模与存储。在建模过程中，需要重点解决以下几个问题：

• 设备维度的设计：确定用于描述设备的关键维度；
• 唯一性的设计：明确用于唯一标识设备的字段，即设备表的 Primary Key；
• 多维选择唯一性的设计：确定可用于唯一检索设备的多个字段组合，即设备表的 Candidate Key。

TDengine 的超级表具备标签列特性，可用于实现设备表的存储。各标签列相互独立，类似于关系型数据库中的字段。由于超级表不具备 Primary Key 和 Unique Index 机制，因此在实际应用中需要通过约定来实现约束：

• db\_name：作为业务分割单元，不同 db\_name 的服务于不同业务，保证同一业务内的 tbname 不重复，避免写入错误数据；
• tbname：作为单个系统的唯一性约束，用于单个业务范围内的真正唯一 id；
• tag::point\_code：作为测点名字记录，用于单个业务领域内的唯一性标记；
• tag::mtype/station\_name 等标签列：作为设备的属性进行描述，联合起来作为候选主键。

以单列模型的测点 pointdata 为例，表结构如下所示：

CREATE STABLE `all_station_st` (
`data_time` TIMESTAMP, 
`point_value` DOUBLE
) TAGS (
`point_code` VARCHAR(20), 
`addr` INT, 
`mtype` VARCHAR(20), 
`station_name` NCHAR(30), 
`description` NCHAR(64), 
`kks` VARCHAR(100), 
`measure_code` VARCHAR(60), 
`original_one` VARCHAR(40), 
`original_two` VARCHAR(64), 
`idx` NCHAR(32), 
`status` TINYINT
)  

由于标签列之间缺少约束功能（如索引、主键），因此需要从业务上做验证和校验，才能保证最终唯一。期望 TDengine TSDB 后续能在这一个维度进行进一步开发，降低业务开发的复杂度。

内置时序计算优化业务效能

在我们的业务系统中，TDengine 以其卓越的性能与强大的时序计算能力，大幅简化了业务开发工作。

对于业务逻辑和部分智能算法而言，常常需要对时间戳进行对齐，并在指定频率下获取测量值，这就要求我们基于原始数据进行计算。传统做法有两种：

• 提前计算：通过定时计算或者流式计算，提前把降采样的结果计算完存放起来；
• 实时计算：通过查询原始数据，实时计算后返回给应用。

提前计算的优势在于能让应用以最快速度获取结果，但缺点是需要维护一整套定时调度机制，涉及任务调度、异常处理和补数等运维工作，复杂度较高。

实时计算能够保证每次计算结果都是最新的计算逻辑，缺点是计算耗时有可能太大，计算内存消耗过大。

而 TDengine 的特色时序计算，就很好地避免了这些问题。即使是在微服务 + 低代码的时代，TDengine 带来的业务简化依然具有重要价值。以获取测点的日平均值进行绘制为例：

提前计算的实现通常需要部署独立的 Java 程序并持续监控其运行状态。编写计算逻辑本身并不复杂，真正的工作量在于多出一套需要维护的应用，同时还要应对算法更新、数据更新带来的重算问题，使整个过程显得十分笨重。

实时计算是指在业务产生数据需求时，直接查询数据库中的原始数据并即时计算结果。在我们的场景中，这类操作往往会演变为 CPU + MEM + Network 的高负载任务——在 queryRawData 过程中，需要占用大量内存来缓存 TSDB 返回的原始数据，消耗 CPU 进行数据解析，同时占用大量网络带宽完成数据传输。

而使用 TDengine 内置的 interval 库函数进行计算，则很轻便的完成了这个计算。interval 库函数是一个时间窗口函数，可分为：滑动时间窗口、翻转时间窗口。在我们的业务当中，大多数情况下会采用等时间窗口的平均值计算方式。例如：

taos > select _wstart, avg(`point_value`) from db.$point_code where _c0 >= ‘2025-01-01’ and _c0 < ‘2025-02-01’ interval(1d);

整个集群内存几乎没波动。做一个简单规模的查询对比：

# 在 1w 测点 10s 采样间隔，统计 7 天内的日平均值

# 使用 TDengine 的计算，只需要 1.14 秒
taos> select _wstart, count(*), avg(`current`), avg(`voltage`), avg(`phase`), tbname from test.meters partition by tbname interval(1d);
Query OK, 70000 row(s) in set (1.140877s)

# 对于提前计算，每日的计算，只是查询 1 天的数据就占用 15.49 秒：
taos> select * from test.meters where _c0 >= '2025-01-01' and _c0 < '2025-01-02' >> /dev/null;
Query OK, 14400000 row(s) in set (15.496163s)

# 对于实时计算，只是查询原始数据，就占用了 106.85 秒
taos> select * from test.meters >> /dev/null;
Query OK, 100800000 row(s) in set (106.852480s)

通过上述的数据可以得到：

从上述数据可以看出，实时计算方案在性能上明显不及 TDengine 内置计算，因此在实际业务中几乎不会被采用。提前计算方案在应用次数超过 16 次后能够带来正向收益（实际业务中查看次数会很容易超过这个数量）。因此，我们在系统中同时采用了提前计算与内置计算的组合方案。其中，内置计算帮助我们有效减少了网络传输、内存占用、CPU 计算以及业务研发等多方面的开销。

订阅替代数据分发

作为企业级数据湖，我们既需要满足桂冠电力内部的数据共享，也要支撑与外部系统之间的数据分发。借助 TDengine 的订阅机制与 taosX 企业级同步组件，这一需求得到了高效而可靠的解决。

对于分发内容的类型，我们主要有 2 大类：

• 针对设备订阅，订阅设备的时序数据

# 选择部分设备进行同步，只订阅时序数据
create topic topic_fzd as select tbname,data_time,point_value from pointdata.all_station_st where status = 1 and idx in ('辐射','辐照度') ;

• 针对业务进行订阅，需要订阅设备的元数据和时序数据

# 选择未知设备进行同步，并且同步元数据变动
create topic topic_longtan with meta as stable pointdata.all_station_st where status = 1 and station_name = 'DJK_LT_90000208'  

同步方式上，我们分为两大类：

• 目的地是 TDengine，应用使用 taosX 进行订阅和写入，保证稳定性。
• 目的地未知，应用由需求方使用官方 driver 编写，订阅对应的 topic，自行安排应用。

通过以上的 topic 方式和应用方式，我们解决了数据湖上的数据分发需求。与过往的其他大数据组件相比，属实是非常轻便了。

大规模的运维经验

在正式投产之后，我们经历过 3.0.3、3.3.4 和 3.3.6 多个大版本。测点规模从百万走向千万，是一个 10 倍增长的运维过程。在这里分享几个 TDengine TSDB 大规模集群运维的经验。

容量规划

基于桂冠的业务场景进行估算，我们最终使用了 64c256g * 3 的虚拟机运行 TDengine TSDB。按照双副本（企业版特性），每个 vgroup 处理 2w 的测点的经验数据，我们预估 64c*3 可以处理：

64 vnode/节点 * 3 节点 / 2 副本 * 20,000 测点/vgroup = 192,000 测点

实际过程中从刚上线的性能宽裕，逐步发展到后来的性能拮据。我们发现 20,000 测点/vgroup 这个经验数值，会随着业务应用的开发出现下滑。其核心原因在于业务开发的增多，会带来显著的 CPU 资源消耗。因此我们把预估方式调整为：

Unit = 20,000 / (insert\_ratio + query\_ratio) 测点/vgroup

其中 insert_ratio 代表写入强度，query_ratio 代表查询强度。可以初步分成几种情况：

• insert\_ratio

  • 0.5：代表数据频率已知，顺序写入，日常没有数据补写。
  • 1.0：代表数据频率已知，大部分时候顺序写入，存在常规的数据补写、部分乱序写入
  • 2.0：代表数据频率未知，大部分时候顺序写入，存在常规的数据补写、乱序写入

• query\_ratio

  • 0.5：代表常规有监控类查询（last/last\_row），短期时间区间查询（7天内）。
  • 1.0：代表常规有监控类查询（last/last\_row），短期时间区间查询（7天内），伴随定期任务查询。
  • 2.0：代表常规有监控类查询（last/last\_row），短期时间区间查询（7天内），伴随定期任务查询，同时提供历史数据查询。

这部分经验分别对应：单个物联网项目、综合物联网平台和集团数据湖平台。

写在最后

在 TDengine TSDB 的多年应用过程中，桂冠电力团队与涛思数据团队共同积累了丰富的大规模运维经验，并将实践成果转化为补丁与功能回馈社区。同时桂冠也见证着 TDengine 从一个时序数据库，逐步走向一个成熟的时序存算平台。在未来的日子里，相信 TDengine 能够成为物联网的一个标准全栈解决方案，为我们的电力业务进一步释放业务价值。

关于广西桂冠

广西桂冠电力股份有限公司是中国大唐集团有限公司的二级企业，主要经营水电、火电、风电及其他清洁能源的开发及运营，电站检修、技术咨询业务，兼营有色金属加工、金融服务等业务。公司拥有广西龙滩、岩滩、平班等共 41 座水电站、1 座火电厂和广西、贵州、山东烟台 9 个风电场，并网范围覆盖国家电网和南方电网的多个区域，资产分布于广西、四川、贵州等数个省市自治区，是一个集多能源、多网源、跨地域为一体的大型综合发电企业。

作者：桂冠电力

站在咖啡馆的柜台前，项目经理李薇用手机轻点几下，就重新分配了因航班延误而受影响的三个任务。这种随时随地的管理能力，如今正通过移动端好用的管理工具成为现实。

在移动办公成为常态的今天，工作场所已从固定的办公桌延伸至通勤路上、客户会议室甚至家庭客厅。据统计，超过68%的职场人需要在下班后处理工作事务，而其中近60%的核心协作通过手机完成。

但屏幕尺寸、网络环境和交互方式的根本性改变，也给团队管理带来了前所未有的挑战。

01 移动办公的挑战：为何传统管理工具力不从心？

移动办公的核心特征是碎片化与场景化。工作被切割成更短的时间块，穿插在差旅途中等候、会议间隙甚至家庭生活中。这种模式下，传统为桌面端设计的管理工具暴露出了明显短板。

信息同步延迟是最常见的痛点。团队成员更新了项目状态，但其他人手机上的通知可能迟迟未到，或淹没在混杂的社交信息中。在需要快速决策时，这种延迟可能导致机会错失。

其次，功能阉割与操作繁琐严重阻碍效率。许多工具的移动版只是桌面版的简化移植，关键功能缺失，操作路径深且不符合触屏逻辑。在小屏幕上创建复杂任务、查看甘特图或进行多文件比对，常常令人沮丧。

更深层的是协作壁垒。移动环境下，沟通与管理往往脱节——重要的讨论散落在微信、钉钉等即时通讯工具中，却无法与任务状态自动同步，导致信息孤岛，执行过程不透明，管理者难以掌握真实进度。

02 核心价值：移动端专用管理工具如何破局？

移动端管理工具的核心价值，在于它不是对桌面工具的补充，而是为移动场景原生设计的新工作界面。它重新定义了信息如何被获取、任务如何被处理以及协作如何发生。

其首要优势是极致的实时性与可达性。优秀的移动工具通过优化的推送机制和后台同步，确保信息秒级触达。即使网络短暂中断，也能在本地记录操作，待网络恢复后自动同步，保证工作流不间断。

其次是情境智能与操作简化。工具能根据用户所处场景（如时间、地点、正在处理的任务）智能推荐下一步行动。例如，在接近客户公司时自动弹出相关项目资料；通过语音快速创建任务、用拍照一键上传并关联至工作项，极大降低了移动输入成本。

最终，它实现了沟通与执行的融合。在任务卡片中直接讨论，评论自动转为待办事项，关键对话一键转为任务指派。这让协作上下文完整保存，决策过程可追溯，真正做到了“讨论即执行，执行即记录”。

03 实战解析：主流移动端管理工具深度评测

理解价值后，我们来剖析几款真正为移动场景深度优化、在手机和平板上拥有卓越体验的管理工具。

微软 To Do 是跨平台轻量级任务管理的典范。其移动端与Office 365生态深度绑定，支持邮件星标自动同步，适合个人事务与轻量协作。

滴答清单 集日历、习惯打卡、番茄钟于一体，移动端自然语义识别强大，输入“明天三点开会”即可智能创建任务。

板栗看板 与微信、钉钉深度融合，支持将群聊对话转为卡片，其移动端看板视图经专门优化，交互流畅。

Things 3 是苹果生态中设计美学与生产力的标杆，移动端交互为触控全新设计，能与系统深度联动构建自动化工作流。

04 未来展望：AI与移动管理工具的融合趋势

移动设备天生的便携性与丰富的传感器，使其成为人工智能技术落地的绝佳平台。未来，移动端管理工具将变得更加主动、情境感知和预见性。

情境感知的自动辅助将成为标配。工具将综合GPS定位、日历日程、手机使用状态，智能判断用户当前是否可处理深度任务。例如，在检测到用户正在通勤时，自动推送适合短时处理的审批或阅读任务。

语音与自然语言成为主要交互界面。未来的移动管理将更多地通过“语音创建任务”、“对话式询问项目进度”来完成。AI不仅能理解指令，还能追问模糊细节，一次性生成结构完整的任务项，彻底解放双手。

预测性风险干预是更高阶的应用。AI通过分析任务推进速度、协作互动频率、历史延期数据等，在移动端提前预警项目风险。例如，向项目经理推送提示：“A任务关联的3个子任务进度均落后，整体延期风险高达70%，建议今天下午召集核心成员进行5分钟快速同步。”

05 选择指南：四步找到你的移动管理利器

面对众多选择，你可以遵循以下路径，找到最适合团队的那一款：

1. 核心场景匹配测试：不要被功能列表迷惑。邀请团队成员，用最常发生的2-3个移动办公场景（如“客户突然来电要求修改方案并同步给团队”）来实测候选工具。观察完成整个流程需要多少步操作，是否顺畅。
2. 评估离线与弱网能力：主动关闭Wi-Fi和蜂窝数据，测试能否查看最近的任务列表、能否编辑任务内容。恢复网络后，观察编辑内容是否自动同步、有无冲突提示。这是移动工具可靠性的试金石。
3. 审视通知系统：仔细研究工具的通知定制粒度。能否按项目、任务类型、紧急程度设置不同的提醒方式和频率？能否在移动端设置“免打扰时段”？一个既及时又不构成骚扰的通知系统至关重要。
4. 考量生态集成成本：检查工具是否与你团队已离不开的日常应用（如邮箱、网盘、通讯软件、签批系统）良好集成。在移动端，每一次强制性的应用切换，都意味着注意力的打断和效率的损耗。

06 技术实践：移动任务管理器的简易代码实现

以下是一个模拟移动端智能任务管理核心逻辑的简化代码示例，展示了如何根据场景生成任务并进行智能同步：

from datetime import datetime, timedelta

class MobileTaskManager:
    """移动端智能任务管理器核心逻辑演示"""
    
    def create_task_from_context(self, context: str, location: str = None) -> dict:
        """根据场景和位置创建智能任务"""
        # 智能优先级判断
        priority = "中"
        if "紧急" in context or "尽快" in context:
            priority = "高"
        elif "整理" in context or "备份" in context:
            priority = "低"
        
        # 智能截止时间建议
        due_hours = {"高": 4, "中": 24, "低": 72}.get(priority, 24)
        due_date = (datetime.now() + timedelta(hours=due_hours)).strftime("%m-%d %H:%M")
        
        task = {
            "id": f"task_{datetime.now().strftime('%H%M%S')}",
            "title": f"[移动端]{context[:15]}..." if len(context) > 15 else context,
            "priority": priority,
            "due": due_date,
            "location": location,
            "created": datetime.now().strftime("%H:%M"),
            "status": "待处理"
        }
        
        print(f"✓ 创建任务: {task['title']}")
        print(f"  优先级:{priority} | 截止:{due_date}" + (f" | 位置:{location}" if location else ""))
        return task
    
    def sync_offline_tasks(self, task_list: list) -> dict:
        """模拟离线任务同步"""
        print(f"\n📡 同步中... 发现{len(task_list)}个待同步任务")
        print("─" * 30)
        
        for i, task in enumerate(task_list, 1):
            print(f"{i}. {task['title']:20} | 状态: {task['status']}")
        
        return {
            "success": True,
            "synced": len(task_list),
            "time": datetime.now().strftime("%H:%M:%S")
        }

# 演示移动端任务管理场景
print("🚀 移动端任务管理器演示\n")

manager = MobileTaskManager()

# 场景1：紧急任务创建
print("场景1：客户现场紧急任务")
manager.create_task_from_context("紧急修复客户演示系统BUG", "客户办公室")

# 场景2：常规任务创建
print("\n场景2：常规跟进任务")
manager.create_task_from_context("整理项目会议纪要并发送")

# 场景3：同步演示
print("\n场景3：网络恢复后同步")
tasks = [
    {"title": "修复演示BUG", "status": "进行中"},
    {"title": "整理会议纪要", "status": "待处理"},
    {"title": "提交周报", "status": "已完成"}
]

sync_result = manager.sync_offline_tasks(tasks)
print(f"\n✅ 同步完成 ({sync_result['time']})")
print(f"   成功同步 {sync_result['synced']} 个任务状态")

移动端管理工具的进化，其本质是将管理的主动权交还给身处不同时空的人。在上海的地铁里审阅设计稿，在西安的出差途中批准预算，在广州的茶餐厅里同步项目节点——工作的节奏不再由地点决定，而是由想法和决策驱动。

当工具真正理解了移动的本质是“人的流动”，而不仅是“桌面的缩小”，高效协作便不再受限于任何物理边界。选择正确的移动端管理工具，不仅是选择一个软件，更是为你的团队选择一种更自由、更敏锐、更连贯的工作方式。

在这个被大模型和智能体（Agent）疯狂重塑的年份，我们不得不承认一个残酷的事实：传统的边缘计算叙事，正在失效。

当算力从中心有序下沉，当 AI Agent 开始接管终端决策，边缘计算不再只是网络的延伸，而正在成为智能的前沿阵地。谁还停留在旧叙事中，谁又真正拿到了通往下一个十年的船票，答案正在迅速分化。

基于这样的行业背景，边缘计算社区正式启动「2026 中国边缘计算企业 20 强」榜单评选。这不仅是一份年度名单，更是一场在技术代际更迭下的行业校准。

榜单背景

自 2019 年起，边缘计算社区已连续六年发布「中国边缘计算企业 20 强」榜单，累计吸引 800 余家产业链企业参与评选，覆盖边缘云、边缘一体机、边缘 AI、5G MEC 等核心领域。

过去六年中，该榜单全网累计传播曝光量突破 3500 万次（清博大数据舆情统计），不仅持续为行业树立技术与商业标杆，也逐步成为企业扩大市场影响力、获取生态与产业资源的重要入口。

当边缘计算进入 “边缘 × AI × 智能体” 的新阶段，我们认为：这份榜单，也必须随技术代际一起升级。

从“连接”到“智算”

回望过去两年，边缘计算的演进速度远超预期。

如果说 2024 年行业仍在聚焦边缘盒子、网关与连接能力，那么到了 2025 年底，只谈连接、不谈推理的产品，已经很难再获得市场认可。

大模型正在以前所未有的速度“瘦身”并下沉至边缘侧：从手机、PC，到工业控制器与现场设备，越来越多的终端被要求具备本地推理与自主决策能力。

边缘计算正在从“管道”，演进为 AI 的“触角”。当然，这并不意味着所有传统边缘计算企业都会被淘汰。但可以确定的是：

以“连接能力”为核心竞争力的边缘产品，正在快速失去议价权。

智能体爆发，边缘侧的“寒武纪时刻”

2026 年，或将成为边缘智能体（Edge Agents）走向规模化应用的起点。所谓边缘智能体，并非简单的模型端侧部署，而是指在受限算力、弱网络甚至离线条件下，仍具备自主感知、规划与执行能力的边缘决策单元。

未来的边缘计算竞争，将不再取决于硬件参数，而在于：

• 谁能让大模型在边缘侧稳定运行
• 谁能在毫秒级延迟内完成复杂决策
• 谁能在算力、算法与网络之间实现系统级优化

这不仅是技术升级，更是一轮生态重构。

寻找 2026 年的“边缘脊梁”

正是在这样的行业变局之下，我们启动「2026 中国边缘计算企业 20 强」评选。

我们要寻找的，不是停留在历史成绩上的老牌玩家，也不是只会包装概念的“PPT 公司”，而是那些真正进入 “边缘 × AI”深水区 的企业：

• 成功将 7B、14B 等模型量化并部署到边缘端的技术实践者
• 用边缘智能体解决真实、碎片化场景问题的实干团队
• 在算力、算法与网络协同中实现突破的破局者

他们，才是真正决定边缘计算下一个十年走向的力量。

评选标准与参选要求

参选条件

• 在边缘计算领域具备成熟的技术解决方案与商业化落地案例；
• 拥有核心技术壁垒（如边缘芯片、算法优化、异构计算等）或独特生态资源；

• 2026 年新增重点：展示边缘计算与 AI 大模型的融合实践（如优化 AI 推理效率、隐私计算、联邦学习等），以及算力。
  

  评分机制

• 线上投票（30%）：公众通过官方渠道为心仪企业投票；

• 专家评审（70%）：从以下四大维度综合打分：

  • 技术领先性（35%）
  • 商业落地（30%）
  • 边缘×AI创新（25%）
  • 生态贡献（10%）

上榜权益

• 品牌升维：通过头部合作伙伴渠道全域曝光，覆盖 10 万+ 开发者社区；
• 商机裂变：优先对接甲方订单资源，2024 年某上榜企业通过生态合作斩获 800 万项目订单；
• 权威认证：榜单企业客户咨询量平均提升 120%（历史数据）；
• 生态赋能：优先加入“边缘计算产业图谱”。

特别提醒

独行者快，众行者远：在 AI 巨头定义规则的战场上，边缘计算企业唯有被看见，才有机会被选择。技术不应被埋没，真正的能力值得被记录。边缘计算的下一个十年，不属于参数最多的人，而属于最懂场景、最懂约束、也最懂 AI 如何落地的人。

边缘计算社区
2026年1月21日