用 daily 仓库管理日常运维和 AI 协作

维护服务器时，最容易遗忘的往往是一次操作背后的细节：某个服务为什么换了端口，上次故障改了哪份配置，部署脚本放在哪里，以及当时用什么方法确认问题已经解决。

把这些信息保存在一个私有 Git 仓库里。日常使用时，在项目中向 AI 助手提出任务，让它先查阅相关记录，再执行工作、验证结果，最后把新的技术点和脚本归档。下一次处理同一主题，就有了可以继续使用的上下文。

这个仓库的内容以服务器运维、网络配置和自动化为主，也包含音频生成等日常工具。使用它的入口是任务和文档；具体工具在各自目录中运行。

daily 是我的私有 git 的仓库名称。

AGENTS.md 项目协作规则

项目根目录的 AGENTS.md 定义了会话归档和 Git 操作约定，内容如下：

## 本目录工作要求

 - 会话开始前，必须确定此会话的id，id可以是以下形式顺序确定：
   - 当英文字母开头遇到空格的时候，这串英文字符就是id：举例 nginx 重启，id为 nginx
   - 会话明确指定id：举例 会话id是 zhangzhang，id为 zhangzhang
   - 网址：举例 https://dmit.io，id为 dmit.io
   - 服务器命名：举例 这是 aivps 的信息，id为 aivps
   - IP地址：举例 登录 10.0.22.21 查看服务器磁盘大小，id为 10.0.22.21
   - 技术名称：举例 使用 wireguard 将这3台服务器组网，id为 wireguard
   - 专有名词：举例 调整 special.list 路由，id为 路由的英文 routing
 - 确认此会话的id以后，优先在会话中输出给我看，在同一个会话当中，id是不会变的
 - 在 docs 目录寻找相关文件名:
    - 会话执行完以后将相关的技术点更新到该文件
    - 寻找不到相关文件名就创建对应的 md 文件
    - 会话执行中产生的脚本等文件，放入到同样名称的文件夹中
    - 举例：dmit.io 网站购买的 vps 信息放在了 docs/dmit.io.md 位置，这些 vps 进行 wireguard 组网等脚本放在了 docs/dmit.io/ 文件夹
 - 线上服务器默认备份目录：/root/backup/
 - 登录服务器默认密钥使用 ~/.ssh/id_rsa

 ## Git 约定

 - 默认 git 是个私密 git，不会对外公开
 - 用户已要求：以后每次改动后，按改动范围自己 先 `git pull --rebase`、`git add` 和 `git commit`，然后 `git push`，需要的 PrivateKey 路径 和 Passphrase 在 .env 文件中
 - 提交只包含本轮相关文件，不要把无关生成物混进去。
 - 生成物和依赖目录应保持 ignored，写入.gitignore
 - 提交信息明确，例如：
   - `修复：调整窗口标题栏布局`
   - `文档：添加代理指南`
   - `新增：更新工作区路径`
 - git pull、git push 的 PrivateKey 和 Passphrase 在 .env 文件中

目录怎样组织

仓库的组织方式很简单：根目录放协作规则，docs 保存长期记录，每个主题还可以有一个同名目录存放配套文件。下面用虚构的 web01 服务器和 nginx 主题演示这种结构：

daily/
├── AGENTS.md
├── .gitignore
├── .env
└── docs/
    ├── web01.md
    ├── web01/
    │   └── check-disk.sh
    ├── nginx.md
    └── nginx/
        └── example.conf

AGENTS.md 约定助手在这个项目里怎样工作，包括如何确定会话 ID、文档和脚本放在哪里，以及怎样提交 Git 改动。docs/web01.md 保存服务器相关记录；docs/web01/ 则保存可复用的脚本、配置等文件。

这样查找资料时，可以先阅读主题文档，了解背景和使用条件，再进入同名目录查看实现。即使暂时不用 AI，也可以直接阅读文档和运行经过检查的脚本。

用会话 ID 确定任务归属

每次会话开始，先确定一个 ID，并在会话中输出。这个 ID 在同一次会话里保持不变，用来定位相关记录和配套目录。

最直接的写法是在请求开头放一个英文主题，后面接空格和具体任务：

web01 检查服务器磁盘使用情况，只读检查，记录大目录和处理建议

这次会话的 ID 就是 web01。助手应先查阅 docs/web01.md，结束后把本次技术点更新到该文件；如果需要编写检查脚本，就放入 docs/web01/。

项目还支持从明确指定的 ID、网址、服务器名、IP 地址或技术名称中确定归属。例如：

请求示例	会话 ID
`nginx 检查配置并记录排查结果`	`nginx`
`这次会话的 ID 是 web01，检查备份任务`	`web01`
`检查 https://example.com 的证书`	`example.com`
`登录 192.0.2.10 查看磁盘大小`	`192.0.2.10`

上面的域名、地址和服务器名仅作示例。实际使用时，尽量沿用已经存在的主题名称，可以减少同一件事散落在多个文档里的情况。

把任务目标和执行范围说清楚

一个好用的请求通常包含操作对象、目标和限制条件。例如，排查问题时可以这样写：

web01 先阅读已有记录，再检查磁盘为什么接近满容量。
本轮只做只读检查，不删除文件、不重启服务。
记录主要占用目录、判断依据和后续处理建议。

需要实际修改配置时，可以说明允许执行的动作和验证标准：

web01 调整已经确认需要修改的日志保留配置。
修改前备份原配置，修改后检查配置语法和服务状态，
把变更位置、验证结果及回退方法更新到文档。

仓库约定线上服务器的默认备份目录是 /root/backup/，登录服务器的默认 SSH 密钥是 ~/.ssh/id_rsa_nopassword。执行时仍需核对目标主机的用户、端口和实际配置。备份可以按任务和时间建立子目录，让文档中的回退说明能够指向明确的位置。

“先查记录、再检查环境、执行变更、验证结果”适合多数运维任务。验证要对应任务目标：检查配置语法只能说明配置能否解析，服务状态说明进程是否运行，对外访问测试才能进一步确认用户实际使用的链路。

任务结束后留下可复用的记录

项目要求在会话结束后，把相关技术点更新到已有主题文档；找不到对应文件时再创建。记录的价值在于，下一次遇到问题时，能够据此继续工作。

一条实用的记录可以写清楚这些内容：

日期、操作对象和问题现象。
关键判断及其依据。
修改过的配置、脚本和备份位置。
实际执行的验证及结果。
尚未解决的问题，以及需要时如何回退。

对于持续维护的主题，可以在同一个文件中按日期追加记录。如果新操作替代了旧方案，也要注明旧方案已经停用，避免以后照着过期步骤操作。

脚本则保存到同名目录中。例如检查磁盘的脚本位于 docs/web01/check-disk.sh，文档应解释它检查什么、如何运行，以及是否会修改系统。可复用脚本和配置值得保留，依赖目录、缓存、构建产物及临时输出则按 .gitignore 管理。

用 Git 保存每一次相关改动

这个项目约定，每轮改动完成后先执行 git pull --rebase，再暂存、提交并推送本轮相关文件。提交信息应说明具体改了什么，例如“文档：记录 web01 磁盘检查结果”。

本项目把 Git 认证所需的私钥路径和口令配置在根目录 .env 中，字段为 PrivateKey 和 Passphrase。它与登录服务器的 SSH 配置承担不同用途，使用前应分别确认。私钥内容和口令不要复制进博客或操作日志。

仓库按私有仓库使用，其中可能包含实际连接信息和环境配置。对外分享时，应单独整理需要公开的文章和示例。新建自己的同类仓库时，可以先配置敏感文件的忽略规则，再放入本地凭据；.gitignore 不会自动移除已经被 Git 跟踪的文件。