ARTICLE · 1087192
AI 帮我做出来了,可我真的学会了吗?
阅读札记 / AI 与学习
之前用 AI 做网站时，我最在意的是最后的效果。
配色好不好看，页面会不会太普通，功能能不能真正用起来。生成的版本不满意，我就继续提要求，让它换风格、调整布局、增加交互。
相比研究代码，我花了更多心思去判断：这是不是我想要的网站？
看到一个想法慢慢变成可以打开、可以点击的页面，确实会有成就感。至少它不再只是脑子里的念头，而是有了具体的样子。
这些尝试当然有意义。只是最近读到一篇关于 AI 与编程学习的研究，我开始觉得，自己还应该多问一个问题：
网站越来越像样了，那我自己呢？
Anthropic 的这项研究纳入了 52 名有 Python 使用经验的开发者，让他们学习一个不熟悉的编程工具。一组可以借助 AI，另一组不能。任务结束后，两组都需要在不使用 AI 的情况下完成理解测试。[2]
任务后的理解测试 · 平均得分[1]
可使用 AI 组 50% | 不使用 AI 组 67% |
相差 17 个百分点。完成任务的速度，两组没有统计上的显著差异。
这项研究的样本不大，测的也是任务完成后不久的理解程度，不能据此断言“长期使用 AI 会让人变笨”，更不能把结果直接套用到所有学习场景里。[1]
不过，它提醒了我一件值得认真想想的事：
完成了一项任务，不代表这项任务涉及的知识，也自动变成了自己的。
以前，我更容易注意到屏幕上发生的变化：页面变漂亮了，功能增加了，内容丰富了。
至于自己多理解了什么，有没有比上一次更清楚问题出在哪里，反而没有那么容易看见。
成果是可以截图的，理解却不太容易展示。我可能也因此，更愿意追求前者。
· · ·
用 AI 做东西，最吸引我的地方，是它让我有机会先开始。
一个不熟悉的想法，不必等到所有准备都做好了才能尝试。我可以先把需求说出来，再根据结果继续调整。原本不知道从哪里下手的事情，终于有了一个入口。
我不想否认这种帮助，更不觉得只有完全靠自己写出来的东西，才配叫作作品。
只是，有了一个能展示的版本，和有了一个真正弄明白的作品，中间还有一段距离。
比如，我之前想在成长记录类的网站里加入照片、语音和长期保存的功能。
站在做页面的角度，我会关心上传入口放在哪里，照片怎样排列，时间线怎样呈现才更有氛围。
但站在使用者的角度，需要回答的问题就不一样了。
上传的内容到底保存在哪里？
关掉页面以后还在不在？
换一台设备能不能看到？
想删除一段回忆时，能不能真正删掉？
这些问题，没有哪一个能靠页面漂亮来回答。
如果网站上写着“长期保存”，我就应该知道这个承诺有没有实现，而不能只因为界面里出现了“保存成功”，就认为事情已经完成。
以前我给 AI 提要求时，经常强调“功能完善”“真正能用”。现在想来，这些话还可以说得更具体。
假如一张照片上传后没有显示，我可以先观察：是点击按钮没有反应，还是提示成功却看不到图片？重新打开页面以后，结果有没有变化？
我未必马上知道怎么修，但至少可以先把问题弄清楚一点。
比起一句“这个功能不行，再改改”，这样的描述更接近我真正遇到的情况，也让我有机会判断下一次修改究竟有没有用。
研究里，两组在识别和排查代码错误的题目上，成绩差距最大。[1]
读到这里，我开始在意一个以前容易忽略的标准：顺利的时候，我能把东西做出来；不顺利的时候，我能不能看出到底哪里出了问题？
如果只能不断要求 AI 重做，直到某一版看起来没问题，我对这个作品的了解，其实还很有限。
当然，这也不意味着我之前对配色、布局和交互的判断没有价值。那些同样是做网站的一部分。
只是，我想把不同的进步分开看。
审美上的变化、需求表达上的变化、对功能原理的理解，都值得积累。但我不能因为其中一项进步了，就默认其他几项也跟着学会了。
· · ·
文章中还有一个细节，让我觉得问题不必走向“用 AI”或者“不用 AI”这样的二选一。
研究者观察到，一些参与者会在得到代码后继续追问解释，或者借助 AI 讨论概念，再自己完成任务。他们的测试表现往往更好。
另一些参与者虽然也反复提问，却主要让 AI 直接修复问题。这些使用方式与成绩存在关联，但研究并没有证明其中的因果关系。[1][2]
这让我意识到，提问很多，不一定说明我思考得很多。
如果每次都只是换一种说法，让 AI 把结果调整到满意，对话可以很长，但我仍然可能没有理解中间发生了什么。
所以，以后再做网站，我想在“帮我改一下”之后，多停留一会儿。
不急着一次弄懂全部代码，可以先选一个自己关心的功能，问清楚它大致分成哪几步，输入的内容经过了什么处理，为什么最后会得到这个结果。
遇到不理解的地方，也不一定直接要完整答案。可以试着问：
先不要替我全部改好。告诉我问题可能出在哪一步，我应该怎样验证。
这不是研究给出的标准学习方法，只是我读完以后，想尝试的一种做法。
得到解释后，我还想多做一件小事：暂时关掉对话，用自己的话讲一遍。
比如，能不能说清楚点击“保存”以后发生了什么？能不能解释为什么要有这个步骤？如果少了它，可能会出现什么问题？
讲不清楚，就回去继续问。没有必要为了显得自己进步很快，把所有“好像明白了”都算作已经学会。
看懂一段解释，和能带着理解处理一个新问题，我想分别检验。
同样，我也可以试着改一个很小的地方。先猜一猜结果会怎样，再看看实际发生了什么。
如果和预想不一样，至少能知道：自己刚才的理解还不完整。
这样做，肯定没有直接让 AI 全部完成那么省事。但如果这一次的目的就是学习，多花一点时间，也不该被我简单算成效率低。
· · ·
写公众号，其实也有类似的问题。
有时候，我会觉得生成的文章“太假了”。
它未必有明显的语病，段落也很完整，开头提出问题，结尾给出感悟，看起来什么都不缺。但仔细读，又找不到我真正想说的那一点东西。
尤其是一些听起来很有道理的话。放进这篇文章可以，换一个主题，好像也一样能用。
以前，我会继续要求它“自然一点”“像学生一点”“不要那么空”。这些修改有用，但现在想想，还可以往前多走一步：
到底是表达不像我，还是这篇文章里，本来就没有多少我自己的想法？
如果我没有说清楚自己在意什么，没有提供具体经历，也没有对原文提出问题，只要求最后得到一篇“有深度的读后感”，那我其实还没完成最重要的部分。
对我来说，一篇读后感不一定非要得出多大的结论。
可以只是读到某个细节时，想起自己做网站的一次选择；也可以是发现，原来自己一直把两个不同的问题混在了一起。
甚至可以保留一点不确定。
比如读完这篇研究，我仍然觉得，不能只用能否脱离 AI 独立写代码，来评价我做网站的全部收获。判断需求、组织内容、调整体验，也是我想练习的能力。
但与此同时，我也不能拿“我负责想法就好”当作理由，完全不去了解功能有没有实现。
这两种想法可以同时存在。没有必要为了让文章的结尾更有力量，就把自己的疑问删掉。
写到这里，我更愿意给自己留一个具体的要求：
文章里引用的数据，我要知道它测的是什么；写进去的经历，要确实与自己有关；表达的判断，也要能够用自己的话解释。
如果有一句话，我只是觉得它“听起来很高级”，却说不清为什么赞同，那就先别急着留下。
比起让文字显得成熟，我更希望自己能在里面认出自己。
· · ·
当然，我也不想因此把每次使用 AI 都变成一场考试。
有时候，我只是想验证一个点子，做一个能够展示的版本；有时候，我需要整理已有的内容，没必要从头练习每一个步骤。
工具帮我省下时间，本来就是有价值的。
我更需要分清的是：这一次，我主要想完成一件事，还是想借这件事学会一些东西？
这两个目标可以同时存在，但不一定每次都要占同样的分量。
如果只是试试看一个想法能不能成立，我可以先做出来，再决定要不要继续投入。
如果它是我想长期做的东西，是准备让别人真正使用的网站，那么涉及核心体验的部分，就值得多弄懂一些。
尤其是我已经向使用者作出承诺的地方。说能保存，就要去检查保存；说可以导出，就要真的试一遍；说操作方便，也不能只凭自己的感觉下结论。
我不需要一下子成为很厉害的开发者，但可以逐渐知道，自己的作品哪些地方已经验证过，哪些地方仍然只是设想。
这样回头看一段时间的尝试时，我就不只是在数：又做了几个网站，又写了几篇文章。
我还可以问问自己：有没有把某个模糊的需求说得更清楚？有没有发现一个过去看不出来的问题？有没有弄懂一个原本只能交给 AI 处理的步骤？
这些变化没有一张新页面那么显眼，却也是我想留下来的东西。
读完这篇研究，我没有打算少用 AI，也不觉得之前那些尝试没有价值。
它让我接触了原本不熟悉的东西，而接下来，我想把这些接触变成更具体的理解。
下次打开一个做过的网站，我想先不急着换主题、加功能，而是选一个地方认真弄明白。
哪怕只是那个看起来很普通的“保存”按钮。
知道自己上传的内容去了哪里，知道出了问题该先检查什么——这一次，除了网站多一个功能，我也能多懂一点。