tech-doc-style-chinese

name	tech-doc-style-chinese
description	在撰写、改写、校对或审阅中文技术文档、产品文案、界面文案、Markdown 文档、API 说明、操作手册、故障排查或运维文档时使用。采用克制、准确、可扫读的中文技术写作风格；保留原文事实、限制和机器可读内容；按任务读取术语排版、API 状态文案、项目覆盖或受控中文技术写作参考。

中文技术文档与产品文案规范

适用范围

将本 Skill 用于中文技术内容的撰写、改写、校对和审阅，包括：

• 文档首页、产品介绍、解决方案页和更新日志
• API 文档、参数说明、错误码和常见问题
• 操作手册、故障排查、运维 Runbook 和安全说明
• 界面文案、按钮、导航、状态和提示信息

不要改写代码字面量、JSON 键名、URL、API 路径、数据库字段名、命令、配置项或其他机器可读标识符。

规则优先级

发生冲突时，按以下顺序处理：

1. 保留事实、逻辑、限制、安全信息和法律含义。
2. 服从用户明确要求和目标项目约定。
3. 保持技术术语和机器可读内容准确。
4. 改善结构、语义、语气和可扫读性。
5. 最后处理标点、留白、大小写等排版细节。

不得为了句子更短、语气更确定或格式更统一而牺牲更高优先级的信息。

事实保真

• 不新增原文或可靠上下文没有提供的日期、数字、时限、SLA、能力、条件、因果关系或结论。
• 不删除前置条件、适用范围、例外、风险、安全警告、兼容性说明或失败处理。
• 不把可能、计划、建议、通常等不确定表达改成确定事实。
• 信息不足时保留原意，或明确标记「待确认」；不要自行补全。
• 改写引用、法规、合同、错误原文或用户提供的固定文案时，优先保持原文并将建议单独列出。

示例：

• 截止 4 月 12 日 -> 截至 4 月 12 日
• 尽快处理 -> 在约定时限内处理〔具体时限待确认〕
• 不要凭空补成 截至 2026 年 4 月 12 日 或 30 分钟内处理

先判断任务模式

撰写

• 先确定受众、内容类型、事实来源、发布载体和篇幅。
• 缺少会改变结论的事实时，先标记缺口，再继续组织可确认内容。

改写

• 保留事实、逻辑关系、信息层级、限制和必要例外。
• 默认交付完整改写稿；重大语义选择或待确认内容另行说明。

校对

• 只处理约定范围内的错字、标点、留白、大小写和术语一致性。
• 未经要求，不改变结构、语气或事实表达。

审阅

• 先列问题，再给建议；按影响程度排序并引用具体原文。
• 未经授权，不直接修改文件。

核心写作规则

语义与语气

• 准确先于修辞，清晰先于热闹。
• 使用克制、直接、可执行的中文。