Apple「顺手」把 Claude.md 发出来了😂：Prompt 文件别再乱放了

你没看错。 Apple 在发布 Apple Support App v5.13 时，被人扒出包里疑似带了个 Claude.md。

这类文件大概率是给大模型（比如 Claude）看的“项目说明书”：项目背景、风格规范、注意事项、接口约定……

笑点在于：它不该出现在正式发布包里。 干货在于：咱们做 AI 功能的人，真的太容易踩同一个坑。

下面这篇就按“能照做”的方式讲清楚：

• Claude.md / Prompt 文件到底怎么写才好用
• 放哪儿更靠谱
• 发布前怎么检查，避免把内部指令一起发出去
• 真要上生产，怎么把“提示词”当成配置来治理

1）Claude.md 到底是什么？你可以把它当「AI 的 README」

很多团队会在仓库里放一个约定文件：

• Claude.md
• PROMPT.md
• assistant_instructions.md
• AGENTS.md

名字不重要。 核心作用就一个：让模型快速进入状态，知道自己在什么项目里、要用什么口吻、别碰什么雷。

你可以把它理解成：

• 给新人看的 onboarding 文档（但读者是模型）
• 给代码生成/内容生成的“团队规范”
• 给所有对话共享的“默认规则”

它通常包含这些内容：

• 产品/业务背景：一句话说明你们在做什么
• 输出风格：要短句还是长文，要不要 Emoji，要不要列步骤
• 技术边界：不能访问外网、不能编造 API、必须标注不确定点
• 代码规范：语言、目录结构、命名、单测要求
• 安全要求：不能泄露 key、不能把内部链接贴出去

2）一个好用的 Claude.md，长什么样？（直接抄这个骨架）

下面这个模板你可以直接拿去用。别写成作文，像写团队规范那样写。

# 项目：Customer Support Assistant

## 你是谁
你是我们的客服助手，目标是：让用户在 2 分钟内找到可执行的解决方案。
口吻：友好、直接、少废话。

## 你要输出什么
- 优先给结论 + 可操作步骤
- 遇到不确定信息：明确说“不确定”，并给验证方法
- 不要编造公司政策、价格、联系方式

## 允许使用的资料
- 本仓库 docs/ 下的内容
- 我提供给你的 FAQ 片段

## 禁止事项
- 不要输出内部域名、内部工单链接
- 不要在回答里出现 API Key、Token、设备序列号示例
- 不要建议用户绕过安全限制（越狱/破解/社工）

## 格式偏好
- 用 Markdown
- 列表要短
- 需要时给“避坑清单”

写完你会发现：

• 它不“酷”，但很能打。
• 它不靠花里胡哨，靠约束把质量稳住。

3）为什么「把 Claude.md 打进 App 包」是个坑？

因为这类文件通常会暴露你不想公开的东西，比如：

• 内部工具名、内部目录结构
• 真实接口路径、测试账号习惯
• 你们的安全策略（越详细越容易被针对）
• 甚至提示词里夹带的“业务规则”，被竞品直接抄走

更现实的一点：

你以为只是一个 md 文件，别人会当成“产品说明书”来读。

所以不要自我安慰“也没啥”。 真泄了，PR 和安全同学会让你体验什么叫“下班失败”。

4）Prompt 文件放哪儿更安全？三种方案，按团队成熟度选

方案 A：仓库里有，但发布产物绝对不带

适合：大多数团队。

做法：

• Claude.md 放在 repo 根目录或 docs/
• 打包时排除：确保不会被 copy 到 app bundle / web build

关键点：把排除写成自动化规则，别靠记忆。

方案 B：Prompt 走服务端配置，客户端只拿“版本号”

适合：Prompt 需要频繁迭代的产品。

做法：

• Prompt 存在服务端（数据库/配置中心）
• 客户端请求时只传：prompt_version 或 policy_id
• 服务端拼装 system prompt + policy + 用户上下文

好处：

• 不用发版就能改提示词
• 不会被轻易从包里扒出来
• 有审计、有灰度

代价：

• 需要一套配置管理和回滚

方案 C：Prompt 分层 + 权限隔离（生产级）

适合：有合规压力、多人协作的大团队。

推荐拆成三层：

• System（平台级）：安全、合规、红线
• Product（产品级）：业务目标、口吻
• Task（任务级）：当前页面/按钮触发的具体任务

再配合：

• 权限：谁能改哪一层
• 审批：上线必须有人 review
• 记录：每次变更可追溯

5）发布前怎么抓“泄露文件”？给你一套能落地的检查清单

你要的不是“提醒大家注意”。 你要的是：CI 直接拦住。

✅ 通用检查（任何项目都能用）

• 构建产物里全量搜索这些关键词：
  • Claude.md / PROMPT / system prompt
  • INTERNAL / TODO / staging / dev-only
• 搜索敏感模式：
  • sk-（常见 API key 前缀）
  • BEGIN PRIVATE KEY
  • Authorization:

你可以在 CI 里做“打包后扫描”，扫描到就失败。

✅ iOS / Android 的常见坑位（很容易中招）

• 你把 md 放进了资源目录（以为只是文档）
• 你用了自动拷贝脚本，把 docs 一起 copy 进包
• 你在 debug 配置里写了 prompt，结果 release 也带上了

经验话：

“我只是顺手放那里” 这种话，最后都会变成事故复盘标题。

6）Prompt 写得再好，也别忘了：模型会“复述”你的机密

即便你没把 Claude.md 打包进客户端，Prompt 也可能通过这些方式泄露：

• 日志：把 system prompt 记录到请求日志
• 埋点：把用户输入和模型输出全量上报
• 前端：把完整提示词拼在浏览器端，用户随便打开 devtools 就看到了

一个简单原则：

• 机密永远只在服务端拼装
• 客户端只传必要上下文（而且要脱敏）

7）给你一个“上线就能用”的 Prompt 治理小流程

不搞花活，按这个走就够稳：

• Prompt 统一放一个目录或配置中心
• 每次改动必须带：变更说明 + 风险点
• 走灰度：5% → 20% → 100%
• 关键指标盯着：
  • 幻觉率（编造信息的比例）
  • 违规触发率（红线命中）
  • 用户二次追问率（回答不清导致反复问）
• 一键回滚：Prompt 版本号回退即可

你会明显感觉到：

• 线上质量更稳
• 团队沟通成本更低
• 出事时能快速定位是哪一次提示词改动导致的

避坑清单（建议你贴到项目 README）

• 不要把任何 Prompt 文档放进会被打包的资源目录
• 不要在客户端拼装完整 system prompt
• 不要把 system prompt 写进日志或埋点
• Prompt 里别出现真实接口域名、内部工具名、工单链接
• Prompt 版本必须可追溯、可回滚

结尾吐槽一句

Apple 都能“顺手”把 Claude.md 带出去，咱们更别指望靠记忆和自觉。 把检查写进 CI，把 Prompt 当配置管起来，这才是正经活。

你要是愿意，我也可以按你现在的项目形态（Web/Android/iOS/桌面端/纯后端）给你一份“打包产物扫描脚本 + 目录排除规则”的落地方案。