矩阵是地图，不是分数表
团队往往在招聘标准不一致或晋升讨论过于主观时建立技能矩阵。给几十项能力打 1 到 5 分看起来很精确，但如果没人能说明三级和四级之间需要什么证据，这些数字没有意义。
从可观察的能力开始：调研、写作与编辑、信息架构、API 理解、工具链、发布协作、质量自动化和跨团队沟通。
描述范围与独立性
对每项能力说明一个人能够解决哪类问题，以及需要多少支持。初级作者可能在审核下修改既有流程；更有经验的作者可以自己发现流程、向工程师验证、设计结构，并为后续变化建立审核机制。
这种描述比“沟通能力优秀”更有用，因为它可以对应具体产物和决策。
区分通用能力与领域知识
不要把某个产品的技术栈直接等同于资历。Kubernetes 对一个岗位可能重要，对另一个岗位却毫无意义。长期有效的文档能力应与本地领域知识分开。
工具也是如此。Docs-as-Code 团队可能要求 Git，但熟悉某个生成器本身并不能定义职业等级。
让矩阵支持双向使用
经理可以用它说明期望，写作者也应该能用它选择下一项练习目标。为每项能力提供证据示例，例如重构导航、制作经过测试的 API reference、迁移术语或建立 CI quality gate。
工作变化时再更新矩阵
AI 辅助写作、结构化内容和文档工程正在改变工作。不要因为出现一个新术语就增加一行，而应在实际工作方式变化时调整。
长期不变的问题是：这个人能可靠地负责什么有价值的文档问题？
实践示例
把《建立真正衡量工作能力的技术写作者技能矩阵》当作团队练习，而不是职位名称清单。选择最近一次文档任务，回溯谁发现了用户需求、谁获得技术事实、谁设计结构、谁完成审阅，以及谁负责下一次修订。
用可观察的能力描述人员：
- 能在多大程度上独立负责问题；
- 能与哪些专家有效沟通并提出质疑；
- 能在发布前发现哪些质量风险；
- 能改进什么文档流程，而不仅仅是使用工具。
好的职业模型应该告诉人下一步需要练习什么更复杂的问题。如果只产生“初级”“高级”“沟通好”之类标签，就不足以指导成长或招聘。
快速编辑检查
- 矩阵是地图，不是分数表. 团队往往在招聘标准不一致或晋升讨论过于主观时建立技能矩阵。
- 描述范围与独立性. 对每项能力说明一个人能够解决哪类问题，以及需要多少支持。
- 区分通用能力与领域知识. 不要把某个产品的技术栈直接等同于资历。Kubernetes 对一个岗位可能重要，对另一个岗位却毫无意义。
- 让矩阵支持双向使用. 经理可以用它说明期望，写作者也应该能用它选择下一项练习目标。
