关于 AI 辅助软件工程的思考
刷 LinkedIn 或 YouTube，感觉每个人要么想卖你点什么，要么想吓唬你。
- “我在一个周末就用共鸣编码做出了这个每月经常性收入 100 万美元的应用”
- “XYZ 公司因 AI 裁掉 80% 员工”
- “如何通过这种新的 AI 工作流程提升 20 倍效率”
取决于你是谁以及你从事何种工作，这听起来要么非常可怕，要么是巨大的机会。本文试图提供一个更现实的视角，基于我在大型代码库的日常软件工程工作以及较小个人项目中实际使用这些工具的经验。
Much of what Andrej Karpathy describes in his recent post matches my experience. If you haven’t read it, it’s worth your time.
我在全文中将“AI”和“LLM”交替使用。
自我与身份
当我读到 Karpathy 的帖子时，确认了过去大约三个月里我和可能许多其他人也有的很多体验。
“[…] 我迅速从十一月大约 80% 手动+自动补全编码、20% 代理编码，变成十二月 80% 代理编码、20% 编辑+润色。也就是说，我现在确实主要用英语在编程，有点羞涩地用语言告诉 LLM 要写什么代码……这会伤到自尊心一点，但 […]”
尤其是“它会伤到自尊心”这部分引起了我的共鸣。为什么？软件工程和编写代码是我身份的一部分。如果在职业场合有人问我是谁，我大概会说“我叫 Joshua，我是软件工程师”。我把很多时间都花在写代码和调试上——在大学、在工作中以及在几个副业项目里。Stack Overflow 就像第二个家，而你偶尔也会去某个无名博主的文章里寻找那些在别处无处可查的解决方法。
在某种程度上，写代码是我谋生的方式。我一直很喜欢写代码，现在仍然享受它。如今人工智能在写代码方面相当出色，所以你辛苦积累的编码技能（也因此包括你作为一个人的价值）似乎变得不那么珍贵了。我认为这正是伤害自尊心的原因所在。
好消息是，软件工程远不止写代码。它关乎沟通与协作。它关乎提出正确的问题和 理解你的用户真正需要什么 。它关乎复杂的设计和架构决策，这些决策既影响技术层面，也影响系统的社会/组织层面。
幸运的是，依我之见，人工智能在这些任务上尚未表现出色——尤其是在复杂的社会技术系统中。我认为原因有好几个，但可能最重要的是缺乏上下文。茶水间的一次闲聊、午餐时与别队同事的一段对话——除非你提供给 AI，否则这些信息都不可得。很多信息是隐含的，存在于你脑海的某个角落，直到在恰当的时刻你才想起来。
也许有些天真，但我认为我们不应过于担心被人工智能取代，或担心未来不再需要软件工程师。相反，我们应更多关注未来将变得更重要的技能，以及如何利用人工智能辅助的工作流程为己所用。
Kent Beck，敏捷宣言的最初签署者之一，如此表述：
未来不是人工智能取代开发者，而是开发者学会与这些强大的新伙伴共舞，同时保持能创造可持续软件的纪律。
当前的局限性
卡尔帕西（Karpathy）描述了当前 AI 辅助编码存在的一些问题：
“他们（LLMs）也非常喜欢把代码和 API 复杂化，膨胀抽象，不会在事后清理无用代码，等等。他们会用超过 1000 行的代码实现一种低效、臃肿、脆弱的构造，而你得像‘嗯，不能改成这样吗？’他们会回答‘当然！’并立刻把它缩减到 100 行。他们有时仍会作为副作用更改/删除他们不喜欢或不够理解的注释和代码，即便这些与当前任务无关。”
这正是我在用 AI 完成较复杂任务时的真实体验。我想这也解释了为什么许多技术经验很少甚至没有经验的人在尝试 AI 辅助编程时会较早遇到瓶颈。他们缺乏判断代码臃肿或内部结构过于复杂的经验和直觉。我做过几次实验，完全不看代码，仅根据输出和错误信息提示 AI。到某个程度，它会陷入循环，试图修复由糟糕设计或本可预防的问题引起的错误。改进的工作流程，比如“把它[AI]放入循环中”并提供合适的工具，可能能解决一些问题，但我认为这并不能发现根本性的设计问题。
大量编写和阅读过代码的人更有可能更早发现这些问题，并能将 AI 引导到另一个方向或自行修复。 Peter Steinberger 在接受 The Pragmatic Engineer 采访时曾说过类似的话 “[…] 一切都只是一个问题的距离，但你必须知道该问什么问题”，我认为这正是很多人在开始使用 AI 辅助编码时所忽略的。
软件与人工智能行业正在迅速变化。 模型会变得更好、错误更少，工具和工作流程会改进，希望训练和推理所需的资源也会减少。 不过，我认为成功的软件工程最重要的因素仍将是具备扎实技术专长和经验的人的作用。 软件工程不仅仅是编写代码，这意味着仍有很大一部分工作尚待完成。 即便是在编写代码方面，我认为如果你具备扎实的技术理解并且对什么是优秀代码与不太优秀的代码形成了某种直觉，你更有可能取得成功。
学习与失败
Karpathy 描述说他手动编写代码的能力正在下降。
“我已经注意到自己在慢慢开始退化手写代码的能力。”
我想有类似工作流程的大多数人都会同意。长期来看，“写更少代码”会如何发展，以及它将如何影响那些从未学会手工编写代码的人，将很值得关注。
当我手工编写代码时，通常需要反复迭代好几次，直到对结果满意为止。把我的想法翻译成代码有助于暴露我思维中的空白，并让我更多地了解问题和系统上下文。从某种意义上说，这类似于写日记或博文。
在学习（或去学习）语境中，我觉得更有趣的是失败（以及摩擦）。 失败是学习的重要组成部分。 大学生活的重要部分就是通过失败来学习。 没有什么比在一个艰难的问题上花好几个小时，起初失败，但不断迭代直到成功并获得多巴胺快感更让人满足的了。
Karpathy 也谈到了失败和错误：
“这些模型确实仍然会犯错……模型会做出错误的假设……它们也不会管理自己的困惑，不会寻求澄清，不会揭示不一致，不会呈现权衡，也不会在应该反击时提出异议……”
虽然从技术上说模型确实犯了错误，但感觉像是在把失败推给它。当我使用 AI 而它生成了糟糕的东西时，我往往会责怪它而不是责怪自己。我知道我仍然要对结果和我交付的代码负责，但在这个过程中感觉不像是我在犯错。甚至在第五次告诉它使用 Svelte 5 语法后，还会激起愤怒的想法。我不知道其他人是否也有同感，但我在想这会如何影响学习的过程。
另一方面，与代码保持更疏离常被认为是积极影响。或许不把代码审查太当回事更好。不过，我认为关于失败和摩擦对学习重要性的问题仍然存在，尤其是对于刚入大学或学校的人来说。
已有一些早期研究。Anthropic 发表了一篇名为《How AI Impacts Skill Formation》的论文 ，他们在一篇博客文章中对其进行了总结 。有一项发现尤其引人注目：
“两个群体得分差距最大的是调试题，这表明理解代码何时不正确以及为何会失败的能力，可能是如果人工智能阻碍编程发展时的一个特别令人担忧的领域。”
这表明，如果你想最大化系统理解，可能应在初期减少对 AI 的使用，改用一些“高得分交互模式”，例如“先生成后理解”的方法。我不是研究设计方面的专家，无法判断这些结果是否稳固，但至少它提供了一个指示。
结论是：如果你想学习新知识或培养新技能，要抵制一开始就用 AI 生成所有解决方案的诱惑。可以用它来询问提示或让它解释概念。如果你只是试验或构建某个不需要深入理解且可能最终丢弃的东西，那就走最快的路径，让 AI 生成代码，但要知道你会学到较少。
我是这样看的：
下一步该往哪走？
我认为 Karpathy 文章中的以下引述是思考这个问题的一个良好起点。
“[…] LLM coding 会把工程师分成那些主要喜欢编程的和那些主要喜欢构建的两类。”
那些主要喜欢编程却因为自尊心而不采用 AI 辅助工作流的人，迟早可能会被甩在后面。另一方面，那些只关心构建而不在意代码质量的人，可能会因为缺乏理解、对代码脱节而更早遇到瓶颈。我认为最佳点位于二者之间。如果你问我该怎么做，这是我的策略：
学习基础： 理解基础将比掌握每种语言或框架的细枝末节更为重要。开始学习一项新技术或编程语言时，把 AI 当作教练或导师，而不是用来生成所有代码。刻意偶尔避开 AI，去经历失败和摩擦，以此优先追求理解而不是速度。
实验： 一切都在快速变化，现在几乎不可能不产生对人工智能的错失恐惧症。对新趋势保持好奇，同时避免被每一次热潮所诱惑。偶尔尝试新的工具和工作流程。如果某样东西有效，就继续使用；如果无效，就换别的——就是这么简单。寻找你信赖的博客或人物，观察他们在做什么或使用什么。最重要的是，先构建起扎实的工具和工作流程基础，避免在五个不同的 IDE 之间频繁切换。
构建 点东西： 如今构建和发布软件从未如此简单且成本低廉。看看你是否喜欢发布产品的其他方面，比如市场营销或销售。它不必成为下一个独角兽，可以是很小的东西，仅供你或朋友使用。也许你可以通过自己构建来替代一项每月订阅。你可以把它作为一个副业项目，以最小的投入完成。
软技能： 我认为人的方面将变得更加重要，软技能的价值会更高。为什么？如今几乎每个人都可以借助 AI 翻转二叉树或解决困难的 LeetCode 问题。更重要的是你是否能够团队协作并有效传达你的想法。学会沟通，学会更真实地表达自己，学会领导。
人脉与个人品牌： 在人工智能无处不在的时代，我认为信任将比以往任何时候都更重要。我不会仅仅因为某人能解决困难的 LeetCode 问题就雇用他们。相反，我会寻找那些我信任能把工作做好并且知道如何交付优秀软件的人。如何判断谁值得信任？我认为这部分变得更加困难了。许多传统的软件工程面试存在问题，因为它们主要关注硬技能和编写代码的能力。因此，我的假设是建立人脉和声誉变得更为重要。你可以通过为开源项目做贡献、在博客上分享你的学习、构建自己的产品以及与工作内外的人建立联系来实现这一点。
这并非魔法，也不会让你一夜之间成为出色的软件工程师。在 AI 出现之前，这些都已经很重要，但其重要性的侧重点发生了变化。时不时重新校准你的方向盘，考虑什么真正有助于你个人和职业发展，会有所帮助。五年后再读这篇文章，看看这个策略是否奏效，将会很有趣。
这篇文章比原计划写得更长，但写出来并分享一些想法让人很舒心。我希望它能激发你的思考，或者在面对喧嚣的 AI 炒作和耸人听闻的标题时，鼓励你以更积极的眼光看待事物。
顺便说一句，我最初是完全在没有 AI 帮助的情况下写完整篇文章，后来才用它来改善拼写和表达的清晰度。 你可以在这里阅读无 AI 版本。
