维基百科:互助客栈/方针

互助客栈： 消息  方针  技术  求助  条目探讨  其他 |  知识问答

发表前请先搜索存档，参考旧讨论中的内容可节省您的时间。

公告栏

• [公告] 因本站已遭中国大陆屏蔽十年，互助客栈其他区正在讨论设置信息页、全站通知、横幅等事宜，如有意见或灵感请尽快参与讨论。
• [公告] 仲裁委员会已就Mafalda4144、Tisscherry傀儡调查一案达成裁决，敬请社群关注。
• [公告] 事实性修订R7条文、信息框不再显示审查（含发行许可证）／分级编号等、允许在中文段落使用斜体表示英文书名、调整快速删除方针G3条、有关被不限期封禁者的已知已停用多重账号的处置及调整朝鲜半岛用语格式手册有关用旗的规定已经通过。
• [公告] 提议更改人身攻击方针中的“对事不对人”、公式中的斜体使用衬线字体、临时账号IP查看者相关事项、提升巡查员申请建议门槛、批量恢复曾持有巡查豁免权的巡查员相关权限、降低巡查豁免者申请建议门槛及重启《维基百科政策简报》并更名为《维基百科社群简报》及相关共识正在公示，如有意见请尽快提出。
• [讨论] 互助客栈方针区正在讨论调整申请权限与申请解除权限的方针条文与申请区的放置位置及授权过滤器助理与过滤器编辑者访问受保护的变量，请踊跃参与讨论。
• [讨论] 互助客栈技术区正在讨论本地安全投票，请踊跃参与讨论。
• [协作] 第二十三次动员令将于7月5日至9月7日间举行，目前正在讨论固化未来部分动员令筹备事项及协调主题，欢迎踊跃参与！

• [协作] 现有155个页面需维基化，510个条目需清理，9个移动请求正在讨论。

#	💭 话题	💬	👥	🙋 最新发言	🕒 (UTC+8)
1	公共运输相关指引再次讨论	53	15	铁路1	2025-06-13 18:58
2	有关申请权限与申请解除权限的方针条文与申请区的放置问题	67	6	Xiplus	2025-06-19 22:20
3	提议提升巡查员的门槛	67	22	Stang	2025-06-20 11:58
4	重提允许巡查员自我增加与移除自动巡查权/将自动巡查与巡查员权限组分离	113	17	Stang	2025-06-20 18:01
5	在人物传记条目合理使用人物配偶的图片	38	12	Ericliu1912	2025-06-10 23:36
6	“允许在中文段落使用斜体表示英文书名”公示通知	5	1	1F616EMO	2025-06-18 18:38
7	建议增加“姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代”去掉“姓、部、卦、母、国、朝”字之后剩下的东西的“重定向/消歧义”的方针	20	8	𠭞	2025-06-18 16:37
8	为修订存废复核方针放宽临时恢复制度事	1	1	1F616EMO	2025-06-14 22:54
9	提议修订天体收录标准	1	1	自由雨日	2025-06-18 14:26

发言更新图例
最近一小时内
最近一日内
一周内
一个月内
逾一个月
特殊状态
已移动至其他页面 或完成讨论之议题
手动设置
当列表出现异常时， 请先检查设置是否有误

正在广泛征求意见的议题

议题清单

以下讨论需要社群广泛关注：（重新整理） 维基百科格式与命名

Wikipedia talk:命名常规 § 重提在条目标题中正确使用书名号

因此我提议在条目标题中正确使用书名号，无论最终使用甲式还是乙式。

以上。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2025年3月8日 (六) 19:53 (UTC)

Wikipedia talk:命名常规/音乐 § 提议使用拉丁原名作为歌曲的标题

理由如下：

1. 目前流媒体收听音乐几乎碾压传统的唱片音乐，而几乎所有的流媒体服务商都主显原名。使用几个中文汉字会使人感到陌生，是“易于识别”的违反，也不符合“使用常用名称”。有一种下位法违反上位法之感。
2. 中文用户普遍认识26个字母，即使可能无法理解其含义并朗读，但普遍有能力拼写、传递和辨别是否同一单词。
3. 维基百科编者为了符合这一要求，不惜代价地去寻找一个中文名称，最后还弄得读者看不懂，徒劳无功，质量还不高。
4. 大部分译文质量不高，做不到“信达雅”，可能只是一些人为了填补“译名”字段空白的草率产物，也不一定是作者原意。
5. 一些找不到译名的条目和隔壁某百科使用原文，看上去也没什么问题，甚至更美观易懂。

--ZLin2222（留言） 2025年3月17日 (一) 17:08 (UTC)

Template talk:文物保护单位 § 建议文物保护单位模板整合至Infobox historic site模板内

建议{{文物保护单位}}模板整合至{{Infobox historic site}}模板内，以便利统一维护。Sanmosa _新朝雅政 2025年4月27日 (日) 05:46 (UTC)

Wikipedia talk:格式手册/标点符号 § 提案：修订“书1”对于软件名的规定

中华人民共和国《标点符号用法》（GB/T 15834—2011）4. 15.3.3 规定“全中文或中文在名称中占主导地位的软件名”用书名号标注，但是实际上除了电子游戏（如“《原神》”）以外罕见。因此建议“书1”去除这项，并明确电子游戏使用书名号标示。提案如左。

现行条文 书1：标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名、全中文或中文在名称中占主导地位的软件名，电影、电视、诗歌、音乐、雕塑等各类用文字、声音、图像等表现的作品名用双书名号。嵌套书名号时，外层用双书名号，内层用单书名号。

提议条文 书1：标示书名、书名篇名并举、报纸名、杂志名、图表名、文件名，以及电影、电视、诗歌、音乐、雕塑、电子游戏等各类用文字、声音、图像等表现的作品的名称。嵌套书名号时，外层用双书名号，内层用单书名号。 GB/T 15834—2011规定“全中文或中文在名称中占主导地位的软件名”使用书名号标示，但实际罕见。

顺便修改了行文。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月30日 (五) 20:47 (UTC)

Wikipedia talk:格式手册/无障碍 § 推动将Wikipedia:格式手册/无障碍/2025列为指引

目前需要解决的问题大致只有“文字”一章节，不知道有没有熟悉屏幕阅读器的编者，或者有家人、好友是视障人士的，能够解决标注出的问题。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月30日 (五) 22:52 (UTC)

Template talk:Mong § Mong模板的命名问题

有鉴于近日{{Lang-mn}}模板被删除，因此我在思考{{Mong}}模板是否应该采纳如现{{Lang-mnc}}模板一样的命名格式，并占用{{Lang-mn}}的名字，又或是仅简单地将{{Lang-mn}}重定向至{{Mong}}，希望各位就此给予意见。Sanmosa _新朝雅政 2025年6月4日 (三) 03:31 (UTC)

Wikipedia talk:格式手册/文字格式 § 公式中的斜体使用衬线字体

此讨论正在公示；如有意见请尽快提出。

现行条文 公式中的变量符号 变量符号通常使用斜体（E=mc2）。例外的情况包括粗体，或者字母上方带有一个箭头用于表示向量。 有些符号总是不用斜体，包括： 化学元素符号，如H2O 计量单位符号，如kg、m/s 数学运算符号，如sin与ln，sin x、ln (p/p0)

提议条文 公式中的变量符号 参见：Wikipedia:格式手册/数学和Help:数学公式 变量符号通常使用斜体（E = mc2）。例外的情况包括粗体，或者字母上方带有一个箭头用于表示向量。 公式可在<math>...</math>中使用LaTeX标记来排版；对于简单的内联公式，可使用{{math}}及其相关模板。这两种方式生成衬线字体，而不同于默认的无衬线字体。这有助于区分I（大写的i）和l（小写的L），其在许多无衬线字体中几乎相同。 对于独立引用的数学变量，可使用{{mvar}}，它将以斜体衬线字体呈现。对于数学方程，可使用{{math}}。在{{math}}中的变量使用双引号以使其变为斜体。 {{mvar|y}}的值恒为... ⇒ y的值恒为... {{math|''E'' {{=}} ''mc''<sup>2</sup>}} ⇒ E = mc2 有些符号不使用斜体，包括： 化学元素符号，如H2O 计量单位符号，如kg、m/s 数学运算符号，如sin与ln，例如：sin x, ln (p/p0)

提案内容参考了及Wikipedia:格式手册/数学。--Steven Sun（留言） 2025年6月12日 (四) 03:50 (UTC)

Wikipedia talk:格式手册/标点符号 § 协调各地标点规范与实际

鉴于标点符号格式手册多以中国大陆为中心，忽视他地、他国规范、实际乃至中国大陆实际，以及效力不清，提出以下各项修订。各项对应意见请在各章节或此节提出，最下方或许陆续补充。— Gohan 2025年6月17日 (二) 08:51 (UTC)

Wikipedia talk:繁简处理 § 繁体模式以“台湾台语”为正，不受WP:台台限制

当前，中华民国对于台湾话的官方名称为“臺灣台語”，盖该政府的刻意用字，窃以为在繁体模式下不应受WP:台台限制。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年6月19日 (四) 06:38 (UTC)

维基百科方针与指引

Wikipedia talk:删除 § 有关模板的删除理由

有鉴于此前提到的部分用户滥建模板的情形至今仍然持续（1、2、3、4），再加上当时将删除模板的要求改为“多余无用，且影响其他模板命名或者百科运作”的讨论并未有效凝聚社群共识，因此现时中文维基百科存在客观、迫切的必要修订“删除理由”第9款，以遏止滥建模板的情形。Sanmosa _新朝雅政 2025年2月1日 (六) 08:42 (UTC)

Wikipedia talk:页面评级 § 提议废除甲级、乙上级与丁级

现时本站条目质量有实质区分度的等级，是小、初、丙、优良、典范。设置没有有效差异而又没人使用的等级令人望而生畏，先不说激进的废除乙级，已经被社群冷落的甲级、乙上级与丁级诚可删除。--HoweyYuan（留言） 2025年3月7日 (五) 15:22 (UTC)

Wikipedia talk:命名常规 § 重提在条目标题中正确使用书名号

因此我提议在条目标题中正确使用书名号，无论最终使用甲式还是乙式。

以上。 ——魔琴［身份声明 留言 贡献 PJ:NEW23］ 2025年3月8日 (六) 19:53 (UTC)

Wikipedia talk:命名常规/音乐 § 提议使用拉丁原名作为歌曲的标题

理由如下：

1. 目前流媒体收听音乐几乎碾压传统的唱片音乐，而几乎所有的流媒体服务商都主显原名。使用几个中文汉字会使人感到陌生，是“易于识别”的违反，也不符合“使用常用名称”。有一种下位法违反上位法之感。
2. 中文用户普遍认识26个字母，即使可能无法理解其含义并朗读，但普遍有能力拼写、传递和辨别是否同一单词。
3. 维基百科编者为了符合这一要求，不惜代价地去寻找一个中文名称，最后还弄得读者看不懂，徒劳无功，质量还不高。
4. 大部分译文质量不高，做不到“信达雅”，可能只是一些人为了填补“译名”字段空白的草率产物，也不一定是作者原意。
5. 一些找不到译名的条目和隔壁某百科使用原文，看上去也没什么问题，甚至更美观易懂。

--ZLin2222（留言） 2025年3月17日 (一) 17:08 (UTC)

Wikipedia talk:格式手册/两岸四地用语 § 条目内文中提及“国家”的部分直接写“台湾”是否违反CS4D

如死刑存废问题#各国死刑现况中提到

根据国际特赦组织（Amnesty International）的统计……其中被自由之家（Freedom House）评比为完全民主自由的经济高度发展国家而维持死刑的仅有美国、日本及台湾。

个人认为如果前文是“国家”不可以使用“中国大陆”（包括“大陆”，惟在前文未提及“中国大陆”的情况下直接简写“大陆”已违反CS4D）和“台湾”指代两岸政权，应使用中华人民共和国和中华民国完整国号（或使用模板{{PRC}}}和{{ROC}}）来表述。但查阅CS4D发现并没有对该种情况做明确规定，所以我想确认上述内文是否违反CS4D？也希望在CS4D内文中对该情况做明确规定。--忒有钱 🌊塩水あります🐳（留言） 2025年4月6日 (日) 18:40 (UTC)

Wikipedia talk:列明来源 § 强制列明原地更新的来源的存取时间

维基百科:可供查证规定“写入维基百科的内容须要能被读者在可靠来源中得到验证”，一般而言，直接列出来源便可。惟部分资料出自随时原地更新信息的网站（例如MLB.com球员信息^例、社交网站订阅数信息^例），若没有列明何时存取以及提供存档，其来源其实依然不明；若内容已更新，但来源存取日期未更新，更会造成来源和内容不符的情况，即内容无法“在可靠来源中得到验证”。因此，我建议新增以下条文：以上，邀请社群讨论。--1F616EMO（喵留言～回复请ping） 2025年5月31日 (六) 10:18 (UTC)

Wikipedia talk:讨论页指引 § 关于“维护维基百科的方针”

目前这一节翻译自英维于2007年2月14日 (三) 07:27的修订版本108026792，当时英维的讨论页方针只有顾及条目讨论命名空间的状况，故规定“适用于条目的政策亦同样适用于讨论页中”。惟目前版本已经涵盖“所有讨论页及具有讨论性质的项目页面”，使所有讨论符合WP:核心内容方针的标准尺度不切实际。（以防有人曲解我的言论，在此声明：此处言论仅指讨论内容无需死板地符合核心内容方针，惟所有讨论的发言以及结果均只能够提升其原则的应用和解释而不能逾越之。）此外，“maintain”一词亦有“坚持”一说，译为“维护”恐怕是早期的误译。因此，我建议翻译自英维的版本，将之修改如下：修改后的版本更能反映其泛用性，使讨论聚焦于符合维基百科宗旨的主题。以上，提请社群讨论。--1F616EMO（喵留言～回复请ping） 2025年6月1日 (日) 23:52 (UTC)

Wikipedia talk:收录标准/虚构 § 提议修改WP:虚构集合规则2

目前WP:虚构集合规则2为：另外在该集合中符合收录标准或虚构准则的子主题必须至少有一项与该集合主题有直接关联。此规则在我看来 ① 标准不明晰——何为“直接关联”、如何判定“直接关联”都具有一定主观性；② 实际操作上亦少被使用——往往被提删的满足规则1的虚构集合的提删理由是WP:NOTGUIDE。规则2所附例子：例如，有尾巴的宝可梦中，皮卡丘符合收录标准，但由于皮卡丘符合收录标准的原因明显与皮卡丘有尾巴无关，因此，有尾巴的宝可梦不应独立成一个列表。——此例亦可用WP:NOTGUIDE来解释（“有尾巴的宝可梦”已落入“攻略书”范畴，非爱好者不太会关心），而且更易于理解和执行，故在我看来，规则2不如改成：另外在该集合须符合维基百科不是手册、攻略书、教科书。

我觉得规则2与WP:NOTGUIDE虽然条文本身并无关系，但起到的范围限制效果是类似的。而且在执行上不如WP:NOTGUIDE好用、易懂，故不妨直接按照WP:NOTGUIDE的表述。之前在存废复核请求，@Znppo也提出对 WP:虚构集合 的不满；我觉得至少规则2的条文可以适当精进。而且，我觉得WP:NOTGUIDE也需要有一个“本地化”版本、适合ACG专题的版本，因此借此次修订正好取代WP:虚构集合规则2，并附带几句ACG专题的操作说明为宜。

Ping“将Wikipedia:关注度 (虚构事物)立为指引”讨论串参与者：@A2569875、Cwek、Ericliu1912、MeritTim、Milkypine、Sanmosa、SmallTim、Temp3600、Viztor、和平至上。--SuperGrey (留言) 2025年6月5日 (四) 01:25 (UTC)

Wikipedia talk:不要人身攻击 § 提议更改人身攻击方针中的“对事不对人”

此讨论正在公示，直至2025年6月28日 (六) 05:00 (UTC)结束；如有意见请尽快提出。

由于本人认为人身攻击方针中的“对事不对人”有明显欠缺（针对条目内容显然并非“对事”），因此提议以下修改：

现行条文 对条目的内容发表意见，而不是对条目的编辑者；换句话说，请对事不对人。

提议条文 对发生的事实（包括但不限于条目内容、用户行为等）发表意见，而不是对用户本身；换句话说，请对事不对人。

--WiiUf（留言） 2025年6月7日 (六) 05:30 (UTC)

Wikipedia talk:中立的观点 § 对“Wikipedia:中立的观点”最近修改的异议

原标题：对”Wikipedia:中立的观点“最近修改的异议

近日发现，Wikipedia:中立的观点最近做了一次比较大的修改，我认为此修改存在一些问题：

1. 程序问题。说没有讨论吧，好像还讨论了；说讨论了吧，又是针对 Wikipedia:命名常规的讨论。问题是，“中立”是我们的“五大支柱”之一，但“命名常规”不是。这就好比，我们在讨论修订“刑法”的时候，发现我们打算发布的新条文跟“宪法”有矛盾，所以我们就顺便把“宪法”也改了。
2. Wikipedia:是英文维基说的！此修改似乎是完全照搬了英维？（这个大家都懂，就不多解释了。）
3. （重点）凌驾于“支柱”之上。此修改似乎特别拔高了“常用”的地位，特别是使其凌驾于“中立”这一“支柱”之上。“常用”本身只是一条普通方针，是需要与其它规则作平衡的，不是必须的。而支柱是必须遵守的。将任一方针凌驾于“支柱”之上，都是不可取的。
4. 英文与中文的区别。（我英文水平有限，如果这一点说得不对，还望大家多多指教。）在中文里，“不偏向某一方观点”叫“中立”，“不褒不贬”叫“中性”；但在英文里似乎都是用的“Neutral”。所以在英维里，在讲“Neutral”的时候，似乎还包含了“不要褒也不要贬”含义。因此在所用例子中，似乎是有“把使用了贬义词（或褒义词）（而非偏向某一方观点）当作不 Neutral”的情况。如果我的理解没错，那么照搬英维就更不可取了。
5. 晦涩难懂。不光是翻译的问题，英维本身就比较晦涩。当然，这是个次要问题，前面的问题解决了，才需要处理这个问题。

--Ma3r（铁塔） 2025年6月8日 (日) 01:26 (UTC)

Wikipedia talk:维基百科政策简报 § 关于重启维基百科政策简报并更名为维基百科简报

此讨论正在公示7天，直至2025年6月27日 (五) 10:16 (UTC)结束；如有意见请尽快提出。

自2023年2月维基百科政策简报发出最后一刊以来，该报已有多年未曾更新。在这几年间中文维基百科社群的生态已发生很大变化，与全域社群进一步对接的需求也与日俱增，由此若仅将重心放于方针未免有些不足。我希望能通过这份刊物让大家了解中文维基百科的近况，并让中维社群的用户能大致了解全域社群的重大事件。以上。--人间百态,独尊变态(讨论)(签名) 2025年6月10日 (二) 14:22 (UTC)

Wikipedia talk:过滤器助理 § 授权过滤器助理与过滤器编辑者访问受保护的变量

本站计划于6月份部署临时账号，届时，IP地址将被视为敏感的个人身份信息变量（abusefilter-access-protected-vars）并将仅允许管理员访问。本提案旨在建议允许过滤器助理与过滤器编辑者同获得abusefilter-access-protected-vars权限，以确保在临时账号部署后，其对所有过滤器的访问仍畅通无阻。

现行过滤器助理方针 对比起一般用户，过滤器助理可以： 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 允许移除自己账号的用户组

提议条文 对比起一般用户，过滤器助理可以： 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 查看和创建使用受保护变量的过滤器（abusefilter-access-protected-vars） 允许移除自己账号的用户组

现行过滤器编辑者方针 相较于一般用户，过滤器编辑者可以： 创建、激活和取消激活标签（managechangetags） 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 创建或修改滥用过滤器（abusefilter-modify） 允许移除自己账号的用户组

提议条文 相较于一般用户，过滤器编辑者可以： 创建、激活和取消激活标签（managechangetags） 查看标记为非公开的滥用过滤器的过滤日志（abusefilter-log-private） 查看被标记为非公开的滥用过滤器（abusefilter-view-private） 启用双重身份验证（oathauth-enable） 创建或修改滥用过滤器（abusefilter-modify） 查看和创建使用受保护变量的过滤器（abusefilter-access-protected-vars） 允许移除自己账号的用户组

——ZhaoFJx(Talk) 2025年6月10日 (二) 17:51 (UTC)

Wikipedia talk:快速删除 § G15的具体含义

近日的AFD使包括我在内的部分用户想到快速删除方针G15条第4款，但由于用户页指引的两次重大修订（1、2），这使“用户讨论页”一词在G15中的定义变得不明（WP:用户页#术语解释中的“用户讨论页”自然被包括于G15的“用户讨论页”内，但“用户讨论页子页面”与“用户子页面讨论页”是否被包括于G15的“用户讨论页”内无从得知），从而使G15条第4款需要修改。此外，由于临时账号机制的部署，G15条第5款的规定将不再适用（Mediawiki页面称“临时账号有自己的用户页与用户讨论页”），因此G15条第5款也同样需要修改。Sanmosa _新朝雅政 2025年6月11日 (三) 12:47 (UTC)

Wikipedia talk:用户页 § 关于wp:FAKEARTICLE

目前，若WP:FAKEARTICLE成立，绝大多数在用户空间的废弃草稿、幽默内容、久未编辑的沙盒等都应被提删，将影响逾千页面。因此，交予社群讨论。--WiiUf（留言） 2025年6月12日 (四) 04:57 (UTC)

Wikipedia talk:存废复核 § 为修订存废复核方针放宽临时恢复制度事

最近经Wcam提醒，我才发现依据“存废复核方针”规定，临时恢复已删除条目供查看之制度，系置于“处理结果”一段，仅限于管理员特别“要求（社群）介入”时始得应用。我认为这不合理，因为以实务情况而言，若干比较困难的存废复核请求，几乎总是需要相当社群意见以达成共识，很少由管理员自行裁决；而已删条目一般情况下根本难以检阅，何况开放社群就其内容讨论原始存废决定妥适与否。是以仅允许管理员于“结案途中”恢复条目供社群讨论，不免限制过度。另查英文维基百科存废复核请求现行规定，则明文表示：“管理员经常受托恢复已删除页面以供查看，将内容替换为TempUndelete模板，同时允许所有人查阅（编辑）历史”（Admins participating in deletion reviews are routinely requested to restore deleted pages under review and replace the content with the {{TempUndelete}} template, leaving the history for review by everyone.），并未有其他介入要件（其余禁止恢复侵权内容等细节规定均同）。据此，本人提出“存废复核方针”修订案如下：

现行条文 管理员须知 鉴于维基百科:管理员对管理员行为的限制，先前曾以下述形式参与待复核页面相关处理流程的管理员，原则上应避免处理存废复核的提案： 存废讨论的提报、投票与讨论、结束讨论及目标页面处理，以及快速删除、修订版本删除的提报、提出异议、讨论和处理。 处理结果 管理员可就提案作以下回应︰ 维持原决；或 发还至相关存废讨论，即重新提交讨论，先恢复后提案至相关讨论亦可，重新提交讨论时应于新讨论处附上存废复核存档和原讨论存档的内部链接；或 转介至存废讨论，当阁下认为速删决定有违快速删除准则，并应获得全面存废讨论时适用；或 推翻原决并代之以其他操作，唯须列明其他操作为何；或 要求介入，当管理员无法就提案下取决定，尤其涉及内容复审、方针指引规范未明或易于引发争议之提案，管理员可作此决定，要求社群介入讨论，用户则可用上述四项回应表达自己意见。启用此程序时，当事管理员应尽量阐明问题所在，以利讨论。为使社群有足够参与，管理员作此决定以后，须于公告栏或互助客栈发出通知，亦应通知曾参与存废讨论用户。此程序一旦展开，一般为期一周，有需要时可列明理由延长时限，唯切勿缩短期限，亦莫应超越五周之限。期届以后，管理员应依照共识执行结果，结束提案。如果要求介入讨论以后，依旧未达共识，则应以无共识结束提案。在未有新理据前，不建议再就该（等）条目提案。如条目已经删除，管理员可临时恢复页面并悬挂{{Tempundelete}}，以便社群讨论。然而，切勿恢复任何侵犯著作权、有违生者传记方针或其他方针禁止之内容。当然，即使管理员未有作此决定，用户仍可随时就提案发表意见。 切记复核并非再就有问题内容发表意见之时机，而应用以纠正过程中所发生（未有重要新资料所引起）之缺失。故此，无论用户或管理员，使用第四项回应时，“其他操作”应可确切反映共识。

提议条文 管理员须知 鉴于维基百科:管理员对管理员行为的限制，先前曾以下述形式参与待复核页面相关处理流程的管理员，原则上应避免处理存废复核的提案： 存废讨论的提报、投票与讨论、结束讨论及目标页面处理，以及快速删除、修订版本删除的提报、提出异议、讨论和处理。 如条目已经删除，管理员可临时恢复页面并悬挂{{Tempundelete}}，以便社群讨论。然而，切勿恢复任何侵犯著作权、有违生者传记方针或其他方针禁止之内容。 处理结果 管理员可就提案作以下回应︰ 维持原决；或 发还至相关存废讨论，即重新提交讨论，先恢复后提案至相关讨论亦可，重新提交讨论时应于新讨论处附上存废复核存档和原讨论存档的内部链接；或 转介至存废讨论，当阁下认为速删决定有违快速删除准则，并应获得全面存废讨论时适用；或 推翻原决并代之以其他操作，唯须列明其他操作为何；或 要求介入，当管理员无法就提案下取决定，尤其涉及内容复审、方针指引规范未明或易于引发争议之提案，管理员可作此决定，要求社群介入讨论，用户则可用上述四项回应表达自己意见。启用此程序时，当事管理员应尽量阐明问题所在，以利讨论。为使社群有足够参与，管理员作此决定以后，须于公告栏或互助客栈发出通知，亦应通知曾参与存废讨论用户。此程序一旦展开，一般为期一周，有需要时可列明理由延长时限，唯切勿缩短期限，亦莫应超越五周之限。期届以后，管理员应依照共识执行结果，结束提案。如果要求介入讨论以后，依旧未达共识，则应以无共识结束提案。在未有新理据前，不建议再就该（等）条目提案。当然，即使管理员未有作此决定，用户仍可随时就提案发表意见。 切记复核并非再就有问题内容发表意见之时机，而应用以纠正过程中所发生（未有重要新资料所引起）之缺失。故此，无论用户或管理员，使用第四项回应时，“其他操作”应可确切反映共识。

以上，请社群讨论。此处修订案，仅涉及条文搬动，至于是否应比照英文维基百科，于悬挂模板时替换所有内容，本人则没有特别意见。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月14日 (六) 12:35 (UTC)

Wikipedia talk:格式手册/标点符号 § 协调各地标点规范与实际

鉴于标点符号格式手册多以中国大陆为中心，忽视他地、他国规范、实际乃至中国大陆实际，以及效力不清，提出以下各项修订。各项对应意见请在各章节或此节提出，最下方或许陆续补充。— Gohan 2025年6月17日 (二) 08:51 (UTC)

Wikipedia talk:收录标准/天体 § 提议修订天体收录标准

本人认为，目前的WP:收录标准/天体对于“可见天体”的定义不甚明确，故提出以下修订：

现行条文 一个天体应该符合《通用收录标准》或以下任何至少一项准则，方可被收录： 该天体可以仅凭肉眼而无需借助任何工具直接观测。

提议条文 一个天体应该符合《通用收录标准》或以下任何至少一项准则，方可被收录： 该天体可以仅凭肉眼而无需借助任何工具直接观测。

--WiiUf（留言） 2025年6月18日 (三) 06:18 (UTC)

Wikipedia talk:快速删除 § 提案禁止一次性将大量页面提报至速删

如题，今天遭遇快速删除候选520+的“盛况”，导致快速删除候选分类难以运作；然后那一批条目又全部有争议无法快速保留，又得全部打包到AfD，浪费编者时间精力。现建议禁止一次性以同一理由将大量页面提报速删，如有需要应提报AfD。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年6月19日 (四) 13:21 (UTC)

Wikipedia talk:删除 § 在存废讨论中禁止/建议避免使用图示标记立场

目前存废讨论使用众多带有图示的表态模板，例如“(×)删除”、“(○)保留”，共同点是在表态字样前带有着色的文字图示。这种图示过分的强调了删除/保留这种概括的立场，而非持某种立场背后的原因，容易使管理员判断共识时侧重于立场本身而非重视正当合理的意见。因此，我建议参照信息框旗帜“不必要地分散读者的注意力，并可能使众多文段中的特定文段过分突出”而禁用的共识，在存废讨论中禁止/建议避免使用图示标记立场。

英文维基百科曾经达成类似的共识，并最终删除相关投票模板。英维在2005年对{{支持}}、{{反对}}及{{中立}}模板的存废讨论中，编者达成共识，认为这些模板让存废讨论倾向于成为投票而非达成共识之处，且将注意力从编者的意见挪开。后续对其他模板的存废讨论亦继续支持此共识，亦有人指出这些模板会助长投票（而非讨论）的行为。英维社群亦在不同的时间达成同样的共识，供各位参考。

就中维的状况而言，不同于英维模板的昙花一现，{{删除}}、{{保留}}等模板历史悠久，期望用户突然抛弃这类用法而转而手动使用粗体不切实际。因此，我建议在这类模板中检查嵌入页面是否存废讨论，并在存废讨论中隐藏图标，仅保留粗体，例子可见{{删除}}模板的沙盒。另提议在WP:删除 § 存废讨论中添加以下内容：

提议条文

存废讨论是讨论页面存废的场所……

为促进共识的创建，避免讨论流为投票，分散参与者和判断共识的管理员的注意力，进行讨论时不宜/不得用图示强调立场（例如“(×)删除”、“(○)保留”、“(►)移动”等），但使用粗体强调意向并没有问题。{{删除}}、{{保留}}等曾经会输出图示的存废意向模板会在存废讨论页自动隐藏图示，只会输出对应的粗体，可以照常使用。

除共识相当明显的情形……［下略］

关于应该使用“不宜”还是“不得”，私以为两者皆可。以上，提请社群讨论。--1F616EMO（喵留言～回复请ping） 2025年6月20日 (五) 16:12 (UTC)

维基百科提议

Wikipedia talk:新条目推荐/候选 § DYK上首页而地区词未转换

刚刚看首页发现，DYK的“问题”似乎没有要注意地区词转换，如现在有出现公交和高达，明显没有转换。在GA和FA以及新闻动态都因上首页需要注意手动转换的部分，因为我很少看DYK，对于相关运作不是很理解，有疑虑所以提出。--提斯切里（留言） 2025年5月28日 (三) 13:43 (UTC)

Wikipedia talk:维基百科政策简报 § 关于重启维基百科政策简报并更名为维基百科简报

此讨论正在公示7天，直至2025年6月27日 (五) 10:16 (UTC)结束；如有意见请尽快提出。

自2023年2月维基百科政策简报发出最后一刊以来，该报已有多年未曾更新。在这几年间中文维基百科社群的生态已发生很大变化，与全域社群进一步对接的需求也与日俱增，由此若仅将重心放于方针未免有些不足。我希望能通过这份刊物让大家了解中文维基百科的近况，并让中维社群的用户能大致了解全域社群的重大事件。以上。--人间百态,独尊变态(讨论)(签名) 2025年6月10日 (二) 14:22 (UTC)

公共运输相关指引再次讨论

近日整理交通相关条目屡遇交通迷持续加入过度着色的文字以及原创研究内容，因此在此重提创建相关指引，已知目前已有的相关草案有Wikipedia:交通车辆条目指引以及Wikipedia:公共交通路线条目指引，在此提出讨论，希望这次有一个结论。相望能做个了结，拖太久了XD--🚊　铁路Railway ^论．签 2025年4月17日 (四) 04:32 (UTC)

邀请先前参与讨论或编辑的维基人@LuciferianThomas、Ghrenghren、BIT0865、一片枫叶、心平星辰、owennson、台南賴哥、SickManWP、捷利、Cdip150、Olaf8940、Tisscherry、Sanmosa--🚊　铁路Railway ^论．签 2025年4月17日 (四) 04:53 (UTC)

一时忙碌被存档了，再次捡回讨论。--🚊　铁路Railway ^论．签 2025年6月9日 (一) 00:57 (UTC)

交通车辆条目指引

现行条文 无

提议条文 维基百科收录交通车辆相关主题，机动车辆、铁路等车款也能开设条目。但为交通车辆开设条目前，编者务需找出若干可靠、独立的第二手来源，举证主题具备收录标准。一方面，收录标准决定主题是否需要开设独立条目；另一方面，符合收录标准就意味着有优质来源支撑，编者能写出全面的条目。收录标准得证后，编者就可以编写条目。 条目在描述车辆概况的同时，还要像可靠来源一样介绍设计、规格、构造等内容；维基百科不欢迎交通迷内容，编者切勿沉沦于过度的细节。 以下介绍交通车辆主题可能用到的元素，撰写条目时请按实际情况适时选用和调整。如果您有想法或疑问，请在讨论页面进行讨论。除此之外，您还应该熟悉WP:更优秀条目写作指南。 信息框模板 信息框是展示主题关键信息的表格，桌面版浏览多置于条目右上角，流动版浏览仅次于起首段。交通车辆信息框一般包括车型名称、制造商、首次出厂年份、图像等资料。某些技术设置对理解车辆整体至关重要，也会记入信息框。“关键”的车辆信息因车种性质而不尽相同。与所有信息框一样，交通车辆的信息框应该避免琐碎的细节。 您可以在Category:交通信息框模板找到合适的模板使用，一般来说，铁路车辆条目通常采用{{鐵路車輛}}、{{鐵路車輛2}}等，机动车辆通常采用{{Infobox Automobile}}等，具体使用方法请见相关信息框内的文档。 导言 导言应精要概括正文，一般来说会简述制造商、车辆类型等，如车辆被用于公共客运服务，则车辆所属的客运或铁路公司、服务路线、投入服务日期等也可简述。 背景与概述 本段应说明该型车辆出现的背景与开发缘由，例如是否为因应运量成长、汰换老旧车辆、导入新技术，或配合政府交通政策与营运策略所开发。可说明规划与制造过程中的主要考量与阶段目标。若车辆已退役，亦应交代退役决策背景，包括技术老化、维修成本、替代方案等因素。此外，也可概述该车型在所属交通系统中的定位与功能，或介绍其在营运历史中的角色与贡献，例如是否为首批引进某项技术的车型，或曾参与重大路线开通。 规格与构造 介绍车辆的核心技术，详细说明其结构、系统与外观特征。内容可涵盖车体材质、设计风格、动力系统（如内燃、电动、混合动力）、机电设备与各项设备规格，并说明编组形式、定员数量及无障碍设施等乘客相关配置。车辆外观如涂装、标志、显示系统，内装如座位配置、信息显示与空调等。撰写时应依据可靠来源进行整合与概述，避免过度细节化或直接复制厂商资料，并避免使用过度细节化的术语堆砌内容。 各代历程 若车辆型号生产超过一代，或具明确的子型号与改良版本，应在本段加以系统性地区分与说明。可依世代顺序介绍各版本的开发背景、设计调整、生产时程及投入营运的情况，并指出相较前代在技术或使用层面的主要差异。若某一代仅有小幅修改，可简要带过，避免过度拆分。撰写时应聚焦于型号整体演进的脉络，避免逐辆记述个别车辆细节，以维持条目的条理性与通用性。 重大事故 若该型车辆曾涉及重大事故，尤其是造成大量人员伤亡或引发媒体广泛关注者，应于本段简述相关事故。叙述内容包括事故的时间与地点、涉及单位、造成的损害与影响。若事故本身已具备独立条目，则可使用{{main}}作主条目导向，以便读者深入阅读。事故描述应以中立、简洁为原则，避免渲染或情绪性文字。 车辆保存 若该型车辆已退役，并有完整保存案例，应介绍其保存状况与保存地点，包括是否由博物馆、学术单位或民间团体保存，是否对外展示，以及保存的原因或文化价值。若保存车辆为特定号码、原型车或纪念车，也应说明其特殊性与保存背景。此段仅限于有可靠来源佐证之公开保存信息，不应记录私人收藏或网络传言。 参考来源 条目必须遵循可供查证的要求，并将对应的可靠来源以内文引用形式来支持条目。 分类 为方便读者搜索，车辆条目可按核心主题或行业元素归类，如在新干线行驶的车辆应归入Category:新干线车辆。但请注意，分类应简明扼要地描述主题，不可过滥。以蒸汽机为动力的车辆可归入Category:蒸汽机车或其子分类；但纯粹因有明火出现而归类则不合适（例如车辆曾发生火烧车事故而将该车辆归入火灾相关分类则不适当）。过度归类只会淡化分类的应有效用。 应避免的事情 爱好者内容 维基百科不是不经筛选的信息收集处，车辆车次运用、车号机务段分配、改造期程、交车期程、领牌车号、行驶路线、停靠站牌等琐碎信息并不适宜加入到条目内。条目不应存在任何原创研究的内容。如果有必要，可以移到维基教科书、维基学院等其他维基项目，又或者到其他专门的Wikia撰写。 大量的短条目 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。 过多的图片 请勿于条目内放置各车号的照片，于信息框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源链接导引 大量的粗体与文字上色 请勿于条目内为文字过多粗体与上色，行驶路线、领牌车号、特殊备注等，如路线有颜色区分需求请使用表格填色，不要为每个路线明上色。

以上条文由在下草创Cdip150君重整，在此提出讨论与公示。--🚊　铁路Railway ^论．签 2025年4月17日 (四) 04:39 (UTC)

不是，你真确定这是写完的草案吗？Sanmosa _新朝雅政 2025年4月17日 (四) 05:43 (UTC)

还没完成，只是全文拿出来看看各位有哪些修改意见。--🚊　铁路Railway ^论．签 2025年4月17日 (四) 06:22 (UTC)

背景与概述、规格与构造、车辆保存三者好歹先扩充一下才拿出来吧，不然我是真的无法给任何的意见。Sanmosa _新朝雅政 2025年4月18日 (五) 13:47 (UTC)

大致没有太大意见，若有其他维基人发表看法本人会加以回应。--维基病夫_{❤️边缘人小组·签到} 2025年4月18日 (五) 04:03 (UTC)

同Sanmosa，指引仍尚未完善。--Aqurs 2025年4月20日 (日) 14:23 (UTC)

@Sanmosa、Aqurs1：已扩充更新，还请指教。--🚊　铁路Railway ^论．签 2025年4月21日 (一) 08:29 (UTC)

(＋)支持，一堆交通迷写车辆调动、编号，甚至是牵引系统、空调、电池箱的型号和种类，这些琐碎信息完全不是一般人所关心的，也没必要保留。（举例：广州地铁一号线列车、广州地铁三号线北延段列车），我敬佩交通迷实地探访总结资料的能力和勇气，但这不适合维基百科。--自由米花🌾🌼 2025年5月2日 (五) 04:34 (UTC)

“这些琐碎信息完全不是一般人所关心的”，这一点我同意。但是除了维基百科，中国大陆已经没有别的地方可以放置这些琐碎信息了，这是很可怕的事情。交通爱好者群体内部也是有纷争的，写车辆调动的反感写牵引系统的，写牵引系统的反感写车辆调动的，有必要就保留哪些信息达成共识。至少我认为，空调、电池箱可写可不写，但是电机主逆辅逆这三大件要留——缺少任何一个都无法构成完整的牵引/辅助系统。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 05:06 (UTC)

不同意您说的“除了维基百科，中国大陆已经没有别的地方可以放置这些琐碎信息了，这是很可怕的事情。”，(►)移动到维基学院是可行的选择。--自由米花🌾🌼 2025年5月10日 (六) 08:18 (UTC)

我在广州地铁四号线南延段列车条目那里进行过移动尝试，移动内容包括电机、主逆、辅逆的参数，乘客信息系统，以及定型编号列表。结果后来，维基主条目那里，编号表格又被别人加了回去 囧rz…… 表格现在被我改成了默认折叠状态，但是说实话，那个表格其实只要两句话就能说明清楚。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月10日 (六) 12:08 (UTC)

细化“规格与构造”部分如下：

现行条文 介绍车辆的核心技术，详细说明其结构、系统与外观特征。内容可涵盖车体材质、设计风格、动力系统、机电设备与各项设备规格，并说明编组形式、定员数量及无障碍设施等乘客相关配置。车辆外观如涂装、标志、显示系统，内装如座位配置、信息显示与空调等。撰写时应依据可靠来源进行整合与概述，避免过度细节化或直接复制厂商资料，并避免使用过度细节化的术语堆砌内容。

提议条文 介绍车辆的核心技术，详细说明其结构、系统与外观特征。内容可涵盖外观、内装、动力系统、机电设备等。 外观：包括但不限于车体材质、设计风格（含涂装）、显示系统等。 内装：以座位配置和乘客信息系统（PIDS）为主。可将编组形式、定员数量、无障碍设施等乘客相关配置以折叠表格形式列出。 动力系统：包括但不限于内燃、电动、混合动力等，仅需在 Infobox train 模板中说明，再经该处链入相关维基条目，避免条目间的同质化。 机电设备：包括车上、车下两类设备，根据关注程度分为两类。 ① 必选项：牵引及辅助系统（牵引电机、牵引逆变器、辅助电源）。 ② 可选项：包括但不限于空调、高压电器箱、蓄电池充电机等，在 Infobox train 模板中归为“其他电气设备”。 机电设备若确有性能优势，可在条目正文内展开说明，并配上机器外观图（若有）。 以上各项在撰写时，应依据可靠来源进行整合与概述，避免直接复制厂商资料，以及使用过度细节化的术语堆砌内容。在已有参考文献佐证的前提下，机电设备的型号若可通过 Commons 内的照片进行佐证，须将照片链接链入；对于佐证资料无法公开的可靠型号，型号提供者须在条目讨论页说明查证过程，接受条目读者监督。

BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 06:17 (UTC)

“机电设备的型号若可通过 Commons 内的照片进行佐证，须将照片链接链入；对于佐证资料无法公开的可靠型号，型号提供者须在条目讨论页说明查证过程，接受条目读者监督。”原创研究？？🚊　铁路Railway ^论．签 2025年5月8日 (四) 06:56 (UTC)

前半句我说的是 A5 的 TGN51E 那种情况。后半句要不去了。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 07:01 (UTC)

(！)意见：后半句不赞同（该内容发表时已划去）。现场拍摄的照片，是在案件发生现场直接拍摄而成的，它记录了案件发生时的真实情况，没有经过复制或转述，因此符合原始证据的定义。现场拍摄的照片在法律上为原始证据，即在佐证层级方面属第一手来源。依据维基百科:非原创研究:第一手来源只能用于描述性断言。若该照片反映的是一件简单事实且理性且受过教育的非专业人士能够加以验证，则不属于原创研究范畴。—— 西行寺海苔子 ハナノモトニテ 2025年5月9日 (五) 14:34 (UTC)

您所说的这些看似更符合在维基学院发布。个人(－)反对此案。--自由米花🌾🌼 2025年5月10日 (六) 08:23 (UTC)

最后一段的最后一句 —— 若其涉及的内容确实适合写入维基学院 —— 可以去掉。至于其他修改部分，我们有必要就何种信息为“琐碎信息”达成共识 —— 对普通乘客而言，确实只需要稍稍介绍外观和内装即可，但是有的爱好者可能会觉得不够。BIT0865 · Discussion · 燕房线永远的神！ 2025年5月10日 (六) 12:24 (UTC)

在下是认为，如果是来自公开可靠来源所介绍的可以写入，但来自非公开或原创研究的则不予收录，就目前已查询到的，汽车也是有介绍引擎型号等。--🚊　铁路Railway ^论．签 2025年5月13日 (二) 06:49 (UTC)

同意此观点。--自由米花🌾🌼 2025年5月20日 (二) 11:39 (UTC)

附议，此外个人管见以为写到系统件即可，若是仍要再往下写到部分子型号即可，如使用引擎，不需要再对此引擎子型号介绍--消波块（留言） 2025年5月22日 (四) 09:55 (UTC)

公共交通路线条目指引

路线条目目前似乎还很不完善，需再仔细讨论。--🚊　铁路Railway ^论．签 2025年4月17日 (四) 04:39 (UTC)

基本上支持没意见。另想请问例如廉江市#交通，经常于写入交通的条目内看到类似的链接，算是旗帜规范能否清理？--提斯切里（留言） 2025年4月17日 (四) 14:34 (UTC)

不是旗帜，但是是图标。你举出的例子违反了WP:格式手册/图标#百科性用途，按例应当清理。Sanmosa _新朝雅政 2025年4月18日 (五) 13:48 (UTC)

清了。--提斯切里（留言） 2025年4月18日 (五) 14:31 (UTC)

玉湛高速公路，化廉高速公路，理当也要清理？--提斯切里（留言） 2025年4月18日 (五) 14:32 (UTC)

这两个例子牵涉到表格，图标在其中能起视觉提示与改善导航功能的作用，因此这倒不是需要清理的对象了。Sanmosa _新朝雅政 2025年4月18日 (五) 14:43 (UTC)

了解。--提斯切里（留言） 2025年4月18日 (五) 14:58 (UTC)

这样说吧，现WP:公共交通路线条目指引的拟议规定非常生硬、僵化。比如它要求“服务时间及班次：须以表格形式展示数据”、“须以相关模板列出常规优惠”与“分段收费须以表格模式列出”，但这忽略了部分巴士路线的服务时间、班次、常规优惠与分段收费状况较为简单的情形（例：九龙巴士61A线在星期一至五（公众假期除外）只开一班车，故而完全用不着表格；九龙巴士39A线的转乘优惠只需要两个句子就能完全说清楚，故而完全用不着模板；新大屿山巴士36线只有一个分段收费，故而也完全用不着表格）。Sanmosa _新朝雅政 2025年4月20日 (日) 10:26 (UTC)

这方面确实僵化，按里程计价的多级票价线路也不一定需要表格即可直接表示，不定班的线路时刻表经常性改变也没法罗列班次时刻表。或可更改为“建议以表格形式展示数据”？--Jason2016426（留言） 2025年4月21日 (一) 04:29 (UTC)

“建议”仍然有一定的约束性质。Sanmosa _新朝雅政 2025年4月25日 (五) 12:36 (UTC)

那不可能不要这段话的。要是删了，碰到有用新开线路条目时，将一天上百班次的线路时刻表写成一堆数字+顿号怎么办？

要么分类讨论。--Jason2016426（留言） 2025年4月26日 (六) 03:55 (UTC)

我的意思是应该仅限定资料项较多时以表格表示，比如九龙巴士61M线的班次牵涉到的时段非常多，这种情况不以表格来处理是不可行的。Sanmosa _新朝雅政 2025年4月26日 (六) 08:22 (UTC)

如此分类规定表格使用相关内容的话，也是( ✓ )同意的。--Jason2016426（留言） 2025年4月26日 (六) 10:00 (UTC)

( ✓ )同意：北捷所有路线条目，内容结构至今为止仍偏向爱好者内容，主要介绍内容过于稀少。--Sinsyuan✍️ 2025年4月26日 (六) 06:12 (UTC)

其实现在已经有一定数量的铁路线GFA了（WP:优良条目/分类/交通#铁路交通、WP:典范条目#交通运输），或许可以参考现有的GFA来商讨合理的结构。Sanmosa _新朝雅政 2025年4月26日 (六) 16:09 (UTC)

已充新编写，故折叠节省空间。

现行条文 无

提议条文 维基百科收录交通路线相关主题，包括铁路线、公共汽车线等公共交通路线皆可作为条目创建的对象。然而，在为交通路线创建条目前，编者应先寻找若干具可靠性、独立性且属于第二手来源的资料，以证明该主题符合收录标准。一方面，收录标准决定是否有必要为某主题设立独立条目；另一方面，若能证明符合标准，亦代表有足够优质来源支撑，足以撰写出完整且具中立性的内容。确认收录标准无虞后，即可着手撰写条目。 条目在介绍路线时，不应仅列举总站电话号码与地址，而应如同可靠来源般，清楚说设开设背景、路线技术规格与路线特征。维基百科并非交通迷的资料收集平台，应避免陷入过度细节，确保内容具有百科全书的深度与广度。 以下介绍交通路线条目中可能使用的内容结构，请依实际情况灵活选择与调整。如有疑问或建议，欢迎至讨论页面交流意见。编者亦可参阅WP:更优秀条目写作指南以提升条目品质。 讯息框模板 讯息框是呈现主题关键信息的表格，于桌面版多位于条目右上角，行动版则紧接导言段落之后。交通路线的讯息框通常包含路线名称、营运商、营运里程与图像等信息，具体内容可依交通工具类型略有不同。与所有讯息框相同，交通路线讯息框应避免填入过于细琐的信息，以维持条目整洁性与可读性。 您可以在Category:交通信息框模板找到合适的模板。铁路路线通常使用{{Infobox rail system-route}}或{{Infobox rail}}，而公共汽车路线则多采用{{公共汽車路線基礎資訊}}等模板。详细用法请参见各模板所附的文档说明。 导言 导言应精要概括条目的核心内容，简述营运单位、服务范围、通车年份等基本信息。如路线属于某特定系统、属延伸路段或重要支线，也可于导言中简单交代，以利读者快速掌握主题背景。 背景与概述 本段应简要说明该路线的开发背景与缘由，说明其是否因应城市发展、运输需求增加、政府政策推动或营运策略调整而规划建设，并可补充规划过程中的关键考量与阶段性目标。若该路线已停止营运，亦应交代废除决策的背景因素，如运量下滑、维护成本过高、重大灾害影响或已有其他替代方案等。此外，可说明该路线在整体交通系统中的定位与功能，或其在营运历史中的角色，例如是否为该系统首条通车路线、工程分期计划、路线延伸计划、改善/改建计划，或对城市交通发展具有指标性意义。 路线与车站 本段应简要说明该路线的起讫点、行经范围与主要站点，并概述沿线车站的设置情形，包括总站数、平均站距，以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息，能够清楚展现路线的基本架构与服务方式。 使用车辆 本段应介绍该路线所使用的营运车辆，包括主要型号、现役车种与退役车辆等信息。相关内容应依据可靠来源撰写，不应使用私人收藏、网络传言等未经查证的资料。为维持条目的中立性与可验证性，应避免仅依赖营运商或监管单位的第一手来源，而应搭配其他次级来源佐证。 参考来源 条目必须遵循可供查证的要求，并将对应的可靠来源以内文引用形式来支持条目。 应避免的事情 爱好者内容 维基百科不是不经筛选的信息收集处，请勿将车牌、车队编号、车厂等琐碎信息加入条目内。条目不应存在任何原创研究的内容。如果有必要，可以移到维基教科书、维基学院等其他维基项目，又或者到其他专门的Wikia撰写。 大量的短条目 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。 过多的图片 请勿于条目内放置各车号的照片，于信息框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源链接导引。 大量的粗体与文字上色 请勿于条目内为文字过多粗体与上色，行驶路线、领牌车号、特殊备注等，如路线有颜色区分需求请使用表格填色，不要为每个路线名上色。

以参见几篇优良或典范条目初步编写，看是否还有需要修正的地方。--🚊　铁路Railway ^论．签 2025年4月30日 (三) 08:34 (UTC)

• 折叠--🚊　铁路Railway ^论．签 2025年6月9日 (一) 01:55 (UTC)

(＋)支持目前的方针提议，以台湾捷运路线条目为例，虽然高捷黄线有稍微提供路线提案规划等内容，但其余路线条目大都只是写的像一篇游记。另外，主条目（XX地铁/捷运）要介绍的东西一定要聚焦在类似目前为优良级的“北京地铁”内容风格，避免让喜欢城市轨道交通的用户无法了解这条路线和地铁系统的来龙去脉。--Sinsyuan✍️ 2025年4月30日 (三) 08:44 (UTC)

(！)意见：

1.关于架构

概括起来三个字：“分情况”。

陆地公共交通无非是两大类：陆地上跑的公路交通、铁轨上跑的轨道交通。铁轨上跑的又分两种：运营意义上的线路和工程意义上的线路。对于城市轨道交通，诸如北京地铁的单条线路，工程意义上的线路与运营意义上的线路区别不大，内文也更多以运营意义上的线路为主、工程意义上的线路为辅展开叙述的。以上我都不是特别懂，所以我就不展开叙述，大体来看应适配于此方针。

但是换做是中国大陆的铁路线路来说则不然。中国大陆的铁路线路应是工程意义上的线路为主、运营意义上的线路为辅来叙述——因为中国大陆的铁路线路存在着大量跨线运营的列车，以京广铁路为例，对于运营意义上的线路，记叙应落实到具体车次条目（例如D1/2次列车）和某两地间的动车组条目（例如京广既有线动车组列车）去承担。至于“运营意义上的线路为辅”，具体措施就是应考虑以客货运概述的形式记叙（另根据经验来看，铁路干线的运输性质大多数共通，除大秦铁路这种专用性极强的线路外，往往不需要特别提及客货运情况）。因此现行条文中“使用车辆”一章、“概述沿线车站的设置情形，包括总站数、平均站距，以及是否设有快慢车制度、区间运行或跳站服务等。”云云语句不适用于中国大陆的铁路线路。

综上，我个人觉得这样一个指引应参照维基百科:格式手册/电子游戏那样，先分情况讨论布局，然后列举出什么是“必需”、什么是“不需”，什么是“值得一写”。目前的拟议内容里，必需要素的列举过于详尽且与章节布局混同，而事实上这两者在性质上本就不同；而“应避免的事情”一章又拼凑着内容、格式文风、图片等多个领域的内容，而显然这也是需要分开谈论的。

2.关于内容

第一条提及的问题不赘述。

只另说一处：“使用车辆”中为维持条目的中立性与可验证性，应避免仅依赖营运商或监管单位的第一手来源。首先不明白第一手来源与“可验证性”的联系。另外诚然，避免依赖第一手来源的原因是在于第一手来源会出现偏颇，但我不是很能理解，究竟是在什么情况下，作为与该信息联系最紧密、最直接的消息源，营运商或监管单位需要在使用车辆这一方面出现偏颇。我想这句话应该出现在历史部分和事故部分——因为这些部分才有可能出现偏颇。

我也并非是完全的专门人士，这些浅见只供参考。另邀请常在国铁领域活跃的编者@MNXANL参与讨论。-- 西行寺海苔子 ハナノモトニテ 2025年4月30日 (三) 11:17 (UTC)

(！)意见“铁路线”条目中，在指引中应明确line还是service：即{{Infobox rail system-route}}和{{Infobox rail service}}，大部分铁路线条目反而用不到{{Infobox rail}}。line和service应该在何时可作为同一主题方面，我基本同意原作者在“关于条目撰写的主张”中的看法。

而对于其具体结构：什么是应该包含的基本要素？

• line的基本要素：背景、建设及改建的历史、线路走向、车站布置、运营状况、影响等
• service的基本要素：背景、规划及运营调整的历史、运营模式、使用车辆、运营状态（客流）等
• bus route不是很了解，应该和service差不多？

因此，应该参照Wikipedia:格式手册/电子游戏#行文结构章节修改指引语言以明确不同“线路”条目（铁路line、铁路service、巴士route/service）的格式规范，然后再去规定编写风格。--MNXANL 贡献 讨论 2025年5月1日 (四) 01:13 (UTC)+11

(＋)支持此版本的提议条文。(！)意见，小弟总觉得“大量的粗体与文字上色”的部分，可以加入示例供参考，不然大家认为路线的粗体标记与表格填色的定义很广，到时又容易有争议。另提议条文的第一段“然而，在为交通路线创建条目前，编者应先寻找若干具可靠性、独立性且属于第二手来源的资料，以证明该主题符合收录标准。”此段虽然明确列出需有第二手来源，但还是有部分编者的认知有所不同。例如在义大客运讨论页的最新话题。感谢@鐵路1阁下的用心。--英国皇家欧拉夫王子（留言） 2025年5月5日 (一) 02:51 (UTC)

@Olaf8940：颜色在下是认为应全部去除，不过有爱好者会认为路线必着色才能分辨，在下是有加入示例，需讨论，只是这边受模板格式引响无法显示，在原页面是有加入的。--🚊　铁路Railway ^论．签 2025年6月9日 (一) 03:10 (UTC)

(！)意见“铁路线”方面，跨线车怎么处理？

公交/巴士线路方面，相关内容呢？我辣么（那么）大个收费、班次、行车路线呢？

实在不行可能还是得学WP:VGORDER，明确“铁路线路”、“巴士线路”两大类条目分别该怎么写吧。--Jason2016426（留言） 2025年5月5日 (一) 12:20 (UTC)

(！)意见：个人觉得概述章节和序言存在一定程度的功能重复，如果明文写入格式手册会和其他适用于全站的政策相冲突。概述章节可能包含了线路走向、附属设施等内容，在二者不足以分开设置章节的情况下会合并，但应该避免使用“概述”这种命名方法。--屠麟傲血（留言） 2025年5月5日 (一) 13:20 (UTC)

线路的发展历史和功能意义的重要性大于其站数及站距。参考 User_talk:Nrya#广州公交线路条目品质之探讨，提议以下两处调整：

现行条文 本段应简要说明该路线的起讫点、行经范围与主要站点，并概述沿线车站的设置情形，包括总站数、平均站距，以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息，能够清楚展现路线的基本架构与服务方式。

提议条文 本段应简要说明该路线的起讫点、行经范围与主要站点，并概述沿线车站的设置情形，以及是否设有快慢车制度、区间运行或跳站服务等。通过这些信息，能够清楚展现路线的基本架构与服务方式。

现行条文 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。

提议条文 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。撰写条目前，需审慎评估线路的有关背景资料是否足够用于创建条目。可将多条背景资料较少，但功能或走向相关联的线路合并为一个条目撰写，或整理为列表形式。

BIT0865 · Discussion · 燕房线永远的神！ 2025年5月8日 (四) 06:54 (UTC)

明显地不是每一条公交线路都满足关注度，利用GNG评判是合理的选择。--自由米花🌾🌼 2025年5月10日 (六) 08:21 (UTC)

此提案文字涉及事项，铁路车站、物理线路部分业已在维基百科:收录标准/交通中有规定（尽管我个人觉得该方针有后续细化空间），直接内链反而更好。另外，正如此前讨论在下与MNXANL观点，仍呼吁此提案全文应依据依据具体类别分情况讨论。-- 西行寺海苔子 ハナノモトニテ 2025年5月10日 (六) 08:32 (UTC)

我早前已经在不少的港铁路线条目和部分车站条目加入了香港旧报纸的来源。事实上，即使陈年旧事，在网上应该也能找到来源的，如有需要可以参考康文署的香港旧报纸，或是到慧科电子剪报查找。--owennson（聊天室、奖座柜） 2025年5月29日 (四) 09:24 (UTC)

现行条文 无

提议条文 维基百科收录交通路线相关主题，如铁路线、公共汽车路线等公共交通系统，皆可作为条目创建的对象。为确保条目符合Wikipedia:收录标准，编者在撰写前应寻找若干具可靠来源、独立来源，且最好为次级来源的资料，作为条目的撰写依据。来源充足、客观中立的内容才能为读者带来有价值的信息。 收录标准决定是否有必要为某主题创建独立条目。对于交通路线主题，符合标准亦代表已有足够来源支持，得以撰写出具有中立性与百科深度的条目。确认符合显著性后，方可着手撰写条目内容。 条目在介绍交通路线时，应避免仅列举车站、营运时刻或电话号码等浅层信息，而是应该像编写其他百科条目一样，根据可靠来源梳理路线的设置背景、营运特性与发展历程。维基百科并非交通爱好者的图鉴或资料仓库，因此在撰写时应注意内容的深度与结构的逻辑性，避免过度罗列细节，失去百科全书应有的知识体例。 以下各章节介绍交通路线条目中常见的内容结构，实际撰写时，应根据交通工具类型与可得来源的丰富程度，灵活选择与调整。对于路线条目中所涉主体属于铁路系统者，应特别注意“线路（line）”与“服务（service）”的区分；例如，京广铁路作为中国国铁干线，其条目多以线路本身的工程性质为主，并不着重于个别列车班次的营运细节；而城市轨道交通如地铁路线则多以服务为导向，条目内容则偏向于列车行驶模式与服务结构。 讯息框模板 交通路线条目通常会使用讯息框模板，以图表形式呈现基本信息。在桌面版中，此框多位于条目右上角，而在行动版中则紧接导言段落之后。铁路路线条目一般使用{{Infobox rail system-route}}来描述系统中某条具体线路的技术与规划信息，若主题为某段列车服务则可使用{{Infobox rail service}}。公共汽车路线则较常使用{{公共汽車路線基礎資訊}}等模板。不同类型交通工具的讯息框栏位有所差异，请依主题在Category:交通信息框模板找到合适的模板。 需注意的是，讯息框仅为辅助呈现条目整体内容的摘要，其内容应保持简洁明确，避免填入过细的信息，如单一车号、班次细节等，以免削弱条目整体可读性与重点聚焦。 导言 条目的导言应扼要总结主题的核心信息，让读者能迅速了解路线的基本概况。通常包括营运单位、服务范围、通车或设立时间等信息。如果路线属于某一交通系统，或为其支线、延伸段，亦可于导言简要交代，帮助读者创建主题脉络。导言不应代替后续段落的细部描述，而应作为全条目的简明引导。 背景与概述 本段旨在综合说明该路线的设立背景与发展概况，包括建设动机、线路规划、车站配置、运营模式与历来调整等。内容可涵盖城市发展带动的交通需求、政府政策的推动、营运策略的改变等关键因素，以呈现路线诞生与演变的完整脉络。对于尚在规划中的路线，应说明其开发过程、决策依据与预期目标；对于已停用的路线，则应交代停驶或裁撤的背景，例如客流下滑、维修成本过高、重大灾害损毁，或是已出现其他替代方案等情形。 此外，条目亦可简要交代该路线在整体交通系统中的功能定位，例如是否为系统中首条通车的主线、是否属于特定阶段计划，或是否具有试办与示范性质。若条目主体属于工程层面较为明确的干线铁路，亦可补充其设计规模、投资来源、工程期程，及与其他路线的连接状况等信息。以上内容应依据可得来源灵活编排，并与后续章节适度区分，避免重复陈述。 路线与车站 此段应针对路线的起讫点、行经范围、服务区域及主要站点进行说明，并描述其空间走向与营运设计。对于城市捷运与部分市区巴士而言，应说明是否采用区间运行、跳站服务或快慢车制度，以帮助读者理解其服务架构。 然而，若条目主体为干线铁路（例如中国大陆的京沪、京广等），因涉及大量跨线列车与复杂的班次配置，则不宜于本段列出车站细节或车次信息。此类内容宜另置于列车服务或列车车次条目中阐述。 使用车辆 如果交通路线具有特定之营运车辆，且具备公开、可靠来源，则可于本段简述所使用的主要车种与列车型号，包括现役与历史车辆。 参考来源 根据Wikipedia:可供查证的基本原则，交通路线条目中所有具体内容皆应以可公开查证的来源支持，并以内文注解或脚注方式清楚列明。内容应以可靠来源为基础，并优先采用具出版、审查或报导机制的资料。条目应避免以网络爱好者整理的图文信息作为唯一来源，尤其对于技术或历史性叙述，更应检验来源的完整性与公信力。 应避免的事情 爱好者内容 维基百科不是不经筛选的信息收集处，请勿将车牌、车队编号、车厂等琐碎信息加入条目内。条目不应存在任何原创研究的内容。如果有必要，可以移到维基教科书、维基学院等其他维基项目，又或者到其他专门的Wikia撰写。 大量的短条目 通常一个较大的条目能提供对主题更有条理的介绍与背景联系。当大条目能做到时，请不要创建大量小条目。理想的条目是既不过大，也不过小。撰写条目前，需审慎评估线路的有关背景资料是否足够用于创建条目。可将多条背景资料较少，但功能或走向相关联的线路合并为一个条目撰写，或整理为列表形式。 图片与图例 请勿于条目内放置各车号的照片，于信息框模板一张代表即可，其他照片则放入共享资源并于底下纳入共享资源链接导引。 不恰当使用颜色与粗体 请勿于条目内为文字过多粗体与上色，行驶路线、领牌车号、特殊备注等，如路线有颜色区分需求请使用表格填色，不要为每个路线名上色。以下提供一个合宜示例： 备注

根据上面讨论稍微整合。--🚊　铁路Railway ^论．签 2025年6月9日 (一) 01:55 (UTC)

邀请@BIT0865、Owennson、Saigyouji-Noriko、Jason2016426、屠麟傲血、Olaf8940再次审查更新的内容，望能尽快完成指引。--🚊　铁路Railway ^论．签 2025年6月13日 (五) 10:58 (UTC)

有关申请权限与申请解除权限的方针条文与申请区的放置问题

WT:方针与指引#修订方针与指引的命名格式曾经提到有关申请权限与申请解除权限的方针条文与申请区的放置问题，当时Ericliu1912提议WP:解除权限比照WP:权限申请的处理并入WP:申请解除权限，而我则反建议WP:权限申请比照WP:解除权限与WP:申请解除权限的处理分拆方针条文与申请区的页面。考虑到现在距离批量调整规则页面名称已经有一段时间，社群或许应该探讨到底要选择哪个方案，我自己对于两个方案均持开放态度。Sanmosa _新朝雅政 2025年4月20日 (日) 10:12 (UTC)

我主张合并的理由是解除权限方面的方针页跟申请页都比权限申请要短，而且两者并没有扞格问题，不必分立，也方便检阅者一次确认有关要件。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月20日 (日) 12:55 (UTC)

然后刚刚才注意到甚至申请页面整段说明都是“包含引用自维基百科:解除权限方针”，没有任何内容差异，所以实际上两者完全可以合并在一起啊== —— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月20日 (日) 12:56 (UTC)

合并在同一页不易查看方针指引的修订历史。--Xiplus#Talk 2025年4月22日 (二) 15:36 (UTC)

如果走Ericliu1912方案的话，可以让除权申请区改为比照现WP:权限申请的申请区处理，也就是每类除权申请一个独立的子页面。Sanmosa _新朝雅政 2025年4月25日 (五) 12:35 (UTC)

@Xiplus？还是说你比较倾向于分拆WP:权限申请页？Sanmosa _新朝雅政 2025年4月29日 (二) 07:18 (UTC)

我觉得应该废除该页的方针地位，因为该页面几乎都是复述各权限方针的内容而已。如果真的有任何应该属于方针层级的内容，应当拆分到各权限介绍页或另立“权限申请方针”页面。--Xiplus#Talk 2025年4月29日 (二) 14:45 (UTC)

@Ericliu1912。Sanmosa _新朝雅政 2025年4月30日 (三) 01:58 (UTC)

这很值得考虑！—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月30日 (三) 05:54 (UTC)

@Xiplus、Ericliu1912：如此，那WP:权限申请的版面或许需要重新设计，此外WP:申请解除权限引述现WP:解除权限方针的部分也需要作一定的调整，个人建议可以参考现WP:存废复核请求顶部的说明文字处理。Sanmosa _新朝雅政 2025年4月30日 (三) 14:45 (UTC)

改写成最合适的说明文字当然可以，但我不认为现在两个申请页的说明有什么不得不改的问题。--Xiplus#Talk 2025年5月4日 (日) 04:28 (UTC)

@Xiplus：那我尝试在今日稍后给一个方案出来。Sanmosa _新朝雅政 2025年5月8日 (四) 04:47 (UTC)

现阶段拟定的方案是WP:权限申请移除“简介”与“要求”的全部内容，WP:申请解除权限引述现WP:解除权限方针的部分代之以现WP:权限申请“解任”的内容，并将其中指向WP:申请解除权限的内部链接替换为“本页”。另外，为确保页面命名一致性，现建议WP:权限申请更名为“WP:申请权限”，所有子页面同。Sanmosa _新朝雅政 2025年5月8日 (四) 23:48 (UTC)

会废除方针？--Xiplus#Talk 2025年5月10日 (六) 02:55 (UTC)

@Xiplus：会，WP:权限申请的方针地位会被废除。Sanmosa _新朝雅政 2025年5月10日 (六) 10:01 (UTC)

“IP封禁豁免权及确认用户权限除外之权限切勿于本页外申请”一句应修订到各方针页。--Xiplus#Talk 2025年5月11日 (日) 00:53 (UTC)

@Xiplus：可，我明天再看看具体要放到哪个方针页里。Sanmosa _新朝雅政 2025年5月11日 (日) 12:22 (UTC)

所有权限的方针都要吧（这两个除外），除非另立申请权限方针。--Xiplus#Talk 2025年5月11日 (日) 12:55 (UTC)

@Xiplus：刚才统计了一下，理论上需要修订的页面应该包括WP:新页面巡查、WP:回退功能、WP:巡查豁免权、WP:大量讯息发送者、WP:AutoWikiBrowser、WP:大量账号创建者、WP:文件移动员、WP:跨维基导入者、WP:模板编辑员、WP:过滤器助理、WP:IP封禁豁免权授予者、WP:活动组织者与WP:过滤器编辑者，然而其中大部分的页面似乎已经有相关的描述了。此外，我留意到这些页面虽然大多数是方针，但还是有少数几个是指引，是否需要把那几个指引与现非规则的WP:巡查豁免权也提升为方针？Sanmosa _新朝雅政 2025年5月12日 (一) 07:39 (UTC)

用词不一样，并没有禁止在其他地方申请。提升方针与此无关，另案讨论。--Xiplus#Talk 2025年5月12日 (一) 13:01 (UTC)

@Xiplus：那可以调整既有条文的用词至有禁止在其他地方申请的意思，但需要提具体方案吗？感觉这要做比较占这里的版面。提升为方针的事情我打算之后才处理，我也只是询问一下意向而已。Sanmosa _新朝雅政 2025年5月15日 (四) 13:51 (UTC)

（其实不用什么东西都提去方针⋯⋯）—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月15日 (四) 16:17 (UTC)

应该要提具体方案。--Xiplus#Talk 2025年5月18日 (日) 05:13 (UTC)

@Xiplus：具体方案：

• WP:新页面巡查中的“要申请巡查权，请至Wikipedia:权限申请/申请巡查权申请”调整为“申请巡查权者须于Wikipedia:权限申请/申请巡查权提出申请”，
• WP:回退功能中的“任何希望申请回退权限的用户都可以前往Wikipedia:权限申请/申请回退权提出请求”调整为“申请回退权者须于Wikipedia:权限申请/申请回退权提出申请”，
• WP:巡查豁免权中的“如您打算为您自己或其他用户申请此权，请移步至维基百科:权限申请/申请巡查豁免权”调整为“申请巡查豁免权者须于Wikipedia:权限申请/申请巡查豁免权提出申请”，
• WP:大量讯息发送者中的“如您欲成为大量讯息发送者，请至Wikipedia:权限申请/申请大量讯息发送权进行申请”调整为“申请大量讯息发送权者须于Wikipedia:权限申请/申请大量讯息发送权提出申请”，
• WP:AutoWikiBrowser中的“欲于中文维基百科上使用此软件，请至申请页面申请自动维基浏览器使用权限”调整为“欲于中文维基百科上使用此软件，须于申请页面申请自动维基浏览器使用权限”，
• WP:大量账号创建者中的“如您欲成为大量账号创建者，请至Wikipedia:权限申请/申请大量账号创建权进行申请”调整为“申请大量账号创建权者须于Wikipedia:权限申请/申请大量账号创建权提出申请”，
• WP:文件移动员中的“如果您有意为您或其他用户申请文件移动的权限，请到Wikipedia:权限申请/申请文件移动权申请”调整为“申请文件移动权者须于Wikipedia:权限申请/申请文件移动权提出申请”，
• WP:跨维基导入者中的“任何希望申请本权限的用户都可以前往Wikipedia:权限申请/申请跨维基导入权提出请求”调整为“申请跨维基导入权者须于Wikipedia:权限申请/申请跨维基导入权提出申请”，
• WP:模板编辑员中的“如果您想申请模板编辑员的权限，请参见Wikipedia:权限申请/申请模板编辑权”调整为“申请模板编辑权者须于Wikipedia:权限申请/申请模板编辑权提出申请”，
• WP:过滤器助理中的“如果您有意申请过滤器助理的权限，请亲自到Wikipedia:权限申请/申请过滤器助理权限申请”调整为“申请过滤器助理权限者须于Wikipedia:权限申请/申请过滤器助理权限提出申请”，
• WP:IP封禁豁免权授予者中的“符合上述资格要求的用户可在权限申请页面自荐，亦可由其他用户提名”调整为“符合上述资格要求的用户须于权限申请页面自荐或获其他用户提名以提出申请”，
• WP:活动组织者中的“希望申请权限的用户都可以提出请求”调整为“申请活动组织权者须于Wikipedia:权限申请/申请活动组织权提出申请”，
• WP:过滤器编辑者中的“如果您有意申请过滤器编辑者的权限，请亲自到Wikipedia:权限申请/申请过滤器编辑者权限申请”调整为“申请过滤器编辑者权限者须于Wikipedia:权限申请/申请过滤器编辑者权限提出申请”，

以上。Sanmosa _新朝雅政 2025年5月18日 (日) 06:38 (UTC)

个人支持。--自由米花🌾🌼 2025年5月22日 (四) 15:46 (UTC)

这部分没有问题。--Xiplus#Talk 2025年5月24日 (六) 12:56 (UTC)

巡查豁免权一节有“本权限无需由申请者本人提出申请”，这是否表示其他权限必须由本人提出申请，不得提名？--Xiplus#Talk 2025年5月24日 (六) 12:59 (UTC)

@Xiplus：按照过往的理解，确实如此（如果把IP封禁豁免权从“其他权限”排除掉的话）。Sanmosa _新朝雅政 2025年5月24日 (六) 13:26 (UTC)

自动维基浏览器使用权 :“管理员有权在申请者申请机器人权限前拒绝其自动维基浏览器使用权限申请。另外，对于已获机器人审核小组批准运作的机器人，可直接予以授权。”可能需列为方针？--Xiplus#Talk 2025年5月24日 (六) 13:02 (UTC)

可以列为章节方针，又或是如果合适的话，整个页面列为方针也未尝不可。Sanmosa _新朝雅政 2025年5月24日 (六) 13:29 (UTC)

解任一节“如机器人账号同时持有AWB使用权及机器人权限，不受此限并应该依据机器人方针活跃度要求，AWB使用权与机器人权限同步移除。”需移至Wikipedia:解除权限。--Xiplus#Talk 2025年5月24日 (六) 13:06 (UTC)

我无法找到这句话，还请指出出现的位置。Sanmosa _新朝雅政 2025年5月24日 (六) 13:31 (UTC)

应该是在Wikipedia:权限申请#解任。--Hamish T 2025年5月24日 (六) 15:16 (UTC)

@Xiplus、Hamish：那我更倾向于WP:权限申请#解任全段搬运。Sanmosa _新朝雅政 2025年5月24日 (六) 16:15 (UTC)

如果您有读过方针，就应该知道其他的句子都已经存在于解除权限方针。--Xiplus#Talk 2025年5月25日 (日) 12:04 (UTC)

无论如何，这事能办就是了。Sanmosa _新朝雅政 2025年5月26日 (一) 02:23 (UTC)

如果您不熟悉的话，那我直接反对这个提案，该方针没有任何严重问题需要修正，不用浪费大家时间讨论。--Xiplus#Talk 2025年5月30日 (五) 04:47 (UTC)

公示5月8日的提案、5月18日的提案与5月24日的提案7日。Sanmosa _新朝雅政 2025年6月9日 (一) 02:14 (UTC)

上面有点乱，请确定公示提案均未有明确反对？另请重新整理提案内容，感谢。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月9日 (一) 05:51 (UTC)

具体的公示内容如下：

1. WP:权限申请废除方针地位，移除“简介”与“要求”的全部内容，并更名为“WP:申请权限”，所有子页面同。
2. WP:申请解除权限引述现WP:解除权限方针的部分代之以现WP:权限申请“解任”的内容（下条所述的部分例外），并将其中指向WP:申请解除权限的内部链接替换为“本页”。
3. 现WP:权限申请“解任”中“如机器人账号同时持有AWB使用权及机器人权限，不受此限并应该依据机器人方针活跃度要求，AWB使用权与机器人权限同步移除。”一句移至WP:解除权限。
4. 修改下列页面中有关权限申请位置的规定的文字描述：
   • WP:新页面巡查中的“要申请巡查权，请至Wikipedia:权限申请/申请巡查权申请”调整为“申请巡查权者须于Wikipedia:权限申请/申请巡查权提出申请”，
   • WP:回退功能中的“任何希望申请回退权限的用户都可以前往Wikipedia:权限申请/申请回退权提出请求”调整为“申请回退权者须于Wikipedia:权限申请/申请回退权提出申请”，
   • WP:巡查豁免权中的“如您打算为您自己或其他用户申请此权，请移步至维基百科:权限申请/申请巡查豁免权”调整为“申请巡查豁免权者须于Wikipedia:权限申请/申请巡查豁免权提出申请”，
   • WP:大量讯息发送者中的“如您欲成为大量讯息发送者，请至Wikipedia:权限申请/申请大量讯息发送权进行申请”调整为“申请大量讯息发送权者须于Wikipedia:权限申请/申请大量讯息发送权提出申请”，
   • WP:AutoWikiBrowser中的“欲于中文维基百科上使用此软件，请至申请页面申请自动维基浏览器使用权限”调整为“欲于中文维基百科上使用此软件，须于申请页面申请自动维基浏览器使用权限”，
   • WP:大量账号创建者中的“如您欲成为大量账号创建者，请至Wikipedia:权限申请/申请大量账号创建权进行申请”调整为“申请大量账号创建权者须于Wikipedia:权限申请/申请大量账号创建权提出申请”，
   • WP:文件移动员中的“如果您有意为您或其他用户申请文件移动的权限，请到Wikipedia:权限申请/申请文件移动权申请”调整为“申请文件移动权者须于Wikipedia:权限申请/申请文件移动权提出申请”，
   • WP:跨维基导入者中的“任何希望申请本权限的用户都可以前往Wikipedia:权限申请/申请跨维基导入权提出请求”调整为“申请跨维基导入权者须于Wikipedia:权限申请/申请跨维基导入权提出申请”，
   • WP:模板编辑员中的“如果您想申请模板编辑员的权限，请参见Wikipedia:权限申请/申请模板编辑权”调整为“申请模板编辑权者须于Wikipedia:权限申请/申请模板编辑权提出申请”，
   • WP:过滤器助理中的“如果您有意申请过滤器助理的权限，请亲自到Wikipedia:权限申请/申请过滤器助理权限申请”调整为“申请过滤器助理权限者须于Wikipedia:权限申请/申请过滤器助理权限提出申请”，
   • WP:IP封禁豁免权授予者中的“符合上述资格要求的用户可在权限申请页面自荐，亦可由其他用户提名”调整为“符合上述资格要求的用户须于权限申请页面自荐或获其他用户提名以提出申请”，
   • WP:活动组织者中的“希望申请权限的用户都可以提出请求”调整为“申请活动组织权者须于Wikipedia:权限申请/申请活动组织权提出申请”，
   • WP:过滤器编辑者中的“如果您有意申请过滤器编辑者的权限，请亲自到Wikipedia:权限申请/申请过滤器编辑者权限申请”调整为“申请过滤器编辑者权限者须于Wikipedia:权限申请/申请过滤器编辑者权限提出申请”。

以上。整个讨论串没有任何（明确的）反对意见，Xiplus说的“如果您不熟悉的话，那我直接反对这个提案”的前提是我不熟悉相关事宜，然而这个前提并不成立。@Ericliu1912。Sanmosa _新朝雅政 2025年6月9日 (一) 13:47 (UTC)

@Xiplus：看法如何？另外他的反对并非无理，因为你针对“如果您有读过方针”这句话的回复，不过是绕过他的质疑而已。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月9日 (一) 16:04 (UTC)

我倾向于这只是微小的沟通问题，而不是真的有意反对。Sanmosa _新朝雅政 2025年6月10日 (二) 00:44 (UTC)

我想那是因为你此前不甚庄重的态度所导致。在我来看，上面迳为宣告没有反对意见的态度，也与之差异无多。真的只是“微小的沟通问题”吗？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月10日 (二) 09:56 (UTC)

这也不是赌气的理由，赌气对于社群协作并无任何帮助。Sanmosa _新朝雅政 2025年6月10日 (二) 14:09 (UTC)

一堆显而易见的问题都是我提的，修订方针品质这么糟糕，怎么让人支持。--Xiplus#Talk 2025年6月10日 (二) 14:42 (UTC)

很不幸地，我相信我当时对于你说的话的具体含义出现了理解上的偏差。已停止公示程序。Sanmosa _新朝雅政 2025年6月10日 (二) 15:02 (UTC)

(－)反对，废除方针部分没有完整的配套方案，Wikipedia:AutoWikiBrowser、Wikipedia:巡查豁免权不是方针指引，废除方针将导致相关资格要求被免除。--Xiplus#Talk 2025年6月10日 (二) 14:40 (UTC)

干脆只拆页面，不调整文字，这样也不用一个字一个字读方针。--Xiplus#Talk 2025年6月10日 (二) 14:45 (UTC)

@Xiplus：WP:巡查豁免权的情况比较特别，它本身是作为信息页（{{Information page}}）存在的，而根据WP:COVID-19条目共识的前例，如果一个信息页根据共识被认定为规则，那该页面的效力会与方针、指引相当，成为既非方针又非指引的正式规则，因此我不认为废除方针会导致巡查豁免权的资格要求会被废除。我的建议是WP:AutoWikiBrowser也同样列为信息页，这样就能避免WP:权限申请废除方针地位后AWB权的资格要求被废除的问题。Sanmosa _新朝雅政 2025年6月10日 (二) 15:07 (UTC)

“效力会与方针、指引相当”直接就错了，Wikipedia:方针与指引已指出方针和指引的效力差距，我同意信息页可能有共识、是规则，但效力也会比较低。--Xiplus#Talk 2025年6月10日 (二) 15:31 (UTC)

WP:权限申请对于巡查豁免者有最近一年内没有受到封禁的要求，（现在）这是方针层级的，这与“建议门槛为创建75个有效条目”的强制力上有差距。--Xiplus#Talk 2025年6月10日 (二) 15:43 (UTC)

@Xiplus：那我感觉我上面提到的事情就很有必要连带执行了，把所有现非方针的相关页面列为方针即可。Sanmosa _新朝雅政 2025年6月11日 (三) 05:35 (UTC)

您可以先对AWB或巡查豁免个别提案，再回来推进此案，新设立方针指引事关重大，不适合一起推动。AWB现在包含不少可能不需要立为方针指引内容，需要详细规划。--Xiplus#Talk 2025年6月11日 (三) 13:53 (UTC)

WP:AutoWikiBrowser#注册与申请权限列为章节方针即可，“需要详细规划”也未免说得太夸张了。Sanmosa _新朝雅政 2025年6月12日 (四) 00:44 (UTC)

您有确认该章节全部都适合作为方针？没有不合时宜的规则？--Xiplus#Talk 2025年6月12日 (四) 11:36 (UTC)

@Xiplus：那容我确认一下，该章节第五个自然段的内容是否至今仍然适用？经查，其余四个自然段的内容并无不合时宜与不对应现WP:权限申请的描述之处。Sanmosa _新朝雅政 2025年6月12日 (四) 14:47 (UTC)

第一段“由于安全原因，仅限于注册用户申请”到底怎么来的，在有编辑次数作为资格限制下，这句话显得冗余。第三段有任何方针而生的效力？像是不允许短期且量少的申请？若没有要强制要求的话，似乎不需要列为方针。第四段好像是机器人方针的范畴，不专属于AWB的。第五段的审核任务是否应该改成强制要求？--Xiplus#Talk 2025年6月12日 (四) 15:47 (UTC)

@Xiplus：第一段的历史背景我不清楚，但考虑到现时临时账号机制的存在，这句话在现在的情况下仍然是有意义的，毕竟一个临时账号能维持90日，理论上还是能达到相关编辑次数的要求的。第三段在我看来属于建议性质，至少能让一开始打算申请权限的人三思是否真的有需要申请权限。第四段我怀疑是因为之前出过没bot权限AWB批次添加评级模板的job引发争议的缘故，在AWB页面提醒一下还是好的。同意第五段的审核任务应改为强制要求。Sanmosa _新朝雅政 2025年6月14日 (六) 15:05 (UTC)

技术上AWB能授权给临时账号？--Xiplus#Talk 2025年6月14日 (六) 15:31 (UTC)

@Xiplus：不清楚，但可以肯定的是不能排除临时账号（的持有者）真有这种想法，留住第一段好歹能避免一个潜在的问题。Sanmosa _新朝雅政 2025年6月15日 (日) 23:36 (UTC)

其他权限不也是有一样的问题，那是不是应该保留权限申请方针，针对一些通用的定义进行规范？--Xiplus#Talk 2025年6月16日 (一) 12:29 (UTC)

@Xiplus：巡查员、巡查豁免者与文件移动员可以引入同样的要求。其他权限中，有参与日数要求的，参与日数要求为至少90日以上，没有参与日数要求的，临时账号没有任何申请相关权限的合理理由。Sanmosa _新朝雅政 2025年6月17日 (二) 00:27 (UTC)

临时用户不会有用户组。 Stang¹³¹⁴ 2025年6月17日 (二) 02:44 (UTC)

如Stang所说，如果技术上就是无法授权，那就不需要另订规则。--Xiplus#Talk 2025年6月17日 (二) 13:31 (UTC)

@Xiplus：那AWB章节的第一段废除掉就是了。Sanmosa _新朝雅政 2025年6月18日 (三) 07:31 (UTC)

第三段不反对保留。--Xiplus#Talk 2025年6月19日 (四) 14:20 (UTC)

第四段应搬移至Wikipedia:机器人方针#对特定工作项目的额外限制。--Xiplus#Talk 2025年6月19日 (四) 14:20 (UTC)

提议提升巡查员的门槛

原标题：提议提升巡查员及回退员的门槛。修改者：--此条未签名留言由Aqurs1（讨论｜贡献）于2025年4月26日 (六) 12:34 (UTC)加入。

因应此讨论串，提议提升巡查员及回退员的门槛。--Aqurs 2025年4月26日 (六) 08:22 (UTC)

由于已经得知WMF不容许此等方法自动获取“临时IP查看”权限，目前考虑到巡查员门槛仍然过低，继续讨论是否应该提升巡查员的门槛。注册时间也不需要因“查看临时账号IP”而有所限制，暂且改为跟回退的90日，目前提案改为是否将巡查员门槛提升至跟回退一样，谢谢。Aqurs 2025年4月26日 (六) 12:34 (UTC)

提高巡查员门槛

现行条文 巡查员：需编辑至少250次，自首次编辑以来参与维基百科至少30日，最近一年内没有受到封禁（不合理封禁除外），且在过去三个月内（新注册者由注册日起计至申请当日）平均每天的编辑次数多于一次。

提议条文 巡查员：需编辑至少1000次，自首次编辑以来参与维基百科至少90日，最近一年内没有受到封禁（不合理封禁除外），且在过去三个月内平均每天的编辑次数多于一次。

(－)反对：巡查回退员有需要且满足查看临时账号IP信息资格可自行申请，且目前WP:RFR未见积压。Python6345（查论编） 2025年4月26日 (六) 11:24 (UTC)

@Python6345：预见的是社群将会人手授予“查看临时账号IP”的用户组，这样会造成大量积压，跟现在未见积压有什么关系？--Aqurs 2025年4月26日 (六) 11:41 (UTC)

目前有194名回退员和163名巡查员。而考虑到其中有同时持权者且查看临时账号IP权者可以提前申请并在添加用户组后由机器人一次性授予，亦难以预见积压存在。反而大幅增加巡查员门槛会加重巡查积压。Python6345（查论编） 2025年4月26日 (六) 12:16 (UTC)移除于2025年4月27日 (日) 04:53 (UTC)，因为提案内容改变。

(＋)支持，加入一个月的新手显然不适合当巡查、回退员。Пусть от победы☆к победе ведёт! 2025年4月26日 (六) 12:27 (UTC)

@阿南之人：见上方留言，提案修改了，你可能需要再审视一下你的支持票。Aqurs 2025年4月26日 (六) 12:34 (UTC)

（由“180日”改为了“90日”87000812。）——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)

也不一定，我印象最深刻的就是@U:Summerize在未成为延确之前就担任了巡查员，而且行事非常成熟。 ——自由雨日🌧️❄️ 2025年4月27日 (日) 03:17 (UTC)

虽然支持，个人在观察中发现，其实巡查员在事实操作中获取难度高于回退员。--花开夜 _{留言 ·签名 ·贡献} 2025年5月5日 (一) 17:53 (UTC)

我个人还是建议设置更加详细的标准。比如，创建一定数量的条目和DYK，或者一定数量的WP与主条目编辑数量等。--花开夜 _{留言 ·签名 ·贡献} 2025年5月5日 (一) 17:54 (UTC)

(！)意见 没有看到明显依据，个人倾向折中，至少500次、至少60日。--YFdyh000（留言） 2025年4月26日 (六) 14:48 (UTC)

巡查员没必要更严格，巡查员本身没有什么高级权限--百無一用是書生 (☎) 2025年4月27日 (日) 02:31 (UTC)

@Shizhao：我是同意这点，不过回退员为何要求如此高？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月27日 (日) 05:58 (UTC)

WP:ROLL#回退功能的优点也可用于在编辑战中占据优势，此外回退员可以访问私有过滤器的日志。Python6345（查论编） 2025年4月27日 (日) 06:39 (UTC)

1000次确实有些多，另外是否可以增加豁免项，比如老用户以新账号开始、在其他维基有相当权限或者比较多的经验。--Kethyga（留言） 2025年4月27日 (日) 03:12 (UTC)

“老用户以新账号开始”应该视为一个全新的账号，不应进行豁免；其他站点的情况确实可以作为一些参考来稍微降低一些标准，但是不能达到完全“进行豁免”的程度。 Stang¹³⁶⁴ 2025年4月27日 (日) 07:04 (UTC)

(＋)支持提升到与回退员相同。August_{讨论‧签名‧回复请ping} 2025年4月27日 (日) 04:23 (UTC)

(－)倾向反对：目前巡查员申请需要有巡查记录证实能力，且巡查有问题者会在申请阶段被拒绝，不认为有提升门槛之必要。Python6345（查论编） 2025年4月27日 (日) 04:53 (UTC)

(＋)支持，原本条件太宽松，新用户在中文维基百科站务规定还不甚了解时，就能轻易申请，这情况着实不合理。我也认为必须施加更严谨的申请条件，以免浮滥申请权限的情况发生，有些人就是想当一个帽子（维基头衔）搜集狂，最近的不当行为页面刚好有一个例子。--Znppo（留言） 2025年4月27日 (日) 06:57 (UTC)

(？)疑问：请问是哪位仁兄？--自由米花🌾🌼 2025年4月28日 (一) 13:30 (UTC)

U:Peterxy12，编辑数不足100即申请多个本地和全域权限。Python6345（查论编） 2025年4月28日 (一) 13:50 (UTC)

（编辑冲突）我猜他想说的应该是这位，不过这位我觉得不是帽子收集狂而是扰乱了…… ——自由雨日🌧️❄️ 2025年4月28日 (一) 13:52 (UTC)

(：)回应，我说的就是他XD。--Znppo（留言） 2025年4月28日 (一) 14:00 (UTC)

不是扰乱--Peterxy12（留言） 2025年4月29日 (二) 10:27 (UTC)

硬性门槛似乎不用那么高，五百次／两个月应该够吧？另外或应说明这是一般建议门槛，若有显著例外，亦可破格申请。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月28日 (一) 18:31 (UTC)

(＋)支持提高标准--🚊　铁路Railway ^论．签 2025年4月29日 (二) 04:29 (UTC)

纯粹给个建议方向：个人觉得提高门槛也不一定只看编辑数量，也可以从条目编写、模拟巡查和参与条目（存废）讨论等方面考察能力。当然这样就难以量化了。--Steven Sun（留言） 2025年4月29日 (二) 07:54 (UTC)

当前巡查员申请必须有巡查记录，否则会被快速拒绝，且如有用户质疑巡查不当亦需要合理回应。Python6345（查论编） 2025年4月29日 (二) 10:19 (UTC)

如果要提升巡查员的门槛的话，是否应该考虑要求巡查员同时满足巡查豁免者的门槛？Sanmosa _新朝雅政 2025年4月29日 (二) 12:02 (UTC)

我一直很困惑这点。巡查员既然有巡查豁免者的权限，那当然要求不应该低于巡查豁免者，这应该是个逻辑问题吧？（要么就规定巡查员并不能让自己免于巡查，这样也可合乎逻辑。）似乎之前有过多次类似提案但均未通过。 ——自由雨日🌧️❄️ 2025年4月29日 (二) 12:09 (UTC)

我在WT:新页面巡查/存档3#取消巡查员的巡查豁免权已经提出过“医者不自医”的情况，而且也明确指出了“巡查员有巡查别人条目的能力也应该有巡查自己条目的能力”这种说法不对应中文维基百科的现况，但还是存在个别用户对实际情况视而不见的事情。Sanmosa _新朝雅政 2025年4月29日 (二) 12:39 (UTC) 👍1

巡查员身具巡查豁免权、自动免巡印象中算技术问题。您可换角度看，巡查员的豁免与巡查豁免者是相同权限但不同缘由，场地工作人员免于安检/员工通道，极少数嘉宾或委员免于安检，不等于前者需具后者级别。但我仍支持对巡查员被豁免的页面做统计列出并存档以履行复审，或者变相削弱自动免巡（Sakamotosan拒绝接受机器人workaround方案）。--YFdyh000（留言） 2025年4月29日 (二) 20:45 (UTC)

正常情况下，如果巡查员确实有有巡查自己条目的能力，那现状并非一个问题，然而现状并非正常情况，那也就只能如此管制了。Sanmosa _新朝雅政 2025年4月30日 (三) 14:47 (UTC)

显然应该弹劾你所说案例，而非反过来降低全体巡查员授权标准。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月2日 (五) 09:08 (UTC)

这不现实，真按你这样说的话，全部巡查员都得除权。Sanmosa _新朝雅政 2025年5月2日 (五) 13:01 (UTC)

既然全部巡查员都得除权，不妨指出几个近期巡查员滥用巡查豁免的案例。Python6345（查论编） 2025年5月2日 (五) 13:19 (UTC)

拿日期20220626写的条目来说好了：他在今年4月30日创建的马达加斯加起义条目里来源与句号之间不知为何出现了空格，而且条目内的两个来源实际上是同一个来源（Special:Permalink/87050726）；他在同日创建的九州风神条目里来源与句号之间、英文与括号之间也不知为何出现了空格，而且内文的表述也不清不楚，我甚至还不知道九州风神是想要在哪个创业板上市（Special:Permalink/87054660）。Sanmosa _新朝雅政 2025年5月3日 (六) 02:56 (UTC)

然后再拿MykolaHK写的条目举例：克里米亚鞑靼饮食条目是他在昨天创建的，整个条目只有一个来源，“传统菜肴”章节完全没有来源，而且还是点列；开尔文桥站条目是他在今年2月16日创建的，大部分正文文段无来源支持，而且整体的翻译水平实在不太好（比如“且是迄今为止保留此配置的最繁忙的车站”）。Sanmosa _新朝雅政 2025年5月3日 (六) 03:13 (UTC)

对于这点我只能认为做翻译的基本上就是忠实翻译，很少人会自己去找来源，当然如果原本的条目有问题那就两边都挂维护模板就好了¯\_(ツ)_/¯翻译腔也是，也得挂上维护模板。--KurGenera^(留言) 2025年5月3日 (六) 03:25 (UTC)

然而巡查权自带的巡查豁免权使之实际上基本无法实现。Sanmosa _新朝雅政 2025年5月3日 (六) 03:58 (UTC)

(：)回应Sanmosa：谢谢建议。关于克里米亚鞑靼饮食，确实来源较少，会先挂维护模板，但这里我认为点列是可以接受的，毕竟这里是介绍各菜式。而开尔文桥那边虽然有10个来源，但不得不承认正文来源确实较少，这里也会先挂维护模板，另外想问您认为“且是迄今为止保留此配置的最繁忙的车站”这句该如何表达？谢谢。--Mykola（留言） 2025年5月3日 (六) 10:29 (UTC)

“且是迄今为止保留此配置的车站中最繁忙者”或许较好。Sanmosa _新朝雅政 2025年5月3日 (六) 15:05 (UTC)

没有感觉更好。虽然之前也觉得两个“的”不太好，但细看我觉得没问题。问题可能在“保留此配置”的具体意涵（淘汰了吗），繁忙统计范围未指明（线路、城市、全球），以及没有列明来源，{{when}}。--YFdyh000（留言） 2025年5月3日 (六) 15:15 (UTC)

@YFdyh000：你或许需要结合前文来看，不结合前文来看的话，你自然看不出个所以然来。Sanmosa _新朝雅政 2025年5月4日 (日) 01:22 (UTC)

前文也没说月台。--YFdyh000（留言） 2025年5月4日 (日) 03:00 (UTC)

我怀疑是没完全翻译的锅。Sanmosa _新朝雅政 2025年5月4日 (日) 13:09 (UTC)

@Sanmosa：关于克里米亚鞑靼饮食和开尔文桥站，我已经进行大幅修改并补上来源，相信已达标准。我在日后也会再写条目推上DYK，通过后再尝试申请巡查豁免权，以消除疑虑。谢谢提点。—Mykola（留言） 2025年6月8日 (日) 18:07 (UTC)

巡查员理当能巡查任何条目（无论是直接改善或是补充标记），不分对象，那自然也包含自己创建的页面。做不到这点，那就除权，没问题。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月4日 (日) 13:23 (UTC)

很多情况是应该发现、注意和提醒，而做不到弹劾。是提升而非降低标准？--YFdyh000（留言） 2025年5月2日 (五) 22:35 (UTC)

看了一下Wikipedia_talk:新页面巡查/存档3#提案四、Wikipedia_talk:新页面巡查/存档3#使巡查员可以移除或增加自己的巡查豁免者权限，社群似乎比较接受这个方向的变革，社群可以尝试朝着这个方向继续讨论下去，会比较容易形成共识。~~Sid~~ 2025年5月3日 (六) 13:40 (UTC)

(＋)强烈支持，个人认为：

现行条文 巡查员：需编辑至少250次，自首次编辑以来参与维基百科至少30日，

提议条文 巡查员：需编辑至少3000次2000次1500次，自首次编辑以来参与维基百科至少120日90日，

（原本打算想3000次或者5000次的，感觉不现实😂）--KurGenera^(留言) 2025年4月29日 (二) 16:44 (UTC)

改了一下，还是1500次吧。1000次感觉还是太少。--KurGenera^(留言) 2025年4月29日 (二) 16:51 (UTC)

(～)补充：至于巡查豁免权的问题...创建75个有效条目...至少得等鄙人编辑次数上$10^{4}$次才有可能吧...因此还是(－)反对需要同时有巡查豁免权程度...--KurGenera^(留言) 2025年4月29日 (二) 17:12 (UTC)

哥们，这标准太高了。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年4月29日 (二) 20:07 (UTC)

加到跟回退员一样的门槛就好了，同时有巡免的程度对你维来说还是太难了。--SunAfterRain 2025年4月29日 (二) 17:20 (UTC)

(！)意见：之前拆权的反对原因为担心巡查员编辑冲刷最近更改，如此可拆巡查员创建操作自动标记为已巡查，但不知是否有技术难题。Python6345（查论编） 2025年5月2日 (五) 03:22 (UTC)

“之前拆权的反对原因为担心巡查员编辑冲刷最近更改”吗？编辑巡查功能上线没多久，也不温不火。--YFdyh000（留言） 2025年5月3日 (六) 03:42 (UTC)

阅读之前讨论，我认为这则留言的理据是阻止拆权提案通过的主要原因，可参考Hotaru Natsumi案的支持理由。此外如上述提议因技术难题无法解决，本人倾向拆权但允许自我授权。Python6345（查论编） 2025年5月3日 (六) 03:56 (UTC)

不如设置编辑至少500次，注册至少90日，创建不少于10个有效且未被提删的条目，且180日内未被封禁为标准？--FK8438（留言） 2025年5月23日 (五) 00:27 (UTC)

为什么要放宽解封后天数门槛？--Mykola（留言） 2025年5月23日 (五) 00:56 (UTC)

我也挺好奇原因的。--~~Sid~~ 2025年6月6日 (五) 13:51 (UTC)

---

小结：社群对于提高巡查员的建议门槛存在共识，但对于“达到与回退员等同标准”并不存在共识。巡查员作为一个权限并不十分“危险”的用户组，使用过高的标准弊大于利。同时，由于下方达成了“分离巡查员的巡查豁免权限”的共识，无需考虑巡查豁免相关的问题。

现行条文 需编辑至少250次，自首次编辑以来参与维基百科至少30日，最近一年内没有受到封禁（不合理封禁除外），且在过去三个月内（新注册者由注册日起计至申请当日）平均每天的编辑次数多于一次。

提议条文 需编辑至少500次，自首次编辑以来参与维基百科至少60日，最近一年内没有受到封禁（不合理封禁除外），且在过去三个月内（新注册者由注册日起计至申请当日）平均每天的编辑次数多于一次。

需要修改的页面包括Wikipedia:权限申请和Wikipedia:新页面巡查。由于上方讨论持续了很久没有新意见了，暂时在这里放置本修改提案一段时间，之后便进行公示。 Stang¹³¹⁵ 2025年6月16日 (一) 03:44 (UTC)

(＋)倾向支持：或可更严格。--Mykola（留言） 2025年6月16日 (一) 09:17 (UTC)

(＋)支持：妥适而稳重的修订案。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月16日 (一) 15:47 (UTC)

公示7日，2025年6月27日 (五) 03:58 (UTC)结束。 Stang¹³¹¹ 2025年6月20日 (五) 03:58 (UTC)

(＝)中立：标准稍低。--WiiUf（留言） 2025年6月20日 (五) 11:21 (UTC)

重提允许巡查员自我增加与移除自动巡查权/将自动巡查与巡查员权限组分离

已通过：

通过

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

由于我看到上面有这方面的讨论需求，所以我单独拉出来讨论提高效率也较易于分别社群共识。

过往讨论参见Wikipedia_talk:新页面巡查/存档3#提案四、Wikipedia_talk:新页面巡查/存档3#使巡查员可以移除或增加自己的巡查豁免者权限

另外我对于提案是没有什么特别的意见，请不要因为我单独拉出讨论而视为我支持这个提案，谢谢。~~Sid~~ 2025年5月7日 (三) 14:30 (UTC)

@ASid：如果是这样的话，倒不如把讨论拆得更完整些，两个提案各自一个小标题。Sanmosa _新朝雅政 2025年5月12日 (一) 07:44 (UTC)

OK的，不过现在没什么人要参予讨论，看起来又要凉了。:(--~~Sid~~ 2025年5月16日 (五) 01:32 (UTC)

edit.~~Sid~~ 2025年5月16日 (五) 01:33 (UTC)

@SunAfterRain、YFdyh000、Python6345、Kurgenera、自由雨日、鐵路1、August.C、Shizhao、Aqurs1、Znppo、花开夜：Hi here!很抱歉打扰各位了，鉴于讨论冷掉，故我把各位ping过来，

先不说提高巡查员标准的事情，为什么我说不用特地讨论标准的问题，因为“将自动巡查与巡查员权限组分离”已经一定程度上降低巡查员的标准，所以我才会说不用太过在意标准的部分。“允许巡查员自我增加与移除自动巡查权”，则是牵扯到自制力的部分，至于如果有人担心滥用自我授权自动巡查的问题，则以巡查员权限组将报告提到WP:RFDR即可（这部分可以在方针修订特别注明），再麻烦各位多加参予讨论了，谢谢。:)

Sanmosa我就不特别ping了。--~~Sid~~ 2025年5月16日 (五) 01:53 (UTC)

静等具体提案。--$\color {White}{\mathfrak {Kurwa}}$__^{Don't bite!} 2025年5月16日 (五) 02:04 (UTC)

我觉得就算把自动巡查拆掉，巡查员依旧要拉高一些标准，毕竟没有帽子其实也能巡查条目（只是没办法用巡查员的那几个功能而已），并且要巡查条目也要基本理解怎么读条目，我不觉得要求应该比回退员低。--SunAfterRain 2025年5月16日 (五) 11:33 (UTC)

(－)倾向反对：提高硬门槛会让一定巡查经验者被迫再次检查被标记为已巡查之条目，虽必要时可IAR但可能引不必要之争议。如允许非巡查员使用隐藏已巡查的条目则对此(＝)中立。Python6345（查论编） 2025年5月16日 (五) 11:58 (UTC)

拔掉之后管理员授予巡查员时就不太需要考虑巡查豁免权的问题，尽管巡查员可以自我授权，但社群仍然可以监察，如果该巡查员让社群觉得他需要被巡查，那他就不该自我授权，如果自我授权就应该提报到WP:RFDR让社群讨论拔掉巡查员权限组的事情。额外一提但管理员与社群在考虑人选时就要特别评估该人过往的行为是否让人信任他自己的自制力，不过我觉得社群平时就会考虑这点，所以没什么好担心的。--~~Sid~~ 2025年5月17日 (六) 12:32 (UTC)

我依然认为由巡查员自行决定是否拥有巡免权是极其无理的，对单独取得巡免权者也非常不公。要拆就完全拆分，两权不再有任何相关。唯有一点我当时想了一阵也认为可以退让，即让巡查员可以巡查自己的条目，这样可以明确巡查动作与职权相符，避免某些因为他可以巡查其他条目所以他也一定可以保证自己条目质量的逻辑死亡。->>Vocal&Guitar->>_留言 2025年5月18日 (日) 02:58 (UTC)

这也可行。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月18日 (日) 06:42 (UTC)

有条件支持：需可在Special:最近更改中排除巡查员之编辑。Python6345（查论编） 2025年5月18日 (日) 07:40 (UTC)

这个页里任何人的编辑都会列在其中，你是要排除什么？--。->>Vocal&Guitar->>_留言 2025年5月19日 (一) 07:21 (UTC)

一般可使用未巡查变更排除巡免和巡查之编辑。如拆巡查之巡免权且不允许自我授权，则本人需有办法在最近更改中排除巡查员之编辑以避免重复检查可能不需要复核之编辑。( π )题外话本人对回退员之编辑无法单独排除亦不满，但技术上无法排除故未提案。Python6345（查论编） 2025年5月19日 (一) 07:47 (UTC)

我理解了，技术问题恕我我无能为力。--。->>Vocal&Guitar->>_留言 2025年5月19日 (一) 23:46 (UTC)

有条件支持，意见同U:Python6345，希望技术问题早日解决。——南屿小十233（对话 | 贡献 | 签名） 2025年6月2日 (一) 04:57 (UTC)

要这么做当然可以，但我只能说你们看要不要也讨论一下顺便也把管理员的自动巡查一并拆掉，原因是对于巡查员有自动巡查，本就是基于巡查员理应能处理好自己创建条目的信任，现在这种信任要单独拉出来讨论当然可以，管理员也理应如此，因为不是所有管理员都会写条目，我过往也不是没看过管理员写的东西，需要做一步处理。至于无理的部分我只能说这是对现有巡查员极度的不信任，对单独取得巡查豁免权的人不公的部分，如果这样的话我认为社群早该把巡查员权限组的自动巡查拆掉，而不是拖到现在，所以这里我不是很明白不公在哪，巡查员相对于巡查豁免权本就是比较好申请的，这我不否认，然而在怎么样都不该说这是不公，如果不公的话那社群早该拆解巡查员权限组。:(

额外一提，要这样做的话请自己说服表示这会大幅度增加巡查员负担的意见。:)

有人说管理员拆掉自动巡查，那自动巡查要谁授予，那当然还是管理员可以自我授权，同样的管理员滥用自我授权，那这种就应视为滥用权限，该除权，不过我知道社群没那个时间与精力以这种理由除管理员权就是。:(--~~Sid~~ 2025年5月18日 (日) 13:53 (UTC)

有些常年提案在若干年后也会有通过的一天，我不认为社群过往的决定能说明什么问题，相反反映出社群对巡查问题、对条目质量问题一贯的漠视。

经常创建新条目的巡查员自然已经达到巡查豁免者门槛，那么他们当然可以直接申请巡免权，不存在大幅增加巡查员负担的问题。

另外关于管理员，Stang已经提过相同意见，我完全同意。--。->>Vocal&Guitar->>_留言 2025年5月18日 (日) 23:30 (UTC)

即便如此我仍认为“单独取得巡查豁免权的人不公”这里不该说不公，这个说法相当的不好至少我来说。此外你的想法我没意见，然而基于过往的讨论，我看到大家最可以接受的方式，仍然是这个，这次的讨论以目前来看也没什么人反对这个变革方式，我还是建议你可以考虑接受这个变革，起码有在改变，而不是僵持不下导致原地踏步。我不是要改变你的想法什么的，你可以继续坚持您的想法，但起码让情况有所转变，如果未来社群或您发现很多巡查员滥用自我授权，您再将情况提出来要求移除也不迟不是么。:)

管理员权限拆解的部分，我认为可能要再等等，因为过往的讨论针对这部分没有很多，应该没办法一并处理，社群对此可能会有很多地方需要磨合，我建议先处理巡查员权限组的部分。:)--~~Sid~~ 2025年5月19日 (一) 01:09 (UTC)

句句没意见，句句在反对，大可以直接一点反对就行了，我的案也不缺你一票反对。这个案过不过对我一点影响都没有，甚至我也是巡查员我的权限还会变少，我倒是很希望反对我案的巡查员一起来对赌，只要我案通过，大家一起永久辞任巡查员，看看到底是谁舍不得这顶帽子。

上一句还在说管理员也理应如此，下一句就变成认为可能要再等等，变脸变这么快不怕自己信用破产吗？--。->>Vocal&Guitar->>_留言 2025年5月19日 (一) 07:21 (UTC)

?--~~Sid~~ 2025年5月19日 (一) 08:24 (UTC)

我会说要再等等是因为这件事情不是我一个人说得算，社群过往也没有讨论，我没有任何基础推动。

我会说理应如此，这是基于我的观察而得出想法。

我建议你试着接受，是因为社群目前并整体上并不怎么接受你的意见。

我没意见也确实是真的，我不知道我话讲这么白，原因也说明白，还要被你冠上一句信用破产，你要跟别人对着干，对着骂我没意见，请不要坡及我。--~~Sid~~ 2025年5月19日 (一) 08:32 (UTC)

另外我也不知道你这是要赌什么，这有什么好赌的，不是很明白你的逻辑。--~~Sid~~ 2025年5月19日 (一) 08:36 (UTC)

我也再次澄清

Wikipedia:互助客栈/方针#c-ASid-20250519010900-Ohtashinichiro-20250518233000这里我有说到“基于过往的讨论，我看到大家最可以接受的方式，仍然是这个，这次的讨论以目前来看也没什么人反对这个变革方式，我还是建议你可以考虑接受这个变革，起码有在改变，而不是僵持不下导致原地踏步。我不是要改变你的想法什么的，你可以继续坚持您的想法，但起码让情况有所转变，如果未来社群或您发现很多巡查员滥用自我授权，您再将情况提出来要求移除也不迟不是么。”

我是要说服你暂时接受，让变革有所推动而不是在原地踏步，这是基于社群的讨论，而不是我的意见，你要坚持照着你的想法变革你可以说，用一副咄咄逼人的样子在对话，那你请自便。--~~Sid~~ 2025年5月19日 (一) 08:49 (UTC)

要这么做当然可以也是你说的，说服你暂时接受也是你说的，从我的角度我只看到你在变来变去，而没有对提案的实质意见。你如果真的没有意见，为什么反复搬出社群（还是两年前的），要建议我说服我接受呢？这一次的讨论里连你在内只有三个人回复了我，你为什么就判定现在的社群不接受我的意见呢？你有没有研究过我上一次为什么故意提一个很奇怪被社群全面反对的方案？？为什么你的案就是变革有所推动，那如果你来支持我的案不就是变革大大地推动吗？--。->>Vocal&Guitar->>_留言 2025年5月19日 (一) 23:44 (UTC)

我已经跟你说明过我对你的意见是真的没意见，社群即便执行你的方案，我也不会有意见也更加不会反对，这对我也没什么影响，也跟你说明过我不是要强行改变你的看法，所以你请自便吧。:)

如果需要帮你另开一个章节来讨论你的方案，我很乐意协助。此外我相信你对我的部分回应仍有些许疑惑，这里也跟您说声抱歉，我不太想特意解释。:)--~~Sid~~ 2025年5月21日 (三) 11:48 (UTC)

我很难想象移除“被认为是社群中有经验的成员”的管理员之自动巡查权限的必要性。如果连管理员权限都要如此阉割，那站内还能有谁符合具备自动巡查权限的要求？——南屿小十233（对话 | 贡献 | 签名） 2025年6月2日 (一) 04:46 (UTC)

大致上支持“默认不巡查但可自行选择”的这个方向，有具体方针上的新增再看。--Aqurs 2025年5月19日 (一) 03:24 (UTC)

将自动巡查与巡查员权限组分离

“将自动巡查与巡查员权限组分离”已经上面是确定的共识，然而措施的部分仍然有人不同意，所以我开了下面的章节讨论，请注意这个只是确立“将自动巡查与巡查员权限组分离”的共识。 公示7日，2025年6月1日 (日) 13:34 (UTC)结束~~Sid~~ 2025年5月25日 (日) 13:34 (UTC)

请各位查看这则澄清留言，谢谢。--~~Sid~~ 2025年5月27日 (二) 13:59 (UTC)

这种提案居然能走到公示，真是神奇。唉。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年5月25日 (日) 15:47 (UTC)

那我觉得不如一并将“自动巡查”这个操作彻底拆分出来，包括巡查员和管理员都不应该自动获得这个权限。另外我觉得最大的遗憾就是技术上的问题导致PageTriage没法进行部署，不然整个操作都是水到渠成的：“巡查”这一操作只针对主空间的条目，可以反复对一个条目进行“巡查”（也就是标记可以逆操作），再加上配套的ui和脚本；“自动巡查”这个操作也只针对主空间新建的页面这个行为，也不会给巡查员带来很大的负担。 Stang¹³³⁴ 2025年5月27日 (二) 06:58 (UTC)

这部分没什么人去讨论到，现况无法处理，强硬公示会被说没有共识为何可以公示，您有空的时候可以推一推社群讨论。🫠--~~Sid~~ 2025年5月28日 (三) 05:50 (UTC)

可以，我就是顺口一说，公示的内容还是只针对巡查员的。另外再顺嘴一说，一些全域权限（比如全域回退员）附带的自动巡查功能实际上也是应该被去除的，只是做起来比较麻烦。这两个地方可以在未来如果需要的时候作为参考。@ASid： Stang¹³³³ 2025年5月28日 (三) 05:55 (UTC)

我很难想象移除“被认为是社群中有经验的成员”的管理员之自动巡查权限的必要性。如果连管理员权限都要如此阉割，那站内还能有谁符合具备自动巡查权限的要求？——南屿小十233（对话 | 贡献 | 签名） 2025年6月2日 (一) 04:59 (UTC)

公示通过—WiiUf（留言） 2025年5月31日 (六) 16:35 (UTC)

@WiiUf：bro是不是忘了5月有31天 Stang¹³³⁰ 2025年6月1日 (日) 04:53 (UTC)

啊啊啊，抱歉--WiiUf（留言） 2025年6月1日 (日) 10:00 (UTC)

@WiiUf：公示期现在是否已完结？Sanmosa _新朝雅政 2025年6月4日 (三) 04:03 (UTC)

已经过几天了。- - 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年6月4日 (三) 04:08 (UTC)

是的呀。-- WiiUf🐉🕯️ 2025年6月4日 (三) 04:34 (UTC)

• 是因为需要避嫌，所以需要换人宣布公示结果？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年6月4日 (三) 04:36 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

提案“删除巡查员附带的巡查豁免权”已通过，下方段落将讨论具体如何执行，以及相关配套设施事项。 Stang¹³²⁶ 2025年6月4日 (三) 12:02 (UTC)

@Stang：（调整了关闭范围并将公示章节降为四级章节）--SunAfterRain 2025年6月4日 (三) 12:07 (UTC)

自Special:固定链接/87784727#提议提升巡查员的门槛起拆分为独立章节。--Steven Sun（留言） 2025年6月16日 (一) 10:36 (UTC)

配套措施

讨论区

这里是讨论拔除后的配套措施，鉴于上面讨论的情况，我不想要来干涉这里的讨论了，即便我是没意见的，所以请各位自便。~~Sid~~ 2025年5月25日 (日) 13:34 (UTC)

请注意，本人同意两权分立的前提是允许巡查员保有巡查自己条目的权力，否则本人不会支持修订有关政策。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月25日 (日) 14:15 (UTC)

另外，我需要提出，原因取得巡查权限而合并巡查豁免权限者，届时均应自动重新授予之。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年5月26日 (一) 08:50 (UTC)

我开出了第一炮Wikipedia:权限申请/申请巡查豁免权#User:A2569875。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月27日 (二) 03:15 (UTC)

为什么巡查员要保有巡查自己条目的权力？本站上除非明显破坏，管理员可以删除自己添加快速删除模板的页面吗？ Stang¹³³⁴ 2025年5月27日 (二) 07:00 (UTC)

原本是巡查豁免者，后来变成巡查员的巡查员本来就应该要保有巡查自己条目的权力。不然申请成为巡查员成为了处罚？？？？ 处罚禁止继续巡查豁免者？？？？？？？？ 这样我申请巡查员我岂不是笨蛋？？？？ 申请了个处罚？？？？ 处罚自己？？？？ 我申请巡查员时你哪只眼睛看到我申请“巡查豁免者除权”？？？ 你没事除我权理由是？？？ 很遗憾我只能理解为处罚。 @Stang：另见我在Wikipedia:权限申请/申请巡查豁免权#User:A2569875的发言。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月28日 (三) 06:14 (UTC)

如果你曾经是巡查豁免者，在权限相关的配置更新之后就会被重新授予巡查豁免的权限，这个你无需担心。@A2569875： Stang¹³³³ 2025年5月28日 (三) 07:34 (UTC)

• 不是“如果”，是事实@Stang：。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月28日 (三) 08:13 (UTC)

我问的这个问题好像没人讨论啊…如下措施实施后，巡查员是否可以标记自己的条目为已巡查？如果不能，看起来好像没法使用过滤器来自动阻止，只能人工的来发现 Stang¹³¹⁰ 2025年6月20日 (五) 10:01 (UTC)

个人认为删除权限和标记巡查权限还是不太一样的：删除操作易引发争议，且删除后的内容对普通用户不可见，不易于复查，因此删除操作需要两名用户完成。而巡查操作争议较少，且易于复查，因此由一个用户完成（即巡查自己创建的条目）不会有太大的风险。--Steven Sun（留言） 2025年6月20日 (五) 12:24 (UTC)

提案区

Python6345提案之一

• 技术上移除巡查员之自动巡查权。
• 允许巡查员自我授权或申请巡查豁免权。
• 自我授权滥用时应同时除巡查权，申请权限滥用时仅除巡免权。

如拟议二无法实现则本人支持该方案。Python6345（查论编） 2025年5月28日 (三) 07:09 (UTC)

“允许巡查员自我授权”意义何在？ Stang¹³³³ 2025年5月28日 (三) 07:37 (UTC)

参阅该疑虑，本人认为自我授权时可默认巡查员为自身条目摁下巡查按钮，此时除权也应对比滥用巡查权。Python6345（查论编） 2025年5月28日 (三) 09:45 (UTC)

有条件支持，但同时也希望技术问题早日得到解决，避免站务巡察工作积压。——南屿小十233（对话 | 贡献 | 签名） 2025年6月2日 (一) 05:01 (UTC)

抱歉，但我看不出这样分离的意义在哪里，只能(－)反对--SunAfterRain 2025年6月4日 (三) 12:11 (UTC)

Python6345提案之二

• 技术上禁止巡查员创建操作自动标记为已巡查。
• 出于尊重，为现有巡查员授巡查豁免权。

本人希望之方案。Python6345（查论编） 2025年5月28日 (三) 07:09 (UTC)

这是不可能的，目前自动巡查不区分这个。如果要在技术上支持这个功能，一个方法是Xiplus的一个分割创建/修改巡查的patch，但是code review方面已经很久没动静了；另一方面是引入PageTriage这个扩展，但是这个目前进度非常缓慢。另外“出于尊重，为现有巡查员授巡查豁免权”的意义何在，如果都授予了还分割什么权限啊。 Stang¹³³³ 2025年5月28日 (三) 07:41 (UTC)

参阅本人附加提案，可能有部分巡查员曾有巡免或条目已符合巡免标准。Python6345（查论编） 2025年5月28日 (三) 09:42 (UTC)

不是“可能”，是活生生在你面前。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年5月28日 (三) 09:51 (UTC)

如果要在技术上支持这个功能，一个方法是Xiplus的一个分割创建/修改巡查的patch，但是code review方面已经很久没动静了；另一方面是引入PageTriage这个扩展，但是这个目前进度非常缓慢本提案为理想提案，如技术上无法实现本人无能为力，请参阅替代提案。Python6345（查论编） 2025年5月28日 (三) 09:49 (UTC)

显然，原本已持有豁免权限（然后因并入而取消）的巡查员，在权限分割当下仍持有巡查权者，均应返还巡查豁免权。因为权限分割纯粹是技术问题，与往后是否弹劾无涉。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月5日 (四) 13:11 (UTC)

注：此处原有文字，因为本人眼瞎，已由Ohtashinichiro（留言）于2025年6月5日 (四) 13:33 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

你确定吗？-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年6月5日 (四) 13:26 (UTC)

(！)抗议“不存在返还一说。”我都讲三次了，你们是故意当耳边风的吗？，如果是故意的，ANM见。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年6月5日 (四) 13:29 (UTC)

是我眼瞎，我收回言论，诚恳致歉。->>Vocal&Guitar->>_留言 2025年6月5日 (四) 13:33 (UTC)

上方讨论已指出多名巡查员之条目不符合巡免质量，且涉有曾持巡免权者。故本人认为应集中讨论重审所有曾有巡免权之巡查员是否能于拆权后重获巡免权。Python6345（查论编） 2025年6月5日 (四) 13:29 (UTC)

• -- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年6月6日 (五) 00:43 (UTC)

注：此处原有文字，因为误会，已由宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️）于2025年6月5日 (四) 14:02 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。

误看成同一人留言。且我已经重新申请权限，“理论上”应该可能大概也许不会影响。-- 宇帆-娜娜奇🐰鲜果茶☕在维基百科寻求休闲是否搞错了什么（☎️·☘️） 2025年6月5日 (四) 14:02 (UTC)

若有人不合格，请届时个别提出。请注意，原本拿过巡查豁免者，都是经过社群审核通过。我们这里应当专注处理技术问题，若认为达不到标准要除权，就应该重走程序，不是借此机会“一刀切”。除非默认烂人过半，否则此事免谈。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月6日 (五) 03:49 (UTC)

请@Sanmosa前来说明。Python6345（查论编） 2025年6月6日 (五) 04:00 (UTC)

问题在于巡查员就从来没被特地检验过写条目的能力，Ericliu1912的言论基本上就是在令整件事情变得完全无法检验，他的reluctance没有把授权应有的谨慎当一回事。“巡查员从来没被特地检验过写条目的能力”是社群的共业，因此其成本必定要由社群整体负担，但看起来Ericliu1912似乎非常不愿意这样做。个人较倾向于下方的Python6345提案二之附加。Sanmosa _新朝雅政 2025年6月6日 (五) 07:24 (UTC)

现在的问题是，你所假定“曾持有巡查豁免权而后升格之巡查员一般没有写好条目的能力”一事，并没有确凿根据，而且不合常理。你上方的说法，更是混淆普通巡查员及合并巡查豁免权的巡查员；后者申请巡查豁免权限之际，本来就已经过“特地检验”，不存在你所谓“社群共业”问题。请注意，我从来不支持“为现有（全部）巡查员授巡查豁免权”，而仅是希望把原本谁有的权限还回去。随意基于假设剥夺他人权限，才真正缺乏“应有的谨慎”。如果你所说要处理的特别情况，例子举不出来，就不要诉诸情绪勒索；若例子真能举出来了，就去办那些例子。不清楚这有什么好讨论的。甚至我不清楚你我立足点是否相同，搞不好其中误会可大了，根本不是在谈一件事。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月10日 (二) 09:58 (UTC)

我们这里探讨的不是“自动恢复曾持有巡查豁免权的巡查员相关权限”吗？请问这有任何问题么？ Stang¹³²⁰ 2025年6月10日 (二) 11:26 (UTC)

我看混了，上面的留言让我以为你们在说的是所有巡查员在权限分拆后自动授予巡查豁免权。Sanmosa _新朝雅政 2025年6月10日 (二) 15:12 (UTC)

上方长期讨论可判断“批量恢复曾持有巡查豁免权的巡查员相关权限”已达成共识， 公示7日，2025年6月27日 (五) 09:54 (UTC)结束。具体名单会在统计之后生成。 Stang¹³¹⁰ 2025年6月20日 (五) 09:54 (UTC)

Python6345提案二之附加

由于确有多名巡查员所创建条目不合格，或可在授巡查豁免权之前全部公示，如公示期有其他巡查员反对则需讨论。Python6345（查论编） 2025年5月28日 (三) 07:09 (UTC)于2025年6月10日 (二) 10:30 (UTC)撤回，无人可证大量曾有巡免之巡查员滥用巡免权以至于需集中重审，故支持授予所有曾有巡免权之巡查员巡免权。

RainSun8942提案

• 取消自己的编辑自动标示为已巡查，但仍可以巡查不具备巡查豁免权限之编辑，仅具备巡查豁免权限方可自动标示为已巡查。
• 由于巡查豁免门槛较高，巡查门槛较低。除可以申请巡查权外，符合巡查豁免申请资格也可申请巡查豁免权限。

以上不知第一项技术上是否可行，另外管理员是否也需要比照办理。--雨朝_{Talk#SamekoSaba🐟} 2025年6月5日 (四) 05:09 (UTC)

1不可行，标记为已巡查是不可逆的操作。2完全可以。管理员是否比照我觉得一步步来比较好，先把巡查员的情况处理好。 Stang¹³²⁵ 2025年6月5日 (四) 08:27 (UTC)

您看起来好像搞错了，我是指将自己的编辑取消自动标记为已巡查，而不是将已巡查逆转为未巡查的状态。--雨朝_{Talk#SamekoSaba🐟} 2025年6月5日 (四) 09:22 (UTC)

原来如此，我理解错了。你的1所表述的就是上方共识事实上的效果：巡查员自己的编辑不再被自动标记为已巡查，他们仍然可以巡查其他无巡查豁免权的用户的编辑。 Stang¹³²⁵ 2025年6月5日 (四) 09:32 (UTC)

是的，仅取消巡查员自己的编辑自动标记为已巡查，此外1有提到自我巡查的部分，是否可以将等候巡查的按钮隐藏?--雨朝_{Talk#SamekoSaba🐟} 2025年6月5日 (四) 10:21 (UTC)

@RainSun8942：“等候巡查”的按钮是在哪里的，可以描述一下吗？咱因为不是巡查员看不到。猜测隐藏起来不难，来点css魔法就行了。 Stang¹³²² 2025年6月9日 (一) 01:04 (UTC)

降低巡查豁免申请要求

创建75个条目的要求没查到当年相关讨论记录，大概是借用enwiki的标准。而enwiki早已将此标准降为25个条目。个人认为至少要将标准降低到50以下，最好是25-35之间。--Steven Sun（留言） 2025年6月6日 (五) 03:23 (UTC)

(！)意见：本人认为硬标准可降至创建10个条目，但需要他人提名或最少一名延确支持后管理员可赋权。Python6345（查论编） 2025年6月6日 (五) 03:52 (UTC)

不确定延确水平。前提定在两名有巡查权限者（净）支持如何？毕竟巡查豁免主要影响巡查员的工作。--YFdyh000（留言） 2025年6月6日 (五) 05:19 (UTC)

(＋)支持将前提定为需巡查员同意，但(－)反对投票。Python6345（查论编） 2025年6月6日 (五) 06:04 (UTC)

考虑到特定申请可能有人反对，而明确的授权与反对标准较容易审视，即通过反对票来延缓授权进程。我也赞成可以宽松裁量是否授权，暂未考虑投票期限等约束。--YFdyh000（留言） 2025年6月6日 (五) 06:42 (UTC)

反对者阐明理由，支持者反驳，如遇长期讨论而管理员无法判断共识之情况可考虑由行政员集体决定。本人不希望RFR和RFA一样成为选举。Python6345（查论编） 2025年6月6日 (五) 06:51 (UTC)

引入DYK/GA/FA的写作数量作为可选条件也可以。比如可将10篇DYK或2篇GA/FA作为参考条件。--Steven Sun（留言） 2025年6月6日 (五) 04:24 (UTC)

(＋)支持引入，但(－)倾向反对上述写作数量，个人认为10篇DYK过少。--$\color {White}{\mathfrak {Kurwa}}$__^{Don't bite!} 2025年6月14日 (六) 11:55 (UTC)

条目质量须被巡查员认可提案

现行条文 任何管理员均可将此权限授予熟知维基方针及指引（特别是生者传记和收录标准）的可信赖用户。建议门槛为创建75个有效条目。如您打算为您自己或其他用户申请此权，请移步至维基百科:权限申请/申请巡查豁免权。

提议条文 任何管理员均可将此权限授予熟知维基方针及指引（特别是生者传记和收录标准）的可信赖用户。建议门槛为创建10个有效条目，且条目质量被巡查员认可。如您打算为您自己或其他用户申请此权，请移步至维基百科:权限申请/申请巡查豁免权。

本人认为巡免权主要需条目平均质量可通过巡查，且10个条目之建议已足够低，故提案未包含DYK/GA/FA之建议标准，如有例外请IAR处理。多日无人留言，如7日内无异议将公示。Python6345（查论编） 2025年6月10日 (二) 10:47 (UTC)

10个条目未免真的太低，但我认同现有门槛确实过高，因此我较为倾向于enwiki的门槛（25个条目），这样可以确保巡免写的条目足够多，又避免为有意申请巡免者造成不必要的负担。Sanmosa _新朝雅政 2025年6月10日 (二) 15:16 (UTC)

保留DYK，又或者做7篇GA如何？--Mykola（留言） 2025年6月14日 (六) 17:49 (UTC)

不认可将DYK/GA/FA纳入巡免申请要求，现时条目经少量改善并挂模板后即可通过巡查，无理由要求巡免之条目质量高于可通过巡查之基本标准。Python6345（查论编） 2025年6月15日 (日) 09:26 (UTC)

不需要“经过巡查员认可”，重点是条目品质足够，这也就是“有效条目”的含义。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月10日 (二) 15:34 (UTC)

(：)回应：是否条目品质足够需用户判断，本人倾向由延确判断，但有人质疑延确判断能力且巡免确主要影响巡查员之工作。故在此拟议巡查员判断，阁下如有更好方案还请提出。Python6345（查论编） 2025年6月14日 (六) 13:41 (UTC)

不必更改现况，由社群判断即可。说实话有什么权限也不影响能不能读条目吧？—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月14日 (六) 17:46 (UTC)

理论上不影响，但连DYK都时常可见水票，且阅读一名用户所创之条目判断是否可获巡免耗费精力显高于阅读一篇条目，本人合理担忧出现更多不读条目就(＋)支持而多日无人认真读条目提出合理反对意见，导致管理员误授权给质量过差之用户巡免权。本人认为此方案如通过而巡查员不读条目而支持，可以WP:CIR除权；普通用户如可给出合理解释表明认真阅读过条目亦可采纳。Python6345（查论编） 2025年6月15日 (日) 09:24 (UTC)

照理说大部分申请应该会是“提出申请”、“符合基础门槛”、“无人反对”（有人支持的话会更快）、“管理员授权”；我们应该是鼓励社群（无论持有权限）参与第二部分过程，因为管理员也非全能。—— Eric Liu _{創造は生命（留言・留名・学生会）} 2025年6月15日 (日) 12:14 (UTC)

让管理员判定即可，目前也不是由管理员判定并授权吗？--Steven Sun（留言） 2025年6月16日 (一) 03:21 (UTC)

(－)强烈反对，10个也太少了吧。像LTA:Kurgenera这样的人申请巡免只会让你维更糟糕，个人认为50个适宜。（折中enwiki和中维）--$\color {White}{\mathfrak {Kurwa}}$__^{Don't bite!} 2025年6月14日 (六) 11:49 (UTC)

(：)回应：此仅为建议标准，而非到达资格后必须授权。Python6345（查论编） 2025年6月14日 (六) 13:43 (UTC)

认真写的条目，10-25个足以判断用户的写作水平。无需50个。况且这只是建议标准，是否授权仍需要管理员及其他用户综合判定写作水平。--Steven Sun（留言） 2025年6月16日 (一) 03:12 (UTC)

简单降低标准提案

现行条文 任何管理员均可将此权限授予熟知维基方针及指引（特别是生者传记和收录标准）的可信赖用户。建议门槛为创建75个有效条目。如您打算为您自己或其他用户申请此权，请移步至维基百科:权限申请/申请巡查豁免权。

提议条文 任何管理员均可将此权限授予熟知维基方针及指引（特别是可供查证、生者传记和收录标准）的可信赖用户。建议门槛为创建25个有效条目。如您打算为您自己或其他用户申请此权，请移步至维基百科:权限申请/申请巡查豁免权。

-- Steven Sun（留言） 2025年6月16日 (一) 03:43 (UTC)

考虑到上方多个提案已经详细的讨论过具体降低到什么样的门槛，可以视为讨论已经很充分，因此 公示7日，2025年6月27日 (五) 09:47 (UTC)结束。 Stang¹³¹⁰ 2025年6月20日 (五) 09:47 (UTC)

巡查豁免活跃度要求提案

现行条文	提议条文 此外，当超过3年没有任何编辑活动，报告后如查明属实时，则立即除权。

注意到巡查豁免权没有活跃度要求，并考虑到无编辑用户可能会不了解编辑方针与指引的变动，因此提出活跃度要求。--Steven Sun（留言） 2025年6月16日 (一) 03:43 (UTC)

多此一举，已经有六个月未有编辑活动的规定。--雨朝_{Talk#SamekoSaba🐟} 2025年6月16日 (一) 12:23 (UTC)

了解，那我 撤回请求。--Steven Sun（留言） 2025年6月16日 (一) 12:51 (UTC)

“允许在中文段落使用斜体表示英文书名”公示通知

下列讨论已经关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

---

通知：允许在中文段落使用斜体表示英文书名正在 公示7日，2025年6月18日 (三) 07:43 (UTC)结束。由于RFC机器人错误摘除RFC模板，而机器人操作者又未回应，为免出现技术问题，本讨论不存在于RFC列表，特此通知。--1F616EMO（喵留言～回复请ping） 2025年6月11日 (三) 07:47 (UTC)

由于有编者就“英语作品名”的定义有意见，现 暂缓公示，直到相关问题被解决；解决后，将按重行公示简易规定进行公示。--1F616EMO（喵留言～回复请ping） 2025年6月11日 (三) 23:14 (UTC)

所有问题已经解决，正在等待发表相关意见者确定公示期。1F616EMO（喵留言～回复请ping） 2025年6月12日 (四) 05:53 (UTC)

已经获得发表意见者同意，现 重启公示，2025年6月18日 (三) 07:43 (UTC)结束。1F616EMO（喵留言～回复请ping） 2025年6月12日 (四) 07:56 (UTC)

提案已经通过，详见结案论述。1F616EMO（喵留言～回复请ping） 2025年6月18日 (三) 10:38 (UTC)

---

本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

建议增加“姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代”去掉“姓、部、卦、母、国、朝”字之后剩下的东西的“重定向/消歧义”的方针

见Wikipedia:页面存废讨论/记录/2025/06/12#批量提删，许多单一字的条目被提删了，当中很多都是“姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代”去掉“姓、部、卦、母、国、朝”字之后剩下的东西，但是，如果有些“姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代”去掉“姓、部、卦、母、国、朝”字之后剩下的东西有重定向或消歧义，有些没有，这样显然不行，所以在此提议增加方针：

任何“姓氏”（刘姓、刘）、“部首”（羽部、羽）、“六十四卦”（节卦、节）、“三十六字母/早期中古汉语（切韵音）声母”（透母、透）、“国家”（德国、德）、“中国朝代”（隋朝、隋）去掉“姓、部、卦、母、国、朝”字之后剩下的东西（刘、羽、节、透、德、隋）必须有页面，且该页面必须符合以下四个条件之一：

1. 重定向到该（姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代）的条目
2. 为消歧义页面，且该消歧义页面中包含该（姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代）的条目
3. 为其他条目，且条目头部有“关于（姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代），请见X（姓、部、卦、母、国、朝）”
4. 为其他条目，且条目头部有连到对应的“X（消歧义）”的消歧义页面，且该消歧义页面中包含该（姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代）的条目

例如：（以“姓氏、部首、六十四卦、三十六字母”的前16个来举例，但三十六字母的第5、6、7个（非母、敷母、奉母）目前仍然没有条目，故只以另外13个来举例）

类型	符合条件1	符合条件2	符合条件3	符合条件4
姓氏	冯、褚、蒋、沈	赵、李、周、吴、郑、陈、卫、韩、杨	孙	钱、王
部首	丨、亅、亠、入、冂、冖、冫	丶、丿、儿、几	乙	一、二、人、八
六十四卦	讼、小畜、谦	干、坤、屯、蒙、需、师、泰、否、同人、大有	履、豫	比
三十六字母	帮、滂、端（提删中）、透、彻、澄	并、娘	微、定、泥、知	明

---59.126.168.120（留言） 2025年6月13日 (五) 06:25 (UTC)

• (－)反对：那堆重定向有不少本身有多义，而且相关主题远比冷门姓氏更具关注度。重定向不应该会让一个读者产生“为什么我会到了这里”的感觉-某人✉ 2025年6月13日 (五) 09:02 (UTC)

  有多义就弄成消歧义页面啊，请看“符合条件2”这栏。--59.126.168.120（留言） 2025年6月13日 (五) 10:47 (UTC)

  另外这里面也包括几个我在条目头部加入“关于（姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代），请见X（姓、部、卦、母、国、朝）”页面，如矛、缶、豆、酉、走、耒、舟、耳、寸、柏、芮、隆（这个条目被回退两次，也可以一起讨论）、屈、禹、席、虞、宣、羿、牧、祖，（这些都符合条件3），我还因此而发现了龚被重定向到错误页面（而且很多年都没有人发现），然后把他弄好了，我也因此发现鼠条目的头部没有连到鼠 (消歧义)页面，然后也加上了，另外还发现羊 (消歧义)跟雨 (消歧义)页面居然都不存在，然后也都创建了。--59.126.168.120（留言） 2025年6月14日 (六) 08:10 (UTC)

(＝)中立：我认为多数词语应该可以从消歧义、重定向、甚至收录标准找出理据，不应删除；不过同意AINH的说法：很多词语颇有歧义，需要厘清。我在检查“端”的时候，就有类似疑问。--Saimmx（留言） 2025年6月13日 (五) 09:14 (UTC)

单字，请去维基词典。--Kethyga（留言） 2025年6月13日 (五) 09:35 (UTC)

单字并不能当做提删的理由。——杰里毛斯（留言） 2025年6月13日 (五) 11:01 (UTC)

Kethyga的单字提删理据大概是“不是辞典”方针：在这个方针下，条目只有释义本身，可能无法成为条目。要反驳的话，可能要进一步阐述为什么单字不是删除理由、并以“不是辞典”方针为基础反驳。--Saimmx（留言） 2025年6月13日 (五) 15:54 (UTC)

@Saimmx：我觉得假定他人的观点不是个好习惯。这里我不将其作为Kethyga的观点而是作为你的观点来来回复。我觉得反而是你需要论述为什么单字就违反了这一方针。是不是词典内容要看这一词指称的含义是词典含义还是百科含义而不是看这一词的字数（尽管客观上有相关性）。“枣”是词典内容？“沪”是上海的简称是词典内容？ ——自由雨日🌧️❄️ 2025年6月13日 (五) 16:17 (UTC)

抱歉，乱假定观点是我的错。我撤回。--Saimmx（留言） 2025年6月13日 (五) 16:26 (UTC)

同上。不成词的语素（通常是一个字）我反对作条目标题，也不赞成建重定向/消歧义，确实是词典内容；但成词且可指称百科含义的语素和单字专名语素完全可以是百科内容。现代汉语只是以双音节词为主而非没有单音节词。 ——自由雨日🌧️❄️ 2025年6月13日 (五) 12:04 (UTC)

不知道您说的是词（又称单字）还是单个汉字。无论是哪个，都不是提删理由。有百科全书性质的内容就应该留下来。譬如我们有维基导游，但是不能说景点的条目就要全部搬过去。 ——魔琴［留言 贡献 PJ:小学 PJ:两岸］ 2025年6月13日 (五) 17:04 (UTC)

注意：这里的“X国”包括任何国家（包括193个联合国会员国、2个联合国观察员国、10个有争议的政治实体），而“X”为该国中文国名（包括：台湾、中国大陆、香港、澳门、新加坡、马来西亚，当中的任何一个地方使用的中文）的第一个汉字，即使中文很少对这个国家这样用都一样，例如对于“巴西、巴林、巴拿马、巴哈马、巴拉圭、巴巴多斯、巴基斯坦、巴勒斯坦国、巴布亚新几内亚”这些国家，X=巴，而对于“密克罗尼西亚联邦”这个国家，X=密，对于“斯里兰卡、斯洛伐克、斯洛文尼亚”这些国家，X=斯，对于“塞浦路斯”这个国家，X=赛，对于“阿尔巴尼亚、阿尔及利亚、阿富汗、阿根廷、阿拉伯联合酋长国、阿曼、阿拉伯也门共和国”这些国家，X=阿，依此类推。--59.126.168.120（留言） 2025年6月13日 (五) 11:03 (UTC)

另外我漏掉了，包括中国的省份（包括：省、自治区、直辖市、特别行政区）的单字简称（例如“冀”为河北省、“沪”为上海市）也一样，虽然对于这些单字简称都很早就有重定向或消歧义了。--59.126.168.120（留言） 2025年6月13日 (五) 11:06 (UTC)

另请@59.126.168.120针对“不是辞典”方针阐述：请问这个改动，是否与“不是辞典”方针冲突？是的话，是否有其他方针支持改动？--Saimmx（留言） 2025年6月13日 (五) 15:59 (UTC)

重点是，总不能有些（姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代）的去掉“姓、部、卦、母、国、朝”字之后剩下的东西可以重定向/消歧义，有些不行吧？这样是双标。--59.126.168.120（留言） 2025年6月14日 (六) 01:29 (UTC)

我认为这符合“标题所代表的个人、群体、概念、地方、事件、物体等。”只有针对字本身的说明才符合WP:NOTDICT，对字所常代表事物进行重定向不宜以“不是辞典”为由拒绝。——𠭞（留言） 2025年6月18日 (三) 08:37 (UTC)

我的目的是要让人们搜索“姓氏、部首、六十四卦、三十六字母/早期中古汉语（切韵音）声母、国家、中国朝代”去掉“姓、部、卦、母、国、朝”字之后剩下的东西（例如“刘、羽、节、透、德、隋”时）的时候都可以快速找到对应的页面（刘姓、羽部、节卦、透母、德国、隋朝），所以这些东西都必须要有重定向或者消歧义。--59.126.168.120（留言） 2025年6月18日 (三) 05:24 (UTC)

已在WT:重定向与WT:消歧义发送讨论通告，另请Ericliu1912注意方针（WP:讨论发起位置），勿再违规添加存档。 ——自由雨日🌧️❄️ 2025年6月18日 (三) 05:39 (UTC)

(＝)中立。我认同这一呼吁，但觉得不值得为此设立方针。我认为大部分有必要重定／消歧的页面适用于“别名重定向至更符合维基百科方针的正式名称”。——𠭞（留言） 2025年6月18日 (三) 08:37 (UTC)