作为一名在技术圈摸爬滚打二十年的老兵，我最近在面试和团队管理中发现了一个有趣的现象：技术的门槛正在崩塌，但职业的护城河却在变深。 现在的职场存在一种普遍的错觉：很多人觉得注册了 ChatGPT、DeepSeek，学会了几句“提示词（Prompt）”，就算是拥抱 AI 了。但在我看来，这只是停留在了“玩具阶段”。真正且深刻的变革正在水面之下发生——我们正处于从“人机对话”向“智能体协作（Agentic Workflow）”转型的关键节点。 2026 年的职场，不会淘汰那些不懂复杂代码的人，但会淘汰那些缺乏“AI 编排力”的人。对于非技术背景的专业人士来说，你们不需要成为程序员，但必须成为自己工作流的“系统架构师”。 以下是我基于行业趋势，为致力于构建核心竞争力的专业人士梳理的一份转型路线图。 -—————————————————- 一、 认知重塑：从“T型”人才向“Π型”人才进化 过去我们推崇“T型人才”（一专多能），但在 AI 时代，这个模型正在失效。 为什么？因为 AI 最擅长的就是“广度”。它可以瞬间填补你原本引以为傲的那个“横向”知识面。如果你的核心竞争力仅仅是“什么都懂一点”， ...

2026年，“十五五”开局，国家数据局将今年定为“数据要素价值释放年”，越来越多的人开始谈论可信数据空间（Trusted Data Space, TDS），将其视为继关系型数据库、湖仓一体之后，数据组织范式的第三次革命。我认同这个判断，它不像是一种单纯的技术升级，更像是在重塑数据流通的生产关系。 一、范式迁移：从“孤岛”到可流动的“活性单元”要理解这场革命，不妨回顾一下历史。过去的数据，像图书馆里的书，编好目放在固定的书架上（关系型数据库），应用必须自己来“借阅”。这造成了大量的“数据孤岛”。 后来，我们建起了超级仓库（湖仓一体/云存储），把所有数据都集中存起来。虽然计算方便了，但数据必须物理搬迁，权属和安全成了新麻烦，本质上只是把“孤岛”集中成了“数据大陆”，流动性问题没解决。 现在的思路变了。在可信数据空间的范式中，数据不再是被动存储的“货物”，而是变成了分布在各处、权属与安全规则内嵌的 “活性单元” 。它可以在不离开自家“保险柜”的前提下，被安全、可信地组合与使用。这从根本上动摇了“数据必须集中才能使用”的旧逻辑，瞄准的正是“不敢供、不可信、流不动”的行业痛点。 二、2 ...

好久没写文章，上一篇漫谈还是3年前写的关于产品管理的认知。在大型创业企业里工作了4年有余，各方面都有不少实践，有弯路也有成绩，便想将一点浅薄的见解记录下来，也算是复盘与反思。这篇文章说一下研发项目管理方面，后续还有交付项目管理、技术管理、科技创新管理、政府课题管理等诸多思考，待有时间再写出来，真的能成为一个系列了。是不是可以出个专栏？ 研发项目管理还是得理清一下定位。研发项目管理有两个层面，一个是项目经理的层面，一个是公司的层面。项目经理关注的是如何在约束内将项目目标达成。这不是本文的重点，在这里我想聊的是公司层面的研发项目管理。 关于研发项目所有项目都是组织资源的一种形式。企业将研发资源采用项目的形式组织起来的目的是什么呢？想明白这个问题，就能想明白企业到底要不要开展研发项目管理（因为管理总会带来成本）以及侧重点是什么。因此同样是研发项目管理，各个企业的管理模式也会有所不同，这就是因为目的不同，生搬硬套，反而适得其反。 一般来说，研发项目存在的目的主要有： 上级或者外部的管理要求。比如为了做资本化、为了后续审计、为了申报企业资质或者财税政策等。 相对准确的管理投产。通过设立项 ...

微服务架构大成以来，业界持续有声音在质疑微服务架构的弊病，时不时的有曝出某某大厂回归了单体架构。今年（即2023年）5月份，又曝出亚马逊一团队抛弃微服务架构回归单体架构后，成本降低90%，引发业内热议。正于此时Spring Modulith更新到了0.6版本。这个孵化于Moduliths项目并且现已纳入Spring Boot 体系的框架的愿景是要将单体架构的框架水平拉升到微服务架构Spring Cloud的层次，让架构师们在做架构选择的时候，能基于真正需求去考量，而不是基于框架先进性。 抛开微服务的优点先不说，我所在的公司也在成本上苦微服务架构久矣……因此，我抽空通读了官方的简介、文档和相关示例代码，以期能盼来解药，结果只能说还差点意思……大家怀念单体架构主要是因为单体架构开发方便，部署方便，然后性能高，但是带来的缺点是事实上的紧耦合，无论再好的规范和设计，也都会随着成员的增多、时间的流逝、紧急需求的响应，导致代码纠缠不清，一团乱麻；而微服务架构带来的是松耦合，独立发布，水平扩展，但是会导致部署架构复杂，基础设施成本、运维成本飙升……Spring Modulith的解法是用单体架构 ...

在一个企业组织里，科技部门不免需要回答科技投入到底产出了什么，科技投产效能是高是低，要回答这个问题不是一个简单的事情。特别是当CEO有这个疑问的时候，通常意味着他对科技的投入产出已经产生了怀疑，定性的产出描述，“形成了XXXX技术能力，提升了XXXX技术水平”，都无法消除他的怀疑。 在一家科技企业里，科技投入通常是在做三方面工作：（一）科技产品的研发；（二）核心技术能力的建设；（三）基础的IT支撑。 科技产品的研发科技产品研发投入带来的直接产出是可供销售的软件系统或者支撑业务运营的软件平台。这两部分可直接与市场收入挂钩。但当市场销售不佳，收入较少时，是否就意味着科技产品的研发产出较差呢？我觉得在投资人的角度来看，这个结论是正确的，但是在公司治理中去看却不竟然。因为只要研发部门按照产品设计部门的设计和时点完成了产品研发，那就代表着科技部门履行了职责，后续市场表现不佳，通常是产品设计或销售环节出了问题。因此我觉得衡量科技产品的研发产出应复合收入和需求实现情况来评价。收入要考虑滞后性，将后续一定时段内的收入框算进来。产品研发效能 = （研发相关收入+需求实现率 X 系数）&# ...

公司网络不支持IPv6，Drive Client使用6690 TCP端口，没有IPv4地址，通过QC连接速度太慢。刚好有台有公网IPv4的云主机，简单的使用NPS实现了TCP隧道转发，记录一下步骤，供参考。 服务端/公网IP云主机 使用docker部署NPS服务端。如果在启动的时候报错提示缺少配置文件，那就根据提示在配置文件目录下，新建对应的文件。docker pull ffdfgdfg/npsdocker run -d --name nps --net=host -v <本机conf目录>:/conf ffdfgdfg/nps 修改nps.conf文件http_proxy_port = 7001 域名代理https代理监听端口,不用可以随便填一个https_proxy_port= 7002 域名代理http代理监听端口,不用可以随便填一个public_vkey = 客户端以配置文件模式启动时的密钥，设置为空表示关闭客户端配置文件连接模式web_username= web界面管理账号web_password= web界面管理密码web_port = 7003 ...

最近看几家HIT厂商在说自己遵循了openEHR标准规范去做了一些应用，包括个人健康档案、集成平台、临床数据仓库、电子病历等等，不一而足。那些厂商到底是应用openEHR解决了一些现实问题呢，还是在整宣传噱头呢？我基于自己的理解，谈一谈openEHR到底适合干什么。 openEHR的起源EHR是电子健康档案的英文缩写，openEHR原本就是一套开源的电子健康档案规范，它是发源于欧洲的GEHR（Good Europe Health Record），最开始的目的是支撑欧洲健康远程信息通讯。上个世纪末，有人基于GEHR的研究成果，提出了openEHR的概念，期望建立一个开源的电子健康档案规范。后来专门的openEHR机构成立了，openEHR机构的主要是目标是通过研究临床需求、建立标准与实施软件，实现开放的、支持互操作的健康处理平台，以加快促进高质量的EHR的发展。经过了十几年的发展，到了2010年后openEHR被引入了中国， openEHR规范概述 openEHR最核心的概念就是RM \ AM,以及EHR、COMPOSITION、SECTION、ENTRY四类对象。 先讲EHR、CO ...

最近一年工作发生很大变化，从技术、研发管理领域转战到了更偏向技术管理、产品管理领域，视角发生了很大变化，也有了很多感悟，正好很久没写文章了，于是总结总结，聊聊在软件企业里如何去做好研发管理、技术管理、产品管理。 产品管理产品管理不同于产品经理做的事。产品经理的工作是致力于打造出一款好的软件产品。产品管理是更高层次的事情，是在企业层面去对所有的产品进行管理，是同时对这家企业的所有产品负责。 做好产品的管理最本质的是要参透在产品到底是什么，产品管理到底要去管什么。有意思的是从企业视角去看产品，与产品经理眼中看到的产品并不一致。之前有产品经理过来诉苦，说我的产品多么好多么牛，结果公司高层却不认可，最后还被砍了，CEO真是SB。其实出现这种现象的原因就是因为他不理解在企业看来产品是什么。 关于产品产品首先是商品。产品被创造出来的目的就是为了销售。所以产品的好坏比较关键的点在于他是否卖的好，而并不在于他是否优美、先进。不可否认的是现实中，特别在 ToB行业很多卖的好的产品并不先进。 产品是以为公司取得收入为目的。产品既然是商品，那么它生来就背负这个使命。产品一定要取得收入，可以是短期收入，也 ...

Domain-driven design并不是一个新鲜的东西，从 2004 年Eric Evans提出这个理念以来，十几年间时不时就有一股DDD的热潮，近几年随着微服务的大行其道，DDD又成了宠儿。但终究逃不过雷声大雨点小。 领域驱动设计最根本的思路是一套自上而下的设计方法，即从要解决的问题领域或系统目标出发，由业务和架构专家一起，对复杂的业务场景和关联性进行分组归类，形成一个一个相对单一职责的子领域。子领域和子领域之间要有明确的界限。在子领域内部，再通过业务上的模型去归类对应的属性和行为。 从设计思想上看，我非常赞同自上而下的架构设计理念，也在不断践行。但今天在技术圈里流传的DDD早已超出了上述的定义，而变成了一套以充血模型为基础，围绕聚合根，并通过门面代理、分离查询、事件传播等手段的软件架构方法。通过这种构建，想达成三种目的： 统一语言：业务与技术统一 让行为回归到实体中去 降低传统service层的复杂度 我所不采纳的即是这样一种“术”，有三个主要原因。 行为是变化的，对象的表达却是几乎不变的，将变化的与不变的聚合在一起，违反了动静分离的原则。 软件实现的是策略，最终想 ...

SSE，全称Server-Sent Events，作为一种半双工的前后端通信方式，由于实现方式简单、轻量，在后端向前端的主动推送场景中具备很好的应用效果，笔者最近在一个项目中多有使用，过程中也是查阅了不少资料和文档，也有所感悟，在此将整体做一次综述。这是一篇系列文章，共分三篇，这是第三篇。 详解Spring 5 Server-Sent Events(一) 基本介绍 详解Spring 5 Server-Sent Events(二) WebMVC 详解Spring 5 Server-Sent Events(三) WebFlux 引言Spring WebFlux framework 5.2.0基于Reactive Streams api，使用事件循环计算模型来实现异步Java Web应用程序。这样的应用程序可以运行在非阻塞的web服务器上，如Netty 4.1和Undertow 1.4，以及Servlet 3.1+容器，如Tomcat8.5和Jetty 9.3。 概述在WebFlux中实现发送事件，需要以下几步： 创建一个controller类并用@RestController注释标记 ...