写书

侧重：

底稿：

写进本 wiki：你当前的工作区就是本 wiki 的仓库，动笔前先读仓库里的 docs/skills/wiki-guide/index.md 和 docs/skills/collect/index.md（收纳的共用规矩），照写作流程写进仓库，和本页冲突的按本页。docs/projects/ 里已经拆过这个项目的，那就是底稿。板块按角度定：从零复刻、做实验讲的是一个具体的东西，进项目；领域对比讲一个领域问题的几种解法，进文章；具体目录盘问时一并问我。

读者读完能自己造出一个迷你版。

• 第 0 章是 baseline：这个领域最简单的做法，几十行能跑
• 之后每章加一个功能：先用一个案例让上一章的版本出问题，再加功能修好；贴本章改了哪些代码、跑出来的效果，再对照原项目的同一处，引源码 文件:起止行，说清迷你版省了什么
• 章节顺序照底稿里侧重那几条线的「问题 → 功能」排；上一章的代码是下一章的起点，每章结束都能跑
• 迷你版的代码自己写，每章真跑通；讲原项目怎么做时引它的源码，不拿迷你版代替
• 最后一章：迷你版和原项目还差什么，省掉的功能列一张表，每个写一句这本书为什么不需要它

读者读完能看清这个领域的设计空间：同一个问题有几种解法，各取舍了什么。

• 至少两个项目，最好都细讲过；只给了一个，先问我还拿哪几个比
• 每章一个领域问题，章名就是这个问题：先写成一个具体案例，再写每个项目怎么解、各引源码 文件:起止行，末尾一张对比表——机制、代价、适合什么场景
• 同一个东西各项目叫法不同，全书统一用一个通用说法，第一次出现时列出各项目的原叫法
• 只有一个项目做了的功能不单独成章，并进最相关的那章顺带一句
• 最后一章：这个领域还没人解好的问题

读者读完能知道哪些功能真管用、管用多少。

• 每章一个功能或一个设计决策：关掉它（消融），或换成另一种常见做法（反事实），量效果变了多少
• 先定指标再跑：指标能自动算，或者有写死的评分标准；每章写清样本、对照、重复几次，报均值和波动，不只报跑一次的结果
• 用项目自己的代码跑：开关和替换做在它的配置或最小改动上，不重写它的逻辑；跑项目代码的进程里不放任何密钥
• 大批量调模型的，先估花费报给我
• 实验设计就是正文，写进每章；脚本和原始输出放附录
• 最后一章：一张总表，所有功能按效果大小排