夏天又到了的专栏

当工作流的输出是多个相关产物时，必须在结尾加一个打包节点，把所有产物压缩为一个可下载的文件包。仅说3条渠道风格不同是远远不够的，必须把不同分解为受众、调性、语言、信息密度、行动指令等可量化的维度，并在每条渠道的提示词中显式落地。在产品解码节点之后，并行运行一个短视频脚本节点，把产品解码结果改写为“适合抖音／视频号的钩子—痛点—解法—行动”的脚本结构，并自动生成分镜表。在每条渠道的文案生成节点之后并行接入翻译节点，自动产出英文、日文、西班牙文等多语言版本，便于国际化品牌一站式投放全球渠道。

这一范式的转变与第 9 章经验一“多模态工作流的入口必须显式声明”在哲学层面是统一的，都是关于“工程化处理不完美现实”的智慧。本章把源可信度作为输入字段（source_metadata.trust），但实际生产中这个值应当是动态的——每次运行结束后，审计报告里都会给出“事后可信度评估”，这个评估应当回流到下次运行的先验里，让系统在多次运行中持续优化。许多初学者会把“冲突”与“异常”混为一谈，但二者本质不同——冲突是“多源不一致的事实”，异常是“某个值看起来明显错误的判断”。第五，引入治理结果的下游联动。

在本章实测中，OCR 循环子图占总耗时的 85%，是性能瓶颈，但也是后续并发化升级的天然抓手——只需把子图的串行迭代替换为并发调度，端到端耗时即可从“页数×单页时间”压缩到 max(单页时间)。值得强调的是，校验的目的是“暴露不确定性”而非“修正数字”——本章测试中故意失衡的资产负债表数据没有被工作流“修正”，而是被诚实地标注为待复核，这正是数据采集工作流应有的态度。这些元字段是工作流“诚实地表达不确定性”的载体，没有它们，AI 数据采集就退化为传统 OCR——只能给出“识别结果”，不能给出“识别质量”。

目录本章导读13.1 从工作流到应用：一次范式跃迁13.1.1 真实场景：一个被遗忘的订阅13.1.2 个人开发者面前的“三座大山”13.1.3 两种产物的边界：工作流与应用13.1.4 扣子编程的“想法到实现”能力13.2 入口：新建一个编程项目13.2.1 从“新建编程项目”说起13.2.2 三种应用形态：网页、移动、小程序13.3 一句话需求的解构：应用描述五要素13.3.1 从一段产品化的指令说起13.3.2 要素一：产品定位与平台命名13.3.3 要素二：数据模型（实体与字

本章导读通过前面章节的学习，我们体验了扣子编程如何通过“生成”来创造内容——写故事、画绘本、做营销素材、生成数据报告。这些场景的共同特征是“从无到有”。但是，在真实的商业世界里，AI 还有另一面同样重要的能力——“理解”与“结构化”，也就是把杂乱无章的现实数据，整理成机器可以直接消费的标准格式。本章以“电商图自动打标”为案例，构建一个能够看图识图、提取标签、产出结构化 JSON 的智能工作流。学习目标：（1）理解“生成”与“结构化”两类 AI 应用的差异；

这一 bug 被定位的过程（先在 cleaned.csv 中看到 858 → 追溯到 data_load_node 与 output_package_node 的 dtype 配置 → 显式声明 dtype={"stock_code": str} 并在 to_csv 阶段保持字符串格式）本身就是一个生动的 AI 协同调试案例，提示读者：AI 生成的工作流并非“开箱即生产”，仍需配合具体业务数据进行回归验证。在本章的初始页面展示中，整条流水线从开始节点出发到结束节点结束，是一条无分支的线性 DAG。

需要特别说明的是，提示词中虽然按 1~9 的顺序枚举节点（含开始节点在内），但扣子编程在落地时把“结束节点”理解为隐含的终止标记而非独立工作节点，最终生成的工作流包含 8 个工作节点（数据加载、主键对齐、字段级冲突检测、异常值检测、仲裁规则应用、数值勾稽校验、审计报告生成、输出打包），加上首尾的“开始”“结束”两个标识节点，构成完整的线性 DAG。与第 10 章的视觉理解约束相比，本章的数据对齐约束在层级上是平行的——前者是图像层的对齐（OCR 识别约束），后者是数据层的对齐（主键与字段约束）。

第二，多源合议的副产品是“自动发现单一源的错误”——某个源的数值与其他三源都不一致，往往是该源出错的强烈信号。本章工作流的能力起点则升维为“如何在多份各有偏差的源数据中决定哪个值是可信的”，本质上是“多源＋仲裁”的范式。“多源仲裁”这一范式的核心，是把数据治理从“清洗＋过滤”转变为“取证＋决策”。从这张表可以看出，本章工作流是第 10 章工作流的自然延伸——第 10 章的产出（cleaned.csv）可以直接作为本章工作流的输入之一，二者合在一起构成“非结构化 → 结构化 → 可信化”的完整数据治理链路。

本章案例提供了应对上述问题的第四条路径——数据中台同事只需把来自多个数据源的同 Schema CSV 上传到工作流，扣子编程会自主完成主键对齐、字段级冲突识别、异常值检测、仲裁规则应用、可信值生成、审计报告输出，最终返回一份“可信值表（cleaned.csv）＋冲突明细表（conflicts.csv）＋可解释审计报告（audit_report.md）”组合起来的产物。更重要的是，机器学习模型输出的是“异常分数”，而非“为什么异常”，可解释性差，难以满足合规审计要求。第五重是可解释困境。第二重是脏数据困境。

值得一提的是，在搭建过程中扣子编程还遇到了3个具有代表性的工程问题——OCR 模型 doubao-seed-1-6-vision-250815 已停运需切换、csv_output 节点的“双重 BOM”乱码、字段语义锚定节点初次尝试时 financial_table_pages 为空——这些问题都通过查日志、改配置、复测的方式被逐一定位并修复，验证了扣子编程在“问题发现 → 根因定位 → 修复回归”这一开发闭环上的工程化能力。多板块设计模拟了真实年报的内容多样性，验证表格区域定位节点的过滤能力。

叶彦辛《扣子编程从一句话到产品上线：零门槛AI心流开发》全书案例分享~_扣子编程从一句话到产品上线:零门槛ai心流开发-优快云博客10.4.1 扣子编程对扫描型PDF工作流的支持从第 9 章到第 10 章，扣子编程的工作流编排能力中再次新增了几项关键能力。具体而言：开始节点的 File 类型字段现在原生支持 PDF 格式校验与页数预读；运行时提供了循环子图（loop_graph）的标准模板，使得“在主图中以普通节点调用子图来表达循环”成为多页 PDF 处理的标准范式；代码工具节点新增了 PyMuPDF（

因此本章提示词把“严禁编造”放在合规护栏的第一条，并通过“识别不出的字段必须留空＋标注 needs_review＝Y”这一具体执行细则，把抽象的“不编造”原则落到了可机器执行的层面。提示词中“系统应自动完成 OCR 识别、表格区域定位、字段语义锚定、数值校验、异常标注，最终输出一份结构化的 CSV 文件”一句，是典型的工序声明。与第 9 章的视觉前置约束（“清晨阳光洒落的窗台”“高级灰调办公室”）相比，本章的视觉前置约束更偏工程而非美学——前者约束的是“画什么样的图”，后者约束的是“怎么看清这张图”。

这种“主图 DAG＋循环子图”的混合结构既保证了主图拓扑的清晰，也把循环逻辑封装到了独立子模块中，是扣子编程对多页／多对象处理的标准范式。本章工作流最终落地为开始与结束之间的七个核心节点：页面切分节点（pdf_split）、OCR 识别节点（ocr_loop，以循环子图形式实现）、表格区域定位节点（table_locate）、字段语义锚定节点（field_anchor）、数值校验节点（value_validate）、异常标注节点（anomaly_mark）、CSV 输出节点（csv_output）。

这位研究员的请求看似只是“把表格里的数字抄出来”，背后却隐藏了一条至少需要 4~6 个小时的高强度手工链路：先把每一份 PDF 用 OCR 工具粗转一遍文本（识别率参差不齐），再人工对照原图核对表格的每一个数字，然后把“扣除非经常性损益的净利润”等长字段映射到目标 Excel 的简称列、最后做加总核对发现勾稽关系不上时还要回头逐一定位错误。同一个会计指标在不同公司的表格中，可能有数十种文字表达——“归母净利润”“归属于上市公司股东的净利润”“归属于母公司所有者的净利润”指的是同一指标；第一种是纯人工录入。

户外背包是一个天然横跨小红书（徒步、露营生活方式）、LinkedIn（专业户外品牌的海外市场推广）、邮件营销（已注册户外会员的复购召回）三个渠道的品类，能完整呈现差异化定位的能力。把户外徒步过成治愈仪式感的太爽了”等极具情绪张力的句子抓住读者注意，正文则把背包的肩部腰部泡棉、透气网布、人体工学背负系统拆解为可感知的生活体验，结尾以多组Emoji与8个垂直标签（#户外治愈时刻 #生活仪式感 #徒步好物推荐 #品质户外装备等）收尾。把图像上传到工作流的开始节点后，无需提供任何额外的文字输入，工作流即可启动。

小红书文案节点的输入是产品解码结果（material、color_palette、key_features等），输出是包含title（标题）、body（正文）、hashtags（话题标签）3个字段的JSON。以小红书生图提示词优化节点为例，节点的系统提示词大致结构如下：你是一名资深视觉总监，请基于产品图与下面这段小红书文案，输出一段适合生图模型的英文Prompt，要求：（1）保留产品的形态特征（材质、颜色）；本节将沿着开发时间线，依次介绍各个节点的实现细节，并展示扣子编程在多模态工作流场景下的工程化能力。

第7章笔者提出的是面向Agent的提示词五要素模型，第8章在此基础上扩展为面向工作流的提示词六要素模型。本章在工作流之上又叠加了多模态输入与多渠道并行两个新维度，因此提示词设计也需要在原有方法论上进一步演进。本节将以笔者发给扣子编程的原始提示词为例，提炼面向多模态营销工作流的提示词设计七要素模型。

在进入提示词编写和节点实现之前，需要先对目标工作流应当具备的核心能力进行系统性拆解。本章工作流的能力设计与第8章相比，最大的差异在于两点：其一是入口形态由文本关键词变为图像文件，对节点的多模态能力提出了新要求；其二是出口形态由单一图文变为三套并行素材，对节点的并行编排提出了新挑战。

周一上午十点，某DTC（Direct-to-Consumer，直接面向消费者）户外品牌的新品上市经理把一幅刚刚由摄影棚拍摄完成的蓝色背包白底图发给运营团队，附上一句话：今天就要把这款新品打出去，小红书种草、LinkedIn海外B端、邮件营销国内会员，三个渠道下午之前都要上线，每个渠道一文一图，调性差异要明显。第二种是模板化工厂模式。一些较成熟的内容机构会建立可复用的模板库——小红书统一的种草文案模板、LinkedIn统一的英文Post模板、邮件营销统一的Banner模板，每次新品只需要替换产品名与卖点。

把 keyword=AI+金融、platform=小红书/公众号/视频号通用、audience=行业从业者、创业者、投资关注者、content_length=中等、mode_preference=自动判断依次填入开始节点的输入框，点击“试运行”按钮，工作流随即依次执行九个节点，并实时显示每个节点的耗时（如图 8-1所示）。这种政策、技术、企业动作三轴交织的关键词，恰好可以让工作流的全部能力都打到痛点——无论是热点筛选、模式判断、深度解读还是配图规划，都能产生明显的差异化输出。这与笔者作为人类的判断一致。

第一是多查询策略：单次查询的覆盖面有限，因此节点内部会构造两条互补的查询字符串——一条聚焦最新动态、行业新闻，另一条聚焦政策、投融资、技术突破，并在结果层做URL去重。节点内部的工程细节有三点。第二是顺序生成：四幅图按封面、正文 1、正文 2、正文 3 的顺序串行调用，便于失败重试。本章的输出契约定义为七个字段：content_mode、topic_direction、content_tone、article_result、image_prompts、generated_images、news_list。

提示词中对每个节点都做了“输入字段—任务描述—输出变量”的结构化定义。例如，新闻搜索节点：输入是keyword，任务是搜索7天内的新闻，输出是news_list；热点定调节点：输入是news_list，任务是判断热点角度，输出是topic_direction、content_tone、content_mode、key_points四个字段。这种契约化定义带来两个工程收益。

在进入具体节点设计之前，必须先回答一个范式层面的问题：同样是基于大模型的内容生成需求，第7章选择了单Agent＋多工具的范式，本章为何转而采用工作流+多节点的范式？这一问题的答案，直接决定了后续所有设计决策的走向。

同样一条新闻，不同编辑会给出不同的重要性判断，结果是有时漏掉真正的拐点，有时却给一条平淡的消息配了重磅的标题。第三是资产沉淀：每一次工作流的运行都伴随着提示词、节点配置、模型选型与输出契约的固化，这些都成为组织可复用、可迁移、可迭代的能力资产，而非某位员工的私人技能。在这一范式下，用户只需输入一个行业关键词（如AI＋金融、新能源汽车、跨境电商、低空经济），工作流系统就会自动完成新闻搜索、热点筛选、模式判断、深度分析、文章生成、配图规划、图片生产，最终输出一份可直接发布的完整图文内容。数字政府／工业互联网。

数据规模为 150 条订单，时间跨度从 2024 年 1 月至 2025 年 12 月，共 17 列字段，覆盖订单标识、时间、客户信息、地域三级、产品类别与名称、价格与数量、折扣、销售额、支付方式、渠道、销售员等维度。在获得查询结果后，Agent 自主判断每一组数据应配何种图表，并依次调用 create_chart_tool 生成了三幅图：按月销售额变化的折线图，用于呈现趋势；Agent 首先通过 exec_sql 查询了目标表的字段定义，确认 17 列字段的名称与类型后，才开始撰写业务查询。

与通用代码生成工具不同，扣子编程的工作范式有两个突出特征：其一是集成（Integration）优先，平台预置了数据库、对象存储、消息队列、大模型等常用基础设施的集成组件，开发者通过查询集成文档即可获得标准化的调用方式；其二是工具（Tool）中心，所有外部能力最终都以工具的形式挂载到 Agent 上，由大模型按需调用。相比 SQL 工具，图表生成工具（src/tools/create_chart_tool.py）是本项目的技术核心，承担了三项关键职责：图表绘制、中文字体降级、图像上传。

本节以笔者发给扣子编程的原始提示词为例，抽取其中可复用的设计原则。这段提示词虽然只有寥寥数行，其背后却隐含五个关键的设计决策。提示词页面如图7-1所示。图7-1 提示词页面。

在进入提示词编写和代码实现之前，需要先对目标Agent应具备的核心能力进行系统性拆解。能力拆解的意义在于：它决定了后续需要挂载哪些工具、选择何种模型、如何设计系统提示词。

随之而来的却是一套高度重复且难以沉淀的工作流：分析师先要把 CSV 导入数据库或用 Pandas 加载，再按不同维度撰写 SQL 查询或 DataFrame 代码，而后用 Matplotlib、Seaborn 等工具绘图，还要单独处理中文字体不显示的历史遗留问题，最后将数字、图表与结论组织成一份结构清晰、易于汇报的报告。在这一范式下，用户以自然语言表达分析意图，Agent负责自主判断查询逻辑、选择图表类型、组织报告结构，并通过外部工具（如 SQL 引擎、绘图库、对象存储）完成实际计算与交付。

让我们一起看看 AI 最终交付的应用是什么样子。它可不是一段静态的代码，而是一个鲜活、可交互的网站。

第三步，自动修复：它直接修改了代码配置，调整了 API 路由的运行环境。第四步，再次测试：再次跑了一遍，API 返回正常，如图 6-7 所示。它在调用生成故事的 API 时，控制台抛出了一段错误信息，提示当前运行环境不支持某个文件模块，如图 6-6 所示。如果是在传统低代码平台，屏幕会弹出一个刺眼的红色提示“Error”，整个流程卡死，你需要复制错误信息去百度搜索，然后回到平台手动修改节点的配置。扣子编程不是一个只会按字面指令写代码的工具，它是一个能自己看错、自己改、自己再跑的智能体。

收到指令后的几十秒里，AI 并没有傻乎乎地直接动手写代码，而是完成了一场缜密的思考过程。我们可以从开发日志中看到它的思路，如图 6-3 所示。图6-3 AI的需求分析与思考过程。

一层是业务目标——“画面连续”，这是从用户视角描述的最终效果，AI 听到后，会知道“我要解决一个跨图一致性的问题”。另一层是技术策略——“使用 seedream 4.5 的 sequential image generation 模式”，这相当于明确指定了“用哪一把钥匙”去打开锁，避免 AI 在多种可选方案中犹豫不决，或者错选一个不擅长保持一致性的模型。我希望开发一个给儿童的绘本生成网站，用户输入一个主题，自动生成一个绘本脚本，然后根据绘本脚本内容，生成最高。开发者从“泥瓦匠”变成了“产品经理”。

某天晚上，孩子（或弟弟妹妹）拉着你的手说，今晚想听一个关于“勇敢的小松鼠”的故事。摆在你面前的，往往是几条令人犯难的路径——去书店买一本相关主题的绘本，但你想要的具体细节书里大概率没有；如果你玩过 AI 生图就会有体会——第一幅图生成了一只褐色蓬松尾巴的小松鼠，第二幅可能就变成了灰色小尾巴；有了扣子编程，事情就变得简单许多：你只需要告诉 AI 你想要什么，它就把整个应用做好。最终效果如图 6-1 所示，输入主题“友谊的力量”后，AI 生成了一本图文并茂的儿童绘本《小松鼠和月亮果》。

扣子编程从一句话到产品上线》是一本恰逢其时的书。它站在了AI从“聊天”走向“行动”、从“辅助”走向“自主”的转折点上。如果你渴望在这个AI原生时代抓住机遇，如果你想把自己的想法真正落地为产品，如果你想体验那种“心流开发”的酣畅淋漓，那么，请翻开这本书。告别琐碎的拖拉拽，把目光投向远方的城池。你的创造之旅，将从这一句话开始。

通过这个跌宕起伏的案例，我们可以提炼出三条对所有 AI 编程项目都适用的“金律”。

本章案例使用扣子编程开发小红书爆款笔记生成智能体，严格遵循平台官方开发流程，整体分为“前期需求规划→首轮提示词开发→功能迭代”等阶段，全程无需编写代码，仅依靠自然语言完成所有开发与修改工作，充分体现了扣子编程“低门槛、全流程 AI 辅助” 的核心优势。最终成品实现了“输入任意主题，自动生成标题、文案、封面全套小红书爆款笔记”的核心目标，覆盖干货、情感、美食、学习、小众细分等全场景，满足个人博主、内容运营的日常创作需求。解决方案：新增“场景自适应”逻辑，让 AI 识别主题类型，匹配专属创作模板。

本书延续上一本书“由浅入深、案例驱动”的写法，共分13章，循着一条清晰的能力进阶之路徐徐展开。第1~3章是入门与筑基。第1章介绍扣子编程开发平台，帮助读者认识这套全新的 AI原生开发环境；第2章是通过案例熟悉扣子编程，手把手带领读者走通网页应用、智能体、工作流的完整流程；第3章讲解扣子编程中技能（Skills）开发，结合“挑选短线强势涨停股”的需求，让大家理解如何开发与部署技能。第4~7章是一段话或一句话造物，对应着扣子的Vibe Coding。

每个工作日的早晨，你的日程往往是这样的——八点钟打开谷歌、百度、微博热搜，像大海捞针一样寻找当天值得讨论的科技话题；十点钟打开 Photoshop 或 Canva，套用模板，把文字粘贴进去，再为每一幅图找配图、调字号、对齐元素，重复十次；在传统开发模式下，要把这套流程自动化，至少需要一个三人技术团队干上两周——产品经理画原型、前端写界面、后端对接搜索引擎和图片生成接口。本章将扮演一位“只动口不动手”的产品经理，用几段中文对话，让AI从零构建出一个可以直接发布的Web应用。

本章开发的小红书爆款笔记生成智能体，面向自媒体博主、内容运营、学生、普通用户等群体。用户仅需输入单一主题（如减肥、居家收纳、考研备考、平价护肤、短途旅行等），智能体自动输出一套完整的小红书笔记内容，包含爆款标题、分段式正文文案、专属封面设计方案，内容贴合小红书主流风格，具备高点击率、高互动性的特点。遵循小红书爆款标题逻辑，融合痛点提问、数字总结、情绪引导、悬念引流四大主流形式，标题字数控制在 15~20 字，可搭配适配 Emoji，拒绝生硬营销感，避免标题党与平台违规词汇，提升笔记打开率。