一篇发在个人技术博客NotAShelf上的文章，最近在开发者社区里被反复转发。文章标题直白——《Taste Is All That's Left》,发布于2026年8月6日,核心判断只有一句话:AI编程工具已经把"把想法变成能跑的程序"这道门槛拆得几乎不剩,但省下来的成本没有消失,它只是换了个地方出现,变成了在一堆看起来都对的AI生成方案里，判断哪个才真正对的能力。
作者用了一个说法概括这种转变:"好用"是一种溶剂,会把"做得更好"的动力慢慢溶解掉。以前做一件事要花成本,成本本身就是过滤器——没人会做一千个平庸版本，因为一千倍的成本谁也付不起。现在这道过滤器没了，决定什么值得留下的，不再是制作成本，而是看的人的判断力，也就是文章反复强调的那个词：taste，品味。
品味从哪儿来，这是原文没敢细说的部分
文章借了《禅与摩托车维修艺术》里罗伯特·波西格的"Quality"概念——好机械师在说出原因之前，就已经感觉到发动机不对劲；好编辑在指出哪个从句出问题之前，就已经觉得这句话读着别扭。作者认为这种判断从来就不是靠看好作品攒出来的,而是靠做出烂东西、被迫承受它失败这种笨办法磨出来的。
问题在于，AI恰好把这个磨的过程拿走了。新人第一天就能流畅产出，永远不用经历"做砸了、硬着头皮上线、然后被现实教育"这一关。作者的结论偏悲观：他们会更能产出，却学不会判断"这东西该不该做"。
谁都能生成，几乎没人能判断什么值得生成。
这个判断听着有道理,但把它当成必然规律,其实经不起推敲。行业里更细的说法是：去技能化不是工具决定的，是用法决定的。判断一个工程师会不会被AI掏空判断力，看的不是他用不用AI，而是他有没有守住一条线——是否还在检查生成代码的行为、挑战它的假设、亲自调试它出的故障、为它的结果签字负责。这条线通常被概括为"拥有系统"而不是"写出系统"：你能不能解释这套代码怎么运作、识别它的不变量、评估换一种做法的代价。守住这条线的人，用AI反而更高产；放弃这条线、无条件接受"看起来对"的输出的人，才是真正丢掉判断力的那一批。
团队能不能把摩擦人为补回去
这里出现了一个原文完全没碰的问题：既然摩擦是学徒期的课程，那生产成本已经被压到接近零之后，还有没有办法人为造一道摩擦出来？
答案是有，但要靠组织主动设计，不会自己长出来。
- 结论.架构评审、对抗性测试、生产环境的可观测性、以结果而不是代码量考核，都是把"失败-反思"这个闭环重新接上的具体手段，不用真的等系统在生产上炸掉。
这几种机制的共同点，是把原文那种"必须亲身经历失败才能学会"的宿命论，改写成一个有条件的命题：只要团队愿意制造真实的检查点，新人依然可以在没有真实事故成本的情况下，学到判断力该有的样子。这和当年围绕IDE、开源库、低代码平台反复出现的"工具让人变懒"的焦虑是同一个结构，只是这次AI把生产成本压得更彻底，考验团队能不能把学徒制重新设计一遍。
谁该盯紧这件事
对刚入行的工程师来说，最实际的问题不是"能不能用AI"，而是所在的团队有没有替代性的检查机制——强制代码评审、要求解释生成逻辑、故意留出调试真实故障的机会。如果团队图省事把这些环节也省了，那才是原文描述的最坏情况真正发生的时候。
对资深工程师和技术主管，另一个现实是：品味这种优势目前还看不出会保持多久。它不会出现在代码差异里，市场也没法用速度指标把它和"看起来能跑就行"的产出区分开。企业要重新想清楚，招聘和培养体系还能不能继续用产出速度衡量初级员工，还是该换成能不能解释、能不能负责这类更慢、更难量化的标准。
这场争论到底是又一轮工具革命焦虑的重演，还是真的碰到了性质不同的转折点，目前没有实证研究给出答案，只有各家博客和团队各自的判断。值得持续盯的，是有没有具体公司公开过自己应对"AI去技能化"的培养机制，那会是比任何一篇个人随笔都更硬的证据。