分类： AI

前言

你是否想过，如何将抖音上优质的视频内容，批量转化为小红书的爆款图文笔记？手动一条条改写太慢了！今天我们来复盘一个 AI Agent 实战案例：利用 Coze（扣子）+ 阿里百炼插件 + 飞书多维表格，实现全自动化的“视频转文案”工作流。

我们的目标是：扔给 AI 一堆链接，它自动帮我们跑完所有流程，最后直接在飞书表格里收货。

🚀 核心工作流拆解

整个智能体的工作流可以分为四个关键阶段：

1. 链接提取：把用户输入的一坨文字变成标准列表。
2. 批量文案提取：利用插件获取视频口播稿。
3. 自动化基建：自动创建飞书 Base 和 Table。
4. 循环改写与归档：利用 LLM 按照“爆款公式”改写并存入表格。

🛠️ 第一阶段：链接提取与预处理

用户输入的内容往往是混乱的，包含各种介绍语和多个链接。我们需要做的第一步就是“清洗数据”。

• 节点选择：大模型节点（LLM）
• Prompt 设定：
  “提取出用户消息中的所有 URL 链接，去除无关文本，整理并输出为标准的数组格式 (Array)。”
  
• 目的：为后续的“数组循环”做准备，只有标准的 Array 格式才能被 Loop 节点识别。

🧩 第二阶段：批量提取视频文案

拿到了链接列表，下一步是获取视频里的内容。

• 插件选择：这里推荐使用 阿里百炼 的相关插件（或者扣子市场里的 提取视频文案 类插件）。
• 配置重点：
  • API Key：一定要在插件配置页填入你的 API Key（例如阿里百炼的 Key），否则无法调用。
  • 输入参数：直接将上一步提取的 URL 数组传给插件，实现批量提取。

🏗️ 第三阶段：飞书基建（自动化建表）

这是本流程中最“极客”的一步。为了不每次都手动建表，我们让 AI 自己去飞书里创建文件。

1. 创建多维表格文件 (Create Base)

调用飞书插件的 Create Base 工具，生成一个新的多维表格文件，并获取 app_token。

2. 构建表头结构 (Code Node)

在创建数据表之前，必须用代码定义好表头（Table Header）。这里需要用到一个 Python/JSON 代码节点。

代码逻辑示例：

我们要构建一个符合飞书 API 格式的 JSON 对象：

JSON

{

    “fields”: [

        { “field_name”: “原链接”, “type”: 1 },  // type 1 代表文本

        { “field_name”: “改写文案”, “type”: 1 }

    ]

}

注意：语音中提到的 “fire name” 其实是 field_name，“type 一” 即 type: 1（文本类型）。

3. 创建数据表 (Create Table)

调用 Create Table 插件，输入上一步生成的 JSON 配置和 app_token，完成表格的初始化。

🔄 第四阶段：循环改写与爆款逻辑 (The Loop)

这是智能体的“大脑”。我们需要使用 Loop（循环） 节点，遍历每一个视频文案，让大模型进行改写。

1. 提示词工程 (Prompt Engineering) – 爆款的核心

在循环内的大模型节点中，我们需要精心设计 Prompt，让它生成的文案符合小红书调性。

核心 Prompt 结构：

• 任务目标：对 content 进行改写，适配小红书平台。
• 标题创作技巧 (20字以内)：
  • 二极管标题法：利用本能喜欢（省力、享受）和动物本能（追乐、避苦）。
  • 公式：正面刺激（只需1秒+便可开挂） VS 负面刺激（你不X+绝对后悔+紧迫感）。
  • 关键词：融入“好用到哭”、“倒库”、“笑不活了”、“YYDS”、“我不允许”、“绝绝子”。
  • 装饰：必须使用 Emoji 表情增加活力 🍓✨。
  • 数量：每次生成 10 个标题供选择。
• 正文创作技巧：
  • 风格：随机选择（严肃、幽默、沉思、温馨、崇敬）。
  • 开篇：引用名言、提出疑问、强对比。
  • 规则：不要解释，不要把 Prompt 当命令回复，直接输出正文。口语化表达。

2. 数据回写 (Add Records)

改写完成后，需要把数据存回飞书。

• 数据清洗 (Code Node)：
  再次使用代码节点，将“原链接”和“改写后的文案”封装成飞书 Add Records 接口需要的 record_info 格式。
  注意：Key 必须与表头字段名完全一致！
• 新增记录：调用飞书插件的 Add Records，将数据写入之前创建的 Sheet 中。

💡 避坑指南 (Tips)

在实操过程中，有几个坑需要特别注意（血泪经验）：

1. 数组循环的空值问题：
   在配置 Loop 节点时，如果上一步输出的列表为空，可能会导致流程报错。建议加一个条件判断。
2. 飞书插件的参数配置：
   在代码节点配置 JSON 时，有些非必填参数（Input）其实可以不用配置，只配置 Output 变量即可。不要为了填空而填空，容易导致参数错误。
3. 字段名匹配：
   代码里构造的 JSON Key（例如 “改写文案”）必须和飞书表里的列名一字不差，否则数据会写不进去。

总结

通过这套工作流，我们实现了从“抖音链接”到“飞书表格归档”的全链路自动化。你只需要喝杯咖啡，AI 就能帮你把 1000 条文案按照爆款逻辑写好。

这就是 AI Agent 的魅力：把重复的工作交给机器，把创造力留给自己。

> 时间：2026.2.1

> 标签：#AI智能体 #Coze #扣子 #低代码开发 #Python

> 摘要：这两天在折腾 Coze（扣子）工作流时踩了两个大坑：一是批处理模式下 item 的迭代逻辑，二是飞书多维表格的数据回写格式。这篇笔记作为复盘，希望能帮大家少走弯路。

> 

🛑 踩坑一：Coze 批处理模式的“逻辑陷阱”

在处理批量任务（比如批量解析视频链接）时，很多程序员（包括我）的第一反应是找“数组下标”，想用类似 arr[i] 的方式去控制循环。但 Coze 的设计逻辑完全不同。

1. item 到底是什么？

在 Coze 的批处理节点中，item 实际上是迭代变量，而不是数组下标。

 * 误区：试图寻找 Item 0、Item 1 这样的索引访问方式。

 * 正解：当你把一个数组（例如 url_list）绑定给批处理节点后，系统会自动运行一个 For Each 循环。

流程拆解：

url_list (输入数组) → 循环遍历 → 每次取出一个元素赋值给 item → 传入节点执行。

举个简单的例子，如果你的 url_list 是 [“url_A”, “url_B”, “url_C”]：

 * 第 1 轮循环：item = “url_A”

 * 第 2 轮循环：item = “url_B”

 * 第 3 轮循环：item = “url_C”

你只需要在输入参数里填入 item，系统就会自动“喂”进当前轮次的数据。

2. 为什么要这么设计？

这种“去下标化”的设计其实是为了低代码的健壮性：

 * 防越界：不需要手动管理 i < length，避免数组越界报错。

 * 自适应：无论数组里有 3 个还是 100 个元素，配置都不用改，item 自动适配。

 * 直观：对非技术背景的开发者更友好，专注“处理当前这个”，而不是“处理第几个”。

🛠️ 实战二：用 Python 代码将对话存入飞书多维表格

意图识别后的对话数据（用户问题、AI 回复），如果想通过 API 写入飞书多维表格，直接连接通常会报错。最稳妥的方式是加一个 Python 代码节点 进行数据清洗和格式化。

1. 飞书侧准备

首先在飞书多维表格中建好表，表头名称要记住（后面代码里要用）：

 * 用户问题 (文本)

 * AI知识库回答 (文本)

 * AI大模型回答 (文本)

(此处建议插入：飞书多维表格的表头截图)

2. Coze 节点配置

在“开始”节点和“飞书-新增记录”节点之间，插入一个 Python 代码节点。

输入变量 (Input)：

 * question ← 引用自 USER_INPUT

 * answer ← 引用自 知识库回复

 * ai_answer ← 引用自 大模型回复

输出变量 (Output)：

 * 变量名：record_info

 * 关键点：变量类型必须选择 Array<Object>（数组包含对象）。因为飞书的 Add Records 接口默认接受列表格式，哪怕你只存一条数据。

(此处建议插入：Coze 代码节点输入/输出配置的截图)

3. 核心代码 (Copy 即可用)

这是由于语音输入容易出错（比如把 params 听成 PA i m s），特意整理后的标准代码。

> 注意：代码中的 Key（如 “用户问题”）必须与你飞书表格的列名一字不差！

> 

async def main(args: Args) -> Output:

    # 1. 获取输入参数

    params = args.params

    # 2. 提取字段 (对应 Input 面板的变量名)

    question = params[‘question’]

    answer = params[‘answer’]

    ai_answer = params[‘ai_answer’]

    # 3. 构建输出结构

    # 结构必须符合飞书要求：Array [ Object { fields: { … } } ]

    ret: Output = {

        “record_info”: [

            {

                “fields”: {

                    # 左边是飞书表格列名，右边是变量

                    “用户问题”: question,

                    “AI知识库回答”: answer,

                    “AI大模型回答”: ai_answer

                }

            }

        ]

    }

    # 4. 返回

    return ret

⚠️ 避坑检查清单 (Checklist)

在点击“试运行”之前，请对照检查这 4 点，能节省 90% 的 debug 时间：

 * 列名对齐：代码 fields 里的 Key 和飞书表头是否完全一致？（包括空格！）

 * 数据层级：输出的 record_info 必须包裹在 [] (List) 里，List 里面才是 {} (Dict)。直接返回 Dict 会报错。

 * 类型声明：在 IDE 右侧的输出栏，record_info 的类型选对了吗？必须是 Array，子项是 Object。

 * 空值兼容：如果 AI大模型回答 可能为空，确保飞书表格对应列允许空值，或者在代码里做个 if 判断处理。

> 写在最后：

> AI Agent 开发很多时候不是难在算法，而是难在这些中间件的数据对齐上。把这两个点打通，数据流转就顺畅多了。希望这篇笔记对你有用！

核心主题： RAG 原理、Prompt 工程、工作流编排

1. 🧠 智能体的底层逻辑：RAG (检索增强生成)

智能体的对话流本质就是三步走：输入 (Input) -> 执行 (Execution) -> 输出 (Output)。 为了让 AI 懂私有知识（比如路飞课程、公司文档），我们需要 RAG。

⚙️ 数据处理流程 (Pipeline)

1. 分块 (Chunking): 把知识库的长文本切成小块。
2. 嵌入 (Embedding): 扔进 Embedding Model，把文字变成数学向量。
3. 入库: 存入 向量数据库 (Vector DB)。

🔄 检索与生成 (Retrieval & Generation)

当用户提问时：

1. 检索: 把用户的问题也变成向量，去向量库里“搜”最相似的内容。
2. 注入: 把搜到的内容（Context）填入 Prompt。
3. 生成: Prompt + 检索到的知识 + 用户问题 -> 扔给大模型 -> 输出答案。

💡 核心价值： 解决大模型“胡说八道”的问题，让它基于事实回答。

2. 🗣️ Prompt 工程 (提示词编写)

提示词是智能体的“大脑皮层”，必须用 Markdown 格式 写才规范。

📐 结构规范

• 标题层级: 用 # 表示一级标题，## 表示二级标题（让 AI 读懂结构）。
• 变量注入: 用双大括号 {{ }} 包裹变量。
  • {{user_input}}: 用户输入的内容。
  • {{context}}: 知识库检索到的内容。

🛡️ 系统提示词 (System Prompt) 模板

Markdown

# Role

你是一个专业的课程顾问。

# Constraints

1. 你必须基于 {{context}} 回复用户，不能编造事实。

2. 如果知识库中没有答案，请直接回答“不知道”。

# Task

回答用户的问题：{{user_input}}

3. 🖼️ 图片检索与多模态

智能体不仅能回文字，还能回图片（比如返回课程海报、架构图）。

• 数据源: 本地图片、在线 URL。
• 难点: 图片多了检索不准。
• 解决方案: 人工标注 (Annotation)。给图片写一段准确的文字描述，检索时其实是在检索这段描述。

📤 图片输出的 Prompt 技巧

如果需要模型返回图片，要在 Prompt 里规定 Markdown 图片格式：

Markdown

# Task

你必须整理相关图片并返回。

# Output Format

请严格按照以下格式输出图片：


(注意：这里必须告诉模型用标准的 Markdown 图片语法，即)

4. 🔀 高级工作流：让 AI 更像人 (Router & Optimization)

为了不让 AI 变成只会答题的机器人，我们需要在检索之前加两个“脑子”：

🚦 第一关：意图识别 (Intent Recognition / Router)

• 为什么要做？ 区分用户是在“闲聊”还是“办正事”。
• 逻辑分流：
  • 👉 情况 A（打招呼/无关话题）： 走 通用大模型（回复“你好”、“天气不错”）。
  • 👉 情况 B（问课程/业务问题）： 走 知识库检索流程（RAG）。

🔧 第二关：问题优化 (Query Rewriting)

• 为什么要做？ 用户问得可能很烂、很模糊（比如只问“多少钱？”）。
• 怎么做？ 在检索之前，先用一个模型把用户的问题改写成机器能听懂的完整句子。
  • 用户问: “贵吗？”
  • 改写后: “请问课程价格是多少？” -> 再去检索知识库，准确率翻倍！