文档编辑器
代码块与代码组
按交付目标选择 Code 还是 CodeGroup,而不是只放一段代码。
技术文档里最容易写散的部分,就是命令、配置和示例代码。Anydocs 提供 `Code` 和 `CodeGroup` 两种主要代码展示方式:前者适合单一示例,后者适合同一操作的多种等价写法。选对结构,reader 可读性和 AI 消费质量都会更高。
Steps
- 先判断是一段示例,还是一组等价示例
- 给代码块明确语言或标签语义
- 让代码和正文形成闭环
- 把 reader 展示和主题一起考虑
先判断是一段示例,还是一组等价示例
如果你只有一个 shell 命令、一个配置片段或一个 API 调用示例,使用 `Code`。如果你想同时展示 npm / pnpm / yarn,或者 JavaScript / Python / curl 这类等价写法,使用 `CodeGroup`。不要把无关示例硬塞进同一个代码组。
给代码块明确语言或标签语义
单代码块应尽量对应明确语言,如 `bash`、`json`、`ts`、`python`。代码组则应保证每个 tab 的标签语义稳定,例如按包管理器、按 SDK 语言、按运行环境分组,而不是一个 tab 写命令、另一个 tab 写结果。
让代码和正文形成闭环
代码块前后都应有最少量说明,告诉读者这段代码解决什么问题、在哪里运行、预期效果是什么。技术文档最差的写法,是把大量命令堆出来却没有上下文。
把 reader 展示和主题一起考虑
reader 的代码高亮主题来自项目设置中的 `site.theme.codeTheme`。这不会改变代码内容本身,但会影响可读性。跨语言代码组尤其需要保证缩进、命名和注释风格尽量一致,否则切 tab 后会显得像不同作者写的。
推荐场景: `CodeGroup` 特别适合安装命令、SDK 示例、同一 API 的多语言调用方式。
不要把输出日志当正文: 大段构建日志、终端噪音或与步骤无关的调试输出,不应直接堆进最终文档。保留真正有解释价值的片段即可。