第7页

TDK 不是填空题。这篇讲标题要说清是什么、描述要写点进去的理由，并给一个发布前的四项自检。

推理服务占显存、启动慢、易被打穿，普通部署文档不提。这篇转赞工程文档里的习惯，给三个必调参数与一个健康检查方法。

榜单不测你的任务。这篇讲一个 30 道题的自建评测集怎么建、怎么评分、怎么长期维护。

微调、RAG、提示词不是替代关系，是三种成本结构。这篇给一张判断表和一个永远成立的先后顺序。

算 AI 费用最容易漏的三块：输入、输出、缓存。这篇给出公式与四个降本手段，按性价比排序。

温度与 top_p 不只是“高低”问题，关键是任务配多少。这篇给四个任务的推荐值与一套调试顺序。

从 BackendWiki 的部署文档里能学到 AI 项目最缺的东西：可重现。这篇给四个可复用的工程习惯与两个文件夹的最小落地。

具身智能的讨论大多悬空，但有进展一定有可验证的痕迹。这篇给三条观察路径，并列出被夸大的常见点。

推理模型不是更聪明，是“愿意多想”。这篇把三个决定成本的数字说清楚，并给出一个可操作的使用判断。

多模态检索听着很大，其实卡在很具体的地方。这篇从三步流程讲起，说清它做得好与做不好的六件事。

长上下文不是用来塞满的。这篇只讲三种真有用的场景，并给出四个省成本的技巧。

```markdown

```markdown

# 项目记录：给旧文章补「更新时间」字段后的观察 ## 起因 站里有一批两年前写的说明类文章，内容大体还成立，但页面上只看得到最初的发布日期。读者分不清「写得早但已修订」和「写得早就没动过」，于是做了一次小改动：给这些文章补上独立的「更新时间」字段，并在正文开头标一行修订说明。 ## 具体做了

# 让一段话可被摘引：先给结论，再给条件，最后给例子 一段文字能不能被完整摘走，很大程度取决于它的顺序。铺垫太多、结论藏在中间，摘引时就不得不连着上下文一起搬，最后往往被放弃。结论先给：按「结论、条件、例子」三段写，一段话就能独立成立。 ## 三段各自的分工 | 顺序 | 内容 | 常见毛病