让 AI 开发持续可靠：长任务、Hooks、自动化与质量控制

01 / 定义：可靠性包含发现失败和恢复工作

一次运行得到正确结果，只证明这一次成功。持续可靠还要求：输入变化后能发现问题，执行中断后知道停在哪里，失败不会被当成完成，旧结果不会被重复覆盖。它关注的是整个运行过程。

Hooks 是在特定工具或会话事件发生时执行的自动动作，例如检查或记录。它适合确定性规则，不适合替代需要业务判断的验收。版本与事件支持会变化，配置前应以当前安装版本的事件定义为准。

02 / 推导：把状态、守门和验收拆开

状态记录回答“现在做到哪里”；执行前检查回答“这个动作是否允许”；执行后检查回答“结果是否符合规则”。三者不能混为一谈。记录了命令不等于命令成功；工具执行后的 Hook 也无法撤销已经发生的外部动作。

对于高影响动作，约束应该在动作发生前生效，并由实际权限或服务端规则保证。提示词和日志可帮助理解，不能替代访问控制。对于代码格式等可逆问题，执行后自动检查更合适。

03 / 应用：让一项三阶段改动能中断恢复

假设要把导出功能改为异步任务，涉及任务创建、状态查询和文件下载。不要一次交给助手“全部做完”，先写三项阶段出口，每项都能独立检查。

1. 定义检查点。阶段一完成数据模型与状态转换；阶段二完成创建和查询接口；阶段三完成下载权限与界面。每阶段写实际变更、验证结果和下一步。
2. 明确有效事实源。当前代码是实现事实，测试结果是验证事实，状态文件是导航入口。状态文件不能用一句“全部通过”代替具体结果。
3. 选择一个自动检查。先用现有格式或静态检查命令，确保直接在终端运行成功，再接入适用事件。不要同时引入一整套新工具。
4. 构造失败。在测试分支制造一个能被检查器发现的小问题，观察 Hook 是否实际触发，以及失败如何反馈。检查输出和退出码，不只看配置文件存在。
5. 测试恢复。在阶段二后停止会话；新会话只根据检查点与代码，说明已完成范围并继续阶段三。若必须靠原会话猜测，记录还不够。
6. 做最终回归。中途检查通过不代表最终组合通过。重跑状态转换、越权下载、失败重试与旧功能检查。

当前目标：工单导出改为异步任务。
已完成：任务创建与查询；具体文件见下方列表。
已验证：记录实际命令、测试范围和结果。
尚未验证：生产队列、真实身份服务和大文件下载。
下一步：实现下载时的项目权限检查。
不得重复执行：已有数据迁移；先检查实际迁移状态。
恢复入口：任务模型、接口测试、下载处理函数。

这份记录要在重要节点更新，而不是每改一行就维护。恢复成本高、会话可能切换或操作不可重复时，检查点尤其重要。

04 / 验收：自动化必须证明自己会失败

在 Claude Code 的适用命令 Hook 中，退出码 2 有特定阻断语义，但并不是所有事件都能阻断，也不能把任意非零退出码都理解为同样效果。先核对事件契约，再设计失败路径。不要把执行后通知当成执行前审批。

自动化还需要维护人。检查器误报时谁修改规则、工具升级后谁复验、哪些失败允许继续，都应写清楚，否则人会习惯性忽略所有红色提示。

05 / 迁移：哪些动作值得自动化

优先自动化频繁、确定、低歧义的检查：格式、链接、固定字段、已知回归测试。涉及产品取舍、隐私范围和外部发布的判断，先保留明确的人与权限边界。自动化的收益是减少遗漏，不是减少所有判断。

当你开始评估整套 AI 应用，而不只是工程检查，进入质量、成本与延迟评估。