<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>程序员成长 on 止语Lab</title>
        <link>https://www.wujiachen.com.cn/tags/%E7%A8%8B%E5%BA%8F%E5%91%98%E6%88%90%E9%95%BF/</link>
        <description>Recent content in 程序员成长 on 止语Lab</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-cn</language>
        <lastBuildDate>Mon, 13 Apr 2026 00:57:39 +0800</lastBuildDate><atom:link href="https://www.wujiachen.com.cn/tags/%E7%A8%8B%E5%BA%8F%E5%91%98%E6%88%90%E9%95%BF/index.xml" rel="self" type="application/rss+xml" /><item>
            <title>AI能读完所有文档，但读不到你的坑</title>
            <link>https://www.wujiachen.com.cn/posts/experience-is-moat/</link>
            <pubDate>Mon, 13 Apr 2026 00:57:38 +0800</pubDate>
            <guid>https://www.wujiachen.com.cn/posts/experience-is-moat/</guid>
            <description>&lt;img src=&#34;https://www.wujiachen.com.cn/&#34; alt=&#34;Featured image of post AI能读完所有文档，但读不到你的坑&#34; /&gt;&lt;p&gt;&lt;img alt=&#34;封面：开发者和AI站在文档库前&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;565px&#34; data-flex-grow=&#34;235&#34; height=&#34;672&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/cover.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/cover_14824612125512995033_hu_dec882da96a71816.png 800w, https://img.wujiachen.com.cn/experience-is-moat/cover.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1584w&#34; width=&#34;1584&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;上周技术评审会上，有人问了个问题：订单服务调库存和支付，分布式事务用什么方案？&lt;/p&gt;&#xA;&lt;p&gt;AI秒回三种方案。Saga，实现简单性能好，但补偿逻辑复杂。TCC，隔离性好一致性高，但每个服务要写三个接口。本地消息表，对业务侵入小，但有延迟。每种方案附了代码示例和架构图。&lt;/p&gt;&#xA;&lt;p&gt;问题来了，选哪个？&lt;/p&gt;&#xA;&lt;p&gt;AI不知道。不是分析不了，是做不了这个判断。选哪个不取决于方案本身的优缺点，取决于你的团队维护过补偿逻辑吗？你的支付服务并发高了会死锁吗？&lt;/p&gt;&#xA;&lt;p&gt;这些信息不在任何架构文档里。只在&amp;quot;上次踩过坑&amp;quot;的人脑子里。&lt;/p&gt;&#xA;&lt;p&gt;**&amp;ldquo;知道选项&amp;quot;和&amp;quot;做对选择&amp;quot;之间，隔着一整个生产事故。**这不是能力问题，是认知结构的问题。&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;一知道选项做不了选择&#34;&gt;&lt;a href=&#34;#%e4%b8%80%e7%9f%a5%e9%81%93%e9%80%89%e9%a1%b9%e5%81%9a%e4%b8%8d%e4%ba%86%e9%80%89%e6%8b%a9&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;一、知道选项，做不了选择&#xA;&lt;/h2&gt;&lt;p&gt;回到那个评审会。&lt;/p&gt;&#xA;&lt;p&gt;AI给了三个方案，信息完整，对比清晰。但团队里的老陈听完直接否了两个：&lt;/p&gt;&#xA;&#xA;    &lt;blockquote&gt;&#xA;        &lt;p&gt;&amp;ldquo;Saga？上次我们写补偿逻辑花了三个月，还踩了两个P0。补偿接口的幂等性和时序问题比主流程还复杂，我们团队撑不住。&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;&amp;ldquo;TCC？你看过支付服务的代码吗？Try接口会锁库存，并发一高就死锁。上次用TCC，灰度第二天就回滚了。&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;&amp;ldquo;本地消息表。我知道不优雅，但基础设施支持重试，团队也熟。出问题我能快速定位。&amp;rdquo;&lt;/p&gt;&#xA;&#xA;    &lt;/blockquote&gt;&#xA;&lt;p&gt;老陈做的不是&amp;quot;信息分析&amp;rdquo;，是&amp;quot;判断&amp;quot;。他不是在比较方案的优缺点，而是在回答一个更本质的问题：&lt;strong&gt;这个团队，在这个阶段，用这套基础设施，能撑住哪个方案？&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;AI能列出所有选项。但&amp;quot;选哪个&amp;quot;需要的不是信息，是判断力。判断力来自上次补偿逻辑写了三个月，来自上次TCC灰度回滚，来自消息表模式跑了一年的稳稳当当。&lt;/p&gt;&#xA;&lt;p&gt;这些经历，文档里没有。只有经历过的人才知道。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;三条岔路：分布式事务方案选择&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;321px&#34; data-flex-grow=&#34;133&#34; height=&#34;896&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/ch1-forking-paths.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/ch1-forking-paths_4585563392452688597_hu_d9e9b3921bca769d.png 800w, https://img.wujiachen.com.cn/experience-is-moat/ch1-forking-paths.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1200w&#34; width=&#34;1200&#34;&gt;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;二看不见的坑才最致命&#34;&gt;&lt;a href=&#34;#%e4%ba%8c%e7%9c%8b%e4%b8%8d%e8%a7%81%e7%9a%84%e5%9d%91%e6%89%8d%e6%9c%80%e8%87%b4%e5%91%bd&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;二、看不见的坑才最致命&#xA;&lt;/h2&gt;&lt;p&gt;知道选项选不了，那把经验写下来、喂给AI不就行了？&lt;/p&gt;&#xA;&lt;p&gt;问题是，**最危险的知识是&amp;quot;负向知识&amp;quot;——不能做什么、哪里不能碰、哪些坑是已接受的坏味道。**而负向知识几乎不会被主动记录。&lt;/p&gt;&#xA;&lt;p&gt;一个SaaS平台做认证服务的灰度发布，从v1升级到v2。AI给了标准流程：配置Istio流量权重，监控错误率，逐步放量。流程完全正确，配置示例也没问题。&lt;/p&gt;&#xA;&lt;p&gt;灰度那天，5%的流量打到v2，所有通过内部CRM处理的请求全部403。&lt;/p&gt;&#xA;&lt;p&gt;原因：下游有个5年前的老系统CRM，对接时对HTTP Header的大小写敏感。v1返回&lt;code&gt;x-user-role&lt;/code&gt;（全小写），v2用了新的HTTP库，默认规范化成&lt;code&gt;X-User-Role&lt;/code&gt;（首字母大写）。CRM收到大写Header，解析失败。&lt;/p&gt;&#xA;&lt;p&gt;这个大小写敏感的问题，从未被文档记录。当初发现的人直接修了，没写Wiki。v2用了新库会改Header格式，也没人意识到——除非你记得&amp;quot;上次CRM因为Header报过403&amp;quot;。&lt;/p&gt;&#xA;&lt;p&gt;踩过坑的人会怎么做？灰度前加一行中间件，做Header大小写转换。就这一行。但AI不会建议这行代码——它不知道CRM对大小写敏感。就算AI接入了所有内部文档和事故记录，它读到的也是&amp;quot;发生了什么&amp;quot;，不是&amp;quot;当时为什么那么决策&amp;quot;——更不是&amp;quot;为什么以后应该这么做&amp;quot;。知识库解决的是信息传递，不是认知结构。&lt;/p&gt;&#xA;&lt;p&gt;负向知识是&amp;quot;不能那么做&amp;quot;，不是&amp;quot;应该怎么做&amp;quot;。AI倾向输出&amp;quot;最佳实践&amp;quot;方案，因为训练数据偏好标准答案。但生产环境需要的不是&amp;quot;标准答案&amp;quot;，是&amp;quot;在这个满是历史技术债的系统里，哪个方案最不容易出事&amp;quot;。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;Header大小写暗雷&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;321px&#34; data-flex-grow=&#34;133&#34; height=&#34;896&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/ch2-header-trap.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/ch2-header-trap_18093453751493610148_hu_bc58239894c69434.png 800w, https://img.wujiachen.com.cn/experience-is-moat/ch2-header-trap.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1200w&#34; width=&#34;1200&#34;&gt;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;三有些东西就是说不出来&#34;&gt;&lt;a href=&#34;#%e4%b8%89%e6%9c%89%e4%ba%9b%e4%b8%9c%e8%a5%bf%e5%b0%b1%e6%98%af%e8%af%b4%e4%b8%8d%e5%87%ba%e6%9d%a5&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;三、有些东西就是说不出来&#xA;&lt;/h2&gt;&lt;p&gt;就算写下来了，有些东西你还是说不出来。&lt;/p&gt;&#xA;&lt;p&gt;你debug的时候，为什么看一眼日志就知道&amp;quot;又是那个问题&amp;quot;？你说得清吗？大概率说不清。你可以说&amp;quot;内存泄漏&amp;quot;，但为什么你跳过了前四步排查直接看GC日志？因为上次P0事故就是这么处理的。&lt;/p&gt;&#xA;&lt;p&gt;你能感觉到答案，但说不出来——不是表达能力的问题，是这种判断本来就不在语言能覆盖的范围内。你自己踩过的坑，你知道那个味道，但你要跟没踩过的人描述这个味道，说不出来。&lt;/p&gt;&#xA;&lt;p&gt;骑自行车也一样——你知道怎么保持平衡，但你说不出来。踩坑经验的结构类似：&amp;ldquo;知道&amp;quot;和&amp;quot;知道为什么&amp;quot;之间有不可传递的差距。&lt;/p&gt;&#xA;&lt;p&gt;你做过三次分布式事务选型，你知道&amp;quot;我们团队用Saga会出事&amp;rdquo;。你可以写进文档：&amp;ldquo;不建议使用Saga，因为2024年Q3补偿逻辑写了三个月且踩了两个P0。&amp;ldquo;但三个月后，新来的同事看到这条，能判断&amp;quot;当前情况是否和2024年Q3一样&amp;quot;吗？&lt;/p&gt;&#xA;&lt;p&gt;不能。因为他不知道当时为什么补偿逻辑写了三个月——业务复杂？团队不熟？需求变了？**文档记录了&amp;quot;发生了什么&amp;rdquo;，但没有记录&amp;quot;当时为什么这么决策&amp;rdquo;。**有人会说ADR（架构决策记录）不是记了&amp;quot;为什么&amp;quot;吗？确实。但ADR记的是决策当时的推理，不是决策之后&amp;quot;这个选择实际上导致了什么后果&amp;quot;——而后者才是判断力的真正来源。&lt;/p&gt;&#xA;&lt;p&gt;这就是&amp;quot;知道规则&amp;quot;和&amp;quot;知道何时用哪个规则&amp;quot;的差距。规则可以文档化，&amp;ldquo;何时适用&amp;quot;需要判断力。判断力不能被文档传递，只能通过亲身经历获得。&lt;/p&gt;&#xA;&lt;p&gt;你可以把所有踩坑经验写进Wiki、喂进知识库。但读Wiki的人和踩过坑的人，面对同一个决策时的反应完全不同。阅读&amp;quot;别人踩过的坑&amp;quot;和&amp;quot;自己踩过的坑&amp;quot;产生的是不同层次的判断力——前者是&amp;quot;知道&amp;rdquo;，后者是&amp;quot;知道为什么此时此地应该这么做&amp;quot;。不是信息差距，是认知结构差距。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;冰山图：知道 vs 知道为什么&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;240px&#34; data-flex-grow=&#34;100&#34; height=&#34;1024&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/ch3-iceberg.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/ch3-iceberg_13748213576906357244_hu_d167876a7c989f85.png 800w, https://img.wujiachen.com.cn/experience-is-moat/ch3-iceberg.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1024w&#34; width=&#34;1024&#34;&gt;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;四代码会贬值判断力不会&#34;&gt;&lt;a href=&#34;#%e5%9b%9b%e4%bb%a3%e7%a0%81%e4%bc%9a%e8%b4%ac%e5%80%bc%e5%88%a4%e6%96%ad%e5%8a%9b%e4%b8%8d%e4%bc%9a&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;四、代码会贬值，判断力不会&#xA;&lt;/h2&gt;&lt;p&gt;判断力不仅不可替代，还不可贬值。&lt;/p&gt;&#xA;&lt;p&gt;AI让写代码的边际成本趋近于零。以前一个CRUD接口你写45分钟，现在AI写15分钟。以前搭个项目骨架要一天，现在半小时。&lt;/p&gt;&#xA;&lt;p&gt;&amp;ldquo;我代码写得快&amp;quot;不再是护城河了。这层优势正在被抹平。&lt;/p&gt;&#xA;&lt;p&gt;但有一层优势抹不平：&amp;ldquo;我知道这个方案在第三年会出问题。&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;代码是会贬值的，今天写的，三年后可能被新技术替代、被重写、被遗忘。但你在某个方案上踩过的坑、做的取舍、承担的后果，不会贬值。它们长在你的判断力里，变成你面对下一个决策时的直觉。&lt;/p&gt;&#xA;&lt;p&gt;代码商品化了，但判断力没有。判断力没法批量生产，它不是信息的汇总，而是踩坑→决策→承担后果→修正直觉的闭环。AI可以读取这个闭环的结果，但无法经历这个闭环的过程。它依赖的上下文是你的团队、你的系统、你的历史，这些上下文不能被复制，只能被经历。&lt;/p&gt;&#xA;&lt;p&gt;你的护城河不在你写了什么代码，而在你踩过什么坑。而这个坑，AI替你踩不了。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;代码贬值 vs 判断力升值&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;321px&#34; data-flex-grow=&#34;133&#34; height=&#34;896&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/ch4-value-shift.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/ch4-value-shift_7923532172038574037_hu_18e2605c2c703f87.png 800w, https://img.wujiachen.com.cn/experience-is-moat/ch4-value-shift.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1200w&#34; width=&#34;1200&#34;&gt;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;五出事了ai和你的第一反应不一样&#34;&gt;&lt;a href=&#34;#%e4%ba%94%e5%87%ba%e4%ba%8b%e4%ba%86ai%e5%92%8c%e4%bd%a0%e7%9a%84%e7%ac%ac%e4%b8%80%e5%8f%8d%e5%ba%94%e4%b8%8d%e4%b8%80%e6%a0%b7&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;五、出事了，AI和你的第一反应不一样&#xA;&lt;/h2&gt;&lt;p&gt;判断力在决策时管用，在故障排查时更明显。&lt;/p&gt;&#xA;&lt;p&gt;凌晨两点，订单服务OOM告警，容器开始重启。&lt;/p&gt;&#xA;&lt;p&gt;AI给你五步排查流程：看内存曲线，查流量变化，导出内存分析（pprof），分析占内存最多的对象，排查协程泄漏。流程完全正确，按部就班30到45分钟定位。&lt;/p&gt;&#xA;&lt;p&gt;但经历过上次P0的工程师，第一反应不一样：&lt;/p&gt;&#xA;&#xA;    &lt;blockquote&gt;&#xA;        &lt;p&gt;&amp;ldquo;又是OOM？先看GC频率——GC在拼命回收但内存还是涨，是泄漏不是流量。&amp;rdquo;&lt;/p&gt;&#xA;&#xA;    &lt;/blockquote&gt;&#xA;&lt;p&gt;打开监控面板，GC频率从正常变成了每秒好几次。&lt;/p&gt;&#xA;&#xA;    &lt;blockquote&gt;&#xA;        &lt;p&gt;&amp;ldquo;回收不动。泄漏。&amp;rdquo;&lt;/p&gt;&#xA;&#xA;    &lt;/blockquote&gt;&#xA;&lt;p&gt;直接看内存分析里占内存最多的对象：&lt;/p&gt;&#xA;&#xA;    &lt;blockquote&gt;&#xA;        &lt;p&gt;&amp;ldquo;上次是&lt;code&gt;orderCache&lt;/code&gt;没过期淘汰，这次……不是，是&lt;code&gt;kafkaConsumer&lt;/code&gt;的offset提交卡住了，消息堆积，又没有背压保护，内存暴涨。&amp;rdquo;&lt;/p&gt;&#xA;&#xA;    &lt;/blockquote&gt;&#xA;&lt;p&gt;从告警到根因，5分钟。&lt;/p&gt;&#xA;&lt;p&gt;不是AI给的流程不对，是有经验的人能跳过大部分步骤，因为上次踩过。他知道先看GC频率，知道大概率是泄漏不是流量，知道先排除最可能的原因。&lt;/p&gt;&#xA;&lt;p&gt;当然，不是每次都这么顺利——但上次踩过的坑，这次确实能跳过大部分步骤。这种&amp;quot;快速排除&amp;quot;的能力，来自亲身经历。读一百篇OOM排查指南，不如凌晨两点被叫醒处理一次。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;AI排查 vs 经验工程师排查&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;430px&#34; data-flex-grow=&#34;179&#34; height=&#34;768&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/ch5-triage-comparison.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/ch5-triage-comparison_56237305521274664_hu_29699abd759893e3.png 800w, https://img.wujiachen.com.cn/experience-is-moat/ch5-triage-comparison.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1376w&#34; width=&#34;1376&#34;&gt;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;六经验不可省略但可以加速&#34;&gt;&lt;a href=&#34;#%e5%85%ad%e7%bb%8f%e9%aa%8c%e4%b8%8d%e5%8f%af%e7%9c%81%e7%95%a5%e4%bd%86%e5%8f%af%e4%bb%a5%e5%8a%a0%e9%80%9f&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;六、经验不可省略，但可以加速&#xA;&lt;/h2&gt;&lt;p&gt;说了这么多&amp;quot;不可替代&amp;rdquo;，那新手怎么办？如果经验不可替代，新一代程序员怎么成长？AI把初级岗位压缩了，中高级从哪来？&lt;/p&gt;&#xA;&lt;p&gt;答案不是&amp;quot;经验不可获得&amp;quot;，而是&amp;quot;经验不可跳过&amp;quot;。&lt;/p&gt;&#xA;&lt;p&gt;你可以读完所有游泳教材，了解自由泳的每一个动作要领。但你不亲自下水，就是不会游。教练可以让你学得更快——纠正姿势、教你换气节奏——但不能替你游。&lt;/p&gt;&#xA;&lt;p&gt;AI就是那个教练。它可以加速你获取经验的过程：帮你跑更多实验、更快定位问题、避免已知陷阱。但有个关键区别——教练自己会游，AI不会。教练基于亲身经验教你纠正姿势，AI基于训练数据猜测你可能需要的指导。教练的&amp;quot;教&amp;quot;来自&amp;quot;做过&amp;quot;，AI的&amp;quot;教&amp;quot;来自&amp;quot;见过&amp;quot;。所以AI没法替你踩坑，也没法替你为决策扛后果。&lt;/p&gt;&#xA;&lt;p&gt;&amp;ldquo;得自己疼过才知道&amp;rdquo;，不是悲观，是认知结构的限制。你可以在疼的过程中少走弯路，但不能跳过&amp;quot;疼&amp;quot;这个环节。&lt;/p&gt;&#xA;&lt;p&gt;如果经验的结构性不可替代，那经验传递的正确方式不是&amp;quot;写文档&amp;quot;，而是&amp;quot;创造经历&amp;quot;——所以如果你是团队里的老手，别只写文档，带新人做一次生产事故复盘，比写十页Wiki有用。如果你是新人，别只读文档，主动参与灰度发布、故障排查，让&amp;quot;别人的经验&amp;quot;变成&amp;quot;你的经历&amp;quot;。&lt;/p&gt;&#xA;&lt;p&gt;经验不可省略。但可以加速。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img alt=&#34;游泳池边的教练和学员&#34; class=&#34;gallery-image&#34; data-flex-basis=&#34;321px&#34; data-flex-grow=&#34;133&#34; height=&#34;896&#34; loading=&#34;lazy&#34; sizes=&#34;(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px&#34; src=&#34;https://img.wujiachen.com.cn/experience-is-moat/ch6-swim-coach.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast&#34; srcset=&#34;https://www.wujiachen.com.cn/ch6-swim-coach_11557432032927743552_hu_706b1fba34df7f11.png 800w, https://img.wujiachen.com.cn/experience-is-moat/ch6-swim-coach.png!/watermark/text/5q2i6K+tTGFi/size/20/color/666666/opacity/70/align/southeast 1200w&#34; width=&#34;1200&#34;&gt;&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;p&gt;AI能读完所有文档。但文档里不会写&amp;quot;上次我们踩过这个坑&amp;quot;。&lt;/p&gt;&#xA;&lt;p&gt;你的判断力不靠背架构模式，也不靠读技术博客。它在你踩过的坑里、做过的取舍里、为某个决策扛过的后果里。&lt;/p&gt;&#xA;&lt;p&gt;这些东西，AI读不到。你的同事也读不到。只有你自己经历过才知道。&lt;/p&gt;&#xA;&lt;p&gt;这不是AI目前不行的局限，是认知结构的限制。不管AI多强，有些知识只能通过亲身经历获得。就像你可以读完所有游泳教材，但不下水就是不会，&amp;ldquo;知道&amp;quot;和&amp;quot;会&amp;quot;之间，隔着一整个水。&lt;/p&gt;&#xA;</description>
        </item></channel>
</rss>
