drawio是个应用广泛的开源画图工具，特别在绘制架构图、流程图、线框图上，完美替代了visio这些商业软件，甚至基于drawio封装的商业版本processon都有很高的用户量，其产品力可见一斑。

next-ai-draw-io是利用大模型实现基于自然语言的AI作图，这个项目在绘制架构图方面真的具备了可用性，从而迅速在github上走红。

我在轻度使用之后，很是惊喜，忍不住推荐给大家，大家可以去试用感受。

功能特性

• LLM驱动的图表创建：利用大语言模型通过自然语言命令直接创建和操作draw.io图表
• 基于图像的图表复制：上传现有图表或图像，让AI自动复制和增强
• PDF和文本文件上传：上传PDF文档和文本文件，提取内容并从现有文档生成图表
• AI推理过程显示：查看支持模型的AI思考过程（OpenAI o1/o3、Gemini、Claude等）
• 图表历史记录：全面的版本控制，跟踪所有更改，允许您查看和恢复AI编辑前的图表版本
• 交互式聊天界面：与AI实时对话来完善您的图表
• 云架构图支持：专门支持生成云架构图（AWS、GCP、Azure）
• 动画连接器：在图表元素之间创建动态动画连接器，实现更好的可视化效果

官方示例

• Transform 架构图
  • 提示词：Give me a animated connector diagram of transformer’s architecture.
  • 效果：
• RAG技术图
  • 提示词：Generate a RAG architecture diagram for chat application. Use connected diagram for data ingestion
  • 效果：
• 开放式创新
  • 提示词：Create visualization of Henry Chesbrough’s Open Innovation model
  • 效果：

应用实例

我将我的上一篇文章大模型应用架构设计要点之安全篇另存到md文件里，直接给next-ai-draw-io，让它生成架构图，提示词如下：

请按照附件的安全架构描述，绘制一副 animated connector 架构图

绘制效果如下：

还是很不错的。从它的思维链过程可以看到，它是根据输入分析整体架构，然后再往下一层层分析，得出具体某个层次里的节点和连接关系，生成每一层次的符合drawio schema的xml，最终拼装为一个整体架构图。

next-ai-draw-io可以下载独立安装包，本机安装，LLM 可以自己配置自己的API KEY，这样确保信息安全，我用的是DeepSeek V3 的 Reasoner 模型。因为生成的是drawio xml文件，所以可以在左边的drawio 区域里，自由修改。

去年年底开始，我就常和人发生这样的对话：

你们这个智能体应用的底层大模型是自己做的吗? — 不是，我们用的XXX

你们是做了微调？—没有呢，基模迭代太快，做微调不现实

哦，那你们就是拿XXXX的API套了个壳啊！ — （无语）

当然，我们不能苛求外行人士去弄懂 DeepSeek API 和 DeepSeek 网页版的区别，他们不知道部署个DeepSeek-V3 不代表拥有了DeepSeek网页版对话应用。转而言之，也不是没有在基模层面做调整就无法形成自己软件产品的核心竞争力。别人说大模型应用是基模API套壳，自己不能真信了，事实上大模型应用相较传统软件应用在架构上更为复杂。

但也由此，触动我去总结大模型应用架构设计的要点，与各位一起探讨进步。

架构设计的目的简而言之就是解决安全、性能、可扩展性这三个问题，因此我也打算分三篇来总结，这是第一篇：安全篇。

下面我就从内容安全、运行安全和数据安全三个角度来阐述。

内容安全

传统类软件在处理内容安全时非常简单，但是大模型对话类应用会复杂许多。事实上，直到现在，网络上关于大模型越狱还是很火的话题，不少人致力于通过提示词注入有意让大模型去生成不当、不妥的内容。

即使不提涉H涉Z的内容，作为一个大模型应用，如果反馈给用户的内容，超出了应用的边界，也属于安全失控，比如健康管理类的应用直接给咨询者出具了诊断或开立了处方或者大模型应用将置信度不足的内容返回给了用户，从而造成了明显的误导。

解决内容安全问题，重点就是解决注入和越界问题，架构设计时需要做到以下三点：

1. 前置拦截器。前置拦截器一般是通过一个网关来实现。在收到用户的 query 之后，递交给 LLM 之前，要对 query 内容进行语义识别，可以是关键词结合分类小模型，为query打上标签：暴力、涉政、代码注入等等。如果是恶意类的标签，网关直接阻断请求并返回预设回复，这样也能使得大模型的token免遭浪费。

2. 提示词锁定。为了避免恶意用户覆写大模型角色，导致应用失控，在前端请求到达网关层时，需要强制拼装一段不可见、不可覆盖的系统级Prompt，限定其身份边界，比如你是一个健康管家助手，拒绝回答医学诊断问题……。

3. 后置判别器。大模型应用的返回方式可能是一次性的也可能是流式的。无论是一次性输出还是流式输出，都需要对返回内容进行判定。比如采用SSE时，旁路要并行运行一个判别器模型。一旦检测到正在输出的 Token 组合触碰红线（例如生成了带有严重错误的临床辅助建议），架构上要立即触发掐断机制，直接回复给前端：生成已中止。

运行安全

传统软件的运行安全主要是考虑保护服务器性能，在适当的时候熔断或降级。大模型应用的运行安全，需要在CPU、连接数这些之外，再额外考虑token负载，无论用户是有意或是无意，造成token异常大量消耗时，架构上应有控制点发挥作用。

为了避免运行时的崩溃与耗尽，架构设计时需要考虑以下三个方面：

1. LLM限流。在大模型应用架构中，需要实时计算每个会话的 Token 消耗，比如每分钟token数，将其写入Redis中，当某个会话的token消耗速率过高时，大模型应用的模型路由层要能自动将用户请求从高参数模型降级到低延迟低成本的模型或者通过阻断用户请求进行流控（显式返回给用户告知其操作过于频繁，请X分钟之后再提问），从而保障系统整体平稳，当然整个过程中可以将用户根据业务价值进行优先级分级，不用一刀切。

2. 断路器。对于涉及多步推理的智能体工作流，架构设计时要考虑最大思考步数和最大执行时间。一旦模型陷入死循环或不断重试错误的 MCP 调用，系统要强制中断，防止计算资源被无限榨干。

3. 隔离沙箱。这一点最早是 ChatGPT 提出的，比如用户上传了一个 csv 文件给 ChatGPT 让它统计分析某个指标，事实上 LLM 会生成一段使用 pandas 库读取该 csv 文件，然后使用numpy进行计算的 Python 代码，这段代码不会在宿主机上执行，而是会迅速拉起一个微型虚拟机，然后在其中执行代码，执行完毕后即销毁该虚拟机，这样的目的是避免影响宿主机，防止恶意代码被执行。比如用户说请删除服务器目录下的所有文件，即使这句话绕过了拦截器，也只是在沙箱中删除不会造成损失。如果大模型应用中涉及到数据分析、准确的数学计算、格式转化等等此类需要通过生成代码并执行代码的场景，需要在系统设计中实现沙箱机制。

数据安全

前一段时间有个新闻，说的是用户在使用Kimi的时候竟然看到了其他用户上传的简历。月之暗面解释说是模型幻觉导致的，但幻觉不至于让一份完整的准确的简历给另一个用户看到，这大概率是生产环境数据未做有效隔离或者上下文缓存错误引用导致的，这是一个工程问题，不是基模幻觉问题。

要作好数据安全隔离，需要着重实现以下三点：

1. 租户会话二级隔离。会话在持久化存储时需要明确标识租户信息，前端在发起请求时只允许携带本轮会话标识，历史会话标识一定要由后端服务通过租户ID关联取出，这样可以避免前端恶意读取跨会话\跨租户内容。
2. 向量库数据权限隔离。大模型应用一般都会通过向量库实现RAG。如果特定用户的数据被切片放入向量库时未附带权限信息，后期检索召回时则无法控制数据不被不当利用。以Qdrant为例，每个向量都可以关联一个 JSON 格式的 Payload。在存储切片时，需要将权限标识作为字段存入。在检索时，调用 search 接口必须将当前会话租户的权限信息通过 filter 参数传入。这样 Qdrant 就会在进行向量相似度计算前执行过滤，只有符合条件的向量才会参与距离计算。
3. 敏感信息过滤器。大模型应用在架构设计时，需要实现一个filter，在数据即将提交给用户前，利用正则表达式或小模型，对身份证、电话号码、真实姓名等敏感信息进行动态掩码或替换。

结语

当大模型由专业的厂商来开发和迭代后，使用大模型去实现应用与使用一个关系数据库去实现应用并无本质不同。它们都是一个组件。我们需要根据这个组件的能力边界、关键特性去使用好它，这也就是架构师的职责所在。

「大爷，您听说过词元吗？就是是最近央视报道、国家宣传的，它是AI 时代的石油、是数字黄金、是下一个比特币。现在有一门稳赚不赔的投资您感兴趣吗——低价囤词元，未来涨百倍」（误，不要信）这是这两天我在一个防诈宣传上看到它列举的典型案例。AI真的太热了，骗子都可以用这个概念骗大爷大妈了。

而你——我的同行们——你既然看到这篇文章，你要么在忙着用大模型重构业务，要么在忙着折腾小龙虾…当你从demo阶段转到实战阶段的时候，你一定已经遇到了一个又一个坑，从刚开始的兴奋不已到困惑不解，为什么不如预期呢？甚至产生了一丝丝怀疑，到底是我不行还是大模型不行？

以小龙虾为例，当它在处理未见过的UI布局时（是的，企业环境里有大量的非公开的UI），效率和准确性会雪崩式的下降，偶尔会陷入“失败-重试”的反复循环，token像流水一样逝去，最终只为了完成一次简单的点击；即使不是模拟操作UI，只是生成一个报表或者月度报告，你敢不敢直接点击“发送”呢？它的确一分钟生成好了，但你要花费十倍的时间去检查验证；更加让人不放心的是，它不理解“删除正式文件”和“删除临时文件”的区别，不加分辨的使用你授予的权限，然后造成悔之不及的后果…

在我实践过的场景中，大模型只在少量的场景上取得了确定性的成功……我相信大家都开始有了这个感受：我们对大模型的期望已然远远超越大模型当前的能力水平。

因此本篇文章，我想安安静静的做一些冷思考，也分享给你。

技术局限性

从技术底层上来看，LLM本质上是在根据海量文本寻找统计相关性，然后预测下一个token，因此LLM有天生的两块短板，一是文本的稀疏性，二是概率的局限性。

首先说说文本的稀疏性。文字语言是人类对现实的一种压缩，它不能代表全部，比如我们不会在书里写：如果你松手，杯子会掉下去——如果哪本书里真写了，那请把这句话改成蒿子粑粑会掉下去，这下总没有了吧，你懂我的意思——因为这是常识。正所谓：一个 10 岁的孩童在成长过程中已经观察了大约 10 亿秒的视频信息（这句话是Yann LeCun说的，图灵奖得主）。这些视频重度参与构建了这名孩童对世界的理解。人类的很多知识是非语言的，但大模型只读过文本，因此寄希望于大模型去准确理解这个世界是天方夜谭。

概率的局限性得分几个层次来说。

你问大模型，1+1等于几，它会告诉你等于2，你如果问它753945乘以8723344等于多少，然后你再用计算器算一下看看LLM是不是在胡扯…（gemini很自信的告诉我答案是6,576,922,084,080，这个数字很像但是不对）。为什么会这样呢？一个小学四年级的学生都能算对，高科技的大模型人工智能却回答不对！这是因为大模型不是在计算，而是在根据训练语料库里的字词概率去模拟，因此具体到某个大数的乘法，它的语料库里缺乏相应的记录，它就没办法“算对”了。这正是概率的局限性的第一点：统计相关性不等同于逻辑因果律。大模型并不理解逻辑因果律，它只是在模仿人类描述这一现象的频率。当面对需要严密因果链条的复杂推理时，如果逻辑链条中某个环节在语料中从未出现过，模型就会根据概率凑出一个听起来最像人话、但逻辑全错的答案。

概率的第二个局限性可以称之为平庸化。大模型在生成文本的过程中，为了让输出的 结果像那么回事，会倾向于选择高概率的词，追求概率最大化的后果就是天然的倾向于输出最稳妥、最符合大众思维的正确的废话，对于那些在语料库中出现频率不高的精准的冷门知识，会被高频的、似是而非的错误知识所干扰，最终大模型输出的内容会趋向平庸化。有一份研究报告提到过互联网上高质量的人类文本的总量大约在几百万亿级别，像Llama、GPT这种级别的模型，训练数据量已经达到15万亿。当人类高质量语料用尽之时，大模型厂商不得不使用充满了广告、SEO垃圾和低质量对话甚至AI生成的数据来训练下一代AI，可以想见，这不仅没办法提高模型的能力，反而会降低模型的能力，因为低质量人类语料带来的是噪音，AI生成的语料带来的是近亲繁殖，信息熵减。

大模型这种基于序列的概率模型还存在误差累积的局限性。假设LLM在每一步预测正确的概率是99%，由于LLM每输出一个token，这个token就会变成下一步预测的已知条件，那么第一个词是99%的正确率，到第100个词的时候整个序列完全正确的概率就变成了0.99的100次方，也就是36.6%。如果某一步选错了词，大模型会基于这个错误的词继续计算下一个概率最高的结果，这就像在一个错误的公式上继续推导，结果就是一本正经的胡说八道。

在这些技术底层原理的局限下，势必会导致LLM天然有着自己的上限，天然有着无法胜任的场景。当然，我们可以辅以其他手段来改善，比如定制一些高质量的语料来训练、挂载RAG来注入上下文或者用专家知识来做输出结果的校验等等，但越是不能出错的场景，带来的额外开销就会越大，最后大到无法承受（正如当年知识图谱路线走过的老路），大到等同于impossible。

发展瓶颈期

随着高质量人类文本语料的消耗完毕以及算力规模基数的不断增大，增加算力和数据带来的准确率提升将越来越小， 仅仅靠喂更多数据已经换不来智力层面的有感知的变化。深度思考的出现，本身就证明预训练层面的边际收益已经不经济了，因此需要转到推理层面的规模化，加入越来越多的逻辑推演，逻辑推演对算力的消耗是随步骤指数级增长的。未来单位算力的价格肯定会下降，但算力降价的速度可能永远赶不上逻辑深度增加的需求，因为线性的追不上指数。

大家都有感受，现在token的消耗速度，相较于去年上半年的时候，有了大幅的增加，就是token好像不耐用了，随随便便一百万token就没了。

成本在上升，但是否带来了有效的收入增长呢？ 如果一个企业需要 5 年时间才能把 AI 变成企业生产力，那么前期的巨额基础设施投入就会产生极大的资金折旧和机会成本。

从另一个角度看，如果AI只能解决有限的特定的场景，比如初级编程、写作、翻译、RPA，那这些场景能带来的收入是否能支持后续的AI成本增长呢？除了这些易学习、强模式的任务，还有很多任务是环境敏感型的，我们在落地的时候，有一些环境因素可以知识化表达给大模型，然后保持动态更新，这带来的额外成本一时半会也算不清楚，更别提另有一些环境因素，并不能形成文字（微妙的人情世故），那大模型就很难起到作用。

结语

我们总是倾向于在短期内过高估计一项技术的影响，而在长期内过低估计它。不可否认，大模型是革命性的突破，但在全民疯狂的时候，不妨保持头脑的冷静，谨慎的乐观，有限制的试点，有计划的投入，在一个浪潮兴起时，活到最后的，往往不是第一批弄潮儿。

引言

大家好，最近openClaw大爆，不少软件/服务都纷纷迭代，提供了CLI或MCP，供各类龙虾、螃蟹以及其他海鲜水产接入（开个玩笑）。我前面写过一篇文章，呼吁各位同仁警惕马车陷阱，不要用AI能力去做了一堆旧式马车出来。同时，我也在思考研究AI时代的软件究竟应该是什么形态，难道就是openClaw这样吗？当然，这个命题实在很大，我个人能力也特别有限，而且其实也还未到能说清楚的时候（子弹还得飞一会），但是从底层技术哲学的角度来看，整体的框架还是有轮廓的，于是我尝试用这篇文章将我的思考写出来，尝试说清楚AI原生架构到底是什么，什么样，能解决什么问题，以及与传统软件架构的关系，也欢迎讨论指正。

首先，AI Native是什么

如果用严肃的语言去描述，AI Native 可以定义为：以大模型作为底层的推理内核与控制逻辑中枢，实现业务流程的编排与交互的语义化，并具备进化能力的软件或系统。
AI Native应用区别于集成了AI功能或外挂了AI能力的应用，比如腾讯会议最近提供了AI会议纪要功能（很棒的功能），但腾讯会议app不是AI Native应用。
要深刻理解AI Native，只需要从一个底层维度去认识到它和传统软件的区别：确定性还是概率性？ 传统软件最典型的特征就是无状态的Restful API，使用同样的参数去调用api必定给出同样的结果，这就是确定性，而AI原生架构的内核就是基于概率性的LLM，它会根据训练数据、模型版本和实时的环境上下文进行适应和动态自主决策。

其次，AI Native应用架构

同样，为了便于理解，我还是先说传统软件架构（抱歉，现在云原生架构也归于“传统”了，技术迭代就是这么快），传统软件架构自下而上是：
以CPU为核心的硬件设施->基于关系数据库/NoSQL的数据层->固化业务逻辑的后台服务层->固化用户交互的前台展示层。
而AI Native应用由于其的核心价值不同，它的架构与传统软件架构有了很大的区别，自下而上是：
以GPU为核心的硬件设施->基于向量数据库的记忆层（以及非结构化数据的语义处理管道）->大模型及大模型网关层->智能体工作流与编排层。
如你所见，AI Native架构没有了UI层，那是因为传统的UI是为了与人交互，在AI Native应用里，人已经被作为一个特殊的节点——通常是观察者、审查者或者最终接管者——被编排到了智能体工作流中。很难理解吗？想想AI Coding的时候，你在干什么。
AI Native应用高度依赖数据，特别是企业专有数据和领域知识数据，来减少幻觉并提供具备独特价值的反馈。因此，在实现AI Native应用时，必然要构建非结构化数据处理管道，选择合适的分块策略，以确保将文档转化为模型易于理解的连贯单元，选择合适的嵌入模型，将文本/多模态数据转化为高维向量。
向量数据库是记忆层的核心设施，用于存储和进行语义搜索。同时，为了提高性能降低Token消耗，这里通常还要构建语义缓存（比如基于Redis LangCache），不同于传统基于精确键值匹配的缓存，语义缓存判断用户查询的意图相似度。对于相似问题直接返回缓存，从而降低Tokens成本和推理延迟。
在智能体工作流与编排层，一方面是明确多智能体的设计模式，我们需根据业务场景去选择多智能体的协作模式，是顺序模式、并发模式、Maker-Checker模式、ReAct模式或者动态编排模式。另一方面是实现MCP的集成，MCP作为一种标准化的客户端-服务器通信规范，让AI智能体能在运行时动态发现并安全调用外部数据源和工具，无疑是大大拓宽了AI Native应用的能力边界。
随便说一下，AI Native应用的评价指标将有别于传统应用。传统应用追求的是高可用以及适当的性能（响应、吞吐），AI Native则还需要考虑模型的准确性以及一次请求的Tokens成本。可以预见，将来调优的工作是越来越复杂了～

第三，AI Native应用还是传统应用

AI Native应用绝对不会替代传统应用，因为AI Native实质上是拓宽了软件应用的服务能力，它做到了传统应用做不到的事情，但是在一些场景下，传统应用是毫无疑问的最佳实践。如果谁妄想拿起AI Native这把锤子把所有的业务场景都当做钉子，那绝对是自寻死路。总的来说，AI Native适合处理复杂、开放式和需要认知能力的任务，而对于高度确定且规则明晰的任务仍然是传统应用的主场。
对于开放式的任务，传统应用受限于代码逻辑，只能按照既定规则执行命令。而 AI Native应用的核心能力就是弄清楚并解决问题。它们能够像人一样自主工作，在遇到歧义时形成假设并测试验证，并在遇到死胡同时自主纠正错误，这是传统应用完全无法做到的。
但是如果一个业务用例可以通过预先定义的明确步骤来解决，传统应用的可靠性和可复现性就成了巨大的优点。同时，传统应用具备更快的响应能力，AI Native应用的思考过程不可能快的过。当然，不可忽视的还有CPU相较于GPU的巨大的成本优势。
因此，将非确定性的AI编排模式应用于本质上是确定性的业务场景，是一种愚蠢的架构错误。企业级应用的最佳实践是各司其职：用传统软件构建确定性的骨架和规则底座，用 AI Native 系统充当“认知大脑”。让传统软件处理固定化的业务流与数据存储，而让 AI 去解决非结构化数据输入、意图路由、多步骤规划以及那些需要灵活性和创造力的边缘场景。

结语

AI时代的冲击是全面的，毕竟即使是适合用传统应用去解决的场景，也可以让AI去写传统应用软件嘛，整个社会陷入了狂热（从没想到代装龙虾也能挣钱- -）。但可以看到的是在LLM的狂热中，还是有不少人给出了警示。狂热不能持久，终将回归理性。下一期我可以讲讲这场狂热中的少数派，毕竟，可能他们掌握着TRUTH？

一、 速度的代价与技术债

这是一个研发效能被彻底颠覆的时代。AI 编码助手正以前所未有的速度接管开发者的键盘。曾经需要一个敏捷迭代才能完成的 CRUD 模块，现在只需几句 Prompt 就能在几分钟内生成。

然而，只有身处局中的我们，才能切身体会到随着效率提升的隐性技术债务的疯狂增长：如果缺乏严谨的工程整合与架构规范，AI 生成的海量代码正在形成可怕的屎山。

在传统的开发流程中，技术债通常伴随着编译错误、测试失败或明显的性能瓶颈。但 AI 带来的隐性技术债却自带“保护色”——代码能够完美跑通，单元测试全绿，甚至在初看之下语法极其规范。但就在这看似繁荣的表象下，系统的全局一致性、可读性以及长期的可维护性，正在被悄悄瓦解。

在人机协同的新范式下，如何防止这种隐性技术债的复利积累，已经成为每一位技术管理者和架构师面前，比“如何让团队写得更快”更紧迫、也更具战略意义的生死大考。

二、 AI是如何偷偷欠下“隐性技术债”的？

要治理疾病，首先要看清病灶。为什么号称掌握了全网开源代码的 AI，会成为制造技术债的“涡轮引擎”？我们可以通过几组关键数据和现象来揭示其本质。

现象 1：认知复杂度与代码警告的飙升

近期针对多个拥抱 AI 编码工具的开源仓库及企业级代码库的纵向跟踪研究表明，引入 AI 自主代理后，代码库虽然体积迅速膨胀，但随之而来的是两项关键指标的恶化：静态分析警告平均增加了约 18%，而代码的认知复杂度更是激增了约 39%。

背后的原因在于 AI 的“心智模型”。AI 的首要优化目标是“快速跑通并满足当前 Prompt”，而不是像资深人类工程师那样，在动量产出之前先思考抽象、复用和重构。当遇到复杂逻辑时，AI 倾向于堆砌 if-else 和硬编码来强行打通路径，这导致代码的圈复杂度和认知复杂度直线上升。

现象 2：AI Workslop 的蔓延

在 AI 生成内容领域，诞生了一个新词汇：Workslop。它指的是那些表面看起来专业、有用、语法完全正确，但实际上缺乏业务深度、包含细微边界错误，或者根本没有完全契合上下文意图的产出物。

在代码世界里，Workslop 的危害极大。由于它在初步的代码审查中极易蒙混过关，导致隐患被直接合入主干。几个月后，当业务需要迭代时，人类工程师将被迫耗费数倍于写代码的时间，去逆向工程、解释、修正甚至完全重写这些毫无灵魂的“AI 糊弄学”产物。

现象 3：常见的四种 AI 失败模式（隐性债的四大源头）

当我们将视角下探到代码微观层面，AI 引入隐性技术债主要表现为四种失败模式：

1. 架构漂移： AI 为了快速实现局部功能，绕过或破坏了系统既定的分层架构和全局设计原则。
2. 模式违规： 团队规定了统一的错误处理、状态管理或日志打印模式，但 AI 引入了它在预训练数据中见过的“另一种流行做法”。
3. 连贯性退化： 在长上下文任务中，AI 前后生成的代码标准不一，导致同一个文件内出现“精神分裂”式的编码风格。
4. 上下文过时： 依赖了旧版 API 或已经废弃的内部私有库，强行生成了看似合理但实则存在版本冲突的胶水代码。

三、 三个典型“案发现场”

为了让上述抽象概念更具象化，让我们来看看日常开发中，隐性技术债是如何在不知不觉中被引入的三个典型场景。

案例 1：糊弄

场景： 临近发版，产品经理要求为一个新的电商大促页面快速添加一个显眼的“蓝色购买按钮”。你为了图快，直接让 AI 助手生成这段 UI 代码。

结果： AI 极其迅速地给出了一段包含内联样式的代码，并硬编码了 HEX 颜色值（例如 #0000FF）。你粘贴进项目，页面上确实出现了一个漂亮的蓝色按钮，功能完美实现，按时下班。

隐患： 你所在的团队其实耗费了大量精力建立了一套完整的设计系统（Design Tokens）和统一的组件库，标准做法应该是调用 <Button color="primary">。AI 给出的局部最优解，在不知不觉中破坏了全局的一致性。当未来品牌升级，主色调从蓝色改为紫色时，全局变量的更改将对这个组件失效。这个由 AI 生成的按钮，就成了代码库里一颗极难被排查到的“定时炸弹”。

案例 2：失忆

场景： 你正在进行一个数百行 React 老代码的重构任务，要求 AI 将传统的 Class Component 彻底翻新，并在 Prompt 中明确强调：“请严格使用最新的 React Hooks 和状态管理规范”。

结果： 在代码的前半部分，AI 表现得像一位现代前端大师，优雅地使用了 useEffect 和自定义 Hooks。然而，随着代码长度的增加，上下文窗口被逐渐稀释，AI 似乎“忘记”了最初的指令。到了后半部分的生命周期处理时，它悄悄地混入了已被弃用的旧版 API 思维，甚至混杂了直接操作 DOM 的陈旧写法。

隐患： 这种连贯性的退化，导致同一个文件或模块中混杂了新旧两套截然不同的标准。后来的维护者在阅读这段代码时，认知负荷会呈指数级上升，完全搞不懂作者（AI）当时的架构意图是什么。

案例 3：疲劳

场景： 团队管理层意识到 AI 生成代码可能存在风险，于是规定：“所有 AI 提交的代码，必须经过人类工程师的审批（Human-in-the-loop）才能合入。”大家认为这绝对万无一失。

结果： 引入高度自主的 AI 代理后，机器不知疲倦，每天能自动提交 200 个包含依赖升级、微小重构和样板代码生成的 Pull Request。人类工程师每天一打开审查面板就被彻底淹没。面对看似规范的“Workslop”，人类迅速产生审查疲劳，从最初的逐行推敲，退化为只看标题的“盲目盖章”。

隐患： 审批流彻底沦为走过场。AI 引入的深层次结构性错误、模式违规被披着合法的外衣，堂而皇之地合入了主干代码库。人类不仅没有守住最后一道防线，反而成为了系统崩坏的背书人。

四、 人机协同时代的“防债”解决方案

面对汹涌而来的 AI 代码洪流，单纯的抵制是开历史倒车，而放任自流则会摧毁工程根基。我们需要全新的架构思想、工具链和研发流程来实施系统级的治理。

策略 1：从静态文档到动态规范 (Living Specs)

理念转变： 过去，我们的架构规范和设计系统是写在 Wiki 上的静态文档，只有人类才会去阅读（往往还不读）。在 AI 时代，不要再过度依赖开发者在聊天框里临时输入的零散提示词。我们需要建立机器可读的、动态更新的“动态规范”，作为人类与 AI 的共享记录系统。

实践落地： 团队应积极引入并利用MCP等工具，将你的内部 API 文档、设计规范和架构规范直接挂载给 AI。在 AI 敲下第一行代码前，强制其先查询规范。让架构规范成为 AI 执行任务时的物理级硬性约束条件，而不是道德建议。此后，发现问题就更新规范，这样让规范成为一个动态的有效的约束。

策略 2：重构审查机制——双节点拦截与自动化防护

双节点审查： 放弃事后逐行看代码的传统 Code Review 模式。针对 AI 生成的复杂任务，强制实施“规划检查点”和“PR 检查点”。在 AI 动手写代码之前，先让人类审查其生成的“执行计划和架构意图”。意图对了，细节可以宽容；意图错了，代码再漂亮也是灾难。

策略执行大于人工审批： 面对 AI 海量的输出，人类的注意力是极其稀缺的资源。对于高频操作，必须用“自动策略执行”代替容易疲劳的“人类审批”。例如，为 AI 设置无法越权的沙盒环境，在 CI/CD 管道中引入极其严格的静态检查规则，把人类从“找拼写错误”的地狱中解放出来，去关注更高维度的系统设计。

策略 3：引入 AI 自治理机制

用魔法打败魔法，用 AI 审查 AI。 在人类介入之前，引入专门的验证代理智能体或复杂的自动化代码审查工具。让“审查型 AI”去挑“生成型 AI”的刺，自动抓取逻辑漏洞、安全风险和激增的认知复杂度。

运行时监控与漂移检测： 借鉴类似 MI9 框架的理念，对高度自主的 AI 代理实施持续的授权监控。一旦在运行态或静态分析中发现 AI 偏离了预定的设计模式（触发 Drift Detection），系统应立即拦截其合入请求，并降级其执行权限，强行切回人类接管模式。

策略 4：提高代码库的AI 就绪度

在向代码库引入高度自主的 AI 代理之前，请务必先“打扫屋子”。 如果你的代码库本身就充满了“脏数据”、面条代码和海量遗留的技术债，AI 代理在阅读上下文时，不仅不会帮你清理，反而会完美地模仿并呈指数级放大这些不良模式。在使用高级 AI 前，先利用重构工具统一编码规范，消除明显的坏味道，让你的代码库达到AI 就绪状态。

五、 结语

技术史上有一个残酷的真相：没有任何一种自动化工具，能够自动写出具备良好可维护性的复杂系统。 AI 代理的出现，本质上是极其残酷地放大了“短期开发速度”与“长期代码可维护性”之间的权衡矛盾。

在这场技术变革中，工程师的角色正在发生深刻的、不可逆转的转变。我们将不再是日复一日逐行编写增删改查代码的Coder，而是演变为设计护栏、制定规范、把控全局架构，并指挥庞大 AI 代理舰队的系统架构师。

只有建立在严格的工程纪律和系统级治理的基石之上，AI 才能真正成为我们所用，而不是在狂欢后成为最终压垮整个系统的灾难源头。

这篇文章是全球智能危机的第二部分，副标题为 一场来自未来的金融史思想实验，这部分不同于 Part One 的分析式论述，而是采用一种虚构的“未来回顾”叙事形式：假装是 Citrini Research 在 2028 年 6 月 发布的宏观备忘录，回顾“全球智能危机”如何从 2026 年起逐步爆发并演变为一场全面金融/经济灾难。以下是全文翻译。

序言

如果我们对 AI 的长期看多是正确的……但如果这反而是利空呢？

接下来的内容是一个情境模拟，而非预测。 这不是“空头意淫”或“AI 灭世幻想”。本文的唯一目的是建模一个相对未被充分探讨的情境。我们的朋友 Alap Shah 提出了这个问题，我们共同构思了答案。

希望阅读此文能让您更好地应对随着 AI 让经济变得日益诡异而可能出现的“左尾风险”。

这是来自 2028 年 6 月的 CitriniResearch 宏观备忘录，详细记录了“全球智能危机”的演变与后果。

宏观备忘录

智力过剩的后果 (The Consequences of Abundant Intelligence)

CitriniResearch 模拟日期：2028年6月30日（发布于2026年2月22日）

今天早晨公布的失业率为 **10.2%**，意外高出预期 0.3%。市场应声下跌 2%，使得标普 500 指数自 2026 年 10 月的高点以来，累计回撤已达 **38%**。

交易员们已经麻木了。六个月前，这样的数据足以触发熔断。

两年。 仅仅两年时间，经济就从“受控的”和“行业特定的”波动，演变成了任何一个伴随我们长大的人都无法认出的模样。本季度的宏观备忘录是我们重建这一过程序列的尝试——一场对危机前经济的“尸检”。

当时的狂热清晰可见。到 2026 年 10 月，标普 500 指数直逼 8000 点，纳斯达克突破 3 万点。第一波由于“人类冗余”导致的裁员始于 2026 年初，它们起到了裁员应有的作用：利润率扩张、业绩超预期、股市上涨。创纪录的企业利润被源源不断地投入到 AI 算力中。

表面的名义 GDP 指标依然亮眼。生产力正在激增。受惠于不需要睡眠、不请病假、不需医保的 AI 智能体，实际每小时产出以 1950 年代以来未见的速率飙升。

算力的拥有者看着财富随着劳动力成本的消失而爆炸。与此同时，实际工资增长陷入停滞。尽管政府一再夸耀创纪录的生产力，白领工人们却不断被机器取代，被迫转入低薪岗位。

当消费经济开始出现裂痕时，经济评论家们普及了一个词：“幽灵 GDP” —— 指出现在国民账户中，但从未在实体经济中循环的产出。

在各方面 AI 都超出了预期，市场即 AI。 唯一的问题是……经济并不是 AI。

原本应该很清楚：一个位于北达科他州的 GPU 集群，产生了过去曼哈顿 10,000 名白领的产出，这与其说是经济灵丹妙药，不如说是经济大流行。货币流通速度归零。占当时 GDP 70% 的、以人为中心的消费经济萎缩了。如果我们早点问问“机器会在可选消费品上花多少钱”，我们可能早就明白这一点了。（提示：答案是零。）

AI 能力提升 → 企业需求更少工人 → 白领裁员增加 → 被替代的工人减少支出 → 利润压力迫使企业加大 AI 投入 → AI 能力进一步提升……

这是一个没有自然刹车的负反馈循环。即**“人类智能位移螺旋” **。白领工人们发现他们的赚钱能力（以及理性的消费能力）遭到了结构性破坏。他们的收入曾是 13 万亿美元抵押贷款市场的基石——这迫使承销商重新评估：曾经的“优质抵押贷款”是否还算得上是钱。

十七年没有真正的违约周期，导致私人市场充斥着估值虚高的私募股权支持的软件交易，这些交易假设年经常性收入（ARR）会永久持续。2027 年中，AI 颠覆引发的第一波违约挑战了这一假设。

如果这种颠覆仅局限于软件行业，原本还是可控的，但事实并非如此。到 2027 年底，它威胁到了每一个基于**居间服务 ** 的商业模式。大量依靠赚取“人类摩擦费用”的公司土崩瓦解。

整个系统被证明是一条关于白领生产力增长的互相关联的对赌长链。2027 年 11 月的崩盘进一步加速了所有已到位的负反馈循环。

我们等待“坏消息即好消息”已经近一年了。政府开始考虑提议，但公众对政府组织任何救援的能力已失去信心。政策反应总是滞后于经济现实，而缺乏全面计划正威胁着要加速通缩螺旋。

01.危机是如何开始的

2025 年底，智能体化编程工具 (Agentic Coding Tools) 的能力发生了阶跃式进化。

一个使用 Claude Code 或 Codex 的合格开发人员，现在可以在几周内复制一个中等规模 SaaS 产品的核心功能。虽然不是百分之百完美，但足以让正在审批 50 万美元SaaS年费续约合同的 CIO 开始发问：“如果我们自己造一个呢？”

2026 年夏季，我们与一家财富 500 强企业的采购经理交谈。他讲述了一次预算谈判：销售员预期像往年一样涨价 5%，并搬出“你们的团队离不开我们”的陈词滥调。采购经理回怼说，他已与 OpenAI 的“前线部署工程师”沟通，利用 AI 工具完全取代该供应商。最终，他们以 30% 的折扣完成了续约。他说，这已经算是不错的结果了。而像 Monday.com、Zapier 和 Asana 这样的“长尾 SaaS”公司，境况要惨得多。

投资者原本预期长尾公司会受重创，但认为“记录系统 (Systems of Record)”是安全的。直到 2026 年第三季度 ServiceNow 的财报发布，反身性 (Reflexivity) 的机制才变得清晰。

SERVICENOW 净新增 ACV 增速从 23% 骤降至 14%；宣布裁员 15% 并开启“结构性效率计划”；股价暴跌 18% | 彭博社，2026年10月

SaaS 并没有死，但“自主研发”成了一个可行的价格谈判筹码。更重要的是，竞争格局变了。AI 降低了开发门槛，差异化消失。老牌巨头陷入了价格战。

最讽刺的是：ServiceNow 是按“席位”收费的。当客户裁掉 15% 的员工时，ServiceNow 也就失去了 15% 的授权收入。那种原本旨在提高客户利润的 AI 裁员，正机械性地摧毁 SaaS 公司自己的收入基础。

受 AI 威胁最严重的公司，反而成了 AI 最激进的采用者。 2026 年与以往不同：老牌巨头没有抵制新技术，因为他们输不起。

在股价下跌 40-60% 的压力下，这些公司做了唯一能做的事：裁员，将省下的钱投入 AI 工具，用更低的成本维持产出。每个公司的个体决策都是理性的，但集体结果是灾难性的。软件行业只是序幕，这种逻辑随后蔓延到了每一个拥有白领成本结构的公司。

02.当摩擦趋于零时

到 2027 年初，大模型的使用已成为默认配置。人们使用智能体就像使用自动补全或拼写检查一样自然。

Qwen 的开源智能体购物助手是催化剂。到 2027 年 3 月，美国的中位个人每天消耗 400,000 个 token —— 是 2026 年底的 10 倍。

经济长链的下一环开始断裂：**居间服务 **。

过去 50 年，美国经济建立了一个巨大的租金提取层，利用人类的局限性：时间成本、耐心、品牌依赖。数万亿美元的企业价值依赖于这些摩擦的持续存在。而智能体抹平了这一切：

• 订阅经济： 智能体能代表用户谈判甚至取消那些悄悄涨价的订阅。
• 旅游与保险： 智能体组建行程或重新比价的速度和成本远低于任何平台。
• 专业服务： 财务顾问、税务筹划、常规法律工作。只要价值主张是“处理繁琐流程”，就会被不知疲倦的智能体取代。
• 房地产： 买家曾容忍 5-6% 的佣金。当 AI 智能体掌握了 MLS（房源信息系统）数据后，这种信息不对称消失了。到 2027 年 3 月，主要城市的买方佣金从 2.5-3% 压缩至 1% 以下。

事实证明，人们口中所谓的“人际关系”，往往只是带着笑脸的“摩擦”。

习惯性中介 的护城河被摧毁了。以 DoorDash 为例：编程智能体降低了开发门槛，大量竞争对手涌现，将 90-95% 的费用返给司机。对于智能体来说，不存在“主屏幕应用忠诚度”，它会全网搜索最低费率。

当智能体控制了交易，它们开始瞄准更大的目标：消灭手续费。

在机器对机器 (M2M) 的商业中，2-3% 的银行卡清算费 成了活靶子。智能体转向了结算更快的稳定币（通过 Solana 或以太坊 L2）。

万事达 (Mastercard) 2027年Q1：购买量增速放缓；管理层提及“智能体主导的价格优化”和“可选消费品压力” | 彭博社，2027年4月29日

万事达和维萨股价重挫。这进一步重创了依赖利息和奖励计划的银行（如 美国运通、Capital One）。他们的护城河由摩擦构成，而摩擦正在归零。

03.从行业风险到系统性风险

2026 年间，市场仍认为这只是行业故事。但到了 2027 年，观点发生了转变：美国经济本质上是白领服务经济。白领工人占就业人数的 50%，驱动了约 75% 的可选消费。AI 正在啃噬的不仅仅是边缘业务，它们就是美国经济本身。

“技术创新会摧毁旧工作并创造更多新工作”——这个反驳曾正确了两百年。但 AI 不同：它是一种通用智能。

过去，ATM 增加了银行柜员，互联网创造了新产业，但每一个新岗位都需要人类。而现在的 AI 智能体已经能处理长达数周的研发任务。

美国 JOLTS：职位空缺跌破 550 万；失业与空缺比攀升至 1.7 | 彭博社，2026年10月

白领职位空缺正在崩溃。招聘率全年低迷。债券市场开始定价消费冲击，10 年期收益率从 4.3% 降至 3.2%。

这种周期无法自发修复。 因为这不是周期性的，而是运营成本的替代。企业增加 AI 预算的同时缩减了整体支出。

这种趋势在国际上产生了不对称影响：

• 受惠国： 台湾、韩国等 AI 基础设施供应国表现出色。
• 受害国： 印度。印度的 IT 服务业（TCS, Infosys, Wipro）面临合同加速取消。因为 AI 编码智能体的边际成本已降至电费水平。卢比在四个月内兑美元下跌了 18%。到 2028 年 Q1，IMF 已开始与新德里进行讨论。

04.智能位移螺旋

2027 年，故事变得不再含蓄。你可以从朋友的晚餐谈话中感受到。

被替代的白领并没有坐以待毙。 他们下沉了。许多人转入了低薪的服务业和零工经济。

• 案例： 曾年薪 18 万美元的 Salesforce 资深产品经理，在失业六个月后开始开 Uber，年收入降至 4.5 万美元。

这种动态导致劳动力市场过剩，进一步压低了现有服务业工人的工资。行业性冲击演变成了全社会的工资挤压。

更危险的是滞后性。高收入者最初靠储蓄维持消费。但到了 2027 年 Q3，数据打破了幻想：

美国首次申领失业金人数飙升至 48.7 万，创 2020 年以来新高 | 劳工部

美国前 10% 的高收入者驱动了超过 50% 的消费。当这部分人因 AI 失去工作或薪水减半时，对住房、汽车、私立学校的冲击是巨大的。2% 的白领失业可能转化为 3-4% 的可选消费下降。

05.关联对赌的长链

私人信贷在 2026 年增长到了 2.5 万亿美元。大量资本锁死在 SaaS 公司的杠杆收购 (LBO) 中，这些估值模型假设收入会永久增长。

穆迪下调 180 亿美元私募支持的软件债务评级 | 2027年4月

Zendesk 成了导火索。

ZENDESK 因 AI 驱动的客服自动化导致 ARR 侵蚀，违反债务限制；50 亿美元贷款减记至 58 分 | 金融时报，2027年9月

这些公司本该有的“永久资本”实际上是美国家庭的保险金和年金。资产管理公司（如 Blackstone, Apollo）收购了寿险公司作为资金池。当底层贷款违约时，这不再只是金融精英的博弈，而是威胁到了全美普通家庭的储蓄。

这种透明度的缺乏导致了 2027 年 11 月的崩盘。美联储主席称其为“关于白领生产力增长的互相关联的对赌长链”。

06.抵押贷款问题

ZILLOW 指数：旧金山房价同比下跌 11%，西雅图 9%，奥斯汀 8% | 2028年6月

13 万亿美元的抵押贷款市场正面临威胁。这些借款人并非“次级”，而是 FICO 780 分、支付了 20% 首付、收入稳定的精英。

• 2008 年： 贷款在发放第一天就是烂账。
• 2028 年： 贷款在发放第一天是优质的，但世界在发放后改变了。

人们抵押了他们无法再负担的未来。如果抵押贷款市场全面崩溃，股市回撤可能达到 57%，使标普 500 回到 3500 点左右——这是 2022 年 ChatGPT 爆发前的水平。

07.与时间的赛跑

政府的税收基数本质上是“对人类时间的征税”。当收入流向算力而非劳动力时，IRS（美国国税局）的收入也随之崩塌。

劳动力在 GDP 中的占比从 1974 年的 64% 降至 2024 年的 56%。而在 AI 爆发的这四年里，这一数字暴跌到了 **46%**。这是历史之最。

政府面临悖论：必须在税收减少的同时，向家庭转移更多资金。

关于“过渡经济法案”和“共享 AI 繁荣法案”的辩论已经开启，包括对 AI 推理征税、建立类似主权财富基金的机制。但政治博弈滞后于现实。

与此同时，社会结构正在断裂。“占领硅谷”运动爆发，示威者封锁了 Anthropic 和 OpenAI 的总部。公众对 AI 实验室的厌恶感直逼 2008 年后的银行家。

08.人类智能溢价的终结

在现代经济史中，人类智能一直是稀缺输入。我们的所有制度——从劳动力市场到抵押贷款市场，再到税收法典——都建立在这一假设之上。

我们正在经历这种溢价的终结。机器智能成了人类智能的廉价且高效的替代品。 重新定价是痛苦且无序的。

但重新定价并不等于崩溃。经济可以找到新的平衡点。如何正确引导这一过程，是目前仅剩的、只能由人类完成的任务。

但你现在读到这篇文章不是在 2028 年 6 月，而是在 2026 年 2 月。

标普处于历史高点。负反馈循环尚未开启。作为投资者，我们仍有时间去评估投资组合中有多少假设已不再成立。作为社会，我们仍有时间主动出击。

金丝雀还活着 (The canary is still alive.)

原文链接：https://www.citriniresearch.com/p/2028gic

最近有两篇文章在国外金融圈和 X 上引发巨大讨论，甚至短暂导致部分软件股和相关股票出现明显波动。题为《The Global Intelligence Crisis（全球智能危机） 》，其作者是 Alap Shah 与 Citrini 。Alap Shah具备多年的AI行业创业及投资经验，他创立的一家 AI 驱动的金融搜索和信息平台公司以超过2亿美元的价格被竞争对手收购，Citrini Research 是一家专注于主题股权投资和全球宏观交易的独立研究机构。 这篇文章不是科幻小说，而是基于作者在 AI 公司建设和公共市场投资的20年经验，对即将到来的经济风暴的深刻剖析。本文是 对《The Global Intelligence Crisis》的第一篇《 Part 1. Part One–The Rise of Agentic AI 》主要观点的归纳，以便各位读者快速了解行业顶级洞见。

核心观点

人类智能一直是经济系统的稀缺资源，但2026年起，AI代理（Agentic AI）的爆发将颠覆这一前提，导致白领认知劳动大规模被取代。如果不采取政策干预，这可能引发一场金融危机。

引言：AI从工具到替代品的跃迁

2026年起，AI不再是辅助工具，而是“近似直接替代”人类认知劳动。现代经济建立在人类智能稀缺且昂贵的假设上——它驱动从原材料到商品服务的转化，提升生活标准。但AI代理的到来，让智能变得廉价且无限供应。这不是渐进式变化，而是指数级跃迁，可能在未来两年内造成失业冲击，规模超过工业革命、金融危机和疫情的总和。

这不是“AI末日论”——AI将带来丰裕生活、无限清洁能源和疾病根除，但我们必须先熬过经济“重定价”的痛苦期。

AI代理的定义与能力爆炸

Agentic AI不是聊天机器人，而是能自主执行复杂、多步工作流的系统。根据METR的报告，AI能独立完成的任务时长每6-7个月翻倍，目前已达14.5小时。如果趋势持续，到2028年中，AI能连续工作一个月。这不是线性增长，而是指数级。

亲历者的洞见

Shah从对冲基金分析师起步，亲历金融危机；2011年创办LOTUS基金；后来创建Sentieo，将AI用于金融信息处理，提升投资效率，最终高价出售。现在，他在Littlebird和LOTUS广泛部署代理AI。他根据自己的实践和观察，给出了关键例子：

• 软件工程：过去原型开发需一周设计+一周迭代，如今用AI 代理 几分钟生成功能原型，减少人类介入，提高发布速度。
• 投资研究：过去分析师需几天阅读文件、建模、写备忘录；现在AI连接FactSet和S&P数据库，几分钟完成类似质量的工作，成本不到人类1%。
• 组织协调：引用Ronald Coase的“企业理论”，人类协调成本是指数级的（会议、邮件、PPT）。代理AI共享完美上下文，消除摩擦——微软Office套件本质上是人类协调工具，但AI让它过时。

在公司实践中，Shah已用AI取代数据分析、迁移、设计、DevOps和客服角色，且列表每月扩展。他虽然没主动裁员（因业务在增长），但招聘已经放缓，而且在职员工每人的输出倍增。

Shah引用了其他AI行业领袖的观点：

• Anthropic CEO Dario Amodei（2025年5月）：AI可能在1-5年内消灭一半入门级白领岗位，失业率飙至10-20%。
• Microsoft AI CEO Mustafa Suleyman（最近FT访谈）：律师、会计、项目经理、市场人员等白领任务将在12-18个月内全自动化。

这些不是炒作，而是基于能力趋势的预言。

白领劳动力市场的脆弱现状

根据Shah引用的美国的数据可以看到：核心白领就业（排除政府、健康、私立教育）自2023年起停滞或下降，仅比疫情前高4%，而人口增长5%、真实GDP增长11%。信息部门（AI冲击前沿）已跌8%，低于2020水平。

企业已在AI爆发前“用更少人做更多事”。AI代理将加速这一趋势，尤其在大公司（高协调成本、稳健业务，更注重成本节约）。

供需平衡与传染风险

Shah预测：即使5%白领失业（低于AI CEO估计），也会打破平衡。失业者转向蓝领/零工，压低全经济工资；幸存者消费信心崩塌。将造成连锁反应（Part Two详述）：

• 不会自然刹车：AI进步→公司减员→白领失业，消费减少→公司加大AI投入以保持利润→循环加剧。
• AI冲击消费主力：收入最高的20%人群约占美国消费者总支出的65%。这些人就是最容易受到人工智能取代的白领。白领就业率的小幅下降对可自由支配的消费支出造成了更大的打击，摧毁了依赖它的企业，并引发了进一步的裁员。
• 中介层将最先被消融：万亿美元行业（如软件、咨询、金融、保险、房地产）靠人类摩擦赚钱；AI消除复杂性，导致营收暴跌、更多裁员。
• 金融连锁效应：美国2.5万亿私人信贷、13万亿抵押贷款是基于持续保持就业30年的基础上产生的，在白领失业后将触发违约，从而冲击金融链条。
• 政府财政恶化：政府收入本质上是对人类工作的征税。随着白领收入下降和工资减少，税收收入枯竭，而转移支付的需求将激增。政府需要在向家庭收取较少资金的同时，向家庭发放更多资金。

可能错误的点

Shah自省：如果失业是渐进的、同时AI驱动GDP出现暴增，或者像过去几次技术革命一样能创造出大量新岗位，那么他的预测将落空。但他认为，当前软件行业的趋势和AI加速的现状让“渐进”场景渺茫，因此我们需要尽快实施政策缓冲（如对AI收益征税、重分配）以应对全球智能危机。

推荐阅读原文：点击访问

1. 2026，技术管理者的“效率错觉”与破局

为什么人人都用 Copilot，交付却依然慢？

现在是 2026 年除夕，作为一名技术从业者，看到春晚里的AI和机器人元素，深切的感受到时代的滚滚洪流，过去的一年里，我相信不使用AI Coding的技术人员已经很少了，很多公司已经开始统一为研发团队配置 AI 辅助工具——从 Cursor 到 Roo Code，再到企业级的 GitHub Copilot Workspace。我自己实践下来的体感是编码速度提升了 50% 甚至 200%。

然而，根据Google公开的25年内部实践数据却是一盆冷水：整个技术部门的 Feature 交付吞吐量（Throughput）仅仅提升了 10-15%，而产品上线周期（Cycle Time）几乎没有缩短。尽管 Google 拥有全球最顶尖的工程基础设施和 AI 工具，且四分之一的代码已由 AI 生成，但整体层面的速度提升并没有人们想象中（如翻倍）那么高，仅为 10% 左右。（数据来源）

为什么？因为我们陷入了经典的“效率错觉”。

在传统的软件工程链路中，编码环节往往只占全周期的 20%-30%。剩余的 70% 时间消耗在了需求澄清、技术方案评审、跨部门 API 联调、QA 回归测试以及等待各种审批的“垃圾时间”中。根据阿姆达尔定律，如果只优化系统中占比 30% 的部分，即使该部分的效率趋于无穷大，系统整体的加速比也有其理论上限。

更糟糕的是，AI 带来的海量代码产出，反而阻塞了下游的测试和评审通道，制造了更大的瓶颈。个体跑得越快，却更猛烈地撞上了传统协作流程这堵“人肉墙”。

别给马车装喷气引擎

正如我在上一篇文章中写到的一样，我们必须认清一个残酷的现实：给传统的敏捷开发或瀑布流流程加上 AI 代码助手，只是在造一辆“跑得更快的马车”。

过去两年的实践证明，单纯的 Copilot 模式（人主导，AI 辅助）无法解决软件工程中 $N \times M$ 的沟通复杂度。当一个需求需要前端、后端、DBA 和运维四方协同，且每个人都依赖碎片化的上下文时，AI 辅助代码生成带来的那点时间节省，瞬间就被一次无效的跨部门会议吞噬了。

技术决策者面临的真正命题，不再是“如何让员工写代码更快”，而是“如何用多智能体重构团队的业务流与系统架构”。我们需要从根本上改变生产关系。

Agent 编排元年

2025 年被行业公认为 Agent 元年，而 2026 年则是企业级 Agent 编排的爆发期。

根据 IDC 和 Gartner 的最新预测，AI Agent 正在从 L2（Copilot）向 L3（Agentic Team）进化。我们正在见证研发组织形态的根本性跃迁：从“碳基团队 + 辅助工具”向“硅基主导执行 + 碳基负责仲裁”的混合编排演进。

在这个新范式下，真正的价值不再产生于单体模型（Model），而产生于系统（System）——即通过精妙的架构设计，让一组专业化的 Agent 能够像一支训练有素的特种部队一样，自主完成从需求分析到代码部署的闭环。

2. 组织变革：适配“硅基劳动力”的形态重塑

技术架构的变革必然要求组织架构的适配。当你的团队中混入了成百上千个不知疲倦的“数字员工”时，传统的层级式管理将面临崩溃。

核心挑战：缺失的控制平面

麦肯锡与 IBM 的联合调研数据显示，尽管 70% 的企业在 2026 年已部署了 AI Agent，但仅有不足 7% 的企业实现了全公司级的规模化应用。阻碍 Agent 规模化的最大障碍不是模型不够聪明，而是缺乏组织级的治理控制平面（Control Plane）。企业如果允许 Agent 在业务中野蛮生长，将导致严重的后果：

• 资源浪费：没有统一调度的 Agent 陷入死循环，消耗巨额 Token 成本。
• 数据安全：缺乏权限管控的 Agent 随意访问敏感数据库。
• 协作冲突：不同部门的 Agent 互相覆盖配置，导致系统故障。

因此，组织变革的第一步，是建立一个统一的 Agent 控制平面，像管理微服务一样管理数字员工。

角色重塑：人人都是AM (智能体经理)

随着 L3 级协作型 Agent 的普及，人类员工的职能将发生质变。麦肯锡预测，未来的工作模式将是“人类 + AI Agent + 机器人”的深度协作。

• 从“执行者”到“管理者”： 传统的初级工程师如果只懂写 CRUD 代码，将失去价值。他们必须转型为智能体经理或提示词工程师。他们的工作重心将从“手动执行任务”转向“定义任务目标”、“配置 Agent 工具”以及“审核 Agent 产出”。
  • 旧日常：自己写 500 行代码实现一个 API。
  • 新日常：编写详细的 Spec，指挥 Coding Agent 实现 API，指挥 Testing Agent 生成测试用例，最后由自己进行 Code Review 和架构把关。
• 从“架构师”到“编排师” ： 高级工程师和技术专家的职责将演变为多智能体编排师。他们需要设计 Agent 之间的交互协议（SOP），定义什么时候该由 Planner Agent 拆解任务，什么时候该由 哪个Executor Agent 执行，以及在出现幻觉时如何通过 Reflector Agent 进行自我修正。
• 新设岗位：Agent 团队负责人： 企业将设立专门的ATL岗位来负责 Agent 资源的调配、任务分配策略的优化以及QA。这个角色类似于现在的 DevOps 负责人，但管理对象从服务器变成了智能体。

组织架构：碳硅混合团队

未来的团队将不再是7～11 个人的披萨团队，而是“2-3 名人类核心成员 + 10多个特定职能 Agent”的混合编排。其核心逻辑是：

1. 人类：负责战略规划、处理模糊的边缘情况、进行价值判断以及最终的合规审核。
2. Agent：负责执行、优化、自我检查以及 7x24 小时的即时响应。

例如，在一个采购小组中，人类负责制定季度的库存策略，而一个由“预测 Agent”、“采购 Agent”和“物流调度 Agent”组成的硅基团队则负责实时的订单处理和异常调整，仅在遇到不可抗力（如疫情封控）时呼叫人类接管。

3. 重构企业技术架构

为了支撑上述的组织变革，技术决策者必须在架构层面进行大刀阔斧的重构。根据 AWS、Google 和 Gartner 的最新架构指引，我总结了重构企业技术架构的四大战略支柱。

（1）标准化集成——拥抱 MCP 协议

在 2024-2025 年，连接 LLM 与企业内部数据（数据库、SaaS、代码库）是一场噩梦。每个新的 AI 应用都需要单独开发 Connector，导致了指数级增长的 $N \times M$ 集成复杂度。

战略动作：全面采纳 **Model Context Protocol (MCP)**。

• 什么是 MCP：MCP 是 AI 时代的 USB-C 接口。它是一个开放标准，允许企业构建一次性的“MCP 服务器”来暴露数据和工具，所有支持 MCP 的客户端（如 Claude、Cursor 或自研 Agent）都可以即插即用。
• 架构收益：
  • 解耦：将数据层与模型层解耦。更换大模型（如从 GPT-5 换到 DeepSeek-V3）无需重写集成代码。
  • 安全性：MCP 协议内置了清晰的权限模型。企业可以控制 Agent 只能读取特定的 Resource（如只读日志）或执行特定的 Tool（如只许在测试环境部署），从而在协议层实现“治理即代码”。
• 落地建议：不要再为每个 Agent 写 Python 脚本去调 API。立即着手搭建企业的 MCP Gateway，将内部的 Postgres、Jira、GitLab 等核心资产通过 MCP 协议标准化暴露。

（2）多智能体编排

单体 Agent受限于上下文窗口和推理能力的边际递减效应，无法处理复杂的长链条任务。2026 年的主流架构是多智能体协作网络。

战略动作：实施 “Supervisor - Worker” 架构模式。

• 架构设计： 参考 AWS 和 LangGraph 的设计模式，构建分层架构：
  • **Supervisor Agent (大脑)**：拥有高推理能力的 LLM（如 o1 或 Claude 3.5 Opus）。它不直接干活，只负责理解模糊目标，将其拆解为子任务，并分发给 Worker。它还负责维护全局状态（State）和监督进度。
  • **Worker Agents (手脚)**：专注于特定领域的窄模型或工具 Agent。例如，“SQL 写手”、“文档生成器”、“API 测试员”。它们使用更便宜、更快的模型（如 GPT-4o-mini 或 Llama 3）。
  • 通信协议：采用 A2A 协议，允许 Agent 之间进行去中心化的协商。例如，测试 Agent 发现 Bug 后，直接通过 A2A 协议将上下文传回给开发 Agent 要求重修，而无需人工介入。

（3）认知数据底座

传统的 RAG（检索增强生成）只是静态的图书馆，Agent 查完即走，没有“经验积累”。

战略动作：构建 Agentic Memory 系统。

• 技术升级：
  • 长期记忆：利用向量数据库存储 Agent 的历史行为、决策路径和用户偏好。
  • 过程反思：在架构中加入“反思环”。每次任务结束后，Agent 自动总结“做对了什么，做错了什么”，并将这些经验写入知识库。下次遇到类似任务时，先检索经验，再执行。
• 数据飞轮： 打通数据闭环，让 Agent 在使用中产生的数据（如修正后的 SQL、成功的 API 调用参数）经过清洗后回流，用于微调更小的专用模型，实现越用越聪明。

（4）统一控制平面与治理

当成百上千个 Agent 在企业网络中游走时，可观测性和安全围栏是生命线。

战略动作：部署 Agent Control Plane。

• 核心功能：
  • 统一仪表盘：查看所有 Agent 的运行状态、任务进度和 Token 消耗。
  • 人工介入接口：在关键操作（如转账、删库、发布生产环境）前，协议层强制挂起任务，发送审批请求给人类管理员，获批后方可继续。
  • 审计与回溯：记录 Agent 的每一步思考过程和工具调用参数，确保合规性和可追溯性。

4. 技术团队的“分步硅基化”

企业重构无法一蹴而就。基于 Gartner 的成熟度模型和 Google 的实践经验，我建议采用三阶段演进路线：

Phase 1: 试点期

• 目标：验证 ROI，跑通 MCP 流程。
• 场景选择：选择规则相对明确、容错率较高、独立性强的场景。例如：自动化代码审查、智能日志分析、内部 IT 帮助台。
• 动作：
  • 部署 1-2 个基于 MCP 的工具连接器。
  • 使用现成的框架构建单体 Agent。
  • KPI：任务自动化率 > 50%，人工干预时间减少 30%。

Phase 2: 平台期

• 目标：建立标准化基础设施，支持多 Agent 协作。
• 动作：
  • 搭建企业级 MCP Gateway，统一数据接口标准。
  • 开发“Agent 模板工厂”，让业务部门可以通过低代码方式组装 Agent。
  • 引入 Supervisor 模式，尝试跨职能协作（如：需求文档 $\rightarrow$ 代码生成 $\rightarrow$ 自动测试）。
  • 建立 Agent 治理委员会，制定权限和安全规范。

Phase 3: 生态期——“多体协同” (Agent Ecosystem)

• 目标：业务流重构，实现端到端自治。
• 动作：
  • 全面部署 A2A 协议，打通 ERP、CRM、DevOps 等系统间的 Agent 通信。
  • 实施动态资源调度，根据任务优先级自动扩缩容 Agent 集群。
  • KPI：复杂业务流程的全自动闭环率 > 80%，组织交付效率提升 300%。

5. 技术管理者的反思

在迈向 Agentic AI 的过程中，我们必须高度警惕：能力陷阱、伪需求陷阱与可靠性陷阱。

• 能力陷阱：年轻开发者过度依赖 AI 生成代码，导致失去了对系统底层的理解能力和排错能力。一旦发生 AI 产生的复杂逻辑错误（幻觉）或发生线上 P0 级事故，无人能看懂机器生成的复杂调用链路。

• 伪需求陷阱：为了 Agent 而 Agent。将原本用一个简单 Python 脚本或 RPA 就能解决的固定流程（如每天定时抓取数据），硬套上大模型，导致运行成本飙升且不确定性增加。要坚持 ROI 导向，采用“RPA + Agent”模式，RPA 处理稳态流程，Agent 处理例外情况。

• 可靠性陷阱：Agent 在 Demo 时表现完美，但在生产环境中遇到边缘情况时陷入死循环，或者一本正经地胡说八道。要强制要求 Agent 在执行前先输出计划（Plan），经由 Supervisor 或人类校验通过后再执行，并且在控制平面设置严格的重试次数限制。一旦超时或失败，立即优雅降级（Graceful Degradation），转由人工接管，防止故障扩散。

6. 结语

技术团队的边界正在消融。未来的卓越技术 Leader，其麾下不仅有优秀的工程师，更有成百上千个不知疲倦、持续进化的硅基智能体。

2026 年，企业级 AI 的竞争将不再是“谁的模型参数更大”，而是“谁的 Agent 编排落地能力更强”。

这场变革不是关于替代，而是关于增强。它将人类从重复的、低价值的“数字搬运”工作中解放出来，去专注于架构设计、复杂决策和创新思考。赢家不是拥有最多算力的公司，而是最先掌握“如何指挥硅基军团”这一新管理艺术的组织。

拥抱硅基！

在这个大模型狂飙突进的时代，最近看到身边的小伙伴们都在如火如荼的学习使用AI Coding，我也深度使用了多个AI编程工具，借助 GitHub Copilot、Cursor、Roo Code 这样惊艳的 AI 编程工具，原本需要三天写完的模块，现在可能半天就能搞定。效率提升是肉眼可见的，但这种狂欢背后，我隐约感到一种不安，我们要的真的是“更快的写代码”吗？

我们是不是正在用最先进的“内燃机”，去疯狂地改进一辆“马车”？

01 无马的马车

历史总是惊人的相似。

当内燃机刚刚被发明，汽车工业萌芽初现时，人们的第一反应并不是设计出今天我们看到的流线型汽车。当时的人们做了一件顺理成章的事：把内燃机装在马车上，试图制造一种“自动跑的马车”。

因为马车是当时社会的“默认形态”。道路是为马车修的，人们习惯了马车的结构。所以，早期的探索者们致力于用新技术去模拟旧形式。

今天，我们可能正在软件行业重演这一幕。

看看现在的 AI Coding 落地场景：我们用 Gemini 3 Pro 去生成服务端代码，去写单元测试，去优化 SQL 查询，去构建更复杂的 Vue 组件。

我们在做什么？我们在用具有概率性、创造性、理解力的新一代动力核心（大模型），去驱动一种确定性、死板、流程化的旧载体（传统软件）。

我们生产软件的速度快了十倍，但软件的形态变了吗？没有。它依然是由数百万行代码堆砌的、需要编译部署的、有着固定菜单和按钮的、一旦需求变更就需要推倒重来的“马车”。

02 软件的本质

如果马车的本质不是“车轮和车厢”，而是“位移”；那么软件的本质也不是“代码、GUI 和数据库”。

我们不应该花大量的时间、精力、算力，去让传统软件被生产得越来越快，而是应该停下来问一问：传统软件到底解决的是人类的什么问题？

本质上，人类发明软件是为了满足四大需求：

1. 处理信息： 从古代的账本到现代的BI系统，我们需要搜索、组织、过滤和分析数据。想想Excel或搜索引擎，它们本质上是在帮我们应对信息爆炸。
2. 自动化任务： 将重复劳动转为自动流程。从最早的计算器到如今的脚本和自动化管道，这让人类从琐事中解放。
3. 连接与创造： 跨越时空的沟通与内容生成。从电报到社交网络，再到现在的协作工具，这扩展了我们的社会边界。
4. 增强能力： 我们需要外脑，扩展人类的认知、记忆与决策边界，软件帮我们记住、推理和预测。

现在的 AI 编程热潮，更多是在加速“制造工具”的过程（写代码），而不是直接加速“满足需求”的结果。我们在给马车换上钛合金轮毂，却忘了我们的初衷是想去远方。我们优化了生产，却忽略了需求的本质重塑。

03 过渡期及风险

当然，我并不是在否定当前的 AI 辅助编程。

这是一个必要的过渡阶段。 基础设施依赖是关键：早期的道路是为马车设计的，现在的互联网基建——云平台、终端设备、操作系统——都是为传统App量身定制的。直接跳到纯AI驱动的系统，会面临兼容性问题。认知惯性也发挥作用：用户习惯了点击图标启动App，程序员习惯了写函数和调试循环。贸然引入“全自动AI”可能会引发信任危机——谁敢把关键业务交给一个黑盒子？安全问题更是大山一座。

所以，这是一个不可逾越的“中间态”。我们需要AI辅助来维持现有系统的运转，就像内燃机初期，人们还得用它拉马车过日子。我们用AI加速迭代旧系统，这确实帮我们节省了成本，快速响应市场。

但是，如果我们满足于此，风险将是巨大的：

• 对于企业：资源错配的浪费。 我们在燃烧昂贵的 GPU 算力和巨大的能源，仅仅是为了生产出更多功能过剩、体验割裂的 传统软件。一旦“汽车”出现，这些马车将会快速贬值。
• 对于个人：技能退化的隐忧。 当程序员变成只会按 Tab 键的“代码监工”，我们正在失去对底层逻辑的掌控力。一旦车辆抛锚（AI 幻觉或复杂逻辑错误），我们将束手无策。
• 对于用户：软件膨胀的陷阱。我们会看到“App数量爆炸”——更多更快的产品，却无法解决信息过载和交互低效的根本问题。用户在海量App中切换，效率反而降低了。

04 寻找“汽车”

如果不做“更快的马车”，那么属于 AI 时代的“汽车”到底长什么样？我尝试分享我的展望：

1. 服务流 现在的软件是建筑，盖好了就很难改。未来的软件应该是水。 软件的概念将消失，取而代之的是服务流。需要时，AI实时生成界面和逻辑；用完即走，无需安装或更新。就像Uber，不是一个App，而是一个随时调用的服务。

2. 意图驱动 ** 现在的软件界面是让人去学习的。你要记住“设置”在右上角，“导出”在二级菜单。这是人在适应机器的逻辑。 真正的 AI Native ，应该是机器去理解人的自然语言，它将没有固定的 UI。界面是根据你的意图**实时生长出来的。你想要订票，屏幕上就只出现行程确认；你想要修图，屏幕上就只出现你需要的那个效果滑块。

3. 自适应生态 软件将从被动的工具，进化为主动的代理。它不再等着你点击按钮，而是能理解甚至预测你的需求，拆解任务，自我纠错，跨应用协作。比如，你的“个人AI助理”能整合邮箱、日历和健康数据，主动建议日程调整。

价值重塑随之而来：未来的核心竞争力不再是“谁代码写得快”，而是“谁能定义并精准描述问题”。

05 结语：别做“马车夫”

我们正处在技术范式转移的十字路口。

眼前的繁荣——那些用 AI 快速生成的代码、那些快速迭代的软件——可能只是旧时代的余晖。

我们既要脚踏实地，利用好 AI 解决当下的实际问题；更要时刻警惕不要陷入路径依赖。这二十年来，我们见过太多技术泡沫，从大数据、云计算、物联网到区块链，每次浪潮都提醒我们，真正的价值只在于本质创新。

当 AI 能够以毫秒级的速度生成代码时，我们是否正在通过训练 AI 来取代自己？本文不贩卖焦虑，我将基于自身身处浪潮之中的切身感受，探讨在 LLM 重构软件开发的当下，中高级开发者应该如何应对。

引言：焦虑与机遇的叠加态

我们正处于软件行业的一个拐点。

Stability AI 的 CEO 曾指出，AI 在 2024 年就已经生成了超过 40% 的代码。随着 GitHub Copilot、Cursor 和 DeepSeek 等工具的普及，“写代码”这一行为的边际成本正在无限趋近于零。

这种现象引发了广泛的焦虑：开发者是否会沦为流水线上的“开关操作员”？甚至像 Matt Welsh 激进预言的那样，我们将面临“编程的终结”？

然而，这种焦虑往往混淆了两个概念：Coding 与 Engineering。

我的看法是：编程语言的语法正在极速贬值，但工程能力却在大幅升值。 在 AI 能够以此生成数千行代码的时代，如果你只满足于做一个熟练的“砌砖工”，你将面临巨大的替代风险；但如果你能转型为驾驭复杂系统的“建筑师”，这将是你的黄金时代。

变：被 AI 重塑的开发范式

AI 并非简单的效率工具，它正在根本性地重塑我们的工作流和思维模式。Andrej Karpathy 曾提出 Software 2.0 的概念，即神经网络权重正在取代传统逻辑代码。而在今天，这种变化更加具体：

1. 交互方式：从“人适应机器”到“机器适应人”

Andrej Karpathy 断言：“英语将是最热门的新编程语言”。在 AI 时代，我们不再纠结于变量、分号和缩进，而是通过自然语言表达意图，然后由 AI 来生成代码。这是计算史上第一次，机器开始适应人类的语言，而非反之。

2. 能力迁移：从“写作”到“鉴赏”与“编排”

• 写作 ➔ 鉴赏：过去，我们的核心价值是“写出无 Bug 的代码”。现在，AI 可以生成看似完美实则脆弱的“纸牌屋”代码。我们的核心价值转变为 Code Curation：我们需要具备极高的鉴赏力，能够快速 Review 并精准定位 AI 生成的逻辑漏洞和安全隐患。
• 构建 ➔ 编排：以前我们从零造轮子，现在的开发越来越像是指挥一个由 AI Agents 组成的团队。Developer 正在转变为 Orchestrator，通过将任务分解并分配给不同的 Agent 来完成复杂工作。

3. 信任边界：从“确定性”到“概率性”

传统的编程是确定性的，而 LLM 是概率性的。这意味着我们不能再盲目信任代码的输出。

我们需要建立新的验证闭环，以前让大家头痛的 TDD（测试驱动开发） 成为 AI 时代构建软件的必备方法，因为我们要确保其行为符合预期。当然，测试代码和测试执行也是由 AI 担当。

不变：穿越周期的核心壁垒

尽管 AI 甚至能写出让人叹为观止的 Python Project，但以下三大基石是 AI 在短期内无法逾越的，也是资深程序员真正的护城河。

1. 复杂度管理

AI 是一个不知疲倦的初级程序员，它倾向于为了实现功能而堆砌代码，缺乏对系统长期可维护性的考量。如果没有资深工程师进行架构设计、解耦和模块化管理，AI 生成的代码库将迅速退化为不可维护的屎山。系统设计，依然是人类的绝对领地。

2. 领域知识与上下文工程

代码只是逻辑的载体，真正的价值在于对业务的理解。AI 不懂“为什么这笔交易需要 T+1 结算”，但我们懂。现在的关键技能是 Context Engineering：如何将业务规则、遗留系统的“特性”以及非功能性需求，通过 MCP 等标准准确地喂给 AI。如果我们无法清晰地向 AI 描述业务背景，AI 就无法生成正确的代码。

3. 经验直觉

METR 的研究发现，在处理复杂任务时，资深开发者使用 AI 反而可能慢了 19%。

为什么？因为理解和调试 AI 生成的复杂代码往往比自己写更难。当系统崩溃、AI 开始“胡说八道”时，只有深厚的底层原理知识（网络协议、内存管理、数据库并发控制）才能让你看穿现象，定位本质。

破局：加减乘除法清单

为了从 10x 开发者进化为 AI 时代的 100x 开发者，我们需要对技能树进行一次彻底的重组：

➖ 减法：放弃低杠杆活动

• 放弃死记硬背语法糖：不要再以背诵类名方法、API 参数为荣。AI 是最好的检索器和生成器。
• 放弃对“平庸代码”的执念：对于样板代码、单元测试骨架、CRUD 接口，要放手让 AI 去写，接受“足够好”的结果，不要有洁癖。
• 摒弃技术鄙视链：不要排斥低代码或 AI 生成的代码。如果 AI 能在 20 分钟内替换掉一个微服务，那就用它。

➕ 加法：掌握新时代的工具与思维

• 理解 AI：不仅仅是会用 ChatGPT。我们需要懂得 Prompt Engineering 的原理（如 Chain-of-Thought），理解 RAG 怎么运作，以及如何规避幻觉。
• 架构思维：既然代码生成成本降低，我们需要花更多时间在系统设计上。设计容错率高、模块化清晰的系统，以便 AI 能够安全地在其中填充细节。

✖️ 乘法：强化软技能与沟通力

• 精准的技术规范能力：这是指挥 AI 的前提。AI 是一个执行力极强但理解力有限的实习生。我们需要能够将模糊的业务需求，转化为精准、无歧义的技术文档或 Prompt。
• 沟通力即生产力：在人机协作和人际协作并存的时代，清晰表达意图的能力被无限放大。

➗ 除法：分解复杂度

• 任务拆解能力：学会将一个宏大的目标（如“做一个电商网站”）拆解为 AI 可以执行的原子任务（如“生成一个符合 OpenAPI 规范的用户登录接口”）。这是 AI 时代 Commander 的核心能力。

结语：从 Coder 到 Commander

Sam Altman 曾说过一句被广泛引用的话：

“AI 不会取代人类，但使用 AI 的人将取代不使用 AI 的人。”

在这个新时代，我们不需要为“不再写代码”而感到悲伤。相反，我们应该感到兴奋，因为我们终于从繁琐的语法细节中解放出来，可以专注于解决真正的问题。

未来的开发者，身份将从 Coder 蜕变为 Commander。我们将指挥 AI 代理军团，去构建那些在纯手工编码时代无法想象的宏大系统。

保持好奇，回归解决问题的本质。

工程的黄金时代，才刚刚开始。

作为一名在技术圈摸爬滚打二十年的老兵，我最近在面试和团队管理中发现了一个有趣的现象：技术的门槛正在崩塌，但职业的护城河却在变深。

现在的职场存在一种普遍的错觉：很多人觉得注册了 ChatGPT、DeepSeek，学会了几句“提示词（Prompt）”，就算是拥抱 AI 了。但在我看来，这只是停留在了“玩具阶段”。真正且深刻的变革正在水面之下发生——我们正处于从“人机对话”向“智能体协作（Agentic Workflow）”转型的关键节点。

2026 年的职场，不会淘汰那些不懂复杂代码的人，但会淘汰那些缺乏“AI 编排力”的人。对于非技术背景的专业人士来说，你们不需要成为程序员，但必须成为自己工作流的“系统架构师”。

以下是我基于行业趋势，为致力于构建核心竞争力的专业人士梳理的一份转型路线图。

-—————————————————-

一、 认知重塑：从“T型”人才向“Π型”人才进化

过去我们推崇“T型人才”（一专多能），但在 AI 时代，这个模型正在失效。

为什么？因为 AI 最擅长的就是“广度”。它可以瞬间填补你原本引以为傲的那个“横向”知识面。如果你的核心竞争力仅仅是“什么都懂一点”，那么面对拥有海量数据的 AI，你将毫无胜算。

你需要进化为 “Π型人才”（拥有两条深度的腿）：

1. 左腿：你的行业洞察（默会知识）这是你的“根”。你在市场、法律、财务或运营领域积累的那些“直觉”、对复杂人际关系的判断、对行业潜规则的理解，这些是默会知识（Tacit Knowledge）。目前的大模型主要学习的是显性知识，通过书本和网络能查到的东西，AI 学得比你快；但那些“只能意会不可言传”的经验，是你对抗算法的护城河。

2. 右腿：AI 流利度与编排能力（AI Fluency & Orchestration）这不是要求你去写 Python 代码，而是要求你具备驾驭 AI 工具解决复杂问题的能力。这不仅仅是会提问，而是懂得如何将 AI 嵌入到你的业务流程中，让它成为你的“数字化外骨骼”。

哈佛商学院的研究提出了两种高效的人机协作模式，值得你参考：

• 半人马模式（Centaur）： 像神话中的半人马一样，人与 AI 分工明确。例如，战略思考由你负责，数据处理和图表生成交给 AI。

• 赛博格模式（Cyborg）： 人机深度交织。你写一句，AI 补全三句，你再进行纠偏和润色。这种模式下，你的产出效率和质量将实现指数级跃升。

-—————————————————-

二、 技能重构：非技术人员的四门必修课

如果把你的职业生涯看作一款产品，那么你需要在这个版本更新中加载以下四个核心模块：

1. 从“提示工程”进阶到“语境工程” (Context Engineering)

很多初学者沉迷于寻找“完美的提示词模版”，这其实是战术层面的勤奋。战略层面的核心在于“语境（Context）”。

AI 产生幻觉或回答平庸，通常是因为缺乏上下文。未来的核心技能是懂得构建信息环境。你需要学会整理你的私有知识库（会议纪要、行业数据、过往案例），并通过RAG（检索增强生成）技术投喂给 AI。

实战建议： 尝试使用 NotebookLM 或 Claude 的长文档分析功能。不要只问 AI “怎么写营销方案”，而是把你们公司过去三年的成功案例喂给它，让它“基于这些风格和逻辑，结合当前市场趋势，生成新方案”。

2. 掌握“工作流编排” (Workflow Orchestration)

AI Agent（智能体）时代已经到来，未来的工作方式不再是单点操作，而是链路自动化。

你需要具备一种“工程化思维”：如何将一个复杂的业务目标，拆解为 AI 可以执行的步骤？例如：当收到客户询价邮件（触发） -> AI 读取并提取需求 -> 检索库存 -> 生成报价草稿 -> 发送给我审核 -> 审核通过后自动回复。

工具推荐： 关注 Zapier、Make 或国内的 Coze（扣子）。这些低代码/无代码平台允许你通过拖拽组件，像搭积木一样构建这种自动化流水线，而无需编写一行代码。

3. 培养“人机回环”的审核能力 (Human-in-the-Loop)

随着 AI 产出效率的提升，你的角色将从“创作者”转变为“主编”和“合规官”。

AI 模型本质上是概率预测机器，它不懂真理，只懂概率。因此，批判性思维（Critical Thinking）****和****事实核查（Fact-Checking）能力变得前所未有的重要。在医疗、法律、财务等高风险领域，这种“最后把关人”的角色是 AI 无法替代的。你必须有足够深厚的专业功底，才能一眼看出 AI 一本正经胡说八道的地方。

4. 捍卫“人类溢价”：软技能的硬核化

当 AI 能以零成本生成完美的商务邮件和报告时，信任就成了稀缺资源。

同理心、谈判能力、跨部门的政治协调能力、以及定义复杂模糊问题的能力，这些过去被轻视的“软技能”，现在是职场的硬通货。AI 无法在饭局上搞定一个犹豫不决的客户，也无法在激烈的部门冲突中平衡各方利益。你的“人味儿”，是你最高的溢价。

-—————————————————-

三、 行动指南：启动你的“AI 飞轮”

不要试图一口吃成胖子。我建议你按照“最小可行性产品（MVP）”的思路，分阶段升级你的工作系统：

阶段一：识别“高耗低效”环节（第1周）对你的工作进行一次“审计”。找出那些重复性高、消耗精力大、但决策密度低的任务（如发票录入、会议纪要整理、初级数据清洗）。这就是 AI 切入的最佳突破口。

阶段二：搭建单点 AI 助理（第1个月）不要一上来就搞复杂的系统。先用 AI 解决一个具体痛点。

• 场景示例：利用 AI 工具将一小时的会议录音转录并提炼成“Action Items（待办事项）”；或者用 AI 辅助阅读几十页的行业报告，快速提取核心观点。一旦你体验到了效率提升的甜头，你的思维方式就会自然转变。

阶段三：构建个人信任信号（长期）在 AI 生成内容泛滥的时代，你需要建立属于你的数字信任。在公开表达中，多分享带有你个人独特观点、失败经验和真实案例的内容。让你的合作伙伴和客户感受到，屏幕后面是一个鲜活、有担当的人，而不是一个 API 接口。

-—————————————————-

结语：从工具的奴隶到系统的主人

接下来几年的职场分水岭已经很清晰了：不是 AI 会取代你，而是“善用 AI 的人”会取代“拒绝 AI 的人”。

未来的核心竞争力公式或许可以总结为：竞争力 = (行业深度经验 × 决策主权) + (AI 素养 × 自动化编排)

请记住，作为人类，我们的终极价值不在于像机器一样高效地执行，而在于定义问题、在于判断价值、在于连接人心。掌握 AI，是为了将自己从繁琐的事务中解放出来，去从事那些真正需要人类智慧的战略性工作。

祝你在这次技术浪潮中，不仅能站稳脚跟，更能乘风破浪。

2026年，“十五五”开局，国家数据局将今年定为“数据要素价值释放年”，越来越多的人开始谈论可信数据空间（Trusted Data Space, TDS），将其视为继关系型数据库、湖仓一体之后，数据组织范式的第三次革命。我认同这个判断，它不像是一种单纯的技术升级，更像是在重塑数据流通的生产关系。

一、范式迁移：从“孤岛”到可流动的“活性单元”

要理解这场革命，不妨回顾一下历史。过去的数据，像图书馆里的书，编好目放在固定的书架上（关系型数据库），应用必须自己来“借阅”。这造成了大量的“数据孤岛”。

后来，我们建起了超级仓库（湖仓一体/云存储），把所有数据都集中存起来。虽然计算方便了，但数据必须物理搬迁，权属和安全成了新麻烦，本质上只是把“孤岛”集中成了“数据大陆”，流动性问题没解决。

现在的思路变了。在可信数据空间的范式中，数据不再是被动存储的“货物”，而是变成了分布在各处、权属与安全规则内嵌的 “活性单元” 。它可以在不离开自家“保险柜”的前提下，被安全、可信地组合与使用。这从根本上动摇了“数据必须集中才能使用”的旧逻辑，瞄准的正是“不敢供、不可信、流不动”的行业痛点。

二、2026：从“画蓝图”到“交答卷”

纸上谈兵的阶段过去了。2026年，我感觉是可信数据空间规模化落地的一个关键检验点，标志性动作就是 “标准引领”与“试点先行”的双线并进。

首先是标准体系的成型。今年要推出30多项数据领域的国家标准。值得关注的是，标准已经不再局限于基础的存储和管理，开始前瞻性地触及智能体（Agent）数据接口、具身智能数据集等前沿地带。这意味着，标准在为未来的AI模型准备高质量的“燃料”，引导力很强。

其次是“三位一体”的试点全面铺开（企业、行业、城市）。这种打法很务实，不再是单一场景的Demo，而是在构建生态。

• 企业侧：考验的是龙头企业的产业链协同能力，做数字化供应链。
• 行业侧：重点在医疗、能源这些高价值、高门槛的领域，目标是构建共建共治的行业知识库，这在过去几乎不可能。
• 城市侧：南京的实践是个很好的注脚。通过可信数据空间融合企业社保、工商、经营流水等多方数据，推出纯信用贷款。关键不是技术，而是通过技术实现的“信任”，让银行敢贷，让企业能快速（据说效率提升30%）拿到钱。这才是数据价值的真实兑现。

三、技术底座：融合之道

支撑数据“活性单元”流动的，是一套融合的技术栈。在我看来，它正在形成一个技术-治理-标准（TGS）的稳定三角。

• 区块链是“信任锚”：它为数据的每一次流转提供不可篡改的“存证”，解决“出事可追责”的问题，是确权的技术基础。
• 隐私计算是“保险柜”：以联邦学习、零知识证明为代表，目标是 “数据可用不可见” 。横琴跨境医疗数据空间的例子很典型：几家机构协作训练模型，准确率达到92.33%，但谁也没看到对方的原始病人数据。这是用密码学创造的新型信任。
• 确定性网络是“高速公路”：毫秒级的精准控制网络，是面向智能体协同、工业互联网等高阶应用时必须的基础设施。没有它，“活性单元”的流动速度和可靠性就无法保障。

四、产业竞速：巨头的不同路径

大厂的动向永远是风向标。在这一新范式下，各家切入点明显不同，反映的是各自的基因。

• 华为：讲的是 “城市一张网” ，做的是可信数据流通的联接底座，依然是其擅长的“管道”和“平台”思路，格局宏大。
• 阿里巴巴：从自身场景（本地生活）切入，用AI大模型（如通义万相）去重构体验，比如自动生成3D餐厅展示。它的路径是“AI驱动数据价值再发现”，很务实，离商业很近。
• 中移互联网：推出了“梧桐数盾”，主打隐私计算+数字合约。运营商手握海量数据但敏感度极高，它的方案更侧重于解决跨域流通中最核心的信任壁垒，切入点很精准。

结语：价值释放的本质

按照规划，到2028年要建成超过100个可信数据空间。2026年这个“释放元年”，究竟在释放什么？我的理解是，它正在纠正一个误区：数据不是“挖出来就值钱”的石油。

它的价值，只有在能够被可靠地计量、合规地使用、安全地流通，并且在出现问题时可以清晰地追责时，才能真正转化为生产力。可信数据空间，本质上就是一套为数据价值“护航”的工程化体系。它的成熟，意味着数据要素市场从“基础设施建设期”，真正迈入了“规模化运营期”。

路还长，但方向已经清晰。

好久没写文章，上一篇漫谈还是3年前写的关于产品管理的认知。在大型创业企业里工作了4年有余，各方面都有不少实践，有弯路也有成绩，便想将一点浅薄的见解记录下来，也算是复盘与反思。这篇文章说一下研发项目管理方面，后续还有交付项目管理、技术管理、科技创新管理、政府课题管理等诸多思考，待有时间再写出来，真的能成为一个系列了。是不是可以出个专栏？

研发项目管理

还是得理清一下定位。研发项目管理有两个层面，一个是项目经理的层面，一个是公司的层面。项目经理关注的是如何在约束内将项目目标达成。这不是本文的重点，在这里我想聊的是公司层面的研发项目管理。

关于研发项目

所有项目都是组织资源的一种形式。企业将研发资源采用项目的形式组织起来的目的是什么呢？想明白这个问题，就能想明白企业到底要不要开展研发项目管理（因为管理总会带来成本）以及侧重点是什么。因此同样是研发项目管理，各个企业的管理模式也会有所不同，这就是因为目的不同，生搬硬套，反而适得其反。

一般来说，研发项目存在的目的主要有：

• 上级或者外部的管理要求。比如为了做资本化、为了后续审计、为了申报企业资质或者财税政策等。

• 相对准确的管理投产。通过设立项目，在财务上去做成本归集，配合产品管理，去衡量评价资源收益率，持续改进资源效益。

• 形成共同体，提高任务达成的成功率。将资源从纵线里抽调出来，形成一个临时性组织，给与这个组织一个愿景，并以实现这个愿景为目的去驱动组织运转。

关于管理侧重点

因此当我们去开展研发项目管理，首先就要想明白我们是为了什么？

• 如果只是管理要求，那就只需要在纸面上做规范、漂亮，要尽量减少对一线员工的打扰和负担。

• 如果是公司产线很多，想将单产线回报算清楚，那开展的项目管理要以code为主，围绕code来做好工时、费用、成本的归集。

• 如果任务重要性高或复杂性高（比如要攻坚克难）抑或组织复杂性高，比如研发人员规模达到70人以上涉及到跨部门的需求-产品-研发-测试-交付协作，这个时候的研发项目管理就是一种常规的组织形式，那么此时管理的重点就是流程的规范性和监控机制。

即使在第三个层次，具体到管理侧重点也应该根据企业的情况有所取舍。

• 研发项目成员总是来自很多部门的，应该将项目经理的授权过程设置的非常正式（比如发红头文件），要将启动会作为必须召开的重要会议，要制定并落实项目和项目成员绩效管理。
• 业务部门和研发部门分离的，应该规范需求过程，制定标准的需求规格说明书模版，要将需求评审会作为必须召开的重要会议，要制定阶段性需求验收的管理要求，开展业务部门针对研发成果的UAT，要定义明确研发成果的发布过程。
• 业务产品研发一体化的，应该加强立项、结项、变更管理，引入第三方部门作为立项、结项、变更的评审方，在公司层面设立PMO角色，开展项目监控，重点跟踪项目里程碑达成和实际投入。

关于研发项目评价

研发项目与交付项目不同，研发项目的效益显现是有滞后性，因此研发项目的开展是预见性的。研发项目的立项启动必须由产品规划驱动或者企业战略驱动。功夫在诗外，超过五成的研发项目的失败，不是项目执行过程出了大纰漏，而是发生在决策过程。

研发项目评价首先要评价的就是决策质量，决策所依赖的假定是否真实客观，当假定发生偏移的时候，有没有及时对项目进行变更或终止？反过来说，如果企业没有这种战略或规划能力，那还是别急着上马做（大投入的）研发项目了，还是放到具体销售合同交付里去One By One吧。

其次就是研发项目直接目标达成情况，同步衡量时间、范围、成本、质量的偏差情况。目标是没有弹性的，其他几点可以有一定的弹性。以此来评价项目的直接产出。目标的达成情况评价应该交给需求方；时间、范围、成本是客观的并且可量化；质量是个无底洞，需要适可而止，因此应该预先定义好质量目标。

再者就是研发项目的规范化程度。规范主要是一种降低风险的措施，放在单项目上，不规范也可以把项目做好，但是放到更大的尺度上去看，不规范迟早要出问题。另外，规范还涉及到组织资产的沉淀以及有利于项目的移交。有的项目做了一段时间之后，离了特定的几个人就玩不转了，那通常是因为项目执行过程不规范，导致很多信息在隐藏状态。

最后就是研发项目的效益达成情况。效益情况应该由业务部门主责，研发部门次责。正如前面说到的滞后性，效益需要在一年半载之后方可以观察到实际情况，因此效益是后评估出来的。效益出现偏差的原因很复杂，可能是市场、竞品、产品规划、非功能性实现情况、研发质量甚至系统的交付难度等多种因素，后评估应该由多方专业人员联合做客观深入的分析。

研发项目管理的挑战

1. 如何建立合适的管理体系。正如上文所说，需要分析企业的局面，建立合适的管理体系。需要管理人员足够敏感，及时做调整。
2. 如何落实科学的启动机制。应该针对项目规模去选择不同的决策机制，投入规模大的项目需要做更多的调研和考量。如果开始就是个错误，那越努力越错。如果盲目决策的人是公司里的power man呢？
3. 谁能、谁来、谁愿意踩刹车。当意识到项目走在错误的道路上，甚至就应该终止的时候，怎么叫停呢？这个挑战在国企中尤为艰巨。交给机制，那么大家都没有责任，都不是关键利益方，那就没有人有动力去拉刹车。交给某个人，那给他带来的压力是巨大的。踩刹车带来的沉默成本和机会成本太难衡量。
4. 如何实现干净利落的收尾。一是成果要保存好，二是遗留问题要识别清楚，在此基础上，把资源释放掉。不能打下来一个城池，留下一个团守着。
5. 如何贯彻项目经理责任制。好的研发项目经理太稀少了，很多时候都是各有擅长，需要第三方如部门管理人员或者研发项目管理部门人员补位。项目经理不能不担责任，不担责任的项目制就失去了大半的价值，有了责任也不能不给权利，没有权利只有责任的项目经理实在是折磨人的岗位，来一个走一个。贯彻权责对等，需要研发部门、组织部门、人力资源部门通力合作，需要配套激励体系和管理手段，是一件很复杂的事情。

微服务架构大成以来，业界持续有声音在质疑微服务架构的弊病，时不时的有曝出某某大厂回归了单体架构。今年（即2023年）5月份，又曝出亚马逊一团队抛弃微服务架构回归单体架构后，成本降低90%，引发业内热议。正于此时Spring Modulith更新到了0.6版本。
这个孵化于Moduliths项目并且现已纳入Spring Boot 体系的框架的愿景是要将单体架构的框架水平拉升到微服务架构Spring Cloud的层次，让架构师们在做架构选择的时候，能基于真正需求去考量，而不是基于框架先进性。

抛开微服务的优点先不说，我所在的公司也在成本上苦微服务架构久矣……因此，我抽空通读了官方的简介、文档和相关示例代码，以期能盼来解药，结果只能说还差点意思……
大家怀念单体架构主要是因为单体架构开发方便，部署方便，然后性能高，但是带来的缺点是事实上的紧耦合，无论再好的规范和设计，也都会随着成员的增多、时间的流逝、紧急需求的响应，导致代码纠缠不清，一团乱麻；而微服务架构带来的是松耦合，独立发布，水平扩展，但是会导致部署架构复杂，基础设施成本、运维成本飙升……
Spring Modulith的解法是用单体架构，通过规范、显式化包与包之间的调用和依赖关系，从而降低单体架构的耦合程度。提供的方法是两种：

• 通过API方式，即由子包去主动暴露API，没有暴露的类或方法均是无法被其他包调用。具体来说，对于子包下的类和方法是默认暴露的，子包下的子包的类和方法是默认隐藏的。即使对于子包下的类和方法也可以通过增加一个package-info.java，并使用@ApplicationModule指明能被谁调用

  @org.springframework.modulith.ApplicationModule( allowedDependencies = "order" ) package example.inventory;

• 通过事件方式，即引入一个ApplicationEventPublisher组件，子包与子包之间通过发布事件、响应事件来完成一次系统。这个过程种可以通过数据库去做事件日志的持久化，再配合事件状态检查和重传机制确保事务最终一致性。

  // 这是发布事件的核心代码，位于Order Package中 @Service @RequiredArgsConstructor public class OrderManagement { private final @NonNull ApplicationEventPublisher events; private final @NonNull OrderInternal dependency; @Transactional public void complete(Order order) { events.publishEvent(new OrderCompleted(order.getId())); } } // 这是响应事件的核心代码，位于 Inventory Package中 @Service @RequiredArgsConstructor class InventoryManagement { private static final Logger LOG = LoggerFactory.getLogger(InventoryManagement.class); private final InventoryInternal dependency; @ApplicationModuleListener void on(OrderCompleted event) throws InterruptedException { var orderId = event.orderId(); LOG.info("Received order completion for {}.", orderId); // Simulate busy work Thread.sleep(1000); LOG.info("Finished order completion for {}.", orderId); } }

  除此之外，Spring Modulith还提供一些增强功能，比如spring-modulith-moments模块提供定时周期性的发布事件的能力，以及在集成测试时的mock支持、UML的自动生成还有一些监控工具等等。
  Spring Modulith会是一剂解药吗？Spring Modulith在降低模块间的耦合上的确能起到作用，但是由此也带来了额外的性能开销，而且并没有解决针对单模块的启停及扩展。Spring Cloud用RPC/HTTP来解决耦合和扩展，Spring Modulith用事件来解决耦合但未能解决扩展，但回头看Java 9 时即推出的JPMS到现在仍用者寥寥，我觉得Spring Modulith还得有一个大的提升才能有用武之地，不过现在才0.6，一切都还早……

在一个企业组织里，科技部门不免需要回答科技投入到底产出了什么，科技投产效能是高是低，要回答这个问题不是一个简单的事情。特别是当CEO有这个疑问的时候，通常意味着他对科技的投入产出已经产生了怀疑，定性的产出描述，“形成了XXXX技术能力，提升了XXXX技术水平”，都无法消除他的怀疑。

在一家科技企业里，科技投入通常是在做三方面工作：（一）科技产品的研发；（二）核心技术能力的建设；（三）基础的IT支撑。

科技产品的研发

科技产品研发投入带来的直接产出是可供销售的软件系统或者支撑业务运营的软件平台。这两部分可直接与市场收入挂钩。但当市场销售不佳，收入较少时，是否就意味着科技产品的研发产出较差呢？我觉得在投资人的角度来看，这个结论是正确的，但是在公司治理中去看却不竟然。因为只要研发部门按照产品设计部门的设计和时点完成了产品研发，那就代表着科技部门履行了职责，后续市场表现不佳，通常是产品设计或销售环节出了问题。
因此我觉得衡量科技产品的研发产出应复合收入和需求实现情况来评价。收入要考虑滞后性，将后续一定时段内的收入框算进来。
产品研发效能 = （研发相关收入+需求实现率 X 系数）/产品研发投入
当然，在现实中，产品、研发、销售总是会互相甩锅，销售会认为卖的不好是产品没有竞争力，产品会说是研发出来的产品质量差、体验不好。因为科技部门需要在版本交付时，让产品部门做好验收，功能、性能、用户体验，并形成一份验收确认单留存。

核心技术能力的建设

为了让企业或产品更有技术竞争力，根据企业所处的行业，通常要去投入一定的研发成本去研发尖端技术，形成企业的核心技术能力。核心技术是可以在多项产品中得到应用，但由于核心技术的挑战性，可能会失败，也可能不是立即能赋能产品或业务，就像隐私计算技术之于数据要素产业。
核心技术的投入是企业的战略决策。但在决策时，科技部门为了获得高层的认可，通常是着重强调了可能的收益，弱化了风险和周期。这也就加大了论述核心技术能力投产效能的难度。
核心技术能力的产出有2个方面，一个是对业务/产品的支撑，一个是专利/论文。对产品的支撑可以使用关联收入规模或者业务规模来体现。
核心技术的研发效能=（收入规模 X 系数+业务规模 X 系数+专利论文数量 X 系数）/核心技术研发投入
鉴于核心技术投入的不确定性，科技条线应该推动企业建立核心技术项目的投入管理或退出机制，这样能使得核心技术的投入是受控状态，也能说明核心技术投入的合理性。一旦缺乏这个机制，就很难说明持续投入的合理性，比较容易引发疑虑。

基础的IT支撑

企业信息化、运维、安全等投入都是为了企业的正常运行，是最基础的IT支撑。这些投入前期是为了实现业务流程的稳定线上化运行，后期是为了不断的提升企业经营效率，降低企业风险。这三方面投入均可以分摊给公司全员，因此可以用人均投入来衡量IT支撑的效能。
IT支撑效能=IT支撑投入/公司人数
安全是个无底洞，可以投入很小，也可以投入很大，一定要适可而止。
通过上面的方式，将三类效能量化以后，问题的关键就来到如何去选择基准值比较，从而得出效能是高还是低的结论。自己与自己的历史去做比较，能说明效能的变化，但关键还是得找到一个同业去做参照。从公开的数据中，能找到上市企业的研发费用、人数等信息，但很难得到打开的更多的信息。只能通过研发费用率（研发费用/营业收入），去说明一些笼统的情况。

后续的思考

科技投入对于科技公司来说，就跟一个人去学本领一样，是必不可少的，但这个人最终能在劳动市场上换来多少报酬，从统计学上来说，肯定跟学本领的投入有关联，但具体的个体，这个投入产出的效能，其实是无法追溯衡量的，因为涉及因素太多。
一个科技部门当被要求量化评价研发效能的时候，就已经是处于比较被动的局面了。因此，还是要在日常的科技制度上做好决策机制和后评估机制，对于每个项目的投入和最终的产出都做到有结论有共识。
另外，在组织架构上，需要匹配企业的阶段去定位科技，是作为能力还是资源。在业务模式探索期，科技应该作为资源，与前端深度绑定；在业务模式稳定期，一部分科技才能作为能力，去追求规模化的效率。

公司网络不支持IPv6，Drive Client使用6690 TCP端口，没有IPv4地址，通过QC连接速度太慢。刚好有台有公网IPv4的云主机，简单的使用NPS实现了TCP隧道转发，记录一下步骤，供参考。

服务端/公网IP云主机

1. 使用docker部署NPS服务端。如果在启动的时候报错提示缺少配置文件，那就根据提示在配置文件目录下，新建对应的文件。

   docker pull ffdfgdfg/nps docker run -d --name nps --net=host -v <本机conf目录>:/conf ffdfgdfg/nps

2. 修改nps.conf文件

   http_proxy_port = 7001 域名代理https代理监听端口,不用可以随便填一个 https_proxy_port= 7002 域名代理http代理监听端口,不用可以随便填一个 public_vkey = 客户端以配置文件模式启动时的密钥，设置为空表示关闭客户端配置文件连接模式 web_username= web界面管理账号 web_password= web界面管理密码 web_port = 7003 web管理端口 bridge_port = 7004 服务端客户端通信端口 bridge_type = 客户端与服务端连接方式kcp或tcp

3. 重启一下docker 容器
4. 登录web端：IP:7003 。
5. 在web管理页面里新建客户端，取得唯一验证密钥
6. 在web管理页面里新建TCP隧道，客户端ID在客户端列表页。目标端口是客户端上要被转发的端口，服务端端口是公网主机对外暴露的端口。

客户端/Synology NAS上

7. 在套件中心安装NPC客户端。套件来源是矿神。
8. 安装完成后打开NPC客户端，配置服务器地址:服务端客户端通信端口，填入唯一验证密钥
9. 此时在web管理页面上能看到客户端在线
10. 在Synology Drive Client 里填写服务端地址：第六步配置的服务端端口即可

最近看几家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、COMPOSITION、SECTION、ENTRY。这些概念是源于GEHR项目的。COMPOSITION可以理解为document，多个document组成一份EHR。COMPOSITION本身可以包含若干个content，这些content可以是SECTION也是是ENTRY。SECTION可以包含若干个ENTRY或者SECTION。

RM是参考模型，是技术层面的定义，比如基础包的定义，支持的数据类型的定义，支持的数据结构的定义，安全信息定义，EHR、COMPOSITION、SECTION、ENTRY四类对象的关系等等。ENTRY是最小的实体，ENTRY下面包含的信息大体分为两类：诊疗类和管理类。诊疗类还可以细分为观察、评估、只是、执行四类业务活动信息。所以RM是纯技术的，不带具体医疗业务的。

AM是原型模型，是业务层面的定义，可以直接理解成一个个领域模型。每个openEHR的原型定义了一种临床概念，比如处方、血压、诊断等等，原型模型定义该原型需要存储的数据内容和形式（也就是前面RM支持的）。原型是使用ADL定义的。目前openEHR已经积累了大概500个左右的原型库可直接引用。

这种RM和AM的设计，就是openEHR机构一直强调的将知识与技术剥离的分层方法。让业务专家去设计原型，让技术人员根据参考模型去开发软件工具。然后最终通过选取不同的原型来组合起来（openEHR称之为模板）支撑应用。

openEHR适用场景

正如在前面阐述的一样，openEHR它本质上是用领域模型的方法去表达医疗业务。按照业务领域的信息聚合必然使得其对医疗业务人员友好。我理解“处方”，不用去查看，就知道处方这个原型下，必然有什么。如果我对整个医疗业务都熟悉，那么我很容易在整个体系内找到我需要的信息。因为整个过程只取决于业务理解，而非技术设计或工程实现。

当openEHR作为一个公开的标准时，那么它就成为一个大家都可以理解的信息定义，在交换传输中就省略了定义声明这一步，简化了对接的步骤。但是，我们得看到目前openEHR的原型大多来自于西方，而欧洲、澳大利亚等的医疗体系与我国还是有很大差别的，所以原型库中的原型肯定有不适用的地方，因此想做到不声明即互知这一步，还需要形成中国的原型库。

openEHR的持久化存储有很多种方式，一种是按照参考模型对象关系来存储数据，另一种是按照属性/路径来存储数据（这种是openEHR机构推荐的），还可以按照原型关系来存储数据。但无论这三种方法的哪一种，在面临数据量级稍微大一点的复杂条件关联的批量查询，必然性能较低——这是受限于openEHR的特性——当它将技术实现与业务知识分离时，当它按照一个个领域实体固化了对象时，就已经埋下了因。至于国内还有人建议通过模板定义以周期性的频率来执行ETL过程在openEHR存储之上生成多维数据集市，只能算时治标，可能在某些场景下可行，但改变不了这个现实。

所以总的来说，openEHR适合的场景有：

1. 跨实体的医疗数据交换协议。如医疗机构之间的互联互通。
2. 有固定路径的精确查询。如患者360视图，个人健康档案应用。
3. 个体健康信息的有层次的组织存储。如个人健康档案存储。

openEHR不适合的场景有：

1. CDR、HDW等面向分析的数据中心
2. 面向交易的医疗业务信息化系统

END

最近一年工作发生很大变化，从技术、研发管理领域转战到了更偏向技术管理、产品管理领域，视角发生了很大变化，也有了很多感悟，正好很久没写文章了，于是总结总结，聊聊在软件企业里如何去做好研发管理、技术管理、产品管理。

产品管理

产品管理不同于产品经理做的事。产品经理的工作是致力于打造出一款好的软件产品。产品管理是更高层次的事情，是在企业层面去对所有的产品进行管理，是同时对这家企业的所有产品负责。

做好产品的管理最本质的是要参透在产品到底是什么，产品管理到底要去管什么。有意思的是从企业视角去看产品，与产品经理眼中看到的产品并不一致。之前有产品经理过来诉苦，说我的产品多么好多么牛，结果公司高层却不认可，最后还被砍了，CEO真是SB。其实出现这种现象的原因就是因为他不理解在企业看来产品是什么。

关于产品

产品首先是商品。产品被创造出来的目的就是为了销售。所以产品的好坏比较关键的点在于他是否卖的好，而并不在于他是否优美、先进。不可否认的是现实中，特别在 ToB行业很多卖的好的产品并不先进。

产品是以为公司取得收入为目的。产品既然是商品，那么它生来就背负这个使命。产品一定要取得收入，可以是短期收入，也可以是未来收入，可以是直接收入，也可以是间接收入。无论如何，产品得有清晰得产生收入的设计和论证。

产品是标准化的。在一定时间范围内，产品是可以重复销售、重复交付的。一款产品在交付中需要定制开发的东西越多，产品化程度就越低。当产品化程度低到一定值的时候，产品的销售交付成本与定制开发的成本（主要是人力）相当，此时产品就失去了规模化的优势，利润率就有限了。很多软件企业挣的就是在合同交付中复用成品带来的成本差值。如果没有标准化的优势，除非能有其他优势形成溢价，否则大概率不是一门好生意了。

产品是有智力投入的。通过渠道优势，采购软件硬件然后转手再卖，这种情形下软件硬件就不能称之为产品，因为其中没有凝结着公司自有的技术成果，此时不需要以产品的方式去做管理，更多的是以商品的形式去管理，这个时候考虑的是怎么拿到更低的价格，怎么降低库存，怎么提升周转率。

软件企业的产品不一定是软件。产品可以是软件，可以是服务，可以是咨询报告。一切满足上面四个要素的都可以称之为产品。

因此，在我看来：产品是以满足客户需求、取得收入为目的，可重复的标准化的交付的，凝结着公司技术成果的一种有形或无形的商品。

除此之外，还要看到企业战略。先有企业再有产品，产品是需要符合企业战略规划的。

太多的产品经理一心扑在精益产品上，看不到产品是在企业战略布局下的一款商品这个基本事实，太多着眼在用户体验，用户痛点，用户价值等等，而忘了这是一门生意。

关于产品管理

那么企业级的产品管理应该管什么呢？

投资管理

从企业的视角看，产品管理实质上是投资管理。在产品研发的过程中，企业的资产形式通常从货币资产转化成了软件资产。如果理解了产品管理就是投资管理，那么产品管理该怎么管就很明显了。

投资前，要去看这个机会是否是一个好机会，要不要投这笔钱。那么就要去问：

• 产品是否符合企业战略
• 产品的市场环境、容量、竞争格局，我们是否会有竞争优势
• 产品我们真的能做出来吗？我们有能力吗？
• 产品的投入产出预期，投资回收周期，累计净现金流量，眼下的投资规模，产品的固定和可变成本
• 产品是短期内可验证的吗？

投资后，就要去看这笔钱花的怎么样，钱花了多少对应这些钱的效果出来了吗？定期的去做后评估，产品投产符合预期吗？外部环境因素是否发生了较大的改变，要不要追加投资，还是要及时止损。

配套管理

在针对产品的管理之外，还要不断的调整公司的产品体系，打通部门协作流程，以使得公司的制度和治理能满足产品商业模式的要求。

规划管理

另外还有一个重点就是产品规划，承接企业战略。

一是明确企业应该在各个发展阶段形成怎样的产品，要在公司层面形成什么样的产品组合；

二是明确每个产品的定位，比如是立足现在承担收入的，还是着眼未来打造核心竞争力的，是负责引流获客的，还是主要的利润来源。

全公司的产品应该形成一张精心设计的、逻辑严密的整体布局。产品打造的过程就是在完成一个个填空题。这种规划是总是处于信息不足状态，是在与未知的勇敢博弈，是不断的滚动试错，但也是不可或缺的，因为它对具体产品的发展给与宏观上的引领。

思考

1. 产品管理可深可浅，这取决于当前所处的局面，在不同的局面下处理方式不同，管理的关注点也不同。比如说是需要快速打开局面找到产品方向，还是要对产品进行收敛聚焦资源。如果是前者，那么就要专注于控制风险，避免重投资，在这个前提下，给予灵活度，要更快速的放行，更频繁的检视，鼓励向外“探索”。如果是后者，那么就要专注于价值收益，避免资源分散，果断关停并转，要更多的关注建立核心竞争力，鼓励向内“创新”。

2. 小部分的产品是设计出来的，大部分的产品是孵化出来的。产品管理要注重如何去建立产品孵化机制，定制化的交付内容在何种情形下需要沉淀为产品。

3. 产品管理还需要注重产品经理的培养，一方面做好至少而下的宣贯，让产品经理在大方向上不偏离，另一方面做好横向拉通，让分散在各个团队或部门的产品，能实现模块复用或业务协同，这需要产品经理互相了解。

END

Domain-driven design并不是一个新鲜的东西，从 2004 年Eric Evans提出这个理念以来，十几年间时不时就有一股DDD的热潮，近几年随着微服务的大行其道，DDD又成了宠儿。但终究逃不过雷声大雨点小。

领域驱动设计最根本的思路是一套自上而下的设计方法，即从要解决的问题领域或系统目标出发，由业务和架构专家一起，对复杂的业务场景和关联性进行分组归类，形成一个一个相对单一职责的子领域。子领域和子领域之间要有明确的界限。在子领域内部，再通过业务上的模型去归类对应的属性和行为。

从设计思想上看，我非常赞同自上而下的架构设计理念，也在不断践行。但今天在技术圈里流传的DDD早已超出了上述的定义，而变成了一套以充血模型为基础，围绕聚合根，并通过门面代理、分离查询、事件传播等手段的软件架构方法。通过这种构建，想达成三种目的：

• 统一语言：业务与技术统一
• 让行为回归到实体中去
• 降低传统service层的复杂度

我所不采纳的即是这样一种“术”，有三个主要原因。

• 行为是变化的，对象的表达却是几乎不变的，将变化的与不变的聚合在一起，违反了动静分离的原则。
• 软件实现的是策略，最终想要引发的是对象的变化，对象的变化最终是持有在DB中的，所以领域的划分是在数据库建模的时候去考虑的，而非在软件实现层面。数据库更贴近现实。
• 领域驱动设计的实现模型会引入无谓的复杂度。而且除了垂直切分实现内聚之外，还需要考虑水平上的相似性，从而提高复用。这套架构方法很难去指导软件设计的真实过程。这也是目前DDD火归火，但落地少的一个原因吧

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注释标记它

• 创建一个接受Http GET请求的方法，该方法返回一个Flux对象，并配置produces=text/event-stream

@RestController
public class ExampleController

    @GetMapping(path="/sse", produces=MediaType.TEXT_EVENT_STREAM_VALUE)
    public Flux<String> createConnectionAndSendEvents() {
        return Flux.just("Alpha", "Omega");
    }
}

如果只发送data，直接返回Flux(Object)就可以了，如果是发送带有id,event,retry等字段，那么就要使用构造器来构建一个ServerSentEvent对象，并放到Flux里。比如：Flux<ServerSentEvent<T>>

一次性事件

短暂的去发送事件是比较简单的，只需要使用Flux.just()将消息列表里的消息一条条发送出去即可。

@RestController
@RequestMapping("/sse/flux")
public class WordsController {

   private static final String[] WORDS = "The quick brown fox jumps over the lazy dog.".split(" ");

   @GetMapping(path = "/words", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
   Flux<String> getWords() {
       return Flux
               .zip(Flux.just(WORDS), Flux.interval(Duration.ofSeconds(1)))
               .map(Tuple2::getT1);
   }
}

周期性事件

长期的发送事件在发送本身上是没有区别，主要是需要一个周期性线程定期处理发送事务，这里直接使用Flux.inteval()来轮询。

@RestController
@RequestMapping("/sse/flux")
public class PerformanceController {

   private final PerformanceService performanceService;

   PerformanceController(PerformanceService performanceService) {
       this.performanceService = performanceService;
   }

   @GetMapping(path = "/performance", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
   Flux<Performance> getPerformance() {
       return Flux
               .interval(Duration.ofSeconds(1))
               .map(sequence -> performanceService.getPerformance());
   }
}

非周期性事件

非周期性事件可以通过Spring的事件监听接口来实现，关键点在于要把监听消息的处理器和Flux的构造结合起来。

这里面核心的方法是Flux.create()。他接受两个参数，一个是FluxSink对象，一个是Flux的溢出策略枚举值。下面是Flux.create()的一个简单例子，便于理解。

Flux.create(sink -> {
    //向下游发布元素
   sink.next("data1");
   sink.next("data2");
   //结束发布元素
   sink.complete();
}).subscribe(System.out::println);//subscribe发布消息，System.out.println为消费者，消费消息;

Flux.create():

我们需要做的就是不断的将监听到的事件填充到sink.next()中去。示例代码如下：

@RestController
@RequestMapping("/sse/flux")
public class FolderWatchController implements ApplicationListener<FolderChangeEvent> {

   private final FolderWatchService folderWatchService;

   FolderWatchController(FolderWatchService folderWatchService) {
       this.folderWatchService = folderWatchService;
   }

   private final SubscribableChannel subscribableChannel = MessageChannels.publishSubscribe().get(); //初始化一个频道

   @PostConstruct
   void init() {
       folderWatchService.start(System.getProperty("user.home"));
   }

   @GetMapping(path = "/folder-watch", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
   Flux<FolderChangeEvent.Event> getFolderWatch() {
       return Flux.create(sink -> {
           MessageHandler handler = message -> sink.next(FolderChangeEvent.class.cast(message.getPayload()).getEvent());
           sink.onCancel(() -> subscribableChannel.unsubscribe(handler));
           subscribableChannel.subscribe(handler);//订阅频道
       }, FluxSink.OverflowStrategy.LATEST);
   }

   @Override
   public void onApplicationEvent(FolderChangeEvent event) {
       subscribableChannel.send(new GenericMessage<>(event));//向频道内发送事件
   }
}

上面的代码中使用了org.springframework.messagin包，他可以通过spring-boot-starter-integration引入。关于这个包的一些基础知识，可以参阅这里。

SSE的注意事项：

• 只适合发送文本消息；尽管可以使用Base64编码和gzip压缩来发送二进制消息，但效率可能很低。

• 早期的一些浏览器，如Internet Explorer不支持。

Internet Explorer/Edge和许多移动浏览器不支持SSE；尽管可以使用polyfills，但它们可能效率低下

• 在系统设计时，同一个页面最好只维持1个SSE连接，通过事件来区分。因为浏览器对同时并发的连接数有限制，一般最大是6个。