Ai-Literacy

前几天，我的一位同事在内部发了一篇文章，标题是《AI 时代，工作十年的钉钉人如何从「专家」变成「乘数」》。起因是他读了另一篇关于校招生用 AI 加速成长的文章后，坐不住了——年轻人用 AI 一两周就跑通了以前需要几个月才能建立的工作节奏，那工作十多年的老同事呢？

他找了三位在钉钉超过十年的老架构师聊，得出了一个结论： AI 没有替代他们的经验，而是把经验变成了可以复制、可以扩展、可以乘以 N 的东西。

我在评论区写了一段话，后来觉得值得展开写一篇。

上周一个计算机大四学生加我钉钉问：“朱老师，我们宿舍最近吵翻了。一个室友说现在 Cursor 能秒写算法题，刷 LeetCode 是浪费时间，应该去学系统设计；另一个说大厂面试还在考八股，老老实实刷题才靠谱。我已经拿了 offer，再过 4 个月入职——我现在应该学什么？”

这个问题很典型。它背后其实藏着一个更深的认知误区——把"写代码"和"做架构"看作两个独立的阶段，仿佛 AI 替代了前者，后者就可以直接上手。

但真相恰恰相反。AI 不是让你跳过写代码，而是让你在写代码的过程中，同时训练架构思维。 传统的架构师成长路径是"先写 5 年代码，再学系统设计"，而 AI 时代的路径是"从你写第一行代码起，就让 AI 帮你同时跑两条线"。

这篇博客就是写给正在毕业、或者刚入职 1-2 年的计算机专业同学的。我会给你一个可以从 今天 就开始执行的成长路径。

最近钉钉内部做了一次 AI 能力摸底。结果出乎很多人意料——那些平时代码写得最溜、技术栈最广的工程师，在解决客户问题的 AI 协同效率上反而不如几个产品同学和前线服务客户的同学。

我观察了一个细节：区分高下最明显的指标，不是 prompt 写得有多长多花哨，而是他们向 AI 提出的问题本身的质量。

技术强的同学倾向于问：“帮我写一个 Python 脚本，读取 CSV 文件，按日期分组，输出统计报表。"——这是执行指令，不是提问。

而得分最高的一个产品同学问的是：“我现在有一个用户行为日志，想找出哪些功能改版后使用率下降了。你觉得我应该从哪些维度分析？有什么常见的分析陷阱？"——这是真正的提问，它打开了一个探索空间。

这个观察让我意识到一个反直觉的判断：评估一个人是否是 AI 人才，最可靠的指标不是他会用多少 AI 工具，而是他提问的能力。