波仔
🧡 第七章 扩展能力：skill、Hook与MCP
📄 一句话概括

建议靠自觉，强制靠机制；凡是【忘了会造成实际损失】的事，就该交给 hook，而不是写进提醒里。

📝 本节和前面几节的关系

上一节讲做法，这一节讲底线。hook 和 skill 的差别不是强弱，是【靠不靠你记得】。

一、它和 skill 的本质差别

skill 是建议：它被触发时可能被忽略、可能被改写、可能这次做下次不做。 hook 是强制：到点了就跑，跑不跑由不得你。 所以两者不是替代关系——skill 管怎么做，hook 管必须做。

二、什么时候必须用 hook

只有一条判据：忘了会造成实际损失。 具体一点：忘一次会留下垃圾、会把不该发的发出去、会留下你以后要找半小时的烂摊子。 反过来，【忘了只是做得不够好】的事，别上 hook——强制太多，人就麻木了。

三、三个值得先挂的检查

提交前检查：有没有弯引号、有没有残留待办、有没有漏改一半的文件。 交付前检查：临时文件清没清、有没有把不该改的目录改了。 红线检查：这一步谁都不该有权跳过。 本节的演示给了一个能真跑的三项检查器——四个样本文件，过两个、拦两个。

四、一个提醒

hook 也会误伤：检查项写得太严，它会把正常流程卡住。 所以挂之前先在小范围试，别一上来就卡所有动作。 判据是：这个检查如果误报，代价大不大。大就宽松点，小就严一点。

五、动手 Demo：hook——不是建议，是强制执行

下面做一个真能跑的检查器，对四个样本文件过一遍。

def check(name, body):
    bad = []
    if not body.startswith(u"---"):
        bad.append(u"缺 frontmatter")
    if u"\u201c" in body or u"\u201d" in body:
        bad.append(u"弯引号")
    if u"TODO" in body:
        bad.append(u"残留待办")
    return bad

实跑输出：

--------------------------------------------------------------------
hook——不是建议，是强制执行
--------------------------------------------------------------------

这一段是本章最实用的东西。下面做一个真能跑的检查器：

  检查项     命中就说     为什么它是强制的
  -----------------------------------------

    good.md        通过
    bad_quote.md   拦下：弯引号
    bad_fm.md      拦下：缺 frontmatter
    bad_todo.md    拦下：残留待办

三个检查项：缺 frontmatter、弯引号、残留待办。

为什么它必须是【强制】的而不是建议：
    建议靠自觉 —— 你总会忘一次
    强制靠机制 —— 想忘也忘不了
**凡是【忘了会造成实际损失】的事，就该交给 hook，而不是写进提醒里。**

四个样本：过两个、拦两个——检查器不是摆设，它真的会拦。 下面那句是本节的落点：建议靠自觉，强制靠机制，想忘也忘不了。

30 秒实验

  1. 选一件你确实忘过的事（不是假想），写成一条 hook。
  2. 在小范围试一两次，确认不会误伤正常流程，再挂到全局。

常见误区

  1. 把所有规矩都做成 hook。强制太多，人就麻木——只剩真会出事的那几件。
  2. hook 写得太严导致天天误报。误伤一次，你就懒得看它了。
自测三问（点开对答案） 1. hook 和 skill 的本质差别是什么？ —— hook 是强制，到点就跑；skill 是建议，可能被忽略。 2. 什么时候才该上 hook？ —— 忘了会造成实际损失的事；忘了只是不够好的事别上。 3. 为什么 hook 要先小范围试？ —— 检查太严会误伤正常流程；误伤一次你就懒得看它了。

相关笔记