[{"data":1,"prerenderedAt":349},["ShallowReactive",2],{"\u002F2025-09-14-5percentai":3,"\u002F2025-09-14-5percentai-rel":136},{"id":4,"title":5,"body":6,"column":119,"date":120,"description":12,"extension":121,"hero_image":122,"meta":123,"navigation":124,"path":125,"seo":126,"series_id":122,"severity":122,"stem":127,"summary":128,"tags":129,"__hash__":135},"posts\u002F2025-09-14-那5%我不交给AI.md","那 5%，我不交给 AI",{"type":7,"value":8,"toc":111},"minimark",[9,13,16,21,24,27,30,33,36,40,43,46,49,52,55,59,62,65,68,71,79,82,85,92,105,108],[10,11,12],"p",{},"用 AI 写代码一年多，交出去的比例一直在涨。但有三类工作我始终自己做，不是还没轮到它们，是明确不交。",[10,14,15],{},"这条线比\"AI 能干什么\"更值得写。能力清单每隔几个月就过期一次，而边界为什么在这里，理由是稳定的。",[17,18,20],"h2",{"id":19},"第一类架构设计","第一类：架构设计",[10,22,23],{},"不是说 AI 给不出架构方案——它给得出，而且通常看起来很合理：分层清晰、职责分明、扩展点齐全。",[10,25,26],{},"问题在于合理的方案可能是错的。",[10,28,29],{},"架构决策依赖两样东西：对业务往哪走的判断，以及对历史包袱的了解。前者在我脑子里都未必清楚，更不在上下文里；后者是一堆\"当初为什么这么做\"的历史，散落在几年的提交记录、废弃的分支、和某次线上事故之后加的一个 workaround 里。这些东西没法塞进对话。",[10,31,32],{},"于是会得到一个技术上自洽、但在具体处境里错误的方案。它不违反任何原则，只是不适合这个项目。而这类错误的代价是最高的——写错的函数改起来是几十行，选错的架构改起来是几个月。",[10,34,35],{},"我的做法是：架构自己定，定完让 AI 挑毛病。让它扮演一个不了解历史的新人来审——它确实就是。它提的问题里，一部分是我已经权衡过的（那说明我的文档没写清），一部分是我真的漏了。这个用法比让它出方案有价值得多。",[17,37,39],{"id":38},"第二类它试了几轮还没解决的问题","第二类：它试了几轮还没解决的问题",[10,41,42],{},"这一类不是按任务性质划的，是按过程判定的。",[10,44,45],{},"同样是\"修一个 bug\"，有时候 AI 两三轮就搞定，有时候十轮还在原地打转。而事前看不出区别——难点常常不在描述里。所以先验分类没什么用，我改用一个事后判据：给它固定几轮，不收敛就自己接手。",[10,47,48],{},"不收敛的样子挺好认：反复改同一处、每轮都给一个新解释但都不对、或者开始建议重写一些明明无关的代码。最后那个信号最明确——它在扩大搜索范围，因为在原范围里已经找不到解了。",[10,50,51],{},"这时候接手，第一件事不是自己从头写，而是找它缺的那条信息。多轮不收敛几乎总意味着关键事实不在它能看到的范围内：一个没被提及的环境差异、一份没给它的日志、一个只有我知道的历史约定。补上那一条，往往剩下的它自己就能做完。",[10,53,54],{},"真正需要我从头写的情况很少。绝大多数\"AI 搞不定\"其实是\"我没给够\"。",[17,56,58],{"id":57},"第三类极高风险操作","第三类：极高风险操作",[10,60,61],{},"发版、删数据、改生产配置。",[10,63,64],{},"这三件事的共同点不是难，是不可逆且影响面大。判断的依据不该是 AI 做得对不对——它大概率做得对——而是做错一次的代价。一个函数写错，测试会拦住，最差是回滚一个提交。一次删错数据，回滚的对象是用户的东西。",[10,66,67],{},"这里面的不对称很关键：AI 在这类操作上的正确率可能比我高（它不会漏步骤、不会记错顺序、不会因为做过一百遍就跳过检查）。但正确率高不代表可以授权，因为失败的代价不由它承担。",[10,69,70],{},"我确实有过一次事故：AI 删掉了数据。恢复它靠的是备份——我一直在做大量备份，那次照常有一份可用的。",[10,72,73,74,78],{},"事后我想的不是\"以后要更小心\"，而是另一件事：",[75,76,77],"strong",{},"如果那次没有备份，这个边界就根本不存在","。我之所以敢把大部分工作交出去，前提是错了能回来。没有兜底的授权不是信任，是赌博——而赌赢过几次的人最容易把它误认为信任。",[10,80,81],{},"所以这条边界真正的支撑不是我不让 AI 碰这些操作，而是我在它碰得到的地方都留了退路。前者是纪律，后者是基础设施。纪律会松，基础设施不会。",[17,83,84],{"id":84},"三条线的共同点",[10,86,87,88,91],{},"回头看这三类，划线的依据其实是同一个问题：",[75,89,90],{},"出错的时候，谁能发现，以及能不能回来","。",[93,94,95,99,102],"ul",{},[96,97,98],"li",{},"架构错误：很晚才能发现，而且几乎回不来",[96,100,101],{},"多轮不收敛：立刻能发现（它自己在原地转圈），随时能回来",[96,103,104],{},"高风险操作：可能立刻发现，但回不回来取决于有没有备份",[10,106,107],{},"中间那一类之所以可以交给 AI 试，正是因为它失败得很明显、很便宜。而另外两类，一个是发现得太晚，一个是回不了头。",[10,109,110],{},"这个判据比\"哪些任务适合 AI\"更耐用。任务类型会变，模型能力会涨，但\"错了能不能发现、能不能回来\"这两个问题永远得先答。",{"title":112,"searchDepth":113,"depth":113,"links":114},"",2,[115,116,117,118],{"id":19,"depth":113,"text":20},{"id":38,"depth":113,"text":39},{"id":57,"depth":113,"text":58},{"id":84,"depth":113,"text":84},"工具链观察","2025-09-14","md",null,{},true,"\u002F2025-09-14-5percentai",{"title":5,"description":12},"2025-09-14-那5%我不交给AI","绝大部分开发工作可以交给 AI，但有三类明确不交：架构设计、AI 多轮未解决的问题、极高风险操作。边界比能力更能说明判断力。",[130,131,132,133,134],"AI 编程","工作边界","风险控制","备份策略","架构决策","B4TC5bxguSoGpmQZ8NDmriLk4_0Iqgk9TWIJsitPCIQ",[137,211],{"id":4,"title":5,"body":138,"column":119,"date":120,"description":12,"extension":121,"hero_image":122,"meta":208,"navigation":124,"path":125,"seo":209,"series_id":122,"severity":122,"stem":127,"summary":128,"tags":210,"__hash__":135},{"type":7,"value":139,"toc":202},[140,142,144,146,148,150,152,154,156,158,160,162,164,166,168,170,172,174,176,178,182,184,186,190,198,200],[10,141,12],{},[10,143,15],{},[17,145,20],{"id":19},[10,147,23],{},[10,149,26],{},[10,151,29],{},[10,153,32],{},[10,155,35],{},[17,157,39],{"id":38},[10,159,42],{},[10,161,45],{},[10,163,48],{},[10,165,51],{},[10,167,54],{},[17,169,58],{"id":57},[10,171,61],{},[10,173,64],{},[10,175,67],{},[10,177,70],{},[10,179,73,180,78],{},[75,181,77],{},[10,183,81],{},[17,185,84],{"id":84},[10,187,87,188,91],{},[75,189,90],{},[93,191,192,194,196],{},[96,193,98],{},[96,195,101],{},[96,197,104],{},[10,199,107],{},[10,201,110],{},{"title":112,"searchDepth":113,"depth":113,"links":203},[204,205,206,207],{"id":19,"depth":113,"text":20},{"id":38,"depth":113,"text":39},{"id":57,"depth":113,"text":58},{"id":84,"depth":113,"text":84},{},{"title":5,"description":12},[130,131,132,133,134],{"id":212,"title":213,"body":214,"column":119,"date":337,"description":218,"extension":121,"hero_image":122,"meta":338,"navigation":124,"path":339,"seo":340,"series_id":122,"severity":122,"stem":341,"summary":342,"tags":343,"__hash__":348},"posts\u002F2025-07-20-五个模型我都熟只用一个.md","五个模型我都熟，只用一个",{"type":7,"value":215,"toc":330},[216,219,222,225,228,231,234,237,240,246,249,255,261,267,273,276,279,282,285,288,291,294,300,303,306,309,312,315,321,324,327],[10,217,218],{},"从 o1 发布那会儿开始碰 AI，到现在快一年。Claude、GPT、Gemini、GLM、Kimi 这几家我都实际用过一段时间，不是试两句就走的那种熟。",[10,220,221],{},"然后日常固定只用其中一个。",[10,223,224],{},"这跟到处能看到的建议是反的——那些建议大意都是\"按任务选模型\"：长文档分析用这家、写代码用那家、要便宜用另一家。听起来很合理，是把每个任务都放到最擅长它的模型上。我试过这么干，后来放弃了。",[17,226,227],{"id":227},"不是因为其他模型不行",[10,229,230],{},"得先把这句说清楚，否则下面全是偏见。",[10,232,233],{},"这五家在我用过的任务上都能干活，各自也确实有明显更强的地方。如果把单个任务孤立出来比，\"按任务分派\"的结论是对的——某类任务上换一家，产出确实更好一点。",[10,235,236],{},"问题是任务并不孤立存在。",[17,238,239],{"id":239},"切换成本不在模型上",[10,241,242,243,91],{},"真正的成本不是学会用一个新模型——那很快，几小时就能上手。成本在于",[75,244,245],{},"围绕单一工具沉淀下来的那些东西，换模型就得重建",[10,247,248],{},"至少有四样：",[10,250,251,254],{},[75,252,253],{},"一套写规则的习惯。"," 用久了就知道这个模型对什么样的指令反应准，哪种表述会被忽略，哪些约束必须重复强调它才当真。这些不是通用的 prompt 技巧，是针对具体模型的。换一家，重新摸。",[10,256,257,260],{},[75,258,259],{},"对它失败模式的直觉。"," 这一条最值钱，也最难迁移。用久了会形成一种预感：这个任务它大概会在哪一步跑偏、什么样的回答是\"它其实没懂但在硬答\"、哪种沉默意味着上下文不够。这种直觉让我能在它出错之前就介入。换模型之后，直觉全部失效——而且是无声失效，你不知道自己已经不准了，只会觉得\"最近怎么老出问题\"。",[10,262,263,266],{},[75,264,265],{},"上下文的组织方式。"," 给多少、按什么顺序给、什么该放开头、什么放结尾、哪些信息其实是噪音。这些在不同模型上的最优解不一样。",[10,268,269,272],{},[75,270,271],{},"命令与工作流的肌肉记忆。"," 这个最琐碎，但每天都在消耗。",[10,274,275],{},"四样加起来，换模型的真实代价是把这些重新长一遍。而收益，是某类任务上的边际提升。",[10,277,278],{},"这笔账在多数时候是不划算的。",[17,280,281],{"id":281},"分派本身也有成本",[10,283,284],{},"还有一层容易被忽略：即使不算沉淀成本，\"按任务分派\"本身也不免费。",[10,286,287],{},"每个任务开始前多了一个决策：这个该给谁。这个决策不难，但它是持续的、高频的、而且经常做不准——因为一个任务的难点往往在做的过程中才暴露出来，事前分派依据的是对任务的初始判断，而初始判断经常是错的。",[10,289,290],{},"于是会出现更糟的情况：任务开到一半发现选错了，换一家重做。此时前面积累的上下文全部作废，因为它在另一个会话里。",[17,292,293],{"id":293},"什么时候值得切换",[10,295,296,297],{},"不是永远不换。判据是：",[75,298,299],{},"它在我的主力场景上有代际差距，而不是某个单点更强。",[10,301,302],{},"单点更强不值得动——比如某家的长文档处理明显好，但我一周只做两次长文档分析，为这个把主力工作流迁走，账算不平。",[10,304,305],{},"代际差距值得动——如果某家在\"理解一个中等复杂度的代码库并做出正确修改\"这件事上明显进了一档，那该换，因为这就是我 80% 的时间花的地方，沉淀成本会被摊平。",[10,307,308],{},"区别在于那个能力是不是压在主路径上。",[17,310,311],{"id":311},"一个更一般的判断",[10,313,314],{},"这件事想通之后，我看工具选型的角度变了。",[10,316,317,318],{},"以前会比参数、比榜单、比某几个 case 的产出质量。现在会先问另一个问题：",[75,319,320],{},"我能在这个东西上面沉淀多深？",[10,322,323],{},"能沉淀得深的工具，即使起点不是最强的那个，一年之后的实际产出也会超过一直在换的那种。因为沉淀是复利，而每次切换都把利息清零。",[10,325,326],{},"反过来，如果一个工具让我沉淀不下任何东西——每次用都像第一次用——那它多强都只是个临时的外援，不构成能力。",[10,328,329],{},"这也解释了为什么\"用哪个模型\"这个问题被问得太多，而\"你在它上面攒下了什么\"几乎没人问。后者才是差距真正拉开的地方。",{"title":112,"searchDepth":113,"depth":113,"links":331},[332,333,334,335,336],{"id":227,"depth":113,"text":227},{"id":239,"depth":113,"text":239},{"id":281,"depth":113,"text":281},{"id":293,"depth":113,"text":293},{"id":311,"depth":113,"text":311},"2025-07-20",{},"\u002F2025-07-20",{"title":213,"description":218},"2025-07-20-五个模型我都熟只用一个","Claude、GPT、Gemini、GLM、Kimi 都用熟了，日常固定只用一个。切换模型的真实成本不在学习模型本身，而在重建围绕它沉淀的一切。",[130,344,345,346,347],"模型选型","工具链","Claude","迁移成本","RYfIUu2g7SajwWGxT566_tQuNPrz69n3WeD4dchs_ho",1785406912450]