在生成 AI 时代，面向新人培养“对自己代码负责的能力”
Back to Top
为了覆盖更广泛的受众，这篇文章已从日语翻译而来。
您可以在这里找到原始版本。
引言
#现在的新人们会如何查询和学习技术呢？通过 Web 搜索，可以找到官方文档、众多技术博客（当然也包括本网站）等相关文章，X (Twitter) 和 YouTube 上也充满了有益的信息。GitHub 上公开了大量 OSS，可以轻松尝试。Udemy、O'Reilly 等在线学习平台也提供了许多高效学习的课程。更不用说生成 AI 了。它常驻在开发工具中，为你编写代码，或者告诉你错误原因。
现在的年轻人信息素养很高，善于利用这些信息源，高效获取知识。
然而，也常常会发生以下情况，不是吗？
- 因为不费太多力气就能做出能运行的东西，导致理解原理的动力被削弱
- 当发生错误时，会凭借 Web 或 AI 上的信息应付了事，而不追究根本原因就结束了
- 真正想深入了解时，不知道从哪里、如何查询，陷入迷茫
换句话说，这就是“信息泛滥、AI 辅助的时代特有的学习难题”。
本文面向这样的时代中的新人，分享一些在掌握技术时，笔者认为值得注意的事项和心态。
在笔者刚当新人时，公司里互联网还不太普及，主要信息来源是安装在 OS 中的命令手册（通过 man 命令阅读的那种）、开发工具附带的（印刷版）手册，以及纸质书籍和杂志等。
当时一边拿着贴满便签的厚厚手册，一边写代码或查错。代码评审也是打印出来用笔批注（当时的电脑屏幕非常狭窄，可视性很差）。
也许会有人觉得这是什么年代了，但笔者自己也感觉与现在相比隔了好几代。由于信息本来就有限，只能根据那有限的信息自己思考、尝试。反过来说，那也是一个开发系统所需的前提和知识比现在少得多的朴素时代。
“能跑就行”的局限
#不仅限于新人，也有一部分人属于“无论如何先谷歌一下，找到合适的代码片段，只要能跑就行”的类型。他们会复制粘贴技术博客或 Stack Overflow 上的代码片段，然后“能跑就行！”。但一旦规范稍有变化，或库的版本不同，就会再次栽跟头。每次都重新查找，虽然能勉强解决，但因为没有根本理解，总是会在类似问题上反复被绊住。希望能养成“为什么会这样？”并深入思考的习惯。
即便使用生成 AI，也只是缩短了能运行所需的时间，而人类所发生的事情本质上并未改变。
近年来，生成 AI 也会在后台进行 Web 搜索，但在刚出现时，它基于模型创建时点的信息，生成的代码常常使用已废弃的 API 而无法运行，这种情况屡见不鲜。
首先阅读官方文档
#曾经，也有一段时间我认为“官方文档没什么用处”。当时，在 OSS 的黎明期，其文档常常不更新、不够友好，且仅有英文，因此通过搜索寻找日语信息更有价值的时代持续了一段很长时间。
但现在情况不同。大多数 OSS 的官方文档都写得非常详尽，是最准确、最可靠的第一手信息。只要 30 分钟，就可以通过 Quick Start 完成安装并运行 Hello World。多语言本地化也已成为理所当然的事，即便只有英文，也可以借助 Google 翻译。
当想要查询某些内容时，如果养成“先看官方”的习惯，理解的深度会有所不同。因为官方文档会明确写出版本差异和配置前提，往往比搜索更快捷、更准确地找到答案。
官方文档中会清楚地写明“规范”“前提”“限制”。例如：
- “此选项仅可在 v2.0 及之后版本使用”
- “此函数会返回 Promise，因此需要用 await 或 then 接收”
如此即可获得软件提供方的准确信息。
通过培养阅读官方文档这一可信第一手信息的“阅读能力”，还会带来以下的附带效应：
- 不仅停留于表面的错误应对，还能进行本质性的修复
- 下次就不会再在相同的问题上绊倒（获得再现能力和预测能力）
- 对新技术的适应力也会提高（能够读懂文档的人吸收速度更快）
在 OSS 普及之前，通常会使用 IBM / Microsoft / Sun Microsystems / Oracle 等企业的专有软件和开发工具。
使用 OSS 进行开发开始普及，是在 Linux、PostgreSQL 等获得了与商用 Unix 操作系统和 DBMS 相当的性能和可靠性之后。随着 Apache HTTP Server 和 Java 在业界被广泛使用，业务中对 OSS 的使用逐渐增多。与此同时，OSS 文档的重要性也开始被认识。
当前的 OSS 项目重视开发者社区的构建，提供教程和友好的文档已成为开发者体验中的必要条件。
出现错误时，首先阅读堆栈跟踪
#当出现错误时，建议不要立即依赖 AI 或搜索，而是先仔细阅读堆栈跟踪。虽然乍看之下不太容易入手，但其中蕴含着解决问题的线索。
当你能清楚地读出“在哪个文件的第几行、由哪个函数调用、因为什么原因导致出错”后，就能自行找到错误原因。首先，请努力尝试读取以下信息。
- 在哪一行、哪个函数、哪个模块发生了失败
- NullPointerException（即常说的空指针错误）、类型错误等的原因
例如，在 JavaScript (Node.js) 中出现如下错误。
TypeError: Cannot read property 'x' of undefined
at doSomething (/src/utils.js:25:13)
at main (/src/index.js:10:5)
在这种情况下，哪里发生了什么错误都清晰地写在了这里。
- 发生了什么 → 试图读取一个 undefined 对象的属性
x - 在哪里发生 → utils.js 的第25行
- 该函数是从哪里被调用的 → 从 index.js 的第10行
通过解读这些信息并与自己的代码对照，就能无需依赖 Web 搜索或 AI 解决许多问题。能够区分哪些是自己代码的问题、哪些是所使用库的错误也很重要。
即使在向 Web 搜索或 AI 提问时，如果只关注表面的错误信息，也经常会出现与实际场景毫不相关的案例，导致花费更多时间才找到解决方案。
一开始可能不太明白，但随着习惯成自然，你会逐渐掌握阅读方法并理解发生原因。从“错误消息中包含了重要信息”这一认知开始吧。
当你能够阅读堆栈跟踪后，在自己编写代码时，也会倾向于写出便于故障分析的错误消息，或者编写易于追踪错误的代码，这些实践对编写易于维护的代码至关重要。
锻炼解决问题的基础能力
#编程是解决问题的手段，其过程本身也是解决问题的连锁。首先必须解决搭建开发环境这一问题。无论是写代码，还是修复错误，都是“遇到问题 → 如何解决”的反复思考[1]。
因此，在编写代码之前先思考“为什么要这么做”，出现错误时也要停下来思考“在哪里发生了什么”，养成这样的习惯会有帮助。
解决问题的能力不是一朝一夕就能获得的。可以慢慢来，请持续“阅读错误消息”“阅读官方文档”“先自己思考”等小习惯。随着自己亲手解决问题的体验不断积累，最终无论在什么环境、面对何种技术，都会形成“总能想办法搞定”的自信。这种自信和经验将成为无论是否依赖 AI 都能独当一面的工程师的基础。
尽情使用 AI。在使用时要注意的事项
#本文并非主张要封印 AI 全部自己解决。笔者本人也在使用 ChatGPT 和 GitHub Copilot。确实很方便，也能提升工作速度。
但如果“将生成的代码未经仔细斟酌就直接使用”成为常态，就存在错失成长机会的风险。
在参考 AI 的答案时，不要忘记以下视角：
- “为什么会这样？”
- “错误是什么意思？”
- “官方文档是怎么写的？”
有了这种“边思考边使用”的习惯，AI 反而会成为加速学习的工具。实际上，由于 AI 大大缩短了从接触技术到开始动手制作的前置时间，能够毫无畏惧地挑战新技术，这本身就是一件美妙的事。
结语
#如果读到这里你觉得“这些我早就都在做了”，那就没问题，请继续前进吧。
笔者年轻时读到过这样一句计算机格言，当时深感赞同。
编译器会帮你编译，链接器会帮你链接。然而，调试器并不会帮你调试。
使用调试器可以逐步执行代码，观察代码行为和变量值等。但调试本身终究还是要由编写者来完成。这一点在生成 AI 时代的今天也并未改变。（啊，或许年轻人听到链接器这个词，也不知道它的存在。嘛，这个不必介意。）
我认为这也与当下的以下情况相契合。
生成 AI 会帮你生成代码，也会帮你查找错误原因。然而，它并不会为生成代码的正确性提供保证。
软件工程师是为了使用系统或服务的人们而编写代码并获取报酬的职业。因此，最终需要对自己编写的代码负责。那么，对代码负责意味着什么呢？就是能够用自己的话解释所写代码的结构和运行方式，并能在规范变更或出现缺陷时自行修正[2]。
虽然也有“负责任的 AI”这一说法，但那是要求 AI 服务提供方承担责任的议题，而不是我们这些工程师把责任推给 AI。
到目前为止，无论生成 AI 如何发展，我认为它都无法成为验证并保证代码正确性的存在。因此，需要由我们人类来完成这项工作。
嘛，工程师这种职业无论有无 AI 都要终身学习，因此无论什么时代来临，都要努力提升以便对自己编写的代码负责。期待各位新人的成长。
