[讨论] AI的陷阱。认知债(Cognitive Debt)

楼主: oopFoo (3d)   2026-02-20 08:37:12
写软件的,之前有所谓的技术债(Technical Debt)。AI时代,现在又多了个认知债(Cognitive Debt)
认知债应该是去年mit的研究人员的创词
https://www.brainonllm.com/
随便一个中文摘要
https://www.managertoday.com.tw/articles/view/70533
虽然研究的课题是写作,但其实是关于思考(Thinking)
然后今年一月29日Anthropic赞助的研究。
https://www.anthropic.com/research/AI-assistance-coding-skills
https://arxiv.org/abs/2601.20245
使用ai辅助写程式的,比不用ai的人,程式码的理解能力显著下降。尤其除错能力(debugging)下降最多。
然后Margaret-Anne Storey分享她的经验
https://margaretstorey.com/blog/2026/02/09/cognitive-debt/
"Student teams were building software products over the semester, moving quickly to ship features and meet milestones. But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected.When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: no one on the team could explain why certain design decisions had been made or how different
parts of the system were supposed to work together"
是认知债不是技术债的问题,修好一个错误但会创造其他错误。整个案子就卡住了。
Simon Willison,如果他说他是ai coding的鼓吹者第二名,那没人敢说第一。也回应了
https://simonwillison.net/2026/Feb/15/cognitive-debt/
"I've experienced this myself on some of my more ambitious vibe-code-adjacent projects. I've been experimenting with prompting entire new features into existence without reviewing their implementations and, while it works surprisingly well, I've found myself getting lost in my own projects.
I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next."
早说 为什么不早说
作者: TonyQ (自立而后立人。)   2026-02-20 08:45:00
我是觉得 vibe coding 本质上是幻觉即使用 ai 写程式完全不意味着你就不需要了解它了
楼主: oopFoo (3d)   2026-02-20 09:10:00
就像读书需要练习,只是背过,但实习,你能了解多少。coding其实是一边写,一边在想也在学习。
作者: dream1124 (全新开始)   2026-02-20 09:13:00
有这种发现不令人意外啊。想想老板就知道了,自从他们不再碰程式碰系统,只负责提供目标和验收标准后,出了问题是不是急着叫你修而很难自己当黑手伸进去修?当初内部逻辑是你构建的,你完善的,你会比较有印象,有状况会比较容易分析问题。我不知道别人用法保守的考量,但我即便知道CLI突飞猛进,但暂时也只把AI当顾问之一,考虑的点就是这个。不过这是工作模式的取舍,对规模小,设计模式经常重复,风险又很低的开发工作,如果LLM已针对情境最佳化,那交给AI写也未尝不可。
作者: gtr22101361 (Kai)   2026-02-20 09:35:00
这种比较是叫AI写出能跑的后,没在管spec和review
作者: jack529 (Jack)   2026-02-20 09:37:00
就像看书一样,你不用想的想出来,只有用看的很快就忘记自己在冲三小,基本上除了coding 应该很多事都会有这问题,总结:人类快没有录用了其实单纯看spec review 也跟你自己想出来的差别很大,自己用AI开始写程式后,真的对程式码的掌控力下降很多所以天天还是会透过Leetcode来训练大脑,我觉得在这个时代反而这种锻炼变得好重要,防止脑残lol
作者: JaccWu (初心)   2026-02-20 10:15:00
大部分东西太久没碰能力多少会下降但产出增加的话 即使认知下降 市场还是会倾向如此
作者: sharek (...)   2026-02-20 10:17:00
个人是感兴趣的topics 就动手写,动手才比较容易思考各个面向,至于不感兴趣只需要交差的,AI 辅助只做review
作者: shinmori (一无所有)   2026-02-20 10:30:00
和导航一样,用久了方向感也会变弱,大脑就用进废退
作者: yamakazi (大安吴彦祖)   2026-02-20 10:44:00
绝大部分人只负责一小部分,我很少看到一个人负责几百万行代码的。一个人通常最多只负责几万到十几万行代码。当责的部分这么小用AI几乎不会有问题
作者: cuzuto   2026-02-20 10:54:00
跟我想的一样,人类的认知变得非常重要
作者: hidog (.....)   2026-02-20 11:07:00
觉得正常,我长时间没写C++后也会退化
作者: yamakazi (大安吴彦祖)   2026-02-20 11:12:00
第二个她说她没有review,会lost掉也很正常,像我每行ai写的代码都有review,掌握度就比较高只审核不用亲手写,同时可以保有速度和掌握度,而且量变终究会产生质变,以前手刻时代一年一万行,平均每天就手刻三十行。AI时代我一个月大概三五万行,一天看代码就要一千行,完全可以抵掉没手写那三十行的熟悉度其实SOC或是5G也是,像手机芯片越做越大,spec越来越厚,已经很难有人说他可以掌握全局了然后这牵涉到思考的本质,Llm底层是条件机率,也就是在有前文的状况下,找出下一个最大机率单词。也就是靠机率统计而已。这在原本专家的眼中跟人类的思考认知天差地别。但没想到这样的llm 居然可以拿到奥林匹亚数学金牌。那有没有一种可能人类的思考本质上也是一种条件机率,你看得越多你就会的越多,而不用再靠“思考”以前手刻时代所谓的想架构,其实也就是看看有什么设计模式好用,有哪个新语法比较高效,本质上还是试错复制贴上Try and error,copy and paste有牵涉到什么思考吗?我觉得没有。然后所谓的手刻维持手感也只是某种机械化重复动作,就像羽球选手打球的那种肌肉记忆而已第二个大神说不review ai code可行了,但代价就是你掌握度降低。
作者: lturtsamuel (港都都教授)   2026-02-20 11:57:00
好奇问一下 什么公司会让单一个工程师一个月产生五万行代码?是真的有这么高的需求?公司放心让一个产品改变得这么快 而且都在单一个人手中?
作者: yamakazi (大安吴彦祖)   2026-02-20 12:09:00
全新实验性的repo,要来取代某个订阅软件的也不是只有我会啦,我们整组人都会,不是只有我单一一个人其实你去看一亩三分地,M7印度人每次都用AI一次推几千行上去,其他同事都在抱怨审核不完https://i.imgur.com/XRgA7aw.jpeg人家M7印度人都一次推个千行PR的大部分人工作的scope就几万行了不起吧,几万行你光用看的都没办法建立掌握度(更何况还有debug mode),那应该不是AI用太多的问题IDE跳转,debug mode,请AI看完写md档,这三个用下去几十万行的掌握度应该轻轻松松
作者: lturtsamuel (港都都教授)   2026-02-20 12:44:00
几万行当然是看得懂 几万行而且每个月动辄改变五万行我就不觉得我能掌握了而且是精读的扣几万行 出问题会找我的扣可能有就三十万 都嘛是大概知道一些在干嘛你也不可能说 呼叫你的人 跟你呼叫的人 一窍不通 跟上下游一起debug的时候不想知道都会知道
作者: yamakazi (大安吴彦祖)   2026-02-20 12:55:00
没关系,不是每个人用AI都会每个月五万行,我只讲我的例子,你也可以每个月写少一点而且只是初期才五万行这么多,后来就没那么多了,都修修改改一些而已
作者: lturtsamuel (港都都教授)   2026-02-20 12:58:00
没别的意思 我就是想知道程式码变动如此剧烈你要怎么掌握他 是不是有什么厉害秘诀 如果秘诀是放弃掌握那我可能就学不来这套ㄛ 那就合理了不过这样比不太公平吧 你每天30行的状况肯定不是这个崭新专案 一定也是修修改改的阶段 你现在修修改改的话ai有显著加速吗?
作者: hidog (.....)   2026-02-20 13:09:00
没发现没人想理某y吗
作者: yamakazi (大安吴彦祖)   2026-02-20 13:11:00
修修改改超快的啊,给他一句话就能改好的事不快吗?甚至修bug 也超快,以前还要除错模式慢慢step in,现在他直接看一看跑个一两次就找到bug,最多再一次log重编重跑。不过我觉得ai强不见得你觉得ai强,毕竟我也不知道你怎么用AI,有兴趣找我以前推文,我就不再赘述再一次加log拿个最简单的例子,用python parsing log档后画出特定资料字段XY散布图,现在交代一句话一分钟就做完了
作者: lturtsamuel (港都都教授)   2026-02-20 13:21:00
我的经验是 如果追到最后发现是某个 底层函式被呼叫太多次而慢,叫他帮弄个快取,他可以分析完直接改扣就很快,但如果只是跟他说 这个操作很慢 他自己分析不太出来 给他权限跑程式也没办法我记得给他看 callgrind 输出他可以抓出几个问题点,但没办法很精确,他也没办法帮我教客户怎么在那个环境跑callgrind而这些做不到的事完全是瓶颈 比写那个快取层久多了而且也无趣多了 我宁愿自己去写那个快取层让ai处理其他事
作者: yamakazi (大安吴彦祖)   2026-02-20 13:37:00
追到底层件事,以前手刻时代我都是用gdb ,AI时代的话他不喜欢用gdb喜欢加log看log,所以我是叫他把整条路径列出来,log全部加上去重编重跑后看log,毕竟文字处理是他的强项Log时间和函数全部打出来,谁最慢一目了然,以前手刻时代加log比较粗活现在加log就几秒钟的事,瓶颈都是在重编重跑,看log他很快比人类快多了
作者: neo5277 (I am an agent of chaos)   2026-02-20 14:21:00
其实一并要求产出注解跟文件就好了...
作者: CoNsTaR ((const *))   2026-02-20 15:15:00
因为 AI 思考的本质是 attention,不是机率有 attention 就可以思考是因为逻辑一定有头有尾,你可以把整条龙每一步之间的所有关系存进 attention,用到机率的地方只有没逻辑的机率事件
作者: yamakazi (大安吴彦祖)   2026-02-20 15:24:00
确实 attention is all you need
作者: bensome0624 (B)   2026-02-20 15:53:00
所以资深工程师用会得心应手,菜鸟工程师掌握度不高还是容易踩雷,而且认知也越来越难进步
作者: viper9709 (阿达)   2026-02-20 16:08:00
推老板的比喻赞的+1
作者: VScode (VSisBestIDEinTheWorld)   2026-02-20 16:18:00
用进废退囉 有地方退步肯定有地方变强俗话说换个位子换个脑袋 你现在叫比尔盖兹写组语他也写不出来
作者: attacksoil (击壤)   2026-02-20 21:21:00
除非ai真的到自己能维护系统 那工程师还是得看code
作者: s78513221 (TERIS)   2026-02-20 21:53:00
啊资深工程师也是菜鸟熬出来的
作者: neo5277 (I am an agent of chaos)   2026-02-20 23:29:00
其实现在ai是可以自己debug啦从issue开单开始
作者: nashyuuki (葛屁老师的藏镜人)   2026-02-21 10:28:00
认知债发生在使用者本身对程式码的熟悉程度。AI产出的程式码,不懂的部分一定要搞懂。我很常叫AI重构,把程式修改成易于阅读和维护。AI写的程式码要花很多时间去看,但是品质更好。AI反而让我进步很快,也学习到更多东西。
作者: strlen (strlen)   2026-02-21 11:03:00
你会去看机器码吗?人们不再自己检查机器码 是认知退化吗其实我觉得 真的不用再担心程式码了以现在发展的方向 软件发展完全无人化 是不可能改变的那些什么技术债 陈年老bug 再越来越强大 越来越高的算力面
作者: Suleika (Suleika)   2026-02-21 11:05:00
确实是大问题,其实很多人ai焦虑完全没必要,在被大环境洗掉前还有一波擦屁股的工作潮颗颗
作者: strlen (strlen)   2026-02-21 11:05:00
前 一点也不重要 系统雷很多?架构老旧改不动?agent开下去直接帮你重写一款codex和opus都有极速版 一个叫spark一个是六倍价格换2.5x速度https://www.youtube.com/shorts/3rQhMs7QBaghttps://youtu.be/3Y3VkvP5_kQ?si=pwCrFu_wXJd8898u&t=206过阵子 现在agent的能力再搭配以上那样的速度你觉得这产业未来会怎样?你还在那边东抠西抠程式码?人家遇到bug直接暴力破解直接重写一套都比你在那边尻bug快认知喔 建议把技术性的认知 通通改成需求性的认知未来技术早就不是重点了 工程师通通都得转职成PM
作者: hidog (.....)   2026-02-21 12:01:00
还是要看领域吧,每个领域状况本来就不太一样-.-
作者: yamakazi (大安吴彦祖)   2026-02-21 12:08:00
基本上目前是这些领域不适用https://i.imgur.com/EEfwEfu.jpeg
作者: hidog (.....)   2026-02-21 12:24:00
不只那些领域-.-
作者: Murasaki0110 (麦当劳欢乐送)   2026-02-21 12:30:00
你理解组语?一样意思
作者: lturtsamuel (港都都教授)   2026-02-21 15:46:00
遇到bug就重写怎么保证不会有新bug?这是什么天才思维你windows或是chrome有bug也要重写吗
作者: strlen (strlen)   2026-02-21 15:59:00
因为重写成本远低于你在那边改A坏B 未来绝对是这样我话就放这边 就跟一年前一样 或三年前一样 会不会验证我们就等时间来解答?
作者: Brioni   2026-02-21 17:32:00
不要搞到飞机掉下来还没人知道为什么就好
作者: strlen (strlen)   2026-02-21 17:40:00
这一百多年来飞机时不时掉下来 这个不是AI的锅
作者: lturtsamuel (港都都教授)   2026-02-21 17:49:00
修改会改a坏b,重写就不会,好喔
作者: WTS2accuracy (宝钟海贼団の一味)   2026-02-21 18:09:00
就一群菜鸡在幻想 系统重写有这么简单哪来屎山代码现在写扣早丢给AI了 你手上的专案全用AI重写了吗?
作者: strlen (strlen)   2026-02-21 18:19:00
重写再坏 就再重写 写到过为止 重写一百次 都比你找bug快这就是最终解法另外楼上 这一个月还真的就重写了三个八年以上的老专案就当我在幻想吧 一年后我们再回来看这篇
作者: yamakazi (大安吴彦祖)   2026-02-21 18:53:00
飞机掉下来还真的不是AI的锅,Netflix有纪录片飞机掉下来最大宗是飞行员人为疏失。再来是波音管理层疏失,最后是飞行程式外包印度仔的疏失
作者: Brioni   2026-02-21 19:42:00
至少知道是谁的锅
作者: yamakazi (大安吴彦祖)   2026-02-21 22:02:00
两次马航就不知道谁的锅啊,只能猜一个是飞弹一个是自杀
作者: viper9709 (阿达)   2026-02-21 23:39:00
有bug就重写会不会太猛...
作者: Romulus (Säubern Mode)   2026-02-22 00:04:00
我觉得这是使用工具错误造成的 所以有办法预防至于程式码掌控能力 我的论点是就和现在写高阶的一般不在乎最终执行的组语一样只是单纯高阶语言也变成更上一层的组语而已
作者: strlen (strlen)   2026-02-22 00:11:00
奇怪 大家都是工程师 为什么scaling的方式这么多人不懂?AI的问题 根本已经不在正确性了 现在只要有更多的算力 原则上什么毁天灭地的东西它都能搞出来 搞一次有bug 就再搞
作者: Romulus (Säubern Mode)   2026-02-22 00:12:00
蛤 因为发现重写的扣有问题的时候可能是在prod然后公司准备赔一千万了
作者: strlen (strlen)   2026-02-22 00:12:00
第二次 出一百个bug我就搞一百次 去看看spark那个速度 五秒写一个贪食蛇耶
作者: Romulus (Säubern Mode)   2026-02-22 00:13:00
有bug就重写大前提是可以承受prod bug再修 或是有超级完整的测试
作者: strlen (strlen)   2026-02-22 00:13:00
你还是看不懂我想表达的喔?有bug是测试期发现的 马上发现 马上修 马上更新迭代
作者: Romulus (Säubern Mode)   2026-02-22 00:14:00
而需要重写的专案99.87%都没有足够完整的测试 AI也写不出来
作者: strlen (strlen)   2026-02-22 00:14:00
在你人为都还没发现bug的状况下 AI早就已经发现然后修掉了
作者: Romulus (Säubern Mode)   2026-02-22 00:15:00
那除非你是2080来的
作者: strlen (strlen)   2026-02-22 00:16:00
作者: Romulus (Säubern Mode)   2026-02-22 00:16:00
现在说AI补测试可以比小修现有code安全那就没人会信的
作者: Romulus (Säubern Mode)   2026-02-22 00:17:00
资安漏洞修补和这个话题有个屌关系
作者: strlen (strlen)   2026-02-22 00:17:00
现在包括Linus uncle bob一票大神通通都在用agent
作者: strlen (strlen)   2026-02-22 00:18:00
AI企业他们最终的目标 就是将所有产品串起来 全自动化
作者: Romulus (Säubern Mode)   2026-02-22 00:19:00
喔我也可以推文留在这里 10年后全世界银行医院etc.超过87%还是不会为了修bug把旧专案直接重写
作者: strlen (strlen)   2026-02-22 00:25:00
很好 让时间证明一切 等著瞧
作者: WTS2accuracy (宝钟海贼団の一味)   2026-02-22 01:01:00
不用跟他吵啦 讲出什么言论的就是什么水准XD我第一份也是管这种可有可无 出事没啥差的专案这种妳让AI随便爆改确实没差 因为 nobody cares
作者: Obama19 (^_^)   2026-02-22 01:13:00
叫ai修就好了 修不好 大不了换一间公司

Links booklink

Contact Us: admin [ a t ] ucptt.com