Claude Code的10个危险Prompt模式 | 绝对不能用的指令与安全替代方案

你是否在写Prompt时心想”大概能理解我的意思吧”？Claude Code会字面执行指令。模糊或危险的指令会产生意想不到的结果。

本文介绍10个实际引发事故的危险Prompt模式，以及各自的安全替代方案。读完后如果发现”这个模式我在用！“，请立刻修改。

---

模式1：「全部读完理解整个项目」

为什么危险

❌ "把这个仓库全部读完理解后再实现"

在拥有数百个文件的仓库上执行，上下文会爆炸。消耗数万个token，以Prompt is too long错误停止处理。如果在读到一半时停止，则会在不完整的理解基础上进行实现。

另外，如果存在包含.env或密钥的文件，它们也会全部被加载到上下文中。

安全替代方案

✅ "查看src/api/目录的结构，只读取auth相关文件"
✅ "先只读package.json和README，了解项目概况"
✅ "用Grep找到认证相关文件后再读"

要点：明确限定读取范围。如果不指定，Claude Code会尝试广泛读取。

---

模式2：「出错了就自动重试」

为什么危险

❌ "调用外部API出错的话就自动重试，一直到成功为止"

如果外部服务宕机，会在无限循环中持续调用API。实际发生过一小时内调用数万次，账单膨胀到数千元的事故。尤其是夜间批处理任务，在不知情的情况下运行到早上的情况很多。

安全替代方案

✅ "出错的话最多重试3次。
   第1次1秒后，第2次4秒后，第3次16秒后重试。
   3次都失败则输出错误日志并停止处理"

✅ "重试使用以下代码：
   withRetry(fn, { maxAttempts: 3, baseDelayMs: 1000 })"

---

模式3：「直接连接生产数据库确认」

为什么危险

❌ "连接DATABASE_URL的生产数据库，确认用户数后再修改"

本来只是”确认”，但存在后续修改查询在生产数据库上执行的风险。另外，如果SELECT之后误跟了DELETE或UPDATE，生产数据就会消失。连接生产数据库容易引发超出预期范围的操作。

安全替代方案

✅ "连接开发数据库(DATABASE_URL_DEV)确认用户数。
   不要连接生产环境"

✅ "只生成查询语句，不要执行。
   确认后由我来执行"

✅ 在CLAUDE.md中明确：
"禁止对生产DATABASE_URL执行查询。
 在staging确认后，仅在用户批准后才可执行"

---

模式4：在Prompt中直接粘贴API密钥

为什么危险

❌ "使用QIITA_TOKEN=abc123def456向Qiita发帖"
❌ "使用sk-ant-api03-xxxxx调用Anthropic API"

Prompt中写的内容会作为对话历史保存。委托给子Agent时也会原样传递。会留在本地.claude/目录的日志中，通过备份工具或代码共享有可能意外流出到外部。

安全替代方案

✅ "使用.env中的QIITA_TOKEN执行scripts/qiita-publish.mjs"
   ← token的值只存在于.env中，Prompt中只写变量名

✅ 在脚本端从环境变量读取：
   const token = process.env.QIITA_TOKEN;
   if (!token) throw new Error("QIITA_TOKEN未设置");

---

模式5：「解决冲突后推送到生产环境」

为什么危险

❌ "和main分支有冲突。解决后推送到生产环境"

“解决冲突”的手段可能会选择git push --force。存在团队成员提交消失的风险。另外，“推送到生产环境”也有可能不经过CI/CD直接推送。

安全替代方案

✅ "确认和main的冲突，提出合并策略。
   实际的合并和推送在我批准后再执行"

✅ 在CLAUDE.md中明确：
"禁止git push --force。
 需要force时使用--force-with-lease，并向用户确认"

// .claude/settings.json
{
  "permissions": {
    "deny": [
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ]
  }
}

---

模式6：「把所有旧文件删掉清理干净」

为什么危险

❌ "把dist/、.cache/和旧日志文件全部删掉清理干净"

由于”旧”的定义模糊，存在连必要文件也被删除的风险。特别是.cache/系列可能包含OS或工具特有的重要数据。同时指定多个目录会变成rm -rf dist .cache logs/，可能影响到意想不到的路径。

安全替代方案

✅ "只删除site/dist/目录的内容。
   目录本身保留。不要动其他目录"

✅ "删除前先显示删除对象的文件列表让我确认。
   批准后再删除"

---

模式7：「把所有确认都自动OK一口气执行」

为什么危险

❌ "跳过中间所有确认，一口气执行到最后"
❌ "加上--dangerously-skip-permissions选项执行"

批准流程是安全装置。跳过后，Claude Code会按其判断”最高效”的方式推进处理。即使是rm -rf、force push或写入生产数据库，也会在没有确认的情况下执行。

安全替代方案

✅ "先把这个任务的步骤列成条目。
   批准后每次执行1步，每步确认结果"

✅ 需要自动化时只将可信操作加入allow：
   "allow": ["Read(**)", "Glob(**)", "Bash(npm run test)"]

---

模式8：「把迁移更新到最新并整理数据库」

为什么危险

❌ "迁移文件乱糟糟的。整理一下更新到最新状态"

“整理”可能被解读为删除旧的迁移文件。迁移历史消失后，新环境的搭建或回滚就无法进行了。另外，如果执行了migrate reset类的命令，生产数据有消失的危险。

安全替代方案

✅ "显示迁移文件列表，如有重复或问题只指出来。
   不要做任何修改"

✅ "确认未执行的迁移，显示计划执行的SQL。
   批准后再执行"

✅ 在CLAUDE.md中明确：
"不删除迁移文件。
 包含ALTER/DROP的迁移执行前必须取得用户确认"

---

模式9：「把所有包更新到最新版本」

为什么危险

❌ "npm包太旧了。全部更新到最新版本"

npm update或npm install 包@latest可能会升级主版本。如果包含Breaking changes，本地构建可能通过但生产部署后服务会停止。依赖关系的级联破坏也容易发生。

安全替代方案

✅ "执行npm outdated，显示可更新包的列表。
   主版本升级的单独确认"

✅ "只更新有安全漏洞的(npm audit检测到的)包"

✅ "只把react和next.js更新到最新次要版本。
   不升级主版本"

---

模式10：「测试以后再写，先部署」

为什么危险

❌ "测试以后写，现在先部署"
❌ "CI太慢了，用--no-verify跳过后push"

测试和CI不是”慢”，而是”在保护你”。跳过后在生产环境首次发现bug是最糟糕的模式。--no-verify会将包括git hooks在内的全部内容失效，密钥扫描和lint也会被跳过。

安全替代方案

✅ "先写测试，通过后再部署。
   测试覆盖率不够也没关系，主要路径通过即可"

✅ "调查CI慢的原因，利用缓存加快速度。
   不要跳过"

✅ 在CLAUDE.md中明确：
"禁止--no-verify。
 不使用任何跳过CI的手段"

---

总结：安全Prompt写法的3个原则

原则1：明确指定范围 “全部”、“所有”、“整个”是危险词汇。具体指定要读取的范围、修改的范围、删除的对象。

原则2：保留确认步骤 在”执行”前加入”确认”、“提案”、“显示列表”。特别是影响生产环境的操作。

原则3：不要在Prompt中写秘密信息 API密钥、密码、连接字符串放在.env中，Prompt中只写变量名。

危险词汇	安全替代
”全部读取"	"只读取〇〇目录"
"自动重试"	"最多重试3次，失败则停止"
"连接生产数据库"	"在开发数据库确认，生产环境由我执行"
"全部删除清理干净"	"只删除〇〇，先显示列表"
"一口气执行"	"先让我确认步骤，批准后再进行”

Claude Code只是忠实执行指令，没有恶意。危险在于给出模糊指令的一方。养成写具体、范围明确指令的习惯，是防止事故的最快方法。

相关文章

• Claude Code引发的7个生产故障案例与完整恢复步骤
• Claude Code安全对策完全指南
• Claude Code权限设置完全指南

参考资料

• Claude Code官方安全指南
• OWASP LLM Application Security