中文的「問題」一個詞對應英文的好幾個詞：question（等著被回答的問句）、problem（壞掉的元件或行為）、issue（要處理的事項）、topic（談論的主題），寫成「要解決的問題」時又常常指 requirement（需求）。英文的作者寫的當下就要從這幾個詞裡選一個，讀者因此知道是哪一種。中文同樣分得開——問句、故障、錯誤、事項、主題、需求都是現成的詞——只要寫的人把它寫出來。

AI 生成的技術文章特別常用「問題」配「回答」組織內容：「X 回答的問題是：……」「這一層問的是……」。這個框架把系統元件寫成回答問題的一方，在文章與一個假想的提問者之間造出一段應答，讀起來像在解釋，而讀者每遇到一次「問題」都要自己決定它是哪一種。

失效的形態

一篇服務端監控的教材以「每一層監控回答一個問題」組織全篇，正文出現「問題」51 次、「回答」21 次，段標是〈一層監控回答的問題與它的缺口〉。同一個詞在這篇裡至少承擔了四種所指：

  • 檢查的內容：「自檢回答的問題是：這個程序自己還能不能回應」。這裡的「問題」是健康檢查驗證的條件，英文會寫 what the health check verifies。
  • 故障：「服務正常運作時仍會出的問題」。這裡是 problem，指業務結果出錯、資料不一致、憑證到期這類失效。
  • 歸屬的範圍：「檢查要探到多深（……）是端點的設計問題」「告警送出之後沒有人回應時要轉給誰，是值班流程的問題」。這裡是 topic 或 concern，意思是「這件事屬於端點設計（值班流程）那個範圍」。
  • 分類的依據：「這一層與下一節應用層訊號的分界是問題」。這裡指兩層各自檢查的對象不同。

文章自創的術語「問題盲區」也建在這個框架上，於是同時帶著兩種讀法：觀察者沒有在問的問句（question），還是觀察者看不到的故障（problem）。文章的定義「它沒有在問的故障」把兩者接在一起，英文譯者在 question blind spot 與 problem blind spot 之間必須選一個。

框架詞落在槽位以外

#358 要求每一句的四個槽位（動作者、動詞、受詞、結果）填領域裡實際存在的實體。「自檢回答的問題是……」的動作者是自檢，動詞是「回答」，受詞是「問題」——健康檢查在領域裡做的事是定期執行一條指令或發一個請求、依結果把容器標成 healthy 或 unhealthy，沒有回答任何提問。動詞與受詞兩格填的都是框架的譬喻。

改寫時把譬喻換回領域裡的動作與對象：

自檢確認程序在自己的容器裡能回應：Docker 的 HEALTHCHECK 每隔一段時間在容器裡執行一條指令……

服務網路內的探測從另一個容器對各服務發 HTTP 請求或 TCP 連線，確認請求能到達服務並得到成功的回應。

其餘幾種所指各自寫成它是什麼：

  • 故障寫出哪個元件、什麼行為、在什麼條件下：「各層都正常時仍會發生的故障：業務結果出錯、資料與寫入時不一致、憑證到期……」
  • 歸屬寫出屬於哪個範圍：「檢查要探到多深，屬於健康檢查端點的設計，見……」
  • 需求寫出誰需要什麼、為什麼：「值班的人要在主機停掉時收到通知，所以心跳監看要放在失效域以外」。
  • 內容本身是一句問句時，寫出問句本身並標成問句（引號、問號，或「是否」），見 #372。

技術文件裡 request 另有固定的所指（HTTP 請求），這也是需求要寫成「需求」、不寫成「請求」的理由。

判斷問句

把這個「問題」翻成英文，要從 question、problem、issue、topic、requirement 裡選哪一個。 選得出來，就用那個意思的中文詞重寫，並把內容寫出來（哪裡壞了、處理什麼、屬於哪個範圍、誰需要什麼）；同一篇裡每一處選出的詞不一樣，代表一個詞承擔了多個所指；選不出來，代表那句話沒有決定它在講什麼。

把「回答」換成這個系統元件實際做的動作：執行、量測、比對、送出、標記。換不出來時，那一句描述的是框架，不是元件的行為。

合規的情形：場景裡有人實際提問（使用者問、審查者問、客服核對身分），業界固定的術語（「N+1 問題」「拜占庭將軍問題」），以及動詞片語「出問題」（泛指發生故障，與 #203 避免濫用泛用詞 的判讀相同，密集重複時才換成具體的詞）。

為什麼讀起來像解釋

應答框架的作用是製造期待：先擺出一個問句，讀者預期下一句是答案，注意力被拉住。這是口頭講解與對談的技巧，#254 把它歸在服務聽眾的演講姿態，#355 的「判定標準包裝成自問自答」是同一個裝置出現在判斷標準上的形態。讀者帶著自己要查的事進來讀教材，不需要文章再替他擺一個問句。

作者看不見這一類，因為作者知道每一處「問題」指的是什麼。同源的審查者也知道。這個框架還會往下游產生別的句型：內容句被寫成正反問句（#372），自創術語帶著兩種讀法（上面的「問題盲區」）。

偵測

框架詞有固定詞形：

1rg -n '回答的問題|回答的是|問的是|問題是：' <檔案或目錄>

全站 content/（不含 report/）量到「回答的問題」100 處、分佈在 74 個檔案，「問的是」133 處、84 個檔案；那篇監控教材一篇就有 11 處「回答的問題」，是全站最集中的一篇。命中後逐處走判斷問句。單獨的「問題」詞頻太高，不適合直接掃；從框架詞找到集中的文章之後，再在那一篇裡逐處翻譯。

同一類的其他詞：足夠性斷言裡的「撐」與評價謂語

「問題」佔著一個內容格，而沒有把內容填進去：讀者讀到它，要自己決定那是問句、故障、事項還是需求。同一類的詞還有兩種，修法相同——寫出它佔住的那個內容，換成同義詞不算修好：

  • 足夠性斷言裡的「撐」（撐得住、撐不起、扛不住、撐不久、會垮）：佔著需求與判斷標準的位置。「這個證據撐不住」沒說要支持哪個主張、需要什麼樣的證據；「單台資料庫撐得住這個流量」沒說是在什麼延遲門檻、多少請求量之下。改寫寫出需求、判斷標準與機制；換成「足以支持」仍然沒寫。先前把這一族歸成物理化錯配、理由是借用物理直覺，那是偵測的入口；修法要回到它省略了什麼，見 #234 的〈足夠性斷言要寫出需求、判斷標準與機制〉。
  • 正反問句裡的評價謂語（「對不對」「通不通」）：佔著判斷標準的位置，見 #372。

三者的判斷問句是同一個：這個詞佔住的位置，原本應該寫的是什麼；那個內容寫在句子裡了嗎。 「問題」要寫出所指，「撐」要寫出需求、判斷標準與機制，「對」要寫出照什麼標準。LLM 生成時三者都高頻，因為它們讓句子在內容還沒決定時就能寫完。

論述基礎與限制

本卡的證據是一篇文章的四種所指歸類（由主 session 逐處判讀、只舉例不逐一計數）、全站框架詞的詞頻，以及使用者的指認：在 AI 寫作中「問題」與「回答」被用來製造應答的對話情境，而中文與英文一樣能把需求、故障、事項、主題分開寫。「AI 生成的文章特別常用」這一點沒有和人寫的文章對照過；詞頻只說明這個框架在本站常見，不說明每一處都違規。

跟其他抽象層原則的關係

判讀徵兆

  • 文章的組織句是「X 回答的問題是」「這一層問的是」，系統元件被寫成回答問題的一方。
  • 同一篇裡的「問題」翻成英文時要選不同的詞。
  • 自創術語裡含有「問題」，而它的定義同時用到「問」與「故障」。

Case

2026-10-14，服務端監控分層的教材在多輪審查期間，使用者指出「自檢回答的問題是」「一層監控回答的問題與它的缺口」「服務網路內的探測回答的問題是」是 AI 寫作習慣用「問題」與「回答」製造應答的對話情境，而文章應該審慎用詞：request、issue、problem 不一樣，句子要明確寫出需求是什麼、為什麼有這個需求、哪裡壞了是什麼 bug、要處理的事項與主題是什麼，這在中文裡與英文一樣可以正常區分，只要好好描述，而不是都用「問題」代替。