给 AI 写的代码做一次复杂度体检
三档任务：让 AI 自报复杂度、要求优化一档并说清代价、用大数据量实测验证它没吹牛
本页解决的问题
先给结论「给 AI 写的代码做一次复杂度体检」要解决的关键问题是什么？
三档任务：让 AI 自报复杂度、要求优化一档并说清代价、用大数据量实测验证它没吹牛
跟着交接处走，不要只看 Demo。 系统是否可靠，往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。
为一个自动化步骤写清输入、负责人、审批和恢复动作。
一次运行成功了，却说不清发生了什么，也无法安全重放。
任务一 · 自报家门
让 AI 给自己的代码标注复杂度
拿一段 AI 刚写的函数（没有就让它写一个「找出两个列表里的共同元素」——这题它十有八九先给你 O(n²) 的版本）。把下面的提示词甩过去，让它自己交代快慢。
任务二 · 优化一档
要求提速，更要求说清代价
接着任务一：如果 AI 自报了 O(n²)，就要求它优化到 O(n log n) 或 O(n)——但重点不是变快，是让它说清代价。学完 ds-6 的你，要能在它的方案里指出「空间换时间」发生在哪一行。
任务三 · 实测打脸
用真实数据验证它没吹牛
复杂度是纸面推演，耗时曲线才是铁证。让 AI 写一个基准测试脚本，生成三个量级的随机数据各跑一遍计时，亲眼看优化前后的曲线差多远——顺便检验它自报的复杂度有没有吹牛。
🩺 体检报告生成器 · 填三格，生成可以发群里的总结
「挑一档 · 今天就动手」里的算法代价曲线
「拿一段 AI 刚写的函数（没有就让它写一个 「找出两个列表里的共同元素」 ——这题它十有八九先给你 O(n²) 的版本）。把下面的提示词甩过去，让它自己交代快慢」真正训练的不是背诵步骤，而是识别重复工作：输入变大时，程序到底多做了多少次比较、移动或递归。
先找重复工作，再谈快慢
「接着任务一：如果 AI 自报了 O(n²)，就要求它优化到 O(n log n) 或 O(n)——但重点不是变快，是让它 说清代价 。学完 ds-6 的你，要能在它的方案里指出「空间换时间」发生在哪一行」可以拆成输入规模、每轮做什么、以及是否能缩小下一轮范围三个问题。Big-O 是描述增长趋势的语言，不是对每台机器的精确计时；常数、内存和真实数据分布也会影响最终结果。
- 体检三步走 ：自报复杂度 → 优化并交代代价 → 实测验证，一步比一步硬核
- 瓶颈行是抓手 ：能指出「最慢的是这一行」，验收就有了着力点
- 优化必谈代价 ：不谈可读性和内存的提速方案，都要多问一句
别把理论最优当成无条件最优
面对 AI 写出的算法，先用小输入手算一遍，再用逐渐放大的数据做基准测试。这样才能把「复杂度是纸面推演，耗时曲线才是铁证。让 AI 写一个 基准测试脚本 ，生成三个量级的随机数据各跑一遍计时，亲眼看优化前后的曲线差多远——顺便检验它自报的复杂度有没有吹牛」从一句结论变成可检查的性能判断。
从这个例子继续往下看
这篇内容先从「拿一段 AI 刚写的函数（没有就让它写一个 「找出两个列表里的共同元素」 ——这题它十有八九先给你 O(n²) 的版本）。把下面的提示词甩过去，让它自己交代快慢」展开，再把问题推进到「接着任务一：如果 AI 自报了 O(n²)，就要求它优化到 O(n log n) 或 O(n)——但重点不是变快，是让它 说清代价 。学完 ds-6 的你，要能在它的方案里指出「空间换时间」发生在哪一行」。把这两个片段放在一起看，可以更清楚地分辨：哪些是文章给出的事实，哪些是需要结合条件才能成立的判断。
把这条判断带到下一个场景
算法题换成真实任务后，先找出重复工作，再问输入规模如何变化，最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。
- 「挑一档 · 今天就动手」：拿一段 AI 刚写的函数（没有就让它写一个 「找出两个列表里的共同元素」 ——这题它十有八九先给你 O(n²) 的版本）。把下面的提示词甩过去，让它自己交代快慢
- 「继续往下看」：接着任务一：如果 AI 自报了 O(n²)，就要求它优化到 O(n log n) 或 O(n)——但重点不是变快，是让它 说清代价 。学完 ds-6 的你，要能在它的方案里指出「空间换时间」发生在哪一行
- 「最后的要点」：实测曲线是铁证 ：纸面复杂度可能吹牛，三档数据量的耗时表不会
最后的「最后的要点」把讨论落到「实测曲线是铁证 ：纸面复杂度可能吹牛，三档数据量的耗时表不会」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这一课想和你分享的
- 体检三步走：自报复杂度 → 优化并交代代价 → 实测验证，一步比一步硬核
- 瓶颈行是抓手：能指出「最慢的是这一行」，验收就有了着力点
- 优化必谈代价：不谈可读性和内存的提速方案，都要多问一句
- 实测曲线是铁证：纸面复杂度可能吹牛，三档数据量的耗时表不会
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。