算法复杂度分析:从O(1)到O(n²),掌握程序性能评估的核心
1. 项目概述算法分析从“能用”到“好用”的必经之路刚入行的朋友或者正在啃《数据结构与算法》这门硬课的同学是不是经常有这样的困惑我写的代码明明能跑出正确结果为什么一提交到在线评测系统OJ就超时为什么别人的程序处理百万级数据只要0.1秒我的却要卡上好几秒这背后就是“算法分析”在起作用。算法分析简单说就是评估一个算法好坏的科学方法。它不关心你的代码风格是否优雅变量命名是否规范它只关心两个核心指标时间和空间。你的算法跑得有多快占用了多少内存在数据量急剧膨胀时它的表现会如何变化这些问题算法分析都能给你一个量化的、理论上的答案。很多人觉得算法分析很抽象离实际开发很远。但恰恰相反它是连接“玩具代码”与“工业级代码”的桥梁。比如你写了一个排序功能在小数据集上测试飞快你就觉得万事大吉了。可一旦用户上传一个包含十万条记录的Excel文件你的程序可能就直接卡死或内存溢出。算法分析能让你在编码之前就预见到这种“灾难”从而引导你选择更优的算法。它回答的不是“这个算法能不能工作”而是“这个算法在什么规模下能高效工作”。无论是面试中要求你分析时间复杂度还是在系统设计时评估接口的QPS每秒查询率上限算法分析都是你必须掌握的基本功。今天我们就抛开那些复杂的数学公式用最直白的方式把算法分析的核心——时间复杂度与空间复杂度——给讲透并分享一些我踩过坑后才明白的实操心得。2. 核心概念拆解时间与空间的较量2.1 时间复杂度你的算法“快”吗时间复杂度顾名思义就是衡量算法执行时间随输入数据规模增长而变化的趋势。注意这里说的不是具体的秒数因为同样的算法在不同性能的CPU上跑时间肯定不一样。我们关心的是增长的数量级。举个例子你要在一本无序的电话簿里找一个人的号码。最笨的方法是从第一页开始一页一页翻直到找到为止。如果电话簿有n页在最坏情况下你要找的人在最后一页你需要翻n次。我们称这个算法的时间复杂度是O(n)读作“大O n”。这意味着执行时间与数据规模n成线性正比关系。如果电话簿页数翻倍最坏查找时间也大致翻倍。如果电话簿是按姓名拼音排序的你就可以用二分查找法从中间翻开看目标姓名在前半部分还是后半部分然后扔掉不可能的一半在剩下的一半里重复这个过程。这样每次比较都能排除一半的数据。最坏情况下你需要翻看多少次是 log₂n 次以2为底的对数。我们称其时间复杂度为O(log n)。当n从1000增长到100万时O(n)算法可能需要多花1000倍时间而O(log n)算法只需要多花大约2倍的时间因为log₂1000≈10 log₂1000000≈20。这就是高效算法的威力。常见的时间复杂度等级从快到慢O(1)常数时间。无论数据量多大操作时间都固定。例如通过数组下标访问元素、在哈希表中查找一个键理想情况下。O(log n)对数时间。非常高效典型代表是二分查找、平衡二叉树的查找。O(n)线性时间。数据量增加一倍时间也增加一倍。例如遍历一个数组。O(n log n)线性对数时间。许多高效排序算法的复杂度如快速排序、归并排序。O(n²)平方时间。数据量增加一倍时间增加四倍。常见于简单的双重循环如冒泡排序、选择排序。O(2^n)指数时间。极其缓慢数据量稍大就不可接受。例如求解斐波那契数列的朴素递归算法。注意大O表示法描述的是最坏情况或一般情况下的渐进上界。它忽略常数因子和低阶项。比如一个算法执行了3n² 100n 500次操作我们只取最高阶项n²并去掉系数记作 O(n²)。因为当n非常大时n²项主导了整个增长趋势。2.2 空间复杂度你的算法“省”吗空间复杂度衡量的是算法在运行过程中临时占用的存储空间大小随数据规模增长的趋势。这里主要关注的是额外空间即除了输入数据本身所占空间外算法运行所需的辅助空间。比如我们要反转一个数组。一种方法是创建一个同样大小的新数组然后从后往前遍历原数组依次放入新数组。这个方法需要额外开辟一个大小为n的数组所以它的空间复杂度是O(n)。另一种“原地”算法是使用双指针一个指向开头一个指向末尾交换它们指向的元素然后指针向中间移动直到相遇。这个方法只使用了几个固定的临时变量用于交换没有使用与n成比例的额外空间所以它的空间复杂度是O(1)即常数空间。在内存有限的嵌入式系统或者处理超大规模数据如大数据分析时空间复杂度往往和时间复杂度一样重要甚至更重要。一个O(n)空间复杂度的算法可能在数据量达到千万级别时就因为内存不足而崩溃。2.3 时间与空间的权衡在算法设计中时间和空间常常是一对需要权衡的矛盾体。有时我们可以用更多的空间来换取更快的速度这被称为“空间换时间”。经典案例哈希表 vs. 平衡二叉搜索树哈希表如Java的HashMap Python的dict在理想情况下插入和查找的时间复杂度是O(1)极快。但它需要预留一个较大的数组桶来减少哈希冲突并且需要存储额外的指针等信息空间开销较大。这是一种典型的“空间换时间”。平衡二叉搜索树如Java的TreeMap C的std::map插入和查找的时间复杂度是O(log n)比哈希表慢但它不需要大的预留空间并且能自动保持元素有序节省了排序的开销。这是一种相对均衡的选择。在实际开发中选择哪种结构就需要根据你的具体场景来分析是追求极致的访问速度还是需要节省内存或者需要范围查询、有序遍历等额外功能算法分析为你提供了做出这些理性决策的理论依据。3. 如何进行算法复杂度分析从代码到“大O”理论懂了怎么应用到自己的代码上呢我们通过几个典型例子手把手分析。3.1 单层循环分析int sum 0; for (int i 0; i n; i) { // 循环执行 n 次 sum i; // 每次循环执行1次操作 }循环体执行了n次每次的操作是常数时间O(1)。所以总时间复杂度 n * O(1) O(n)。 空间上只使用了固定的变量sum和i与n无关所以空间复杂度是O(1)。3.2 双层嵌套循环分析for (int i 0; i n; i) { // 外层循环 n 次 for (int j 0; j n; j) { // 内层循环 n 次 printf((%d, %d) , i, j); // 常数操作 } }外层循环执行n次。对于外层循环的每一次内层循环都完整执行n次。所以printf语句总共执行了 n * n n² 次。时间复杂度为O(n²)。 空间复杂度依然是O(1)。3.3 递归算法分析递归的分析稍复杂常用递归树法或主定理。我们看一个简单的例子计算阶乘的递归int factorial(int n) { if (n 1) return 1; // 递归基 O(1) return n * factorial(n - 1); // 递归调用 }这个递归的深度是n。每一层递归除了调用自身只做了乘法O(1)和返回操作。所以总时间开销 ≈ n * O(1) O(n)。 空间上递归调用会在调用栈上保存每一层的局部变量和返回地址栈的深度也是n所以空间复杂度也是O(n)。这是递归需要注意的地方可能带来额外的空间开销。3.4 对数复杂度是如何产生的对数复杂度通常出现在每次操作都将问题规模减半或按固定比例减小的情况下。二分查找是最标准的例子def binary_search(arr, target): left, right 0, len(arr) - 1 while left right: # 循环条件 mid (left right) // 2 if arr[mid] target: return mid elif arr[mid] target: left mid 1 # 舍弃左半部分 else: right mid - 1 # 舍弃右半部分 return -1初始搜索范围是n。第一次比较后范围缩小到约n/2第二次缩小到n/4第三次n/8... 直到范围缩小到1。设循环次数为k则有 n / (2^k) ≈ 1推导出 k ≈ log₂n。所以时间复杂度是O(log n)。这里循环变量left,right,mid都是固定数量的变量空间复杂度为O(1)。4. 实战场景中的复杂度抉择与避坑指南懂了理论我们来看看在真实项目中如何运用算法分析来避坑和优化。4.1 场景一数据检索——从O(n)到O(log n)的飞跃假设你正在开发一个用户管理系统需要根据用户ID快速查找用户信息。最初你用一个ListUser存储所有用户。查找时你写了一个遍历public User findUserById(ListUser userList, int id) { for (User user : userList) { if (user.getId() id) { return user; } } return null; }当用户量只有几百时这没问题。但当用户量达到百万级n1,000,000最坏情况下需要遍历一百万次每次数据库或内存对比接口响应时间可能达到秒级用户体验极差。时间复杂度是O(n)。优化方案使用哈希表HashMap。将用户ID作为键用户对象作为值存入。MapInteger, User userMap new HashMap(); // 初始化时将所有用户放入map // 查找时 User user userMap.get(id);HashMap的get操作在良好的哈希函数和负载因子下平均时间复杂度是O(1)。这意味着无论有一千个还是一千万个用户查找时间几乎恒定。这就是通过选择合适的数据结构将复杂度从O(n)优化到O(1)的经典案例。当然代价是消耗了更多的内存O(n)空间来存储这个映射关系。实操心得不要一上来就追求最完美的数据结构。如果数据量很小比如1000O(n)的遍历可能比O(1)的哈希表更快因为哈希表有计算哈希值、处理冲突等开销。“先让程序跑起来再用数据驱动优化”是更务实的做法。当性能监控发现这个查找接口调用频繁且耗时成为瓶颈时再引入哈希表优化。4.2 场景二排序算法选择——理论复杂度和实际性能排序是算法分析的试金石。教科书上会讲一堆排序算法冒泡排序O(n²)、插入排序O(n²)、选择排序O(n²)、归并排序O(n log n)、快速排序O(n log n)。为什么实践中我们几乎总是用快速排序或类似变体如Arrays.sort()底层用的Timsort因为虽然它们和归并排序的理论平均复杂度都是O(n log n)但快速排序的常数因子更小。也就是说在公式c * n log n里快速排序的c值通常比归并排序小所以在实际运行时更快。而且快速排序是原地排序空间复杂度O(log n)~O(n)取决于实现而归并排序需要O(n)的额外空间。但是快速排序有一个致命弱点在最坏情况下比如数组已经有序朴素快排会退化成O(n²)。这就是为什么工业级的排序实现如Java的DualPivotQuicksort会做大量优化随机化枢轴、三数取中、小数组切换为插入排序、递归深度过大时切换为堆排序等来避免最坏情况保证在实际应用中高效稳定。给你的建议除非有极特殊的场景如要求稳定排序且不能修改原数组且空间充足可能选归并否则对于通用排序相信语言标准库的实现。它们是由顶尖专家优化过的比你手写的99%的排序都要快和稳。你的工作不是重写排序而是理解它们的特性在必要时如排序复杂对象提供高效的比较器Comparator。4.3 场景三递归的美丽与危险——以斐波那契数列为例斐波那契数列定义F(0)0, F(1)1, F(n)F(n-1)F(n-2) (n2)。 最直观的递归实现def fib(n): if n 1: return n return fib(n-1) fib(n-2)这个代码简洁优美但性能是灾难性的。我们来分析它的时间复杂度。画出一棵递归树计算fib(n)需要计算fib(n-1)和fib(n-2)计算fib(n-1)又需要计算fib(n-2)和fib(n-3)……你会发现fib(3)、fib(2)等子问题被重复计算了无数次。可以证明其时间复杂度是惊人的O(2^n)。计算fib(50)可能需要数小时甚至更久。空间上递归深度为n空间复杂度O(n)。优化方案1记忆化搜索自顶向下动态规划memo {} # 用一个字典保存已计算的结果 def fib_memo(n): if n 1: return n if n not in memo: memo[n] fib_memo(n-1) fib_memo(n-2) return memo[n]这样每个子问题如fib(i)只计算一次结果被保存下来。时间复杂度骤降至O(n)每个值算一次空间复杂度O(n)用于存储备忘录。优化方案2动态规划自底向上迭代def fib_dp(n): if n 1: return n dp [0] * (n1) dp[1] 1 for i in range(2, n1): dp[i] dp[i-1] dp[i-2] return dp[n]同样时间复杂度O(n)空间复杂度O(n)。但我们可以进一步优化空间因为计算fib(n)只需要前两个状态def fib_iter(n): if n 1: return n a, b 0, 1 for _ in range(2, n1): a, b b, a b return b这就是迭代法时间复杂度O(n)空间复杂度优化到了O(1)。避坑指南递归是解决问题的强大思维工具但在使用时一定要警惕重复子问题。如果递归函数中包含了多个递归调用并且参数有重叠很大概率存在重复计算。这时记忆化搜索或动态规划就是你的救命稻草。在面试中写出朴素递归通常只能得到基础分指出其复杂度缺陷并给出优化方案才能拿到高分。5. 高级话题与性能分析实践5.1 均摊分析看待复杂度的另一个视角有些操作单次看可能很耗时但平均到一系列操作上代价却很小。典型例子是动态数组如Java的ArrayList Python的list的扩容。当数组已满需要插入新元素时它会申请一个更大的新数组通常是原容量的1.5或2倍然后把所有旧元素拷贝过去。这次插入操作的时间是O(n)看起来很糟糕。但是在接下来的n-1次插入中除非再次触发扩容否则都只需要O(1)时间。均摊分析告诉我们将一次昂贵的扩容开销平摊到之前所有廉价的插入操作上每次插入的均摊时间复杂度仍然是O(1)。这就是为什么我们说动态数组的append操作是O(1)均摊时间。理解这一点你就不会因为害怕偶尔的扩容而不敢使用ArrayList。5.2 实际测量与理论分析的互补理论复杂度分析是强大的指南但绝不能替代实际测量。因为大O表示法忽略了常数因子和低阶项。一个O(n)的算法如果常数巨大在n较小时可能比一个O(n log n)的算法慢。如何进行实际性能分析基准测试使用专门的工具如Java的JMH Go的testing.B对关键代码段进行反复测试获取平均执行时间。性能剖析使用分析器Profiler如Java的VisualVM、Async Profiler Python的cProfile找出代码中的“热点”最耗时的函数或行。关注关键操作在算法中往往有一两种操作是性能瓶颈比如比较次数、内存访问次数。优化这些操作收益最大。我曾经优化过一个图像处理算法理论分析两个方案复杂度相同。但实测发现方案A因为内存访问模式不连续大量随机访问导致CPU缓存命中率极低实际耗时是方案B的5倍。这就是理论分析无法揭示的细节。5.3 空间复杂度的隐藏成本除了显式声明的数组、链表空间复杂度还有一些容易被忽略的“隐藏成本”递归调用栈如前所述深度递归会消耗大量栈空间可能导致栈溢出StackOverflowError。函数调用开销频繁的函数调用尤其是在循环中会带来入栈、出栈的开销。在极端性能敏感的代码中有时需要将小函数内联Inline。缓存友好性访问连续内存如数组比访问跳跃的内存如链表中的节点快得多因为CPU缓存能更好地预取连续数据。虽然这不直接影响空间复杂度的“大O”但深刻影响实际运行速度是算法设计中“常数因子”的重要部分。6. 从理论到面试常见考题与回答思路算法分析是技术面试的必考环节。面试官不仅想听你背出复杂度更想考察你的分析能力和工程思维。常见问题1“分析一下这段代码的时间/空间复杂度。”回答框架识别核心操作找出随着输入规模n变化执行次数会变化的操作通常是循环、递归。计算执行次数用数学表达式表示核心操作的执行次数与n的关系。简化成大O保留最高阶项去掉系数和低阶项。说明特殊情况如果有最好、最坏、平均情况之分要分别说明例如快速排序。空间分析分析除了输入外算法额外使用的辅助空间数组、队列、递归栈等与n的关系。常见问题2“有没有办法优化这个O(n²)的算法”回答思路审视内层循环的目的内层循环是否在重复计算之前已经算过的信息能否用查找表哈希表或缓存记忆化来避免重复这是优化到O(n)或O(n log n)的常见思路。数据是否有序如果数据有序能否使用二分查找O(log n)替代线性扫描O(n)这常能将O(n²)优化为O(n log n)。使用更高效的数据结构能否用哈希表O(1)查找替代线性查找O(n)能否用堆O(log n)插入删除维护极值问题是否可分解能否用分治法Divide and Conquer将问题拆解归并排序和快速排序就是分治法的典范。考虑空间换时间是否允许使用额外的O(n)空间来将时间复杂度降低一个数量级常见问题3“在实际情况中你会选择O(n log n)时间、O(1)空间的算法还是O(n)时间、O(n)空间的算法”这是一个经典的权衡问题没有标准答案考察你的工程判断力。回答要点数据规模如果n很小比如1000两者差异不大可能选O(1)空间的代码简单。内存限制如果运行环境内存紧张如嵌入式设备可能被迫选择O(1)空间的算法即使它慢一点。性能要求如果对速度要求极高如高频交易系统且内存充足那么O(n)时间的算法是更好的选择。数据特性如果数据是流式的无法一次性装入内存那么O(1)空间的算法是唯一选择。可以给出折中方案“我会先实现O(n)时间、O(n)空间的版本因为它通常更直观。如果性能测试表明它是瓶颈并且内存压力大我会再考虑优化到O(n log n)时间、O(1)空间的版本并做基准测试对比。”我个人在面试候选人时最欣赏的不是能脱口而出标准答案的人而是能条理清晰地分析出不同复杂度背后的原因并能结合具体场景数据量、硬件、业务要求做出合理取舍的人。这展现的正是算法分析这门学问的真正价值它不是死记硬背的教条而是一种用于设计和评估解决方案的底层思维框架。掌握了它你就能在编码之前预见程序的“未来”写出真正经得起考验的代码。

相关新闻

合同文档解析从人力密集到机器智能:AI原生架构与传统方案的代际差距

合同文档解析从人力密集到机器智能:AI原生架构与传统方案的代际差距

合同文档的智能解析,正在成为企业合同管理数字化进程中一个无法回避的技术分水岭。 过去十年间,绝大多数企业处理合同文档的方式并没有发生本质变化:法务人员逐字审阅、业务人员手动录入关键条款、财务人员从合同中提取付款条件并录入ERP系统…

2026/10/19 0:07:58 阅读更多 →
Win+G录屏无声与音质差?系统级音频链路排查与FFmpeg音频提取全攻略

Win+G录屏无声与音质差?系统级音频链路排查与FFmpeg音频提取全攻略

1. 从“游戏栏”到全能录屏:WinG的隐藏实力如果你还在为找一个免费、无广告、不占地方的电脑录屏工具而发愁,那大概率是忽略了Windows 10系统里一个自带的“宝藏”功能。没错,我说的就是那个按一下Win G键就会跳出来的“游戏栏”。很多人第一…

2026/10/19 0:08:35 阅读更多 →
Rust异步运行时Tokio核心原理与性能优化实践

Rust异步运行时Tokio核心原理与性能优化实践

1. 理解Rust异步运行时的核心价值我第一次接触Tokio时,被它复杂的调度机制搞得晕头转向。直到在线上服务中遇到性能瓶颈,才真正理解异步运行时的价值所在。想象你经营着一家快餐店,同步I/O就像让唯一的服务员在等汉堡煎熟时完全发呆&#xff…

2026/10/16 3:12:10 阅读更多 →

最新新闻

前端Leader转型AI Agent工程化:72天学习路径与实操踩坑总结

前端Leader转型AI Agent工程化:72天学习路径与实操踩坑总结

1. 一个前端Leader的转型焦虑与破局思路1.1 为什么前端Leader会盯上AI Agent先说一个我观察到的现象:身边做前端做到Leader层级的朋友,最近两年普遍有一种"位置很稳但心里很慌"的状态。稳是因为业务熟、团队带得动、跨部门沟通也顺&#xff1b…

2026/10/19 0:57:09 阅读更多 →
科迅捷AI(官方网站:www.kexunjie.com)帮你选对文献综述的三种写法

科迅捷AI(官方网站:www.kexunjie.com)帮你选对文献综述的三种写法

博士论文的文献综述,往往是最先动笔、却最后定稿的部分。为什么?因为综述不是文献的简单堆砌,而是你对一个领域发展脉络的梳理——它得按时间、按流派、按争论,把几十上百年的研究讲成一个有逻辑的故事。写综述的过程,…

2026/10/19 0:57:09 阅读更多 →
科研绘图总被退稿嫌丑?科迅捷AI(官方网站:www.kexunjie.com)从配色到标注给出方案

科研绘图总被退稿嫌丑?科迅捷AI(官方网站:www.kexunjie.com)从配色到标注给出方案

研究生小周第一次投期刊,实验数据做得很漂亮,却被审稿人一句话打回来:图太丑,重画。他很不服气:数据明明都画在图上了,为什么还要挑画面?其实科研图不是把数据摆出来就行,它是你论文…

2026/10/19 0:57:09 阅读更多 →
R语言心脏病术后复发预测:从数据清洗到XGBoost全流程

R语言心脏病术后复发预测:从数据清洗到XGBoost全流程

简介:R语言医学分析教程,聚焦心脏病术后复发预测问题,面向医学数据分析人员、生物统计研究者以及R语言学习者。资源共含906个文件,以91个R脚本、20个RMarkdown可复现文档、13个CSV数据表和6个XLSX工作簿为主体,配套31张…

2026/10/19 0:57:09 阅读更多 →
论文格式自查清单,最后一个很多人都会漏——科迅捷AI(官方网站:www.kexunjie.com)替你补齐

论文格式自查清单,最后一个很多人都会漏——科迅捷AI(官方网站:www.kexunjie.com)替你补齐

本科论文定稿前,很多人把内容改了又改,却在格式上交了白卷:导师一句"格式不对,改完再来",前面的功夫差点白费。下面这份自查清单,按数字排好,提交前逐项打勾,能帮你避开绝…

2026/10/19 0:57:09 阅读更多 →
如何重建 reference_only 语料?humanizer-data 重建脚本 rebuild_reference_only.py 源码深度剖析

如何重建 reference_only 语料?humanizer-data 重建脚本 rebuild_reference_only.py 源码深度剖析

【免费下载链接】humanizer-data 项目地址: https://ai.gitcode.com/hf_mirrors/jialinyyzz/humanizer-data 点击查看 免费下载 humanizer-data 是为 12B 文本重写模型 humanizer v2 准备的训练语料集,其中 reference_only 分片因版权限制不含原文文本。…

2026/10/19 0:56:09 阅读更多 →

日新闻

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

频率跟踪型PWM电源设计:臭氧发生器谐振点漂移与软开关实现

简介:本资源为电源技术方向的学术研究文档,聚焦介质阻挡放电型臭氧发生器电源的频率跟踪型PWM控制策略,面向电力电子、高压电源及臭氧应用领域的科研人员与工程技术人员。针对负载呈容性、等效电容随外加电压升高而增大、谐振频率随之漂移的难…

2026/10/19 0:00:47 阅读更多 →
Vibe Coding 遇上 TaoToken:把开发者思维圣殿的灵感流接入统一 Key 通道

Vibe Coding 遇上 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/19 0:00:47 阅读更多 →
HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

HundredCV-Chat话题建模实战教程:利用4,871个内置话题标签构建主题分析系统

【免费下载链接】HundredCV-Chat 项目地址: https://ai.gitcode.com/hf_mirrors/Jax-dan/HundredCV-Chat 点击查看 免费下载 HundredCV-Chat 是一个由 100 位青年简历数据开发而来的中文多轮对话数据集,共包含 24,750 组日常闲聊对话和 4,871 个话题标签…

2026/10/19 0:00:47 阅读更多 →

周新闻

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

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

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

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

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

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

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

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

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

2026/10/18 0:00:55 阅读更多 →

月新闻

我发现了一个新思路:用 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/18 0:55:02 阅读更多 →
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/17 17:22:31 阅读更多 →
黑夜航拍船只数据集训练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/18 12:16:16 阅读更多 →