与你的智能体共同创建工作流指令

你无需从零开始编写工作流指令。可以先与智能体一起完成一个真实任务。当结果有用时，让智能体将你们共同开发的方法转化为可复用的工作流。

智能体会生成第一版草稿。你的角色是审查其假设，并决定哪些地方需要更明确的约束，以便其他团队成员也能获得可靠的结果。

每个工作流都属于一个智能体。智能体提供更广泛的角色和能力，工作流则记录某个可重复任务的流程和约束。

从一次成功的运行开始

在智能体已经了解任务、原始资料、你的反馈和可接受结果后，创建工作流会更容易。

1. 给智能体一个真实任务和实际所需的输入。
2. 审查结果，纠正缺失的上下文、推理薄弱或格式错误。
3. 当结果令人满意时，让智能体提取可复用的方法。
4. 让智能体起草工作流名称、描述、指令及其推荐的参考文件。
5. 在公开工作流前，与智能体一起审查草稿。

你可以这样提问：

把我们刚才做的事情转化为团队可复用的工作流。起草名称、描述和指令。将可复用的方法与仅适用于本次的细节分开。在最终确定前，列出我需要审查的假设和约束。

这样，智能体负责起草，你负责决定哪些部分必须受控。

指令是常见的约束位置

工作流指令会随工作流一起流转，每次运行时都适用。这使其成为定义约束（如必需输入、批准来源、输出格式、质量标准和需确认的操作）最常见的位置之一。

但它不是唯一的控制层：

不要仅依赖指令文本来替代访问控制。如果某项操作必须技术上受限，请结合智能体授权和权限，以及明确的指令。

审查智能体的第一版草稿

你无需重写每一句话。请将审查重点放在对团队重要的决策上。

何时应使用？

• 哪些请求或情境应选择此工作流？
• 何时智能体不应使用它？
• 描述是否足够具体，能与类似工作流区分？

需要哪些输入？

• 工作开始前，团队成员必须提供哪些内容？
• 缺失哪些输入时，智能体应主动提问？
• 哪些细节属于每次运行，而非永久指令？

哪些来源和规则优先？

• 什么是权威数据源？
• 哪个附件包含批准的标准或模板？
• 如果两个来源冲突，哪个优先？
• 智能体如何标注无法验证的事实？

输出应是什么样？

• 必须包含哪些部分或字段？
• 需要多详细？
• 输出是否需要引用、链接或置信标签？
• 提供目标时，结果应发送到哪里？

智能体应在哪些地方停止？

• 哪些操作需要确认？
• 智能体是否应只创建草稿而不直接发送或发布？
• 哪些数据不得出现在公开工作流或共享结果中？

这些约束值得明确。让智能体负责措辞，再确认措辞是否反映了你的决策。

一起审查的结构

智能体可以用以下结构起草第一版。将其视为审查框架，而非你必须自己填写的表单：

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

简单的工作流可能只需几个部分。高风险工作流则需要更明确的来源、验证和审批规则。让智能体尽量简明地编写指令，但不能遗漏团队依赖的决策。

示例：共创线索资格审查工作流

假设你让智能体调研一个入站线索并起草回复。在运行过程中，你纠正了公司规模，说明CRM是权威数据源，应用了团队的ICP标准，并要求邮件更简短。

结果获批后，让智能体将对话转化为工作流。智能体会起草流程，你再补充应长期保留的约束：

• 在进行公开调研前先检查CRM；
• 使用附件中的ICP标准进行评分；
• 对公司规模、地点和当前职位引用来源；
• 对无法验证但必需的事实标注为Unknown；
• 返回账户摘要、证据、ICP分数、风险、推荐下一步和回复草稿；
• 创建邮件草稿，未经确认不得发送。

智能体现在可以将这些决策纳入指令。你无需规定每一步调研细节，只需让团队的数据来源、输出要求和审批边界清晰明确。

用通俗语言反馈约束

你可以直接告诉智能体哪些内容必须更改，以收紧草稿：

• “如果缺少CRM记录，开始前请先索取。”
• “公司名称冲突时，以CRM为权威数据源。”
• “简报中的每个事实都需要有来源链接。”
• “回复控制在150字以内，但语气需适应入站信息。”
• “邮件只创建草稿，绝不自动发送。”
• “此工作流不应用于现有机会。”

让智能体更新工作流，并总结每项更改对应的约束。这样更容易发现被误解或放错位置的规则。

保持合适内容在指令之外

有些信息不应成为永久工作流文本：

• 客户名称、一次性截止时间和特定案例的目标应放在运行请求中；
• 密码、令牌和私密凭证不应出现在指令或附件中；
• 日程和事件属于自动化；
• 技术访问边界属于智能体授权和权限；
• 仅适用于某次结果的个人反馈可保留在该聊天中。

指令应承载可复用的方法和行为约束，而非所有与工作相关的细节。

一起测试和完善

用至少两个真实输入运行工作流，最好有第二位团队成员参与。每次运行后请问：

• 工作流是否针对正确任务激活？
• 是否请求了所需输入？
• 是否遵循了预期的数据来源优先级？
• 输出是否保持一致且不过于僵化？
• 是否在所需审批边界处停止？
• 问题是否可复现，还是仅限本案例？

让智能体针对可复现的问题修订指令。一次性的修正保留在运行中。当方法适用于原作者以外的人时，将工作流分享给你的团队。