核心要点 2026年3月4日，华为在鸿蒙智行技术焕新发布会上正式推出896线双光路图像级激光雷达，这是目前全球量产线束规格最高的激光雷达产品。 首发车型：尊界S800、问界M9 技术规格对比 指标 896线（华为） 192线（当前主流） 提升幅度 目标识别精度 14cm 30cm 2.1倍 最远识别距离 120m 100m 20% 辅助驾驶最高车速 120km/h 80km/h 50% 单帧点云量 128线的7倍 基准 7倍 此前量产最高规格为速腾聚创的520线激光雷达，应用于极氪9X、智己LS9等车型。 核心技术创新：双光路架构 华为乾崑首创的双光路专利技术是本次最大亮点： 广角+长焦一体成像：内部集成两个不同焦段的激光接收单元 图像级感知：从传统的"点云级"正式迈入"图像级"，轮廓清晰度大幅提升 分辨率提升4倍 实际场景表现 针对自动驾驶的高风险场景，896线雷达带来显著提升： 低反射率目标（倒地轮胎）：感知识别距离提升 190% 异型障碍物（横倒锥桶）：感知识别距离提升 77% 超远距识别：120米外可识别14cm高度的碎石、锥桶、低矮障碍 同时，视窗硬度提升25%，耐久能力提升2倍，在雨雾、逆光、夜间等恶劣环境下表现更稳定。 行业背景 激光雷达正成为高阶辅助驾驶的核心零部件： 2025年中国市场：乘用车前装标配激光雷达 324.84万颗，同比增长112% 市场渗透率：已达 20.48% 华为乾崑主动安全系统已累计为鸿蒙智行车主避免潜在碰撞超过 354万次，乾崑智驾累计辅助驾驶安全里程突破 87.6亿公里。 技术意义 从128线到192线，再到如今的896线，激光雷达线束的跃升不仅仅是数字游戏： 感知精度质变：从"看得见"到"看得清" 安全冗余提升：更早识别风险，更长的反应时间 车速上限突破：辅助驾驶车速从80km/h提升至120km/h，覆盖高速场景 这次发布标志着华为在智能驾驶感知层再次拉开与竞争对手的代差。 参考来源： IT之家：华为乾崑发布全球量产最高的896线激光雷达 腾讯新闻：华为发布896线业内最高规格激光雷达

引言：一个看似疯狂的问题 “有没有可能，人完全不需要读AI生成的代码？” 这个问题听起来很极端，甚至有点危险。毕竟，代码是系统运行的基础，不看代码怎么知道AI写对了没有？ 但如果我们换个角度思考： 你会去读编译器生成的汇编代码吗？不会，因为你信任编译器。 你会去读框架的源码吗？很少，因为你信任框架的测试。 你会去读数据库的存储引擎代码吗？不会，因为你信任它的ACID保证。 每一次技术进步，都是在减少人需要"看底层"的场景。 这篇文章要探讨的是：在什么条件下，人可以完全信任AI生成的代码，而不需要去阅读它？ 一、现状：人为什么要读AI生成的代码？ 1. 不信任AI的理解能力 需求：实现用户登录功能 AI理解成了： - 用户输入账号密码 → 验证 → 返回结果 人实际想要： - 用户输入账号密码 → 验证 → 生成JWT → 记录登录日志 → 返回结果 问题：AI理解的需求，可能和人真实意图有偏差。 2. 担心实现细节有问题 # AI生成的代码 def login(username, password): user = db.query(f"SELECT * FROM users WHERE username='{username}'") if user and user.password == password: return {"token": create_token(user)} return {"error": "登录失败"} 问题： SQL注入漏洞 密码明文比对（应该用bcrypt） 没有登录失败限制（可能被暴力破解） 人不看代码，怎么知道这些细节没问题？ 3. 维护的需要 三个月后，需求变了：登录需要支持手机验证码。 如果当初的代码是AI生成的，人没看过： - 哪个文件负责登录逻辑？ - 代码结构是什么样的？ - 哪些地方需要修改？ 4. 责任归属 AI生成的代码上线后出了bug，造成了损失。 老板问：谁审查的？ 你：我没有看代码，直接让AI部署的。 老板：？？？ 人看代码，本质是在承担审查责任。 ...

传统 RAG 的困境 如果你用过 RAG（检索增强生成），应该熟悉这套流程： 文档切片（chunking） 向量化（embedding） 存入向量数据库 查询时检索 Top-K 相似片段 喂给 LLM 生成答案 这套方案有个致命问题：切片粒度很难把握。 切太小，语义不完整；切太大，噪音太多。更麻烦的是，向量相似度检索本质上是模糊匹配——它能找到相关的内容，但不一定能找到精确的内容。 比如你问项目预算在第几章？，向量检索可能返回一堆提到预算的片段，却无法告诉你精确的章节位置。 PageIndex 的思路：给 AI 一张地图 PageIndex 的核心理念很简单：不用向量，用结构。 它把文档解析成一棵层级树： 文档 ├── 第一章 概述 │ ├── 1.1 项目背景 │ └── 1.2 目标与范围 ├── 第二章 技术方案 │ ├── 2.1 架构设计 │ └── 2.2 技术选型 └── 第三章 实施计划 这棵树直接放在 LLM 的上下文窗口里。检索时，LLM 像人一样读目录找答案： 问题：架构设计在哪？ → LLM 定位到 第二章 > 2.1 架构设计 问题：项目总体目标是什么？ → LLM 定位到 第一章 > 1.2 目标与范围 这就是 推理即检索（Reasoning-based Retrieval）。 ...

2026年2月，一个让开发者困惑的消息：OpenAI 收编了 OpenClaw。 困惑的点在于——这项目看起来没技术含量：调用 LLM API、连 WhatsApp、操作文件，哪一项不是现成的技术？凭什么 Meta、xAI 都要抢，扎克伯格亲自下场？ 更让人不解的是，Peter Steinberger 本人也说：这只是一个周末业余项目，用 Codex 几个月就写出来了。 如果技术不是重点，那巨头到底在抢什么？ 一、一个反直觉的开场 在回答这个问题之前，让我们先看一个有趣的平行案例。 Sam Altman 在回顾 OpenAI 十年历程时说过一句话： “我觉得站在创新前沿的代价就是你会犯很多蠢错误，因为你深陷战争迷雾之中。” 这句话看似在解释失败，实则揭示了创新的本质——真正有价值的发现，往往来自"在黑暗中摸索直到找到光"。 OpenAI 的成功产品 ChatGPT，按 Altman 自己的说法，“确实是个意外”。他们原本计划用 GPT-4 发布聊天产品，但担心"同时推出会像是通过了图灵测试"，才先用 GPT-3.5 试水。 这个"意外"改变了世界。 这个故事和 OpenClaw 有什么关系？ 关系在于：两者都揭示了一个被忽视的真相——在 AI 时代，技术正在快速商品化，真正稀缺的是对场景的洞察力。 二、Peter 的选择：一个清醒的判断 2026年2月14日，情人节。Peter Steinberger 在博客上宣布加入 OpenAI。 很多人困惑：OpenClaw 不是正火吗？GitHub 19.6 万颗星，三个月。三大云争相上线一键部署，网易直接推出国产版。整条产业链两周内形成。 这么火，为什么要走？ Peter 的解释是：他想让他妈妈也能用上 Agent，加入 OpenAI 是最快的路。 这个解释很坦诚，但它掩盖了一个更深的逻辑：OpenClaw 所在的那一层，正在被吸收。 不是 OpenClaw 不好。恰恰相反，正因为 OpenClaw 太好了，它证明了"个人 Agent 编排"这件事是可行的，于是 OpenAI、Anthropic、Google 都开始亲自下场做同样的事。 当最顶级的玩家开始认真做一件事，独立创业者就没有空间了。 Peter 选择加入 OpenAI，某种程度上是一个清醒的判断：与其在一个正在被吸收的层里继续建造，不如去更高的地方。 ...

前言 AI Agent 正在成为软件架构的重要组件。但如何让 Agent 能够被远程访问，是一个容易被低估的技术决策。 不同的协议选择，会直接影响： 用户体验：延迟、流畅度 开发成本：实现难度、调试复杂度 运维成本：资源占用、可扩展性 应用场景：能做什么、不能做什么 本文从技术角度深度分析几种主流协议，帮助你做出最佳选择。 协议全景图 ┌─────────────┬──────────────┬──────────────┬─────────────┐ │ 协议 │ 连接类型 │ 通信模式 │ 适用场景 │ ├─────────────┼──────────────┼──────────────┼─────────────┤ │ HTTP/REST │ 短连接 │ 请求-响应 │ API 服务 │ │ WebSocket │ 长连接 │ 全双工 │ 实时交互 │ │ SSE │ 长连接 │ 单向推送 │ 流式输出 │ │ gRPC │ 长连接 │ 全双工 │ 内部服务 │ │ SSH │ 长连接 │ 终端交互 │ CLI 工具 │ └─────────────┴──────────────┴──────────────┴─────────────┘ 一、HTTP/HTTPS + RESTful API 1.1 工作原理 最传统的方式。客户端发送 HTTP 请求，服务器返回 Agent 的响应。 ...

前言 2026年2月25日，路透社的一则报道在科技圈炸开了锅： DeepSeek 发布 V4 之前，打破行业惯例，没有向英伟达和 AMD 提供早期访问权限，而是让华为等中国芯片厂商提前数周开展适配工作。 这条新闻的分量，不在于技术突破，而在于选择的姿态。 打破的惯例 AI 行业有一条不成文的规则：模型厂商会优先与英伟达合作，确保新模型在主流硬件上高效运行。这不是商业偏好，而是生存本能——英伟达占据了 AI 芯片市场 80% 以上的份额，你的模型如果不能在 CUDA 上跑得好，基本等于废了一半。 DeepSeek 之前也是这么做的。它的 V3、R1 等模型都与英伟达工程师紧密合作，确保在 H100、H800 上有最佳性能。 但这次不一样。 V4 发布之前，DeepSeek 没有联系英伟达和 AMD，而是让华为等中国芯片厂商提前几周拿到模型进行适配。这是对行业惯例的公然违背。 英伟达和 AMD 拒绝置评。DeepSeek 和华为未予回应。 沉默本身，就是一种态度。 选择的背景 这不是一个孤立的技术决策。理解这个选择，需要看更大的背景。 美国芯片出口管制的困局 2025年12月，特朗普政府宣布允许英伟达向中国出口 H200 芯片，但有附加条件： 保障美国"国家安全" 美国政府获得25%的分成 消息一出，英伟达要求供应链增产 H200，预判中国需求旺盛。 然而两个月过去了，H200 对华销售数量为零。 美国商务部官员在国会听证会上承认：“据我了解，截至目前，数量为零。” 原因很简单：国务院坚持更严格的限制，许可证审批陷入僵局。英伟达方面"十分沮丧"，有知情人士直言"国务院把事情变得非常困难"。 中国客户的观望 在许可条件不明朗的情况下，中国客户没有向英伟达下达订单。部分供应商已暂停生产 H200 的关键组件。 这不是短期的波动，而是供应链重构的开始。 当未来充满不确定性，企业会本能地寻找替代方案。华为昇腾、寒武纪、摩尔线程——这些曾经被视为"备胎"的国产芯片，正在从边缘走向中心。 DeepSeek 的考量 DeepSeek 为什么做出这个选择？ 1. 用户在哪里，适配就优先到哪里 DeepSeek 在 Hugging Face 上的模型下载量已超过 7500 万次，中国是重要市场。如果 V4 发布时，华为昇腾芯片的用户能获得更好的性能体验，这对 DeepSeek 的生态建设是利好。 ...

前言 2026年3月，魅族手机正式退市。 这条新闻没有掀起太大波澜——一个边缘厂商的消亡，早已是预期之内的事。但对于经历过那个时代的人来说，这个句号画得有些沉重。 从MP3到智能手机的浪漫 魅族的故事始于2003年。那时候它做MP3播放器，是国内市场的龙头之一。创始人黄章是个产品偏执狂，对细节有近乎病态的苛求——这种气质后来也延续到了手机上。 2009年，M8发布。它是国内第一部真正意义上的智能手机，比小米早了两年。M9更是让魅族一战成名：深度定制的系统、retina屏幕、三星处理器——在那个"中华酷联"还在做运营商定制机的年代，魅族是少数认真做产品的厂商。 它的系统叫Flyme，设计语言是"侘寂"——一种日式美学，追求简约、克制、不完美的美感。这很魅族：小众、文艺、有点自我感动。 魅蓝的误判 2014年，小米和荣耀崛起。魅族被逼到了墙角。 时任高级副总裁的李楠推动成立了子品牌"魅蓝"，定位"青年良品"，主打性价比。2015年，魅族销量突破2000万台，其中魅蓝占了70%。这是魅族最后的高光时刻。 但魅蓝从未得到内部真正的重视。 2016年，魅族决定放弃销量导向，转向高端市场。它开始学OV——疯狂铺线下渠道，用机海战术覆盖市场，试图用高溢价换取利润。 这个战略彻底失败了。渠道扩张带来了巨额成本，却没有换来相应的销量。与此同时，苹果和"华米OV"的格局日趋稳固，魅族被挤压到了边缘。 李楠后来在知乎上反思：魅蓝本可以成为魅族的红米，但公司选择了另一条路。 吉利的收购：一笔学费 2022年，吉利旗下星纪时代收购魅族79%的股权，组建星纪魅族集团。吉利董事长李书福的算盘很清楚：通过手机业务，加速车机系统的智能化。魅族最值钱的不是手机，而是Flyme。 三年后，这笔交易的结果是：魅族手机累计亏损上百亿，Flyme被并入吉利智驾部门，手机业务正式停摆。 一位魅族员工说：“这算是吉利为智驾交的学费，吉利也觉得这笔学费早就交够了。” 从商业角度，这个结局不难理解。手机行业早已是红海，头部效应明显。魅族没有规模、没有供应链话语权、没有足够的研发投入，维持手机业务纯属烧钱。吉利要的是Flyme，不是又一个亏损的手机品牌。 技术情怀的边界 魅族的故事让我想起很多类似的命运：锤子、金立、360手机、联想手机业务（卖给摩托又买回来）……它们都有过雄心，都有过人才，但最终都败给了同一个东西：规模。 智能手机是一个典型的"赢家通吃"行业。你需要： 每年数千万台的出货量来摊薄研发成本 强大的供应链话语权来压低采购价格 庞大的渠道网络来触达用户 足够的利润来支撑下一轮创新 这些条件缺一不可。而一旦你失去规模，就会陷入恶性循环：销量下降→成本上升→利润下滑→研发投入减少→产品竞争力下降→销量继续下降。 魅族不是输给了情怀，而是输给了行业规律。在手机这个赛道，小而美是活不下去的。 Flyme的遗产 魅族手机死了，但Flyme会活着。 它已经被整合进吉利的智驾体系，继续服务车机市场。这是魅族最有价值的技术资产，也是吉利真正想要的东西。 某种意义上，魅族完成了它的使命：它培养了一支有能力的软件团队，这套能力现在被转移到了汽车行业。从结果来看，这不是一个完全失败的故事——只是手机业务成了代价。 给技术人的启示 魅族的故事对技术人有什么启示？ 1. 情怀不能对抗规律 你可以热爱产品、追求极致、坚持审美，但最终要尊重商业规律。市场不会因为你的情怀而网开一面。 2. 选择赛道比努力更重要 手机行业在2016年就已经格局固化。魅族在那之后的所有挣扎，本质上都是在与趋势对抗。如果你的赛道已经是红海，再努力也很难出头。 3. 技术资产的转移是可能的 魅族手机失败了，但Flyme的能力被继承了下来。技术、团队、方法论——这些可以迁移到新的战场。失败的组织，不一定意味着失败的经验。 4. 时机比能力更重要 魅族做智能手机比小米早，但它错过了互联网手机的黄金窗口。小米抓住了2011-2014年的红利期，而魅族在犹豫。同样的能力，不同的时机，结局完全不同。 尾声 魅族曾是中国手机行业的一股清流。它不够圆滑、不够功利、有时候甚至有点轴。这种气质在商业世界里是脆弱的，但它也是真实的。 2026年3月，魅族手机正式退市。 再见，珠海小厂。你的故事结束了，但你留下的东西——那些关于产品、关于设计、关于"小而美"的坚持——会被记住。 在这个赢家通吃的时代，或许每一个小而美的消亡，都值得我们停下来说一声：谢谢你曾经来过。 本文写于2026年2月26日，基于界面新闻、IT之家等媒体报道。

前言 2026年2月25日，一条新闻在AI圈刷屏： Kimi K2.5 上线不足20天，累计收入已超过2025年全年总和。 同一周，另一个消息鲜有人注意： 智谱AI招股书披露：云端部署业务毛利为零。 两家公司，同一个行业，两种命运。 这不是个案，而是整个大模型行业的缩影——在价格战、开源潮、出海竞争的三重挤压下，有人突围，有人挣扎，有人注定出局。 本文将基于最新的公开数据和报道，深度解构国内外AI大模型厂商的真实生存局面。 一、行业的"烧钱悖论" 1.1 成本结构：为什么赚钱这么难？ 大模型的核心成本来自三块： 成本类型 说明 量级 训练成本 一次完整训练的算力消耗 数千万-上亿美元 推理成本 每次API调用的GPU消耗 持续、可变 人力成本 顶尖AI研究人才 百万美元/年/人 以GPT-4为例，业界估计其训练成本约1亿美元。但这只是开始——每次用户提问，OpenAI都要消耗GPU算力。 推理成本的残酷现实： 过去3年，AI推理成本下降了超过99%。 但即便如此，当你的API价格降到OpenAI的1/10时，你可能仍在亏本。 1.2 收入困境：价格战没有赢家 2025年下半年，国内大模型行业进入"自杀式价格战"： 阿里云、百度提供免费长文本服务 DeepSeek API价格持续下探 各家Coding Plan套餐定价低于成本 智谱AI的招股书数据很说明问题： 云端部署业务毛利为0——这还是按原价售卖API的情况下。 换句话说，智谱每卖出1元钱的API服务，成本就是1元。不算研发、不算人力，仅算力成本就吃掉了全部收入。 这不是智谱的问题，是整个行业的问题。 二、谁在赚钱？突围者的共同密码 2.1 Kimi的"降维打击" 2026年2月25日，腾讯新闻披露了一组令人咋舌的数据： 月之暗面（Moonshot AI）核心数据： K2.5发布20天，收入超过2025年全年 全球付费用户环比增长4倍 海外收入首次超越国内 估值突破100亿美元，成为国内最快"十角兽" API定价比OpenAI低6-10倍 Kimi做对了什么？ 策略一：全面开源 + MIT协议 K2.5采用MIT开源协议，这是最宽松的开源许可——开发者可以商用、可以闭源、几乎没有任何限制。 更重要的是：全面兼容OpenAI API接口。 海外开发者无需重写代码，仅需替换一行URL即可无缝切换。 这种"无感替代"策略，让Kimi在GitHub、Hugging Face等国际社区迅速渗透。 策略二：放弃国内免费流量，专注海外付费市场 2025年，Kimi做了一个当时被质疑的决定： 砍掉Ohai、Noisee等C端泛娱乐产品线，将资源集中于基座模型与Agent研发。 当时国内同行都在做"免费聊天机器人"抢用户，Kimi却选择了另一条路。 事实证明，这个选择是对的： 国内用户习惯了"免费"，付费意愿低 海外开发者更愿意为高质量API付费 OpenAI的高定价给竞争对手留出了空间 策略三：技术差异化 ...

2025年初，Anthropic 推出了 Claude Code。这不是一个普通的代码补全工具，而是一个代理式（Agentic）编程助手——它能理解整个代码库、执行 bash 命令、查看 Git 历史、运行测试，甚至自主规划多步骤任务。 研究显示，使用它能让开发速度提升 5 倍以上。 很多人开始问一个尖锐的问题：如果 AI 能帮我们写代码，内部编程框架还有必要存在吗？ 这篇文章不谈炒作，只回答一个问题：AI 编程工具和内部框架，到底是什么关系？ 一、事实：Claude Code 的当前实力 1.1 它能做什么？ 根据 Anthropic 官方文档和开发者社区反馈，Claude Code 的核心能力包括： 1. 理解整个代码库 不是局部补全，而是项目级理解 能追踪跨文件的依赖关系 能理解代码的设计意图 2. 代理式工作流 不只是"写代码"，而是"完成任务" 你说"帮我构建一个 React 组件"，它会： 3. 终端集成 能执行 bash 命令 能查看 Git 历史 能运行测试和构建 4. 上下文记忆 通过 CLAUDE.md 文件记录项目细节 能记住代码风格、常见问题、团队规范 5. Skills 模块（2025年新功能） 可重用的工作流 支持市场共享 可构建自定义代理 1.2 它不能做什么？ 1. 不理解业务战略 它能写代码，但不能决定"应该做什么" 2. 不负责长期维护 生成的代码需要人工审查和改进 3. 不知道你的框架规范 除非你明确告诉它（通过 CLAUDE.md 或提示词） 4. 不能替代架构设计 ...

背景 我的博客建于 2014 年，最初使用 WordPress 搭建。十年来，积累了 282 篇文章，涉及技术笔记、产品评测、行业观察等多个类别。 但随着时间推移，WordPress 的问题越来越明显： 性能瓶颈：每次访问都要查询数据库，响应慢，需要缓存插件维持 维护负担：核心、插件、主题需要频繁更新，安全隐患多 资源消耗：PHP + MySQL 的组合对服务器资源要求较高 备份复杂：需要同时备份数据库和文件，恢复流程繁琐 2026 年初，我决定将博客迁移到 Hugo —— 一个基于 Go 语言的静态网站生成器。 迁移完成后，博客的访问速度提升了 5-10 倍，服务器资源占用降低了 90% 以上。 本文记录了整个迁移过程，希望对有类似需求的朋友有所帮助。 一、为什么选择 Hugo？ 在决定迁移之前，我对比了几种主流的静态网站生成器： 工具 优点 缺点 Hugo 极快（毫秒级构建）、Go 原生、主题丰富 模板语法需要学习 Jekyll GitHub 原生支持、生态成熟 Ruby 依赖、构建较慢 Hexo 中文社区活跃、上手简单 Node.js 依赖、插件质量参差 Astro 现代化、支持多框架 相对较新、迁移资源少 最终选择 Hugo 的原因： 构建速度：282 篇文章的构建时间不到 5 秒 单文件部署：Hugo 是一个独立二进制文件，无需安装依赖 主题生态：PaperMod、Stack 等主题现代且维护活跃 迁移工具：社区有成熟的 WordPress 转 Hugo 方案 二、迁移方案设计 2.1 迁移流程概览 WordPress (MySQL) ↓ 导出 WXR XML（WordPress 导出工具） ↓ PHP 转换脚本（自定义 wp2hugo.php） ↓ Hugo Markdown 文件 ↓ Hugo 构建 ↓ 静态 HTML（Nginx 托管） 2.2 关键决策 决策一：使用 PHP 转换而非现成工具 ...

前言 2026 年 2 月 21 日，一条看似低调的消息在科技圈炸开了锅： OpenAI 将 2030 年算力支出目标从 1.4 万亿美元下调至 6000 亿美元。 降幅 57%。直接腰斩还多。 如果你关注 AI 行业，应该记得几个月前 Altman 还在高调宣称要投资"万亿级基础设施"。当时整个行业都在讨论：算力缺口有多大？GPU 还要涨多少？数据中心建得够不够快？ 然后，OpenAI 自己踩了刹车。 这不仅仅是数字的调整，更是整个行业心态转变的信号。 一、发生了什么？ 让我们先看看具体数据： 算力支出目标调整 原计划：2030 年投入 1.4 万亿美元（约 9.68 万亿人民币） 调整后：6000 亿美元（约 4.15 万亿人民币） 降幅：57% 估值调整 原估值：8300 亿美元 调整后：7300 亿美元 降幅：12% 财务目标 2030 年营收预期：超 2800 亿美元 2025 年实际收入：131 亿美元（超原目标 100 亿） 2025 年资金消耗：80 亿美元（低于预估 90 亿） 融资情况 新一轮融资规模：超 1000 亿美元 战略投资者占比：90% 主要投资方：软银、英伟达（最多 300 亿）、亚马逊 表面上看，这是 Altman 对此前"激进承诺"的修正。但更深层的问题是：为什么需要修正？谁在推动修正？ ...

背景 2025年11月25日，华为正式发布了Mate80系列手机。这场发布会选择在央视直播，这一决策本身就值得玩味。作为中国科技企业的代表，华为的每一次大动作都不再仅仅是商业行为，而是承载了更多的象征意义。 Mate80系列概览 根据公开信息，Mate80系列共推出四款机型： Mate80 标准版 - 入门旗舰定位 Mate80 Pro - 主力高端机型 Mate80 Pro Max - 大屏旗舰 Mate80 非凡大师版 - 顶配奢华定位 全系搭载纯血鸿蒙系统（HarmonyOS），这意味着华为彻底切断了与安卓生态的依赖关系。 央视直播的战略考量 为什么是央视？ 一家商业公司的产品发布会登上国家级媒体平台，这在中国科技史上并不常见。华为此举至少有三层考量： 政治背书 - 在中美科技博弈的背景下，央视直播本身就是一种态度表态 市场覆盖 - 央视的受众远超科技圈，有助于触达更广泛的消费群体 品牌塑造 - 将产品发布上升为"国家大事"级别，强化民族品牌形象 利弊分析 优势： 极大提升品牌公信力 获得主流舆论支持 在下沉市场建立认知优势 风险： 过度绑定可能导致国际市场顾虑加深 商业行为政治化可能引发部分消费者反感 央视受众与高端手机目标用户存在错位 纯血鸿蒙：技术自主的最后拼图 Mate80系列最大的技术亮点不是硬件，而是全系预装纯血鸿蒙系统。 技术层面的挑战 纯血鸿蒙意味着： 应用生态重构 - 开发者需要适配全新系统 兼容性阵痛 - 早期用户体验可能面临应用缺失 性能优化 - 新系统需要时间打磨 根据华为官方数据，鸿蒙生态已有超过10万个原生应用。但与安卓、iOS数百万级别的生态相比，差距依然明显。 自主可控的代价 技术自主从来不是免费的午餐。华为在芯片、操作系统、应用生态三个层面同时推进自主化，这种"全栈自研"策略在全球科技企业中极为罕见。 其代价是： 研发成本激增 - 每年千亿级别的投入 生态建设周期长 - 至少需要3-5年才能成熟 用户体验阵痛 - 早期用户承担了生态建设的成本 客观评价 产品力 从已知参数来看，Mate80系列在硬件层面依然是第一梯队： ...

假期有闲暇学习一下AI相关的知识，尝试着想用公众号对接DeepSeek做一个问答，当做一个BlogAgent，又不想写太多的工程类的代码，想着AI这么强大，能不能直接用AI生成代码。没有看阿里，百度的产品，直接试用了豆包的AI编程，通过这两天的试用，AI惊人的生产力着实让我惊掉下巴。 一、项目级代码生成 我一开始描述，要求 实现一个微信公众号的后台服务代码，可以接收用户信息，并且回复。 豆包直接生成了一个Python的代码，实现了微信公众号的后台接口，并且实现了签名认证，并且给出了详细的代码说明和注意事项。 然后我又要求使用Java+Spring Boot实现，它竟然给我实现了了一个完整的Maven项目。代码下载下来是真的可以跑的。 二、根据要求重构代码 在仔细看了下整个工程，代码就是一个Spring Boot的启动类，再加一个Controller。稍显不足的是，关于签名的代码，放在了Controller里，导致代码很乱。我随即发了一个优化建议： 把WechatController里的通用公共代码抽出去 这货竟然完全听懂了，乖乖的提取了一个Utils类，把签证签名，XML解析等相关的操作放了进去。 我又对比了下微信的API文档，我疑问道： POST接口不需要验证签名吗？ 它竟然立马意识到自己的错误，修正了自己的错误： 三、根据要求增添内容 我继续下达着我的命令： >请生成Spring Boot的配置文件 >再加入log4j2的日志框架，把相关的异常打到日志里 >把参数搞成对象，把解析xml改成通用的反序列化拦截器 >响应体也可以搞成对象，使用序列化拦截器 >把token改成配置项形式，放在配置文件里 >使用langchain4j集成调用deepseek。当微信用户发来消息以后，转发给deepseek，然后把响应给微信用户 >Spring Boot的方式初始化langchain4j 并且把相关代码抽出去单独的类，整个项目包名改成com.zhaoyanblog.agent项目名称微blog-agent >帮我在pom里设置国内的maven仓镜像地址 >集成对wordpress的访问，当微信用户请求“wp:” 开头的信息时，搜索WordPress里的文章，返回给用户。 >微信返回的消息 要是一个包含文章的摘要富媒体链接，业务点击消息可以跳转到网站。WordPress的网站地址zhaoyanblog.com。要放在配置文件里。 关于微信的Token也放在额外的类里，不要放在controller里 >请对工程使用Spring boot的方式配置accesslog， >配置文件里的注释在IDEA里是乱码，请修正. …… 它就像一个不知疲倦的程序员，不断的实现着产品经理提出的需求 四、帮我修正Bug 有关freemarker模版的问题，开始我希望把markdown改成HTML。它一开始给我的代码其中有这样一段： <p class="text-gray-800"><span class="speaker-highlight">DeepSeek</span>：<#noescape>${conversation.getContentAsHtml()}</#noescape></p> 但是我真实跑起来的时候，它报这样的错误 #noescape with no matching #escape encountered 它直接给我了解决方案，并解释了原因： <span class="speaker-highlight">DeepSeek</span>：${conversation.getContentAsHtml()?no_esc}</p> 但是好像还不行，我直接把报错信息再贴给它 ?no_esc can't be used here, as the current output format isn't a markup (escaping) format: undefined(mimeType=null, class=f.c.UndefinedOutputFormat) 这次它给的答案，完美解决了问题： 五、竟然提示我遵守规范 ...

本站在阿里云ECS已经有5年之久了，1C2G的配置，1M带宽 外加20G云盘，一年要耗费1100多大洋~~。随着云化技术的发展，一直等着阿里能有优惠，然而一直都如此。 碰巧前段时间看到华为云的优惠活动。新注册用户 2C4G的HECS 3年只要700多。瞬间心动，直接买了。 前段时间增加了域名备案，但是一直没有机会把主机迁移。 今晚早下班，一并做了迁移。同时把好久没升级的nginx和php都升级到了最新版本 华为云 棒棒的^_^