项目记录：给一份产品页补“定义与边界”章节后的变化
起因
一份产品页写得很努力：功能、优势、使用场景、案例，一应俱全。但读者常问的两类问题始终没解决——“它到底是不是做 X 的”“我们这种情况算不算能用”。页面里其实有答案，只是散在几段描述里，得自己拼。
于是没改功能介绍，只补了一个很短的章节：定义与边界。
补了什么
章节只有三块，每块两三句：
- 一句话定义：它是什么，用“是……”的句式，不夹带卖点；
- 明确不做什么：列出两三个最常被误认为属于它的能力；
- 适用条件：在什么规模、什么前提、什么版本下成立。
第三块特意写了版本与前提。以前页面里所有句子都像“永远成立”，读者只能自己判断对自己适不适用。
写定义时我参考了 Layui 镜像站对组件边界的克制表述——先划清是什么，再谈能做什么；参数与默认值这类硬信息，则按 BackendWiki 的表格化写法 列清，避免含糊。
变化
最明显的不是流量，是咨询内容变了。之前大量提问在确认“我们能不能用”，补完之后这类问题少了很多，剩下的多是具体实施细节——说明读者在页面上已经完成了自我筛选。
另一个变化出现在内容复用上：这段定义Frequently被整段摘走，因为它短、自足、带条件。相比之下，原来那些长段落虽然写得好，却很难被单独引用。
复盘
补的不是信息，是边界。功能介绍回答“有什么”，定义与边界回答“是不是、适不适合”。后者恰恰是生成式引擎和读者都最想先拿到的一层。
后来我把这个章节固化进页面模板：凡是新页面，先写一屏定义与边界，再写其余内容。顺序一换，后面所有段落都更容易读。想让生成环节就带上这类结构，可参考 HTML 入门教程站的静态化与结构化数据实践。