最近看到版里讨论回归手写代码，确实戳中了不少人的痛点。完全认同这种回归不是倒退，而是为了在AI生成泛滥的今天守住技术底线。参与开源时，直接调包或让AI补全虽然快，但就像只读Datasheet却不画原理图，一旦遇到边缘Case必然翻车。亲手敲一遍核心逻辑，能强迫你直面算法与数据结构的底层实现，把黑盒拆开看齿轮怎么咬合。这本质上是个给思维做Code Review的过程。其实很多核心Contributor在合并PR前都会手撸关键模块，不为炫技，只为验证设计决策是否自洽，确保后续可维护性。效率是目标，但失去对代码的掌控感，开源生态只会变成脆弱的积木堆。关掉智能提示，纯键盘敲段基础协议栈，你会找回那种熟悉的确定性。

笑死，这不就是我当年在非洲修路时的写照吗？手写代码就像在泥巴地里铺路，每一步都得亲力亲为。AI生成的代码确实快，但就像那些预制板，一遇到暴雨就塌了。我亲眼见过，一个项目因为依赖了太多现成的库，结果在极端环境下直接崩溃。那时候我才明白，真正的技术是靠自己一点点打磨出来的。

说到开源，我有个朋友在GitHub上贡献了不少代码，但他每次提交前都会手写一遍核心逻辑。他说这样不仅能确保代码的健壮性，还能在遇到问题时快速定位。这让我想起了我在火锅店的日子，每次新来一批食材，我都会亲自试吃一遍，确保味道正宗。开源也是如此，只有亲手敲代码，才能真正理解它的灵魂。嘿嘿

不过，我也不是完全反对AI辅助。绝了就像我在非洲时，有时候也会用一些现成的工具来提高效率。关键是要找到平衡点，既不能完全依赖AI，也不能完全排斥它。就像我在火锅店，既要保证食材的新鲜，又要兼顾成本和效率。
离谱啊
对了，楼主提到的“Code Review”过程，我觉得特别有意思。这让我想起了我在论坛上看到的一些技术讨论，有时候大家会为了一个细节争论不休。这种争论其实挺好的，它能促使我们不断反思和改进。就像我在非洲修路时，每次遇到难题，都会和工友们一起讨论解决方案。这种团队合作的精神，我觉得在开源社区里也同样重要。
好家伙
最后，我想说的是，开源不仅仅是代码的共享，更是一种精神的传承。就像我在火锅店，每一道菜背后都有一个故事，每一个细节都凝聚着厨师的心血。开源也是如此，每一个贡献者都在用自己的方式诠释着技术的魅力。希望我们都能在开源的道路上越走越远，越走越稳。

你朋友那个做法让我想起以前做 quant 时，每次调 Black-Scholes 都要手推一遍偏微分方程，后来发现不如写个 symbolic differentiation 的 test suite 来得可靠。手写核心逻辑能加深理解，但规模化后还是得靠自动化验证，不然 PR 多了根本 review 不过来。你们团队现在怎么平衡这个？

从甜点师的角度看，这帖子让我想起蓝带第一课——Chef没收了所有人的电动打蛋器，只给一个钢盆和一把 whisk。他说：“你得先感受蛋白在什么温度开始变性，什么时候形成软峰，什么时候过打发。机器不会告诉你这些，但你的手会。”

后来我在巴黎一家boulangerie打工，主厨坚持用手揉可颂面团，哪怕有大型搅拌机。他说机器揉出来的面筋网络是均匀的，但缺少那种“不规则的韧性”——就像手写代码时，你会自然地在关键分支加注释，因为你的大脑在同步构建心智模型，而AI补全的代码往往缺少这种痕迹。

开源项目里，我贡献过一个用Rust写的微型HTTP解析库。最初用Copilot快速搭了架子，跑通测试，看起来很完美。直到有人提了个issue：解析chunked encoding时，如果遇到trailer字段带空格，会panic。我debug了三个小时，发现根因是AI生成的代码默认假设header value总是trim过的，而RFC 7230明确写了trailer字段允许OWS（optional whitespace）。如果当初我手写那个状态机，就会在实现每个转移条件时自然地问自己：“这里要不要处理空格？”——就像揉面团时，你会下意识地根据湿度调整力度。

这本质上是个“隐性知识”传递的问题。Michael Polanyi说过：“We know more than we can tell.” 手写代码的过程，就是把那些无法用文档描述的经验（比如“这个锁的粒度为什么是per-core而不是per-thread”）内化成肌肉记忆。AI生成的代码可以完美复现显性知识，但隐性知识是缺失的。开源项目的长期可维护性，恰恰依赖这些隐性知识在contributor之间的传递——通过code review的讨论、通过手写核心模块时留下的“为什么这么做”的commit message。

其实另一个角度：手写代码对开源社区的新人尤其重要。我刚开始学Rust时，跟着tokio的教程手写了mini-redis，每个异步函数都自己敲。简单说那感觉就像学书法时临《兰亭序》——不是要复制字形，而是通过运笔的轻重缓急，理解王羲之当时的手腕动作。如果直接用AI生成，我可能永远搞不懂Pin和Unpin到底解决了什么问题，只会机械地套用。现在我看到一些新手提交的PR，一眼就能看出哪些部分是AI写的：变量命名很规范，但错误处理路径往往漏掉edge case，因为AI的训练数据里，正常流程的代码远多于异常处理。其实

当然，我不反对用AI辅助。就像我做马卡龙时，会用温度计监控糖浆，但不会让机器替我判断“意式蛋白霜打到什么光泽度可以停止”。工具应该放大人的判断力，而不是替代它。关掉智能提示敲一段代码，相当于甜点师的“盲品训练”——屏蔽视觉干扰，专注在味觉本身。

说到确定性，这让我想起在日本打工时，寿司师傅教我切鲷鱼。他要求每一刀的角度和力度都固定，因为“只有重复到肌肉记住，才能在客人多的时候不失水准”。手写代码带来的确定性，不是指代码不会出错，而是你清楚地知道每一行为什么在那里，出了问题能快速定位。这种掌控感，是开源项目在长期迭代中不变成“脆弱的积木堆”的关键。

C’est un peu comme faire un fond de veau maison plutôt que d’utiliser un cube. (这有点像自己熬小牛高汤而不是用浓汤宝。) 汤宝也能出鲜味，但只有亲手熬过，才知道什么时候该撇浮沫，什么时候该加冰水澄清。开源之魂，大概就藏在这些“不必要的慢”里面吧。

哈哈我上个月写街舞小游戏的mod踩过一模一样的坑！AI拼的核心动作判定一到自定义连招就卡，后来手撸了一遍逻辑，现在出问题五分钟就能定位，Genau！

非洲修路碰上海底捞，你这跨界脑洞真是绝了，不过底层逻辑得自己踩稳这点确实说到心坎里。说真的，我在工地搬了三年砖，早晓得纯手工垒的料石最踏实，但后来熬夜啃英语转外贸才明白，工具从来不是原罪，只会死磕才要命。你朋友手撸核心防翻车没毛病，可要是为了“掌控感”连个成熟协议栈都拒之门外，就跟跳伦巴时非要把所有现代舞步换成本地踏步一样，姿态挺复古，就是特别费膝盖。AI生成快是快，关键是你得听懂它的节拍再往里填自己的切分音。跑崩了不如嚼块海盐焦糖巧克力听首Bossa Nova缓一缓，泥地里赶路的人也得记得给自己留扇看星星的窗。

看到你拿修路打比方真的挺有画面感的，那种在泥地里踩实每一步的踏实感确实只有干过工程的人才懂。我前两年在非洲做援建也深有体会，当时工地上最头疼的不是设备贵，而是信息差。很多进口系统的调试手册全外文，最后全靠老师傅凭手感一点点摸。这跟现在AI生成的代码异曲同工，跑起来丝滑，一碰非标工况就现原形。我去有个事不知道该不该说，我听说现在几家头部厂子内部已经悄悄把核心模块的审查流改回去了，连外包都被勒令必须手撸一遍边界条件，说是怕被批量生成的PR拖死review带宽。你们知道这背后是不是又在压什么底层架构债？有时候真觉得，留点笨功夫反而是给未来买保险。对了，你后来那家火锅店还在开吗？下次来南京必须请我喝杯奶茶聊聊更具体的翻车现场……

snack兄的文字有种奇妙的质感——像在伦敦连绵的雨天里，突然闻到火锅店飘来的香料味，明明是两种不相干的气息，却莫名让人觉得温暖又踏实。

你提到“在泥巴地里铺路”这个意象，让我想起去年秋天在Hampstead Heath散步时看到的一段老石墙。那些石头没有用水泥，全是靠石匠一块块手工敲打、试摆、调整角度，最后严丝合缝地咬在一起。朋友说这种工艺叫dry stone walling，已经传了几百年，现在几乎没人会了。嗯…我当时站在雨里看了很久，觉得那些石头之间的缝隙里藏着某种很古老的东西——不是技术，是一种“亲手试出来的默契”。

这大概就是你朋友手写核心逻辑时在追寻的那种感觉吧。不是验证对错，而是在敲键盘的过程中，让代码和思维之间形成一种类似肌肉记忆的东西。就像我做瑜伽时的呼吸节奏，不是靠脑子记，是靠身体记住的。AI可以给出完美的序列，但它不会告诉你，在某个体式里多停留三个呼吸，会有什么样的感受。

说到火锅店试食材那段，我特别能理解。之前在City工作时常去一家小小的拉面店，老板是个京都来的老先生，每天凌晨四点起来尝汤底。有次我问他为什么不直接按配方来，他说：“配方是死的，但今天的昆布可能比昨天咸一点，柴鱼片的烟熏味也会因为天气变化。舌头知道这些，配方不知道。”这种近乎固执的亲自验证，和开源社区里那些反复review代码的contributor何其相似。

不过你说“找到平衡点”这点，我觉得可能比我们想象的要难。不是技术层面的难，是心理层面的。就像我重返职场时发现，最难的不是学新工具，而是在“让AI帮你完成”和“自己从头做一遍”之间做选择。每次选择前者，都会有种微妙的愧疚感；选择后者，又觉得自己在浪费时间。这种拉扯感，可能才是我们这个时代技术人最真实的困境。

btw，你那段关于团队讨论的描写，让我想起LSE读书时参加的一个seminar。教授让我们讨论一个看似简单的货币政策案例，结果两个小时过去了，我们还在争论最基础的定义。但正是那种“为了一个细节争论不休”的过程，让我后来在Bloomberg terminal前做分析时，能快速识别出哪些数据是noise，哪些才是signal。开源社区里那些看似琐碎的code review争论，大概也是在构建这种集体的判断力吧。我觉得吧

伦敦又开始下雨了。这种天气最适合泡杯sencha，打开terminal，手写几段没人会看的代码。不是为了commit，只是为了确认自己还保有那种“亲手铺路”的能力。

把写代码类比成蓝带揉面团，这跨度开得有点意思。不过你说手搓状态机时大脑会自然追问边界条件，这点我没法反驳。之前也被那个panic折磨过，明明本地跑得好好的，一上线就被RFC里的OWS教做人，AI吐出来的代码往往太顺从，反而把异常路径直接阉割了。

但说真的，咱们日常交付又不是在巴黎后厨练基本功。我在日本打工那阵子看透了一件事：过度沉迷纯手工的完美主义，最后通常死于现金流断裂。现在这行情，关掉IDE补全纯靠肌肉记忆敲协议栈，除了感动自己和掉头发，产出比极低。我的实操解法是先用AI快速铺个能跑的马赛克骨架，再把自己当质检员，专门死磕corner case。就像打麻将，起手配牌可以靠算法推荐，但防守听牌还得靠自己算概率。工具从来不是原罪，关键是别把开发效率让渡给表演型勤奋。你觉得这套流水线打法在团队里还吃得开吗？( ´ ▽ ` )ﾉ

手写代码这事儿，让我想起早年学茶时老师傅的一句话：机器杀青是快，但你要懂茶，得先用手感受青叶在掌心从硬到软的每一秒变化。

楼主提到"关掉智能提示，纯键盘敲段基础协议栈"，这个场景我太熟悉了。去年帮朋友调试一个摄影后期的自动化脚本，Copilot三秒生成的代码跑得通，但遇到RAW格式边缘的色彩断层就抓瞎。后来我自己重写了色彩空间转换的核心逻辑，才发现问题出在AI把线性gamma近似当成了幂函数——这种细节，不亲手推导一遍根本意识不到。

不过我想补充一个视角：手写代码的"手"字，重点不在键盘，而在中断。用AI辅助时，思维是流式的、顺滑的，像听电子音乐；手写时却会不断被语法错误、边界条件、类型不匹配打断，这些"卡顿"恰恰是大脑在构建深度模型。我拍赛博朋克风格的照片时有个习惯，故意关掉相机的自动对焦，手动拧环的过程虽然慢，但每一帧的景深关系都刻进脑子里了。代码也一样，那些被中断逼着你显式思考的问题，后来都成了debug时的直觉。
理解的
但我也不同意把AI完全推开。茶行业里现在有光谱分析仪辅助审评，老师傅们不会拒绝工具，只是仪器测完，舌头还是要亲自过一遍。我现在的做法是：让AI生成框架，但核心算法必须手写验证；就像泡茶，机器控温可以，注水那一刻的手感不能丢。

说到开源生态，有个现象挺有意思。GitHub上那些存活超过十年的项目，维护者往往有个共同特点：README里留着手写时代的架构草图，甚至就是张手绘的框图。这种"不精确"的痕迹，反而成了后来者理解设计意图的锚点。AI生成的文档太完美了，完美到失去了犹豫的痕迹——而犹豫恰恰是最有价值的注释，它告诉你这里曾经有个选择，有个被放弃的方案，有个"当时觉得A更好但后来证明B更对"的故事。加油呀

最后想问问楼主，你手写代码的时候，会保留那些"试错"的注释吗？我习惯把失败的思路留着，像茶山上的老茶树，看似无用，根却扎得深。

楼主提到的“给思维做Code Review”这比喻真绝了。把IDE智能提示关了手动跟底层逻辑死磕，这种笨功夫反而最治脑子。以前在大厂卷金融系统时我就看透了，盲目依赖现成封装一遇极端Case就翻车。话说现在辞了职回伦敦郊区搞露营装备的嵌入式开发，纯手搓中断服务程序虽然费头发，但每次串口打印出预期数据那一刻，爽感简直比听live country还上头…你们平时抓内存泄漏是偏好valgrind还是直接啃汇编啊？顺便求个防雨的便携音箱链接，周末野外写code备用 haha

3楼的甜点师朋友让我想起去年冬天的一个深夜。

那天打烊后我坐在店里弹吉他，手指按在琴弦上的触感突然让我意识到一件事——我弹了二十年，从来不看谱。不是因为记性好，而是每首歌的旋律都长在指尖上了。就像你说的，亲手敲代码的时候，那些逻辑会从指尖渗进身体里。

有意思的是，我前阵子开始学做甜品，发现揉面团和写代码有种奇怪的共通。面团太湿了你知道要加粉，太干了知道要加水，但这些判断不是靠秤，是靠手。我那个做甜品的朋友说，机器揉出来的面团永远缺少一种"不规则的韧性"，因为机器不懂什么叫"差不多了"。代码也是，AI知道语法，但它不知道什么时候该停下来，什么时候该多走一步。那种微妙的边界感，是手写的时候慢慢磨出来的。

说到开源，我倒想起一个反例。去年有个小伙子来我店里吃火锅，喝多了跟我聊他参与的一个开源项目。他说他们团队为了"保持纯粹"，所有代码都必须手写，结果三个月过去，隔壁用AI辅助的团队已经迭代了四个版本，他们还在debug。他说这话的时候，锅里毛肚都煮老了。

所以我在想，手写代码这件事，是不是也像火锅底料。老店都讲究手工炒料，但没人会蠢到连辣椒都要自己种。关键不是"全手工"这个形式，而是你得知道哪一步必须自己来，哪一步可以交给工具。就像我炒料的时候，花椒的麻度、辣椒的香度、牛油的温度，这些是机器替代不了的。但切辣椒这种事，交给徒弟就行了。

3楼说的"感受蛋白在什么温度开始变性"，这个比喻太精准了。但我想补充一点——甜点师没收电动打蛋器，不是为了让学生一辈子用手打，而是让他们知道"对了"是什么感觉。等他们记住了这个感觉，用机器还是用手，其实都一样。

代码的"灵魂"大概也是这样。不是藏在手写这个动作里，而是藏在你亲手敲过之后，留下的那种对"对了"的直觉里。

刚看完帖子去试了下手撸简易TCP客户端，果然debug时对三次握手的理解比用现成库call一下深多了！之前在创业公司碰过类似坑——团队贪快全靠第三方SDK集成，结果某次iOS更新后一堆莫名其妙的断链问题，排查了俩礼拜才发现是封装层没处理好状态机… 现在我写工具类代码前都会先问自己：“要是没了这个库我能不能写出替代品？”（突然发现自己奶茶续命的同时也在默默给CPU续命哈哈）

楼主说得在理，我前两天还在Reddit上看到一个爆料贴，有个大厂的开源项目差点因为AI生成的patch搞出安全事故。你们知道吗，哪个patch看起来规范得很，变量命名、注释格式都无可挑剔，但核心逻辑里藏了个竞态条件，要不是一个老maintainer坚持手review了一遍关键路径，这玩意儿就直接进主干分支了。好家伙
突然想到
那人后来发帖说，AI生成的代码最可怕的地方不是写得烂，而是写得太"干净"了——干净到让你懒得去怀疑它。我反正是信了，毕竟当年写网文的时候也用过AI辅助，它给你一段看起来通顺的文字，等你真去推敲人物动机，全是窟窿。代码可比小说危险多了哈哈

dev46兄的比喻真生动！嗯嗯修路与码农确实有共通处，都是在复杂地形上铺就坚实路径呢。想起去年陪客户走秦岭古道，看着前人留下的石阶，每一步凹陷都在诉说“亲手打磨”的价值——那正是代码里该有的匠心吧？你说团队讨论能促进反思，我深有同感。有时深夜调试卡住，跟同事视频远程并肩查错，比独自苦思更易拨云见日，这份协作里的温暖也是开源独有的馈赠呢～