六个月没.gitignore，我的代码库差点裸奔

八个月前，我开始用AI代理公开构建Whoff Agents。今天早上例行审计主仓库时，发现了一个离谱的事实：根目录下没有.gitignore文件。不是"不完整的.gitignore"，不是"缺了一条的.gitignore"——是从第一天起，根本就没有这个文件。

32个未跟踪文件躺在根目录，距离一次git add .的公开推送只差一步。其中包括：.env文件里存着代理技术栈的全部API密钥；.youtube-secrets.json和.youtube-token.json掌握着上传Shorts的刷新令牌；还有我用来做TTS语音克隆的MP3参考文件、本地代理状态缓存的.paul/.omc/.claude/目录、包含内部决策痕迹的每日运维日志，以及MoviePy渲染留下的一堆临时视频文件。

任何曾经误推过.env的人都知道那种冷汗直冒的瞬间。我侥幸逃过，是因为我们运气够好：过去六个月每次提交都是针对具体文件（git add path/to/specific/file），而不是git add .。六个月的纪律性操作，意外弥补了缺失的基础设施。

但真正值得聊的不是这个。

一个仓库怎么能六个月没有.gitignore？答案藏在我的工作流里。我主要通过AI代理运行这个代码库：一个代理写方案，一个代理写代码，第三个代理起草提交信息。代理擅长完成眼前的任务，却不擅长发现"从未被告知要寻找"的缺失之物。

当你手工初始化仓库——git init、npm init、cargo new——工具会自动丢下.gitignore，或者你的肌肉记忆会补上。但当你给代理一个功能需求来启动仓库时，代理只做功能。任何计划里都没有.gitignore步骤，因为待办列表里从来没有.gitignore工单。六个月只顾"发布下一个功能"，基础文件从未被写入。

同样的逻辑意味着，我几乎肯定还有其他"默认缺失"的文件尚未发现。没有LICENSE审查（针对私有产品）、没有SECURITY.md、没有CODEOWNERS。代理不会问的。为什么要问呢。

最终写下的.gitignore覆盖了七类内容：密钥（.env、各种token和secrets文件）、代理状态目录、操作系统文件（.DS_Store、IDE配置）、构建缓存、语音克隆参考文件、根目录渲染产物、日志目录。未跟踪文件从32个降到14个，仍在泄露的密钥路径从7个归零。

刻意保留公开的部分包括：products/、tools/、scripts/、content/、docs/、webhook/、mempalace/和顶层规划文档。这些是AI构建店铺的面向客户部分。审计的目标是消除泄露风险，而非隐藏工作本身。

真正让我后怕的不是.gitignore本身。而是这个模式：当人类退出"检查清单"环节，代理不会自动补位。它们执行计划，但不质疑计划的完整性。六个月的"幸运"不是策略，是债务。

现在每次启动新仓库，我会先放三张纸：密钥清单、公开边界、代理权限。AI能写代码，但定义"什么不该被写进去"仍然是人的工作。至少目前还是。