两种想法一直都在
在一个网站项目里，面对自建内容后台的选择，我先冒出来的念头是：明明有WordPress这种现成的东西，为什么还要自己搭？紧跟着是一串问题：眼前要多出多少活？以后加功能、修bug会不会很麻烦？已经做好的网站会不会被牵连？
我其实不觉得自建是坏主意。我当时想，成品要照顾各种各样的使用场景，兼容考虑得多，学起来、用起来都有它自己的一套门道。自己做可以照着需求来，用不上的功能干脆不做，路更直。现在又有AI帮忙，起步也快些。可落到这次的事情上，我反倒更想用成品，原因是时间。周期短，一个系统哪怕用AI写，也不可能一点问题没有，总得调一阵。而调试恰恰是最难估的那部分，我怕它把工期吃掉。自建更直接，这次又更想用现成的，这两个想法我是同时揣着的，到现在也没有哪个把另一个完全压下去。
支持自建的理由我也听进去了：反正用成品要调，自建也要调，那不如调出一套合自己习惯的，还更自由。这话有道理，我的看法松动了一点，也只是一点。
都要调试，调的是什么
现在整理的时候，我更想把当时没说清的地方补上：两边都要调试，具体是在调什么？用成品，我想先弄清哪些现成机制能直接复用，哪些地方还要适配；选择自建，则要看我们多写了哪些规则，之后由谁理解和维护。这些工作不一定一样多，时间也不一定一样好估。我没有把两套系统各搭一遍测过，没法断定谁更省时间，但听到"都要调"以后，我仍然想把这些差别问清楚。
下面用同一篇通用示例文章，看看两种编辑界面各把工作放在哪里。
"贴合需求"到底意味着什么，我当时也只有个大概。后来对照WordPress官方文档，才有了点具体的认识。比如希望某类内容多填一栏，或者定一条发布时必须遵守的规则。在WordPress里，发文章、存草稿、传图片这些已经有现成做法，普通的更新直接用文章就够了。真要加专门的字段和规则，它也能扩展出自己的内容类型，只是得另外配置、装插件或写代码。自建则可以从一开始就按这个样子做。
两边都走得通，差别在于这条规则写在谁的代码里、以后由谁来改。现成的机制能复用，但仍要花功夫适配；定制的东西贴合，但哪天想调整规则，就得有人读懂当初为什么这么写，改完再核一遍。我放不下的，就是这个"有人"。
我放不下的那个“有人”
这也让我把"起步快"和"能一直维护下去"分开来看。前者是眼下的事，AI确实帮了大忙。后者是之后很长一段时间、甚至换了人以后的事：加功能、修bug、升级，靠的是有人看得懂、接得住。WordPress那边也不是装上就完事，官方建议常更新、更新前先备份，插件也要留意兼容，成品同样有它的维护活。
所以我在意的不是哪边能一劳永逸，而是更具体的几件事。换一个没参与过的人，能不能照着说明把它跑起来？哪天发布出了错，他知不知道从哪里查起？这些我还没去确认，答案也许是好的，但在我这儿，它还是个没落地的问题。
先把自己负责的这块做好
轮到我负责的网站要从新后台拿内容时，我提的要求很简单：保留已经做好的页面和展示部分，接入新的内容来源时，要核对原有页面还能不能正常显示。具体的配置和核对是AI协助做的，我更多是在说清楚哪些东西不能动。查资料时我也看到，WordPress同样可以通过接口把内容交给单独的前端。换后台本来就不等于前端要推倒重来，要看的是怎么接、图片和格式怎么处理。我那时想的，就是先把已经做好的东西护住，别让后台的变化顺手把它带走。
最后我没有去接后台，继续做手上的网站。工期和工作量摆在那里，我想先把自己负责的这块做好。后台已有其他人负责，我就不再接这部分。不接，不代表维护和交接的顾虑就没有了，我没把它当成解决了。我把时间留给了自己正在负责的页面。
这一轮让我长了见识，也多了点底气。后来我主动提出一个想法：再做一个网站，加上一套管理内容的功能。目前还在梳理需求、看同类网站、准备方案，没有开始开发。讨论里功能越列越多，我问了一句：这么多东西，有必要在第一版就上吗？是不是跑偏了？所以现在先把调研和需求弄清楚，再决定第一版放什么。
资料说明：文中关于WordPress的部分参考官方公开文档：REST API Handbook、Registering Custom Post Types、Updating WordPress、Manage Plugins。
配图中的 WordPress 界面截自官方 Gutenberg 编辑器演示，使用与自建界面相同的通用示例正文。