怎么写指令，让 Claude Code 只改一个文件

「这篇博客的开头，你帮我改得更好一点。」

我敲下这句话的时候，是周五晚上十点。我想改的只有一个文件、开头那三段而已。可第二天早上打开 diff 一看，竟然有 12 个文件被动过。不只是正文，连公用布局、标签列表，甚至连一个发布配置文件都被改了。我连它能不能正常跑都没确认，就睡过去了。

光是把它们撤回来就花了 30 分钟。问题出在哪？不是 Claude Code 笨。是我的指令里，一句都没说清「能动到哪、不能动到哪」，所以这个聪明的 AI 就自作主张地理解成「把开头改好＝顺手把相关的地方也一起整理了」。

这篇文章，我把那天晚上翻车之后总结出来的「只让它安全地改一个文件」的请求文，直接以可复制粘贴的形式交给你。范围划窄、改完让它自己验证、改错了能撤回——就这么几下，半夜的事故基本就消失了。

本文要点

• AI 干活会失控，不是模型不行，而是你没写清楚它能动的范围
• 请求文里一定要放这五样：「要看的文件」「要改的文件」「不许碰的东西」「验证命令」「回滚方法」
• 在它报告「搞定了」之前，强制先跑一遍验证命令，能少很多「人类事后当测试员」的事故
• 从止损点清晰的小活儿开始：改博客、整理 bug 报告、改写商品文案
• 把范围划窄，文章或成果的价值并不会缩水，反而读者更容易套到自己的环境里

为什么「改得更好一点」一定会翻车

「改得更好一点」这种说法，没有一条终点线。

换成一个人类编辑，周五晚上忙起来被这么一托，会先反问一句：「就开头那三段对吧？」可 AI 不会确认，直接就跑起来了。而且它特别擅长「自作聪明」——「既然要把开头改好，那把标签也整理一下、相关链接也补上，岂不是更周到？」于是擅自把范围越扩越大。它一点恶意都没有。这才是最麻烦的地方。

这时候真正管用的，是**在指令里事先写好「止损点」**这个思路。提示词不用写得又长又花哨，反而越短越好。你要做的，是一开始就把「能动的文件」和「绝对不许动的文件」明确分开。光这一招，失控就被掐住了。

想再往深里钻提示词本身怎么写的人，可以配合读一下 Claude Code 的提示词设计，你会看清这里说的「把范围收窄」是怎么和其他技巧串起来的。

请求文里必放的五样东西

我现在用的请求文里，一定有这五样。它们的顺序也是有讲究的。

项目	内容	缺了它会发生什么
要看的文件	为了解状况而允许读的范围	把不相关的地方也读了，做出驴唇不对马嘴的修改
要改的文件	实际允许改写的 1～2 个文件	出现「12 文件翻车」
不许碰的东西	配置、生成物、机密信息、发布配置	删了就完蛋的文件被它「整理」掉
验证命令	改完后要跑的那一条验证命令	东西坏着就报告「搞定了」
回滚方法	改错时把它撤回原状的步骤	恢复要花 30 分钟

关键在于，在动手编辑之前，先让它把「计划」回一遍。别让它上来就改。先让它说清楚「打算看哪些文件、改哪一个、万一改错了什么会坏」。要是这时候回来的计划就跑偏了，你当场就能叫停。这比改完才发现要便宜太多了。

哪些交给 AI，哪些自己来定

不必把所有事都丢给 AI。我是这么划线的。

可以放心交给 AI 的部分

• 为了解状况去读文件
• 把改动的计划想清楚、用文字说出来
• 实际写文案或代码
• 跑验证命令并报告结果

人要自己攥在手里的部分

• 把哪些文件定为改动对象（范围的决定权）
• 按不按「发布 / 上生产」那个按钮
• 要不要碰配置文件和机密信息的判断
• 验证没过时，要不要叫停发布的判断

这条线，越是第一次把活儿交给 AI 的人越重要。怎么分「交给它的范围」和「人来判断的范围」，在 给非工程师的 Claude Code 用法 里也是作为基本思路出现的。还不熟的时候，粗到「读和写交给 AI，删和发布留给人」这种程度就够用了。

可复制粘贴的请求文模板

直接贴上去，只把文件名换成你自己环境里的就行。PowerShell 也好、bash 也好，无非是把这段文字塞进一个变量里再确认一下。

brief=$(cat <<'EOF'
目的：只在一处做一次安全的编辑。
允许改的文件：site/src/content/blog/example.mdx
不许碰：package 相关文件、生成物、机密信息、发布与部署配置。

开始编辑之前，请先返回：
1. 为了解状况要看的文件
2. 实际要改的那 1 个文件
3. 万一这次改动是错的，会坏掉什么
4. 改完后要跑的验证命令

编辑结束后，请返回：
- diff 摘要
- 验证命令的执行结果
- 撤回原状的步骤
EOF
)

echo "$brief"

这段文字一点都不花哨。它的价值在于，能在动手之前就把边界写成文字。把文件名、不许碰的东西、验证命令换成你自己仓库的，再交给 Claude Code。等它回来一份像样的计划，先让它把同样的约束复述一遍，再让它开干。

把同样的约束写进 CLAUDE.md，不用每次粘贴也能自动生效。具体做法整理在 CLAUDE.md 最佳实践 里。

改完就让它验证的小脚本

不轻信「搞定了」。这是第二根支柱。

编辑结束后，机械地确认一下「被改的文件是不是真的只有一个」。下面这个脚本，就是数一数未提交的改动文件数，比预期多就直接停。带中文注释，复制就能跑。

#!/usr/bin/env bash
# 确认改动文件是否只有一个。太多就停下来。
set -e

# 预期的改动文件数（只改 1 个文件就填 1）
expected=1

# 数一数未提交的改动文件数
changed=$(git status --porcelain | grep -c .)

echo "改动的文件数：$changed（预期：$expected）"

if [ "$changed" -gt "$expected" ]; then
  echo "改动的文件比预期多。请检查 diff。"
  git status --porcelain
  exit 1
fi

echo "范围符合预期。"

把这个脚本指定为请求文里的「验证命令」，AI 就会自己去跑、自己报结果。要是改了 12 个文件，报告的那一刻就会蹦出红字。不是等我早上起床才发现，而是当场就停住。这一招很顶用。

想把验证和日常的流程再自动化一些的人，Claude Code 的效率提升技巧 里还整理了别的套路。

三个真正管用的场景

这三个活儿，都有清清楚楚的「止损点」。反过来说，看不到止损点的活儿，就是「还别整个甩给 AI」的信号。

1. 重写博客开头 一开始就写明「只改一个文件的开头」，再附上目标读者和验证命令。这样它的手就伸不到全文和布局上去。我那次 12 文件翻车，要是有这一行，根本就不会发生。

2. 整理 bug 报告 只把日志文件和一个模板给它看，并写上「禁止整理无关代码」。整理报告的时候顺手被重构一通，审查一下子就变重了。给它看的范围收窄，它的输出也就跟着收窄。

3. 测试商品页文案 别让它重做整页，只要求「一版标题文案」和「确认改后的样子」。范围固定在一版上，做 A/B 测试时对比也轻松。

常见问题

Q. 每次都贴这么长一段请求文，不嫌烦吗？ 常用的约束写进 CLAUDE.md，不用每次贴也能生效。每次要贴的，就只剩「这次允许动的文件名」了。

Q. 把范围收窄，不会把 AI 的长处给扼杀掉吗？ 正相反。范围越窄，AI 越不犹豫，改得越深。指令一宽，反倒让它在「从哪儿下手」上犯难。

Q. 验证命令该放什么？ 一开始光放「改动文件数检查」就够了。熟了之后，再一条条加上：能不能构建通过、测试有没有挂、有没有死链。

Q. 万一还是有意料之外的文件被改了呢？ 只要请求文里写了回滚方法，照那个步骤撤回就行。把 git restore . 这类撤回命令一开始就写进指令里，是个窍门。

Q. 从哪儿开始最好？ 挑一个就算搞砸也能撤回的小活儿。改草稿文章、替换某段文案，都挺合适。要是连基本操作都还没底，从 Claude Code 入门指南 开始能先把地基打平。

我实际试下来的结果

经历那次 12 文件翻车之后，我写请求文一定带上「要改的文件」「不许碰的东西」「验证命令」这三样。

自从把验证脚本指定为「验证命令」，意料之外的文件混进来的情况，都会在当场被停住。上周我让它改商品页文案，AI 又差点把手伸到公用组件上，结果改动文件数变成 2 的那一刻，脚本就蹦红停了。早上起床看 diff 然后脸都吓白——这种事再没发生过。

还有一点我也验证了：把范围收窄，输出质量并不会掉。反而是我用「只改开头三段」框死的那天，回来的改动更对路。比起把活儿宽宽地甩给聪明的 AI，不如窄窄地托给它、再自己验证。看着像绕远路，但对我来说，这才是最快的——这是我现在的结论。

如果你想在公司业务里搭一套「把编辑和运营交给 AI」的机制，可以在 培训 / 落地咨询 里从具体步骤开始一起搭。不过先别急，自己手头先试一遍「只改一个文件」的请求文吧。

顺便附上一句，这里用到的工具，官方资料在 Claude Code 官方文档 里。