起因：让 AI 把一个项目发布到 GitHub，它把整个项目文件夹全发上去了，连交接文档这类内部文件都没落下。踩完坑总结出来的规矩，分享给同样让 AI 帮忙发布项目的人。

一句话原则：默认私有、先出清单、只发白名单。没确认清单之前，谁也不许 push。

一、为什么 AI 会把整个项目都发上去

不是它故意泄密，是它默认就这么干：

你说「把项目发布到 GitHub」，执行端最省事的做法就是 git init + git add. + git push。git add. 的意思就是当前文件夹里所有没被忽略的文件，一股脑全加进去。

对它来说，交接文档、内部记录、源码都只是普通文件，长得没区别。它不知道哪些是你内部的、不能见人的，除非你提前把规矩写死给它。

所以结论是：发布这件事不能只说「发上去」，必须把「发哪些、不发哪些、先给谁确认」写进给它的指令里。

这条对所有 AI 编程工具都成立，不管你用的是哪一家。

二、三分法：什么能发、什么不能发

1. 1. 应该发的（公开仓库）
2. 源码本身：代码文件、样式、页面README：对外说明，写这个项目是干嘛的、怎么装、怎么跑LICENSE：想让别人合法使用才加；不加 = 默认保留所有权利，别人不能随便用对外文档：使用说明、接口说明这类本来就给外人看的示例配置：如 .env.example（只写字段名，值留空或写假例子）依赖清单：requirements.txt、package.json、Cargo.toml 这类
4. 2. 绝对不能发的
5. 密钥凭证：.env、私钥文件、token、cookie、API Key、密码、带真实凭证的配置文件记住：这类东西一旦进了公开仓库，就算你下一分钟删掉，git 历史里还在，等于已经泄露。处理办法只有去对应服务把那把钥匙作废、重新生成，删文件没用。
7. 3. 默认不发的（内部东西）
8. 项目内部文档：交接文档、内部状态记录、决策记录、会议记录、复盘笔记你和 AI 协作的过程文件：任务记录、AI 的工作报告、草稿区业务资料、客户和供应商信息、价格、聊天截图、个人笔记真实数据文件：数据库、导出的表格、真实用户数据拿不准的，一律先归这一类，不发这一类的具体文件名每个人都不一样，照着上面的类别，对一遍你自己项目里实际有的文件。
10. 4. 不用发的（发了纯添乱）
11. 依赖和生成物：node_modules/、虚拟环境、pycache/、target/、dist/、build/日志、缓存、临时文件、系统文件、大体积二进制和备份文件三、防线：.gitignore 放在项目根目录作用：写进这个名单的文件，git 会自动当没看见。每个要发布的项目，发布前先放好它，再谈发布。下面这份是通用版，覆盖常见的语言和工具，「内部文档」那一段请按你自己项目的实际文件名替换：

--- 密钥凭证，绝对不发 ---

.env.env.*!.env.examplecookietokensecret*.pem.key.localconfig.local.credentials

--- 内部文档，不对外（按自己项目的文件名改这一段）---

docs-internal/_内部交接*_交接handover*notes-private/

--- 依赖、构建产物、缓存 ---

node_modules/venv/.venv/pycache/target/dist/build/out/

--- 编辑器和系统 ---

.idea/.vscode/.DS_StoreThumbs.db

--- 日志、数据、备份 ---

*.log*.db.sqlitedata/*.bak_backup_old*~

注意两点：.gitignore 只管「还没被 git 收进去过」的文件。已经提交过的文件，再加忽略也没用，要单独移除（见第五节）。

个别项目有特殊情况，比如团队就是要共享 .vscode 配置，那就把对应那行删掉。模板是起点，不是圣旨。

四、正确发布流程（五步，顺序不能乱）

先定公开还是私有：拿不准就先建 Private 私有仓库。私有随时能改公开，公开被人看过就收不回来了。

放好.gitignore：用第三节模板，先挡住密钥和内部文档。

先出清单，不 push：让 AI 只做到「列出将要提交的全部文件清单」这一步就停下。你逐行看完，清单里出现内部文档、.env、数据文件，直接打回。

确认后才提交：按白名单点名加文件，不要用 git add.。

推完立刻自查：打开 GitHub 网页，从头翻一遍仓库文件列表，自己扮演外人看一遍：有没有不该出现的文件，README 里的路径和截图有没有带出内部信息。查到问题按第五节处理。

五、已经全发上去了，怎么办

按这个顺序处理，别只删文件：

先看仓库是公开还是私有：私有的风险小得多，慢慢清就行；公开的按下面从重到轻处理。

里面有密钥、cookie、token 吗：有的话，第一件事是去对应服务把那把钥匙作废、重新生成。删仓库都排在它后面，因为可能已经被抓走了。

清的是历史，不是表面文件：在最新一次提交里删掉某个文件，旧提交里它还在，点开历史照样能看。干净的做法二选一：仓库刚建、没人用：直接删仓库，按第四节流程重建一个干净的。最省事、最稳。

仓库已经有人在用：用重写历史的工具清掉再强推。这活可以让 AI 做，但指令要写明「重写历史」，只说「删掉文件」它只会删表面那层。

内部文档本身：没有密钥那么急，但公开过就当外人已经看过，里面提到的路径、账号、计划按已公开对待，该改的改。

六、给 AI 的标准指令（发布时直接粘这一段）

不管你用哪个 AI 编程工具，这段都能用，把括号里的换成你的实际情况：任务：把发布到 GitHub，仓库名，可见性：Private（没我确认不许建 Public）。

硬规矩：

1. 1. 禁止 git add. 全量添加。只按白名单添加：源码文件、README、LICENSE（如有）、对外文档、依赖清单、.env.example。
2. 2. 以下一律不许进仓库：.env 及任何密钥/cookie/token/凭证文件；项目内部文档（交接、内部记录、会议记录、AI 协作过程文件）；node_modules、虚拟环境、pycache、target、dist、build；数据库和真实数据文件；备份文件。
3. 3. 项目根目录没有.gitignore 的，先按我给的模板建好再继续。
4. 4. 先做到「列出将要提交的完整文件清单」就停下，把清单发我确认。没收到我「可以推」三个字，不许 commit、更不许 push。
5. 5. 推送完成后，回报：仓库链接、实际提交的文件总数、被.gitignore 挡掉的文件有哪些。这段的要点就一个：把判断权留在清单确认那一步，AI 只负责干活，不负责决定发什么。七、发布前自查清单（每次推之前扫一眼）□ 仓库是私有，还是我确实想公开？□.gitignore 已放好，密钥和内部文档在名单里？□ 提交清单我逐行看过了，没有内部文件和数据文件？□ README 里没有内部路径、真实账号、截图里的敏感信息？□ .env.example 是空值／假值，不是真配置改个名？□ 推完我打开网页亲眼翻过一遍文件列表？