企业官网建设流程全解析

1. 从“监工”到“派活”：重新理解 Claude 的协作模式

大多数人用 Claude 的方式，本质上是在当监工。你坐在屏幕前，敲一句提示词，等它回一段，看一眼不满意，再补一句，再等，再改。整个过程你的注意力被牢牢绑在对话框上，一分钟都走不开。这种模式在写个短函数、改个报错的时候没问题，但一旦任务稍微复杂一点——比如重构一个模块、批量处理一批文件、跑一轮完整的测试并修复失败用例——你就会发现自己变成了一个低效的传话筒，真正干活的时间还没盯着进度条的时间长。

这个项目标题里说的“睡前派个活，第二天起来验收”，核心不是让你偷懒，而是换一种协作范式：把 Claude 从“即时问答工具”变成“可托管的异步执行单元”。你负责定义目标、划定边界、设定验收标准，然后把它挂到后台去跑；它负责在无人盯守的情况下持续推进，遇到能自己解决的问题就自己解决，遇到真正卡住的点就记录下来等你回来处理。第二天你打开电脑，看到的不是一堆待确认的对话，而是一份完成报告加一份待决策清单。

这套玩法能成立，靠的是几个关键能力：/goal用来声明一个可验收的终态目标，Hooks用来在关键节点插入自动检查或自动动作，/background用来把任务丢到后台不占用当前会话，/schedule用来做定时或延迟触发。这几个东西组合起来，才构成了“派活—执行—验收”的闭环。少了任何一个，你要么没法定义什么叫“干完了”，要么没法在无人时保证质量，要么没法真正解放自己的注意力。

适合读这篇的人有三类。第一类是已经在用 Claude 写代码或处理文档，但每次都被“必须盯着”这件事拖住的开发者；第二类是手里有大量重复性、流程化任务，想用 AI 批量处理但不知道怎么保证不出岔子的效率型选手；第三类是对 Claude 的进阶能力（Hooks、后台任务、调度）只有模糊概念，想找一个完整可复现案例来打通认知的技术爱好者。下面我会按“设计思路—核心机制—实操落地—问题排查”的顺序，把这套异步协作模式拆开讲透。

2. 整体设计思路：为什么是“目标 + 钩子 + 后台 + 调度”这套组合

2.1 同步对话的根本瓶颈在哪里

同步对话模式的问题不在于 Claude 不够聪明，而在于注意力耦合。你和模型之间是一条实时通道，你发它回，它回你审。这条通道的带宽由你的反应速度决定，而不是由任务本身的复杂度决定。一个需要跑二十分钟的任务，如果你每两分钟就要看一眼，那这二十分钟里你的有效工作时间几乎为零。

更麻烦的是，同步模式下你很难给出一个“完整的目标”。因为对话是逐步展开的，你往往是在看到中间结果之后才想起来“哦对，还要处理边界情况”。这种边想边说的模式，导致任务定义本身是碎片化的，Claude 拿到的上下文也是碎片化的，最终产出自然容易漏东西。

异步模式要解决的就是这两个问题：把注意力从实时通道里抽出来，把任务定义从碎片化变成结构化。而要做到这两点，你需要一套机制来回答三个问题——干什么、干到什么程度算完、干的过程中谁来把关。

2.2/goal解决的是“什么叫干完了”

/goal的本质是给任务声明一个可验收的终态。它不是普通的提示词，普通提示词是“帮我改一下这个函数”，而 goal 是“这个模块的所有单元测试通过，且覆盖率不低于 80%，且没有新增 lint 错误”。区别在于，前者没有明确的完成边界，后者有。

为什么这个区别在异步场景下是致命的？因为你不在场。如果目标模糊，Claude 在无人确认的情况下只能自己判断“差不多行了”，而这个判断标准和你心里的标准大概率不一致。你第二天起来看到的可能是一个“它觉得完成了但你觉得还差得远”的结果，然后你又得重新派活，一来一回反而更慢。

一个合格的 goal 应该包含三个要素：可观测的终态（比如测试全绿、文件生成完毕、接口返回符合预期）、可量化的约束（比如时间上限、改动范围上限、依赖不能新增）、可回退的边界（比如只允许改 src 目录下的文件，不允许动配置文件）。这三样写清楚，Claude 在后台跑的时候才有明确的“停”和“继续”的判断依据。

2.3Hooks解决的是“过程中谁来把关”

光有目标还不够。异步执行最大的风险是“跑偏了没人拦”。比如你让它重构一个模块，它改到一半发现某个依赖冲突，于是自作主张把依赖降级了——这个动作可能符合“让测试通过”的目标，但违反了“不新增/不改动依赖”的约束。如果你不在场，这个改动就被默默做掉了。

Hooks就是在关键节点插入的自动检查器。它可以在工具调用前后触发，比如在每次写文件之前检查路径是否在允许范围内，在每次执行命令之后检查退出码和输出是否符合预期，在任务声称完成时跑一遍验收脚本。如果检查不通过，Hook 可以阻断这次操作、记录日志、或者触发一个回退动作。

这套机制的价值在于，它把“质量把关”从人的实时判断变成了规则的前置声明。你不需要盯着每一步，你只需要在派活之前把规则写对。规则写对了，Claude 在后台跑一晚上，你第二天看到的产出就是经过过滤的。

2.4/background和/schedule解决的是“怎么真正解放注意力”

/background的作用是把当前任务从交互式会话里剥离出去，让它在一个独立的后台上下文里继续跑。你发完指令就可以关掉窗口去做别的事，任务不会因为你切走而中断。/schedule则更进一步，它允许你指定一个触发时间或触发条件，比如“今晚十一点开始跑”“等某个文件出现之后再启动”。

这两个能力组合起来，才真正实现了“睡前派活”。你不需要在睡前守着它启动，你可以把任务排好，到点它自己开始跑。你也不需要担心跑的时候你不在，因为 Hooks 已经帮你把该拦的都拦了，/goal已经帮你把完成标准定死了。

注意：后台任务和调度任务的前提是你的运行环境支持持久化执行。如果你是在本地终端里跑，关掉终端进程就没了；如果你用的是支持后台会话的客户端或服务端环境，才能真正做到“关掉窗口继续跑”。这一点在实操部分会详细说。

3. 核心机制拆解：/goal、Hooks、/background、/schedule到底怎么用

3.1/goal的写法与常见误区

/goal的语法本身不复杂，难的是把目标写得既完整又不啰嗦。我见过太多人把 goal 写成一篇小作文，结果 Claude 在解析的时候抓不住重点；也见过有人写得过于简略，比如“优化这个项目”，这种 goal 等于没写。

一个实用的写法是三段式：终态描述 + 约束条件 + 验收方式。举个例子：

/goal 完成 user-service 模块的重构，要求： 1. 所有现有单元测试通过，且新增测试覆盖重构后的分支逻辑 2. 不新增任何第三方依赖，不修改 package.json 中的版本号 3. 重构后模块的公开 API 保持不变，调用方无需改动 4. 验收方式：运行 npm test -- --coverage，要求 statements 覆盖率不低于 85%

这个 goal 的好处是，每一条都是可机器验证的。测试通过与否是二值的，依赖有没有新增是可以 diff 的，API 有没有变是可以对比类型定义的，覆盖率是有数字的。Claude 在后台跑的时候，每完成一个阶段都可以自己对照这些条件判断是否达标。

常见的误区有三个。第一个是把手段当目标，比如写“用策略模式重构这个模块”——策略模式是手段，不是终态，你应该写“消除 if-else 分支，使新增一种类型时不需要修改现有代码”。第二个是约束写得太宽，比如“尽量不要改动其他文件”，这种“尽量”在无人监督时等于没有约束。第三个是验收方式不可执行，比如“代码质量要高”，这不是验收，这是愿望。

3.2Hooks的触发时机与配置逻辑

Hooks 的核心是触发时机和触发动作。触发时机决定了它在什么时候介入，触发动作决定了它介入之后干什么。

从时机上看，常用的有这几类：工具调用前（PreToolUse），用来做权限检查、路径校验、参数合法性检查；工具调用后（PostToolUse），用来做结果校验、日志记录、副作用检查；任务完成时（Stop），用来跑最终验收；会话开始时（SessionStart），用来做环境初始化。

从动作上看，Hook 可以执行一个 shell 命令、调用一个脚本、或者直接返回一个阻断信号。比如你想限制 Claude 只能改 src 目录下的文件，可以配一个 PreToolUse Hook，在每次 Write 或 Edit 之前检查目标路径：

{ "hooks": { "PreToolUse": [ { "matcher": "Write|Edit", "command": "check-path.sh", "description": "只允许修改 src 目录下的文件" } ] } }

check-path.sh的逻辑很简单：从标准输入读取工具调用的参数，提取文件路径，如果路径不以src/开头就返回非零退出码。返回非零退出码时，Claude 会收到一个阻断信号，这次操作不会执行，它会尝试换一种方式或者记录下这个限制。

这里有个实操心得：Hook 的报错信息要写清楚原因。如果你只是返回一个退出码 1，Claude 可能反复尝试同一个操作，浪费大量时间。如果你在 stderr 里输出“目标路径不在允许范围内，只允许修改 src/ 下的文件”，它就能理解约束并调整策略。

另一个心得是：Hook 不要写得太重。Hook 是在每次工具调用时同步执行的，如果里面跑一个耗时十秒的检查，整个任务的速度会被拖垮。路径检查、参数校验这种轻量逻辑适合放 Hook，完整的测试套件应该放在 Stop Hook 里，只在任务声称完成时跑一次。

3.3/background的运行机制与适用边界

/background把一个任务从当前会话剥离出去，给它一个独立的执行上下文。这个上下文有自己的对话历史、自己的工具调用序列、自己的状态。你当前会话里继续做别的事，不会干扰到后台任务的执行。

它的适用边界很明确：适合长耗时、低交互、目标明确的任务。比如批量重命名文件、跑一轮完整的回归测试并修复失败用例、把一批 Markdown 转换成指定格式、对一个大模块做静态分析并生成报告。这些任务的共同点是，一旦启动，中间不需要你提供额外信息，跑完为止。

不适合的场景也很明确：需要频繁决策、需要你提供偏好、目标本身还在探索中的任务。比如“帮我设计一个架构”，这种任务需要来回讨论，放后台跑只会得到一个你不满意的方案，然后你还得重新来。

后台任务启动之后，你可以用状态查询命令看它的进度。通常会有类似/background list或/background status <id>的命令，具体取决于你用的客户端版本。看到任务在跑、没有报错、进度在推进，就可以放心去睡了。

3.4/schedule的定时与条件触发

/schedule解决的是“什么时候开始跑”的问题。最简单的用法是定时触发，比如：

/schedule 23:00 /goal 完成 nightly-regression 任务...

意思是今晚十一点启动这个 goal。更复杂的用法是条件触发，比如“等 CI 流水线的最新构建完成之后再启动”“等某个数据文件更新之后再启动”。条件触发需要你的环境支持事件监听，配置起来比定时触发麻烦一些，但适用场景更精准。

定时触发的一个实际价值是错峰。如果你用的环境有资源限制或者配额限制，白天跑任务可能和你的交互式使用抢资源，放到深夜跑既不影响你，也不影响别人。另一个价值是利用空闲时间做重活，比如全量测试、大规模重构、批量生成文档，这些任务白天跑会拖慢你的正常节奏，放到睡前启动刚刚好。

注意：/schedule的可靠性取决于你的运行环境是否持续在线。如果你是在个人电脑上跑，电脑休眠了任务就断了；如果你是在常开的开发机或服务端环境上跑，才能真正做到“到点自动启动”。这一点在派活之前一定要确认清楚。

4. 实操落地：一个完整的“睡前派活”案例

4.1 场景定义与目标拆解

假设你手里有一个 Node.js 项目，里面有一个user-service模块，代码写得比较乱，if-else 嵌套很深，测试覆盖率只有 40% 左右。你想重构它，但白天没时间盯着，于是决定睡前派个活，让 Claude 在后台跑一晚上，第二天起来验收。

第一步是把目标写清楚。不要写“重构 user-service”，要写成一个可验收的终态：

/goal 重构 src/services/user-service 模块，要求： 1. 消除 getUserLevel 函数中超过三层的 if-else 嵌套，改用策略模式或查表法 2. 所有现有测试保持通过，且为重构后的每个分支新增至少一个测试用例 3. 不修改模块的公开导出接口，调用方代码零改动 4. 不新增任何 npm 依赖 5. 验收命令：npm test -- --coverage --collectCoverageFrom='src/services/user-service/**' 6. 验收标准：所有测试通过，且该模块 statements 覆盖率不低于 85%，branches 覆盖率不低于 80%

这个 goal 里，第 1 条是终态描述，第 2、3、4 条是约束，第 5、6 条是验收方式。每一条都可以被机器验证，Claude 在后台跑的时候有明确的判断依据。

4.2 配置 Hooks 做过程把关

目标定好之后，配 Hooks。这个场景下需要两个 Hook：一个防止它改到不该改的文件，一个在它声称完成时跑验收。

第一个 Hook 是 PreToolUse，限制写入范围：

{ "hooks": { "PreToolUse": [ { "matcher": "Write|Edit|MultiEdit", "command": "bash -c 'path=$(jq -r .path); if [[ ! \"$path\" =~ ^src/services/user-service/ ]]; then echo \"只允许修改 src/services/user-service/ 下的文件，当前路径: $path\" >&2; exit 1; fi'" } ] } }

这个 Hook 从工具调用的 JSON 参数里提取path字段，检查它是否以src/services/user-service/开头。如果不是，就往 stderr 写一条说明并返回退出码 1，Claude 会收到阻断信号并调整策略。

第二个 Hook 是 Stop，在任务声称完成时跑验收：

{ "hooks": { "Stop": [ { "command": "bash -c 'npm test -- --coverage --collectCoverageFrom=\"src/services/user-service/**\" 2>&1 | tee /tmp/acceptance.log; if ! grep -q \"All tests passed\" /tmp/acceptance.log; then echo \"验收失败：测试未全部通过\" >&2; exit 1; fi'" } ] } }

这个 Hook 跑完整的测试命令，把输出写到日志文件，然后检查日志里有没有“All tests passed”。如果没有，返回退出码 1，Claude 会知道验收没过，继续修复。

4.3 启动后台任务并设置调度

Hooks 配好之后，把任务挂到后台并设置定时启动：

/schedule 23:30 /background /goal 重构 src/services/user-service 模块...

这条命令的意思是：今晚十一点半，在后台启动这个 goal。启动之后你可以关掉窗口去睡觉，任务会在后台独立运行。

如果你不想等到特定时间，想立即启动，可以去掉/schedule部分，直接/background /goal ...。如果你想确认任务有没有正常启动，可以在启动后查一下后台任务列表：

/background list

看到任务状态是 running，没有报错，就可以放心了。

4.4 第二天验收：看什么、怎么判断

第二天起来，第一件事是看后台任务的最终状态。通常会有类似/background status <id>的命令，输出里会包含任务是否完成、跑了多久、有没有被 Hook 阻断过、最终验收有没有通过。

如果任务显示完成且验收通过，不要急着合并代码。先做三件事：看 diff，确认改动范围符合预期，没有意外修改；看测试报告，确认覆盖率数字达标，新增测试确实覆盖了重构后的分支；跑一遍完整测试，确认没有影响到其他模块。

如果任务显示未完成或者验收失败，看日志里最后卡在哪一步。常见的情况是：某个测试用例一直修不过，Claude 反复尝试但没找到正确解法；或者 Hook 阻断次数过多，任务提前终止了。这时候你需要看它记录的待决策清单，里面会列出它尝试过什么、卡在哪里、需要你做什么决定。

实操心得：第一次跑的时候，建议把任务范围缩小一点，比如只重构一个函数而不是整个模块。跑通一次完整流程之后，再逐步扩大范围。这样你对 Hook 的严格程度、goal 的写法、后台任务的稳定性都会有一个实际的体感，后面再派大活心里有底。

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

5.1 后台任务启动失败或中途断掉

最常见的原因是运行环境不支持持久化。如果你是在本地终端里直接跑，关掉终端进程就没了。解决办法是确认你用的客户端是否支持后台会话，或者把任务放到一个常开的开发机/容器里跑。

另一个原因是权限问题。有些环境对后台任务的资源有限制，比如内存上限、CPU 配额、网络访问权限。如果任务启动后很快失败，先看日志里有没有权限相关的报错。Windows 环境下尤其容易遇到权限问题，比如后台服务需要管理员权限但当前终端不是管理员终端，或者反过来，共享客户端不能继承管理员权限。这类问题的通用排查思路是：先用最小权限跑一个简单任务，确认基础环境没问题，再逐步加复杂度。

5.2 Hook 阻断太频繁导致任务卡死

Hook 写得太严格，Claude 每走一步都被拦，最后什么都干不了。比如你把路径限制写成了只允许改一个文件，但它需要同时改测试文件和源文件，结果测试文件被拦，任务卡住。

解决办法是放宽到合理的粒度。路径限制应该限制到目录级别，而不是文件级别。参数校验应该校验关键字段，而不是所有字段。另外，Hook 的报错信息要写清楚“为什么被拦”和“什么情况下允许”，这样 Claude 才能调整策略而不是反复撞墙。

5.3 验收标准写得太模糊导致结果不符合预期

这是最常见的问题。你写“代码质量要高”，Claude 交出来的东西你可能觉得不行，但它觉得已经达标了。因为“质量高”没有可验证的定义。

解决办法是把验收标准量化。覆盖率写到具体数字，测试通过写成二值条件，API 不变写成可 diff 的约束。凡是不能用命令验证的标准，都不要写进 goal。如果你确实有一些主观偏好，比如“变量命名要清晰”，那就把它转化成可检查的规则，比如“变量名长度不少于 3 个字符，不使用缩写”。

5.4 任务跑完了但改动范围超出预期

有时候 Claude 为了让测试通过，会顺手改一些不该改的东西，比如调整 tsconfig、修改 eslint 配置、升级依赖版本。这些改动可能让验收通过了，但违反了你的约束。

解决办法是在 Hook 里加一条改动范围检查。在 Stop Hook 里跑一个git diff --name-only，检查所有改动的文件是否都在允许范围内。如果有超出范围的，返回退出码 1 并列出违规文件，让 Claude 回退这些改动。

5.5 常见问题速查表

5.6 几个我踩过的坑

第一个坑是忘了配 Stop Hook。第一次跑的时候只写了 goal，没配验收 Hook，结果 Claude 声称完成了，我第二天起来一看测试根本没跑。后来学乖了，任何后台任务都必须配 Stop Hook，验收命令必须跑。

第二个坑是Hook 脚本里用了相对路径。Hook 执行时的工作目录可能和你预期的不一样，导致脚本找不到文件。解决办法是 Hook 里一律用绝对路径，或者在脚本开头先cd到项目根目录。

第三个坑是调度时间设得太早。有次设了晚上八点启动，结果那时候我还在用电脑做别的事，后台任务和我的交互式操作抢资源，两边都变慢。后来改成十一点之后启动，错开使用高峰，顺畅很多。

第四个坑是goal 里写了“尽量”。“尽量不新增依赖”这种写法，Claude 会理解为“可以新增，但尽量少”。后来改成“不新增任何依赖”，并在 Hook 里加了 package.json 的 diff 检查，才彻底堵住。

6. 进阶玩法：把这套模式扩展到更多场景

6.1 批量文档处理与格式转换

除了代码重构，这套模式也适合批量文档处理。比如你有一批 Markdown 文件需要转换成特定格式的 HTML，或者一批 CSV 需要清洗后导入数据库。写一个 goal 定义终态（所有文件转换完成且格式校验通过），配一个 Hook 检查输出目录（只允许写入 output/ 目录），挂到后台跑，第二天验收。

这类任务的关键是输入输出的边界要清晰。输入文件列表要明确，输出格式要有可验证的标准，中间过程不需要你介入。

6.2 定时回归测试与自动修复

如果你有一个稳定的测试套件，可以配一个每晚定时跑的回归任务：跑全量测试，如果有失败用例，尝试自动修复，修复不了就记录下来。第二天你只需要看失败清单，不用自己跑测试。

这个场景下，Hook 的作用是防止它为了修测试而改测试。很多自动修复工具会直接把失败的测试用例删掉或者跳过，这在无人监督时是灾难性的。你需要在 Hook 里加一条：不允许修改 test/ 目录下的文件，只能修改 src/ 下的实现代码。

6.3 多任务并行与优先级管理

当你有多个后台任务同时跑的时候，需要管理它们的优先级和资源占用。一般来说，交互式会话的优先级最高，后台任务次之，定时任务最低。如果你的环境支持优先级配置，把后台任务设成低优先级，避免它们影响你的正常使用。

另外，多个后台任务之间如果有依赖关系，比如任务 B 需要等任务 A 的输出，可以用/schedule的条件触发来串联。A 完成后触发 B，B 完成后触发 C，形成一条流水线。

6.4 验收清单的模板化

跑多了之后，你会发现验收清单的写法可以模板化。我常用的模板是：

验收清单： - [ ] 命令：<验收命令> - [ ] 标准：<可量化的通过条件> - [ ] 范围：<允许改动的文件/目录> - [ ] 禁止：<明确不允许的操作> - [ ] 回退：<验收失败时的处理方式>

这个模板覆盖了验收的五个关键维度，每次派活之前照着填一遍，基本不会漏东西。填完之后直接贴进 goal 里，Claude 解析起来也清晰。

7. 最后分享几个实用技巧

关于 goal 的写法，我的经验是先写验收命令，再写目标描述。因为验收命令是最终判断依据，先把验收命令定下来，目标描述自然就围绕它展开了。如果你先写目标描述，很容易写出一堆没法验证的形容词。

关于 Hook 的调试，建议先在交互模式下测试。把 Hook 配好之后，不要直接挂后台，先在当前会话里跑一个小任务，看 Hook 有没有正常触发、报错信息是否清晰、阻断逻辑是否符合预期。确认没问题了再挂后台。

关于后台任务的监控，如果环境支持，配一个简单的通知机制。比如任务完成或失败时发一条消息到你的手机或邮箱。这样你第二天起来之前就知道任务跑没跑完，不用打开电脑才发现出了问题。

关于任务粒度，宁可拆小也不要贪大。一个后台任务跑两到四个小时是比较合适的粒度，跑一晚上八个小时的任务，一旦中间卡住，你第二天起来发现什么都没干成。拆成几个小任务串行跑，每个任务都有独立的验收，出问题也容易定位。

关于版本管理，派活之前先提交当前代码。后台任务会改文件，如果改坏了你想回退，有一个干净的提交点会方便很多。我习惯在派活之前跑一次git add -A && git commit -m "checkpoint before background task"，这样第二天验收不通过可以直接git reset --hard回到派活前的状态。

这套模式我用了几个月，最大的感受是写 goal 和配 Hook 的时间，远比盯着任务跑的时间值钱。前期花二十分钟把目标和约束写清楚，后面就能省下几个小时的盯守时间。而且写多了之后，你会发现自己对“什么叫完成”这件事的思考也变清晰了，这反过来对日常的同步协作也有帮助。