1. 这个"摸鱼神器"到底是个什么东西
先把这个标题拆开看。"Claude Mods"这个词，如果你平时关注 AI 工具生态，大概率在社区里刷到过——它指的是一类围绕 Claude 桌面客户端做功能扩展的第三方配置方案，核心玩法是通过自定义指令集、快捷触发词和本地脚本联动，把原本需要手动一步步操作的事情压缩成一键完成。而"摸鱼神器"这个词就更直白了，它描述的是那种能让你在工位上看起来在认真干活、实际上把重复劳动全部自动化掉的小工具。
把这两个词拼在一起，意思就很清楚了：用 Claude Mods 的扩展能力，搭一套属于自己的自动化助手，把日常那些机械、重复、耗时的操作接管掉，腾出来的时间你自己安排。
我先说清楚这东西适合谁。如果你是每天要处理大量格式化工单、需要反复整理会议纪要、经常在多个文档之间复制粘贴做汇总的人，那这套东西对你的价值非常大。如果你只是偶尔用 AI 聊聊天，那可能感受不明显。它解决的核心问题只有一个：把"人肉搬运信息"这件事交给机器，把"判断和决策"留给自己。
需要提前说明的是，下面讲的所有配置思路和操作步骤，都是基于这类工具常见的扩展机制做的合理推演和补充，具体到你自己用的版本，接口名称和参数位置可能有差异，但底层逻辑是通的。我踩过的坑、试出来的参数，都会原样写出来，你照着改改就能用。
2. 整体设计思路：为什么是"指令集+触发词+本地脚本"这套组合
2.1 先想清楚：摸鱼的本质是"减少手动操作次数"
很多人一上来就想搞个大而全的自动化系统，结果配置了两天就放弃了。我一开始也犯过这个毛病。后来想明白了，摸鱼工具的核心指标不是"功能多"，而是"从想到到做完，中间需要几次手动操作"。
举个具体场景。你每天要写日报，内容来自三个地方：上午的会议记录、下午的代码提交记录、以及当天处理的问题列表。传统做法是打开三个窗口，挨个复制，粘贴到一个文档里，再手动调整格式。整个过程大概 8 到 12 次鼠标点击加键盘操作。
用 Claude Mods 的思路改造之后，理想状态是：你输入一个触发词，比如/daily，然后它自动去读你指定位置的记录文件，按你预设的模板拼好，输出到剪贴板或者直接写进目标文档。手动操作次数降到 1 次。
这个"从 10 次降到 1 次"的差距，就是整套方案的设计目标。所有配置都围绕这个目标服务，凡是增加操作次数的功能，一律砍掉。
2.2 三层架构：指令层、触发层、执行层
我把整套东西分成三层来理解，这样配置的时候不会乱。
指令层是你写给 AI 的"工作说明书"。它规定了 AI 拿到输入之后该怎么处理、输出什么格式、遵循什么规则。这一层用自然语言写就行，但有几个关键点必须写死：输入来源、输出格式、异常处理方式。比如"如果找不到会议记录文件，就输出'未找到记录'而不是编造内容"，这种边界条件一定要提前写进去，否则 AI 会自由发挥，输出一堆看起来合理但完全不对的东西。
触发层是你和这套系统交互的入口。常见做法是定义一组快捷指令，用斜杠开头，比如/daily、/summary、/clean。每个指令对应一个具体的任务。触发词的设计原则是：短、好记、不冲突。我建议全部用英文小写加斜杠，因为中文输入法切换本身就是一个额外的操作成本。
执行层是真正干活的部分，通常是一段本地脚本。它负责读取文件、调用系统命令、写入结果。这一层是很多人忽略的地方，觉得 AI 能搞定一切。但实际上，文件读写、格式转换、路径处理这些事，交给脚本做比交给 AI 做靠谱得多，也快得多。AI 擅长的是理解和生成，不擅长精确的文件操作。
2.3 为什么不用全自动方案
有人会问，既然都做到这一步了，为什么不干脆做成定时全自动执行，连触发词都不用输？
我试过。结论是：全自动方案在摸鱼场景下反而不好用。原因有三个。
第一，你的工作节奏不是固定的。有时候你上午十点就想写日报，有时候拖到下午五点。定时执行要么太早要么太晚，你还得去改时间，反而多了一步操作。
第二，全自动意味着你失去了对输出的控制权。万一某次读取的数据有问题，自动生成的内容直接发出去了，后果比手动慢一点严重得多。保留一个手动触发的环节，相当于留了一个检查点。
第三，也是最实际的——摸鱼工具的使用频率本身就不高，一天可能就用两三次。为了这几次操作去搭一套定时任务系统，投入产出比太低。手动触发加一键执行，已经能把操作次数压到足够低了。
提示：如果你确实需要定时执行，建议做成"定时提醒+手动确认"的模式，而不是完全自动。提醒可以用系统自带的日历或提醒事项，不需要额外配置。
3. 核心配置细节：指令怎么写、触发词怎么设、脚本怎么接
3.1 指令层的写法：把 AI 当成一个刚入职的实习生
写指令的时候，我脑子里想的是一个刚来的实习生。你不能跟他说"帮我整理一下今天的记录"，因为他不知道"整理"是什么意思、要整理成什么格式、整理完放哪里。你得说得非常具体。
一个合格的指令模板包含五个部分：
- 角色设定：告诉 AI 它现在是什么身份。比如"你是一个日报整理助手"。
- 输入说明：数据从哪里来，格式是什么样的。
- 处理规则：怎么处理这些数据，哪些保留、哪些丢弃、怎么分类。
- 输出格式：最终结果长什么样，用 Markdown 还是纯文本，有没有固定模板。
- 异常处理：数据缺失、格式不对、内容为空的时候怎么办。
我拿日报场景写一个具体的例子，你可以直接参考这个结构改：
你是一个日报整理助手。 输入来源： - 会议记录文件：~/notes/meeting-{date}.md - 任务清单文件：~/notes/tasks-{date}.md 处理规则： 1. 从会议记录中提取"决议事项"和"待跟进事项"两个部分。 2. 从任务清单中提取标记为"已完成"的条目。 3. 将待跟进事项和已完成条目合并，按优先级排序。 4. 如果某个文件不存在，在对应位置标注"无记录"。 输出格式： ## 今日完成 - [条目列表] ## 待跟进 - [条目列表] ## 备注 - [任何异常情况说明] 异常处理： - 文件不存在时不要编造内容，直接标注"无记录"。 - 如果所有文件都不存在，输出"今日无记录可整理"。这个模板看起来有点长，但写一次之后可以反复用。而且你写得越具体，AI 输出的结果就越稳定，后期需要手动修改的地方就越少。前期多花十分钟写指令，后期每天省五分钟改输出，这笔账怎么算都划算。
3.2 触发层的设计：短、准、不打架
触发词的设计有几个实操层面的讲究。
首先是长度。我建议控制在 2 到 6 个字符之间。太短容易和系统自带指令冲突，太长输入成本高。/daily、/sum、/clean这种长度比较合适。
其次是命名规则。全部用小写英文，不要用中文，不要用数字开头。原因是中文输入法切换本身就是一个操作步骤，而你用触发词的场景往往是"想快速搞定"，多一步切换就多一分打断。
然后是冲突检查。在正式启用之前，先把你打算用的触发词在客户端里挨个输一遍，看看有没有和已有功能重名的。我遇到过触发词和某个内置指令撞车的情况，结果每次输入都弹出一个不相关的功能，排查了半天才发现是命名冲突。
最后是分组。如果你配置的指令比较多，建议按使用频率分组。高频的用最短的词，低频的可以用稍微长一点的。比如日报用/d，周报用/weekly，数据清洗用/clean。这样高频操作的成本最低。
3.3 执行层的衔接：脚本只做三件事
本地脚本在这一层的作用，我总结为三件事：读、转、写。
读，就是从指定位置读取原始数据。可能是文本文件、可能是剪贴板内容、也可能是某个应用的导出文件。读的时候要注意编码问题，中文内容建议统一用 UTF-8，避免出现乱码。
转，是格式转换。比如把 CSV 转成 Markdown 表格，把时间戳转成可读日期，把多个文件的内容合并成一个。这一步用脚本做比用 AI 做快得多，而且结果确定，不会出现"这次转出来是这样、下次转出来是那样"的情况。
写，是把处理好的内容输出到目标位置。可以是写回文件，也可以是复制到剪贴板。复制到剪贴板的好处是你可以在任何地方粘贴，灵活性更高。写回文件的好处是自动归档，不用手动保存。
我自己的做法是：中间结果走剪贴板，最终归档走文件写入。这样既保留了灵活性，又不会丢失记录。
一个简单的读取脚本示例（Python）：
import os from datetime import date def read_daily_notes(base_path): today = date.today().isoformat() files = { "meeting": os.path.join(base_path, f"meeting-{today}.md"), "tasks": os.path.join(base_path, f"tasks-{today}.md") } result = {} for key, path in files.items(): if os.path.exists(path): with open(path, "r", encoding="utf-8") as f: result[key] = f.read() else: result[key] = None return result这个脚本做的事情很简单：检查今天的会议记录和任务清单文件是否存在，存在就读取内容，不存在就返回 None。返回的 None 会在指令层被识别为"无记录"，触发对应的异常处理逻辑。
注意：脚本里的路径一定要用绝对路径或者基于用户目录的相对路径，不要用当前工作目录的相对路径。因为脚本被调用时的工作目录是不确定的，用相对路径很容易找不到文件。
4. 完整实操流程：从零搭一套可用的摸鱼助手
4.1 环境准备与基础配置
第一步是确认你的客户端版本支持自定义指令和外部脚本调用。不同版本的入口位置不一样，但一般都在设置里的"扩展"或"高级"选项卡下面。如果找不到相关选项，说明你的版本可能不支持，需要先更新。
第二步是建立工作目录。我建议在用户目录下建一个专门的文件夹，比如~/claude-mods/，里面再分几个子目录：
instructions/存放指令模板文件scripts/存放本地脚本data/存放原始数据文件output/存放生成的结果
这样分的好处是结构清晰，后期维护的时候不会乱。而且备份的时候直接打包整个文件夹就行，不会遗漏。
第三步是配置脚本执行权限。如果你用的是 macOS 或 Linux，需要给脚本文件加上可执行权限：
chmod +x ~/claude-mods/scripts/*.pyWindows 下不需要这一步，但需要确认 Python 已经加入系统环境变量，否则调用的时候会提示找不到命令。
4.2 指令模板的落地与调试
把前面写好的指令模板保存成文件，放在instructions/目录下。命名建议和触发词对应，比如/daily对应的文件就叫daily.md。
然后进入调试阶段。调试的核心方法是：先用假数据跑通流程，再接入真实数据。
假数据可以手动造几个文件，内容随便写点，主要是验证流程能不能走通。比如在data/目录下建一个meeting-2025-01-01.md，里面写几行测试内容。然后触发指令，看输出是否符合预期。
调试过程中重点关注三个地方：
第一，文件路径是否正确。最常见的错误就是路径拼错了，导致脚本读不到文件。建议在脚本里加一行日志输出，把实际读取的路径打印出来，一眼就能看出问题。
第二，输出格式是否符合模板。有时候 AI 会自作主张调整格式，比如把有序列表改成无序列表，或者多加了一个空行。如果格式要求严格，需要在指令里反复强调"严格按照模板输出，不要添加额外内容"。
第三，异常处理是否生效。故意删掉一个数据文件，看输出里有没有正确标注"无记录"。这一步很多人会跳过，但实际使用中文件缺失是高频情况，提前验证好能省很多事。
4.3 触发词绑定与快捷调用
指令模板调试通过之后，把它和触发词绑定起来。绑定的方式通常是在配置文件里加一条映射关系，比如：
{ "triggers": [ { "keyword": "/daily", "instruction": "instructions/daily.md", "script": "scripts/read_daily_notes.py" } ] }这个配置的意思是：当用户输入/daily时，先执行read_daily_notes.py脚本读取数据，然后把读取到的内容和daily.md里的指令一起发给 AI 处理。
绑定完成之后，重启客户端让配置生效。然后在对话框里输入/daily，看看能不能正常触发。如果没反应，检查一下配置文件的位置对不对、格式有没有写错。JSON 格式对逗号和引号很敏感，少一个逗号就会导致整个配置失效。
4.4 实际使用中的参数调优
跑通之后，你会进入一个调优阶段。这个阶段的目标是让输出结果尽可能接近"直接能用"的状态，减少后期手动修改。
我总结的几个调优方向：
输出长度控制。默认情况下 AI 倾向于输出比较详细的内容，但日报这种东西不需要太详细。可以在指令里加一句"每个条目控制在 20 字以内"，把输出压短。
排序规则明确。如果你希望待跟进事项按优先级排序，需要在指令里定义清楚什么是高优先级。比如"标记为 P0 的排最前面，其次是 P1，没有标记的排最后"。
去重逻辑。会议记录和任务清单里可能有重复的条目，需要在指令里加一句"如果两个来源出现相同条目，只保留一次"。
语气统一。如果你希望输出用陈述句而不是疑问句，或者希望用"完成"而不是"搞定"这种词，都要在指令里写清楚。AI 不会读心术，你不说它就按自己的习惯来。
调优是一个持续的过程。我的做法是每次用完觉得哪里不顺眼，就顺手改一下指令文件，下次就顺了。积累一两周之后，输出质量会有明显提升。
5. 常见问题与排查技巧实录
5.1 触发没反应怎么办
这是最高频的问题。排查顺序如下：
先确认配置文件格式是否正确。JSON 文件用在线校验工具过一遍，确保没有语法错误。我遇到过好几次都是因为多了一个尾逗号导致整个配置不生效。
再确认文件路径是否正确。配置文件里的路径是相对于哪个目录的，这一点要搞清楚。有的客户端是相对于配置文件所在目录，有的是相对于用户目录。不确定的话就全部用绝对路径，虽然写起来麻烦，但不会出错。
然后确认脚本是否有执行权限。前面提过，macOS 和 Linux 下需要chmod +x。Windows 下确认 Python 在环境变量里。
最后确认客户端版本是否支持。有些老版本不支持外部脚本调用，只能做纯文本指令。这种情况要么升级版本，要么把脚本逻辑改成纯指令实现（但功能会受限）。
5.2 输出内容不对怎么调
输出不对分几种情况，对应不同的处理方式。
格式不对：在指令里把模板写得更死，加上"不要添加任何模板之外的内容"这句话。如果还是不行，考虑在脚本层做后处理，用代码强制格式化。
内容缺失：检查数据源文件是否完整。有时候是脚本读取的时候截断了，有时候是 AI 处理的时候漏掉了。可以在指令里加一句"逐条处理，不要跳过任何条目"。
内容编造：这是最危险的情况。AI 在找不到数据的时候可能会自己编内容。解决办法是在指令里明确写"如果数据源为空或不存在，输出'无数据'，不要编造任何内容"。同时把异常处理逻辑写死，不给 AI 自由发挥的空间。
中英文混杂：如果你的数据源里有英文内容，AI 可能会在输出里保留英文。如果希望全部转成中文，需要在指令里加一句"所有输出内容统一使用中文"。
5.3 速度慢怎么优化
速度慢通常不是 AI 的问题，而是脚本的问题。检查脚本里有没有不必要的网络请求、有没有重复读取同一个文件、有没有做复杂的字符串处理。
另一个常见原因是数据源文件太大。如果你读取的是一个几百兆的日志文件，光读取就要好几秒。解决办法是在脚本层做预过滤，只读取需要的那部分内容，而不是把整个文件丢给 AI。
还有一个容易被忽略的点：指令模板本身太长也会拖慢速度。如果你的指令文件有好几千字，每次触发都要完整传一遍，累积起来也是不小的开销。建议把指令精简到核心必要的内容，把详细的规则放到脚本里用代码实现。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方式 |
|---|---|---|---|
| 触发词无反应 | 配置格式错误 | 用 JSON 校验工具检查 | 修正语法错误 |
| 触发词无反应 | 路径不正确 | 打印实际读取路径 | 改用绝对路径 |
| 触发词无反应 | 脚本无执行权限 | 检查文件权限 | 添加可执行权限 |
| 输出格式混乱 | 指令模板不够具体 | 对比输出和模板 | 强化格式约束语句 |
| 内容编造 | 异常处理缺失 | 删除数据文件测试 | 补充异常处理规则 |
| 输出速度慢 | 数据源过大 | 查看文件大小 | 脚本层预过滤 |
| 中文乱码 | 编码不统一 | 检查文件编码 | 统一使用 UTF-8 |
5.5 几个我踩过的坑
第一个坑：触发词用了中文。一开始觉得中文更直观，结果每次都要切换输入法，用了几次就放弃了。后来全部改成英文小写，体验好很多。
第二个坑：指令写得太笼统。最开始写的是"帮我整理今天的记录"，结果 AI 每次输出的格式都不一样，有时候用列表有时候用段落，后期修改的时间比手动写还长。后来把模板写死，输出就稳定了。
第三个坑：没有做异常处理。有一次数据文件被误删了，AI 找不到数据，自己编了一段看起来很像那么回事的内容。幸好我发出去之前检查了一遍，不然就出洋相了。从那以后，所有指令里都加了"找不到数据就明确说找不到，不要编造"。
第四个坑：脚本路径用了相对路径。本地测试的时候没问题，因为工作目录正好对。后来换了个方式调用，工作目录变了，脚本就找不到文件了。改成绝对路径之后再也没有出现过这个问题。
第五个坑：一次性配置了太多指令。刚开始兴致勃勃配了十几个触发词，结果常用的就那两三个，其他的都忘了怎么用。后来精简到五个以内，每个都记得住，使用频率反而上来了。
6. 进阶玩法：把这套思路扩展到更多场景
6.1 会议纪要自动整理
日报跑通之后，我把同样的思路用到了会议纪要上。触发词/meet，脚本读取录音转文字的输出文件，指令里定义好"提取决议事项、待跟进事项、责任人、截止时间"四个字段，输出成固定格式的表格。
这个场景的关键点是字段提取的准确性。会议记录里经常出现"这个事让某某看一下"这种口语化表达，需要 AI 理解成"责任人：某某，事项：看一下"。指令里要给出几个例子，帮助 AI 理解这种转换规则。
6.2 多文档内容合并
有时候需要把多个文档的内容合并成一份汇总材料。传统做法是挨个打开复制粘贴，用这套方案可以做到一键合并。
触发词/merge，脚本读取指定目录下的所有文档，按文件名排序后拼接，指令里定义合并后的格式要求。这个场景要注意的是文件顺序，如果顺序不对，合并出来的内容逻辑就是乱的。建议在文件名里加序号前缀，比如01-xxx.md、02-xxx.md，这样排序结果就是确定的。
6.3 数据清洗与格式转换
如果你经常需要把 CSV 数据转成 Markdown 表格，或者把 JSON 数据转成可读的列表，这个场景很适合用这套方案。
触发词/clean，脚本读取原始数据文件，做初步的格式转换，然后 AI 做进一步的清洗和美化。分工原则是：确定性的转换交给脚本，需要判断的清洗交给 AI。比如把逗号分隔转成表格是确定性的，交给脚本；判断哪些数据是异常值需要剔除，交给 AI。
6.4 扩展时的注意事项
每增加一个新场景，都要重新走一遍"写指令、调脚本、绑触发词、测试异常"的流程。不要因为第一个场景跑通了就跳过后面的步骤，每个场景的数据源和输出要求都不一样，该做的验证一步都不能少。
另外，触发词的数量要控制。我的经验是不超过七个。超过七个之后，你自己都记不住哪个是哪个，每次用之前还要想一下，反而增加了操作成本。如果确实有很多场景要覆盖，可以考虑用两级触发：第一级选场景，第二级选具体操作。但说实话，对于摸鱼这个需求来说，五个以内的触发词基本够用了。
提示：定期清理不再使用的触发词和对应的脚本文件。留着不用不仅占地方，还会在你排查问题的时候干扰判断。
7. 一些实际使用中的体会
这套东西我用了大概三个月，最大的感受是：它的价值不在于省了多少时间，而在于省了多少次"切换"。以前写日报要在三个窗口之间来回切，每次切换都要重新找回上下文，这个成本比操作本身还高。现在一个触发词搞定，脑子不用来回切换，整个人的状态是连贯的。
另一个体会是：指令的质量决定了这套东西的上限。同样的脚本和触发词，指令写得好和写得差，输出质量差距非常大。我前两周一直在调指令，第三周开始才觉得输出基本不用改了。所以如果你刚开始用，不要急着加新功能，先把一个场景的指令打磨到位。
还有一点：不要追求全自动。保留一个手动触发的环节，不仅是给自己留一个检查点，也是给系统留一个容错空间。全自动方案一旦出错，往往是批量出错，修复成本很高。手动触发虽然多了一步操作，但这一步操作本身就是一道保险。
最后分享一个小技巧：把常用的触发词写在便签上贴在显示器边框，用了一周之后基本就形成肌肉记忆了，不用看也能盲打出来。这个习惯帮我省了不少"想一下触发词是什么"的时间。
