把 Claude 用成团队操作系统
—— Austin 的使用经验汇报

1一个业务 = 一个自包含工作区，标配「四件套」

为什么：Claude 每次开新会话都是「失忆」的，工作区就是它的外置大脑。

每条业务线一个独立文件夹，里面固定四样东西，新业务直接照抄这个骨架：

会话组织上是「一个长期主会话 + 若干卫星会话」：主会话当项目总控台（最长一场从 6 月初跑了一个多月），测试、单项交付、单个客户的活拆到卫星会话去干，互不污染上下文。

CLAUDE.md 开头固定写死启动流程：①读 CLAUDE.md ②读 PROGRESS.md ③查 git log ④有不一致先问人。这样任何一个新会话都能自己「接上班」。

2先立规则、再给任务；先框架、再动手

为什么：Claude 的执行质量，一半取决于你开工前把「游戏规则」讲得多清楚。

开新方向时，第一条消息不是任务，是「本次会话基本规则」：

而且把「双向澄清」也定成了规则——不是我单方面下命令，是让 Claude 先提问、我补信息、它再开工：

大工程一律「先框架后动手」：先要一张框架图 / 插件清单，我审完说「可以，没有问题」「全采纳」，才允许动手搭。口语化中文完全没问题（我大量任务是语音说出来的），关键是结构：编号列表、分阶段、附上背景材料（PDF / 竞品链接 / 团队自己的分析）。

3纠偏不只改这一次——每次都升级成「长期规则」

为什么：只改眼前这个错，下周它还会犯；把错误变成规则，才是真正在「训练」你的 Claude。

这是我最核心的习惯。发现问题时的固定句式是「把这个规则记录下来 / 当成一个长期的规则和记忆」：

出错时还有一个「归因追问」的动作——先搞清楚是执行失误还是规则本身没写，再决定修哪一层：

沉淀下来的规则存在个人记忆库里，目前 42 条，每条都是标准结构：规则是什么 → 为什么（附当时的实际案例）→ 怎么执行 → 有什么例外。规则之间还互相引用，形成一张会生长的规则网。比如现在生效的几条硬规则：所有产出必须 HTML、生成后自动打开浏览器、默认部署公网链接、不留 v1/v2 版本号后缀、日常回答用中文讲人话。

4反馈飞轮制度化：从「个人教 AI」升级成「团队养 AI」

为什么：习惯 3 只能优化我自己的 Claude。团队每个人踩的坑，应该让所有人的 Claude 一起变聪明。

三套业务体系都实现了同一个「反馈飞轮」，这是整个系统里设计最精密的部分：

配了三重护栏，防止飞轮转飞：

• 上报 ≠ 改规则：成员的反馈只进意见箱，绝不当场改团队规则；
• 门槛：同类问题复现 ≥ 2 次才够格上周审，防止个案污染规则；
• 铁律哨兵 + 可回滚：核心红线段落设了「永不因提案而改」的哨兵标记，每次落地必看真实改动对比、打 git 标签，随时一键回滚。

每张经验卡强制回答「三问追因」（表面现象是什么 → 直接原因是什么 → 根本原因是什么），确保修的是根子不是症状。

5插件五层流水线范式：一套骨架，三次复制，越抄越好

为什么：把工作流封装成插件，团队装插件 = 装下整套业务能力，新人零配置上岗。

所有业务插件都是同一个分层骨架，按业务替换中间层：

这套骨架经历了三次复制，每次都在改进——这才是重点：

分发走私有 git 仓当插件市场，团队一键安装、自动更新；数据服务打包成自包含文件随插件下发，团队机器零依赖。

6交付标准化：一切产出 = 精致 HTML + 公网链接

为什么：交付物的终点是「别人能直接用」。聊天记录里的一段字没法转发，一个链接可以。

• 硬规则：任何任务的最终产出不能只是聊天里的文字，必须生成 HTML 报告——自动打开浏览器 + 给出可分享的公网链接，不用每次问；
• 设计标准：给团队/对外看的长文档要做成精致独立页面（彩色卡片、可视化、跳转目录、FAQ 折叠、深浅色和手机适配），你现在看的这份就是按这个标准出的；
• 分级：非机密走公开管线；敏感物料单开项目——链接带随机后缀（像房卡号，防猜）、全站禁止搜索引擎收录、默认 7 天自动失效可续期；最敏感的经营数据（订单/成本/客户）强制只存本机，绝不上公网；
• 版本卫生：同一份报告迭代时同链接覆盖，不开 v2 新页面；文件名不带版本号后缀。

7工程纪律四件套：攒批修、写交接、分会话、真机测

为什么：这四个习惯全是从返工的坑里长出来的（对应坑 3、坑 4），是「慢就是快」的具体做法。

• Debug 清单攒着统一修，不现场改。跑全流程时遇到技能问题，先记进清单（现象/根因/修复方向三段式 + 优先级），跑完再开专门会话一次性修。原话：「这是我在另一个 session 测试遇到的问题，你先记录一下，不急着改。」——因为边跑边改会打断流程，还会让一处改动影响下一环节的输入。例外：真正卡死后续测试的阻塞级 bug 当场修；
• 跨会话交接靠「交接文档」，让 Claude 自己写。测试会话只测不改，发现的问题让 Claude 整理成结构化话术，发给专门的修改会话。每条固定五段：现象 / 根因 / 怎么改 / 落点文件 / 验收标准。文档开头先列「已修复勿重复改」防返工；
• 会话角色分工：主会话总控、测试会话找茬、修改会话动手、交付会话出活——各司其职，上下文互不污染；
• 真机端到端测试：通过静态检查 ≠ 真的能跑（坑 3 的教训）。每个技能都要在真实环境完整跑一遍，把工具的真实能力（哪个平台能抓、限多少条、哪个接口废弃了）记录在案、定期复测。信得过流程之后，还可以「过夜自主跑」——原话：「我先去睡觉了哈，你自己把剩下任务跑完，我起来验收。」

心法把它当「聪明但今天刚入职的下属」，不是搜索框

为什么：所有提问技巧，本质上都是这一个心态的推论。

你不会对一个刚入职的下属说「帮我弄一下那个东西」——他再聪明也不知道「那个东西」是什么、给谁看、做到什么程度算好。Claude 一样。它每次开工时不知道三件事，这三件事只有你能告诉它：

• 你的背景：这个任务为什么存在、在整个业务里处于哪一环；
• 你的标准：什么样算好、什么样算不合格；
• 你没说出口的偏好：语言、格式、密级、忌讳——你不说，它只能猜，猜错了你还得返工。

1派活六要素：背景、目标、材料、规则、格式、验收

为什么：这是把 102,884 条对话里「一次就拿到好结果」的任务拆出来后，发现的共同结构。

布置一个正式任务时，对照这六项过一遍。不用每次全写满，但缺哪项，Claude 就会在哪项上猜：

直接抄的模板（复制后替换【】里的内容）：

2三个开工动作：立规则 → 授权提问 → 先框架后动手

为什么：这三个动作是 Austin 每个大任务的固定开场，成本不到两分钟，省掉的返工按小时计。

动作一：任务之前，先立规则。新方向的第一条消息不是任务本身，是这次合作的游戏规则（输出语言、格式要求、什么情况要停下来问人），并让它复述确认。

动作二：明确授权它提问。这是最简单、被低估最狠的一招——很多人从头到尾单向下命令，Claude 只好把不确定的地方全靠猜。加一句授权，它就会把坑在开工前问出来：

动作三：大活先要框架，确认了再动手。直接让它跑一个大任务，方向错了就是整体返工；先要框架，错了只废一张草图：

3差话术 vs 好话术：同一个任务的两种命运

为什么：抽象道理记不住，对照着改最快。三组都是团队日常真实场景。

4收活三招：自查、归因、立规则

为什么：布置得好只是一半，收活收得好，Claude 会一次比一次好用；收得不好，同一个错它跟你耗一年。

第一招：让它自查，别急着自己挑错。它自己往往能找出来，你还省了打字：

第二招：归因追问——搞清「是忘了，还是没规则」。这是整个收活环节最值钱的一问。执行失误让它复述规则就行；规则缺失就补规则。修错了层，问题必复发：

第三招：值得长期生效的要求，当场升级成规则。说「把这个记成长期规则：以后都要……」，并让它复述以后会怎么做。个案纠偏只保这一次，规则纠偏保以后每一次（用团队插件的同事：这类反馈直接说出来，AI 会自动上报意见箱）。

5六个最常见的误区（对号入座）

为什么：以下每一条，都是从返工最多的那批对话里总结出来的反面模式。

• 一句话甩任务：「帮我弄个方案」——它不知道的部分全靠编，编完你再骂它编。先过一遍六要素；
• 十个要求一口气塞：大任务不分阶段，跑到一半发现方向错，全部重来。先框架后动手，一次推进一个阶段；
• 不给材料让它硬写：手里明明有 PDF / 上一版文件 / 聊天记录，却让它凭空写。它没有的信息只能编，丢材料永远比描述材料强；
• 只说「不好」不说哪不好：等于让它抽奖式重写，越改越乱。指位置、给参照、圈范围；
• 在跑歪的对话里硬拗：改了五六轮越来越糊的时候，别继续拗——让它总结「这次任务的完整要求和已确认的结论」，拿着这段话开个新会话，一次到位；
• 从不让它提问：全程单向命令，理解偏差只能在成品里暴露。开工前加一句「有不清楚的先问我」，成本为零。

甲旧判断会过期——一切结论都是「时间点观察」

「这个平台完全抓不了」后来被新工具打通了；「这个判定短语可靠」后来因平台改版失效了;「密钥是安全的」在推上 git 那刻就不成立了。工具能力、平台行为、安全状态，全都在漂移。

做法：重要结论记下来时注明日期和失效条件；隔段时间复测；引用旧结论前先验证它还成不成立。

乙不要让 AI 自作主张——不确定时「展示」而不是「判定」

验证器自创检测 → 假阳性；给外国专家音译中文名 → 引入错误信息。模式是一样的：AI 在规范之外「好心」加了逻辑，结果引入了比没有更糟的错误。

做法：给 Claude 的规范里明确写「严格按此执行，不自创判定」；要求它把拿不准的东西作为信息展示出来让人判断，而不是替人下结论。

丙慢就是快——修改要成批、要留痕、要能回滚

攒批统一修、五段式交接文档、改版必升版本号、每次烘焙打 git 标签。这套纪律看起来慢，但它是四轮返工喂出来的结论：散弹式的即兴修改，最后总要用十倍时间还债。

做法：改团队共用的东西，永远走「记录 → 评审 → 成批落地 → 存证可回滚」四步，一步都别省。

• 给你的业务建一个专属工作区文件夹，第一件事写 CLAUDE.md（你是谁、这个项目是什么、有什么规矩），第二件事写 PROGRESS.md。以后所有相关会话都在这个目录里开。
• 开工前先立规则：把你的输出偏好（语言、格式、密级）一次性告诉 Claude 并让它记住；给复杂任务时要求它「先提问澄清、先出框架，我确认后再动手」。
• 学会「规则级反馈」句式：发现问题别只说「改一下」，说「把这个记成长期规则：以后都要……」，并让它复述。
• 用团队插件的，先跑 foundation 的一键配置和健康自检；遇到「以后都该改」的问题直接说，AI 会自动上报意见箱，别自己改技能文件。
• 产出要求 HTML + 可分享链接，同时问自己一句：这份东西的密级对吗？敏感数据（客户/成本/凭证）绝不进公网链接。
• 凭证红线背下来：任何密钥不进聊天记录、不进配置文件明文、不进 git。让 Claude 处理凭证时，只给环境变量名，不给值。