功能预览
用 AI 辅助改模板,改动要落回站点模板文件并即时验证才会生效。站内路径分四种提需求来源:可视化模板编辑、技能、AI Chat、外部客户端经 MCP 接入。共同步骤是描述需求、生成或修改代码、核对落盘、再验证首页与列表页;技能层覆盖模板开发与 API 开发两类任务。
在后台用 AI 辅助修改模板,改完不会自动等于线上生效——中间固定有几步:把需求描述清楚、让 AI 生成或修改模板代码、核对改动确实落到了站点模板文件、再回到页面验证。按这条线走一遍,首页和列表页看到的变化才算真正改了。差别只在「谁在提需求」:站内可视化编辑、技能、AI Chat,或经 MCP 从外部客户端接入,四条路径最终都要落回同一套「存盘 + 验证」。
第一种是人在后台的 AI 可视化模板编辑里直接改,AI 辅助生成或调整模板代码,人当场看结果;第二种是技能,把一类任务(比如给某栏目套一个新排版)交给封装好的能力去做;第三种是外部 AI 客户端通过 MCP 接入,在对话里提出改动。三者入口不同,但改动都必须写回模板文件、都必须走页面验证这一步,不能凭「AI 说改好了」就认为生效。
可视化模板编辑解决的是「不脱离后台就能改排版」。用法是四步:一、选中要改的模板,把想要的效果用一句话描述(哪个区域、变成什么);二、让 AI 生成修改,逐处核对它改的是不是你指的那段;三、保存,让改动落到站点模板文件;四、打开受影响的页面确认渲染。AI 编辑模板时最容易出的偏差是「改对了效果、带坏了别处」,所以第三步的落盘核对和第四步的真实页面验证都不能省。
站内的技能系统覆盖多类任务,模板开发是其中一档,能按既定套路批量或结构性地改模板;另一档 API 开发则面向接口侧。技能的价值在于把「反复要做的一类改动」固化成可调用的能力,但它的边界要清楚:技能能生成和修改模板代码,改完仍需回到落盘与页面验证,不会替你确认线上表现。把技能当成「会写模板的执行者」,而不是「保证上线的裁判」。
改动落盘后,验证要挑覆盖面而非挑顺眼:先看首页(多数模板改动会牵连它)、再看列表页与详情页各一条(确认结构没被改坏)、然后看一个用了被你改到的公共片段的页面。带缓存的环境还要确认验证读到的是新内容而不是旧缓存——如果页面看着没变,先排缓存再怀疑改动没落盘。
经 MCP 接入外部 AI 客户端时,改动路径多了一层:工具面按意图目录收敛,写操作在一个回合里合并确认。也就是说,外部客户端提出的模板改动,不会每处各弹一次确认,而是把这一回合内的写入合并成一次审批,确认后才落盘。这和站内可视化编辑「即时保存、即时看」的手感不同,但落盘与验证这两步仍然一样,接入方式不改变生效条件。
问:AI 说改完了,能直接算生效吗? 答:不能。必须核对改动落到了模板文件,并在首页、列表页、详情页各验一次,看到新渲染才算生效。
问:技能和可视化编辑该用哪个? 答:单点、当场想看效果用可视化编辑;一类要重复套用的模板任务用技能,两者都要走同样的落盘与验证。
问:MCP 接入是不是更容易改坏? 答:它反而多一道回合级合并确认;真正防改坏靠的还是验证那几步,和入口无关。
预览
备份、升级这类全站级操作接口默认不对外开放,收的是「一旦被调用就影响整站」的风险面。默认关闭的不是某个功能,而是全站级动作这一档,需要显式开启。站内工具面按意图目录收敛,写操作在一个回合里合并确认,高危域默认关闭、按需开启,把可调用面压到最小。
预览
落地页该用单页面还是自定义内容模型,看三处边界:会不会反复生成同类页、要不要按字段筛选、需不需要挂进导航或多站复用。一次性活动页用单页面管理即可;要批量产出、按结构化字段组织的方案页和列表页,交给自定义内容模型和它的自定义字段,两类承载各管一段。
预览
草稿或待发布内容带预览参数的链接会不会被爬虫抓到,取决于三件事:地址能不能被猜到、抓取规则有没有覆盖它、服务端读详情时是否校验状态。抓取排除规则只是建议,挡不住已经被分享出去的地址;真正的收口要落在状态校验与预览参数只在授权会话里生效这两条上,改完再用搜索引擎站点信息核对有没有漏页。