如何让 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 当聊天框,要当执行单元
传统用法是:
- 你问一步;
- AI 回一步;
- 你再补一句;
- AI 再继续。
这种模式的问题是:任务容易中断,质量依赖用户不断提醒,AI 很难负责到底。
Agentic 工作流的目标是换成:
- 用户给出完整任务包;
- AI 先确认目标、边界和验收标准;
- AI 规划步骤;
- AI 执行;
- AI 自检并报告证据;
- 用户审核最终结果。
简化成一句话:用户负责目标和风险边界,AI 负责过程推进和可验证交付。
第一步:把需求写成任务包
不要这样说:
帮我处理一下这个客户。这句话太模糊,AI 不知道要查什么、改什么、发不发邮件、成功标准是什么。
改成任务包:
目标:帮我准备一次客户上线公告流程。
背景:客户 Acme Corp 已完成企业版上线,需要更新 CRM 记录并草拟一封上线通知邮件。
允许做:
- 读取我提供的客户信息;
- 草拟 CRM 更新内容;
- 草拟邮件正文;
- 列出需要我确认的字段。
禁止做:
- 不要直接写入 CRM;
- 不要发送邮件;
- 不要编造客户联系人或合同信息。
交付物:
1. CRM 更新草案;
2. 邮件草稿;
3. 需要人工确认的问题清单;
4. 自检结果。
验收标准:
- 客户名称、联系人、上线日期必须来自输入资料;
- 邮件语气专业、简洁;
- 所有不确定信息必须标注“待确认”。这个任务包做了四件事:
- 给 AI 明确目标;
- 限定允许和禁止动作;
- 定义交付物;
- 设置验收标准。
第二步:要求 AI 先计划,不要直接开做
对于多步骤任务,直接让 AI 执行容易跑偏。更稳的提示词是:
请先不要执行。先输出:
1. 你对任务目标的理解;
2. 你计划执行的步骤;
3. 哪些步骤需要外部系统或人工确认;
4. 你会如何验证最终结果。
等我确认后,再进入执行。如果任务低风险,例如整理文章、生成草稿、改写说明,可以把确认环节放宽:
先给出简短计划,然后直接执行。若遇到不确定事实,不要猜,标注为“待确认”。判断是否需要人工确认,可以用这张表:
| 场景 | 是否需要先确认 | |---|---| | 改写文案、总结文章、生成草稿 | 通常不需要 | | 修改本地临时文件 | 视重要性而定 | | 写入生产数据库 | 必须确认 | | 发送邮件/消息给真人 | 必须确认 | | 调用付费 API 或外部服务 | 必须确认 | | 删除、覆盖、部署、发布 | 必须确认 |
第三步:把执行拆成「草案 → 检查 → 最终版」
不要让 AI 一次性输出最终结果。更好的流程是:
请按以下流程完成:
1. 生成第一版草案;
2. 对照验收标准逐项自检;
3. 修复自检发现的问题;
4. 输出最终版;
5. 列出仍需人工确认的事项。这会迫使 AI 把「质量检查」显式化,而不是默认它已经做过。
案例一:业务自动化任务
假设你要处理一个类似原文中的任务:更新 Salesforce 账户层级,并向企业联系人发送上线公告。
安全版任务包可以这样写:
目标:为 Acme Corp 准备上线公告流程。
输入资料:
- 客户:Acme Corp
- 产品:Enterprise Plan
- 上线日期:2026-08-15
- 联系人:Jane Lee, VP Operations
- 内部负责人:Chris Wang
允许做:
- 生成 Salesforce 字段更新草案;
- 草拟给 Jane Lee 的上线公告邮件;
- 输出人工确认清单。
禁止做:
- 不要登录 Salesforce;
- 不要发送邮件;
- 不要假设未提供的合同金额、账号层级或技术细节。
请输出:
1. Salesforce 更新草案,字段和值分开列;
2. 邮件标题和正文;
3. 风险检查清单;
4. 需要人工确认的问题。期望输出结构:
## 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」改成更可执行的形式:
目标:修复登录接口在 token 过期时返回 500 的问题。
上下文:
- 项目使用 Python + FastAPI;
- 期望 token 过期时返回 401;
- 不允许改变数据库 schema;
- 不允许引入新依赖。
请按流程执行:
1. 先定位相关文件和测试;
2. 写一个失败的回归测试;
3. 修改实现;
4. 运行最小相关测试;
5. 输出 git diff 摘要和测试结果。
验收标准:
- token 过期返回 401;
- 现有登录成功路径不变;
- 没有新增第三方依赖。如果 AI 具备本地工具调用能力,最终报告不应只说“应该可以”,而应包含真实证据,例如:
验证结果:
- pytest tests/auth/test_login.py -q 通过
- ruff check src/auth tests/auth 通过
- 未修改数据库 schema案例三:文章转工作流
如果你想把一篇文章变成可执行流程,可以这样提示:
请把这篇文章整理成一套可执行工作流。
要求:
1. 分离原文事实、作者观点和你的推论;
2. 提炼 3 个可落地步骤;
3. 每个步骤给出输入、动作、输出和验收标准;
4. 标注哪些建议不是原文直接支持,而是你的推论;
5. 给出一个可复制的提示词模板。输出最好长这样:
## 工作流:用 AI 完成长任务
### 步骤 1:任务包化
输入:模糊需求
动作:改写为目标、边界、交付物、验收标准
输出:任务包
验收:没有未定义的外部副作用
### 步骤 2:计划先行
...通用提示词模板
你可以直接复制下面这段,用于大多数复杂任务:
你是我的执行型 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 个端到端任务:
- 一个写作任务;
- 一个代码修复任务;
- 一个资料整理任务;
- 一个跨系统业务草案任务;
- 一个需要识别风险边界的任务。
每个任务按同一标准评分:
| 指标 | 说明 | |---|---| | 目标理解 | 是否准确复述任务 | | 计划质量 | 是否能拆步骤、识别依赖 | | 执行完整度 | 是否真的交付结果 | | 自检能力 | 是否发现并修正自身问题 | | 风险控制 | 是否避免未授权副作用 | | 证据质量 | 是否提供验证结果 |
这比只问“哪个模型更聪明”更接近真实工作场景。
小结
Claude Sonnet 5 文章真正值得提炼的不是某个模型名,而是一种工作方式:把 AI 从回答问题的聊天框,升级为可规划、可执行、可检查的任务协作者。
最小可用公式是:
清晰任务包 + 明确边界 + 先计划 + 分步执行 + 自检证据 + 人工确认点只要这六项齐备,即使不用同一个模型,也能显著提高 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、失败案例和安全评估指标。本文中的通用工作流、评分表和提示词模板是基于原文观点的实操化整理,并非原文逐字内容。