---
title: "从 AI 问答到 AI 值夜班：我的真实工作流拆解"
author: deletexiumu
pubDatetime: 2026-03-29T00:00:00+08:00
featured: false
draft: false
tags:
  - Claude Code
  - AI Agent
  - 效率
  - 教程
description: "从 6884 条 Claude 对话和 6 个定时任务出发，拆解一个开发者如何把 AI 从问答工具变成个人操作系统：多模型对抗审查、Agent Team 协作、定时任务自动化的完整实战。"
---

去年 6 月开始用 Claude Code，一开始就是问问题、写写代码。大半年后回头翻日志，发现 AI 已经渗透到我几乎所有的工作场景——仅一台设备上有记录的数据（从去年 9 月至今）就留下了 6884 条 Claude 对话、312 个 Codex 线程，还有 6 个定时任务在我不在的时候自动跑。

这篇不是方法论，是一次基于真实日志的复盘。先说两个关键认知，再用一个端到端案例穿起整个工作流，最后聊聊怎么让 AI 替你"值夜班"。

先统一几个概念：**对话**指 Claude Code 中一条用户输入记录；**线程**指 Codex 中一个完整的任务对话；**会话**指一次连续的 Claude Code 使用过程（可包含多条对话）；**定时任务**指通过系统调度自动触发的 AI 工作流。

---

## 一、两个前置认知

工具配置是表层，心智模型决定你能走多远。在翻日志之前，先说两个改变了我使用方式的认知。

### LLM 是知识的有损压缩——所以我用多模型交叉验证

Justineo 在 working-with-ai 分享中有个很精准的类比：LLM 对人类知识的压缩，类似 JPEG 对图片的压缩——实用，但有损失，你看到的"幻觉"本质上是压缩损失。

我的日志能佐证这个判断：312 个 Codex 线程中，67% 的调用是从 Claude Code 通过 MCP 发起的，其中有一部分用于对抗审查——让一个模型检查另一个模型的产出。这至少说明我在实践中倾向于不盲信单一模型。

这不是说要用更多工具，而是对关键决策做交叉验证。写段代码让 AI 自己跑跑测试就行，但做架构选型、写要发布的技术文章，值得多花一道工序让另一个模型挑刺。

### 瓶颈已从"写代码"转移到"review 代码"

Justineo 用自动驾驶等级来类比 AI 编程的演进（*来源：working-with-ai slides*）：从 L0 完全人工到 L3 Agent 写代码、人 review，当前大部分人正在 L2 到 L3 的过渡中。这个分级里有个关键转折——L3 开始，瓶颈从"写"变成了"看"。

我的 Codex 数据印证了这个方向：63% 的线程使用 read-only sandbox（只读模式），意味着大部分 Codex 使用是审查和咨询，而非直接生成代码。约 30% 是 workspace-write（可写），只有约 6% 是 danger-full-access（完全权限）。

所以工作流优化的重点不是"怎么让 AI 写更快"，而是"怎么更高效地 review AI 的产出"。后面的案例会反复体现这个原则。

---

## 二、用一个真实任务串起完整工作流

说认知太抽象，直接看一个端到端的案例。

这是我写第 23 篇公众号文章《AI Agent 多模型编排》的完整过程，从 2026-03-04 21:45 到 03-05 01:05，大约 3.5 小时。选它是因为流程最完整（选题→调研→评审→写作→再评审→Skill 沉淀），且没有敏感的客户信息。下面精选 6 个核心阶段展开。

![任务流转图：一个真实任务在 Research → Plan → Review → Implement → Review → Automate 各阶段的工具切换](/blog/ai-workflow-from-qa-to-nightshift/01-flowchart-task-workflow.jpg)

### 2.1 Research：Claude Code 做调研（21:45）

我扔给 Claude Code 一句模糊的需求："查看我目前的文章，然后结合最近热点，挑选本周博文选题。"

它做的事情：扫描已发布文章目录（避免重复选题）、读取我的 AI 日报摘要、输出多个候选选题。我看完后回了一句："细化 #3 多模型编排大纲。"

为什么用 Claude Code 做调研？因为调研需要并行多路搜索和长上下文整合——同时读文件、搜网络、分析数据——终端 Agent 比 chat 窗口更合适。

### 2.2 Plan：大纲 + 素材收集（22:00）

选定选题后，Claude Code 创建文章目录，启动 brainstorming skill 发散思考，然后并行派出多个 subagent 收集三类素材：行业趋势、开源工具方案、工作流配置方案。每份素材存入 `原始素材/` 目录下独立的 Markdown 文件。

这个阶段有个关键细节：我通常会把踩过的坑——比如"不要加下一篇预告"、"公众号版不做内容删减"——写进 Claude Code 的项目配置文件（CLAUDE.md）和 Memory 中，这样每次启动新会话时 AI 会自动加载这些约束，不需要重复交代。

### 2.3 Review（第一次）：Codex 大纲评审（22:07）

大纲和素材准备好后，我让 Claude Code 通过 MCP 把它们发给 Codex 做对抗审查。

这里有个翻车：我一开始还想让 Gemini 也参与评审做交叉验证，但 Gemini 限流了。我的反应是："如果 pro 模型限流就算了，不要降级到 flash。先更新大纲，不等 gemini 意见了。"——工具限流时果断放弃而不是降级，这本身就是一个真实的协作决策。

Codex 的评审发现了多个问题，其中最关键的三个：成本数据口径不统一、核心案例需要"可复现、可理解、可脱敏"、以及双版本共用大纲会导致技术段落挤压叙事段落。这些是我自己很难一次想全的。

中间还有个小插曲——我发现 Claude Code 在调用 Codex 时没传文件路径，审查方可能获取信息不完整，于是纠正了它："你没有发送具体文档目录吗？评审模型可能获取信息不完整。"这种对 AI 工具使用方式的纠正，也是协作中常见的场景。

### 2.4 Implement：Agent Team 写作（22:53）

大纲修改完毕，进入写作阶段。我启动了一个 Agent Team（为便于说明，这里做了简化）：writer 负责写作，reviewer 从技术准确性和可读性两个角度审查。内部多轮迭代——reviewer 说"第三段论据不够"，writer 马上改，改完再审——直到审查通过。

为什么用 Agent Team 而不是单个 Agent？因为 writer 和 reviewer 需要直接对话迭代，普通 subagent 做不到这种来回交流。

写完后我自己又审了一遍，给了几条具体反馈："除了 MCP 配置方案，还缺另一个工具的方案"、"希望有更多干货，现在感觉有点空洞"、"不要出现下一篇预告"。

### 2.5 Review（第二次）：Codex 终稿评审（23:32）

内部评审通过后，我再次让 Codex 做终稿审查。这次它发现了 7 个问题，其中一个是**高危技术错误**：文章里写 Codex MCP 需要在 `.mcp.json` 手动配置，但实际上它是内置插件机制，不需要手动配。

如果这个错误发布出去，会直接误导读者的配置方式。这就是对抗审查的核心价值——不是锦上添花，而是拦住你自己没发现的硬伤。

### 2.6 Automation：Skill 沉淀（00:29）

文章发布后，我做了一件让这次经验有长期价值的事：把整个流程固化为一个 tech-article-creator Skill。

下次写文章，直接 `/tech-article-creator` 一键启动，从选题到发布的完整链路都不用从零配置。后续的文章可以直接用这个 Skill 启动整个流程。

从"一次性对话"到"可复用系统"，这是工作流质变的关键一步。如果你不用 Claude Code，同样的思路可以用提示词模板、shell 脚本或命令别名来实现——核心是把重复做了 3 次以上的操作模板化。

---

## 三、让 AI 替你值夜班：从问答到自动化

从"人问 AI 答"到"AI 定期自动执行"，是另一个质变节点。

### 为什么值夜班有杠杆

不是所有任务都适合自动化。只有满足三个条件的任务才值得：**输入稳定**（不需要每次人工指定不同参数）、**输出可验证**（能判断跑成功还是失败）、**频率固定**（每天或每周重复）。我的判断标准很简单：如果一个工作流手动跑了 3 次以上，就考虑自动化。

### 我的 6 个定时任务

| 任务 | 触发 | 做什么 | 产出 |
|------|------|--------|------|
| AI 周报摘要 | 周日凌晨 | 汇总 AI 领域新闻 | Markdown 摘要 |
| 论文精选 | 周一凌晨 | 精选论文解读 | Markdown + PDF |
| 消息日报 | 每天傍晚 | 整理当天消息 | 结构化日报 |
| 热点信息图 | 每天晚间 | AI 热点可视化 | 图片 + 文案 |
| 邮件清理 | 周日上午 | 邮件分类整理 | 操作报告 |
| 工具权限修复 | 事件触发 | 版本更新时自动修复 | 静默执行 |

注意这些任务大部分不是"写代码"——内容处理、信息聚合、运维自动化，这正是 Coding Agent 的"通用性"。能跑代码意味着能调 API、读文件、发消息——所以 Coding Agent 天然适合做这些杂活。

![定时任务架构图：OS 调度 → Shell 脚本 → Claude Code → Skill → 产出](/blog/ai-workflow-from-qa-to-nightshift/02-framework-scheduled-tasks.jpg)

### 三种自动化方案怎么选

- **launchd / cron（OS 原生）**：本地执行，适合需要访问本地文件和工具链的任务。我目前的定时任务走的都是这个方案，因为它们需要读本地的聊天记录、调用本地安装的 Claude Code。
- **/loop（Claude Code 内置）**：在一个 CLI session 中按间隔重复执行，适合短期轮询监控，比如盯着一个部署跑完。
- **Scheduled Tasks（Claude Code 定时触发）**：支持定时触发。具体运行环境、权限边界和可用工具以官方最新文档为准。

一句话选择建议：需要本地资源用 launchd/cron，短期监控用 /loop，定时调度用 Scheduled Tasks。

### 30 分钟搭一个定时任务

以消息日报为例，搭一个最小可用的定时任务只需要三步：

**第一步：写触发脚本**。创建一个 shell 脚本，核心就是调用 Claude Code 执行任务：

```bash
#!/bin/bash
# ~/scripts/daily-report.sh
export PATH="$HOME/.local/bin:$PATH"
LOG_DIR="$HOME/Library/Logs"
mkdir -p "$LOG_DIR"

# claude -p 以非交互模式运行，--allowedTools 控制权限范围
# 参数以实际 CLI 版本为准，可通过 claude --help 查看
claude -p "执行消息日报生成" \
  --allowedTools "Read,Write,Bash,WebFetch" \
  >> "$LOG_DIR/daily-report.log" 2>&1
```

> 注意：launchd 不继承你的 shell 环境，PATH 和代理配置都要在脚本里显式 export。这是最常见的失败原因。

**第二步：配置定时触发**。macOS 用 launchd plist，手写或参考 Apple 官方 launchd.plist 文档。plist 的核心就是三个字段：`Label`（任务唯一标识）、`ProgramArguments`（执行什么）、`StartCalendarInterval`（什么时候触发）。Linux 用户用 crontab 即可。

**第三步：加载并验证**：

```bash
# 加载 plist（Label 替换为你自己的标识，如 com.myname.daily-report）
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.myname.daily-report.plist
# 手动触发一次验证
launchctl kickstart gui/$(id -u)/com.myname.daily-report
# 检查日志（路径与脚本中的 LOG_DIR 一致）
tail -f ~/Library/Logs/daily-report.log
```

验收标准：手动触发后 5 分钟内看到日志输出，且产出文件内容完整。

跑成功后，消息日报的产出大概长这样（脱敏示例）：

```
## 2026-03-28 消息日报

### 待办事项（3 项）
- [ ] 回复某某关于数据接口的问题
- [ ] 确认周五会议时间
- [ ] 审阅 PR #142

### 今日摘要
- 技术讨论 12 条：主要围绕缓存策略优化
- 项目协调 8 条：某项目排期确认
- 其他 5 条
```

---

## 四、3 个反直觉发现

日志比回忆更可靠，但仍有局限——它能告诉你"发生了什么"，不能直接告诉你"什么是最好的"。翻完半年的数据，有三个发现出乎我意料。

![3 个反直觉发现：时段双峰分布、63% 审查模式、压缩频率集中](/blog/ai-workflow-from-qa-to-nightshift/03-infographic-data-findings.jpg)

### 凌晨 0 点是我最活跃的时段

时段分布呈明显的双峰型：上午 9-12 点是工作高峰，晚间 21-01 点是深夜高峰。而全天最活跃的单一小时是凌晨 0 点（570 条对话），比上午 10 点的高峰（440 条）高出 30%。

可能的原因：深夜没有会议和消息打断，长任务（写文章、重构代码）更容易进入心流状态。但也不排除定时任务的干扰——每天 22:00 和每周日 00:30 都有自动任务在跑。

### 用得最多的不是写代码，是审查

Codex 的 63% 使用 read-only sandbox，这意味着审查类任务在我的 Codex 使用中占绝对主导。剩下的 30% workspace-write 可能也有一部分是"看完再小改"，纯粹从零生成的比例更低。

这和第一章说的"瓶颈从写转到看"方向一致。如果你发现自己 review AI 产出的时间越来越多，不是效率变低了，恰恰是在做最有价值的事。

### Context 压缩是隐形成本

半年内触发了 50 次 context 压缩，其中 3 月 2-3 日两天就占了 27 次（54%）。517MB 的 debug 日志也可作为这段时间高强度使用的侧面迹象。

推测当时在跑一个超长上下文的连续任务（大型文章写作或代码重构），导致对话长度频繁突破上下文窗口限制。每次压缩都意味着信息损失——AI 可能丢掉之前讨论过的关键细节。

启示是：任务越大越要主动分解，不要等 AI 被迫压缩上下文。拆成多个会话、中间状态存到文件，比一口气塞进一个超长对话要靠谱。

---

## 五、从问答工具到个人操作系统

回头看这半年多的日志，有一条清晰的演进线，大致分三个阶段：

- **问答助手**：遇到问题问一下，得到答案就关掉。大部分人停在这里。
- **协作伙伴**：AI 参与完整的任务链路——调研、规划、执行、审查。上面的端到端案例就是这个阶段。
- **自动化系统**：AI 在你不在的时候也能工作——定时任务、自动审查、Skill 复用。

好的 AI 工作流不是"怎么让 AI 写更多代码"，而是怎么把 AI 从一个你需要主动去问的工具，变成一个持续在后台为你工作的系统。

如果你想从今天开始，这是一个 30 分钟的起步清单：

1. **AI-on-AI Review（5 分钟）**：下次写完代码，把 diff 发给另一个模型审查。提示词模板：`"审查以下 diff，找出逻辑错误、安全风险和可维护性问题：{diff}"`。验收标准：审查发现至少 1 个你没注意到的问题。

2. **夜间 PR 摘要（15 分钟）**：参考前文定时任务模板，把触发脚本中的 prompt 换成 `"读取本仓库昨天合并的所有 PR，输出一份摘要：每个 PR 的标题、核心变更、潜在风险"`，触发时间设为每天早上 8:00。验收标准：第二天早上在日志中看到结构化的 PR 摘要。

3. **封装一个可复用模板（10 分钟）**：把你重复做了 3 次以上的操作模板化。Claude Code 用户可以写成 Skill（`/skill-name` 一键触发）；其他工具用户可以存为提示词模板、shell 脚本或命令别名。验收标准：下次同类任务耗时减半。

不需要一步到位。先从问答走到协作，再从协作走到自动化。日志会告诉你走到了哪里。

---

*本文数据来源：个人 Claude Code 和 Codex 使用日志（2025-09 至 2026-03，单设备数据，已脱敏）*

*参考来源：*

*Justineo, working-with-ai: https://github.com/Justineo/working-with-ai*

*Neil Kakkar, Being Productive with Claude Code: https://neilkakkar.com/productive-with-claude-code.html*

*Addy Osmani, AI-augmented Coding Workflow: https://addyosmani.com/blog/ai-coding-workflow/*

---

## 相关阅读

- [我如何使用 Claude Code：先计划，再编码](/posts/claude-code-plan-first/) — 本文第二章工作流的前置理念，聚焦 plan mode 的使用方法
- [AI Agent 多模型编排：让 Claude、ChatGPT、Gemini 各干各的活](/posts/multi-model-orchestration/) — 本文端到端案例的产出物，展示多模型协作的具体配置
- [同样的话跟 Claude Code 说了八遍，是时候让它自己记住了](/posts/claude-code-memory/) — 本文 2.2 节提到的 Memory 和 CLAUDE.md，详细配置指南