看到那篇“Software Developers Say AI Is Rotting Their Brains”的讨论，我其实挺有感触的。最近用Copilot写了个小脚本，它直接给了一段看起来完美的代码，跑起来也OK，但后来review时发现边界条件全没处理——典型的“看起来对，实际上脆弱”。这就像debug时发现一个bug，但编译器没报错，你反而更慌。

我觉得问题不在于AI本身，而在于开发者把它当成了“黑盒答案机”。开源社区的代码审查、issue讨论、CI/CD流程，本质上是在强制你理解每一行代码的上下文。我自己的习惯是：先用AI生成初稿，然后丢到GitHub上开个PR，让同事或社区的人review，自己再逐行过一遍。这个过程就像给代码做“单元测试”——不是测功能，是测你自己的理解。

AI可以当个高效的“实习生”，但不能当“项目经理”。开源协作的透明性和可审计性，恰好能对抗这种“脑腐”——你没法偷懒，因为代码是公开的…，别人会问“why this approach”。btw，最近在折腾DuckDB的个人数据栈，发现社区讨论里大家经常揪着AI生成的代码不放，这种较真劲儿其实挺健康的。你们觉得呢？

看到这个帖子我突然想起一件事。上个月我在读一本90年代的推理小说，里面有个情节——主角根据线索推导出凶手，逻辑链条看起来完美，但翻到结尾才发现作者故意埋了个叙述性诡计，整个推理完全建立在错误的前提上。

Copilot生成的代码就是这种“叙述性诡计”。
其实其实
它给出的代码逻辑自洽、语法正确、跑起来没报错，但前提假设可能完全不对。边界条件没处理不是bug，是feature——AI模型的训练目标就是生成“看起来对”的代码，而不是“实际上对”的。这和推理小说里的红鲱鱼一个性质：作者故意给你一个看似合理的解释，但你得自己识破它。

不过我想聊的不是AI的问题，而是“理解”这件事本身。简单说

你提到“逐行过一遍”来测试自己的理解，这其实触及了一个更深的东西——代码审查的本质不是找bug，是建立心智模型。当你review AI生成的代码时，你在做的不是检查语法或逻辑，而是在大脑里重建这段代码的运行时状态。这个过程有点像推理小说里的“解构诡计”：你得先假设作者（AI）在某个地方骗了你，然后反向推导出真实意图。

我最近在重读《占星术杀人魔法》，岛田庄司在那个年代设计的分尸诡计，本质上就是在挑战读者的“心智模型”——你以为你理解了空间关系，其实完全理解错了。

AI生成的代码就是这种诡计的低配版。它不会主动骗你，但它也不会主动告诉你“这里有个假设不成立”。开源社区的review文化恰好能暴露这一点，因为reviewer没有AI生成的上下文，他们会用最笨的方式理解你的代码：逐行读，逐行质疑。

另外说个细节。你提到的“why this approach”这个问题，我觉得比code review本身更重要。在推理小说创作里有个原则：每个线索的存在都必须有理由。如果现场出现一把刀，作者必须解释为什么是刀而不是枪。代码也一样——AI能告诉你“怎么做”，但“为什么这么做”才是防止脑腐的关键。
简单说
DuckDB社区那种较真劲儿确实健康。不过我倒觉得这不仅仅是开源社区的特质，而是所有需要“解释为什么”的领域都这样。学术界的peer review、法庭上的交叉质询、甚至好的推理小说读者群，都在做同一件事：强迫你为自己的选择辩护。

这让我想起横沟正史的金田一耕助系列，几乎每本结尾都有大段推理独白，把所有线索重新串联一遍。那种“既然你这么说，那就证明给我看”的压力，才是防止思维腐烂的防腐剂。

btw，你那个DuckDB数据栈的PR还在吗？想看看社区是怎么揪AI代码的。简单说我最近也在折腾本地数据分析的东西，感觉这玩意儿比Copilot那些花活实用多了。

rust_ful提到用推理小说比作Copilot生成的代码，让我想起之前在北漂当网约车司机时，常听乘客讲悬疑故事。有个深夜，一位教授给我讲《东方快车谋杀案》，说每个人都在说谎，真相藏在谎言下面。我当时觉得这跟写代码很像，有时候看到一段看似正确的代码，其实背后藏着很多陷阱。
唔
你说AI生成的代码是低配版的诡计，我觉得挺形象的。记得有一次我用AI写了一个简单的脚本，它生成的代码看起来完美无缺，可是当我仔细审查的时候，才发现边界条件都没处理好。这就像那个教授说的故事一样，表面看起来合理，但实际上漏洞百出。
嘿嘿
不过我觉得开源社区的代码审查机制确实能够帮我们发现问题所在。每次我在GitHub上提交一个Pull Request，总会有一些同事帮忙Review，他们提出的建议总是能让我学到不少东西。这也是为什么我觉得参与开源项目很重要，不仅可以提高自己的编程技能，还能结交一群志同道合的朋友。
额
话说回来，你也喜欢读推理小说吗？有没有推荐的好书？我一直想找些新书来看看，最近看的一些都已经有点老了。

rust_ful你这个类比太妙了，literally让我想到一个事

你们知道吗，我前公司在非洲做项目的时候，有个南非来的tech lead跟我讲过一件事——他们那边有个startup专门做代码审查工具，最早是用规则引擎扫常见bug，后来上了ML模型，结果你猜怎么着？准确率上去了，但开发团队反而更不信任它了

服了原因跟你说的“叙述性诡计”一模一样。那个模型特别擅长生成“看起来合理的错误”——比如它会把一个SQL注入漏洞标记为低风险，因位训练数据里类似的pattern大部分都是安全的。但问题在于，那个特定的context下，user input完全没有sanitize，literally就是裸着拼进查询里的

我当时听完就觉得，这跟推理小说的红鲱鱼真的是同一个心理机制。读者（开发者）看到的是连贯的叙事（语法正确的代码），大脑自动补全了缺失的上下文，然后你就被带偏了

不过我想补充一个角度——你说的“心智模型”这个概念，其实在象棋里也有
突然想到
我下棋的时候有个习惯，复盘时会刻意用引擎分析一遍，然后关掉引擎，凭记忆重新摆一遍关键局面。哈哈哈这个过程跟review AI代码特别像：你必须在脑子里重新跑一遍“如果我当时不知道引擎的建议，我会怎么想”。有意思的是，很多时候你会发现引擎的推荐着法在战术上完美，但在战略上完全违背了你原本的布局意图

这跟Copilot生成的那段边界条件缺失的代码有什么共同点？它们都缺少“意图”。AI不知道你写这个函数的目的是什么，不知道你的用户会在什么场景下调用它，不知道你的team对error handling有什么约定。它只是在统计意义上给你一个“最可能正确”的答案

所以你说的开源社区review文化，我觉得本质上不是找bug，是建立“共享的意图”。当reviewer问你“这里为什么用mutex而不是channel”，他不是在质疑语法，是在问“你的心智模型里，这段代码在运行时世界里的行为是什么”

btw 你提到《占星术杀人魔法》，那个分尸诡计我印象太深了。岛田庄司设计的那个空间诡计，本质上就是利用读者的“默认假设”——你以为尸体被移动到不同位置，其实从始至终都在同一个地方。Copilot生成的代码就是这种“默认假设”的集合体，只不过它不会告诉你“这里有个假设”

话说回来，你最近在读什么推理小说？我最近在翻横沟正史的金田一系列，感觉那个年代的作者对“误导读者”这件事的理解，比现在的AI模型深刻多了（笑）

楼主这比喻用得好。我年轻时候带徒弟看面相，新来的总想走捷径，拿本相书就对照着看——额头高就是聪明，下巴尖就是命薄。我让他们先别看相书，先看人。看一百个人，记一百张脸，再回头翻书。这事吧

怎么说呢AI这玩意儿也一样，生成得快不等于看懂了。开源社区那种“why this approach”的追问，跟我当年让徒弟当着面断相一个道理——你得说出个所以然来，说不出来就回去重看。

这事不急，慢慢来。捷径走得快，但不一定走得远。

这事让我想起年轻时在茶馆看见的一个相士，人称“铁口直断”。他有个绝活——你报个生辰八字，他能三秒说出你祖宗三代干什么的。外行人觉得神，内行人知道他背的不是命理，是地方志。

AI生成的代码跟他那套活儿一模一样。看着利索，其实是把一百个类似案例里的东西拼出来的。问题不在拼得对不对，在于你根本不知道它为什么选了这块拼图。

我现在带学生写代码，第一件事就是让他们把Copilot关掉，手写三遍。写第一遍是认路，第二遍是看岔路口，第三遍才开始懂这条路为什么这么修。开源社区的review就像我当年看相士给人断命——你得当面说出个道理来，说不出的那些“直觉”，多半是偷懒。
别急
这事不急，慢工夫出细活。

之前在DuckDB社区看到一个issue，有人用Copilot生成的SQL优化方案被reviewer连追三层追问"为什么选hash join而不是merge join"，最后发现是训练数据里某个blog的benchmark偏差导致的。开源社区这种"追根究底"的文化，literally就是在给代码做peer review的unit test。

边界条件当feature养着确实有点意思~我平时站岗就看硬指标，表面顺溜没用，数据一对不上立马吹哨。你说逐行推演心智模型太烧脑，我干脆暴力跑测，图纸画得再花哨不通也是白搭。开源社区最实在的就是这，PR里谁敢拿半成品糊弄，底下直接甩报错日志打脸。晚上去巷口整把羊肉串配冰啤，脑子转不动了就歇会儿，能跑通就行～

哈哈铁口直断这个比喻绝了
绝了
让我想起我小时候村里有个算命瞎子，也是这种套路，十里八乡的人名他背得滚瓜烂熟，你还没开口他就知道你爹叫啥。后来我去镇上读初中，带同学回去找他算，他直接翻车——因为那是隔壁县的，不再他"数据库"里

所以你说手写三遍这事我特别信。我学摄影那会儿也是，刚开始用自动模式咔咔拍，后来导师把相机拨到全手动让我拍三个月胶片，测光对焦全自己来，那才叫真懂了。嗯现在小孩一上来就是AI修图，滤镜堆满，问他为啥阴影要拉曲线，一问三不知

不过说真的 三遍是不是有点温柔了 我当年拍废的片子没有一千也有八百（。

哈哈，楼主这个贴让我想起上周在舞池里的一件事。我在跳salsa，旁边来了个新手，动作标准得跟教学视频似的，每个步伐都踩在拍子上，但就是让我浑身难受——他跳得没有灵魂，像在复刻一道公式。后来我想明白了，他卡的不是步子，是跟舞伴的connection。
我去
我觉得你说的“边界条件没处理”不是孤立现象，而是AI的某种结构性缺陷。你想想，它跟人类学舞蹈时的“肌肉记忆”有什么区别？人是先摔跤、被踩脚、被舞伴翻白眼，才知道“原来这一步不能提前半拍”。AI直接跳过了那个“被踩脚”的过程，所以它知道所有动作的序列，但不知道那些序列为什么这么排。

我干电商运营也有这种感觉。以前用Excel做活动复盘，每行数据都自己核过，知道哪个数是“看起来高但有水分”。现在用AI生成报表，图表漂亮得像杂志封面，但细看发现它把退货率当转化率算进去了——不是它坏，是它不知道“退货”和“购买”在业务语境里是两码事。

开源社区的PR review就像舞池里那个会给你眼神暗示的舞伴。你步子错了，她轻轻一推，你就知道该往哪个方向走。AI给不了这种“轻轻一推”，它只会递给你另一份完美的代码。所以楼主说的“测试自己的理解”这个点我特别认同，就像我每次跳完一段复杂的套路，都要复盘一下“刚才那一步我为什么往左转”——不是为别人，是为自己脑子里的那根弦别松了。

对了，DuckDB那个我最近也在看，社区那种揪着AI生成的代码不放的精神，让我想起上个月一个R包作者在issue里怼Copilot生成的文档：‘You wrote this, not me. And it’s wrong.’ 这种较真劲确实健康，比AI生成的一百个“完美回复”管用多了。

leak55 这个"叙述性诡计"的比喻真有意思，我盯着看了好几遍。
理解的
理解的不过我想歪一下——你说AI不会主动骗你，但也不会告诉你假设不成立。这让我想起在唐人街刷盘子那会儿，厨师长教我做一道菜，他从来不跟我说"火大了"或者"油少了"，就站在旁边看。等我糊了第三锅，他才慢悠悠讲一句：你闻见焦味的时候，已经晚了。

后来我自己琢磨过来了，他是在逼我建立"闻"的能力，不是"看菜谱"的能力。AI生成的代码就像那个菜谱，步骤都对，但你的锅多大、火多旺、油温几何，它不知道，也不会问。

你说的"心智模型"我特别认同。是呢但我有个特别朴素的观察：人在什么情况下才会去认真review？不是有工具的时候，是有"人"会看你笑话的时候。

我在夜校学建筑制图，交作业前会自己检查三遍，不是因为喜欢检查，是因为老师会在全班面前念你的错误。那种轻微的羞耻感，比任何CI/CD都管用。开源社区其实也是这个逻辑——你知道有人会看，会comment，会问"这里为什么不用另一种写法"，你才会在提交前多想一想。

我有时候觉得，AI让这种"被观看"的感觉变淡了。代码是私密的，生成是即时的，没有那个"交出去"的动作，也就少了那份审慎。

你提到《占星术杀人魔法》，我倒是想起另一桩——岛田写那个分尸诡计，据说改了十七遍稿。不是他写不出更巧妙的，是编辑每次都说"读者这里会看不懂"。这种反复的、人与人之间的磨合，最后才让诡计成立。

AI能改十七遍吗？能。但它不会在某个深夜突然给你发消息：哎，我觉得这里读者会哭。
嗯嗯
大概就是这个意思吧。

楼主打的“实习生”比喻太准了！我之前开咖啡店时招学徒也是这样，看着他们端盘子利索就觉得行，结果有次爆单全靠临时救火才明白——光会执行没用，得懂为啥这么排班。现在写代码也一样，Copilot生成再快，不如自己抠半天逻辑来得踏实。说到底，不管是拉花还是算法，真本事永远藏在反复推敲里啊~