别急着打字：把 Claude 用成“能交付的同事”

你有没有这种体验：

聊到一半开始跑偏
代码越改越乱
明明给了很多背景，它还是误解
你越补充，它越自信地胡说

问题不在你不够会问，而是你把它当聊天对象了。

咱们把它当“同事”用：先想清楚再让它动手，把记忆放在该放的地方，把模型分工做清楚，把流程做成自动化。输出会稳定很多。

1）开口前先让它“出方案”：Plan Mode 的正确打开方式 🧠

很多任务失败，是因为你直接说“帮我写/帮我改”。Claude 也会直接开写。

更稳的方式是：先让它规划，再让它执行。

你可以这么说

进入 plan mode。目标：把 xxx 做到可上线。限制：xx 技术栈、xx 时间、不能引入新依赖。先给计划：步骤列表、每步产出、风险点。我确认计划后你再开始写。

你会发现：

它会主动问关键缺口（比如接口、数据结构、边界条件）
它会把任务拆成可验收的块
你可以在“写代码之前”就纠错

小技巧

让它在计划里写清“验收标准”，你就不会陷入无限来回改。
计划越短越好，能落地就行。别搞论文。

2）把团队口味写进 CLAUDE.md：短、具体、带原因、常更新

CLAUDE.md 是你的“长期记忆入口”。但很多人写成公司文化墙，没用。

好的 CLAUDE.md 长这样

短：一屏内能看完
具体：直接给规则，不要口号
告诉原因：原因能让它更一致地执行
常更新：每次踩坑就补一条

一个可直接套用的模板

# 工作偏好
- 输出中文，语气直接，少铺垫（方便我复制到文档）
- 代码优先可读性：命名清晰、函数短（减少后期维护成本）
- 提供改动点列表（方便 code review）

# 技术约束
- 项目使用 Node 18 + TypeScript
- 不引入新依赖，除非我明确允许（避免部署风险）

# 输出格式
- 方案先给 bullet list
- 代码给完整文件内容，标明文件路径
- 涉及配置要附上可复制的示例

你会明显感觉到

同一个问题，输出风格更统一。团队协作也更省沟通。

3）上下文别塞爆：到 30%～40% 质量就开始掉

很多人以为“给它越多信息越好”。现实是：上下文长到某个程度，注意力会分散，质量下滑很明显。

你可以把它想象成：会议开到第 90 分钟，大家都开始飘。

实战做法：外部记忆 + 定期清空

长背景放到外部：README、规范文档、需求说明、数据库结构
对话只放“这次任务必须用到的片段”
卡住/跑偏时，直接 clear，重新开一轮

一套好用的“外部记忆”组织方式

/docs/requirements.md：需求与边界
/docs/decisions.md：关键决策记录（为什么这么选）
/docs/api.md：接口与示例
/docs/guidelines.md：代码风格与约束

然后在对话里只说一句：

只参考 docs/requirements.md 和 docs/api.md 的内容。别脑补。

省心。

4）提示词写具体点：尤其是“不要做什么”，再补一句为什么

很多人只写“做什么”。Claude 很容易热心过头。

你要明确：

做什么
不要做什么
不要做的原因

示例：让它写接口，不要乱加功能

不太稳的写法

写一个用户登录接口。

更稳的写法

写一个用户登录接口（Express + TS）。只支持邮箱+密码。不要加注册、忘记密码、第三方登录（需求没排期，别扩 scope）。密码校验用 bcrypt compare。返回值固定：{ token, user: { id, email } }。给我一份可复制的 route + service + 简单单测。

你会发现它更“像在交付”，而不是在表演。

5）Opus 做决策，Sonnet 做实现：别让“架构脑”去搬砖

如果你用的是 Claude 的不同模型版本，一个很稳的分工是：

Opus：架构、权衡、方案选型、风险评估
Sonnet：写代码、补测试、做重构、修 bug

一个典型流程

1）把需求丢给 Opus：

让它给 2～3 个方案
写清 trade-off（性能、成本、复杂度、可维护性）
给推荐方案 + 原因

2）选定方案后，把“决策结果”丢给 Sonnet：

让它按结构落地
让它按文件输出
让它补边界 case

你会少掉很多“代码写了半天，方向错了”的崩溃时刻。

6）MCP、hooks、slash commands：把对话变成工作台 🛠️

如果你还停留在复制粘贴，那效率确实上不去。

这三个东西的价值很直接：

MCP：让模型接入你的工具/数据源（仓库、文档、任务系统等）
hooks：在关键动作前后自动触发规则（比如提交前检查、生成摘要）
slash commands：把常用操作变成一条命令（少打字，少跑偏）

你可以先做的 3 个“最有感”的命令

/summarize：把当前讨论压成 10 行结论 + 待办
/diff-plan：先列出要改哪些文件、每个文件改什么
/risk-check：列出可能踩坑点 + 如何验证

用久了你会发现：你在管理流程，不是在跟模型斗智斗勇。

7）卡住别硬推：清空、简化、给示例，比继续聊更快

卡住的表现：

它开始反复道歉或反复解释
改一处坏三处
需求越讲越多，它越乱

这时候继续怼它没意义。

三招救命

clear：重新开对话，把必要信息精简成 10 行
简化：把任务拆小，只做“最小可验证”版本
给示例：给输入输出样例、给一段你能接受的参考代码

一个非常好用的“止损提示”

你现在不要写新方案。只问我 5 个最关键的问题，问完等我回答。

模型会突然变得像个靠谱的同事。

8）别追求“一次聊完”：搭系统，才能每天早下班一小时 😄

一次对话写出一段代码没啥难度。难的是：反复出现的工作能不能自动化。

把重复劳动做成固定流程

需求模板（你填空，它执行）
代码生成脚手架（统一目录、统一输出格式）
PR 检查清单（自动跑测试、自动生成改动摘要）
决策记录（每次选型写入 decisions.md）

你会得到一个很现实的好处：

新需求来时，你不是“重新开始一段对话”
你是在“跑一套流程”

交付稳定，返工变少。

一页纸执行清单（照做就能变稳）

写任务前让 Claude 出计划，计划里要有验收标准
CLAUDE.md 控制风格与约束，一屏内读完
上下文别塞满，长信息放外部文档
prompt 写清楚：要做什么 + 不要做什么 + 为什么
Opus 负责决策，Sonnet 负责落地
常用能力做成 slash commands
一旦跑偏：clear / 简化 / 给样例
把高频工作变成自动化流程，而不是一次次聊天

如果你愿意，我可以按你的工作场景（写代码/写方案/写自媒体/做运营）给你一份可直接用的 CLAUDE.md + 命令清单。你告诉我你主要拿它干啥就行。

别急着和 Claude 聊：用 Plan Mode、CLAUDE.md、外部记忆把输出稳定到“可交付”