原理基础版写作规范

《大模型原理入门：从 Token 到 Transformer》是电子书式内容，不是课堂讲稿，也不是工程实战教程。写作目标是让有开发经验的读者在不学习复杂数学推导的前提下，理解大模型的底层机制。

核心定位

每一章都应该回答一个原理问题，例如：

大模型为什么不是数据库？
预测下一个 Token 为什么能产生复杂能力？
Attention 为什么是 Transformer 的核心？
模型为什么会幻觉？

文章可以联系开发者经验，但不要展开工程实现方案。基础版和进阶版已经覆盖了 Prompt、RAG、Agent、Eval、网关、上下文工程等实践内容，本书只解释这些现象背后的模型机制。

统一章节结构

每章建议包含这些部分：

开篇问题：用一个读者熟悉的问题进入。
本章你会理解什么：列出 3-5 个学习目标。
核心概念：解释本章关键词。
机制拆解：按步骤讲清楚原理。
开发者常见误解：纠正常见错误直觉。
小实验 / 思考实验：帮助读者自测理解，不做复杂工程。
本章小结：用 3-5 条收束。
自测题：给出 5 道左右问题。

写作风格

使用电子书正文风格，不写“同学们”“本节课我们来讲”。
少用公式，必要时先给直觉，再给简化表达。
多使用开发者能理解的类比，例如接口、缓存、编译、状态、索引、压缩、概率分布。
不神秘化大模型，不把能力说成魔法，也不把错误简单归因为“模型不够聪明”。
每个核心概念至少配一个例子或思考实验。

边界要求

可以提到工程概念，但只用来解释原理边界：

可以说 RAG 为什么常被用来补外部知识，但不要讲 RAG 架构。
可以说 Prompt 会改变条件上下文，但不要讲 Prompt 模板设计。
可以说 Agent 依赖模型规划和工具，但不要讲 Agent 工程实现。
可以说评估能发现错误，但不要讲 Eval 系统搭建。

质量检查

每章完成后，用下面的问题做自检：

读者能否在不懂深度学习的情况下读完？
这一章是否只围绕一个核心问题展开？
是否避免了和基础版、进阶版的工程实践内容重复？
是否解释了机制带来的能力，也解释了机制带来的边界？
是否有足够的例子、误区和自测题？

好的章节不是把所有知识点堆进去，而是让读者读完后终于能说出一句清楚的话：原来这个东西是这么工作的。