写中文技术文档时用：统一中英混排、全半角标点与结构…

适用于撰写或审校中文技术文档、README 与 API 文档，统一中英混排、标点和结构，消除机翻味。

适用场景

解决思路

1. 遵循核心原则：排版服务于阅读体验，规范服务于一致性，内容服务于读者；参考《中文文案排版指北》。
2. 中英文之间加空格，如「使用 Git 进行版本管理，配合 Jenkins 实现持续集成」。
3. 中文与数字之间加空格，如「本次更新包含 3 个新功能和 12 个 Bug 修复」。
4. 数字与单位之间加空格，如「文件大小不超过 5 MB，响应时间控制在 200 ms 以内」。
5. 度数、百分比等不加空格，如「32°C」「95%」。
6. 链接前后加空格，如「请参考 [官方文档](https://example.com) 获取更多信息」。
7. 中文语境使用全角标点，如「注意：该接口需要鉴权，请先获取 Token。」。
8. 全角标点与英文/数字之间不加空格，如「项目使用 MIT 协议，详见 LICENSE 文件。」。
9. 括号使用：中文语境用全角括号，如「请运行安装命令（详见下方说明）」。
10. 括号内有英文或数字时用半角括号，如「该项目基于 Spring Boot (v3.2.0) 开发」。
11. 纯英文内容用半角括号，如「See the documentation (README.md) for details.」。
12. 中文引号推荐直角引号，如「「确定」按钮触发表单提交，「取消」按钮关闭弹窗」。
13. 中文引号也可使用弯引号，视团队规范而定，如「「确定」按钮触发表单提交」。
14. 嵌套引号示例：他说：「请点击『确定』按钮。」。
15. 数字规范：技术文档中统一使用半角阿拉伯数字，如「支持最多 100 个并发连接」。
16. 不要用中文数字写技术参数，如不要写「支持最多一百个并发连接」。
17. 数字使用半角字符，如版本号 v2.1.0、端口号 8080、HTTP 状态码 200。
18. 中英混排保留英文：专有名词，如 React、Kubernetes、Redis、MySQL。
19. 中英混排保留英文：行业通用缩写，如 API、SDK、CLI、ORM、CI/CD。
20. 中英混排保留英文：命令和代码，如 `npm install`、`git commit`。
21. 中英混排保留英文：协议和标准，如 HTTP、TCP/IP、JSON、REST。
22. 中英混排保留英文：没有公认中文翻译的术语，如 debounce、throttle、middleware。
23. 中英混排翻译为中文：有公认翻译的通用概念，如数据库、服务器、浏览器、框架。
24. 中英混排翻译为中文：描述性短语，如 version control → 版本控制，load balancing → 负载均衡。
25. 中英混排翻译为中文：文档标题和章节名尽量中文，技术名词可保留英文。
26. 技术术语首次出现时标注中英对照，如「消息队列（Message Queue）」「死信队列（Dead Letter Queue）」。
27. 术语后续出现直接使用，如「消息队列的消费者需要实现幂等性……」。
28. 避免过度翻译：保留业界通用英文术语，如「在 Controller 层做参数校验，Service 层处理业务逻辑」。
29. 避免过度翻译：不要强行翻译成看不懂的中文，如不要把 Controller 翻成控制器、Service 翻成服务层。
30. 避免过度翻译：不要把 Redis 翻成「远程字典服务」、Session 翻成「会话」缓存。
31. API 接口文档使用中英对照模板：标题格式如「创建订单 / Create Order」。
32. API 基本信息列出请求方式 (Method)、请求路径 (Path)、鉴权方式 (Auth)、Content-Type。
33. API 请求参数用表格，列包括参数名 (Field)、类型 (Type)、必填 (Required)、说明 (Description)。
34. API 请求参数表中填写 product_id、quantity、address_id、coupon_code 等字段，并注明必填和说明。
35. API 提供请求示例代码块，并标注 json；示例包含 product_id、quantity、address_id、coupon_code。
36. API 响应参数用表格，列包括参数名 (Field)、类型 (Type)、说明 (Description)。
37. API 响应参数填写 order_id、status、total_amount、created_at，并注明状态枚举和单位。
38. API 提供响应示例代码块，并标注 json；示例包含 code、message、data 等。
39. API 错误码用表格，列包括错误码 (Code)、说明 (Description)、处理建议 (Suggestion)。
40. API 错误码示例：40001 商品不存在、40002 库存不足、40003 优惠券已过期，并给出处理建议。
41. 金额表示必须明确单位，如 total_amount: 9900 // 单位：分（即 99.00 元）。
42. 不要不说明金额单位造成歧义，如 total_amount: 99.00 无法判断是元还是分，且浮点数有精度问题。
43. README 使用国内开源项目常用结构：项目名称、徽章、一句话介绍。
44. README 包含「特性」列表。
45. README 包含「快速开始」：环境要求列出 Node.js >= 20、MySQL >= 8.0。
46. README 包含安装命令，如 `npm install your-package`。
47. README 包含基本用法代码块，标注 typescript，示例 import、实例化、调用。
48. README 包含「文档」链接：使用指南、API 参考、常见问题、更新日志。
49. README 包含「示例」，指向 examples 目录。
50. README 包含「贡献指南」，欢迎 Issue 和 Pull Request，并链接 CONTRIBUTING.md。
51. README 包含「本地开发」命令：git clone、npm install、npm run dev、npm test。
52. README 包含「致谢」列出依赖项目及说明。
53. README 包含「许可证」，链接 MIT 和 LICENSE。
54. 消除机翻味：避免被动语态，如「被用来」改成「用于」。
55. 消除机翻味：避免冗余代词，如「你想要」直接说。
56. 消除机翻味：避免直译英文句式，如「这个函数用于计算用户折扣。更多信息请参考文档。」。
57. 消除欧化句式：长句拆成短句。
58. 消除欧化句式：把定语从句改成并列句。
59. 消除欧化句式：一句话只说一件事，如改成「这是一个前端脚手架工具，帮助开发者快速搭建项目，免去手动配置构建工具链的麻烦。」。
60. 避免过度翻译：打开终端，运行 npm install；不要把「终端模拟器」「节点包管理器」等强行翻译。
61. 避免中英标点混用：中文句子用全角标点，如「请先安装依赖，然后运行测试。」。
62. 避免中英标点混用：英文内容用半角标点，如 Run `npm install`, then `npm test`.。
63. 缺乏结构化时用列表和分段组织信息，如缓存策略分为存储层、写入流程、读取流程、缓存过期。
64. 缓存策略示例：存储层 MySQL（持久化）+ Redis（缓存）；写入流程先写 MySQL，再异步更新 Redis；读取流程先查 Redis → 未命中则查 MySQL → 回写 Redis；缓存过期 TTL 设为 30 分钟。
65. 发布前检查排版：中英文之间有空格。
66. 发布前检查排版：中文与数字之间有空格。
67. 发布前检查排版：中文语境使用全角标点。
68. 发布前检查排版：英文/代码部分使用半角标点。
69. 发布前检查排版：没有全角半角标点混用。
70. 发布前检查术语：专有名词保留英文原文。
71. 发布前检查术语：首次出现的术语标注了中英对照。
72. 发布前检查术语：没有过度翻译业界通用术语。
73. 发布前检查术语：术语使用前后一致。
74. 发布前检查内容：句子简短，没有欧化长句。
75. 发布前检查内容：没有不必要的被动语态。
76. 发布前检查内容：用列表和表格组织结构化信息。
77. 发布前检查内容：代码示例可以直接运行。
78. 发布前检查内容：没有「机翻味」。
79. 发布前检查格式：标题层级正确，不跳级。
80. 发布前检查格式：代码块标注了语言类型。
81. 发布前检查格式：链接可以正常访问。
82. 发布前检查格式：图片有 alt 文本。

适用边界 · 注意事项

• 仅在用户显式调用 /chinese-documentation 时使用；不要根据上下文自动触发。
• 非中文技术文档写作或审校不适用。
• 当团队已有相反排版规范（例如引号、全半角选择）时，以团队规范为准，不要机械套用。