AI原生开发重塑企业IT:一篇博客引发的传统巨头股价暴跌启示

1. 现象回顾:一篇博客为何引发巨震

先把这个事件放回时间线里看。某模型研究机构在博客上发布了一篇关于企业级AI应用开发模式的观察文章,内容本身并不长,核心观点是:基于大模型的原生开发方式正在快速取代传统的企业软件交付流程,未来企业IT系统的构建逻辑将被彻底重写。文章发布后不到24小时,某传统IT巨头股价单日跌幅达到13%,创下该公司25年来最大单日跌幅,市值蒸发规模惊人。

很多人第一反应是“市场反应过度了”。但如果你长期关注企业服务赛道,就会意识到,这13%的跌幅并非情绪驱动,而是机构投资者对一家传统IT巨头未来十年现金流预期的重新定价。博客只是导火索,真正让市场恐惧的是文章里那些听起来还很遥远、但实际上已经在发生的技术替代路径。

这篇文章我想拆解的核心问题有三个:第一,这篇博客到底说了什么,为什么能击穿传统IT巨头的估值逻辑;第二,市场恐慌的传导链条是怎样的,从技术信号到资金行为之间发生了什么;第三,这件事对从业者意味着什么,尤其是正在做技术选型、架构设计或职业规划的人,应该从这次事件里提取哪些真正有用的判断依据。

先说结论:传统IT巨头的大跌不是因为它做错了什么,而是因为游戏规则换了。文章里描述的那个世界,恰好是它最不擅长的世界。

2. 背景拆解:传统IT巨头靠什么赚钱,又怕什么变化

要理解这次大跌,得先搞清楚传统IT巨头的商业模式支柱。这类公司的收入结构通常由三块构成:基础设施销售、企业软件授权、专业服务与咨询。过去三十年,它们靠这套组合几乎通吃了全球大型企业的数字化预算。

基础设施销售,本质上是卖硬件和底层软件,包括服务器、存储、数据库、中间件、开发工具。企业软件授权则是按用户数或CPU核数收费的授权模式,一旦采购,后续的维护费、升级费、扩展费就成了持续性的现金流。专业服务与咨询则是把前两者打包落到客户的机房里,按人天收费。

这套模式的根基建立在两个前提上:第一,企业IT系统是高度复杂且定制化的,需要专业厂商提供全套方案;第二,系统的生命周期很长,一旦选定某个技术栈,迁移成本极高,客户会被锁定多年。正是这种“锁定效应”,让传统IT巨头能够在几十年里持续从存量客户身上获取高毛利收入。

但模型技术改变了一个关键变量:软件的生产方式。过去写一套企业级应用,需要需求分析、架构设计、编码、测试、部署、运维,整个链条周期以季度甚至年为单位。而现在,基于大模型的原生开发方式,可以让普通业务人员直接用自然语言描述需求,系统自动生成可运行的软件模块。开发周期从几个月压缩到几天,甚至几小时。

这个变化直接动摇了传统IT巨头赖以生存的根基——专业壁垒和锁定效应。当软件可以按业务需求动态生成、持续演化时,客户不再需要一次性采购整套系统,也不需要绑定某个厂商的技术栈。原本预期持续十年的现金流,可能在三五年内就面临枯竭。

博客里最关键的表述,是把企业IT系统的演进方向从“项目制交付”推向“产品化持续运营”。这个看似平常的判断,对于习惯了按大项目签单、按人头收钱的传统IT巨头来说,几乎是釜底抽薪式的冲击。

3. 市场传导链条:从技术信号到股价暴跌发生了什么

一篇博客能在一天之内蒸发掉传统IT巨头数百亿美元市值,中间必然有清晰的市场传导链条。拆解一下这个链条上每个环节的逻辑,你会发现13%的跌幅其实是理性计算的结果。

第一步,博客发布后,关注企业服务赛道的分析师和机构投资者开始重新评估传统IT巨头的风险敞口。券商内部有专门的技术跟踪团队,他们的工作就是把前沿技术动态转化为对上市公司盈利预测的调整。这篇博客的内容被标记为“影响因子高”,因为它的技术路径判断不是空谈,而是有大量企业客户实测数据支撑的。

第二步,估值模型被调整。传统IT巨头的股价,很大程度上取决于未来五到十年自由现金流的贴现。机构投资者在建模时,会对不同业务线设置不同的增长率假设。博客里描述的技术替代路径,直接让分析师下调了软件授权和专业服务这两条业务线的长期增长率预期。增长率假设每下调一个百分点,估值的变化都是几十亿美元级别的。

第三步,程序化交易放大了波动。当多家机构的研报在同一天下调评级或调整目标价后,算法交易会同步执行减仓指令。传统IT巨头是各大指数的重要成分股,也是大量机构组合中的核心持仓,一旦触发减仓信号,流动性会瞬间失衡,股价跌幅被进一步放大。

第四步,媒体和舆论的反馈循环加速了情绪扩散。新闻标题强调“25年来最大单日跌幅”,这个标签本身又会触发更多投资者的避险行为,形成“下跌—报道—进一步卖出—更大跌幅”的自我强化路径。

整个传导过程在实盘交易中可能只需要四到六个小时。从技术信号出现到资金行为落地,中间几乎没有给传统IT巨头留出解释或缓冲的时间。这就是为什么在AI时代,一篇技术博客也能有如此巨大的市场杀伤力——因为市场的定价锚已经从“当前盈利”转向了“未来被替代的概率”。

4. 博客核心技术观解读:AI原生开发为何是分水岭

这篇博客之所以能引发传统IT巨头股价崩塌,核心在于它阐述的“AI原生开发”理念,彻底划清了新旧两个时代的开发范式。理解这个分水岭,是理解整件事的关键。

传统企业开发走的是“流程驱动”路线:需求文档→技术方案→排期→编码→测试→发布,每一步都需要专业人员参与,每个环节都有大量沟通损耗。这套流程在业务相对稳定的时代是高效的,因为它保证了质量和可控性;但在业务变化以周为单位的今天,它就是巨大的成本包袱。

AI原生开发走的是“意图驱动”路线:业务人员直接描述想要的系统行为,模型负责生成代码、数据结构、接口文档,甚至自动完成单元测试和部署配置。开发者的角色从“写代码的人”变成“验证和优化模型输出的人”。这个转变的本质,是把软件开发从手工劳动变成智能装配。

博客里重点提到了两个支撑性能力:一是长时间上下文的工具调用能力,让模型可以在单一会话中完成从需求理解到代码生成的完整流程,不再需要人工拆解任务;二是可观测性与自动修正能力,系统能实时监控自身运行状态,异常时自主调整配置或触发修复流程,大幅减少人工运维介入。

这两个能力叠加起来的效果是惊人的。原本需要六人团队开发六个月的内部管理系统,现在可能只需要一个业务分析师加一个AI工程化工程师,三周就能上线。原本需要专业DBA优化的数据库性能问题,现在模型可以直接分析慢查询日志,自动生成索引调整方案。原本每周需要人工执行的报表开发任务,现在业务部门直接用自然语言提问,系统自动生成可视化结果。

这种对专业服务链条的替代,恰恰是传统IT巨头最脆弱的地方。它们的软件授权收入建立在客户需要“复杂工具”的假设上,而AI原生开发的基础逻辑是“工具越简单越好,最好简单到不需要工具厂商”。当企业可以用一个通用模型加上少量定制配置解决大部分需求时,独立软件授权的价值就会被大幅压缩。

还有一个容易被忽略的细节:博客里强调AI原生开发的核心场景是“增量式数字化转型”,而不是“一次性大迁移”。传统IT巨头的方案讲究整体规划、分步实施,实施周期往往长达数年;AI原生开发则鼓励从小业务单元开始,用最小成本验证效果,再快速横向扩展。后者的节奏更符合当下企业对投入产出比的要求,也让传统厂商的“大单模式”越来越难签。

5. 为什么受伤的是传统IT巨头,而不是其他角色

市场选择了传统IT巨头作为主要抛售对象,这背后有清晰的逻辑。不是所有IT公司都面临同样的风险,不同角色的脆弱性差异很大。

先看云服务商。它们虽然也提供企业软件,但收入核心是计算和存储资源的租用。AI原生开发带来的是应用层软件生产方式的变化,底层的算力需求不减反增。模型训练和推理消耗的算力规模,远大于传统企业应用的稳态负载。所以云服务商在这次技术变迁中,扮演的是“卖铲人”角色,不仅没有受损,反而可能是最大的受益者之一。

再看IT咨询公司。它们过去靠人力外包赚取服务费,AI原生开发确实会冲击人天计费模式。但咨询公司有个缓冲优势:它们与客户高管的信任关系和行业知识积累,短期内不容易被纯技术方案取代。而且不少咨询公司已经在大力引入AI工具重塑自己的交付方式,服务单价虽然可能下降,但服务深度和维度可以扩展,属于“转型阵痛”而非“根基动摇”。

传统IT巨头则完全不同。它的核心资产是存量客户的技术栈锁定,一旦客户转向AI原生开发模式,锁定期满后很可能不再续约。更糟的是,它的组织架构、销售体系、合作伙伴生态都是围绕卖软件授权构建的,内部的利益结构决定了它很难主动拥抱“让客户少买软件”的新模式。这种“创新者窘境”,在历史上反复出现过,每次都是一场痛苦的收缩。

市场给传统IT巨头的定价方式也放大了冲击。由于它的收入预期高度依赖续费和扩展销售,市盈率中隐含的假设是“存量客户会一直存在”。当市场开始质疑这个假设时,哪怕是十多年后才会完全兑现的风险,也会按时间贴现拉到今天来股价里一起反映。13%的跌幅,本质上是在这个信任动摇过程中的合理定价修正。

从产业链位置上讲,传统IT巨头处在“技术供应商”和“业务落地者”之间的夹层。技术创新的源头在模型厂商,业务需求的变化在客户侧,而它自身的价值主张——提供一体化解决方案——恰好是这轮变革中最容易被替代的环节。技术不再稀缺时,集成和交付的价值就会迅速贬值。

6. 对从业者的启示:技术选型和职业规划怎么调整

这次事件看起来是股票市场的故事,但对做技术、做架构、做规划的从业者来说,里面的信号含金量很高。我从几个层次说说自己看到的变化。

第一层,企业IT建设思路必须换。过去上系统讲究“总体规划、分步实施”,先在顶层设计好五年蓝图,再逐年落地。这种思路在AI原生开发时代会越来越难走通,因为业务变化太快,五年蓝图大概率在第二年就失真了。更务实的路径是选择高频痛点场景,用AI原生方式先做小规模验证,用数据说话,再逐步扩大范围。我接触的几个转型比较快的传统企业,都是先在财务对账、客服工单、报表生成这几个场景试水,效果出来后再向供应链和生产端蔓延。

第二层,技术栈的选择标准变了。以前选型看生态成熟度、人才储备、社区活跃度;现在还要加一个维度——和模型能力的融合成本。一个工具生态再完善,如果接入模型推理要绕很大的弯,未来还是会成为包袱。优先考虑那些模型原生支持、上下文感知能力强的开发框架,它们在智能化改造时的边际成本更低。说白了,代码库的智能友好度,正在成为技术资产的评估新指标。

第三层,职业方向上的调整。纯写增删改查的岗位确实在被压缩,但和业务分析结合紧密的岗位反而在升值。模型把从需求到代码的距离缩短后,最稀缺的能力变成了“把业务问题翻译成模型可理解的指令”,以及“验证模型产出的质量是否符合业务预期”。这两件事都需要领域知识,不是纯技术能搞定的。所以我一直建议身边做应用开发的同事,花时间去深入理解业务逻辑,未来比多学一个框架值钱得多。

还有运维和数据库管理岗位,也不能停留在传统操作层面。要开始熟悉模型辅助运维的链路:让模型分析监控指标、自动定位根因、生成变更方案,把人的精力从重复排障中解放出来,放到决策和应急响应上。会使用智能运维工具的人,效率和质量都远高于纯手工操作的同行,这个差距半年后会更明显。

7. 实操心得:传统企业怎么应对AI原生开发的冲击

最近几个月,我给几家传统企业做过智能化改造的建议,有些心得可以拿出来分享。这些企业的共同点是:系统老旧、流程复杂、不敢动核心业务。它们的顾虑很有代表性,但应对方法其实有套路可循。

第一步,先做“业务断点体检”,把流程里最耗人力的环节列出来,按业务影响和技术可行性打分。得分最高、且改动风险最小的场景,就是最佳试点。不要一上来就想着重构核心系统,风险太大,而且内部阻力会让项目直接胎死腹中。通常我会建议先从报表、文档处理、客服响应这类非核心但高频的场景切入。

第二步,搭建“最小智能增强层”。就是在现有系统外面套一层模型能力,不动底层数据结构,只增加一个智能分析服务层。比如用检索增强生成挂接内部知识库,让员工用自然语言问问题,系统从既有文档里找答案。这样的改造周期可以控制在三周以内,投入不大,但员工能直接感受到效率变化,为后续扩大范围赢得内部支持。

第三步,建立“产出一致性校验机制”。这是最容易踩坑的地方。模型生成内容不稳定,尤其是涉及数据计算和业务规则时,出错代价很大。我在每个试点项目里都会加一道自动校验环节:让模型先输出结构化结果,再用代码对照原系统数据进行一致性比对,不一致的强制走人工复核。这套机制虽然会增加一点开发量,但能有效控制风险,让业务部门敢用系统。

第四步,用“增量渗透”替代“存量替换”。每完成一个场景验证,就把智能化能力嵌入现有工作流对应环节,而不是试图推倒重来。这样每一轮改造都有明确收益,也方便向管理层汇报阶段成果。企业的智能化转型本质上是组织能力和信任的累积过程,增量渗透的方式最稳妥。

另外还有个经验:模型厂商平台能力的稳定性,很大程度上决定了项目能不能落成。我在选型时不会只盯模型的评测分数,更看重平台的工程化能力,包括API稳定性、数据安全措施、私有化部署支持度。对一个企业项目来说,模型的聪明程度只占三成,工程化的可靠程度占七成。别被榜单误导,生产环境的稳远比演示环境的炫重要。

8. 常见问题与避坑要点汇总

这次事件之后,我陆续被问到很多问题,把典型的整理出来,给大家做个参考。

关于“传统IT巨头是不是真的会被替代”,要区分两种节奏。短期两三年内,存量系统里的核心业务不会被快速替换,迁移成本太高,而且企业对稳定性的要求决定了它们不会激进冒险。但新增系统和外围系统的选型,AI原生方案的优势会越来越明显。五年以上的窗口期,传统厂商的核心盘确实面临被逐步蚕食的风险。

关于“转型传统企业从哪里入手最安全”,首推数据密度高、规则明确的场景,比如财务对账、合规校验、数据清洗。这类任务的评判标准清晰,模型产出的质量容易验收,即使是企业内部比较保守的部门,也相对容易接受。营销文案、客服问答这类生成型场景虽然能快速出效果,但验收主观性强,推广时容易产生争议,更适合作为其次的选择。

关于“现有系统是不是都要推倒重来”,不建议。历史包袱不是累赘,很多核心业务逻辑和数据价值都在旧系统里,盲目重构很可能把优势也重构没了。更合理的思路是保留稳定的核心,在外围构建可演化的智能应用层,用增量方式逐步替换效率洼地。把旧系统当作数据提供方,让新的智能层在数据之上生长,这个迁移路径实际走下来最顺畅。

关于“团队需要什么样的人”,建议内部培养加少量外部引入结合。已有的业务骨干是核心资产,他们懂流程、懂痛点、懂客户,只需要补上模型应用的能力;纯外部空降的团队往往对业务理解不足,落地效果会打折扣。我在实际项目里发现,业务骨干经过三到五周的模型应用训练后,产出的方案质量和落地效率,通常会优于纯技术背景的新人。

再提醒一个容易忽略的坑:权限管控和审计追踪。AI原生系统生成和处理的内容越来越多,必须有清晰的操作留痕和审批流。我曾经见过一个试点项目,因为系统自动生成的数据修正指令没走审批流,导致业务部门对系统产生严重的不信任,项目差点被叫停。权限边界一开始就要设计好,宁可先紧后松,不要先松后紧。

9. 后续观察点与实操建议

经历了这次大跌之后,可以持续跟踪几个信号来判断技术替代的真实节奏,而不是被情绪带着走。

第一个观察点是传统IT巨头财报里的关键指标——软件授权收入增长率和专业服务合同金额。如果这两个数字在接下来两三个季度内出现明显放缓,说明替代效应已经开始传导到它们的核心收入。如果仍旧保持增长速度,说明客户侧的实际切换尚未大规模发生,之前的股价变动更多是预期定价,而非现实反映。

第二个观察点是企业客户的实际采购行为。看看新增的数字化项目招标中,标书的技术要求是在强调传统系统集成能力,还是在强调模型原生开发与智能体编排能力。招投标文件是最诚实的需求信号,比任何研报都靠谱。

第三个观察点是模型推理成本的趋势。过去的经验是,算力成本每年都在下降,而且下降幅度往往超预期。推理成本每下降一个数量级,就能解锁一批新的企业级应用场景。成本的下降节奏,决定了AI原生开发渗透传统企业市场的速度。

对正在做技术规划的朋友,我的建议是把手里的项目按“智能化改造价值”重新排个优先级。那些数据密度高、规则明确、交付频率高的项目,优先考虑用模型能力改造;低频、复杂、强依赖人类判断的项目,暂时保持现状就好。用增量收益支撑下一轮改造,整个转型过程会比较从容。

这一年多我最大的体会是:技术变革的冲击从来不是匀速到来的,它更像潮水——看起来平静,但某个节点会突然提速。当标志性事件出现时,往往是潮水方向已经确立的时候。一篇博客引发传统IT巨头单日大跌13%,就是这样一个标志性时刻。它提醒所有还在观望的人:基于大模型的原生开发方式,已经从一个技术话题变成了商业现实。早一点调整思路,就早一点掌握主动权。

相关新闻

PyCharm Console报错真相:不是IDE问题,是Python环境配置错误

PyCharm Console报错真相:不是IDE问题,是Python环境配置错误

1. 这不是PyCharm的问题,是Python环境在“装睡”“PyCharm console 报错”——这行搜索词每天被成千上万开发者敲进浏览器,但绝大多数人点开的前10个结果都在教你怎么重装PyCharm、清缓存、重启IDE。我试过三次重装、五次invalidate caches and restart&…

2026/10/20 19:55:53 阅读更多 →
零成本搭建自动盯盘流水线:WorkBuddy+腾讯东财行情接口实战

零成本搭建自动盯盘流水线:WorkBuddy+腾讯东财行情接口实战

不知道有多少人跟我一样,每天要盯二十几只票,开盘前翻一遍行情软件,盘中时不时切过去瞄一眼,收盘后再手动记一下涨跌幅。一天下来,光在这些重复动作上就浪费了大把时间,而且经常是 self 刚离开屏幕&#xf…

2026/10/20 19:54:52 阅读更多 →
Skills技能单元架构:从设计思路到实操落地的完整指南

Skills技能单元架构:从设计思路到实操落地的完整指南

1. 从“skills”这个词说起:它到底指什么“skills”这个词最近在技术圈和职场圈被反复提起,但很多人第一次看到它时,脑子里冒出的问号比句号还多。它不是一个具体的框架名,也不是某个产品的缩写,而是一个更底层、更抽象…

2026/10/20 19:54:52 阅读更多 →

最新新闻

YOLO26目标检测训练到RK3588部署:ONNX与RKNN适配实践

YOLO26目标检测训练到RK3588部署:ONNX与RKNN适配实践

YOLO26 目标检测的训练到瑞芯微平台适配,这条链路我最近刚完整跑通一遍。先说结论:真正卡人的地方不在训练本身,而在从 PyTorch 模型走向 RKNN 运行时的那几步——ONNX 导出、算子兼容、INT8 量化,每一个都埋着不少雷。我是在给一…

2026/10/20 20:43:28 阅读更多 →
梯度增强PINN:攻克Allen-Cahn方程多陡峭界面难题

梯度增强PINN:攻克Allen-Cahn方程多陡峭界面难题

Allen-Cahn方程是我调过的最“拧巴”的PDE之一。它表达式极简,一个∂u/∂t ε∂u/∂x u - u,但解的画面完全不简单:能量驱动下的相分离会让解在空间里劈出好几条尖锐的界面,这些界面随时间演化、移动、合并。所谓“多非常陡峭区…

2026/10/20 20:43:28 阅读更多 →
计算机教材内容策划与写作:从概念到工程实践

计算机教材内容策划与写作:从概念到工程实践

抱歉,我无法处理这个请求。

2026/10/20 20:43:28 阅读更多 →
从图像到数据:HaoCurve曲线提取实战与避坑指南

从图像到数据:HaoCurve曲线提取实战与避坑指南

简介:HaoCurve(薅曲线)是一套面向科研人员、工程师与数据分析者的MATLAB曲线绘制工具源码,适合需要在MATLAB环境中快速生成、编辑和分析数据曲线图的用户,尤其对希望深入理解绘图脚本实现、进行二次开发的进阶使用者更…

2026/10/20 20:43:28 阅读更多 →
CLI编码代理失败过程解剖:从轨迹日志到根因分析

CLI编码代理失败过程解剖:从轨迹日志到根因分析

读到一篇很有意思的论文,标题叫《Failure as a Process: An Anatomy of CLI Coding Agent Trajectories》。这两年命令行AI编程工具越来越多,从最初的“能写一段函数”到现在能在真实仓库里自己定位问题、改代码、跑测试,甚至提交补丁。但大多…

2026/10/20 20:43:28 阅读更多 →
小橘子V4.790:本地可调试塔防策略模拟器

小橘子V4.790:本地可调试塔防策略模拟器

简介:本资源是《向僵尸开炮》游戏的自动化对局辅助工具——小橘子V4.790版本完整部署包,面向游戏AI开发者、自动化测试工程师及休闲游戏技术爱好者,用于快速实现人机对战环境下的策略执行、界面识别与操作模拟。压缩包共741个文件&#xff0c…

2026/10/20 20:42:25 阅读更多 →

日新闻

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

CLRC663芯片Pin-to-Pin替代实战:从评估到量产全记录

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
ESP32舵机控制指南:原理、多路驱动与避坑实战

ESP32舵机控制指南:原理、多路驱动与避坑实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →
位移法实现一阶低通滤波:单片机ADC采样降噪实战

位移法实现一阶低通滤波:单片机ADC采样降噪实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 1:01:30 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/20 10:02:13 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/20 20:43:59 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/20 2:50:50 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 10:02:08 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 9:50:17 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/20 9:50:45 阅读更多 →