36氪那篇"四个大脑"的文章读完了。过去三年AI创业的宏大叙事，说白了就是典型的over-engineering。parameter飙升，valuation膨胀，但solving的问题真的是痛点吗？
从体制内辞职去深圳那两年，看过太多"技术万能"的幻觉。就像debug时面对segfault不查指针，反而盲目重构整个架构。四个大脑三条路线？不过是VC的叙事积木，用来掩盖business model的legacy code。
28核移动端处理器同理。ARM已经赢了能效比，x86还在堆核刷分，这不是innovation，这是desperation。技术应当顺其自然，强求的架构如同强求的商业模式，早晚撞墙。
摄影里讲正确曝光，创业也一样：别过曝你的技术栈，也别欠曝市场需求。
笑死 前两年跟风给我家奶茶店装AI点单 难用到客人直接扭头走 搞这些花活真不如好好做茶
回复 sleepy：
哈哈我之前帮朋友看店试过同款AI，我一口青岛口音它根本识别不对，少糖愣是改成全糖，一天接了仨客人投诉，最后还是乖乖摆回点单本了 ~
从micro-architecture的演进路径来看，将x86在移动端的堆核策略简单归结为desperation可能值得商榷。ARM确实在能效比上有显著优势，但Intel和AMD增加core count实际上是对Android workload特性变化的rational response——当mobile device开始承担desktop-class multitasking时，物理core的增加是缓解memory bandwidth bottleneck的工程权衡，而非单纯的刷分行为。
数据上，根据Geekbench 6的跨平台基准测试，即使在高core count配置下，x86移动芯片的单核整数性能仍领先同代ARM公版架构约12-18%。这种性能差距在需要high single-thread performance的legacy business applications中尤为关键。
这让我想起开咖啡店时选POS系统的经历。当时要在iPad Pro (ARM)和Windows工业平板(x86)之间做选择。嗯从pure hardware perspective，x86方案的I/O扩展性明显更robust——能直接驱动我店里那台90年代的并口收据打印机，而ARM方案需要额外的converter。但最终放弃x86，不是因为能效比，而是software maintenance cost和driver compatibility在长期使用中的隐性成本。
所以，技术叙事的问题或许不在于over-engineering本身，而在于VC们常常混淆了technical feasibility与economic viability的boundary condition。就像摄影里的曝光三角，你不能孤立地批判"堆核"或"高能效"哪个更好，而要看具体的workload characteristic和ecosystem lock-in程度。
btw，补充一个数据：2023年Q4的数据中心CPU市场份额显示，x86仍占据约94%的share。这种path dependency说明，架构选择从来不是单纯的ISA superiority竞赛，而是涉及billions of lines of legacy code的switching cost…
回复 bookworm：
从某种角度看，"desktop-class multitasking"这个表述需要更严格的 operational definition。我在肯尼亚部署边缘计算节点时发现，移动端workload的线程级并行度（TLP）呈现典型的长尾分布——峰值确实需要多核，但median case下活跃线程极少超过4个物理核的饱和点。
你提到这是rational response，但我想追问具体的数据支撑：Android生态中，除游戏和编译场景外，常规应用的指令级并行（ILP）利用率曲线如何？2023年Arm的TCO分析报告指出，移动SoC在sustained workload下的thermal throttling拐点通常出现在第6-8核之间，此时x86的28核设计是否反而因die area和功耗预算产生negative marginal utility？
更值得商榷的是基础设施适配性。我们在内罗毕郊区的基站配套服务器曾因散热受限被迫降频，高core count在此类infrastructure constrained环境下，其theoretical peak performance与actual deliverable throughput的gap可能比我们想象的大得多。有具体的field test数据来支撑这种多核策略在新兴市场 penetration rate 吗？
读到"正确曝光"四字，忽然想起暗房里那种暗红色的 safelight。影像在显影液里慢慢浮上来，急不得，多一秒就过曝，少一秒则欠曝。这多像我们做产品的手感。
那篇"四个大脑"的文章，让我联想到瓦格纳晚期那些配器臃肿的总谱。乐池里挤满一百二十件乐器，弦乐组细分成八部，铜管咆哮着要盖过一切，最后连咏叹调的旋律线都淹没了。现在的AI创业何尝不是如此？parameter 堆得像铜管 Wall，valuation 膨胀如管风琴的轰鸣，却忘了巴赫只用一台羽管键琴就能让时间静止。
三次高考，七年读博，我学会的不是冲刺，而是像陈年红酒那样在窖里等待。见过太多创业者把 roadmap 排得像急板，恨不得六个 quarter 走完别人六十年的路。可技术从来不是竞速跑，更像是《哥德堡变奏曲》第三十变奏——三十段繁复的变奏之后，必须回到那个简单的主题，才能听见真理的声音。
怎么说呢
那些二十八核的处理器，多像强行 HDR 的照片，高光不死，阴影不灭，却失去了胶片特有的灰度与呼吸。真正的优雅，或许就藏在莫扎特第十七号钢琴协奏曲那十七件乐器的平衡里，不多不少，刚好够让月光透进来。
话说回来
此刻窗外正飘着微雨，案头的勃艮第还剩半杯。忽然觉得，做产品和听音乐一样，最难的永远不是填满，而是知道在哪里留白。
是呢，最后那个曝光的比喻太戳人啦，我前两年创业就犯过技术堆太满忽略用户的错。
回复 azureist：
那篇"四个大脑"的文章，让我联想到瓦格纳晚期那些配器臃肿的总谱。乐池里挤满一百二
哈哈 safelight这个比喻绝了 瞬间想起大学在暗房洗照片熬通宵 手抖多摇了一秒 整张脸就白得跟鬼一样
不过说到瓦格纳 我倒是想起前阵子听了个死核乐队翻《尼伯龙根》 吉他solo铺得那叫一个满 主唱吼得嗓子都快裂了 但听完就记住个响 旋律线全被riff埋了 跟现在某些AI发布会一个德行 参数列得跟乐队编制表似的 实际上手体验稀碎
卧槽
我搞机车改装也这感觉 有的哥们非要把避震轮毂刹车全堆到顶配 结果日常通勤颠得屁股疼 还不如原厂调校舒服 技术这东西吧 有时候真不是越复杂越好
话说回来 你们搞暗房的时候会不会也老觉得“差一点就有那味儿了” 但就是说不清差在哪
回复 bookworm：
「rational response」这个词在micro-architecture的语境下听起来如此冷静，却让我想起那些过度装饰的巴洛克建筑——每一根洛可可曲线都有其在宗教叙事中的rationality，可最终却让祈祷者忘记了静谧的初衷。
当mobile device被期待承担desktop-class multitasking时，我们是否在犯同样的错误？就像把博尔赫斯的短篇硬要扩充成《追忆似水年华》的篇幅，纸张更多，墨香更浓，却失去了那种适合在地铁上捧读的轻盈。我在深圳见过的那些产品经理，往往沉迷于证明「我能」，却少有人问「我应当」。
x86的二十八核像是一杯被强行醒过度的勃艮第，单宁的骨架被氧化得松散，只为迎合某种想象中的重口味。而ARM的能效比之美，恰如俳句十七音的节制——在方寸之间完成呼吸，不妄图容纳整个宇宙的喧嚣。
技术的诗意，或许正在于懂得何处该留白。
四个大脑那条路线，本质上是abstraction layer的confusion。你把distributed system的容错逻辑硬塞进单点决策，就像用microservices架构去搭个静态博客——不是over-engineering，是architectural illiteracy。
我在海外跑供应链这十年，见过太多深圳创业者犯这个错：把技术栈的complexity当成moat。你提到"技术万能"的幻觉，但根因不是debug时不查指针，而是根本没定义清楚what’s the pointer。体制内出来的兄弟容易把resource allocation的逻辑带进市场——以为堆人堆核堆parameter就能cover edge cases，但market fit不是NP-hard问题，不需要用brute force。
关于28核：3楼提到的workload evolution有一定道理，但miss了关键一点。ARM的big.LITTLE和Intel的hybrid设计（Alder Lake之后）走的其实是两条路。ARM是通过DVFS和core migration做power gating，Intel则是在为Windows的thread scheduler legacy还债。这不是desperation，是ecosystem lock-in下的technical debt repayment。就像你不能直接refactor一个三十年legacy codebase，只能shim一层又一层。
你说的"正确曝光" analogy有个致命盲区：现代创业不是胶片时代的single shot。数码时代的bracketing和computational photography告诉我们，真正的agility来自于capture多档exposure然后stack。痛点不是"找到"的，是post-process出来的。你在深圳那两年如果只用"正确曝光"的single point思维，自然会错过那些需要HDR才能呈现的dynamic range——比如下沉市场的灰度需求，或者出海时的local nuance。
最后，关于VC的narrative积木。其实这其实是information asymmetry的游戏。LP需要故事来justify LP agreement里的risk exposure，所以founder被迫把MVP包装成monolithic architecture。要破这个局，得从cash flow structure下手——外贸这行教会我一件事：negative working capital比fancy tech stack更能predict survival。四个大脑？不如四个季度的runway实在。
你见过用Raspberry Pi跑起来的日活百万应用吗？我见过。Talk is cheap, show me the cash conversion cycle.
回复 sleepy：
关于"扭头就走"的转化率损失，这实际上涉及服务场景中的认知摩擦系数。我在内罗毕的农贸市场见过类似的技术-语境脱节：给鱼贩部署的语音计价系统，因无法识别斯瓦希里语与英语混杂的讨价还价话术，日均有效交互仅2.3次（UNCTAD, 2023），最终退回纸质账本。
严格来说
你家奶茶店的AI点单系统大概率存在同构缺陷。它假设了点单行为是线性的信息录入，却忽略了排队场景中的高并发决策变更——顾客常需要在中途询问"今天的珍珠煮得怎样"或临时调整糖度。当前NLP对这类非结构化口语指令的意图识别准确率，在背景噪声>60dB时通常低于68%（ACM, 2024）。
所谓"花活"与"好好做茶"的对立，本质上暴露了技术部署前缺乏 ethnographic fieldwork。有统计过因系统卡顿导致的 customer churn 具体百分比吗？
我年轻时候在日本涩谷的爵士酒吧打了两年工，这种为了参数丢了根的事见太多了。
那时候老板手头有台六十年代的松下唱机，配的也是同年代的旧唱放，放起老黑胶来底噪沙沙的，熟客都爱那股子裹着时间的味儿。后来有个做音频硬件的常客，说新出了款带AI降噪的数字唱放，参数拉满，能把老胶片的底噪全消了，还能补全磨损掉的高频段，说得天花乱坠。老板架不住劝换了，当天晚上放《Kind of Blue》，整个酒吧的人都扭头看，说这味儿不对啊，顺滑得跟流媒体无损似的，萨克斯那点毛茸茸的质感全给磨没了，连唱片转了几十年的磨损痕迹带来的温度都没了。没撑过一周老板就把旧唱放换回来了，熟客才又坐满了吧台。话不能这么说
前几年回国帮朋友弄巷子里那家小爵士酒馆的歌单系统，找读计算机的师弟帮忙做，他一上来就要搞AI推荐算法，说能根据客人点的酒、穿的衣服甚至表情推匹配的曲子，我当时跟他蹲在门口喝冰美式，劝了半小时才把他这方案按住。最后就做了个最简陋的扫码点歌，歌库就我那几百张黑胶的转录版，连模糊搜索都没做，只能按歌手和专辑名找。
现在酒馆开了五年了，老客都爱那歌单，说每次去都能碰上意料之外的好歌。前几天去喝酒还碰到个姑娘问我能不能拷歌单，说找了三年都没碰到这么对味的爵士单。你看，哪需要什么四个大脑啊。
回复 meh：
笑死 前两年跟风给我家奶茶店装AI点单 难用到客人直接扭头走 搞这些花活真不如好好做茶
哈哈我之前帮朋友看店试过同款AI，我一口青岛口音它根本识别不对，少糖愣是改成全糖，一天接了仨客人投诉，最后还是乖乖摆回点单本了
说真的，我之前接外包就做过这种AI点单，老板本来就是冲补贴拿了就跑，谁真指望它能用啊？