扣子編程從一句話到產品上線：零門檻AI心流開發

第 1 章　扣子編程平臺介紹1

1.1　扣子編程簡介1

1.1.1　扣子編程能做什麼1

1.1.2　為什麼選擇扣子編程2

1.1.3　扣子平臺架構3

1.1.4　扣子平臺訂閱套餐4

1.2　智能體概述6

1.2.1　什麼是智能體及智能體的本質6

1.2.2　智能體的兩大類型6

1.3　天氣查詢智能體開發與部署案例7

1.3.1　智能體開發7

1.3.2　智能體部署9

1.4　本章小結13

1.5　思考與練習13

第 2 章　通過案例熟悉扣子編程14

2.1　開發網頁應用14

2.1.1　輸入需求14

2.1.2　進階配置15

2.1.3　開發應用16

2.2　開發智能體18

2.2.1　輸入提示詞18

2.2.2　測試智能體19

2.3　開發工作流21

2.3.1　AI編程開發工作流21

2.3.2　試運行及疊代工作流22

2.4　本章小結24

2.5　思考與練習24

第3章　扣子編程的技能開發25

3.1　技能介紹25

3.1.1　什麼是技能 25

3.1.2　技能與插件的本質區別26

3.2　技能的格式和工作機制27

3.2.1　技能標準文件結構27

3.2.2　技能的完整運行機制27

3.3　技能開發基礎：Markdown語法28

3.4　技能開發案例：挑選短線強勢漲停股31

3.4.1　技能的設計31

3.4.2　技能的開發32

3.4.3　技能的部署34

3.5　本章小結35

3.6　思考與練習35

第4章　一段提示詞造智能體：小紅書爆款筆記生成36

4.1　項目規劃與需求梳理36

4.1.1　核心功能需求37

4.1.2　開發前的準備38

4.2　開發智能體39

4.2.1　第一輪開發：編寫提示詞生成基礎智能體39

4.2.2　第二輪疊代：針對性優化內容細節與創作邏輯41

4.2.3　第三輪疊代：增加多風格模式與內容多樣性42

4.2.4　後續長期疊代與維護方案43

4.3　開發總結和復盤44

4.4　本章小結45

4.5　思考與練習45

第 5 章　一句話造網站：每日信息差生成器46

5.1　項目背景：自媒體人的“早晨四小時”46

5.1.1　一個真實的工作場景46

5.1.2　我們的目標：把四小時壓縮到三十秒47

5.2　開發指令的設計47

5.2.1　一句話需求47

5.2.2　深度拆解：AI從這句話裏讀到了什麼47

5.3　見證奇跡：AI 的自主構建過程48

5.3.1　任務規劃：先畫圖紙，再動工48

5.3.2　全棧代碼生成：並發優化自動完成48

5.4　危機與轉機：圖片全掛了48

5.4.1　事故現場48

5.4.2　一句話反饋，AI 自主完成修復48

5.4.3　診斷、修復與意外收獲49

5.5　最終成果驗收49

5.6　三條心法：如何駕馭 AI 編程50

5.7　本章小結51

5.8　思考與練習51

第 6 章　一句話造應用：兒童繪本夢工廠52

6.1　項目背景52

6.1.1　真實場景：睡前故事的煩惱52

6.1.2　本案例的核心難點：畫面一致性54

6.2　提示詞設計：業務目標 + 技術策略54

6.2.1　一句話指令54

6.2.2　業務目標與技術策略的雙重聲明54

6.3　AI的“心理活動”：比你想得更周全55

6.3.1　第一步：拆解需求55

6.3.2　第二步：環境偵察55

6.3.3　第三步：制訂計劃56

6.4　關鍵時刻：它自己修好了 Bug56

6.5　成果展示：所見即所得58

6.5.1　界面：懂你沒說出口的審美58

6.5.2　連續畫風：技術實力的體現58

6.5.3　自動排版：上圖下文60

6.6　總結：從“如何做”到“做什麼”60

6.7　本章小結61

6.8　思考與練習61

第 7 章　數據分析專家Agent62

7.1　項目背景與價值62

7.1.1　從真實工作場景說起62

7.1.2　傳統數據分析方案的三條路徑與各自的痛點63

7.1.3　大模型時代的第四條路徑：智能體化63

7.1.4　典型應用場景63

7.2　Agent能力設計64

7.2.1　動態 SQL 查詢能力64

7.2.2　Python 可視化能力64

7.2.3　Markdown 報告生成能力64

7.2.4　能力協同：編排才是真正的難點65

7.3　面向Agent的提示詞設計方法論65

7.3.1　從一段提示詞說起65

7.3.2　決策點一：角色定位先於能力描述65

7.3.3　決策點二：用動詞拆解能力65

7.3.4　決策點三：明確數據來源66

7.3.5　決策點四：關鍵約束前置聲明66

7.3.6　決策點五：指定輸出格式66

7.4　基於扣子編程的實現過程67

7.4.1　扣子編程的工作範式67

7.4.2　集成組件的識別與選用67

7.4.3　工具實現一：SQL 執行工具68

7.4.4　工具實現二：圖表生成工具68

7.4.5　Agent 主體編排69

7.4.6　調試過程中的典型問題70

7.5　運行效果驗證72

7.5.1　測試數據集的設計思路72

7.5.2　Agent的執行流程展示73

7.5.3　三幅圖的中文渲染驗證74

7.5.4　Markdown 報告的完整輸出76

7.5.5　與設計目標的逐項對照78

7.6　經驗總結與遷移應用78

7.6.1　五條關鍵經驗78

7.6.2　遷移場景矩陣79

7.6.3　擴展方向展望79

7.6.4　當前版本的局限性79

7.7　本章小結80

7.8　思考與練習80

第 8 章　行業熱點內容生成工作流 81

8.1　項目背景與價值81

8.1.1　從一位新媒體編輯的清晨說起81

8.1.2　內容生產的五重難關82

8.1.3　傳統應對方案的三種姿態82

8.1.4　工作流時代的新答案83

8.1.5　典型應用場景83

8.2　工作流與單Agent：能力設計的範式選擇84

8.2.1　Agent與工作流的本質差異84

8.2.2　適用邊界的判斷準則84

8.2.3　九節點能力拆解85

8.2.4　條件分支：讓流程具備判斷力86

8.2.5　編排難點：節點契約與數據流86

8.3　面向工作流的提示詞設計方法論86

8.3.1　從一段完整的工作流提示詞說起86

8.3.2　決策點一：先描述目標，再描述結構87

8.3.3　決策點二：節點輸入輸出的契約化定義87

8.3.4　決策點三：分支與路由的顯式化88

8.3.5　決策點四：模型能力與外部能力的混合編排88

8.3.6　決策點五：終端輸出的可發布性約束88

8.3.7　決策點六：圖像生成的視覺約束88

8.4　工作流九個節點的實現過程89

8.4.1　節點1：開始節點與字段約束89

8.4.2　節點2：新聞搜索節點（聯網搜索）90

8.4.3　節點3：熱點定調節點（大語言模型）91

8.4.4　節點4：內容模式路由節點（條件判斷）92

8.4.5　節點5：深度解讀與盤點匯總（雙分支）92

8.4.6　節點6：文章生成節點（結構化輸出）93

8.4.7　節點7：圖片提示詞規劃節點94

8.4.8　節點8：圖片生成節點（生圖模型）94

8.4.9　節點9：結束節點與輸出契約95

8.4.10　調試過程中的典型問題95

8.5　運行效果驗證96

8.5.1　測試關鍵詞的設計思路96

8.5.2　工作流執行流程展示97

8.5.3　輸出結果剖析97

8.5.4　與設計目標的逐項對照98

8.6　經驗總結與遷移應用99

8.6.1　六個關鍵經驗99

8.6.2　遷移場景矩陣100

8.6.3　擴展方向展望100

8.6.4　當前版本的局限性100

8.7　本章小結101

8.8　思考與練習102

第9章　產品全渠道營銷工作流 103

9.1　項目背景與價值104

9.1.1　從一位品牌運營經理的清晨說起104

9.1.2　全渠道營銷的四重困境104

9.1.3　傳統應對方案的三種模式104

9.1.4　多模態工作流時代的新答案105

9.1.5　典型應用場景105

9.2　工作流能力設計：從單輸入到多輸出的能力分層106

9.2.1　多模態輸入：讓圖像成為工作流的第一驅動力106

9.2.2　三渠道差異化：內容人格的精確切分107

9.2.3　能力拆解：8+3節點的工程化劃分107

9.2.4　並行與串行：讓差異化與一致性同時成立108

9.3　面向多模態工作流的提示詞設計方法論109

9.3.1　從一段完整的工作流提示詞開始109

9.3.2　決策點一：多模態輸入的顯式聲明110

9.3.3　決策點二：先解碼、後創作的工序聲明110

9.3.4　決策點三：差異化人格的角色化描述110

9.3.5　決策點四：每條渠道的視覺氛圍前置約束110

9.3.6　決策點五：文案與配圖的串行依賴聲明111

9.3.7　決策點六：合規護欄的隱式植入111

9.3.8　決策點七：終局打包的輸出契約111

9.4　基於扣子3.0的實現過程112

9.4.1　扣子編程對多模態工作流的支持112

9.4.2　集成識別與選用112

9.4.3　節點1：產品解碼節點113

9.4.4　節點2/5/8：三渠道文案生成節點114

9.4.5　節點3/6/9：三渠道生圖提示詞優化節點114

9.4.6　節點4/7/10：三渠道圖片渲染節點115

9.4.7　節點11：素材打包節點115

9.4.8　主圖編排：讓11個節點協同流動116

9.5　運行效果驗證117

9.5.1　測試輸入設計117

9.5.2　工作流執行流程展示118

9.5.3　三套素材輸出剖析119

9.5.4　與設計目標的逐項對照121

9.6　經驗總結與遷移應用121

9.6.1　七個關鍵經驗121

9.6.2　遷移場景矩陣122

9.6.3　擴展方向展望122

9.6.4　當前版本的局限性123

9.7　本章小結124

9.8　思考與練習124

第 10 章　AI數據采集工作流126

10.1　項目背景與價值127

10.1.1　從一位證券研究員的清晨說起127

10.1.2　非結構化數據的四重困境127

10.1.3　傳統應對方案的三種姿態128

10.1.4　AI數據采集時代的新答案128

10.1.5　典型應用場景129

10.2　工作流能力設計：從輸入端範式到輸出端範式的轉向129

10.2.1　輸出端範式：目標Schema驅動的提取129

10.2.2　數據采集與數據生成的適用邊界130

10.2.3　七節點能力拆解130

10.2.4　數值校驗閉環：讓AI數據采集“可信”131

10.3　面向數據采集工作流的提示詞設計方法論132

10.3.1　從一段完整的工作流提示詞說起132

10.3.2　決策點一：輸入形態的具體化聲明134

10.3.3　決策點二：目標Schema驅動135

10.3.4　決策點三：工序聲明先於節點結構135

10.3.5　決策點四：角色化描述的隱式植入135

10.3.6　決策點五：視覺理解約束的前置聲明136

10.3.7　決策點六：數值校驗閉環的顯式契約136

10.3.8　決策點七：合規與質量護欄136

10.3.9　決策點八：輸出契約的多產物聲明136

10.4　基於扣子編程的實現過程137

10.4.1　扣子編程對掃描型PDF工作流的支持137

10.4.2　集成識別與選用137

10.4.3　節點1：開始節點與字段約束138

10.4.4　節點2：頁面切分節點（pdf_split）139

10.4.5　節點3：OCR 識別節點（ocr_loop，循環子圖）139

10.4.6　節點4：表格區域定位節點（table_locate）140

10.4.7　節點5：字段語義錨定節點（field_anchor）141

10.4.8　節點6：數值校驗節點（value_validate）142

10.4.9　節點7：異常標註節點（anomaly_mark）143

10.4.10　節點8：CSV 輸出節點（csv_output）143

10.5　運行效果驗證144

10.5.1　測試輸入設計144

10.5.2　工作流執行流程展示145

10.5.3　CSV 輸出結果剖析146

10.5.4　與設計目標的逐項對照147

10.6　經驗總結與遷移應用148

10.6.1　八個關鍵經驗148

10.6.2　遷移場景矩陣149

10.6.3　擴展方向展望150

10.6.4　當前版本的局限性150

10.7　本章小結151

10.8　思考與練習152

第 11 章　AI 數據質檢工作流154

11.1　項目背景與價值155

11.1.1　從一位投研經理的下午說起155

11.1.2　多源數據沖突的五重困境155

11.1.3　傳統數據質檢方案的三種姿態156

11.1.4　AI數據質檢時代的新答案156

11.1.5　典型應用場景157

11.2　工作流能力設計：從單源采集到多源仲裁157

11.2.1　數據治理的範式躍遷：從單源采集到多源仲裁158

11.2.2　數據采集與數據質檢的能力邊界158

11.2.3　八節點能力拆解159

11.2.4　仲裁規則：讓沖突變得可解釋159

11.3　面向多源數據質檢工作流的提示詞設計方法論160

11.3.1　從一段完整的工作流提示詞說起160

11.3.2　決策點一：多源輸入形態的顯式聲明162

11.3.3　決策點二：目標 Schema 與主鍵的同步聲明163

11.3.4　決策點三：工序聲明先於節點結構163

11.3.5　決策點四：角色化描述的隱式植入163

11.3.6　決策點五：數據對齊約束的前置聲明163

11.3.7　決策點六：多源沖突仲裁規則164

11.3.8　決策點七：數值校驗閉環的延續164

11.3.9　決策點八：合規與質量護欄164

11.3.10　決策點九：輸出契約的多產物聲明165

11.4　基於扣子編程的實現過程165

11.4.1　扣子編程對多源數據治理的支持165

11.4.2　集成識別與選用166

11.4.3　節點1：開始節點與字段約束166

11.4.4　節點2：數據加載節點167

11.4.5　節點3：主鍵對齊節點167

11.4.6　節點4：字段級沖突檢測節點168

11.4.7　節點5：異常值檢測節點168

11.4.8　節點6：仲裁規則應用節點169

11.4.9　節點7：數值勾稽校驗節點170

11.4.10　節點8：審計報告生成節點171

11.4.11　節點9：輸出打包節點172

11.5　運行效果驗證172

11.5.1　測試輸入設計172

11.5.2　工作流執行流程展示173

11.5.3　三類核心輸出剖析174

11.5.4　與設計目標的逐項對照176

11.6　經驗總結與遷移應用177

11.6.1　九個關鍵經驗177

11.6.2　遷移場景矩陣178

11.6.3　擴展方向展望179

11.7　本章小結180

11.8　思考與練習181

第 12 章　電商圖自動打標工作流182

12.1　項目背景與價值182

12.1.1　真實場景：雙十一前的 500 款新品182

12.1.2　用 AI 工作流解決的新思路183

12.1.3　本案例的兩個隱形大坑183

12.2　工作流的設計：像 CTO 一樣思考183

12.2.1　一段工程化的指令183

12.2.2　拆解：AI 是如何理解“工程化指令”的184

12.3　關鍵技術突破185

12.3.1　預處理：給 AI 戴上一副“眼鏡”185

12.3.2　結構化輸出：讓數據“規規矩矩”185

12.4　運行驗證：見證“金牌理貨員”的誕生186

12.4.1　處理過程186

12.4.2　最終產出186

12.4.3　設計目標與實際運行結果的對照186

12.5　經驗總結與遷移應用187

12.5.1　三條避坑指南187

12.5.2　遷移場景矩陣187

12.6　本章小結187

12.7　思考與練習188

第13章　從一句話需求到上線“續費管家”小程序189

13.1　從工作流到應用：一次範式躍遷190

13.1.1　真實場景：一個被遺忘的訂閱190

13.1.2　個人開發者面前的“三座大山”190

13.1.3　兩種產物的邊界：工作流與應用191

13.1.4　扣子編程的“想法到實現”能力191

13.2　入口：新建一個編程項目192

13.2.1　從“新建編程項目”說起192

13.2.2　三種應用形態：網頁、移動、小程序192

13.3　一句話需求的解構：應用描述五要素193

13.3.1　從一段產品化的指令說起193

13.3.2　要素一：產品定位與平臺命名194

13.3.3　要素二：數據模型（實體與字段）194

13.3.4　要素三：頁面與導航結構195

13.3.5　要素四：業務規則與計算邏輯195

13.3.6　要素五：設計與部署約束195

13.4　實現過程：一名“數字全棧工程師”的工作日誌196

13.4.1　第一步：勘探與規劃——AI如何理解“做一個應用”196

13.4.2　第二步：技術棧選型——Taro＋NestJS＋Supabase197

13.4.3　第三步：後端API——一組規整的RESTful接口198

13.4.4　第四步：前端三頁面與TabBar198

13.4.5　第五步：五道驗證關卡199

13.5　AI協同調試：3個真實的工程現場199

13.5.1　現場一：被誤刪的函數體（formatCost）199

13.5.2　現場二：toast函數簽名不匹配200

13.5.3　現場三：小程序不兼容的小數類名200

13.6　運行驗證：慶賀“續費管家”的誕生201

13.6.1　五項驗證全部通過202

13.6.2　前後端契約匹配驗證202

13.6.3　成品一覽：運行界面202

13.6.4　預覽與發布：配置小程序AppID203

13.6.5　設計目標與實際交付的對照203

13.7　經驗總結與遷移應用204

13.7.1　七條關鍵經驗204

13.7.2　遷移場景矩陣205

13.7.3　何時用應用生成，何時用工作流編排205

13.8　本章小結206

13.9　思考與練習206