跳到正文
Hacker News· ukuina·· 8 天前AI 评分22

AI 立场并非二元对立

AI stance is not binary

AI 导读

软件工程中使用 AI 并非只有完全委托或完全拒绝两种立场,更合理的模式是像接力赛一样分工:工程师负责理解问题、设计架构、权衡取舍与调试,AI 负责探索方案、编写重复代码、准备测试和实现明确定义的组件。文章提到 37signals 已将 AI 智能体作为默认代码生成工具,手写代码成为例外,但作者认为若只以代码产出量衡量,就已选错了赛道。

正文 · AI 翻译

关于 AI 的讨论常常假装只有两种可能的立场:完全委托,即机器产出一切、人类只监督结果;或者完全拒绝,即使用 AI 工具就被视为放弃这门手艺本身。

但使用 AI 并不自动意味着认为它应该取代工程师,正如拒绝使用它并不意味着认为它毫无用处。尤其是在软件工程中,有趣的问题不是人类是否应该使用机器,而是人类与机器应该如何协作。

为了解释我的看法,我喜欢用一个简单的例子:想象一位跑步者被要求训练一个机器人去跑著名的 100 米赛跑。
人们会为这项任务设想两种不同的可能性。但实际上,还有第三种(隐藏的)……

电视上的教练 #

第一种可能性是跑步者不再跑步。

相反,他坐在沙发上看电视里机器人跑步,并给它下指令:

把膝盖抬得更高。

步幅迈得更大。

呼吸更有规律。

机器人需要非常精确的指令,因为它不像跑步者那样理解这项运动。每一次改进都必须转化为一条新的、具体的命令。随着这些指令变得越来越具体,跑步者也越来越难以解释清楚,机器人也越来越难以正确执行。

与此同时,跑步者正在变胖。

他不再训练,自身的能力越来越差,也越来越难以理解机器人在做什么。他可能仍然掌握着跑步的理论,但他正在失去对这项运动的身体感觉。

这是一个奇怪的教练。
他有知识,却不实践。最终,他会既失去知识,也失去训练的能力。

这就是当工程师完全委托编程行为、只看着智能体产出代码时会发生的事:工程师或许仍然能够给出指令,但通过解决问题而培养出的直觉正在慢慢消失。

一起跑 #

第二种可能性更诚实,但不一定更有用。

跑步者和机器人同时跑同一条赛道。跑步者一边训练机器人,一边试图击败它。

这让人精疲力竭。跑步者必须跑步、观察机器人、纠正它、比较彼此的表现,还要继续跑。

而且,如果跑步者无论如何都得跑同一条赛道,那训练机器人跑步又有什么意义呢?

这有时就是我们使用 AI 工具的方式。我们让智能体实现一个功能,但每一行、每一个决定、每一个生成的文件我们都守在旁边。我们仍然在做工作,但现在还要监督另一个做着同一工作平行版本的工人。
现在,想象一下不是只有一个机器人,而是 10 个机器人并行……这通常会导致倦怠。

结果可能有用,但也可能是一种非常昂贵的写代码方式,代价是跑步者的健康。

改变运动 #

还有第三种可能性。

与其让跑步者和机器人在同一条赛道上竞争,我们可以改变这项运动。我们可以把个人 100 米赛跑变成接力赛。

跑者并不跑完全程,而机器人跑完全程;相反,他们分工合作:跑者跑一段,把接力棒交给机器人,机器人再跑另一段。他们需要彼此才能获胜。

这不是妥协,而是一种不同的运动。

跑者仍在训练。机器人也在训练。
跑者仍然负责理解比赛,但不会浪费精力去跑机器人能跑好的同一段。 机器人不需要变成人类跑者。它只需要擅长接力赛中自己的那一部分。

这就是我对 AI 感兴趣的那种协作方式。

工程师可以继续处理困难的部分:理解问题、设计架构、做出权衡、审查结果、编写最复杂的代码,以及在现实与计划不符时调试系统。

AI 工具可以处理其他部分:探索替代方案、编写重复性代码、准备测试、搜索文档,或者在工程师处理另一个问题时实现一个定义明确的组件。

缺失的中间地带 #

这不是互联网上普遍推崇的方法。大多数讨论都是二元对立的,因为二元立场容易解释,也容易推销。

一方说 AI 会让软件工程师过时,另一方则拒绝使用它(有时把每一行生成的代码都视为对这门手艺本身的攻击)。

双方都可能忽略一个实际问题:人类和机器应该一起做什么样的工作?

Michael Hashimoto 在他的 AI 采用文章中描述了一段更有趣的历程。他没有立即接受每一个 AI 工具,也没有永远拒绝它们。他尝试复现自己的工作,了解了智能体在哪些地方有用,在哪些地方浪费时间,并围绕验证构建了一套工作流程。

David Heinemeier Hansson(即 DHH)最近在 Rails World 上描述了一个激进得多的立场。根据这篇报道,37signals 现在将 AI 智能体视为默认的代码生成工具,而手写代码已成为例外活动。

这对某些类型的工作可能很高效。但如果唯一的衡量标准是产出的代码量,那么我们已经选错了运动。

软件工程不是百米赛跑,赢家是每秒产出字符最多的人,而更(更更)接近接力赛,交接的质量与每个跑者的速度同样重要。
困难的部分不只是产出代码,而是知道应该产出什么、为什么它应该存在,以及如何识别结果何时出错。

我不认为 DHH 是个失败者。但我认为他的结论已经过时:他仍然把软件工程视为一场追求最大产出的竞赛。

作为一种协作 #

当然,协作方式要求我们改变工作流程。
我们需要训练自己足够理解机器的输出。我们需要给它足够清晰、可验证的任务,但又要有足够的意义以节省我们的时间。而且,当然,我们需要继续跑自己的困难赛道,而不是把这项运动的每一部分都委托出去。

这比选择一个二元立场更难,因为它需要实验、自律,以及对我们自身极限的精确理解。
而且,说实话,我不知道有谁是以正确的方式处理这件事的。

但工程的未来可能不属于使用 AI 最多的人,也不属于完全拒绝它的人。
相反,它可能属于那些学会如何改变这项运动的人。

来源:Hacker News · carette.xyz