正反問句（「能不能」「連不連得到」「對不對」「有沒有」這類 A 不 A 形式）在中文裡是問句。它被寫進一個句子裡，當主語、受詞或介系詞的受詞時，承擔的是英文 whether 子句的角色：一整段「某件事成不成立」被當成一個名詞來談。英文的 whether 放在子句最前面，讀者一開始就知道後面整段是一個名詞；中文的正反問句沒有開頭標記，問句的形式出現在子句中間的動詞位置，讀者讀到那裡才知道前面那段是一個問題，再回頭把它重新歸類。

這一類的判讀分兩件事，彼此獨立：正反問句在句子裡的位置，以及它的謂語是否寫出判斷標準。

失效的形態

一篇服務端監控的教材描述容器健康檢查的盲區：

自檢的問題盲區是程序以外的路徑：它在程序所在的容器裡測，別的容器連不連得到它、入口的路由對不對都不在它的問題裡，由服務網路內的探測接手。

這一句的讀者要做四件事才還原得出命題：

  • 兩段正反問句並列在主語位置。「別的容器連不連得到它」「入口的路由對不對」並列起來，是「都不在它的問題裡」的主語，讀者讀到「都不在」才知道前面兩段是主語。
  • 「連」先被讀成「連……都」。句子前段出現「連」、後段出現「都」，讀者先套進「連 X 都 Y」（even X … Y）這個高頻句型，套不進去才退回來重讀。
  • 「對不對」先被讀成附加問句。「對不對？」是口語裡最常見的附加問句（right?），「入口的路由對不對」第一眼像「入口的路由，對吧」。
  • 一句話裡三個「它」指兩個對象。「它在程序所在的容器裡測」的「它」是自檢，「連得到它」的「它」是被監控的程序，「它的問題裡」又回到自檢。

同一篇裡還有正反問句坐在介系詞後面的形態：「讓 Prometheus 讀 Gatus 的指標，再對讀不讀得到它寫一條規則」。「對」在這裡是介系詞，而它後面接的是一整段問句，「對」本身又有「正確」的意思，和形容詞的「對不對」撞在一起。

改寫的方向是把被檢查的那件事寫成直述，或用「是否」「能否」：

自檢只確認程序在自己的容器裡能回應；請求能否從別的容器到達程序、入口 Nginx 是否把請求轉到正確的服務，自檢都不檢查，由服務網路內的探測接手。

「是否」「能否」放在它所標記的那段內容前面，作用接近 whether：讀者在子句開頭就知道接下來是一個「成不成立」的問句。

位置判讀

同一篇文章有十五處正反問句，按位置分成四組，各組的讀者負擔不同。

放在「問」「檢查」「確認」「判斷」這類動詞後面當受詞（「讀取缺口問的是有沒有人知道」「再寫一條規則問它有沒有出現」）——中文語法本來就給這類動詞留了接問句的位置，讀者讀到「問」就預期後面是問句。這一組五處，讀起來自然。

用「」標成引語（容器的健康檢查回答「這個程序自己的端點回不回應」）——引號告訴讀者這是一句被引出來的直接問句，而不是句子成分。這一組三處。

放在「X 回答的問題是：」後面、沒有引號也沒有問號（「自檢回答的問題是：這個程序自己還能不能回應」「服務網路內的探測回答的問題是：從服務的程序以外發請求，打不打得通」）——冒號後面那段沒有標記成問句，讀者先把它當直述句讀，讀到正反問的動詞再改。這一組三處，修法是加「」與問號，或改用「是否」。

放在主語位置、介系詞後面，或多段並列——「別的容器連不連得到它、入口的路由對不對都不在……」與「對讀不讀得到它寫一條規則」。這一組四處，負擔最重：主語位置沒有任何前導動詞預告問句，介系詞「對」與並列的「都」又各自撞上高頻句型。

位置判讀的問句是：「讀者讀到這段正反問句之前，有沒有一個詞（『問』『檢查』、引號、問號、『是否』）告訴他接下來是一個問題？」 有，就留；沒有，就改成直述或「是否」。

謂語要寫出判斷標準

正反問句還讓作者不必寫出判斷標準，這一點與位置無關。「入口的路由對不對」的「對」是照什麼算對，「打不打得通」的「通」是請求、封包還是連線到達了哪裡，句子都沒寫。中文接受「對不對」作為一個完整的問句，所以作者寫的當下不覺得少了什麼。

翻成英文時這一格被強制填上。「入口的路由對不對」譯成英文要決定是 whether the ingress routes requests to the right service 還是 whether the ingress route configuration is valid，兩者檢查的對象不同：前者要發一個請求看它落在哪個服務，後者讀設定檔就能判斷。原文沒有決定，讀者各自補一個。這是 #286 的翻譯探針能量到的那一層——中文允許不決定的語法項，英文強制決定。

判斷問句：「把正反問句的謂語（對、通、到、行）單獨拿出來，讀者說不說得出它是照什麼標準判斷的？」 說不出來，改寫時把標準寫進去（「是否把請求轉到正確的服務」「請求能否到達程序」）。這一條在每個位置都適用，包括讀起來自然的「檢查」受詞位置：「門檻還對不對得上基線」寫出了標準（基線）；「拿到的回應對不對」沒有寫，回應要跟什麼比對才算對（狀態碼、內容、轉址目標）留給讀者補。

成因：文章的框架詞把內容寫成問句

這篇文章的組織框架是「每一層監控回答一個問題」，盲區的名字也從這裡來（「問題盲區」是一層沒有在問的故障）。框架把每個觀察者擬人化成發問的一方，於是作者每次描述一個觀察者檢查什麼，就引一句問句當內容，正反問句的密度跟著框架走。

這個框架本身另有一個缺陷：「問題」一個詞同時指檢查的內容、故障、歸屬的範圍，「回答」不是健康檢查在領域裡做的動作，見 #374。就本卡的範圍，修法是內容句用直述寫出這個觀察者檢查什麼（「自檢確認程序在容器裡能回應」），真的要保留問句形式時加引號與問號。

偵測

正反問句有固定詞形，可以掃：

1# 需要 PCRE2：(\p{Han})不\1 抓 A 不 A，有沒有另外列
2rg --pcre2 -n '(\p{Han})不\1|有沒有' <檔案>

命中是候選，判定走位置判讀與判斷標準兩個問句：正反問句前面是否有前導標記，謂語是否寫出判斷標準。「問」「檢查」後面的受詞、引號內的引語是多數，掃完多半只剩少數幾處要改。這條 pattern 抓不到不用「不」的問句形式（「是否」本身合規，「X 嗎」夾在句中是另一種形態，例如「使用者從外面連得到服務嗎、拿到的回應對不對」把兩種問句並列在同一個冒號後面）。

這一類的缺陷作者自己看不見：寫的人知道每個「它」指誰、「對」照什麼標準，讀起來是通順的。同源的審查者也一樣。讀者端的訊號是「說不出哪裡怪，但中文不會這樣說」或「翻成英文才發現原文沒講清楚」；翻成英文的那一種訊號，可以用翻譯探針系統性地重現。

論述基礎與限制

本卡的證據是一篇文章、一位讀者的指認，以及主 session 對同篇十五處正反問句的位置分類。依位置分組的負擔排序是從語法機制推出來的，還沒有用理解探針或翻譯探針量過；「連……都」與附加問句兩種撞形，是從這一句的實際讀法歸納，還不知道它們在其他文章裡的頻率。全站 content/（不含 report/）有三千多行命中上面那條 pattern，位置沒有分類，所以這個數字只說明形態常見，不說明違規多少。

寫這張卡與 #373 的初稿時，用本卡的 pattern 掃自己，兩張卡加上 _index.md 的篇目共七處正反問句坐在沒有前導標記的位置（「判讀分兩件事，彼此獨立：正反問句坐在句子的哪個位置，以及它的謂語有沒有寫出判斷標準」「所以一句排比有沒有內容，要看每一個子句的變動格填了什麼」），而且都寫在分析這個形態的段落裡。寫的人正在分析這一類，同一段就寫出同一類；這一條要靠掃描，不能靠寫的人記得。

跟其他抽象層原則的關係

判讀徵兆

  • 讀者說「看得懂，但中文不會這樣說」，而那一句有正反問句坐在主語或介系詞後面。
  • 一句裡有兩段以上的正反問句並列，後面接「都」。
  • 正反問句的謂語是「對」「通」「行」這類評價詞，句子沒寫照什麼標準。
  • 文章的組織框架是「X 回答什麼問題」，而正反問句的密度明顯高於同分類的其他文章。

Case

2026-10-14，服務端監控分層的教材在多輪審查期間，使用者讀到「別的容器連不連得到它、入口的路由對不對都不在它的問題裡」，指出「這裡有一種文法但是我說不出是哪裡怪，但是中文不會這樣說」，並以英文對照說明同一個意思在英文裡可以寫得乾淨清楚、中文卻拗口；同篇的「打不打得通」「這個程序自己還能不能回應」是同一類。