摘要：最近深度使用了 Cursor 等 AI 编程助手，效率提升的同时，却产生了一种“知识空心化”的危机感。本文记录了从“依赖 AI”到“重新审视基础”的心路历程，探讨了在 AI 辅助编程时代，程序员的核心竞争力究竟发生了什么变化，以及如何利用 AI 反向驱动基础知识的学习。

关键词：Cursor, AI 编程, TypeScript, 程序员成长, 代码审查, 系统设计

---

一、引言：效率背后的隐忧

相信很多开发者和我一样，自从入手了 Cursor（或者其他基于 LLM 的 IDE）， coding 的体验发生了翻天覆地的变化：

• 以前需要查文档写半天的样板代码，现在 Cmd+K 一键生成。
• 复杂的正则、晦涩的 SQL、甚至整个模块的重构，只要描述清楚，它都能给出不错的方案。
• 遇到报错，直接把错误日志丢给它，秒出修复方案。

爽吗？太爽了。

但在这种“丝滑”的背后，最近我产生了一种强烈的焦虑感：

“如果离开了 AI，我还能写出这段代码吗？”
“它生成的这个泛型约束是什么意思？我好像只是看懂了表面，没懂原理。”
“如果它写错了，而我连错在哪都看不出来，那我不就成了一个只会‘复制粘贴’的搬运工了吗？”

这种焦虑并非杞人忧天。AI 放大了我们的能力上限，但也无情地暴露了我们的知识下限。

二、角色转变：从“砖瓦工”到“架构师/监理”

在使用 AI 之前，我们花费大量时间在“怎么写”（Implementation）上；而在使用 AI 之后，我们的核心职责发生了根本性的转移。

维度	传统模式	AI 辅助模式 (Cursor)
主要工作	手写每一行代码，查 API 文档	描述需求，审查 AI 生成的代码
核心能力	记忆语法，快速打字，搜索技巧	代码审查 (Code Review), 架构设计, 调试决策
风险点	手误，语法错误，效率低	逻辑陷阱, AI 幻觉，难以维护的“黑盒代码”
你的角色	砖瓦工 (亲自砌墙)	建筑师 + 监理 (画图纸 + 验收质量)

结论：
如果你不懂基础，你就无法胜任“监理”这个角色。

• 你无法判断 AI 生成的代码是“精妙的设计”还是“隐藏的炸弹”。
• 当 AI 产生幻觉（引用不存在的库、写出看似通顺实则错误的逻辑）时，你会被误导。
• 一旦出现深层 Bug，面对一堆 AI 生成的复杂逻辑，你将无从下手，只能陷入“让 AI 再试一次”的死循环。

AI 时代，基础知识不再是用来“手写代码”的，而是用来“判断对错”和“指挥 AI”的。

三、我们需要补哪些“基础知识”？

在 Cursor 的语境下，以下四个维度的基础变得比以往任何时候都重要：

1. 代码阅读与审查能力 (Code Review) > 编写能力

AI 生成代码的速度极快，你需要具备在几秒钟内读懂几十行代码的能力。

• 复杂度分析：它能看出 AI 是否写出了 $O(n^2)$ 的低效循环吗？
• 边界条件：空值处理、并发竞争、异常捕获，AI 往往会忽略这些角落。
• 安全漏洞：SQL 注入、XSS、权限校验，这些必须由人来把关。

2. 系统设计与架构 (System Design)

AI 擅长写局部函数（Local Optimization），但不擅长把控全局架构（Global Architecture）。

• 模块如何拆分？
• 数据流向如何设计才解耦？
• 数据库选型与表结构范式？
  这是 AI 目前最难替代的部分。 如果你的架构思路混乱，AI 只会帮你更快地堆出一座“屎山”。只有你清晰地定义好接口和边界，AI 才能完美落地。

3. 调试与排错 (Debugging)

当 AI 写的代码跑不通时，它给出的修复建议未必是对的。

• 你能读懂复杂的 Stack Trace 吗？
• 你理解语言底层的运行机制吗？（如 JS 的事件循环、Python 的 GIL、内存泄漏原理）
• 只有懂原理，你才能精准地告诉 AI：“这里不对，是因为 XXX 机制导致的，请修改为 YYY 写法”，而不是盲目地让它“再修一下”。

4. 语言底层特性与最佳实践

AI 有时会写出“能跑但很烂”的代码。

• TypeScript 类型体操：理解 Partial, Record, Pick 的原理，你才能写出更好的 .cursorrules 来约束它，而不是让它生成一堆 any。
• 设计模式：知道什么时候该用单例、工厂或观察者模式，才能指挥 AI 进行正确的重构。

四、实战案例：从一段 TS 代码看基础的重要性

前几天，我在处理一个表单联动逻辑时，Cursor 生成了这样一段代码：

const strategyMap: Partial<Record<AssetField, (idx: number) => void>> = {
    assetCategoryMajor: handleAssetCategoryMajorChange,
    revitalizationType: handleRevitalizationTypeChange,
    currentStatus: handleCurrentStatusChange
};

如果我不懂基础：
我可能直接复制粘贴，觉得“哇，好高级，能跑就行”。一旦 AssetField 新增了一个字段，或者 handle 函数参数变了，我可能完全不知道哪里会爆红，也不知道为什么要用 Partial。

如果我懂基础：
我会立刻意识到这是一个策略模式 (Strategy Pattern) 的实现：

1. Record<K, V>：定义了一个键为 AssetField，值为函数的映射表。
2. Partial<T>：关键！这意味着我不需要为所有字段都提供处理函数，未定义的字段会是 undefined。这避免了冗余代码。
3. (idx: number) => void：统一了所有策略函数的签名，保证了调用的规范性。
4. 价值：这种写法消除了大量的 if-else 或 switch-case，极大地提高了可扩展性。

正是因为懂了这些基础，我才能：

• 放心地使用这段代码。
• 指导 AI：“请用策略模式重构这段 switch 代码，利用 TypeScript 的 Partial<Record> 类型来确保类型安全。”
• 在出问题时，迅速定位是类型推断错了，还是函数签名不匹配。

五、如何利用 Cursor“反向学习”？

既然焦虑解决不了问题，不如把 Cursor 变成你的私人导师。不要只把它当代码生成器，试试以下 Prompt 技巧：

1. 追问“为什么”

不要只接受代码。选中生成的代码，问：

“这段代码为什么要用 Partial<Record<...>> 而不是直接定义接口？这样做有什么优缺点？在什么场景下不适用？”

2. 让它解释报错原理

遇到 Bug 时：

“请先解释这个报错的根本原因是什么？涉及到底层的什么机制（如事件循环、作用域链等）？然后再给出修复方案。”

3. 代码走查 (Walkthrough)

“我是 TypeScript 初学者，请像老师一样，逐行解释这段代码中的每一个语法点，特别是泛型和工具类型部分。”

4. 对比学习

“请用‘新手写法’和‘资深工程师写法’分别实现这个功能，并列出两者的区别、性能差异和维护成本。”

六、结语

AI 不会淘汰程序员，但“会用 AI 且基础扎实”的程序员，一定会淘汰“只会用 AI 但不懂原理”的程序员。

感到焦虑是好事，这说明你在思考，你在试图掌控工具而不是被工具奴役。
继续大胆地使用 Cursor，让它帮你省去重复劳动的“搬砖”时间。然后，把省下来的时间，全部投入到对底层原理、系统设计和代码质量的深度学习中去。

这才是 AI 时代，程序员的终极进化之路。

---

参考资料：

• TypeScript Official Documentation: Utility Types
• Design Patterns: Elements of Reusable Object-Oriented Software
• Cursor Documentation