这是一个创建于 99 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近大量地使用 Cursor 替代了 VS Code, 开始习惯直接在编辑器里告诉 AI 我的需求，让它来代替我写出代码段。
请注意，我用了「代码段」这个词，而不是「代码」，因为我想做一个区分 —— 按照我目前的经验来看，生成式 AI 非常擅长生成一段内聚的代码，而不是一整个应用程序。
在没有 AI 生成代码前，我写代码也是这样的一个流程：
- 思考整个应用的架构、模块
- 选择适合的技术栈
- 开始写代码，设计目录结构、抽象
- 真正开始实现实现
AI 也许能为第 1 和第 2 点提出建议，但我目前不需要。第 3 点我认为对于稍微复杂一点的生产级应用，AI 还做不到把这一块也做到。可能很多人看到现在 Claude 直接能写出一个全功能的 Todo List 就惊叹 AI 要取代程序员了，我觉得真正写过一个完整的给用户使用的「应用」的朋友对此都会很淡定。
对于我来说，只有在第 4 步（实现） 的阶段才真正能杠杆 AI 的能力。我会尽可能地描述清楚我的需求，让 AI 能理解我要做的任务，让它来生成满足我的抽象的代码，或修改现有的代码。
这里我提到的描述清楚我的需求是用 AI 生成代码中最重要的一点。所谓的「需求」不仅仅是描述这个函数需要做什么事情，还需要包含这个函数应该接收什么参数，返回的是什么数据结构。
例如，我在做的一个应用，其中我需要一个上传文件到 S3 的函数。在这个需求中，如果我单纯告诉 AI 它要做什么，那我很有可能得到一个可以实现功能但不适合我调用的函数，因为 AI 没有上下文去确定我可以传哪些参数给它。
在深度和 AI 「结对编程」后，我对于「 AI 是否能取代程序员」这个问题有了更深刻的思考。
有了 AI, 我现在写代码花的精力主要是在「设计」上，例如思考这个应用的交互设计，例如整个应用的架构设计。所谓的架构设计，一部分的工作是决定这个系统里要有什么模块，一部分的工作是决定这些模块如何串联在一起。而这些设计工作恰恰是我写代码的时候最喜欢做的，对我来说，写代码就应该是一个设计的过程，设计出优雅、易用、易扩展的接口是一件很有成就感的事。这也是我当初看 Head First Design Patter 这本书时的感受。 如果写软件变成了一个只需要花精力在设计而不是实现上的过程，那么写软件的人就是「代码艺术家」了。我觉得「代码艺术家」是不会被 AI 取代的，因为设计的起点和终点都是人类，AI 可以给你 100 个设计上的答案，但只有人类最终能感知到现实和当下的环境和信息，创造出能触动另一群人类的产品。
如果你从现在开始，开始把 AI 当作是你的员工，就像某一天你突然只需要 $20 一个月就能招无数多愿意帮你打工的人，你很快就会发现，你最终会面临两种局面：
局面 1：你将手足无措，你突然发现如果你不是实现函数的那个人，你就不知道你应该做什么了。从前你沾沾自喜的手写快排，手写红黑树突然变得一文不值，无处施展。
局面 2：你将如虎添翼，你突然发现你曾经有很多想法没有精力和时间去实现，现在突然有这么多廉价劳动力将不厌其烦地帮你写代码，而你要做的只是设计好整个系统的结构，把具体实现外包给 AI. 然后把产品推出市场，去碰壁，去失败，去成功。显然，AI 不能替代你去碰壁，去失败，去成功，但真正让你变得强大的不是你手写快排有多烂熟于心，而是去碰壁之后学习到的东西。
AI 不会替代「代码艺术家」，因为 AI 是「代码艺术家」的喷射机。
读到这里，可能有人要说，Randy, 你飘了，你开始技术虚无主义了。在这里我要申明，这篇文章我是写给有一定经验的程序员看的。对于没有什么经验的程序员，多写点代码总是好的（至少目前来看）。AI 能力的上限是由用的人的上限决定的。无论是任何行业，充分掌握领域知识后配合 AI 才是最好的做法。
就像下面这个例子，我只要说一句 add tanstack query provider 就能让 AI 帮我把 @tanstack/query 加到我的程序里。我自己会写，但我自己写可能要花一两分钟，但 AI 一下子就好了。
但如果你没有任何代码经验，你连 tanstack query 是什么都不知道，也不知道要放在程序的哪个地方，那用 AI 还是有点困难。
写下这篇文章是因为最近用 Cursor 有感，加上刚好看到 Daniel Nguyen 发了一篇 Software is Art, 有感而发，不吐不快。在此粗浅翻译（非 GPT ），作为结尾：
I realize the reason I like building is not just because I’m a builder.
我意识到我一直喜欢创造点东西的原因不只是因为我就是个创造者.
It’s because software products are how I express my creativity.
而是因为写软件产品是我表达我的创意的一种方式
It’s like a poem to a poet, a song to a songwriter, a painting to a painter…
就像诗人的诗，歌手的歌，画家的画
Software is my art form, my medium of expression.
软件是属于我的一种艺术形式，是我表达（创造力）的媒介。
10 条回复 • 2024-08-12 14:16:44 +08:00
 |
1
JustW 99 天前
已经用习惯 github copilot 了, 现在代码的注释量蹭蹭往上涨.
|
 |
2
Zaden 99 天前
刚在 rss 里看过
|
 |
3
chuunshii 99 天前
写的太棒了，和我感知到的也一样，我们老板非常沉迷于“一句话让 AI 生成一个系统”，我用过 AI 后，发现根本不是那一回事儿。
|
 |
4
yinmin 98 天前 via iPhone  5
老板们马上会发现：在 ai 的助力下，30-45 岁的高级程序员才是效率最高、成本最低的。
新手程序员无法及时发现 ai 的深层次问题，导致调试时间过长和代码存在隐患，而这些问题能被经验丰富的老程序员轻松化解。 |
 |
7
luoling8192 98 天前
感谢推荐！种草了～
|
 |
9
artiga033 97 天前 via Android
是这样的，反正我从 github copilot 刚出那会用到现在，体验就是只能用来写基本业务无关的独立功能，以及测试用例之类的。要么就是 golang C#那种比较啰嗦的语言能省不少样板代码的击键次数。
在涉及到大片核心代码的情况下，ai 极有可能生成不符合我的架构设计的代码，即便能跑也严重影响可扩展性。 |
Select Language