为 OpenSEO 网站撰写和审校用户可见内容时…

在 web/content 或 web/src 中新增或修改面向用户的文案（博客、指南、功能页、FAQ）时，用可追溯的事实、直给的答案和真人语气来写与审。

适用场景

解决思路

1. 确保每一条能力声明、价格和截图都能对照代码、事实表（src/server/features/onboarding/openseo-fact-sheet.md）或线上产品验证；指不出哪里为真就不发布。
2. 把真实答案放在开头："不"、"不是无限"、"要花钱"本身就是完整答案；不要用模糊措辞让读者推断出比事实更讨喜的结论。
3. 诚实说明定价并给出理由：优质 SEO 数据到处都贵，大厂套件每月 100 美元起；OpenSEO 是平价选项——每月 10 美元、可免费开始，绝不要简单说成"免费"。
4. 像真人一样说话：修正 AI 腔的办法是把底层主张用平实的话重述，而不是打磨辞藻；参考 deslop skill（../deslop/SKILL.md）了解要猎捕什么、怎么改。
5. 保持以读者为先的高度：指南要教能独立成立的、可操作的 SEO，而不是产品文档或泛泛填充；免费资源要归功于真正的所有者（Google 的 autocomplete、读者自己的 Search Console）。
6. 统一标准、覆盖全站：标准提升时，把所有 FAQ、所有页面都扫一遍对齐，而不只是被注意到的那一处。
7. 使用 playbook 术语：OpenSEO playbook 中的每种方法叫 "strategy"，绝不叫 "play"；读者执行的步骤叫 "workflow"；"playbook" 只用于指完整集合。
8. 审校时自问：如果读者相信了每条声明和截图，然后立刻打开 OpenSEO，哪里会对不上？
9. 审校时自问：每个回答是否以真实答案开头，还是悄悄引向更讨喜的推断？
10. 审校时自问：把最尖锐的那句读出声——真人会那样说吗？
11. 审校时自问：有没有把实际要消耗 credits 的东西说成免费？
12. 审校时自问：这是在教读者真正有用的东西，还是滑向产品文档或凑字数？
13. 审校时自问：页面上每个链接、图片和示例是否都为读者赢得了它的位置？
14. 不要凭记忆复述这些事实，要对照代码核实（它们会变）：定价与 credits（src/shared/billing.ts、定价页）、免费计划限制（src/shared/audit-limits.ts）、MCP 能力（src/server/mcp/tools/，每个工具一个文件），以及任何 UI 提示文案让读者使用的功能（列、排序或筛选必须在客户端代码中存在）。
15. 派生子代理执行各轮审校（语气/deslop、声明准确性、直给程度），让它们返回精确的 old → new 修改建议，而不是直接编辑。
16. 不要盲目接受子代理的建议：应用前逐条对照实际文件核实，每条事实声明对照代码核实——子代理改写可能引入自己的别扭或错误，建议与文件不匹配说明它审的是旧文本。
17. 应用修改后自己再扫一遍改动的范围（模式会聚集——一个破折号或模糊措辞通常有邻居），然后对改动的 TS/TSX 运行 npm --prefix web run types:check 和 prettier。
18. 审校时自问：如果读者相信了每条声明和截图，然后立刻打开 OpenSEO，哪里会对不上？
19. 审校时自问：每个回答是否以真实答案开头，还是悄悄引向更讨喜的推断？
20. 审校时自问：把最尖锐的那句读出声——真人会那样说吗？
21. 审校时自问：有没有把实际要消耗 credits 的东西说成免费？
22. 审校时自问：这是在教读者真正有用的东西，还是滑向产品文档或凑字数？
23. 审校时自问：页面上每个链接、图片和示例是否都为读者赢得了它的位置？

适用边界 · 注意事项

• 不适用于非面向用户的内部代码或注释。
• 不适用于无法对照代码、事实表或线上产品验证的声明。
• 不适用于与 OpenSEO 产品无关的通用写作。