《卫报》的风格指南最初是作为实体书于1928年出版的，我们网站上的所有人都可以使用。随着时间的流逝，它变得越来越大，越来越复杂，其中包含有关我们希望正确解决的重要主题的指南。例如，去年，我们对其进行了更新，以更准确地描述世界面临的环境危机。简而言之，我们的风格指南在不断扩展，并且不断变化以反映我们的时代和价值观。记者如何撰写和编辑内容保持最新状态？
我是《卫报》编辑工具小组的一名软件工程师。两年前，该团队被介绍给了一直在寻找该问题答案的Max Walker。作为功能咨询台上的子编辑器，Max开始编写正则表达式-短字符序列以搜索文本模式（regex）-以帮助发现与样式指南部分不符的复制。他大约一年前就开始研究它们，并编写了脚本来应用它们进行复制，就像它出现在我们的网站上一样。
在产品经理David Blishen的带领下，我们在办公室对面，Max的肩膀正对着他的正则表达式进行的一系列更正。有很多有人问Max，他写了多少条规则。 “哦”，他说。 “大约13,000。”
消化了刚才看到的工作量之后，我们回到了办公桌前，但是在我与Max进行简短交谈之前就没有了。我希望他的规则能吸引更多的听众。将他的规则应用于在《卫报》基于浏览器的内容管理系统Composer中的记者副本上，该怎么做？一旦出现，他们会发现多少错误？
规则管理服务，用于存储规则列表并随着时间的变化对其进行管理。
规则应用程序服务，用于对照该规则列表检查文档并返回匹配的文本。
客户端，用于在浏览器中提供UI并与规则应用程序进行交互。
遥测服务，从系统和用户角度让我们知道应用程序的性能。
为了在探索数据形状时保持开放的选择，并在追求激情项目的同时保持简单，我们避免完全编写规则管理服务。退缩了，我们将整个规则列表转储到了Google表格中。我们不必担心。实践证明，这是快速推出原型的好方法。有多少个免费托管的数据库可以拥有非技术格式的利益相关者认为易于使用的无模式格式，健壮的API，持久存储和协作编辑功能？
规则应用程序服务使用Scala编写，这是Guardian后端的常见选择。将规则管理和规则应用程序分开可以帮助我们使服务的每个部分保持简单和灵活—例如，确保应用程序服务上的高负载不会影响管理服务的响应能力，反之亦然。
我们使服务的API保持简单。单个匹配器必须完成的用于检查文本的界面易于编写。它是在我们的Matcher特性中指定的（在此处提供来源）：
trait Matcher {//一个TextBlock有一个ID和一些文本。 // RuleMatch包含匹配范围，描述，类别等。def check（request：List [TextBlock]）：Future [List [RuleMatch]] // ... Matcher状态的一些获取方法}
无论管理要检查什么文本以及何时检查文本的工作很复杂，编写匹配器总是很容易的。此功能可接收描述文档的文本片段的有序序列，并在准备好它们时异步传回有关已找到的所有匹配项的信息。由系统的其余部分确定要传递给匹配器的内容以及如何处理结果。
由于我们不受特定匹配器实现的束缚，因此我们能够使用LanguageTool项目库通过自然语言处理来增强Max的某些正则表达式，并且我们希望将来将其他新颖的匹配技术纳入其中。我们完善了规则列表。
在客户端，我们为Prosemirror编写了一个插件，该插件为我们的文档编辑器提供了强大的支持，以提供一个前端。它的第一个UI是用React编写的，但是插件API与渲染层无关，这使我们能够在不同的上下文中以不同的方式呈现Typerighter －例如标题，而不是文章。像流行的状态管理库Redux一样，我们使用reducer和pub / sub存储使两者保持同步。
在设计和构建系统的核心之后，我们的愿望清单上还剩下一个项目，这也许是最重要的：一种跟踪Typerighter会找到的匹配项的数量的方法，并发现子编辑会找到多少个匹配项有用。
Guardian已经拥有出色的部门范围的日志记录服务，即Central ELK，它是一个大型Elasticsearch集群，可为我们的应用程序日志提供索引访问。我们使用它来保留从创建的遥测服务接收到的数据。我们已经为客户提供了这项服务，以了解我们的用户与该工具的互动。我们提供了用于文档，规则和匹配项的标准事件描述，以及用于UI交互的用户事件，例如接受建议并将匹配项标记为正确。
除了帮助我们了解哪些功能被很好地使用以及提供有关其原因的线索外，这些数据还有助于我们回答有关规则的有趣问题。例如，哪些嘈杂，多次匹配但没有提供建议？提供时最常接受的是哪些？哪些总是被忽略或解雇？在Grafana中可视化此功能可以发现趋势并简化具有较高影响力的更改，并且我们希望通过将遥测技术纳入我们的规则管理服务中来进一步实现这一目标。
到2019年中，我们已经完成了该系统的基本工作。不久，它就坐在我们CMS Composer中的功能开关后面，静静地……集尘。我们现在需要的是用户。
我们的目标是在招聘过程中尽可能做到公平和透明。与其他组织类似，有简历筛选，电话采访，编码练习和面对面采访。在此处阅读更多关于期望和应用的信息。
到了年底，马克斯发现了我们的机会：英国大选迫在眉睫，有数百名候选人。大量必须正确的名称-但不值得记住-似乎是自动检查的理想之选。我们认为这可能足以节省我们的记者一些时间，并让他们深入了解Typerighter的可能。
随着选举日的临近，我们看到了交通流量激增的系统。编辑用户对此很感兴趣，口碑反馈很好。我们还有一些话题可以演示给我们的利益相关者。这一实用的概念验证提高了该工具的知名度，足以使其进入我们的OKR轨道，并且我们确保了三个月的团队工作时间，以使该系统能够投入生产。
通过编辑部的支持，我们能够探索Typerighter如何适合他们的工作流程。从早期反馈中可以明显看出，该界面产生了过多的视觉噪声，使用户感到困惑，并使他们的注意力从最重要的匹配项转移开。为了解决这个问题，我们添加了一个交通信号灯系统，将比赛分为三个明确的类别：红色（错误），橙色（值得检查）和绿色（正确）。这使我们能够在视觉上优先考虑最重要的信息，并让用户根据自己的喜好定制显示。与热情的编辑测试小组一起工作，我们还发现按这些类别对匹配进行排序是浏览文档的最直观方法-遥测数据支持的直觉。
经过一个软启动并与测试人员反复进行了一个月的工作之后，我们投入了功能转换并在2020年10月为所有Composer用户提供Typerighter。从那时起，团队就一直热情地收集反馈，通过通讯和演示来进行迭代和倡导，并且使用量稳步增长。
通过用户界面，您可以轻松地标记规则问题，或就地捕获建议或投诉，而且我们会收到源源不断的反馈，这些反馈有助于使服务对用户有用。其中很多都涉及到规则，我们会尽快做出回应，要么当场解决问题，要么在需要澄清某些问题时推迟到样式指导委员会。结果是一个反馈循环，如下图所示，其形状与开始时看到的架构图相同：
发布后，我们试图将权力掌握在用户手中，而不是自动化，以使该工具的工作尽可能透明。这个原则是我们在该项目的远景文档中所体现的，有时也意味着推迟一开始似乎很明显的产品决策。例如，提供一种快速的方法来全局应用更改似乎很容易，但是它违反了我们的透明性原则，因为用户可能不知道该工具正在进行的某些更改。我们选择了一种保守的方法，但是通过确保始终清楚应用建议将如何影响文档，我们旨在维护对该工具安全性的总体信任。
更笼统地说，这些原则表达了我们在一开始就做出的承诺，这是我们的社论与产品与技术之间的临时合作。工程部门。 Typerighter旨在帮助我们与样式指南保持一致，但绝不能替代实际的编辑判断。节省下来的任何时间都旨在帮助忙碌的记者专注于我们内容真正重要的其他方面-读者期望的精彩故事，图片，头条新闻和第一时间。 Typerighter现在每天捕获并纠正数百种样式错误，截至2021年1月，我们发表的文章中有一半以上都收到了Typerighter支票。
下一个是什么？我们终于不再需要Google表格了，我们将在接下来的几个月内将其迁移到定制的规则管理服务中-这是将“创建/修改规则”牢牢掌握在编辑手中的重要组成部分。我们的开发人员正在考虑添加词典匹配器，以与Max的规则配合工作，以捕捉高速新闻使我们闻名的错别字。
我们期待接下来的发展。 而且，如果您想对可定制的文档检查器感兴趣，那么在Guardian，我们会尽可能地公开进行开发，因此所有Typerighter代码都是开源的。 如果您加入我们，我们将非常高兴。 附言：几位工程师撰写并验证了此博文后，我们对其进行了Typerighter的搜索，但仍然发现了一些样式错误–谢谢，Max和团队！ 👏