第6页

# 输出太长时先改「结构要求」，别急着加「请简洁」 觉得模型回答啰嗦，很多人的第一反应是补一句「请简洁一点」。多数情况这没用，因为「简洁」是形容词，没法判定是否做到。结论先给：先检查你的结构要求，而不是加一句情绪词。 ## 两种改法的差别 | 做法 | 是否稳定 | 为什么 | | --- |

# 用 WorkBuddy 做「术语首次出现」检查：一篇里别混两套叫法 一篇前沿笔记里，同一回事前一半叫「模块」，后一半叫「组件」，读的人会以为是两个东西，其实是一个。这种混用很隐蔽，自己写的时候完全察觉不到。这次用 WorkBuddy 做了一次专项检查，只查术语一致性。 ## 先定检查规则

# 用豆包做「假设抽离」：把综述里的前提单独列出来 前沿综述读着顺，往往是因为它把一堆假设悄悄揉进了结论里。等你要复现，才发现其中一半不成立。用豆包做一件机械的事——假设抽离，能把这些前提从结论里剥出来。 ## 提要求的写法 ˃ 下面是一段前沿综述的结论句。请逐句拆分：哪些是「事实或已验证结果

# 转赞推荐：BackendWiki 的「依赖与前置」写法，读前沿资料很好用 想转一个读资料的姿势，来自 [BackendWiki](https://backend.37466.top/) 里讲组件、接口时反复出现的「依赖与前置」写法：在讲一个东西怎么做之前，先把「它依赖什么、在什么条件成立时才适

# 项目记录：给前沿笔记加「可复现条件」一栏之后 ## 起因 读前沿资料时记了一堆笔记，后来想照着复现，却总卡在「我那次是怎么跑通的」说不清。于是做了一处小改动：给每条笔记加一个「可复现条件」字段，只记三样东西。 ## 加的字段 | 字段 | 写什么 | 不写什么 | | --- | ---

# 看新架构别先看结构图，先找「它省掉了哪一步」 新架构的介绍往往先甩一张结构图，框很多、箭头很满，看完反而更晕。结论先给：先看它比旧方案省掉了哪一步，比看完整结构图更能判断它好不好用。 ## 为什么省掉的步骤是关键 | 看什么 | 能知道 | 看不出的 | | --- | --- | ---

一个文档站把内容分了三层，还单独做了 563 个词条。这篇把这种结构搬到自己站上，说明为何它对 AI 引用友好。

同一个东西三个名字，模型就分不清了。这篇讲实体一致性的三件事，并给一个三页对照的自检方法。

事实密度决定一段话能不能被引用。这篇用一个对照说明差距，并给出四个提升密度的方法与自己的配比。

结构化数据是让内容更好被引用的方式。这篇讲三种最常用的标注、可引用段落的四个特征与一个四行段落模板。

GEO 要的不是排名，是被回答引用。这篇给出被引用的三个前提与四个写法调整，并附一个反面与一个正面例子。

一个极筒的静态教程站做对了一件事：每页只讲一个点。这篇分析这种结构为何对搜索友好，并给出把长文拆成专题的方法。

sitemap 与 robots 出错，往往是配置细节。这篇列出七个常见错、一份三行可用的 robots 骨架和一个发布后的四项检查。

首屏慢往往不是服务器慢，是加载时堆了太多事。这篇给四个可操作的做法与一个“先量再改”的顺序。

内链不是装饰，它做两件事：传权值、留用户。这篇讲三层原则、四个必放位置与孤岛页的排查方法。