从一次对话，到一条真正可用的 AI 工作流

一次精彩的演示很容易让人兴奋。但当任务从一段精心准备的对话，变成每天都要处理的真实工作时，我们需要回答另一组问题：输入不完整怎么办？结果怎样检查？哪一步失败后可以重来？

本文提供一套设计框架，帮助你把模糊的「用 AI 做点什么」，拆成可以独立检查的工作步骤。以下是方法示例，不代表某个产品的实测结果。

先定义交付物，再讨论模型

假设你想让 AI 帮忙整理客户访谈。任务不是「读懂这些文字」，而是交付一份能被下一位同事使用的记录。

先写下这三个问题：

• 输入是什么？ 一份转写稿，还是包含录音、聊天记录与笔记的材料包？
• 输出给谁？ 产品经理需要问题线索，销售可能更需要明确的跟进事项。
• 怎样算完成？ 每条结论能回到原文，行动项能找到负责人，缺失信息被明确标出。

交付物越明确，越容易发现哪些步骤需要模型，哪些只需要普通程序。

把长任务拆成可检查的步骤

可以从一条简单的处理链开始：

接收原始材料
    ↓
整理格式、保留来源位置
    ↓
提取事实与待确认问题
    ↓
按目标模板组织内容
    ↓
检查引用、日期与行动项
    ↓
人工确认后交付

步骤之间传递的内容应当有清楚的结构。例如，事实记录除了文本，还可以保留 source_id 与原文位置。这样，当最终报告出现疑问时，你可以直接回到输入，而不必重新阅读全部材料。

不要一开始就追求复杂的自动编排。先让最短的处理链稳定地完成一种任务，再考虑增加分支。

给每一步留下失败出口

工作流需要处理的不只是正常情况。材料缺页、引用不存在、输出格式不符，都是应该显式出现的状态。

情况	建议的处理方式	需要保留的信息
输入材料不足	暂停并请求补充	缺少什么、为什么需要
结构不符合约定	有限次数重试，失败后转人工	原输出、校验错误
找不到结论的来源	删除结论或标为待核实	被引用的文本与位置
外部服务不可用	保存进度，稍后恢复	已完成步骤、重试记录

这些处理方式是设计选项，具体采用哪一种，取决于任务能容忍多长延迟，以及错误会造成什么后果。

用真实样例决定下一步

准备一组有权使用的材料，包含正常样例与边界样例。先人工完成并记录判断依据，再运行你的处理链。

记录的不应只有「这次回答看起来不错」，还应包括：遗漏了什么、改错了什么、人工花了多少时间修正，以及遇到问题能否定位到具体步骤。

一个有用的起点：今天就选一项重复任务，写清楚它的输入、交付物与检查方式。不要先写提示词。

这套框架的边界

它帮助你组织任务和观察错误，并不保证模型的正确性。涉及不可逆的外部操作时，仍应根据实际业务设置权限、确认与恢复机制。工作流是否值得继续投入，最终要回到真实使用中的质量与成本。