AI-Wiki

文档概览

原文先回答“Loop Engineering 到底该从哪入手”这个问题，作者给出的答案是先看 Hook。

文章的核心判断是：loop 的本质是循环，而任何循环要真正跑起来，首先都需要“触发器”。这个触发器就是 Hook。只要满足某个条件，就自动执行某个命令，这就是最基础的 loop 起点。

作者用生活化类比解释这个概念：

到了 10 点窗帘自动拉开；
识别到人出门后自动关闭灯；
到公司后手机自动切换工作模式；
早上闹钟到点自动响起。

这些都属于“条件触发后执行动作”的模式。在 Agent 系统中，Hook 承担的也是同类角色。

文章随后切回 Claude Code：用户可在底部输入 /hooks 查看可用 Hook 事件。作者提到，他年初看到时只有 13 个事件，到写文时已经接近 30 个，数量翻了一倍多。不过他同时提醒，日常高频真正会用到的，还是其中少数几个关键事件。

在此基础上，原文整理了 6 个作者认为“好玩且实用”的 Hook 场景，用来给读者建立设计直觉。

关键事实

Hook 为什么适合作为入门切口

Loop Engineering 的“loop”强调循环运行。
循环要成立，先要定义“什么时候触发”。
Hook 就是这个“触发时刻”与“触发后动作”的连接器。
对初学者而言，比起一开始就设计复杂 Agent 流程，先做一个明确触发、明确结果的 Hook，理解成本更低，也更容易验证是否有效。

作者的表达非常明确：如果真要说一个适合作为入口的东西，就是 Hook。

Claude Code 中 Hook 的基本使用方式

打开 Claude Code。
在底部输入 /hooks。
回车后可以查看当前可用的 Hook 事件列表。
然后把 Hook 挂到你关心的时刻上，提前定义“什么时候做什么”。

作者强调的是“事情一来，它自己跑”，也就是说 Hook 的意义不在于多一次手动命令，而在于把常见等待、提醒、归档、整理、通知这类动作前置成自动机制。

Hook 与 Token 的关系

文章专门回答了一个常见顾虑：如果频繁触发提醒，会不会很耗 Token。

作者给出的解释是：绝大多数 Hook 本质上就是代码或写死的规则脚本，运行时和 AI 模型本身关系不大，因此通常不会明显消耗 Token。这个判断是文章中很重要的实操认知，因为它把 Hook 从“每次都要重新问模型”区分成“预先设定好的事件脚本”。

不过这一点在涉及 Skill、模型理解文件内容等场景时会变复杂：纯脚本型 Hook 不太耗 Token，但如果触发后还要调用模型能力去分类、总结、识别内容，实际开销就会取决于后续实现方式。

六类典型 Hook 场景

1. 权限弹窗提醒

这是作者首先给出的痛点场景：

用户给 Claude Code 下达任务后切走窗口去干别的事；
过了十分钟回来，发现任务根本没开始；
原因不是模型出错，而是流程卡在“等待用户授权”这一步。

对应做法是配置一个授权提醒 Hook：每当需要用户授权时，就调用系统自带工具弹出通知。

原文的操作思路不是手工一点点写规则，而是直接对 Claude 说：

帮我配置一个通知的 Hook；
每当需要我授权的时候；
调用系统自带的工具给我来一个弹窗提醒。

配置完成后，还可以让 Claude Code 自测。作者描述的结果是：需要授权时，右上角会出现提醒。这样即使你已经切到别的页面，也不会让 AI 因为权限等待而长期卡住，减少空等时间。

这个案例的价值不在“弹窗”本身，而在于它把人机协作中最常见的阻塞点显式化了：当工作流必须等人确认时，Hook 可以把“沉默等待”改成“主动召回用户”。

2. 会话开始播报天气与日程

第二类 Hook 发生在“会话开始”这个时刻。

作者认为，很多人打开 Claude Code 时看到的只是冰冷终端；于是可以把每次打开或恢复会话，变成一个信息播报入口。原文给出的需求包括：

在打开或恢复 Claude Code 时触发；
输出一段有活力的问候；
告诉用户北京朝阳区当天的天气；
说明会不会下雨、要不要带伞；
调用飞书 CLI 拉出当天日程安排；
整体文案尽量有趣。

重新打开 Claude Code 后，这段播报会自动出现。作者把它称作“让原本枯燥的终端多了点温度”。

这个例子说明 Hook 不只能做工程动作，也能做环境初始化和个人工作节奏引导。它既是自动化，也是“进入工作状态”的开场动作。

从 loop 设计角度看，这个 Hook 把“开始一天工作”这个事件结构化了：

触发时机：会话开启或恢复；
获取外部上下文：天气、日程；
输出结果：一段个性化开场信息。

3. 上下文预压缩摘要卡片

这是文中作者认为“最实用”的玩法之一，也是与大模型使用痛点结合得最紧的一项。

作者描述了自己的真实背景：

平时会长期迭代 4～5 个项目；
有时多个项目并行跑；
像 AIHOT 这样较大的项目，甚至会同时开 3 个分支并行；
一天之内反复在多个 Agent 任务之间切换；
到最后，连自己都不一定记得今天到底做了什么。

在这种高频碎片化使用方式下，真正有价值的结论往往埋在长对话里。一旦发生以下情况，回溯成本就非常高：

上下文被压缩；
聊天记录过长；
用户执行了 /clear；
之后想再找当时的结论。

为了解决这个问题，作者做了一个“预压缩摘要卡片” Hook，要求是：

当上下文处于预压缩阶段时触发；
生成一张摘要卡片；
记录当前上下文的概要内容；
文件保存到一个跨项目也可查看的位置；
总结完毕后再打印回 Claude Code 中，方便即时查看。

作者描述的效果是：在上下文快要被压缩、但还没真正丢失之前，系统会先抢先生成摘要卡片。

这类 Hook 的关键价值包括：

把“即将丢失的上下文”转换成可检索资产；
降低回看几万字聊天记录的成本；
形成类似“AI 自动写的工作日记”；
以后查某天做过什么时，不必翻原始长对话，只需翻摘要卡片。

作者进一步提出扩展玩法：再加一个定时 Hook，例如每周五把这些摘要日记自动汇总为周报。这说明 Hook 不只是单点通知，也可以串成更长的闭环：

预压缩时先归档；
周末定时再汇总；
最后形成可复用的工作记录体系。

4. 文件夹自动整理：Hook + Skill 组合

第四类玩法是文件自动整理，也是文章中最清楚展示 Hook 与 Skill 分工的一段。

作者的原始问题很具体：下载文件夹非常乱，截图、文档、PDF 混在一起，每次找文件都要翻很久。于是他想到，不如让 Claude Code 盯着某个文件夹，自动完成分类整理。

整体逻辑是：

指定一个要监听的文件夹；
每当有新文件放进来时触发；
先判断文件是什么、内容是什么；
再自动重命名；
然后移动到应该去的目录。

作者特别强调，文件整理“光靠简单代码搞不定”，所以这里不是只靠 Hook，而是用了“Hook + Skill”的组合技。

文中的类比非常重要：

Hook 是门铃；
Skill 是开门以后真正干活的人。

也就是说：

门铃响了，表示有新东西来了；
但来了之后怎么处理，仍然需要模型能力；
例如识别文件内容、判断归类、按规则重命名、移动到对应目录，这些更适合交给 Skill。

作者还给出几个实现边界与使用条件：

每个人的整理需求不同，所以最好让 Claude 帮你现写一个符合自己规则的 Skill；
该方案要求 Claude Code 持续开着，不能把程序关掉；
它会在后台持续盯着目标文件夹；
发现新文件后，会先等几秒，确认文件已经传输完成，再开始处理。

原文给出的处理结果案例包括：

PDF 和图片都可以识别内容；
会议纪要归到会议目录；
发票归到报销目录；
截图还能按内容自动起一个人能看懂的名字；
然后统一移动到对应文件夹。

作者也指出，这个模式并不限于下载文件夹：

也可以盯工作项目文件夹；

Loop Engineering 入门 Hook 玩法 摘要