Anthropic 官方内部手册 · 2025.07.24 · 23 页
Claude Code 内部实践：
10 个团队怎么用 AI 干活
Anthropic 采访了自己 10 个团队，把「Claude Code 到底怎么用」写成了一份 23 页的内部实践文档。这一页是它的中文精读版：10 个团队的一手用法 + 10 条可复用方法论 + 3 个能直接套用到你工作里的步骤 + 全部关键数字与坑。
2–4×
数据科学团队：常规重构与重复任务的省时倍数
80%
推理团队：ML 概念调研时间从 1 小时降到 10–20 分钟
70%
产品团队：Vim 模式最终实现中由 Claude 自主完成的比例
1/3
RL 团队：一句 prompt 就首次成功的真实概率（所以要留后手）
01
30 秒速览
如果只记一句话，记这个。
一句话总纲
AI 编程工具真正在做的，不是把写代码变快，而是把「技术 / 非技术」的界线抹掉——能描述清楚问题的人，就能做出解决方案；而能不能做出来，取决于你给的上下文有多厚、你放权的边界有多清。
这不是一份「工具教程」
全文没有讲一个功能键怎么按。10 个团队讲的都是同一件事：把一件重复的、有明确产出的事情，写成 AI 能执行的流程。所以它更像一份工作方式样本集，你换成任何 Agent 工具都成立。
最反直觉的一点
文档里最抢眼的案例全来自非工程团队：法务 1 小时给家人做出无障碍沟通 App，营销一个人生成数百条广告变体，设计师直接改状态管理代码。技术背景不是前提，会拆解问题才是。
读这份材料，你要带走的四样东西
① 一套判断标准 放多少权
哪些任务可以让 AI 自己跑 30 分钟，哪些必须你盯着看每一步——文档给了可操作的分界线。
② 一套准备工作 上下文
开始之前要写什么：项目说明文件、纯文本流程、成功样例。写得好不好，直接决定产出质量。
③ 一套收尾动作 沉淀
跑完之后做什么：回滚检查、把经验写回说明文件、把一次性脚本升级成长期工具。
④ 一个心理准备 失败率
一次成功率大约 1/3。所以流程里必须内置「回滚」和「重开」，而不是硬修。
02
底层逻辑：为什么非技术团队也能用起来
10 个团队的做法五花八门，但底层是同一套 5 条。
1 · 上下文工程 > 提示词技巧
文档反复出现同一个判断：你把工作流、工具、期望写得越清楚，AI 表现越好。数据基础设施团队靠一份详细的 CLAUDE.md，让 AI 在「照既有模式建新数据管道」这类例行任务上近乎稳过。提示词是战术，文档是地基。
2 · 先判断「要不要盯」
产品团队明确把任务分两类：边缘功能、原型 → 异步放权（auto-accept 模式，人走开）；核心业务逻辑、关键修复 → 同步协作，逐句给实现指令并实时看。放权程度是能决策的，不是全有或全无。
3 · 可回滚，才敢放权
所有敢让 AI 自主跑 30 分钟的团队，前提都一样：干净的 git 状态 + 频繁 commit 检查点。数据科学团队把这叫「老虎机模式」——存档、让它跑、接受或重开，而不是在错误的基础上硬改。
4 · 把一次性做成常驻
同样的工具，用法差一个量级：用 Jupyter 跑完就扔，还是让 AI 建一个可复用的 React 看板？安全团队把常用流程做成自定义斜杠命令（占全公司 monorepo 的 50%），营销团队把重复流程拆成专职子代理。一次性是省钱，常驻是攒资产。
5 · 让 AI 自己验收
「自足循环」是出现频率最高的技巧：让 AI 自己跑构建、跑测试、跑 lint，用结果修正自己。产品团队甚至要求先让 AI 写测试，再写实现——这样它有客观的成功标准，而不是等你来夸。
6 · 知识从人脑搬进仓库
文档、runbook、规格说明、会话总结，都被要求落成文件。推理团队用它补 ML 背景（调研时间 −80%），安全团队拿多份文档合成排障手册，法务把「找谁」做成原型工具。组织的隐性知识，被 AI 逼成了显性文本。
03
10 条通用方法论
从 10 个团队的 30+ 条 tips 里合并去重，只留有证据支撑的。
- 先写项目说明文件（CLAUDE.md）把目录结构、常用命令、代码风格、禁止事项、踩过的坑写进去，让它每次开局就带着记忆。证据：数据基础设施团队「写得越细，表现越好」；RL 团队用它写死常见错误（「用 pytest 跑，别用 run，别乱 cd」）后一致性明显提升。
- 建立自足循环，让 AI 自己验收把构建 / 测试 / lint 命令交给它自己跑，失败就读报错继续改，直到通过。证据：Claude Code 团队，配合「先写测试后写实现」效果最好。
- 任务分级：异步放权 vs 同步盯边缘功能、原型、探索 → 开 auto-accept 走开；核心逻辑、线上事故 → 逐条 prompt、实时监督。证据：Claude Code 团队「任务分类直觉」；RL 团队的中型功能是「监督式自主」。
- 干净起点 + 频繁存档开跑前确认 git 状态干净，每完成一步 commit 一次；出问题直接回滚，别抢救。证据：多个团队强调 checkpoint；数据科学团队直接叫它「老虎机」。
- 一次只做一步，别要 one-shot把大任务拆成可逐步验证的小步，让它「慢下来」一步一步做，你随时可以插手。证据：法务团队（「请它放慢，一步一步实现」）；增长营销（拆成标题子代理 + 描述子代理）。
- 先规划，再编码在对话式界面里把思路聊透，让它输出一份分步实施 prompt 和代码结构，再进工具执行。证据：法务「Claude.ai 里规划，Claude Code 里落地」；营销团队同样先头脑风暴再动手。
- 能贴图就别描述截图 / 设计稿 / 仪表盘 / 报错界面直接粘进去，比写三段文字更准。证据：产品设计用 Mock 图生成可交互原型；数据基础设施靠仪表盘截图定位 K8s 故障。
- 拆专职子代理与自定义命令一个任务一个角色（标题、描述、审查……），链路清晰、好调试；高频流程固化成斜杠命令。证据：增长营销两个子代理几分钟生成数百条广告；安全团队用了全公司一半的自定义命令。
- 让它先讲，再从最小信息起步别一口气把所有背景倒给它。先给最少信息，让它复述任务、提出缺什么，你来补。证据：API 团队「从最小信息开始」；安全团队「让 Claude 先说话」+ 边做边 commit。
- 收尾沉淀：让经验回流文档每次会话末尾让它总结做了什么、哪里走了弯路、下次该提前给什么，然后更新说明文件。证据：数据基础设施团队每轮结束都更新 CLAUDE.md，形成持续改进循环。
一条隐含原则
不要「教 AI 怎么写代码」，要「设计一个它自己能验证成功的环境」。所有 2 倍、4 倍、10 倍的案例，赢在环境设计，不在提示词修辞。
04
套用到你的工作：3 个步骤
挑一件你每周都要重复做、且有明确产出的事，按这三步跑一轮。每步都给了可直接复制的提示词。
1
建上下文：把「你脑子里的流程」变成文件
目标：让 AI 在不问你的情况下，能说清这件事该怎么做。
- 选 一件高频重复任务（例：周报汇总、竞品信息整理、活动复盘数据、合同条款比对），只选一件。
- 用纯文本写清 输入 → 步骤 → 输出：数据从哪来、中间几步、最后交付什么格式（Excel / 文档 / 网页）。
- 建一个项目说明文件（CLAUDE.md 或 AGENTS.md），写四块：目标与背景、关键文件与目录、常用命令/流程、禁止事项。
- 准备 一个成功样例（上次做得好的产出），比任何形容词都管用。
先不要动手，只做三件事： 1. 通读我在项目说明文件里写的「目标/文件/流程/禁止事项」； 2. 用 5 条话复述你理解的任务边界； 3. 指出还缺哪些信息，以及你会先看哪些文件。 我的任务：______（一句话） 交付物：______（文件/格式/给谁看） 成功标准：______（做到什么程度算对） 说明文件位置：______
完成标准它能用自己的话把流程讲对，并只问 3 个以内、且是真正缺失的问题。如果它开始瞎猜细节，说明说明文件写得不够具体。
2
放权一轮：给边界，不给步骤
目标：你离开 30 分钟，回来看到一份 80% 可用的结果。
- 先存档：git commit 或复制一份备份，确保能一键回到起跑线。
- 给 明确目标 + 明确边界：允许改哪些文件、不许碰哪些部分、必须跑哪些校验。
- 开 auto-accept（自动接受）模式，然后真的走开；只在它明显跑偏时才打断。
- 时间盒 30 分钟：时间到就验收，不要追加"再改改"。
目标：______（一句话，说结果不说步骤） 可以改：______（目录/文件） 不要动：______（核心逻辑/配置/线上文件） 完成标准： - 命令 `______` 全部通过（测试/构建/校验） - 产出 ______（路径 + 格式） - 不留临时文件和调试输出 执行方式： 1. 先给 3 行计划，然后直接执行，不用等我确认； 2. 每完成一个可验证的小步，commit 一次； 3. 遇到不确定，选最简单方案，并在最后列出你的假设； 4. 自查失败就自己改，直到满足上述标准。
完成标准回来时：校验命令是它自己跑过并通过的，改动范围没有越界，你能用一分钟看懂它改了什么。达不到就进第 3 步，别在这里硬修。
3
验收与沉淀：让它变成下次的资产
目标：这次花 30 分钟，下次花 10 分钟，第三个月变成一键。
- 看 diff 而不是只看结论：重点看有没有悄悄改到不该改的地方。
- 三次修不好就回滚重开——文档里的经验是「重开的成功率高于硬修」。
- 让它把这次踩的坑写回说明文件（只输出要新增/修改的条目，别重写全文）。
- 评估这个流程是否值得固化：做成斜杠命令 / 模板 / 子代理，或者干脆砍掉。
会话收尾，请依次完成： 1. 总结这次做了什么（≤10 行）； 2. 指出哪些步骤走了弯路、原因是什么； 3. 列出下次同类任务「应提前提供」的 3 条信息； 4. 更新项目说明文件的对应章节：只输出「要新增/修改的条目」， 不要重写整个文件； 5. 判断这个流程是否值得固化成一个可复用命令，给出建议。
完成标准说明文件里至少多了 1 条可复用的规则；同类任务第二次跑时，你给的信息量明显变少、迭代轮次明显变短。
什么任务适合走这套流程 / 什么不适合
| 适合（放权收益高） | 不适合（收益低或风险高） |
|---|---|
| 有明确产出格式的重复任务（报表、文案变体、文档整理） | 目标本身还没想清楚、需要来回讨论的探索 |
| 边缘功能、内部工具、原型、演示用 demo | 核心业务逻辑、计费、权限、线上热修 |
| 陌生代码库 / 陌生领域的「先搞懂」阶段 | 涉及敏感数据且没有沙箱与审计的环境 |
| 有客观验收标准的任务（能跑测试、能比对数字） | 验收只能靠人「感觉对」的任务 |
05
十个团队速查
点开看你最像哪个团队。每个卡片 = 他们怎么用 · 拿到什么结果 · 一句最狠的建议。
01数据基础设施Data Infrastructure把全公司的数据整理成可自助使用的流程▶
主要用例
- 截图排障 K8s：集群不调度新 Pod，把仪表盘截图喂进去，它逐级指路 Google Cloud 控制台，定位到 Pod IP 地址耗尽，并给出创建新 IP 池、加入集群的确切命令。
- 让财务自助跑数据：教财务同事写纯文本流程（「查这个看板 → 取数 → 跑这些查询 → 出 Excel」），加载进 Claude Code 自动执行，连「要哪一天的数据」这种输入也会主动问。
- 新人导航代码库：新数据科学家入职直接用它读 CLAUDE.md、定位文件、解释数据管道依赖和上游数据源，替代传统数据目录工具。
- 会话末尾更新文档：每次任务结束让它总结并改进 CLAUDE.md，形成持续改进循环。
- 多实例并行：不同仓库开多个实例跑长任务，各自保留完整上下文，几天后回来还能接着干。
拿到什么结果
不请专家也能修基础设施；新人上手更快；能盯 200 个看板找异常；财务零代码自助。
最狠的三条建议
- CLAUDE.md 写得越细，例行任务越稳。
- 敏感数据别用 CLI 直连，走 MCP 做权限与日志控制。
- 团队互相演示各自用法——很多技巧是自己想不到的。
02产品开发Claude Code team用自家产品开发自家产品▶
主要用例
- auto-accept + 自主循环做原型：shift+tab 开启，让 Claude 写码、跑测试、自我迭代；先拿到 80% 的版本，再接手做最后打磨。
- 核心功能同步协作：涉及业务逻辑的改动，给极其具体的实现指令并实时盯代码质量、风格、架构。
- Vim 模式：最难的一次异步项目，最终实现约 70% 由 Claude 自主完成，只迭代了几轮。
- 测试与 PR 修复：功能写完后让它补测试；用 GitHub Actions 让它自动处理 PR 评论（格式化、函数重命名）。
- 陌生代码库探索：不再等 Slack 回复，直接问它要解释和代码位置。
拿到什么结果
复杂功能 70% 自主完成；原型迭代速度提升；测试覆盖和例行修复自动化；monorepo 理解成本大降。
最狠的三条建议
- 造自足循环：让它自己跑构建、测试、lint。
- 培养任务分类直觉：边缘异步、核心同步。
- 组件同名同功能时，prompt 必须精确到文件与函数。
03安全工程Security Engineering管软件生命周期、供应链与开发环境安全▶
主要用例
- 事故排查：把 stack trace 和文档喂进去，让它沿代码库追控制流；原来人工扫 10–15 分钟的问题，约 5 分钟定位。
- Terraform 变更审查：把 plan 贴进去问「这会发生什么？我会不会后悔？」把安全审批的反馈环路压短。
- 文档合成：把多份文档变成 markdown 排障手册 / runbook，再拿这些浓缩件去 debug 真实问题。
- TDD 工作流：从「设计文档 → 烂代码 → 重构 → 放弃测试」改成先要伪代码、引导测试驱动、卡住时再介入。
- 跨项目贡献：给已有项目写 / 审 / 执行 markdown 规格说明，几天就能有效贡献（原来要几周）。
拿到什么结果
事故排查约 3 倍提速；安全审批不再堵开发；跨职能贡献以天计；排障手册更好用。
最狠的三条建议
- 大量使用自定义斜杠命令（他们一家占全 monorepo 的 50%）。
- 让 Claude 先说话，并要求「边做边 commit」。
- 写文档也给写作样例和格式偏好，出来就能贴进 Slack / Docs。
04推理Inference维护 Claude 读你输入时的记忆系统▶
主要用例
- 架构理解与上手：让它找「哪个文件调用了这个功能」，秒级拿到结果，不用翻 GitHub、也不用问同事。
- 单元测试补边界：写完核心逻辑让它补测试，自动覆盖你漏掉的边界场景。
- ML 概念解释：没有 ML 背景的成员靠它搞懂模型函数与参数；原来 1 小时的搜索读文档，现在 10–20 分钟。
- 跨语言实现：要在 Rust 里验证逻辑，直接说清要测什么，它来写，不用为了测试去学一门语言。
- 命令回忆：Kubernetes 的复杂命令直接问，不用背。
拿到什么结果
调研时间 −80%；代码库导航从「问人」变成「秒回」；测试覆盖提升；语言门槛消失。
最狠的三条建议
- 先拿几个问题试它是否比搜索更快更准，再决定是否纳入工作流。
- 从「让它写、你来验」开始建立信任。
- 把写测试这件事整体外包给它，脑子留给设计。
05数据科学与可视化DS & MLE要复杂可视化，但不该变成全栈工程师▶
主要用例
- 不会 JS/TS 也能建 React 应用：直接让它写一个 5,000 行的 TypeScript 可视化应用，用来观察 RL 模型训练表现。可视化应用上下文相对独立，不需要懂整个 monorepo，很适合快速试。
- 重复重构当「老虎机」：merge 冲突、半复杂重构这类「编辑器宏搞不定、又不值得立项」的活——存档、放它跑 30 分钟、接受或重开。
- 从一次性到常驻：不再造一次性 notebook，改让 AI 建可复用的 React 看板，供后续每轮评测使用。
- 完全陌生代码库的整包委派：不在自己专长范围的任务，整个交给它收集上下文并实现。
拿到什么结果
常规任务 2–4 倍省时；零 JS 经验产出 5,000 行应用；工具从一次性变常驻；可视化驱动模型决策。
最狠的两条建议
- 当老虎机用：修不如重开，重开成功率更高。
- 监督时随时打断：「你为什么要这样做？换个更简单的方案。」它默认偏复杂。
06APIAPI Knowledge把 PDF、引用、搜索接进上下文窗口▶
主要用例
- 任何任务的第一站：先问它「这次该看哪些文件」，再开始动手，省掉手工找上下文的时间。
- 独立 debug：陌生模块的 bug 也敢接——「你觉得能修吗？现象是这样的」，往往马上有进展。
- 狗粮式体验新模型：Claude Code 自动用最新研究模型快照，成为他们感知模型变化的主要渠道。
- 消灭上下文切换：不用再复制代码片段、拖文件到对话框里解释半天，直接在工具里问。
拿到什么结果
敢碰陌生区域；上下文整理时间大幅下降；轮岗上手更快；开发者反馈「更开心、更顺」。
最狠的三条建议
- 当迭代伙伴，不要指望一次到位。
- 用它建立「我可以独立处理陌生模块」的信心。
- 从最小信息开始，让它带路，别一次性倒完背景。
07增长营销Growth Marketing一个人的非技术团队，干出一个工程团队的活▶
主要用例
- Google Ads 创意自动化：读入含数百条广告与效果数据的 CSV，找出表现差的，按 30 字符标题 / 90 字符描述的硬限制生成新变体；拆成两个子代理（标题 / 描述），几分钟出数百条。
- Figma 插件批量出图：识别画板、自动替换标题与描述，单批最多 100 个变体、0.5 秒完成，把几小时的复制粘贴压到瞬时，创意产出 10 倍。
- Meta Ads MCP Server：在 Claude Desktop 里直接查投放效果与花费，不用来回切平台。
- 带记忆的提示工程：记录每轮迭代的假设与结果，生成新变体时把历史结论拉进上下文，形成自我改进的测试框架。
拿到什么结果
广告文案 2 小时 → 15 分钟；创意产出 10 倍；一个人干出团队产能；时间转向策略。
最狠的三条建议
- 专找「有 API 的重复动作」，这是最高杠杆的自动化工位。
- 复杂流程拆成专职子代理，别一个 prompt 硬扛。
- 先在对话界面把流程想透、生成完整 prompt 与结构，再进工具执行，且一步一步来。
08产品设计Product Design设计师直接改代码，不再写需求文档▶
主要用例
- 自己改前端细节与状态管理：字体、颜色、间距这类调整不再走多轮反馈；工程师惊讶地发现设计师在做「通常不会让设计师碰的大状态管理改动」。
- GitHub Actions 自动出工单：提一个 issue 描述要改什么，它自动给出代码方案，不用打开工具。
- 贴图生成可交互原型：粘 Mock 图 → 生成能跑的原型，工程师立刻能看懂并接手。
- 提前发现边界情况：让它梳理错误态、逻辑流、系统状态，在设计阶段就暴露边界问题，而不是开发阶段才发现。
- 全库文案替换：替换「research preview」这类全局措辞，它负责找出所有实例、检查上下文、配合法务实时确认——两次 30 分钟会议搞定，原来要一周。
拿到什么结果
Figma 与 Claude Code 80% 时间同时开着；执行 2–3 倍提速；周级协作变小时级；两种体验：开发者「增强版工作流」、非技术者「我居然成开发者了」。
最狠的三条建议
- 让工程同事帮你完成初始仓库与权限配置，前期门槛主要在这里。
- 写自定义记忆文件说明「我是设计师、几乎不会写代码，请详细解释、小步修改」。
- Command+V 直接贴截图，它读设计稿比读描述准得多。
09RL 工程RL Engineering研究向工程：小步试错，频繁回滚▶
主要用例
- 监督式自主做功能：中小型功能让它写大部分代码（如权重传输的鉴权机制），人在旁边纠偏。
- 写测试 / 审代码：自己写完再让它补测试或 review，省掉例行但重要的质量工作。
- Debug：效果时好时坏——有时立刻定位并补上相关测试，有时理解不了问题，但整体仍有价值。
- 组件与调用栈摘要：这是他们工作流变化最大的一点，替代人工读代码和生成大量调试输出。
- K8s 操作问答：省掉大量搜索。
拿到什么结果
形成「试错 → 回滚」的实验式工作流；注释与文档省时（但偶尔位置奇怪、代码组织可疑）；中小 PR 省时间——但一次成功率只有约 1/3。
最狠的三条建议
- 把工具调用错误写进 CLAUDE.md（「用 pytest 跑，别用 run，别乱 cd」）。
- 密集 checkpoint，实验失败随时回滚。
- 先 one-shot 试一次；失败就换协作模式，别在失败基础上硬修。
10法务Legal零开发资源，做出能用的内部工具▶
主要用例
- 给家人做无障碍工具：一位同事因家人患病导致说话困难，用 1 小时做出带原生语音识别的预测输入 App，能建议回复并用语音库朗读，补上现成无障碍工具的空白。
- 法务「电话树」：帮同事按问题类型找到对口的律师，无需传统开发资源。
- 团队协作工具：管理者做 G Suite 应用，自动生成周报、追踪各产品的法务审阅状态，律师点按钮就能标记待审，不再靠表格。
- 快速原型验证想法：做出能演示的原型给专家看（例如给 UCSF 的专家看无障碍工具），先验证再投入。
工作方式与提醒
先在对话界面把想法聊透 → 再进 Claude Code 落地，并要求「放慢、一步一步来」；大量用截图沟通界面；别怕分享「玩具」原型——它会启发别的部门。作为法务，他们同时提醒：MCP 深度集成的安全影响要提前想清楚，合规工具要尽快建。
最狠的三条建议
- 先充分规划，让它把所有想法总结成分步 prompt。
- 小步 + 视觉化，别一口气要完整应用。
- 大胆分享不完美的原型，跨部门的创新常从此开始。
06
关键数字
原文出现的全部效率与效果数据，按团队归拢。数字是别人家的，别直接当预期。
| 团队 | 数字 | 说明 |
|---|---|---|
| 数据基础设施 | 200 个 | 靠它批量盯看板找异常，人力不可能做到 |
| 数据基础设施 | 省 20 分钟 | K8s 故障期间用截图定位 IP 耗尽并给出修复命令 |
| 产品开发 | 70% | Vim 模式的最终实现中由 Claude 自主完成的比例 |
| 安全工程 | 10–15 分 → 5 分 | 事故排查时人工扫代码的时间（约 3 倍提速） |
| 推理 | 1 小时 → 10–20 分 | ML 概念与文档调研时间，减少 80% |
| 数据科学 | 2–4 倍 | 常规重构与重复任务的省时倍数 |
| 数据科学 | 5,000 行 | 几乎不懂 JS/TS 却生成的 TypeScript 可视化应用规模 |
| 增长营销 | 2 小时 → 15 分 | 广告文案产出时间 |
| 增长营销 | 10 倍 / 0.5 秒 / 100 条 | 创意产出量、Figma 插件每批耗时、单批最多变体数 |
| 增长营销 | 30 / 90 字符 | Google Ads 标题 / 描述的硬性字数限制 |
| 产品设计 | 80% | Figma 与 Claude Code 同时打开的时间占比 |
| 产品设计 | 2–3 倍 | 视觉与状态管理改动的执行提速 |
| 产品设计 | 一周 → 两次 30 分钟 | 全库文案替换 + 法务协同的周期 |
| RL 工程 | 约 1/3 | 给一句 prompt 就能首次成功的概率 |
| 法务 | 1 小时 | 做出可用的无障碍沟通 App 的时间 |
口径提醒：三个 80% 不是一回事
原文里「80%」出现了三次，含义完全不同：产品团队拿到的是完成度 80% 的原型；产品设计团队的 80% 指两个工具同时开着的时间占比；推理团队的 80% 才是调研时间减少。同理「70%」是 Vim 功能里 AI 自主完成的代码占比，「10 倍」是创意产出数量，不是转化率或 ROI。引用这些数字前，先问一句：它衡量的到底是什么。
07
七个坑：原文里没被美化的部分
这些是文档里真实写出的局限，比成功案例更值得先看。
① 一次成功率只有约 1/3
RL 团队明确写出：一句 prompt 就首次成功的比例大约三分之一。所以流程里必须有「失败后切换协作模式」的分支，而不是假设一次就对。
② 硬修不如重开
数据科学团队的经验：在错误产出上反复纠正，成功率反而不如存档后重来。修到第三轮还没好，就回滚。
③ 它默认偏复杂
模型倾向于给更复杂的方案。要习惯打断：「为什么这样做？换个更简单的。」这句话本身就能提升产出质量。
④ 核心逻辑不能全放权
产品团队把业务逻辑、关键修复划为「必须同步盯」的区域。放权边界是判断力问题，不是胆子问题。
⑤ 代码组织可能可疑
RL 团队提到：它加的注释常常有用，但偶尔位置奇怪、结构可疑。所以 diff 必须看，不能只看「跑通了」。
⑥ 非技术者的门槛在配置
设计团队说得很直接：前期仓库设置与权限是真正的难点，最好让工程同事帮忙；一旦配好，日常就顺了。
⑦ 敏感数据的接入方式决定风险
数据基础设施团队宁可走 MCP 也不用 CLI，就是为了保留权限与日志控制；法务团队也提醒 MCP 深度集成会带来新的安全与合规问题。
最容易误读的一条
API 团队说「从最少信息开始」，产品团队说「组件同名时必须极其具体」——两者不矛盾：「少」指的是别一次性倒背景，不是允许目标、硬性约束和判定标准含糊。该给的验收条件一个字都不能省。
08
值得记住的话
原文金句 + 中文对照，适合抄进自己的笔记。
"Agentic coding isn't just accelerating traditional development. It's dissolving the boundary between technical and non-technical work, turning anyone who can describe a problem into someone who can build a solution."智能体编程不只是让传统开发变快，它在消融技术与非技术工作的边界——把「能描述问题的人」变成「能做出解决方案的人」。— 开篇结论
"The better you document your workflows, tools, and expectations in Claude.md files, the better Claude Code performs."你把工作流、工具、期望写进 CLAUDE.md 写得越好，Claude Code 的表现就越好。— 数据基础设施团队
"Treat it like a slot machine."把它当老虎机：先存档，让它自己跑 30 分钟，然后接受结果或重开一局——而不是跟它的错误死磕。— 数据科学团队
"Starting over often has a higher success rate than trying to fix Claude's mistakes."重新开始的成功率，往往高于纠正 Claude 犯的错。— 数据科学团队
"Create self-sufficient loops."造自足循环：让它自己跑构建、测试、lint 来验证自己的工作，它才能自主工作更久、并自己抓出错误。— 产品开发团队
"Let Claude talk first."让 Claude 先讲。别急着问零碎问题，让它先自主推进、定期检查，得到的方案更完整。— 安全工程团队
"Try one-shot first, then collaborate."先试一发到底；成功了就省下大量时间（约三分之一概率），失败了再切换到协作模式。— RL 工程团队
"Rather than expecting Claude to solve problems immediately, approach it as a collaborator you iterate with."不要指望它立刻解决问题，把它当成可以反复协作的伙伴——效果比追求一次到位更好。— API 团队
"The model tends toward more complex solutions by default but responds well to requests for simpler approaches."模型默认会偏向更复杂的方案，但只要你要求「简单点」，它通常配合得很好。所以要主动打断。— 数据科学团队
"holy crap, I'm a developer workflow"「天啊，我居然成开发者了」式工作流——产品设计团队用它形容非技术同事获得的全新体验，与技术同事的「增强版工作流」形成对照。— 产品设计团队
09
一周上手路径
不用先学工具，按这个顺序走一遍，你会有自己的判断。
- 第 1 天 · 读完这份材料 30 分钟只做一件事：从 10 个团队里找出与你工作最像的那个，把它的「主要用例」抄成 3 条自己的候选任务。
- 第 2 天 · 写一份「纯文本流程」 20 分钟选一件每周都做的事，写成「输入 → 步骤 → 输出 → 成功标准」。写不出来的地方，就是你还没想清楚的地方。
- 第 3 天 · 建项目说明文件 30 分钟按第 4 节的四块内容写 CLAUDE.md；把第 2 天的流程贴进去，再补一个成功样例。这是投入产出比最高的一步。
- 第 4 天 · 第一次「老虎机」实验 30 分钟 + 离开 30 分钟存档 → 用第 2 步的提示词放权 → 走开 → 回来验收。重点不是结果好不好，而是观察它在哪一步需要你补信息。
- 第 5 天 · 复盘并沉淀 20 分钟用第 3 步的收尾提示词，让它更新说明文件；记录这次省了多少时间、错了多少次、下次能改什么。
- 第 6–7 天 · 决定要不要固化 30 分钟如果同类任务还会再来，就固化成模板 / 斜杠命令 / 子代理；如果只做一次，就停在这里，别再投入。
- 之后 · 团队内部分享 每月一次数据基础设施团队的做法值得抄：定期互相演示用法，比自己摸索快得多。
最后提醒
这份材料最大的价值不是「学会某个工具」，而是让你看清：哪些工作本来就该被拆成「描述 + 验收」，以及你的知识有多少还只存在脑子里、没有落成文字。