编辑、引用与纠错规范¶

书稿的阅读顺序¶

书稿以英文为主稿，配有完整简体中文版。各节围绕读者真正会问的问题展开：先给出回答，再解释机制、例子与适用边界。好的既有段落不因统一格式而重写，技术错误则应及时修正。

网站允许按主题查阅，书稿按连续的篇章顺序阅读。正文不应要求读者反复跳转才能理解当前问题；交叉引用用于补充细节。电子书的图、公式、代码和表格也应在离线与窄屏条件下可读。

来源选择¶

双语迁移时，中文原稿用于保留内容范围和示例，原始英文论文、规范及官方文档用于核对技术含义。不能用模型记忆覆盖这两类来源。两者冲突时，应按相关版本查证，并在中英两边同步做有依据的修正，留下证据和核对范围。

资料优先级依次为规范与标准、官方文档、原始论文、带完整环境说明的工程报告，以及能够交叉核验的从业者经验。厂商案例可以用于说明做法，但厂商自报的性能、成本和客户收益不会直接视为独立验证结果。

引用应尽量靠近对应事实。文末“参考资料”提供延伸阅读，不代表正文中的所有判断都由某一条链接单独支持。

时效性与版本¶

模型能力、框架 API、协议规范和云服务配置变化很快。相关章节应注明核验时间、版本和适用条件。页面底部的创建与更新日期来自当前文件路径的 Git 历史；目录迁移可能改变创建日期，大规模排版或文风修改也可能刷新更新时间，因此判断技术时效性时仍应查看正文中的版本说明和上游链接。经典方法不因年代较早就被删除，但历史 API 不应当作当前推荐用法。

原创分析与外部事实¶

架构分层、选型表和工程建议通常是作者根据公开材料做出的归纳。可核验的数字、产品能力和他人观点应附来源；由多个来源推导出的工程判断应明确适用条件，避免写成无边界结论。

虚构案例必须明确标注假设场景和模拟数据。验收目标是事先约定的门槛，模拟结果用于说明评测方法，真实生产效果则需要实测证据，三者不能相互替代。面试练习时应说明“如果面对这个场景，我会如何设计”，不能把虚构案例说成亲自交付的项目。

中英文怎样保持一致¶

实质内容修改先从英文开始，对应中文在同一个 PR 中审阅。两版使用相同的章节标识、示例和技术结论；标题、解释和图标签可以按语言表达，标识符、协议字段、单位、数据和数学含义不能漂移。

同步记录标识一起审过的英文与中文版本，用来发现缺页或陈旧配对，不证明翻译质量。不能未读正文就刷新记录；英文只改措辞时，可以在确认中文仍准确后保留原有中文。

纠错流程¶

发现问题时，请通过 GitHub Issue 提供：

页面链接和具体段落；
认为有误或已经过时的内容；
可供核验的一手来源；
建议修改方式。

修正会通过公开提交记录保留。涉及争议性判断时，优先补充条件和来源，而不是直接删除不同观点。

许可范围¶

仓库中的原创文档和图表采用 CC BY 4.0 许可。引用的第三方商标、截图、论文、代码片段和外部材料仍受各自权利人与原始许可约束。

署名与通用许可说明集中放在项目说明和书末，不在技术章节之间重复出现。集中呈现不改变已有许可，也不免除保留第三方必要声明的义务。