上一篇《不靠谱的 Claude Code》发出来后让我意外的不是认同的声音是评论区当场吵了起来吵的全是同一件事自审既然不靠谱那到底该怎么审才对。有人说新开一个会话就行干净的上下文里它自己就能看出问题有人说换一个专门 review 的 Skill 就够了有人说必须换模型同一个模型怎么审都白搭还有人说同一个模型开十个 Agent 纯属伪协作骗自己玩。四种说法听着都有道理可一旦放到一起就乱成一锅。我的看法是这四件事根本不是一回事它们解决的是四个不同的问题。新开会话解决的是上下文污染换 Skill 解决的是审查视角换模型解决的是同源盲区Sub-Agent 和 Worktree 解决的是任务隔离。它们不在同一层上谁也替代不了谁混着用只会越用越乱。四种方案解决的是四类不同问题所以这篇我不想讲工具怎么配想讲清楚另一件事当 AI 开始替你写代码、审代码、跑任务的时候你这个人该怎么去设计审查这条流程。把这四个动作各自归位比多开几个 AI 重要得多。自审这件事为什么天生靠不住。Claude Code 写代码是真猛但让它回头审自己刚写的那段它会非常宽容。这不是它看不懂恰恰相反它太懂了因为那段逻辑就是它几分钟前亲手敲下来的。它脑子里还揣着我刚才这么写是有道理的这层上下文带着这个预设去审它审的其实已经不是代码本身了更像在替自己几分钟前下过的结论找证据。这事其实跟人一模一样。公司里 code review 为什么要拉别人来审而不是让作者自己审自己就是因为写的人对自己的代码有天然的信任感盯不到那些我以为没问题的地方。我自己改 AlgoMooc 那个算法网站时就栽过Claude 改完一段调度逻辑自测说通过我让它再 review 一遍它又确认边界没问题结果上线就因为一个没判的空数组白了屏。坑是它埋的审的时候它当成符合预期放了过去。更微妙的是自审还常常审出一种虚假的安全感。它会一本正经地给你列出三五条我检查了如下几点每一条听上去都挺像那么回事让你觉得这一关过得很扎实。但你仔细看就会发现它检查的全是它本来就写对了的地方真正容易出事的那一两处根本没在它的清单里。这种自审最坑因为它不是没审是审得特别认真地绕开了真正的雷区。我后来定了个习惯凡是它自己说已全面检查、可以合并我反而会多留个心眼因为越是这种笃定的措辞越说明它没换过看问题的角度。为什么自己审自己容易漏想清楚这一层那四个方案各自在补哪块短板就分得开了。新开会话解决的是上下文污染。一轮对话聊到后面上下文里塞满了之前的代码、之前的解释、之前那句已修复自测通过。这些东西会持续给模型一种心理暗示前面这套都是对的。新开一个会话等于把这些肯定性的记忆全部清空让它用一双没有先入之见的眼睛重新看这段代码。这一招对那些被自己之前的话术带偏的情况确实有用。但它的边界也很清楚你换了上下文没换底层那个模型更没换掉它训练里带的盲区。它依然是那个 Claude依然会在同一类问题上犯同一类错。所以新开会话适合小改动的复查、文案润色、简单 bug 的二次确认这种场景不适合高风险逻辑、架构级的改动、或者涉及权限和数据一致性的代码。新开会话是清上下文不是换裁判说白了新开会话是清缓存不是换裁判。裁判还是原来那个只是不让他翻旧账了而已。换 Skill解决的是审查视角。一个普通的 review模型大多只会看语法对不对、有没有明显的 bug扫一眼跑得通就说可以合并。但一个写得好的 review Skill会强制它按一张检查清单走这里有没有考虑空数组和空指针权限校验做了没有失败了能不能回滚测试覆盖到这个分支了吗性能上有没有隐患并发下数据还一致吗。同样一段代码普通 review 可能直接说没问题挂上带 checklist 的 Skill它至少会追问你这几刀。我自己有段合并两个数据源的代码让 Claude 裸审它说逻辑清晰可以合。换上一个带边界检查清单的 Skill 再审它立刻反过来问如果其中一个数据源返回空这里会不会直接抛异常写一半失败了前面那半要不要回滚这条新分支有对应的测试吗。问题一下就具体了。换 Skill 是换检查表不是换大脑换 Skill 换的是审题的方式换不掉它那颗脑子。清单能逼它去看那些它本来会跳过的地方可清单本身列不到的盲区它照样看不见。底层模型的能力上限和训练偏向一张 markdown 是改不动的。换模型解决的是同源盲区。这是上一篇的主角。我拉 Codex 来审 Claude 写的代码核心不在于 Codex 比 Claude 更聪明而在于它身上没有这是我写的那层包袱。它把 Claude 的代码当成一段陌生人交上来的东西该挑就挑。两个模型出自不同厂商、不同训练数据擅长的地方不一样盲区也不一样很多 Claude 顺手放过去的边界问题换 Codex 的视角一看就拎了出来。工程上很多问题靠的根本不是更强的模型换一个视角就能看见。异构交叉审查怎么跑起来举个具体的。有回 Claude 改完一段分页加载的逻辑自审说没问题Codex 接手一看就指出翻到最后一页、数据条数正好被每页数量整除的时候会多发一次请求去拉一页空数据。这种藏在整除边界里的小毛病写代码的那个最容易脑补成应该不会发生换个完全没参与过的模型来看反而一眼就盯上了。它不是更聪明只是站的位置不一样。代价当然也实打实。多养一个模型token 大概翻倍出结果更慢两边交接还得有个清晰的中间状态要么写个状态文件要么把上下文交代干净不然 Codex 接到一半不知道前因后果有时候两个模型意见还会打架比如 Codex 说这里该加锁、Claude 坚持当前并发量下没必要最后还是得你来拍板。所以换模型这一招是用异构的视角去对冲同源的盲区不是免费的银弹得用在值得的地方。再说评论区那句绕不开的话同一个模型开十个 Agent是不是伪协作。我的看法是多 Agent 从来不是数量问题。判断它真假就看三件事角色是不是真的不同上下文是不是真的隔离产物有没有可验证的交接。十个 Agent 用同一个模型、同一份上下文、奔着同一个目标只是名字从 agent-1 排到 agent-10那确实是伪多 Agent热闹而已。真正的多 Agent得有清晰的任务边界、各自独立的上下文、不一样的检查清单、明确的交接物最后还有一道统一的验收。拿我现在这套真实流程来说。Claude Code 负责写文章和排版Codex 负责出 SVG 配图、以及对代码做交叉 review两边各盯着一个共享的 status.json 接力Claude 写完状态自动流转给 CodexCodex 做完自己那摊再把产物交回来。每一步交出来的都是能验的东西文章是成稿配图是 PNGreview 是一条条具体的问题。最后还有一个 await_review 的状态卡在那儿由我这个活人做终审。这里面每一方职责都不一样产出都摆在明面上能对这才叫协作而不是多开一个 AI 显得高级。真多 Agent 和伪多 Agent差在哪还有两个常被混进这场争论的东西得单独拎出来Sub-Agent 和 Worktree。它们解决的是完全另一类问题。Sub-Agent 解决的是任务拆分和上下文隔离把一个大任务切成几块每块在自己干净的上下文里跑互不污染。Worktree 解决的是文件层面的隔离让一条改动在独立的工作区里进行搞砸了也不脏主线回滚干脆利落。这两个东西能让并行更安全但请注意它们并不天然让审查变得更准。一个 Sub-Agent 如果用的还是同一个模型、同一份 checklist它该漏的同类问题照样漏Worktree 再隔离里头跑的要是同一套自审照样审不出东西。它们的价值在于出错时不连累别人是隔离机制本身并不等于质量保证。把这四类东西分清之后怎么用就有谱了。我自己是按风险分档来定审查强度的。第一档小改动比如改个文案、调一个常量、动几行不影响主流程的代码。同会话里自查一下、看 diff、把测试跑一遍就行没必要折腾。第二档中等改动涉及一段业务逻辑的调整。这时候我会新开一个会话来 review挂上专用的 review Skill让它按清单走一遍。第三档关键逻辑比如核心链路上一段绕不开的处理。光换会话不够得 Claude 写、Codex 或另一个模型交叉审用异构视角兜一道。第四档高风险动钱、动权限、动数据一致性比如一段会往生产库里写数据的脚本。这种我会上 Worktree 隔离跑完整测试做交叉 review最后人工确认并且确保能回滚。第五档长任务、多阶段一件事要分好几步、跨好几个模型接力完成。这种就走 shared-pipeline 那套用 status.json 把每一步串起来每一步的产物都明确、可验、可交接谁也不靠记性接力。不同风险级别配不同审查流程这个分档我用下来最大的体会是绝大多数日常改动其实落在第一、二档真正需要交叉审和人工终审的是少数。把精力按风险分配比每段代码都上最重的流程要省得多也更可持续。我见过有人一上来就给所有改动都套交叉审跑两天就嫌烦放弃了最后又退回到全靠自审等于白折腾。审查强度这东西扛得住、能长期跑下去才是有用的。档位越高兜底越厚慢一点、贵一点都认了档位低还硬上重型流程那是给自己加戏。评论区还有人问了个很现实的问题万一哪天 Claude Code 被封了、用不了了怎么办。我的回答是这恰恰说明流程不能绑死在某一个工具上。Claude Code 不可用的时候我能切到 Codex切到普通的 Claude 网页版实在不行手动跑脚本、对着本地那张检查清单一条条过。真正稳定的从来不是某个工具而是这条流程本身输入是什么每一步交出什么产物拿什么验收出事了怎么回滚。这几个问题想清楚了工具只是其中一个可替换的执行件。这个话题能单独写一篇下次细聊。这套东西用得越久我越确信一件事AI 编程真正进入工程阶段之后开发者之间的差距不在谁开了几个 Agent、谁的提示词更花哨而在谁能把写、审、测、回滚这几个动作拆得足够清楚再让合适的机制各管一段。新开会话是清上下文换 Skill 是换检查表换模型是换视角Worktree 是换隔离层。把这些混在一起才会越用越乱把它们放到各自该在的位置AI 才真的像一个能协作的工程队友。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
