技能介绍

要解决的问题

代码库的 README、文档注释、提交信息和 Wiki 页面里经常藏着带有性别偏见或排他性的措辞——比如用 man hours 描述工作量、用 chairman 指代职位、或用带有极化色彩的比较句式。这类语言本身未必是恶意的，但它会潜移默化地塑造团队的沟通文化：新人读到「写得像女孩一样」式的玩笑时，感受到的信号是「这里不属于我」。alex Inclusive Writing Linter 要处理的就是这种无意识的语言偏见。

它如何工作

alex 同时提供 CLI 工具和 Node.js 库两种形态，核心能力是把文本作为输入，输出两类结果：

问题定位：逐条标记包含性别偏见、极化或排斥性表述的段落，并说明为什么这条措辞不合适
替代建议：为每个问题给出更包容的改写方案，而不是只报错不修复

典型的工作流是：把 README.md、PR 描述或任意纯文本文件交给它扫描，检查器逐行比对已知的不敏感表达模式，输出一份可操作的修改清单。团队可以把它挂进文档评审或 CI 检查环节，在文字合入之前就发现问题，而不是等读者已经感到被冒犯之后再补救。

适用边界

需要注意，这个技能目前无法自动提取基于源代码的安装方式或使用说明——它依赖上游仓库提供的部署配置，安装前需要手动查阅并审查上游项目。另外，语言模式检查是启发式的：它能命中常见的偏见表达，但无法判断上下文中的意图是否恶意，机械套用替换建议也可能在特定语境下显得生硬。建议把它当作写作评审的辅助信号，而不是自动改写内容的权威裁判。