蓝色波点几何画板｜Blue Dot

蓝色波点几何画板｜Blue Dot は何をしますか？

目標

把知識表達轉成一張「一圖一意」的幾何圖示。核心視覺語言是點、線、面、體及其關係：先提煉唯一核心判斷，再判斷對象與關係、選擇卡片/點線/混合表達，隨後選擇構圖、生成 Scene JSON，用 scripts/validate_scene.py 做確定性結構校驗後，按視覺系統規則生成 SVG；不要讓模型不經 Scene JSON 與校驗就直接自由堆砌像素或 SVG 路徑。

默認輸出白底、黑白灰加一個強調色、留白充足、幾何語義穩定、文字直白易懂且簡潔克制的圖。視覺上要有「正在編輯一張結構圖」的幾何編輯感，而不是信息卡片牆；優先保證內容準確、重點清楚、讀者一眼能看懂和結果可復用，再追求裝飾性；畫板負責核心判斷、關係和必要副標題，正文負責背景、證據和細節，寫入後刪除與畫板重複的解釋。

觸發後的標準流程

1. 取得輸入。優先讀取用戶提供的文字或當前選中文字；若用戶給出已有圖示，先提取其信息關係，再決定是否進入「重繪」流程。
2. 寫出內部摘要：這張圖要讓讀者一眼理解什麼？讀者會帶走什麼？。只保留一個核心判斷，並先用日常業務語言說清楚；混合技術背景時，先寫共同收益、判斷標準或下一步動作，再放入必要術語；標題要能被陌生讀者直接複述，若讀者還要先解釋隱喻再說結論，就繼續改寫；若確實存在兩個互不相容的判斷，拆成兩張圖或向用戶說明取捨。
3. 抽取信息：主體、對象、動作、關係、層級、順序、狀態、對比、重點和輔助信息。
4. 先按「表達方式選擇」判斷使用卡片、點線或混合，再用 點線面體與視覺關係語言 確定幾何語義和主要視覺變量，最後按下方決策規則選擇一個主構圖。多張畫板先建立「主題 → 核心判斷 → 構圖家族」清單，避免連續套用同一閱讀方向和骨架；默認只生成一個最佳結果，用戶要求備選時再給最多兩個候選。
5. 生成符合 Scene JSON 協議 的結構化場景數據。節點、邊和文字都要有表達目的。
6. 執行 scripts/validate_scene.py 做結構約束檢查；有錯誤時先修正 Scene JSON，不要用渲染後的視覺問題掩蓋結構問題。
7. 先執行「直白易懂 + 文字克制模式」，刪除重複解釋、例子、長句、抽象名詞堆疊和非關鍵限定；必要時把一行解釋壓縮為副標題，再按 Scene JSON 生成 SVG（結構由 validate_scene.py 約束，視覺呈現由模型按下述規則生成）。若畫板會插入正文，正文保留背景、證據和鏈接，刪除與標題/副標題重複的說明。使用 視覺系統 中的尺寸、顏色、字號、線寬、留白和禁用規則；涉及點線面體、節奏、格式塔、圖層、透明度、網格或動態關係時，讀取 點線面體與視覺關係語言。
8. 做視覺審查：檢查重疊、溢出、對齊、連線交叉、文字密度、視覺焦點、顏色數量和縮小後的可讀性。多張畫板還要檢查構圖家族、閱讀方向和視覺重心是否有足夠差異。未達標時優先刪減信息、重排佈局或切換構圖。
9. 向用戶展示預覽，並用一句話說明核心判斷和採用的構圖。若用戶要求文件，輸出 SVG；需要兼容性時額外導出高解析度 PNG。
10. 用戶確認後再寫入飛書文檔。寫入前確認目標文檔、目標賬號/租戶和寫入方式；不得混用個人與公司身份。先按文檔結構建立「畫板主題 → 段落錨點」映射，再把畫板插入對應段落附近；默認禁止把多張畫板一股腦追加到文檔末尾或集中到同一處。使用當前可用的飛書文檔/雲盤能力完成寫入並讀回驗證。
11. 自然語言修改時只改變用戶明確提及的部分，保留其他節點、關係和風格；用戶要求保留或恢復某個構圖時，凍結幾何骨架，只修改文字與必要間距；修改後重新校驗、渲染和審查。

點線面體核心語言

• 點表達位置和對象；線表達移動、連接、方向和依賴；面表達範圍、群組、階段和共同屬性；體表達層級、空間剖面和系統整體。
• 通過位置、距離、尺度、方向、線寬、對齊、重複、包含、重疊、透明度和空白表達關係；每個視覺變量優先只承擔一個含義。
• 從點到體優先使用生成關係、軸測、切面、疊層和透明度，不使用寫實光影製造裝飾性立體感。
• 節奏來自重複與變化，平衡來自對稱與有意的不對稱，層級來自尺度、位置、線寬和對比度。
• 線條不默認全部使用直線：軸線、邊界、對齊線和明確的步驟關係可用直線；流動、反饋、協作、迴路和跨空間關係優先使用自然弧線。
• 多條弧線必須有共同的幾何依據，例如共享圓心、共同控制點、統一曲率或鏡面對稱；弧線數量增加時優先使用平行偏移或對稱展開，不允許隨機彎折、方向不一或為了「有設計感」而漂浮。
• Geometry Blue #2F6BFF 是唯一默認強調色，面積小而位置準，只標出核心對象、主路徑、當前狀態、風險或變化。
• 藍色圓點是可選的「狀態定位點」，不是必備裝飾。只有當它明確標記變化、反饋、決策、信號或當前焦點，並且與主路徑相連時才使用；沒有可說清的語義就刪除。
• 藍色圓點可以出現一個或多個，但數量由語義決定，不由版式填充決定。多個圓點必須表達同一類狀態或一組可比較的事件，並保持位置、大小和連接規則一致。
• 使用藍色圓點時，先回答「這個點發生了什麼？」以及「它改變了哪條關係？」。圓點應落在幾何中心、主軸、轉折點或連接端點上；不要讓它漂浮在文字旁邊，也不要用它替代普通節點。
• 詳細語義、視覺變量和設計原則見 點線面體與視覺關係語言。

構圖選擇

• 明確時間、流程、因果或演進：axis-flow
• 存在上下依賴、平台/產品/組織分層：layered-architecture
• 一個中心連接多個對象：radial-center
• 兩個評價維度、分類、優先級或風險影響：matrix-2d
• 輸入經過中間機制產生輸出：input-process-output
• 群體分類、篩選、轉化或規模收斂：dot-filter
• 系統內部層次、平台能力或空間剖面：section-space
• 舊新模式、衝突、權衡、競爭或目標現實張力：tension-contrast

無法判斷時，優先選擇最能表達關係的構圖，而不是最熟悉的傳統流程圖。輸入缺少明確關係、信息過於零散或更適合表格/數據圖表時，明確告知用戶並建議縮小範圍或換表達方式。

多張畫板的構圖策略

• 統一視覺系統，主動變化主體構圖。標題位置、字體、顏色和線寬保持穩定；關係區可在匯聚、縱向篩選、雙欄、上下邊界、雙路徑和二維矩陣之間切換。
• 4 張畫板至少使用 3 種構圖家族；6 張畫板至少使用 4 種。連續兩張不要共享完全相同的閱讀方向、視覺中心和節點骨架。
• 保留一張經典錨點圖。系列開頭若表達「若干輸入組成系統並產生結果」，優先使用經典匯聚結構：左側輸入 → 中間系統/Harness → 右側結果。經典構圖承擔識別與定調，不因追求變化而刪除。
• 構圖差異必須來自信息關係。流程用路徑，篩选用漏鬥，雙類型用雙欄，跨邊界行動用上下穿透，有無增量用雙路徑，雙條件判斷用二維矩陣。
• 詳細的系列編排和內容—構圖映射見 視覺系統。

表達方式選擇：卡片、點線還是混合

先判斷讀者要看的是「對象本身」還是「對象之間的關係」，再決定容器和連線：

• 卡片：當對象是相對獨立、需要並列比較或需要明確邊界的模塊時使用，例如方案選項、角色職責、能力單元、指標組。卡片只承載標題和一條短說明，尺寸或位置可以表達層級，不默認全部等大。
• 點與線：當重點是順序、路徑、依賴、網絡、流動、信號、變化或共同中心時使用。點表達對象/事件，線表達關係/方向，優先讓關係直接可見。
• 混合：當對象本身需要被看作模塊，但模塊之間也有明顯關係時使用。卡片表達真實邊界，點線表達模塊之間的路徑；卡片不能遮住主關係。
• 判斷方法：去掉邊框後，如果關係仍然清楚，邊框多半只是裝飾，應改用點線；如果去掉邊界會讓獨立模塊難以識別，才保留卡片。卡片不是禁用項，卡片牆才是問題。
• 視覺覆核：說明為什麼選擇這種表達方式；如果所有內容都能被機械地塞進相同卡片，說明還沒有完成關係判斷。

版式與佈局原則

• 居中：主視覺中心落在畫布主軸或有意設置的視覺中心，文字使用明確的中心錨點和統一基線；幾何中心、文字中心和視覺重心不應互相打架。
• 對齊：使用 8 px 網格、共同基線、共同軸線和統一內邊距；對齊是讓關係可讀，不是把所有元素機械地排成同一列；寧可重新排版，也不要留下「差一點對齊」的邊緣錯位。
• 排列：按讀者閱讀順序組織，默認從左到右、從上到下；一張圖只保留一條主路徑，相關元素成組，不相關元素拉開，連線盡量不交叉。自然弧線要有明確起點和終點，不能穿過文字；多條弧線採用對稱、鏡像或等距偏移。
• 緊密度：距離表達關係強弱。同組元素使用 8 / 16 / 24 px，相關組之間使用 40 / 64 px，獨立組之間保留更大空白；不要把所有元素平均鋪滿畫布。
• 密度：關係密集處可以緊湊，但必須保留清晰層級；關係稀疏處保留空白，不用額外組件填空。留白是結構的一部分，不是未完成的區域。
• 視覺重點：主對象、主路徑和次要信息使用不同的尺寸、線寬、對比度或顏色；禁止多個同等強度的視覺中心。
• 關係優先：先檢查容器是否幫助讀者識別關係；若邊框只是裝飾或遮住主路徑，就刪除卡片，改用點、線、面、層或空間距離。

詳細的點線面體生成關係、節奏與平衡、尺度、格式塔、圖層、透明度、模塊、網格、模式、時間和規則原則見 點線面體與視覺關係語言。

硬約束

• 默認畫布 1200 × 675、比例 16:9、8 px 網格；可按用戶要求切換 4:3 或 A4 縱向。
• 外邊距約為畫布寬度的 8%，安全區 64–96 px；留白原則上不低於 40%。
• 顏色只用 #111111 / #666666 / #999999 / #222222 / #B8B8B8 / #E8E8E8 / #F5F5F5 / #FFFFFF 加最多一個強調色；默認強調色為 #2F6BFF（Geometry Blue），強調色面積原則上低於 8%。
• 線寬默認 0.5 / 1 / 1.5 px；軸線和邊界優先使用直線，流動與反饋優先使用自然弧線；避免粗大箭頭、隨機曲線和無語義線條。
• 中文優先蘋方、思源黑體、HarmonyOS Sans 或系統無襯線；英文/數字優先 Inter、SF Pro、Helvetica Neue 或 IBM Plex Sans。
• 文字層級不超過三種；單個節點標籤不超過 12 個漢字，中文可見文字默認不超過 80 個漢字，硬上限 120 個漢字。
• 節點默認不超過 15 個，邊默認不超過 20 條；不得出現無連接、無語義的裝飾節點。
• 禁止藍紫漸變、玻璃擬態、大面積陰影、高飽和配色、彩色圓角卡片陣列、卡通圖標、寫實 3D、複雜插畫和模板化 SmartArt 審美。
• 禁止把內容拆成三個以上等尺寸信息卡片、圓角卡片牆、標籤膠囊或 dashboard 式模塊陣列；關係優先使用軸線、點、面、層、交疊、輔助線和空間距離表達。
• 不添加原文沒有的重要事實；無法確認的關係標為假設或請求用戶確認。

視覺定位：幾何編輯感，不是信息卡片

• 把畫板當作一張正在被編輯的結構圖：優先使用幾何體、主軸、輔助線、對齊線、定位點、截面、邊界和空間關係；這些元素必須有結構作用，不做裝飾。
• 默認只設一個主視覺中心或一條主路徑。主對象使用最清晰的輪廓和唯一強調色，其他元素降低對比度、尺寸或線寬，不讓多個模塊爭奪注意力。
• 高級審美來自比例、對齊、留白、線條層級和克制的對比，不來自複雜紋理、陰影、漸變、圖標或堆疊更多組件。
• 如果一個構圖可以被輕易改寫成「三張並列卡片」，優先重構為軸線、層級、中心幾何體、交疊關係或空間佈局。
• 視覺審查時先暫時忽略文字：即使不讀文字，也應能看出重點、方向和關係；若去掉文字後只剩一組盒子，視為卡片感過強，必須重排。

文字克制模式（默認）

• 只保留一個核心判斷；標題表達判斷，幾何關係表達邏輯，副標題在必要時補充一行「為什麼/怎麼用」，正文承載背景、證據和細節。
• 默認採用三層文字：標題、關鍵詞節點、必要註釋；副標題承擔局部解釋時，正文刪除相同意思的導語，底部說明默認刪除。
• 中文可見文字默認控制在 80 字以內；結構複雜時硬上限 120 字。標題之外的句子盡量不超過 18 個漢字。
• 節點優先使用 2–8 字關鍵詞；把完整解釋移到文檔正文。
• 一張圖最多保留 6–8 個關鍵節點；信息過多時，先刪例子和背景，再刪次要節點，不靠縮小字號解決。
• 若出現「標題 + 副標題 + 階段說明 + 節點說明 + footer」五層文案，至少刪掉其中兩層。
• 修改已有圖示時按順序執行：刪長句 → 壓縮節點 → 刪除重複副標題 → 刪除 footer → 再檢查關係是否仍然清楚。

受眾與收穫模式

• 技術和非技術共讀時，先回答「這對我有什麼用」：共同語言、判斷標準、應用邊界或下一步動作；術語放在收益之後。
• 畫板標題負責結論，副標題負責消除歧義，節點負責動作和結果；三者形成一條短閱讀路徑，不重複同一句話。
• 茶水間、群聊、內部推薦等輕閱讀場景，正文先給閱讀理由和可帶走的收穫，再給入口鏈接；畫板作為快速入口，承載最小必要解釋。
• 正文與畫板同時出現時，保留背景、證據、數據、鏈接和需要展開的細節；刪去讀者已經能從標題、副標題和關係圖中讀出的句子。

直白易懂模式（與少字模式同等優先級）

• 優先使用同事日常會說的話，讓不熟悉原文的人也能看懂；標題先說結論，節點盡量寫成「誰做什麼 / 先做什麼 / 結果是什麼」。
• 能用動詞就不用抽象名詞，能用短句就不用概念堆疊。例如「先說清楚」優於「提煉判斷」，「放回原文」優於「確定輸出」。
• 默認少用「賦能、抓手、沉澱、洞察、畫像、機制、鏈路、閉環」等泛化術語；確需保留時，補一個更直白的解釋，或改成具體動作和結果。
• 英文縮寫只在確有必要時保留；首次出現優先給出中文含義，不能讓讀者依賴術語表才能理解圖。
• 每個標題和節點都做一次「陌生同事測試」：只看畫板，能否說出誰、做什麼、為什麼或下一步是什麼；不能時先改文字，再考慮改佈局。
• 做一次「3 秒複述測試」：只看標題和主關係，讀者應能說出核心判斷。公式可直接寫成公式，分類可直接寫「分兩類」，條件可直接寫「滿足兩個條件才做」；不要讓讀者從抽象隱喻裡猜結論。
• 節點可用問題句降低理解成本，例如「這個人是誰」「這個世界是什麼」；結果節點優先寫「拿到信息」「驗證結果」「完成動作」「修改下一步」。
• 直白不等於口語化過度：保持專業、準確和克制，不添加原文沒有的判斷或情緒。

修改指令的處理

把用戶修改分為三類：

• 內容：刪除、增加、改名、合併節點；同步更新節點和相關邊。
• 結構：改成三層、左右對比、時間軸、閉環或縱向版；只重排受影響結構。
• 視覺：更簡潔、增加留白、減少顏色、突出路徑、縮小輔助信息；優先調整 Token 和佈局，不改變語義。

每次修改都要保留未被提及的內容，重新運行校驗和視覺審查，並說明實際改變了什麼。

若回饋只指向一張畫板，只更新該畫板及其源文件，不順手重畫整組。若用戶說「保留上一版構圖，只改內容」，把構圖當作已確認資產，保持節點位置、主路徑和視覺重心，僅改文案及其必要適配。

飛書寫入與交付

默認先交付可審閱的 SVG/PNG 和一句結果說明，再執行插入。若用戶明確要求直接插入，仍需先生成並檢查結果。

分段定位與插入規則

• 先讀取文檔標題層級、段落順序和已有畫板；長文優先讀取大綱及候選章節上下文，不憑標題猜位置。
• 為每張畫板寫出一句內部定位說明：主題 → 對應章節/段落 → 插入錨點。畫板表達該段落剛剛引出的關係、流程或判斷。
• 默認將畫板插在對應段落之後、下一主題標題之前；若該段落有小標題，優先插在小標題下的解釋段之後，而不是插在章節開頭或文檔末尾。
• 多張畫板對應不同主題時，按正文主題出現順序分散插入；同一主題需要多張圖時，保持連續但只放在該主題的小節內。
• 保留原文已有畫板及其相對位置；除非用戶明確要求重排，不移動、替換或合併已有畫板。
• 找不到精確錨點時，選擇最近的語義完整段落，並在寫入前向用戶說明位置假設；不要為了完成插入而集中放置。
• 寫入後不僅確認畫板數量，還要讀回大綱和每個插入點前後的文本，核對「畫板主題—段落主題」是否匹配。
• 若畫板標題與副標題已經承擔該段的局部解釋，可採用「章節標題 → 畫板」的緊湊結構；不要強行保留一段重複導語。

寫入飛書前：

• 確認目標文檔和插入位置；
• 驗證當前使用的賬號/租戶與用戶目標一致；
• 按當前可用連接器或飛書 Skill 的規範上傳/插入；
• 寫入後讀回文檔或資源元數據，確認插入成功；
• 在結果中區分「已生成」「已插入」「僅保留源文件」三種狀態。

若飛書圖片預覽暫時返回佔位圖或空白圖，先查詢原生節點數量並導出遠端 SVG；遠端 SVG 可正確回讀和渲染時，說明畫板內容已寫入，再重試圖片預覽。不要把預覽緩存延遲誤判為畫板丟失。

若飛書側無法保留 SVG 的可編輯性，插入高解析度 PNG，同時保留 SVG 源文件；不要把 PNG 插入成功誤報為可編輯畫板。

交付檢查清單

在聲明完成前確認：

• 核心判斷能用一句話說清，且與原文一致；
• 畫板文字直白易懂，陌生讀者不需要額外術語解釋；
• 卡片、點線或混合表達方式與信息關係匹配，並能說明選擇理由；
• 居中、對齊、排列和緊密度經過檢查，關係強弱與空間距離一致；
• 構圖與關係匹配；
• 多張畫板達到構圖多樣性要求，並保留適合內容的經典錨點圖；
• 標題與主關係通過「3 秒複述測試」，讀者無需先解釋隱喻；
• 無重疊、文字溢出、無意義節點和明顯連線交叉；
• 弧線有明確關係語義，多條弧線經過對稱、鏡像或等距檢查，沒有隨機彎折；
• 黑白灰加一個強調色，字號/線寬/圓角統一；
• 留白充分，縮小至 25% 仍能看懂整體關係；
• Scene JSON 已通過校驗；
• 多張畫板已按主題分散到對應段落，未無理由集中追加；
• 文件路徑或飛書文檔寫入狀態可被用戶覆核。

詳細構圖模板、視覺 Token、禁用樣式和審查權重見 references/visual-system.md；Scene JSON 字段和示例見 references/scene-json-schema.md。