Cues — 預測使用者的下一個詞彙
你坐在一位透過對話探索某個領域的使用者旁邊。
他們正在草稿、建構或創作某樣東西。你的
副作用是一個檔案 — .cues/CUES.md — OpenCues 運行時
會在下一次重新載入時載入它，並在使用者輸入時
用來呈現替代方案、改寫和技巧。
在你的聊天回覆「之外」觸發，而非取代它
這是一個副作用技能。它與使用者實際要求你做的事情
並存。如果他們說「我正在起草一封給 X 的電子郵件 — 幫幫我」，你的聊天回覆會起草電子郵件，而你的
副作用會寫入 .cues/CUES.md 預測未來同類型郵件的提示。
如果他們說「我正在建立一個網站」，你的聊天回覆會
提出釐清問題，而你的副作用會寫入
.cues/CUES.md 預測他們的詞彙。
聊天任務和提示副作用是獨立的。提示 檔案絕不是使用者可見的交付物 — 它存在於磁碟上 供運行時靜默載入。如果你發現自己省略了 檔案，因為「我已經在聊天中幫助他們了」，你就 違反了技能的合約。兩者都要做。
聊天回覆結尾的單行括號是檔案唯一的 提及。它不會佔據聊天輸出。
產物是預測。一個在使用者已經輸入其字詞後才出現的提示 就太遲了。標準是：當使用者在他們的下一個 回話中引入新的詞彙時，它應該已經被你 在這個回話中寫入的內容所涵蓋。
兩種模式
在執行任何其他操作之前，先讀取 .cues/CUES.md。它的存在
會切換模式：
- 初始（檔案缺失） — 從頭開始預測任務的 整個預測表面。
- 持續（檔案存在） — 擴展表面。先讀取 現有檔案；你的輸出是其嚴格的超集。
嚴格擴展（僅限持續模式）
檔案中已有的每個來源必須出現在你的輸出中 —
相同名稱、相同 match:、相同主體 — 除非新的
對話上下文直接與之矛盾（使用者轉向了、
放棄了該部分等）。你可以：
- 提高當前活躍焦點區域中來源的優先級。
- 降低使用者已完成部分中來源的優先級。
- 為先前預測不足的詞彙添加新來源。
每次回話都重寫 — 而非「無變更則跳過」
在每個實質的使用者回話時，你必須呼叫寫入工具並提供一個完整的更新版 CUES.md， 即使自上一個回話以來的變更很小。理由：使用者剛剛給了你一條新訊息； 該訊息移動了對話的焦點，即使只是一個子主題。活躍區域 需要追蹤這個移動。 「無變更」輸出意味著你判斷使用者沒有轉向， 這在一個新的實質回話之後幾乎從未成立。
如果經過思考，你真誠地相信使用者的新訊息 沒有增加任何新內容 — 他們回覆了「謝謝」或在同一個微主題內 提出了一個快速的後續問題 — 你可以跳過寫入。 但門檻很高：說出具體原因（「使用者提出了完全在活躍區域主題內的釐清問題，且沒有新的子詞彙」）。跳過是例外，而非預設。
基準證據（2026 年 5 月，評審基準）：當技能在 N>1 的回話中 跳過重寫時，新鮮度會在回話 3 時崩潰，因為 活躍區域凍結在回話 1 的主題上。每次回話都 重寫能讓焦點跟隨使用者。
前瞻 — 指出接下來的 2-3 個部分，為它們提高來源
在分配優先級之前，先在心裡（不在檔案中）寫下 鑑於使用者目前所在位置，該領域中最有可能出現的下 2-3 個 子主題。然後檢查：預測表面是否有至少一個來源 在 75 或以上來涵蓋這些即將到來的部分？
如果沒有，提高一個來源來填補這個缺口 — 可以是全新的
### <id>，或者提升一個現有低優先級來源。
重點不在於確定性；而是覆蓋率。如果使用者 讓對話持續前進，你希望他們的接下來 1-2 個 部分已經預先準備好。如果他們反而回頭， 後處理器/降級規則會在下一個回話時將前瞻來源標記為 非活躍 — 這代價很小。
範例（2026 年 5 月經基準驗證的失敗模式）：
- API 端點分階段建構：在 T3（錯誤封裝），
可能的 T4 是整合測試或可觀測性。提高
至少一個涵蓋
vitest|supertest|describe|it| expect或logger|telemetry|trace|metric的 來源到 75 或以上。 - 自由合約逐條草擬：在 T3（智慧財產權），
可能的 T4 是終止/爭議解決/責任。提高
至少一個涵蓋
terminate|notice|kill.fee| dispute|arbitration|liability的來源到 75 或以上。 - 逐頁建立網站：在 T2（畫廊），可能的 T3 是關於/聯絡/商店。為這些提高來源到 75 或以上。
經基準驗證的規則：對於任何超過 2 層的對話， 活躍區域不應該只向後看。 至少有一個 75 或以上的來源應該預測該領域中一個 可能的下一個子主題。如果你只是鏡像使用者 已經說過的話，當他們轉向時，預測表面就會過時。
這不是對隨機岔題的猜測。它是 領域中的主線路徑：合約有終止條款， REST 端點有測試，網站有聯絡 頁面，食譜有裝盤說明。指出明顯的 下一個部分並預先準備好。
降級 — 可觀察的，每個來源獨立
當使用者完成一個子主題並轉向一個新的子主題時， 你必須降低已解決來源的優先級。問題是 多少 — 而答案在使用者的新訊息中是可觀察的， 而非領域判斷。
測試：使用者的新訊息是否包含
先前來源的 match: 正則表達式會命中的詞彙？
對於當前在 85+ 活躍區域中的每個來源，掃描新的使用者訊息：
-
找到匹配 — 使用者仍在引用這個 來源的詞彙。該來源在下一個回話中仍然活躍或 跨領域影響。輕度降級：從 85 降到 70。 將其保留在相鄰區域，以便當使用者再次輸入那些字詞時， 其提示仍然會出現。
-
無匹配 — 使用者已經脫離了這個來源的詞彙。 該來源已正交地解決。 重度降級：從 85 降到 50。 將其撤出檯面。 阻止它與真正活躍的新來源競爭詞彙匹配。
在不確定時預設：重度降級。 基準證據 （2026 年 5 月）：大多數轉向在詞彙層面是正交的， 即使高層領域看起來相關。預設使用輕度降級會 在使用者明顯轉向時（網站作品集：T2 關於 畫廊 → T3 關於 Stripe 付款 — 畫廊詞彙 並未出現在 T3；畫廊應該重度降級，即使兩個 回話都「關於網站」），在相鄰區域留下太多過時的詞彙。 重度降級一個仍然相關的來源的代價是，當使用者 回溯引用時，他們的那個詞會完全沒有提示 — 但使用者的新訊息是事實依據：如果他們引用了先前的詞彙， 正則表達式匹配會捕捉到它。
實作範例（針對同一 v3.0e 規則）：
| 先前來源 @ 85 | 使用者的新訊息 | 匹配？ | 動作 |
|---|---|---|---|
gallery-layout match: gallery|portfolio|grid | "現在我需要一個有 Stripe 的聯絡頁面…" | 否 | 重度 → 50 |
jr-pass match: JR Pass|Shinkansen|reserved | "JR Pass 就它了。現在住宿…" | 是 (JR Pass) | 輕度 → 70 |
captaincy match: captain|armband|differential | "接下來後衛 — Trippier 或 Gordon" | 否 | 重度 → 50 |
ownership match: template|differential|owned | "隊長用範本" | 是 (template) | 輕度 → 70 |
規則是每個來源獨立，而非每個回話。在一個回話中，你可能會 重度降級一些先前來源，並輕度降級其他來源 — 這取決於 每個來源的詞彙是否實際上出現在新的使用者訊息中。
如果兩個或更多來源都仍然匹配 — 沒問題，兩個都降到 70。 活躍區域保持狹窄；相鄰區域可以容納幾個 跨領域影響的來源而不會稀釋。
三層優先級模型
將優先級想像成一個三層開關：
- 85–90 — 活躍焦點（使用者現在正在輸入的內容）
- 65–80 — 相鄰 / 即將活躍 / 跨領域影響 / 專案背景
- 50–60 — 最近完成的正交（保持存活但 不競爭匹配）
如果你發現自己在 85+ 區域中有超過 3 個來源， 那就出錯了 — 它們大多數應該在 65-80 或 50-60。活躍區域應該狹窄。
你不得以「使用者沒用過它」為由刪除先前的來源。 使用者可能現在正在循環使用它；從他們下面抽走它 是循環的主要失敗模式。
如果你的輸出比先前檔案中的來源少，你就 犯了錯。重新讀取；將缺失的來源複製到前方。
初始模式 — 廣泛預測
第一次寫入是決定性的。預測使用者合理可能會 觸及的每一個子詞彙 — 不僅僅是他們在開場回話中所說的內容。
將使用者的種子訊息視為一個關於更大空間的數據點。
從「我正在為我的攝影作品集建立一個網站」
使用者陳述了一個運行時需要提示的詞
（photography）；你的工作是推斷任何
正在運作的攝影作品集網站會觸及的約 15-20 個
詞彙族（專業化、畫廊佈局、圖片格式、
部署目標、預約機制、可訪問性等）。
無論領域如何，都應用相同的擴展。對於「起草 A 輪融資簡報」、 「撰寫小說第三章」或「設定 Rails 部署手冊」— 讀取種子，產生使用者合理會 輸入的每個子區域。
如果你發現自己在 8 個來源就停了，問「我還遺漏了什麼合理的子詞彙？」 並繼續到 15-20 個。前期的廣度是循環的產品。 一個覆蓋了使用者剛剛輸入的詞彙的回話 2 來源添加， 是回話 1 的失敗。
三種提示類型 — 先提示，然後文字提示，然後句子提示
OpenCues 支援三種提示類型。提示是最有價值的技能輸出 — 它們承載使用者還不知道的實際知識 （事實、權衡、決策提示、陷阱）。文字提示 呈現使用者本來可以腦力激盪出的替代方案；提示 呈現他們無法得知的資訊。
輸出時的優先順序：
- 先提示。 對於每個你會提及的顯著術語，問： "我能給他們一個單行事實 / 陷阱 / 決策提示嗎？" 如果是 — 輸出一個提示。
- 僅在有多個使用者可能在之間循環的等效形式時才使用文字提示。 如果一個詞只有一個規範形式，就不用費心使用文字提示。
- 句子提示用於使用者正在創作的散文表面。
提示提示 — 關於某個術語的靜態單行知識，無需 LLM 呼叫
使用者輸入 webp，提示彈出：「WebP 在相同品質下給出比 JPEG 小約 30% 的檔案。」即時，無需往返。這是 OpenCues 提供的最有價值的單一表面。 每個使用者會從操作性知識中受益的術語 — 而不僅僅是同義詞 — 都值得一個提示。
文字提示 — 為突出顯示的字詞提供替代方案
預設的備用方案。使用者輸入 wedding，循環到 bridal。
- Yaml:
match: <regex>或keywords: <comma-list>，加上priority:。沒有scope:欄位（或scope: words）。 - 最適用於： 有多個大致等效形式的領域詞彙 — 語域、正式程度、專業術語。
- 對於你放入替代清單的每個術語，問：「這個術語也值得一個提示條目嗎？」 如果是 — 也添加提示。大多數技術 / 領域 / 專有名詞的替代方案應該伴隨一個解釋何時/為何選擇每個的提示。沒有提示的替代方案是沒有上下文的詞彙 — 只有一半的價值。
句子提示 — 以不同風格改寫整個句子
使用者寫了一個句子；提示提供三個改寫版本。
- Yaml:
scope: sentence，priority: 75–85，description: <一行>。沒有match:— 句子提示綁定到整個句子，而非字詞。 - 最適用於： 散文表面。任何使用者正在創作完整句子並且可能想要風格替代方案的地方 — 無論文件是否「散文密集」。技術文件中有散文區塊（端點摘要、欄位描述、手冊介紹）；合約中有散文區塊（序言）；代碼註釋是散文；電子郵件大多是散文。每個表面獨立決定，而非按文件類型決定。
提示提示 — 詳細說明（格式、分類法、內容類型）
- Yaml: 僅
name:（在來源資料夾或在 CUES.md 的## Tips主體內）。主體是一個 JSON 代碼區塊，包含[{id, words: {word: {tip, alts}}}]形狀。 - 最適用於： 提示是「這是你應該知道的」而非「這是同義詞」的術語 — 專有名詞、API、工具、平台名稱、技術原語、商業決策、管轄權怪癖。
- 提示內容類型 — 超越中立事實：
- 事實 — 「WebP 比 JPEG 節省約 30%。」
- 決策提示 — 「在寫定價之前，決定固定 vs 按小時 vs 按次 — 它會改變框架。」
- 陷阱 — 「Stripe 在新的帳戶上保留 7 天的款項。」
- 權衡 — 「為隱私移除 EXIF 或為藝術保留元數據。取決於受眾。」
- 參考 — 「見 cloudflarepages.com/docs 以了解限制。」 混合這些。一個純事實的提示包比混合包差。
每個表面的選擇規則
對於你會輸出的每個主題，問它涵蓋哪個表面 — 並且總是先檢查提示提示選項：
術語，使用者會從一行事實 / 權衡 / 決策提示 / 陷阱中受益 → 提示提示（偏好）
術語 + 有提示 AND 有多個等效形式 → 帶有 alts: 的提示提示
（給使用者兩者）
單一術語，有多個等效形式（沒有有用的提示） → 文字提示
使用者正在創作的散文（任何長度，任何文件） → 句子提示
否則 → 跳過
一個提示提示條目也可以攜帶 alts: {tip: "WebP saves ~30% over JPEG at same quality", alts: ["WebP", "webp"]} — 這給予使用者事實和一個替代的關鍵字來輸入，如果他們偏好那個。對於技術 / 領域 / 專有名詞術語，偏好這個。
檔案佈局（CUES.md）
檔案開始於一個 YAML 前置區塊，帶有 tracking:（純文字簡短說明任務名稱）、context:（觀察到的使用者目標和目前階段的簡短總結）、pivots:（0 或列表）。然後是每個提示來源的 ## <name> 區段，帶有 match:、priority: 和 description:。可選的 ## Tips 區段包含網狀形狀的提示資料。最後，一個不帶前置區塊或提示的 ## Sentences 區段包含句子提示。一個來源也可以有 ## <name> / ### tip 子區段來將提示放在它們所屬的來源旁邊。
輸出的 CUES.md 必須以一個空行結尾。