Codex 的常見問題
Codex 一個常見的問題是傾向於使用定義鬆散的詞彙來設計或實作。根據我的經驗，這個問題在 Claude 上稍微少見一些，但在 Codex 上，它在 5.5 版本中是個問題，並且在 5.6 版本中仍然存在。這是一個針對該問題的應對措施。
例如，一份研究報告的某個章節有一個標題叫做「壓縮點」。閱讀內文時，這個詞彙在三種意思之間搖擺不定：「當對話歷史達到設定數量時」、「開始自動摘要的門檻」，以及「摘要實際開始進行的時刻」。文章寫得很流暢，看起來像是技術說明。然而，當一個單詞同時作為起始條件、一個數值和一個事件時，說明的對象就變得不明確了。結果，研究發現不幸地被導向了錯誤的方向。
受到這次失敗的啟發，我建立了一個名為 semantic-generation 的技能。雖然這個名字聽起來像是一種文字生成技術，但我實際上改變的是在撰寫文字之前對詞彙的定義。
問題的結構與影響
「壓縮點」這個日文詞彙本身就存在含義不清的問題，但當 Codex 被指出這點時，它首先試圖將其修正為解釋不足的問題，然後是標題表達的問題。它並沒有立即意識到自己混淆了起始條件和執行事件。
在同一次對話中，也發生了類似的事情。由於原因尚不清楚，計畫是進行測試，從結果中隔離出原因，然後選擇應對措施。Codex 將此總結為「將觀察結果匯總為一」。
匯總的目標並非觀察結果本身，而是從測試中獲得的數值或記錄。此外，收集數值並非目標，而是隔離原因的手段。
將其濃縮成一個簡短的詞語後，以下順序就消失了：
- 原因尚不清楚。
- 進行測試。
- 從結果中隔離出原因。
- 隔離後選擇應對措施。
「將觀察結果匯總為一」看起來合理。因為它看起來合理，所以掩蓋了未組織好的部分，並成為後續設計的前提。
原始詞彙的修正列表無法阻止它
在考慮改進時，有人提議記錄修正過的詞彙與其含義之間的對應關係，並將其帶入下一次對話。
我想要阻止的，不是「再次使用先前錯誤的詞彙」。而是在目標不明確時先放上一個詞彙，然後基於該詞彙進行思考。即使你建立了一個錯誤詞彙的清單，下次也會產生一個不同的新造詞。
因此，我改變了策略，不是記錄修正後的詞彙，而是在每次對話開始時，在建立原始詞彙之前，先建立候選詞彙列表。
應對措施) 強制在設計之前建立候選詞彙列表
我決定讓 AI 先為獨特定義的詞彙建立一個對應表，然後在載入該檔案後再進行設計。
對應表包含以下七個欄位：
- 來源
- 目的
- 具體對象
- 角色
- 上下文
- 候選詞彙
- 初始定義
欄位的順序很重要。候選詞彙在最右邊，在寫出具體對象和角色之前無法填寫。
如果候選詞彙在最左邊，就可以先寫下「壓縮點」這個詞，然後再建立符合該詞的解釋。這只會在表格內重現我想要阻止的生成順序。
角色也放在每一行中。如果你想用同一個詞來處理起始條件和事件，就將行分開。然後，在「用一個詞搞定」的壓力出現之前，正在處理兩個對象的事實就會變得可見。
透過這種方式，生成式 AI 本身可以在詞彙變得不明確時注意到，並且我能夠主動禁止在詞彙仍不明確時使用它們。
總結
生成式 AI 不擅長讓空白保持空白。即使目標或目的尚未確定，只要放上一個看似合理的詞彙，它就能繼續撰寫文字。這種流暢性在設計中可能很危險。
semantic-generation 不是一個用來尋找好詞彙的技能。它是一個讓 AI 在嘗試使用原始詞彙時暫停一下，並選擇合適詞彙的技能。
目標是什麼？是條件、狀態還是事件？為了什麼目的處理它，以及什麼之後會發生什麼？
只有對於那些已經寫到這個程度的行，我們才會在最後賦予一個名稱。乍看之下，這似乎是繞了遠路，但比起從像「壓縮點」這樣的一個詞彙就重建整個設計，這條路更短。
semantic-generation 技能
1---2name: semantic-generation3description: |4 一種生成程序，在撰寫目標文件（設計資料、從需求出發的設計、研究報告、原因隔離計畫、對策計畫、命名、推理順序摘要）之前，先提交一個對應表（指涉表）作為獨立的交付物，以在詞彙之前固定指涉對象和角色。5 觸發條件：撰寫設計資料、建立設計文件、撰寫研究報告、撰寫對策計畫、命名、決定狀態名稱/條件名稱/類型名稱/方法名稱、總結推理順序、指涉表、對應表。6 請勿觸發：引用使用者原文、簡單的機械性編輯、重複使用現有名稱、固定輸出、閒聊、僅使用既定術語即可撰寫的簡短句子。7---89# semantic-generation — 在詞彙之前固定目標的程序1011如果在目標不明確時先放上一個詞彙（通常是當場新造的詞），然後基於該詞彙進行思考，那麼與指涉對象的偏差會未經修正地傳播到日文句子、設計句子和程式碼識別碼中。此技能強制執行「先獨立提交對應表，再將其副本作為正文撰寫」的順序。12紀律的標準由 [[referent-before-label]] 規則持有。1314## 適用標準1516在符合以下任一條件時使用。如果無法判斷，則視為適用。17181. 撰寫設計資料、從需求出發的設計、研究報告、原因隔離計畫或對策計畫。192. 命名（公開規格、狀態名稱、條件名稱、事件名稱、數值或記錄的類型名稱、方法名稱、布林名稱）。203. 嘗試將使用者提供的推理順序總結為簡短的工作標籤。2122## 正常流程2324### 1. 先將對應表儲存為獨立的交付物（兩階段提交）2526在撰寫正文的任何一個字之前，先將對應表儲存為一個獨立的檔案。2728- 儲存位置：工作目錄中的 `referent-table-<slug>.md`（如果交付物在 `output/` 下，則放在同一目錄中）。29- 儲存後記錄 sha256（例如，`shasum -a 256 <path>`）。此記錄成為「對應表是在正文之前建立的」證據。僅將表格放在完成文件的最前面並不能證明生成順序。3031### 2. 對應表的格式（禁止變更欄位順序）3233| 來源 | 目的 | 具體對象 | 角色 | 上下文 | 候選詞彙 | 初始定義 |3435- **候選詞彙固定在最右邊。在填寫具體對象和角色之前，保持候選詞彙欄位為空白。** 這是為了透過格式，使得「先決定詞彙，再附加目標」的順序無法實現。36- 從封閉選項中選擇角色：`起始條件 / 狀態 / 事件 / 數值 / 記錄 / 目的 / 手段`。如果同一個詞彙指涉多個角色，則將行分開。37- 在「上下文」中，使用使用者原文中的詞彙來寫出推理順序（例如，測試 → 隔離 → 對策）。不要與角色欄位混用。38- 表格通常限制在 1 到 6 行。如果超過，則在含義變化的邊界處分割表格。39- 完成後，確認即使隱藏了候選詞彙欄位，僅從「具體對象」欄位也能清楚理解其含義。4041### 3. 填寫候選詞彙4243- 優先使用使用者術語和既定術語。44- 在放置其他新詞彙時，在「初始定義」欄位中寫下「X 指的是...」。不要引入無法寫出定義的詞彙；直接使用具體對象的描述作為正文。4546### 4. 將正文作為對應表的副本來撰寫4748- 僅使用對應表中列出的詞彙作為正文的核心詞彙。49- 在日文句子、設計元素和程式碼識別碼這三個層級中保持相同的對應關係（例如，「歷史記錄量達到 250K」= 起始條件 → 條件名稱 / 「自動摘要開始」= 事件 → 事件名稱/方法名稱 / 「自動摘要進行中」= 狀態 → 狀態名稱。不同的角色應該有不同的名稱）。50- 不要將工作標籤（省略目的、目標和判斷的抽象名詞片語）用於框架或標題。如果你想使用一個，嘗試在表格中寫出該片語的指涉對象；如果做不到，就用具體的句子來寫。5152## 問題發生時的初步行動5354- 如果你發現自己開始撰寫正文而未提交對應表，請不要繼續並在之後添加表格。丟棄正文，重新獨立提交對應表，然後重新生成正文。55- 如果被指出表格中的一行不正確（指涉對象或角色的混淆），不要添加解釋；重寫相關行，然後重新生成正文的相應部分。56- 在無法載入此技能的環境中，在開始正文之前，先將一個至少有 6 個欄位（來源、目的、具體對象、角色、上下文、候選詞彙）的表格儲存為獨立的檔案。5758## 備註5960- 請勿在此技能的正文中包含用於驗證的測試輸入或預期答案（以保持驗證的獨立性。測試在單獨目錄的 fixtures 中管理）。61- 目標不是與錯誤術語列表進行比對。比對的目標是「文件本身宣告的對應表」。
referent-before-label 規則
1# 在詞彙之前固定指涉對象23<!-- codex-runtime-summary -->4- 重要：對於目標文件（設計句子、研究報告、對策計畫、命名、推理順序摘要），請在獨立提交對應表後再撰寫正文。禁止在沒有對應表的情況下提交正文。如果你在沒有表格的情況下開始寫作，請丟棄正文並從對應表重新開始。5- 重要：不要將工作標籤（將未組織的工作包裹在抽象名詞中的片語）用於框架或標題。除非你能寫出初始定義，否則不要引入新詞彙或新造詞；將目標分解為具體的描述。6- 重要：在開始撰寫目標文件時觸發 semantic-generation 技能。即使無法使用該技能，也請先將一個至少有 6 個欄位（來源、目的、具體對象、角色、上下文、候選詞彙）的對應表儲存為獨立的交付物。7<!-- /codex-runtime-summary -->89如果在目標不明確時先放上一個詞彙（通常是當場新造的詞），然後基於該詞彙進行思考，那麼與指涉對象的偏差會未經修正地傳播到設計句子、狀態名稱、條件名稱、方法名稱和類型名稱中（如 TASK-52 中的「壓縮點」和「將觀察結果匯總為一」範例）。此規則會阻止此生成過程本身。與錯誤術語列表進行比對（詞彙狩獵）並非應對措施，因為新造詞是無法列舉的。詞彙波動的標準由 [[terminology]] 持有，而此規則持有「在放置詞彙之前的程序」。1011## 範圍（目標文件）1213僅適用於符合以下任一條件的任務。如果無法判斷，則適用。14151. 撰寫設計資料、從需求出發的設計、研究報告、原因隔離計畫或對策計畫。162. 命名（公開規格、狀態名稱、條件名稱、事件名稱、數值或記錄的類型名稱、方法名稱、布林名稱）。173. 嘗試將使用者提供的推理順序總結為簡短的工作標籤。1819不適用於引用使用者原文、簡單的機械性編輯、重複使用現有名稱、固定輸出、閒聊，或僅使用既定術語即可撰寫的簡短句子。2021## 持續應用（3 項禁止）2223- 重要：在目標文件中，未獨立提交對應表（指涉表）之前，不要提交正文。對應表必須先儲存在一個與正文分離的檔案或對話輪次中，然後才撰寫正文（僅將表格放在完成文件的最前面並不能證明它是「先製作的」）。24- 重要：不要將工作標籤用於框架、標題或結論。工作標籤指的是將未組織的工作包裹在沒有目的、目標或判斷的抽象名詞中的片語（例如，「總結觀察結果」）。如果你想使用一個，嘗試在對應表中寫出該片語所指涉的目標；如果做不到，請丟棄該片語並用具體的句子來寫。25- 重要：在引入使用者術語或既定術語之外的新詞彙時，請在首次出現時寫下定義句子「X 指的是...」。不要引入無法寫出定義句子的詞彙；直接用句子寫出目標。2627## 正常流程28291. 判斷是否屬於目標文件（如果有疑問，則視為適用）。302. 觸發 [[semantic-generation]] 技能，並先將對應表儲存為獨立的交付物。313. 僅使用對應表中列出的詞彙作為核心詞彙來撰寫正文，在日文句子、設計元素和程式碼識別碼之間保持相同的對應關係。3233## 問題發生時的初步行動3435- 如果你發現自己開始為目標文件撰寫正文而未提交對應表，請不要繼續並在之後添加表格。丟棄正文，重新獨立提交對應表，然後重新生成正文。36- 在無法使用該技能的環境中，在開始正文之前，先將一個至少有 6 個欄位（來源、目的、具體對象、角色、上下文、候選詞彙）的對應表儲存為工作目錄中的獨立檔案。
