三个让我和 AI Agent 更好协作的 Skill：大扫除、抢凳子与白板

这篇文章只讨论可迁移的方法。为避免泄露内部信息，我省略了实际工具名、 本地路径、资源标识、客户信息、账号、基础设施拓扑和操作参数。

AI Agent 提高了我的开发速度，也把三个老问题放大了。

第一，代码、文件、自动化和中间产物会越来越多。Agent 很擅长补东西， 却不会天然知道哪些东西已经失去用户。

第二，多个 Agent 可以同时工作，但数据库、端口、GPU、模拟器和本地服务 仍然只有一份。并行很快就会变成互相覆盖。

第三，系统越复杂，解释越容易漂移。文档说的是设计目标，运行时展示的是 当前行为，日志只证明某件事发生过。它们经常被混成同一种“事实”。

我为这三个问题分别写了三个 Skill。我给它们起的名字是：大扫除、 抢凳子和白板。

一个实体或系统
→ 大扫除：它还该存在吗？
→ 抢凳子：谁现在可以操作它？
→ 白板：大家对它的理解一致吗？

GitHub 仓库： zhaidewei/agent-skills — 三个 Skill 的脱敏、可复用版本与安装说明都在这里。

大扫除：不要按年龄删东西，要按责任删

大扫除不是搜索“六个月没改过的文件”。老代码可能是稳定的权威数据源， 昨天刚生成的文件也可能已经是无人维护的重复品。

我使用的判断链只有几个问题：

它有明确用户和触发时机吗？
→ 它是 Source of Truth，还是从别处生成的 Projection？
→ 如果是 Projection，它相对 Source of Truth 有独特价值吗？
→ 如果有，这个价值靠什么持续维护？
→ 保留 / 告警 / 归档 / 删除

这里最重要的区分是 Source of Truth 和 Projection。

Source of Truth 负责做决定。Projection 负责把决定变成某种更方便的形态， 例如索引、报表、manifest、生成后的配置或缓存。Projection 本身没有问题； 问题是它既不增加独特价值，又没有同步机制，却继续让人以为它可信。

所以我的规则是：

1. 有真实用户、明确触发时机，并且负责一个必要决定的 SoT，保留。
2. Projection 能提供查询性能、兼容性、审计或不同消费形态等独特价值， 并且有生成、校验或过期机制，保留。
3. Projection 有价值但没有维护机制，告警。它现在能用，不代表下个月仍然可信。
4. 没有用户、没有权威职责、没有独特价值的实体，归档或删除。

这个 Skill 真正减少的不是文件数量，而是系统里“看起来像还有效”的错误承诺。

抢凳子：共享资源需要 lease，不只是一个锁

多个 Agent 同时读取文档通常没问题。多个 Agent 同时重建同一个数据库、 重启同一个服务或占用同一个端口，问题就来了。

我把这种协调叫“抢凳子”。凳子不是谁先看见就归谁，而是通过一个所有守约 参与者都承认的登记处取得一个有期限的 lease。

完整模型不是只有 locked / unlocked：

资源定义 + 健康状态 + 并发容量
→ 可用性预检
→ 原子取得有期限的 lease
→ 执行操作
→ 检查结果和健康状态
→ 释放

我通常把操作分成三类：

• read：已经证明没有副作用的观察和查询；
• write：普通写入、触发任务，以及无法证明无副作用的操作；
• destroy：停止、重启、重建、删除，或会打断现有使用者的动作。

几个边界很重要。

可用性检查不是占位。检查结束到真正执行之间，其他 Agent 仍然可能拿走资源， 所以最终必须原子取得 lease。Lease 必须有 TTL，长任务要续租，成功、失败、 取消和交接时都要释放。没有无限期占座。

它也不是安全系统。Lease 只能协调愿意遵守规则的参与者，不会替 Agent 获得 新的权限，更不能替代数据库权限、操作系统隔离或云端 IAM。

这个 Skill 减少的是并行工作的“隐性碰撞”。它让冲突变成一个可以看见、 等待和解释的状态，而不是两条任务互相破坏以后再猜发生了什么。

白板：把系统讲成因果关系，不要讲成术语表

我经常遇到一种文档：每个名词都有定义，读完仍然不知道出问题时该相信谁。

白板 Skill 的目标不是摘要文档，而是建立一个别人可以复述的因果模型。 我常用的主链路是：

外部事实
→ 内部 Authority / Source of Truth
→ Projection / Manifest
→ Runtime 执行
→ Evidence / Lineage / Outcome
→ Consumer 查询与解释

这条链不是模板填空。系统里没有的层不能凭空发明。但几个问题必须回答：

1. 每个对象负责什么，又明确不负责什么？
2. 它读取谁，谁又读取它？
3. 两个对象冲突时，谁有裁决权？
4. 关系是一对一、一对多，还是多对多？
5. 当前版本能否解释历史事实，还是必须使用当时的 exact version？
6. 日志和 evidence 证明了什么，又没有证明什么？
7. 零匹配、多匹配、缺失证据和运行时漂移时，系统进入什么状态？

“系统应该怎样”与“实际发生了什么”必须分开。配置表达意图，runtime 执行， 日志记录结果。日志不能因为最接近现场，就自动升级成 Source of Truth。

好的白板解释会先给结论，再画一条因果链，然后给出 6–12 条可以直接复制的 编号心智模型，最后列出几个长期不变量。目标是让读者离开白板后，能够自己 判断新的情况，而不是背下我的术语。

三个 Skill 放在一起

假设几个 Agent 正在维护一个共享的本地测试环境。

大扫除先判断重复的配置、缓存和旧脚本是否仍有用户，谁是 SoT，哪些只是 Projection。它降低系统里需要被理解和维护的对象数量。

抢凳子随后决定谁可以读取环境、谁可以写入，以及谁可以执行会中断其他人的 重建。它降低并行执行时的冲突。

白板最后把配置、生成产物、运行服务、日志和测试结果放回正确的因果位置。 它降低人和 Agent 对系统的理解偏差。

三者处理的是同一类问题：不要让速度制造出来的熵，超过团队理解和治理它的速度。