docs: stage-1 i18n coverage + news
This commit is contained in:
sanbuphy
@@ -0,0 +1,82 @@
|
||||
# 專案介紹
|
||||
|
||||
2025年，被很多人視為AI程式設計的元年。越來越多的人開始用AI寫程式碼，但往往做出來的還停留在玩具層面——不知道如何用Vibe Coding組織開發流程，不知道該選哪些工具，更不清楚從原型到上線中間還差哪些關鍵步驟。
|
||||
|
||||
我們採用循序漸進的**三階段實戰路徑**：新手入門階段透過小遊戲快速上手AI程式設計，第一階段掌握Vibe Coding工作方式並完成Web應用原型，第二階段學習全棧開發與部署上線，第三階段構建跨平臺複雜應用。
|
||||
|
||||
每個階段都配有完整專案實戰，讓你在真實挑戰中從玩具走向產品，最終具備**將任何想法落地為可用應用**的能力。
|
||||
|
||||
我們相信，掌握Vibe Coding並配合系統化訓練，你一個人就能成為**集前後端開發、AI能力整合、產品設計於一身的全能開發者**。
|
||||
|
||||
本專案主要面向三類學習者：
|
||||
|
||||
- **新手（普通人 / 產品與運營側）**：幫助非技術背景角色和入門學習者聽懂關鍵概念，完成第一個 AI 小工具或產品原型。
|
||||
- **初中級開發者（有一定基礎的學生和開發者）**：系統掌握 vibe coding 與原生 AI 應用開發。
|
||||
- **高階開發者（公司與初創、開源與獨立開發者）**：支援團隊和個人快速搭建、驗證與迭代原生 AI 應用。
|
||||
|
||||
## 📖 內容導航
|
||||
|
||||
### 總附錄
|
||||
|
||||
[AI 能力詞典：常見 AI 核心概念與名詞、場景解釋](/zh-tw/appendix/8-artificial-intelligence/ai-capability-dictionary)
|
||||
|
||||
### 零、幼兒園
|
||||
|
||||
| 章節 | 關鍵內容 | 狀態 |
|
||||
| :------------------------------------------------------------------------------------- | :------------------------------------- | :--- |
|
||||
| [新手入門：學習地圖](/zh-tw/stage-1/learning-map/) | 整體學習路徑導覽 | ✅ |
|
||||
| [新手入門：AI 時代，會說話就會程式設計](/zh-tw/stage-1/ai-capabilities-through-games/) | 透過貪喫蛇等案例初步感受 AI 程式設計的能力 | ✅ |
|
||||
|
||||
### 一、AI 產品經理
|
||||
|
||||
| 章節 | 關鍵內容 | 狀態 |
|
||||
| :---------------------------------------------------------------------------- | :------------------------------------------------------- | :--- |
|
||||
| [初級二：認識 AI IDE 工具](/zh-tw/stage-1/introduction-to-ai-ide/) | 學會使用 IDE，掌握介面結構和高效提示方式 | ✅ |
|
||||
| [初級三：動手做出原型](/zh-tw/stage-1/building-prototype/) | 從產品分析拆解，到多頁面產品原型實現的完整閉環 | ✅ |
|
||||
| [初級四：給原型加上 AI 能力](/zh-tw/stage-1/integrating-ai-capabilities/) | 理解並完成常見 AI 能力（文字圖片影片）的 API 接入 | ✅ |
|
||||
| [初級五：完整專案實戰](/zh-tw/stage-1/complete-project-practice/) | 模擬真實場景、接受使用者反饋迭代並完成專案展示（含大作業） | ✅ |
|
||||
|
||||
#### 附錄
|
||||
|
||||
| 章節 | 關鍵內容 | 狀態 |
|
||||
| :-------------------------------------------------------------------- | :---------------------------------------- | :--- |
|
||||
| [附錄A：產品思維補充](/zh-tw/stage-1/appendix-a-product-thinking/) | 從想法評估到需求拆解與 MVP 的產品思維框架 | ✅ |
|
||||
| [附錄B：常見報錯及解決方案](/zh-tw/stage-1/appendix-b-common-errors/) | vibe coding 中的常見錯誤及排查方法 | ✅ |
|
||||
| [附錄：從哪裡找點子](/zh-tw/stage-1/appendix-idea-sources/) | 從參考應用、趨勢和 VC 清單裡收出細分方向 | ✅ |
|
||||
| [附錄：雙鑽模型](/zh-tw/stage-1/appendix-double-diamond/) | 理解先定義問題，再展開方案設計的完整節奏 | ✅ |
|
||||
| [附錄：Jobs to Be Done](/zh-tw/stage-1/appendix-jobs-to-be-done/) | 用 JTBD 方法看清使用者真正想完成的事 | ✅ |
|
||||
| [附錄：The Mom Test 使用者訪談法](/zh-tw/stage-1/appendix-mom-test/) | 透過使用者訪談驗證需求的調研方法 | ✅ |
|
||||
|
||||
### 二、初中級開發工程師
|
||||
|
||||
#### 前端部分
|
||||
|
||||
| 章節 | 關鍵內容 | 狀態 |
|
||||
| :------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------- | :--- |
|
||||
| 使用 lovart 生產素材 | 學會用 lovart 批次生成人物、場景等視覺素材，為 UI 設計和前端開發提供素材基礎 | 🚧 |
|
||||
| Figma 與 MasterGo 入門 | 用設計工具梳理資訊架構和頁面結構，為前端實現打基礎 | 🚧 |
|
||||
| 構建第一個現代應用程式-UI 設計 | 基於設計稿完成元件化介面，實現從設計到程式碼的第一條鏈路 | 🚧 |
|
||||
| 參考 UI 設計規範設計頁面和按鈕 | 學習用主流設計規範組織頁面結構、按鈕層級，並藉助 AI 生成設計方案 | 🚧 |
|
||||
| [一起做霍格沃茨畫像](/zh-tw/stage-2/frontend/hogwarts-portraits/) | 從 0 到 1 做出接入 AI 能力的前端應用，串聯設計與開發 | 🚧 |
|
||||
|
||||
#### 後端開發部分
|
||||
|
||||
| 章節 | 關鍵內容 | 狀態 |
|
||||
| :---------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------ | :--- |
|
||||
| 什麼是 API | 理解 HTTP 介面與請求響應模型，為後端整合與聯調做準備 | 🚧 |
|
||||
| [從資料庫到 Supabase](/zh-tw/stage-2/backend/database-supabase/) | 在 Supabase 上落地資料庫和 API，打通資料模型與前端頁面 | 🚧 |
|
||||
| 大模型輔助編寫介面程式碼與介面文件 | 用大模型協助生成介面與資料庫文件及程式碼，實現可讀可測的後端 | 🚧 |
|
||||
| Git 工作流與 Zeabur 部署 | 在 Git 工作流中管理程式碼，並將應用部署到 Zeabur 上線 | 🚧 |
|
||||
| 現代 CLI 開發工具 | 使用 CLI 類 AI 程式設計工具加速開發與除錯，形成個人工程化工作流 | 🚧 |
|
||||
| 如何整合 stripe 等收費系統 | 接入支付系統，完成收費鏈路與基礎結算流程 | 🚧 |
|
||||
| 構建第一個現代應用程式-全棧應用 | 綜合前端、後端與支付模組，完成可上線的全棧 Web 應用 | 🚧 |
|
||||
| 現代前端元件庫 + Trae 實戰 | 使用現代前端元件庫與 Trae，獨立完成可登入註冊並支援收費的產品 | 🚧 |
|
||||
|
||||
#### AI 能力附錄
|
||||
|
||||
| 章節 | 關鍵內容 | 狀態 |
|
||||
| :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------- | :--- |
|
||||
| [Dify 入門與知識庫整合](/zh-tw/stage-2/ai-capabilities/dify-knowledge-base/) | 用 Dify Workflow 與基礎 RAG 搭建工具類產品，為後續應用升級打樣 | 🚧 |
|
||||
| 學會查詢 AI 詞典與整合多模態 API | 學會查詢合適的模型與 API，並把文字、影象等多模態能力接入產品 | 🚧 |
|
||||
|
||||
### 三、高階開發工程師
|
||||
@@ -0,0 +1,768 @@
|
||||
# 初級一：AI 時代，會說話就會程式設計
|
||||
|
||||
這是一個**基於專案制學習**的學習教程。我們鼓勵你跟隨步驟一步步操作，並嘗試復現結果。
|
||||
不要擔心犯錯或修改內容，我們永遠相信你可以做到，請你永遠記住：
|
||||
|
||||
<div style="text-align: center;">
|
||||
<div style="display: inline-block; padding: 8px 20px; border-radius: 8px; border: 1px dashed #FFB6C1; background: linear-gradient(135deg, #FFF0F5 0%, #FFE4EC 100%); margin: 12px 0;">
|
||||
<span style="font-size: 15px; font-weight: 500; color: #666;">完成比完美更重要 🐣</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>4 小時</strong>，可分多次完成'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['zh-tw/stage-1/ai-capabilities-through-games'] ?? []
|
||||
</script>
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['對話式 AI 程式設計', 'AI 原生小遊戲', '貪喫蛇實戰']" coreOutput="AI 原生貪喫蛇 + 自創小遊戲" expectedOutput="1 個可執行的 AI 原生貪喫蛇 + （可選）1 個你自創的 AI 原生小遊戲或 Demo">
|
||||
|
||||
如果你<strong>完全不會程式設計</strong>，或者只會一點皮毛，這一章就是為你準備的。我們會從最基礎的開始：用<strong>對話的方式</strong>讓 AI 幫你寫程式碼，不需要記語法、不需要配環境，直接在網頁上就能跑起來。
|
||||
|
||||
你會親手做出<strong>第一個能執行的程式</strong>——一款會"喫單詞、寫詩、畫畫"的貪喫蛇。透過這個實戰，你會體驗到 AI 程式設計到底是什麼感覺：不是 AI 代替你思考，而是你把想法說出來，AI 幫你實現。
|
||||
|
||||
所有的創造都是從 0 到 1 開始的，很高興能將每一份信心與專業度傳遞與你，於你而言，<strong>執行力 is all you need</strong>。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '困境與機會', description: '普通人的程式設計新可能' },
|
||||
{ title: '能力初探', description: '60秒極速開發體驗' },
|
||||
{ title: '原生實戰', description: '打造AI原生貪喫蛇' },
|
||||
{ title: '拓展創造', description: '舉一反三做遊戲' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 普通人的困境與機會
|
||||
|
||||
很多人腦子裡有一堆產品點子：一款幫自己記賬的小工具、一個記錄孩子成長的網頁、甚至一款小遊戲。但一想到要寫程式碼、要找程式設計師，就直接勸退。
|
||||
|
||||
AI 出現之後，第一次給了普通人一個全新的可能：你不需要會寫程式碼，只需要學會對 AI 說清楚你想要什麼。來自 GitHub Copilot 的[資料顯示](https://www.wearetenet.com/blog/github-copilot-usage-data-statistics)，超過1500萬開發者正在用AI輔助程式設計，平均46%的程式碼都是AI生成的! 在Java專案中這個比例能達到61%。
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="display: flex; align-items: center; gap: 8px;">
|
||||
<span style="font-size: 20px;">🚀</span>
|
||||
<span style="font-weight: bold; font-size: 16px;">效率與採用率的飛躍</span>
|
||||
</div>
|
||||
</template>
|
||||
|
||||
<el-row :gutter="20" style="margin-bottom: 24px;">
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #409EFF; font-size: 24px; font-weight: bold;">55%</div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">速度提升</div>
|
||||
</div>
|
||||
</el-col>
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #67C23A; font-size: 24px; font-weight: bold;">2.4 <span style="font-size: 14px;">天</span></div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">任務耗時 (原9.6天)</div>
|
||||
</div>
|
||||
</el-col>
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #E6A23C; font-size: 24px; font-weight: bold;">81%</div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">首日安裝率</div>
|
||||
</div>
|
||||
</el-col>
|
||||
<el-col :span="6" :xs="12">
|
||||
<div style="text-align: center; padding: 10px;">
|
||||
<div style="color: #F56C6C; font-size: 24px; font-weight: bold;">96%</div>
|
||||
<div style="color: #909399; font-size: 12px; margin-top: 4px;">建議採納率</div>
|
||||
</div>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
<div style="line-height: 1.8; color: #606266;">
|
||||
讓人真正興奮的是效率的飛躍：開發者完成任務的速度提升了 <b>55%</b>。原本需要 9.6 天才能提交的程式碼，現在只要 <b>2.4 天</b>就能搞定。 這種肉眼可見的效率提升，說明 AI 不再只是一個“可選工具”，而是正在成為開發流程中不可或缺的程式設計助手。採用率的資料也印證了這一點：在獲得訪問許可權的當天，就有 <b>81%</b> 的開發者第一時間完成安裝並開始使用；其中 <b>96%</b> 的人更是在當天就開始採納 AI 提供的程式碼建議。換句話說，開發者幾乎是立刻把 AI 融入了日常編碼工作。
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
對於普通人來說,這個趨勢更有意義:如果專業程式設計師都在大量依賴AI寫程式碼,那我們這些**不會程式設計的人,為什麼不能直接跟AI對話來實現自己的想法呢**?
|
||||
|
||||
這門課的目標是幫你練成新技能：透過自然語言對話就能做應用。我們將教你怎麼跟 AI 用計算機的語言溝通、怎麼讓AI幫你把腦子裡的想法變成真實可用的產品。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: '困境與機會', description: '普通人的程式設計新可能' },
|
||||
{ title: '能力初探', description: '60秒極速開發體驗' },
|
||||
{ title: '原生實戰', description: '打造AI原生貪喫蛇' },
|
||||
{ title: '拓展創造', description: '舉一反三做遊戲' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. AI 能幫你做到什麼程度
|
||||
|
||||
在本節中，我們只討論一個問題：如果你完全不會寫程式碼，現在的 AI 能幫你做到什麼程度？
|
||||
|
||||
大致來說，你可以把當前大模型的能力理解為：可以勝任**簡單的內部小工具**、**資料視覺化看板**，以及一些**輕量級小遊戲**的開發。這些能力用來做**自用工具**、從**產品經理視角驗證需求**，基本已經足夠。但若想一鍵生成可直接**商用的成熟產品**，通常仍需要人工在**流程設計**、**細節打磨**上持續最佳化。
|
||||
|
||||
接下來，我們就以貪喫蛇為例，具體看看 AI 程式設計目前到底能做到什麼程度。
|
||||
|
||||
### 2.1 60 秒做一個貪喫蛇遊戲
|
||||
|
||||
首先，請你開啟課程中使用的實驗網頁 [z.ai](https://chat.z.ai/)，`z.ai` 是由智譜 AI（中國領先的大語言模型公司之一）開發的 AI 平臺，其核心能力由智譜自研的 GLM 系列大模型提供支援。該平臺整合了多項 AI 功能，包括幻燈片生成、海報設計和全棧開發等。在本教程中，我們將重點介紹其全棧開發模組的使用。
|
||||
|
||||
::: details 💡 什麼是「網頁就能程式設計」的新模式？
|
||||
|
||||
過去，開發一個網頁應用需要：
|
||||
- 安裝程式設計環境（如 Python、Node.js）
|
||||
- 配置程式碼編輯器
|
||||
- 學習 HTML/CSS/JavaScript 等語言
|
||||
- 處理各種依賴和報錯
|
||||
|
||||
而現在，藉助 AI 程式設計平臺，你只需要：
|
||||
- 開啟瀏覽器，訪問網頁
|
||||
- 用自然語言描述你想要的功能
|
||||
- AI 自動生成程式碼並實時預覽效果
|
||||
|
||||
這種「對話即程式設計」的模式，讓程式設計從「寫程式碼」變成了「描述需求」。你不需要關心底層技術細節，只需要清楚地告訴 AI 你想要什麼，它就能幫你把想法變成可執行的程式。這就是 AI 時代程式設計的新正規化——**Vibe Coding（氛圍式編碼）**。
|
||||
:::
|
||||
|
||||
|
||||
|
||||
輸入我們的簡單需求後點選 **全棧開發** 按鈕，你可以實時觀看網頁的完整建立過程。通常只需泡一杯咖啡的時間，網頁便會自動生成完畢！
|
||||
|
||||
```
|
||||
幫我做一個貪喫蛇遊戲：
|
||||
1. 用方向鍵控制蛇的移動
|
||||
2. 喫到食物後蛇會變長，分數增加
|
||||
3. 撞到牆壁或自己的身體就遊戲結束
|
||||
4. 要有開始和重新開始按鈕
|
||||
5. 介面要簡潔好看
|
||||
```
|
||||
|
||||
|
||||
|
||||
生成結束後，你能看到右側出現可瀏覽的網頁介面。你可以上下滾動瀏覽頁面內容，或點選頁面頂部的 🧭 按鈕切換至全屏模式檢視效果。
|
||||
|
||||
> 其中頂部從左到右按鈕的作用依次為：箭頭按鈕展開側邊對話歷史欄，鉛筆按鈕用於新建一個對話，迴圈箭頭按鈕用於重新整理頁面，指南針按鈕負責切換至全屏模式，Download 按鈕用於下載專案，<> 按鈕用於切換程式碼檢視，Publish 按鈕用於釋出專案。
|
||||
|
||||
|
||||
|
||||
如果你想檢視該網頁的原始碼，可以點選右上角的程式碼圖示檢視完整程式碼。
|
||||
|
||||
|
||||
|
||||
::: tip 🌐 探索更多 AI 程式設計工具
|
||||
|
||||
除了 z.ai，還推薦你還可以嘗試以下優秀的 AI 程式設計平臺進行測試：
|
||||
|
||||
| 工具 | 地址 | 特點 |
|
||||
|------|------|------|
|
||||
| **Google AI Studio**（推薦） | [aistudio.google.com/apps](https://aistudio.google.com/apps) | 谷歌官方出品，支援 Gemini 模型，適合快速原型開發 |
|
||||
| **Figma Make** | [figma.com/make](https://www.figma.com/make) | 與設計工具深度整合，適合設計師快速實現互動原型 |
|
||||
| **Coze** | [coze.com](https://www.coze.cn) | 位元組跳動推出的 AI Bot 開發平臺，提供零程式碼的視覺化搭建能力。與豆包、Kimi 等國產大模型深度整合，支援外掛市場、定時任務和多渠道釋出（飛書、微信等），適合快速構建面向 C 端使用者的對話應用或企業內部智慧助手 |
|
||||
| **v0.dev** | [v0.dev](https://v0.dev) | Vercel 出品的 AI 生成 UI 工具，輸入描述即可生成可執行的 React 元件程式碼 |
|
||||
| **Bolt.new** | [bolt.new](https://bolt.new) | StackBlitz 推出的 AI 全棧開發平臺，可直接生成並部署完整的 Web 應用 |
|
||||
| **Lovable** | [lovable.dev](https://lovable.dev) | 專注於生成高質量 React 應用，支援 GitHub 整合和一鍵部署 |
|
||||
| **Replit Agent** | [replit.com](https://replit.com) | 整合 AI 程式設計助手的線上 IDE，支援多種語言和實時協作 |
|
||||
|
||||
想了解更多網頁程式設計工具的詳細對比和使用教程，可以參考我們的擴充套件閱讀：[7 款主流 Vibe Coding 線上平臺實測對比](../../stage-1/appendix-articles/example0-1/vibe-coding-tools-snake-game-tutorial.md)
|
||||
:::
|
||||
|
||||
### 2.2 對話程式設計能做什麼不能做什麼
|
||||
|
||||
本節聚焦一個具體問題：當你只依賴對話式 AI、不寫任何程式碼時，它究竟能把事情推進到哪一步。
|
||||
在經驗層面，一個較為穩定的結論是：它可以幫你完成一個“小而完整”的東西，但“做到什麼程度就算夠”，仍然需要你親自決策每一步的詳細步驟。
|
||||
|
||||
#### 更擅長“小而清晰”的應用
|
||||
|
||||
從前面的貪喫蛇示例中，你已經看到了一種典型模式：
|
||||
只要你能把介面和互動說清楚，AI 通常可以在幾輪對話內，拼出一個可以開啟、可以點選、可以玩的完整網頁。
|
||||
|
||||
這類任務往往具備幾個共同特徵：
|
||||
|
||||
- 範圍清晰：一頁網頁、一個簡單內部工具、一個小玩法
|
||||
- 結果可見：你能立即在瀏覽器中驗證是否按預期工作
|
||||
- 糾錯直接：發現問題後，可以在後續對話中點明具體現象並要求修正（透過複製錯誤直接貼上，或者截圖貼上的形式讓 AI 進行修改）
|
||||
|
||||
在這個邊界內，你可以把對話式 AI 看作一位執行力不錯的"輔助開發者"。你只需在每一輪用自然語言細化和修正需求，就能快速得到可用的原型。
|
||||
|
||||
**AI 獨立完成小型專案的成功率：**
|
||||
<el-progress :percentage="90" :stroke-width="15" status="success" striped striped-flow />
|
||||
|
||||
#### 大型專案需要“流程視角”
|
||||
|
||||
一旦超出小而清晰的範圍，只指望靠幾輪對話讓 AI 端到端完成複雜系統，很快就會遇到上限。大型專案往往要接後端、連資料庫、整合第三方服務，還牽涉許可權、安全、併發和大量業務規則，目標是交付一整套與現有業務深度打通的系統，而不是一頁網頁。
|
||||
|
||||
在這種情況下，更合理的做法不是把所有需求一股腦丟給 AI，而是先梳理出清晰的整體流程：關鍵步驟是什麼、每一步的輸入輸出和狀態變化是什麼、哪些節點對效能和安全最敏感。再基於這張流程圖，把相對獨立的環節拆分出來，交給對話式 AI 生成介面、模組、指令碼和測試。
|
||||
|
||||
以目前的能力來看，AI 更擅長加速一個個小步驟，由你（或你的團隊）來決定怎麼拆步驟、如何串聯，並負責最終的架構設計、系統整合和運維。
|
||||
|
||||
#### 能寫和能用的區別
|
||||
|
||||
咋一看，AI 好像什麼都能寫，但這些東西到底能不能用，能用到什麼程度，我們該如何劃分？
|
||||
|
||||
一個可參考的經驗是：
|
||||
|
||||
::: warning ⚠️ 適用場景指南
|
||||
|
||||
- **原型 / Demo / 內部自用工具**：非常適合先交給 AI 打第一版，再由你迭代細節。
|
||||
- **面向真實使用者的大型產品**：通常需要工程師在架構、抽象、效能和維護上長期投入。
|
||||
- **強安全 / 強合規系統（如支付、風控、醫療等）**：在當前階段，不宜“生成完就直接上線”，必須引入嚴格的審查與測試流程。
|
||||
:::
|
||||
|
||||
在當下，你可以相對安心地把 AI 視作一個高效的 Demo 與自用工具搭檔：
|
||||
只要你願意多測試、多迭代，多問幾輪“這裡不對，幫我修一下並解釋原因”，在原型與內部工具這一級別，整體質量通常是足夠且具備實踐價值的。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: '困境與機會', description: '普通人的程式設計新可能' },
|
||||
{ title: '能力初探', description: '60秒極速開發體驗' },
|
||||
{ title: '原生實戰', description: '打造AI原生貪喫蛇' },
|
||||
{ title: '拓展創造', description: '舉一反三做遊戲' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 3. 動手：你的第一個 AI 原生應用
|
||||
|
||||
讓我們回到動手部分，在前一部分，我們已經用 AI 快速做出了一個可以玩的貪喫蛇原型，也大致知道了 AI 能做什麼、不能做什麼。接下來我們將學習如何用最基礎的 **vibe coding** 技巧建立一個**現代版**的 AI 貪喫蛇遊戲。我們將讓蛇喫掉文字字元而不是豆子。最後讓遊戲根據喫掉的文字字元生成一首詩，並畫一幅畫。
|
||||
透過這個實際案例你能夠理解全新程式設計方式的核心理念：如何學會用自然語言清晰地表達需求。
|
||||
|
||||
### 3.1 AI 原生貪喫蛇
|
||||
|
||||
在一開始，我們可以用最簡單的方式與大模型對話，這將幫助我們快速獲得產品原型。我們可以直接在聊天框中輸入：
|
||||
|
||||
> **💡 示例提示詞：** 幫我做一個貪喫蛇遊戲
|
||||
>
|
||||
> 
|
||||
|
||||
> **💡 示例提示詞：** 幫我做一個貪喫蛇遊戲，它應該支援
|
||||
>
|
||||
> 1. 我可以喫不同的單詞，它們會被收集在一個盒子裡
|
||||
> 
|
||||
|
||||
> **💡 示例提示詞：** 幫我做一個貪喫蛇遊戲，它應該支援：
|
||||
>
|
||||
> 1. 我可以喫不同的單詞，它們會被收集在一個盒子裡
|
||||
> 2. 當蛇喫了8個單詞時，llm 應該根據這些單詞創作一首詩，我們可以根據需要重新混合這首詩。
|
||||
> 3. 當詩完成後，下一步將自動根據這首詩建立一幅影象。
|
||||
>
|
||||
> 
|
||||
|
||||
注意，在開發過程中，我們可能會遇到不盡如人意的問題，例如點選按鈕沒有任何反應、使用功能時報錯、功能未按預期工作，或者前端頁面與預期設計不符。
|
||||
|
||||
在這種情況下，我們需要進一步向模型提問，以幫助修復這些意外問題。
|
||||
|
||||
|
||||
|
||||
### 3.2 給遊戲新增新功能
|
||||
|
||||
完成基本功能後，我們可以嘗試給我們的程式新增一些新花樣！如果你覺得蛇喫單詞或字元的過程有點枯燥，你可以讓蛇喫不同顏色的單詞，並相應地改變蛇的顏色。
|
||||
|
||||
你還可以為“喫”的過程新增特效，或者引入觸發特效的魔法單詞——比如增加蛇的速度或大小。另一個想法是每當蛇喫一個單詞時就讓模型生成一首詩和一幅圖，而不是等到它喫掉八個單詞。
|
||||
|
||||
如果覺得這些有挑戰性，你可以直接向語言模型求助！它可以提供創意建議，讓你的遊戲更有趣。試一試吧！
|
||||
|
||||
```
|
||||
1. "單詞解鎖世界" 機制
|
||||
每當蛇喫掉一個單詞，LLM 會對該單詞進行詩意聯想（例如，“樹”→“森林”、“綠蔭”），影象模型會即時為該單詞生成一個小藝術品。這些影象逐漸拼湊成一個獨特的、玩家創造的全景圖，所以玩家每次遊玩都在“作畫和寫詩”。
|
||||
|
||||
2. "詩歌拼圖" 玩法
|
||||
蛇喫掉的每個單詞都會觸發 LLM 生成簡短的詩句，影象模型生成插圖。這些詩句和影象像拼圖一樣組合在一起，在回合結束時形成一首 AI 協作的詩和畫。
|
||||
|
||||
3. "魔法單詞" & "故事分支"
|
||||
特殊的“魔法單詞”（例如，“風”、“夜”、“夢”）不僅觸發 LLM 生成詩歌，還會改變場景的情緒或主題——將生成影象的風格轉變為夜晚、暴風雨或夢幻般的氛圍。
|
||||
分支故事：LLM 在開始時給出一個主題或謎語（例如，“秋天的回憶”）。玩家的單詞選擇直接影響故事和詩歌的演變，影象模型實時更新背景和視覺效果。
|
||||
|
||||
4. "實時互動生成"
|
||||
每個單詞之後，LLM 生成一行對話或描述，遊戲中的 NPC 可以對玩家“說話”，或者環境可以相應地改變。
|
||||
蛇的外觀或遊戲中的障礙物可以根據喫掉的單詞在視覺上發生變化，這要歸功於影象模型。
|
||||
|
||||
5. "創作 & 分享"
|
||||
玩家可以在會話結束時儲存並分享他們 AI 創作的詩歌和影象，炫耀他們獨特的“AI 協作”。
|
||||
“最美詩歌+藝術”、“最有創意單片語合”等排行榜，鼓勵重玩和創造力。
|
||||
|
||||
6. "按句貪喫蛇" 挑戰
|
||||
反向模式：LLM 給出一句詩或一個謎語，玩家必須引導蛇按順序喫掉單詞來重構句子。喫錯單詞會透過影象生成模型觸發有趣或藝術性的後果。
|
||||
|
||||
7. "主題關卡" & "風格選擇"
|
||||
遊戲開始時，玩家選擇一個主題（例如，“童話”、“科幻”、“唐詩”），LLM 和影象模型都會調整單詞選擇、詩歌風格和視覺效果以匹配，使每次執行都感覺新鮮。
|
||||
|
||||
8. "現場共創"
|
||||
當喫掉一個特殊單詞時，LLM 可以提示玩家輸入短語或選擇風格，然後 AI 生成相應的詩句和插圖，使其成為真正的人類-AI 共創。
|
||||
|
||||
9. "AI 彩蛋 & 成就"
|
||||
某些單片語合被 LLM 識別為特殊主題或內部笑話（例如，“月亮”、“桂花”、“河岸”），觸發稀有的詩句和插圖，獎勵探索。
|
||||
|
||||
10. "成長的故事"
|
||||
隨著蛇的成長，LLM 生成一個連續的故事詩，影象模型建立一個無縫的長卷或全景圖，所以玩家同時在“寫作、繪畫和玩耍”。
|
||||
```
|
||||
|
||||
此外，我們還可以要求 LLM 幫你直接生成專案級的提示詞。在上一節中，我們只自己寫了貪喫蛇遊戲的提示詞。現在讓我們嘗試讓大模型生成一個帶有整體框架和實現路徑的提示詞（你可以直接用 z.ai 生成）。
|
||||
|
||||
如果你想學習如何寫出更好的提示詞，可以檢視[提示詞工程附錄](/zh-tw/appendix/8-artificial-intelligence/prompt-engineering)。
|
||||
|
||||
> 我想讓 AI 生成一個網頁貪喫蛇遊戲，需要一個更完整的提示詞，讓生成結果更令人印象深刻和有趣。請生成相應的提示詞。當前目標是：生成一個貪喫蛇遊戲，需要實現喫不同單詞生成詩歌的功能，並且應該包含影象生成模組。
|
||||
|
||||
z.ai 的回覆將會是這樣的：
|
||||
|
||||
|
||||
|
||||
我們可以使用這個提示詞在全棧開發模式下重新生成專案：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: '困境與機會', description: '普通人的程式設計新可能' },
|
||||
{ title: '能力初探', description: '60秒極速開發體驗' },
|
||||
{ title: '原生實戰', description: '打造AI原生貪喫蛇' },
|
||||
{ title: '拓展創造', description: '舉一反三做遊戲' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
### 3.3 嘗試製作其他小遊戲
|
||||
|
||||
除了貪喫蛇（遊戲），我們可以讓想象力盡情馳騁。
|
||||
|
||||
創造任何我們想創造的東西，甚至嘗試搞砸一切！然後重頭再來！
|
||||
|
||||
```
|
||||
1. AI 藝術畫廊平臺
|
||||
描述：一個展示 AI 生成藝術作品的線上畫廊，使用者可以上傳、分享和評論 AI 藝術作品。
|
||||
功能：使用者賬戶系統、藝術作品上傳和展示、評分系統、分類瀏覽、AI 生成工具整合。
|
||||
技術亮點：React/Vue 前端、Node.js 後端、MongoDB 資料庫、AI API 整合。
|
||||
|
||||
2. 復古遊戲檔案館
|
||||
描述：一個致敬經典遊戲的網站，包含遊戲歷史、玩法指南和線上可玩復古遊戲。
|
||||
功能：遊戲資料庫、時間軸展示、線上模擬器、使用者評論、遊戲收藏功能。
|
||||
技術亮點：響應式設計、WebGL/Canvas 遊戲實現、RESTful API、使用者認證系統。
|
||||
|
||||
3. 可持續生活追蹤器
|
||||
描述：一個幫助使用者透過環保提示和社羣挑戰來追蹤和減少碳足跡的網站。
|
||||
功能：個人碳足跡計算器、目標設定、進度追蹤、社羣挑戰、環保知識庫。
|
||||
技術亮點：資料視覺化、移動端最佳化、社交功能、推送通知。
|
||||
|
||||
4. 虛擬廚房助手
|
||||
描述：一個基於 AI 的烹飪指導平臺，提供個性化食譜推薦和分步烹飪說明。
|
||||
功能：食譜資料庫、食材識別、個性化推薦、烹飪計時器、營養分析。
|
||||
技術亮點：影象識別 API、機器學習推薦系統、語音控制、實時影片指導。
|
||||
|
||||
5. 地下音樂發現平臺
|
||||
描述：一個專注於獨立和新興藝術家的音樂流媒體平臺，提供獨特的發現體驗。
|
||||
功能：音樂流媒體、藝術家資料、個性化推薦、播放列表建立、社羣評論。
|
||||
技術亮點：音訊流處理、推薦演算法、社交功能、音樂視覺化。
|
||||
|
||||
6. 極簡任務管理系統
|
||||
描述：一個具有禪意美學的任務管理工具，專注於簡單和高效的任務組織。
|
||||
功能：任務建立和分類、優先順序設定、進度追蹤、團隊協作、資料分析。
|
||||
技術亮點：極簡 UI 設計、拖放功能、實時同步、跨平臺相容性。
|
||||
|
||||
7. 科幻寫作工坊
|
||||
描述：一個為科幻作家提供創意工具和靈感的平臺，包括世界觀構建輔助和角色開發工具。
|
||||
功能：故事結構工具、角色資料、世界觀構建模板、寫作統計、社羣反饋。
|
||||
技術亮點：富文字編輯器、資料視覺化、協作編輯、AI 輔助創作。
|
||||
|
||||
8. 個人知識圖譜
|
||||
描述：一個幫助使用者構建個人知識網路，視覺化並連線各種想法和資訊的工具。
|
||||
功能：節點建立和連線、標籤系統、搜尋功能、匯入/匯出工具、視覺化圖表。
|
||||
技術亮點：圖資料庫、資料視覺化演算法、Markdown 支援、跨裝置同步。
|
||||
|
||||
9. 虛擬植物園
|
||||
描述：一個互動植物百科全書，使用者可以探索植物世界並建立虛擬花園。
|
||||
功能：植物資料庫、3D 植物模型、生長模擬、園藝指南、社羣展示。
|
||||
技術亮點：3D 渲染、季節變化模擬、AR 整合、植物識別 API。
|
||||
|
||||
10. 程式設計挑戰競技場
|
||||
描述：一個面向程式設計師的線上競賽平臺，具有各種難度級別的程式設計挑戰。
|
||||
功能：挑戰問題、程式碼編輯器、自動評估、排行榜、學習路徑。
|
||||
技術亮點：程式碼沙箱環境、實時評估系統、演算法視覺化、社交學習功能。
|
||||
```
|
||||
|
||||
還有... 如果你喜歡玩遊戲，讓我們一起嘗試創造遊戲吧！
|
||||
|
||||
```
|
||||
1. 3D 開放世界 RPG
|
||||
描述：一個具有廣闊開放世界、任務和角色成長的奇幻 RPG。
|
||||
功能：晝夜迴圈、動態天氣、技能樹、多人合作、製作系統。
|
||||
技術亮點：Three.js 或 Babylon.js 用於 3D 渲染、伺服器端遊戲邏輯、角色自定義、存檔系統。
|
||||
|
||||
2. 第一人稱射擊 (FPS) 競技場
|
||||
描述：一個快節奏的多人 FPS，具有各種遊戲模式和地圖。
|
||||
功能：團隊死鬥、奪旗、武器自定義、排位賽。
|
||||
技術亮點：WebGL/Three.js 用於 3D 圖形、多人網路程式碼、命中檢測、語音聊天。
|
||||
|
||||
3. AI 國際象棋和多人遊戲
|
||||
描述：一個功能齊全的國際象棋平臺，具有 AI 對手和線上對戰功能。
|
||||
功能：AI 難度級別、殘局挑戰、錦標賽模式、回放分析。
|
||||
技術亮點：國際象棋邏輯庫、WebSocket 用於實時對戰、ELO 排名系統、反作弊。
|
||||
|
||||
4. 麻將線上多人遊戲
|
||||
描述：一個具有線上多人遊戲和計分功能的傳統麻將遊戲。
|
||||
功能：多種規則集、私人房間、排名系統、回放功能。
|
||||
技術亮點：牌匹配邏輯、實時多人遊戲、大廳系統、分數追蹤。
|
||||
|
||||
5. 回合制策略遊戲
|
||||
描述：一個具有網格戰鬥和單位管理的戰術策略遊戲。
|
||||
功能：戰役模式、遭遇戰、單位升級、戰爭迷霧、多人對戰。
|
||||
技術亮點：網格移動系統、AI 決策、回合同步、存檔/讀檔系統。
|
||||
|
||||
6. 計時賽賽車遊戲
|
||||
描述：一個專注於計時賽和賽道記錄的 3D 賽車遊戲。
|
||||
功能：多條賽道、汽車自定義、幽靈回放、排行榜。
|
||||
技術亮點：3D 汽車物理、賽道編輯器、回放系統、線上排行榜。
|
||||
|
||||
7. 卡牌對戰遊戲 (卡組構建)
|
||||
描述：一個策略卡牌遊戲，玩家構建卡組並與對手戰鬥。
|
||||
功能：卡牌收集、卡組構建、排位賽、賽季活動。
|
||||
技術亮點：卡牌遊戲邏輯、匹配系統、AI 對手、卡牌動畫。
|
||||
|
||||
8. 大逃殺 (俯視 2D)
|
||||
描述：一個俯視 2D 大逃殺遊戲，具有縮小的遊戲區域和戰利品機制。
|
||||
功能：單人和小隊模式、武器多樣性、局內事件、排行榜。
|
||||
技術亮點：實時多人遊戲、區域縮小邏輯、戰利品生成系統、匹配。
|
||||
|
||||
9. 恐怖生存遊戲 (第一人稱)
|
||||
描述：一個具有資源管理和逃生機制的第一人稱恐怖遊戲。
|
||||
功能：氛圍環境、解謎、敵人 AI、多重結局。
|
||||
技術亮點：動態照明、聲音設計、敵人尋路、存檔系統。
|
||||
|
||||
10. 音樂節奏遊戲 (3D)
|
||||
描述：一個 3D 節奏遊戲，玩家隨著音樂節拍擊打音符。
|
||||
功能：多種難度級別、賽道編輯器、自定義歌曲支援、排行榜。
|
||||
技術亮點：音訊分析、節拍同步、3D 音符軌道、輸入時機檢測。
|
||||
```
|
||||
|
||||
## 📚 Assignment
|
||||
|
||||
<el-card id="assignment-card" shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🎯 本章作業：完成你的第一批 AI 原生小遊戲</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
這一節，你已經跟著步驟體驗了從“對話生成貪喫蛇”到“理解 AI 原生小遊戲設計思路”的完整流程。下面的作業幫助你把這些理解真正變成自己的能力。
|
||||
</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
<strong>完整復現 AI 原生貪喫蛇遊戲</strong>
|
||||
<ul>
|
||||
<li>至少實現：蛇可以移動、喫到“食物”後長度和分數發生變化、撞牆或撞到自己會結束。</li>
|
||||
<li>在復現過程中，練習把錯誤現象 + 報錯資訊 + 關鍵程式碼片段一次性丟給 AI，請它“小白模式”修復。</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>（可選）自創 1 個 AI 原生小遊戲或 Demo</strong>
|
||||
<ul>
|
||||
<li>可以是圍繞文字、圖片、音樂、節奏等的任意輕量玩法，例如“喫單詞寫詩”“節奏點選”“生成式跑酷”等。</li>
|
||||
<li>重點不是畫面多炫，而是你能清楚說出：AI 在這裡具體幫了什麼忙，它解決了什麼“人工難以做到或很麻煩”的部分。</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<p>
|
||||
這就是完整的教程！你可能需要 <strong>4 小時</strong> 才能完成所有內容並構建你自己的貪喫蛇遊戲。不要著急——探索、實驗並享受這個過程。如果在過程中遇到概念不太理解，推薦你順手檢視下方附錄中的相關部分。
|
||||
</p>
|
||||
</el-card>
|
||||
|
||||
## 附錄
|
||||
|
||||
<el-card id="appendix-nav" shadow="hover" style="margin-top: 24px; margin-bottom: 24px; border-left: 5px solid #67C23A;">
|
||||
<div style="font-weight: bold; margin-bottom: 8px;">附錄導航</div>
|
||||
<div style="color: #606266; font-size: 14px; line-height: 1.6; margin-bottom: 12px;">
|
||||
這裡整理了一些和本章相關的基礎概念：如果你在學習過程中遇到“前端是什麼”“Vibe Coding 到底指什麼”等問題，可以隨時回到這裡查閱。
|
||||
</div>
|
||||
<el-row :gutter="16">
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-1" style="text-decoration: none; color: inherit;"><b>附錄 1：我們需要前端開發知識嗎？</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">搞清楚前端在整個應用裡的位置，知道哪些是“看得見”的部分。</span>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-2" style="text-decoration: none; color: inherit;"><b>附錄 2：到底什麼是 Vibe Coding</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">理解“對話式開發”的核心思路，知道該如何和 AI 配合。</span>
|
||||
</el-col>
|
||||
</el-row>
|
||||
<el-row :gutter="16" style="margin-top: 10px;">
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-3" style="text-decoration: none; color: inherit;"><b>附錄 3：模型上下文</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">搞清楚“上下文長度”這類常聽到卻又容易混淆的概念。</span>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<a href="#appendix-4" style="text-decoration: none; color: inherit;"><b>附錄 4：指令遵循能力</b></a><br/>
|
||||
<span style="font-size: 12px; color: #909399">瞭解模型為什麼有時“聽不懂話”，以及如何寫得更清楚。</span>
|
||||
</el-col>
|
||||
</el-row>
|
||||
<div style="margin-top: 12px; font-size: 12px; color: #909399;">
|
||||
小技巧：你可以按 Ctrl/⌘+F 搜尋關鍵字，或者把不懂的段落複製給 AI，請它用“完全小白能看懂”的方式再解釋一遍。
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
## <span id="appendix-1">[附錄 1：我們需要前端開發知識嗎？](#appendix-nav)</span>
|
||||
|
||||
::: tip 💡 一句話總結
|
||||
你不需要會寫程式碼，但瞭解基礎概念能讓你更好地向 AI 描述需求。
|
||||
:::
|
||||
|
||||
<el-row :gutter="16" style="margin: 20px 0;">
|
||||
<el-col :span="12" :xs="24" style="margin-bottom: 16px;">
|
||||
<el-card shadow="hover" style="border-radius: 12px; height: 100%;">
|
||||
<template #header>
|
||||
<div style="display: flex; align-items: center; gap: 8px;">
|
||||
<span style="font-size: 20px;">👁️</span>
|
||||
<span style="font-weight: bold;">前端</span>
|
||||
<el-tag type="success" size="small">可見</el-tag>
|
||||
</div>
|
||||
</template>
|
||||
<div style="color: #606266; line-height: 1.8;">
|
||||
使用者能<strong>看到、點到</strong>的所有內容
|
||||
<ul style="margin: 12px 0; padding-left: 20px;">
|
||||
<li>網頁標題、文字、圖片</li>
|
||||
<li>按鈕、輸入框、下拉選單</li>
|
||||
<li>遊戲介面、動畫效果</li>
|
||||
</ul>
|
||||
</div>
|
||||
</el-card>
|
||||
</el-col>
|
||||
<el-col :span="12" :xs="24" style="margin-bottom: 16px;">
|
||||
<el-card shadow="hover" style="border-radius: 12px; height: 100%;">
|
||||
<template #header>
|
||||
<div style="display: flex; align-items: center; gap: 8px;">
|
||||
<span style="font-size: 20px;">⚙️</span>
|
||||
<span style="font-weight: bold;">後端</span>
|
||||
<el-tag type="info" size="small">不可見</el-tag>
|
||||
</div>
|
||||
</template>
|
||||
<div style="color: #606266; line-height: 1.8;">
|
||||
執行在伺服器上的資料處理
|
||||
<ul style="margin: 12px 0; padding-left: 20px;">
|
||||
<li>使用者分數儲存</li>
|
||||
<li>登入賬號驗證</li>
|
||||
<li>關卡內容分配</li>
|
||||
</ul>
|
||||
</div>
|
||||
</el-card>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
### 前端三件套
|
||||
|
||||
瀏覽器透過三種"程式碼"來構建頁面：
|
||||
|
||||
<el-tabs type="border-card" style="margin: 20px 0;">
|
||||
<el-tab-pane label="🏗️ HTML - 骨架">
|
||||
<div style="padding: 10px;">
|
||||
<p><strong>作用：</strong>定義頁面上<strong>有什麼</strong>元素</p>
|
||||
<p><strong>類比：</strong>房子的結構草圖（牆、門、窗在哪裡）</p>
|
||||
<el-card style="background: #f5f7fa; margin-top: 12px;">
|
||||
<pre style="margin: 0;"><code><button>點我</button>
|
||||
<h1>標題</h1>
|
||||
<img src="photo.png"></code></pre>
|
||||
</el-card>
|
||||
</div>
|
||||
</el-tab-pane>
|
||||
<el-tab-pane label="🎨 CSS - 樣式">
|
||||
<div style="padding: 10px;">
|
||||
<p><strong>作用：</strong>控制元素<strong>長什麼樣</strong></p>
|
||||
<p><strong>類比：</strong>房子的裝修（顏色、材質、佈局）</p>
|
||||
<el-card style="background: #f5f7fa; margin-top: 12px;">
|
||||
<pre style="margin: 0;"><code>button {
|
||||
background: blue;
|
||||
color: white;
|
||||
border-radius: 8px;
|
||||
}</code></pre>
|
||||
</el-card>
|
||||
</div>
|
||||
</el-tab-pane>
|
||||
<el-tab-pane label="⚡ JavaScript - 行為">
|
||||
<div style="padding: 10px;">
|
||||
<p><strong>作用：</strong>讓頁面<strong>動起來</strong></p>
|
||||
<p><strong>類比：</strong>房子的電路開關（點選後的響應）</p>
|
||||
<el-card style="background: #f5f7fa; margin-top: 12px;">
|
||||
<pre style="margin: 0;"><code>button.onclick = () => {
|
||||
alert('你點了我！')
|
||||
}</code></pre>
|
||||
</el-card>
|
||||
</div>
|
||||
</el-tab-pane>
|
||||
</el-tabs>
|
||||
|
||||
### 程式碼如何變成頁面？
|
||||
|
||||
當你開啟一個網頁時，瀏覽器會按順序處理三種程式碼：
|
||||
|
||||
**1. HTML —— 定義頁面結構**
|
||||
瀏覽器首先解析 HTML，瞭解頁面上有哪些元素（標題、段落、圖片、按鈕等），以及它們的層級關係。
|
||||
|
||||
**2. CSS —— 應用樣式**
|
||||
然後瀏覽器根據 CSS 規則，給這些元素新增樣式：顏色、大小、位置、間距等，讓頁面變得美觀。
|
||||
|
||||
**3. JavaScript —— 新增互動**
|
||||
最後執行 JavaScript 程式碼，讓頁面"動起來"：響應點選、提交表單、播放動畫等。
|
||||
|
||||
**4. 頁面呈現**
|
||||
三者的配合結果就是你最終看到的網頁。
|
||||
|
||||
### 現代前端框架：從 HTML 到 React/Vue
|
||||
|
||||
前面介紹的 HTML、CSS、JavaScript 是前端開發的"三件套"，它們是所有網頁的基礎。但當頁面變得複雜時，直接用這三件套開發會遇到挑戰：程式碼難以維護、重複勞動多、資料同步麻煩。
|
||||
|
||||
**現代前端框架**（如 React、Vue、Angular）建立在 HTML/CSS/JS 之上，讓開發更高效：
|
||||
|
||||
**1. HTML/CSS/JS（基礎階段）**
|
||||
直接操作頁面元素，適合簡單頁面。但當程式碼量增大時，所有邏輯混在一起，難以維護。
|
||||
|
||||
**2. jQuery（過渡階段）**
|
||||
簡化了 DOM 操作，讓程式碼更簡潔。但仍需手動管理頁面狀態，資料變化時要自己找到對應的元素並更新。
|
||||
|
||||
**3. React/Vue（現代階段）**
|
||||
採用元件化和狀態驅動的設計：
|
||||
- **元件化**：把頁面拆成獨立的可複用模組（如按鈕、卡片、導航欄）
|
||||
- **狀態驅動**：資料變化時，框架自動更新對應的介面，無需手動操作
|
||||
|
||||
::: tip 💡 簡單理解
|
||||
- **HTML/CSS/JS** = 基礎材料（磚塊、水泥、鋼筋）
|
||||
- **React/Vue** = 建築框架（提供了搭建房屋的規範和工具）
|
||||
|
||||
在 AI 輔助程式設計時代，你不需要深入掌握框架的所有細節，只需要理解它們的基本概念，就能透過自然語言描述讓 AI 幫你生成程式碼。
|
||||
:::
|
||||
|
||||
### 在 Vibe Coding 中
|
||||
|
||||
**核心要點：你不需要寫程式碼，只需要會描述。**
|
||||
|
||||
瞭解前端概念後，你可以這樣跟 AI 描述需求：
|
||||
|
||||
> "用 React 做一個排行榜頁面，右側顯示分數列表，點選某行在下方展示玩家詳情，風格簡潔現代。"
|
||||
|
||||
如果你想深入理解 HTML、CSS、JavaScript 等前端基礎知識，可以檢視[Web 基礎附錄](/zh-tw/appendix/3-browser-and-frontend/javascript-deep-dive)。想了解前端技術的發展歷程，可以檢視[前端進化史附錄](/zh-tw/appendix/3-browser-and-frontend/frontend-frameworks)。
|
||||
|
||||
## <span id="appendix-2">[附錄 2：到底什麼是 Vibe Coding](#appendix-nav)</span>
|
||||
|
||||
> 💡 什麼是 Vibe Coding？電腦科學家 [Andrej Karpathy](https://karpathy.ai/)（OpenAI 的聯合創始人之一，特斯拉前 AI 負責人）於 2025 年 2 月提出了 **vibe coding** 一詞。這個概念指的是一種依賴於 LLM 的編碼方法，**允許程式設計師透過提供自然語言描述而不是手動編寫程式碼來生成可工作的程式碼。**
|
||||
|
||||
|
||||
|
||||
從字面上看，Vibe Coding 可以理解為一種“用說的方式來做開發”。它的核心變化在於：你不再需要自己一行一行寫程式碼、查語法、調 Bug，而是直接用自然語言描述你想要的東西，例如：
|
||||
|
||||
“我需要一個登入頁面，上面有手機號輸入框和驗證碼輸入框。”
|
||||
“登入成功後，跳轉到首頁，並在右上角顯示使用者名稱。”
|
||||
“給我一個簡單的貪喫蛇小遊戲，可以用鍵盤方向鍵控制。”
|
||||
大語言模型（LLM）會把這類描述自動翻譯成真正可以執行的程式碼，並生成對應的頁面、邏輯和資料結構。你看到效果後，再用自然語言提出修改意見，例如“按鈕再大一點”“背景換成深色”“得分記錄下來並顯示排行榜”，AI 會繼續按你的要求調整實現。
|
||||
|
||||
在這種模式下，你不需要先學會程式語言，再去寫程式碼；而是把主要精力放在：說清楚要做什麼、看到結果後判斷“哪裡不對”、再提出新的修改。AI 則負責把這些高層的想法落成具體實現，從而顯著減少機械、重複的編碼工作。
|
||||
|
||||
你可以點選這裡檢視更多關於 vibe coding 的細節：[https://www.ibm.com/think/topics/vibe-coding](https://www.ibm.com/think/topics/vibe-coding)
|
||||
|
||||
你可以點選這裡檢視更多關於 Karpathy 的分享內容：[https://karpathy.bearblog.dev/blog/](https://karpathy.bearblog.dev/blog/)
|
||||
|
||||
### 如何假裝自己是 Vibe Coding 大師
|
||||
|
||||
實際上，在真正的 vibe coding 過程中，我們通常不會使用很多複雜的提示詞。也許我們在開始時需要為整個程式提供一個具體且適度複雜的提示詞，但在那之後的每一步，你可能只需要以下型別的提示詞：
|
||||
|
||||
```
|
||||
"程式碼裡有個 bug，請修復它。"
|
||||
"我不要部分程式碼，給我完整的修改後的程式碼。"
|
||||
"你的程式碼還是有問題。"
|
||||
"請再次修改並給我完整的修正後的程式碼。"
|
||||
"剛才還能執行，為什麼現在不能執行了？"
|
||||
"你沒理解我的意思嗎？不要改我原來的程式碼。"
|
||||
"不要新增任何除錯功能。"
|
||||
"不要做我沒讓你做的事。"
|
||||
"我讓你實現的功能在哪裡？"
|
||||
"你聽不懂我說的話嗎？"
|
||||
"我只要一個函式。"
|
||||
"我告訴過你參考我之前的程式碼。"
|
||||
"請不要新增不必要的註釋。"
|
||||
"請不要修改我原始程式碼的基本邏輯。"
|
||||
"幫我修改程式碼。"
|
||||
"基於我的程式碼修改..."
|
||||
"不要改我的變數名！！！"
|
||||
"不要改原來的函式名！"
|
||||
"不要亂動我的變數。"
|
||||
"不要新增額外的功能。"
|
||||
"不要只生成框架，生成完整的程式碼。"
|
||||
```
|
||||
|
||||
這聽起來可能有點誇張，但實際上，這些就是我們在日常工作中可能使用的提示詞。由於大語言模型的**上下文長度限制**，或者有時因為它們的**指令遵循能力**不是很強，模型可能會忘記對話早些時候討論的內容。在 vibe coding 中，我們傾向使用長上下文的模型，並且使用指令遵循能力強的模型，我們可以透過這兩者的排行或者指標來判斷其是不是好模型。
|
||||
|
||||
或者，由於訓練資料集的風格，大模型傾向於以其訓練資料的風格回答。例如，有些人說話很嚴肅，有些人喜歡新增很多修飾，而有些大模型喜歡在程式碼中新增很多註釋或不必要的模組。
|
||||
|
||||
## <span id="appendix-3">[附錄 3：模型上下文](#appendix-nav)</span>
|
||||
|
||||
模型上下文可以理解為 AI 的短期記憶。它指的是在當前一次對話或一次任務中，模型能夠“看到”和“記住”的所有文字內容，包括你之前輸入的問題、系統提供的說明、相關資料等。
|
||||
|
||||
正是因為有上下文，AI 才能理解你在接著前面的內容繼續提問，才能進行一輪一輪、看起來連貫自然的對話。如果沒有上下文，你的每一句話在模型看來都像是一次全新的提問，它無法知道你之前說過什麼，也就談不上延續對話。
|
||||
|
||||
每個模型都有自己的有效上下文長度（context window）。這個長度通常用 token（可以粗略理解為“字詞片段”的單位）來衡量，目前主流模型大多在 32k～128k token 之間。上下文越長，模型一次能“讀”的內容就越多，例如：
|
||||
|
||||
- 一次性讀完一篇較長的論文或報告
|
||||
- 在同一輪對話中引用多篇資料、多個案例
|
||||
- 讓模型記住之前幾輪的複雜討論結論
|
||||
|
||||
當你輸入的內容接近或超過模型的上下文限制時，往往會出現一些常見現象：
|
||||
|
||||
- 模型開始遺忘前面長文字中的細節或關鍵資訊
|
||||
- 對話進行到後面，話題逐漸偏離最初目標
|
||||
- 對同一材料的不同問答之間，引用的內容不一致
|
||||
|
||||
這些現象並不是模型突然“變笨”，而是上下文容量被用滿或接近用滿後產生的自然結果。
|
||||
|
||||
在實際使用中，我們既希望上下文儘可能長，又要意識到：
|
||||
|
||||
- 上下文越長，佔用的算力資源越多
|
||||
- 對應的呼叫成本（費用）也會隨之增加
|
||||
|
||||
因此，在設計 AI 應用時，需要在讓模型看得足夠多和控制成本、提升效率之間做平衡。例如：
|
||||
|
||||
- 對真正需要長期保留的資訊進行提煉後再交給模型
|
||||
- 對不再需要的細節資訊，避免一遍又一遍原樣塞入上下文
|
||||
- 使用外部知識庫等方式，把“長期記憶”交給系統，而不是強行塞進模型上下文中
|
||||
|
||||
## <span id="appendix-4">[附錄 4：指令遵循能力](#appendix-nav)</span>
|
||||
|
||||
指令遵循能力指的是：模型在理解你的指令之後，能否準確、完整地按照你的要求執行。它不僅包括能回答問題，還包括能按指定格式、風格、步驟完成任務。
|
||||
|
||||
例如，下面這些都是對模型有明確要求的指令：
|
||||
|
||||
- 將這篇文章總結為三個要點
|
||||
- 用正式、禮貌的語氣寫一封回覆郵件
|
||||
- 把這個詞翻譯成英文，並各造一個例句
|
||||
- 從文章中提取作者、時間和主要事件
|
||||
|
||||
一個指令遵循能力強的模型，通常具備以下特徵：
|
||||
|
||||
- 按要求的數量輸出內容
|
||||
例如要求總結三個要點，就不會給出五條。
|
||||
- 覆蓋所有指定的要素
|
||||
例如要求提取作者、時間和事件，就不會遺漏其中任何一項。
|
||||
- 遵守指定的格式和語氣
|
||||
例如要求使用正式語氣，就不會輸出過於口語化的回覆。
|
||||
- 不做不必要的額外延伸
|
||||
例如只要求翻譯和造句，就不會額外輸出一大段無關解釋。
|
||||
|
||||
在實際應用中，強指令遵循能力非常重要，原因包括：
|
||||
|
||||
- 提高穩定性：同樣的指令在不同時間、多次執行時，輸出結構和行為模式更加一致，不容易隨意發揮
|
||||
- 提高可復現性：當你把一段提示詞配置到產品或流程中時，可以預期模型大致會怎樣響應，方便測試和迭代
|
||||
- 便於系統整合：當模型輸出符合預期格式時，更容易與後端程式、工作流或其他工具自動對接
|
||||
|
||||
因此，在選擇和評估一個大語言模型時，除了關注它是否聰明、知識覆蓋是否廣之外，還需要特別關注它的指令遵循能力。對於工業級應用來說，能否穩定而準確地執行指令，往往比偶爾給出一次驚豔回答更重要。
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="繼續學習"
|
||||
description="從“遊戲化體驗”出發，推薦你繼續進入本地開發與產品實踐。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
---
|
||||
title: '初級一：AI 時代，會說話就會編程'
|
||||
description: '用對話式方式讓 AI 幫你寫代碼：從 0 到 1 做出 AI 原生貪吃蛇，並學會舉一反三做出自己的小遊戲或 Demo。'
|
||||
---
|
||||
File diff suppressed because it is too large
Load Diff
+359
@@ -0,0 +1,359 @@
|
||||
# 七款 AI 程式設計工具對比
|
||||
|
||||
## 本章導讀
|
||||
|
||||
面對琳琅滿目的 AI 程式設計工具，哪一款才最適合你？本章透過一個統一的實戰任務——開發“貪喫蛇 + AI 寫詩”遊戲，對 Lovable、Replit、Z.ai 等 7 款主流 Web Vibe Coding 平臺進行了深度橫向評測。我們將從新手友好度、程式碼可控性、部署便捷性等多維度對比，助你快速選出最強開發輔助工具。
|
||||
|
||||
---
|
||||
|
||||
# 1. 用 Vibe Coding 搭建貪喫蛇遊戲：完整實戰教程
|
||||
|
||||
本文介紹了一種新興的軟體開發實踐——“Vibe Coding（氛圍式編碼）”，它利用人工智慧來加速應用構建過程。
|
||||
|
||||
接下來我們將依次介紹 Vibe Coding 的核心概念、解釋什麼是 AI Agent，並給出實用的提示詞編寫方法。最後，會透過從零開始構建“貪喫蛇（Snake）”遊戲的完整實戰，並對多個主流 Vibe Coding 平臺進行詳細對比評測，幫助你選擇最適合自己的工具組合。
|
||||
|
||||
## 你將學到：
|
||||
|
||||
- **什麼是 Vibe Coding：** 瞭解它的定義、工作流和關鍵優勢。
|
||||
- **AI Agent 的角色：** 理解 AI Agent 的工作方式，以及它與傳統程式的差異。
|
||||
- **如何寫好提示詞：** 掌握清晰、具體的提示詞寫法，以獲得更好的結果。
|
||||
- **Vibe Coding 工具：** 認識一批主流的 AI 程式設計與設計平臺。
|
||||
- **平臺對比：** 從初學者視角出發，對 7 個不同 AI Agent 平臺的優劣勢進行評測與對比。
|
||||
- **UI / UX 工具：** 學會如何將 Figma、Mastergo 等 UI/UX 工具融入到整體工作流中。
|
||||
|
||||
## 1. 引言
|
||||
|
||||
在此前的課程中，我們一直使用 z.ai 的全棧開發模型來完成程式設計任務。
|
||||
|
||||
不過，我們是否想過：它的核心其實是 “AI Agent”（與普通聊天式 AI 不同，而且要智慧得多）？這是因為它不只是和你對話，而是能夠進行思考（當你給它任務時，它會先制定計劃），還能主動採取行動（比如呼叫網頁搜尋、執行電腦命令、開啟網頁等工具）。我們稍後會詳細介紹。
|
||||
|
||||
## 1. 什麼是 Vibe Coding？
|
||||
|
||||
Vibe Coding 是一種利用 AI 加速應用開發流程的新型軟體開發方式。它並不是傳統程式設計的替代品，而是一種更加“對話式”的程式設計模式。這個概念由 AI 研究者 Andrej Karpathy 提出：在這種工作流下，開發者不再逐行手寫程式碼，而是主要透過引導 AI Agent 來生成、最佳化和除錯應用。
|
||||
|
||||
Vibe Coding 的核心思想，是從 **“以程式碼為中心（code-first）”** 轉變為 **“以意圖為中心（intent-first）”**。你不再需要從第一行程式碼開始構思，而是用自然語言描述你想要的結果。
|
||||
|
||||
典型的 Vibe Coding 工作流程是一個不斷迭代的迴圈：
|
||||
|
||||
- **描述目標：** 先用一句話或一段話描述你想要實現的功能，例如：“做一個帶有 Python 後端、可以生成詩歌的簡單貪喫蛇遊戲。”
|
||||
- **AI 生成程式碼：** AI Agent 解析你的需求，生成初版程式碼，包括基本結構、前端頁面和後端邏輯。
|
||||
- **執行並觀察：** 執行生成的程式碼，檢查其是否按預期工作，同時發現 bug 或不足之處。
|
||||
- **反饋並迭代：** 如果有錯誤或效果不理想，就在對話中繼續下指令，例如：“蛇移動太慢了，把速度調快些”，或者“現在 `.env` 檔案裡的 API Key 沒被正確讀取，請修復後端程式碼。”
|
||||
- **重複上述步驟：** 不斷在“描述 → 生成 → 執行 → 反饋”的迴圈中迭代，直到應用達到滿意的狀態。
|
||||
|
||||
### Vibe Coding 的主要優勢：
|
||||
|
||||
- **降低門檻：** 讓缺乏程式設計經驗的設計師、創業者、學生等，也可以透過自然語言參與應用開發。
|
||||
- **快速原型：** 從想法到最小可行產品（MVP）的時間大幅縮短。
|
||||
- **提高效率：** 自動處理大量重複、機械的編碼工作（如模板程式碼），讓開發者可以把精力放在架構設計和問題抽象上。
|
||||
- **利於試驗：** 鼓勵先快速產出，再不斷完善的方式，更便於嘗試新點子和新功能。
|
||||
|
||||
## 2. 什麼是 Vibe Coding 線上平臺（Web-based）？
|
||||
|
||||
在本次實測中，你會發現我們評測的工具被分為了兩類：**Web-based（線上平臺）** 和 **IDE（本地開發環境）**。
|
||||
|
||||
雖然它們的核心都是用 AI 幫你寫程式碼，但在使用體驗和適用場景上有著巨大的區別：
|
||||
|
||||
### Vibe Coding 線上平臺 (Web-based)
|
||||
|
||||
**代表工具：** Lovable, Replit, Z.ai, v0
|
||||
|
||||
這就像是“拎包入住”的酒店式公寓。
|
||||
|
||||
- **無需環境配置：** 你不需要關心什麼是 Python 環境、Node.js 版本，也不用管依賴安裝。開啟瀏覽器，輸入網址，直接就能開始寫程式碼。
|
||||
- **一鍵預覽與部署：** 程式碼生成後，平臺通常會自動在右側視窗展示執行效果。做好了，點一個按鈕就能生成一個連結分享給朋友。
|
||||
- **適合場景：**
|
||||
- **快速驗證想法（MVP）：** 腦子裡有個點子，想花半小時看看能不能做出來。
|
||||
- **新手入門：** 完全不想被複雜的環境報錯勸退，只想體驗 AI 程式設計的樂趣。
|
||||
- **輕量級應用：** 做個簡單的工具網頁、小遊戲或者個人展示頁。
|
||||
|
||||
### AI IDE (本地開發環境)
|
||||
|
||||
**代表工具：** Cursor, Trae, VS Code + AI 外掛
|
||||
|
||||
這就像是“精裝修”的自有住房。
|
||||
|
||||
- **強大的本地能力：** 它執行在你的電腦上，可以直接訪問你所有的本地檔案，利用你電腦的算力。
|
||||
- **無縫對接專業工作流：** 適合大型專案，可以自由安裝各種外掛，連線本地資料庫，進行復雜的除錯。
|
||||
- **適合場景：**
|
||||
- **專業專案開發：** 需要長期維護、結構複雜的商業專案。
|
||||
- **深度定製：** 需要對程式碼細節有極致掌控，或者需要與現有的本地工作流（如 Git、Docker）深度結合。
|
||||
- **資料隱私：** 程式碼完全在本地，更符合某些企業的安全規範。
|
||||
|
||||
**總結來說：** 如果你是剛開始接觸 AI 程式設計，或者只想快速做一個小東西玩玩，**線上平臺**是絕佳的起點。如果你是專業開發者，或者專案越來越複雜，**本地 IDE** 則會提供更高的上限。
|
||||
|
||||
---
|
||||
|
||||
## 3. 什麼是 AI Agent？
|
||||
|
||||
### 什麼是 AI Agent？
|
||||
|
||||
AI Agent 是一種軟體系統，它能夠感知環境、做出決策，並自主採取行動來實現特定目標。與遵循固定指令、流程單一的傳統軟體相比，AI Agent 更加靈活和自適應。
|
||||
|
||||
下面是一些將 AI Agent 與傳統程式區分開的關鍵特徵：
|
||||
|
||||
- **自主性（Autonomy）：** AI Agent 具有較高的獨立性。傳統程式通常需要人一步一步觸發，而 Agent 可以根據目標自主決定下一步要做什麼。
|
||||
- **感知與記憶（Perception & Memory）：** Agent 會從環境中收集資料（例如 API 響應、感測器資料、使用者輸入等），並透過“記憶”保留上下文，從而在後續行動中複用經驗、持續改進效果。
|
||||
- **理性與目標導向（Rationality & Goal-Orientation）：** Agent 會圍繞給定的目標進行分析與規劃，選擇最合適的行動序列來追求更高的“績效指標”。
|
||||
- **工具使用（Tool Use）：** 現代 AI Agent 的一大特徵，是可以呼叫外部工具，不再侷限於“生成文字”。例如，它可以瀏覽網頁、執行程式碼、查詢資料庫、傳送郵件等，是一個會“排程工具”的大腦。
|
||||
|
||||
可以這樣類比理解：
|
||||
|
||||
- 一個 **傳統程式** 像是計算器。你給它輸入數字和運算子，它只在你按下按鈕時執行計算。
|
||||
- 一個 **AI 助手** 像是人類助理。你讓它“幫我找附近的餐館”，它會給你搜尋結果並列出選項，但最後還是由你做決策。
|
||||
- 一個 **AI Agent** 則更像是一支自動化研究團隊。你只需要給出高層目標（比如“幫我規劃一次日本旅行”），它就會分解任務、上網查資料、預定機票酒店（透過 API）、整理日程，最終把結果交付給你，全程幾乎不需要你幹預細節。
|
||||
|
||||
---
|
||||
|
||||
# 2. 關於提示詞編寫
|
||||
|
||||
## 1. 提示詞一次寫完好，還是拆成多步更好？
|
||||
|
||||
很多人會忍不住想直接在一個提示詞裡，把“做一個完整的全棧應用”一次性說清楚。事實上，當前工具已經足夠強大，確實有機會一次性給出一個看上去還不錯的結果。但從整體體驗和成功率來看，把工作拆成小步驟、按階段迭代，效果往往會更好，也更不容易陷入“改不動”的死衚衕。
|
||||
|
||||
> **小提示：** 與其期望“一次到位”，不如把大目標拆成一條條可執行的小待辦（To-do）。
|
||||
> 例如，不要直接說 “build me a Snake game”，而是拆成：
|
||||
> “1. 先做一個貪喫蛇遊戲的前端”，
|
||||
> “2. 再實現一個記錄分數的後端”，
|
||||
> “3. 最後把前後端連起來”。
|
||||
> 這樣能讓 AI 更準確地理解你的需求並給出更可靠的輸出。
|
||||
|
||||
## 2. 越清晰，越好
|
||||
|
||||
- 在 Vibe Coding 中，你寫的提示詞和你寫的程式碼一樣重要。提示越清晰、越具體，結果就越接近你心中所想。
|
||||
- 一開始就把目標與約束條件說清楚，可以減少後續反覆修改的次數，這不僅省時間，也能節省使用額度和成本。
|
||||
|
||||
---
|
||||
|
||||
# 3. 工具總覽（Vibe Coding / UIUX 工具）
|
||||
|
||||
## 1. AI Agent 平臺
|
||||
|
||||
| **Name** | **Platform** |
|
||||
| ------------------------------------------ | ------------ |
|
||||
| **[Lovable](https://lovable.dev/)** | Web-based |
|
||||
| **[Cursor](https://cursor.com/cn/agents)** | PC |
|
||||
| **[Z.ai](https://chat.z.ai/)** | Web-based |
|
||||
| **[Replit](https://replit.com/~)** | Web-based |
|
||||
| **[Minimax](https://agent.minimaxi.com/)** | Web-based |
|
||||
| **[Trae](https://www.trae.ai/)** | PC |
|
||||
| **[V0](https://v0.app/)** | Web-based |
|
||||
|
||||
## 2. AI UIUX 平臺
|
||||
|
||||
| **Name** | **Platform** |
|
||||
| ------------------------------------- | -------------------- |
|
||||
| **[Mastergo](https://mastergo.com/)** | Web-based |
|
||||
| **[FIgma](https://www.figma.com/)** | Web-based, PC Plugin |
|
||||
|
||||
---
|
||||
|
||||
# 4. 實戰教程（Vibe Coding + UI 結合）
|
||||
|
||||
1. 在你準備進行 Vibe Coding 的平臺聊天視窗中，輸入你想要的程式描述。
|
||||
示例：
|
||||
|
||||
> 請構建一個帶前端和後端的簡單貪喫蛇（Snake）網頁應用。
|
||||
>
|
||||
> 1. 前端
|
||||
>
|
||||
> - 頁面 1：遊戲頁面
|
||||
> - 使用鍵盤控制蛇的移動。
|
||||
> - 蛇喫掉的不是食物，而是英文單詞。
|
||||
> - 頁面側邊欄展示已收集單詞及其數量。
|
||||
> - 遊戲結束後，已收集的單詞仍然保留，並在新一局中延續。
|
||||
> - 頁面 2：寫詩頁面（Make Poem）
|
||||
> - 展示與遊戲頁面相同的單詞列表（資料一致）。
|
||||
> - 提供一個按鈕，將當前收集的單詞傳送給後端生成一首詩。
|
||||
> - 生成詩歌后，將被使用到的單詞從列表中移除或遞減計數。
|
||||
>
|
||||
> * 新增簡單的導航，在 Game 和 Make Poem 兩個頁面之間切換。
|
||||
> * 確保收集到的單詞在兩個頁面中都能看到。
|
||||
>
|
||||
> 2. 後端
|
||||
>
|
||||
> - 提供一個後端介面，接收收集到的單詞並返回一首詩。
|
||||
> - 使用 DeepSeek API 生成詩歌。
|
||||
> - 將 API Key 存放在 `.env` 檔案中，並在 `.gitignore` 中忽略該檔案。
|
||||
|
||||
2. 輸入你的 DeepSeek API Key。（可以在 [https://platform.deepseek.com/](https://platform.deepseek.com/) 獲取）
|
||||
1. LLM 的 API Key 用於在你自己的專案中呼叫大模型。由於這是敏感資訊，不能公開，因此需要單獨寫在配置檔案裡。
|
||||
**為什麼要用 `.env` 檔案，並且不要把它上傳到 GitHub？**
|
||||
- `.env` 檔案專門用來存放 **金鑰或密碼**（例如 DeepSeek API Key）。
|
||||
- 如果這個檔案被上傳到 GitHub，全世界的人都能看到你的金鑰並盜用它。
|
||||
- 為了安全起見，我們需要在 `.gitignore` 檔案中宣告忽略 `.env`，讓 Git 不跟蹤它。
|
||||
- 這樣一來，你的專案仍然可以在本機正常使用這些金鑰，但不會在倉庫中洩露。
|
||||
|
||||
3. 檢視生成結果後，如果發現錯誤或有需要修改的地方，可以直接在聊天視窗中輸入你的修改請求。
|
||||
4. 如果你對頁面設計不滿意，也可以選擇在 Figma 或 Mastergo 中重新設計介面，再把設計思路反饋給 Agent。
|
||||
|
||||
- **示例**
|
||||
|
||||
> 請設計一個名為 _Word-Snake_ 的 **雙頁面 Web 應用**。
|
||||
>
|
||||
> - **Game 頁面：**
|
||||
> - 蛇透過鍵盤控制移動。
|
||||
> - 蛇喫掉的是英文單詞，而不是普通食物。
|
||||
> - 右側面板展示已收集單詞及數量。
|
||||
> - 遊戲結束後，單詞庫存不會清空，在新一輪中繼續使用。
|
||||
> - **Make Poem 頁面：**
|
||||
> - 展示同一份共享單詞庫存。
|
||||
> - 使用者選擇部分單詞並點選 **Generate Poem** 按鈕。
|
||||
> - 將這些單詞傳送給後端，由 DeepSeek API 生成一首詩。
|
||||
> - 生成詩歌后，從庫存中刪除或減少被使用的單詞。
|
||||
> - **導航：** 透過簡單的 Tab 或頂部選單在兩個頁面之間切換。
|
||||
> - **共享狀態：** 確保收集到的單詞在兩個頁面始終保持同步可見。
|
||||
|
||||
- **效果示例**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 5. AI Agent 平臺對比（如何為簡單專案選最佳組合）
|
||||
|
||||
不同的 Vibe Coding 平臺各有特色和工作流。我們使用同一套“帶 DeepSeek API 的貪喫蛇遊戲”需求，在多個平臺上進行實測，從初學者的角度評估它們的優劣。以下是總結。
|
||||
|
||||
## 1. 對比標準
|
||||
|
||||
1. **目標（Goal）**
|
||||
構建一個接入 DeepSeek API 的貪喫蛇（Snake）網頁應用。
|
||||
2. **遊戲細節（Game Details）**
|
||||
1. 遊戲透過 DeepSeek LLM API 生成詩歌。
|
||||
2. 蛇喫掉的是英文單詞，收集到的單詞會在遊戲結束後保留，並在新一局中繼續使用。相同單詞可以被多次收集，並分別計數。
|
||||
3. 當生成一首詩後，被使用到的單詞會從庫存中移除。
|
||||
|
||||
3. **必備功能（Must-Haves）**
|
||||
1. 一個可執行的前端頁面，包含貪喫蛇遊戲（鍵盤控制、Canvas 渲染）。
|
||||
2. 單詞收集機制（單詞出現在棋盤上，蛇喫掉單詞後，側欄列表更新）。
|
||||
3. 在多輪遊戲之間保持單詞庫存的持久化。
|
||||
4. 使用 DeepSeek API 的後端（如果沒有 API Key，可以先返回模擬詩歌）。
|
||||
5. “生成詩歌”按鈕：點選後呼叫後端，顯示詩歌，並根據使用情況更新單詞庫存。
|
||||
6. 對 API Key 的 `.env` 支援，以及透過 `.gitignore` 避免金鑰洩漏。
|
||||
|
||||
4. **加分項（Nice-to-Haves）**
|
||||
1. 使用者可以選擇要用哪些詞來生成詩歌。
|
||||
2. 使用者體驗友好（例如側邊欄清晰展示單詞列表、詩歌展示區佈局合理）。
|
||||
3. 為初學者在程式碼中加入註釋，解釋關鍵邏輯。
|
||||
|
||||
## 2. 編碼輸出對比
|
||||
|
||||
### 1. Lovable（Web-based）
|
||||
|
||||
- **平臺型別：** Web 端
|
||||
- **主要特性與工作流：** Lovable 在整合與協作方面做得很好，它自動完成諸如連線 Supabase 資料庫等初始化工作，使專案搭建過程非常順暢。你只需描述專案需求，Agent 就會幫你把各類服務串聯起來，構建好基本結構。
|
||||
- **適合的使用者：** 對於第一次嘗試 Vibe Coding 的新手來說，Lovable 是非常友好的選擇。它簡化了多服務聯動的複雜度，讓你可以把注意力集中在提示詞與迭代上，而不是環境配置。得益於高度自動化，你能很快得到一個可執行的原型。
|
||||
- **提示詞過程：**
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
|
||||
|
||||
- **價格：** 相對偏貴，但如果你有學校郵箱，可以透過學生驗證以半價使用。
|
||||
|
||||
|
||||
### 2. Cursor（IDE）
|
||||
|
||||
- **平臺型別：** 桌面應用（PC）
|
||||
- **主要特性與工作流：** Cursor 是一款整合了 AI 能力的專有 IDE，支援 Windows、macOS 和 Linux。它把程式碼生成、智慧重寫、程式碼庫查詢等功能直接嵌入在開發環境中。與 Web 工具相比，它更接近傳統本地開發體驗。由於是本地環境，不同電腦的配置各異，偶爾會遇到環境相關問題。好處是專案就在本機，無需再額外下載或配置執行環境，Cursor 會幫你處理很多繁瑣步驟。
|
||||
- **適合的使用者：** 對已有一定程式設計基礎的使用者，Cursor 是一個非常強大又熟悉的環境。但對完全零基礎的新手來說，需要自己理解專案結構、依賴管理和檔案組織等概念，學習曲線會更陡一些。更適合想在傳統編碼流程中加入 AI 助手的開發者。
|
||||
- **提示詞過程：**
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
|
||||
|
||||
- **價格：**
|
||||
|
||||
|
||||
### 3. Z.ai（Web-based）
|
||||
|
||||
- **平臺型別：** Web 端
|
||||
- **主要特性與工作流：** Z.ai 的使用方式比較直接，但一個明顯的挑戰在於：你需要 **手動複製貼上生成的程式碼**。平臺本身缺少實時預覽視窗，因此很難第一時間看到程式碼執行效果。
|
||||
- **適合的使用者：** 這個平臺要求比較“動手”的使用方式。缺少自動化意味著你必須與程式碼直接打交道，這對想深入理解 AI 輸出內容的人來說反而是種訓練。但頻繁的複製貼上會帶來效率問題和出錯風險。更適合想看“原生 AI 輸出程式碼”的同學，而不是追求一鍵式體驗的人。
|
||||
- **提示詞過程：**
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
|
||||
|
||||
- **價格：**
|
||||
|
||||
|
||||
### 4. Replit（Web-based）
|
||||
|
||||
- **平臺型別：** Web 端
|
||||
- **主要特性與工作流：** Replit 是一體化的線上開發與部署環境，瀏覽器裡就可以寫程式碼、執行程式、生成線上訪問地址。開始編碼前，它會給出清晰的行動計劃；同時還提供視覺化編輯器，你可以在預覽視窗裡直接改 UI，原始碼會自動同步更新。這樣可以讓你隨時校驗 AI 的輸出是否符合預期，大幅減少來回修改的次數。
|
||||
|
||||
|
||||
|
||||
- **適合的使用者：** Replit 對新手十分友好。它簡化了從編碼到部署的完整閉環，無需自己額外配置伺服器或託管服務。協作功能也很強，適合同學之間一起做專案或請他人遠端幫忙檢視程式碼。
|
||||
- **提示詞過程：** 在構建過程中，AI 並不是一開始就完全理解需求，中間經歷了大約 3 輪迭代，最終輸出才達到了理想效果。
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
|
||||
|
||||
- **價格：**
|
||||
|
||||
|
||||
### 5. Minimax（Web-based）
|
||||
|
||||
- **平臺型別：** Web 端
|
||||
- **主要特性與工作流：** Minimax 在執行任務時通常比較耗時。其流程往往包括：AI 自動發現並修復錯誤，因此整個過程可能較慢、甚至略顯折騰。以本專案為例，Agent 一般會先生成一個詳細計劃，然後一步步搭建後端、資料庫和前端邏輯。
|
||||
- **適合的使用者：** 由於它會自動執行測試和修復錯誤，時間與 Token 消耗都比較大，但你可以清楚看到 AI 如何定位並解決問題，從學習角度看很有價值。
|
||||
- **提示詞過程：**
|
||||
|
||||
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
|
||||
|
||||
- **價格：** 免費版在複雜專案中很可能無法順利從頭跑到尾，因此更推薦付費升級，以確保專案可以完整構建。
|
||||
|
||||
|
||||
### 6. Trae（IDE）
|
||||
|
||||
- **平臺型別：** 桌面應用（PC）
|
||||
- **主要特性與工作流：** 作為桌面應用，Trae 相比 Web 工具在效能和響應速度上通常更有優勢。但它需要下載安裝，對一些使用者來說入門門檻稍高。同樣地，由於是本地環境，不同電腦配置和依賴環境的差異，會帶來一定的不確定性。優勢在於，Trae 會幫助你在本地完成專案建立與執行配置，你可以直接在本機開發與除錯。
|
||||
- **適合的使用者：** 更適合計劃長期進行 Vibe Coding 專案、並希望使用專門桌面工具的使用者。對於只想“偶爾玩一下”的同學，可能不是最輕量的選擇。
|
||||
- **提示詞過程：**
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
|
||||
|
||||
- **價格：** 價格相對親民，即便是免費版本，也足以完成質量不錯的小專案。
|
||||
|
||||
|
||||
### 7. V0（Web-based）
|
||||
|
||||
- **平臺型別：** Web 端
|
||||
- **主要特性與工作流：** V0 是一個專注於生成 React UI 元件的工具，由 Vercel 提供。它在生成高質量、可用於生產環境的介面方面表現出色。但在實際使用中，會遇到諸如“難以找到程式碼檢視”、“沒有清晰說明 API Key 應該配置在何處”等問題。
|
||||
- **適合的使用者：** V0 非常適合專注前端和 UI/UX 設計的學生或設計師。但它並不是完整的全棧解決方案，你仍然需要使用其他平臺來實現後端邏輯與 API 整合，因此如果你的目標是“一站式搭建完整應用”，它可能不是最佳首選。
|
||||
- **提示詞過程：**
|
||||
|
||||
|
||||
|
||||
|
||||
- **貪喫蛇遊戲效果：**
|
||||
|
||||
- **價格：** 免費使用者大約可以構建 4–5 個簡單專案。
|
||||
|
||||
|
||||
## 3. 平臺總結對比
|
||||
|
||||
| **平臺** | **Review** | **Platform** | **Notes** |
|
||||
| ------------------------------------------ | ------------------------------------------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
|
||||
| **[Lovable](https://lovable.dev/)** | 對 AI 程式設計新手非常友好，上手簡單、體驗順滑，是理想的入門選擇。 | Web-based | 自動完成 Supabase 等服務連線，減少配置成本。 |
|
||||
| **[Cursor](https://cursor.com/cn/agents)** | 適合已有開發經驗的使用者，大幅提升生產力與程式碼質量。 | PC | 需要一定程式設計基礎，本地環境中需自己理解專案結構和依賴。 |
|
||||
| **[Z.ai](https://chat.z.ai/)** | 更適合有程式設計基礎、想直接研究 AI 輸出程式碼細節的使用者。 | Web-based | 無預覽視窗，檢查結果較麻煩；需要手動貼上程式碼、建立資料夾和檔案並手動執行服務。 |
|
||||
| **[Replit](https://replit.com/~)** | 推薦給想快速把點子變成可訪問線上服務的使用者。 | Web-based | 一體化線上開發與部署，支援協作並提供視覺化編輯器。 |
|
||||
| **[Minimax](https://agent.minimaxi.com/)** | 適合希望看到 AI 自動查錯與修復全過程、並從中學習的人，但整體較慢且耗費 Token。 | Web-based | 整個過程較長，AI 會多次自動執行測試並修復錯誤。 |
|
||||
| **[Trae](https://www.trae.ai/)** | 針對有程式設計經驗、希望使用桌面 IDE + AI Agent 組合的使用者，是提升效率的有力工具。 | PC | 需本地安裝與環境配置，但效能更好，適合長期進行 Vibe Coding 專案。 |
|
||||
| **[V0](https://v0.app/)** | 為想快速做出 React UI 視覺效果的非開發者進行了最佳化，適合前端 / 設計向的學生。 | Web-based | 專注生成 React UI，需要與其他平臺配合完成後端和完整應用搭建。 |
|
||||
---
|
||||
title: '七款 AI 編程工具對比'
|
||||
description: '用統一任務實戰評測 7 款主流 Web Vibe Coding 平台，從新手友好度、代碼可控性、部署便捷性等維度幫你快速選型。'
|
||||
---
|
||||
+348
@@ -0,0 +1,348 @@
|
||||
# 用設計和程式設計 Agent 設計網站
|
||||
|
||||
## 本章導讀
|
||||
|
||||
本章將展示設計與開發如何透過 AI 完美協作。你將扮演產品經理的角色，指揮“設計 Agent”完成 Logo 設計、配色方案與頁面佈局，再協同“程式設計 Agent”將視覺稿轉化為可執行的程式碼。從創意構思到網站上線，體驗全鏈路的 AI 賦能開發流程，讓一個人成為一支隊伍。
|
||||
|
||||
---
|
||||
|
||||
# 1. 入門指南
|
||||
|
||||
## 1. 教程簡介
|
||||
|
||||
讓我們使用 AI 設計 Agent 和編碼 Agent，從零開始搭建一個完整的網站。
|
||||
|
||||
- **設計 Agent**：負責建立 logo、網頁佈局、配色方案和其他視覺元素
|
||||
- **編碼 Agent**：根據你在提示中提出的需求與佈局，編寫 HTML/CSS/JS 等實際程式碼，構建可執行的網站
|
||||
|
||||
## 2. 設計 Agent 與編碼 Agent
|
||||
|
||||
- **設計 Agent**：根據你提供的提示，生成圖片、頁面模型或設計風格的 AI。
|
||||
- Mastergo
|
||||
- Lovart
|
||||
- Figma MCP
|
||||
- **編碼 Agent**：根據你在提示中請求的功能與佈局，編寫實際的程式碼（HTML/CSS/JS 等）的 AI。
|
||||
- Z.AI
|
||||
- Trae
|
||||
- Cursor
|
||||
- Lovable
|
||||
|
||||
---
|
||||
|
||||
# 2. 使用設計 Agent 建立 Logo
|
||||
|
||||
## 1. 設計 Logo 時需要考慮的關鍵要素
|
||||
|
||||
Logo 是決定你網站第一印象的關鍵元素之一。想要從 AI 設計 Agent 那裡獲得滿意的結果，你需要在提示中清楚地描述你想要的 Logo 型別。
|
||||
|
||||
1. **品牌名稱 / 文字**
|
||||
|
||||
- 必須出現在 Logo 中的文字（例如：網站標題、品牌名稱等）。
|
||||
|
||||
2. **風格（情緒 / 氣氛）**
|
||||
|
||||
- Logo 想要傳達的整體感覺或氛圍。
|
||||
- _示例：極簡、可愛、簡潔、現代、復古、未來感等。_
|
||||
|
||||
3. **配色方案**（可選）
|
||||
|
||||
- 最好讓 Logo 的配色與整個網站的整體基調相匹配。
|
||||
- 可以指定具體的十六進位制色號，或大致的色調（冷色、暖色等）。
|
||||
- _示例：**`#171721`**（黑色）、**`#FF7130`**（橙色）。_
|
||||
|
||||
4. **形式（形狀 / 結構）**
|
||||
|
||||
- 明確 Logo 是否需要特定的形狀或構圖。
|
||||
- _示例：文字在圓形內部、圖示 + 文字組合、以圖示為主的 Logo 等。_
|
||||
|
||||
5. **圖示 / 符號元素**（可選）
|
||||
|
||||
- 希望出現在 Logo 中的圖形或符號。
|
||||
- _示例：書本圖示、閃電符號、與 AI 相關的圖形、抽象幾何圖形等。_
|
||||
|
||||
## 2. 編寫 Logo 設計提示詞
|
||||
|
||||
**示例提示詞**
|
||||
|
||||
```
|
||||
"請為我設計一個極簡風格的 Logo，品牌名稱是 ‘My First Website’。
|
||||
使用黑色 (#171721) 和橙色 (#FF7130)，並將文字放在一個圓形內部。"
|
||||
```
|
||||
|
||||
```
|
||||
"請設計一個以 ‘AIID’ 為品牌名的 Logo。
|
||||
整體風格要未來感、乾淨簡潔，主色為藍色與白色。
|
||||
將象徵 AI 的抽象圖形與文字相結合，並匯出為帶透明背景的 PNG。"
|
||||
```
|
||||
|
||||
## 3. 向 Agent 請求設計
|
||||
|
||||
- 輸入上述提示詞 → 比對 Agent 生成的多個設計稿。
|
||||
|
||||
|
||||
|
||||
## 4. 確定最終 Logo
|
||||
|
||||
- 從草稿中選擇你最喜歡的版本並下載。
|
||||
|
||||
---
|
||||
|
||||
# 3. 規劃你的網站結構
|
||||
|
||||
## 1. 瞭解基礎版塊
|
||||
|
||||
在真正開始製作網站前，先規劃好要包含哪些選單（版塊）非常重要。選單的設計取決於你希望訪客看到什麼、以及你希望他們採取什麼行動。
|
||||
一般來說，網站通常由 **Home / About / Contact** 等基礎版塊構成。
|
||||
|
||||
## 2. 自己先畫一個結構草圖（可選）
|
||||
|
||||
你可以先根據網站的目標，大致寫出一個簡單的選單結構。
|
||||
|
||||
### 基礎選單
|
||||
|
||||
1. **Home**
|
||||
1. 訪客進入網站後首先看到的主頁面
|
||||
2. 通常包含 Logo、主視覺區域和一句簡短的標語或簡介
|
||||
2. **About**
|
||||
1. 介紹你是誰，或者專案 / 服務的目的
|
||||
2. 個人作品集：自我介紹 + 簡短履歷
|
||||
3. 服務類網站：願景、目標以及核心功能
|
||||
3. **Contact**
|
||||
1. 聯絡方式，如郵箱、電話號碼、社交媒體連結等
|
||||
2. 也可以加入一個簡單的聯絡表單
|
||||
|
||||
### 可選選單
|
||||
|
||||
4. **Services / Projects**
|
||||
1. 展示你提供的服務，或你的專案 / 作品集
|
||||
2. 通常以列表或卡片形式展示
|
||||
|
||||
5. **Gallery**
|
||||
1. 用於展示圖片、照片或設計作品
|
||||
|
||||
6. **Blog / News**
|
||||
1. 用於釋出文章、動態或日誌
|
||||
|
||||
7. **FAQ**
|
||||
1. 整理訪客經常會問的問題及解答
|
||||
|
||||
## 3. 選擇配色方案（可選）
|
||||
|
||||
如果你已經有了 Logo，或者想用特定的顏色搭配來設計網站，也可以直接在提示詞中寫上你想使用的顏色程式碼。
|
||||
|
||||
**示例：** `#171721, #872B97, #FF7130, #FF3C68`
|
||||
|
||||
即使你暫時想不到配色方案，也可以透過配色網站或搜尋關鍵詞來找到靈感。
|
||||
|
||||
- **配色參考網站**
|
||||
- https://colorhunt.co/
|
||||
- https://coolors.co/
|
||||
|
||||
|
||||
|
||||
- **在 Google 上透過關鍵詞搜尋配色**
|
||||
|
||||
|
||||
|
||||
## 4. 編寫網站設計提示詞
|
||||
|
||||
**示例提示詞**
|
||||
|
||||
```
|
||||
"請設計一個由 Home、About、Contact 三個版塊構成的單頁網站。
|
||||
使用配色 #171721、#FF7130 和 #FF3C68。
|
||||
整體風格要現代、簡潔。"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4. 使用設計 Agent 設計網站
|
||||
|
||||
## 1. 輸入提示詞 → 生成設計稿
|
||||
|
||||
- 在提示詞中寫出你規劃好的結構以及選定的配色。
|
||||
|
||||
**Mastergo 提示詞示例**
|
||||
|
||||
|
||||
|
||||
## 2. 審閱設計稿並提出修改意見
|
||||
|
||||
你可以根據自己的需求，向 Agent 提出反饋，例如：
|
||||
|
||||
- “太花哨了，整體風格改得更簡潔一些。”
|
||||
- “換一種字型。”
|
||||
- “調整一下顏色搭配。”
|
||||
- “把這裡這一塊刪掉。”
|
||||
|
||||
|
||||
|
||||
## 3. 確定最終設計
|
||||
|
||||
當你對設計稿進行多輪修改並滿意之後，就可以把這個設計轉化為程式碼，讓編碼 Agent 能理解並繼續工作。
|
||||
|
||||
將設計轉為程式碼的方式會因平臺而異，但通常是在設計平臺中安裝並使用某些外掛來完成。
|
||||
|
||||
**Mastergo 示例**
|
||||
|
||||
1. 開啟 [Mastergo 外掛網站](https://mastergo.com/community/plugin)，搜尋 **seal**。
|
||||
|
||||
|
||||
|
||||
2. 回到設計頁面，點選 **方塊圖示（外掛）**。
|
||||
|
||||
|
||||
|
||||
3. 選中你想轉換為程式碼的設計區域，點選 **Generate** 按鈕生成程式碼。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 5. 使用編碼 Agent 搭建網站
|
||||
|
||||
## 1. 理解 HTML/CSS/JS 的基礎概念
|
||||
|
||||
一個網站本質上由三種語言構成：
|
||||
|
||||
- **HTML（HyperText Markup Language）** → 結構（骨架）
|
||||
- **CSS（Cascading Style Sheets）** → 樣式（外觀）
|
||||
- **JavaScript（JS）** → 功能（互動）
|
||||
|
||||
這三者配合在一起，構成我們看到的完整網頁。
|
||||
|
||||
1. **🏗️ HTML（結構）**
|
||||
|
||||
- 定義頁面中“展示什麼”
|
||||
- 用來放置文字、圖片、按鈕、連結等元素
|
||||
- 類似於建築物的 **牆體和框架**
|
||||
|
||||
**示例**
|
||||
|
||||
```html
|
||||
<h1>Hello!</h1>
|
||||
<p>This is my first website.</p>
|
||||
<a href="contact.html">Contact</a>
|
||||
```
|
||||
|
||||
2. **🎨 CSS（樣式）**
|
||||
|
||||
- 決定“內容怎樣展示”
|
||||
- 控制文字大小、顏色、間距、背景、按鈕形狀等
|
||||
- 讓 HTML 有了“衣服”和視覺風格
|
||||
|
||||
**示例**
|
||||
|
||||
```css
|
||||
h1 {
|
||||
color: #FF7130; /* Text color */
|
||||
font-size: 36px; /* Font size */
|
||||
text-align: center; /* Center alignment */
|
||||
}
|
||||
|
||||
body {
|
||||
background-color: #171721; /* Background color */
|
||||
color: white; /* Default text color */
|
||||
}
|
||||
```
|
||||
|
||||
3. **⚙️ JavaScript（JS）（功能）**
|
||||
|
||||
- 讓網頁能夠和使用者互動
|
||||
- 可以實現按鈕點選、選單展開、圖片輪播、表單提交等動態效果
|
||||
- 如果說 HTML/CSS 是靜態的骨架和外觀，那麼 JS 就是讓網頁“活起來”的 **大腦**
|
||||
|
||||
**示例**
|
||||
|
||||
```javascript
|
||||
function showAlert() {
|
||||
alert("The button has been clicked!");
|
||||
}
|
||||
```
|
||||
|
||||
```html
|
||||
<button onclick="showAlert()">Click me</button>
|
||||
```
|
||||
|
||||
## 2. 讓編碼 Agent 生成程式碼
|
||||
|
||||
**示例提示詞**
|
||||
|
||||
```
|
||||
"請為一個包含 Home、About 和 Contact 版塊的單頁網站編寫 HTML 和 CSS。
|
||||
使用配色 #171721、#FF7130、#FF3C68。
|
||||
背景為黑色，文字為白色。"
|
||||
```
|
||||
|
||||
|
||||
|
||||
## 3. 執行網站
|
||||
|
||||
當草稿程式碼生成後，Agent 通常會自動啟動專案，並展示生成好的網站頁面。
|
||||
|
||||
如果你重新啟動了 Agent，或者網站畫面沒有出現，可以輸入類似這樣的提示：
|
||||
|
||||
```
|
||||
"Please activate the project"
|
||||
```
|
||||
|
||||
讓 Agent 重新啟動專案並開啟預覽頁面，方便你檢視當前的效果。
|
||||
|
||||
## 4. 進行簡單修改
|
||||
|
||||
你可以繼續透過自然語言對草稿進行微調，例如：
|
||||
|
||||
- “把按鈕做大一點。”
|
||||
- “字型粗一點。”
|
||||
|
||||
|
||||
|
||||
## 5. 修改網站文案內容
|
||||
|
||||
Agent 生成的初版網站，通常會包含一些自動生成的佔位文字。為了讓它更貼近你的真實場景，你可以提前準備好實際內容，再讓 Agent 幫你替換。
|
||||
|
||||
**應用示例**：更新 AIID 網站的 About 頁面
|
||||
|
||||
1. 先寫好你想在 About 頁面展示的內容。為了方便 Agent 理解，可以將內容儲存為 Markdown 格式。
|
||||
|
||||
|
||||
|
||||
2. 然後在對話中告訴 Agent，將該檔案中的內容應用到指定頁面上。
|
||||
|
||||
|
||||
|
||||
3. 檢視應用內容後的更新版本。
|
||||
|
||||
|
||||
|
||||
## 6. 插入圖片
|
||||
|
||||
如果你想加入特定圖片（例如 Logo、背景圖等），可以先把圖片上傳到專案資料夾中，然後在提示詞裡說明要在頁面的什麼位置使用這些圖片。
|
||||
|
||||
- **示例：**
|
||||
|
||||
|
||||
|
||||
- **結果：**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 6. 將設計與程式碼整合
|
||||
|
||||
## 1. 將設計檔案與網站程式碼整合（可選）
|
||||
|
||||
當你從設計 Agent 那裡下載到了程式碼檔案後，可以把它們移動到當前專案目錄中，然後請編碼 Agent 幫你將這些設計程式碼與現有專案進行合併。
|
||||
|
||||
- **示例：**
|
||||
|
||||
|
||||
|
||||
- **結果：**
|
||||
|
||||
|
||||
---
|
||||
title: '用設計與編程 Agent 設計網站'
|
||||
description: '從創意到上線：用設計 Agent 產出視覺方案，再用編程 Agent 把設計稿變成可運行網站，總結可復用的協作流程。'
|
||||
---
|
||||
@@ -0,0 +1,325 @@
|
||||
---
|
||||
title: '寫程式碼時遇到錯誤怎麼辦 - 截圖問 AI 的實戰指南'
|
||||
description: '學習如何高效地向 AI 提問來解決開發中的各種報錯問題，掌握截圖、描述、定位問題的標準流程，讓 AI 成為你的除錯助手。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>30 分鐘</strong>'
|
||||
</script>
|
||||
|
||||
# 寫程式碼時遇到錯誤怎麼辦
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['除錯技巧', 'AI 協作', '問題排查', '開發者工具']" coreOutput="一套標準化的報錯排查流程" expectedOutput="能獨立解決 90% 的常見報錯">
|
||||
|
||||
在 AI 時代，排查錯誤的方式已經變了。
|
||||
|
||||
你不需要背下所有錯誤型別，不需要成為除錯專家，甚至不需要理解錯誤是什麼意思。
|
||||
|
||||
<strong>你只需要學會一件事：怎麼問 AI。</strong>
|
||||
|
||||
本章會教你一套<strong>從簡單到進階</strong>的排查流程：
|
||||
|
||||
1. <strong>第一步：直接問</strong>：描述現象 + 截圖，一句話提問
|
||||
2. <strong>第二步：補充資訊</strong>：如果解決不了，再開啟 F12 補充關鍵資訊
|
||||
|
||||
掌握這套流程後，<strong>90% 的報錯你都能自己解決</strong>。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 說明
|
||||
本章所有方法基於 Cursor/Trae/Claude 等 AI IDE 的實際使用經驗，可直接應用於日常開發。
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '直接提問', description: '描述現象 + 截圖' },
|
||||
{ title: '補充資訊', description: '開啟 F12 定位問題' },
|
||||
{ title: '迭代解決', description: '直到問題解決' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 核心心法：截圖問 AI
|
||||
|
||||
::: warning 為什麼這一章很重要？
|
||||
|
||||
很多初學者遇到報錯時的第一反應是：
|
||||
- 慌張，開始瞎改程式碼
|
||||
- 花半小時搜尋"xxx 錯誤怎麼解決"
|
||||
- 試圖自己理解錯誤是什麼意思
|
||||
- 自己 debug 到深夜
|
||||
|
||||
<strong>這些都是在浪費時間。</strong>
|
||||
|
||||
在 AI 時代，除錯已經變成了一件很簡單的事：
|
||||
|
||||
```
|
||||
看到報錯 → 截圖 → 問 AI → 按 AI 說的做
|
||||
```
|
||||
|
||||
你不需要理解錯誤，不需要會除錯，甚至不需要知道問題出在哪裡。
|
||||
|
||||
<strong>你只需要學會怎麼問。</strong>
|
||||
|
||||
:::
|
||||
|
||||
### 1.1 最簡單的提問方式
|
||||
|
||||
不需要複雜的模板，兩種方式任選：
|
||||
|
||||
**方式一：描述現象**
|
||||
|
||||
格式：剛才做了什麼，現在出現了什麼
|
||||
|
||||
```
|
||||
剛才我修改了登入頁面的程式碼，現在頁面白屏了，怎麼辦？
|
||||
```
|
||||
|
||||
**方式二：截圖**
|
||||
|
||||
直接截圖當前頁面或報錯資訊
|
||||
|
||||
```
|
||||
[截圖]
|
||||
|
||||
這個報錯怎麼解決？
|
||||
```
|
||||
|
||||
**最好的方式：描述 + 截圖**
|
||||
|
||||
```
|
||||
剛才我修改了登入頁面的程式碼，現在頁面白屏了。
|
||||
|
||||
[截圖]
|
||||
|
||||
怎麼辦？
|
||||
```
|
||||
|
||||
**記住：描述清楚上下文，加上截圖，AI 能更快幫你解決問題。**
|
||||
|
||||
### 1.2 如何把問題講清楚
|
||||
|
||||
很多初學者知道要提問，但不知道怎麼說。其實只需要講清楚三件事：
|
||||
|
||||
**1. 剛才做了什麼**
|
||||
|
||||
```
|
||||
剛才我點選了儲存按鈕
|
||||
剛才我修改了登入頁面的程式碼
|
||||
剛才我重新整理了頁面
|
||||
```
|
||||
|
||||
**2. 現在看到了什麼**
|
||||
|
||||
```
|
||||
現在頁面是空白的
|
||||
現在按鈕點了沒反應
|
||||
現在顯示報錯資訊
|
||||
```
|
||||
|
||||
**3. 想要達到什麼效果**
|
||||
|
||||
```
|
||||
我想讓資料儲存成功
|
||||
我想讓頁面正常顯示
|
||||
我想讓按鈕點選後彈出提示
|
||||
```
|
||||
|
||||
**完整示例：**
|
||||
|
||||
```
|
||||
剛才我點選了儲存按鈕，現在頁面顯示"儲存失敗"的報錯。
|
||||
|
||||
[截圖]
|
||||
|
||||
我想讓表單資料成功儲存到資料庫，該怎麼辦？
|
||||
```
|
||||
|
||||
**關鍵原則：**
|
||||
- 用大白話描述，不用專業術語
|
||||
- 按時間順序說：先做了什麼，然後發生了什麼
|
||||
- 把你的預期說出來，讓 AI 知道你想要什麼
|
||||
|
||||
## 2. 第一步：直接描述現象提問
|
||||
|
||||
遇到問題時，<strong>不要急著開啟 F12</strong>。先直接描述現象，截圖當前頁面，丟給 AI 看看。
|
||||
|
||||
很多時候，AI 看到截圖就能直接給出解決方案。
|
||||
|
||||
### 2.1 常見現象怎麼描述
|
||||
|
||||
::: tip 直接描述即可
|
||||
|
||||
**頁面白屏**
|
||||
```
|
||||
頁面開啟是空白的，怎麼辦？
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
**按鈕點選沒反應**
|
||||
```
|
||||
點選這個按鈕沒反應，幫我看看。
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
**資料儲存不了**
|
||||
```
|
||||
點了儲存，資料沒存上，怎麼辦？
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
**樣式顯示不對**
|
||||
```
|
||||
這個按鈕位置偏了，怎麼調整？
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
**介面報錯**
|
||||
```
|
||||
呼叫介面報錯了，幫我看看。
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 2.2 如果 AI 直接解決了
|
||||
|
||||
恭喜你，問題解決了！按照 AI 說的修改即可。
|
||||
|
||||
### 2.3 如果 AI 說"需要更多資訊"
|
||||
|
||||
這時候才需要開啟 F12，補充關鍵資訊。往下看。
|
||||
|
||||
## 3. 第二步：補充關鍵資訊
|
||||
|
||||
當 AI 說需要更多資訊時，根據問題型別，開啟 F12 擷取對應的內容。
|
||||
|
||||
### 3.1 什麼時候需要補充資訊
|
||||
|
||||
AI 可能會這樣回覆：
|
||||
- "請開啟 Console 看看有沒有報錯"
|
||||
- "截圖 Network 面板給我看看"
|
||||
- "需要看具體的錯誤資訊"
|
||||
|
||||
這時候，根據下面的指引補充截圖。
|
||||
|
||||
### 3.2 補充 Console 資訊（頁面白屏/報錯）
|
||||
|
||||
::: tip 操作步驟
|
||||
|
||||
**第一步：按 F12 開啟開發者工具**
|
||||
|
||||
Mac 是 `Cmd+Option+I`，或者右鍵頁面選"檢查"。
|
||||
|
||||
**第二步：切換到 Console 標籤頁**
|
||||
|
||||
**第三步：截圖紅色報錯資訊**
|
||||
|
||||
**第四步：發給 AI**
|
||||
|
||||
```
|
||||
Console 報錯如下：
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 3.3 補充 Network 資訊（資料問題/API 報錯）
|
||||
|
||||
::: tip 操作步驟
|
||||
|
||||
**第一步：按 F12 開啟開發者工具**
|
||||
|
||||
**第二步：切換到 Network 標籤頁**
|
||||
|
||||
**第三步：重新操作一遍**（點儲存/重新整理頁面）
|
||||
|
||||
**第四步：找到對應請求，截圖**
|
||||
|
||||
- 看 URL 和狀態碼
|
||||
- 看 Payload（傳的引數）
|
||||
- 看 Response（返回結果）
|
||||
|
||||
**第五步：發給 AI**
|
||||
|
||||
```
|
||||
Network 資訊如下：
|
||||
|
||||
請求：[截圖1]
|
||||
引數：[截圖2]
|
||||
返回：[截圖3]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
### 3.4 補充 Elements 資訊（樣式問題）
|
||||
|
||||
::: tip 操作步驟
|
||||
|
||||
**第一步：右鍵元素 → "檢查"**
|
||||
|
||||
開發者工具會自動定位到該元素。
|
||||
|
||||
**第二步：截圖 Styles 面板**
|
||||
|
||||
**第三步：發給 AI**
|
||||
|
||||
```
|
||||
元素樣式如下：
|
||||
|
||||
[截圖]
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
## 4. 第三步：迭代直到解決
|
||||
|
||||
### 4.1 低效的做法
|
||||
|
||||
這些做法會浪費你的時間：
|
||||
|
||||
看到報錯就慌張，開始瞎改程式碼
|
||||
花半小時搜尋錯誤解決方案
|
||||
試圖自己理解每個錯誤的意思
|
||||
一個人 debug 到深夜
|
||||
|
||||
### 4.2 高效的做法
|
||||
|
||||
按照這套流程來：
|
||||
|
||||
先直接描述現象截圖提問
|
||||
AI 說需要更多資訊時，再開啟 F12 補充
|
||||
按照建議修改程式碼
|
||||
改完後測試，如果問題還在就繼續截圖提問
|
||||
|
||||
## 5. 總結：完整流程
|
||||
|
||||
```
|
||||
遇到問題
|
||||
↓
|
||||
直接描述現象 + 截圖
|
||||
↓
|
||||
丟給 AI："怎麼辦？"
|
||||
↓
|
||||
AI 直接解決？
|
||||
↓ 是
|
||||
按 AI 說的做
|
||||
↓
|
||||
測試是否解決
|
||||
↓
|
||||
↓ 否 / AI 需要更多資訊
|
||||
開啟 F12，補充關鍵資訊
|
||||
↓
|
||||
再發給 AI
|
||||
↓
|
||||
重複直到解決
|
||||
```
|
||||
@@ -0,0 +1,642 @@
|
||||
---
|
||||
title: 'C 端消費場景靈感參考'
|
||||
description: '本文件彙總了 LLM 大模型在 C 端消費場景中的創意應用方向，涵蓋生活方式、情感陪伴、娛樂休閒、個人成長、社互動動等領域的靈感場景，為面向普通消費者的 AI 應用開發者提供參考。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { computed, ref } from 'vue'
|
||||
|
||||
const duration = '約 <strong>4 小時</strong>'
|
||||
|
||||
const vibePoint = ref('')
|
||||
const feeling = ref('')
|
||||
|
||||
// 每個場景的主題池 - 強調感覺、氛圍、心理暗示
|
||||
const topicPool = {
|
||||
'lifestyle': [
|
||||
{ title: '晨間儀式感喚醒助手', desc: '根據天氣、日程、心情生成專屬晨間儀式，讓每一天從美好開始' },
|
||||
{ title: '獨居生活氛圍營造師', desc: '為獨居者設計居家氛圍方案，燈光、音樂、香薰的智慧搭配建議' },
|
||||
{ title: '週末宅家治癒計劃生成器', desc: '根據當下心情推薦完美的宅家組合：電影+零食+氛圍佈置' },
|
||||
{ title: '睡前心靈安撫電臺', desc: '生成溫柔的故事、冥想引導，陪伴入睡的私人電臺' },
|
||||
{ title: '生活美學靈感捕手', desc: '從日常小事中發現美，生成生活美學建議和儀式感指南' }
|
||||
],
|
||||
'emotion': [
|
||||
{ title: '深夜樹洞傾聽者', desc: '24 小時線上的情緒垃圾桶，無評判地接納所有心事' },
|
||||
{ title: '失戀療愈陪伴師', desc: '在失戀低谷期提供溫柔的陪伴、療愈建議和情緒出口' },
|
||||
{ title: '焦慮緩解呼吸教練', desc: '感知焦慮情緒，引導呼吸練習和正念冥想' },
|
||||
{ title: '自信心重建導師', desc: '透過積極對話和心理暗示，幫助重建自我認同和價值感' },
|
||||
{ title: '情緒日記智慧解讀', desc: '分析情緒日記，發現情緒規律，給出溫暖的洞察和建議' }
|
||||
],
|
||||
'entertainment': [
|
||||
{ title: '沉浸式劇本殺 DM', desc: '扮演劇本殺主持人，營造懸疑氛圍，推動劇情發展' },
|
||||
{ title: '開放世界遊戲靈魂 NPC', desc: '有血有肉的 NPC，記住玩家故事，產生真實的情感羈絆' },
|
||||
{ title: '個性化播客內容生成', desc: '根據興趣生成專屬播客，像朋友聊天一樣自然' },
|
||||
{ title: '虛擬演唱會氛圍組', desc: '為線上演唱會營造現場感，實時互動、應援、氛圍渲染' },
|
||||
{ title: '互動小說共創夥伴', desc: '與讀者共同創作故事，每個選擇都影響世界走向' }
|
||||
],
|
||||
'growth': [
|
||||
{ title: '個人成長見證者', desc: '記錄成長軌跡，在重要節點給予鼓勵和回顧' },
|
||||
{ title: '習慣養成遊戲化教練', desc: '將枯燥的習慣養成變成有趣的冒險遊戲' },
|
||||
{ title: '技能學習搭子匹配', desc: '找到志同道合的學習夥伴，互相督促、分享進步' },
|
||||
{ title: '每日小確幸發現者', desc: '幫助發現生活中的小美好，培養感恩和積極心態' },
|
||||
{ title: '人生模擬體驗器', desc: '模擬不同人生選擇，體驗平行時空的另一種可能' }
|
||||
],
|
||||
'social': [
|
||||
{ title: '破冰話題生成器', desc: '在社交場合提供有趣的話題，化解尷尬、拉近距離' },
|
||||
{ title: '朋友圈文案氛圍師', desc: '根據照片和心情，生成有格調的朋友圈文案' },
|
||||
{ title: '約會氛圍策劃師', desc: '為約會設計完整的氛圍方案，從地點到話題到驚喜' },
|
||||
{ title: '遠端聚會氣氛擔當', desc: '線上上聚會中活躍氣氛，組織遊戲、引導互動' },
|
||||
{ title: '社交能量管理助手', desc: '幫助內曏者管理社交能量，找到舒適的社交節奏' }
|
||||
],
|
||||
'creative': [
|
||||
{ title: '靈感枯竭急救包', desc: '在創意瓶頸時提供意想不到的靈感火花' },
|
||||
{ title: '個人風格探索嚮導', desc: '幫助發現獨特的個人風格，從穿搭到表達' },
|
||||
{ title: '手賬與日記美學顧問', desc: '提供手賬排版、配色、內容創意的美學建議' },
|
||||
{ title: '攝影構圖氛圍指南', desc: '根據場景和想要的感覺，提供攝影和修圖建議' },
|
||||
{ title: '音樂心情匹配師', desc: '根據當下心情和場景，推薦完美的音樂組合' }
|
||||
],
|
||||
'travel': [
|
||||
{ title: '城市漫步探索嚮導', desc: '像本地人一樣探索城市，發現隱藏的寶藏地點' },
|
||||
{ title: '旅行心情日記生成', desc: '將旅行照片和心情轉化為優美的遊記和回憶' },
|
||||
{ title: '獨自旅行陪伴助手', desc: '為獨自旅行者提供陪伴、建議和安全感' },
|
||||
{ title: '目的地氛圍預覽', desc: '在出發前沉浸式體驗目的地氛圍，提前進入狀態' },
|
||||
{ title: '旅行攝影氛圍指導', desc: '根據場景和光線，指導拍出有故事感的旅行照片' }
|
||||
],
|
||||
'health': [
|
||||
{ title: '運動動力喚醒師', desc: '在不想動的時候給予恰到好處的鼓勵和動力' },
|
||||
{ title: '健康飲食靈感廚房', desc: '根據心情和食材，生成治癒系的健康食譜' },
|
||||
{ title: '睡眠質量最佳化氛圍師', desc: '從環境到心理，全方位營造優質睡眠氛圍' },
|
||||
{ title: '身體感知引導師', desc: '引導關注身體訊號，建立身心連線' },
|
||||
{ title: '自我關愛提醒助手', desc: '在忙碌中提醒你停下來，關愛自己' }
|
||||
],
|
||||
'learning': [
|
||||
{ title: '知識探索遊戲化嚮導', desc: '將枯燥的知識學習變成有趣的探索冒險' },
|
||||
{ title: '語言學習情景夥伴', desc: '扮演不同角色，在情景對話中自然習得語言' },
|
||||
{ title: '好奇心滿足助手', desc: '回答各種奇思妙想，滿足對世界的好奇心' },
|
||||
{ title: '讀書筆記靈感激發', desc: '幫助整理讀書心得，發現新的思考角度' },
|
||||
{ title: '知識分享氛圍營造', desc: '將學到的知識轉化為有趣的分享內容' }
|
||||
],
|
||||
'relationship': [
|
||||
{ title: '親密關係溝通教練', desc: '幫助表達難以啟齒的情感，改善親密關係' },
|
||||
{ title: '家人關懷提醒助手', desc: '提醒你關心家人，提供溫馨的互動建議' },
|
||||
{ title: '友誼維護氛圍師', desc: '幫助維護遠距離友誼，創造共同話題' },
|
||||
{ title: '表白與驚喜策劃師', desc: '為重要的人策劃難忘的驚喜和浪漫時刻' },
|
||||
{ title: '衝突緩和氛圍引導', desc: '在關係緊張時提供緩和氛圍的建議和話術' }
|
||||
],
|
||||
'pet': [
|
||||
{ title: '寵物擬人化日記', desc: '以寵物的視角生成日記，記錄與主人的溫馨日常' },
|
||||
{ title: '寵物行為解讀師', desc: '解讀寵物的行為語言，加深與寵物的連線' },
|
||||
{ title: '寵物陪伴時光策劃', desc: '設計與寵物互動的創意活動，增進感情' },
|
||||
{ title: '寵物紀念故事生成', desc: '將寵物的照片和回憶轉化為溫馨的故事' },
|
||||
{ title: '新手鏟屎官安心指南', desc: '為新手寵物主人提供溫暖的陪伴和指導' }
|
||||
],
|
||||
'finance': [
|
||||
{ title: '消費情緒覺察助手', desc: '覺察衝動消費背後的情緒，建立健康的消費觀' },
|
||||
{ title: '儲蓄目標視覺化激勵', desc: '將儲蓄目標轉化為視覺化的夢想進度' },
|
||||
{ title: '理財知識輕鬆學', desc: '用輕鬆有趣的方式學習理財知識' },
|
||||
{ title: '財務焦慮舒緩師', desc: '在面對財務壓力時提供情緒支援和實用建議' },
|
||||
{ title: '小額投資體驗遊戲', desc: '透過遊戲化方式體驗投資，降低入門門檻' }
|
||||
],
|
||||
'career': [
|
||||
{ title: '職業迷茫陪伴者', desc: '在職業迷茫期提供傾聽、探索和方向建議' },
|
||||
{ title: '工作成就感喚醒師', desc: '幫助發現工作中的價值和意義，重燃熱情' },
|
||||
{ title: '職場社交氛圍助手', desc: '提供職場社交的輕鬆話題和互動建議' },
|
||||
{ title: '副業靈感激發器', desc: '根據個人興趣和技能，激發副業創意' },
|
||||
{ title: '面試前信心加油站', desc: '在面試前提供心理建設和信心鼓勵' }
|
||||
],
|
||||
'home': [
|
||||
{ title: '居家空間氛圍設計師', desc: '根據心情和季節，設計居家氛圍方案' },
|
||||
{ title: '四季家居變換指南', desc: '隨季節變換家居佈置，保持新鮮感' },
|
||||
{ title: '小戶型空間魔法', desc: '讓小空間也能有舒適溫馨的氛圍' },
|
||||
{ title: '居家儀式感創造者', desc: '為日常居家活動創造儀式感' },
|
||||
{ title: '斷舍離心理陪伴', desc: '在整理物品時提供心理支援和決策建議' }
|
||||
],
|
||||
'food': [
|
||||
{ title: '一人食治癒料理', desc: '為獨居者設計簡單治癒的料理方案' },
|
||||
{ title: '節日餐桌氛圍設計', desc: '為特殊日子設計有儀式感的餐桌布置' },
|
||||
{ title: '料理心情匹配師', desc: '根據當下心情推薦適合的食物和做法' },
|
||||
{ title: '廚房小白信心建立', desc: '為零基礎烹飪者提供溫暖鼓勵和簡單食譜' },
|
||||
{ title: '美食攝影氛圍指南', desc: '讓家常料理也能拍出誘人的氛圍感' }
|
||||
],
|
||||
'fashion': [
|
||||
{ title: '今日穿搭心情板', desc: '根據天氣、場合、心情生成穿搭靈感' },
|
||||
{ title: '膠囊衣櫥搭配師', desc: '用有限的單品創造無限的搭配可能' },
|
||||
{ title: '個人風格探索之旅', desc: '幫助發現和建立獨特的個人風格' },
|
||||
{ title: '舊衣新穿創意師', desc: '為舊衣服提供新的搭配靈感' },
|
||||
{ title: '特殊場合造型顧問', desc: '為重要場合設計令人自信的造型' }
|
||||
]
|
||||
}
|
||||
|
||||
// 預定義的推薦鏈路對映表 - 基於氛圍和感覺
|
||||
const recommendationMap = {
|
||||
// 氛圍點: 治癒系
|
||||
'healing': {
|
||||
'relax': ['emotion', 'lifestyle', 'health', 'home'],
|
||||
'inspire': ['creative', 'growth', 'learning', 'entertainment'],
|
||||
'connect': ['relationship', 'social', 'pet', 'emotion'],
|
||||
'escape': ['travel', 'entertainment', 'creative', 'lifestyle']
|
||||
},
|
||||
// 氛圍點: 成長系
|
||||
'growth': {
|
||||
'relax': ['growth', 'learning', 'creative', 'health'],
|
||||
'inspire': ['career', 'learning', 'creative', 'growth'],
|
||||
'connect': ['social', 'relationship', 'career', 'learning'],
|
||||
'escape': ['travel', 'entertainment', 'creative', 'lifestyle']
|
||||
},
|
||||
// 氛圍點: 社交系
|
||||
'social': {
|
||||
'relax': ['social', 'pet', 'food', 'home'],
|
||||
'inspire': ['social', 'creative', 'entertainment', 'travel'],
|
||||
'connect': ['relationship', 'social', 'pet', 'travel'],
|
||||
'escape': ['social', 'travel', 'entertainment', 'creative']
|
||||
},
|
||||
// 氛圍點: 探索系
|
||||
'explore': {
|
||||
'relax': ['travel', 'creative', 'lifestyle', 'food'],
|
||||
'inspire': ['travel', 'creative', 'learning', 'entertainment'],
|
||||
'connect': ['travel', 'social', 'relationship', 'pet'],
|
||||
'escape': ['travel', 'entertainment', 'creative', 'lifestyle']
|
||||
},
|
||||
// 氛圍點: 日常系
|
||||
'daily': {
|
||||
'relax': ['lifestyle', 'home', 'health', 'emotion'],
|
||||
'inspire': ['creative', 'food', 'fashion', 'home'],
|
||||
'connect': ['relationship', 'social', 'pet', 'lifestyle'],
|
||||
'escape': ['entertainment', 'creative', 'travel', 'lifestyle']
|
||||
}
|
||||
}
|
||||
|
||||
const vibeOptions = [
|
||||
{ label: '治癒系', value: 'healing', desc: '溫暖、安撫、療愈' },
|
||||
{ label: '成長系', value: 'growth', desc: '進步、突破、蛻變' },
|
||||
{ label: '社交系', value: 'social', desc: '連線、分享、互動' },
|
||||
{ label: '探索系', value: 'explore', desc: '好奇、冒險、發現' },
|
||||
{ label: '日常系', value: 'daily', desc: '平凡、真實、當下' }
|
||||
]
|
||||
|
||||
const feelingOptions = [
|
||||
{ label: '想要放鬆', value: 'relax', desc: '舒緩壓力、放空自己' },
|
||||
{ label: '尋找靈感', value: 'inspire', desc: '激發創意、獲得啟發' },
|
||||
{ label: '渴望連線', value: 'connect', desc: '與人連線、情感共鳴' },
|
||||
{ label: '暫時逃離', value: 'escape', desc: '逃離現實、沉浸體驗' }
|
||||
]
|
||||
|
||||
const scenarios = [
|
||||
{ key: 'lifestyle', name: '生活方式', anchor: '#_1-生活方式' },
|
||||
{ key: 'emotion', name: '情感陪伴', anchor: '#_2-情感陪伴' },
|
||||
{ key: 'entertainment', name: '娛樂休閒', anchor: '#_3-娛樂休閒' },
|
||||
{ key: 'growth', name: '個人成長', anchor: '#_4-個人成長' },
|
||||
{ key: 'social', name: '社互動動', anchor: '#_5-社互動動' },
|
||||
{ key: 'creative', name: '創意表達', anchor: '#_6-創意表達' },
|
||||
{ key: 'travel', name: '旅行探索', anchor: '#_7-旅行探索' },
|
||||
{ key: 'health', name: '身心健康', anchor: '#_8-身心健康' },
|
||||
{ key: 'learning', name: '知識探索', anchor: '#_9-知識探索' },
|
||||
{ key: 'relationship', name: '關係經營', anchor: '#_10-關係經營' },
|
||||
{ key: 'pet', name: '寵物陪伴', anchor: '#_11-寵物陪伴' },
|
||||
{ key: 'finance', name: '財務健康', anchor: '#_12-財務健康' },
|
||||
{ key: 'career', name: '職業發展', anchor: '#_13-職業發展' },
|
||||
{ key: 'home', name: '居家空間', anchor: '#_14-居家空間' },
|
||||
{ key: 'food', name: '美食料理', anchor: '#_15-美食料理' },
|
||||
{ key: 'fashion', name: '穿搭風格', anchor: '#_16-穿搭風格' }
|
||||
]
|
||||
|
||||
// 計算推薦結果 - 從主題池中隨機抽取
|
||||
const recommendationTopics = computed(() => {
|
||||
if (!vibePoint.value || !feeling.value) return []
|
||||
|
||||
const keys = recommendationMap[vibePoint.value]?.[feeling.value] || []
|
||||
const topics = []
|
||||
|
||||
// 從每個推薦場景中隨機抽取 1-2 個主題
|
||||
keys.forEach(key => {
|
||||
const scenario = scenarios.find(item => item.key === key)
|
||||
const scenarioTopics = topicPool[key] || []
|
||||
|
||||
if (scenario && scenarioTopics.length > 0) {
|
||||
// 隨機抽取 1-2 個主題
|
||||
const count = Math.floor(Math.random() * 2) + 1
|
||||
const shuffled = [...scenarioTopics].sort(() => Math.random() - 0.5)
|
||||
const selected = shuffled.slice(0, Math.min(count, shuffled.length))
|
||||
|
||||
selected.forEach(topic => {
|
||||
topics.push({
|
||||
...topic,
|
||||
scenarioKey: key,
|
||||
scenarioName: scenario.name,
|
||||
scenarioAnchor: scenario.anchor
|
||||
})
|
||||
})
|
||||
}
|
||||
})
|
||||
|
||||
// 隨機排序並限制總數
|
||||
return topics.sort(() => Math.random() - 0.5).slice(0, 8)
|
||||
})
|
||||
|
||||
// 獲取當前選擇的描述
|
||||
const currentSelection = computed(() => {
|
||||
const vibe = vibeOptions.find(i => i.value === vibePoint.value)
|
||||
const feel = feelingOptions.find(p => p.value === feeling.value)
|
||||
return {
|
||||
vibe: vibe?.label || '',
|
||||
feeling: feel?.label || ''
|
||||
}
|
||||
})
|
||||
|
||||
const scrollToAnchor = (anchor) => {
|
||||
// 延遲滾動確保DOM更新完成
|
||||
setTimeout(() => {
|
||||
// 嘗試透過ID查詢（支援多種格式）
|
||||
let element = document.querySelector(anchor)
|
||||
|
||||
// 如果找不到，嘗試其他可能的ID格式
|
||||
if (!element) {
|
||||
// 嘗試去掉下劃線字首
|
||||
const altAnchor = anchor.replace('#_', '#')
|
||||
element = document.querySelector(altAnchor)
|
||||
}
|
||||
|
||||
// 如果還是找不到，透過標題文字查詢
|
||||
if (!element) {
|
||||
// 從錨點提取場景名稱
|
||||
const anchorText = decodeURIComponent(anchor.replace('#', '').replace(/^_/, ''))
|
||||
const headings = document.querySelectorAll('h2, h3')
|
||||
|
||||
for (let heading of headings) {
|
||||
const headingText = heading.textContent.trim()
|
||||
// 完全匹配或包含匹配
|
||||
const cleanHeading = headingText.replace(/^\d+\.\s*/, '')
|
||||
if (cleanHeading === anchorText || headingText.includes(anchorText)) {
|
||||
element = heading
|
||||
break
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (element) {
|
||||
element.scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
block: 'start'
|
||||
})
|
||||
// 高亮顯示目標段落
|
||||
element.style.backgroundColor = '#fdf2f8'
|
||||
element.style.transition = 'background-color 0.3s'
|
||||
element.style.padding = '8px'
|
||||
element.style.borderRadius = '4px'
|
||||
setTimeout(() => {
|
||||
element.style.backgroundColor = ''
|
||||
element.style.padding = ''
|
||||
}, 2000)
|
||||
}
|
||||
}, 100)
|
||||
}
|
||||
|
||||
const resetSelection = () => {
|
||||
vibePoint.value = ''
|
||||
feeling.value = ''
|
||||
}
|
||||
</script>
|
||||
|
||||
# C 端消費場景靈感參考
|
||||
|
||||
## 章節導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['C 端應用', '生活方式', '情感體驗', '氛圍營造']" coreOutput="發現 15+ 生活場景靈感" expectedOutput="找到打動使用者的產品方向">
|
||||
|
||||
本文件彙總了 <strong>LLM 大模型在 C 端消費場景中的創意應用方向</strong>。與 B 端關注效率和痛點不同，C 端產品更注重<strong>營造感覺、心理暗示和氛圍</strong>，讓使用者在使用過程中獲得情感共鳴和美好體驗。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
## 場景氛圍快速選擇
|
||||
|
||||
<el-card shadow="hover" style="margin-top: 16px; margin-bottom: 24px; border-left: 5px solid #ec4899;">
|
||||
<div style="font-weight: 600; margin-bottom: 8px;">找到觸動你的場景靈感</div>
|
||||
<div style="color: #606266; font-size: 14px; line-height: 1.6; margin-bottom: 12px;">
|
||||
選擇你想要的氛圍和當下的感覺，系統會推薦相關的場景方向，點選標籤即可跳轉到對應章節。
|
||||
</div>
|
||||
<el-row :gutter="16">
|
||||
<el-col :span="12">
|
||||
<el-select v-model="vibePoint" placeholder="選擇氛圍型別" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in vibeOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value"
|
||||
>
|
||||
<div style="font-weight: 500;">{{ item.label }}</div>
|
||||
<div style="font-size: 12px; color: #909399;">{{ item.desc }}</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<el-select v-model="feeling" placeholder="選擇當下感覺" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in feelingOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value"
|
||||
>
|
||||
<div style="font-weight: 500;">{{ item.label }}</div>
|
||||
<div style="font-size: 12px; color: #909399;">{{ item.desc }}</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
<div v-if="recommendationTopics.length > 0" style="margin-top: 16px;">
|
||||
<div style="font-weight: 600; margin-bottom: 12px; color: #ec4899;">
|
||||
為你推薦的 {{ currentSelection.vibe }} × {{ currentSelection.feeling }} 場景：
|
||||
</div>
|
||||
<div style="display: flex; flex-wrap: wrap; gap: 8px;">
|
||||
<el-tag
|
||||
v-for="topic in recommendationTopics"
|
||||
:key="topic.title"
|
||||
type="danger"
|
||||
effect="light"
|
||||
style="cursor: pointer; margin-bottom: 4px;"
|
||||
@click="scrollToAnchor(topic.scenarioAnchor)"
|
||||
>
|
||||
{{ topic.title }}
|
||||
</el-tag>
|
||||
</div>
|
||||
<el-button type="text" size="small" @click="resetSelection" style="margin-top: 8px;">
|
||||
重新選擇
|
||||
</el-button>
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
---
|
||||
|
||||
## 1. 生活方式
|
||||
|
||||
> 💡 **核心理念**：讓平凡的日常變得有儀式感，在細節中創造美好
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 晨間儀式感喚醒助手 | 整合天氣 API、日曆資料，LLM 生成個性化晨間方案；配合智慧音響播放定製音樂，智慧燈光漸亮 |
|
||||
| 2 | 獨居生活氛圍營造師 | 接入智慧家居裝置（燈光、音響、香薰機），LLM 根據時間/心情自動調節引數；學習使用者偏好持續最佳化 |
|
||||
| 3 | 週末宅家治癒計劃生成器 | 對接流媒體平臺 API 獲取片單，結合使用者歷史偏好生成電影+美食+佈置的組合方案 |
|
||||
| 4 | 睡前心靈安撫電臺 | TTS 語音合成生成溫柔故事，白噪音混合演算法，智慧音量漸弱；根據睡眠資料調整內容 |
|
||||
| 5 | 生活美學靈感捕手 | 影象識別分析使用者環境照片，LLM 生成美學建議；Pinterest/小紅書風格內容推薦 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 情感陪伴
|
||||
|
||||
> 💡 **核心理念**：無條件的接納和陪伴，成為情緒的溫柔容器
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 深夜樹洞傾聽者 | 端到端加密確保隱私，LLM 情感分析理解情緒，長期記憶儲存使用者故事，多輪對話持續陪伴 |
|
||||
| 2 | 失戀療愈陪伴師 | 情感階段識別演算法，分階段提供不同支援（傾訴期→宣洩期→重建期）；心理學知識庫 RAG 檢索 |
|
||||
| 3 | 焦慮緩解呼吸教練 | 生物感測器資料接入（心率/呼吸），實時監測焦慮水平；語音引導呼吸節奏，漸進式肌肉放鬆指導 |
|
||||
| 4 | 自信心重建導師 | 積極心理學對話方塊架，記錄並反饋使用者的小成就；認知重構技術幫助改變負面自我對話 |
|
||||
| 5 | 情緒日記智慧解讀 | 情緒識別 NLP 模型，時間序列分析發現情緒規律；視覺化情緒圖譜，預測性情緒預警 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 娛樂休閒
|
||||
|
||||
> 💡 **核心理念**：創造沉浸式的體驗，讓娛樂成為心靈的棲息地
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 沉浸式劇本殺 DM | LLM 實時生成劇情分支，語音合成扮演 NPC，根據玩家反應動態調整難度和節奏；AR/VR 場景渲染 |
|
||||
| 2 | 開放世界遊戲靈魂 NPC | 長期記憶資料庫儲存玩家互動歷史，LLM 生成個性化對話；情感計算讓 NPC 有真實情緒反應 |
|
||||
| 3 | 個性化播客內容生成 | 根據使用者興趣圖譜生成專屬內容，TTS 克隆使用者喜歡的聲音；實時互動回答聽眾問題 |
|
||||
| 4 | 虛擬演唱會氛圍組 | 虛擬形象渲染，實時彈幕互動，虛擬熒光棒/應援道具；空間音訊技術營造現場感 |
|
||||
| 5 | 互動小說共創夥伴 | LLM 實時生成劇情，使用者選擇影響故事走向；多結局設計，角色關係動態發展 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 個人成長
|
||||
|
||||
> 💡 **核心理念**：成長不是苦行，而是一場有趣的自我發現之旅
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 個人成長見證者 | 時間軸視覺化展示成長軌跡，里程碑自動標記；對比圖展示"過去的我"vs"現在的我" |
|
||||
| 2 | 習慣養成遊戲化教練 | 遊戲化機制（經驗值、等級、徽章），社交排行榜，AI 教練角色扮演（如"冒險導師"） |
|
||||
| 3 | 技能學習搭子匹配 | 基於興趣和學習目標的匹配演算法，學習小組社羣，互相監督打卡機制 |
|
||||
| 4 | 每日小確幸發現者 | 影象識別發現生活中的美好瞬間， gratitude journal 引導，每週美好瞬間回顧 |
|
||||
| 5 | 人生模擬體驗器 | 多分支劇情模擬不同選擇的結果，平行人生對比；決策後果的視覺化呈現 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 社互動動
|
||||
|
||||
> 💡 **核心理念**：讓社交變得輕鬆自然，找到舒適的連線方式
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 破冰話題生成器 | 基於場合和參與者的智慧話題推薦，實時對話分析提供延續話題建議；尷尬時刻救場提示 |
|
||||
| 2 | 朋友圈文案氛圍師 | 影象內容分析，LLM 生成多風格文案（文藝/幽默/深沉）；emoji 和排版智慧推薦 |
|
||||
| 3 | 約會氛圍策劃師 | 基於雙方興趣的約會方案生成，餐廳/活動推薦，對話話題建議；實時天氣和交通提醒 |
|
||||
| 4 | 遠端聚會氣氛擔當 | 線上遊戲庫，破冰活動生成器，話題輪盤；虛擬背景和濾鏡增強氛圍 |
|
||||
| 5 | 社交能量管理助手 | 社交活動後的能量消耗評估，恢復建議（獨處活動推薦）；社交日曆智慧規劃 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 創意表達
|
||||
|
||||
> 💡 **核心理念**：每個人都有創造力，只是需要被喚醒
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 靈感枯竭急救包 | 跨領域聯想演算法，隨機刺激詞生成，創意 prompt 庫；腦圖式靈感發散工具 |
|
||||
| 2 | 個人風格探索嚮導 | 影象分析識別使用者現有風格，風格趨勢推薦，虛擬試衣/試妝；風格進化時間軸 |
|
||||
| 3 | 手賬與日記美學顧問 | 排版模板推薦，配色方案生成，裝飾元素建議；手寫體識別和內容美化 |
|
||||
| 4 | 攝影構圖氛圍指南 | 場景識別和構圖建議，濾鏡風格推薦，修圖引數智慧調整；攝影技巧學習路徑 |
|
||||
| 5 | 音樂心情匹配師 | 音樂情感分析演算法，使用者心情識別，個性化歌單生成；音樂故事和背景介紹 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 旅行探索
|
||||
|
||||
> 💡 **核心理念**：旅行不僅是看風景，更是感受不同的生活方式
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 城市漫步探索嚮導 | 本地達人內容聚合，小眾地點推薦，AR 導航指引；實時翻譯和語音講解 |
|
||||
| 2 | 旅行心情日記生成 | 照片自動分類和精選，LLM 生成優美遊記，地理位置標記時間軸；一鍵生成旅行影片 |
|
||||
| 3 | 獨自旅行陪伴助手 | 實時位置共享和安全提醒，當地緊急聯絡人，AI 導遊語音陪伴；獨行社羣交流 |
|
||||
| 4 | 目的地氛圍預覽 | VR/360° 全景預覽，當地聲音和氣味模擬，文化背景介紹；虛擬"試住"體驗 |
|
||||
| 5 | 旅行攝影氛圍指導 | 黃金時刻提醒，構圖輔助線，當地特色拍攝點推薦；後期調色風格建議 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 身心健康
|
||||
|
||||
> 💡 **核心理念**：健康不是目標，而是一種溫柔的自我關愛
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 運動動力喚醒師 | 根據使用者狀態智慧推薦運動型別，微運動（5分鐘）選項，遊戲化運動挑戰；社交運動打卡 |
|
||||
| 2 | 健康飲食靈感廚房 | 冰箱食材識別，個性化食譜推薦，營養搭配分析； step-by-step 烹飪指導 |
|
||||
| 3 | 睡眠質量最佳化氛圍師 | 睡眠監測資料分析，睡前儀式生成，環境最佳化建議（溫度/溼度/光線）；智慧喚醒 |
|
||||
| 4 | 身體感知引導師 | 身體掃描冥想引導，身體部位情緒關聯，身心連線練習；生物反饋視覺化 |
|
||||
| 5 | 自我關愛提醒助手 | 工作強度監測，定期提醒休息，微關愛活動建議（喝水/伸展/深呼吸）；自我關愛記錄 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 知識探索
|
||||
|
||||
> 💡 **核心理念**：學習是一場永無止境的冒險，好奇是最好的老師
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 知識探索遊戲化嚮導 | 知識點地圖視覺化，闖關式學習路徑，成就徽章系統；AI 導師角色扮演 |
|
||||
| 2 | 語言學習情景夥伴 | LLM 扮演不同角色進行對話，發音糾正，文化背景介紹；沉浸式情景模擬 |
|
||||
| 3 | 好奇心滿足助手 | 維基百科/知識圖譜接入，複雜概念通俗化解釋，相關知識推薦；好奇心記錄 |
|
||||
| 4 | 讀書筆記靈感激發 | 書籍內容分析，觀點提取和關聯，思考角度推薦；讀書筆記模板和美化 |
|
||||
| 5 | 知識分享氛圍營造 | 知識卡片自動生成，分享文案最佳化，視覺美化；社交分享資料反饋 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 關係經營
|
||||
|
||||
> 💡 **核心理念**：好的關係需要用心經營，而用心不需要很複雜
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 親密關係溝通教練 | 情感表達模板生成，非暴力溝通技巧指導，衝突化解話術；關係健康度評估 |
|
||||
| 2 | 家人關懷提醒助手 | 重要日期提醒（生日/紀念日），關懷話術建議，家庭活動推薦；家庭相簿生成 |
|
||||
| 3 | 友誼維護氛圍師 | 朋友互動記錄，共同話題推薦，遠端聚會組織；友誼時間軸和回憶生成 |
|
||||
| 4 | 表白與驚喜策劃師 | 個性化驚喜方案生成，禮物推薦，浪漫話術建議；執行時間表和提醒 |
|
||||
| 5 | 衝突緩和氛圍引導 | 情緒降溫話術，換位思考引導，和解步驟建議；關係修復跟蹤 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 寵物陪伴
|
||||
|
||||
> 💡 **核心理念**：寵物是家人，它們的陪伴值得被記錄和珍惜
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 寵物擬人化日記 | 寵物行為分析，第一人稱日記生成，照片自動配圖；寵物"朋友圈" |
|
||||
| 2 | 寵物行為解讀師 | 寵物行為影片分析，健康預警，訓練建議；品種特性知識庫 |
|
||||
| 3 | 寵物陪伴時光策劃 | 寵物活動推薦，DIY 玩具教程，寵物友好地點推薦；寵物社交匹配 |
|
||||
| 4 | 寵物紀念故事生成 | 照片和影片精選，時間軸故事生成，音樂配搭；紀念冊/影片自動生成 |
|
||||
| 5 | 新手鏟屎官安心指南 | 分階段養護指南，常見問題解答，緊急情況處理；新手社羣支援 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 財務健康
|
||||
|
||||
> 💡 **核心理念**：財務自由不是目標，財務健康纔是
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 消費情緒覺察助手 | 消費記錄分析，情緒-消費關聯分析，衝動消費預警；替代性滿足建議 |
|
||||
| 2 | 儲蓄目標視覺化激勵 | 目標進度視覺化，夢想場景渲染，里程碑慶祝；儲蓄習慣養成遊戲 |
|
||||
| 3 | 理財知識輕鬆學 | 碎片化知識推送，場景化案例教學，互動問答；知識檢測和證書 |
|
||||
| 4 | 財務焦慮舒緩師 | 財務狀況健康評估，壓力管理技巧，小步行動計劃；財務心理諮詢 |
|
||||
| 5 | 小額投資體驗遊戲 | 虛擬投資模擬，風險教育，投資組合遊戲；真實小額投資引導 |
|
||||
|
||||
---
|
||||
|
||||
## 13. 職業發展
|
||||
|
||||
> 💡 **核心理念**：職業不是軌道，而是可以探索的曠野
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 職業迷茫陪伴者 | 職業興趣測評，能力盤點，行業資訊推薦；職業導師對話 |
|
||||
| 2 | 工作成就感喚醒師 | 工作成果記錄，價值提煉，成就視覺化；同事/客戶正向反饋收集 |
|
||||
| 3 | 職場社交氛圍助手 | 職場話題推薦， networking 技巧，行業活動推薦；LinkedIn 內容最佳化 |
|
||||
| 4 | 副業靈感激發器 | 技能-興趣-市場需求匹配，副業案例庫，啟動指南；副業社羣交流 |
|
||||
| 5 | 面試前信心加油站 | 模擬面試，常見問題準備，自信提升技巧；形象建議 |
|
||||
|
||||
---
|
||||
|
||||
## 14. 居家空間
|
||||
|
||||
> 💡 **核心理念**：家不只是居住的地方，更是心靈的棲息地
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 居家空間氛圍設計師 | 空間照片分析，風格推薦，傢俱/裝飾推薦；AR 預覽效果 |
|
||||
| 2 | 四季家居變換指南 | 季節主題推薦，收納和展示建議，節日裝飾方案；購物清單生成 |
|
||||
| 3 | 小戶型空間魔法 | 空間最佳化演算法，多功能傢俱推薦，收納技巧；視覺擴容技巧 |
|
||||
| 4 | 居家儀式感創造者 | 日常儀式設計（晨間/晚間/週末），儀式執行提醒；儀式效果反饋 |
|
||||
| 5 | 斷舍離心理陪伴 | 物品情感價值評估，斷舍離步驟指導，心理支援；捐贈/回收渠道推薦 |
|
||||
|
||||
---
|
||||
|
||||
## 15. 美食料理
|
||||
|
||||
> 💡 **核心理念**：食物是愛的語言，烹飪是表達愛的方式
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 一人食治癒料理 | 冰箱食材識別，簡單食譜推薦， step-by-step 指導；一人食擺盤美學 |
|
||||
| 2 | 節日餐桌氛圍設計 | 節日主題選單，餐桌布置方案，氛圍營造技巧；賓客體驗最佳化 |
|
||||
| 3 | 料理心情匹配師 | 心情-食物關聯演算法，情緒調節食譜， comfort food 推薦；烹飪療愈引導 |
|
||||
| 4 | 廚房小白信心建立 | 超簡單食譜，失敗挽救技巧，信心建設話術；漸進式難度提升 |
|
||||
| 5 | 美食攝影氛圍指南 | 食物擺盤建議，自然光利用，拍攝角度指導；濾鏡和後期建議 |
|
||||
|
||||
---
|
||||
|
||||
## 16. 穿搭風格
|
||||
|
||||
> 💡 **核心理念**：穿搭是自我表達，風格是內在的外顯
|
||||
|
||||
| 序號 | 應用場景名稱 | 應用場景功能 |
|
||||
| :--: | ------------ | ------------ |
|
||||
| 1 | 今日穿搭心情板 | 天氣/場合/心情綜合推薦，虛擬試衣，搭配靈感；衣櫥管理 |
|
||||
| 2 | 膠囊衣櫥搭配師 | 衣櫥盤點，單品搭配組合，一衣多穿方案；購物建議（填補空缺） |
|
||||
| 3 | 個人風格探索之旅 | 風格測試，參考 icon 推薦，風格進化路徑；自信建設 |
|
||||
| 4 | 舊衣新穿創意師 | 舊衣改造靈感，新搭配方式，配飾點綴技巧；可持續時尚理念 |
|
||||
| 5 | 特殊場合造型顧問 | 場合 dress code 解讀，造型方案生成，妝容髮型建議；整體造型協調 |
|
||||
|
||||
---
|
||||
|
||||
## 設計 C 端產品的核心心法
|
||||
|
||||
### 1. 從"功能"到"感受"
|
||||
|
||||
B 端產品關注"這個功能能解決什麼問題"，C 端產品關注"這個功能能帶來什麼感覺"。
|
||||
|
||||
| B 端思維 | C 端思維 |
|
||||
|---------|---------|
|
||||
| 提高效率 | 節省時間去做喜歡的事 |
|
||||
| 降低成本 | 讓每一分錢花得值得 |
|
||||
| 解決痛點 | 創造美好體驗 |
|
||||
| 功能完備 | 感覺到位 |
|
||||
|
||||
### 2. 營造氛圍的三個層次
|
||||
|
||||
**感官層**：視覺、聽覺、觸覺的設計
|
||||
- 溫暖的顏色
|
||||
- 舒緩的聲音
|
||||
- 流暢的動效
|
||||
|
||||
**情感層**：情緒的共鳴和引導
|
||||
- 理解使用者的心情
|
||||
- 提供情感支援
|
||||
- 創造正向情緒
|
||||
|
||||
**意義層**：價值的認同和歸屬
|
||||
- 讓使用者感到被理解
|
||||
- 創造歸屬感
|
||||
- 賦予行動意義
|
||||
|
||||
### 3. 心理暗示的力量
|
||||
|
||||
C 端產品的文案和設計都在傳遞心理暗示：
|
||||
|
||||
- **正向暗示**："你已經做得很好了"、"慢慢來，沒關係"
|
||||
- **歸屬暗示**："很多人和你一樣"、"你並不孤單"
|
||||
- **成長暗示**："每一次嘗試都是進步"、"你在變得更好"
|
||||
|
||||
### 4. 讓使用者成為更好的自己
|
||||
|
||||
最好的 C 端產品不是改變使用者，而是幫助使用者成為他們想成為的自己。
|
||||
|
||||
- 不是"你應該..."，而是"你可以..."
|
||||
- 不是"你必須..."，而是"如果你想要..."
|
||||
- 不是"你還不夠..."，而是"你已經..."
|
||||
|
||||
---
|
||||
|
||||
> 🌟 **記住**：C 端使用者買的不是功能，是感覺；不是工具，是陪伴；不是服務，是理解。
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,544 @@
|
||||
---
|
||||
title: '雙鑽模型：先做對的事，再把事做對'
|
||||
description: '面向零基礎讀者的 Double Diamond 入門文章。理解 Discover、Define、Develop、Deliver 四個階段，避免在問題還沒搞清楚時就急著做原型。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 小時</strong>'
|
||||
</script>
|
||||
|
||||
# 雙鑽模型：先做對的事，再把事做對
|
||||
|
||||
<a id="top-dd"></a>
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['Double Diamond', '設計思維', '需求分析', '方案設計']"
|
||||
coreOutput="1 個更清楚的問題定義和 1 個更合理的驗證切口"
|
||||
expectedOutput="不再一上來就急著畫原型，而是知道先想清楚問題，再比較方案"
|
||||
>
|
||||
|
||||
很多人第一次做產品時，最容易踩的坑不是“不夠努力”，而是太快進入解決方案。
|
||||
|
||||
腦子裡剛冒出一個方向，就開始想頁面怎麼畫、按鈕放哪、要不要接 AI、要不要做登入註冊、原型用什麼工具畫。忙了一圈之後，才發現最根本的問題根本沒想清楚：使用者到底是不是真的有這個痛點？這個問題值不值得現在解決？你以為自己在推進專案，其實只是很努力地在錯誤方向上加速。
|
||||
|
||||
雙鑽模型（Double Diamond）就是用來避免這種情況的。
|
||||
|
||||
它最有價值的提醒是：**“做對的事情”和“把事情做對”，是兩個完全不同的階段。** 如果你還沒搞清楚問題，就急著衝去做原型，通常只會把錯誤方向做得更完整。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完後，你會更清楚做產品時什麼時候該先想問題，什麼時候才該開始想方案和原型，避免一上來就在錯誤方向上做得很認真。
|
||||
|
||||
**行動項**：按 `Discover → Define → Develop → Deliver` 四步往下走，每一步只做當前階段該做的事。
|
||||
|
||||
**結果**：你會得到一個更清楚的問題定義、幾種可比較的方案，以及一個可驗證的最小版本。
|
||||
|
||||
**關鍵詞跳轉**：[雙鑽模型是什麼](#dd-what) · [第一個鑽石](#dd-first) · [AI 怎麼幫你](#dd-ai)
|
||||
:::
|
||||
|
||||
## 你將學到以下內容
|
||||
|
||||
1. 雙鑽模型是什麼，為什麼它適合零基礎做產品時使用
|
||||
2. Discover、Define、Develop、Deliver 四個階段分別在做什麼
|
||||
3. 怎樣區分“現在應該繼續發散”還是“現在應該開始收斂”
|
||||
4. 如何把雙鑽模型用在 AI 產品、原型設計和需求驗證裡
|
||||
|
||||
<a id="dd-what"></a>
|
||||
## [1. 雙鑽模型到底是什麼](#top-dd)
|
||||
|
||||
雙鑽模型是英國 **Design Council** 推廣的一套經典設計流程框架。它把一個完整的設計與創新過程，畫成兩個連續的鑽石形狀。
|
||||
|
||||
之所以是“鑽石”，是因為每個鑽石都包含兩種相反但都很重要的動作：
|
||||
|
||||
- **發散**：先把視野開啟，看更多可能性
|
||||
- **收斂**：再把範圍縮小，做出判斷和取捨
|
||||
|
||||
整個過程一共四步：
|
||||
|
||||
1. **Discover**：廣泛瞭解使用者、問題、環境和市場
|
||||
2. **Define**：從大量資訊裡提煉出真正值得解決的核心問題
|
||||
3. **Develop**：圍繞核心問題發散多種解決方案
|
||||
4. **Deliver**：篩選、原型、測試並交付更合適的方案
|
||||
|
||||
如果把這四步壓縮成一句最容易記住的話，就是：
|
||||
|
||||
- **第一個鑽石**：先搞清楚到底要解決什麼問題
|
||||
- **第二個鑽石**：再決定用什麼方案去解決它
|
||||
|
||||
這也是你剛才說得很準確的那句話：
|
||||
|
||||
- **第一個鑽石：做對的事情**
|
||||
- **第二個鑽石：把事情做對**
|
||||
|
||||
## 2. 為什麼雙鑽模型特別適合新手
|
||||
|
||||
新手做產品最常見的節奏，往往是這樣的：
|
||||
|
||||
- 想到一個點子
|
||||
- 覺得這個方向很酷
|
||||
- 馬上開始畫原型
|
||||
- 做著做著發現功能越來越多
|
||||
- 最後不知道自己到底在解決什麼問題
|
||||
|
||||
雙鑽模型的價值，不在於讓流程變複雜，而在於 **強迫你把“理解問題”和“設計方案”拆開** 。
|
||||
|
||||
這件事聽起來很普通，但實際非常重要。因為很多失敗的產品，不是執行不認真，而是：
|
||||
|
||||
- 選錯了問題
|
||||
- 誤解了使用者
|
||||
- 過早鎖定了解決方案
|
||||
- 把大量時間花在細節打磨上，卻沒有驗證方向
|
||||
|
||||
雙鑽模型就是在不斷提醒你：
|
||||
|
||||
- 不要因為想法順手，就預設問題已經成立
|
||||
- 不要因為方案能做出來，就預設它值得做
|
||||
- 不要因為原型看起來完整，就預設使用者會真的需要
|
||||
|
||||
<a id="dd-first"></a>
|
||||
## [3. 第一個鑽石：做對的事情](#top-dd)
|
||||
|
||||
第一個鑽石關注的是 **問題本身** ，而不是解決方案。
|
||||
|
||||
你可以把它理解成一句話：**先別急著做，先搞清楚到底值不值得做。**
|
||||
|
||||
### 3.1 Discover：先把問題空間開啟
|
||||
|
||||
Discover 階段的核心任務，是 **廣泛調研，而不是快速下結論。**
|
||||
|
||||
這一步通常會做的事情包括：
|
||||
|
||||
- 看使用者在真實場景裡怎麼做
|
||||
- 訪談潛在使用者，瞭解他們最近一次遇到問題是什麼時候
|
||||
- 觀察他們現在怎麼湊合解決
|
||||
- 看競品和替代方案都在怎麼處理
|
||||
- 收集市場、流程、約束、上下游資訊
|
||||
|
||||
很多人會誤以為 Discover 就是“多看點資料”。其實更關鍵的是：**你要理解人和場景，而不只是搜一堆資訊。**
|
||||
|
||||
比如你想做一個“AI 幫忙整理會議紀要”的工具，在 Discover 階段更應該關注的是：
|
||||
|
||||
- 使用者開完會後到底哪裡最痛苦
|
||||
- 是記錄難，還是整理難，還是同步難
|
||||
- 他們現在是自己寫、讓實習生寫、錄音回聽，還是乾脆不整理
|
||||
- 哪些會議場景最需要紀要，哪些根本不需要
|
||||
|
||||
這一步最重要的目標不是得出答案，而是 **別太早以為自己已經知道答案。**
|
||||
|
||||
### 3.2 Define：從一堆資訊裡提煉出核心問題
|
||||
|
||||
如果 Discover 是開啟視野，Define 就是開始收束。
|
||||
|
||||
Define 階段要做的，不是把所有觀察都保留下來，而是問：
|
||||
|
||||
- 真正最值得優先解決的問題是哪一個
|
||||
- 哪個問題最常出現、最痛、最有價值
|
||||
- 我們第一版到底只盯住哪一個場景
|
||||
|
||||
這一步的核心，是把一個寬泛話題，收斂成一個清晰問題定義。
|
||||
|
||||
比如你一開始說：
|
||||
|
||||
> 我想做一個提高開會效率的 AI 工具。
|
||||
|
||||
到了 Define 階段，更好的表達可能會變成：
|
||||
|
||||
> 我們先解決專案型團隊在 30 到 60 分鐘協作會議結束後，無法在 10 分鐘內輸出帶待辦、責任人和截止時間的紀要這個問題。
|
||||
|
||||
這時候問題就開始變清楚了：
|
||||
|
||||
- 使用者是誰
|
||||
- 場景是什麼
|
||||
- 卡點是什麼
|
||||
- 成功標準是什麼
|
||||
|
||||
Define 的本質，就是 **從“問題很多”收斂到“這次先解決哪一個問題”。**
|
||||
|
||||
## 4. 第二個鑽石：把事情做對
|
||||
|
||||
當你完成第一個鑽石後，才真正適合進入第二個鑽石。因為這時你解決的不是一個模糊方向，而是一個被收斂過的具體問題。
|
||||
|
||||
### 4.1 Develop：圍繞核心問題發散方案
|
||||
|
||||
Develop 階段的重點，是 **圍繞同一個問題，探索多種可能方案。**
|
||||
|
||||
注意，這裡的發散和 Discover 階段不一樣。
|
||||
|
||||
- Discover 的發散，是在探索問題空間
|
||||
- Develop 的發散，是在探索解決方案空間
|
||||
|
||||
比如還是會議紀要這個例子，到了 Develop 階段，你可以開始想：
|
||||
|
||||
- 是做網頁工具，還是會議外掛
|
||||
- 是上傳錄音後處理，還是實時記錄
|
||||
- 是隻做摘要，還是重點做待辦提取
|
||||
- 是強調個人效率，還是強調團隊同步
|
||||
- 是給使用者自由編輯，還是直接輸出結構化模板
|
||||
|
||||
這一步很適合腦暴，也很適合和團隊一起把方案拉開。
|
||||
|
||||
但這裡有一個前提：**所有方案都必須服務同一個已定義的問題。**
|
||||
如果問題沒定義清楚，Develop 很容易又重新變成功能亂飛。
|
||||
|
||||
### 4.2 Deliver：選擇方案、做原型、測試和交付
|
||||
|
||||
Deliver 階段是第二個鑽石裡的收斂階段。
|
||||
|
||||
這時你要做的不是繼續想更多，而是開始判斷：
|
||||
|
||||
- 哪個方案最適合當前階段
|
||||
- 哪個版本最小但最有用
|
||||
- 哪些功能必須先做，哪些可以以後再說
|
||||
- 怎麼做原型、測試和小範圍驗證
|
||||
|
||||
很多人以為 Deliver 就等於“上線”。其實它更準確的意思是：**把一個方案變成可測試、可驗證、可迭代的東西。**
|
||||
|
||||
它可能是：
|
||||
|
||||
- 一張低保真流程圖
|
||||
- 一個 Figma 原型
|
||||
- 一個可執行的 MVP
|
||||
- 一次小規模使用者測試
|
||||
- 一輪真實反饋後的迭代版本
|
||||
|
||||
Deliver 的重點不是“完美交付”，而是 **儘快把方案放進真實環境裡驗證。**
|
||||
|
||||
## 5. 一個最容易記住的對照表
|
||||
|
||||
如果你總是分不清四個階段，可以直接記下面這個版本：
|
||||
|
||||
| 階段 | 你在做什麼 | 關鍵詞 | 常見產出 |
|
||||
| --- | --- | --- | --- |
|
||||
| Discover | 理解問題 | 調研、觀察、訪談、收集資訊 | 使用者洞察、場景筆記、問題清單 |
|
||||
| Define | 定義問題 | 提煉、聚焦、取捨、重寫問題 | 問題定義、優先順序、MVP 切口 |
|
||||
| Develop | 探索方案 | 腦暴、比較、共創、原型設想 | 方案列表、流程草圖、原型方向 |
|
||||
| Deliver | 驗證方案 | 原型、測試、迭代、交付 | 原型、測試反饋、最佳化版本 |
|
||||
|
||||
再壓縮一點，就是這樣：
|
||||
|
||||
- **Discover / Define**：解決“做對的事情”
|
||||
- **Develop / Deliver**：解決“把事情做對”
|
||||
|
||||
## 6. 雙鑽模型最常見的誤區
|
||||
|
||||
### 6.1 還沒 Discover，就直接 Deliver
|
||||
|
||||
這是最常見的一種。很多人剛有想法就開畫原型、寫 PRD、接模型、做頁面。
|
||||
|
||||
問題不是你做得不認真，而是你可能根本還沒確認問題值不值得解決。
|
||||
|
||||
### 6.2 Discover 很久，但始終不 Define
|
||||
|
||||
另一種極端是一直調研、一直看資料、一直訪談，卻遲遲不敢收斂。
|
||||
|
||||
雙鑽不是讓你無限發散，而是提醒你：發散之後必須進入判斷和取捨。
|
||||
|
||||
### 6.3 Define 之後，又偷偷改問題
|
||||
|
||||
很多團隊會在 Develop 時因為某個方案更容易做，就反過來修改問題定義，讓它適配現有方案。
|
||||
|
||||
這很危險。因為你可能不是在解決問題，而是在為自己偏愛的方案找理由。
|
||||
|
||||
### 6.4 把 Deliver 誤解成“大而全上線”
|
||||
|
||||
Deliver 不是說必須把完整產品都做完纔算結束。很多時候，一個可以測試的原型、一輪真實使用者試用，已經是很好的 deliver。
|
||||
|
||||
## 7. 在 AI 產品裡，雙鑽模型怎麼用
|
||||
|
||||
AI 產品特別容易掉進“能力先行”的坑裡，因為模型能力看起來太誘人了。你會很想直接去想：
|
||||
|
||||
- 要不要接多模態
|
||||
- 要不要做 Agent
|
||||
- 要不要加工作流
|
||||
- 要不要接語音、影象、聯網搜尋
|
||||
|
||||
但雙鑽模型會逼你先問：
|
||||
|
||||
- 使用者到底在哪個環節真的卡住了
|
||||
- 這個卡點是不是非 AI 不可
|
||||
- 如果不用 AI，現有辦法到底哪裡最差
|
||||
- AI 加進去之後，最核心的進展是什麼
|
||||
|
||||
這能幫你避免一種常見情況：**能力很強，價值很弱。**
|
||||
|
||||
一個實用的順序是：
|
||||
|
||||
1. 在 Discover 階段觀察使用者現在怎麼處理任務
|
||||
2. 在 Define 階段把最痛的一個場景寫成一句清晰的問題定義
|
||||
3. 在 Develop 階段再去比較哪些 AI 能力最適合服務這個問題
|
||||
4. 在 Deliver 階段做一個最小版本，讓真實使用者測試
|
||||
|
||||
## 8. 可以直接套用的雙鑽模板
|
||||
|
||||
如果你正在做自己的產品，可以先按這個順序往下寫：
|
||||
|
||||
### Discover
|
||||
|
||||
- 我觀察到的使用者是誰？
|
||||
- 他們最近一次遇到這個問題是什麼時候？
|
||||
- 他們現在怎麼解決？
|
||||
- 他們最煩、最慢、最不放心的地方是什麼？
|
||||
|
||||
### Define
|
||||
|
||||
- 這堆問題裡，最值得優先解決的是哪一個？
|
||||
- 哪個場景最高頻，或者最關鍵？
|
||||
- 我們第一版先只服務誰、只解決什麼？
|
||||
- 成功解決後，使用者狀態會發生什麼變化？
|
||||
|
||||
### Develop
|
||||
|
||||
- 針對這個問題，有哪些可能方案？
|
||||
- 哪些方案最輕、最快、最容易驗證？
|
||||
- 哪些是必須做，哪些是以後再說？
|
||||
|
||||
### Deliver
|
||||
|
||||
- 我們最小可以交付什麼來驗證這個方向？
|
||||
- 是流程圖、原型，還是 MVP？
|
||||
- 需要找誰測試？
|
||||
- 測試後怎樣判斷要繼續、修改還是放棄？
|
||||
|
||||
## 9. 一個從零基礎也能看懂的例子
|
||||
|
||||
假設你想做一個“幫大學生準備求職簡歷”的 AI 工具。
|
||||
|
||||
很多人一開始就會直接進入第二個鑽石，開始想：
|
||||
|
||||
- 要不要一鍵美化
|
||||
- 要不要智慧改寫
|
||||
- 要不要自動匹配 JD
|
||||
- 要不要生成自我介紹
|
||||
|
||||
但按雙鑽模型，更好的過程會是這樣：
|
||||
|
||||
### 第一個鑽石
|
||||
|
||||
**Discover**
|
||||
|
||||
- 去聊應屆生最近一次改簡歷是什麼時候
|
||||
- 看他們怎麼從舊簡歷改成新版本
|
||||
- 瞭解他們最困擾的是“不會寫”“不會改”，還是“不會判斷好不好”
|
||||
|
||||
**Define**
|
||||
|
||||
- 最後收斂出一個更具體的問題：
|
||||
- 不是“大學生不會做簡歷”
|
||||
- 而是“第一次投遞實習的學生，很難把已有經歷改寫成貼合崗位的表達，因此拖延投遞”
|
||||
|
||||
### 第二個鑽石
|
||||
|
||||
**Develop**
|
||||
|
||||
- 想幾種方案：模板庫、AI 改寫、崗位對照、簡歷評分、案例參考
|
||||
|
||||
**Deliver**
|
||||
|
||||
- 第一版只做“根據崗位描述改寫經歷 bullet points”
|
||||
- 給 5 個學生試用，看他們會不會更快投出第一版簡歷
|
||||
|
||||
你會發現，一旦第一個鑽石做紮實，第二個鑽石會清楚很多。
|
||||
|
||||
## 10. 小結
|
||||
|
||||
雙鑽模型最有力量的地方，是它幫你把一整團混亂拆成了四個更清楚的動作：
|
||||
|
||||
- 先發散理解問題
|
||||
- 再收斂定義問題
|
||||
- 再發散探索方案
|
||||
- 最後收斂交付方案
|
||||
|
||||
它不是讓你變慢，而是讓你 **少走很多看起來很忙、其實方向不對的彎路。**
|
||||
|
||||
尤其在 AI 時代，做東西變得越來越快，雙鑽模型反而更重要。因為當“做出來”越來越容易時，真正稀缺的能力會變成：**你有沒有在解決一個值得解決的問題，以及你有沒有用合適的方式去解決它。**
|
||||
|
||||
記住這一句就夠了：
|
||||
|
||||
**先做對的事情，再把事情做對。**
|
||||
|
||||
<a id="dd-ai"></a>
|
||||
## [11. 如何利用 AI 幫你跑雙鑽流程](#top-dd)
|
||||
|
||||
雙鑽模型本身不是 AI 工具，但 AI 很適合在四個階段裡充當“加速器”。關鍵不是讓 AI 替你決策，而是讓它幫你擴充套件視野、整理資訊、比較方案和生成驗證材料。
|
||||
|
||||
### 11.1 在 Discover 階段，用 AI 先做一輪資訊鋪墊
|
||||
|
||||
在正式訪談和調研前，你可以先讓 AI 幫你做一些輕量級問題掃描，比如：
|
||||
|
||||
- 市面上常見替代方案有哪些
|
||||
- 使用者在公開社羣裡最常抱怨什麼
|
||||
- 這個問題常見於哪些場景和人羣
|
||||
- 現有產品通常忽略了什麼
|
||||
|
||||
這一步不能代替真實調研，但很適合幫你快速搭一個問題地圖。
|
||||
|
||||
一個很簡單的小白輸入可以是：
|
||||
|
||||
```text
|
||||
我想做一個幫大學生改簡歷的工具。
|
||||
你先別幫我想功能，先幫我看看大家在這個問題上最常遇到什麼麻煩。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
初步問題地圖：
|
||||
|
||||
1. 不知道該寫什麼經歷
|
||||
2. 不知道怎麼針對崗位修改
|
||||
3. 改了很多版還是不確定是否夠好
|
||||
4. 需要別人幫看，但不方便總麻煩別人
|
||||
5. 因為不確定，所以一直拖著不投
|
||||
```
|
||||
|
||||
這種輸出的作用不是替你下結論，而是讓你更快進入 Discover。
|
||||
|
||||
### 11.2 在 Define 階段，讓 AI 幫你收斂問題定義
|
||||
|
||||
很多人收集了一堆資料之後，最難的是把問題收成一句真正清楚的話。你可以把調研筆記交給 AI，讓它幫你壓縮成幾個候選問題定義：
|
||||
|
||||
```text
|
||||
下面是我在 Discover 階段收集到的使用者反饋和調研筆記：
|
||||
[貼上內容]
|
||||
|
||||
請你幫我做三件事：
|
||||
1. 歸納最常出現的問題模式
|
||||
2. 按問題頻率、痛感和可驗證性，整理出 3 個值得優先解決的問題
|
||||
3. 把每個問題寫成一句具體的問題定義
|
||||
```
|
||||
|
||||
這樣你會更容易進入 Define，而不是一直停留在“問題好多”的狀態裡。
|
||||
|
||||
你甚至可以把輸入寫得非常簡單：
|
||||
|
||||
```text
|
||||
我現在收集到的問題有：
|
||||
1. 大家不知道簡歷寫什麼
|
||||
2. 大家不知道怎麼改
|
||||
3. 大家總覺得沒改好，不敢投
|
||||
|
||||
你幫我看看，第一版最適合先解決哪個問題。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
建議優先解決的問題：
|
||||
|
||||
“第一次投遞實習的學生，不確定簡歷是否已經達到可投遞水平，因此會反覆修改並拖延投遞。”
|
||||
|
||||
原因：
|
||||
1. 這個問題更具體
|
||||
2. 它能解釋拖延行為
|
||||
3. 更容易設計一個小版本去驗證
|
||||
```
|
||||
|
||||
這類輸出很有用，因為它幫你從一堆模糊問題裡收出一個更像 MVP 起點的定義。
|
||||
|
||||
### 11.3 在 Develop 階段，用 AI 發散多個方案
|
||||
|
||||
很多人一定義完問題，就只盯著腦子裡第一個想到的方案。AI 在這一步很適合幫你強制發散：
|
||||
|
||||
```text
|
||||
我已經定義了一個核心問題：[你的問題定義]
|
||||
請你不要直接給我一個最終答案，而是從以下角度各提出 2-3 種解決方向：
|
||||
1. 最輕量的 MVP
|
||||
2. 最適合驗證需求的方案
|
||||
3. 最適合提高體驗的方案
|
||||
4. 不依賴 AI 的方案
|
||||
5. 依賴 AI 的方案
|
||||
最後請對比每種方案的優點、風險和驗證成本。
|
||||
```
|
||||
|
||||
這樣你就不會太早被單一方案綁住。
|
||||
|
||||
一個簡單輸入可以是：
|
||||
|
||||
```text
|
||||
我現在的問題定義是：
|
||||
“大學生不確定簡歷是否已經可以投，所以一直拖著不投。”
|
||||
|
||||
請你幫我想 4 種不同解決方案，不要只給我一種。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
方案 1：簡歷可投遞檢查清單
|
||||
方案 2：根據崗位描述做針對性改寫
|
||||
方案 3：讓使用者上傳簡歷後給出風險提示
|
||||
方案 4：提供優秀案例對照，幫助使用者判斷差距
|
||||
```
|
||||
|
||||
這時你就更容易進入“比較方案”，而不是一上來只盯著 AI 改寫一個方向。
|
||||
|
||||
### 11.4 在 Deliver 階段，用 AI 幫你生成原型文案和測試材料
|
||||
|
||||
當你進入 Deliver 階段，AI 非常適合幫你加快這些工作：
|
||||
|
||||
- 生成低保真原型裡的頁面文案
|
||||
- 整理使用者測試指令碼
|
||||
- 生成可對比的多個版本標題、按鈕、說明語
|
||||
- 整理測試後的反饋和問題列表
|
||||
|
||||
比如你可以讓 AI 幫你生成一個 20 分鐘使用者測試指令碼，或者幫你把 5 個使用者反饋歸納成“繼續做 / 修改方向 / 暫停”的判斷依據。
|
||||
|
||||
比如一個最小輸入可以是：
|
||||
|
||||
```text
|
||||
我做了一個很簡單的原型：
|
||||
使用者上傳簡歷，系統告訴他哪些地方還不適合投遞。
|
||||
|
||||
請幫我生成一份 15 分鐘的使用者測試指令碼。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
15 分鐘測試指令碼：
|
||||
|
||||
1. 先請使用者描述最近一次投簡歷經歷
|
||||
2. 讓使用者獨立完成上傳簡歷
|
||||
3. 觀察他是否看得懂反饋結果
|
||||
4. 詢問：這些提示裡哪些最有幫助，哪些讓你困惑
|
||||
5. 詢問：如果下次投遞前，你會不會想再用一次
|
||||
```
|
||||
|
||||
這種輸出很實用，因為它能幫你從“我做完原型了”走到“我接下來怎麼測”。
|
||||
|
||||
### 11.5 讓 AI 扮演“階段守門員”
|
||||
|
||||
雙鑽模型最常見的問題，是人會跳階段。你可以直接讓 AI 充當一個守門員，提醒你現在到底在哪一步：
|
||||
|
||||
```text
|
||||
請你扮演產品流程教練。
|
||||
下面是我當前的專案狀態：[你的描述]
|
||||
請你判斷我現在更像處於 Discover、Define、Develop 還是 Deliver。
|
||||
並告訴我：
|
||||
1. 我是不是過早跳到了下一階段
|
||||
2. 當前階段最該補的動作是什麼
|
||||
3. 哪些事情現在先別做
|
||||
```
|
||||
|
||||
這對新手特別有幫助，因為你很容易在“還沒想清楚問題時就開始畫原型”。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
請你根據上文內容，完成下列作業：
|
||||
|
||||
1. 選一個你最近想做的產品點子，寫出它的 Discover、Define、Develop、Deliver 四步草稿
|
||||
2. 在 Define 階段，強迫自己把問題縮成一句具體的話
|
||||
3. 在 Develop 階段，至少列出 3 種不同方案，而不是隻盯著第一個想到的做法
|
||||
4. 在 Deliver 階段，寫出一個一週內能交付的最小驗證版本
|
||||
|
||||
## 延伸閱讀
|
||||
|
||||
這篇文章主要參考了 Design Council 關於 Double Diamond 的官方資料，適合繼續往下看：
|
||||
|
||||
- [Design Council: The Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)
|
||||
- [Design Council: Framework for Innovation](https://www.designcouncil.org.uk/our-work/skills-learning/tools-frameworks/framework-for-innovation-design-councils-evolved-double-diamond/)
|
||||
- [Design Council: History of the Double Diamond](https://www.designcouncil.org.uk/our-resources/the-double-diamond/history-of-the-double-diamond/)
|
||||
@@ -0,0 +1,301 @@
|
||||
---
|
||||
title: '從哪裡找點子：3 種最適合新手的參考來源'
|
||||
description: '面向零基礎讀者的產品點子入門文章。重點整理適合直接刷 idea 的網站、趨勢來源、真實業務來源和 VC 清單，幫助你從連結裡快速找到更具體的方向。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 小時</strong>'
|
||||
</script>
|
||||
|
||||
# 從哪裡找點子：3 種最適合新手的參考來源
|
||||
|
||||
<a id="top-idea-sources"></a>
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['找點子', '產品方向', '需求發現', '行業觀察']"
|
||||
coreOutput="1 個更具體、值得繼續查的產品方向"
|
||||
expectedOutput="知道去哪裡刷、怎麼看、先看什麼，不再只留下“AI + 某行業”這種很空的想法"
|
||||
>
|
||||
|
||||
很多人卡在第一步，不是因為完全沒有靈感，而是因為刷了很多內容以後，腦子裡留下的還是大詞：
|
||||
|
||||
- AI for education
|
||||
- AI for healthcare
|
||||
- AI for finance
|
||||
- AI agent for business
|
||||
|
||||
這些都還不是點子。它們只是在告訴你“方向很大”，沒有告訴你：
|
||||
|
||||
- 誰在用
|
||||
- 在什麼場景下用
|
||||
- 現在怎麼湊合做
|
||||
- 哪一步最值得先切
|
||||
|
||||
這篇文章不講空的方法論，直接整理一批更好用的來源給你。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完後，你會知道沒想法的時候，先去哪裡刷，哪些連結適合看“具體需求”，哪些適合看“趨勢”，哪些適合看“真實業務”。
|
||||
|
||||
**行動項**：先刷一輪 idea 列表，再看一輪賺錢小產品，再看趨勢和更業務的來源，最後留下 1 個你願意繼續查的方向。
|
||||
|
||||
**結果**：你會得到 1 個更具體、值得繼續驗證的方向，而不是停在大詞。
|
||||
|
||||
**關鍵詞跳轉**：[參考應用清單](#idea-apps) · [趨勢來源](#idea-trends) · [更業務的來源](#idea-business) · [VC / 加速器來源](#idea-vc) · [最短路徑](#idea-path) · [AI 怎麼幫你](#idea-ai)
|
||||
:::
|
||||
|
||||
## 你將學到以下內容
|
||||
|
||||
1. 哪些網站適合直接刷 idea
|
||||
2. 哪些網站適合看已經賺錢的小產品
|
||||
3. 哪些來源適合看趨勢和行業變化
|
||||
4. 哪些來源更接近真實業務和真實付費
|
||||
5. 一條適合零基礎的最短使用路徑
|
||||
|
||||
<a id="idea-apps"></a>
|
||||
## [1. 參考應用清單：先看別人已經在做什麼](#top-idea-sources)
|
||||
|
||||
這是最適合新手的起點，因為最具體。
|
||||
|
||||
### 第一梯隊：開啟就是 idea 列表，直接挑
|
||||
|
||||
- [Reddit — r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
這個 subreddit 的核心用途就是：真實使用者直接發“我希望有人做一個 XX”。每條帖子通常就是一個具體產品需求，還會帶一點場景描述。進去後按 `Top -> Past Month` 或 `Top -> Past Year` 排序，20 分鐘就能掃到一批真實需求。
|
||||
- [Reddit — r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
|
||||
和上面類似，但更偏軟體 / App。帖子常見格式就是“我需要一個能做 XX 的應用”，顆粒度更小，很多都是小而美的 niche。
|
||||
- [Reddit — r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
|
||||
比前兩個更完整。很多帖子不只是一句話需求，還會帶一點市場分析、商業模式和為什麼現在值得做。
|
||||
- [Unvalidated Ideas](https://unvalidatedideas.com/)
|
||||
每週釋出未經驗證的創業 idea，常見欄位包括目標使用者、變現方式、初步驗證思路。格式統一，適合快速掃。
|
||||
- [IdeasAI](https://ideasai.com/)
|
||||
用 AI 生成創業 idea，可以一直刷。質量不穩定，但很適合在“完全沒感覺”的時候拿來刺激靈感，再自己往細分場景下鑽。
|
||||
|
||||
### 第二梯隊：看別人已經在做的賺錢小產品，反推 idea
|
||||
|
||||
這類平臺的邏輯是：別人已經驗證了需求，甚至已經在賺錢。你看它們，不是為了照搬，而是為了看“什麼小問題已經有人付費”。
|
||||
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
收錄了很多真實小生意案例，通常有創始人訪談、收入資料、起步過程。重點看月收入 1 萬到 10 萬美元的小產品，通常更 niche，也更接近普通人能理解的產品規模。
|
||||
- [Indie Hackers — Products](https://www.indiehackers.com/products)
|
||||
獨立開發者展示產品的地方，很多會公開收入和增長。按收入排序，看那些月入幾千到幾萬美元的產品都在解決什麼具體問題。
|
||||
- [MicroConf Blog](https://microconf.com/blog)
|
||||
偏 Micro SaaS。適合看“足夠小、但有人願意付錢”的產品切口。
|
||||
- [1000 Tools](https://1000.tools/)
|
||||
AI 工具聚合站。適合看哪些品類已經有人做、但做得一般，或者哪些方向在國內 / 某垂直行業裡還沒被很好覆蓋。
|
||||
- [Product Hunt](https://www.producthunt.com/)
|
||||
看最近反覆出現的產品型別，不要只盯榜一，重點看哪些品類持續有人做但還沒有明顯贏家。
|
||||
- [BetaList](https://betalist.com/)
|
||||
適合看早期產品和還在試方向的團隊。
|
||||
|
||||
### 看產品時，不要只看產品本身，也看差評和“代做服務”
|
||||
|
||||
- [G2](https://www.g2.com/)
|
||||
用法：看 1 星、2 星評價。差評裡通常藏著“現有產品哪一步沒做好”。
|
||||
- [Capterra](https://www.capterra.com/)
|
||||
用法：和 G2 類似，適合看 SaaS 類產品的真實抱怨。
|
||||
- 淘寶 / 閒魚 / [Fiverr](https://www.fiverr.com/) / [Upwork](https://www.upwork.com/) / 豬八戒
|
||||
用法：搜“代做”“代整理”“代填”“代錄入”“代轉寫”。如果某種人工服務賣得好，背後通常就有一個可重複、可產品化的流程。
|
||||
|
||||
判斷訊號很簡單：
|
||||
|
||||
- 使用者已經在抱怨現有工具
|
||||
- 使用者已經在花錢找人代做
|
||||
- 使用者已經為這個流程投入很多人工和時間
|
||||
|
||||
### 第四梯隊：看影片，有人直接幫你拆解 idea
|
||||
|
||||
如果你不喜歡刷論壇、刷榜單，更喜歡“有人幫我拆思路”，那影片和播客也很適合。
|
||||
|
||||
- 搜尋 `Greg Isenberg startup ideas`
|
||||
適合看有人直接拆 2 到 3 個具體 idea，順帶講市場規模、競爭分析和切入點。
|
||||
- 搜尋 `My First Million podcast`
|
||||
兩個主持人經常整期頭腦風暴商業 idea，密度高，經常會冒出很具體的 niche。
|
||||
- 搜尋 `YC startup ideas` 或 `Michael Seibel startup ideas`
|
||||
適合初學者，內容直白，很多會直接講如何選方向。
|
||||
|
||||
<a id="idea-trends"></a>
|
||||
## [2. 趨勢來源：看哪些方向正在起來](#top-idea-sources)
|
||||
|
||||
趨勢站點的作用不是直接給你點子，而是幫你判斷：某個方向是不是在升溫，值不值得繼續看。
|
||||
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
用資料追蹤增長很快、但還沒進入主流視野的話題和產品品類。適合看“正在起來但還沒特別擁擠”的方向。
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
搜關鍵詞，看過去一年的趨勢線，再看“相關查詢”裡的“飆升”詞。
|
||||
- [Glimpse](https://meetglimpse.com/)
|
||||
和 Google Trends 類似，
|
||||
- 行業研究報告摘要頁
|
||||
適合你已經有方向，想快速看這個方向在行業裡的位置。
|
||||
- McKinsey / BCG / Gartner 的趨勢內容
|
||||
更偏企業和大行業視角，適合 B 端、工業、傳統行業。
|
||||
- [State of AI Report](https://www.stateof.ai/)
|
||||
如果你的方向和 AI 技術本身相關，這類年度報告很適合建立大局觀。
|
||||
|
||||
看趨勢時重點只看三件事：
|
||||
|
||||
- 這個詞是不是持續升溫
|
||||
- 它落在哪個具體場景裡
|
||||
- 誰會最早為它付出時間、切換成本或預算
|
||||
|
||||
<a id="idea-business"></a>
|
||||
## [3. 更業務的來源：看誰在花錢、誰在抱怨、誰在賣人工服務](#top-idea-sources)
|
||||
|
||||
如果你想找的不是“聽起來很酷”的方向，而是“更接近真實業務”的方向，就要看離工作流更近的來源。
|
||||
|
||||
### 看誰在真實花錢買什麼
|
||||
|
||||
- [中國政府採購網](https://www.ccgp.gov.cn/)
|
||||
用法：搜“智慧工地”“實驗室管理系統”“資料採集”“診所管理”“報價系統”這類詞，看預算、技術要求、使用場景。
|
||||
- 各省市公共資源交易中心
|
||||
用法：看地方政府和國企到底在採買什麼系統。
|
||||
- 比標網 / 千里馬招標網 / 標事通
|
||||
用法：看企業側的採購需求和高頻系統型別。
|
||||
|
||||
這些來源的強訊號是：不是在討論未來，而是在暴露“今天已經有人願意為這件事花錢”。
|
||||
|
||||
### 看誰在真實抱怨什麼
|
||||
|
||||
- 製造業：機械社羣、工控論壇
|
||||
- 醫療：丁香園、醫脈通
|
||||
- 建築 / 工程：土木線上、廣聯達社羣
|
||||
- 財務 / 會計：中國會計視野論壇
|
||||
- 外貿：福步外貿論壇、米課圈
|
||||
- 餐飲 / 零售：職業餐飲網、聯商網論壇
|
||||
- [Reddit](https://www.reddit.com/) 的垂直板塊：`r/smallbusiness`、`r/Entrepreneur`、`r/SaaS`、`r/healthcare`、`r/manufacturing`
|
||||
- [V2EX](https://www.v2ex.com/)
|
||||
- 即刻
|
||||
- 小紅書
|
||||
|
||||
搜尋時不要只搜“AI”“創新”，更有效的是搜：
|
||||
|
||||
- 太麻煩了
|
||||
- 有沒有更好的辦法
|
||||
- 求推薦工具
|
||||
- Excel 管不過來了
|
||||
- I wish there was
|
||||
- is there a tool for
|
||||
- I hate
|
||||
|
||||
### 看誰在賣重複性人工服務
|
||||
|
||||
- [Fiverr](https://www.fiverr.com/)
|
||||
- [Upwork](https://www.upwork.com/)
|
||||
- 豬八戒網
|
||||
- 淘寶
|
||||
- 閒魚
|
||||
|
||||
如果你看到這些服務賣得不錯，就值得繼續查：
|
||||
|
||||
- 幫你把 PDF 報價單整理成 Excel
|
||||
- 幫你批次整理客戶資料
|
||||
- 幫你改簡歷 / 改文案 / 做轉寫 / 做歸檔
|
||||
|
||||
這類服務背後通常不是一次性需求，而是重複發生的工作流。
|
||||
|
||||
### 看完整工作流，而不是隻看 idea 清單
|
||||
|
||||
有時最直接的方法就是挑一個行業，把流程看一遍，找還在靠微信、Excel、紙筆、電話完成的步驟。
|
||||
|
||||
- 外貿：找供應商、詢價、比價、做報價單、發給客戶、跟進回覆、安排驗貨、訂艙、報關。
|
||||
值得看的切口：供應商報價整理成客戶報價單。
|
||||
- 口腔診所：接診、拍片、看片、溝通方案、跟進、治療、複診。
|
||||
值得看的切口：給患者解釋方案並持續跟進。
|
||||
- 建築工地：巡檢、拍照、發羣、整理報告、交給甲方。
|
||||
值得看的切口：從現場照片到合規報告。
|
||||
|
||||
<a id="idea-vc"></a>
|
||||
## [4. VC / 加速器來源：看“浪往哪邊打”](#top-idea-sources)
|
||||
|
||||
這一類來源適合幫你找大方向，不適合直接替代驗證。
|
||||
|
||||
- [Y Combinator — Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
用法：適合找切口，因為它經常會直接說“我們想看到有人做這個”。
|
||||
- [a16z — Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
用法：更偏大趨勢和賽道判斷，適合建立行業感覺。
|
||||
- [NFX](https://www.nfx.com/)
|
||||
用法：適合快速掃一組創業題目。
|
||||
- [Sequoia Capital](https://www.sequoiacap.com/article/)
|
||||
用法：不一定直接列點子，但常會講某類平臺變遷和機會。
|
||||
- [First Round Review](https://review.firstround.com/)
|
||||
用法：適合深挖某個方向，不一定是點子清單，但文章質量通常很高。
|
||||
|
||||
這類來源的優點：
|
||||
|
||||
- 能告訴你未來什麼方向值得看
|
||||
- 能告訴你哪些賽道可能會持續被推動
|
||||
- 能讓你快速進入某個賽道的語境
|
||||
|
||||
這類來源的限制：
|
||||
|
||||
- 通常是投資人視角
|
||||
- 不一定告訴你具體哪個角色最痛
|
||||
- 不一定告訴你哪一步流程最卡
|
||||
- 不一定告訴你今天誰已經在為此付錢
|
||||
|
||||
所以更好的用法是：先用它們找方向，再回到參考產品、行業論壇、採購資訊和真實工作流裡找更具體的切口。
|
||||
|
||||
<a id="idea-path"></a>
|
||||
## [5. 最適合“沒想法只知道做助手的人”的最短使用路徑](#top-idea-sources)
|
||||
|
||||
如果只走一條最短路徑，可以這樣：
|
||||
|
||||
1. 第一步，30 分鐘。
|
||||
開啟 [r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)，按 `Top -> Past Year` 排序，快速掃 50 條帖子，把所有你覺得“這個我好像能做”的方向先存下來。
|
||||
2. 第二步，30 分鐘。
|
||||
開啟 [Starter Story](https://www.starterstory.com/) 或 [Indie Hackers Products](https://www.indiehackers.com/products)，按收入排序，看中等收入的產品，不要只看最成功的。找到和第一步相關的方向，看它們具體賣給誰、解決哪一步。
|
||||
3. 第三步，20 分鐘。
|
||||
去 [Google Trends](https://trends.google.com/) 搜相關關鍵詞，看趨勢是不是在增長，再看“相關查詢”的飆升詞。
|
||||
4. 第四步，20 分鐘。
|
||||
去 G2 / Capterra / 行業論壇 / 招標平臺 / Fiverr 這類地方，看這個方向今天到底哪裡最煩、哪裡還在靠人工。
|
||||
|
||||
看完之後，能說清楚下面這句話就夠了：
|
||||
|
||||
- 某類人，在某個場景裡，被某一步流程卡住，現在主要靠某種笨辦法硬撐。
|
||||
|
||||
<a id="idea-ai"></a>
|
||||
## [6. AI 怎麼幫你](#top-idea-sources)
|
||||
|
||||
這篇的重點不是 AI，但 AI 很適合做整理。
|
||||
|
||||
最實用的用法只有兩個：
|
||||
|
||||
- 把你刷到的連結、帖子標題、使用者原話貼給 AI，讓它幫你歸類成“人羣 / 場景 / 痛點 / 替代方案”。
|
||||
- 讓 AI 幫你把一堆散亂資訊收成 3 個候選方向，而不是繼續發散 50 個功能。
|
||||
|
||||
可以直接這樣問：
|
||||
|
||||
```text
|
||||
我最近刷到這些來源：
|
||||
1. [貼標題或原話]
|
||||
2. [貼標題或原話]
|
||||
3. [貼標題或原話]
|
||||
|
||||
請不要給我功能列表。
|
||||
請只做三件事：
|
||||
1. 按人羣和場景分類
|
||||
2. 找出反覆出現的麻煩步驟
|
||||
3. 幫我整理成 3 個更具體的候選方向
|
||||
```
|
||||
|
||||
## 延伸閱讀
|
||||
|
||||
- [Y Combinator - Requests for Startups](https://www.ycombinator.com/rfs)
|
||||
- [a16z - Big Ideas](https://a16z.com/big-ideas-2025/)
|
||||
- [NFX](https://www.nfx.com/)
|
||||
- [Reddit - r/SomebodyMakeThis](https://www.reddit.com/r/SomebodyMakeThis/)
|
||||
- [Reddit - r/AppIdeas](https://www.reddit.com/r/AppIdeas/)
|
||||
- [Reddit - r/Startup_Ideas](https://www.reddit.com/r/Startup_Ideas/)
|
||||
- [Starter Story](https://www.starterstory.com/)
|
||||
- [Indie Hackers - Products](https://www.indiehackers.com/products)
|
||||
- [Product Hunt](https://www.producthunt.com/)
|
||||
- [BetaList](https://betalist.com/)
|
||||
- [IdeasAI](https://ideasai.com/)
|
||||
- [Unvalidated Ideas](https://unvalidatedideas.com/)
|
||||
- [Google Trends](https://trends.google.com/)
|
||||
- [Exploding Topics](https://explodingtopics.com/)
|
||||
- [G2](https://www.g2.com/)
|
||||
- [Capterra](https://www.capterra.com/)
|
||||
@@ -0,0 +1,765 @@
|
||||
---
|
||||
title: 'B 端產業應用場景方向參考'
|
||||
description: '本文件彙總了 LLM 大模型在 B 端企業場景中的落地應用，包括工業製造業、智慧客服、教育行業、智慧程式設計、醫療方向、網路安全、金融管理、企業服務等領域的具體應用方向，為面向企業客戶的 AI 應用開發者提供參考。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { computed, ref } from 'vue'
|
||||
|
||||
const duration = '約 <strong>6 小時</strong>'
|
||||
|
||||
const interestPoint = ref('')
|
||||
const purpose = ref('')
|
||||
|
||||
// 每個行業的主題池
|
||||
const topicPool = {
|
||||
'manufacturing': [
|
||||
{ title: '新能源客車外觀 AI 輔助設計平臺', desc: '基於圖片生成模型進行外觀概念設計' },
|
||||
{ title: '智慧圖紙設計與審查助手', desc: '利用 RAG 技術構建企業設計規範知識庫' },
|
||||
{ title: '技術文件自動生成與管理', desc: '基於 LLM 自動生成產品規格書和操作手冊' },
|
||||
{ title: '生產裝置巡檢報告自動生成助手', desc: '語音描述裝置狀態，結構化生成巡檢報告' },
|
||||
{ title: '工業裝置故障診斷知識問答助手', desc: '基於歷史故障案例構建向量知識庫' }
|
||||
],
|
||||
'customer-service': [
|
||||
{ title: '多渠道智慧客服自動回覆與工單生成系統', desc: '接入多渠道訊息，LLM 理解意圖後生成回覆' },
|
||||
{ title: '潛在客戶挖掘與跟進建議助手', desc: '分析歷史對話記錄，識別高意向客戶' },
|
||||
{ title: '企業內部知識智慧檢索與問答管家', desc: '基於內部文件構建向量知識庫' },
|
||||
{ title: '客服對話智慧小結與工單生成工具', desc: '自動生成會話小結並提取關鍵資訊' },
|
||||
{ title: '客服金牌話術推薦知識庫系統', desc: '分析優秀案例，提煉金牌話術模板' }
|
||||
],
|
||||
'education': [
|
||||
{ title: '個性化語言學習路徑規劃與智慧導學系統', desc: '評估學習者水平，規劃每日學習任務' },
|
||||
{ title: '教案自動化編寫與教學資源推送平臺', desc: '根據課程大綱生成教案框架' },
|
||||
{ title: '作業自動化批閱與學情診斷分析系統', desc: '自動批改主觀題並生成批改建議' },
|
||||
{ title: '人才崗位勝任力模型構建與學習地圖', desc: '分析崗位 JD 提取能力要求' },
|
||||
{ title: '外語口語一對一情景化實戰演練', desc: 'LLM 扮演不同角色進行口語對話' }
|
||||
],
|
||||
'programming': [
|
||||
{ title: '智慧程式碼補全與 Bug 自動修復助手', desc: 'IDE 外掛實時提供程式碼補全建議' },
|
||||
{ title: '低程式碼應用構建與流程自動化平臺', desc: '自然語言描述需求，轉換為低程式碼配置' },
|
||||
{ title: '單元測試用例生成系統', desc: 'AST 解析原始碼，生成邊界條件測試用例' },
|
||||
{ title: '程式碼智慧分析與語言遷移工具', desc: '分析程式碼質量並提供最佳化建議' },
|
||||
{ title: '前端介面（UI）程式碼自動生成工具', desc: '設計稿圖片識別，生成響應式 CSS' }
|
||||
],
|
||||
'healthcare': [
|
||||
{ title: '醫學檢驗報告智慧解讀助手', desc: 'OCR 識別關鍵指標，解讀異常值' },
|
||||
{ title: '基於知識檢索技術的健康諮詢專家', desc: '構建醫學知識圖譜，RAG 檢索生成回答' },
|
||||
{ title: '臨床科研資料決策分析平臺', desc: '整合 EMR 資料，輔助生成統計分析程式碼' },
|
||||
{ title: '醫學影像報告自動生成工具', desc: '描述影像特徵，自動生成結構化報告' },
|
||||
{ title: '慢病管理用藥提醒智慧助手', desc: '生成個性化用藥提醒，支援用藥禁忌檢查' }
|
||||
],
|
||||
'security': [
|
||||
{ title: '程式碼安全漏洞檢測與修復引擎', desc: 'SAST 掃描程式碼，分析漏洞原理' },
|
||||
{ title: 'AI 生成式釣魚郵件智慧識別與攔截系統', desc: '分析郵件內容，識別 AI 生成的釣魚郵件' },
|
||||
{ title: '安全運營日報自動生成助手', desc: '日誌彙總，自動提取關鍵事件' },
|
||||
{ title: '滲透測試報告智慧生成助手', desc: '根據漏洞描述自動生成報告' },
|
||||
{ title: '威脅情報智慧查詢與分析助手', desc: '對接多源威脅情報，解讀情報內容' }
|
||||
],
|
||||
'finance': [
|
||||
{ title: '信貸盡調報告智慧生成助手', desc: '輸入財務資料，自動生成信貸盡調報告' },
|
||||
{ title: '私人銀行財富管理智慧顧問', desc: '分析客戶風險偏好，生成資產配置建議' },
|
||||
{ title: 'IPO 招股書智慧生成與合規校驗助手', desc: '模組化模板，自動填充業務描述' },
|
||||
{ title: '企業財務報告自動生成與經營異常預警系統', desc: '自動生成財務分析和管理層討論' },
|
||||
{ title: '保險代理人智慧話術陪練', desc: '模擬對話，評估話術合規性和說服力' }
|
||||
],
|
||||
'enterprise': [
|
||||
{ title: '企業合同全生命週期合規性審查與修改建議平臺', desc: '條款比對法規庫，生成合規性審查報告' },
|
||||
{ title: '銷售會話語音轉寫與話術推薦', desc: 'ASR 轉寫，分析會話並推薦金牌話術' },
|
||||
{ title: '營銷內容智慧生成與設計系統', desc: '生成營銷文案和賣點提煉' },
|
||||
{ title: '競品廣告投放分析平臺', desc: '採集競品廣告，分析投放策略' },
|
||||
{ title: '全網熱點選題智慧分析與內容推薦系統', desc: '分析熱點趨勢並推薦選題角度' }
|
||||
],
|
||||
'content': [
|
||||
{ title: '影視與小說內容創作輔助平臺', desc: '提供故事大綱、角色設定、對白生成' },
|
||||
{ title: '企業品牌故事與公關軟文智慧撰寫助手', desc: '輸入品牌關鍵詞，生成多風格文案' },
|
||||
{ title: '虛擬數字人直播互動與推流管理系統', desc: '數字人形象 + TTS 語音 + LLM 對話' },
|
||||
{ title: '短影片指令碼生成與智慧剪輯', desc: '生成短影片指令碼和分鏡' },
|
||||
{ title: '營銷內容智慧生成與設計系統', desc: '生成營銷文案和賣點提煉' }
|
||||
],
|
||||
'government': [
|
||||
{ title: '12345 政務熱線智慧語音導航與自動分派系統', desc: '語音識別，理解訴求並智慧分派' },
|
||||
{ title: '政務服務大廳智慧導辦與政策問答機器人', desc: '政務知識庫 RAG 檢索' },
|
||||
{ title: '惠企政策智慧匹配與精準推送平臺', desc: '企業畫像自動匹配適用政策' },
|
||||
{ title: '行政審批材料智慧預審與合規校驗助手', desc: 'OCR 識別和關鍵資訊提取' },
|
||||
{ title: '城市網格化事件智慧識別與排程管理平臺', desc: '識別事件型別並分派' }
|
||||
],
|
||||
'legal': [
|
||||
{ title: '合同風險漏洞一鍵"找茬"Agent', desc: '對照風險清單識別潛在問題' },
|
||||
{ title: '類似案件勝訴率 AI 智慧評估顧問', desc: '案件特徵提取，類案檢索匹配' },
|
||||
{ title: '法律法規變更實時監測與業務影響分析雷達', desc: '解析變更內容並評估業務影響' },
|
||||
{ title: '律師函 AIGC 自動起草工具', desc: '事實陳述輸入，生成規範律師函' },
|
||||
{ title: '複雜法律條款"翻譯"為大白話的解釋外掛', desc: '生成通俗易懂的解釋' }
|
||||
],
|
||||
'travel': [
|
||||
{ title: '基於 AIGC 的懶人路書生成器', desc: '生成每日行程安排' },
|
||||
{ title: '全網機票酒店價格趨勢預測與低價自動鎖定機器人', desc: 'ML 模型預測價格趨勢' },
|
||||
{ title: '簽證材料智慧預審與自動化填表輔助系統', desc: 'OCR 識別資訊完整性檢查' },
|
||||
{ title: '出境遊實時語音翻譯與選單視覺漢化管家', desc: '離線語音翻譯，選單圖片 OCR' },
|
||||
{ title: '旅行足跡自動生成精美遊記與社交文案助手', desc: '照片資訊提取，生成遊記文案' }
|
||||
],
|
||||
'emotion': [
|
||||
{ title: '基於 LLM 大模型的 24 小時深度陪伴虛擬伴侶', desc: '記憶系統儲存對話歷史' },
|
||||
{ title: '多模態情感識別與心理疏導 AI 顧問', desc: '語音語調分析 + 文字情感識別' },
|
||||
{ title: '阿爾茨海默症老人 AI 認知訓練與記憶喚醒數字人', desc: '認知遊戲訓練，老照片觸發記憶' },
|
||||
{ title: '社恐人士的 AIGC 模擬社交演練教練', desc: '虛擬社交場景模擬' },
|
||||
{ title: '全天候心情監測與 AI 正向情緒激勵助手', desc: '分析心情趨勢並生成激勵內容' }
|
||||
],
|
||||
'entertainment': [
|
||||
{ title: '基於 LLM 驅動的開放世界遊戲 NPC 自主決策引擎', desc: 'NPC 行為樹融合 LLM 決策' },
|
||||
{ title: '沉浸式劇本殺 AIGC 劇情推演與 DM 控場輔助工具', desc: '玩家選擇觸發劇情分支' },
|
||||
{ title: '互動小說結局生成式修改器', desc: '讀者選擇影響劇情走向' },
|
||||
{ title: '電競戰局 CV 視覺分析與 AI 智慧解說員', desc: '遊戲畫面實時分析' },
|
||||
{ title: '多角色 TTS 語音合成有聲書自動生成系統', desc: '文字角色分配，個性化音色生成' }
|
||||
],
|
||||
'ecommerce': [
|
||||
{ title: '高轉化率 AIGC 商品詳情頁批次生產工具', desc: '生成賣點文案和場景描述' },
|
||||
{ title: '服裝虛擬模特 AI 智慧試穿與展示影片生成工廠', desc: '虛擬模特試穿效果生成' },
|
||||
{ title: '跨境電商多語言 LLM 本地化翻譯與潤色助手', desc: '商品描述多語言翻譯' },
|
||||
{ title: '24 小時全天候 AIGC 數字人直播帶貨系統', desc: '數字人形象 + 實時話術生成' },
|
||||
{ title: '市場流行趨勢 AI 洞察與爆款預測引擎', desc: '洞察趨勢熱點，選品建議' }
|
||||
],
|
||||
'energy': [
|
||||
{ title: '家庭用電行為 AI 分析與節能策略顧問', desc: '用電模式分析，生成節能建議' },
|
||||
{ title: '光伏元件缺陷無人機 CV 視覺識別系統', desc: '無人機巡檢拍攝，熱紅外影象分析' },
|
||||
{ title: '電力現貨交易價格 AI 趨勢預測與自動獲利策略 Agent', desc: '價格預測模型，策略生成' },
|
||||
{ title: '企業全鏈路碳排放 AI 自動核算與 ESG 報告生成助手', desc: '碳排放因子計算，ESG 報告生成' },
|
||||
{ title: '電網極端天氣負荷 AI 預測與應急排程指揮系統', desc: '負荷預測模型，排程策略生成' }
|
||||
],
|
||||
'av-media': [
|
||||
{ title: '長影片精彩片段 AI 識別與短影片自動剪輯工具', desc: '影片內容分析，關鍵幀識別' },
|
||||
{ title: '影片背景噪音 AI 智慧分離與人聲增強助手', desc: '音訊分離模型，去除背景噪音' },
|
||||
{ title: '老舊影像 4K 超分修復與 AI 智慧上色工作臺', desc: '影片超解析度模型，AI 自動上色' },
|
||||
{ title: '文字轉真人級 TTS 配音與情感控制系統', desc: '多音色 TTS 模型，情感控制' },
|
||||
{ title: '會議錄音 AI 智慧轉寫與核心待辦提取助手', desc: '多人會議語音分離轉寫' }
|
||||
],
|
||||
'ai-marketing': [
|
||||
{ title: '小紅書爆款文案 AIGC 自動撰寫引擎', desc: '生成種草文案，emoji 最佳化' },
|
||||
{ title: '營銷海報 AI 智慧排版與多尺寸適配工具', desc: '海報模板智慧匹配' },
|
||||
{ title: '品牌 LOGO 創意 AIGC 生成與 VI 體系構建平臺', desc: 'LOGO 創意生成，VI 規範生成' },
|
||||
{ title: '全網熱點 AI 追蹤與借勢營銷創意生成助手', desc: '分析營銷角度，創意方案生成' },
|
||||
{ title: '短影片指令碼創意 AIGC 生成與分鏡指導助手', desc: '指令碼和分鏡生成，拍攝建議' }
|
||||
],
|
||||
'data-intelligence': [
|
||||
{ title: '自然語言轉 SQL 語句自動生成工具', desc: '自然語言查詢轉換為 SQL' },
|
||||
{ title: '企業資料資產目錄智慧盤點與分類系統', desc: '後設資料採集，自動分類' },
|
||||
{ title: '資料質量異常自動檢測與修復建議引擎', desc: '規則引擎 + ML 模型檢測異常' },
|
||||
{ title: '智慧報表生成與視覺化配置助手', desc: '對話式生成報表配置' },
|
||||
{ title: '資料指標口徑智慧問答助手', desc: '基於指標定義文件構建知識庫' }
|
||||
]
|
||||
}
|
||||
|
||||
// 預定義的推薦鏈路對映表
|
||||
const recommendationMap = {
|
||||
// 興趣點: 創意內容
|
||||
'creative-content': {
|
||||
'increase-efficiency': ['content', 'av-media', 'ai-marketing', 'entertainment'],
|
||||
'reduce-cost': ['content', 'ecommerce', 'ai-marketing'],
|
||||
'improve-experience': ['entertainment', 'emotion', 'travel', 'content'],
|
||||
'innovate-business': ['ai-marketing', 'content', 'av-media', 'entertainment']
|
||||
},
|
||||
// 興趣點: 技術服務
|
||||
'tech-service': {
|
||||
'increase-efficiency': ['programming', 'enterprise', 'data-intelligence', 'customer-service'],
|
||||
'reduce-cost': ['programming', 'enterprise', 'manufacturing'],
|
||||
'improve-experience': ['customer-service', 'enterprise', 'programming'],
|
||||
'innovate-business': ['data-intelligence', 'programming', 'security', 'enterprise']
|
||||
},
|
||||
// 興趣點: 資料智慧
|
||||
'data-intel': {
|
||||
'increase-efficiency': ['data-intelligence', 'finance', 'enterprise', 'manufacturing'],
|
||||
'reduce-cost': ['data-intelligence', 'manufacturing', 'energy'],
|
||||
'improve-experience': ['data-intelligence', 'customer-service', 'ecommerce'],
|
||||
'innovate-business': ['data-intelligence', 'finance', 'security', 'ai-marketing']
|
||||
},
|
||||
// 興趣點: 使用者服務
|
||||
'user-service': {
|
||||
'increase-efficiency': ['customer-service', 'ecommerce', 'travel', 'enterprise'],
|
||||
'reduce-cost': ['customer-service', 'ecommerce', 'enterprise'],
|
||||
'improve-experience': ['customer-service', 'emotion', 'travel', 'ecommerce', 'entertainment'],
|
||||
'innovate-business': ['ecommerce', 'travel', 'emotion', 'entertainment']
|
||||
},
|
||||
// 興趣點: 行業解決方案
|
||||
'industry-solution': {
|
||||
'increase-efficiency': ['manufacturing', 'healthcare', 'finance', 'government'],
|
||||
'reduce-cost': ['manufacturing', 'energy', 'enterprise', 'finance'],
|
||||
'improve-experience': ['healthcare', 'education', 'government', 'travel'],
|
||||
'innovate-business': ['finance', 'security', 'legal', 'healthcare', 'government']
|
||||
}
|
||||
}
|
||||
|
||||
const interestOptions = [
|
||||
{ label: '創意內容生成', value: 'creative-content', desc: '文案、圖片、影片等創意內容' },
|
||||
{ label: '技術服務工具', value: 'tech-service', desc: '開發工具、自動化、程式碼輔助' },
|
||||
{ label: '資料智慧分析', value: 'data-intel', desc: '資料分析、預測、智慧決策' },
|
||||
{ label: '使用者服務體驗', value: 'user-service', desc: '客服、營銷、使用者體驗' },
|
||||
{ label: '行業解決方案', value: 'industry-solution', desc: '特定行業的深度應用' }
|
||||
]
|
||||
|
||||
const purposeOptions = [
|
||||
{ label: '提升效率', value: 'increase-efficiency', desc: '自動化、加速流程' },
|
||||
{ label: '降低成本', value: 'reduce-cost', desc: '減少人力、最佳化資源' },
|
||||
{ label: '改善體驗', value: 'improve-experience', desc: '使用者滿意度、服務質量' },
|
||||
{ label: '業務創新', value: 'innovate-business', desc: '新產品、新模式' }
|
||||
]
|
||||
|
||||
const industries = [
|
||||
{ key: 'manufacturing', name: '工業製造業', anchor: '#_1-工業製造業' },
|
||||
{ key: 'customer-service', name: '智慧客服', anchor: '#_2-智慧客服' },
|
||||
{ key: 'education', name: '教育行業', anchor: '#_3-教育行業' },
|
||||
{ key: 'programming', name: '智慧程式設計', anchor: '#_4-智慧程式設計' },
|
||||
{ key: 'healthcare', name: '醫療方向', anchor: '#_5-醫療方向' },
|
||||
{ key: 'security', name: '網路安全', anchor: '#_6-網路安全' },
|
||||
{ key: 'finance', name: '金融管理、保險銀行業', anchor: '#_7-金融管理、保險銀行業' },
|
||||
{ key: 'enterprise', name: '企業服務', anchor: '#_8-企業服務' },
|
||||
{ key: 'content', name: '內容生產與運營', anchor: '#_9-內容生產與運營' },
|
||||
{ key: 'government', name: '智慧政務管理', anchor: '#_10-智慧政務管理' },
|
||||
{ key: 'legal', name: '法律事務與合同管理', anchor: '#_11-法律事務與合同管理' },
|
||||
{ key: 'travel', name: '旅遊與出行服務', anchor: '#_12-旅遊與出行服務' },
|
||||
{ key: 'emotion', name: '情感陪伴', anchor: '#_13-情感陪伴' },
|
||||
{ key: 'entertainment', name: '休閒娛樂', anchor: '#_14-休閒娛樂' },
|
||||
{ key: 'ecommerce', name: '電商服務', anchor: '#_15-電商服務' },
|
||||
{ key: 'energy', name: '能源', anchor: '#_16-能源' },
|
||||
{ key: 'av-media', name: '音影片', anchor: '#_17-音影片' },
|
||||
{ key: 'ai-marketing', name: 'AI 營銷', anchor: '#_18-ai-營銷' },
|
||||
{ key: 'data-intelligence', name: '資料智慧', anchor: '#_19-資料智慧' }
|
||||
]
|
||||
|
||||
// 計算推薦結果 - 從主題池中隨機抽取
|
||||
const recommendationTopics = computed(() => {
|
||||
if (!interestPoint.value || !purpose.value) return []
|
||||
|
||||
const keys = recommendationMap[interestPoint.value]?.[purpose.value] || []
|
||||
const topics = []
|
||||
|
||||
// 從每個推薦行業中隨機抽取 1-2 個主題
|
||||
keys.forEach(key => {
|
||||
const industry = industries.find(item => item.key === key)
|
||||
const industryTopics = topicPool[key] || []
|
||||
|
||||
if (industry && industryTopics.length > 0) {
|
||||
// 隨機抽取 1-2 個主題
|
||||
const count = Math.floor(Math.random() * 2) + 1
|
||||
const shuffled = [...industryTopics].sort(() => Math.random() - 0.5)
|
||||
const selected = shuffled.slice(0, Math.min(count, shuffled.length))
|
||||
|
||||
selected.forEach(topic => {
|
||||
topics.push({
|
||||
...topic,
|
||||
industryKey: key,
|
||||
industryName: industry.name,
|
||||
industryAnchor: industry.anchor
|
||||
})
|
||||
})
|
||||
}
|
||||
})
|
||||
|
||||
// 隨機排序並限制總數
|
||||
return topics.sort(() => Math.random() - 0.5).slice(0, 8)
|
||||
})
|
||||
|
||||
// 獲取當前選擇的描述
|
||||
const currentSelection = computed(() => {
|
||||
const interest = interestOptions.find(i => i.value === interestPoint.value)
|
||||
const pur = purposeOptions.find(p => p.value === purpose.value)
|
||||
return {
|
||||
interest: interest?.label || '',
|
||||
purpose: pur?.label || ''
|
||||
}
|
||||
})
|
||||
|
||||
const scrollToAnchor = (anchor) => {
|
||||
// 延遲滾動確保DOM更新完成
|
||||
setTimeout(() => {
|
||||
// 嘗試透過ID查詢（支援多種格式）
|
||||
let element = document.querySelector(anchor)
|
||||
|
||||
// 如果找不到，嘗試其他可能的ID格式
|
||||
if (!element) {
|
||||
// 嘗試去掉下劃線字首
|
||||
const altAnchor = anchor.replace('#_', '#')
|
||||
element = document.querySelector(altAnchor)
|
||||
}
|
||||
|
||||
// 如果還是找不到，透過標題文字查詢
|
||||
if (!element) {
|
||||
// 從錨點提取行業名稱
|
||||
const anchorText = decodeURIComponent(anchor.replace('#', '').replace(/^_/, ''))
|
||||
const headings = document.querySelectorAll('h2, h3')
|
||||
|
||||
for (let heading of headings) {
|
||||
const headingText = heading.textContent.trim()
|
||||
// 完全匹配或包含匹配
|
||||
const cleanHeading = headingText.replace(/^\d+\.\s*/, '')
|
||||
if (cleanHeading === anchorText || headingText.includes(anchorText)) {
|
||||
element = heading
|
||||
break
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (element) {
|
||||
element.scrollIntoView({
|
||||
behavior: 'smooth',
|
||||
block: 'start'
|
||||
})
|
||||
// 高亮顯示目標段落
|
||||
element.style.backgroundColor = '#f0f9ff'
|
||||
element.style.transition = 'background-color 0.3s'
|
||||
element.style.padding = '8px'
|
||||
element.style.borderRadius = '4px'
|
||||
setTimeout(() => {
|
||||
element.style.backgroundColor = ''
|
||||
element.style.padding = ''
|
||||
}, 2000)
|
||||
}
|
||||
}, 100)
|
||||
}
|
||||
|
||||
const resetSelection = () => {
|
||||
interestPoint.value = ''
|
||||
purpose.value = ''
|
||||
}
|
||||
</script>
|
||||
|
||||
# B 端產業應用場景方向參考
|
||||
|
||||
## 章節導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['B 端應用', '產業應用', 'AI 場景', '落地參考', '行業方案']" coreOutput="瞭解 15+ B 端行業應用場景" expectedOutput="找到適合企業客戶的專案方向">
|
||||
|
||||
本文件彙總了 <strong>LLM 大模型在 B 端企業場景中的落地應用</strong>。與 C 端關注使用者體驗和情感不同，B 端產品更注重<strong>解決實際業務需求、提升效率、降低成本</strong>。每個場景都具備<strong>實際落地的可行性</strong>，涵蓋從<strong>需求分析到技術實現</strong>的完整思路，適合面向企業客戶的 AI 應用開發者參考。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
## 行業方向快速選擇
|
||||
|
||||
<el-card shadow="hover" style="margin-top: 16px; margin-bottom: 24px; border-left: 5px solid #409EFF;">
|
||||
<div style="font-weight: 600; margin-bottom: 8px;">找到適合你的應用場景</div>
|
||||
<div style="color: #606266; font-size: 14px; line-height: 1.6; margin-bottom: 12px;">
|
||||
選擇你的興趣方向和想要實現的目的，系統會推薦相關的行業場景，點選標籤即可跳轉到對應章節。
|
||||
</div>
|
||||
<el-row :gutter="16">
|
||||
<el-col :span="12">
|
||||
<el-select v-model="interestPoint" placeholder="選擇興趣方向" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in interestOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value">
|
||||
<div style="display: flex; flex-direction: column;">
|
||||
<span>{{ item.label }}</span>
|
||||
<span style="font-size: 12px; color: #909399;">{{ item.desc }}</span>
|
||||
</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
<el-col :span="12">
|
||||
<el-select v-model="purpose" placeholder="選擇實現目的" style="width: 100%;">
|
||||
<el-option
|
||||
v-for="item in purposeOptions"
|
||||
:key="item.value"
|
||||
:label="item.label"
|
||||
:value="item.value">
|
||||
<div style="display: flex; flex-direction: column;">
|
||||
<span>{{ item.label }}</span>
|
||||
<span style="font-size: 12px; color: #909399;">{{ item.desc }}</span>
|
||||
</div>
|
||||
</el-option>
|
||||
</el-select>
|
||||
</el-col>
|
||||
</el-row>
|
||||
|
||||
<!-- 推薦結果展示 - 表格形式 -->
|
||||
<div v-if="recommendationTopics.length > 0" style="margin-top: 16px;">
|
||||
<div style="font-weight: 600; margin-bottom: 10px; color: #409EFF;">
|
||||
為你推薦 {{ recommendationTopics.length }} 個應用場景
|
||||
<span style="font-weight: normal; color: #909399; font-size: 13px; margin-left: 8px;">
|
||||
({{ currentSelection.interest }} + {{ currentSelection.purpose }})
|
||||
</span>
|
||||
</div>
|
||||
<el-table
|
||||
:data="recommendationTopics"
|
||||
style="width: 100%; cursor: pointer;"
|
||||
@row-click="(row) => scrollToAnchor(row.industryAnchor)"
|
||||
highlight-current-row>
|
||||
<el-table-column prop="title" label="應用場景" min-width="300">
|
||||
<template #default="scope">
|
||||
<div style="font-weight: 500; color: #303133;">{{ scope.row.title }}</div>
|
||||
<div style="font-size: 12px; color: #909399; margin-top: 4px;">{{ scope.row.desc }}</div>
|
||||
</template>
|
||||
</el-table-column>
|
||||
<el-table-column prop="industryName" label="所屬行業" width="180" align="center">
|
||||
<template #default="scope">
|
||||
<el-tag type="info" effect="light" size="small">{{ scope.row.industryName }}</el-tag>
|
||||
</template>
|
||||
</el-table-column>
|
||||
</el-table>
|
||||
<div style="margin-top: 10px; font-size: 12px; color: #909399;">
|
||||
💡 點選表格任意行即可跳轉到對應行業章節
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- 未完全選擇時的提示 -->
|
||||
<div v-else-if="!interestPoint || !purpose" style="margin-top: 14px; color: #909399; font-size: 13px;">
|
||||
<span v-if="!interestPoint && !purpose">💡 請選擇興趣方向和實現目的</span>
|
||||
<span v-else-if="!interestPoint">💡 請選擇興趣方向</span>
|
||||
<span v-else>💡 請選擇實現目的</span>
|
||||
</div>
|
||||
|
||||
<!-- 重置按鈕 -->
|
||||
<div v-if="interestPoint || purpose" style="margin-top: 12px;">
|
||||
<el-button size="small" @click="resetSelection">重新選擇</el-button>
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
## 行業快速介紹
|
||||
|
||||
### 主流技術選型
|
||||
|
||||
在 AI 應用開發中，常見的技術方向包括：
|
||||
|
||||
1. **LLM（大語言模型）**：擅長處理自然語言任務，如對話、文字生成、摘要、翻譯等，適合構建智慧客服、內容創作、知識問答類應用。
|
||||
2. **VLM（視覺語言模型）**：結合視覺理解與語言能力，可實現影象描述、視覺問答、多模態內容生成等功能，適用於醫療影像分析、工業質檢、創意設計等場景。
|
||||
3. **GenAI（生成式 AI）**：包括文字生成、影象生成（如 Stable Diffusion、DALL·E）、影片生成等技術，能夠快速生成創意內容，適用於設計輔助、營銷素材製作、教育培訓等領域。
|
||||
|
||||
### 選擇策略
|
||||
|
||||
學習者可以根據以下維度選擇適合自己的應用方向：
|
||||
|
||||
1. **興趣導向**：優先選擇自己感興趣的行業或技術方向，保持學習動力。例如：
|
||||
- 對創意設計感興趣：可嘗試內容生產、工業設計類應用
|
||||
- 對技術挑戰感興趣：可嘗試網路安全、醫療方向的應用
|
||||
- 對社會價值感興趣：可嘗試智慧政務、教育行業的應用
|
||||
|
||||
2. **行業適配**：結合自身行業背景或資源優勢選擇場景：
|
||||
- 製造業從業者：可優先考慮工業製造、企業服務類應用
|
||||
- 教育工作者：可優先關注教育行業、內容生產類應用
|
||||
- 醫療從業者：可探索醫療方向、健康管理類應用
|
||||
|
||||
3. **技術難度**：根據自身技術基礎選擇合適的複雜度：
|
||||
- 入門級：智慧客服、內容創作、簡單問答系統
|
||||
- 進階級：工業質檢、醫療影像分析、程式碼智慧助手
|
||||
- 專業級：金融風控、網路安全、多模態複雜應用
|
||||
|
||||
## 1. 工業製造業
|
||||
|
||||
工業製造業場景主要圍繞設計輔助、生產最佳化、智慧運維三大方向展開。常見應用包括利用 AI 輔助產品外觀設計、自動化圖紙審查、技術文件智慧生成、工業裝置故障診斷等，能夠顯著提升設計效率和降低運維成本。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | 新能源客車外觀 AI 輔助設計平臺 | 基於圖片生成模型進行外觀概念設計，結合 LLM 進行設計規範檢查和創意迭代；整合 Three.js 3D 渲染服務 |
|
||||
| 2 | 智慧圖紙設計與審查助手 | 利用 RAG 技術構建企業設計規範知識庫，DALL·E 生成參考圖輔助理解；整合 CAD API 實現圖紙自動化解析 |
|
||||
| 3 | 技術文件自動生成與管理 | 基於 LLM 從產品資料庫自動生成產品規格書和操作手冊，ChromaDB 向量庫儲存歷史文件支援智慧檢索 |
|
||||
| 4 | 生產裝置巡檢報告自動生成助手 | 巡檢人員語音描述裝置狀態，LLM 結構化生成巡檢報告；自動關聯歷史故障記錄 |
|
||||
| 5 | 工廠叉車智慧排程與路徑規劃系統 | LLM 解析訂單任務和倉庫位置，結合地圖 API 生成最優排程方案 |
|
||||
| 6 | 基於 LLM 資訊檢索的資料倉儲 | 採用 Text-to-SQL 技術將自然語言轉換為資料庫查詢，Superset 視覺化展示查詢結果；Doris 或 ClickHouse 作為 OLAP 引擎 |
|
||||
| 7 | 工業裝置故障診斷知識問答助手 | 基於歷史故障案例構建向量知識庫，LLM 根據故障描述提供診斷建議和解決方案 |
|
||||
| 8 | 生產質檢報告智慧生成與缺陷分類 | OCR 識別質檢照片中的缺陷，LLM 生成結構化質檢報告；自動分類缺陷型別和嚴重程度 |
|
||||
| 9 | 庫存檔點智慧助手與盤點報告生成 | 盤點資料錄入，LLM 自動比對系統庫存並生成差異報告；異常庫存預警 |
|
||||
| 10 | 工藝流程最佳化建議智慧問答系統 | 基於生產工藝文件構建 RAG 知識庫，LLM 根據生產問題提供最佳化建議 |
|
||||
|
||||
## 2. 智慧客服
|
||||
|
||||
智慧客服場景聚焦於客戶服務效率提升和使用者體驗最佳化。典型應用涵蓋多渠道客服整合、智慧回覆生成、客戶情緒分析、工單自動化處理等，幫助企業實現 7×24 小時客戶服務。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
|
||||
| 1 | 多渠道智慧客服自動回覆與工單生成系統 | 接入微信、APP、官網等多渠道訊息，LLM 理解意圖後生成回覆並自動建立工單；使用 LangChain 構建對話流程，MySQL 儲存工單資料 |
|
||||
| 2 | 潛在客戶挖掘與跟進建議助手 | LLM 分析歷史客服對話記錄，識別高意向客戶特徵並打分；推薦系統結合協同過濾演算法 |
|
||||
| 3 | 企業內部知識智慧檢索與問答管家 | 基於 Confluence 和內部文件構建向量知識庫，LLM 結合 RAG 技術生成答案 |
|
||||
| 4 | 客戶滿意度調查與服務改進管理系統 | LLM 自動分析客服對話內容進行情感分類和滿意度評分；BI 報表展示分析結果 |
|
||||
| 5 | 客服對話智慧小結與工單生成工具 | 客服結束對話後，LLM 自動生成會話小結並提取關鍵資訊；自動填充工單欄位 |
|
||||
| 6 | 客服話術合規性自動檢測助手 | 客服輸入回覆內容，LLM 實時檢測話術合規性和敏感詞；給出修改建議 |
|
||||
| 7 | 客服工單自動摘要與分類生成工具 | LLM 對長對話記錄進行摘要生成和自動分類打標；Elasticsearch 支援工單全文檢索 |
|
||||
| 8 | 客戶情緒監測與異常預警工具 | 實時分析語音語調特徵和文字情感，LLM 識別異常情緒並觸發預警；WebSocket 推送預警訊息 |
|
||||
| 9 | 客服金牌話術推薦知識庫系統 | LLM 分析優秀客服對話案例，提煉金牌話術模板；推薦系統根據對話上下文實時推薦話術 |
|
||||
| 10 | 智慧外呼對話內容分析與質檢助手 | 外呼錄音轉寫後，LLM 分析對話內容提取關鍵資訊；自動生成質檢報告和改進建議 |
|
||||
|
||||
## 3. 教育行業
|
||||
|
||||
教育行業場景致力於實現個性化教學和智慧教育管理。核心應用包括智慧學習路徑規劃、作業自動批改、教案生成、學情分析等，推動教育資源的最佳化配置和因材施教的實現。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ---------------------------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| 1 | 個性化語言學習路徑規劃與智慧導學系統 | LLM 評估學習者當前水平，根據學習目標規劃每日學習任務；推薦演算法結合知識圖譜推薦學習資源 |
|
||||
| 2 | 教案自動化編寫與教學資源推送平臺 | LLM 根據課程大綱生成教案框架和教學設計；向量庫儲存優質教案和課件，支援關鍵詞檢索和相似推薦 |
|
||||
| 3 | 作業自動化批閱與學情診斷分析系統 | LLM 自動批改主觀題並生成批改建議，知識圖譜定位學生薄弱知識點 |
|
||||
| 4 | 人才崗位勝任力模型構建與學習地圖 | LLM 分析崗位 JD 提取能力要求，構建崗位能力畫像；根據差距生成個性化學習地圖 |
|
||||
| 5 | 校本課程體系構建與課件製作工具 | LLM 分析學校特色和學生需求，生成校本課程框架；整合 PPT 生成介面自動製作課件 |
|
||||
| 6 | 外語口語一對一情景化實戰演練 | LLM 扮演不同角色進行口語對話，ASR 識別發音並評分；TTS 生成標準發音示範 |
|
||||
| 7 | 高考志願大資料推薦與生涯規劃指導平臺 | LLM 分析考生分數、位次、興趣等資訊，結合招錄資料推薦院校和專業 |
|
||||
| 8 | 少兒程式設計程式碼助手 | LLM 解釋程式碼邏輯和提供程式設計指導，支援塊語言和 Python 切換 |
|
||||
| 9 | 知識點思維導圖自動生成與學習路徑推薦工具 | 輸入課程主題，LLM 自動生成知識點思維導圖；根據學習進度推薦下一步學習內容 |
|
||||
| 10 | 中英文作文自動化評分與批改引擎 | LLM 從立意、結構、語言、多樣性等多維度評分並生成批註；比對優秀範文 |
|
||||
|
||||
## 4. 智慧程式設計
|
||||
|
||||
智慧程式設計場景旨在提升開發效率和程式碼質量。典型應用有智慧程式碼補全、Bug 自動修復、自動化測試生成、程式碼轉換等，讓開發者能夠專注於業務邏輯而非重複性編碼工作。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| 1 | 智慧程式碼補全與 Bug 自動修復助手 | 基於 CodeLlama 微調程式碼模型，IDE 外掛實時提供程式碼補全建議；LLM 分析錯誤棧自動定位 Bug 並生成修復程式碼 |
|
||||
| 2 | 低程式碼應用構建與流程自動化平臺 | 使用者透過自然語言描述需求，LLM 轉換為低程式碼配置或程式碼框架 |
|
||||
| 3 | 單元測試用例生成系統 | AST 解析原始碼提取函式邏輯，LLM 生成邊界條件和異常場景的測試用例；整合 Jest/Pytest 執行測試 |
|
||||
| 4 | 程式碼智慧分析與語言遷移工具 | 基於 Tree-sitter 解析程式碼結構，LLM 分析程式碼質量並提供最佳化建議；結合規則引擎實現語言轉換 |
|
||||
| 5 | 自然語言轉 SQL 語句自動生成工具 | LLM 將自然語言查詢轉換為 SQL，支援複雜多表關聯和聚合查詢 |
|
||||
| 6 | API 介面自動化測試與文件生成平臺 | LLM 分析程式碼註釋和介面定義，自動生成測試用例和 API 文件；Postman 整合測試執行 |
|
||||
| 7 | UI 測試指令碼智慧錄製與維護工具 | 瀏覽器外掛錄製使用者操作軌跡，LLM 分析操作意圖生成測試指令碼；AI 修復失效的定位器 |
|
||||
| 8 | 系統日誌分析與故障定位 | ELK Stack 採集日誌資料，LLM 分析異常日誌提取關鍵資訊並定位根因；推薦修復方案 |
|
||||
| 9 | 前端介面（UI）程式碼自動生成工具 | 設計稿圖片經 OCR 識別佈局結構，LLM 生成響應式 CSS 和元件程式碼；整合 TailwindCSS 支援多種樣式框架 |
|
||||
| 10 | 資料庫結構智慧設計與建模助手 | 業務需求文件輸入給 LLM，自動生成 ER 圖和資料表結構；支援匯出 MySQL/PostgreSQL 建表指令碼 |
|
||||
|
||||
## 5. 醫療方向
|
||||
|
||||
醫療方向場景致力於提升診療效率和醫療服務質量。常見應用包括病歷自動生成、醫學知識問答、影像分析輔助、藥物研發支援等，推動醫療行業的智慧化轉型。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ---------------------------------- | ------------------------------------------------------------------------------------- |
|
||||
| 1 | 醫學檢驗報告智慧解讀助手 | 上傳檢驗報告圖片，OCR 識別關鍵指標，LLM 解讀異常值並生成通俗解釋 |
|
||||
| 2 | 基於知識檢索技術的健康諮詢專家 | 構建醫學知識圖譜（ICD-10、藥品說明書、診療指南），RAG 檢索生成回答 |
|
||||
| 3 | 臨床科研資料決策分析平臺 | 整合 EMR 資料和檢驗結果，LLM 輔助生成統計分析程式碼和視覺化圖表；支援佇列研究和生存分析 |
|
||||
| 4 | 醫學考題智慧生成與錯題解析系統 | 輸入教材章節和知識點，LLM 生成練習題和解析；自動收錄錯題並生成薄弱點分析 |
|
||||
| 5 | 藥物研發全流程知識圖譜智慧問答專家 | 構建藥物-靶點-疾病知識圖譜，LLM 解答研發相關問題；支援文獻檢索和實驗方案推薦 |
|
||||
| 6 | 藥品說明書智慧問答助手 | 上傳藥品說明書圖片或輸入藥名，LLM 解答用法用量、不良反應、注意事項等問題 |
|
||||
| 7 | 疾病知識科普文章生成助手 | 輸入疾病名稱和受眾，LLM 生成通俗易懂的科普文章；支援多版本（患者版/家屬版） |
|
||||
| 8 | 醫學影像報告自動生成工具 | 影像科醫生描述影像特徵，LLM 自動生成結構化報告；支援常見檢查型別模板 |
|
||||
| 9 | 手術記錄智慧生成與歸檔助手 | 手術過程中語音錄入關鍵步驟，LLM 結構化生成手術記錄；自動關聯手術編碼 |
|
||||
| 10 | 慢病管理用藥提醒智慧助手 | 患者輸入用藥清單，LLM 生成個性化用藥提醒；支援用藥禁忌檢查和互動問答 |
|
||||
|
||||
## 6. 網路安全
|
||||
|
||||
網路安全場景聚焦於安全防護和風險管控。核心應用涵蓋漏洞檢測、威脅情報分析、釣魚郵件識別、安全事件響應等，為企業構建全方位的智慧安全防護體系。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ----------------------------------- | -------------------------------------------------------------------------------------- |
|
||||
| 1 | 程式碼安全漏洞檢測與修復引擎 | 靜態程式碼分析工具（SAST）掃描程式碼，LLM 分析漏洞原理並生成修復建議；整合 CI/CD 流水線 |
|
||||
| 2 | AI 生成式釣魚郵件智慧識別與攔截系統 | LLM 分析郵件內容、傳送者特徵和連結安全性，識別 AI 生成的釣魚郵件；對接郵件閘道器實時攔截 |
|
||||
| 3 | 安全運營日報自動生成助手 | 安全裝置日誌彙總，LLM 自動提取關鍵事件並生成日報；異常事件highlight標記 |
|
||||
| 4 | 安全知識庫智慧問答助手 | 基於安全文件、CVE 庫構建向量知識庫，LLM 解答安全技術和處置建議問題 |
|
||||
| 5 | 滲透測試報告智慧生成助手 | 滲透測試完成後，LLM 根據漏洞描述自動生成報告；漏洞修復建議批次生成 |
|
||||
| 6 | 惡意程式碼防護與隱私合規監控 | 沙箱分析可疑檔案行為，LLM 識別惡意特徵並生成簽名；隱私資料識別掃描 |
|
||||
| 7 | 安全配置合規性檢查清單生成工具 | 輸入目標系統型別，LLM 生成安全配置檢查清單；支援等保 2.0、CIS 等標準 |
|
||||
| 8 | 威脅情報智慧查詢與分析助手 | 對接多源威脅情報（開源、商業），LLM 解讀情報並關聯企業資產；推薦防護策略 |
|
||||
| 9 | 安全事件覆盤報告生成助手 | 安全事件發生後，LLM 根據時間線自動生成覆盤報告；根因分析和改進建議 |
|
||||
| 10 | 全球威脅情報監測與預警中心 | 爬蟲採集全球安全資訊和漏洞披露，LLM 提取關鍵資訊並評估影響；郵件/簡訊預警通知 |
|
||||
|
||||
## 7. 金融管理、保險銀行業
|
||||
|
||||
金融領域場景圍繞風險控制和業務智慧化展開。典型應用包括信貸風控評估、財富管理顧問、財務報告生成、反洗錢監測等，提升金融機構的運營效率和風險管控能力。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------- | ------------------------------------------------------------------------------------ |
|
||||
| 1 | 信貸盡調報告智慧生成助手 | 輸入企業基本資訊和財務資料，LLM 自動生成信貸盡調報告；風險點自動標註 |
|
||||
| 2 | 私人銀行財富管理智慧顧問 | LLM 分析客戶風險偏好和財務目標，生成資產配置建議；對接理財產品和基金庫 |
|
||||
| 3 | IPO 招股書智慧生成與合規校驗助手 | 招股說明書模組化模板，LLM 自動填充業務描述和風險因素；合規校驗規則引擎檢查前後一致性 |
|
||||
| 4 | 企業財務報告自動生成與經營異常預警系統 | 財務系統資料自動採集，LLM 生成財務分析和管理層討論部分；異常指標預警規則 |
|
||||
| 5 | 財務票據資訊提取與問答助手 | 上傳發票圖片，OCR 識別資訊，LLM 解答票據相關問題；支援增值稅發票、火車票等 |
|
||||
| 6 | 合規案例智慧檢索與問答助手 | 基於監管處罰案例構建知識庫，LLM 解答合規問題並提供案例參考 |
|
||||
| 7 | 保險代理人智慧話術陪練 | LLM 扮演不同型別客戶進行模擬對話，評估代理人話術合規性和說服力；錄音轉寫分析 |
|
||||
| 8 | 保險產品條款分析與競品對比平臺 | 條款結構化解析，LLM 生成亮點摘要和注意事項 |
|
||||
| 9 | 客戶話術情緒識別服務 | 語音情緒識別結合話術合規檢測，實時反饋代理人改進建議 |
|
||||
| 10 | 保險理賠進度智慧查詢與對話助手 | 使用者輸入保單號或報案號，LLM 查詢理賠進度並解答理賠相關問題 |
|
||||
|
||||
## 8. 企業服務
|
||||
|
||||
企業服務場景致力於提升組織運營效率和管理水平。常見應用包括客戶關係管理、銷售預測、輿情監測、HR 智慧管理等，幫助企業實現數字化轉型升級。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ---------------------------------- | ------------------------------------------------------------------------------ |
|
||||
| 1 | 客戶留存分析與流失預警平臺 | 行為資料埋點採集使用者操作，ML 模型預測流失機率，LLM 生成挽留建議 |
|
||||
| 2 | B2B 潛在客戶觸達與營銷郵件平臺 | 企業工商資料篩選目標客戶，LLM 生成個性化營銷內容；郵件群發平臺對接 |
|
||||
| 3 | 銷售管線監測與業績預測平臺 | CRM 資料自動採集，LLM 分析銷售漏斗並預測業績達成；異常預警推送管理者 |
|
||||
| 4 | 品牌輿情監測與危機預警雷達 | 全網輿情資料採集（社交媒體、新聞、論壇），LLM 分析情感和傳播趨勢；危機預警推送 |
|
||||
| 5 | 職場郵件智慧撰寫與溝通情緒管理助手 | 郵件上下文理解，LLM 生成專業郵件草稿；情緒分析反饋改進建議 |
|
||||
| 6 | 簡歷智慧解析與崗位匹配系統 | 簡歷 PDF 解析提取關鍵資訊，LLM 匹配合適崗位並生成面試建議；ATS 系統對接 |
|
||||
| 7 | 企業員工入職指引與問答助手 | 入職文件知識庫 RAG 檢索，LLM 解答新員工常見問題 |
|
||||
| 8 | 員工績效反饋與 OKR 目標管理平臺 | OKR 系統資料採集，LLM 分析目標完成情況並生成反饋建議；360 反饋收集 |
|
||||
| 9 | 智慧會議記錄與待辦管理 | 會議錄音轉寫，LLM 提取關鍵討論點和待辦事項；任務系統自動建立待辦 |
|
||||
| 10 | 發票識別與費用報銷自動處理 | OCR 識別發票資訊，自動校驗發票真偽和報銷合規性；對接財務系統 |
|
||||
|
||||
## 9. 內容生產與運營
|
||||
|
||||
內容生產與運營場景聚焦於創意生成和流量運營。核心應用包括文案創作、短影片製作、數字人直播、SEO 最佳化等，幫助企業提升內容產出效率和營銷轉化率。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ----------------------------------------- | -------------------------------------------------------------------------- |
|
||||
| 1 | 影視與小說內容創作輔助平臺 | LLM 提供故事大綱、角色設定、對白生成等創作輔助；思維導圖視覺化故事結構 |
|
||||
| 2 | 企業品牌故事與公關軟文智慧撰寫助手 | 輸入品牌關鍵詞和產品資訊，LLM 生成多風格文案版本；A/B 測試介面對接 |
|
||||
| 3 | 虛擬數字人直播互動與推流管理系統 | 數字人形象建模 + TTS 語音 + LLM 對話，實時響應觀眾彈幕；OBS 推流整合 |
|
||||
| 4 | 短影片指令碼生成與智慧剪輯 | LLM 生成短影片指令碼和分鏡，Sora/Runway 生成影片片段；剪輯工具自動拼接 |
|
||||
| 5 | 銷售會話語音轉寫與話術推薦 | 電話錄音 ASR 轉寫，LLM 分析會話並推薦金牌話術；CRM 系統整合 |
|
||||
| 6 | 營銷內容智慧生成與設計系統 | 產品資訊輸入，LLM 生成營銷文案和賣點提煉；整合 Canava/稿定設計模板 |
|
||||
| 7 | 多平臺廣告投放 ROI 實時監控與策略調優系統 | 廣告平臺 API 對接採集資料，LLM 分析投放效果並生成最佳化建議；異常預警推送 |
|
||||
| 8 | 搜尋引擎關鍵詞與流量分析 | 百度指數、5118 資料採集，LLM 分析關鍵詞趨勢和競爭度；內容選題推薦 |
|
||||
| 9 | 競品廣告投放分析平臺 | 第三方資料平臺 API 採集競品廣告，LLM 分析投放策略和創意特點 |
|
||||
| 10 | 全網熱點選題智慧分析與內容推薦系統 | 微博熱搜、抖音熱榜資料採集，LLM 分析熱點趨勢並推薦選題角度；日曆化內容排期 |
|
||||
|
||||
## 10. 智慧政務管理
|
||||
|
||||
智慧政務場景致力於提升政府服務效能和治理能力。典型應用包括政務熱線智慧導航、政策智慧問答、行政審批最佳化、城市事件管理等，推動數字政府建設。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ------------------------------------------ | -------------------------------------------------------------------- |
|
||||
| 1 | 12345 政務熱線智慧語音導航與自動分派系統 | 市民來電語音識別，LLM 理解訴求並智慧分派到對應部門；工單系統自動流轉 |
|
||||
| 2 | 政務服務大廳智慧導辦與政策問答機器人 | 政務知識庫 RAG 檢索，LLM 解答辦事流程和政策問題；取號系統對接 |
|
||||
| 3 | 惠企政策智慧匹配與精準推送平臺 | 政策結構化解析，企業畫像自動匹配適用政策；簡訊/郵件推送提醒 |
|
||||
| 4 | 行政審批材料智慧預審與合規校驗助手 | 材料 OCR 識別和關鍵資訊提取，LLM 校驗材料完整性和合規性 |
|
||||
| 5 | 公共安全影片監控異常行為檢測系統 | 影片流實時分析，CV 模型檢測異常行為（打架、跌倒等）；告警推送 |
|
||||
| 6 | 城市網格化事件智慧識別與排程管理平臺 | 城市感知資料（IoT、攝像頭）採集，LLM 識別事件型別並分派 |
|
||||
| 7 | 社情民意大資料分析與風險預警系統 | 政務熱線、網路輿情、社情走訪等多源資料融合分析；LLM 識別風險熱點 |
|
||||
| 8 | 政務檔案數字化識別與智慧歸檔管理平臺 | OCR 識別檔案文字內容，LLM 提取關鍵資訊並自動分類；全文檢索支援 |
|
||||
| 9 | 突發公共事件應急指揮與救援資源智慧排程平臺 | 事件資訊採集，LLM 生成應急響應方案；資源排程最佳化演算法 |
|
||||
| 10 | 大氣環境汙染網格化監測與精準溯源系統 | 空氣質量感測器資料採集，CV 模型識別汙染源；LLM 分析汙染趨勢並溯源 |
|
||||
|
||||
## 11. 法律事務與合同管理
|
||||
|
||||
法律事務場景聚焦於法律服務效率提升和合規管理。常見應用包括合同審查、案件分析、法規監測、法律文書生成等，為法律從業者提供智慧化工具支援。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------------------------- | ---------------------------------------------------------------- |
|
||||
| 1 | 合同風險漏洞一鍵"找茬"Agent | 合同文字結構化解析，LLM 對照風險清單識別潛在問題；標註高風險條款 |
|
||||
| 2 | 企業合同全生命週期合規性審查與修改建議平臺 | 合同條款比對法規庫，LLM 生成合規性審查報告；修改建議跟蹤 |
|
||||
| 3 | 類似案件勝訴率 AI 智慧評估顧問 | 案件特徵提取，類案檢索匹配；LLM 分析影響勝訴因素 |
|
||||
| 4 | 法律法規變更實時監測與業務影響分析雷達 | 法律法規資料庫實時更新，LLM 解析變更內容並評估業務影響；預警推送 |
|
||||
| 5 | 律師函 AIGC 自動起草工具 | 事實陳述輸入，LLM 生成規範律師函模板；要素檢查和合規校驗 |
|
||||
| 6 | 庭審錄音實時轉寫與爭議焦點自動化提取記錄儀 | 法庭錄音 ASR 轉寫，LLM 提取爭議焦點和關鍵論點；時間戳標註 |
|
||||
| 7 | 全網智慧財產權侵權線索自動監測與區塊鏈取證系統 | 電商平臺、社交媒體侵權監測；侵權證據自動採集存證 |
|
||||
| 8 | 基於 LLM 的 IPO 招股書關鍵資料一致性核查與風險預警 Agent | 招股書多章節資料比對，LLM 識別不一致和資料異常；風險標註 |
|
||||
| 9 | 複雜法律條款"翻譯"為大白話的解釋外掛 | 選中法律條文，LLM 生成通俗易懂的解釋 |
|
||||
| 10 | 案件證據鏈智慧梳理與視覺化展示系統 | 證據材料上傳，LLM 分析證據關係和時間線 |
|
||||
|
||||
## 12. 旅遊與出行服務
|
||||
|
||||
旅遊出行場景致力於提升旅行體驗和服務便捷性。核心應用包括智慧行程規劃、價格預測、虛擬導覽、翻譯服務等，讓旅行更加輕鬆愉快。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------------- | ----------------------------------------------------------------------------------- |
|
||||
| 1 | 基於 AIGC 的懶人路書生成器 | 使用者偏好輸入（天數、預算、興趣），LLM 生成每日行程安排；景點 API 獲取開放時間和門票 |
|
||||
| 2 | 全網機票酒店價格趨勢預測與低價自動鎖定機器人 | 採集 OTA 價格資料，ML 模型預測價格趨勢；價格監控提醒 |
|
||||
| 3 | 航班取消後的跨航司行程重組與應急方案推薦顧問 | 航班狀態監控，LLM 分析替代行程方案；多航司比價 |
|
||||
| 4 | 簽證材料智慧預審與自動化填表輔助系統 | 材料拍照上傳，OCR 識別資訊完整性檢查；表格自動填充 |
|
||||
| 5 | 出境遊實時語音翻譯與選單視覺漢化管家 | 離線語音翻譯模型，選單圖片 OCR 識別並翻譯 |
|
||||
| 6 | 基於大資料真實評價的酒店"避雷"指南分析儀 | 酒店評論資料採集，LLM 提取正負面評價關鍵詞 |
|
||||
| 7 | 目的地沉浸式 VR 預覽與虛擬選房互動平臺 | 360°全景圖採集，VR 技術實現沉浸式預覽；房間虛擬遊覽 |
|
||||
| 8 | 旅行足跡自動生成精美遊記與社交文案助手 | 照片時間地點資訊提取，LLM 生成遊記文案；模板排版生成 |
|
||||
| 9 | 企業差旅發票自動歸集與合規報銷管理平臺 | 差旅平臺 API 對接，發票資訊自動採集；合規校驗 |
|
||||
| 10 | 景區客流擁堵實時預測與錯峰遊覽路線規劃導航 | 景區客流資料採集，ML 模型預測擁堵時段；錯峰推薦 |
|
||||
|
||||
## 13. 情感陪伴
|
||||
|
||||
情感陪伴場景聚焦於心理健康和情感慰藉。典型應用包括虛擬伴侶、情感諮詢、認知訓練、心理疏導等，為使用者提供全天候的陪伴和支援。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------------- | ----------------------------------------------------------- |
|
||||
| 1 | 基於 LLM 大模型的 24 小時深度陪伴虛擬伴侶 | 記憶系統儲存對話歷史，LLM 生成個性化回覆；情感支援模組 |
|
||||
| 2 | 多模態情感識別與心理疏導 AI 顧問 | 語音語調分析 + 文字情感識別，LLM 生成疏導建議；危機干預預警 |
|
||||
| 3 | 阿爾茨海默症老人 AI 認知訓練與記憶喚醒數字人 | 認知遊戲（記憶、計算、語言）訓練；老照片/老歌觸發記憶回憶 |
|
||||
| 4 | 社恐人士的 AIGC 模擬社交演練教練 | 虛擬社交場景模擬，LLM 扮演不同角色；社交技巧建議 |
|
||||
| 5 | 生成式 AI 兒童睡前故事定製機 | 家長輸入主題和偏好，LLM 生成定製故事；背景音樂生成 |
|
||||
| 6 | 逝者數字生命復原與 LLM 跨時空對話系統 | 生前資料（語音、文字）訓練個性化模型；記憶對話生成 |
|
||||
| 7 | 基於 MBTI 資料的 AI 性格映象與共情聊天機器人 | MBTI 測試結果輸入，LLM 生成性格分析和共情回覆；性格匹配推薦 |
|
||||
| 8 | 全天候心情監測與 AI 正向情緒激勵助手 | 日常記錄心情狀態，LLM 分析趨勢並生成激勵內容；正向提醒推送 |
|
||||
| 9 | 隱私保護級青少年 AI 傾訴樹洞 | 匿名傾訴入口，LLM 提供傾聽和建議；敏感詞預警 |
|
||||
| 10 | 具備自主進化能力的 AI 虛擬寵物養成系統 | 寵物性格模型訓練，對話互動成長進化；虛擬裝扮系統 |
|
||||
|
||||
## 14. 休閒娛樂
|
||||
|
||||
休閒娛樂場景致力於提供豐富的數字化娛樂體驗。常見應用包括遊戲 NPC 智慧決策、劇本殺輔助、內容創作、音影片處理等，滿足使用者的多元化娛樂需求。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------------- | --------------------------------------------------------- |
|
||||
| 1 | 基於 LLM 驅動的開放世界遊戲 NPC 自主決策引擎 | NPC 行為樹融合 LLM 決策，對話系統生成個性化互動；行為引擎 |
|
||||
| 2 | 沉浸式劇本殺 AIGC 劇情推演與 DM 控場輔助工具 | 玩家選擇觸發劇情分支，LLM 生成推理邏輯；線索卡自動生成 |
|
||||
| 3 | 互動小說結局生成式修改器 | 讀者選擇影響劇情走向，LLM 生成多種結局分支 |
|
||||
| 4 | 二次元角色 3D 建模 AIGC 自動生成工作臺 | 描述文字生成角色草圖，3D 建模工具自動建模；材質貼圖渲染 |
|
||||
| 5 | 電競戰局 CV 視覺分析與 AI 智慧解說員 | 遊戲畫面實時分析，關鍵時刻識別；LLM 生成解說文案 |
|
||||
| 6 | 個性化幽默內容推薦演算法引擎 | 使用者興趣畫像，幽默內容匹配推薦 |
|
||||
| 7 | AI 智慧修音與 KTV 人聲美化軟體 | 音訊降噪和人聲增強處理；AI 修音演算法 |
|
||||
| 8 | 影視劇角色專屬劇情 AI 提取與剪輯工具 | 影片內容分析，角色相關片段提取；自動剪輯生成 |
|
||||
| 9 | 多角色 TTS 語音合成有聲書自動生成系統 | 文字角色分配，個性化音色生成；背景音樂和音效新增 |
|
||||
| 10 | 棋牌類遊戲強化學習對弈覆盤教練 | 棋局分析，AI 對手模擬對弈；覆盤建議生成 |
|
||||
|
||||
## 15. 電商服務
|
||||
|
||||
電商服務場景聚焦於運營效率和轉化提升。核心應用包括商品內容生成、直播帶貨、客戶服務、價格分析等，幫助商家實現智慧化運營。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | --------------------------------------------- | ---------------------------------------------------------- |
|
||||
| 1 | 高轉化率 AIGC 商品詳情頁批次生產工具 | 商品資訊輸入，LLM 生成賣點文案和場景描述；背景圖生成 |
|
||||
| 2 | 服裝虛擬模特 AI 智慧試穿與展示影片生成工廠 | 服裝平鋪圖處理，虛擬模特試穿效果生成；多角度展示影片 |
|
||||
| 3 | 跨境電商多語言 LLM 本地化翻譯與潤色助手 | 商品描述多語言翻譯，文化適配潤色；多平臺釋出介面 |
|
||||
| 4 | 基於 NLP 的客戶情感分析與智慧回覆機器人 | 諮詢對話情感分析，自動生成安撫回覆；好評差評分類 |
|
||||
| 5 | 24 小時全天候 AIGC 數字人直播帶貨系統 | 數字人形象 + 實時話術生成，商品資訊實時呼叫；彈幕互動回覆 |
|
||||
| 6 | 全網同款商品 AI 比價與趨勢預測外掛 | 電商平臺價格爬取，比價圖表展示；價格趨勢預測 |
|
||||
| 7 | 買家秀圖片 AI 智慧篩選與短影片合成平臺 | 買家秀圖片質量評分，優質內容自動推薦；短影片模板合成 |
|
||||
| 8 | 基於 LLM 的實時銷售對話語音分析與金牌話術推薦 | 通話 ASR 轉寫，實時話術合規檢測；話術推薦 |
|
||||
| 9 | 市場流行趨勢 AI 洞察與爆款預測引擎 | 社交媒體和電商資料採集分析，LLM 洞察趨勢熱點；選品建議推薦 |
|
||||
| 10 | 私域流量使用者畫像 AI 聚類與精細化運營系統 | 使用者行為資料聚類分析，畫像標籤生成；自動化營銷觸發 |
|
||||
|
||||
## 16. 能源
|
||||
|
||||
能源場景致力於實現能源行業的智慧化管理和綠色轉型。典型應用包括用電分析、裝置檢測、碳排放核算、排程最佳化等，推動能源系統的高效執行。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ------------------------------------------------ | ------------------------------------------------------ |
|
||||
| 1 | 家庭用電行為 AI 分析與節能策略顧問 | 智慧電錶資料採集，用電模式分析；LLM 生成節能建議 |
|
||||
| 2 | 光伏元件缺陷無人機 CV 視覺識別系統 | 無人機巡檢拍攝，熱紅外影象分析；缺陷檢測標註 |
|
||||
| 3 | 電力現貨交易價格 AI 趨勢預測與自動獲利策略 Agent | 電力市場資料採集，價格預測模型；策略生成和交易執行 |
|
||||
| 4 | 儲能電池健康度 AI 無損檢測與熱失控風險預警系統 | 電池執行資料監測，健康度評估模型；風險預警推送 |
|
||||
| 5 | 企業全鏈路碳排放 AI 自動核算與 ESG 報告生成助手 | 能源消耗資料採集，碳排放因子計算；ESG 報告自動生成 |
|
||||
| 6 | 電網極端天氣負荷 AI 預測與應急排程指揮系統 | 氣象資料對接，負荷預測模型；排程策略生成 |
|
||||
| 7 | 加油站違規行為 AI 影片識別與報警衛士 | 影片監控分析，違規行為檢測（打電話、抽菸等）；告警推送 |
|
||||
| 8 | 長輸油氣管道洩漏聲波 AI 監測與精準定位系統 | 聲波感測器資料採集，洩漏檢測模型；定位演算法計算 |
|
||||
| 9 | 虛擬電廠資源聚合與 AI 電力交易決策系統 | 分散式資源接入，聚合最佳化排程；交易策略執行 |
|
||||
| 10 | 礦井人員位置 AI 追蹤與危險區域入侵報警 | UWB/藍芽定位，人員軌跡追蹤；危險區域電子圍欄 |
|
||||
|
||||
## 17. 音影片
|
||||
|
||||
音影片場景聚焦於內容生產和媒體處理。常見應用包括影片剪輯、語音合成、字幕生成、影片修復等，提升音影片內容的生產效率和質量。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------------- | -------------------------------------------------- |
|
||||
| 1 | 長影片精彩片段 AI 識別與短影片自動剪輯工具 | 影片內容分析，關鍵幀識別；精彩片段自動剪輯 |
|
||||
| 2 | 影片背景噪音 AI 智慧分離與人聲增強助手 | 音訊分離模型，去除背景噪音；人聲增強處理 |
|
||||
| 3 | 老舊影像 4K 超分修復與 AI 智慧上色工作臺 | 影片超解析度模型，修復老舊畫質；AI 自動上色 |
|
||||
| 4 | 文字轉真人級 TTS 配音與情感控制系統 | 多音色 TTS 模型，情感控制生成；音訊匯出 |
|
||||
| 5 | 影片語音 ASR 自動識別與雙語字幕生成工具 | 語音識別生成字幕，多語言翻譯；雙語字幕疊加 |
|
||||
| 6 | 影片畫面多餘物體 AI 智慧擦除引擎 | 影片目標追蹤，物體移除修復；幀間一致性處理 |
|
||||
| 7 | 無版權背景音樂 AIGC 自動作曲機 | 音樂生成模型，情緒風格可控；版權檢測 |
|
||||
| 8 | 特定人物音色 AI 克隆與變聲轉換軟體 | 少量語音樣本訓練音色模型；變聲處理 |
|
||||
| 9 | 劇本一鍵轉分鏡指令碼與 AI 動態預演影片生成平臺 | 劇本解析生成分鏡，AI 生成預演影片 |
|
||||
| 10 | 會議錄音 AI 智慧轉寫與核心待辦提取助手 | 多人會議語音分離轉寫，LLM 提取待辦事項；時間戳標註 |
|
||||
|
||||
## 18. AI 營銷
|
||||
|
||||
AI 營銷場景致力於提升營銷效率和創意產出。核心應用包括文案生成、海報設計、熱點追蹤、競品分析等，幫助企業實現精準營銷和品牌傳播。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | ------------------------------------------ | ------------------------------------------------ |
|
||||
| 1 | 小紅書爆款文案 AIGC 自動撰寫引擎 | 話題輸入，LLM 生成種草文案；emoji 和話題標籤最佳化 |
|
||||
| 2 | 營銷海報 AI 智慧排版與多尺寸適配工具 | 文案輸入，海報模板智慧匹配與多尺寸匯出 |
|
||||
| 3 | 品牌 LOGO 創意 AIGC 生成與 VI 體系構建平臺 | 品牌關鍵詞輸入，LOGO 創意生成；VI 規範生成 |
|
||||
| 4 | 全網熱點 AI 追蹤與借勢營銷創意生成助手 | 熱點資料採集，LLM 分析營銷角度；創意方案生成 |
|
||||
| 5 | 廣告投放 ROI 實時監控與 AI 預算競價管家 | 廣告平臺資料對接，效果分析模型；競價策略最佳化 |
|
||||
| 6 | 競品營銷策略深度解析與 AI 週報生成器 | 競品內容採集分析，策略提取；週報自動生成 |
|
||||
| 7 | 搜尋引擎關鍵詞 AI 佈局與引流文章批次寫作 | 關鍵詞分析，文章批次生成；SEO 最佳化建議 |
|
||||
| 8 | 千人千面個性化營銷郵件 AI 撰寫專家 | 使用者畫像資料，個性化內容生成；A/B 測試 |
|
||||
| 9 | 品牌聲譽全網監測與輿情危機 AI 預警雷達 | 全網輿情資料採集，情感分析；危機預警推送 |
|
||||
| 10 | 短影片指令碼創意 AIGC 生成與分鏡指導助手 | 主題輸入，指令碼和分鏡生成；拍攝建議指導 |
|
||||
|
||||
## 19. 資料智慧
|
||||
|
||||
資料智慧場景聚焦於資料分析和價值挖掘。典型應用包括自然語言查詢、視覺化生成、資料治理、知識圖譜構建等，幫助企業實現資料驅動的決策支援。
|
||||
|
||||
| 序號 | 應用場景名稱 | 實現參考 |
|
||||
| :--: | -------------------------------------- | ------------------------------------------------------------ |
|
||||
| 1 | 基於 Text-to-SQL 的自然語言查數引擎 | 自然語言轉換為 SQL 查詢，結果視覺化展示 |
|
||||
| 2 | 對話式 BI：一句話生成視覺化圖表 | 資料需求描述，圖表自動生成；支援多圖表型別切換 |
|
||||
| 3 | 截圖一鍵轉 Excel 表格識別工具 | 截圖上傳後，VLM 識別表格結構和資料；匯出為 Excel 檔案 |
|
||||
| 4 | 圖片及截圖轉 Excel 表格 AI 識別神器 | 圖片 OCR 識別表格結構，資料匯出為 Excel |
|
||||
| 5 | 多源異構資料知識圖譜自動化構建 | 多資料來源接入，實體和關係抽取；圖資料庫儲存 |
|
||||
| 6 | 資料包表智慧解讀與趨勢分析助手 | 上傳資料包表圖片或輸入資料，VLM 解讀圖表內容並分析趨勢 |
|
||||
| 7 | 資料庫表結構智慧解讀與查詢示例生成助手 | 輸入表名或欄位描述，LLM 生成建表說明和示例查詢 SQL |
|
||||
| 8 | 企業主資料智慧對齊與 AI 去重治理 | 多源主資料匹配，重複記錄識別；合併規則配置 |
|
||||
| 9 | 資料需求文件智慧轉測試用例工具 | 輸入資料需求描述，LLM 生成測試場景和驗證用例 |
|
||||
| 10 | 資料指標口徑智慧問答助手 | 基於指標定義文件構建知識庫，LLM 解答指標口徑、計算邏輯等問題 |
|
||||
@@ -0,0 +1,496 @@
|
||||
---
|
||||
title: '用 Jobs to Be Done 找到使用者真正想完成的事'
|
||||
description: '面向零基礎讀者的 Jobs to Be Done 入門文章。理解使用者不是在買功能，而是在特定場景裡“僱用”你的產品完成進展，並學會用 JTBD 拆解產品方向、訪談問題與 AI 提示詞。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 小時</strong>'
|
||||
</script>
|
||||
|
||||
# 用 Jobs to Be Done 找到使用者真正想完成的事
|
||||
|
||||
<a id="top-jtbd"></a>
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['JTBD', '使用者需求', '產品思維', '需求洞察']"
|
||||
coreOutput="1 條更像真實需求的 JTBD 句子"
|
||||
expectedOutput="能把模糊點子收成一個更具體的使用者場景和 MVP 方向"
|
||||
>
|
||||
|
||||
很多人剛開始做產品時，最容易犯的一個錯誤是把注意力全部放在“我要做什麼功能”上。看別人有智慧分類，你也想加；看別人有自動總結，你也想接；看別人做了 Agent、多模態、工作流，你也覺得自己不能少。
|
||||
|
||||
但現實裡，使用者很少是因為“這個功能名字很酷”才決定用一個產品。他們更多是在某個具體時刻，想把一件事情推進下去，於是臨時“僱用”了一個工具、一個服務，甚至一個人，來幫自己完成這一步。
|
||||
|
||||
這正是 **Jobs to Be Done（JTBD）** 這套方法想提醒我們的事情：**使用者不是在購買功能本身，而是在僱用某種解決方案，幫助自己完成一個進展。**
|
||||
|
||||
本篇文章會用盡量直白的語言，帶你從零理解 JTBD，並把它變成你做 AI 應用時能直接拿來用的分析工具。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完後，你會更清楚怎樣把一個模糊點子，收成一句真正有使用者場景的需求，而不是腦子裡只有一堆功能名。
|
||||
|
||||
**行動項**：寫 1 句模糊點子，找 3 個潛在使用者聊“最近一次怎麼處理”，再整理成 1 條 JTBD 句子。
|
||||
|
||||
**結果**：你會得到一個更清楚的需求假設，知道第一版該先解決什麼。
|
||||
|
||||
**關鍵詞跳轉**：[JTBD 是什麼](#jtbd-what) · [一句話公式](#jtbd-formula) · [AI 怎麼幫你](#jtbd-ai)
|
||||
:::
|
||||
|
||||
## 你將學到以下內容
|
||||
|
||||
1. 什麼是 Jobs to Be Done，為什麼它比“功能腦暴”更接近真實需求
|
||||
2. 如何區分“使用者說想要的功能”和“使用者真正想完成的事”
|
||||
3. 怎樣用一套簡單模板，把一個模糊點子拆成場景、觸發、障礙和成功標準
|
||||
4. 如何把 JTBD 用在 AI 產品、訪談提問和提示詞整理裡
|
||||
|
||||
<a id="jtbd-what"></a>
|
||||
## [1. 什麼是 Jobs to Be Done](#top-jtbd)
|
||||
|
||||
Jobs to Be Done 常被簡稱為 **JTBD**。它背後的核心想法，和 Clayton Christensen 團隊推廣的那句經典表達有關：**使用者會“僱用”某個產品來完成一件事。**
|
||||
|
||||
這裡的“事”，不是待辦清單裡那種表面動作，而是使用者希望自己狀態發生的一種 **進展** 。比如：
|
||||
|
||||
- 不是“我要一個 AI 紀要工具”，而是“我想在會後 10 分鐘內把重點、待辦和責任人整理清楚，別再靠回憶補筆記”
|
||||
- 不是“我要一個記賬 App”，而是“我想知道錢到底花去哪了，好讓我月底別再焦慮”
|
||||
- 不是“我要一個簡歷最佳化器”，而是“我想更有把握地投出一份像樣的簡歷，不想每次投遞都懷疑自己寫得太差”
|
||||
|
||||
所以，**JTBD 關注的不是產品長什麼樣，而是使用者為什麼在這個時刻需要它。**
|
||||
|
||||
這也是為什麼很多看似不同的產品，實際上在競爭同一個 job。使用者想“在上班路上不那麼無聊”，可僱用的物件可能是短影片、播客、遊戲、聊天，甚至打瞌睡。使用者想“快速搞懂一份很長的 PDF”，可僱用的物件可能是 AI 摘要工具、實習生、同事、自己硬著頭皮看，或者乾脆先不看。
|
||||
|
||||
一旦你用這種視角看問題，你會發現自己真正的競爭對手，往往並不只是“另一個長得像你的 App”，而是 **使用者當前所有可接受的替代方案** 。
|
||||
|
||||
## 2. JTBD 和使用者畫像、功能列表有什麼不同
|
||||
|
||||
很多新手剛開始做需求分析時，會先寫使用者畫像：25 歲，女生，一線城市，白領，喜歡效率工具，願意嘗試新產品。這樣的資訊不能說完全沒用，但它通常 **不夠解釋一個人為什麼會在此刻採取行動。**
|
||||
|
||||
JTBD 更關心的是下面這些問題：
|
||||
|
||||
- 他是在什麼場景下決定找解決方案的
|
||||
- 當時到底卡住了什麼
|
||||
- 他想把什麼事情推進到下一步
|
||||
- 現在正在用什麼笨辦法撐著
|
||||
- 如果事情解決得好，什麼結果會讓他覺得“值了”
|
||||
|
||||
也就是說，**使用者畫像更像“這個人大概是誰”，JTBD 更像“這個人現在到底想完成什麼”。**
|
||||
|
||||
同樣地，功能列表也容易把人帶偏。使用者說“我想要匯出 Word”“我想要 AI 改寫”“我想要語音輸入”，這些都只是表層表達。JTBD 會繼續往下追問：
|
||||
|
||||
- 為什麼你現在需要匯出 Word，而不是 PDF？
|
||||
- 你想改寫，是因為文風太差，還是因為需要適配不同物件？
|
||||
- 你想語音輸入，是因為懶得打字，還是因為你經常在走路、開車、開會後馬上記錄？
|
||||
|
||||
很多時候，**功能只是 job 的一種臨時翻譯** 。如果你只收集功能，很容易把產品做成“使用者說什麼就堆什麼”；如果你能看見背後的 job，才更有機會做出真正順手、真正有競爭力的方案。
|
||||
|
||||
## 3. 一個零基礎也能理解的例子
|
||||
|
||||
先不要急著想複雜的 AI 產品，我們從一個生活例子開始。
|
||||
|
||||
假設有人早上出門前總來不及喫早餐，於是經常在地鐵口買一個三明治和咖啡。表面上看，他“購買”的是早餐；但如果用 JTBD 看，他真正想完成的事可能是：
|
||||
|
||||
- 在趕時間的早晨，用最省腦力的方式解決一頓飯
|
||||
- 讓自己在到公司前不至於餓得發慌
|
||||
- 不因為喫早餐耽誤通勤節奏
|
||||
|
||||
這時候，使用者僱用的不是“某個固定品牌的三明治”，而是一個能幫他把早晨順利推進下去的解決方案。如果隔壁便利店更快、更近、更穩定，他可能立刻換掉原來的選擇。
|
||||
|
||||
把這個邏輯搬到 AI 產品裡就更明顯了。
|
||||
|
||||
比如你想做一個“AI 會議紀要工具”。如果只停在功能層面，你會很容易開始想：
|
||||
|
||||
- 要不要支援上傳音訊
|
||||
- 要不要接入說話人分離
|
||||
- 要不要匯出 Markdown
|
||||
- 要不要自動生成待辦
|
||||
|
||||
這些都沒錯，但還不夠。用 JTBD 再問一層，使用者真正想完成的可能是：
|
||||
|
||||
- 我想在會後 10 分鐘內，把討論結果同步給沒參會的人
|
||||
- 我想把待辦、責任人和截止時間提幹淨，別讓團隊靠記憶協作
|
||||
- 我想減少重複整理會議內容的時間，把精力留給決策和推進
|
||||
|
||||
一旦 job 被說清楚，很多功能優先順序就會自動浮出來。第一版最重要的也許不是“支援 12 種匯出格式”，而是：
|
||||
|
||||
- 紀要結構要足夠清楚
|
||||
- 待辦提取要穩定
|
||||
- 分享連結要方便
|
||||
- 輸出結果要讓人敢直接轉發給團隊
|
||||
|
||||
這就是 JTBD 的價值：**它能幫助你從“我要堆哪些能力”回到“我要幫使用者推進什麼進展”。**
|
||||
|
||||
## 4. 一個好用的 JTBD 模板
|
||||
|
||||
如果你是零基礎，可以先不要試圖把 JTBD 想得很學術。先抓住最實用的 5 個要素就夠了。
|
||||
|
||||
### 4.1 場景
|
||||
|
||||
使用者是在什麼時刻、什麼環境裡想起這個產品的？
|
||||
|
||||
- 是開完會以後
|
||||
- 是老闆臨時要材料的時候
|
||||
- 是晚上準備投簡歷的時候
|
||||
- 是月底發現錢又不夠花的時候
|
||||
|
||||
**沒有場景的需求，通常都還不夠真實。**
|
||||
|
||||
### 4.2 觸發
|
||||
|
||||
是什麼讓他決定立刻找解決方案？
|
||||
|
||||
- 被長文件壓住，不知道從哪開始看
|
||||
- 明天要交材料，今天才發現格式亂七八糟
|
||||
- 剛被領導追問進度，意識到自己沒有整理清楚
|
||||
- 想堅持記錄，但手寫、複製、整理都太麻煩
|
||||
|
||||
觸發點往往帶著情緒。這個情緒很重要，因為它決定了使用者為什麼會在這一刻產生行動。
|
||||
|
||||
### 4.3 想完成的進展
|
||||
|
||||
他不只是想“做個動作”，而是想把自己推進到什麼新狀態？
|
||||
|
||||
- 從混亂到清楚
|
||||
- 從焦慮到安心
|
||||
- 從拖延到啟動
|
||||
- 從低效到順手
|
||||
- 從說不明白到能直接交付
|
||||
|
||||
這一步裡，“進展”這個詞非常關鍵。因為很多人真正買的不是工具，而是 **狀態變化** 。
|
||||
|
||||
### 4.4 當前替代方案
|
||||
|
||||
現在沒有你的產品時，他怎麼做？
|
||||
|
||||
- 手工複製貼上
|
||||
- 用 Excel 或備忘錄硬撐
|
||||
- 找同事幫忙
|
||||
- 拖著不做
|
||||
- 在幾個工具之間來回切
|
||||
|
||||
誰是替代方案，誰就是你的真實競爭環境。
|
||||
|
||||
### 4.5 成功標準
|
||||
|
||||
事情怎樣纔算真的被解決？
|
||||
|
||||
- 10 分鐘內得到可分享的結果
|
||||
- 不需要二次大改就能發給別人
|
||||
- 不容易漏項、出錯、忘事
|
||||
- 第一次用就知道下一步怎麼走
|
||||
|
||||
如果你連“使用者怎麼判斷值不值”都說不清，那這個方向大機率還沒有收斂好。
|
||||
|
||||
<a id="jtbd-formula"></a>
|
||||
## [5. 直接套用的一句話公式](#top-jtbd)
|
||||
|
||||
當你想梳理一個產品方向時，可以先套這個非常實用的句式：
|
||||
|
||||
> 當 __________ 的時候，我想要 __________，以便於 __________。
|
||||
> 現在我只能透過 __________ 來勉強完成這件事。
|
||||
|
||||
比如：
|
||||
|
||||
> 當我開完一場資訊量很大的專案會時，我想要快速得到一份帶待辦、責任人和截止時間的紀要，以便於我能馬上同步團隊並推進執行。
|
||||
> 現在我只能靠自己回憶、翻聊天記錄和手工整理來勉強完成這件事。
|
||||
|
||||
再比如：
|
||||
|
||||
> 當我準備投遞一個新崗位時，我想要快速把已有經歷改寫成更貼合崗位的版本，以便於我能更有把握地投出一份像樣的簡歷。
|
||||
> 現在我只能反覆複製舊簡歷、手改措辭，改到最後越來越不確定。
|
||||
|
||||
如果你能把一句話寫到這種清晰程度，後面的頁面設計、提示詞設計、功能優先順序判斷，都會容易很多。
|
||||
|
||||
## 6. 做 AI 產品時，特別要看的三層 job
|
||||
|
||||
很多 AI 產品在功能演示時看上去很強，但真正上線之後卻留不住人，常見原因是隻解決了表層動作，沒有解決更深的 job。
|
||||
|
||||
你可以把一個 job 粗略分成三層來看：
|
||||
|
||||
### 6.1 功能層
|
||||
|
||||
最表面的任務是什麼？
|
||||
|
||||
- 總結文件
|
||||
- 改寫文案
|
||||
- 提取待辦
|
||||
- 生成圖片
|
||||
|
||||
這是使用者嘴上最容易說出來的一層。
|
||||
|
||||
### 6.2 情緒層
|
||||
|
||||
使用者希望減少什麼不舒服，或者獲得什麼感受？
|
||||
|
||||
- 不想那麼慌
|
||||
- 不想顯得不專業
|
||||
- 不想每次都從零開始
|
||||
- 想更有掌控感
|
||||
|
||||
很多付費意願，實際上和情緒層關係很大。
|
||||
|
||||
### 6.3 社會層
|
||||
|
||||
使用者希望在別人眼裡變成什麼樣？
|
||||
|
||||
- 看起來更靠譜
|
||||
- 在團隊裡更有組織能力
|
||||
- 在客戶面前更專業
|
||||
- 在社交平臺上更會表達
|
||||
|
||||
如果你只做功能層，產品很容易被替代；如果你同時理解了情緒層和社會層，你就更容易找到真正有黏性的價值。
|
||||
|
||||
## 7. 用 JTBD 反過來篩產品方向
|
||||
|
||||
有時候不是你已經有產品，而是你手裡有 3 到 5 個點子，不知道做哪個。這時 JTBD 很適合拿來做篩選。
|
||||
|
||||
你可以拿著每個點子，分別問自己 5 個問題：
|
||||
|
||||
1. 這個點子對應的場景是不是足夠具體？
|
||||
2. 使用者現在是否已經在用某種笨辦法解決？
|
||||
3. 這個 job 的痛感是否足夠強，或者足夠高頻？
|
||||
4. 如果我做好了，使用者會不會明顯感受到“狀態變好了”？
|
||||
5. 第一版能不能只圍繞這個 job 的關鍵一步，做出一個很小但有用的版本？
|
||||
|
||||
如果一個方向講到最後還是隻能說“感覺挺有意思”，卻說不清觸發、替代方案和成功標準，那它大機率還只是一個模糊靈感，不是一個成熟方向。
|
||||
|
||||
## 8. 可以直接拿去訪談使用者的問題
|
||||
|
||||
很多人一做調研就問：“你想要什麼功能？”這種問法很容易得到表面答案。
|
||||
|
||||
JTBD 更適合問下面這些問題：
|
||||
|
||||
- 最近一次你遇到這個問題是什麼時候？
|
||||
- 當時你在做什麼，為什麼會卡住？
|
||||
- 你最後是怎麼解決的？
|
||||
- 這個過程裡最煩、最慢、最不放心的地方是什麼？
|
||||
- 如果有一個工具能幫你，什麼結果會讓你覺得真的有用？
|
||||
- 你試過哪些替代方法？為什麼它們不夠好？
|
||||
|
||||
這種問法有個好處：它會把對話拉回真實經歷，而不是停留在想象中的偏好。
|
||||
|
||||
## 9. 用 AI 幫你做 JTBD 拆解
|
||||
|
||||
JTBD 本身不是 AI 發明的，但 AI 很適合幫你整理和提煉 JTBD。
|
||||
|
||||
比如你已經收集了 5 到 10 條使用者反饋，就可以把它們丟給模型，讓它按以下結構總結：
|
||||
|
||||
```text
|
||||
請你扮演產品研究助手。
|
||||
我會給你一些使用者原話，請你不要先給功能建議，
|
||||
而是先按 Jobs to Be Done 的框架整理：
|
||||
|
||||
1. 使用者處在什麼場景
|
||||
2. 觸發他採取行動的事件是什麼
|
||||
3. 他真正想完成的進展是什麼
|
||||
4. 當前替代方案是什麼
|
||||
5. 他最在意的成功標準是什麼
|
||||
6. 這些反饋裡反覆出現的情緒詞有哪些
|
||||
|
||||
最後，請把這些內容整理成 3 個最值得優先驗證的 JTBD 假設。
|
||||
```
|
||||
|
||||
如果你已經有一個點子，也可以讓 AI 幫你做第一輪收斂：
|
||||
|
||||
```text
|
||||
我想做一個 [你的產品想法]。
|
||||
請不要直接給我功能列表，而是用 Jobs to Be Done 方法幫我分析：
|
||||
|
||||
1. 這個產品可能服務哪些具體場景
|
||||
2. 每個場景中使用者想完成的核心 job 是什麼
|
||||
3. 現有替代方案有哪些
|
||||
4. 哪個 job 最適合作為 MVP 的起點，為什麼
|
||||
5. 請把最終推薦的 job 寫成一句清晰的 JTBD 句子
|
||||
```
|
||||
|
||||
這樣做的好處是，你不會一上來就被 AI 帶去“腦暴 50 個功能”，而是先把方向講清楚。
|
||||
|
||||
## 10. 新手最常見的 4 個誤區
|
||||
|
||||
### 10.1 把 job 寫成功能名
|
||||
|
||||
“AI 總結”“智慧分類”“自動生成”都不是 job，它們只是可能的實現方式。
|
||||
|
||||
### 10.2 把人羣寫得很寬
|
||||
|
||||
“所有職場人”“所有學生”“所有創業者”通常都太泛。越泛，你越難看見真實場景。
|
||||
|
||||
### 10.3 只聽使用者說，不看使用者怎麼做
|
||||
|
||||
使用者會描述自己想要什麼，但他真正的優先順序，常常藏在他現在如何湊合解決問題裡。
|
||||
|
||||
### 10.4 一開始就想做完整平臺
|
||||
|
||||
JTBD 的正確開啟方式，通常不是“我來做一個包打天下的大平臺”，而是先盯住一個場景裡最關鍵的一步，把它做到非常順手。
|
||||
|
||||
## 11. 小結
|
||||
|
||||
Jobs to Be Done 最有價值的地方，不是給你一個新名詞，而是幫你換一個觀察角度：**不要只盯著產品功能，而要盯著使用者想把什麼事情推進到下一步。**
|
||||
|
||||
當你開始反覆問自己：
|
||||
|
||||
- 使用者是在什麼場景下僱用這個產品的
|
||||
- 他到底卡在了哪裡
|
||||
- 現在正用什麼辦法硬撐
|
||||
- 事情解決後，狀態會發生什麼變化
|
||||
|
||||
你會發現，很多原本模糊的點子一下子變清楚了，很多原本很花哨的功能也一下子沒那麼重要了。
|
||||
|
||||
做產品，尤其是做 AI 產品，最怕的是一開始就沉迷能力展示。JTBD 能幫你把注意力拉回到真正重要的地方：**使用者為什麼需要你，以及你到底在幫他完成什麼進展。**
|
||||
|
||||
<a id="jtbd-ai"></a>
|
||||
## [12. 如何利用 AI 幫你實踐 JTBD](#top-jtbd)
|
||||
|
||||
JTBD 不是 AI 發明的，但 AI 很適合在這套方法裡當你的研究助手、整理助手和對照助手。關鍵是：**讓 AI 幫你整理和擴充套件，而不是替你臆測使用者。**
|
||||
|
||||
你可以這樣用：
|
||||
|
||||
### 12.1 讓 AI 幫你把模糊點子改寫成 JTBD 假設
|
||||
|
||||
當你腦子裡只有一句模糊描述，比如“我想做一個幫大學生找實習的工具”，可以先讓 AI 幫你把它拆成幾種可能的 job：
|
||||
|
||||
```text
|
||||
我現在有一個模糊產品點子：[你的點子]
|
||||
請不要直接給我功能列表，而是用 Jobs to Be Done 的方式幫我分析：
|
||||
1. 可能對應哪些具體場景
|
||||
2. 每個場景裡使用者真正想完成的進展是什麼
|
||||
3. 當前替代方案可能是什麼
|
||||
4. 哪個 job 最適合先做 MVP
|
||||
請最後把每個 job 寫成一句清晰的 JTBD 句子。
|
||||
```
|
||||
|
||||
你甚至可以把輸入寫得很小白：
|
||||
|
||||
```text
|
||||
我想做一個幫大學生找實習的東西。
|
||||
我現在也說不清具體是做什麼，你幫我想想使用者到底想完成什麼事。
|
||||
```
|
||||
|
||||
AI 可能給出的有用輸出會像這樣：
|
||||
|
||||
```text
|
||||
可能的 JTBD 方向：
|
||||
|
||||
1. 當我第一次準備投實習時，我想快速知道應該先準備哪些材料，
|
||||
以便我不要因為資訊混亂一直拖著不投。
|
||||
|
||||
2. 當我看到一個實習崗位時，我想快速判斷自己是否值得投，
|
||||
以便我不要在不合適的崗位上浪費太多時間。
|
||||
|
||||
3. 當我開始投遞時，我想把現有簡歷改成更貼合崗位的版本，
|
||||
以便我能更快完成投遞並提高透過率。
|
||||
```
|
||||
|
||||
這種輸出的價值在於，它會把你原本一句很泛的想法，拆成幾個更接近真實場景的方向。
|
||||
|
||||
### 12.2 讓 AI 幫你整理訪談原話
|
||||
|
||||
如果你已經做了幾次使用者訪談，可以把訪談記錄交給 AI，讓它幫你提煉反覆出現的場景、觸發點、替代方案和成功標準。
|
||||
|
||||
```text
|
||||
下面是 5 位使用者的訪談原話。
|
||||
請不要先給解決方案，而是按 JTBD 框架整理：
|
||||
1. 使用者處在什麼場景
|
||||
2. 觸發他採取行動的事件是什麼
|
||||
3. 他真正想完成的進展是什麼
|
||||
4. 當前替代方案是什麼
|
||||
5. 他最在意的成功標準是什麼
|
||||
6. 哪些資訊在多位使用者中重複出現
|
||||
最後整理成 3 條最值得優先驗證的 JTBD 假設。
|
||||
```
|
||||
|
||||
一個很簡單的小白輸入也可以這樣寫：
|
||||
|
||||
```text
|
||||
我問了 3 個人，他們大概是這樣說的：
|
||||
|
||||
1. 每次要投實習我都得重新改簡歷，特別煩。
|
||||
2. 我其實最怕的是不知道自己寫得對不對。
|
||||
3. 我現在會先找學長學姐幫我看，但每次都不好意思總麻煩別人。
|
||||
|
||||
你幫我整理一下，他們真正想完成的事情是什麼。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
整理結果：
|
||||
|
||||
- 共同場景：準備投遞實習前，需要處理簡歷
|
||||
- 共同困難：不知道如何修改到“夠好”
|
||||
- 當前替代方案：找學長學姐幫看，自己反覆修改
|
||||
- 可能的 JTBD：
|
||||
當我準備投遞實習時，我想更快判斷簡歷是否已經達到可投遞水平，
|
||||
以便我不要一直卡在“再改一改”而遲遲投不出去。
|
||||
```
|
||||
|
||||
這種輸出很有用，因為它幫你從零散原話裡提煉出更像“需求”的東西。
|
||||
|
||||
### 12.3 讓 AI 幫你做一輪輕量級網路調研
|
||||
|
||||
在你還沒開始大規模訪談前，可以先讓 AI 幫你做一些很輕的外部資訊掃描，比如：
|
||||
|
||||
- 公開論壇或社羣裡，大家是怎麼抱怨這個問題的
|
||||
- 市面上已有產品主要在解決哪一層問題
|
||||
- 使用者最常見的替代方案是什麼
|
||||
- 常見評價裡，大家最滿意和最不滿意的點是什麼
|
||||
|
||||
這種調研不能代替真實使用者訪談，但很適合作為 Discover 階段的熱身，幫你先建立問題地圖。
|
||||
|
||||
一個簡單輸入可以是：
|
||||
|
||||
```text
|
||||
請你幫我查一查：
|
||||
“大學生改簡歷、投實習時最常見的痛點是什麼？”
|
||||
優先看公開論壇、經驗帖、求職社羣裡大家自己說的話。
|
||||
幫我整理成 5 條最常見問題。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
常見痛點整理：
|
||||
|
||||
1. 不知道簡歷該寫什麼，經歷太少
|
||||
2. 不知道怎麼針對不同崗位修改
|
||||
3. 改了很多版，但始終不確定是否夠好
|
||||
4. 找不到可靠的人幫忙看
|
||||
5. 投遞流程複雜，容易拖延
|
||||
```
|
||||
|
||||
這類輸出不能當最終結論，但很適合幫你先決定要優先訪談哪類問題。
|
||||
|
||||
### 12.4 讓 AI 充當“反方”
|
||||
|
||||
很多時候，我們會對自己的想法太有感情。你可以專門讓 AI 扮演一個挑刺的人，逼你把問題說得更清楚：
|
||||
|
||||
```text
|
||||
請你扮演一個非常嚴格的產品研究顧問。
|
||||
下面是我的 JTBD 假設：[你的假設]
|
||||
請從以下角度批判它：
|
||||
1. 這個場景是否過寬
|
||||
2. 這個 job 是否寫成了功能而不是真正進展
|
||||
3. 替代方案是否太弱
|
||||
4. 成功標準是否不夠清楚
|
||||
5. 這個假設最需要被驗證的風險是什麼
|
||||
```
|
||||
|
||||
這樣做的好處是，你能更快發現自己是在看需求，還是只是在看自己喜歡的方案。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
請你根據上文內容，完成下列作業：
|
||||
|
||||
1. 選一個你最近想做的產品點子，用一句 JTBD 公式把它寫清楚
|
||||
2. 為這個點子補齊 5 個要素：場景、觸發、進展、替代方案、成功標準
|
||||
3. 找 3 個潛在使用者，至少問出一次“最近一次你遇到這個問題是什麼時候”
|
||||
4. 把訪談原話交給 AI，整理成 3 條最值得優先驗證的 JTBD 假設
|
||||
|
||||
## 延伸閱讀
|
||||
|
||||
- [Christensen Institute: Jobs to Be Done](https://www.christenseninstitute.org/theory/jobs-to-be-done/)
|
||||
- [Harvard Business School Online: What Is Jobs to Be Done?](https://online.hbs.edu/blog/post/jobs-to-be-done)
|
||||
- [Intercom: Jobs-to-be-Done: A framework for customer needs](https://www.intercom.com/blog/jobs-to-be-done-framework/)
|
||||
- [Mural: Jobs to Be Done framework guide](https://www.mural.co/blog/jobs-to-be-done-framework)
|
||||
@@ -0,0 +1,589 @@
|
||||
---
|
||||
title: 'The Mom Test：如何透過使用者訪談驗證需求'
|
||||
description: '面向零基礎讀者的 The Mom Test 入門文章。學會避免禮貌性反饋，圍繞真實行為、具體事實和已有問題做使用者訪談，把“聽起來不錯”變成更可靠的需求判斷。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
const duration = '約 <strong>1.5 小時</strong>'
|
||||
</script>
|
||||
|
||||
# The Mom Test：如何透過使用者訪談驗證需求
|
||||
|
||||
<a id="top-mom"></a>
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction
|
||||
:duration="duration"
|
||||
:tags="['使用者訪談', '需求驗證', '使用者研究', '產品調研']"
|
||||
coreOutput="1 組更能問出真實資訊的訪談問題"
|
||||
expectedOutput="不再把使用者的禮貌性鼓勵當成驗證，而能用真實行為判斷方向"
|
||||
>
|
||||
|
||||
很多人第一次做產品調研時，以為最重要的是“找人聊聊”。於是他們去問朋友、同事，甚至家人：
|
||||
|
||||
- 你覺得我這個想法怎麼樣？
|
||||
- 如果有這樣一個產品，你會不會用？
|
||||
- 這個功能聽起來是不是還不錯？
|
||||
|
||||
對方往往也會給出非常鼓舞人的反饋：
|
||||
|
||||
- 挺好的啊
|
||||
- 聽起來很有用
|
||||
- 我覺得你可以試試
|
||||
|
||||
問題在於，這些回答通常並不能幫你做判斷。它們更像是禮貌、支援，或者一種不想當場掃你興的自然反應。你以為自己得到了“市場驗證”，其實只是收集了一堆很難用來決策的安慰。
|
||||
|
||||
The Mom Test 這套方法，就是專門用來解決這個問題的。它提醒我們：**不是使用者在故意騙你，而是你問問題的方式，天然會把對方引向好聽但沒用的回答。**
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info 最小 SOP
|
||||
**目的**：看完後，你會更清楚怎麼和使用者聊天，纔不會只聽到“聽起來不錯”，而是真的問出能幫你判斷方向的資訊。
|
||||
|
||||
**行動項**：把你原本想問的 5 個問題改掉，優先問“最近一次發生在什麼時候”“你當時怎麼處理”。
|
||||
|
||||
**結果**：你會更容易分清哪些是意見，哪些纔是真正能支撐判斷的證據。
|
||||
|
||||
**關鍵詞跳轉**：[The Mom Test 是什麼](#mom-what) · [三個核心原則](#mom-principles) · [AI 怎麼幫你](#mom-ai)
|
||||
:::
|
||||
|
||||
## 你將學到以下內容
|
||||
|
||||
1. The Mom Test 到底在解決什麼問題，為什麼很多“使用者調研”其實沒有調研到真實資訊
|
||||
2. 這套方法最核心的幾個原則：少問意見，多問行為；少問假設，多問事實
|
||||
3. 怎樣把一個容易得到假陽性反饋的問題，改成更有價值的訪談問題
|
||||
4. 如何把 The Mom Test 和 JTBD、需求驗證、MVP 判斷連起來使用
|
||||
|
||||
<a id="mom-what"></a>
|
||||
## [1. The Mom Test 到底是什麼](#top-mom)
|
||||
|
||||
The Mom Test 來自 Rob Fitzpatrick 的同名書籍。它的名字聽起來有點像玩笑，但點得非常準：
|
||||
|
||||
**就算是你媽媽，也很難直接告訴你“這是個爛想法”。**
|
||||
|
||||
原因不是她不誠實，而是：
|
||||
|
||||
- 她不想傷害你
|
||||
- 她會下意識鼓勵你
|
||||
- 她很容易順著你的表達方式回答
|
||||
|
||||
其實不只是媽媽，朋友、同事、前同學，甚至很多陌生人，在面對你的產品想法時，也常常會給出類似的“正向反饋”。這不代表需求真的存在，只代表你把問題問成了一個很容易得到好聽答案的形式。
|
||||
|
||||
所以，The Mom Test 的重點從來不是“別問媽媽”，而是：
|
||||
|
||||
**別把問題問成任何人都會順著你回答的樣子。**
|
||||
|
||||
這套方法真正想教你的，是如何透過對話，拿到更接近真實需求的資訊，而不是收集一堆讓自己感覺良好的評論。
|
||||
|
||||
## 2. 它解決的核心問題是什麼
|
||||
|
||||
The Mom Test 主要解決的是一種非常常見的認知錯覺：
|
||||
|
||||
**把禮貌性的積極反饋，當成真實需求。**
|
||||
|
||||
比如你問：
|
||||
|
||||
- 你覺得這個 App 想法怎麼樣？
|
||||
- 如果我做一個 AI 幫你寫簡歷的工具，你會用嗎？
|
||||
- 這個功能是不是很有價值？
|
||||
|
||||
這些問題的共同特點是：
|
||||
|
||||
- 它們都在問“意見”
|
||||
- 它們都帶著一點暗示
|
||||
- 它們都在談一個還沒發生的未來
|
||||
|
||||
而人對“意見”和“未來假設”的回答，通常都不穩定。很多人會高估自己的興趣、高估自己的執行力，也會高估自己未來的購買意願。
|
||||
|
||||
所以 The Mom Test 提醒你：
|
||||
|
||||
- 不要太相信別人對你點子的評價
|
||||
- 不要太相信別人對未來行為的預測
|
||||
- 要儘量回到使用者已經發生過的真實行為裡
|
||||
|
||||
因為和“你會不會用”相比，“你上次怎麼處理這件事的”往往更接近真相。
|
||||
|
||||
<a id="mom-principles"></a>
|
||||
## [3. 三個最核心的原則](#top-mom)
|
||||
|
||||
如果你只想先記住最重要的部分，可以先記下面這三個原則。
|
||||
|
||||
### 3.1 少談你的點子，多談使用者過去的真實經歷
|
||||
|
||||
很多無效訪談一開場就講自己的方案，講自己多麼興奮，講自己準備做什麼產品。問題是，一旦你講得太多，對方就很容易切換到“配合你”“鼓勵你”的狀態。
|
||||
|
||||
相比之下，更好的方式是把重點放在對方的經歷上：
|
||||
|
||||
- 最近一次遇到這個問題是什麼時候？
|
||||
- 當時你在做什麼？
|
||||
- 你最後是怎麼處理的？
|
||||
- 哪一步最麻煩？
|
||||
|
||||
你會發現，這類問題能更自然地把對話帶回現實，而不是停留在想象中的偏好。
|
||||
|
||||
### 3.2 少問抽象意見，多問具體事實
|
||||
|
||||
“我覺得這個功能挺好”“聽起來不錯”“好像有點用”，這些表達都太抽象了，很難指導產品決策。
|
||||
|
||||
更有價值的資訊通常長這樣：
|
||||
|
||||
- 我上週剛為了這件事折騰了 2 小時
|
||||
- 我現在是用 Excel 加微信硬撐
|
||||
- 我上個月已經為類似工具花過錢
|
||||
- 我最怕的是做錯，不是做慢
|
||||
|
||||
這些纔是真正能幫你判斷問題強度、頻率和付費可能性的資訊。
|
||||
|
||||
### 3.3 少問使用者想要什麼方案，多看他現在怎麼解決問題
|
||||
|
||||
使用者很擅長描述自己的困擾，但不一定擅長設計解決方案。
|
||||
|
||||
如果你問：
|
||||
|
||||
- 你想不想要一個 AI 幫你自動做這個？
|
||||
- 你覺得加個智慧功能有沒有幫助？
|
||||
|
||||
你得到的，通常只是對某個方案的模糊態度，而不是需求本身。
|
||||
|
||||
更好的問題是：
|
||||
|
||||
- 你現在用什麼方法處理這個問題？
|
||||
- 為什麼你會選擇這種方式？
|
||||
- 它哪裡不夠好？
|
||||
|
||||
看清現有替代方案，往往比直接問“你想要什麼”更重要。
|
||||
|
||||
## 4. 為什麼人們總會給你好聽但沒用的回答
|
||||
|
||||
如果你能理解這件事，做訪談時就會少很多誤判。
|
||||
|
||||
### 4.1 人會下意識地保持禮貌
|
||||
|
||||
尤其當對話物件和你有關係時，對方很難直接說：
|
||||
|
||||
- 這個方向聽起來不太行
|
||||
- 我根本不會用
|
||||
- 這個問題對我沒那麼重要
|
||||
|
||||
他更可能說“挺好的”“有機會可以做做看”。
|
||||
|
||||
### 4.2 人會高估未來的自己
|
||||
|
||||
很多人真心相信自己未來會：
|
||||
|
||||
- 更自律
|
||||
- 更願意學習
|
||||
- 更願意付費
|
||||
- 更願意嘗試新工具
|
||||
|
||||
所以“如果有的話我應該會用”這句話，常常並不等於未來真的會用。
|
||||
|
||||
### 4.3 你的提問方式本身就在引導答案
|
||||
|
||||
當你問：
|
||||
|
||||
- 我這個想法是不是挺好？
|
||||
- 這個功能對你來說是不是很有幫助？
|
||||
|
||||
你其實已經偷偷把“正確答案”塞進問題裡了。
|
||||
|
||||
這也是為什麼 The Mom Test 特別強調：**不要把訪談做成你在尋找認可。**
|
||||
|
||||
## 5. 直接對比：什麼問題容易問廢，什麼問題更有價值
|
||||
|
||||
下面這些對照，幾乎是每個新手都會用到的。
|
||||
|
||||
| 容易問廢的問題 | 更有價值的問題 |
|
||||
| --- | --- |
|
||||
| 你覺得我這個想法怎麼樣？ | 你最近一次遇到這個問題是什麼時候？ |
|
||||
| 如果有這個產品你會用嗎？ | 你現在是怎麼處理這件事的？ |
|
||||
| 你願意為這個功能付費嗎？ | 你上次為了這個問題花過錢嗎？花在什麼上？ |
|
||||
| 你覺得這個功能重要嗎？ | 這個流程裡最煩、最慢、最不放心的是哪一步？ |
|
||||
| 你想不想要一個 AI 幫你自動做？ | 你現在為什麼還沒有找到更順手的解決辦法？ |
|
||||
|
||||
這張表最重要的不是具體句子，而是背後的方向：
|
||||
|
||||
- 從意見走向事實
|
||||
- 從未來走向過去
|
||||
- 從你的方案走向使用者的問題
|
||||
|
||||
## 6. 一個零基礎也能立刻用的訪談節奏
|
||||
|
||||
如果你現在就想去找人聊，可以直接按下面這個順序來。
|
||||
|
||||
### 6.1 開場：說明你在學習，不是在推銷
|
||||
|
||||
比如：
|
||||
|
||||
> 我最近在研究大家怎麼處理這類問題，想先了解真實情況，不是來賣東西的。
|
||||
|
||||
這種表達會讓對方更容易放下“我要給你積極反饋”的心理負擔。
|
||||
|
||||
### 6.2 從最近一次真實經歷開始問
|
||||
|
||||
可以先從這類問題開始：
|
||||
|
||||
- 最近一次遇到這個問題是什麼時候？
|
||||
- 當時發生了什麼？
|
||||
- 你第一反應是怎麼處理的？
|
||||
|
||||
一旦對話進入具體事件，資訊質量通常會明顯提升。
|
||||
|
||||
### 6.3 往下追問行為、成本和替代方案
|
||||
|
||||
繼續問：
|
||||
|
||||
- 你現在用什麼辦法解決？
|
||||
- 這個辦法最不舒服的地方是什麼？
|
||||
- 你為此花過多少時間、錢或者精力？
|
||||
- 你試過別的方法嗎？為什麼沒繼續用？
|
||||
|
||||
### 6.4 最後再判斷痛感和優先順序
|
||||
|
||||
你不需要直接問“痛不痛”，可以從細節裡判斷：
|
||||
|
||||
- 他是不是經常遇到
|
||||
- 他是不是已經在主動補救
|
||||
- 他是不是已經願意為此付出成本
|
||||
- 他在講這件事時是不是帶著明顯情緒
|
||||
|
||||
這些都比一句“這是不是你的痛點”更有用。
|
||||
|
||||
## 7. 一個更完整的例子
|
||||
|
||||
假設你想做一個“AI 幫大學生改簡歷”的產品。
|
||||
|
||||
### 錯誤問法
|
||||
|
||||
你去問同學：
|
||||
|
||||
> 我想做一個 AI 簡歷最佳化工具，你覺得怎麼樣？
|
||||
> 如果它能根據崗位自動改簡歷，你會不會用？
|
||||
|
||||
這時候，對方很可能會說：
|
||||
|
||||
- 聽起來挺好
|
||||
- 我覺得應該有用
|
||||
- 如果免費我會試試
|
||||
|
||||
這些回答幾乎沒有辦法幫你判斷需求到底強不強。
|
||||
|
||||
### 更好的問法
|
||||
|
||||
你可以改成：
|
||||
|
||||
> 你最近一次改簡歷是什麼時候？
|
||||
> 當時為什麼要改？
|
||||
> 你是怎麼改的？
|
||||
> 哪一步最卡？
|
||||
> 你有沒有找過別人幫你看？
|
||||
> 你以前為簡歷這件事花過錢或者花過很多時間嗎？
|
||||
|
||||
透過這些問題，你可能得到的資訊會是：
|
||||
|
||||
- 很多人不是不會寫，而是不知道怎麼針對不同崗位改寫
|
||||
- 他們最痛的不是排版，而是“不知道哪些經歷值得寫”
|
||||
- 他們會拖延，不是因為懶，而是因為每次改簡歷都很消耗
|
||||
- 他們已經在用學長建議、模板網站、AI 工具和朋友幫看來勉強解決
|
||||
|
||||
這時候，你離真實問題就近得多了。
|
||||
|
||||
## 8. The Mom Test 和 JTBD 怎麼配合用
|
||||
|
||||
如果說 JTBD 幫你看清“使用者想完成什麼進展”，那麼 The Mom Test 更像是在教你：
|
||||
|
||||
**怎麼透過訪談，確認這個 job 是不是真的存在。**
|
||||
|
||||
你完全可以把兩者接起來使用：
|
||||
|
||||
1. 先用 JTBD 假設一個 job
|
||||
2. 再用 The Mom Test 的方式，去問使用者最近一次真實經歷
|
||||
3. 看看這個 job 是否真的高頻、真實、值得優先做
|
||||
|
||||
比如你的 JTBD 假設是：
|
||||
|
||||
> 當我準備投遞實習時，我想快速把舊簡歷改成貼合崗位的版本，以便儘快完成投遞。
|
||||
|
||||
那你就可以用 The Mom Test 風格的問題去驗證：
|
||||
|
||||
- 你最近一次投遞是什麼時候？
|
||||
- 當時你是怎麼改簡歷的？
|
||||
- 哪一段最難寫？
|
||||
- 你改完之後怎麼判斷它夠不夠好？
|
||||
|
||||
這樣，方法就連起來了：
|
||||
|
||||
- JTBD 幫你定義需求假設
|
||||
- The Mom Test 幫你訪談驗證假設
|
||||
|
||||
## 9. 新手做使用者訪談時最常見的誤區
|
||||
|
||||
### 9.1 把訪談做成產品介紹會
|
||||
|
||||
你一講太多自己的想法，對方就容易開始配合你，而不是告訴你真實情況。
|
||||
|
||||
### 9.2 訪談物件全是熟人
|
||||
|
||||
熟人不是不能聊，但熟人更容易鼓勵你。你至少需要混合一些更接近真實使用者的人，而不是隻找支援你的人。
|
||||
|
||||
### 9.3 過早追著問功能
|
||||
|
||||
如果你還沒搞清楚問題，就開始追問按鈕、介面、功能細節，通常是在太早進入解決方案。
|
||||
|
||||
### 9.4 把一句“我會用”當成驗證結果
|
||||
|
||||
訪談最多幫你判斷方向，不等於已經完成驗證。真正的驗證，最終還是要看使用者是否願意付出真實成本，比如時間、切換成本、試用行為，甚至付費。
|
||||
|
||||
### 9.5 訪談結束後不整理
|
||||
|
||||
如果你聊完就放著，資訊很快會變成模糊印象。最好儘快整理：
|
||||
|
||||
- 出現頻率高的問題
|
||||
- 使用者原話裡的情緒詞
|
||||
- 當前替代方案
|
||||
- 已經付出的成本
|
||||
- 你自己的新判斷
|
||||
|
||||
## 10. 可以直接複製去用的問題清單
|
||||
|
||||
如果你想盡快開始，這裡有一組足夠通用的問題。
|
||||
|
||||
### 開場問題
|
||||
|
||||
- 最近一次你遇到這個問題是什麼時候？
|
||||
- 當時具體發生了什麼？
|
||||
|
||||
### 行為問題
|
||||
|
||||
- 你當時是怎麼處理的？
|
||||
- 你為什麼會選擇這種方式？
|
||||
|
||||
### 成本問題
|
||||
|
||||
- 這件事一般會花掉你多少時間或精力？
|
||||
- 你有沒有為瞭解決它花過錢？
|
||||
|
||||
### 替代方案問題
|
||||
|
||||
- 你試過別的工具或辦法嗎？
|
||||
- 為什麼最後沒有繼續用？
|
||||
|
||||
### 收尾問題
|
||||
|
||||
- 如果以後還遇到同樣的問題，你覺得最理想的解決方式應該是什麼樣？
|
||||
|
||||
注意，這個收尾問題可以問，但最好放在後面。因為前面你更需要拿到事實，而不是願望。
|
||||
|
||||
## 11. 小結
|
||||
|
||||
The Mom Test 最重要的貢獻，不是給你一套“更會聊天”的技巧，而是幫你建立一種更清醒的判斷方式：
|
||||
|
||||
- 不要太快相信別人對你點子的誇獎
|
||||
- 不要把“如果有我會用”當成真實需求
|
||||
- 不要讓訪談變成你在尋找認可
|
||||
|
||||
真正有價值的訪談，應該儘量回到這些東西上：
|
||||
|
||||
- 使用者最近一次真實經歷
|
||||
- 他現在怎麼處理
|
||||
- 他已經付出了什麼成本
|
||||
- 他在哪些地方明顯不舒服
|
||||
|
||||
當你開始這樣問，你得到的資訊雖然有時沒那麼好聽，但通常更有用。
|
||||
而做產品時，**有用的真相，永遠比好聽的鼓勵更重要。**
|
||||
|
||||
<a id="mom-ai"></a>
|
||||
## [12. 如何利用 AI 幫你做使用者訪談](#top-mom)
|
||||
|
||||
The Mom Test 本質上還是一套“和真人聊”的方法，所以 AI 不能替代真實訪談。但 AI 非常適合在訪談前、中、後給你打輔助，尤其適合幫新手降低門檻。
|
||||
|
||||
### 12.1 讓 AI 幫你把“容易問廢”的問題改寫掉
|
||||
|
||||
很多人知道自己不該問“你覺得我這個想法怎麼樣”，但一開口還是會回到這種句子。你可以先把自己準備問的問題交給 AI，讓它幫你改寫：
|
||||
|
||||
```text
|
||||
下面是我準備做使用者訪談時想問的問題：
|
||||
[貼上你的問題]
|
||||
|
||||
請你用 The Mom Test 的原則幫我改寫：
|
||||
1. 刪掉意見型問題
|
||||
2. 刪掉假設未來的問題
|
||||
3. 儘量改成圍繞過去真實行為、已有替代方案和已付成本的提問
|
||||
4. 最後整理成一套 8-10 個可以直接訪談的問題清單
|
||||
```
|
||||
|
||||
一個很小白的輸入也完全可以：
|
||||
|
||||
```text
|
||||
我想問使用者：
|
||||
1. 你覺得我做一個 AI 改簡歷工具怎麼樣？
|
||||
2. 你會不會用？
|
||||
3. 你願不願意付費？
|
||||
|
||||
請幫我改成更好的問法。
|
||||
```
|
||||
|
||||
AI 可能給出的有用輸出會像這樣：
|
||||
|
||||
```text
|
||||
改寫後的問題：
|
||||
|
||||
1. 你最近一次改簡歷是什麼時候？
|
||||
2. 當時為什麼要改？
|
||||
3. 你是怎麼改的？
|
||||
4. 哪一步最花時間？
|
||||
5. 你有沒有找別人幫你看？
|
||||
6. 你以前有沒有為簡歷修改花過錢或花過很多時間？
|
||||
```
|
||||
|
||||
這種輸出很有幫助，因為它直接把你原本“在問意見”的問題，改成了“在問真實行為”的問題。
|
||||
|
||||
### 12.2 讓 AI 幫你生成不同物件的訪談提綱
|
||||
|
||||
同一個方向，面對不同人羣，訪談重點會不一樣。比如學生、HR、自由職業者，關心點完全不同。你可以讓 AI 幫你針對不同物件各出一版提綱：
|
||||
|
||||
- 面向新手使用者，重點瞭解最近一次真實經歷
|
||||
- 面向重度使用者，重點瞭解替代方案和痛感
|
||||
- 面向付費使用者，重點瞭解是否已經為此付過成本
|
||||
|
||||
這樣你在真正聊天時會更有節奏，而不會每個人都問同一套問題。
|
||||
|
||||
比如你可以直接這樣輸入：
|
||||
|
||||
```text
|
||||
我要聊兩類人：
|
||||
1. 第一次找實習的大學生
|
||||
2. 已經幫別人看過很多簡歷的學長學姐
|
||||
|
||||
請分別給我一套訪談提綱，每套 6 個問題。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
對大學生：
|
||||
1. 最近一次投實習是什麼時候？
|
||||
2. 當時最卡的是哪一步？
|
||||
3. 你怎麼知道自己的簡歷能不能投？
|
||||
...
|
||||
|
||||
對學長學姐：
|
||||
1. 你最近一次幫別人看簡歷是什麼時候？
|
||||
2. 你最常看到哪些明顯問題？
|
||||
3. 學弟學妹最容易卡在哪一步？
|
||||
...
|
||||
```
|
||||
|
||||
這樣一來，你不用自己從零編問題，訪談準備會輕鬆很多。
|
||||
|
||||
### 12.3 讓 AI 幫你整理訪談記錄
|
||||
|
||||
訪談做完之後，最容易出現的問題不是“沒資訊”，而是“資訊太散”。AI 很適合幫你把碎片化對話整理成結構化筆記：
|
||||
|
||||
```text
|
||||
下面是我和 3 位使用者的訪談記錄。
|
||||
請按 The Mom Test 的角度整理：
|
||||
1. 哪些內容是事實，哪些只是意見
|
||||
2. 使用者最近一次真實行為是什麼
|
||||
3. 當前替代方案是什麼
|
||||
4. 使用者已經付出的時間、金錢或精力成本是什麼
|
||||
5. 哪些問題被反覆提到
|
||||
6. 哪些說法聽起來積極，但證據不足
|
||||
```
|
||||
|
||||
這一步尤其有價值，因為它能幫你把“聽起來不錯”的內容和“真的能支撐判斷”的內容分開。
|
||||
|
||||
一個簡單輸入可以是：
|
||||
|
||||
```text
|
||||
這是我和一個使用者聊完後的記錄：
|
||||
|
||||
- 她說如果有個工具應該會試試
|
||||
- 她上週為了改簡歷花了一個晚上
|
||||
- 她現在主要靠朋友幫看
|
||||
- 她說最難的是不知道改到什麼程度算可以投
|
||||
|
||||
請你幫我分一下，哪些是意見，哪些是事實。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
意見：
|
||||
- 如果有個工具應該會試試
|
||||
|
||||
事實：
|
||||
- 上週為了改簡歷花了一個晚上
|
||||
- 當前替代方案是找朋友幫看
|
||||
- 最難點是不知道什麼時候算“可以投”
|
||||
|
||||
可用於判斷需求的重點：
|
||||
- 這個問題最近剛發生過
|
||||
- 使用者已經投入了明顯時間成本
|
||||
- 當前方案依賴他人，不穩定
|
||||
```
|
||||
|
||||
這個輸出就能很直觀地告訴新手：哪些話能拿來做判斷，哪些話只能聽聽。
|
||||
|
||||
### 12.4 讓 AI 先做一輪輕量級網路搜尋
|
||||
|
||||
如果你還沒開始訪談，可以先讓 AI 幫你做一些很輕的外部調研，比如：
|
||||
|
||||
- 公開社羣裡，大家最近是怎麼抱怨這個問題的
|
||||
- 現有工具被吐槽最多的是什麼
|
||||
- 使用者是不是已經為相似問題花過錢
|
||||
- 市場上有哪些替代方案已經存在
|
||||
|
||||
這類資訊不能替代真人訪談，但能幫你更快進入狀態，知道該從哪裡切入問題。
|
||||
|
||||
比如一個簡單輸入可以是：
|
||||
|
||||
```text
|
||||
請你幫我搜一下：
|
||||
“大學生改簡歷時最常吐槽什麼”
|
||||
幫我整理出 5 條最常見抱怨，用很白話的話寫出來。
|
||||
```
|
||||
|
||||
AI 可能輸出：
|
||||
|
||||
```text
|
||||
常見抱怨：
|
||||
|
||||
1. 不知道簡歷上到底該寫什麼
|
||||
2. 每投一個崗位都要改，太累
|
||||
3. 改了很多版還是不確定好不好
|
||||
4. 沒人能給靠譜反饋
|
||||
5. 總覺得還沒準備好，所以一直拖
|
||||
```
|
||||
|
||||
這種結果的價值在於，它會讓你更容易找到訪談切入口。
|
||||
|
||||
### 12.5 讓 AI 扮演“訪談覆盤教練”
|
||||
|
||||
你還可以把自己剛做完的一場訪談記錄丟給 AI，讓它幫你挑刺：
|
||||
|
||||
```text
|
||||
下面是我的一段使用者訪談記錄。
|
||||
請從 The Mom Test 的角度幫我覆盤：
|
||||
1. 我哪些問題問得太像在找認可
|
||||
2. 哪些問題帶有明顯引導
|
||||
3. 哪些地方本來可以繼續追問事實
|
||||
4. 如果再來一次，這段對話可以怎麼問得更好
|
||||
```
|
||||
|
||||
這對新手特別有幫助，因為你會更快建立一種“我到底是在收集證據，還是在收集鼓勵”的敏感度。
|
||||
|
||||
## 📚 Assignments
|
||||
|
||||
請你根據上文內容，完成下列作業：
|
||||
|
||||
1. 選一個你最近想做的產品方向，先寫出 5 個你原本會問的“容易問廢”的問題
|
||||
2. 把這 5 個問題改寫成更符合 The Mom Test 風格的提問
|
||||
3. 找 3 個潛在使用者，至少問出一次“最近一次你遇到這個問題是什麼時候”
|
||||
4. 訪談結束後整理 4 類資訊：真實行為、替代方案、已付成本、反覆出現的困難
|
||||
|
||||
## 延伸閱讀
|
||||
|
||||
- [The Mom Test 官方網站](https://momtestbook.com/)
|
||||
- [Rob Fitzpatrick: The Mom Test](https://www.robfitz.com/the-mom-test/)
|
||||
@@ -0,0 +1,605 @@
|
||||
---
|
||||
title: '動手做出原型 - 從業務分析到多頁面產品原型實現'
|
||||
description: '體驗從業務分析到多頁面產品原型實現的完整閉環。學習如何向業務提問、拆解需求、使用 AI IDE 生成單頁面及多頁面應用，並進行原型美化和測試。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>8 小時</strong>'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['zh-tw/stage-1/building-prototype'] ?? []
|
||||
</script>
|
||||
|
||||
# 初級三：動手做出原型
|
||||
|
||||
## 本章導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['業務分析', '原型設計', 'AI 輔助程式設計', '多頁面應用']" coreOutput="1 個電商素材工作臺原型" expectedOutput="可互動的 Web 原型">
|
||||
|
||||
在上一章，我們學習瞭如何<strong>找到好點子</strong>——從使用者需求出發，找到有人願意買單的方向。但找到方向只是第一步，<strong>真正考驗產品經理的是：如何把模糊的需求變成能用的產品。</strong>
|
||||
|
||||
這一章，我們要解決一個<strong>現實問題</strong>：老闆丟給你一句"用 AI 提高商品釋出到電商平臺的效率" —— 你怎麼把它變成<strong>能用的產品原型</strong>？
|
||||
|
||||
和前面做貪喫蛇、計算器不同，<strong>真實業務不能憑空想功能</strong>：
|
||||
|
||||
1. <strong>明確痛點</strong>：找運營聊聊，從模糊的"提高效率"裡挖出<strong>真正的痛點</strong>
|
||||
2. <strong>挑重點做</strong>：一堆問題裡先解決<strong>最痛的那個</strong>，別想著一次性做全
|
||||
3. <strong>快速驗證</strong>：用 AI IDE 先做<strong>單頁面原型</strong>，跑通了再擴充套件成多頁面
|
||||
4. <strong>做出能用的東西</strong>：最後交付一個<strong>能演示、能操作的電商素材工作臺</strong>
|
||||
|
||||
我們將學會從<strong>做玩具到做應用的轉變</strong>，學會<strong>共情和思考客戶的真實需求</strong>。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
::: info ℹ️ 說明
|
||||
本篇中可能會有一些業務的名詞，如果你不懂可以詢問 AI 獲得解釋。
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '需求分析', description: '從模糊到具體' },
|
||||
{ title: '單頁驗證', description: '核心玩法落地' },
|
||||
{ title: '多頁擴充套件', description: '完善應用結構' },
|
||||
{ title: '美化完善', description: '提升使用者體驗' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 寫程式碼前確定需求
|
||||
|
||||
在前面的教程中，我們使用 AI IDE 輕鬆生成了貪喫蛇和各類小遊戲，但這些只能算是玩具專案，並不能運用在工作和生活當中；如果我們想要 AI 能力真正為大家所用，就應該結合生活、工作場景進行 vibe coding 程式設計。
|
||||
|
||||
上一章我們學習瞭如何找到<strong>有人願意買單的好點子</strong>，但找到方向只是開始。真正做產品時，你會發現：<strong>知道"做什麼"和知道"怎麼做"之間，還有巨大的鴻溝。</strong>
|
||||
|
||||
這個鴻溝就是<strong>需求的具體化</strong>。
|
||||
|
||||
舉個例子，在課堂或個人專案中，我們經常是從最簡單的可執行功能出發做產品和應用：
|
||||
|
||||
- "做個看板，把任務列出來。"
|
||||
- "幫我做個畫畫的工具。"
|
||||
- "幫我做個可以收集問卷的軟體。"
|
||||
|
||||
這些往往只是一個工具、一個功能模組，甚至都稱不上是一個清晰的業務問題。更關鍵的是，<strong>這些想法往往只是"你覺得有用"，而不是"使用者真的需要"。</strong>
|
||||
|
||||
在企業級專案或創業專案中，產品經理和工程師往往是從更大的業務命題出發。例如，我們可以假定這樣的一個場景：
|
||||
|
||||
<el-card shadow="hover" style="border-left: 5px solid #409EFF; background-color: #ecf5ff; margin: 20px 0;">
|
||||
<div style="font-weight: bold; color: #303133; margin-bottom: 10px;">🛍️ 業務場景：</div>
|
||||
<div style="color: #606266; line-height: 1.6;">
|
||||
<p>你是一家店鋪的電商運營產品經理。老闆給了你一個模糊但壓力很大的命題：</p>
|
||||
<p style="font-style: italic; margin-top: 10px;">“現在公眾號裡都在用 AI 做圖做文案，我看都挺簡單的。你幫我搞一下，讓我們在抖音電商上新商品時效率高一點。”</p>
|
||||
</div>
|
||||
</el-card>
|
||||
|
||||
這時候你可能想：“老闆你又在做夢了！”，然而，實際工作中這樣模糊的一句話拍板的現象是非常常見的，甚至比你一週點奶茶的次數還要多。因此，為了能夠做好一個合格的職場牛馬（我更希望你是新興的創業公司 CEO），我們必須學會如何從做自用的工具轉向做真正的產品原型。
|
||||
|
||||
由於我們學過 AI IDE，你仔細一想這個需求其實很簡單，不就是讓 AI 基於這個給個提示詞，丟給 Agent 就萬事大吉了嗎？
|
||||
|
||||
```
|
||||
請你參考我的需求 xxxx，
|
||||
幫我設計一個電商素材工作臺，
|
||||
包含商品描述、圖片、影片等素材的生成和管理功能。
|
||||
```
|
||||
|
||||
如果你興高采烈的直接把這個需求轉換成了原型，然後發給了老闆 —— 恭喜你，這個季度的獎金要取消了！
|
||||
|
||||
**為什麼會這樣？這就是我們要解決的核心痛點：**
|
||||
|
||||
以前我們學 AI IDE，做的都是貪喫蛇、計算器這種**自己用的玩具專案**——功能簡單、自己清楚要什麼、做出來自己用就行。但**真實業務場景完全不同**：
|
||||
|
||||
- **你不是使用者**：老闆要的是"提高效率"，但你不知道運營每天具體怎麼工作、卡在哪裡；
|
||||
- **AI 也不懂業務**：你丟給 AI 一個模糊需求，它只能基於通用知識瞎猜，做出來的東西看著像那麼回事，實際根本用不了；
|
||||
- **好點子不等於好產品**：你以為"加個 AI 生成功能"很酷，但使用者可能根本不需要，或者用起來比原來更麻煩。
|
||||
|
||||
**這就是為什麼我們必須學會"從想到點子到理解使用者"** 只有你的創意真正解決別人的問題，開口問、深入瞭解業務，才能做出真正意義上有價值的事情。（好的點子甚至大於好的技術）
|
||||
|
||||
### 1.1 從想象到真實：學會向業務提問
|
||||
|
||||
::: info 💡 先搞清楚：什麼是需求？什麼是業務？
|
||||
|
||||
**需求**就是使用者真正想要的東西，是他們遇到的麻煩、想解決的問題。比如"老闆想讓我上架商品更快一點"，這就是一個需求。
|
||||
|
||||
**業務**就是使用者每天實際在做的事情、他們的工作方式。比如電商運營每天要做的事：上架商品、改價格、做圖片、看資料……這些都是業務。
|
||||
|
||||
**為什麼要關注業務？**
|
||||
因為如果你不懂業務，做出來的工具可能就是"看起來很好，但沒人用"。只有真正瞭解使用者每天怎麼工作、卡在哪裡，才能做出真正幫得到他們的東西。
|
||||
|
||||
:::
|
||||
|
||||
從最簡單的視角出發，你可以先問自己幾個問題：
|
||||
|
||||
- 老闆說"**效率高一點**"，具體是什麼意思？是想**做得更快**？還是想**少花錢**？還是想**賣更多貨**？
|
||||
- 現在是怎麼把商品上架的？**哪裡做得不順**？
|
||||
- 每天要做多少個**新商品**？每個商品要做多少**圖**、寫多少**字**？
|
||||
- 現在的工作中，**哪件事最麻煩**、**最不想做**？
|
||||
|
||||
但這些都是猜測的問題，我們要向一線的抖音電商業務方直接提問，“你們的困難和關注的點在哪裡？”，透過溝通獲得更準確的答案：
|
||||
|
||||
::: info 📋 真實業務採訪結果
|
||||
|
||||
我們問了做電商運營的人，他們說了這些煩惱：
|
||||
|
||||
**1. 事情太多太雜**
|
||||
- 一個人要管好幾個店，每個店都有很多商品要弄；
|
||||
- 每天忙來忙去：**上架新商品**、**改價格**、**做圖片**、**看資料**，一件事沒做完又要做另一件。
|
||||
|
||||
**2. 做內容不是一次做好，而是邊做邊試**
|
||||
- 先用**廠家給的圖**、**以前用過的素材**或**網上找的參考圖**，快速把商品**上架**試試；
|
||||
- 花點小錢做推廣，**看看有沒有人買**；
|
||||
- 只有**賣得好的商品**，才會認真做圖、寫詳情、拍影片。
|
||||
|
||||
:::
|
||||
做完業務方提問後，我們心懷激情，因為此時我們真正能做出完美的符合業務的產品原型了！—— 又錯了，如果我們試圖“一口氣滿足所有訴求”，產品會非常龐大，也很難在課程時間內落地。因此，還需要進一步梳理和收斂，找出真正的核心痛點。
|
||||
|
||||
### 1.2 從發散到收斂：鎖定業務的核心痛點和功能
|
||||
|
||||
::: info 💡 為什麼要"收斂"？什麼叫"痛點"？
|
||||
|
||||
**問題很多，但先做哪一個？**
|
||||
|
||||
使用者可能告訴你一堆問題：A也麻煩、B也麻煩、C也麻煩……但如果你試圖一次性解決所有問題，最後可能什麼都做不好。所以要**收斂**——就是從一堆問題裡，挑出**最痛、最急、最能解決**的那個先動手。
|
||||
|
||||
**什麼是痛點？**
|
||||
就是使用者**最煩、最花時間、最想解決**的那個具體問題。不是"我覺得有用"，而是使用者**每天都在抱怨、每次做都很痛苦**的事。
|
||||
|
||||
:::
|
||||
|
||||
透過上面的採訪，我們發現運營遇到的問題有很多：被活動打斷節奏、要管多個店、在上架/改價/做圖/看資料之間忙來忙去……
|
||||
|
||||
如果我們試圖"這些問題我全都要解決"，最後會做出一個**大而全但不好用**的工具。
|
||||
|
||||
讓我們把這些問題分分類（可以讓 AI 幫忙），大致有三類：
|
||||
|
||||
1. **節奏問題**：什麼時候上架、什麼時候調價；
|
||||
2. **效率問題**：怎麼同時管好多個店、多個商品；
|
||||
3. **內容問題**：怎麼快速做出商品圖片和文案。
|
||||
|
||||
對於我們的課程來說，最適合先解決的是**第3類：做內容的問題**。但"快速做內容"還是有點抽象，我們再問問業務方具體卡在哪裡：
|
||||
|
||||
::: info 📋 業務方說：做內容有兩個最痛苦的地方
|
||||
|
||||
**痛苦1：批次做圖做文案太費勁**
|
||||
- 素材到處放：網盤、微信記錄、平臺後臺……**找起來很費勁**；
|
||||
- 一次要上很多商品，**沒時間逐個精心做**，只能隨便拼一下；
|
||||
- 要求不高，**能看、能上架就行**，不需要多精美。
|
||||
|
||||
**痛苦2：好用的方案沒法存下來複用**
|
||||
- 之前做得好的標題、排版，**下次想用卻找不到了**；
|
||||
- 方案散落在聊天記錄、以前的商品連結裡；
|
||||
- 想用的時候得**翻半天、複製貼上改半天**；
|
||||
- 缺一個能**收藏、管理、直接套用**的工具。
|
||||
|
||||
:::
|
||||
|
||||
基於上面兩個痛點，我們要做一個簡單的小工具：**幫運營批次做圖做文案，還能把好用的方案存下來下次直接用**。
|
||||
|
||||
它只做兩件事（可以讓 AI 幫忙細化，記得根據業務反饋不斷刪減功能）：
|
||||
|
||||
::: info 功能1：批次生成電商商品圖和文案
|
||||
|
||||
**這是做什麼的？**
|
||||
給系統一些商品資訊，它自動幫你生成能在電商平臺（如抖音、淘寶）上架用的商品圖和文字。
|
||||
|
||||
**輸入**
|
||||
| 型別 | 內容 |
|
||||
|------|------|
|
||||
| 商品資訊 | 名字、類別、品牌、材質、尺寸、顏色等 |
|
||||
| 商品圖片 | 白底圖或簡單場景圖 |
|
||||
| 參考圖 | 以前賣得好的商品截圖或參考連結 |
|
||||
| 匯入方式 | Excel 批次匯入，或直接在頁面上填寫 |
|
||||
|
||||
**輸出（生成的電商素材）**
|
||||
- **商品主圖**：帶文字賣點的產品展示圖（使用者刷到時第一眼看到的圖）
|
||||
- **商品標題**：搜尋時能搜到的關鍵片語合
|
||||
- **賣點文案**：1-2句吸引買家的話
|
||||
- 都是**改改就能上架**的成品
|
||||
|
||||
**效果**
|
||||
- 以前：每個商品都要從零開始做圖寫文案
|
||||
- 現在：把一批商品丟給系統，生成草稿後挑挑改改就行
|
||||
|
||||
:::
|
||||
|
||||
::: info 功能2：把好用的方案存成模板
|
||||
|
||||
**輸入**
|
||||
| 型別 | 內容 |
|
||||
|------|------|
|
||||
| 一整套 | 主圖 + 標題 + 文案 |
|
||||
|
||||
**輸出**
|
||||
| 功能 | 說明 |
|
||||
|------|------|
|
||||
| 套用 | 下次做新商品時，用模板自動生成 |
|
||||
| 修改 | 直接改標題、改文案 |
|
||||
| 管理 | 起名字、打標籤（如"男包模板""大促標題"），方便找 |
|
||||
|
||||
**效果**
|
||||
1. 匯入新商品
|
||||
2. 選擇：讓系統預設生成，或**用我存好的模板**
|
||||
3. 系統自動套用模板風格，輸出新的圖和文案
|
||||
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
**回顧我們剛才做了什麼：**
|
||||
|
||||
1. **先問問題**：不是直接動手做，而是先問運營"你們最煩什麼"；
|
||||
2. **找到痛點**：發現他們最痛苦的是"做圖寫文案太費勁"和"好用的方案沒法存"；
|
||||
3. **收斂範圍**：不做大而全的平臺，只做"批次生成圖和文案 + 存模板"這兩個功能。
|
||||
|
||||
**為什麼這樣做很重要？**
|
||||
|
||||
很多新手做產品的誤區是：功能越多越好。但使用者真正需要的是**解決最痛的那個問題**。做一堆功能但都不好用，不如做一兩個功能但真的幫到使用者。
|
||||
|
||||
**產品和業務思維的核心：**
|
||||
- 不要自己想"我覺得使用者需要什麼"
|
||||
- 要去問使用者"你每天在做什麼？哪裡最痛苦？"
|
||||
- 從一堆問題裡**收斂**到最痛、最能解決的那個
|
||||
- 先做出**最小可用**的版本，再慢慢迭代
|
||||
|
||||
這就是我們在寫程式碼之前要想清楚的事。程式碼只是工具，**理解使用者、找準問題**纔是第一步。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: '需求分析', description: '從模糊到具體' },
|
||||
{ title: '單頁驗證', description: '核心玩法落地' },
|
||||
{ title: '多頁擴充套件', description: '完善應用結構' },
|
||||
{ title: '美化完善', description: '提升使用者體驗' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. 10分鐘產出原型：讓 AI IDE 落地"核心玩法"
|
||||
|
||||
::: info 💡 程式設計 Plan 建議
|
||||
如果你覺得當前 IDE 不夠聰明，或者覺得很快就花完了額度，你可以去買一個**程式設計 Plan 計劃**。提前預習參考[這個文章](../../stage-2/backend/modern-cli/)使用 Claude 進行程式設計。
|
||||
:::
|
||||
|
||||
Thinking 是好事，但不可 over thinking，我們就此控制過度反思，嘗試從單個頁面開始製作原型。
|
||||
|
||||
### 2.1 第一步：用大白話告訴 AI 你要什麼
|
||||
|
||||
剛開始不用追求完美的提示詞，先從你最自然的表達開始。就像跟同事描述需求一樣，用大白話告訴 AI 你想做什麼，然後讓 AI 幫你最佳化成更專業的表達。
|
||||
|
||||
#### 2.1.1 從口述開始（推薦新手）
|
||||
|
||||
先用自己的話描述想法，哪怕很粗糙也沒關係：
|
||||
|
||||
```
|
||||
我想做一個工具，幫電商運營自動生成商品的主圖和文案。
|
||||
運營平時要一個個手動做圖寫文案，很麻煩。
|
||||
我的想法是：他們上傳商品資訊，系統自動生成一批草稿，
|
||||
運營挑選好用的稍微改改就能用。
|
||||
|
||||
先做最簡單的版本：一個頁面，左邊填商品資訊，
|
||||
右邊顯示生成的結果。能上傳圖片，能填文字，
|
||||
生成後顯示主圖預覽和文案。
|
||||
```
|
||||
|
||||
接下來，把這段話發給 AI（比如 ChatGPT、Claude 等），讓它幫你擴寫一下。AI 通常會幫你補充一些你沒考慮到的細節，把你的想法整理得更清晰，最後生成一個適合發給 AI IDE 的提示詞。
|
||||
|
||||
你可以這樣跟 AI 說：
|
||||
```
|
||||
幫我把上面的想法擴寫一下，整理成一份清晰的業務邏輯文件，
|
||||
然後生成一個適合發給 AI IDE（比如 Cursor、Trae）的提示詞，
|
||||
用來生成單頁面應用的原型程式碼。
|
||||
```
|
||||
|
||||
AI 會返回一份結構化的需求和對應的提示詞。你自己檢查一遍，刪減不需要的功能，確認無誤後再拿去生成程式碼。
|
||||
|
||||
這樣做的好處是：口述的東西是最真實的想法，可能會漏掉一些重要的細節。而 AI 幫你擴寫的時候，可能會問"要不要支援批次上傳？"這種沒想到的問題，幫助你進一步驗證。你可以根據反饋需要選擇保留或刪除不實際的功能，在反覆修改中確定給 AI 的初版提示詞。
|
||||
|
||||
#### 2.1.2 跳過擴寫環節：直接把你整理好的業務文件丟給 AI
|
||||
|
||||
如果你已經在前面的章節整理好了業務邏輯文件（比如用大白話寫的需求說明），可以直接套用下面的格式發給 AI IDE，省去了讓 AI 擴寫的中間步驟。適合需求已經很清晰、想直接動手寫程式碼的情況：
|
||||
|
||||
```
|
||||
幫我參考業務邏輯實現一個單頁面應用，用來驗證核心玩法功能。
|
||||
|
||||
業務邏輯參考如下：
|
||||
1. 幫運營批次生成第一版圖文草稿：
|
||||
- **輸入（支援直接上傳和批次匯入素材）：**
|
||||
- 商品基礎資訊：名稱、類目、品牌、材質、尺寸、顏色、適用人羣等；
|
||||
- 商品圖片：白底圖 / 簡單場景圖；
|
||||
- 每次生成支援上傳額外上傳歷史爆款截圖或參考連結，允許有參考物；
|
||||
- 支援透過 Excel 批次匯入，或在頁面上線上錄入 / 上傳。
|
||||
- 支援頁面上指定是否儲存商品素材到素材庫，方便下次使用
|
||||
- **輸出（能直接拿去上架或輕改就能上架的內容）：**
|
||||
- 每個商品一張"看得過去、包含基礎賣點"的主圖草稿；
|
||||
- 一條"結構合理、含核心關鍵詞"的標題 + 1–2 句賣點文案。
|
||||
- **期望的使用方式變化：**
|
||||
從每批商品白手起稿變為把一批商品丟進系統，拿系統生成的草稿做篩選和微調。
|
||||
|
||||
先做第一個功能，第二個功能（模板庫）後面再加。
|
||||
```
|
||||
|
||||
#### 2.1.3 程式設計師的做法（進階）：讓 AI 幫你寫 "提示詞的提示詞"
|
||||
|
||||
如果你想更精細地控制程式碼生成過程，可以先讓 AI（如 ChatGPT）基於你的需求，生成一份專門給 AI IDE 的提示詞：
|
||||
|
||||
```
|
||||
基於下面的想法，幫我寫一個發給 coding Agent 的寫程式碼用的提示詞，
|
||||
我需要用這個提示詞來生成程式碼。
|
||||
|
||||
[把你的業務邏輯描述貼在這裡]
|
||||
|
||||
要求：
|
||||
1. 提示詞要包含清晰的頁面佈局描述
|
||||
2. 明確資料結構和互動邏輯
|
||||
3. 指定技術棧（如 React + Tailwind）
|
||||
4. 列出需要實現的核心功能點
|
||||
```
|
||||
|
||||
通常 AI 會生成類似下面的結構化提示詞：
|
||||
|
||||
|
||||
你可以把這份提示詞稍作修改後，發給 AI IDE 生成程式碼。
|
||||
|
||||
### 2.2 第二步：讓 AI IDE 直接生成程式碼
|
||||
|
||||
#### 2.2.1 準備工作：瞭解 AI IDE 的基本操作
|
||||
|
||||
如果你還不熟悉 AI IDE（如 Cursor、Trae、Windsurf 等）的基本使用方式，建議先看附錄中的[IDE 基礎教程](/zh-tw/appendix/2-development-tools/ide-basics/)，瞭解如何：
|
||||
- 建立新專案
|
||||
- 與 AI Agent 對話
|
||||
- 理解 AI 的程式碼生成過程
|
||||
|
||||
#### 2.2.2 開始生成程式碼
|
||||
|
||||
此時你已經獲得了初始提示詞，我們以第一種提示詞風格為例，讓 AI 協助我們生成程式碼。首先建立一個視窗和對應的資料夾，開啟資料夾（在你喜歡的資料夾地址下初始化一個新專案）：
|
||||
|
||||
|
||||
|
||||
在側邊欄中選擇一個你喜歡的模型（推薦 gemini、gpt、glm、kimi、minimax 等），輸入第一步中得到的提示詞：
|
||||
|
||||
|
||||
點選生成後，我們會看到熟悉的環節，AI 會根據提示詞，規劃出專案的目錄結構、必要的檔案，並給出每個檔案的初始內容。
|
||||
|
||||
::: warning ⚠️ 特別注意：AI 可能會停下來等你確認
|
||||
在生成過程中，AI Agent 經常會**停下來等待你的輸入或確認**，比如：
|
||||
- 詢問你是否繼續下一步
|
||||
- 讓你按回車確認某個操作
|
||||
- 詢問你某個技術細節的選擇
|
||||
|
||||
**如果看到 AI 不動了，先檢查一下對話介面，看看是不是在等你回覆。** 很多新手以為 AI 在思考，其實它早就停在那等你了。主動回覆或按回車，AI 就會繼續工作。
|
||||
:::
|
||||
|
||||
此時同樣別忘記按回車確認資訊（否則會陷入等待，有些 AI IDE 不會陷入這個問題）：
|
||||
|
||||
|
||||
如果遇到如下場景，這個意思是已經在本地啟動了一個服務，你需要點選跳過，否則會停留在這個介面（如果程式碼生成完沒有東西出下，你就需要主動說“幫我啟動這個專案”）：
|
||||
|
||||
|
||||
::: info 💡 場景說明
|
||||
**場景說明**：你用 `npm create vite@latest` 建立了一個 React + TypeScript 專案（easy-vibe-web），建立完成後，電腦會自動把這個網頁“跑起來”，方便你立刻看到效果。
|
||||
|
||||
**本地服務**：可以理解為你的電腦臨時開了一個網頁展示視窗，只在你自己這臺電腦上執行，別人訪問不到。
|
||||
|
||||
**localhost（本地地址）**：`localhost` 就是“這臺電腦自己”的意思，瀏覽器訪問它，其實是在訪問你電腦上正在執行的網頁。
|
||||
|
||||
**埠**：埠可以理解為編號，用來區分同一臺電腦上執行的不同網頁服務，本專案使用的是 5174。
|
||||
|
||||
**訪問連結 `http://localhost:5174/`**：這個地址表示“訪問我這臺電腦上編號為 5174 的網頁”，在瀏覽器開啟就能看到效果。
|
||||
|
||||
**本次場景說明**：系統原本想使用 5173，但該編號已被佔用，所以自動換成了 5174，這屬於正常情況。
|
||||
|
||||
**操作指引**：開啟瀏覽器，在位址列輸入 `http://localhost:5174/` 並回車，即可看到當前專案頁面。
|
||||
:::
|
||||
|
||||
都確認完畢後，等待智慧體執行片刻，我們可以得到如下結果：
|
||||
|
||||
|
||||
可以看到已經有了初步功能圖，但前端頁面顯示太醜了，此時我們可以嘗試這樣和 AI 進行直接對話，最佳化介面顯示：
|
||||
|
||||
|
||||
最佳化後我們能夠得到如下更美觀的介面：
|
||||
|
||||
|
||||
你可以根據自己的需求修改網頁功能，可以附上截圖自由進行提問，比如：“我現在還不需要批次匯入功能，幫我取消”，“左邊要輸入的東西太多了，幫我只留下 xxxxx”。甚至，你還可以參考其他成熟的網站，比如這裡我們可以直接參考谷歌的某設計產品進行“參考”（你可以貼上自己喜歡的某個成熟網站的截圖）：
|
||||
|
||||
|
||||
最後可以得到：
|
||||
|
||||
|
||||
### 2.3 遇到報錯怎麼辦
|
||||
|
||||
在實際操作中，遇到報錯是必然的，這是正常現象，不代表你哪裡做錯了。你不需要看懂報錯，只需要把“看到的情況”完整交給 AI。
|
||||
|
||||
常見的處理方式只有三種：
|
||||
|
||||
- **方式一：頁面或終端報錯**
|
||||
頁面變紅、白屏，或終端出現一堆紅字時，直接截圖或複製全部錯誤資訊發給 AI，讓它幫你修。
|
||||
|
||||
- **方式二：功能不對但沒報錯**
|
||||
比如按鈕沒反應、資料沒顯示、樣式亂了，用大白話描述“現在發生了什麼 + 你本來想要什麼”，必要時加一張截圖。
|
||||
|
||||
- **方式三：不確定有沒有問題**
|
||||
可以直接問 AI：“幫我檢查一下這個功能有沒有明顯問題，需不需要調整。”
|
||||
|
||||
#### 2.3.1 新手常見疑問
|
||||
|
||||
- **Q：我不知道錯誤資訊在哪裡？**
|
||||
- A：一般來說，看所有“紅色的字”。在終端、控制檯或頁面上，找到紅色提示，全選複製給 AI 即可。
|
||||
|
||||
- **Q：AI 改完還是報同樣的錯怎麼辦？**
|
||||
- A：這是常見情況。繼續截圖或複製最新的錯誤資訊發給它，讓它在上一次修改基礎上進一步修復。
|
||||
|
||||
- **Q：我需要完全理解 AI 的修復方案嗎？**
|
||||
- A：不需要一次性全部搞懂。可以每次只關注一兩個點，久而久之，你會逐漸看懂越來越多程式碼，就像積累英語詞彙一樣。
|
||||
|
||||
- **Q：改了很多次，問題還是沒解決怎麼辦？**
|
||||
- A：可以嘗試：
|
||||
- 使用 IDE 的“版本回退”功能，在智慧體對話處找到撤回按鈕，回到一個可執行的版本重新開始；
|
||||
- 更換模型或調整提示詞，將現象、錯誤資訊講得更具體；
|
||||
- 將“當前程式碼 + 錯誤日誌 + 預期行為”打包，一次性發給 AI，讓它整體重構問題部分。
|
||||
|
||||
## 3. 從單頁面擴充套件到多頁面應用
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: '需求分析', description: '從模糊到具體' },
|
||||
{ title: '單頁驗證', description: '核心玩法落地' },
|
||||
{ title: '多頁擴充套件', description: '完善應用結構' },
|
||||
{ title: '美化完善', description: '提升使用者體驗' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
當核心玩法的邏輯基本生成完畢後，我們可以生成剩下部分的內容。比如此時我們點選設定或者是一些按鈕是根本無效的。
|
||||
|
||||
你可以讓 AI 根據業務提示詞的需求進行檢查，生成未生成的部分，又或者是讓 AI 直接補充未實現完成的頁面，你也可以指定一個頁面讓 AI 補充實現，直到頁面可以被點選，功能可以正常互動：
|
||||
|
||||
|
||||
等待片刻後，我們能夠看到程式已經在之前的基礎上補充了多個頁面和可互動功能：
|
||||
|
||||
|
||||
|
||||
|
||||
此時你只需要人工點選每個你所關注的功能和按鍵，確保互動正常即可，如果有不能互動的功能，你可以和 AI 溝通，讓它幫你修復。
|
||||
|
||||
## 4. 把原型做得“像那麼回事”
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: '需求分析', description: '從模糊到具體' },
|
||||
{ title: '單頁驗證', description: '核心玩法落地' },
|
||||
{ title: '多頁擴充套件', description: '完善應用結構' },
|
||||
{ title: '美化完善', description: '提升使用者體驗' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
有了多頁面結構之後，最後一步是讓原型從“能跑”變成“用起來順手、看上去專業”。這需要我們動手體驗一遍全流程（使用者流程），並且把無法執行的部分讓 AI 進行修復，使得我們可以每次重新整理後都能從零開始模仿一個新使用者走全部流程，得到預期結果。
|
||||
|
||||
讓我們回顧最初的需求：
|
||||
|
||||
```
|
||||
1. 幫運營批次生成第一版圖文草稿：
|
||||
- **輸入（支援直接上傳和批次匯入素材）：**
|
||||
- 商品基礎資訊：名稱、類目、品牌、材質、尺寸、顏色、適用人羣等；
|
||||
- 商品圖片：白底圖 / 簡單場景圖；
|
||||
- 每次生成支援上傳額外上傳歷史爆款截圖或參考連結，允許有參考物；
|
||||
- 支援透過 Excel 批次匯入，或在頁面上線上錄入 / 上傳。
|
||||
- 支援頁面上指定是否儲存商品素材到素材庫，方便下次使用
|
||||
- **輸出（能直接拿去上架或輕改就能上架的內容）：**
|
||||
- 每個商品一張“看得過去、包含基礎賣點”的主圖草稿；
|
||||
- 一條“結構合理、含核心關鍵詞”的標題 + 1–2 句賣點文案。
|
||||
- **期望的使用方式變化：**
|
||||
從每批商品白手起稿變為把一批商品丟進系統，拿系統生成的草稿做篩選和微調。
|
||||
|
||||
2. 把好用的輸出沉澱成可複用的模板庫：
|
||||
- **什麼可以被收藏？**
|
||||
- 任意一條運營覺得“好用”的輸出都可以一鍵收藏：
|
||||
- 可以是“主圖 + 標題 + 賣點”的完整組合；
|
||||
- 也可以只收藏其中一部分，例如某個標題結構、某條賣點文案。
|
||||
- **收藏之後能做什麼？**
|
||||
- **複用：**
|
||||
- 用這條收藏，套一批新商品引數，重新生成圖文草稿；
|
||||
- 或在同一商品上，基於該模板生成多版變體做 A/B 測試。
|
||||
- **編輯：**
|
||||
- 直接修改標題文案 / 賣點文案；
|
||||
- 如果支援圖片編輯，可以微調主圖中的文字、貼紙等元素。
|
||||
- **管理：**
|
||||
- 給收藏起名字、打標籤（如“男包主圖模板”“大促標題結構”）、支援按照店鋪分類，方便後續檢索。
|
||||
- **下次上新時如何使用？**
|
||||
- 匯入新商品後，運營可以選擇：
|
||||
- 使用系統預設邏輯生成，或
|
||||
- 指定“使用我收藏的某個模板來生成”；
|
||||
- 系統基於新商品資料，自動套用模板的結構與風格，輸出新的主圖 + 標題 + 賣點草稿。
|
||||
```
|
||||
|
||||
如果每次測試時候都需自己新建資料進行測試，這需要花費大量時間，在這個時候我們通常會使用叫做”測試資料“的方式進行處理，我們可以按照下列方式和 AI 溝通，讓 AI 在介面上生成可以測試的快速資料入口，方便我們測試功能都能正常跑通：
|
||||
|
||||
```
|
||||
我現在需要測試這個使用者使用過程，確保他能完全走通，請你結合下列需求生成測試資料入口，讓我能夠點選後很快測試全流程是否正常：
|
||||
1. 幫運營批次生成第一版圖文草稿：
|
||||
- **輸入（支援直接上傳和批次匯入素材）：**
|
||||
- 商品基礎資訊：名稱、類目、品牌、材質、尺寸、顏色、適用人羣等；
|
||||
- 商品圖片：白底圖 / 簡單場景圖；
|
||||
- 每次生成支援上傳額外上傳歷史爆款截圖或參考連結，允許有參考物；
|
||||
- 支援透過 Excel 批次匯入，或在頁面上線上錄入 / 上傳。
|
||||
- 支援頁面上指定是否儲存商品素材到素材庫，方便下次使用
|
||||
- **輸出（能直接拿去上架或輕改就能上架的內容）：**
|
||||
- 每個商品一張“看得過去、包含基礎賣點”的主圖草稿；
|
||||
- 一條“結構合理、含核心關鍵詞”的標題 + 1–2 句賣點文案。
|
||||
- **期望的使用方式變化：**
|
||||
從每批商品白手起稿變為把一批商品丟進系統，拿系統生成的草稿做篩選和微調。
|
||||
```
|
||||
|
||||
很容易得到結果（如果你覺得一個資料太少，你可以讓 AI 生成多個可測試用例）：
|
||||
|
||||
|
||||
點選後得到結果：
|
||||
|
||||
|
||||
此時我們直接得到的是結果，並不是有一個“假設的生成過程”，我們想要模擬真實的生成過程，可以直接和 AI 進行對話：“請你模擬一個真實的生成過程，在點選後過一段時間才給我結果。”
|
||||
|
||||
|
||||
走通生成功能後，我們還要確保模板庫的功能正常，從頁面的生成卡片上我們能夠知道模版庫收藏功能並沒有實現，此時需要和 AI 進一步深入對話，“請你幫我確保需求 [此處貼上上面的 2. 的內容] 正常，可以點選一個結果收藏對應的模板，點開後能看到生成引數”
|
||||
|
||||
生成往往不是一蹴而就，時常需要截圖修正：
|
||||
|
||||
|
||||
最後得到預期結果：
|
||||
|
||||
|
||||
除了手動體驗需求流程，你還可以讓 AI 幫你直接做需求檢查，例如：
|
||||
|
||||
- “請對照我最開始的需求，檢查當前應用是否已經覆蓋所有核心功能。”
|
||||
- “幫我列一個功能清單，標出哪些已經完成、哪些尚未實現或體驗不足。”
|
||||
|
||||
AI 一般會輸出一個 checklist，你可以根據結果思考是否需要繼續改進，經過反覆修改後能夠得到比較完善的原型結果。
|
||||
|
||||
## 5. 📚 作業：復刻屬於你自己的抖音電商工作臺
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🚀 挑戰任務：復刻電商素材工作臺</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
參考本節課的提示詞和內容，完成一次完整閉環：
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>完整閉環實踐</strong>
|
||||
<ul>
|
||||
<li>業務梳理提示詞生成 → 單頁原型生成 → 多頁原型生成</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>成果分享</strong>
|
||||
<ul>
|
||||
<li>截圖你的程式分享給大家看</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>思考題</strong>
|
||||
<ul>
|
||||
<li>為下一節“接入大語言模型（LLM）和文生圖能力”預留空間，提前思考：你的工作臺裡，可以怎樣嵌入“AI 寫文案 / 生成配圖 / 生成指令碼”等能力？</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 下一步
|
||||
|
||||
在下一節中，我們將在這個內容生產工作臺的基礎上，接入具體的 AI 能力（文字生文字、圖片生文字、文字生圖片），例如：
|
||||
|
||||
- 為某條內容任務自動生成文案初稿和多個標題備選
|
||||
- 根據任務描述自動生成配圖草稿（文生圖）
|
||||
- 對歷史內容任務做自動歸類和摘要，幫助你規劃下一個活動的選題
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="繼續學習"
|
||||
description="建議按“接入 AI 能力 → 完整專案閉環 → 設計工程化”順序繼續。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
@@ -0,0 +1,301 @@
|
||||
---
|
||||
title: '完整專案實戰 - 從 Demo 到產品級原型'
|
||||
description: '走出 Demo 階段，學習如何完善產品鏈路、構建逼真的模擬資料、透過反饋快速迭代，最終完成一個可展示、可互動的完整 AI 產品原型。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>3 天</strong>'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['zh-tw/stage-1/complete-project-practice'] ?? []
|
||||
</script>
|
||||
|
||||
# 初級五：完整專案實戰
|
||||
|
||||
## 章節導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['產品思維', '模擬資料', '互動完善', 'LocalStorage']" coreOutput="1 個功能完備的 AI 產品原型" expectedOutput="包含完整鏈路與真實資料的 Web 應用">
|
||||
|
||||
上一章接入了 AI 能力，Demo 能跑起來了，但離真正的"產品"還<strong>差得遠</strong>：頁面一重新整理<strong>資料就沒了</strong>，報錯就<strong>白屏</strong>，列表裡只有"測試資料 1、測試資料 2"，使用者點錯了也<strong>沒法撤銷</strong>...
|
||||
|
||||
這一章要把這些<strong>坑都填上</strong>：我們會<strong>補全產品的完整鏈路</strong>，用 AI 生成<strong>逼真的業務資料</strong>替代假資料，加上<strong>錯誤處理和使用者反饋</strong>，最後打磨出一個<strong>拿得出手、能給別人演示</strong>的完整原型。
|
||||
|
||||
這是初級階段的<strong>最後一章</strong>，走完這一步，你就完成了從"完全不會程式設計"到"<strong>能獨立做出 AI 產品原型</strong>"的蛻變。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: '完善鏈路', description: '從單點功能到完整閉環' },
|
||||
{ title: '注入靈魂', description: '模擬真實業務資料' },
|
||||
{ title: '反饋迭代', description: '基於真實反饋修補體驗' },
|
||||
{ title: '最終大作業', description: '你的畢業設計' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 1. 拒絕 "Happy Path"：完善核心鏈路
|
||||
|
||||
很多初學者做原型，往往只做“Happy Path”（最理想的路徑）：使用者點選 -> API 響應成功 -> 顯示結果。
|
||||
但在真實世界裡，事情往往沒那麼順利。為了讓你的原型看起來像個真正的產品，你需要考慮以下幾個“隱形”的環節。
|
||||
|
||||
### 1.1 增加“等待”與“反饋”
|
||||
|
||||
當使用者點選“生成文案”時，AI 往往需要幾秒鐘才能響應。如果介面毫無反應，使用者會以為程式壞了。
|
||||
**你需要讓 AI IDE 幫你加上 Loading 狀態：**
|
||||
|
||||
> 提示詞示例：
|
||||
> “當我點選生成按鈕時，請把按鈕變成‘生成中...’並不可點選，同時在右側區域顯示一個載入動畫。直到 API 返回結果後，再恢復正常。”
|
||||
|
||||
### 1.2 處理“失敗”與“異常”
|
||||
|
||||
API Key 可能會過期，網路可能會斷開。
|
||||
**你需要讓 AI IDE 幫你處理報錯：**
|
||||
|
||||
> 提示詞示例：
|
||||
> “如果 API 請求失敗了，不要直接在控制檯報錯，請在頁面頂部彈出一個紅色的提示框（Toast），告訴使用者‘生成失敗，請稍後重試’，並允許使用者重新點選生成。”
|
||||
|
||||
### 1.3 對話歷史持久化
|
||||
|
||||
在與 AI 互動的過程中，我們需要儲存對話內容，讓使用者能夠回顧歷史、繼續之前的交流。目前階段我們暫不引入資料庫，可以選擇以下輕量級方案：
|
||||
|
||||
**儲存方案選擇：**
|
||||
|
||||
| 方案 | 適用場景 | 特點 |
|
||||
| ---------------- | -------------------------------- | ------------------------------------ |
|
||||
| **LocalStorage** | 純前端專案，使用者資料儲存在瀏覽器 | 實現簡單，重新整理不丟失，無法跨裝置同步 |
|
||||
| **JSON 檔案** | 本地原型，資料以檔案形式儲存 | 結構清晰，便於除錯，可手動編輯 |
|
||||
| **TXT 檔案** | 最簡方案，快速記錄文字內容 | 格式自由，相容性好 |
|
||||
|
||||
**對話內容示例：**
|
||||
儲存的對話歷史通常包含以下內容：
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"role": "user",
|
||||
"content": "幫我生成一款藍芽耳機的抖音帶貨文案",
|
||||
"timestamp": "2026-01-20 10:30:00"
|
||||
},
|
||||
{
|
||||
"role": "assistant",
|
||||
"content": "【藍芽耳機種草文案】\n\n🎧 告別延遲，沉浸式聽歌體驗\n\n姐妹們！這款藍芽耳機真的太絕了👇\n\n✅ 40dB主動降噪，瞬間進入音樂世界\n✅ 30小時超長續航，一週通勤不用充電\n✅ 通話清晰如面對面，地鐵嘈雜也能聊\n✅ 半入耳設計，久戴不痛不悶耳\n\n💰 限時優惠，點選下方連結入手！",
|
||||
"timestamp": "2026-01-20 10:30:05"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
**實現提示詞：**
|
||||
|
||||
> “請幫我實現對話歷史的儲存功能。支援將使用者和 AI 的對話記錄儲存為 JSON 檔案（或使用 LocalStorage）。每次進入頁面時自動載入歷史對話，支援檢視和刪除單條對話記錄。”
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: '完善鏈路', description: '從單點功能到完整閉環' },
|
||||
{ title: '注入靈魂', description: '模擬真實業務資料' },
|
||||
{ title: '反饋迭代', description: '基於真實反饋修補體驗' },
|
||||
{ title: '最終大作業', description: '你的畢業設計' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 2. 注入靈魂：模擬真實資料 (Mock Data)
|
||||
|
||||
一個空蕩蕩的頁面是無法打動人的。想象一下，你向別人展示“電商素材工作臺”，結果歷史記錄裡空空如也，或者只有一行 "test / test / test"。
|
||||
為了讓演示效果最佳，我們需要“偽造”一些逼真的資料，讓你的原型看起來像一個已經運營了半年的真實產品。
|
||||
|
||||
### 2.1 讓 AI 幫你設計資料結構
|
||||
|
||||
我們不需要自己去想每一個欄位叫什麼（比如是叫 `name` 還是 `title`），這件事完全可以交給 AI。
|
||||
|
||||
你只需要告訴 AI 你的**業務場景**：
|
||||
|
||||
> **提示詞示例：**
|
||||
> “我正在做一個**抖音電商素材工作臺**的原型。
|
||||
> 請幫我設計一個 JSON 資料結構，用來描述一個‘商品任務’。
|
||||
> 這個任務應該包含：商品的基本資訊（名字、類目）、輸入的素材（圖片連結）、以及 AI 生成的結果（標題、文案、海報圖）。
|
||||
> 請直接給我一個 JSON 示例。”
|
||||
|
||||
AI 會根據你的描述，自動幫你構思出類似 `productName`, `generatedContent` 這樣的欄位。
|
||||
|
||||
### 2.2 讓 AI 批次生產“逼真”資料
|
||||
|
||||
有了資料結構後，下一步就是讓 AI 幫你“填空”，生成一批看起來真實的資料。
|
||||
|
||||
**提示詞技巧：**
|
||||
你不能只告訴 AI “幫我生成資料”，你需要像給實習生布置任務一樣，告訴它**業務背景**和**內容要求**：
|
||||
|
||||
- **業務背景**：告訴 AI 我們是做“抖音電商”的，所以商品標題要吸睛（比如“顯瘦神器”、“學生黨必入”），文案要口語化。
|
||||
- **圖片要求**：為了讓原型好看，圖片不能是黑白的佔位符，最好是隨機的彩色風景或實物圖。
|
||||
|
||||
> **提示詞示例：**
|
||||
> “請基於剛才設計的結構，幫我生成 10 條逼真的模擬資料。
|
||||
> （備註：不一定要 JSON 格式。如果你正在寫前端，可以讓它直接生成 JavaScript 陣列；如果你用 Python，可以讓它生成 List。）
|
||||
>
|
||||
> **業務場景要求**：
|
||||
>
|
||||
> 1. 假設這是一家綜合百貨店，商品涵蓋‘女裝’、‘數碼’、‘美妝’三個類目。
|
||||
> 2. **生成的標題和文案要非常‘抖音風’**：比如標題要包含 Emoji (🔥, ✨)，文案要用‘絕絕子’、‘親測好用’這種語氣。
|
||||
> 3. **圖片欄位**：請統一使用 `https://picsum.photos/seed/{random_id}/300/400` 這個格式，確保每張圖都不一樣。”
|
||||
|
||||
**生成的 Mock Data 示例：**
|
||||
|
||||
```javascript
|
||||
export const mockProductTasks = [
|
||||
{
|
||||
id: 'task_001',
|
||||
name: '夏季法式復古碎花裙',
|
||||
status: 'completed',
|
||||
input: {
|
||||
category: '女裝',
|
||||
features: ['收腰', '顯瘦', '氣質'],
|
||||
originalImage: 'https://picsum.photos/seed/dress_input/300/400'
|
||||
},
|
||||
output: {
|
||||
generatedTitle: '✨誰穿誰好看！這條法式碎花裙真的絕絕子🔥',
|
||||
generatedCopy:
|
||||
'姐妹們！這條裙子真的太顯瘦了！收腰設計絕了，穿上立馬有腰身。面料很透氣，夏天穿完全不悶。約會逛街首選！👗',
|
||||
generatedPosterImage: 'https://picsum.photos/seed/dress_output/300/400'
|
||||
},
|
||||
createdAt: '2026-01-20T10:00:00Z'
|
||||
},
|
||||
{
|
||||
id: 'task_002',
|
||||
name: '超強降噪藍芽耳機 Pro',
|
||||
status: 'completed',
|
||||
input: {
|
||||
category: '數碼',
|
||||
features: ['降噪', '超長續航', '低延遲'],
|
||||
originalImage: 'https://picsum.photos/seed/tech_input/300/400'
|
||||
},
|
||||
output: {
|
||||
generatedTitle: '🎧 終於被我找到了！這款耳機降噪太強了吧！🔇',
|
||||
generatedCopy:
|
||||
'戴上它，世界瞬間安靜了。音質絕佳，聽歌就像在現場。續航也很給力，充一次電用一週！學生黨必入！',
|
||||
generatedPosterImage: 'https://picsum.photos/seed/tech_output/300/400'
|
||||
},
|
||||
createdAt: '2026-01-21T14:30:00Z'
|
||||
}
|
||||
// ... 更多資料
|
||||
]
|
||||
```
|
||||
|
||||
### 2.3 (進階) 使用 LocalStorage 實現“假增刪改”
|
||||
|
||||
如果你希望剛才生成的“模擬資料”不僅能看，還能刪、能改，甚至新生成的任務重新整理頁面後還在，你可以結合 `LocalStorage`。
|
||||
|
||||
> **提示詞示例：**
|
||||
> “請幫我實現一個資料儲存功能。
|
||||
>
|
||||
> 1. 優先從 `localStorage` 讀取資料。
|
||||
> 2. 如果 `localStorage` 為空，則使用剛才生成的 Mock 資料初始化，並將它們存入 `localStorage`。
|
||||
> 3. 同時幫我寫 `addProductTask` 和 `deleteProductTask` 函式，每次操作都要同步更新 `localStorage`。”
|
||||
|
||||
透過這一步，你的原型就擁有了“記憶”，使用者體驗幾乎和真產品無異。
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: '完善鏈路', description: '從單點功能到完整閉環' },
|
||||
{ title: '注入靈魂', description: '模擬真實業務資料' },
|
||||
{ title: '反饋迭代', description: '基於真實反饋修補體驗' },
|
||||
{ title: '最終大作業', description: '你的畢業設計' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 3. 收集反饋與快速迭代
|
||||
|
||||
閉門造車是做不出好產品的。現在你的原型已經具備了“核心功能”+“完整鏈路”+“演示資料”，是時候拿給別人看了。
|
||||
|
||||
### 3.1 找誰測？怎麼測？
|
||||
|
||||
- **找朋友/同事**：不需要他們懂技術，只需要讓他們試著用一下。
|
||||
- **觀察而非引導**：不要說“點這裡”，而是看他們會點哪裡。如果他們找不到按鈕，說明設計有問題。
|
||||
- **“Wizard of Oz” (綠野仙蹤法)**：如果你的 AI 還沒接好，你可以人工在後臺（或資料庫）手動修改資料來模擬 AI 的返回，先驗證使用者是否需要這個功能。
|
||||
|
||||
### 3.2 面對 Bug 和 吐槽
|
||||
|
||||
- **樣式錯亂**：不同螢幕尺寸下可能會亂。
|
||||
- **Action**: 截圖發給 AI IDE -> “在這個螢幕寬度下亂了，幫我修一下。”
|
||||
- **操作別扭**：“這個流程太繁瑣了”。
|
||||
- **Action**: 把建議告訴 AI IDE -> “使用者覺得先上傳再生成太慢，能不能改成一鍵生成？”
|
||||
- **需求新增**：“如果有這個功能就好了”。
|
||||
- **Action**: 評估是否核心，如果是，讓 AI 快速實現一個簡化版。
|
||||
|
||||
**記住：在這個階段，AI 是你最好的修改助手。你只需要負責發現問題，程式碼修改交給它。**
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="3" :items="[
|
||||
{ title: '完善鏈路', description: '從單點功能到完整閉環' },
|
||||
{ title: '注入靈魂', description: '模擬真實業務資料' },
|
||||
{ title: '反饋迭代', description: '基於真實反饋修補體驗' },
|
||||
{ title: '最終大作業', description: '你的畢業設計' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
## 4. 🎓 階段大作業：完成你的“畢業設計”
|
||||
|
||||
恭喜你！你已經走完了從“需求”到“原型”再到“AI 整合”的全過程。現在，是時候展示你的最終成果了。
|
||||
|
||||
**本次大作業不再侷限於“電商素材工作臺”**。你需要結合自己的興趣或行業背景，打造一個獨一無二的 AI 產品原型。
|
||||
|
||||
### 選題與要求
|
||||
|
||||
你需要從 **[產業多分類場景方向參考](../appendix-industry-scenarios/index.md)** 中選擇一個最接近的場景，或者根據自己的想法構思一個全新的場景。
|
||||
|
||||
**專案必須綜合運用前幾節課學到的所有內容：**
|
||||
|
||||
1. **原型的構建**：使用前端技術搭建美觀、易用的介面。
|
||||
2. **需求的控制**：不求大而全，但求核心功能邏輯閉環。
|
||||
3. **API 的接入**：接入真實的 AI 模型（LLM/VLM 等），賦予應用真正的智慧。
|
||||
4. **實現一個可玩的應用**：不僅僅是靜態頁面，而是有資料流轉、有互動反饋的動態應用。
|
||||
|
||||
### 作業產出
|
||||
|
||||
最終你需要提交以下兩樣內容：
|
||||
|
||||
1. **一個完整的原型應用**：部署上線或本地可執行，具備完整的使用鏈路。
|
||||
2. **30 秒的演示影片**：錄製一段影片，簡要介紹你的應用場景，並演示核心功能的實際操作。
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🚀 最終挑戰清單</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
這是 Stage 1 的最後一戰。請按照以下清單檢查你的作品：
|
||||
</p>
|
||||
|
||||
<div style="font-weight: bold; margin-bottom: 10px;">核心功能自檢</div>
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> <strong>場景明確</strong>：選定了一個具體的行業或應用場景</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>邏輯閉環</strong>：核心流程能跑通，不僅僅是 Happy Path</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>AI 驅動</strong>：真實呼叫了大模型 API，而非預設回覆</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>體驗完整</strong>：包含 Loading、錯誤處理及模擬資料</label></li>
|
||||
</ul>
|
||||
|
||||
<div style="font-weight: bold; margin: 20px 0 10px;">交付物準備</div>
|
||||
<ul style="list-style-type: none; padding-left: 0;">
|
||||
<li><label><input type="checkbox" disabled /> <strong>原型應用</strong>：程式碼已完成並可執行</label></li>
|
||||
<li><label><input type="checkbox" disabled /> <strong>演示影片</strong>：30 秒左右，清晰展示核心亮點</label></li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 下一步
|
||||
|
||||
完成大作業後，你已經具備了“獨立開發 AI 應用原型”的能力。
|
||||
在接下來的 Stage 2 中，我們將深入更復雜的全棧開發，學習如何把這個原型變成一個真正能上線、有資料庫、有使用者系統的商業級應用。
|
||||
|
||||
讓我們在下一階段見！
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="繼續進階"
|
||||
description="恭喜完成 Stage 1，下面這些章節可以幫助你進入工程化開發。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,808 @@
|
||||
---
|
||||
title: '給原型加上 AI 能力 - 接入文字與影象 API'
|
||||
description: '在已有 Web 原型中接入真實的 AI 能力：理解 API 的核心概念，學會找到 API Key 和官方示例；實戰整合 DeepSeek 文字模型與多種影象生成服務（SiliconFlow Qwen-Image、Recraft、Seedream），並掌握常用的模型選型方法。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const duration = '約 <strong>1 天</strong>'
|
||||
const relatedArticles =
|
||||
relatedArticlesMap['zh-tw/stage-1/integrating-ai-capabilities'] ?? []
|
||||
</script>
|
||||
|
||||
# 初級四：為原型注入 AI 能力
|
||||
|
||||
## 章節導讀
|
||||
|
||||
<ChapterIntroduction :duration="duration" :tags="['API', '文字模型', '文生圖', '原型整合']" coreOutput="原型接入 1 個文字模型 + 1 個影象模型（可選）" expectedOutput="可呼叫真實 API 的 AI 原型">
|
||||
|
||||
在前面的章節中，我們完成了從<strong>找到好點子</strong>到<strong>做出產品原型</strong>的完整流程。但現在的原型還只是一個"殼子"——點選按鈕不會真的生成內容，頁面上的資料都是寫死的。
|
||||
|
||||
還記得我們在第一章強調的嗎？<strong>我們要做"有人願意買單的產品"，而不是"看起來像樣的原型"。</strong> 真正的價值來自於產品能<strong>解決真實問題</strong>，而要做到這一點，原型必須能<strong>真正執行</strong>。
|
||||
|
||||
這一章要讓原型<strong>"活"起來</strong>：我們會接入<strong>真實的 AI 能力</strong>，從拿到 API Key 開始，到讀懂官方文件、讓 AI IDE 幫你把介面整合進程式碼裡。你會以 <strong>DeepSeek 文字模型</strong>為例，學會怎麼讓應用<strong>真正呼叫大模型生成內容</strong>；如果感興趣，還可以<strong>選做影象生成的接入</strong>。
|
||||
|
||||
學完這章，你的原型就<strong>不再是靜態演示</strong>，而是<strong>能呼叫真實 AI 能力、能解決真實問題的應用</strong>。
|
||||
|
||||
</ChapterIntroduction>
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="0" :items="[
|
||||
{ title: 'API 基礎', description: '理解核心概念與安全規範' },
|
||||
{ title: '接入文字', description: 'DeepSeek 文字生成實戰' },
|
||||
{ title: '接入圖片', description: 'VLM 影象理解與生成' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
# 1. API 基礎概念
|
||||
|
||||
前面提到，我們的目標是「把 AI 能力接進來」，讓原型不再是靜態演示，而是能呼叫真實 AI 服務的工具。要實現這一點，關鍵就在於理解並使用 API（應用程式程式設計介面）。
|
||||
|
||||
API 是計算機領域的一個重要抽象概念，我們可以簡單理解為：**你按對方要求的格式"發一個問題"，對方就按同樣的格式"回一個結果"**。
|
||||
|
||||
- **你發出去的內容**：通常包括"金鑰（API Key）"和"你要生成什麼"
|
||||
- **對方回給你的內容**：成功就給結果；失敗會告訴你原因（比如"金鑰不對""餘額不足""引數寫錯"）
|
||||
|
||||
具體來說，你需要掌握以下核心要素：
|
||||
|
||||
1. **API Key**：你的"通行證"，也是"錢包鑰匙"。別人拿到它，就可以替你呼叫介面併產生費用。
|
||||
2. **Endpoint（介面路徑）**：API 請求的具體路徑，告訴伺服器你要訪問哪個功能。完整的請求地址通常由"基礎 URL + Endpoint路徑"構成。例如：
|
||||
- 文字生成：基礎URL (`https://api.service.com`) + Endpoint (`/v1/chat/completions`) = 完整URL `https://api.service.com/v1/chat/completions`
|
||||
- 影象生成：基礎URL (`https://api.service.com`) + Endpoint (`/v1/images/generations`) = 完整URL `https://api.service.com/v1/images/generations`
|
||||
3. **呼叫/請求**：向 AI 服務傳送任務並獲取結果的過程
|
||||
4. **請求內容**：你發給AI的具體內容，比如你想讓AI寫的文章主題、生成的圖片描述等。
|
||||
5. **響應結果**：AI處理完後返回給你的內容，比如生成的文章、圖片等。
|
||||
6. **錯誤處理**：當出現問題時（如API Key錯誤、請求太頻繁等），知道如何排查解決。
|
||||
|
||||
::: info ℹ️ 什麼是 API
|
||||
對於 API 的更深入的解釋，請看附錄：[API 入門](/zh-tw/appendix/4-server-and-backend/api-intro)。
|
||||
|
||||
::: warning 🔐 **API 安全注意事項**
|
||||
API Key 是你請求 AI 服務的「通行證」，它是一串密碼字串，用於身份驗證和計費。
|
||||
|
||||
由於 API Key 直接關聯賬戶和費用，務必注意：
|
||||
|
||||
- 絕對**不要分享到羣聊、截圖上傳網路**或釋出在公開論壇
|
||||
- **不要硬編碼到程式碼中**並提交到 Git 倉庫（尤其是公開倉庫）
|
||||
- 如懷疑 Key 已洩露，**立即更換新 Key**
|
||||
|
||||
我們會在下面的內容中**直接把 API KEY 貼上到 AI IDE 中進行操作**，**在正規的專案裡不要這麼做！！**，由於我們是練習可以這麼做。（等你更加熟練後，你能夠讓 AI 生成一個配置檔案，你只需要把 API KEY 放入配置檔案即可）
|
||||
:::
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="1" :items="[
|
||||
{ title: 'API 基礎', description: '理解核心概念與安全規範' },
|
||||
{ title: '接入文字', description: 'DeepSeek 文字生成實戰' },
|
||||
{ title: '接入圖片', description: 'VLM 影象理解與生成' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
# 2. 接入文字生成 API：DeepSeek
|
||||
|
||||
雖然 API 涉及這些技術概念，但在原型開發階段，實際操作可以非常簡單高效。核心思路就是：
|
||||
|
||||
> **找到官方示例、拿到 API Key、讓 AI IDE 幫你接到按鈕上。**
|
||||
|
||||
掌握了這些概念後，你會發現無論是接入文字模型還是影象模型，其本質流程都是一樣的：當使用者點選按鈕時，前端整理輸入併發起請求；介面返回結果後，再把結果展示到頁面上。接下來，我們就透過實際操作來驗證這一點。
|
||||
|
||||
在 `1.2 動手做出原型` 裡，你已經做出了一個可互動的原型。接下來我們要做的，是把原型裡“看起來像 AI 的功能”變成真正可用的能力：**當使用者點選按鈕時，原型會向外部的 AI 服務發出請求，並把返回的文字展示出來。**
|
||||
|
||||
::: info ℹ️ 原理延伸
|
||||
如果你想了解更多原理相關的內容，請檢視附錄：[大語言模型（LLM）入門](/zh-tw/appendix/8-artificial-intelligence/llm-principles)。
|
||||
::: details 瞭解更多：DeepSeek 是什麼？
|
||||
|
||||
**杭州深度求索人工智慧基礎技術研究有限公司**（Hangzhou DeepSeek Artificial Intelligence Basic Technology Research Co., Ltd.），以 DeepSeek 為商號，是一家**開發大語言模型（LLMs）的中國人工智慧（AI）公司**。DeepSeek 總部位於浙江杭州，由中國對沖基金幻方量化（High-Flyer）擁有並資助。DeepSeek 由幻方量化的聯合創始人梁文鋒於 2023 年 7 月創立，他也同時擔任這兩家公司的 CEO。該公司於 2025 年 1 月推出了同名聊天機器人及其 DeepSeek-R1 模型。
|
||||
|
||||
讓我們看看 DeepSeek 在 GPQA 基準排名中與其他頂級模型的表現對比。值得注意的是，DeepSeek 是一個開源（每個人都可以從網際網路下載模型）模型，而其他常見模型如 Grok、Google Gemini 和 ChatGPT 都是閉源的。正如我們所見，DeepSeek 已經很大程度上接近了第一梯隊的模型。
|
||||
|
||||
|
||||
|
||||
GPQA 是“研究生級 Google-Proof 問答基準”的縮寫，這是一個用於科學問答任務的研究生級基準。以下是詳細介紹。
|
||||
|
||||
GPQA 包含 448 個多項選擇題，涵蓋生物學、物理學和化學的子領域，如量子力學、有機化學、分子生物學等。這些問題由 61 位持有博士學位或正在攻讀博士學位的專家編寫，並經過了嚴格的驗證過程。
|
||||
:::
|
||||
|
||||
跟著這 3 步走，就能實現大模型生成 API 的快速整合：
|
||||
|
||||
1. **在 DeepSeek 平臺建立一個 API Key**
|
||||
2. **在 DeepSeek 文件中找到文字生成示例**（通常有現成程式碼可直接複製）
|
||||
3. **開啟 AI IDE，把 API Key + 官方示例貼上進去**，告訴 AI 要實現什麼功能：
|
||||
> 幫我接入這個大模型的 API ，支援這個應用的文案生成任務
|
||||
|
||||
接下來我們進行演示，你可以跟隨操作走一遍全流程。首先註冊 [DeepSeek](https://platform.deepseek.com/usage) 賬號並建立一個 API Key，並且充值少量費用進行驗證。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
點選“API KEYS”並在螢幕下方找到“create new API key”。你最終會得到一個像 sk-8573341c39fc44315aadc071c53rh7d2 這樣的 API key。
|
||||
|
||||
|
||||
|
||||
一旦你獲得了金鑰，你就擁有了呼叫模型的許可權。
|
||||
|
||||
此時，你可以直接閱讀 [API](https://api-docs.deepseek.com/) 文件，它通常提供 curl 或 Python 的呼叫示例。
|
||||
|
||||
|
||||
|
||||
找到示例後，你可以將文件中的所有內容以及金鑰複製到 AI IDE 的對話方塊中，要求它幫你整合大語言模型到之前已經開發的原型中。
|
||||
|
||||
|
||||
|
||||
使用提示詞參考如下：
|
||||
|
||||
```
|
||||
參考這個呼叫方法，幫我支援文案生成功能，可以基於商品資訊點選後生成對應抖音電商文案，多種風格。
|
||||
|
||||
以下參考資料：
|
||||
api key：sk-8573341c39aefa1efe
|
||||
api 請求參考：
|
||||
curl \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
|
||||
-d '{
|
||||
"model": "deepseek-chat",
|
||||
"messages": [
|
||||
{"role": "system", "content": "You are a helpful assistant."},
|
||||
{"role": "user", "content": "Hello!"}
|
||||
],
|
||||
"stream": false
|
||||
}'
|
||||
```
|
||||
|
||||
經過一段時間的 AI 程式碼生成，我們很容易得到對應的文案生成按鈕進行測試，如果你找不到入口，可以讓 AI IDE 告訴你從什麼頁面可以點到該頁面，如果實在找不到，可以讓 AI IDE 直接基於你的想法重構改進，得到最後的文案生成結果。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
當然，此處你可能想問，我怎麼知道真正呼叫了大模型而不只是內建了固定的回覆？你可以輸入自定義的文案，讓大模型根據你及時指定的自定義分析，生成對應的文案。
|
||||
|
||||
如果發現每次不一樣並且合乎邏輯，你可以放心認為此時已經正常呼叫 API 生成。你也可以在 [API 使用管理平臺](https://platform.deepseek.com/usage)檢視是否成功呼叫（雖然可能需要等幾分鐘才能看到）。
|
||||
|
||||
## 更多文字生成模型選型
|
||||
|
||||
除了 DeepSeek 之外，你也可以嘗試其他大語言模型。由於大多數模型都提供了 **OpenAI 相容介面**，切換起來非常簡單——只需要更換 API Key、基礎 URL 和模型名稱即可。
|
||||
|
||||
### MiniMax 整合
|
||||
|
||||
::: details 瞭解更多：MiniMax 是什麼？
|
||||
|
||||
**MiniMax** 是一家中國人工智慧公司，致力於通用人工智慧技術的研發。MiniMax 推出了自研的 MiniMax-M2.7 大語言模型系列，在多項基準測試中表現優異，具有極高的價效比。
|
||||
|
||||
**MiniMax-M2.7 系列的主要特點：**
|
||||
|
||||
- **超長上下文**：支援 204,800 tokens 的上下文視窗，適合處理長文件、多輪對話
|
||||
- **高價效比**：價格極具競爭力
|
||||
- **OpenAI 相容介面**：可以直接使用 OpenAI SDK 呼叫，無需額外學習新的 API 格式
|
||||
- **兩個可用模型**：
|
||||
- `MiniMax-M2.7`：旗艦模型，適合複雜任務
|
||||
- `MiniMax-M2.7-highspeed`：高速版本，保持同樣的效能但更快
|
||||
:::
|
||||
|
||||
接入方式與 DeepSeek 一致，只需要三步：
|
||||
|
||||
1. 前往 [MiniMax 開放平臺](https://platform.minimax.io/) 註冊賬號並建立 API Key
|
||||
2. 在 MiniMax 文件中找到呼叫示例
|
||||
3. 把 API Key + 示例貼上到 AI IDE 中
|
||||
|
||||
由於 MiniMax 提供了 OpenAI 相容介面，你可以直接複製下面的 curl 示例和你的 API Key，發給 AI IDE 進行整合：
|
||||
|
||||
```bash
|
||||
curl https://api.minimax.io/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer ${MINIMAX_API_KEY}" \
|
||||
-d '{
|
||||
"model": "MiniMax-M2.7",
|
||||
"messages": [
|
||||
{"role": "system", "content": "You are a helpful assistant."},
|
||||
{"role": "user", "content": "Hello!"}
|
||||
],
|
||||
"stream": false
|
||||
}'
|
||||
```
|
||||
|
||||
::: tip ✅ 提示
|
||||
MiniMax 的 API 格式與 DeepSeek 幾乎完全一致（都是 OpenAI 相容格式），所以如果你已經成功接入了 DeepSeek，切換到 MiniMax 只需要修改三個地方：
|
||||
1. **基礎 URL**：改為 `https://api.minimax.io/v1`
|
||||
2. **API Key**：使用 MiniMax 的 API Key
|
||||
3. **模型名稱**：改為 `MiniMax-M2.7` 或 `MiniMax-M2.7-highspeed`
|
||||
|
||||
更多資訊請參考 [MiniMax OpenAI 相容介面文件](https://platform.minimax.io/docs/api-reference/text-openai-api)。
|
||||
:::
|
||||
|
||||
# 3. 接入影象轉文字 API：Qwen3 VL
|
||||
|
||||
::: info ℹ️ 原理延伸
|
||||
如果你想了解更多原理相關的內容，請檢視附錄：[視覺語言模型（VLM）入門](/zh-tw/appendix/8-artificial-intelligence/multimodal-models)。
|
||||
|
||||
::: details 瞭解更多：Qwen3 VL 是什麼？
|
||||
|
||||
**Qwen3 VL** 是阿里雲通義千問團隊推出的多模態視覺語言模型系列中的最新版本。VL 代表「Vision-Language」，即視覺語言模型。它能夠理解影象內容，並根據影象生成文字描述、回答關於影象的問題、提取影象資訊等。
|
||||
|
||||
|
||||
|
||||
|
||||
**Qwen3 VL 的主要能力包括：**
|
||||
|
||||
- **影象理解**：能夠識別圖片中的物體、場景、人物、文字等內容
|
||||
- **視覺問答**：根據使用者提問，準確回答關於影象的問題
|
||||
- **影象描述**：生成詳細或簡潔的影象文字描述
|
||||
- **多圖理解**：支援同時處理多張影象，進行對比分析
|
||||
- **文字提取**：從影象中提取文字內容（OCR 能力）
|
||||
|
||||
**為什麼選擇 Qwen3 VL？**
|
||||
|
||||
相比上一代模型，Qwen3 VL 在影象理解準確性上有顯著提升，支援更長、更復雜的影象分析任務。它在中文理解方面表現優異，API 呼叫成本相對較低，價效比較高。此外，它的上下文視窗更大，能處理更復雜的視覺推理任務。
|
||||
|
||||
**典型應用場景：**
|
||||
|
||||
- 電商：商品圖片自動生成標題、描述、賣點
|
||||
- 內容創作：根據素材圖自動生成文案或配圖建議
|
||||
- 辦公：圖片內容提取、報表自動識別
|
||||
- 教育：圖片題目自動解析、知識點提取
|
||||
|
||||
:::
|
||||
|
||||
在前面的部分我們說明瞭如何接入文字生成 API， 但對於前面的應用場景我們會發現一個問題，我們上傳的是一張圖片，如果只用大語言模型，它沒辦法很好的理解圖片中的內容，生成的結果很可能會有差別。
|
||||
|
||||
我們希望有一個模型能夠幫助我們把一個圖片變成文字描述，這就需要用到視覺語言模型（VLM）。在案例中，我們將會使用視覺語言模型生成商品的賣點描述，提升使用者體驗。
|
||||
|
||||
為了方便，我們使用[雲平臺 SiliconFlow](https://cloud.siliconflow.cn/me) 提供的 API 介面進行圖生文 API 的接入。
|
||||
|
||||
::: details 瞭解更多：什麼是 Siliconflow
|
||||
**矽基流動（SiliconFlow）** 是國內知名的 AI 模型聚合平臺，提供多種主流大語言模型和視覺語言模型的 API 介面服務。
|
||||
|
||||
**平臺特點：**
|
||||
|
||||
- **多模型支援**：整合多種主流 AI 模型，包括 DeepSeek、Qwen、Llama 系列等開源模型
|
||||
- **技術最佳化**：針對開源模型進行推理最佳化，提供低延遲、高併發的 API 服務
|
||||
- **介面相容**：提供相容 OpenAI 格式的 API 介面，便於現有應用整合
|
||||
- **按需付費**：支援按呼叫量計費的方式使用
|
||||
|
||||
SiliconFlow 在開源大模型的推理服務方面較為成熟，是使用國產開源 AI 模型的常見選擇之一。
|
||||
:::
|
||||
|
||||
進入到 SiliconFlow 平臺的首頁，我們可以看到有很多模型可以選擇，左上角找到篩選器，點選展開篩選器，選擇視覺標籤，我們能看到很多圖片轉文字模型，比如智譜 GLM-4.6V，或者是 Qwen3-VL。
|
||||
|
||||
|
||||
|
||||
我們可以選擇任意一個進行測試，這裡以 `Qwen/Qwen3-VL-8B-Instruct` 為例。
|
||||
|
||||
|
||||
|
||||
進入 [ SiliconFlow 平臺](https://cloud.siliconflow.cn/me/account/ak)，在 API 金鑰中點選「新建 API 金鑰」，建立一個新的 API Key。
|
||||
|
||||
你可以直接使用下面的程式碼作為參考程式碼，和生成的 API Key 一起，傳送給 AI IDE ，進行功能整合。
|
||||
|
||||
::: details 圖片轉文字參考程式碼
|
||||
|
||||
```python
|
||||
from openai import OpenAI
|
||||
from typing import Dict, Any, List
|
||||
import base64
|
||||
import os
|
||||
SILICONFLOW_API_KEY: str = ""
|
||||
SILICONFLOW_BASE_URL: str = "https://api.siliconflow.cn/v1/"
|
||||
MODEL_NAME: str = "Qwen/Qwen3-VL-8B-Instruct"
|
||||
|
||||
def encode_image(image_path: str) -> str:
|
||||
with open(image_path, "rb") as image_file:
|
||||
return base64.b64encode(image_file.read()).decode('utf-8')
|
||||
|
||||
def get_vlm_completion(client: OpenAI, messages: List[Dict[str, Any]]) -> str:
|
||||
response = client.chat.completions.create(
|
||||
model=MODEL_NAME,
|
||||
messages=messages,
|
||||
max_tokens=512,
|
||||
temperature=0.7,
|
||||
top_p=0.7,
|
||||
frequency_penalty=0.5,
|
||||
stream=False,
|
||||
n=1
|
||||
)
|
||||
return response.choices[0].message.content
|
||||
|
||||
def caption_image(image_path: str) -> str:
|
||||
base64_image = encode_image(image_path)
|
||||
messages = [
|
||||
{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{
|
||||
"type": "text",
|
||||
"text": "Please describe this image in detail."
|
||||
},
|
||||
{
|
||||
"type": "image_url",
|
||||
"image_url": {
|
||||
"url": f"data:image/jpeg;base64,{base64_image}"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
client = OpenAI(
|
||||
api_key=SILICONFLOW_API_KEY,
|
||||
base_url=SILICONFLOW_BASE_URL
|
||||
)
|
||||
|
||||
return get_vlm_completion(client, messages)
|
||||
|
||||
image_path = "images.jpg"
|
||||
caption = caption_image(image_path)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
在這個場景中，我們直接嘗試讓 AI IDE 幫我們實現將上傳的圖片，自動生成電商賣點文字、關鍵詞的功能，如下所示：
|
||||
|
||||
```
|
||||
基於下面的圖生文介面 API ，幫我們實現將上傳的圖片，自動生成電商賣點文字、關鍵詞的功能
|
||||
|
||||
<此處省略程式碼，你需要自行貼上金鑰和參考程式碼>
|
||||
```
|
||||
|
||||
最後得到生成結果：
|
||||
|
||||
|
||||
|
||||
|
||||
<div style="margin: 50px 0;">
|
||||
<ClientOnly>
|
||||
<StepBar :active="2" :items="[
|
||||
{ title: 'API 基礎', description: '理解核心概念與安全規範' },
|
||||
{ title: '接入文字', description: 'DeepSeek 文字生成實戰' },
|
||||
{ title: '接入圖片', description: 'VLM 影象理解與生成' }
|
||||
]" />
|
||||
</ClientOnly>
|
||||
</div>
|
||||
|
||||
# 4. 接入影象生成 API：Seedream 即夢
|
||||
|
||||
在前面的部分我們主要和文字相關的任務打交道，接下來我們將嘗試接入圖片生成的功能，支援從文字描述生成圖片，或者對圖片進行修改。
|
||||
|
||||
::: info ℹ️ 原理延伸
|
||||
如果你想了解更多原理相關的內容，請檢視附錄：[影象生成入門](/zh-tw/appendix/8-artificial-intelligence/image-generation)。
|
||||
|
||||
::: details 瞭解更多：什麼是 [Seedream 即夢](https://seed.bytedance.com/en/seedream4_5)？
|
||||
|
||||
|
||||
|
||||
> 也許你已經知道 Nano Banana（Google 開發），但你最好不要錯過 Seedream。Seedream 4.5 是位元組跳動打造的新一代影象創作模型。它將影象生成和影象編輯能力整合到一個統一的架構中。這使得它能夠靈活處理複雜的多模態任務，如基於知識的生成、複雜推理和參考一致性。此外，它的推理速度比前代產品快得多，並且可以生成解析度高達 4K 的令人驚歎的高畫質影象。
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
**主要能力：**
|
||||
|
||||
- **文生圖**：用文字描述生成圖片，支援多種風格（寫實、卡通、水墨、賽博朋克等）
|
||||
- **風格遷移**：將一張圖片轉換成指定的藝術風格
|
||||
- **影象變體**：基於參考圖生成相似風格的新圖
|
||||
- **解析度提升**：增強圖片清晰度和細節
|
||||
- **影象編輯**：在現有圖片上進行編輯和修改，透過自然語言指令
|
||||
|
||||
**為什麼選擇 Seedream？**
|
||||
|
||||
- **國內網路穩定**：國內訪問速度快，延遲低
|
||||
- **效果優秀**：在電商、素材場景下表現穩定可靠
|
||||
- **中文最佳化**：對中文提示詞理解更準確，適合國內使用者
|
||||
- **速度快**：生成效率高，響應時間短
|
||||
- **質量穩定**：生成解析度高達 4K 的高畫質影象
|
||||
|
||||
**典型應用場景：**
|
||||
|
||||
- 電商：生成主圖、詳情頁配圖、促銷海報
|
||||
- 社交媒體：生成頭像、表情包、配圖
|
||||
- 設計：快速出概念圖、素材圖、背景圖
|
||||
- 營銷：製作廣告圖、活動 banner、節日海報
|
||||
|
||||
**與 Qwen3 VL 的配合：**
|
||||
|
||||
這兩個 API 可以串聯使用：先用 Qwen3 VL 分析參考圖，理解畫面內容；再用 Seedream 基於分析參考圖的提示詞內容生成新圖片。
|
||||
:::
|
||||
|
||||
你可能在抖音、B 站或 YouTube 上看到的很多 "AI 海報 / AI 主圖 / AI 角色圖"，本質上都是用到這部分介紹的技術。你需要做的事情很簡單：把使用者輸入整理成一句話，請求圖片 API，然後把返回的圖片展示出來。此時用到的模型叫做圖片生成 / 圖片編輯模型。
|
||||
|
||||
我們將逐步演示如何將 Seedream API 整合到你的專案中（透過 AI IDE 輔助完成）。
|
||||
|
||||
[訪問首頁頁面](https://www.volcengine.com/experience/ark?launch=seedream)後，點選登入。
|
||||
|
||||
|
||||
|
||||
登入後，找到頁面右上角的充值選項。
|
||||
|
||||
|
||||
|
||||
進行充值需要實名認證。
|
||||
|
||||
|
||||
|
||||
認證成功後，你可以[充值 1 元用於測試](https://console.volcengine.com/finance/fund/recharge)。
|
||||
|
||||
返回[初始介面](https://www.volcengine.com/experience/ark?launch=seedream)並點選 API 訪問。
|
||||
|
||||
|
||||
|
||||
首先，建立一個 API key，然後點選選擇選項。
|
||||
|
||||
|
||||
|
||||
這將帶你進入第 2 步。在這裡，你需要確認呼叫的服務是 Seedream 4.5，並複製提供的呼叫示例。（此處截圖時間比較早起，故而模型版本仍然是 4.0）
|
||||
|
||||
|
||||
|
||||
準備好 API Key 和呼叫示例後，你可以直接將它們貼上到 AI IDE 中，讓它生成前端互動演示或把能力接入現有原型。注意到在圖片中可以選擇是文生圖還是多張圖片生成單張圖，你需要根據當前的需求進行選擇參考程式碼。
|
||||
|
||||
::: warning ⚠️ 重要提示
|
||||
這裡的預設示例相對複雜。記得禁用 **"新增水印"** 和 **"流式響應"**，以確保不生成水印且不會發生請求失敗。
|
||||
:::
|
||||
|
||||
由於我們之後使用的是參考圖生成模式，我們先去的是多張圖生成單張圖的功能。參考程式碼複製如下：
|
||||
|
||||
```
|
||||
curl -X POST https://ark.cn-beijing.volces.com/api/v3/images/generations \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer xxxxxxx" \
|
||||
-d '{
|
||||
"model": "doubao-seedream-4-5-251128",
|
||||
"prompt": "將圖1的服裝換為圖2的服裝",
|
||||
"image": ["https://ark-project.tos-cn-beijing.volces.com/doc_image/seedream4_imagesToimage_1.png", "https://ark-project.tos-cn-beijing.volces.com/doc_image/seedream4_imagesToimage_2.png"],
|
||||
"sequential_image_generation": "disabled",
|
||||
"response_format": "url",
|
||||
"size": "2K",
|
||||
"stream": false,
|
||||
"watermark": true
|
||||
}'
|
||||
```
|
||||
|
||||
有了影象參考程式碼後，我們讓 AI IDE 支援電商中常用的影象任務功能：
|
||||
|
||||
```
|
||||
請你基於下面 API，幫我實現這個工程中，電商業務的常見功能（例如海報生成、抖音電商首圖生成等等）
|
||||
|
||||
<此處貼上 API KEY以及影象編輯程式碼>
|
||||
```
|
||||
|
||||
實現效果如下:
|
||||
|
||||
|
||||
|
||||
值得注意的是，由於生成圖片可能會經常遇到一些奇怪的問題，建議你需要讓 AI IDE 能夠顯示完整的報錯資訊，方便複製貼上進行修改（否則可能會反覆顯示生成失敗但是不知道為什麼），例如你可以說：
|
||||
|
||||
```
|
||||
不要只顯示圖片生成失敗，每次都顯示完整的失敗原因，比如圖片不匹配、請求錯誤、超時等等！
|
||||
```
|
||||
|
||||
有時候修改後更新並不會應用到網頁中，如果你發現修改後網頁一直還在報錯（反覆多次），也可以試試直接對 AI IDE 說：請你重啟這個專案。
|
||||
|
||||
在電商的業務中，我們可能會想讓使用者上傳的衣服能夠自動穿在人物身上，又或者是自動生成商品吸引人的售賣圖、海報。這裡我們嘗試的提示詞是讓它生成一個電商海報：
|
||||
|
||||
|
||||
|
||||
你可以根據自己想象的業務場景，使用文生圖或者圖生圖 API 實現不同的功能。
|
||||
|
||||
## 更多不同影象服務選型
|
||||
|
||||
下面給出其他選擇。建議你先跑通 Qwen 生圖的結果，再根據效果與成本使用下列服務做替換（根據實際使用感受選擇）。
|
||||
|
||||
### Recraft 整合
|
||||
|
||||
如果你的原型更偏“設計生產”（例如生成品牌風格插畫、營銷海報、向量風格素材），Recraft 往往會更順手。接入方式與上一節完全一致：**拿到 Key + 找到官方示例 + 讓 AI IDE 把示例落到你的按鈕/頁面裡**。
|
||||
|
||||
::: details 瞭解更多：什麼是 Recraft？
|
||||
|
||||
> Recraft 是一款面向設計師、插畫師和營銷人員的 AI 工具——於 2022 年在美國成立，總部位於倫敦。它幫助生成/迭代視覺效果（影象、向量藝術、3D 圖形），具有高質量輸出（任何文字大小/長度）、精確元素定位和品牌一致性設計等優勢。受到 200 個國家/地區 300 多萬使用者（包括奧美、Netflix）的信任，並已建立了 3.5 億多張影象，其團隊旨在使其成為必備的設計師工具，確保創作者能夠控制他們的 AI 輔助工作流程。
|
||||
>
|
||||
> 
|
||||
> 
|
||||
|
||||
首先，我們仍然需要找到[ API 入口](https://www.recraft.ai/profile/api)以獲取 API Key。
|
||||
|
||||
由於這裡沒有提供免費額度，我們需要自己充值 1,000 積分。這個網站支援支付寶和微信支付，所以很容易獲得 1,000 積分（注意：不要充值超過必要的金額）。
|
||||
|
||||
|
||||
|
||||
之後，我們仍然遵循同樣的方法：去官方文件找到相應的請求示例：
|
||||
|
||||
- <https://www.recraft.ai/docs/api-reference/getting-started>
|
||||
- <https://www.recraft.ai/docs/api-reference/usage>
|
||||
- <https://www.recraft.ai/docs/api-reference/guides>
|
||||
|
||||
:::
|
||||
|
||||
### Qwen Image / Qwen Image Edit 整合
|
||||
|
||||
如果你希望使用更簡單的方式接入影象生成服務，可以考慮 Qwen Image（通義萬相）。思路同樣不變：把它當成一個"圖片生成 API"，接到你的原型按鈕上即可。
|
||||
|
||||
::: details 瞭解更多：Qwen Image / Qwen Image Edit 是什麼？
|
||||
|
||||
**Qwen Image**（也稱通義萬相）是阿里雲通義團隊推出的影象生成模型系列，主要包括兩大模型：
|
||||
|
||||
**1. Qwen Image——文生圖（Text-to-Image）模型**
|
||||
|
||||
根據文字描述生成全新的圖片。你輸入一段提示詞，模型會理解你的意圖並生成符合描述的影象。
|
||||
|
||||
|
||||
|
||||
**主要能力：**
|
||||
|
||||
- **文生圖**：用文字描述生成圖片，支援多種風格（寫實、卡通、水墨、賽博朋克等）
|
||||
- **風格遷移**：將一張圖片轉換成指定的藝術風格
|
||||
- **影象變體**：基於參考圖生成相似風格的新圖
|
||||
- **解析度提升**：增強圖片清晰度和細節
|
||||
|
||||
**2. Qwen Image Edit——圖生圖（Image-to-Image）模型**
|
||||
|
||||
在現有圖片上進行編輯和修改。透過自然語言指令，讓模型理解你的修改意圖並生成結果。
|
||||
|
||||
**主要能力：**
|
||||
|
||||
- **區域性替換**：替換圖片中的某個物體或人物（如「把背景換成海邊」）
|
||||
- **元素移除**：去除圖片中不需要的元素
|
||||
- **風格轉換**：給圖片新增濾鏡或藝術效果
|
||||
- **影象擴充套件**：擴充套件圖片邊界，生成新內容
|
||||
- **智慧修圖**：自動美化、調整光影、修復瑕疵
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**為什麼選擇 Qwen Image 系列？**
|
||||
|
||||
- **中文最佳化**：對中文提示詞理解更準確，適合國內使用者
|
||||
- **成本低**：相比國際競品，價格更實惠
|
||||
- **速度快**：生成效率高，響應時間短
|
||||
- **質量穩定**：在電商、素材場景下表現穩定可靠
|
||||
- **風格多樣**：支援多種藝術風格和創意效果
|
||||
|
||||
**典型應用場景：**
|
||||
|
||||
- 電商：生成主圖、詳情頁配圖、促銷海報
|
||||
- 社交媒體：生成頭像、表情包、配圖
|
||||
- 設計：快速出概念圖、素材圖、背景圖
|
||||
- 營銷：製作廣告圖、活動 banner、節日海報
|
||||
:::
|
||||
|
||||
檢視 [SiliconFlow](https://siliconflow.cn/) 的官網。左側有一個"Playground"部分，你可以在不進行 API 呼叫的情況下試用不同的模型。在網頁頂部有一個"Filters"按鈕；點選它可以篩選右側的模型列表。
|
||||
|
||||
如果你選擇"Image"，你將只看到當前支援的所有文生圖模型。在這種情況下，我們將使用 Qwen/Qwen-Image。
|
||||
|
||||
|
||||
|
||||
一切設定好後，我們需要參考相應的影象生成 API 文件。你可以在官方文件頁面找到任何標記為"API Reference"的部分。點選它，然後導航到[影象生成的 API 部分](https://docs.siliconflow.cn/cn/api-reference/images/images-generations)並找到相關的請求示例。
|
||||
|
||||
你可以把下列請求示例和 API KEY 一起發給 AI IDE， 即可實現影象生成的功能。
|
||||
|
||||
```bash
|
||||
curl --request POST \
|
||||
--url https://api.siliconflow.cn/v1/images/generations \
|
||||
--header 'Authorization: Bearer <token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '
|
||||
{
|
||||
"model": "Qwen/Qwen-Image-Edit-2509",
|
||||
"prompt": "an island near sea, with seagulls, moon shining over the sea, light house, boats int he background, fish flying over the sea"
|
||||
}
|
||||
'
|
||||
```
|
||||
|
||||
這裡的模型可以使用 Qwen/Qwen-Image 或者 Qwen/Qwen-Image-Edit-2509。
|
||||
|
||||
::: details 影象編輯參考程式碼
|
||||
|
||||
複製下列程式碼和 key，一起傳送給 AI IDE：
|
||||
|
||||
```python
|
||||
import requests
|
||||
import os
|
||||
from typing import Dict, Any, Optional
|
||||
|
||||
SILICONFLOW_API_KEY: str = ""
|
||||
SILICONFLOW_BASE_URL: str = "https://api.siliconflow.cn/v1/images/generations"
|
||||
QWEN_IMAGE_EDIT_MODEL: str = "Qwen/Qwen-Image-Edit-2509"
|
||||
|
||||
def generate_image_edit(
|
||||
prompt: str,
|
||||
image: Optional[str] = None,
|
||||
image2: Optional[str] = None,
|
||||
image3: Optional[str] = None,
|
||||
negative_prompt: Optional[str] = None,
|
||||
cfg: Optional[float] = 4.0,
|
||||
seed: Optional[int] = None
|
||||
) -> Optional[Dict[str, Any]]:
|
||||
payload: Dict[str, Any] = {
|
||||
"model": QWEN_IMAGE_EDIT_MODEL,
|
||||
"prompt": prompt,
|
||||
}
|
||||
if image:
|
||||
payload["image"] = image
|
||||
if image2:
|
||||
payload["image2"] = image2
|
||||
if image3:
|
||||
payload["image3"] = image3
|
||||
if negative_prompt:
|
||||
payload["negative_prompt"] = negative_prompt
|
||||
if cfg is not None:
|
||||
payload["cfg"] = cfg
|
||||
if seed is not None:
|
||||
payload["seed"] = seed
|
||||
|
||||
headers: Dict[str, str] = {
|
||||
"Authorization": f"Bearer {SILICONFLOW_API_KEY}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
try:
|
||||
response = requests.post(SILICONFLOW_BASE_URL, json=payload, headers=headers)
|
||||
response.raise_for_status()
|
||||
return response.json()
|
||||
except requests.exceptions.RequestException as e:
|
||||
print(f"Error generating image: {e}")
|
||||
return None
|
||||
|
||||
def save_image_from_url(image_url: str, output_path: str = "image.png") -> bool:
|
||||
try:
|
||||
response = requests.get(image_url)
|
||||
response.raise_for_status()
|
||||
os.makedirs(os.path.dirname(output_path) if os.path.dirname(output_path) else ".", exist_ok=True)
|
||||
with open(output_path, "wb") as f:
|
||||
f.write(response.content)
|
||||
print(f"Image saved successfully to: {output_path}")
|
||||
return True
|
||||
except requests.exceptions.RequestException as e:
|
||||
print(f"Error downloading image: {e}")
|
||||
return False
|
||||
except Exception as e:
|
||||
print(f"Error saving image: {e}")
|
||||
return False
|
||||
|
||||
prompt: str = "讓天空變成傍晚，有月亮和星星，夢幻風格"
|
||||
negative_prompt: str = "模糊, 低質量, 扭曲"
|
||||
image_url: str = "https://inews.gtimg.com/om_bt/Os3eJ8u3SgB3Kd-zrRRhgfR5hUvdwcVPKUTNO6O7sZfUwAA/641"
|
||||
image2_url: Optional[str] = None
|
||||
image3_url: Optional[str] = None
|
||||
|
||||
cfg: float = 4.0
|
||||
seed: int = 12345
|
||||
output_path: str = "edited_image.png"
|
||||
|
||||
print(f"Generating edited image with prompt: {prompt}")
|
||||
print(f"Input image: {image_url}")
|
||||
print(f"CFG: {cfg}, Seed: {seed}")
|
||||
print("-" * 50)
|
||||
|
||||
result = generate_image_edit(
|
||||
prompt=prompt,
|
||||
image=image_url,
|
||||
image2=image2_url,
|
||||
image3=image3_url,
|
||||
negative_prompt=negative_prompt,
|
||||
cfg=cfg,
|
||||
seed=seed
|
||||
)
|
||||
|
||||
if result and "images" in result:
|
||||
images = result["images"]
|
||||
if images and len(images) > 0:
|
||||
image_url_result = images[0]["url"]
|
||||
print(f"Image edit generated successfully. URL: {image_url_result}")
|
||||
success = save_image_from_url(image_url_result, output_path)
|
||||
if success:
|
||||
print(f"Image saved to: {output_path}")
|
||||
else:
|
||||
print("Failed to save image to local file")
|
||||
else:
|
||||
print("No images found in response")
|
||||
else:
|
||||
print("Image generation failed")
|
||||
if result:
|
||||
print(f"Response: {result}")
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
# 附錄：如何找到“當前更強”的 AI 模型
|
||||
|
||||
文字模型（也常被叫作“大語言模型”）的發展速度非常快，我們總是需要確保我們用的是表現更好的模型之一。透過以下兩個網站，你可以很方便地看到“現在大家常用、評價也更好的模型”。
|
||||
|
||||
一般來說，這類網站可以理解為 **“模型競技場”**：它會把兩個模型的輸出放在一起，你投票選你更喜歡的那個。票數高的模型，通常意味著更多人覺得它“更好用”。
|
||||
|
||||
此外，你偶爾可能會在這些大模型競技場中看到神祕的匿名模型（“Unknown Model”）。這通常意味著：有人把“內部測試模型”悄悄放進來做盲測，你可能有機會提前體驗到更強的能力。
|
||||
|
||||
## LMArena
|
||||
|
||||
網站：<https://lmarena.ai/>
|
||||
|
||||
LMArena 更適合用來判斷“多數人更偏好哪個模型的回答”。投票越多、分數越高，通常意味著它在真實使用場景裡更穩。
|
||||
|
||||
一個簡單的用法是：
|
||||
|
||||
1. 直接看排行榜（Leaderboard）
|
||||
2. 先選一個你要做的方向（例如通用對話 / 程式設計 / 視覺）
|
||||
3. 選 Top 3 裡你能用的那個（能訪問、價格能接受、延遲能接受）
|
||||
|
||||
|
||||
|
||||
## Artificial Analysis
|
||||
|
||||
網站：<https://artificialanalysis.ai/>
|
||||
|
||||
Artificial Analysis 更適合把“效果 / 價格 / 速度”放在同一張表裡對比，你可以把它當作模型選型的參數列。
|
||||
|
||||
常用的用法是：
|
||||
|
||||
1. 找到你關心的模型類別（文字 / 生圖等）
|
||||
2. 看質量指標（Quality）+ 價格（Price）+ 延遲/吞吐（Latency/Throughput）
|
||||
3. 選一個“綜合價效比”最符合你產品的
|
||||
|
||||
::: tip ✅ 建議
|
||||
不要憑感覺爭論“哪個更強”。更可靠的做法是：用同一組輸入同時測試 2~3 個模型，再結合榜單與價格做決定。
|
||||
:::
|
||||
|
||||
## 總結
|
||||
|
||||
在接入各類 AI 服務時，不必把 API 想象得太複雜。把握住以下幾個核心概念，基本就能應對大多數場景：
|
||||
|
||||
**API 的本質是通訊橋樑**。它做的事情很簡單：把你的請求傳送出去，再把模型的響應帶回來。你不需要關心背後發生了什麼，只需要正確地組織請求格式。
|
||||
|
||||
**SDK 是對 API 的封裝**。如果說 API 是 raw 介面，SDK 就是一套現成的工具箱——它把請求籤名、錯誤處理、引數校驗這些繁瑣的細節都替你做好了。日常開發中，優先選擇 SDK 而不是直接調 API，能省去不少麻煩。
|
||||
|
||||
**閱讀文件時，盯住三樣東西就夠了**：服務地址（endpoint）、身份憑證（API key）以及呼叫引數怎麼填。把這三點弄清楚，調通只是時間問題。
|
||||
|
||||
剩下的工作，IDE 和現代化的開發工具會幫你完成。專注於你的業務邏輯，底層呼叫的事交給這些成熟的 SDK 和工具鏈。
|
||||
|
||||
# 5. 📚 作業：整合你的第一個 AI 能力
|
||||
|
||||
<el-card shadow="hover" style="margin: 20px 0; border-radius: 12px;">
|
||||
<template #header>
|
||||
<div style="font-weight: bold; font-size: 16px;">🚀 挑戰任務：整合 AI 能力到你的工作臺</div>
|
||||
</template>
|
||||
|
||||
<p>
|
||||
參考本節課的提示詞和內容，完成一次完整閉環：
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>
|
||||
<strong>完整閉環實踐</strong>
|
||||
<ul>
|
||||
<li>選擇並接入一個 AI 服務（LLM / 文生圖 / 圖生圖）→ 實現前後端互動 → 整合到你的原型中</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>成果分享</strong>
|
||||
<ul>
|
||||
<li>截圖你的功能頁面分享給大家看</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>
|
||||
<strong>思考題</strong>
|
||||
<ul>
|
||||
<li>為下一節"完整專案實踐"預留空間，提前思考：你打算如何把這些 AI 能力組合起來，做出什麼有意思的功能？</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</el-card>
|
||||
|
||||
## 下一步
|
||||
|
||||
在下一節中，我們將把這些分散的 AI 能力串聯起來，結合實際業務場景做一個完整的產品：
|
||||
|
||||
- 把內容策劃、商品上架、資料分析等環節串聯成一條完整的業務流程
|
||||
- 將本節課學到的 AI 能力（LLM 文案生成、文生圖、影象編輯等）嵌入到實際業務節點中
|
||||
- 實現一個真正可用的"電商 AI 工作臺"，而不是孤立的 demo
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="相關文章"
|
||||
description="從“單點 AI 能力”到“完整產品流程”的推薦學習路徑。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,275 @@
|
||||
---
|
||||
title: '從創意到 AI 產品 - Easy-Vibe 學習路線圖'
|
||||
description: '學習 AI 程式設計完整路線圖：從零基礎到全棧開發。掌握 Vibe Coding、Claude Code、Cursor 等 AI IDE 工具，學會產品思維、全棧開發和 AI 能力整合。'
|
||||
---
|
||||
|
||||
<script setup>
|
||||
import { relatedArticlesMap } from '@theme/data/relatedArticles'
|
||||
|
||||
const relatedArticles = relatedArticlesMap['zh-tw/stage-1/learning-map'] ?? []
|
||||
</script>
|
||||
|
||||
# 從創意到 AI 產品
|
||||
|
||||
::: info 特別感謝
|
||||
特別感謝來自 **清華大學深圳國際研究生院** 的同學們對本課程的測試、反饋和支援！你們的意見和貢獻讓這門課程變得更好。[👉 檢視完整貢獻者名單](https://github.com/datawhalechina/easy-vibe#-contributing--contributors)
|
||||
:::
|
||||
|
||||
以前做軟體，門檻很高：你要懂程式設計、懂演算法，還得有幾年的專案經驗。
|
||||
現在不一樣了。只要你有想法，AI 就能幫你寫程式碼。
|
||||
|
||||
這是一個巨大的變化：**程式語言正在變成自然語言**。
|
||||
|
||||
大語言模型（LLM）的出現，讓開發不再是“技術大神的專屬”，而是變成了每個人都能上手的工具。曾經最難的是“怎麼寫程式碼”，現在最難的是“**你要做什麼**”。
|
||||
|
||||
> **什麼是 Vibe Coding？**
|
||||
> 簡單說，就是“用說話來程式設計”。 氛圍程式設計的意思是你可以依賴只和 AI 對話，而不是直接寫程式碼的方式，來完成程式設計專案。
|
||||
|
||||
當然，讓 AI 寫出程式碼只是第一步。要做出一個真正能用的產品，你還會遇到這些問題：
|
||||
- 怎麼讓 AI 寫出乾淨、能維護的程式碼？
|
||||
- 怎麼把零散的程式碼拼成一個能跑的應用？
|
||||
- 怎麼讓應用真正上線、被人用到？
|
||||
- 怎麼把文字生成、影象識別這些 AI 能力裝進你的產品？
|
||||
|
||||
這些問題將在這門課中找到答案。
|
||||
|
||||
不管你是學生、老師、醫生、工人，還是任何一位對技術一竅不通的普通人——不用先學幾年程式設計，兩週時間就能做出能跑、能演示的產品原型。
|
||||
|
||||
| 你的身份 | 這門課能幫你 |
|
||||
|---------|-------------|
|
||||
| 學生 | 作業、比賽、創業，自己動手做專案，不再求人 |
|
||||
| 職場人 | 把重複工作自動化，提升效率，甚至開發副業 |
|
||||
| 產品經理 / 設計師 | 想法不再停留在紙面，能快速做出 Demo 給老闆/客戶看 |
|
||||
| 創業者 / 中小企業主 | 低成本驗證想法，不用花幾萬塊找外包也能做出 MVP |
|
||||
| 老師 / 教育工作者 | 製作教學工具、課件、自動化出題，提升教學效率 |
|
||||
| 醫生 / 律師 / 專業工作者 | 把專業流程自動化，打造自己的效率工具 |
|
||||
| 任何人 | 用 AI 解決生活/工作中的具體問題，讓不可能變成可能 |
|
||||
|
||||
AI 時代，執行力和想法永遠比技術更重要。
|
||||
|
||||
## 成長路徑：從“會用 AI”到“會做 AI 產品”
|
||||
|
||||
<div class="stage-intro">
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🎮</div>
|
||||
<h3>新手入門</h3>
|
||||
<p class="stage-role">體驗 AI 程式設計</p>
|
||||
<div class="stage-tags">
|
||||
<span>貪喫蛇小遊戲</span>
|
||||
<span>零基礎上手</span>
|
||||
<span>Vibecoding 初體驗</span>
|
||||
<span>幾分鐘生成</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="stage-grid">
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🛠️</div>
|
||||
<h3>第一階段</h3>
|
||||
<p class="stage-role">產品經理 / 運營</p>
|
||||
<div class="stage-tags">
|
||||
<span>AI IDE (Cursor/Claude)</span>
|
||||
<span>需求拆解 & 原型</span>
|
||||
<span>接入 AI 能力</span>
|
||||
<span>完整 Demo 開發</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">💻</div>
|
||||
<h3>第二階段</h3>
|
||||
<p class="stage-role">初中級開發 / 獨立開發者</p>
|
||||
<div class="stage-tags">
|
||||
<span>Figma 到程式碼</span>
|
||||
<span>Supabase 資料庫</span>
|
||||
<span>Stripe 支付整合</span>
|
||||
<span>Dify 知識庫</span>
|
||||
</div>
|
||||
</div>
|
||||
<div class="stage-card">
|
||||
<div class="stage-icon">🚀</div>
|
||||
<h3>第三階段</h3>
|
||||
<p class="stage-role">高階開發 / 架構師</p>
|
||||
<div class="stage-tags">
|
||||
<span>Web/小程式/多端</span>
|
||||
<span>MCP 高階工具</span>
|
||||
<span>RAG & LangGraph</span>
|
||||
<span>高階工程師思維</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<style>
|
||||
.stage-intro {
|
||||
margin: 20px auto;
|
||||
max-width: 400px;
|
||||
}
|
||||
|
||||
.stage-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
|
||||
gap: 12px;
|
||||
margin: 16px 0;
|
||||
}
|
||||
|
||||
.stage-card {
|
||||
border: 1px solid var(--vp-c-divider);
|
||||
border-radius: 10px;
|
||||
padding: 12px;
|
||||
background-color: var(--vp-c-bg-soft);
|
||||
transition: all 0.3s ease;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
text-align: center;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.stage-card:hover {
|
||||
transform: translateY(-2px);
|
||||
background-color: var(--vp-c-bg-mute);
|
||||
box-shadow: 0 4px 16px rgba(0, 0, 0, 0.05);
|
||||
border-color: var(--vp-c-brand);
|
||||
}
|
||||
|
||||
.stage-icon {
|
||||
font-size: 2rem;
|
||||
margin-bottom: 8px;
|
||||
line-height: 1;
|
||||
}
|
||||
|
||||
.stage-card h3 {
|
||||
margin: 0 0 4px 0 !important;
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
line-height: 1.2;
|
||||
}
|
||||
|
||||
.stage-role {
|
||||
margin: 0 0 8px 0 !important;
|
||||
font-size: 0.8rem;
|
||||
color: var(--vp-c-text-2);
|
||||
font-weight: 500;
|
||||
}
|
||||
|
||||
.stage-tags {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
justify-content: center;
|
||||
gap: 4px;
|
||||
}
|
||||
|
||||
.stage-tags span {
|
||||
font-size: 0.7rem;
|
||||
padding: 1px 6px;
|
||||
border-radius: 3px;
|
||||
background-color: var(--vp-c-bg-alt);
|
||||
color: var(--vp-c-text-2);
|
||||
border: 1px solid var(--vp-c-divider);
|
||||
}
|
||||
|
||||
.stage-card:hover .stage-tags span {
|
||||
background-color: var(--vp-c-bg);
|
||||
border-color: var(--vp-c-brand-dimm);
|
||||
color: var(--vp-c-brand-dark);
|
||||
}
|
||||
</style>
|
||||
|
||||
透過這個完整的學習路徑，你將獲得：
|
||||
|
||||
- **Vibe Coding開發能力：** 熟練使用 vibecoding 思維和 AI 編碼工具，將開發效率提升數倍。不再需要死記硬背語法，而是學會如何引導 AI 生成高質量程式碼。
|
||||
- **全棧開發技能：** 從 UI 設計到前端實現，從資料庫設計到 API 開發，從本地開發到雲端部署，掌握現代 Web 應用的完整技術棧。
|
||||
- **AI 能力整合：** 學會呼叫各類多模態 AI API，將文字、影象、語音等 AI 能力無縫整合到你的應用中，並透過 RAG 等技術構建智慧化產品。
|
||||
- **產品思維與運營能力：** 從使用者研究到需求拆解，從 MVP 設計到產品迭代，從支付整合到使用者管理，形成完整的產品開發與運營閉環。
|
||||
|
||||
# 學完能做什麼？
|
||||
|
||||
## 第一階段：做出你的第一個產品原型
|
||||
|
||||
這個階段適合完全沒程式設計基礎，或者只會一點點但不太自信的同學。你不用先學一堆理論知識，而是直接跟著做，在做的過程中學會用 AI 工具寫程式碼。
|
||||
|
||||
**學完你能**：
|
||||
- 用 AI 程式設計工具獨立完成一個網頁應用
|
||||
- 把產品想法變成能點選、能互動的原型
|
||||
- 給原型加上 AI 功能（比如文生圖、智慧對話）
|
||||
- 遇到報錯知道怎麼排查和解決
|
||||
|
||||
簡單說，就是能做出一個"能跑、能給別人演示"的東西。
|
||||
|
||||
我們可以先透過小遊戲感受 AI 程式設計，然後學會用 AI 程式設計工具幫你寫程式碼、改報錯。接著從簡單頁面開始，逐步做出能互動的多頁面應用，再加上文生圖、智慧對話這些 AI 功能。最後獨立完成一個完整專案，讓你的創意能夠真正擁有落地的可能。
|
||||
|
||||
# 為什麼要用專案制來訓練？
|
||||
|
||||
> **現實世界的挑戰**
|
||||
>
|
||||
> 原因其實很簡單：按照大多數同學現在的狀態，直接走入職場，很可能會在真實專案和老闆 / 客戶的“社會毒打”下寸步難行。現實世界更常見的場景是：
|
||||
|
||||
> 你的導師 / 老闆：我們要做一個 xxx，目標是達到 yyy 的效果。
|
||||
>
|
||||
> 文件？現成框架？詳細的需求說明？很多時候都不存在。
|
||||
|
||||
真實工作中的許多工，本質上就是在高度不確定的環境下解決從未見過的問題：需求是模糊的，邊界是變化的，沒人告訴你標準答案，你需要自己查資料、做實驗、搭原型、不斷迭代，最後給出一個“能跑、能用、能上線”的解決方案。
|
||||
|
||||
這門課想做的，就是在一個相對安全的環境裡，提前給你一次“模擬社會毒打”：
|
||||
|
||||
- 透過看似有一定難度的專案任務，迫使你練習拆解問題、設計方案、自己尋找資料
|
||||
- 透過不那麼“傻瓜化”的腳手架和程式碼，讓你學會閱讀、理解和改造一份中大型程式碼庫
|
||||
- 透過從創意到上線的完整閉環，讓你體驗真實產品從 0 到 1 的完整過程
|
||||
|
||||
短期來看，這種訓練確實比較折磨人；但從長期來看，它會極大提高你在求職和職業發展中的競爭力：你會更能扛事兒，更能在不確定環境中找到突破口，也更有能力把 AI 變成真正落地的產品，而不是停留在“玩玩 Demo”階段。
|
||||
|
||||
# 提問的藝術：AI 時代的必備技能
|
||||
|
||||
在 AI 時代，提問也屬於一種 “基本功”。同一份程式碼、同一個報錯，**你怎麼提問，幾乎決定了 AI 能給出怎樣的答案**：是泛泛而談，還是一步一步給出可落地的改法。
|
||||
|
||||
**養成好習慣**：把“向 AI 提問”當成日常開發流程的一部分：遇到不懂、卡住的問題就立刻問。
|
||||
|
||||
## 為什麼這是必備技能？
|
||||
|
||||
- **現實很少有完整文件**：更多時候你面對的是不清晰的需求、半成品程式碼、零散的錯誤資訊
|
||||
- **AI 是你隨身的導師 + 同事**：會提問的人，能把它變成“高質量的結對程式設計”
|
||||
- **能力上限由溝通決定**：你越能提供關鍵資訊、越能約束輸出格式，答案越可用
|
||||
|
||||
**常見誤區**：只問一句“為啥報錯？”通常只能得到一堆猜測。把上下文補齊，才會得到可執行的方案。
|
||||
|
||||
## 如何把資訊"餵給"AI：截圖 vs 複製貼上
|
||||
|
||||
兩種方式都可以，但用途不同：
|
||||
|
||||
| 方式 | 適用場景 | 關鍵要求 |
|
||||
| ------------ | ----------------------------------------- | ----------------------------------------- |
|
||||
| **複製貼上** | 報錯堆疊、日誌、程式碼、配置、API 返回 | 儘量完整，不要只截一行關鍵字 |
|
||||
| **截圖** | UI 佈局問題、互動異常、工具介面找不到按鈕 | 截全屏 + 標註重點區域，最好配一句文字說明 |
|
||||
|
||||
::: danger ⚠️ 重要前提
|
||||
**並非所有 AI 都支援圖片輸入。** 截圖溝通需要 AI 具備多模態能力（即能夠理解和分析圖片）。目前支援圖片輸入的 AI 包括：Claude (Anthropic)、GPT-4V/GPT-4o (OpenAI)、Gemini (Google)、以及部分國產大模型如通義千問、文心一言等。
|
||||
|
||||
**如果你使用的 AI 不支援圖片輸入**，截圖將無法被識別，此時請改用複製貼上文字的方式溝通。
|
||||
:::
|
||||
|
||||
## 讓 AI “解釋得很好”的提示詞技巧
|
||||
|
||||
如果你不是隻要答案，而是要“學會”答案。使用類似下面指令能顯著提升解釋質量：
|
||||
|
||||
> **學習型提問示例**
|
||||
>
|
||||
> - “請先用 5 句話講清楚這個概念，再給幾個問題提問我驗證我理解對了沒。”
|
||||
> - ”請你詳細解釋一下這個報錯資訊，我不理解為什麼會報錯。”
|
||||
|
||||
# 堅持了好久還是搞不定，我想放棄了
|
||||
|
||||
也許是你堅持的方法不對。不要一個人在黑暗中硬撐，可以來跟作者和助教們聊聊：把你已經嘗試過的方法、遇到的具體卡點、和你目前的心理狀態，坦誠地說出來。很多時候，只要稍微調整一下方向、補上一個關鍵知識點，你就能繼續往前走。
|
||||
|
||||
# 我覺得教程有的設計不合理
|
||||
|
||||
歡迎隨時聯絡作者、提交 issue，或者在羣裡 / 課堂上直接反饋。我們非常希望和你一起把這套教程打磨得越來越好：哪裡不清晰、哪裡體驗不好、哪裡讓你白費力氣，都可以坦誠指出來。越真實、越具體的反饋，越能幫助後來者少踩坑。
|
||||
|
||||
# Reference
|
||||
|
||||
- [南京大學 電腦科學與技術系 計算機系統基礎 課程實驗](https://nju-projectn.github.io/ics-pa-gitbook/ics2025/)
|
||||
|
||||
<RelatedArticlesSection
|
||||
title="接下來可以學什麼"
|
||||
description="按“從會用 AI 到會做產品”的路線，繼續向前推進。"
|
||||
:items="relatedArticles"
|
||||
/>
|
||||
Reference in New Issue
Block a user