維基百科討論:過濾器助理

賦予過濾器助理修改濫用過濾器權限

注意到防濫用過濾器錯誤報告和防濫用過濾器請求積壓，管理員及行政員負擔較重，導致部分請求無法及時處理，這降低了過濾器阻止破壞的能力，亦增加了社群維護其的難度。因此，謹提議授予過濾器助理修改權限，協助管理濫用過濾器，尚祈社群商議為荷。Iming 彼女の愛は、甘くて痛い。 2024年12月28日 (六) 03:12 (UTC)

---

注意到防濫用過濾器錯誤報告和防濫用過濾器請求積壓，管理員及行政員負擔較重，導致部分請求無法及時處理，這降低了過濾器阻止破壞的能力，亦增加了社群維護其的難度。因此，謹提議授予過濾器助理修改權限，協助管理濫用過濾器，尚祈社群商議為荷。

現行條文 權限總覽 對比起一般使用者，過濾器助理可以： 檢視標記為非公開的濫用過濾器日誌項目（abusefilter-log-private） 檢視標記為非公開的防濫用過濾器（abusefilter-view-private） 啟用雙因素驗證（oathauth-enable） 允許移除自己帳號的用戶組

提議條文 權限總覽 對比起一般使用者，過濾器助理可以： 檢視標記為非公開的濫用過濾器日誌項目（abusefilter-log-private） 檢視標記為非公開的防濫用過濾器（abusefilter-view-private） 啟用雙因素驗證（oathauth-enable） 建立或修改防濫用過濾器（abusefilter-modify） 修改防濫用過濾器使用已限制的動作（abusefilter-modify-restricted） 允許移除自己帳號的用戶組

此外，亦請參見二年前之增設過濾器編輯員討論。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月5日 (四) 16:00 (UTC)

已知獲權者皆熟悉過濾器和正則表達式，並考慮到目前的積壓，(＋)支持本提案。不過，可能不應當授予abusefilter-modify-restricted權限，該權限實質上允許過濾器助理進行封禁這一管理動作。--Iming 彼女の愛は、甘くて痛い。 2024年12月5日 (四) 16:27 (UTC)

另可以增加限制：「僅在社群有明確共識時，過濾器助理才可以新建過濾器。」--Iming 彼女の愛は、甘くて痛い。 2024年12月5日 (四) 16:34 (UTC)

關於這個限制，需規定在 WP:AFR/可靠來源佈告版 達成的共識才算數，實行沒有共識的動作有機會遭除權。

BTW, 現在已經有GPT，有沒有wiki人願意付那20美金/690台幣一個月，建立GPT BOT,餵他關於wiki獨有的正則表達式技術文件及實行內容，建立或修改防濫用過濾器應該沒什麼難度^{[開玩笑的]}。--唔好阻住我愛國（留言） 2024年12月5日 (四) 16:47 (UTC)

贊成您的觀點，我補充一下：「僅在社群有明確共識時，過濾器助理才可以新建過濾器。如過濾器助理未經社群討論並取得明確共識便自行設置過濾器，則不論過濾器性質為何，皆屬違規，管理員可自行決定是否除權或給予警告，社群成員如有發現也可至布告板舉報。」--Iming 彼女の愛は、甘くて痛い。 2024年12月5日 (四) 16:54 (UTC)

布—>佈--唔好阻住我愛國（留言） 2024年12月5日 (四) 17:23 (UTC)

@HK5201314 布—>佈，考慮使用-{}-避免自動轉換——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月5日 (四) 21:23 (UTC)

雖然但是，請不要這麼做，除非你只是懶但有辦法自行檢驗GPT寫的到底合不合理--SunAfterRain 2024年12月13日 (五) 19:56 (UTC)

這個限制可能比較雞肋，先是過濾器規則裡面加個或條件就能在不創建新過濾器的情況下幾乎達到新過濾器的功能，再是如果A過濾器本身是阻止，沒有對應的警告過濾器，如果過濾器助理認為有必要拆分出僅警告的過濾器，還得走流程，也會變相積壓。不如要求「依據常識判斷，不合理的過濾器更動應被警告或除權」。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月6日 (五) 01:59 (UTC)

我覺得可以，您書的對。--Iming 彼女の愛は、甘くて痛い。 2024年12月6日 (五) 02:36 (UTC)

(－)反對：設立過濾器助理的原意是為了查看過濾器的詳細資訊，而非編輯過濾器。儘管資格要求中「建議」申請人對正規表達式以及應對過濾器有基本認識，但此項並非必須。個人認為應另設新權限組，而非沿有過濾器助理此原有權限。謝謝。--SCP-0000（留言） 2024年12月22日 (日) 03:24 (UTC)

@ZhaoFJx、Iming。@SCP-2000：我個人會關注現時實際上有多少個不具備對正規表達式與過濾器本身的基本認識的過濾器助理，如果沒有的話，那你説的這點可以通過把資格要求中的「建議」改為硬性要求來處理。亲，我簽名那刻的時間是 2024年12月22日 (日) 03:57 (UTC)

可以改為強制性要求，本來看不懂過濾器要AFH就沒什麼作用，日誌rollbacker還是可以看（rollbacker有abusefilter-log-private權）。出於緩解積壓的考慮，現行方案我認為是最優解，還請您再考慮改「申請人對正規表達式以及應對過濾器有基本認識」為強制性要求後授予AFH修改濫用過濾器權限的可行性。多謝。--Iming 彼女の愛は、甘くて痛い。 2024年12月22日 (日) 06:49 (UTC)

@Sanmosa、Iming： 抱歉忘了這討論。簡單而言，個人認同對於編輯過濾器之權限，「對正規表達式以及應對過濾器有基本認識」應為強制性要求，然而此舉只會對現時持有者及反破壞工作帶來干擾。為了避免帶來不必要的影響，應考慮另外建立新權限組，而非沿用現有權限組。

具體而言，其一，現時有部分過濾器助理主要因反破壞或其他需要（如維護機器人）而申請此權限（參見2023、2024年存檔），以便查看過濾器日誌等，如果未來此權限的申請要求改為「對正規表達式以及應對過濾器有基本認識」，部分人可能因缺乏對正規表達式等技術的理解，不能申請此權限，某程度上影響了反破壞以及其他工作。

其二，正如上述所言，設立過濾器助理的原意是為了查看過濾器的詳細資訊，而非編輯過濾器。當時的申請只判斷申請者的能力及受信任程度，是否合適持有「查看」過濾器詳細資訊，而非「編輯」過濾器。現實上，現在不可能每個過濾器助理有足夠能力及信任程度擁有「編輯」過濾器權限，我們也不可能就憑表面印象而知曉誰有否能力，那唯有每位過濾器助理需重新申請此權限，無疑是擾民之舉。

當然，社群可以選擇不調整要求，但編輯過濾器之權限為相當「敏感」，稍有錯誤便會影響眾多用戶，且事實上跟管理員權限無異（皆可保護及封禁），故不調整要求並非明智之舉。無論是英維有兩個不同權限組（分別為查看及編輯過濾器），以至本站過去亦有相關討論，本身本站權限組也不少及不差多一個權限組，個人不太理解為何沿用現有權限組，而非另外建立新權限組。謝謝。--SCP-0000（留言） 2025年1月5日 (日) 16:27 (UTC)

WP:帽子收集狂。Sanmosa _蘭絮 2025年1月5日 (日) 23:59 (UTC)

至少應該禁止利用過濾器實現條目保護、帳戶封禁、編輯禁制之類一般認為是管理員權限範圍的操作。--Tiger（留言） 2024年12月22日 (日) 06:40 (UTC)

前面那個可以寫進修正案里，後面兩個AFH技術上就做不到（沒有abusefilter-modify-restricted權）--Iming 彼女の愛は、甘くて痛い。 2024年12月22日 (日) 06:43 (UTC)

「disallow」在 $wgAbuseFilterActionRestrictions 里嗎？不在的話，寫一個 user_name == 某人 然後設置阻止就和封禁沒差別了吧。當然我的意思是廣義上的不可以做這種事情，而不只是列出幾種。或者說，這個討論缺失了這個部分，討論的時候至少要意識到這種問題。--Tiger（留言） 2024年12月22日 (日) 07:54 (UTC)

見草案一，AFH有權修改過濾器的情況僅包含「按照社群共識創建過濾器或根據相關討論分拆過濾器」和「可以按照錯誤報告修復過濾器」，前者如果有禁止某用戶編輯這類的討論我想應該無法達成共識，後者修復過濾器不太可能涉及到這類操作（至少現在的過濾器還沒有）。如果確認到AFH濫用權限做到類似封禁用戶的操作，管理員可以直接撤銷權限。所以雖然技術上不能直接阻止這類編輯，但是在AFH高度可信的前提下，我覺得應該還是在可控範圍的，無需對這類操作過度擔憂。--Iming 彼女の愛は、甘くて痛い。 2024年12月22日 (日) 08:02 (UTC)

草案

草案 #1

提議條文 權限總覽 對比起一般使用者，過濾器助理可以： 檢視標記為非公開的濫用過濾器日誌項目（abusefilter-log-private） 檢視標記為非公開的防濫用過濾器（abusefilter-view-private） 啟用雙因素驗證（oathauth-enable） 建立或修改防濫用過濾器（abusefilter-modify） 允許移除自己帳號的用戶組

Iming指出，過濾器助理不應包含「修改包含受限動作的濫用過濾器」一權。根據濫用過濾器文檔和之前討論，過濾器助理將……

1. 可以按照社群共識創建過濾器；
   1. 可以按照社群共識創建過濾器或根據相關討論分拆過濾器；
2. 可以按照錯誤報告修復過濾器；
3. 不能創建或修改包含「撤銷用戶的自動確認狀態」、「封禁進行編輯的用戶和/或IP位址」兩類操作的過濾編輯器。

——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月5日 (四) 22:02 (UTC)

參考上方Hotaru Natsumi君，第一條或可以改為「可以按照社群共識創建過濾器或根據相關討論分拆過濾器；」--Iming 彼女の愛は、甘くて痛い。 2024年12月6日 (五) 16:25 (UTC)

已添加——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月6日 (五) 16:49 (UTC)

修改申請標準和流程

撤回：

提案人 撤回提案。Sanmosa _蚌埠 2024年12月17日 (二) 08:50 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

在站外收到了一些意見，有些意見指出由於賦予編輯權，應當適當拔高AFH的申請標準。因而，本人參考WP:IPBEG、WP:BAG和WP:SPI/C，草擬了一份提案，尚祈社群商議為荷。

現行條文 申請程序 如果您有意申請過濾器助理的權限，請親自到Wikipedia:權限申請/申請過濾器助理權限申請，或接受其他用戶於該頁發起的提名。 以下使用者不需要去申請或是為他們增加本權限，他們本身已經獲自動授予同等的權限： 管理員

提議條文 申請程序 符合申請過濾器助理要求者，可循一般程序，在權限申請頁申請成為過濾器助理。 提出申請後，具有管理員、回退員或過濾器助理權限的用戶可以提出問題，並自行按其認知支持或反對申請，惟須附上有效理由。在申請人明顯不符合條件的情況下，一名管理員或過濾器助理可以快速關閉此申請。申請以七日為限，七日後如總有效票數大於等於四票，且滿足以下條件符合以下條件，則一名管理員或過濾器助理可以結案並授予過濾器助理權限： 支持率在50%以上； 社群就授予權限達成合意； 沒有管理員或過濾器助理反對。 或： 有效票數大於等於四票； 支持率在80%以上； 沒有管理員反對。

以上。Iming 彼女の愛は、甘くて痛い。 2024年12月6日 (五) 12:45 (UTC)

基於程序公義，煩請閣下透露相關意見是在哪個外站及哪個人發表，謝謝！--唔好阻住我愛國（留言） 2024年12月6日 (五) 12:50 (UTC)

似乎這不涉及程序正義？另相關建議在我的私人群組中提出，當事人信息屬隱私，恕不能公開。如果您一定需要的話，請理解成是我的想法。如有帶來困擾，還請諒解，感謝。--Iming 彼女の愛は、甘くて痛い。 2024年12月6日 (五) 12:55 (UTC)

這可能有些打破RFR邏輯？當前RFR的邏輯應該類似於申請人提出申請，其他人有疑問則提出，管理員依據疑問及其處理完成授權與否的判斷，不是簡單投票。這種要求支持率的是RFA而非RFR。而且RFR很少能出現「有效票數」≥4的情況。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:44 (UTC)

因為有些意見指出由於賦予編輯權，應當適當拔高AFH的申請標準，因而我參考IPBEG和BAG的申請流程，寫了這麼個東西，本身最主要的作用是讓有能力判斷是否適合擔任AFH的人參與最終決定。如果您真的覺得這樣不合適的話，那麼取消無過濾器助理反對情況下的有效票數和支持率限制如何？而且我相信管理員在賦權時也會參考社群意見，對於明顯無法達成合意的討論會直接忽視。--Iming 彼女の愛は、甘くて痛い。 2024年12月10日 (二) 02:07 (UTC)

個人感覺還是使用原來的RFR程序即可，高標準應該是高准入，而不是複雜化和量化的申請流程。但是現行AFH的准入標準已經足夠高，申請人不是回退員、他站可信用戶、基金會成員的情況下，本身就需要社群討論是否准入，而即便是門檻相對低的回退員也要求活躍於反破壞；此外通用的全域1000編輯數限制也不見得低。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月16日 (一) 09:13 (UTC)

現在申請IPBEG已經明文要求大於四票了 囧rz……，不過80%尚不清楚會不會太高，就先觀望一下，看實操結果如何。--$\int$（☎）dt 2024年12月14日 (六) 04:10 (UTC)

IPBEG的權限實際上是在讓IP封禁對特定用戶廣泛失效，進而讓用戶查核失效，權限可以算敏感，畢竟這樣會查不出傀儡，影響反破壞和站務，但是僅是AF的編輯權很難說敏感，AF的編輯歷史只要能看AF就能看到，這樣AFH加了個比如禁止所有編輯的規則，管理員馬上可以以濫權撤權並封禁，這種明面上的權限至少不能和IPBEG相提並論。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月16日 (一) 09:13 (UTC)

---

根據先前討論，考慮到部分社群成員對AFH是否適合擁有此權限不信任，本人動議試行草案一和「修改申請標準和流程」兩案一年，以觀後效。考慮到草案一和「修改申請標準和流程」兩案無有效反對，擬三日後公示，還請各位提出意見。Iming 彼女の愛は、甘くて痛い。 2024年12月15日 (日) 13:45 (UTC)

見上方回復。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月16日 (一) 09:13 (UTC)

按H.Natsumi君意見撤回「修改申請標準和流程」案。--Iming 彼女の愛は、甘くて痛い。 2024年12月16日 (一) 10:00 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

草案 #2

不通過：

尚無必要賦予過濾器助理授權權限。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月16日 (一) 00:35 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

提議條文 權限總覽 對比起一般使用者，過濾器助理可以： 檢視標記為非公開的濫用過濾器日誌項目（abusefilter-log-private） 檢視標記為非公開的防濫用過濾器（abusefilter-view-private） 啟用雙因素驗證（oathauth-enable） 建立或修改防濫用過濾器（abusefilter-modify） 添加用戶組：過濾器助理 允許移除自己帳號的用戶組

有成員主張，根據上方的授權流程草稿，草案#2應明確，在#1的基礎上，允許過濾器助理賦予其他受信任用戶過濾器助理一組。相信此改革可顯著減輕管理人員在過濾器相關方面的任務壓力。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月7日 (六) 04:03 (UTC)

(＋)贊成，在管理員工作積壓嚴重的當下，我相信這樣可以顯著減輕管理人員在過濾器助理相關方面的任務壓力。--Iming 彼女の愛は、甘くて痛い。 2024年12月7日 (六) 05:22 (UTC)

不同意過濾器助理授予他人此一權限。現行權限申請制度未至積壓，請維持依照正常程序申請，俾便於社群檢視。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年12月7日 (六) 22:35 (UTC)

同Eric君，以目前的申請積壓情況無必要授予過濾器助理授予他人權限的權限--人間百態,獨尊變態(討論)(簽名) 2024年12月8日 (日) 14:30 (UTC)

RFR現在沒有積壓，沒有必要由現任AFH給申請人上權限，並且2024年AFH申請的頻率極低，明顯不會造成RFR積壓，故反對這一部分。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:32 (UTC)

個人認為過濾器編輯員應該是另一種權限，這個權限遠遠比查看過濾器敏感（例如有過濾器編輯權限者可以建立過濾器封禁所有試圖編輯的用戶）。反對賦予過濾器助理修改濫用過濾器權限。--GZWDer（留言） 2024年12月10日 (二) 11:25 (UTC)

@GZWDer：草案一定義了權限中將不再存在abusefilter-modify-restricted一權，故「封禁所有試圖編輯的用戶」這一行動技術上即不可行。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月11日 (三) 01:21 (UTC)

但是仍然可以創建一個過濾器阻止任何用戶編輯。--GZWDer（留言） 2024年12月11日 (三) 11:34 (UTC)

沒必要因噎廢食。現在錯誤報告的積壓呢是放在那裡的，喊管理員呢是沒有人管的。按過往討論，單開編輯者權限估計過不了，在考慮到積壓問題、過往討論和現有AFH均具備技術能力的情況下，給予AFH除受限過濾器外過濾器的編輯權是最優解，我上方提出的「修改申請標準和流程」案就是為了解決您這個問題設計的。而且事實上，我寫個機器人實時回退匹配的編輯也不是不能實現這個功能，所以我是覺得把需要管理員權限的扔出去就差不多了，您意下如何？--Iming 彼女の愛は、甘くて痛い。 2024年12月11日 (三) 15:23 (UTC)

(－)反對，如果是IPBE那種就算了，但很顯然授權過濾器助理沒有那種積壓問題（更何況還是高危權限）--SunAfterRain 2024年12月13日 (五) 19:51 (UTC)

根據上方討論，草案二不通過。由於主要反對意見均關於草案二中新增的授予權限權限，因而草案一維持開放，請移步草案一處進行討論，感謝。--Iming 彼女の愛は、甘くて痛い。 2024年12月14日 (六) 02:55 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在受限過濾器多次匹配正常編輯時的處理措施

已關閉：

提案人 撤回提案。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月10日 (二) 02:16 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

---

按前文討論，考慮到對包含受限動作的過濾器的編輯權限實際上等同於封禁權限，因而沒有授予過濾器助理創建或編輯含受限動作的過濾器的權限。然而參考近期AF/FP，可預見的在未來會存在含受限動作過濾器錯誤匹配甚至封禁正常編輯者的情況。又考慮到WP:AF等頁面不存在事實上的過濾器方針，宜同本案一併討論。是故，本人有以下想法，尚祈社群商議為荷。

現行條文 不存在

提議條文 編輯受限過濾器 當確認到一個包含受限動作的過濾器存在不符合預期的行為或已嚴重影響到正常編者編輯時，過濾器助理可以請求管理員臨時關閉相關過濾器或取消相關過濾器內的受限動作，直至問題解決為止。當管理員處理此類操作時，除非有其他原因，否則通常應當在關閉過濾器後取消相關過濾器內的受限動作以便其他管理員或過濾器助理修復。當一名管理員或過濾器助理確認問題得到解決後，就可以恢復過濾器至原先狀態。

以上Iming 彼女の愛は、甘くて痛い。 2024年12月8日 (日) 16:14 (UTC)

反對這種處理，比如過濾器275這類自動化封禁破壞的過濾器顯然不能簡單取消受限，只能過濾器助理調查哪一個正則導致了錯誤觸發並請管理員處理，取消受限造成的反破壞影響太大了。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:39 (UTC)

您說的確實很有道理，那可能我們需要進一步討論在受限過濾器多次匹配正常編輯時的處理措施。至少，我認為應當將封禁一類操作改為阻止+標記以供人工審查，您覺得如何？如此應當可以有效減輕對反破壞工作的影響。--Iming 彼女の愛は、甘くて痛い。 2024年12月9日 (一) 10:44 (UTC)

275這種泛用過濾器出現這類同規則多次觸發的情況下直接把封禁過濾器裡面多次誤報的那一個規則移動到阻止或者警告（這裡可以是201和289），這個操作管理員很容易完成，過濾器助理只需要調查出受限過濾器哪一個特定規則造成了錯誤觸發，通知管理員即可。而像是322這種針對某一特定LTA（或者類似的單一用途過濾器），多次假陽性可以改為不受限。簡單說就是需要具體情況具體分析，不建議寫成條文，而是出問題了再和管理員依據常識解決。𝐻.𝑁𝑎𝑡𝑠𝑢𝑚𝑖 ™ 2024年12月9日 (一) 10:55 (UTC)

可以，我很贊成您的觀點。撤回提案。--Iming 彼女の愛は、甘くて痛い。 2024年12月9日 (一) 11:02 (UTC)

有需要自行IAR就好，不要訂一條規則合理化IAR結果還時常發生必須IAR該規則的規則。--SunAfterRain 2024年12月13日 (五) 19:53 (UTC)

---

本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

公示

由於除草案1外的所有分案均不通過或被撤回，而有關原案或草案1的最後留言在11日前作出。依WP:共識#提案討論及公示時間的規定，互助客棧中的提案在7日內無新留言時或可在已取得共識的前提下公示，故現以草案1為定稿，並公示定稿7日。Sanmosa _蚌埠 2024年12月17日 (二) 08:56 (UTC)

見上，提案的新發展使維持公示不再適合，現撤下公示。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:32 (UTC)

改走RFC機制。亲，我簽名那刻的時間是 2024年12月22日 (日) 08:36 (UTC)

距上個問題及解答之日已逾7天，現恢復13天前中斷的已公示5天的公示。 公示7日，2025年1月7日 (二) 01:54 (UTC)結束。——敬頌冬綏 ZhaoFJx_(論•簽) 2024年12月31日 (二) 01:54 (UTC) 暫停公示：公示期間有爭議，故暫停公示並進行討論。——敬頌冬綏 ZhaoFJx_(論•簽) 2025年1月5日 (日) 00:03 (UTC)

(！)意見：論其利弊，以為利大於弊；論其可靠，以為配套未足。私以為往後申請權限應要求回答至少三個問題，加強其可信度。--駭客呼吸焉—☎️— 2025年1月2日 (四) 10:29 (UTC)

(－)反對，過濾器事關全站，與管理員相比，過濾器組顯然不可信。->>Vocal&Guitar->>_留言 2025年1月1日 (三) 13:27 (UTC)

(：)回應 首先，目前所有助理的申請都是在本草案通過前完成的，也就是說，基本不會存在為了破壞而申請該權限的可能；其次，這些申請都由專門的管理員檢查後再授權——你可能也注意到了，並不是每個申請者都被賦權；最後，草案通過後，管理員會在處理申請時更加審慎，以確保不會讓破壞者成為過濾器助理。話又說回來，草案#1中所定義的技術權限確保了助理們不能通過過濾器執行惡意操作——或在同等條件下更難執行惡意操作。——敬頌冬綏 ZhaoFJx_(論•簽) 2025年1月1日 (三) 18:59 (UTC)

完全是空話，只要過濾器可以阻擋正常編輯，那就完全可能被惡意利用，而且是全站範圍影響將會巨大。當初這個組分拆自回退權，回退員申請默認都給過，現在權限發生巨大變化，之前的申請當然不能作數。--。->>Vocal&Guitar->>_留言 2025年1月4日 (六) 00:16 (UTC)

你這意見多少有些Opky式的誇張了。Sanmosa _蘭絮 2025年1月4日 (六) 01:55 (UTC)