如果AI编程助手总给你半成品代码，那这套工作流能救你狗命！
用Claude Code开发常因上下文超载导致代码幻觉，开发者通过严格拆分单任务单会话、引入裁判大脑角色和执行强制审计流程，总结出一套降低Bug率的硬核工作流，核心是用流程对抗AI的偷懒本能。
单任务单会话不是玄学，是活命底线
打开Claude Code准备开始写新功能。输入提示词，几秒钟后代码生成。复制粘贴进项目。运行。报错。回去找Claude。它说刚才忘了包含依赖。修正。再运行。新报错。来回折腾四五轮之后，整个会话窗口长到需要手指在触控板上滑三下才能到底。
这时候会发现一个规律。越往后，Claude给的代码越奇怪。有时候是函数名凭空捏造。有时候是引用了项目里根本不存在的库。还有更离谱的，它会把上一轮修正过的内容再次弄错，仿佛失忆了一样。这不是错觉。上下文窗口快爆了。
把同一个项目拆成两个方案对比着做实验。方案A，一个长会话干到底，中间全靠自动压缩历史记录。方案B，每个小功能开一个新会话，一个会话只干一件事。结果很说明问题。方案A到第四个小时开始出现幻觉代码，方案B全程没有一次无中生有。
自动压缩就是障眼法。把早期对话内容揉成一团塞进角落，表面看窗口空间腾出来了，但模型真正依赖的注意力机制早就在那堆压缩数据里迷了路。就像一个学生考试前把课本压缩成十张便利贴，真到答题时根本找不到公式在哪页。
单任务单会话的硬规矩定下来之后，每个会话的生命周期变得很短。进去，说清楚要什么，拿到代码，验证，关闭。干净利落。没有历史包袱就没有幻觉土壤。
脑力工作者必须分角色，否则全乱套
写代码有两种完全不同的认知负荷。一种是全局俯瞰，得知道整个系统长什么样，各个模块怎么搭在一起，接下来要走哪条路。另一种是埋头干活，盯着眼前那个函数，把那几十行代码写对写稳。这两种状态在人类脑子里切换都很费劲，何况是AI。
所以搞了个双角色架构。一个大脑聊天窗，专门负责想。其他的工作聊天窗，专门负责干。大脑窗接入项目根目录，读取Claude.md和Rules.md两份文件。那两份文件里写清楚了项目的技术栈、目录结构、编码规范、测试要求。大脑窗不用写具体代码，它的产出物是任务说明书。
工作窗怎么启动。创建一个新的聊天窗，输入wait for task，然后放在那里不动。大脑窗分析完当前需求，会用指令把具体任务写进对应的工作窗。比如需要写一个登录接口，大脑窗会描述清楚接口路径、请求参数、返回格式、需要引用的中间件，然后把这段描述塞给工作窗。工作窗醒来，读完指令，开始写代码。
这样拆开之后，每个工作窗的上下文极其干净。里面只有当前这个任务的描述，外加项目的基础规则文件。没有其他模块的讨论，没有历史报错信息，没有之前推翻的方案。干净上下文意味着模型可以集中全部注意力在当前这个小范围问题上。
大脑窗也不用忍受漫长的代码生成过程。它发出任务就完了，转身去处理架构设计或者审核其他工作窗的产出。两个角色各司其职，整个开发节奏快了一截。
忘记是AI的天赋，文档是人类的盔甲
跟Claude说帮我记住这个配置路径。它点头答应。过了二十分钟，在另一个任务里问它配置在哪。它开始瞎编路径。这种事情反复发生之后，才反应过来一个问题。AI没有长期记忆这回事。每个会话的上下文就是它的全部世界，压缩丢掉的、遗忘抹去的，那就是真的没了。
解决的笨办法但极其有效。所有需要记住的东西，必须落盘成文件。告诉Claude把这个配置信息写入docs目录下的某个指定文件，然后把文件绝对路径返回。这样每次问它，它可以直接打开文件读内容。文件系统不会压缩历史，不会偷懒，不会记错。
规则文件本身也是同样的道理。Claude.md和Rules.md不是写一次就扔在那里的摆设。每次启动大脑窗之前，扫一眼这两份文件，该更新的更新，该补充的补充。规则文件写得越细，Claude越不容易跑偏。比如明确写了所有API响应必须包含requestId字段，它就真的每次都会加上。如果不写进文件，它想起来就加，想不起来就省略。
还有一种情况更隐蔽。Claude说自己做过了全面检查，所有测试通过。结果一运行，某个边缘case直接崩了。后来加了一条硬规矩，做完功能必须执行全链路冒烟测试，从用户发起请求到数据库落地的完整流程走一遍，而且这个过程要形成固定规则，每次强制触发。有了这条规矩，漏测的问题减少了很多。
别跟AI辩论，用新聊天窗当外脑
碰到一种很耗神的场景。Claude在某个任务里死活绕不开一个错误方向，给的建议越来越离谱。在同一个窗口里跟它讲道理，解释为什么那条路走不通，它换了个姿势继续错。再解释，再换姿势。几个来回下来，窗口里塞满了争辩内容，真正的代码产出几乎为零。
这其实就是陷入了局部最优陷阱。模型在当前上下文的重力场里被带偏了，靠内部修正很难扳回来。与其在泥潭里跟它摔跤，不如开一个全新的聊天窗，跟项目毫无关联的那种。在新窗里把情况描述一遍，说工作窗正在做什么事，具体哪个地方让人不满意。新窗没有历史包袱，能给出一个相对客观的判断。
更妙的是，可以让新窗帮忙写一段提示词。这段提示词专门用来纠正工作窗的错误方向，措辞精确、逻辑清晰。然后把这段提示词复制进工作窗。工作窗读到新指令后，往往能跳出之前的死循环。相当于请了一个临时顾问，解决了问题又不污染主工作区的上下文。
审计不是可选项，是刹车片
Claude有个根深蒂固的毛病。它倾向于快速给出一个看似合理的答案，而不是花更多时间去验证这个答案的真伪。这就导致生成的代码里隐藏着大量似是而非的逻辑。变量名对得上，结构看起来也对，但一跑就出问题。
解决这个问题的核心思路是强制它做测量和审计，而不是靠记忆或猜测。对一个功能做完之后，必须让工作窗自己重新读一遍刚改过的文件，列出所有变更点。然后对照任务要求逐条检查是否满足。再跑一遍测试用例。最后做一次从入口到出口的完整流程验证。
这一套流程如果让Claude自己决定做不做，它大概率说不做或者做得很敷衍。所以把它写成了铁律。每次交付代码之前，必须走完审计步骤，并且把审计结果附在回复里。这样一来，它没法偷懒说都检查过了，因为审计结果是实打实列在那里的。
有一种情况特别典型。开发一个新接口，Claude写完了，审计阶段让它列出所有可能出错的地方。它会列出来，比如数据库连接可能超时、参数校验可能遗漏某种格式、缓存穿透可能导致压力过大。然后针对每一条补上相应的处理逻辑。没有审计步骤的话，这些潜在问题就跟着代码一起上线了。
工作树的妙用，并行不打架
项目开发很少是一条直线走到底。经常是这个功能写到一半，突然发现另一个模块有个紧急Bug要修。如果用同一个分支来回切换，脑子容易乱，Git操作也容易出错。
Git工作树解决了这个问题。每个新功能或者每个Bug修复，都开一个独立的工作树目录。这些目录共享同一个版本历史，但各自的代码状态完全隔离。大脑窗可以在不同工作树之间穿梭，发任务给不同的工作窗。
一个典型的并行场景。工作树A在开发用户认证模块，工作树B在修复支付回调的Bug，工作树C在实验性地重构数据库查询层。三个工作窗各自接到对应的工作树任务，互不干扰。等各自完成之后，再通过版本控制把稳定的代码合并回主线。
这种并行能力配合单任务单会话的原则，把整体开发节奏拉高了一个档次。任何时候都不会因为等待某个会话完成而卡住。大脑窗在调度，各个工作窗在执行，审计窗在验收。各司其职，像一条流水线。
最后还有一个关于模型选择的策略。大脑窗对推理能力的要求更高，所以用Opus模型跑。工作窗只需要忠实地按照技术简报写代码，Sonnet模型足够应付，而且上下文消耗更低。大脑窗在发出任务时，必须明确标注工作窗应该使用哪个模型，并且持续监督它是否遵守了这条指令。
三个月前刚开始用Claude Code的时候，经常被气得摔键盘。现在回头看，大部分问题都出在流程上，而不是工具本身。AI就是个极度聪明但又极度懒惰的实习生。不把规矩定死，不给审计流程卡死，它就总能找到最省力的方式糊弄过去。而开发者的价值，恰好就是把这套流程建起来，然后让AI在轨道里跑出该有的速度。
AI编程助手的真相是，它不会替你思考架构，但它能把你想清楚的事执行得飞快。如果连想都没想清楚就直接丢给AI，那被气出病来也别怪它。