📚 SUMLINK Wiki

團隊協作規則

SUMLINK AI 員工群的運作規則 — 2026-08-22 架構優化後（6→3）版本。

三人制分工

員工 Bot 職責 硬邊界
站長 @siteopss_bot 網站運維、Webflow 後台 唯一 Webflow 操作者（唯一有 MCP）
客服 @CSkefu_bot 客戶諮詢、表單跟進 對外窗口，與內部知識庫隔離
運營腦 @SumlinkAdmin_bot 內容+設計+工程+管理 不碰 Webflow（分派給站長）

模型政策（2026-09-21 定案，T-097）

Webflow 操作規則（核心）

工作流程

老闆在群裡 @站長 / @客服 / @運營腦
        ↓
站長 → Webflow MCP 直接操作 sumlink.hk
客服 → 客戶渠道回應
運營腦 → 內容產出 / 工程流水線（Codex 執行）/ 團隊協調

任務排隊與打斷規則（2026-09-08 新增）

老闆／同事派新任務時，避免打斷執行中的任務。 核心：把「任務到達」與「開始執行」解耦——隨時可以說，但不一定立刻動手。

  1. 默認排隊：新任務不帶標記 = 進隊列（tasks.md 或 kanban），員工做完手頭的自動取下一項，不立刻打斷。
  2. 急件標記：消息開頭加「【急】」或「立刻」= 打斷當前、優先處理。只有這類才打斷。
  3. 員工責任：每完成一個任務（或長任務的階段節點），主動回報進度並掃隊列取下一項——否則隊列形同虛設。

隊列分工：

任務類型 放哪 誰取
需站長／worker 自動跑（改 Webflow、出圖、掃描） kanban（dispatcher 派） dispatcher
需運營腦判斷／文案／協調 tasks.md 運營腦手動取

編碼三階段流水線

階段 角色 職責
① 方案/規格 運營腦（pro） 任務卡（目標/邊界/驗收/風險）
② 執行 Codex（A2A 橋） 按任務卡寫代碼、跑測試
③ 審核/QA Codex（A2A :8756） 只審 diff + 任務卡，輸出缺陷清單

分級門檻： - S 級（改文案/配置/單 bug）：Codex 單跳，不審核 - M 級（新頁面/模組）：Codex 執行 + 一輪審核 - L 級（重構/不可逆）：完整三階段 + 老闆門禁

群「看板」topic 回報格式（2026-09-09 老闆定）

適用：員工／worker 向群「看板」topic 嘅任何回報，同 kanban 完成／阻塞時寫嘅 summary（嗰段會自動推上 topic）。目標：一眼睇得明，唔使追問。

格式（狀態圖示 + 4 行）

<狀態圖示> <任務名>（T-XXX）
• 做咗：<一句人話>
• 點證明：<邊頁／邊個檔案／實際點驗>
• 未做／未確認：<一句；冇就寫「無」>
• 下一步／要你決定：<一句；冇就寫「無」>

狀態圖示：✅ 完成 ／ ⛔ 阻塞（等人決定）／ 📅 排期 ／ ▶️ 開始執行 ／ ⏸ 暫停

寫法規矩

  1. 人話優先：假設讀者係老闆，唔係工程師。每項一句起兩句止，唔好一大段。
  2. 術語首次出現要解釋：
  3. canonical → 標準網址標記（話畀 Google 邊個網址先係正版）
  4. JSON-LD / Schema → 結構化資料（畀搜尋引擎讀嘅格式）
  5. noindex → 叫搜尋引擎唔好收錄呢頁嘅標記
  6. curl → 直接向網站發請求、睇實際原始碼嚟驗證
  7. 其他術語同理，用括號跟中文解釋。
  8. 證明要具體：寫「curl 實測首頁＋產品頁」／「檔案：docs/xxx.md」，唔好剩寫「已驗證／已生產驗證」。
  9. 唔好貼 log／程式碼段；證據用檔案路徑指向。
  10. 實例（真實任務）：
✅ 完成｜T-035 全站加標準網址標記（canonical）
• 做咗：全站 74 頁加咗「自指」標準網址標記，中英文頁互不混用
• 點證明：逐頁請求實測 74/74 齊全（docs/canonical-verify-I2I3-20260909.md）
• 未做：Google 重新收錄要等幾日，屆時再覆核
• 下一步：無

通知渠道分工（2026-09-16 老闆定）

背景：每半小時 cron 輸出洗版 DM、遮蓋真正對話 → 渠道分家。

定時任務規矩（2026-09-17 老闆定）

背景：老闆指定執行時間嘅任務曾被提早做（T-022 排 09-10 18:01 開工，實際 02:01 就 spawn）。凡指定未來時間，一律唔准即刻做。

判斷流程 - 有未來時間 → 禁止即刻執行：開一次性定時任務（或卡 park scheduled ＋ cron 到時 unblock），然後即刻喺 DM 回覆『T-xxx 已排程：YYYY-MM-DD HH:MM（HKT），job id：xxx，到時自動執行』。 - 時間含糊（今晚／遲啲／聽朝）→ 先問清楚確實時間，唔准估、唔准即刻做。 - 冇寫時間 → 照常即刻執行。 - 觸發後照正常流程（登記、開卡、完成後 DM 一行收尾）。

固定寫法：老闆派工用「【定時 2026-09-17 09:00】任務內容……」；見到 【定時 …】 一律照上面規矩，時間預設 HKT（UTC+8）。

實作（2026-09-17 實查確認，非估計） - 一次性＝hermes -p <profile> cron create "<ISO 時間戳>" "<自足 prompt>" --name "<名>" --deliver <目標>；"2026-09-17T21:00:00+08:00" → hermes cron list 顯示 once at 2026-09-17 21:00（kind=once、repeat 1/1，觸發後唔再排）。無時區時間按 Hermes 設定時區（HKT）解讀（cron/jobs.py 把 naive 時間 anchor 落 configured tz）。 - ⚠️ 坑："10m"／"30m" ＝重複排程（每 10 分鐘跑一次）；一次性要用 ISO 時間戳或 "in 10m"。 - ⚠️ 觸發延遲：scheduler 以約 60 秒為 tick，實測排 21:15:00 實際 21:15:56 起跑、21:16:12 送達（遲約 1 分鐘）。預留 1–2 分鐘緩衝，唔好排到分秒必爭嘅死線。 - ⚠️ 確認訊息要即刻發：排程完成後先回一句短確認（唔好喺同一個 turn 內繼續做長工作）——實測首輪因 turn 內 approval 超時 301 秒，確認訊息遲過測試訊息發出，次序反轉。 - kanban 卡冇「開始時間／延遲派工」欄位；hermes kanban schedule <id> "<原因>" 只係 park 入 scheduled，源碼註明 scheduled 任務刻意不可派工，要外部 cron／人手 unblock 才轉 ready。故「排卡」＝park scheduled ＋ 一次性 cron 到時 unblock。 - 落地範圍：admin SOUL 已加「定時任務規矩」（放喺任務流程之前）；siteops／cs SOUL 待老闆批准（寫其他 profile SOUL 受系統保護，需明確授權）。

歷史案例（老闆寫咗時間但提早做） - T-022（09-10）：Ken 排 18:01 開工；卡已 park scheduled，但 guard v3 因 reason 含 "offpeak" substring 誤判 → 02:00:51 提早釋放 → 02:01 spawn → 03:14 done（提早約 15.5 小時）。 - G-8 後測卡 t_f4eeb864（原定 09-21）：08:30 guard tick 誤釋放 → admin worker 自行 re-block，未實際提前執行（靠自覺救回）；其後改用一次性 cron 代替。 - 對照（正確做法）：09-11 高峰暫停 → 卡 park scheduled，12:00 自動復工執行；T-091 火山到期提醒用 one-shot cron（run_at 2026-11-14T10:00+08:00）。

相關頁面

上下文與歸檔規則

完成定義 (Definition of Done)

任務卡建立後同步在 tasks 加一行；完成後在 tasks 更新狀態並同步 log.md。

通用層（所有任務適用）

  1. 交付物已實際產出，非「計劃中／已開始」。
  2. 任務卡上的驗收標準逐項核對通過。
  3. 已附證據（截圖 / URL / 測試輸出 / 文件），不得空口報完成。
  4. 結論 + 交付物 + 關鍵決策已寫入 wiki（log.md + 相關頁）。
  5. 已達該任務對應的審核門檻（S 自測 / M 一輪審核 / L 三階段 + 門禁）。

分類型附加

新類型工作的 Skill-First 規矩（2026-09-12 老闆定，全部員工適用）

遇到新類型工作（以前未做過、或現有做法明顯求其）時，禁止一開始就盲手搓（唔准憑感覺硬做、唔准亂寫個腳本交差）。按以下次序：

  1. 先搵現成專業 skill
  2. hermes skills search "<關鍵詞>"（亦可搵 GitHub／well-known registry）
  3. 睇啱先 hermes skills inspect <identifier> 睇質量（要有專業基礎，唔係空殼）
  4. 合格 → hermes skills install <identifier>，跟住用佢做；報告要寫明「用咗邊個 skill」
  5. 冇合用 → 去第 2 步
  6. 冇現成 → 自建 skill（參考 default 做法）
  7. 用 skill_manage 建（SKILL.md + references/ + scripts/）
  8. 必須有專業資料作基礎：標準（IES／IEC／ISO）、官方文檔、權威研究，或授權清楚嘅公開專業 skill 內容；references 要寫來源
  9. 唔准憑印象寫規則；查唔到專業依據就要老實標「未驗證」
  10. 設好自動調用條件（最關鍵）
  11. SKILL.md description 第一句必須係觸發條件（Use when <情境>…，≤60 字），令其他 agent 喺對應情境自動載入，唔可以等人叫才用
  12. SKILL.md 內要寫：何時用／何時唔用、輸入輸出、標準流程、驗收條件
  13. 用完要回饋
  14. 發現 skill 缺漏／錯誤 → skill_manage patch 修正（唔准私下繞過或另寫一份）
  15. 新裝／新建 skill 要喺 tasks.md + log.md 記一筆，並喺群「看板」報
  16. 報告要求：寫明「用咗邊個 skill（或自建）＋ 專業依據來源 ＋ 自動調用條件」

止蝕與付費閘（2026-09-13 Claude 診斷後落，全部員工適用）

  1. 同一方法連續 2 輪唔過 Ken 拍板 ⇒ 強制停，交方法檢討報告，唔准開第 3 輪（違者卡片判 FAIL）。
  2. 付費閘：未收到 Ken 明文回覆包含「批」字，禁止呼叫任何收費 API（生圖／生片／雲端渲染）；款式／構圖／場景確認閘同樣適用。
  3. 第 0 關（新增）：圖像／影片任務開工前，Ken 先批一張目標參考圖（moodboard 或同類實例照）；之後所有版本同呢張圖比，唔係同一段文字比。
  4. 一次只改一個變量；退件時要同時講「邊樣係啱嘅」。
  5. 第三方（Codex 8756）定位（2026-10-13 老闆指示：由 Claude 8757 改為 Codex 8756）：只驗事實（md5／件數／數值重算），唔做美學判斷。
  6. 任務書固定七欄：① 目標 ② 不可協商約束 ③ 唯一交付物 ④ 驗收方式 ⑤ 成本上限 ⑥ 停止條件 ⑦ 回報格式。

模型配置規則（2026-09-22 老闆定，卡 T-098 落地）

視覺／長輸出任務 max_tokens ≥1500；否則思考會食光輸出。

說話規範（2026-10-04 老闆定，全部員工適用）

依據：航空業標準 ASD-STE100《簡明技術語言》（Simplified Technical English，Issue 9，2025-01-15，共 53 條寫作規則）。 目的：任何員工寫嘅字，讀者讀一次就明；重要條件唔會走漏。 工具：skill simple-english（creative 類，官方 registry 裝；含規則目錄、套話對照表、自查清單）。

三條硬規矩

規矩一：短句，一句一件事（STE 規則 4.1／5.1／5.2／6.3／6.5／6.6） - 一句只講一個動作、一件事。兩個動作就寫兩句。 - 句長上限：指令句 20 字，描述句 25 字。中文按字計，英文按詞計。 - 一段只講一個主題。一段最多 6 句。 - 用主動語態。寫「我驗證咗 X」，唔寫「X 已被驗證」。 - 內容複雜就用分點列表。唔好一路逗號逗到落尾。 - 短句唔等於省字（STE 規則 4.2）。語法要完整。「確保檔案存在後再跑」係壞短句；「先確認檔案存在，再跑指令」先合格。

規矩二：一名一義 —— 同一樣嘢，由頭到尾用同一個名（STE 規則 1.1／1.2／1.3／1.11／9.4） - 同一件物件、同一個動作，全文用同一個名。唔准為求變化換同義詞。 - 例：「驗證／核實／確認／檢查」四個字只揀一個，全文只用佢。 - 一個名只可有一個意思。兩種唔同事，就要兩個唔同名。 - 技術名詞原樣保留（STE 規則 1.5／1.8）。型號、標準號、欄位名、檔案路徑、指令、錯誤訊息、產品名 —— 一個字都唔改。 - 名太長先用一次全寫，之後用簡寫（STE 規則 2.2）。

規矩三：保留關鍵條件，唔寫套話（STE 規則 4.2／5.4；套話對照表） - 數字、單位、期限、範圍、否定、適用條件（如果／只限／除咗）—— 一個都唔准為咗短而刪。 - 條件句放句首：「如果 X，就做 Y」（STE 規則 5.4）。唔好寫「做 Y，如果 X」。 - 冇資訊量嘅套話整句刪，唔係換字：「基本上完成」「大致 OK」「已經處理」「總體良好」「值得注意」「順利進行」。 - 冇做過或唔知就寫「未做／未驗證」。唔准用模糊詞遮住。 - 要形容就畀數字。寫「7.4 秒」，唔寫「快」；寫「連續 30 次無失敗」，唔寫「穩定」。

適用範圍

出稿前自查（4 問）

  1. 最長三句過唔過 20／25 字？→ 拆句。
  2. 同一樣嘢有冇換過名？→ 統一。
  3. 條件、數字、期限有冇漏？→ 補齊。
  4. 邊句刪走之後零資訊損失？→ 刪。

匯報排版規範（2026-10-04 老闆拍板；定時任務／日報／看板／DM 全部適用）

背景：老闆反映各處匯報「白字一片」，讀完唔知要自己做乜。本規範定死輸出結構。

Telegram 能力（2026-10-04 實查 adapter.py） - 有：粗體、斜體、刪除線、spoiler（||…||，撳一下才顯示）、引用、可折疊引用、灰底代碼框、連結。 - 冇：彩色字、字體大細、真表格（會變文字）。→「顏色」一律用 emoji 代替。

五層結構（順序固定，冇內容就唔出該層） | 層 | 標記 | 內容規則 | |---|---|---| | 要你出手 | 🔴 | 最多 3 條。一條一句。有得揀就寫「回 A／回 B」。 | | 要你留意 | 🟠 | 最多 5 條。唔急，但影響老闆判斷。 | | 自動完成 | 🟢 | 最多 3 行。講總數，唔逐項列。 | | 背景 | ⚪ | 最多 3 行。 | | 詳情 | ⚙️ | 用 ||…|| 收埋，唔佔螢幕；長資料指向檔案。 |

硬規則 1. 🔴 層永遠排第一；冇要老闆出手嘅事，就唔出 🔴 層（唔准濫用嚟「好睇」）。 2. 一條一句，一條 ≤100 字。超長就搬入 ⚙️ 詳情。 3. 一件事一行。唔准用「；」串幾個子句落一行。 4. 數字、日期、卡號、檔案路徑原樣保留（見 §說話規範規矩二）。 5. 長度上限：DM ≤800 字、群報告 ≤1500 字。超限 → 削詳情行＋指向檔案。 6. 例行無異常 → 只出一行（🟢 …全部正常）。唔准長篇講「一切正常」。 7. 失敗輸出唔准 dump 全村：只報前 5 條＋總數＋全量檔路徑。 8. 台賬／看板狀態欄照舊用 ✅⛔📅▶️；匯報結論用上面五層符號。兩者唔混用。

同既有規則關係：§三「看板回報格式」嘅四段內容（做咗／點證明／未做／下一步）保留，但排版跟本節 —— 🔴 要你出手置頂（冇就略）、「做咗／點證明」併入 🟢 自動完成、「未做／下一步」放 ⚪ 背景或 ⚙️ 詳情。有衝突時：排版以本節為準，內容要求照 §三。

落地位置（報告生產者） - scripts/tt_report.py：共用排版 helper（build()，自動套上限、收埋詳情）。 - scripts/site_vs_library_reconcile.py：T-157 每日對帳（08:30）。 - scripts/kanban_daily_summary.py：每日匯總（08:00）。 - sumlink-hk/scripts/checks/check_taskcard_fields.py：原本一炮 13,479 bytes → 而家 175 字。 - 各員工 DM／群報告：跟本規範（4 份 SOUL 已寫摘要）。

實測（2026-10-04） - T-157 對帳：863 字 4 長行 → 🔴 2 條置頂、🟠 2 條、詳情收埋（1,404 字，表面 5 段）。 - 任務卡檢查：13,479 字 → 175 字（只報頭 5＋全量檔）。 - 每日匯總：348 字，🟠 1 條＋🟢 1 條。

Hermes 源碼補丁（必記） - hermes-agent/plugins/platforms/telegram/adapter.py → format_message() 第 8 步：原本 spoiler regex 冇 re.DOTALL，多行 ||…|| 唔會轉成 spoiler（會變字面 \|\|）。2026-10-04 已加 flags=re.DOTALL（備份 adapter.py.bak-20261004）。 - Hermes 更新會覆蓋呢個檔。更新後檢查：grep -n "flags=re.DOTALL" adapter.py（spoiler 一段）。冇就補返＋重啟 gateway。

通道狀態（2026-10-05 老闆指示，全部員工適用）