iFlow CLI hook实战：Windows下打造个性化任务完成通知-平芜编程栈

开头

最近我一直在用一个叫 iFlow 的任务管理工具，日常把它挂在命令行里，随手抓任务、写待办。用得多了就开始不满足于它默认那套提醒方式：任务完成的时候，屏幕上顶多弹个系统通知，消息内容固定，也没有任务详情。我想要的其实是更“懂我”的通知——完成重要任务时弹窗提醒附带任务名，普通任务只在日志里留一条记录，有的任务还得顺手触发一个联动动作。折腾了一圈，发现 iFlow 的 CLI 提供了一个 hook 机制，正好能把通知这件事完全变成自己的脚本。这篇文章就把我在 Windows 下用 iFlow CLI 配置 hook、定制任务完成通知的完整过程写出来，包括原理、配置、脚本和踩坑记录。

如果你也是那种任务多到“通知不过来”的人，或者你手里的工具已经支持类似的事件钩子但没有玩明白，这篇内容可以直接照着抄。下面是从思路到实操的完整过程。

1. 为什么是 hook：任务通知的常规方案与 hook 机制的取舍

先说一个朴素的问题：为什么非要用 hook 来做通知？很多人会觉得，任务管理工具不是自带提醒吗？命令行里敲一行iflow remind不也能弹提醒？确实能，但我自己用下来的感受是，现成的通知方案在真正高频、长期使用时会暴露三个问题。

1.1 常规通知方式的三个瓶颈

第一个瓶颈是通知渠道太固定。内置通知基本就是系统弹出框加声音，顶多再亮个角标，你没办法把任务标题、完成时间、标签这些上下文信息格式化之后推到别的地方。

第二个瓶颈是触发时机太死板。大部分任务工具的提醒都围绕“到期时间”来做，临到点了提醒你该做了；但“任务真的被标记为完成”这个瞬间，内置提醒往往没有对应的钩子。对我来说，恰恰是完成的那一刻最有价值——我需要知道一天里到底完成了哪些事，而不是只听一遍“该做某事了”。

第三个瓶颈是定制成本高。如果你想要“任务完成后往某个协作工具的群里发一条消息”，或者“自动给某个文件追加一条记录”，内置通知根本做不到。早期我以为这类需求得靠插件体系，后来发现用 CLI 的 hook 就能解决，而且解决得比插件更轻量。

1.2 hook 机制的运作逻辑

hook 在我的理解里就是一个“事件门铃”。你按了门铃，屋里就会响铃，但响铃之后屋里的人具体做什么，完全由你决定。任务管理工具的生命周期里有很多事件：任务创建、任务开始、任务完成。这些事件一旦发生，工具会去查一下“有没有用户注册的 hook”，如果有，就执行用户配置好的命令。

放在 iFlow CLI 的场景里，逻辑就是这样一条链：你在终端里执行iflow task done或者用快捷键把某个任务标记为完成 → iFlow 内部触发 task.completed 事件 → CLI 检查 hook 配置，发现有对应的命令 → 拉起一个子进程执行你写的脚本 → 脚本负责弹窗、发通知、写日志。

这条链路的最大优势是解耦：iFlow 只负责“到点喊你”，至于喊完之后你干什么，它完全不管。这和我之前用过的笨办法完全不一样。以前我会写一个轮询脚本，每隔几秒钟查一次任务列表，看有没有新完成的任务。轮询的问题是延迟高、浪费资源、还会漏状态。hook 是事件驱动，任务完成的瞬间就是脚本执行的瞬间，没有中间商赚差价。

1.3 为什么是“CLI + hook”而不是插件体系

我曾经也想过，要不要等官方插件体系成熟了再做这些事情。后来实际对比下来，CLI + hook 的方式有它独特的好处。

CLI 是天然可脚本化的。你不需要学习一套插件 API，不需要处理 SDK 版本兼容问题，只需要写一个能跑的批处理脚本或 PowerShell 脚本，然后用命令行参数把任务数据传进去就行。这意味着我可以复用以前所有的脚本经验，比如调用curl或Invoke-RestMethod发 Webhook、用[System.Windows.Forms.MessageBox]弹窗，这些都是通用技术，不绑死在工具上。

另外，调试链路更透明。插件体系出问题的时候，很多时候你只能看日志猜；而 hook 执行的是一个命令，我可以先手动跑一遍命令看输出、看退出码，再挂到 hook 上验证。这种“先手工调通，再接自动化”的调试方式，对我的习惯来说太友好了。

方案	定制空间	技术门槛	调试难度	与外部系统联动
内置通知	低，只能改开关	无	无需调试	不支持
插件体系	高	需要学插件 API	依赖平台日志	取决于插件能力
CLI + hook	高，任意脚本语言	会写命令即可	可手动模拟命令调试	天然支持

所以对我来说，hook 不是“多一个功能”，而是把“任务完成通知”从一个死板的功能变成了一个可以完全掌控的自动化流程。

2. iFlow CLI hook 配置基础：看懂参数、结构与触发链路

在写通知脚本之前，得先把 iFlow CLI 的 hook 配置结构摸清楚。我拿到的版本具体命令格式可能和你手上的略有差异，但核心要素是通用的：事件、命令、参数、超时。下面我按照我配置时的思路来拆解。

2.1 CLI 的基本节奏：先建立上下文

如果你已经很熟悉 iFlow CLI 的基础用法，可以直接跳过这一段。不熟悉的，先建立一下上下文，不然 hook 挂在哪里会有点绕。

我日常的节奏是：用iflow task add添加任务，用iflow task list查看今天要做什么，做完之后用iflow task done <任务ID>把它标记为完成。hook 要监听的就是“标记为完成”这个动作，也就是 task.completed 事件。

在开始配置 hook 之前，可以先执行一下iflow --help和iflow hook --help，看看当前的 CLI 对 hook 提供了哪些指令。有些版本是iflow hook add，有些版本是编辑配置文件再 reload，形式不一样，但背后都是同一套事件模型。我的建议是先跑一下帮助命令，确认你手里的版本用的是哪种方式。

2.2 核心配置项拆解：事件、命令与参数

hook 配置虽然不同版本有差异，但拆开来看就几个核心字段，理解了字段，任何版本都能快速上手。

事件名是最重要的。我配置的是 task.completed，但要注意区分大小写，事件名写错了 hook 不会触发，而且很多时候 CLI 不会给你明显报错，只会静默忽略。另一个常见写法是 task:completed 或者 on_task_completed，具体以你版本的文档或者--help为准。

命令字段指定要执行的程序。我一般不会直接在这里写复杂脚本，而是写一个批处理文件或 PowerShell 脚本的路径，因为直接写一长串命令会有转义和引号的坑，脚本文件则可以用更完整的逻辑。

参数是 hook 配置里最灵活的部分。我希望在通知里看到任务标题、完成时间这些信息，所以参数里要注入模板变量。比如{task.title}代表任务标题，{task.completed_at}代表完成时间。具体的占位符命名每个版本可能不同，可以在帮助信息里搜一下 variables 或 tokens 相关的说明。

shell 字段指定用哪个解释器来执行命令。在 Windows 下一般是 cmd 或 powershell。这个字段直接影响后面命令的写法：用 cmd 就得按批处理的转义规则处理，用 powershell 就要注意执行策略。我实际配置的时候选择的是 cmd，然后让批处理在内部调用 PowerShell 脚本，这样两边的转义问题能分离，调试起来清晰很多。

还有一个容易忽视的字段是超时时间。任务完成事件触发的时候，不应该让用户等太久。如果脚本里写了网络请求，或者弹窗阻塞了没有点确定，hook 进程可能会挂在那里。所以我给 hook 设置了一个超时，比如 15 秒，脚本卡住了就不管它，至少不阻塞我的终端。这个字段叫 timeout，单位一般是秒。

2.3 Windows 环境的关键准备

我在 Windows 上配置这个 hook 时，环境层面的坑比配置本身的坑更多，所以专门整理了一下前置准备。

首先是 PowerShell 执行策略。如果你的 hook 命令是直接调 PowerShell 脚本，默认情况下可能被系统拦截，报一个“因为在此系统上禁止运行脚本”的错误。可以用：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

这条命令允许本机创建的脚本运行，同时远程下载的脚本仍需要签名。我建议只用 CurrentUser 范围，不要动机器级别的策略。

其次是编码问题。Windows 的 cmd 默认代码页是 936，也就是 GBK，而现代工具默认输出 UTF-8，这会导致中文变量在脚本里显示成乱码。最简单的办法是在批处理开头加一句：

chcp 65001 >nul

同时，脚本文件本身要保存为 UTF-8 with BOM 编码。用记事本或者 VSCode 保存时留意一下编码选项，如果发现弹窗里中文是乱码，第一反应先查编码，而不是查逻辑。

最后是路径写法。Windows 下路径里经常有空格，如果 hook 命令配置里的路径没有用双引号包起来，命令会被拆成多段，执行直接失败。我统一用绝对路径，并且每次都在路径外面加引号，这个习惯避免了很多低级问题。

在正式写通知脚本之前，我强烈建议先做一个“链路验证”：配置一个最简单的 hook，只往一个日志文件里写一行字。这样你能先确认“事件→hook→脚本执行”这条链路是通的，再往里填通知逻辑。先做通链路，再做深功能，这个顺序能省掉大量排查时间。

3. Windows 下自定义通知脚本：弹窗、声音与联动应用

链路通了之后，剩下的就全是脚本的活了。这一节我把 Windows 下几个常见的通知实现方式逐个展开，从单纯的弹窗到声音，再到联动外部应用。通知脚本的价值不在于代码多复杂，而在于你能把任务上下文准确、美观地呈现出来。

3.1 弹窗通知：从 VBS 到 PowerShell 的方案对比

Windows 下弹窗有好几种实现方式，我逐一试过，先说结论再解释。

方案	实现方式	稳定性	样式	备注
msg 命令	`msg %username% 内容`	受系统服务限制	古典	部分 Windows 版本不能用
VBScript	`MsgBox("内容")`	稳定	古典	需要临时生成 .vbs 文件
PowerShell + WinForms	MessageBox 类	稳定	可自定义图标按钮	推荐
mshta + HTML	HTA 弹窗	不稳定	可写 HTML	边缘方案，自求多福

我最推荐的是 PowerShell 加 System.Windows.Forms 的方案。理由很简单：不用生成临时文件，可以直接在脚本内引用程序集，而且可以设置标题、按钮、图标，比顽固的 VBS 弹窗好看一点。

基础弹窗的脚本长这样：

param( [string]$TaskTitle, [string]$TaskTime ) Add-Type -AssemblyName System.Windows.Forms $message = "任务「$TaskTitle」已完成`n`n完成时间：$TaskTime" [System.Windows.Forms.MessageBox]::Show( $message, "任务完成通知", [System.Windows.Forms.MessageBoxButtons]::OK, [System.Windows.Forms.MessageBoxIcon]::Information )

这里要注意两个细节。第一，脚本开头用param声明参数，这样从批处理调用时可以用-TaskTitle "xxx"的方式传参，比$args[0]可读性好很多。第二，$message里的反引号和n是 PowerShell 的换行转义，写在双引号字符串里才有效。如果写了一堆n都变成字母 n，八成是用了单引号。

3.2 声音与视觉提醒：让通知更有存在感

有些任务完成的时候我就坐在电脑前，看一眼就完事了，不需要弹窗打断工作流。但有些重要任务完成的时候，我希望明确听到一个反馈。这时候声音提醒就很有用。

Windows 下最朴素的声音方案是控制台蜂鸣：

[console]::beep(1200, 500) [console]::beep(1500, 300)

这段代码会让扬声器发出两个不同频率的短音，类似“叮咚”的效果。注意，beep方法在 Windows 服务会话里可能没有效果，但在普通用户桌面会话下没问题。如果你在终端里直接运行没声音，先确认当前环境是不是交互式会话。

想要更柔和一点的效果，可以调用系统内置提醒音：

[System.Media.SystemSounds]::Asterisk.Play()

这个声音和 Windows 系统通知的声音一致，辨识度高。更进一步的方案是播放自定义音频文件，用SoundPlayer：

$player = New-Object System.Media.SoundPlayer "C:\path\to\finish.wav" $player.Play()

这里有一个采坑经验：Play()是异步播放，如果脚本马上结束，声音有可能被截断。短音频文件影响不大，但如果音频较长，建议改用PlaySync()，或者让脚本等待几百毫秒再退出。

我把声音和弹窗组合成了一段脚本逻辑：先播放两个提示音，再弹窗。实际体验下来确实比纯弹窗更能引起注意，尤其是我开着多个终端窗口、根本没注意到 Windows 通知角落里弹出的提示时。

3.3 联动外部应用：用 Webhook 把任务消息推送到协作平台

弹窗通知只能覆盖本机，远程的情况就覆盖不到了。比如我有时候在另一个环境里完成任务，希望消息能推送到团队协作工具，或者至少送到手机上的某个通知渠道。这时候就得靠 Webhook。

Webhook 的原理很简单：别人给你提供一个 URL，你用 HTTP POST 把数据发过去。不管是企业微信、钉钉、飞书还是 Slack，工作原理都差不多，差别只是消息体格式。我用 PowerShell 的Invoke-RestMethod来实现，代码量很小：

param( [string]$TaskTitle ) $body = @{ msgtype = "text" text = @{ content = "任务完成：$TaskTitle" } } | ConvertTo-Json -Depth 5 $webhookUrl = "https://example.com/hook/your-token" Invoke-RestMethod -Uri $webhookUrl -Method Post -Body $body -ContentType "application/json; charset=utf-8"

这段代码把任务标题包成一个 JSON 消息，POST 到 Webhook 地址。模板消息字段要对着你用的平台格式调整，有些平台要求content字段，有些要求markdown，原理相通，照葫芦画瓢即可。

唯一要提醒的是网络请求增加的不确定性。hook 脚本如果卡在网络请求上，任务完成的反馈就会变慢。所以我把 Webhook 调用放进了 try/catch 块，并且设置一个短超时。脚本宁可失败，也不能拖慢主流程。

3.4 把任务信息注入通知：变量占位符与转义细节

上面的脚本都需要接收任务标题、完成时间等参数，那这些参数从哪里来？答案是 hook 配置里的变量占位符。

当我配置 hook 参数时，写的是类似这样的东西：

{ "args": "-TaskTitle \"{task.title}\" -TaskTime \"{task.completed_at}\"" }

执行的时候，iFlow CLI 会把{task.title}替换成实际的任务标题，把{task.completed_at}替换成完成时间，然后再把完整命令交出去执行。这个机制让我不用在脚本里再去查询任务数据，直接把上下文带进脚本。

但这里有个容易踩的坑：如果任务标题里本身包含空格、引号或者特殊字符，替换之后命令行就乱了。所以参数里的模板变量一定要用引号包住，同时在脚本内部再对参数做一次防御性清理。我在脚本里加了简单的判断，为空时给个兜底文案，避免因为一个空标题导致弹窗上出现大空白：

if ([string]::IsNullOrWhiteSpace($TaskTitle)) { $TaskTitle = "未命名任务" }

之所以强调这些细节，是因为 hook 是自动化链路，它不像手动执行脚本那样每次都会盯一眼。无人值守场景下，脚本必须自己做好防御，不然一个小意外就会让通知链路安静地失效。

4. 实操过程：配置一套完整的“任务完成通知”个性化方案

理论部分说得差不多了，这一节我放一套完整可复制的实操流程。我会创建一个任务完成通知的演示场景：任务标记为完成之后，播放提示音、弹出带任务标题的窗口、写一条日志、向协作平台推送一条消息。每一步都会写清楚怎么操作以及为什么要这么操作。

4.1 准备阶段：建立脚本目录与测试任务

我先在D:\scripts\iflownotify目录下建好了脚本的“家”。目录单独放，有两个好处：一是 hook 配置里引用这个绝对路径，以后不会因为当前工作目录变化而找不到脚本；二是脚本产生的日志、临时文件都集中在一起，排查问题的时候不用到处找。

同时我在 iFlow 里加了一个测试任务，标题是“写一篇任务自动化通知博文”。之所以用中文标题做测试，就是为了提前暴露编码问题。如果中文标题都能处理干净，英文和特殊字符基本也不会有大问题。

4.2 编写通知脚本：一个可扩展的完整示例

我在目录下建了一个 PowerShell 脚本notify.ps1。结构上分成两块：第一块是收参数，第二块是按参数执行通知动作。

param( [string]$TaskTitle, [string]$TaskTime ) if ([string]::IsNullOrWhiteSpace($TaskTitle)) { $TaskTitle = "未命名任务" } if ([string]::IsNullOrWhiteSpace($TaskTime)) { $TaskTime = Get-Date -Format "yyyy-MM-dd HH:mm:ss" } # 记录日志 $logDir = "D:\scripts\iflownotify\logs" if (-not (Test-Path $logDir)) { New-Item -ItemType Directory -Path $logDir -Force | Out-Null } $logLine = "$TaskTime`t$TaskTitle" Add-Content -Path "$logDir\completed.log" -Value $logLine -Encoding UTF8 # 播放声音 [console]::beep(1200, 500) [console]::beep(1500, 300) # 弹窗提醒 Add-Type -AssemblyName System.Windows.Forms $message = "任务「$TaskTitle」已完成`n`n完成时间：$TaskTime" [System.Windows.Forms.MessageBox]::Show( $message, "任务完成通知", [System.Windows.Forms.MessageBoxButtons]::OK, [System.Windows.Forms.MessageBoxIcon]::Information ) # 推送 Webhook（通过 try/catch 防止脚本卡住） try { $body = @{ msgtype = "text" text = @{ content = "任务完成：$TaskTitle" } } | ConvertTo-Json -Depth 5 $webhookUrl = "https://example.com/hook/your-token" Invoke-RestMethod -Uri $webhookUrl -Method Post -Body $body -ContentType "application/json; charset=utf-8" -TimeoutSec 5 } catch { $errLog = "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')\tWebhook 推送失败: $($_.Exception.Message)" Add-Content -Path "$logDir\notify-errors.log" -Value $errLog -Encoding UTF8 }

脚本的逻辑是按部就班的：先把任务标题和完成时间变成安全字符，再写日志，然后出声、弹窗、推送。把 Webhook 放在最后一个环节，是为了避免网络问题阻断前面的通知。这个顺序我建议不要颠倒了——弹窗和声音是本地反馈，必须优先保证。

4.3 配置 hook 并注册：把脚本挂到完成事件上

脚本写好了，接下来要告诉 iFlow CLI：任务完成事件触发时，运行notify.ps1，并且传入任务标题和时间。

在支持iflow hook add的版本里，大致命令形式如下：

iflow hook add --event task.completed --command "powershell -ExecutionPolicy Bypass -File D:\scripts\iflownotify\notify.ps1" --args "-TaskTitle \"{task.title}\" -TaskTime \"{task.completed_at}\"" --timeout 15

如果版本是配置文件驱动的，那就找到 iFlow 的配置文件，在 hooks 节点下加一段：

{ "hooks": { "task.completed": { "command": "powershell -ExecutionPolicy Bypass -File D:\\scripts\\iflownotify\\notify.ps1", "args": "-TaskTitle \"{task.title}\" -TaskTime \"{task.completed_at}\"", "timeout": 15 } } }

这里有两个细节。第一，我用了powershell -ExecutionPolicy Bypass，而不是全局去改系统执行策略。这个参数只对本次启动的 PowerShell 有效，既绕过了执行策略限制，又不会影响系统安全设置。第二，args 里的引号是转义过的，正常情况下应该能够在空格和特殊字符存在时正确传参。

配置完记得重新加载配置或者重启 iFlow CLI 的守护进程。这一步经常被忽略，配置写完了半天不生效，回头一看是没重载，白白浪费几分钟。

4.4 触发与观察：验证通知链路是否通畅

配置完成后，我就去 iFlow 里把“写一篇任务自动化通知博文”这个任务标记为完成。

预期结果应该是：终端旁边会响起两段提示音，屏幕上弹出内容为“任务「写一篇任务自动化通知博文」已完成”的窗口，同时completed.log文件里新增了一行记录，协作平台里收到一条消息。

我自己实操时第一次出现的问题是弹窗没出来，但日志文件里已经写入了内容。这说明事件触发了、脚本也执行了，问题出在弹窗环节。排查之后发现是因为我从一个非交互式会话里测试，用户桌面看不到弹窗。改成正常终端里完成任务后，弹窗就正常出来了。

验证链路的关键思路是分步确认：先看日志文件有没有更新，如果没有，说明事件或 hook 配置有问题；如果日志有更新但弹窗没出现，说明脚本中弹窗这部分有问题。这种逐级排查的方法，比单纯盯着“通知不出来”这个问题瞎猜要高效得多。

4.5 进阶玩法：按任务类型走不同通知规则

上面的脚本把所有任务都当同等重要处理，但实际使用时，普通任务和重要任务的反馈应该不一样。普通任务完成时，写个日志就够了，频繁弹窗反而让人烦躁；重要任务完成时，才值得弹窗加推送。

我在脚本里加了一个开关参数，用任务标签或者任务优先级决定通知级别。假设 iFlow 的模板变量支持{task.priority}，可以把优先级值传进来：

{ "args": "-TaskTitle \"{task.title}\" -TaskTime \"{task.completed_at}\" -Priority \"{task.priority}\"" }

然后在脚本开头用优先级做分支：

param( [string]$TaskTitle, [string]$TaskTime, [string]$Priority ) $isHighPriority = ($Priority -eq "high" -or $Priority -eq "重要") if ($isHighPriority) { # 弹窗 + 声音 + Webhook } else { # 只写日志 }

这样的思路非常实用：不是说所有通知都要最大声，而是根据任务的重要程度分配注意力。通知的本质是信息分发，不是声音越大越好。按优先级做分流之后，我反而觉得“完成通知”的可感知度提高了—真正重要的事情不会被一堆普通通知淹没。

5. 常见问题与排查技巧实录

坑踩得多了，自然就有了清单。这一节我把 Windows 下配置 iFlow CLI hook 做任务完成通知时最容易遇到的高频问题整理成一张速查表，然后是排查套路和避坑心得。

5.1 高频问题速查表

问题表现	可能原因	解决办法
hook 完全没有触发	事件名写错；配置未重新加载；CLI 版本不支持该事件	查阅帮助信息确认事件名；重载配置文件；升级 CLI
日志文件没更新	hook 命令路径错误；脚本权限不足；工作目录不对	确认命令用绝对路径；手动执行脚本验证
弹窗一闪而过	PowerShell 窗口执行完成后自动关闭；弹窗进程被阻塞	先用终端手动执行脚本观察；弹窗脚本单独进程运行
中文内容是乱码	脚本文件编码不是 UTF-8；cmd 代码页不是 65001	脚本保存为 UTF-8 with BOM；批处理开头加 chcp 65001
路径含有空格时命令执行失败	路径没有加引号	所有路径用双引号包裹，必要时转义嵌套引号
模板变量没有替换成真实任务数据	占位符命名写错；大小写不一致	查看帮助信息里的变量列表；复制原文而不是手敲
PowerShell 无法运行脚本	执行策略禁止脚本运行	使用`-ExecutionPolicy Bypass`参数启动脚本
弹窗正常但声音不响	非交互式会话；音频服务异常；`beep`在服务会话失效	确认在桌面会话执行；用`SystemSounds`替代`beep`

这张表我每次配置新环境时都会过一遍，可以少走很多弯路。

5.2 三层定位法：快速找到问题源头

我把排查 hook 通知问题的思路总结成了“三层定位法”，从下往上找。

第一层是“事件有没有触发”。在 hook 命令里先配一个最朴素的命令，只往一个文件里追加一行字符，比如echo event-ok >> D:\scripts\iflownotify\event-debug.log。完成后去看文件有没有更新。没更新，就是事件或 hook 注册的问题，这时候检查事件名和配置加载。

第二层是“配置好了的脚本本身能不能跑”。手动在终端执行一遍完整的脚本命令，看是否报错、退出码是多少。如果是路径问题、引号问题、变量解析问题，这一层就会暴露出来。手动执行通过，再回过来看 hook 配置里的命令和参数是不是和手动执行的命令一致。

第三层是“脚本内部哪个环节失败”。在脚本的关键步骤后面加日志输出，比如声音播完写一行，弹窗弹完写一行，Webhook 请求完成写一行。跑一遍流程，看日志停在哪一行，就能定位到具体环节。这个方法我屡试不爽，比反复猜原因靠谱得多。

5.3 避坑清单：Windows 下 hook 配置的实操心得

最后分享几条我踩过之后留下的避坑心得，都是常规文档里不会写的东西。

第一，hook 命令里不要写太复杂的逻辑。你需要的是“触发”，不是“实现”。复杂逻辑放在脚本里，hook 命令保持简单，这样一旦出错，你能很容易区分是配置问题还是脚本问题。

第二，所有路径都用绝对路径。hook 执行的工作目录不一定是你的项目目录，甚至不一定是固定的，所以相对路径会让你找不到日志文件、找不到脚本。

第三，参数全部加引号。不管是配置里的路径参数，还是传给脚本的任务标题，尽量都用双引号包住。任务标题里很可能有空格和中文，不加引号会出现各种各样的诡异拆分。

第四，注意 Windows Defender 的干扰。有时候脚本本身没问题，但被安全软件判定为风险行为，弹窗不出现或者 Webhook 被拦截。如果你试了所有方法都没用，顺手看一眼安全中心的防护记录。实测下来，把脚本目录加入到白名单可以避免很多莫名的拦截。

第五，hook 脚本里不要碰交互式输入。正常弹窗可以，但不要让脚本停留在等待用户输入的阶段，否则会把 hook 执行卡住。如果需要用户确认，给弹窗加一个超时或者改用非阻塞通知方式。

第六，日志是 hook 排查的生命线。脚本里尽量在关键节点追加日志，日志文件路径固定下来。自动化脚本第一次跑成功率并不高，真正把成功率拉起来的方式，就是靠日志一遍一遍地发现问题、修正问题。

我个人在实际操作中的体会是，任务完成通知这件事，技术上没有任何难点，难的是把每个环节的细节照顾到。从事件名、变量占位符到脚本编码、参数引号，每个细节都可能让整个链路静默失效。但只要你配置好第一套能跑的流程，后面再遇到其他工具、其他事件，都会变得很简单。一个小建议：不要一开始就追求“全功能通知”，先从写日志开始，链路通了再加声音、弹窗、Webhook。这样你排查问题的范围会小很多，效率也高得多。