编辑原则与页面复核标准

1. 我们发布什么样的页面

ToolsKit 发布两类核心页面：可直接使用的工具页，以及把多个工具串成完整任务路径的 guide。对我们来说，页面价值不只来自“能不能运行”，还来自“用户能不能据此完成真实任务”。

因此，一个页面至少需要说明用途、使用方式、边界条件、常见失败点或修复路径中的一部分。只有功能，没有解释和判断边界的页面，不是我们希望长期保留的内容形态。

2. 页面进入发布前会经过什么流程

1. 01

   先定义页面要解决的问题

   明确页面目的、目标用户、关联工具、语言版本和搜索意图，避免写成泛化内容。

2. 02

   补足可执行信息

   在功能介绍之外，优先加入步骤、案例、错误样本、判断边界、修复动作或核对清单。

3. 03

   统一执行发布门禁

   发版前检查元信息、结构一致性、内容完整度、埋点覆盖与关键交互状态。

4. 04

   发布后继续观察与补强

   根据反馈、搜索表现和真实问题继续修订页面，而不是一次上线后停止维护。

3. 页面必须满足的最低标准

4. 什么会触发重写、降权或补强

• 页面只剩工具功能介绍，几乎无法支撑独立完成任务。
• 不同页面出现大段结构重复，但没有新的案例、判断边界或场景差异。
• 搜索意图虽明确，但页面没有解决用户最常见的错误输入或失败场景。
• 页面流量上升后暴露出说明不足、误导性文案或更新频率过低的问题。

5. 我们如何控制薄弱页面

薄弱页面通常不是某个句子写得太短，而是整页无法支撑用户完成任务。我们会重点检查页面是否只是换标题的模板页、是否缺少真实案例、是否没有失败样例、是否把说明压缩到了只剩定义。

• 重点检查 guide 是否只是“3 个小节 + 少量描述”的轻量模板，而没有真正展开。
• 对工具页优先补失败样例、真实任务案例、诊断逻辑和结果解释，而不是继续平均加字。
• 当页面无法在当前阶段补强到位时，会优先降级其站内权重，而不是强行放大它。

6. AI 辅助内容的使用边界

我们允许使用 AI 辅助生成草稿、整理结构或扩展例子，但不会直接发布未经复核的稿件。发布前需要人工确认技术正确性、术语一致性、语言可读性、跨语言对齐，以及页面是否真的比用户自己搜索一圈更有帮助。

7. 纠错与责任归属

核心工具页、guide 与信任页由 ToolsKit 编辑团队维护。用户反馈会回到具体页面处理，而不是只停留在收件箱里。对于结果正确性、误导性文案、隐私说明和使用边界问题，我们会优先进入纠错流程。