WinStory Wiki:词条编写指南

来自 WinStory Wiki
跳转到导航 跳转到搜索

写在阅读之前：

在 WinStory Wiki，我们希望你可以遵循本指南中提到的常见做法创建和/或扩展 WinStory Wiki 的内容，从而在最大程度上避免可能且不必要的冲突。

任何违反或滥用规定的行为（具体取决于严重程度）可能会导致你的讨论页上出现任何临时性的警告，或者由管理员暂时/永久禁止你编辑/创建词条。

强烈建议你在编辑/创建词条之前阅读本指南。通过在 WinStory Wiki 中进行各类编辑操作，我们将视同你已阅读并了解这些规则和指南。

通用规定

请注意，这些规定并未完全覆盖 Wiki 中的所有情况，因此请不要认为不被禁止就意味着允许。

从 WinStory 团队的角度，如果我们有理由相信你在编辑 WinStory Wiki 的意图与你的目标相悖（包括但不限于：明显缺乏合作兴趣、骚扰、马甲操作和破坏性编辑），你的编辑权限可能会被管理员撤销。

最后，在本指南中，Wiki=百科，可以互相替换理解。

常规

  • 对其他用户保持礼貌。请始终假设善意，除非你有很好的理由和/或证据这样做——永远不要攻击新来者。无论何时，个人争议始终都应该远离 Wiki。
  • 进行有意义的编辑。不要进行诸如将单词替换为其同义词，或从图库图像中删除“文件:”前缀等操作在内无用编辑行为。
  • 使用单个帐户编辑 Wiki。任何未经事先批准创建的傀儡帐户都有可能会被无限期阻止，恕不另行通知，这也包括主帐户。
  • 尽可能避免编辑战。如果你发现自己卷入了内容争议，请在相应的讨论页上提出问题，并使用争议模板标记相应的页面或部分。根据多家同类型 Wiki 的经验，我们规定，由于恢复公然破坏行为以外的原因，在短时间（例如：30 分钟）内还原页面三次及以上即被视为发生编辑战。
  • 仅使用移动工具移动页面。除非完全必要，否则不要剪切和粘贴页面内容，因为这样做会删除贡献历史记录。即使没有移动权限也不例外。
  • 你的个人用户页面来规避显著性规则或以前的删除。
  • 注意验证任何新的信息。请务必花时间正确理解问题，检查特定陈述是否存在支持来源，并确保所提供的信息来自可靠、合法的来源；将新发现的信息添加到百科不是一场比赛。如果你从社交网络小组收集信息，请不要害怕提出后续问题。
  • 编辑操作应符合法律。无论在词条中进行何种内容的编辑，请始终确保你的编辑内容是在中华人民共和国（含台湾省）的法律法规允许的范围之内进行的。

内容

  • 保持真实。不要将 WinStory Wiki 用于“从未发布的 Windows”（Windows Never Released，WNR）、“从未发布的操作系统”（Never Released OS，NROS）或其他幻想内容。这适用于所有页面，包括用户页面和沙盒页面。
  • 任何非原创内容都应正确认可原始来源。不要在未提供至少一个来源网址的情况下复制其他网站的内容。在重新上传他人发布的照片之前，请先获得许可。
  • 词条主题必须符合知名度准则。尽管并非所有内容都值得在 WinStory Wiki 上报道，但是在通常情况下，如果同一内容（如未来版本或周期等）被超过 3 家知名媒体（同时或非同时）提到，即达到词条创建的标准。但是，达到词条创建标准，并不意味着一定要立刻创建词条，反之亦然。
  • 请在新词条中投入一些精力。仅由公式化的“X 是 Z 的 Y”组成的词条，且没有其他内容，这并不比根本没有内容的词条好多少，并且有资格被管理员执行快速删除。在编辑或创建词条时，请始终记住，WinStory Wiki 是一个百科全书，不是一个记录流水账的账本。因此，WinStory Wiki 反对且禁止任何人创建根本没有内容的“白板”词条以及只有公式化的内容“X 是 Z 的 Y”的词条。
  • 请确保链接到你创建的词条！如果你不这样做，这个词条就会丢失，并可能导致另一个意义重复的词条被创建。未链接的页面可以在这里找到：孤立页面。
  • 禁止使用生成式 AI 来编辑词条。像 ChatGPT 这样的大模型通常初看内容很不错，但由于大模型内容差异，事实可能不准确。

法律

  • 本 Wiki 只是这些版本的知识库。但这并不意味着不能提供或请求任何下载版本的链接。
  • 不建议提供有关如何破解软件的链接或说明，例如删除时间炸弹或绕过激活。在法律允许的范围内，管理员有权在不通知的情况下删除相关链接和说明。
  • 请勿发布可在软件的零售版本中使用的产品密钥或其他激活码（公共产品密钥除外）。虽然软件开发者或开发商可能对此不在意，但这些密钥在网上很容易找到。

讨论页

  • 为新的讨论页主题添加章节标题。如果没有这些，它会从页面中造成不必要的混乱。你的消息也可能对所有用户不可见。
  • 在讨论页上签署你的评论。如果你想匿名，请创建一个用户帐户，签名将带有你的用户名。
  • 未经作者事先许可，请勿编辑或删除评论。你可以在任何人回复之前更改或删除自己的评论，但是，之后这样做会删除有价值的上下文，应避免。
  • 讨论页不是论坛或即时通讯服务。尽量保持关于 Wiki 内容的讨论。还有许多其他服务可用于一般和个人讨论，例如 QQ、Discord 等。

常见问题

Q：我可以在 WinStory Wiki 自由注册帐户吗？

A：不可以。WinStory 属于经中国国家相关部门批准备案的网站，根据备案要求，以及 WinStory Wiki 的实际，WinStory Wiki 不支持任何形式的自由注册帐户功能。如果你需要注册 WinStory Wiki 帐户，你可以直接联系站长 Enlightment101。请在发出请求时注明自己要用于注册的用户名。

Q：我可以更改我的用户名吗？

A：如果你的帐户已存在至少 6 个月，且你之前一年没有更改过用户名，你可以在管理员公告板上要求更改你的用户名。请注意，即使你符合标准，在某些情况下你的请求仍有可能被拒绝。 要求更改用户名的拒绝情形包括：

  • 用户名使用了任何国家当前或过往国家领导人的姓名（包括拼音）；
  • 用户名使用了邪教名称或者与邪教相关的名称；
  • 用户名使用了明显攻击他人的名称；
  • 用户名违反中华人民共和国境内的有关法律规定中规定的其他情形。

Q：为什么我无法上传图片或创建新词条？

A：只有自动确认的用户才能上传图片和创建新词条。自动确认状态会自动提供给注册存在至少 90 天且至少进行了 50 次编辑的所有注册帐户。

Q：我可以将内置应用的列表明细写进词条吗？

A：不可以。内置应用情况因不同版本的情况也会有区别。如果写进内置应用情况，可能会引发争议。因此，不可以将内置应用的列表明细写进词条。但是这里仅指代单纯的应用列表及简介，对于更改中有关应用的增减，依然可以正常写进词条，因为这属于版本自身功能变化。

Q：我可以将较新版本的性能提升对比结果（如较新版本比较旧版本性能提升多少）写进词条吗？

A：不可以。首先，此类性能提升对比源自非官方渠道，且对比条件会因为不同人的对比而产生明显差异。在这种情况下，将性能提升对比结果写入词条将对词条公平性产生最直接的威胁，甚至还存在夹杂广告的嫌疑。因此，不允许将此类对比结果写入词条，违者除撤销有关更改之外，还将会视情形严重程度给予处罚。

Q：WinStory Wiki 与 BetaWiki、BetaArchive 或 BetaWorld 有关吗？

A：不，WinStory Wiki 与问题中所述的其他几家互不隶属，同样的，与其他类似的网站或社区等也互不隶属。我们与这些网站唯一相同的只是碰巧与其他几家共享相同的研究重点。

Q：如何下载内部版本？

A：目前暂时不提供下载。对于标记为可用的版本，在多数情况下，未来计划通过规划的另一个站点提供下载。

日期格式

WinStory Wiki 在词条和其他文章中使用年月日“长”日期格式（如 2023 年 1 月 10 日）。但是，在空间有限的情况下，也可以使用 ISO 8601 使用的年-月-日 （YMD） 数字日期格式（例如：2023-1-10），但不能在文章文本本身中使用。

下表进一步记录了首选日期格式：

WinStory Wiki 可接受的日期格式
一般写法 备注
1985 年 11 月 20 日 词条正文和信息框内使用的日期格式。
11 月 20 日 只有在没有歧义风险的情况下省略年份。
1985-11-20 只在空间有限的地方使用，例如表格。信息框则是正常使用长日期格式。
1985 年 11 月 只有仅明确到月份时才使用。

知名度准则

世间的软件多如牛毛，同样的，流行的软件也非常多，作为一家百科，WinStory Wiki 不可能也无法涵盖在 Internet 上提到的每一个软件的每一个版本。基于这一点，我们根据知名 Beta 百科 BetaWiki 的知名度准则，结合 WinStory Wiki 和国内爱好者的实际，设计了一套通用的知名度准则，判断某个主题是否需要或值得涵盖。这些准则并非绝对性的，在平日操作中，可以根据具体情况针对具有重大历史意义的主题采取豁免。

请注意，单纯因为一个主题符合知名度原则，并不意味着它必须在单独的词条上收录。质量优先于数量，因此拥有一个优秀的词条比拥有一个包含简略主词条、简略版本与版本词条的词条更为理想。

操作系统与应用

当某个操作系统（Windows 为未来产品或开发周期）或应用在独立于产品供应商的多个消息源中被多次提及且有具体可证实的版本信息（如内部版本）时，即认定此操作系统（Windows 为未来产品或开发周期）或应用适合单独设立词条。

独立产品的组件和软件模组将会视为单独产品，同样需要通过知名度准则评估。

软件版本

涵盖原型版本并因此研究流行软件的演变是 WinStory Wiki 的主要任务。如果以下所有要点（包括列出的额外两类情况在内）中有至少两点适用，版本可以认为是值得注意的：

  • 产品本身值得注意
  • 版本（开发周期）已被适当的来源提及
  • 对于开源软件，版本必须由官方来源编译
  • 源材料的作者被认为不太可能拥有所述版本

以下来源也被认为是合理适当的：

  • 版本媒介本身，例如：可引导安装介质，例如光盘或软盘上的安装介质；原始媒体，如磁盘映像转储、编译器输出
  • 版本的截图或视频，前提是可以追溯到最初的上传来源
  • 关于版本本身或其特性、错误等的文章
  • 提及此版本的内部文档，如此后公开的内部文件

如果在多个版本中提及以下来源，也同样可以作为来源接受：

  • Warez CD 列表
  • 新闻组讨论、评论、错误报告
  • 下载页面的屏幕截图
  • 文件版本
  • 源代码控制元数据

不符合上述标准的版本，仍可通过与其他重要版本相关的文章进行涵盖（例如包含其他版本文件的版本）。在这种情况下，原本不重要的版本也可以包含在版本列表中，并创建词条。

如果版本的一些证据来自第一方，即参与产品开发的人士，版本将自动视为已确认，不存在对其合法性/存在性的疑问。

同样，我们也以有限的方式涵盖部分虚假版本。如果除了上述标准之外，虚假版本仍然存在使个人对其合法性感到困惑的可能，版本也会被认为是值得注意的。

Android

对于开源操作系统，如 Android——这种情况与其他闭源操作系统有所不同，原因是任何人都可以编译操作系统版本。针对 Android，版本必须符合：

  • 从 Android 开源项目（Android Open Source Project，AOSP）主干建立，并直接在源代码树中打标签；带有自定义标签的版本（如高通 QSSI 镜像）不包括在内，这是因为任何人都可以修改它们
  • 以可用镜像的形式提供，如果此版本是独特的，例如仅作为某个界面皮肤提供但未在 AOSP 树中提供——则具有显著性，否则没有显著性（这主要适用于现代 Android）
  • 在具体来源中被引用，例如：
    • 空中下载（Over-the-air，OTA）更新镜像
    • 移动设备（如手机和平板）上的预装镜像
    • 在某种公开活动中展示
    • 多个可靠新闻来源详细说明版本的具体情况

仅在以下情况下，在错误报告中列出的版本才具有显著性：

  • 它们展示操作系统的某些部分，而不仅仅提及字符串；
  • 它们以源代码形式不可用，例如 Android（dogfood）版本或 Android 4.4.4 发布 RTM 后版本。如果某个版本最初没有作为源代码提供，而在此时间段内生成了错误报告页面，则在源代码发布后，可以将其标记为快速删除。需要注意的是，即使源代码发布后，某些版本仍可能不是开源的。
  • 在 platform/sdk/platform/prebuilts/sdk 仓库中列出的版本也没有显著性。如果某个版本有关于页面的镜像，应显示版本字符串并表明它是由某个内部 Android 构建机器人帐户（如 hammerheadf 或 soju）编译。此规则仅适用于 eng 或 userdebug 类型的镜像。

某些 Android 版本是基于其标记时的 AOSP 提交重新构建的。这些提交仅旨在记录少量（大约 15-20 个）展示 Android 在版本标记时的外观和功能的版本。这些版本由社区成员选出，以包含有趣的（或在某些情况下匹配的，例如评审版本或预览版本）更改和预发布功能。

游戏

只有预装在 WinStory Wiki 上记录的操作系统中的游戏及其原型版本才被认为足够引人注目，可以创建并编写独立的词条。任何未预装在任何操作系统中的第三方游戏都不适合于 WinStory Wiki 的范围。

工具

除了介绍实际软件及其原型版本外，我们还专注于使旧测试版使用更容易的工具，例如模拟器或隐藏功能的解锁程序。当然，这些工具也应该被社区证明是值得注意的。

版本收录范围和规则

在上节之中规定了版本收录的条件，但是没有规定具体收录版本的范围。根据爱好者们和用户的实际，针对版本收录范围，WinStory Wiki 对版本收录范围做出以下明确：

允许的版本

  • 正式发布的版本（包括推送和发布）
  • 已通过散装程序、镜像等形式泄露的版本
  • 在版本的屏幕截图中提及的版本
  • 在符号服务器被发现的版本（仅有限涵盖）。
  • 特定性质的累积更新版本。如：功能更新本身基于累积更新开发、特定累积更新是特定主要版本的最终更新、具有重大功能变化的累积更新、在功能更新正式发布前的累积更新、专用累积更新（如测试通道）。
  • 需要以有限的方式涵盖的假冒版本

不收录的版本

  • 源自原始设备制造商（OEM）的零售版本的变体。唯一的例外是那些具有重大变化的产品，例如在与零售业不同的体系结构中可用（通常是不兼容 IBM PC 的体系结构）。
  • 通过 Windows Update 服务获取的 RTM 内部版本的更新修订版。唯一的例外是具有主要接口、内核/内部版本号和/或应用程序更改的更新版本。
  • 来自 compliance.ini、cversion.ini 或 AppxManifest.xml 文件的版本号。
  • 测试版的累积更新版本，特别是来自 Windows 10 及更高版本的版本。但特定性质的累积更新版本除外。

删除政策

请参阅删除政策。

风格指南

WinStory Wiki 的语句风格主要遵循维基百科的风格手册，另有说明者除外。在此基础之上，我们根据多家同样研究 Beta 的百科分析后制定 WinStory Wiki 的风格指南。整个风格指南由命名方案、模板、正文三部分组成。Wiki 中的任何词条，无论是正文、标题，还是截图的说明，公共要求是中英文、汉字和数字间均要求使用空格分隔。

命名方案

Windows

Windows <version>

通常，Windows 主要版本无需特别规定，仅需写明具体 Windows 的产品名称即可，例如：Windows XP、Windows Embedded 8。对于 Windows 10 和 11 功能更新版本的版本，只需使用数字 10 或 11，后面加简略的版本号。例如：Windows 11 v22H2。

建议为各个更新单独建立已知版本列表，其名称应包含更新的官方名称，例如：Windows 10 创意者更新。

对于已经确定更新正式名称者，需要在正文开始声明更新正式名称，如：Windows 11 版本 22H2，正式名称为 Windows 11 2022 更新。

与其他同类百科不同，为了能够增强版本认知，我们采用了相反的策略，在一般情况下，完整正式名称将会重定向到 YYMM 或 YYH2 更新版本，例如将 Windows 11 2022 更新重定向到 Windows 11 v22H2。

Windows <version> Build <完整内部版本字符串>

上述规格是整个 Windows 版本词条的统一命名模式。通过使用完整内部版本字符串，使得 Windows 词条在整个百科范围内具备唯一性。例如：Windows 10 Build 16179.1000.rs_prerelease.170414-1642

对于仅使用主版本号和次版本号的 Windows 版本，请在版本字段中使用它们，并完全省略内部版本号。例如：Windows 1.04。

仅有仅有内部版本号和/或没有修订版本号，没有分支等其他信息，分支和编译时间可省略。例如：Windows 11 Build 25871.1000、Windows 11 Build 25865

符合 WinStory Wiki 要求的版本词条模板可参看 Windows 示例词条（主词条）、Windows 示例词条（版本词条）。

重定向

为了让搜索版本页面更容易，WinStory Wiki 除了上面提到的重定向之外，还维护了多个重定向：

如果某个版本有官方名称，则应将其重定向到主页面，即 Windows 8.1 Preview ⇒ Windows 8.1 Build 9431.0.winmain_bluemp.130615-1214。

如果有多个版本使用官方命名方案，则将其重定向到主版本页面，即 Windows 10 Insider Preview ⇒ Windows 10。

macOS

经典

Mac OS <version> Build <build>

Mac OS X

version 表示特定版本的名称，即 Jaguar 或 Yosemite。

Mac OS X <version> Build <build>

OS X <version> Build <build>

macOS <version> Build <build>

OS/2

1.x

多任务 MS-DOS 4.00 内部 [工作/修订] <build>

IBM OS/2 <version> Build <build>

Microsoft OS/2 <version> Build <build>

2.0 及更高版本

OS/2 <version> Build <build>

模板

Windows 版本信息框

请参阅模板:Infobox Windows build

macOS 版本信息框

请参阅模板:Infobox macOS build

版本列表

关于软件版本的文章中，一个已知或著名版本列表是常见的功能。大多数版本列表由版本列表项组成——指向不同版本文章的链接，并根据可用性或确认状态使用不同的项目符号图标和前景颜色。

以下模板用于版本列表项：

Available build [[[词条标题]|版本字符串发布名称]]

当版本公开可用时使用

Confirmed build [[[词条标题]|版本字符串发布名称]]

当版本信息可获取，且有可信来源（如开发者）进一步证明时使用

Unconfirmed build [[[词条标题]|版本字符串发布名称]]

当信息可用但没有提供证明和/或来源可疑时使用

Fake build [[[词条标题]|版本字符串发布名称]]

当版本被证明是伪造时使用。如果版本是真的，但也有伪造截图，请不要使用此模板。

“发布名称”参数是可选的，应包含此版本发布的官方名称。

在使用上述列表项模板时，也应在版本列表顶部添加 {{[[模板:Builds legend|Builds legend]]}}。

如果不需要根据状态区分版本，建议使用常规百科列表和链接。然而，不要在同一列表中混合常规列表/链接语法与版本列表项模板。

在排序版本列表时，最重要的因素是版本号。如果有几个不同版本编号相同的版本，应始终按编译日期和时间排序。如果多个版本共享相同的编译日期和时间，应按以下顺序排序：

主分支（例如 main、winmain、rsmain、rsmaster）

发布分支（例如 beta1、xpclient、winmain_win8m3、rs2_release 等）

内部测试/合作伙伴分支重新编译（例如 idx、fbl_partner、vbl_media_ehome 等）

其他分支按字母顺序排序

谨慎使用“泄露（泄漏）”一词（非强制）

此条款非强制，但需要对此进行说明。

通常仅在指首次或一般情况下在其预期用户群之外发布的版本行为时使用“泄露（泄漏）”。尽可能避免使用此词来指代上传到特定站点（如果未经授权的个人早在主题公开之前就已经访问了版本）。其他替代方案（例如共享、上传或可用）可能更可取，具体取决于相关主题或词条的上下文，即：

“用户 X 共享此版本”；
“版本已上传到站点 Y”；
“这是最早可用的版本 [...]”

正文内容

在 WinStory Wiki 中，对于正文，要求不得采用空白或仅仅简单写一句版本何时泄露或发布即完成任务。Wiki 是一个百科平台，而非一个记账的账本，如果你在 WinStory Wiki 中将词条编写和修改作为记账对待，管理员可能会对你进行警告，乃至收回编辑权力。

在风格指南开始，我们提到，Wiki 中的任何词条，无论是正文、标题，还是截图的说明，公共要求是中英文、汉字和数字间均要求使用空格分隔。这里提供一组对照，以此来解释为什么会有这样的要求。

Windows 7 Build 6519是Windows 7的版本，于2008年6月10日泄露
Windows 7 Build 6519 是 Windows 7 的版本，于 2008 年 6 月 10 日泄露

通过上下两组对照可以看出，很明显，靠下的这行文本在格式上更加工整。在这一组对照之中，靠上的这一行相比靠下的这一行，由于在中英文、汉字和数字间没有空格分隔，整体看起来糊成一片，显得并不工整。

对于词条的正文，所有词条的正文都应以导语开始，介绍主题并总结词条中的要点。这一部分通常以一句对词条主题的简单描述开始。例如：

Windows 8 Build 8250 是 Windows 8 的官方 Consumer Preview 版本，于 x 年 x 月 x 日正式向公众发布。

正文中的版本号通常不写具体的分支（实验室）和编译日期和时间。但以下情况需要在正文中说明：如果版本在不同分支（实验室）存在多个版本，此时正文需要在版本号中注明分支（实验室）。例如：

Windows 10 Build 14355.rs1_release_prs 是 Windows 10 的版本，于 x 年 x 月 x 日泄露

如果版本在同一内部版本号、同一修订版本号、同一分支（实验室），但在不同日期具有多个版本，此时正文中需要在版本号中注明编译日期和时间。例如：

Windows XP Build 2267.000909-1503 是 Windows XP 的版本，于 x 年 x 月 x 日泄露。

如果版本在同一内部版本号，但在不同修订具有多个版本，此时正文中需要在版本号中注明具体修订版本号。例如：

Windows 11 Build 23403.1000 是 Nickel 的版本

这一部分可以跨越多个段落，并以词条首个章节标题结束，此时 Wiki 软件会自动插入内容目录。

针对词条中表示更新或 Bug 等内容的部分（包括新增功能和更改、Bug 或其他单独列出的栏目），如果只有一条更改、更新或 Bug 等内容，可以正常以正文的方式列出。但是，如果此版本包括的更改或更新内容不止一条，应通过无序列表来标记。

对于词条的正文有关更新、引用或 Bug 部分内容，在只有一条的情况下可以正常列出：

版本更新、引用或 Bug 内容。

在有多条的情况下可以正常列出：

  • 版本更新、引用或 Bug 内容。
  • 版本更新、引用或 Bug 内容。

在有多条，且需要分级的情况下可以这样列出：

  • 版本更新、引用或 Bug 内容。
    • 版本更新、引用或 Bug 内容。
      • 版本更新、引用或 Bug 内容。
        • 版本更新、引用或 Bug 内容。

无序列表在编辑器中你看到的应该是这样的：

在有多条的情况下列出：

* 版本更新、引用或 Bug 内容。
* 版本更新、引用或 Bug 内容。

在有多条，且需要分级的情况下列出：

* 版本更新、引用或 Bug 内容。
** 版本更新、引用或 Bug 内容。
*** 版本更新、引用或 Bug 内容。
**** 版本更新、引用或 Bug 内容。


词条中的大部分内容应以散文形式书写。不要使用项目符号引出段落——列表语法只应用于实际的列表，并且列表应尽量简明扼要。原始内容中不得直接以第二人称称呼读者（然后重新启动计算机）——除非直接引用声明或消息，否则应始终使用第三人称。

注重质量胜于数量——多不一定比少好，反之亦然。除非差异足够重要，否则避免给图库添加多个相似的图像。同样，在单篇文章中多次引用相同主题也不必全部链接到相关条目。

应避免的事项

请避免添加此类信息，因为对于大多数人来说，这被认为既无益又无关紧要。

专属于特定配置的错误或奇怪现象，或与在非预期环境中运行软件有关的问题（例如在新的虚拟机管理程序中运行旧版本）。 提及某个特定版本之前持续存在的故意更改。

引用特定软件版本，但错误地暗示它是包含某个更改的第一个版本，而该更改可能已出现在先前尚不可用的版本中。

屏幕截图

在 WinStory Wiki 中，屏幕截图也是绝大多数词条必不可少的的组成之一。基于 BetaWiki 成员 Foxlet 的词条要求，WinStory Wiki 对所有屏幕截图的要求如下： 剪裁到主题的精确大小（桌面或应用窗口）

  • 不得以任何方式缩放或扭曲
  • 以无损格式保存，例如 PNG
  • 在符合时代背景的分辨率和色深下拍摄
  • 展示产品的干净、原始安装
  • 使用默认设置，除非目的是展示某个设置的效果
  • 不包含任何产品本身未包含的自定义图形

如果可能，请使用 Windows 截图功能（Print Screen 键、截图工具）拍摄桌面，或者在使用虚拟机/模拟器时使用其截图功能。如果完整截图中有光标，应尽可能将其隔离在背景的一角（以展示其独特功能）。

示例

好截图
差截图
  • ❌ 差截图： 不是实际尺寸，质量低，图形显示在真实桌面之外

    ❌ 差截图：
    不是实际尺寸，质量低，图形显示在真实桌面之外

  • ❌ 差截图： 像素被拉伸，应用缩放滤镜

    ❌ 差截图：
    像素被拉伸，应用缩放滤镜

  • ❌ 差截图： 图像小于真实比例

    ❌ 差截图：
    图像小于真实比例

  • ❌ 差截图： 图像使用图像编辑器进行标注

    ❌ 差截图：
    图像使用图像编辑器进行标注

  • ❌ 差截图： 分辨率和色深不足

    ❌ 差截图：
    分辨率和色深不足

  • ❌ 差截图： 使用 Aero 效果时透明度不可见，部分背景可见

    ❌ 差截图：
    使用 Aero 效果时透明度不可见，部分背景可见

  • ❌ 差截图： 图像包含的图形未包含在操作系统中

    ❌ 差截图：
    图像包含的图形未包含在操作系统中

  • ❌ 差截图： 图像以有损压缩格式保存且裁剪过度

    ❌ 差截图：
    图像以有损压缩格式保存且裁剪过度

  • ❌ 差截图： 图像有额外的图形，且裁剪不当，尽管它符合所有其他标准

    ❌ 差截图：
    图像有额外的图形，且裁剪不当，尽管它符合所有其他标准

词条截图

在应用截图中不应显示桌面。

每个词条通常需要三个部分的屏幕截图：桌面、关于窗口，以及（有时）登录界面。在大多数情况下，版本词条只需要前两个。完整截图（如桌面和“开始”菜单）应以操作系统发布时较为流行的分辨率拍摄。基于这样的情景，对于屏幕截图的分辨率，在确保原始画质的情况下，需要的要求如下：

对于过渡版本，分辨率规定如下（建议）：

  • Windows 3.x 至 Windows 9x 过渡版本，建议 800×600；
  • Windows 2000 至 Windows Vista 开发重置前之间的过渡版本，建议 1024×768。
  • 对于 Windows 11 及以后版本，除部分版本的特殊限制，建议 1280×800；

屏幕截图不得使用主题、壁纸或其他不在主题内容中存在的图形，即使是“演示”截图。大多数截图应使用默认设置拍摄，除非截图的目的是展示设置的效果。截图应显示安装后干净的状态，没有额外安装的软件，除非截图显示了该主题的某些特征，否则无法通过其他方式证明。任何个性化选项都可以在画廊中的演示截图中合理展示。建议使用一台独立的机器（无论是否虚拟化）并保留操作系统或应用的干净副本以用于截图。

桌面照片应该不包括额外的窗口。它应表示系统在完全空闲、没有运行任何程序时的状态。如果操作系统在初始设置后立即显示工具或特殊图形（如欢迎界面），截图将因此视为“首次启动”镜头，与桌面快照分开。

每篇文章还可以包含一个图库，里面包含其他相关屏幕截图。更多完整截图也属于这里，比如“展示版本”（展示了版本中特别独特的特性）。剩余的屏幕截图通常是某个版本独有程序的。这些截图应裁剪成程序窗口大小（包括透明和窗户阴影，如果有这些效果的话）。子窗（如果有的话）应该能在整个区域内看到。文章截图应避免使用图片编辑器（如画图）添加任何水印或注释。[a]

对于通过桌面窗口管理器合成的窗口截图（此管理器会产生 Windows Vista 及后续操作系统中观察到的半透明和投影效果），建议使用能够生成保留上述特征截图的应用。我们通常推荐使用 AeroShotCRE，它提供了多样的可定制选项，可以进一步提升截图的整体质量。我们也推荐使用 AeroShot，大多数情况下的透明效果截图都可以通过它完成。[b]这个过程也可以手动完成，比如在白黑背景下截两张截图，然后用图像编辑器遮挡半透明部分。

安装程序屏幕截图
启动屏幕截图
  • 启动屏幕

    启动屏幕

  • 同上一个

    同上一个

桌面屏幕截图
  • 桌面

    桌面

  • 同上一个

    同上一个

  • 首次启动截取

    首次启动截取

关于屏幕截图
其他

注

  1. ↑ 此规则的唯一例外是，如果相应的版本未公开发布，且唯一可用的截图要么带有水印、带有注释，或质量低下。在版本公开发布之前拍摄的图片可以为了公众利益而保留，并需标注为此类图片。
  2. ↑ 如果你尝试在较新的 Windows 版本上运行 AeroShot，例如在 Windows 8.x 或 Windows 11 上，你可能需要通过“可选功能”控制面板小程序或通过部署映像服务和管理工具（DISM）安装 .NET Framework 3.x 按需功能包。
取自“https://wiki.win-story.cn/index.php?title=WinStory_Wiki:词条编写指南&oldid=61434”