维基百科:互助客栈/其他/存档/2022年6月

糾正歷史上陰陽家的錯誤

雪球關閉：

請閣下勿于此發表離題内容。 --紹💓煦^{意見箱 · sign} 2022年6月5日 (日) 19:27 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

很不幸的是歷史上這種前人的錯誤，不是我們後人能糾正的。

一個中國文化的特徵而世上也是獨一無二的，那就是中國古代的陰陽學。陰陽學的晢理至深，一般世人無法了解，以訛傳訛，傳至其末，「不知所云」，屬性與本質是兩碼事。這種前人的錯誤，不是我們後人能糾正的，在這裡我們沒有理由去追求那些“以訛傳訛” 的陰陽屬性，那只能越描越黑。我們必需從新來過。

根據太極圖，那不是兩個蝌蚪擠在一個圓圈裡，而是一對黑白象徵性的代表一個陰陽整體，黑裡一點白，白裡一點黑，隱藏著“陰陽錯”的天機（“錯” 作交錯或是錯過解）。

https://upload.wikimedia.org/wikipedia/commons/1/17/Yin_yang.svg

見圖，陰陽表現四個不同又相關又不能分的特性： 一）對立統一。那是陰陽相對而形成一體。 二）相克相生。陰長克陽，同時助陽復生，反之亦然。 三）物極必反。陰極變陽，而陽極變陰。 四）極盡平衡。極盡—最終—陰陽總是平衡的；那是說，陰陽總是追尋平衡的。

那“四個不同又相關而不能分的特性” 是個很高深的學問，世人不能理解，謂之詭譎/邪術，終於在魏晉朝時代失傳，只有一個太極圖和一些陰陽的“屬性” （裡外，上下，男女等等） 留傳下來。

用語言吾人可以定義任何事物，但是它存在嗎？定義沒有實物與其對應只是一個幻想。根據上述陰陽的特性，陰陽是不能分的，所以是“一元” ，當陰陽家創“陰陽二元論” 時，陰陽一元的本質盡失，陰陽家是始作俑者，後世跟著錯。那什麼是真正的陰陽呢？“陰入陽出” ，呼吸也。世上萬物，只有呼吸附合那四個陰陽的特性，呼吸是“一元” 世界的元素，二元世界不過是一元世界的幻想。

証明：一）對立統一：吾人呼吸，一呼一吸，然後循環，我們不能只呼不吸，或是只吸不呼，所以呼吸是不能分的一體—“一元”—對立統一。 二）相克相生：當我們吸氣時，越吸越難吸，同時呼氣比較容易，那是吸氣克呼氣，同時助呼氣復生—相克相生。 三）物極必反：當我們吸氣吸到盡頭不能再吸的時候（物極），必然呼氣，反之亦然—物極必反。 四）極盡平衡：吾人要是活著，呼吸一定平衡—極盡平衡。

陰陽二元論說不定是一門學問，但是其主題的對象不是我們中國古典的陰陽一元論的陰陽。 --太極滑雪（留言） 2022年6月4日 (六) 18:32 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

在谷歌搜索维基百科论述疑似被劫持

在谷歌搜索维基百科:热血速删,发现搜索结果被劫持到一个叫“barang.live”的网址，里面的内容不可描述。

不知道其他用户是否也遇到了这个情况，是否还有其它的维基百科搜索结果在谷歌被劫持？--Hooonooka（留言） 2022年6月1日 (三) 08:39 (UTC)

动态镜像加有SEO。好像有讨论过，但好像没有办法让Google对待我们站点更友好。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月1日 (三) 08:59 (UTC)

之前有过。这并不能算“劫持”，仅仅是Google收录了镜像站的结果且排名更靠前而已。

办法嘛，我没记错的话萌娘百科通过JavaScript实现了如果通过镜像网站访问，会显示提示。不知道本站有没有意向部署类似功能？或许可以在一定程度上解决此问题。--Tranve (✉) 2022年6月2日 (四) 13:20 (UTC)

如果找知名人物，事件，品牌和與自己地區相關的事物和愛好者相關的條目，Google搜索结果會放在非常前的位置。不過如果要找海外的景點資料，Google搜索结果找KOL和博客比較多，維基基本放在很後的位置。--Wpcpey（留言） 2022年6月2日 (四) 14:27 (UTC)

应该请基金会联系Google。--虹易（留言） 2022年6月9日 (四) 04:49 (UTC)

重啟逐筆巡查標記的討論

已通过：

后续请见phab工单T308976。 MilkyDefer 2022年5月22日 (日) 12:57 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

如題，之前有提過是否能對每一筆編輯進行逐筆巡查的標記，以避免巡查員重複巡查同一篇文章的問題，不過好像最後結論就不了了之，因此希望能重啟討論。

在前一篇討論中，有很多人擔心巡查人力的問題，這部分我回覆一下，就是因為現行巡查人力不足，所以我們更應該改善巡查的效率，讓每位巡查員一打開巡查頁面就能知道什麼編輯尚未審查，而不是像現在一樣每筆點開來看，如同大海撈針。至於擔心巡查員積壓工作的問題，我想這並不是一個很好的理由，逐筆巡查對反破壞工作來說非常重要，並不是說不打開這個工具就可以當作現在這個工作不存在。--Koala0090（留言） 2022年5月8日 (日) 03:56 (UTC)

先是技术上是否支持，其次是用法和是否可靠。如权限下放程度，是否允许机器人/批量标记巡查，标记不当（应该有日志吧？）是否要追问质询、如何应对增加的“煮”。如果启用/禁用手续不复杂，试行也无妨。其实最近更改巡查也挺好，每个人对修订是否得当的标准不同；或者，逐笔巡查主要应对隐秘的鬼祟破坏？--YFdyh000（留言） 2022年5月8日 (日) 04:20 (UTC)

之前@Xiplus：好像有說技術上有可能辦得到，不過機器人批量巡查這件事我不確定能不能。我是覺得可以試行兩周個幾次，如果沒問題就全面適用。--Koala0090（留言） 2022年5月8日 (日) 05:05 (UTC)

主要是逐笔标记巡查有何意义？有不同于Wikipedia:稳定版本功能（好像由于技术原因，不会再追加功能新开站点）可以控制显示标记后的显示页面。新页面巡查好歹被视为具有权限性的职务，而最近更新巡查是人都可以巡查，是否标记的意义不大。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 09:41 (UTC)

意义可能是减少重复检查，提升对冷门条目的检查率。--YFdyh000（留言） 2022年5月9日 (一) 09:46 (UTC)

想到一个弊端，破坏者可能根据条目修订长期无人“巡查”而采取鬼祟破坏，不知道是否有应对之策，就像条目监视者太少时不具体显示。--YFdyh000（留言） 2022年5月9日 (一) 09:48 (UTC)

@Cwek沒有標記的話，打開最近更改只能望洋興嘆，根本不知道從何檢查起。如果有標記的話，至少我一登入就知道我要檢查哪些編輯。--Koala0090（留言） 2022年5月9日 (一) 09:54 (UTC)

最近更改的过滤器功能现在挺强的。可以用最近更改-“监视列表新更改”过滤器。--YFdyh000（留言） 2022年5月9日 (一) 09:59 (UTC)

我目前是這樣做沒錯，但這一樣會有重工的問題--Koala0090（留言） 2022年5月9日 (一) 10:13 (UTC)

最近更新和监视列表有个修订评分功能，会自动标记可能是坏质量的修订版本，可以试试打开。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 10:32 (UTC)

我有開，但感覺不知道評斷依據是什麼？而且似乎大多數的破壞反而都不在標記中。另外會需要蹲點巡查就是因為有些蓄意破壞很難透過位元組或用戶加入時間去判斷。--Koala0090（留言） 2022年5月9日 (一) 18:08 (UTC)

那也没办法，有些破坏行为是偶然看条目发现不对劲才去翻查页面历史的，不可能靠整天蹲着最近更新来“扫描”（好吧，虽然有工具是可以这么干的），要不然这是严重的中毒了。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月9日 (一) 23:33 (UTC)

所以有什麼具體不能開放的缺點嗎，理論上巡查工具應該是越多越好，如果技術上可行，又沒有什麼缺點就開著，想用的人就用，不想用的人不用也沒關係吧。--Koala0090（留言） 2022年5月11日 (三) 09:25 (UTC)

• 尽速启用。->>Vocal&Guitar->>_留言 2022年5月12日 (四) 23:45 (UTC)

如果技术允许的话，建议将所有延伸确认用户的编辑自动标记为已巡查。否则打开最近更改看到一大片未标记的编辑，更没有动力去标记了。--Steven Sun（留言） 2022年5月15日 (日) 01:59 (UTC)

看了之前的讨论，技术上似乎无法区分新页面巡查豁免和编辑巡查豁免。--Steven Sun（留言） 2022年5月15日 (日) 02:11 (UTC)

可以开发机器人来自动标记。--YFdyh000（留言） 2022年5月15日 (日) 04:00 (UTC)

@Xiplus：想請問技術上是否能達成？若能達成，是否還需經表決，還是直接當成小工具開啟即可。---Koala0090（留言） 2022年5月15日 (日) 04:36 (UTC)

哪個部分？--Xiplus#Talk 2022年5月15日 (日) 04:42 (UTC)

@Xiplus 開啟逐筆巡查以及利用機器人標記巡查豁免者--Koala0090（留言） 2022年5月15日 (日) 06:25 (UTC)

我覺得可以開啊，但我覺得沒必要用機器人自動巡查，最近更改本來就可以篩選30/500，跟90/500也差不多吧，用這個就行了。--Xiplus#Talk 2022年5月15日 (日) 06:30 (UTC)

@Xiplus感謝回覆，那如果要啟用的話需先經過表決，還是要經過什麼討論步驟嗎？--Koala0090（留言） 2022年5月15日 (日) 09:18 (UTC)

公示數日即可--Xiplus#Talk 2022年5月15日 (日) 09:31 (UTC)

自即日起公示七日，若無其他反對意見，則開啟逐筆巡查功能。---Koala0090（留言） 2022年5月15日 (日) 12:57 (UTC)

先試三個月看看好不好？直接一次通過我擔心沒能完全消掉社群的疑慮。--Ghren🐦🕙 2022年5月15日 (日) 14:31 (UTC)

不需要定死时间吧，有共识再关闭。开关都需要phab那边完成。--YFdyh000（留言） 2022年5月15日 (日) 22:35 (UTC)

技术层面上，这个功能能够启用吗？（已经发生过多次搞不清楚状况，最后提交到phab那里被拒。。。）--百無一用是書生 (☎) 2022年5月18日 (三) 02:39 (UTC)

@Xiplus屆時是否可以協助提交請求呢？--Koala0090（留言） 2022年5月18日 (三) 03:19 (UTC)

好。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)

近百個wiki開啟此功能。--Xiplus#Talk 2022年5月18日 (三) 03:31 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

感觉启用后实在没啥意义，全都是红色感叹号，而且修订历史里还没有这个标记，只有最近更改和监视列表里才有--百無一用是書生 (☎) 2022年5月23日 (一) 14:56 (UTC)

目前看來回退和復原後並不會自動標記已巡查，若是如此，認為可能需要提醒所有巡查員要記得點選已巡查，不然還是要每筆點開來看。Koala0090--0906_{（回復請Ping我）} 2022年5月23日 (一) 16:30 (UTC)

對我也發現這個問題了，有辦法將某些設定設定為自動巡查嗎，例如說回退之類的。--Koala0090（留言） 2022年5月23日 (一) 16:32 (UTC)

另外就是因為我有開啟小工具，可以在不點開畫面的狀況下進行依些簡單的巡查。但因為最新更改清單中沒有巡查按鈕，還是要點進去才能巡查。不知道之後可不可以在後面加上一個巡查按鈕--Koala0090（留言） 2022年5月23日 (一) 16:37 (UTC)

Xiplus如果使用TW不知道可否自動標記，還有管理員、机器人應該可以自動免巡查吧....--0906_{（回復請Ping我）} 2022年5月23日 (一) 18:57 (UTC)

@ChhTJ096：全都是靠外部脚本运作的配套功能，为什么要靠脚本来清除？所以说，这个功能，为什么不从一开始就考虑解决后续的问题（一些用户或者大部分用户并不需要这些标记，或者说还需要考虑部分用户组的编辑可能不需要被这样标记）。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 02:21 (UTC)

很困惑的鸡肋功能，而且还要靠额外的手段来清理掉一些不必要的标识。只为其中一位编辑的识别能力弱而特此开启该功能，真的是……——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 01:45 (UTC)

祝某些编辑“消消乐”愉快。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 01:49 (UTC)

沒價值的引戰留言恕我不回覆了--Koala0090（留言） 2022年5月24日 (二) 06:22 (UTC)

建议撤销该操作

正如所见，这个标记功能很鸡肋，而且观感糟糕（最近更新和监视列表全是叹号），一系列解决方案（包括机器人自动标记、延伸确认用户自动标记）都没有跟上。所以没必要开启，如果特定编辑需要为每笔编辑标记以防止漏查，亲，我建议你自己写工具更好，毕竟是自己动手丰衣足食。@Shizhao、Steven Sun、YFdyh000：如果认为该功能作用不大，应该考虑撤销掉。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 02:13 (UTC)

暂时来看，具有“新页面巡查”、“巡查豁免”，或者说用户组具有标记巡查功能，的编辑是没有叹号的，也就是自动标记的。有可能这本身和“新页面巡查”的巡查机制是同一套的。Wikipedia:最近更改巡查也仅仅是提供一些外部追踪工具的志愿工作，而不是具有权限组的“职能”，为此开启这个功能有点用大炮打蚊子？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 02:37 (UTC)

另外，去了部分开启这个功能的wiki项目（波斯语fa，意大利语it，C区commons），fa和it的最近更新没看到有叹号，同时我没有当地类似巡查的职能性权限，可以认为没有“标记巡查”功能的用户是不会看到“叹号”的。commons的最近更新基本上没见到叹号，而且我有当地的“自动巡查”组，我就纳闷，然后再对了一下，一来分是大部分编辑都具有“巡查标记”功能的用户组，所以前述，会自动标记巡查；二来新页面巡查似乎也清得很勤快，没有对应用户组的用户的编辑很快被清理了；三来留意到一个bot账户User:BotLeo，会将新加入的“自动巡查”组的用户的旧编辑全部标记为已巡查。如果要达到不干扰的情况下，至少要做到commons区的情况才行。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 03:15 (UTC)

其實本來這個狀況就是有預期到的，首先開啟第一天，有許多巡查員尚不知有這個功能；第二就是這個工具缺乏自動標記功能。如果要解決的話應該是可以透過改善自動標記某些巡查功能，真的不能做到再關閉。每個新工具上線之初本來就會有問題，本來就需要一段時間的測試和調整。每個人的需求不同，如果因為你個人「不需要用到」這個因素而去阻止其他新工具的開發，那其實對於整個社群的進步是有危害的。例如說視覺化編輯上線初期，也是出現了很多反對的聲音，有些人說「原始碼用得好好的，為什麼要開發這麼難用的工具！」但對於許多不會原始碼的新手，這個工具還是相當重要的，如果還是用你那論調主張「只有少部分程式語言能力低落的用戶需要用到」，那就會阻礙很多人參與和工作。總之，言盡於此，若閣下後續有價值的留言我會適予回覆，單純來引戰和人身攻擊的就上ANM，這樣。--Koala0090（留言） 2022年5月24日 (二) 06:37 (UTC)

“‘我’不需要用到”不等于“你需要用到就启用”，而且我也留意到一些用户也疑惑启用的必要性。而且“最近巡查”并不是“点击标记”，且不依赖于“点击标记”，你的想法是假设有最近巡查的人员会重复巡查，但问题当发现怀疑破坏后，不应该直接点击差异进去看一下有没之后的编辑（可能有其他用户已经发现而撤回，又或者不只是这一笔还有后续）？只要能做到这步，就不会出现重复巡查的问题（因为前述，如果没被处理就肯定这个“破坏”处理或者还有后续，这就更需要看页面历史），所以这个最近更改的标记就没有意义。而且没有CSS修饰的话，的确可以肯定已经对众多有巡查权限的用户造成困扰，而且我不认同靠CSS来掩耳盗铃来处理（甚至没有其他mw-core的功能配套下，依靠外部的行动来标记“可信”的编辑）。如果只是某些编辑为了防止自己的失误的话，应该自行解决，而不应该用大炮打蚊子的方法，还要搞出额外的操作来换更小的大炮打蚊子来避免。甚至最近巡查真靠逐个标记来排除破坏，而不是通过观察编辑行为来判断？———Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 09:49 (UTC)

所以你根本沒有搞清楚為什麼需要開啟這個工具，你說的重複巡查跟我說的重複巡查根本是不一樣的東西。你說的是重複反破壞，但至於重複審閱的問題根本沒有解決，開啟這個工具的目標並不是防止失誤，而是可以讓巡查員一眼看出哪些編輯還沒巡過，可以更有效率地去找。

第一天許多巡查員根本還沒進入狀況投入巡查，本來就預期會有這樣的情形，但我們卻必須花大把的時間跟你解釋這個是本來就會發生的狀況。--Koala0090（留言） 2022年5月24日 (二) 11:00 (UTC)

反而你没搞清楚WP:新页面巡查和Wikipedia:最近更改巡查的差异（一个是具有职权性的（有专属的用户组），另一个是只需要配合工具任何人都可以参与的志愿工作），而且“最近巡查”处理完破坏后还要手工点击“标记”多此一举的行为。所以我只能说你不过沉迷于“消消乐”的游戏，给有“巡查标记”功能的“新页面巡查”带来困惑罢了。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 01:02 (UTC)

别瞎代表，是“你”。根据行文来看，Shizhao似乎对此有不太赞同或疑惑的意思。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 01:14 (UTC)

“最近逐笔巡查标记”的问题是，对于没问题的编辑版本，依然依靠“标记”来消去提醒，在大部分编辑没问题的情况，这可能是困扰性的。不同于“新页面巡查”，“标记巡查 ”对于其他“新页面巡查人员”来避免重复新页面巡查来说，才是有必要性的。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 01:26 (UTC)

既然知道這是同源技術，那麼新頁面巡查就是巡查這個頁面的第1筆編輯，最近更改巡查就是巡查這個頁面的第2、3、4筆編輯，實際並無差異。就算已經有巡查員群組，所有人都還是可以參與新頁面巡查，而巡查權限本質上只是一個「告知其他人不需要再檢查一遍這個條目」的權力而已，同理，提案人只是需要「告知其他人不需要再檢查一遍這個編輯」的功能。--Xiplus#Talk 2022年5月25日 (三) 03:09 (UTC)

Wikipedia:新頁面巡查是职权性的（具有独立的用户组和功能），Wikipedia:最近更改巡查是带有志愿性和非职权性的，实际上“逐笔巡查”的功能是“新页面巡查”用户组及职权下所拥有的功能（或者说附带的，由于启用了逐笔巡查且技术同源），对于普通用户而言，逐笔编辑除了撤销破坏之外，就没有任何功能的操作的，而新页面巡查有着更多的操作（分析页面并且挂标示或者编辑改善），而且有着功能性的操作——将第一笔标记以便于清除提醒。所以对于“最近巡查”而言，有没这个功能（是否标记）无关重要，对于“新页面巡查”用户组而言，只是多了“最近巡查”的附带功能，而且对于想执行“最近巡查”的用户，“需要”这个功能还不如就是申请成为“新页面巡查”用户组人员。而且基于两次提案实际上看上去更像是Koala0090的一己之欲，支持者也不多（或者更多的是认为功能是否必要或者有不太可行的附加要求），所以看不出这样的功能开启共识有多强。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 04:26 (UTC)

或者说，对于大部分拥有“巡查标记”功能的“新页面巡查”人员来说，“逐笔标记”是否具有必要性；而对于想执行“最近更新巡查”的用户来说，“逐笔标记”是否具有必要性，另外如果为了这个“逐笔标记”的能力，是否其实应该考虑成为“新页面巡查”人员？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 04:30 (UTC)

「新頁面巡查有著更多的操作（分析頁面並且掛標示或者編輯改善）」難道一個文字內容在建立頁面時需要掛模板，但如果建立條目一段時間後再加入同樣的文字內容就不用掛模板嗎？--Xiplus#Talk 2022年5月25日 (三) 04:32 (UTC)

特定一笔编辑“挂修葺标示”和“标记巡查”在“Wikipedia:最近更改巡查”中有必要的关联？或者说，有必要每一笔编辑操作都需要人力确认有问题或者没问题，来消除这个巡查提醒？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 04:36 (UTC)

Re「有必要每一筆編輯操作都需要人力確認有問題或者沒問題」：沒有檢查到就算了，這同理於存在積壓的新頁面巡查，所以我們才需要「標記功能」來讓僅有的人力效益最大化，如果每個巡查員每天能巡查10個條目，那麼2個巡查員最多可以巡查20個條目，如果沒有將新條目標記為已巡查的功能，那麼這2位巡查員就可能檢查到重複的條目，導致總巡查量降低。同理如果有2位志願巡查最近更改的人，而分別每天能檢查100筆編輯，那總檢查量最高是200編輯，但如果沒有將編輯標記為已巡查的功能，那麼這2位檢查到重複的編輯，就會讓總檢查量降低。--Xiplus#Talk 2022年5月25日 (三) 04:44 (UTC)

我认为还是一个问题，没搞清楚WP:新页面巡查和Wikipedia:最近更改巡查的意义，原则上新条目应该被标记巡查掉（现在就是人力原因或者其他原因，导致了经常超期，而且也不会影响条目的显示），“标记掉”就是“暗示”给其他“新页面巡查”人员这个条目已经巡查过。而执行“最近更改巡查”工作的用户，添加了修葺标识、撤销了一笔破坏，与“标记掉”有没必要的关联？没有，而且看是否存在后续编辑就知道是否被处理过。而且也提及过，由于技术同源，这个功能是对“新页面巡查”人员有影响也只对“新页面巡查”人员有意义，但对于“新页面巡查”人员来说，这个功能（连“逐笔编辑”都可以或者需要标记巡查）是否具有必要性？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 04:55 (UTC)

「而且看是否存在後續編輯就知道是否被處理過」為什麼我必須要點進去才知道有沒有被處理過，對於不需回退的正常編輯，也不可能有後續編輯。巡查新頁面同理，我如果點進去10個條目都發現已經被掛快速刪除模板，這是否表示巡查沒有積壓，並不是，這只是表示我巡查了其他人已經巡查過的條目。--Xiplus#Talk 2022年5月25日 (三) 05:02 (UTC)

簡單問：Special:最新页面裡面的「隱藏巡查過的編輯」意義是什麼？您巡查時會使用此功能嗎？為什麼要使用？--Xiplus#Talk 2022年5月25日 (三) 05:08 (UTC)

如果针对最近更新的编辑，如果发现有问题的编辑，点击差异进去，确认是有问题了，直接撤销掉，然后还要回去上一笔编辑，点击标记（对于具有“巡查标记”功能的用户，例如“新页面巡查”组的）；或者然后可以什么都不用干（对于没有“巡查标记”功能但又想干“最近巡查”的用户）。而对于已经处理了的编辑（即使像过去一样，没有“逐笔标记”功能），没点击差异进去之前，最近更新已经提示有下一笔编辑了；点击差异进去，如果已经处理了，同样显示已经有下一笔版本；或者操作撤销时，提示有编辑冲突，因为类似的操作已经被另一位用户同样处理了。最终回到这里，“逐笔标记”似乎变得可以没有的存在，因为整个行为只对“新页面巡查”组有功能意义，但又不是必要的操作。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 05:29 (UTC)

「沒點擊差異進去之前，最近更新已經提示有下一筆編輯了」那如果沒有下一筆編輯，但這筆編輯實際上已經由別人檢查過的話呢？--Xiplus#Talk 2022年5月25日 (三) 06:29 (UTC)

如果是好编辑，那就别管它，关掉窗口或者忽略掉就是了。如果是坏编辑，请行动，或者已经有人行动了。“逐笔标记”并非必要。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 07:18 (UTC)

您一直沒有理解我的重點，我為什麼要重複檢查別人實際上已經檢查過的編輯？為什麼不能直接排除掉別人檢查過的編輯？--Xiplus#Talk 2022年5月25日 (三) 07:29 (UTC)

重申：點進去一筆編輯後才發現別人已經檢查過就算重複工作了，別人檢查過的編輯要直接隱藏！--Xiplus#Talk 2022年5月25日 (三) 07:30 (UTC)

那问题是这样做有意义吗？然后让一个对Wikipedia:最近更改巡查有兴趣的用户，特意去申请加入“Wikipedia:新頁面巡查”去获得“标记巡查”功能，然后就是为了给没有问题的编辑做标记，然后通过这样告诉其他“Wikipedia:新頁面巡查”人员“哦，这个编辑没问题，这个编辑也没有问题，这些编辑也没有问题”？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 09:18 (UTC)

有必要的話會進行權限拆分。--Xiplus#Talk 2022年5月25日 (三) 09:30 (UTC)

Wikipedia:最近更改巡查没有用户组，而Wikipedia:新頁面巡查关联的用户组“巡查员”的核心权限就是“patrol”功能权限，也就是想做Wikipedia:最近更改巡查工作，现时肯定就要成为“新页面巡查”人员，才能拥有核心权限及对应的权利（启用逐笔巡查功能（非特设的话，默认关闭），则最近更新和监视列表能区分有没标记巡查的编辑，启用了新页面巡查功能（非特设的话，默认开启），则新页面能区分有没标记巡查的编辑，新文件巡查功能也是同新页面同理）。为了给每笔没问题的编辑标记没问题来提醒其他不一定相关的人员“没问题”，而特意去申请一个为新页面做巡查的职务或用户组，我觉得哪里不对。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 10:05 (UTC)

所以不會這麼做，會進行權限拆分。--Xiplus#Talk 2022年5月25日 (三) 10:06 (UTC)

愿闻其详，希望不是为了别扭地配合，还要mw开发申请新功能。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 10:08 (UTC)

拆分權限比開發新功能簡單多了，mw開發新功能不行，開發外部工具就可以，是什麼道理？--Xiplus#Talk 2022年5月25日 (三) 10:21 (UTC)

为了使用一个从一开始开发完就被嫌弃的“新”功能，而去别扭地适配使用，还要靠外部工具去“修正”，还不如不用。因为你提到拆分权限，我无法确定你的想法，我猜想可能是将“patrol”功能拆成适配新页面、新文件、逐版本编辑的“patrol”，然后重新分配用户组？所以这意味着是不是还要找mw开发组进行功能适配？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月26日 (四) 02:26 (UTC)

開發新的外部工具就不會被你嫌棄嗎？--Xiplus#Talk 2022年5月27日 (五) 04:33 (UTC)

参考该功能开发初期的讨论，我认为好的编辑不需要特意标记（旧en讨论也有人提到，假设所有编辑都是可疑的来去标记不是好的wiki风格），坏的编辑直接操作处理则可；坏的编辑处理好后还需要额外的操作来标记之前被破坏的编辑（除了core-rollback似乎能直接标记，但留意到巡查日子似乎没记录）；粗略看了commons的巡查日志，似乎也很少人会做“逐笔编辑标记”的操作，在旧en讨论中也提到这个问题。所以既然这个功能从一开发后就被遗弃，单独启用了的也似乎是鸡肋一样少用，我不认有启用的必要。而且这个功能更依赖于“新页面巡查”用户组的“patrol”权限，对于只做“最新巡查工作”但不属于这个用户组的用户来说，似乎并不合适。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月27日 (五) 05:59 (UTC)

仍有近百個wiki開啟此功能，單憑en一個wiki不足以證明很難用。--Xiplus#Talk 2022年5月28日 (六) 12:47 (UTC)

不然請您提出改善「重工」問題的具體解決方案。--Xiplus#Talk 2022年5月28日 (六) 12:51 (UTC)

近百wiki启用功能并不能说明普遍性（反而你需要倒转数一下有多少wiki是默认关闭的，为什么这个“逐笔编辑标记”不是普遍使用，反而同源的“新页面标记”和“新页面标记”反而是默认启用的），你应该说明这些wiki是否有大量使用这个功能（也就是经常地使用逐笔标记），否则就会出现某些用户不会（有功能者）或不能（没功能者）标记正常编辑或者已处理的编辑而还是存在重复“巡查”的问题。至于“重工”问题，最简单的处理就是把这个鸡肋功能关闭掉，让一切回归以前。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月29日 (日) 11:24 (UTC)

以前就有重工問題，您是不是根本不懂哪裡重工。--Xiplus#Talk 2022年5月29日 (日) 11:33 (UTC)

要么就是“最近巡查”的志愿行动和“新页面巡查”职务性行动因为启用“逐笔巡查”后的冲突（“逐笔巡查”需要用到“新页面巡查”的“patrol”功能）；要么就是你所说的重复检查需要靠标记来区分，我认为这个需要数据统计，究竟有多少用户愿意去做这样的标记行为。我认为应该根据已开启该功能的wiki项目的最近变更数据来统计，如果很少人使用这个功能或者能力（也就是最近编辑中，手工标记的页面编辑的比例很低甚至几乎没有），那就说明这个功能就是鸡肋功能，没必要凑热闹来开。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月30日 (一) 02:02 (UTC)

只要有兩個人願意做標記，那麼這兩個人就能夠省下彼此的時間。其他不參與的人一樣會有重工的問題，但其他人要浪費自己的時間我管不著。--Xiplus#Talk 2022年5月30日 (一) 15:23 (UTC)+1 YFdyh000为此+1了。

那只能之后看支持启用的人有多大的意愿去做这种消消乐的活了。（摊手）——Sakamotosan路过围观 | 避免做作，免敬 2022年5月31日 (二) 04:50 (UTC)

如果只因为“观感糟糕”，在目前阶段，新增CSS/小工具默认禁用、以小工具自选启用，这样是否完美？没有巡查权限是看不到叹号的，例如我当前只有巡查豁免，看不到叹号。后续功能得功能开启才方便测试和有动力开发。其他观点不赞成。--YFdyh000（留言） 2022年5月24日 (二) 07:55 (UTC)

CSS屏蔽，或者依靠外部行动来标记没有功能豁免的编辑，我认为不就是掩耳盗铃？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月24日 (二) 09:53 (UTC)

CSS屏蔽，然后对有巡查权但认为不需要逐笔巡查的用户，不就跟以前一样吗？--YFdyh000（留言） 2022年5月24日 (二) 10:03 (UTC)

话说，这是已经关掉了吗？现在我已经看不到红色感叹号了（除了新建页面）。另外，我认为其他wiki很少标记，可能更多的原因是具有“巡查标记”功能的用户组门槛很低，类似于自动确认用户那样。如果中文版这边没有类似机制，导致的后果就是一片红色的感叹号。另外，我对监视列表里的编辑，不会因为有感叹号标记而去特意查看并“标记为已巡查”，也不会因为没有感叹号或已经巡查而就不去看了。最后，这个功能到底我们社群有多大的需求？--百無一用是書生 (☎) 2022年5月24日 (二) 12:35 (UTC)

没有关闭功能，只是在Mediawiki:Common.css用CSS屏蔽掉了。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 01:08 (UTC)

我认为可以降低逐笔巡查的门槛到扩展确认用户，以及前期默认不显示（如上文，通过小工具启用）。以及通过机器人标注可信用户，应比巡查豁免多并且进出更灵活。最好能提交批量标记历史编辑的请求。机器人编辑肯定要默认巡查。对于标记行权争议，也可再制定规则。--YFdyh000（留言） 2022年5月24日 (二) 13:48 (UTC)

逐笔巡查和新页面查询是同源技术，也就是有“patrol”（标记别人编辑已巡查）权限就会看到功能按钮和进行操作，现阶段有的用户组应该有“新页面巡查员”和“管理员”。如果基于用户组的话，可能要给扩展确认用户添加“autopatrol”（自动标记自己编辑已巡查）权限，但Xiplus认为类似的机制不需要（？），而且前述，两者同源，如果给了“autopatrol”，连新建页面都会自动标记巡查，也就是等于有了“巡查豁免”用户组（该组有这个权限），可能会和“新页面巡查”的权责有冲突。或者申请开发mw-core功能作为绕过，但需要mw开发组的处理。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 01:08 (UTC)

其實以前在巡查最近更改的時候，就發現有重復巡查的問題，後來我發現Huggle和SWViewer的功能非常的強大，如果說最後這個工具被撤销，Koala0090君可以試試這兩種程式。--0906_{（回復請Ping我）} 2022年5月24日 (二) 14:01 (UTC)

我的意见就是这个意思，“最近更新巡查”因为定性于非职权性（没有用户组，而且逐笔标记似乎过于鸡肋，以至于很早（根据配置文件，似乎是en在2005年的讨论）被默认禁止了），只需要辅助工具就能解决，如果避免重复巡查的话，完全可以依靠这些工具来实现。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 01:10 (UTC)

請問哪個工具可以檢查一個小時前的編輯？Huggle或SWViewer可以嗎？這些工具都僅能檢查當下新出現的編輯吧。--Xiplus#Talk 2022年5月25日 (三) 03:12 (UTC)

这只是对这些外部工具对过往记录的回溯能力需求吧？有这个需求的话可以向相关工具开发提出（core-API没记错，最近更新列表似乎可以指定回溯的时间？）。如果这些工具长期启动的话，也可以回溯已经发生过的编辑？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 04:26 (UTC)

MediaWiki本身就有這樣的功能，不理解為何一定要開發新的。--Xiplus#Talk 2022年5月25日 (三) 04:46 (UTC)

你应该问Huggle或SWViewer的开发，这样外部的最近更新追踪工具有什么作用，就是为了给自己标记自己已经“复核”过的每笔编辑？——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 04:58 (UTC)

我认为最近更改巡查对于small wiki或许有些意义，对于更新相当多的wiki完全没有实用价值--百無一用是書生 (☎) 2022年5月25日 (三) 06:40 (UTC)

另外，实操上，我看到一个好的编辑我可能会标记巡查，但对于坏的编辑我可能直接回退而不会标记为巡查（因为操作太繁琐）。所以我感觉这个逻辑上有些怪--百無一用是書生 (☎) 2022年5月25日 (三) 06:43 (UTC)

我认为为了提醒别人“好编辑，我巡查过了”或者“坏编辑，我确认过，并处理了”而特意在不断更新的最近更新里面启用这个功能，有点不值的，这在当时这个功能开发出来后就有人提出这个问题，后来开发者初步统计过，的确没多少人愿意做最近更新的巡查标记。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 10:15 (UTC)

如果有必要的话，可以参考当年实现了但又关闭掉这个功能的讨论：en:Wikipedia:Village_pump_(news)/Archive_A#Recent changes flags→en:Wikipedia_talk:Checked_edits_brainstorming。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月25日 (三) 06:25 (UTC)

两天观察和处理后，对于“撤销”破坏编辑后的标记情况，我所观察到：如果使用系统功能rollback的话，是可以将被回退的编辑版本标记巡查（例如这笔：diff=71810208&oldid=71712640），不过在巡查日志没有找到该笔版本的巡查记录，不太确定这个是不是一个bug；如果使用盖板本的编辑式“回退”（例如：TW的回退、还有系统提供的撤销），则不会将被回退的编辑版本标记巡查（这笔：diff=71820246&oldid=71789098、diff=71822172&oldid=71822032）。可以将页面进行监视后然后在监视页面检查“叹号”。所以我认为shizhao的说法可能没说错：如果撤销掉一个破坏，可能不会有人得此返回去将“破坏”的编辑版本进行标记，尤其是用覆盖版本的编辑来“回退”。——Sakamotosan路过围观 | 避免做作，免敬 2022年5月26日 (四) 02:18 (UTC)

开了功能就多试试吧，没有必要立即关闭，用CSS把感叹号的影响处理掉就好，逐笔巡查的按钮还是有点用的。桐生ここ★[讨论] 2022年5月26日 (四) 07:55 (UTC)

或許可以開一個「版本巡查」功能，一旦判定某版本為已巡查版本，就將過去的版本視為已巡查。--Koala0090（留言） 2022年5月28日 (六) 13:14 (UTC)

可以用這個連結，只要僅顯示最新修訂版本+未巡查，就僅會列出最新版本未巡查的頁面。MediaWiki:Gadget-RCPatrol.js則會在歷史中標記最新版本到最近巡查的版本。--Xiplus#Talk 2022年5月28日 (六) 13:37 (UTC)

自动巡查被认为无问题的编辑

前情提要：Wikipedia:机器人/申请/Crystal-bot/3，这是一个会自动巡查已被回退（撤销）掉的编辑的机器人。@Shizhao认为可以更进一步，将“符合某些条件的用户”或“ORES打分如何”的编辑直接自动巡查，来让巡查员更集中于真正需要人工进行巡查的编辑。我的想法是利用ORES的打分来进行判断。尽管中文项目上精度相比于英文有些不尽人意，但个人认为基本够用了。

暂拟的规则如下：如果某笔编辑“被认为有危害（damaging）”为真（true）的可能性小于等于0.027（2.7%），则认为这一编辑不需人工巡查，机器人将自动标记为已巡查。按今年的数据来说，此举可以自动巡查约46%的编辑。希望社群对本提议给出建议。（特别感谢@WhitePhosphorus提供的帮助） Stang^★ 2022年6月8日 (三) 15:09 (UTC)

如何获取某一笔编辑的ORES打分？以这笔编辑为例，解析请求可知damaging打分为0.014，因此会被自动巡查。 Stang^★ 2022年6月8日 (三) 15:14 (UTC)

 好诶。疑问：1. 机器人或ORES模型是否能及时地自主或辅助纠正“误判”。2. 如果积压率极低/清零，建议能自动或适时调高阈值。--YFdyh000（留言） 2022年6月9日 (四) 00:43 (UTC)

理论上ORES会自主学习；有关阈值可以参考下方的FAQ链接（“Where should I set my thresholds for filtering/highlighting”章节）。 Stang^★ 2022年6月9日 (四) 04:34 (UTC)

为何不考虑goodfaith的分数？--百無一用是書生 (☎) 2022年6月9日 (四) 01:54 (UTC)

还有，为何不直接用prediction的真假值，而要用分数做判断？ORES这一块我没仔细看过文档，不太了解--百無一用是書生 (☎) 2022年6月9日 (四) 01:57 (UTC)

我忘记是从哪里看到的了，但似乎有说法说这两个模型的训练方式不是很一样；既然goodfaith有更高的recall rate，那可以选用它。我也没有仔细看过文档……这个页面可能有点帮助。 Stang^★ 2022年6月9日 (四) 04:34 (UTC)

或者严格一点，damaging为false且goodfaith为true的自动巡查？你那个0.027的条件说实话我不理解为什么设定这个值？当然，ORES给出的数据我也不是看的很明白[1]。另外，可以参考mw:ORES/Thresholds--百無一用是書生 (☎) 2022年6月9日 (四) 07:05 (UTC)

大致用今年数据统计了一下，排除掉damaging为真或goodfaith为假的编辑，大约88%的编辑都可以自动巡查掉。--百無一用是書生 (☎) 2022年6月9日 (四) 07:58 (UTC)

Re: 「不理解為什麼設定這個值」，mw:ORES/Thresholds#Balancing sensitivity vs. specificity裡面有解釋。--Xiplus#Talk 2022年6月10日 (五) 13:02 (UTC)

@Stang：以全部編輯為分母確實是46%，但您沒有排除自動巡查的編輯，如果以需要巡查的編輯為分母，30天內的數值為33%。--Xiplus#Talk 2022年6月10日 (五) 12:46 (UTC)

没有“稳定版本能力”的稳定版本。我反而感兴趣会有多少具有巡查页面功能的编辑（例如新页面巡查或者管理员）会愿意手工标记巡查。为了盐巴而特意弄出一桌子的面包反而有点本末倒置。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月9日 (四) 01:29 (UTC)

成本不高，有一两个人愿意持续做就可以，存废讨论、关注度等很多维护也并没有很多人坚持。我更关心的是，筛出来的有问题或有争议的编辑/编者，是否能得到妥善讨论和处理，以及标记巡查本身的尺度与责任性。--YFdyh000（留言） 2022年6月9日 (四) 09:34 (UTC)

观望，因为似乎正在跑手工自动标记测试，而且也留意到将权限分拆的代码提交（T308153）（PS.如果成功的话，权限组别分配可能会有一些改革调整，例如可能Wikipedia:最近更改巡查可以得到一个职务性的用户组，Wikipedia:巡查豁免權可能也有所调整）。至于有问题的编辑，如果有需要，本来就应该去提报，和过去的做法无异。——Sakamotosan路过围观 | 避免做作，免敬 2022年6月9日 (四) 09:59 (UTC)

客棧方針區升格虛擬內容編輯手冊議案協作告

謹打擾諸位，現虛構編輯指南正處在可能升格階段，是以可能由電遊專案方面活躍編輯加速推進編輯規程化，翻譯、審閱和交換意見可能均有需各有關注涉及虛擬內容之未活躍wikipeoject同好補足之處，已查如歌曲專案之討論版指示為於本版面提起新案，故在此告知，以協調並帶動維基社區更多類似專案協同討論：

該手冊影響範圍可不限於由多個wikiproject可涉及的虛擬事物和跨界產生連續影響關係的系列課題，尤其在本地多個project尚缺少對應專門手冊之下，

總體化之的創作形成、創作內容和創作意義是「可以表述甚麼」並「如何表述這些可以表述的內容」，期待諸位不吝協同參與該總框架手冊的幾大方面，先行給予各自專注方面的智慧和意見，並調動和活躍多方維基人和維基計劃間的互助互利，以補足本地維基參與計劃的系統偏好運作可能遺留的不足之處。謝閱。--約克客（留言） 2022年6月7日 (二) 13:20 (UTC)

悉。( π )题外话：每每觀覽閣下發言，總覺敝人中文造詣尚有諸多不足之處，自愧不如 囧rz……--Rice King 信箱 · 留名．邊緣人_🇹🇼 2022年6月13日 (一) 03:22 (UTC)

（您想多了，情況應該正好是反過來）—— Eric Liu _{創造は生命（留言・留名・學生會）} 2022年6月13日 (一) 13:19 (UTC)

Reply tool for mobile editors

Please see Wikipedia:互助客栈/其他/存档/2022年2月#Reply tool for mobile editors. This will happen on Wednesday. I apologize for the long delay.--Whatamidoing (WMF)（留言） 2022年6月27日 (一) 21:41 (UTC)