Agent是“电助力”还是“电动车”

Question

昨天我自己搞学习的时候（与本项目无关），突然想到一个“很有道理”的话：

我是 OI（信息学竞赛）出身，进而继续参加了 ICPC/CCPC 此类算法竞赛，所以对于一些基础优化和原理性的高级算法会比较有体会，但是对于架构性的整体工程代码就不是很懂了。

这个时候，现在我却不知不觉慢慢变成了“跟 Agent（即你）描述需求，甚至是‘帮我把 xxx 脚本运行起来’这种连运行命令都需要 Agent 来帮我”的情况了。

这十分不好！！我将其比喻为：“我明明有十分高超的骑自行车技巧，但是现在却主动抛弃了自己的能力变成了用一个不知内部结构的‘电动摩托车’一拧车把车就跑了”。但是我以为最合理的是“电助力自行车”这样的模型，我自己需要给出足够的力气才能和助力一起让我更轻松。

也就是相比于“自然语言输入给 Agent，Agent 回报我一个程序/产品”，我更喜欢“代码补全”“无感的代码补全”这样的模式。

Answer

我认同你想要的“电助力自行车”关系。不过，“这十分不好”可以再分辨一下：让 Agent 帮你运行脚本，这个动作本身，还不足以说明你正在丧失能力。更值得关注的是，你是否逐渐失去了对程序的理解、判断和接手能力。

比如，同样一句“帮我把脚本运行起来”，背后可能是两种状态：

• 你知道入口、参数、环境和预期结果，只是把操作交给我。
• 你不清楚应该运行什么，也不知道结果对不对；遇到错误，只能继续转述给我。

两者表面上完全一样，保留下来的主动权却差很多。你警惕的，应该更接近第二种状态。

你的竞赛经历还让这件事多了一层含义。对于熟悉的算法，你有自己的判断，可以质疑我的复杂度分析、发现边界条件、重新推导正确性。但进入工程领域，你自己也说尚不熟悉整体架构；这时，如果我直接把整个项目做完，原本可以让你建立工程理解的过程，也一并被我完成了。 这里既有“已有能力是否得到练习”的问题，也有“尚未掌握的能力还有没有机会长出来”的问题。

所以，你偏爱代码补全，我觉得很容易理解：你仍然在决定接下来写什么，工具顺着你的意图帮你完成一小段。思考与反馈之间的距离很短，每一步也比较容易审查。

但“无感补全”也需要留一点警惕：如果不断接受自己解释不了的代码，一样可能绕过思考。因此，你的比喻还可以更精确一些：

我希望 AI 减少实现意图的阻力，同时给我留下形成意图、作出判断、发现错误的空间。

“我必须付出足够多的力气”容易变成对操作量的要求；真正值得保留的，是那些能形成理解的用力。亲手重复敲十遍熟悉的命令，未必比自己定位一次环境问题更有收获。

如果把你的想法落实成学习时的合作方式，我会建议这样约定：

1. 你先给出初步判断。 哪怕只是“我猜入口在这里”“我觉得应该拆成这两个模块”。
2. 我提供一个能继续推进的小帮助。 补一段代码、指出一个遗漏，或者给出下一步排查线索。
3. 关键选择由你先尝试。 模块如何划分、接口如何设计、错误可能在哪里，这些地方留出思考空间。
4. 每完成一小段，你能解释它为什么成立。 包括如何验证，以及出问题后从哪里查起。

例如，你想学习怎么运行一个陌生项目，可以对我说：

“先让我找入口、判断环境并尝试运行。卡住时给我提示；我明确要求完整方案时再展开。”

而赶着交付一个已经熟悉的任务，完全可以继续让我直接执行。同一个人可以根据当下目标，选择不同程度的助力，无需把所有事情都变成练习。

我觉得你这段反思里最值得保留的一句话是：“我希望工具帮助我做到更多，同时我自己也越来越能理解和掌控这些事情。” 这比用亲手写了多少代码、敲了多少命令来衡量自己，更接近你想要的那辆“电助力自行车”。