技术负责人的 AI 对话历史如果是空的
所谓「AI exhaust」（AI 排气/副产物），不是指跑多少 token，而是你留下的上下文工程痕迹：那些失败的 Prompt、被修正的 hallucination、迭代三轮才跑通的重构脚本、甚至是你在 .cursorrules 里写的项目级约束。这些东西才是团队真正的「资产库」，文档永远滞后于对话历史。
一、Leader 不亲自「踩雷」，规范全是空中楼阁
上个月让组里试着用 Agent 模式重构一个老旧的 Python 数据管道。我自己先上手跑了两天，发现 Claude Code 在处理动态导入和隐式依赖时幻觉率高得离谱，必须把 import 关系图喂给它才稳。这结论如果不亲自跑、不看它吐出的错误堆栈、不调整三次 system prompt，光靠读博客根本得不出来。最后我把那套「喂依赖图 -> 让它生成测试 -> 再让它重构」的工作流扔进团队共享的 prompts/ 目录，新人照着跑，半天搞定。Leader 不产出这种「带血的教训」，团队只能自己再踩一遍坑。
二、权限结构靠「示范」不是靠「文档」
很多团队搞个《AI 编码规范》，里面写「禁止提交 AI 生成的未审查代码」「必须写单测」。问题是新人根本不知道「审查」的标准是什么，标准藏在 Leader 的对话记录里。
我现在习惯在 PR 里直接贴一段对话截图：看这里，模型第一版漏了边界条件，我追问了两轮才补全，你们审代码时重点盯这块。这比写十页 Wiki 管用得多。你的 AI exhaust 里包含的「追问逻辑」「纠偏节奏」「拒绝生成的时机」，就是最活的规范。
三、上下文管理能力，练出来全靠「量」
Context window 变长了，但有效上下文管理反而更难。什么时候用 @file，什么时候用 @codebase，什么时候该新开一个 chat 别污染上下文，这全是手感。Leader 如果自己天天只问简单的「帮我写个正则」，永远体会不到 200k context 里检索失焦的痛苦，也就做不出「拆任务、喂精准上下文、限定输出格式」这种架构级决策。
我现在的经验法则：单次任务超过 3 轮对话没解决，必须强制清理上下文重来，这规则是我自己把一个 1500 行的重构任务聊崩了三次总结出来的。
四、别让「AI exhaust」变成「数据垃圾」
有个前提：这些对话
