name: data-analysis-dashboard description: 傳入 CSV/Excel/JSON 資料,自動體檢、評估優劣勢,並從 7 種中文模板中生成 HTML 看板。所有分析與數字嚴格基於真實資料,禁止編造。 agent_created: true

Data Analysis Dashboard

核心紅線 (不可逾越)

所有分析結論、看板資料、文字報告必須嚴格基於使用者提供的實際資料,禁止編造、推測、填充、美化資料。

• 沒有資料支撐時,寫「資料不足,無法判斷」而非給出一個看似合理的數字。
• 圖表中的每個數字、每個標籤、每個 KPI 值必須來自真實計算結果。
• 若資料有侷限(如缺少時間維度、缺少使用者標識),明確說明侷限,不誇大結論適用範圍。
• 發現異常值時,先判斷是真實業務訊號還是髒資料,不確定時寫「疑似異常,需進一步核實」而非強行解釋。
• 看板必須離線可渲染:Chart.js 只能本地引用 ./chart.umd.min.js,絕不可回退到外網 CDN(你當前網路連不上 cdn.jsdelivr.net 等,一旦回退圖表就會全空白)。

Overview

本技能將「拿到資料 → 分析 → 出報告」固化為標準流程:先做資料質量體檢,再給出優勢與劣勢分析,最後產出可直接開啟的 HTML 資料看板,並附上文字版分析結論。

可用看板模板

模板存放在 assets/templates/ 目錄下,共 7 種風格。選擇模板時根據資料場景和展示物件決定:

重要:向用戶展示和提問時一律用中文名(如「淺色商務風」),不要用英文檔名。

選擇策略: - 展示場景偏「大屏/監控/即時」→ 選深色科技風 / 深紫科技風 - 展示場景偏「彙報/PPT/列印」→ 選淺色商務風 / 極簡報告風 - 資料型別偏「金融/交易」→ 選深藍商務風,並遵循「漲紅跌綠」 - 資料型別偏「運營/使用者」→ 選淺色清新風 - 綜合經營分析 → 選白色綜合經營風

工作流

小蔥技能7w4.net有完整的技能分類。

Step 1: 定位並讀取資料

• 確認使用者傳入的資料檔案路徑(支援 CSV / Excel / JSON)或直接貼上的資料內容。
• 用 Python 讀取並確認可讀性;若路徑缺失,向用戶索取,不要憑空假設。
• 記錄基本盤:行列數、欄位名、每列型別。
• 紅線檢查:所有後續結論的原始資料必須來自此檔案,嚴禁編造。

Step 2: 選擇看板模板(選項用中文)

• 向用戶展示可用模板列表時,一律用中文名(深色科技風 / 深藍商務風 / 深紫科技風 / 淺色商務風 / 白色綜合經營風 / 淺色清新風 / 極簡報告風),用表格列出「中文名 + 適用場景」,不要只給英文檔名。
• 使用 AskUserQuestion 讓使用者選擇,選項 label 必須用中文。最多給 4 個常用選項(如「淺色商務風(推薦)」「白色綜合經營風」「深藍商務風」「深色科技風」),其餘模板使用者在自由輸入框直接輸入中文名(如「深紫科技風」「極簡報告風」)即可。
• 可給出推薦:如「這份資料是銷售運營類,推薦淺色商務風或白色綜合經營風」。
• 若使用者未指定或未明確選擇,預設使用 light-business.html(淺色商務風)。
• 記錄使用者選擇的模板(中文名 + 對應模板檔案路徑),後續 Step 6 使用此模板生成看板。

Step 3: 執行資料體檢指令碼

• 需要客觀統計資料支撐時,執行 scripts/analyze_data.py 做快速體檢:

python scripts/analyze_data.py <資料檔案路徑> --output <輸出json路徑>

• 指令碼輸出每列的缺失值、唯一值、描述性統計、IQR 異常值,以及整體重複行。
• 將指令碼輸出轉化為自然語言結論,不要原樣羅列 JSON。
• 紅線檢查:體檢報告中的每個數字必須來自指令碼輸出,不可目測估算或編造。

Step 4: 資料質量檢查

對照 references/analysis_framework.md 的檢查清單逐項核對,重點排查:

• 缺失與空值(是否集中、是否有關聯規律)
• 重複記錄(完全重複 / 關鍵欄位重複)
• 異常值(IQR 或業務規則判斷,區分「髒資料」與「真實業務訊號」)
• 型別錯亂與格式不一致(如日期混格式、數值帶單位、文本帶前後空格)
• 量綱不統一(元/萬元、kg/噸)
• 時間連續性(缺口、亂序、時區問題)

紅線: 每個質量問題必須指明具體欄位、具體現象、資料證據(如「訂單金額列有 3 個負值: -50, -120, -30」)。不寫模糊表述如「有些異常」。

Step 5: 優勢與劣勢分析

• 優勢:從完整性、粒度、時效性、覆蓋度、規範性、一致性、欄位豐富度等維度找亮點。
• 劣勢:指出不足,並說明其對下游分析或決策的具體影響,再給可執行改進建議。
• 紅線: 每個結論都要有資料依據(引用具體列名與數值),不寫空話。不確定時寫「資料不足,無法判斷」。

Step 6: 產出 HTML 看板

• 以使用者選擇的模板檔案(Step 2 中確定)為骨架,生成 HTML 看板(圖表庫用 Chart.js,必須本地引入,禁止任何外網 CDN)。
• 圖表庫本地化(強制,防止圖表空白): 模板裡的 <script src="./chart.umd.min.js"></script> 引用的是同目錄本地檔案。生成看板時,必須把技能自帶的庫檔案複製到看板 HTML 所在的同一目錄: copy <skill目錄>/assets/vendor/chart.umd.min.js <輸出目錄>/chart.umd.min.js
• 複製後再儲存 dashboard.html,確保兩者在同一資料夾。使用者開啟看板時圖表才能渲染,不依賴任何網路。
• 嚴禁把模板裡的本地引用改回 https://cdn... 等外網地址——你當前網路連不上外網 CDN,會導致 Chart 未定義、圖表全空白。
• 看板必須包含:標題欄、KPI 概覽卡片、2–4 個核心圖表、發現與建議區。
• 將模板中的 {{佔位符}} 替換為真實資料和文字結論。
• 紅線檢查: 看板中每一個數字、每一條標籤、每一個百分比都必須來自真實資料的精確計算,嚴禁為了「好看」而調整或編造資料。圖表資料必須與文字結論完全一致。
• 金融/股票資料遵循「漲紅跌綠」配色慣例。
• 圖表選型:時間趨勢→折線圖,佔比→環形圖,分類對比→柱狀圖,分佈→直方圖。
• 數字保留合理精度,KPI 卡片標註口徑(如「近 30 天」「同比」)。
• 儲存為 <輸出目錄>/dashboard.html,並用 present_files 呈現給使用者。注意:移動或分享看板時,必須連 chart.umd.min.js 一起帶走。

Step 7: 生成後全量質檢(每次必做,不可跳過)

看板 HTML 生成後、呈現給使用者前,必須先執行自動化質檢指令碼,並對結果逐項人工複核。四項檢查缺一不可:

1. 資料計算正確性
2. 執行質檢指令碼(傳入原始資料 + 看板 HTML + 本輪的體檢報告/深度分析 JSON 作為參考): python scripts/verify_dashboard.py <原始資料檔案> <看板HTML> --ref <體檢報告.json> --ref <深度分析.json>
3. 指令碼會從原始資料重算權威數字,並與看板中出現的每個數字交叉核對(自動識別萬元/億/百分比換算)。
4. 指令碼輸出的未匹配數字必須逐個人工複核:確認是真實資料換算(如 1.89 億=189,181,440 元、11.96%=0.1196)或圖表樣式配置(如 pointRadius: 3)才可通過;凡是 KPI、圖表資料、發現建議中的數字未匹配,一律修正後重新質檢。

5. 禁止用任何「目測」「心算」「感覺對」代替核對。

6. 文字無亂碼無異常(含圖表文字)

7. 檢查指令碼輸出:mojibake 亂碼數、異常符號數、佔位符殘留數必須為 0;圖表專項檢查中,每個圖表的 labels、圖例 label 同樣不得含亂碼。
8. 人工抽查:標題、KPI 標籤、圖表標題、圖例、發現與建議區無亂碼方框、無「�」替換符、無 mojibake(如 é)、無模板佔位符 {{...}} 殘留。

9. 全部文本統一 UTF-8 編碼,中英文與數字之間排版正常。

10. 圖表正確生成 + 圖表資料真實(新增圖表專項檢查)

11. 指令碼自動檢查每張圖表:
    • 完整性: <canvas> 數量必須等於 new Chart 例項數量且 id 一一對應;每個圖表 type 合法(line/bar/pie/doughnut 等)、labels 非空、資料集 data 非空(否則圖表畫不出來)。
    • 圖表文字亂碼: 檢測每個圖表的 labels、圖例 label 是否含亂碼/異常字元。
    • 圖表資料真實性: 提取每個資料集 data 的數字,與權威數字集交叉核對,確保圖表畫出來的數字來自真實計算、與文字結論一致。
12. 指令碼輸出 canvas 數量 / Chart 例項 / 完整性 / 每圖 type·labels·資料點 / 圖表文字亂碼 / 圖表資料匹配數,逐項確認。

13. 任一圖表缺失、型別非法、資料為空、文字亂碼、或圖表資料與權威數字對不上 → 視為硬錯誤,修正後重跑質檢。

14. 建議與發現準確無誤

15. 逐條核對「發現與建議」:每條結論必須能引用具體欄位與真實數字作為證據,數字與看板圖表一致。
16. 無資料證據的表述一律刪除或改寫為「資料不足,無法判斷」。
17. 嚴禁為了湊條數、湊 Top3 而編造或誇大結論。

質檢結論處理: - 指令碼硬錯誤(亂碼/異常符號/佔位符殘留/圖表未正確生成/圖表文字亂碼)> 0 → 修正看板 → 重跑質檢,直到為 0。 - 未匹配數字(含圖表資料):逐個人工確認後,在交付說明中註明「已複核」;發現錯誤數字 → 修正 → 重跑質檢。 - 只有質檢通過(硬錯誤為 0 且未匹配數字全部複核無誤)後,才允許進入 Step 8 呈現看板。 - 使用者提出修改意見、生成第二版後,同樣必須重跑一次質檢。

Step 8: 首版看板意見徵詢(只問一次)

• 呈現首版看板後,必須向用戶徵詢一次修改意見,提問格式: 「看板已生成,是否需要修改?不需要修改請回復『否』;需要修改請直接告訴我改哪裡,例如:去掉標題下面的小字、第一張圖配色改成紫色、第六張圖改成雙摺線圖等。」
• 使用者回覆「否」「不用」「可以」「OK」等否定或確認表達 → 直接進入 Step 9 交付文字結論。
• 使用者回覆具體修改意見 → 嚴格按意見修改看板(如調整配色、更換圖表型別、刪除元素、調整佈局、改標題文字),修改後重跑 Step 7 質檢,再生成第二版並重新用 present_files 呈現;修改完成後不再二次徵詢,直接進入 Step 9。
• 修改看板時紅線不變:允許改的是樣式、圖表型別、佈局、文案措辭;資料與數字絕不可編造或改動,圖表資料必須與 Step 3–5 的分析結果保持一致。

Step 9: 交付文字結論

在最終回覆中總結(交付前同樣確認文字無亂碼、數字與看板一致):

• 資料問題 Top 3
• 優勢 Top 3
• 劣勢 Top 3(含影響與建議)
• 看板包含哪些內容、下一步可以做什麼分析
• 附一句質檢結論:「已通過生成後全量質檢(數字核對/亂碼檢查/發現準確性)」

紅線: 文字結論中的每個數字必須與看板中完全一致。若某條結論無法從現有資料得出,寫「資料不足,無法判斷」或「建議補充 XX 資料後驗證」。

注意事項

• 大檔案先抽樣描述,避免長時間執行或記憶體溢位。
• 發現異常值先判斷是真實訊號還是髒資料,不要機械標註。
• 分析結論與圖表口徑一致,避免「文字說 A、圖表畫 B」。
• 使用者只給了部分資料時,明確說明結論的適用範圍,不誇大。
• 嚴禁在分析或看板中編造任何資料、推測未提供的指標、或美化資料以迎合預期。

這個 Skill 整體質量中規中矩，能較好地完成資料視覺化儀表板生成任務。主要優點是模板風格多樣、視覺效果不錯、分析邏輯完整。不足之處在於使用說明不夠詳細，對新手不太友好，且缺乏靈活的配置選項，個性化程度有限。如果需要快速生成固定風格的資料展示頁面可以使用，但複雜需求可能需要進一步定製。