用途：用于编写 API 文档、README、代码注释与 JSDoc、提交信息与 PR 描述、架构决策记录（ADR），以及向团队成员解释技术概念。不适用于营销文案、面向用户的内容或非技术沟通。
主要能力与约定：要求使用主动语态；提供可运行示例；保持句子简洁、文档可扫读；使用规范 Markdown；记录假设与决策。提交信息默认使用简单格式（单行）：[TICKET-ID] type: summary; summary2; summary3，用分号分隔多项变更；仅在用户要求“descriptive commit”时使用描述格式：一行摘要加项目符号列表。有效类型包括 feat、fix、refactor、chore、docs、test 等。有工单号时以 [TICKET-ID] 开头，无工单号则完全省略，不得使用占位符。仅使用 ASCII 撇号与连字符。
使用方式（决策指引）：API 文档需包含端点、参数、请求/响应示例与错误码；代码注释解释“为什么”而非“是什么”，避免显而易见的注释；README 包含目的、安装、用法、示例与贡献指南；技术决策记录背景、理由与影响；复杂概念用图示、示例、类比并拆分小节；错误信息说明问题、原因与可操作的解决方案。
限制与边界情况：根据受众调整技术深度，面向普通读者避免术语；定期审查更新过时文档，可用文档测试或 CI 检查；明确标注文档适用版本；面向非英语母语者使用简单清晰语言，避免习语与复杂句；确保代码示例可运行且经过测试，包含必要导入与初始化。
参考资料：https://www.writethedocs.org/guide/writing/style-guides/ 与 https://developers.google.com/style。