品經(jīng)理從原型到簡歷的完整作品集實戰(zhàn))
聊聊最近被不少 AI 產(chǎn)品經(jīng)理同行問爆的一個組合Vibe Coding ChatBI。圈子里好像一夜之間都在聊“用嘴寫代碼”“讓 AI 自己搭數(shù)據(jù)分析系統(tǒng)”。很多朋友想把這套東西做成作品集寫進簡歷但又不知道從哪兒開始下手更不知道簡歷上到底該怎么寫才不虛。先說結(jié)論Vibe Coding 不是歪門邪道也不是“偷懶不寫代碼”它是 AI 時代產(chǎn)品經(jīng)理快速驗證想法的一種新的工作方式。而 ChatBI對話式數(shù)據(jù)智能是目前最適合拿來當作品集落地場景的 AI 應用之一——需求清晰、價值明顯、技術鏈路完整面試官一看就懂問起來也有話聊。這篇文章我會從一個 AI 產(chǎn)品經(jīng)理的實際視角出發(fā)拆解三件事Vibe Coding 到底是什么、怎么用它把一個 ChatBI 從想法變成能跑的原型以及最后怎么把這個作品集專業(yè)地寫進簡歷里。全程給可復用的提示詞、代碼思路和簡歷模板不是那種只講概念的空文章。1. 背景與核心概念1.1 為什么 AI 產(chǎn)品經(jīng)理需要“作品集”傳統(tǒng)產(chǎn)品經(jīng)理找工作靠的是 PRD、原型圖、數(shù)據(jù)報告和講項目故事的能力。但 AI 產(chǎn)品經(jīng)理面臨的情況不太一樣面試官尤其是一線技術負責人很難通過文檔判斷你是否真的理解 AI 能力邊界。你說你設計過一個智能客服問你 Prompt 怎么調(diào)優(yōu)、模型幻覺怎么處理、召回率怎么測答不上來就露餡了。作品集的核心作用是證明“我不光會畫圖寫文檔我真的動手把一個 AI 應用從概念推到了可用狀態(tài)”。而 AI 產(chǎn)品經(jīng)理的作品集和程序員的作品集有一個本質(zhì)區(qū)別重點不是代碼寫得多漂亮而是你如何定義問題、拆解功能、評估效果、迭代優(yōu)化。所以作品集不要求你有高級工程師的編碼水平但要求你能用最低成本把想法落地成可體驗、可演示、可分析的產(chǎn)品。1.2 Vibe Coding 是什么解決什么問題Vibe Coding 這個詞最早流行起來源于大家發(fā)現(xiàn)用自然語言給 AI 編程助手比如 Cursor、Claude、GPT 的 Artifacts、DeepSeek、通義靈碼等下達指令已經(jīng)能完成相當一部分實際開發(fā)工作。它不強調(diào)手寫每一行代碼而是強調(diào)用清晰的意圖描述驅(qū)動 AI 生成代碼自己負責判斷、組合、調(diào)試和驗證。對 AI 產(chǎn)品經(jīng)理來說Vibe Coding 的意義不是替代工程師而是快速做原型把想法直接跟 AI 說幾分鐘拿到一個可點擊、可交互、可演示的頁面。驗證技術可行性不確定某個功能能不能做直接讓 AI 寫一版試試比爭論半天都有效。降低溝通成本你手上有個能跑的 Demo和技術團隊溝通需求時大家對著真實系統(tǒng)討論而不是對著文字想象。補齊產(chǎn)品 Sense 到技術理解之間的空檔通過親手調(diào)試 Prompt、修改參數(shù)、觀察錯誤日志你能真正理解模型的能力邊界。有人可能會擔心這是不是在鼓勵產(chǎn)品經(jīng)理搶工程師的活我個人的觀點是Vibe Coding 產(chǎn)出的是“原型”“樣板”和“作品集”不是高并發(fā)高可用的商業(yè)系統(tǒng)。你的目標是用它來驗證和表達而不是用它替代專業(yè)研發(fā)流程。1.3 ChatBI 是什么為什么適合做成作品集ChatBI 是 Chat Business Intelligence 的縮寫指通過自然語言對話的方式來查詢、分析和理解業(yè)務數(shù)據(jù)。你可以把它理解成一個“能聊天”的數(shù)據(jù)分析助手。傳統(tǒng) BI 工具要求用戶會拖拽報表、懂維度指標、能自己寫 SQLChatBI 做的事情是讓用戶直接問“上個月華東區(qū)域的銷售額環(huán)比增長了多少哪個品類貢獻最大”系統(tǒng)自動理解問題生成查詢邏輯返回結(jié)果甚至自動生成圖表。ChatBI 作為 AI 產(chǎn)品經(jīng)理的作品集有幾個天然優(yōu)勢需求場景普及幾乎每個公司都有數(shù)據(jù)分析需求面試官完全能理解這個產(chǎn)品解決什么問題。技術鏈路完整涉及 NL2SQL、意圖識別、Prompt 工程、可視化、數(shù)據(jù)權限、效果評估這些都是 AI 產(chǎn)品經(jīng)理面試的高頻話題?？闪炕Ч媚憧梢越o出“SQL 生成準確率”“查詢響應時間”“端到端任務完成率”等指標這些都是作品集里的硬通貨。能獨立完成借助 Vibe Coding一個人就能搭出可演示的版本不需要依賴后端團隊、數(shù)據(jù)團隊和測試資源。1.4 容易混淆的概念澄清很多初學者會把幾個相關概念搞混概念核心能力與 ChatBI 的區(qū)別傳統(tǒng) BITableau、Power BI可視化報表、拖拽分析需要用戶手動配置圖表和指標學習成本高Chatbot智能客服對話問答、任務辦理偏向服務交互不一定涉及數(shù)據(jù)庫查詢ChatBI自然語言 → 數(shù)據(jù)查詢 → 分析與展示強調(diào)“對話即分析”核心是理解和查詢數(shù)據(jù)Copilot編程助手在 IDE 里輔助寫代碼面向研發(fā)場景不是面向業(yè)務分析場景搞清楚這些邊界寫簡歷時才能精確表達自己作品集的定位。2. 環(huán)境準備與工具選型做作品集不需要企業(yè)級技術架構(gòu)我們的原則是夠用、開源、免費、演示順暢。2.1 我選擇的工具鏈下面是我個人的方案你可以根據(jù)手頭資源調(diào)整用途工具選擇選型理由Vibe Coding 主環(huán)境Cursor 或 Claude / DeepSeek 對話窗口Cursor 適合邊聊邊改代碼對話式工具適合快速生成完整腳本編程語言Python 3.10AI 生成代碼最容易穩(wěn)定運行的語言生態(tài)完善前后端框架Streamlit純 Python 寫 Web 應用幾百行代碼就能做出像樣的界面數(shù)據(jù)庫SQLite無需安裝數(shù)據(jù)庫服務單文件存儲作品集演示零成本向量數(shù)據(jù)庫ChromaDB用于存放樣例問題和 SQL 模板提升 NL2SQL 準確率LLM APIOpenAI GPT-4o / DeepSeek / Qwen任選其一即可取決于你的預算和可用性依賴管理requirements.txt pip保持環(huán)境簡單方便他人復現(xiàn)2.2 需要確認的版本說明我必須先聲明大模型相關 API 和工具版本變化非常快下面給出的版本號只是說明我在寫這篇文章時的常見選擇。你實際使用時請以官方最新文檔為準不要照搬。# 建議使用 Python 3.10 或 3.11 python --version # 安裝核心依賴注意版本可能隨時間更新 pip install streamlit pip install openai pip install langchain pip install chromadb pip install pandas pip install sqlite3 # 一般內(nèi)置無需單獨安裝如果你所在的網(wǎng)絡環(huán)境不方便直接訪問部分外部服務可以選擇國內(nèi)可用的模型服務商或者通過代理方式訪問這里不展開。2.3 示例項目結(jié)構(gòu)我在做這個作品集時項目目錄如下chatbi-mvp/ ├── app.py # Streamlit 入口頁面 ├── nl2sql.py # 核心模塊自然語言轉(zhuǎn) SQL ├── database/ │ ├── init_db.py # 初始化數(shù)據(jù)庫和樣例數(shù)據(jù) │ └── sales.db # SQLite 數(shù)據(jù)庫文件 ├── prompts/ │ └── sql_prompt.py # Prompt 模板 ├── examples/ │ └── few_shot_examples.py # 少樣本示例用于提升準確率 ├── requirements.txt └── README.md這個結(jié)構(gòu)夠清晰面試官一眼能看出你對項目有工程化思維而不是把代碼堆在一個文件里。3. Vibe Coding 實操方法論從想法到原型這一節(jié)是整篇文章最關鍵的部分。我不會直接給你一堆代碼而是先講 Vibe Coding 的操作方法。因為只有掌握了這套方法你以后才能快速做出不同主題的作品集。3.1 第一輪用自然語言讓 AI 生成腳手架我第一次做 ChatBI 原型時沒有先寫架構(gòu)文檔而是直接打開 Cursor輸入了這樣一段 Prompt你是一名 Python 開發(fā)工程師請幫我搭建一個 ChatBI MVP 項目的骨架。 要求如下 1. 使用 Streamlit 作為 Web 界面框架 2. 用戶輸入中文問題系統(tǒng)返回 SQL 查詢語句、執(zhí)行結(jié)果和圖表 3. 數(shù)據(jù)庫使用 SQLite提前生成一個銷售訂單表包含 100 條左右的測試數(shù)據(jù)字段包括 - order_id - order_date - region - product_category - sales_amount - quantity 4. 先別寫完整功能只生成項目目錄結(jié)構(gòu)和每個文件的占位代碼。 請直接輸出每個文件的完整代碼。這段 Prompt 的關鍵信息非常明確技術棧、數(shù)據(jù)表結(jié)構(gòu)、輸出格式要求。AI 生成的代碼一開始當然不完美但不重要。第一輪的目標是拿到一個能跑起來的骨架。3.2 第二輪逐模塊迭代而不是一次到位拿到骨架后不要急著讓 AI 一次性把所有功能全部補齊那樣很容易生成一大堆互相不兼容的代碼。我的建議是把完整需求拆成下面幾個模塊分別對話解決模塊一數(shù)據(jù)初始化讓 SQLite 有數(shù)據(jù)可查模塊二LLM 調(diào)用封裝讓程序可以請求大模型接口模塊三NL2SQL 核心邏輯自然語言轉(zhuǎn)成 SQL 語句模塊四結(jié)果解析與可視化把查詢結(jié)果渲染成圖表模塊五異常處理SQL 生成錯誤時給出兜底方案每次對 AI 只提一個小需求。比如請給 nl2sql.py 寫一個函數(shù)輸入是用戶問題中文輸出是一條 SQL 查詢語句。 要求 1. 先獲取數(shù)據(jù)表的 schema也就是表名、字段名、字段類型和主鍵信息 2. 把 schema 和 few-shot 示例一起放進 Prompt 3. 解析 LLM 返回的 SQL去掉 markdown 格式代碼塊標記 4. 如果生成失敗返回空字符串。這樣做的優(yōu)勢是每個模塊的代碼都短小、邏輯清晰即使出現(xiàn) Bug 也容易定位。這就是 Vibe Coding 和傳統(tǒng)開發(fā)的典型差異——我們通過“對話 小步迭代”替代了“一次性編碼”。3.3 第三輪運行、報錯、反饋、優(yōu)化Vibe Coding 的本質(zhì)不只是讓 AI 寫代碼還包括讓 AI 幫你改代碼。運行報錯時直接把錯誤信息復制回對話窗口運行 app.py 時出現(xiàn)以下報錯請分析原因并給出修復后的代碼。 Streamlit run app.py 報錯信息 sqlite3.OperationalError: table sales_orders has no column named order_dateAI 能根據(jù)報錯信息迅速定位問題通常是因為我們初始化數(shù)據(jù)庫時字段名不一致。它會把相關代碼段重新生成一遍你復制覆蓋即可。這個“運行-報錯-反饋-修復”的循環(huán)就是 Vibe Coding 的核心工作流。你要習慣把自己當成項目經(jīng)理和測試人員而不是“打字員”。3.4 關于“避免幻覺功能”的提醒使用 Vibe Coding 時最大的風險是讓 AI 生成了它“以為自己能做”但實際運行不了的功能。比如讓它接入一些并不存在的第三方 API或者編造不存在的 Python 庫。我的規(guī)避方法有兩條在 Prompt 里明確要求使用主流、成熟、真實存在的庫拿到 AI 給的代碼后先看它 import 了哪些庫逐個確認這些庫是否真實存在、是否能正常安裝。如果 AI 給出的某個庫你從來沒聽說過不要直接相信先去 PyPI 或 GitHub 搜一下再決定。這是 AI 產(chǎn)品經(jīng)理應該養(yǎng)成的技術敬畏心。4. 實戰(zhàn)用 Vibe Coding 從零構(gòu)建 ChatBI 最小可行版本下面進入完整實戰(zhàn)環(huán)節(jié)。我盡量把每一步寫清楚讓你可以照著做出來。4.1 初始化數(shù)據(jù)庫與樣例數(shù)據(jù)首先準備好數(shù)據(jù)。在項目根目錄創(chuàng)建database/init_db.py。# 文件路徑database/init_db.py import sqlite3 import random from datetime import datetime, timedelta def create_database(db_pathdatabase/sales.db): conn sqlite3.connect(db_path) cursor conn.cursor() # 創(chuàng)建銷售訂單表 cursor.execute( CREATE TABLE IF NOT EXISTS sales_orders ( order_id INTEGER PRIMARY KEY AUTOINCREMENT, order_date TEXT NOT NULL, region TEXT NOT NULL, product_category TEXT NOT NULL, sales_amount REAL NOT NULL, quantity INTEGER NOT NULL ) ) # 生成測試數(shù)據(jù) regions [華東, 華南, 華北, 西南] categories [數(shù)碼產(chǎn)品, 家用電器, 服飾鞋包, 食品飲料] start_date datetime(2024, 1, 1) random.seed(42) # 固定隨機種子保證數(shù)據(jù)可復現(xiàn) for i in range(200): order_date start_date timedelta(daysrandom.randint(0, 365)) region random.choice(regions) category random.choice(categories) amount round(random.uniform(50, 2000), 2) quantity random.randint(1, 10) cursor.execute( INSERT INTO sales_orders (order_date, region, product_category, sales_amount, quantity) VALUES (?, ?, ?, ?, ?), (order_date.strftime(%Y-%m-%d), region, category, amount, quantity) ) conn.commit() conn.close() print(數(shù)據(jù)庫初始化完成共插入 200 條銷售訂單。) if __name__ __main__: create_database()運行初始化腳本python database/init_db.py預期輸出數(shù)據(jù)庫初始化完成共插入 200 條銷售訂單。這個腳本有三個教學點值得你在簡歷里提到字段設計、隨機種子保證數(shù)據(jù)可復現(xiàn)、SQLite 輕量化的選型理由。4.2 編寫 Prompt 模板與少樣本示例NL2SQL 的核心是 Prompt 設計。我們要讓模型知道有哪些表、哪些字段、用戶的問題是什么意思、應該生成什么 SQL。先創(chuàng)建prompts/sql_prompt.py# 文件路徑prompts/sql_prompt.py def build_sql_prompt(schema_text: str, examples_text: str, user_question: str) - str: prompt f 你是一個數(shù)據(jù)分析師負責把用戶的中文問題轉(zhuǎn)換成 SQL 查詢語句。 請嚴格遵循以下規(guī)則 1. 只能根據(jù)給定的表結(jié)構(gòu)生成 SQL不能臆造不存在的字段 2. 只輸出 SQL 語句本身不要輸出解釋、不要使用 Markdown 代碼塊標記 3. 查詢結(jié)果必須是聚合后的匯總數(shù)據(jù)不允許返回明細行 4. 如果用戶問題中指定了時間范圍要使用 WHERE 條件進行過濾 5. 金額相關字段需要輸出保留兩位小數(shù) 6. 如果問題無法用給定表結(jié)構(gòu)回答請輸出: ERROR: 無法生成查詢 數(shù)據(jù)庫表結(jié)構(gòu)如下 {schema_text} 參考示例 {examples_text} 用戶問題{user_question} SQL: return prompt再創(chuàng)建examples/few_shot_examples.py這里放了幾個典型問題用來引導模型生成風格統(tǒng)一的 SQL# 文件路徑examples/few_shot_examples.py FEW_SHOT_EXAMPLES [ { question: 上個月華東區(qū)域的銷售額是多少, sql: SELECT region, ROUND(SUM(sales_amount), 2) AS total_sales FROM sales_orders WHERE region 華東 AND order_date BETWEEN 2024-11-01 AND 2024-11-30 GROUP BY region }, { question: 哪個產(chǎn)品類別累計銷售額最高, sql: SELECT product_category, ROUND(SUM(sales_amount), 2) AS total_sales FROM sales_orders GROUP BY product_category ORDER BY total_sales DESC LIMIT 1 }, { question: 西南區(qū)域今年第一季度各個月份的訂單數(shù)量趨勢如何, sql: SELECT strftime(%Y-%m, order_date) AS month, COUNT(*) AS order_cnt FROM sales_orders WHERE region 西南 AND order_date BETWEEN 2024-01-01 AND 2024-03-31 GROUP BY month ORDER BY month }, { question: 華南區(qū)域銷量最高的商品類別是哪一類, sql: SELECT product_category, SUM(quantity) AS total_quantity FROM sales_orders WHERE region 華南 GROUP BY product_category ORDER BY total_quantity DESC LIMIT 1 }, { question: 最近一個月平均每筆訂單的金額是多少, sql: SELECT ROUND(AVG(sales_amount), 2) AS avg_order_amount FROM sales_orders WHERE order_date 2024-11-30 - INTERVAL 30 DAY }, ]需要說明的是最后一個示例里的INTERVAL語法在 SQLite 中不一定直接生效實際使用時應統(tǒng)一用字符串日期比較。這里保留原樣是想提醒你AI 生成的 SQL 并不總是和數(shù)據(jù)庫方言匹配審查 SQL 是產(chǎn)品經(jīng)理必須具備的能力。因此我們在運行時會對生成的 SQL 做兩層校驗下面會講到。4.3 編寫獲取 Schema 的工具函數(shù)要讓模型寫出正確 SQL必須把數(shù)據(jù)庫結(jié)構(gòu)告訴它。寫一個工具函數(shù)用 SQLite 的系統(tǒng)表查詢字段信息# 文件路徑nl2sql.py部分代碼 import sqlite3 def get_schema(db_path: str database/sales.db) - str: conn sqlite3.connect(db_path) cursor conn.cursor() cursor.execute(SELECT name FROM sqlite_master WHERE typetable) tables [row[0] for row in cursor.fetchall()] schema_parts [] for table in tables: cursor.execute(fPRAGMA table_info({table})) columns cursor.fetchall() col_desc , .join([f{col[1]} {col[2]} for col in columns]) schema_parts.append(f表名: {table}, 字段: {col_desc}) conn.close() return \n.join(schema_parts)這里用PRAGMA table_info獲取字段名和類型信息足夠簡潔適合放進 Prompt。需要說明的是這里的fPRAGMA table_info({table})屬于內(nèi)部信任場景因為表名來自系統(tǒng)表不是直接拼接用戶輸入因此在演示場景下風險可控。如果對接真實業(yè)務庫不能直接這樣寫應該使用參數(shù)化查詢方式獲取元數(shù)據(jù)。4.4 編寫 NC2SQL 主流程下面來寫nl2sql.py的完整核心邏輯。它負責四件事獲取 Schema、調(diào)用模型生成 SQL、校驗 SQL、執(zhí)行 SQL。# 文件路徑nl2sql.py import re import sqlite3 from openai import OpenAI from prompts.sql_prompt import build_sql_prompt from examples.few_shot_examples import FEW_SHOT_EXAMPLES client OpenAI(api_keyyour-api-key, base_urlyour-base-url) # 取決于你的模型服務商 def get_schema(db_path: str database/sales.db) - str: # 省略同上文 get_schema 函數(shù) def extract_sql(text: str) - str: 從模型輸出中提取純 SQL去掉可能的 markdown 標記 # 去掉代碼塊標記 text re.sub(rsql|, , text).strip() return text def validate_sql(sql: str) - bool: 簡單校驗 SQL 是否包含風險或異常語法 blacklist [INSERT, UPDATE, DELETE, DROP, ALTER, CREATE] for word in blacklist: if re.search(r\b word r\b, sql.upper()): return False return True def execute_sql(sql: str, db_path: str database/sales.db): conn sqlite3.connect(db_path) try: cursor conn.cursor() cursor.execute(sql) columns [desc[0] for desc in cursor.description] if cursor.description else [] rows cursor.fetchall() return columns, rows except Exception as e: return None, f執(zhí)行錯誤: {e} finally: conn.close() def nl2sql(user_question: str) - dict: schema get_schema() examples_text for item in FEW_SHOT_EXAMPLES: examples_text f問題: {item[question]}\nSQL: {item[sql]}\n\n prompt build_sql_prompt(schema, examples_text, user_question) response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], temperature0.1, ) raw_sql response.choices[0].message.content sql extract_sql(raw_sql) # 判斷是否生成失敗 if sql.startswith(ERROR) or sql : return {error: 無法理解該問題請嘗試換個說法。} # 判斷是否包含非法 SQL if not validate_sql(sql): return {error: 生成的 SQL 存在安全風險已阻止執(zhí)行。} # 執(zhí)行 SQL columns, rows execute_sql(sql) if columns is None: return {error: rows} return {columns: columns, rows: rows, sql: sql}關鍵步驟說明temperature0.1讓模型輸出更穩(wěn)定減少隨意生成。extract_sql是為了兼容不同模型輸出格式有的模型喜歡帶 markdown 代碼塊。validate_sql是安全兜底避免模型生成非查詢語句。這很重要正式做 ChatBI 時不能直接執(zhí)行模型生成的 SQL。execute_sql捕獲執(zhí)行異常保證至少不會讓整個 Web 應用崩潰。4.5 編寫圖表可視化邏輯為了讓作品集看起來更完整我們在拿到查詢結(jié)果后嘗試根據(jù)字段特征自動判斷是否適合畫圖。# 文件路徑app.py部分代碼 import pandas as pd import streamlit as st from nl2sql import nl2sql import matplotlib.pyplot as plt plt.rcParams[font.sans-serif] [SimHei, Arial Unicode MS, PingFang SC] plt.rcParams[axes.unicode_minus] False def auto_visualize(columns, rows): 根據(jù)返回的字段做簡單的可視化判斷。 如果只有一個維度字段和一個數(shù)值字段輸出柱狀圖或折線圖。 df pd.DataFrame(rows, columnscolumns) if len(df.columns) 2: first_col df.columns[0] second_col df.columns[1] if pd.api.types.is_numeric_dtype(df[second_col]): fig, ax plt.subplots(figsize(10, 5)) ax.bar(df[first_col].astype(str), df[second_col]) ax.set_xlabel(first_col) ax.set_ylabel(second_col) ax.set_title(f{first_col} vs {second_col}) plt.xticks(rotation45, haright) st.pyplot(fig)這一步不用太復雜關鍵是讓面試官和用戶直觀感受到“系統(tǒng)不僅能問答還能自動給出圖表”。4.6 編寫 Streamlit 界面最后是 Web 界面層。我們希望用戶輸入一個問題點擊按鈕看到三個東西生成的 SQL、查詢結(jié)果表格、對應圖表。# 文件路徑app.py import streamlit as st import pandas as pd from nl2sql import nl2sql def auto_visualize(columns, rows): # 省略同上文 def main(): st.set_page_config(page_titleChatBI 數(shù)據(jù)問答助手, layoutwide) st.title( ChatBI 數(shù)據(jù)問答助手) st.caption(輸入你的業(yè)務問題系統(tǒng)將自動完成 SQL 生成、執(zhí)行與可視化展示。) user_question st.text_input(請輸入你的問題, placeholder比如華東區(qū)域銷售額最高的商品類別是什么) if st.button(開始分析, typeprimary): if not user_question.strip(): st.warning(請先輸入問題。) return with st.spinner(正在理解和生成查詢...): result nl2sql(user_question) if error in result: st.error(result[error]) return st.subheader(生成的 SQL) st.code(result[sql], languagesql) st.subheader(查詢結(jié)果) columns result[columns] rows result[rows] df pd.DataFrame(rows, columnscolumns) st.dataframe(df, use_container_widthTrue) st.subheader(可視化分析) auto_visualize(columns, rows) if __name__ __main__: main()運行方式streamlit run app.py瀏覽器會自動打開http://localhost:8501。輸入中文問題就能看到完整的問答分析過程。4.7 運行效果預期當你輸入“華東區(qū)域銷售額最高的商品類別是什么”時預期輸出大致是生成的 SQLSELECT product_category, ROUND(SUM(sales_amount), 2) AS total_sales FROM sales_orders WHERE region 華東 GROUP BY product_category ORDER BY total_sales DESC LIMIT 1數(shù)據(jù)表格一列是商品類別一列是累計銷售額按降序排列?？梢暬瘓D表因為第一列是字符串、第二列是數(shù)值系統(tǒng)自動繪制柱狀圖。雖然這個 MVP 還不夠智能但它已經(jīng)是一個完整的 ChatBI 閉環(huán)足夠放進作品集里講清楚產(chǎn)品邏輯。5. 進階提升讓 ChatBI 更接近真實產(chǎn)品只跑通一個簡單 Demo 是不夠的AI 產(chǎn)品經(jīng)理的作品集一定要體現(xiàn)“思考深度”。下面這幾個方向你可以選 1 到 2 個在作品集里展示。5.1 加入語義緩存機制在很多 ChatBI 場景中用戶會反復問類似的問題。如果每次都調(diào)用大模型生成 SQL成本高、響應慢。一個簡單有效的優(yōu)化是引入語義緩存。思路先把用戶問題轉(zhuǎn)成 embedding 向量然后在 ChromaDB 里查找最相似的歷史問題。如果相似度超過一個閾值比如 0.85直接返回歷史 SQL 和結(jié)果。# 思路示例語義緩存 from chromadb import Client # 1. 初始化 Chroma 集合 # 2. 將每個歷史問題寫入 collection同時存儲 SQL 和結(jié)果 # 3. 用戶提問時先用 embedding 搜索相似記錄 # 4. 相似度高直接返回否則走 NL2SQL 主鏈路這個機制進簡歷非常加分因為它體現(xiàn)你考慮了成本、性能和產(chǎn)品體驗的平衡。5.2 加入多輪對話能力上面的 MVP 只支持單輪對話。真實產(chǎn)品中用戶會追問“那華北呢”“占比是多少”這些問題依賴上下文。優(yōu)化思路有兩種簡單法把歷史對話記錄拼進 Prompt讓模型自己理解當前問題是否依賴上文。結(jié)構(gòu)法在對話歷史中抽取實體和條件區(qū)域、時間、品類填充一個“查詢條件槽位”。作為作品集建議先實現(xiàn)簡單法后說明結(jié)構(gòu)法的演進方向。5.3 加入數(shù)據(jù)權限控制真實 ChatBI 最重要的工程問題之一是數(shù)據(jù)權限。不是所有用戶都有權限查看所有區(qū)域的數(shù)據(jù)。你可以在作品集里加上一個簡單的角色權限模型# 思路示例權限控制 # 1. 定義用戶角色比如 admin、analyst、visitor # 2. 根據(jù)角色生成不同的 SQL 過濾條件 # 3. 例如 visitor 只在 WHERE 條件中強制追加 user_region 華東 # 4. 在原型中通過側(cè)邊欄切換角色演示不同身份看到的數(shù)據(jù)范圍不同這個功能不用寫得很復雜但一定要在 README 和簡歷里說明因為這直接展示了你作為 AI 產(chǎn)品經(jīng)理對“安全邊界”的理解。6. 如何把 ChatBI 作品集寫進簡歷作品集做出來了最關鍵的一步來了怎么在簡歷里展示它。6.1 簡歷項目描述通用框架我建議參考 STAR 法則但寫簡歷時不需要嚴格寫成四段。核心是讓面試官在 30 秒內(nèi)看懂三個信息背景、動作、結(jié)果。信息項內(nèi)容建議項目背景一句話說明為什么做這個 ChatBI時間跨度寫清楚周期最好在 2-4 周內(nèi)你的角色獨立完成或作為 AI 產(chǎn)品經(jīng)理主導核心動作Vibe Coding、Prompt 工程、NL2SQL、可視化、安全機制量化結(jié)果SQL 生成準確率、響應時間、功能覆蓋率技術棧Python、Streamlit、SQLite、LLM API6.2 簡歷項目描述示例下面給一個可以直接參考的寫法注意替換為你的實際數(shù)據(jù)和指標ChatBI 對話式數(shù)據(jù)分析助手獨立開發(fā) / 2025.03 - 2025.04 項目背景 企業(yè)內(nèi)部運營人員日常取數(shù)依賴數(shù)據(jù)團隊大量常見問題通過即時通訊工具紙質(zhì)傳遞查詢效率低、口徑不一致。 項目動作 - 基于 Vibe Coding 方法論使用 Python Streamlit 完成 ChatBI MVP 從需求拆解到可運行原型 - 設計 NL2SQL 核心鏈路通過 LLM 將中文問題轉(zhuǎn)換為 SQL結(jié)合 sqlite schema 注入、few-shot 示例增強生成準確率 - 設計結(jié)果可視化模塊根據(jù)字段類型自動選擇柱狀圖、折線圖或明細表展示 - 加入語義緩存、多輪對話擴展方案降低接口調(diào)用成本 - 設計用戶角色與數(shù)據(jù)權限控制邏輯確保不同角色只能查看授權范圍內(nèi)的數(shù)據(jù)。 量化結(jié)果 - 在 200 條銷售訂單數(shù)據(jù)上常見業(yè)務問題的 SQL 生成準確率達到約 92% - 將語義緩存命中后的查詢響應從平均 8 秒降低至 1 秒以內(nèi) - MVP 從需求確定到可演示版本交付耗時 2 周全程獨立完成 - 沉淀了一套可復用的 NL2SQL 提示詞模板和 SQL 安全校驗規(guī)則。 技術棧Python、Streamlit、SQLite、ChromaDB、OpenAI API / DeepSeek API需要提醒的是準確率 92% 這種數(shù)字不能拍腦袋亂寫。我的建議是自己在測試集上跑一遍記錄真實結(jié)果后填進去。哪怕準確率只有 75%只要說明測試條件和改進路徑也比虛標數(shù)字更有說服力。6.3 面試時如何講解這個作品集面試官通常會從三個角度追問技術理解類NL2SQL 的難點是什么幻覺問題怎么處理產(chǎn)品判斷類為什么選 ChatBI 這個場景目標用戶是誰工程落地類模型返回錯誤 SQL 怎么辦如何防止用戶越權查數(shù)建議在本地留一個可運行的 Demo 包面試時直接打開 Streamlit 現(xiàn)場演示。這比任何口頭描述都有說服力。你需要準備好一段 3 分鐘的演示腳本講清楚“用戶輸入問題 → 生成 SQL → 執(zhí)行 → 可視化”的完整流程。7. 常見問題與排查思路7.1 常見問題匯總問題現(xiàn)象常見原因解決思路輸入問題后長時間無響應LLM API 響應慢或網(wǎng)絡不穩(wěn)定檢查 API 服務狀態(tài)設置超時時間落地語義緩存模型生成的 SQL 執(zhí)行報錯字段名與 schema 不一致在 Prompt 中強調(diào)只使用給定字段查看報錯信息反饋給 AI 修復SQL 能執(zhí)行但結(jié)果明顯不對缺少 WHERE 條件或聚合方式錯誤補充 few-shot 示例降低 temperature中文圖表亂碼matplotlib 缺少中文字體設置字體為 SimHei 或 PingFang SCStreamlit 頁面打不開端口被占用或依賴未裝齊檢查streamlit run app.py的啟動日志嘗試換端口數(shù)據(jù)庫大量重復數(shù)據(jù)重復運行 init_db.py在腳本里增加刪除舊表或判斷是否已存在的邏輯7.2 排查優(yōu)先級清單如果系統(tǒng)跑不通不要慌按下面的順序排查數(shù)據(jù)庫是否有數(shù)據(jù)打開database/sales.db確認sales_orders表非空API 是否可用在 Python 里單獨測試一次client.chat.completions.create看能否返回內(nèi)容Prompt 是否正確拼接打印出build_sql_prompt的完整輸出檢查 schema 和 examples 是否有語法問題SQL 校驗是否過嚴確認沒有誤殺合法的 SELECT 語句頁面渲染是否出錯查看 Streamlit 終端的完整 traceback定位到具體行號。8. 最佳實踐與工程建議8.1 Vibe Coding 過程的工程素養(yǎng)Vibe Coding 不等于“沒有工程素養(yǎng)”。恰恰相反AI 產(chǎn)品經(jīng)理更應該具備工程思維否則很容易被 AI 生成的一堆花哨代碼帶偏。幾點建議版本控制必須有哪怕是小項目也建議用 Git 管理否則改壞了無法回退。每個版本“能跑即提交”不要等技術債積累太多才想起保存。記錄 Prompt 迭代過程你每次怎么修改 Prompt 才讓模型輸出變好這是 AI 產(chǎn)品經(jīng)理作品集里的隱形資產(chǎn)。保持項目結(jié)構(gòu)整潔即使代碼是 AI 寫的也要堅持模塊化拆分不要一個文件寫 800 行。8.2 安全邊界這是 ChatBI 類作品最重要的部分絕不能讓模型生成的 SQL 直接在生產(chǎn)庫上執(zhí)行必須加白名單機制、SQL 校驗和資源限制明確定義安全邊界作品集演示可以用 SQLite但簡歷里一定要寫清楚“正式方案中需要接入查詢網(wǎng)關、數(shù)據(jù)脫敏、行級權限”提示詞注入風險不要在業(yè)務數(shù)據(jù)中直接拼接用戶輸入到 Prompt 之外的部分涉及真實數(shù)據(jù)時必須經(jīng)過授權和脫敏處理。8.3 效果評估方法ChatBI 不是“能跑就行”。一個合格的數(shù)據(jù)分析助手必須有一套評估維度評估維度說明評估方式查詢生成準確率生成的 SQL 是否與預期結(jié)果一致構(gòu)建測試集人工標注端到端成功率用戶提問后是否成功返回結(jié)果日志統(tǒng)計響應時間從提問到結(jié)果展示的總耗時日志統(tǒng)計用戶滿意率用戶對回答是否滿意問卷或反饋按鈕兜底率無法回答時是否有友好提示日志統(tǒng)計建議在作品集 README 里寫清楚評估方式和測試結(jié)果這比“Demo 做得很炫”更有專業(yè)深度。9. 總結(jié)與下一步行動路線9.1 你已經(jīng)掌握了什么通過這篇文章你已經(jīng)了解到Vibe Coding 的核心工作流自然語言 → 生成代碼 → 運行報錯 → 反饋修復 → 迭代優(yōu)化從零構(gòu)建 ChatBI MVP 的完整鏈路數(shù)據(jù)準備、Prompt 設計、NL2SQL、業(yè)務校驗、可視化展示ChatBI 產(chǎn)品在真實落地時需要關注的進階能力語義緩存、多輪對話、數(shù)據(jù)權限控制如何把一個作品集項目專業(yè)地寫進簡歷并準備好面試講解路徑。9.2 下一步推薦做什么我一直強調(diào)AI 產(chǎn)品經(jīng)理最重要的不是堆代碼量而是形成“定義問題 - 快速驗證 - 量化評估 - 持續(xù)迭代”的閉環(huán)?；谶@個思路建議你接下來做以下增強把自己測試的真實業(yè)務數(shù)據(jù)替換掉樣例數(shù)據(jù)讓作品集更有業(yè)務說服力嘗試接入一個國內(nèi)可用的模型服務比如 DeepSeek驗證不同模型在 NL2SQL 場景下的表現(xiàn)差異增加 10 條真實測試用例記錄準確率變化形成一份簡短的效果評估報告把整個項目放進 GitHub順便把 README 寫完整讓別人可以復現(xiàn)。當你完成上面這些動作之后這個作品集就不只是一個“AI 生成的 Demo”而是一個能證明你具備 AI 產(chǎn)品經(jīng)理核心能力的完整項目。9.3 作品集的長期意義最后說一點真心話。Vibe Coding 必然會繼續(xù)進化模型能力也會越來越強也許未來會出現(xiàn)更輕量的方式直接構(gòu)建數(shù)據(jù)問答系統(tǒng)。但無論工具怎么變作為 AI 產(chǎn)品經(jīng)理真正稀缺的能力始終是判斷什么場景值得做知道怎么把模糊想法拆成可落地的功能邊界能評估模型和產(chǎn)品的效果差距在哪里能推動一個 AI 功能從“能跑”走向“好用”。ChatBI 只是切入點。通過這個作品集你證明的不是“我會用 AI 寫代碼”而是“我能用 AI 把一個產(chǎn)品想法變成可體驗、可評估、可演進的原型”。接下來就動手打開 Cursor 或任意一個 AI 編程工具把上面第 4 節(jié)的代碼結(jié)構(gòu)跑通。遇到問題也不用怕報錯信息直接貼給 AI改就完了。Vibe Coding 的樂趣恰恰就在這個“邊聊邊改、不斷逼近可用狀態(tài)”的過程里。如果這篇文章對你有幫助可以收藏備用。要是你想了解 ChatBI 更進階的語義緩存實現(xiàn)或者想看更復雜的簡歷案例可以在評論區(qū)留言我來安排。 Vibe Coding × ChatBI：AI產(chǎn)品經(jīng)理從原型到簡歷的完整作品集實戰(zhàn)
聊聊最近被不少 AI 產(chǎn)品經(jīng)理同行問爆的一個組合Vibe Coding ChatBI。圈子里好像一夜之間都在聊“用嘴寫代碼”“讓 AI 自己搭數(shù)據(jù)分析系統(tǒng)”。很多朋友想把這套東西做成作品集寫進簡歷但又不知道從哪兒開始下手更不知道簡歷上到底該怎么寫才不虛。先說結(jié)論Vibe Coding 不是歪門邪道也不是“偷懶不寫代碼”它是 AI 時代產(chǎn)品經(jīng)理快速驗證想法的一種新的工作方式。而 ChatBI對話式數(shù)據(jù)智能是目前最適合拿來當作品集落地場景的 AI 應用之一——需求清晰、價值明顯、技術鏈路完整面試官一看就懂問起來也有話聊。這篇文章我會從一個 AI 產(chǎn)品經(jīng)理的實際視角出發(fā)拆解三件事Vibe Coding 到底是什么、怎么用它把一個 ChatBI 從想法變成能跑的原型以及最后怎么把這個作品集專業(yè)地寫進簡歷里。全程給可復用的提示詞、代碼思路和簡歷模板不是那種只講概念的空文章。1. 背景與核心概念1.1 為什么 AI 產(chǎn)品經(jīng)理需要“作品集”傳統(tǒng)產(chǎn)品經(jīng)理找工作靠的是 PRD、原型圖、數(shù)據(jù)報告和講項目故事的能力。但 AI 產(chǎn)品經(jīng)理面臨的情況不太一樣面試官尤其是一線技術負責人很難通過文檔判斷你是否真的理解 AI 能力邊界。你說你設計過一個智能客服問你 Prompt 怎么調(diào)優(yōu)、模型幻覺怎么處理、召回率怎么測答不上來就露餡了。作品集的核心作用是證明“我不光會畫圖寫文檔我真的動手把一個 AI 應用從概念推到了可用狀態(tài)”。而 AI 產(chǎn)品經(jīng)理的作品集和程序員的作品集有一個本質(zhì)區(qū)別重點不是代碼寫得多漂亮而是你如何定義問題、拆解功能、評估效果、迭代優(yōu)化。所以作品集不要求你有高級工程師的編碼水平但要求你能用最低成本把想法落地成可體驗、可演示、可分析的產(chǎn)品。1.2 Vibe Coding 是什么解決什么問題Vibe Coding 這個詞最早流行起來源于大家發(fā)現(xiàn)用自然語言給 AI 編程助手比如 Cursor、Claude、GPT 的 Artifacts、DeepSeek、通義靈碼等下達指令已經(jīng)能完成相當一部分實際開發(fā)工作。它不強調(diào)手寫每一行代碼而是強調(diào)用清晰的意圖描述驅(qū)動 AI 生成代碼自己負責判斷、組合、調(diào)試和驗證。對 AI 產(chǎn)品經(jīng)理來說Vibe Coding 的意義不是替代工程師而是快速做原型把想法直接跟 AI 說幾分鐘拿到一個可點擊、可交互、可演示的頁面。驗證技術可行性不確定某個功能能不能做直接讓 AI 寫一版試試比爭論半天都有效。降低溝通成本你手上有個能跑的 Demo和技術團隊溝通需求時大家對著真實系統(tǒng)討論而不是對著文字想象。補齊產(chǎn)品 Sense 到技術理解之間的空檔通過親手調(diào)試 Prompt、修改參數(shù)、觀察錯誤日志你能真正理解模型的能力邊界。有人可能會擔心這是不是在鼓勵產(chǎn)品經(jīng)理搶工程師的活我個人的觀點是Vibe Coding 產(chǎn)出的是“原型”“樣板”和“作品集”不是高并發(fā)高可用的商業(yè)系統(tǒng)。你的目標是用它來驗證和表達而不是用它替代專業(yè)研發(fā)流程。1.3 ChatBI 是什么為什么適合做成作品集ChatBI 是 Chat Business Intelligence 的縮寫指通過自然語言對話的方式來查詢、分析和理解業(yè)務數(shù)據(jù)。你可以把它理解成一個“能聊天”的數(shù)據(jù)分析助手。傳統(tǒng) BI 工具要求用戶會拖拽報表、懂維度指標、能自己寫 SQLChatBI 做的事情是讓用戶直接問“上個月華東區(qū)域的銷售額環(huán)比增長了多少哪個品類貢獻最大”系統(tǒng)自動理解問題生成查詢邏輯返回結(jié)果甚至自動生成圖表。ChatBI 作為 AI 產(chǎn)品經(jīng)理的作品集有幾個天然優(yōu)勢需求場景普及幾乎每個公司都有數(shù)據(jù)分析需求面試官完全能理解這個產(chǎn)品解決什么問題。技術鏈路完整涉及 NL2SQL、意圖識別、Prompt 工程、可視化、數(shù)據(jù)權限、效果評估這些都是 AI 產(chǎn)品經(jīng)理面試的高頻話題?？闪炕Ч媚憧梢越o出“SQL 生成準確率”“查詢響應時間”“端到端任務完成率”等指標這些都是作品集里的硬通貨。能獨立完成借助 Vibe Coding一個人就能搭出可演示的版本不需要依賴后端團隊、數(shù)據(jù)團隊和測試資源。1.4 容易混淆的概念澄清很多初學者會把幾個相關概念搞混概念核心能力與 ChatBI 的區(qū)別傳統(tǒng) BITableau、Power BI可視化報表、拖拽分析需要用戶手動配置圖表和指標學習成本高Chatbot智能客服對話問答、任務辦理偏向服務交互不一定涉及數(shù)據(jù)庫查詢ChatBI自然語言 → 數(shù)據(jù)查詢 → 分析與展示強調(diào)“對話即分析”核心是理解和查詢數(shù)據(jù)Copilot編程助手在 IDE 里輔助寫代碼面向研發(fā)場景不是面向業(yè)務分析場景搞清楚這些邊界寫簡歷時才能精確表達自己作品集的定位。2. 環(huán)境準備與工具選型做作品集不需要企業(yè)級技術架構(gòu)我們的原則是夠用、開源、免費、演示順暢。2.1 我選擇的工具鏈下面是我個人的方案你可以根據(jù)手頭資源調(diào)整用途工具選擇選型理由Vibe Coding 主環(huán)境Cursor 或 Claude / DeepSeek 對話窗口Cursor 適合邊聊邊改代碼對話式工具適合快速生成完整腳本編程語言Python 3.10AI 生成代碼最容易穩(wěn)定運行的語言生態(tài)完善前后端框架Streamlit純 Python 寫 Web 應用幾百行代碼就能做出像樣的界面數(shù)據(jù)庫SQLite無需安裝數(shù)據(jù)庫服務單文件存儲作品集演示零成本向量數(shù)據(jù)庫ChromaDB用于存放樣例問題和 SQL 模板提升 NL2SQL 準確率LLM APIOpenAI GPT-4o / DeepSeek / Qwen任選其一即可取決于你的預算和可用性依賴管理requirements.txt pip保持環(huán)境簡單方便他人復現(xiàn)2.2 需要確認的版本說明我必須先聲明大模型相關 API 和工具版本變化非常快下面給出的版本號只是說明我在寫這篇文章時的常見選擇。你實際使用時請以官方最新文檔為準不要照搬。# 建議使用 Python 3.10 或 3.11 python --version # 安裝核心依賴注意版本可能隨時間更新 pip install streamlit pip install openai pip install langchain pip install chromadb pip install pandas pip install sqlite3 # 一般內(nèi)置無需單獨安裝如果你所在的網(wǎng)絡環(huán)境不方便直接訪問部分外部服務可以選擇國內(nèi)可用的模型服務商或者通過代理方式訪問這里不展開。2.3 示例項目結(jié)構(gòu)我在做這個作品集時項目目錄如下chatbi-mvp/ ├── app.py # Streamlit 入口頁面 ├── nl2sql.py # 核心模塊自然語言轉(zhuǎn) SQL ├── database/ │ ├── init_db.py # 初始化數(shù)據(jù)庫和樣例數(shù)據(jù) │ └── sales.db # SQLite 數(shù)據(jù)庫文件 ├── prompts/ │ └── sql_prompt.py # Prompt 模板 ├── examples/ │ └── few_shot_examples.py # 少樣本示例用于提升準確率 ├── requirements.txt └── README.md這個結(jié)構(gòu)夠清晰面試官一眼能看出你對項目有工程化思維而不是把代碼堆在一個文件里。3. Vibe Coding 實操方法論從想法到原型這一節(jié)是整篇文章最關鍵的部分。我不會直接給你一堆代碼而是先講 Vibe Coding 的操作方法。因為只有掌握了這套方法你以后才能快速做出不同主題的作品集。3.1 第一輪用自然語言讓 AI 生成腳手架我第一次做 ChatBI 原型時沒有先寫架構(gòu)文檔而是直接打開 Cursor輸入了這樣一段 Prompt你是一名 Python 開發(fā)工程師請幫我搭建一個 ChatBI MVP 項目的骨架。 要求如下 1. 使用 Streamlit 作為 Web 界面框架 2. 用戶輸入中文問題系統(tǒng)返回 SQL 查詢語句、執(zhí)行結(jié)果和圖表 3. 數(shù)據(jù)庫使用 SQLite提前生成一個銷售訂單表包含 100 條左右的測試數(shù)據(jù)字段包括 - order_id - order_date - region - product_category - sales_amount - quantity 4. 先別寫完整功能只生成項目目錄結(jié)構(gòu)和每個文件的占位代碼。 請直接輸出每個文件的完整代碼。這段 Prompt 的關鍵信息非常明確技術棧、數(shù)據(jù)表結(jié)構(gòu)、輸出格式要求。AI 生成的代碼一開始當然不完美但不重要。第一輪的目標是拿到一個能跑起來的骨架。3.2 第二輪逐模塊迭代而不是一次到位拿到骨架后不要急著讓 AI 一次性把所有功能全部補齊那樣很容易生成一大堆互相不兼容的代碼。我的建議是把完整需求拆成下面幾個模塊分別對話解決模塊一數(shù)據(jù)初始化讓 SQLite 有數(shù)據(jù)可查模塊二LLM 調(diào)用封裝讓程序可以請求大模型接口模塊三NL2SQL 核心邏輯自然語言轉(zhuǎn)成 SQL 語句模塊四結(jié)果解析與可視化把查詢結(jié)果渲染成圖表模塊五異常處理SQL 生成錯誤時給出兜底方案每次對 AI 只提一個小需求。比如請給 nl2sql.py 寫一個函數(shù)輸入是用戶問題中文輸出是一條 SQL 查詢語句。 要求 1. 先獲取數(shù)據(jù)表的 schema也就是表名、字段名、字段類型和主鍵信息 2. 把 schema 和 few-shot 示例一起放進 Prompt 3. 解析 LLM 返回的 SQL去掉 markdown 格式代碼塊標記 4. 如果生成失敗返回空字符串。這樣做的優(yōu)勢是每個模塊的代碼都短小、邏輯清晰即使出現(xiàn) Bug 也容易定位。這就是 Vibe Coding 和傳統(tǒng)開發(fā)的典型差異——我們通過“對話 小步迭代”替代了“一次性編碼”。3.3 第三輪運行、報錯、反饋、優(yōu)化Vibe Coding 的本質(zhì)不只是讓 AI 寫代碼還包括讓 AI 幫你改代碼。運行報錯時直接把錯誤信息復制回對話窗口運行 app.py 時出現(xiàn)以下報錯請分析原因并給出修復后的代碼。 Streamlit run app.py 報錯信息 sqlite3.OperationalError: table sales_orders has no column named order_dateAI 能根據(jù)報錯信息迅速定位問題通常是因為我們初始化數(shù)據(jù)庫時字段名不一致。它會把相關代碼段重新生成一遍你復制覆蓋即可。這個“運行-報錯-反饋-修復”的循環(huán)就是 Vibe Coding 的核心工作流。你要習慣把自己當成項目經(jīng)理和測試人員而不是“打字員”。3.4 關于“避免幻覺功能”的提醒使用 Vibe Coding 時最大的風險是讓 AI 生成了它“以為自己能做”但實際運行不了的功能。比如讓它接入一些并不存在的第三方 API或者編造不存在的 Python 庫。我的規(guī)避方法有兩條在 Prompt 里明確要求使用主流、成熟、真實存在的庫拿到 AI 給的代碼后先看它 import 了哪些庫逐個確認這些庫是否真實存在、是否能正常安裝。如果 AI 給出的某個庫你從來沒聽說過不要直接相信先去 PyPI 或 GitHub 搜一下再決定。這是 AI 產(chǎn)品經(jīng)理應該養(yǎng)成的技術敬畏心。4. 實戰(zhàn)用 Vibe Coding 從零構(gòu)建 ChatBI 最小可行版本下面進入完整實戰(zhàn)環(huán)節(jié)。我盡量把每一步寫清楚讓你可以照著做出來。4.1 初始化數(shù)據(jù)庫與樣例數(shù)據(jù)首先準備好數(shù)據(jù)。在項目根目錄創(chuàng)建database/init_db.py。# 文件路徑database/init_db.py import sqlite3 import random from datetime import datetime, timedelta def create_database(db_pathdatabase/sales.db): conn sqlite3.connect(db_path) cursor conn.cursor() # 創(chuàng)建銷售訂單表 cursor.execute( CREATE TABLE IF NOT EXISTS sales_orders ( order_id INTEGER PRIMARY KEY AUTOINCREMENT, order_date TEXT NOT NULL, region TEXT NOT NULL, product_category TEXT NOT NULL, sales_amount REAL NOT NULL, quantity INTEGER NOT NULL ) ) # 生成測試數(shù)據(jù) regions [華東, 華南, 華北, 西南] categories [數(shù)碼產(chǎn)品, 家用電器, 服飾鞋包, 食品飲料] start_date datetime(2024, 1, 1) random.seed(42) # 固定隨機種子保證數(shù)據(jù)可復現(xiàn) for i in range(200): order_date start_date timedelta(daysrandom.randint(0, 365)) region random.choice(regions) category random.choice(categories) amount round(random.uniform(50, 2000), 2) quantity random.randint(1, 10) cursor.execute( INSERT INTO sales_orders (order_date, region, product_category, sales_amount, quantity) VALUES (?, ?, ?, ?, ?), (order_date.strftime(%Y-%m-%d), region, category, amount, quantity) ) conn.commit() conn.close() print(數(shù)據(jù)庫初始化完成共插入 200 條銷售訂單。) if __name__ __main__: create_database()運行初始化腳本python database/init_db.py預期輸出數(shù)據(jù)庫初始化完成共插入 200 條銷售訂單。這個腳本有三個教學點值得你在簡歷里提到字段設計、隨機種子保證數(shù)據(jù)可復現(xiàn)、SQLite 輕量化的選型理由。4.2 編寫 Prompt 模板與少樣本示例NL2SQL 的核心是 Prompt 設計。我們要讓模型知道有哪些表、哪些字段、用戶的問題是什么意思、應該生成什么 SQL。先創(chuàng)建prompts/sql_prompt.py# 文件路徑prompts/sql_prompt.py def build_sql_prompt(schema_text: str, examples_text: str, user_question: str) - str: prompt f 你是一個數(shù)據(jù)分析師負責把用戶的中文問題轉(zhuǎn)換成 SQL 查詢語句。 請嚴格遵循以下規(guī)則 1. 只能根據(jù)給定的表結(jié)構(gòu)生成 SQL不能臆造不存在的字段 2. 只輸出 SQL 語句本身不要輸出解釋、不要使用 Markdown 代碼塊標記 3. 查詢結(jié)果必須是聚合后的匯總數(shù)據(jù)不允許返回明細行 4. 如果用戶問題中指定了時間范圍要使用 WHERE 條件進行過濾 5. 金額相關字段需要輸出保留兩位小數(shù) 6. 如果問題無法用給定表結(jié)構(gòu)回答請輸出: ERROR: 無法生成查詢 數(shù)據(jù)庫表結(jié)構(gòu)如下 {schema_text} 參考示例 {examples_text} 用戶問題{user_question} SQL: return prompt再創(chuàng)建examples/few_shot_examples.py這里放了幾個典型問題用來引導模型生成風格統(tǒng)一的 SQL# 文件路徑examples/few_shot_examples.py FEW_SHOT_EXAMPLES [ { question: 上個月華東區(qū)域的銷售額是多少, sql: SELECT region, ROUND(SUM(sales_amount), 2) AS total_sales FROM sales_orders WHERE region 華東 AND order_date BETWEEN 2024-11-01 AND 2024-11-30 GROUP BY region }, { question: 哪個產(chǎn)品類別累計銷售額最高, sql: SELECT product_category, ROUND(SUM(sales_amount), 2) AS total_sales FROM sales_orders GROUP BY product_category ORDER BY total_sales DESC LIMIT 1 }, { question: 西南區(qū)域今年第一季度各個月份的訂單數(shù)量趨勢如何, sql: SELECT strftime(%Y-%m, order_date) AS month, COUNT(*) AS order_cnt FROM sales_orders WHERE region 西南 AND order_date BETWEEN 2024-01-01 AND 2024-03-31 GROUP BY month ORDER BY month }, { question: 華南區(qū)域銷量最高的商品類別是哪一類, sql: SELECT product_category, SUM(quantity) AS total_quantity FROM sales_orders WHERE region 華南 GROUP BY product_category ORDER BY total_quantity DESC LIMIT 1 }, { question: 最近一個月平均每筆訂單的金額是多少, sql: SELECT ROUND(AVG(sales_amount), 2) AS avg_order_amount FROM sales_orders WHERE order_date 2024-11-30 - INTERVAL 30 DAY }, ]需要說明的是最后一個示例里的INTERVAL語法在 SQLite 中不一定直接生效實際使用時應統(tǒng)一用字符串日期比較。這里保留原樣是想提醒你AI 生成的 SQL 并不總是和數(shù)據(jù)庫方言匹配審查 SQL 是產(chǎn)品經(jīng)理必須具備的能力。因此我們在運行時會對生成的 SQL 做兩層校驗下面會講到。4.3 編寫獲取 Schema 的工具函數(shù)要讓模型寫出正確 SQL必須把數(shù)據(jù)庫結(jié)構(gòu)告訴它。寫一個工具函數(shù)用 SQLite 的系統(tǒng)表查詢字段信息# 文件路徑nl2sql.py部分代碼 import sqlite3 def get_schema(db_path: str database/sales.db) - str: conn sqlite3.connect(db_path) cursor conn.cursor() cursor.execute(SELECT name FROM sqlite_master WHERE typetable) tables [row[0] for row in cursor.fetchall()] schema_parts [] for table in tables: cursor.execute(fPRAGMA table_info({table})) columns cursor.fetchall() col_desc , .join([f{col[1]} {col[2]} for col in columns]) schema_parts.append(f表名: {table}, 字段: {col_desc}) conn.close() return \n.join(schema_parts)這里用PRAGMA table_info獲取字段名和類型信息足夠簡潔適合放進 Prompt。需要說明的是這里的fPRAGMA table_info({table})屬于內(nèi)部信任場景因為表名來自系統(tǒng)表不是直接拼接用戶輸入因此在演示場景下風險可控。如果對接真實業(yè)務庫不能直接這樣寫應該使用參數(shù)化查詢方式獲取元數(shù)據(jù)。4.4 編寫 NC2SQL 主流程下面來寫nl2sql.py的完整核心邏輯。它負責四件事獲取 Schema、調(diào)用模型生成 SQL、校驗 SQL、執(zhí)行 SQL。# 文件路徑nl2sql.py import re import sqlite3 from openai import OpenAI from prompts.sql_prompt import build_sql_prompt from examples.few_shot_examples import FEW_SHOT_EXAMPLES client OpenAI(api_keyyour-api-key, base_urlyour-base-url) # 取決于你的模型服務商 def get_schema(db_path: str database/sales.db) - str: # 省略同上文 get_schema 函數(shù) def extract_sql(text: str) - str: 從模型輸出中提取純 SQL去掉可能的 markdown 標記 # 去掉代碼塊標記 text re.sub(rsql|, , text).strip() return text def validate_sql(sql: str) - bool: 簡單校驗 SQL 是否包含風險或異常語法 blacklist [INSERT, UPDATE, DELETE, DROP, ALTER, CREATE] for word in blacklist: if re.search(r\b word r\b, sql.upper()): return False return True def execute_sql(sql: str, db_path: str database/sales.db): conn sqlite3.connect(db_path) try: cursor conn.cursor() cursor.execute(sql) columns [desc[0] for desc in cursor.description] if cursor.description else [] rows cursor.fetchall() return columns, rows except Exception as e: return None, f執(zhí)行錯誤: {e} finally: conn.close() def nl2sql(user_question: str) - dict: schema get_schema() examples_text for item in FEW_SHOT_EXAMPLES: examples_text f問題: {item[question]}\nSQL: {item[sql]}\n\n prompt build_sql_prompt(schema, examples_text, user_question) response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: prompt}], temperature0.1, ) raw_sql response.choices[0].message.content sql extract_sql(raw_sql) # 判斷是否生成失敗 if sql.startswith(ERROR) or sql : return {error: 無法理解該問題請嘗試換個說法。} # 判斷是否包含非法 SQL if not validate_sql(sql): return {error: 生成的 SQL 存在安全風險已阻止執(zhí)行。} # 執(zhí)行 SQL columns, rows execute_sql(sql) if columns is None: return {error: rows} return {columns: columns, rows: rows, sql: sql}關鍵步驟說明temperature0.1讓模型輸出更穩(wěn)定減少隨意生成。extract_sql是為了兼容不同模型輸出格式有的模型喜歡帶 markdown 代碼塊。validate_sql是安全兜底避免模型生成非查詢語句。這很重要正式做 ChatBI 時不能直接執(zhí)行模型生成的 SQL。execute_sql捕獲執(zhí)行異常保證至少不會讓整個 Web 應用崩潰。4.5 編寫圖表可視化邏輯為了讓作品集看起來更完整我們在拿到查詢結(jié)果后嘗試根據(jù)字段特征自動判斷是否適合畫圖。# 文件路徑app.py部分代碼 import pandas as pd import streamlit as st from nl2sql import nl2sql import matplotlib.pyplot as plt plt.rcParams[font.sans-serif] [SimHei, Arial Unicode MS, PingFang SC] plt.rcParams[axes.unicode_minus] False def auto_visualize(columns, rows): 根據(jù)返回的字段做簡單的可視化判斷。 如果只有一個維度字段和一個數(shù)值字段輸出柱狀圖或折線圖。 df pd.DataFrame(rows, columnscolumns) if len(df.columns) 2: first_col df.columns[0] second_col df.columns[1] if pd.api.types.is_numeric_dtype(df[second_col]): fig, ax plt.subplots(figsize(10, 5)) ax.bar(df[first_col].astype(str), df[second_col]) ax.set_xlabel(first_col) ax.set_ylabel(second_col) ax.set_title(f{first_col} vs {second_col}) plt.xticks(rotation45, haright) st.pyplot(fig)這一步不用太復雜關鍵是讓面試官和用戶直觀感受到“系統(tǒng)不僅能問答還能自動給出圖表”。4.6 編寫 Streamlit 界面最后是 Web 界面層。我們希望用戶輸入一個問題點擊按鈕看到三個東西生成的 SQL、查詢結(jié)果表格、對應圖表。# 文件路徑app.py import streamlit as st import pandas as pd from nl2sql import nl2sql def auto_visualize(columns, rows): # 省略同上文 def main(): st.set_page_config(page_titleChatBI 數(shù)據(jù)問答助手, layoutwide) st.title( ChatBI 數(shù)據(jù)問答助手) st.caption(輸入你的業(yè)務問題系統(tǒng)將自動完成 SQL 生成、執(zhí)行與可視化展示。) user_question st.text_input(請輸入你的問題, placeholder比如華東區(qū)域銷售額最高的商品類別是什么) if st.button(開始分析, typeprimary): if not user_question.strip(): st.warning(請先輸入問題。) return with st.spinner(正在理解和生成查詢...): result nl2sql(user_question) if error in result: st.error(result[error]) return st.subheader(生成的 SQL) st.code(result[sql], languagesql) st.subheader(查詢結(jié)果) columns result[columns] rows result[rows] df pd.DataFrame(rows, columnscolumns) st.dataframe(df, use_container_widthTrue) st.subheader(可視化分析) auto_visualize(columns, rows) if __name__ __main__: main()運行方式streamlit run app.py瀏覽器會自動打開http://localhost:8501。輸入中文問題就能看到完整的問答分析過程。4.7 運行效果預期當你輸入“華東區(qū)域銷售額最高的商品類別是什么”時預期輸出大致是生成的 SQLSELECT product_category, ROUND(SUM(sales_amount), 2) AS total_sales FROM sales_orders WHERE region 華東 GROUP BY product_category ORDER BY total_sales DESC LIMIT 1數(shù)據(jù)表格一列是商品類別一列是累計銷售額按降序排列?？梢暬瘓D表因為第一列是字符串、第二列是數(shù)值系統(tǒng)自動繪制柱狀圖。雖然這個 MVP 還不夠智能但它已經(jīng)是一個完整的 ChatBI 閉環(huán)足夠放進作品集里講清楚產(chǎn)品邏輯。5. 進階提升讓 ChatBI 更接近真實產(chǎn)品只跑通一個簡單 Demo 是不夠的AI 產(chǎn)品經(jīng)理的作品集一定要體現(xiàn)“思考深度”。下面這幾個方向你可以選 1 到 2 個在作品集里展示。5.1 加入語義緩存機制在很多 ChatBI 場景中用戶會反復問類似的問題。如果每次都調(diào)用大模型生成 SQL成本高、響應慢。一個簡單有效的優(yōu)化是引入語義緩存。思路先把用戶問題轉(zhuǎn)成 embedding 向量然后在 ChromaDB 里查找最相似的歷史問題。如果相似度超過一個閾值比如 0.85直接返回歷史 SQL 和結(jié)果。# 思路示例語義緩存 from chromadb import Client # 1. 初始化 Chroma 集合 # 2. 將每個歷史問題寫入 collection同時存儲 SQL 和結(jié)果 # 3. 用戶提問時先用 embedding 搜索相似記錄 # 4. 相似度高直接返回否則走 NL2SQL 主鏈路這個機制進簡歷非常加分因為它體現(xiàn)你考慮了成本、性能和產(chǎn)品體驗的平衡。5.2 加入多輪對話能力上面的 MVP 只支持單輪對話。真實產(chǎn)品中用戶會追問“那華北呢”“占比是多少”這些問題依賴上下文。優(yōu)化思路有兩種簡單法把歷史對話記錄拼進 Prompt讓模型自己理解當前問題是否依賴上文。結(jié)構(gòu)法在對話歷史中抽取實體和條件區(qū)域、時間、品類填充一個“查詢條件槽位”。作為作品集建議先實現(xiàn)簡單法后說明結(jié)構(gòu)法的演進方向。5.3 加入數(shù)據(jù)權限控制真實 ChatBI 最重要的工程問題之一是數(shù)據(jù)權限。不是所有用戶都有權限查看所有區(qū)域的數(shù)據(jù)。你可以在作品集里加上一個簡單的角色權限模型# 思路示例權限控制 # 1. 定義用戶角色比如 admin、analyst、visitor # 2. 根據(jù)角色生成不同的 SQL 過濾條件 # 3. 例如 visitor 只在 WHERE 條件中強制追加 user_region 華東 # 4. 在原型中通過側(cè)邊欄切換角色演示不同身份看到的數(shù)據(jù)范圍不同這個功能不用寫得很復雜但一定要在 README 和簡歷里說明因為這直接展示了你作為 AI 產(chǎn)品經(jīng)理對“安全邊界”的理解。6. 如何把 ChatBI 作品集寫進簡歷作品集做出來了最關鍵的一步來了怎么在簡歷里展示它。6.1 簡歷項目描述通用框架我建議參考 STAR 法則但寫簡歷時不需要嚴格寫成四段。核心是讓面試官在 30 秒內(nèi)看懂三個信息背景、動作、結(jié)果。信息項內(nèi)容建議項目背景一句話說明為什么做這個 ChatBI時間跨度寫清楚周期最好在 2-4 周內(nèi)你的角色獨立完成或作為 AI 產(chǎn)品經(jīng)理主導核心動作Vibe Coding、Prompt 工程、NL2SQL、可視化、安全機制量化結(jié)果SQL 生成準確率、響應時間、功能覆蓋率技術棧Python、Streamlit、SQLite、LLM API6.2 簡歷項目描述示例下面給一個可以直接參考的寫法注意替換為你的實際數(shù)據(jù)和指標ChatBI 對話式數(shù)據(jù)分析助手獨立開發(fā) / 2025.03 - 2025.04 項目背景 企業(yè)內(nèi)部運營人員日常取數(shù)依賴數(shù)據(jù)團隊大量常見問題通過即時通訊工具紙質(zhì)傳遞查詢效率低、口徑不一致。 項目動作 - 基于 Vibe Coding 方法論使用 Python Streamlit 完成 ChatBI MVP 從需求拆解到可運行原型 - 設計 NL2SQL 核心鏈路通過 LLM 將中文問題轉(zhuǎn)換為 SQL結(jié)合 sqlite schema 注入、few-shot 示例增強生成準確率 - 設計結(jié)果可視化模塊根據(jù)字段類型自動選擇柱狀圖、折線圖或明細表展示 - 加入語義緩存、多輪對話擴展方案降低接口調(diào)用成本 - 設計用戶角色與數(shù)據(jù)權限控制邏輯確保不同角色只能查看授權范圍內(nèi)的數(shù)據(jù)。 量化結(jié)果 - 在 200 條銷售訂單數(shù)據(jù)上常見業(yè)務問題的 SQL 生成準確率達到約 92% - 將語義緩存命中后的查詢響應從平均 8 秒降低至 1 秒以內(nèi) - MVP 從需求確定到可演示版本交付耗時 2 周全程獨立完成 - 沉淀了一套可復用的 NL2SQL 提示詞模板和 SQL 安全校驗規(guī)則。 技術棧Python、Streamlit、SQLite、ChromaDB、OpenAI API / DeepSeek API需要提醒的是準確率 92% 這種數(shù)字不能拍腦袋亂寫。我的建議是自己在測試集上跑一遍記錄真實結(jié)果后填進去。哪怕準確率只有 75%只要說明測試條件和改進路徑也比虛標數(shù)字更有說服力。6.3 面試時如何講解這個作品集面試官通常會從三個角度追問技術理解類NL2SQL 的難點是什么幻覺問題怎么處理產(chǎn)品判斷類為什么選 ChatBI 這個場景目標用戶是誰工程落地類模型返回錯誤 SQL 怎么辦如何防止用戶越權查數(shù)建議在本地留一個可運行的 Demo 包面試時直接打開 Streamlit 現(xiàn)場演示。這比任何口頭描述都有說服力。你需要準備好一段 3 分鐘的演示腳本講清楚“用戶輸入問題 → 生成 SQL → 執(zhí)行 → 可視化”的完整流程。7. 常見問題與排查思路7.1 常見問題匯總問題現(xiàn)象常見原因解決思路輸入問題后長時間無響應LLM API 響應慢或網(wǎng)絡不穩(wěn)定檢查 API 服務狀態(tài)設置超時時間落地語義緩存模型生成的 SQL 執(zhí)行報錯字段名與 schema 不一致在 Prompt 中強調(diào)只使用給定字段查看報錯信息反饋給 AI 修復SQL 能執(zhí)行但結(jié)果明顯不對缺少 WHERE 條件或聚合方式錯誤補充 few-shot 示例降低 temperature中文圖表亂碼matplotlib 缺少中文字體設置字體為 SimHei 或 PingFang SCStreamlit 頁面打不開端口被占用或依賴未裝齊檢查streamlit run app.py的啟動日志嘗試換端口數(shù)據(jù)庫大量重復數(shù)據(jù)重復運行 init_db.py在腳本里增加刪除舊表或判斷是否已存在的邏輯7.2 排查優(yōu)先級清單如果系統(tǒng)跑不通不要慌按下面的順序排查數(shù)據(jù)庫是否有數(shù)據(jù)打開database/sales.db確認sales_orders表非空API 是否可用在 Python 里單獨測試一次client.chat.completions.create看能否返回內(nèi)容Prompt 是否正確拼接打印出build_sql_prompt的完整輸出檢查 schema 和 examples 是否有語法問題SQL 校驗是否過嚴確認沒有誤殺合法的 SELECT 語句頁面渲染是否出錯查看 Streamlit 終端的完整 traceback定位到具體行號。8. 最佳實踐與工程建議8.1 Vibe Coding 過程的工程素養(yǎng)Vibe Coding 不等于“沒有工程素養(yǎng)”。恰恰相反AI 產(chǎn)品經(jīng)理更應該具備工程思維否則很容易被 AI 生成的一堆花哨代碼帶偏。幾點建議版本控制必須有哪怕是小項目也建議用 Git 管理否則改壞了無法回退。每個版本“能跑即提交”不要等技術債積累太多才想起保存。記錄 Prompt 迭代過程你每次怎么修改 Prompt 才讓模型輸出變好這是 AI 產(chǎn)品經(jīng)理作品集里的隱形資產(chǎn)。保持項目結(jié)構(gòu)整潔即使代碼是 AI 寫的也要堅持模塊化拆分不要一個文件寫 800 行。8.2 安全邊界這是 ChatBI 類作品最重要的部分絕不能讓模型生成的 SQL 直接在生產(chǎn)庫上執(zhí)行必須加白名單機制、SQL 校驗和資源限制明確定義安全邊界作品集演示可以用 SQLite但簡歷里一定要寫清楚“正式方案中需要接入查詢網(wǎng)關、數(shù)據(jù)脫敏、行級權限”提示詞注入風險不要在業(yè)務數(shù)據(jù)中直接拼接用戶輸入到 Prompt 之外的部分涉及真實數(shù)據(jù)時必須經(jīng)過授權和脫敏處理。8.3 效果評估方法ChatBI 不是“能跑就行”。一個合格的數(shù)據(jù)分析助手必須有一套評估維度評估維度說明評估方式查詢生成準確率生成的 SQL 是否與預期結(jié)果一致構(gòu)建測試集人工標注端到端成功率用戶提問后是否成功返回結(jié)果日志統(tǒng)計響應時間從提問到結(jié)果展示的總耗時日志統(tǒng)計用戶滿意率用戶對回答是否滿意問卷或反饋按鈕兜底率無法回答時是否有友好提示日志統(tǒng)計建議在作品集 README 里寫清楚評估方式和測試結(jié)果這比“Demo 做得很炫”更有專業(yè)深度。9. 總結(jié)與下一步行動路線9.1 你已經(jīng)掌握了什么通過這篇文章你已經(jīng)了解到Vibe Coding 的核心工作流自然語言 → 生成代碼 → 運行報錯 → 反饋修復 → 迭代優(yōu)化從零構(gòu)建 ChatBI MVP 的完整鏈路數(shù)據(jù)準備、Prompt 設計、NL2SQL、業(yè)務校驗、可視化展示ChatBI 產(chǎn)品在真實落地時需要關注的進階能力語義緩存、多輪對話、數(shù)據(jù)權限控制如何把一個作品集項目專業(yè)地寫進簡歷并準備好面試講解路徑。9.2 下一步推薦做什么我一直強調(diào)AI 產(chǎn)品經(jīng)理最重要的不是堆代碼量而是形成“定義問題 - 快速驗證 - 量化評估 - 持續(xù)迭代”的閉環(huán)?；谶@個思路建議你接下來做以下增強把自己測試的真實業(yè)務數(shù)據(jù)替換掉樣例數(shù)據(jù)讓作品集更有業(yè)務說服力嘗試接入一個國內(nèi)可用的模型服務比如 DeepSeek驗證不同模型在 NL2SQL 場景下的表現(xiàn)差異增加 10 條真實測試用例記錄準確率變化形成一份簡短的效果評估報告把整個項目放進 GitHub順便把 README 寫完整讓別人可以復現(xiàn)。當你完成上面這些動作之后這個作品集就不只是一個“AI 生成的 Demo”而是一個能證明你具備 AI 產(chǎn)品經(jīng)理核心能力的完整項目。9.3 作品集的長期意義最后說一點真心話。Vibe Coding 必然會繼續(xù)進化模型能力也會越來越強也許未來會出現(xiàn)更輕量的方式直接構(gòu)建數(shù)據(jù)問答系統(tǒng)。但無論工具怎么變作為 AI 產(chǎn)品經(jīng)理真正稀缺的能力始終是判斷什么場景值得做知道怎么把模糊想法拆成可落地的功能邊界能評估模型和產(chǎn)品的效果差距在哪里能推動一個 AI 功能從“能跑”走向“好用”。ChatBI 只是切入點。通過這個作品集你證明的不是“我會用 AI 寫代碼”而是“我能用 AI 把一個產(chǎn)品想法變成可體驗、可評估、可演進的原型”。接下來就動手打開 Cursor 或任意一個 AI 編程工具把上面第 4 節(jié)的代碼結(jié)構(gòu)跑通。遇到問題也不用怕報錯信息直接貼給 AI改就完了。Vibe Coding 的樂趣恰恰就在這個“邊聊邊改、不斷逼近可用狀態(tài)”的過程里。如果這篇文章對你有幫助可以收藏備用。要是你想了解 ChatBI 更進階的語義緩存實現(xiàn)或者想看更復雜的簡歷案例可以在評論區(qū)留言我來安排。