# 如何让 AI 助手真正把任务做完：从 Claude Sonnet 5 文章提炼的 Agentic 工作流教程

> 本文整理自 GPT Central 的文章《Claude Sonnet 5 Explained: The AI Assistant Built to Finish Real Work》。原文偏产品介绍，缺少公开基准测试数据；本文把其中可复用的方法提炼成一套通用教程，适用于 Claude、ChatGPT、Gemini、Codex、Hermes 等具备工具调用或长任务能力的 AI 助手。

## 你会学到什么

读完后，你应该能搭出一个最小可用的「AI 完成真实任务」工作流：

- 把模糊请求改写成可执行任务包；
- 让 AI 先规划，再执行，再自检；
- 为外部系统、邮件、客户数据、代码修改设置安全边界；
- 用验收标准判断任务是否真的完成；
- 把成功流程沉淀成可复用模板。

## 适用场景

这套方法适合：

- 写作、邮件、报告、销售材料等知识工作；
- 代码修改、调试、测试、文档更新；
- 跨系统业务流程，例如 CRM 更新、公告草拟、数据整理；
- 需要 AI 连续执行 3 步以上的任务。

不适合直接无保护地用于：

- 资金交易、生产数据库写入、批量发邮件；
- 删除、覆盖、发布、部署等不可逆操作；
- 包含敏感客户数据但没有脱敏和权限控制的场景。

## 核心观念：不要把 AI 当聊天框，要当执行单元

传统用法是：

1. 你问一步；
2. AI 回一步；
3. 你再补一句；
4. AI 再继续。

这种模式的问题是：任务容易中断，质量依赖用户不断提醒，AI 很难负责到底。

Agentic 工作流的目标是换成：

1. 用户给出完整任务包；
2. AI 先确认目标、边界和验收标准；
3. AI 规划步骤；
4. AI 执行；
5. AI 自检并报告证据；
6. 用户审核最终结果。

简化成一句话：**用户负责目标和风险边界，AI 负责过程推进和可验证交付。**

## 第一步：把需求写成任务包

不要这样说：

```text
帮我处理一下这个客户。
```

这句话太模糊，AI 不知道要查什么、改什么、发不发邮件、成功标准是什么。

改成任务包：

```text
目标：帮我准备一次客户上线公告流程。

背景：客户 Acme Corp 已完成企业版上线，需要更新 CRM 记录并草拟一封上线通知邮件。

允许做：
- 读取我提供的客户信息；
- 草拟 CRM 更新内容；
- 草拟邮件正文；
- 列出需要我确认的字段。

禁止做：
- 不要直接写入 CRM；
- 不要发送邮件；
- 不要编造客户联系人或合同信息。

交付物：
1. CRM 更新草案；
2. 邮件草稿；
3. 需要人工确认的问题清单；
4. 自检结果。

验收标准：
- 客户名称、联系人、上线日期必须来自输入资料；
- 邮件语气专业、简洁；
- 所有不确定信息必须标注“待确认”。
```

这个任务包做了四件事：

- 给 AI 明确目标；
- 限定允许和禁止动作；
- 定义交付物；
- 设置验收标准。

## 第二步：要求 AI 先计划，不要直接开做

对于多步骤任务，直接让 AI 执行容易跑偏。更稳的提示词是：

```text
请先不要执行。先输出：

1. 你对任务目标的理解；
2. 你计划执行的步骤；
3. 哪些步骤需要外部系统或人工确认；
4. 你会如何验证最终结果。

等我确认后，再进入执行。
```

如果任务低风险，例如整理文章、生成草稿、改写说明，可以把确认环节放宽：

```text
先给出简短计划，然后直接执行。若遇到不确定事实，不要猜，标注为“待确认”。
```

判断是否需要人工确认，可以用这张表：

| 场景 | 是否需要先确认 |
|---|---|
| 改写文案、总结文章、生成草稿 | 通常不需要 |
| 修改本地临时文件 | 视重要性而定 |
| 写入生产数据库 | 必须确认 |
| 发送邮件/消息给真人 | 必须确认 |
| 调用付费 API 或外部服务 | 必须确认 |
| 删除、覆盖、部署、发布 | 必须确认 |

## 第三步：把执行拆成「草案 → 检查 → 最终版」

不要让 AI 一次性输出最终结果。更好的流程是：

```text
请按以下流程完成：

1. 生成第一版草案；
2. 对照验收标准逐项自检；
3. 修复自检发现的问题；
4. 输出最终版；
5. 列出仍需人工确认的事项。
```

这会迫使 AI 把「质量检查」显式化，而不是默认它已经做过。

## 案例一：业务自动化任务

假设你要处理一个类似原文中的任务：更新 Salesforce 账户层级，并向企业联系人发送上线公告。

安全版任务包可以这样写：

```text
目标：为 Acme Corp 准备上线公告流程。

输入资料：
- 客户：Acme Corp
- 产品：Enterprise Plan
- 上线日期：2026-08-15
- 联系人：Jane Lee, VP Operations
- 内部负责人：Chris Wang

允许做：
- 生成 Salesforce 字段更新草案；
- 草拟给 Jane Lee 的上线公告邮件；
- 输出人工确认清单。

禁止做：
- 不要登录 Salesforce；
- 不要发送邮件；
- 不要假设未提供的合同金额、账号层级或技术细节。

请输出：
1. Salesforce 更新草案，字段和值分开列；
2. 邮件标题和正文；
3. 风险检查清单；
4. 需要人工确认的问题。
```

期望输出结构：

```text
## Salesforce 更新草案
- Account Name: Acme Corp
- Plan: Enterprise Plan
- Launch Date: 2026-08-15
- Customer Contact: Jane Lee
- Internal Owner: Chris Wang
- 未确认字段：Account Tier、Contract Value、Support SLA

## 邮件草稿
Subject: Welcome to Enterprise Plan, Acme Corp
...

## 风险检查
- 未写入 CRM
- 未发送邮件
- 未编造合同金额

## 待确认问题
1. Account Tier 是否已有正式定义？
2. 是否需要抄送技术支持负责人？
3. Support SLA 是否已生效？
```

这个例子的重点不是让 AI 直接操作 Salesforce，而是先生成可审核、可复制、低风险的执行草案。

## 案例二：代码修改任务

把「帮我修 bug」改成更可执行的形式：

```text
目标：修复登录接口在 token 过期时返回 500 的问题。

上下文：
- 项目使用 Python + FastAPI；
- 期望 token 过期时返回 401；
- 不允许改变数据库 schema；
- 不允许引入新依赖。

请按流程执行：
1. 先定位相关文件和测试；
2. 写一个失败的回归测试；
3. 修改实现；
4. 运行最小相关测试；
5. 输出 git diff 摘要和测试结果。

验收标准：
- token 过期返回 401；
- 现有登录成功路径不变；
- 没有新增第三方依赖。
```

如果 AI 具备本地工具调用能力，最终报告不应只说“应该可以”，而应包含真实证据，例如：

```text
验证结果：
- pytest tests/auth/test_login.py -q 通过
- ruff check src/auth tests/auth 通过
- 未修改数据库 schema
```

## 案例三：文章转工作流

如果你想把一篇文章变成可执行流程，可以这样提示：

```text
请把这篇文章整理成一套可执行工作流。

要求：
1. 分离原文事实、作者观点和你的推论；
2. 提炼 3 个可落地步骤；
3. 每个步骤给出输入、动作、输出和验收标准；
4. 标注哪些建议不是原文直接支持，而是你的推论；
5. 给出一个可复制的提示词模板。
```

输出最好长这样：

```text
## 工作流：用 AI 完成长任务

### 步骤 1：任务包化
输入：模糊需求
动作：改写为目标、边界、交付物、验收标准
输出：任务包
验收：没有未定义的外部副作用

### 步骤 2：计划先行
...
```

## 通用提示词模板

你可以直接复制下面这段，用于大多数复杂任务：

```text
你是我的执行型 AI 助手。请按“计划 → 执行 → 自检 → 交付”的流程完成任务。

任务目标：
[写清楚你要完成什么]

背景资料：
[贴资料、链接、文件路径或业务上下文]

允许做：
- [允许的读取、分析、草拟、修改范围]

禁止做：
- 不要编造事实；
- 不要执行未授权的外部副作用；
- 不要删除、覆盖、发送、发布或部署，除非我明确确认。

交付物：
1. [交付物 A]
2. [交付物 B]
3. 自检结果

验收标准：
- [标准 1]
- [标准 2]
- [标准 3]

执行规则：
1. 如果任务有外部副作用，先停下来请求确认；
2. 如果信息不足，列出待确认问题，不要猜；
3. 每完成一个阶段，给出可验证证据；
4. 最终输出“已完成项 / 未完成项 / 风险 / 验证结果”。
```

## 验收清单：判断 AI 是否真的完成了任务

完成一个 AI 任务后，用这张清单检查：

- [ ] 目标是否被明确复述过？
- [ ] 是否列出允许做和禁止做？
- [ ] 是否区分事实、推论和不确定信息？
- [ ] 是否给出了最终交付物，而不是只给计划？
- [ ] 是否有验证证据？
- [ ] 是否说明了失败、风险或未完成项？
- [ ] 是否避免了未经确认的外部副作用？

如果其中三项以上没有满足，说明这次 AI 协作还停留在“聊天”，不是可靠的执行工作流。

## 常见失败模式

### 失败 1：任务太模糊

表现：AI 输出一堆泛泛建议。  
修复：补充目标、边界、交付物、验收标准。

### 失败 2：AI 编造缺失信息

表现：自动补了客户联系人、合同金额、技术细节。  
修复：在提示词中加入“所有缺失信息标注为待确认”。

### 失败 3：直接执行高风险动作

表现：未经确认发送邮件、改生产数据、发布内容。  
修复：把“外部副作用必须先确认”写入禁止事项。

### 失败 4：没有验证

表现：AI 说“已完成”，但没有测试、diff、检查结果或可读证据。  
修复：要求最终报告包含验证命令、输出摘要或人工检查清单。

## 进阶：如何评估不同 AI 助手

不要只看模型宣传或单次问答。更现实的评估方法是准备 5 个端到端任务：

1. 一个写作任务；
2. 一个代码修复任务；
3. 一个资料整理任务；
4. 一个跨系统业务草案任务；
5. 一个需要识别风险边界的任务。

每个任务按同一标准评分：

| 指标 | 说明 |
|---|---|
| 目标理解 | 是否准确复述任务 |
| 计划质量 | 是否能拆步骤、识别依赖 |
| 执行完整度 | 是否真的交付结果 |
| 自检能力 | 是否发现并修正自身问题 |
| 风险控制 | 是否避免未授权副作用 |
| 证据质量 | 是否提供验证结果 |

这比只问“哪个模型更聪明”更接近真实工作场景。

## 小结

Claude Sonnet 5 文章真正值得提炼的不是某个模型名，而是一种工作方式：把 AI 从回答问题的聊天框，升级为可规划、可执行、可检查的任务协作者。

最小可用公式是：

```text
清晰任务包 + 明确边界 + 先计划 + 分步执行 + 自检证据 + 人工确认点
```

只要这六项齐备，即使不用同一个模型，也能显著提高 AI 完成长任务的可靠性。

## 来源与边界

- 原文：Claude Sonnet 5 Explained: The AI Assistant Built to Finish Real Work
- 来源：https://gptcentral.substack.com/p/claude-sonnet-5-explained-the-ai
- 提取边界：原文为 Substack 产品介绍/教程性质文章，重点是功能使用和工作流概念；缺少公开 benchmark、失败案例和安全评估指标。本文中的通用工作流、评分表和提示词模板是基于原文观点的实操化整理，并非原文逐字内容。