“做一个智能客服”“自动分析合同”“帮我写内容”都不是可以直接搭建的需求。节点只负责一种具体工作，真正的设计过程，是把模糊目标拆成输入、事实、判断、动作和输出。

第一步：写清输入

先列出用户或上游系统会提供什么。文本、文件、单选项、数字和数组应使用合适的输入类型，不要把所有内容都塞进一个长文本框。每个字段都要有稳定的变量名、清楚的说明、是否必填和合理的长度限制。

例如“合同信息提取”至少需要文件；“多平台内容生成”还需要目标平台、语言和语气；“订单查询”需要用户问题，但订单号可以在对话中追问后再提取。

第二步：区分事实来源

模型参数中的知识不应被当作实时数据库。需要判断每项事实来自哪里：

  • 固定制度、手册和产品资料来自知识库；
  • 订单、库存和账户状态来自业务 API；
  • 用户上传内容来自文档提取；
  • 公开实时信息来自受控的搜索或数据工具；
  • 只影响表达方式的要求可以直接写入提示词。

事实来源一旦明确，知识检索、HTTP 请求、工具和文档提取节点的位置也就清楚了。

第三步：把“理解”与“规则”分开

需要理解自然语言、归纳文本或生成表达时使用 LLM、参数提取或问题分类器。需要精确计算、格式转换、字段校验和固定分支时，使用 Code、Template 或 IF/ELSE。

例如从“下周三前给我”识别日期，可以交给模型理解；验证日期是否早于今天，应交给代码或规则。让模型负责所有工作，会让本应确定的结果也变得不稳定。

第四步：先定义输出契约

在连接节点前，先写出最终输出。面向人的 Chatflow 通常由 Answer 返回可读文字；面向系统的 Workflow 应由 Output 返回名称固定、类型明确的字段。

{
  "status": "success | needs_review | failed",
  "summary": "给人阅读的摘要",
  "data": {},
  "reason": "失败或待复核原因"
}

有了输出契约，就能倒推哪些节点必须产生哪些变量，也能避免业务系统依赖一段自然语言中的固定句子。

第五步：为失败画出路线

文件读取失败、知识没有命中、接口超时、字段缺失和模型输出不合格，都需要明确分支。不要只画成功路径，再指望 LLM 自己解释错误。

一个可实现的需求说明至少应包含：输入字段、事实来源、确定性规则、模型任务、外部动作、失败分支和输出契约。完成这张清单以后再进入画布，节点选择会快得多，测试也会有明确目标。