如果你想用 AI 做个网站，又不知道做什么，可以先找一个自己愿意持续了解的题目，看看别人会遇到哪些具体问题。
以WARDOGS Field Guide为例。这是一个独立的游戏攻略资料站，除了整理了基础的配置要求、平台信息，最重要的是玩家遇到的问题如何解决？例如进不去服务器怎么办、装备怎么解锁、补给怎么运送等内容。
这类网站的思路很好理解。有人遇到问题，去搜索，找到一篇能帮他解决问题的文章。网站要做的，就是把这篇文章准备好。
但真要动手，第一步该让 AI 写什么？
先别急着让它生成一整站。选一个问题，把它讲清楚，会更容易判断自己做出来的东西有没有用。
比如，一个玩家已经买了游戏，却进不去服务器。他这时大概没兴趣再读一遍游戏介绍。他需要知道有没有维护公告，自己的报错是什么意思，接下来先检查哪一项。
这就可以做成一篇单独的页面。标题说清解决什么问题，开头先给检查入口，后面再解释不同情况。写完以后，自己沿着页面走一遍，看看读者会不会读到一半，又得去别处搜索才能继续。
相比“做一个内容丰富的游戏网站”，这样的要求更具体，交给 AI 也更容易检查。
不过，页面写得顺，不代表里面的判断就可靠。
WARDOGS 站上有一条服务器维护说明。公告写了预计维护时间，但时间过去以后，能不能直接告诉读者“服务器已经恢复”？
还不能。预计结束时间已经过去，和服务器现在能正常进入，是两件事。
如果读者正卡在登录界面，一句未经确认的“已经恢复”，可能会让他以为问题出在自己电脑上，接着折腾网络或重装游戏。
所以，这个页面保留了维护安排，也说明那段时间已经过去，但当前是否可用仍需查看最新消息。做这种资料整理，日期和适用条件就得跟着答案一起留下来。
有些题目也不必急着写完。
项目里曾准备过一份“最佳画面设置”的内部草稿。这样的文章很容易排得像模像样，列出阴影、纹理、分辨率，再给每项填一个推荐值就行。
可玩家真正想知道的是，照着调整以后能快多少，画面会损失多少，自己的电脑能不能参考。
要回答这些问题，就需要游戏版本、硬件配置和实际测试。那份草稿把这些项目留了下来，没有拿封测期间零散的玩家反馈补成测试结果。
如果你也准备做游戏Wiki站，碰到这种情况，可以先换一个手头资料足够的问题。没有必要为了凑齐栏目，把每个页面都填满。
等第一篇完成，再决定要不要做第二篇。你会更清楚自己是否找得到资料，能不能解释明白，以及愿不愿意在信息变化后回来修改。
后面这件事也得算进工作量。游戏更新了，旧方法可能失效；测试结束了，原来的报名入口就得检查。网站发出去以后，读者还会继续看到那些旧页面。
你可以先拿自己熟悉的题目试一次。找出一个你曾经搜了好几处才弄明白的问题，把答案、出处和操作步骤整理到一起，再请一个不了解这件事的人读一遍。
他在哪里停下来问“然后呢”，那里就是下一处该改的地方。
感谢阅读，我们下一篇见。