线上体验站的后台入口在哪里，试用时该核哪几项能力

官方体验站的后台入口在哪里？入口写在项目的说明文档里：体验站地址是 demo.anqicms.com，后台入口在其后加 /system，演示账号在 README 的演示区给出，本文不重复任何登录口令。试用时该核哪几项能力，目标应当限定为一件事：确认能力形态是否符合你的工作流。性能、资源占用和迁移成本都不适合在体验站上取结论。

体验站入口与后台路径

打开体验站域名后，在地址后接 /system 即进入后台。体验站通常已经预置好栏目、示例文档与模板，这对试用是好事：你不用从零建站就能直接看功能是否合手。

三条使用提醒。一是体验站是共享环境，不要在里面写业务数据、真实客户信息或未公开的产品资料。二是体验站的配置可能被重置，有价值的操作以「看懂流程」为目的，而不是把那儿当工作区。三是演示账号是***息，权限边界与真实生产环境的超管不同，看到某些入口不可写时不要当成缺陷。

第一组要核的：内容与结构

内容模型决定你的站点能承载哪些类型的信息。自定义内容模型支持灵活的内容结构，试用时重点看两件事：新建一个模型时能加哪些字段类型，以及这些字段能否在前台模板里取到。

栏目与标签的组织方式也在这一步一起看。建议按你自己的业务问三个问题：产品页与文章页能否用不同模型；同一篇内容能否出现在多个位置；改栏目结构时历史地址会不会变。答案在后台的具体位置不必记住，能不能做到要在这一轮确认。

第二组要核的：AI 对话与工具集

第二组看 AI Chat 与配套工具集。内置的智能对话配有覆盖内容、SEO、运维、商务等域的 AI 工具，可由智能体自主编排调用。试用时不要只问它「会不会写文章」，那属于模型能力，与后台无关。要看的是三件具体的事：

对话里能否直接完成一次后台操作，而不是只给建议；操作前是否要求你确认；一次对话里能否连续完成多步（例如先查列表再改状态）。这三点决定了它是「问答助手」还是「能干活的助手」。

配套的是 AI 技能系统，内置可扩展的技能覆盖内容规划、SEO 分析、批量操作、站点健康检查、故障排除、模板开发与 API 开发。试用时挑两个和你日常工作相关的技能跑一遍，看它给出的结果是可读的报告，还是需要你自己再加工的数据。技能能否按自己的流程扩展，也要在这一组里问清。

第三组要核的：接入与审批

如果你的团队会用外部客户端，这一组最关键。系统内置 MCP Server，工具面基于意图目录统一收敛，支持 Bearer 鉴权与回合级操作审批，写操作会合并确认，可被 Claude、Cursor 等外部客户端接入。

试用清单：

第四行容易被忽略但很重要：写操作的确认粒度决定了你敢不敢把这套接入交给非开发人员使用。

第四组：收录与模型可读相关模块

最后花几分钟看 SEO 与收录相关模块。站内支持站点地图自动生成、面向搜索引擎的链接推送，以及自动生成 llms.txt，让大语言模型更容易理解与索引站点内容。试用时的关注点是「这些是否需要人工维护」：如果栏目变更需要手工重新生成文件，长期运营成本会体现在这里。

试用别测什么

三类结论不要在体验站上取。

性能与资源占用。体验站的负载、缓存与你的生产环境不同，测出来的时间没有参考价值。要评估资源占用，回到官方口径：内存占用相比 PHP 类 CMS 降低约 80%，单机可承载约 500 万 PV，这类约数是设计目标而非你的实测值，真实数字要在自己的服务器上测。

数据迁移。共享环境不适合导入业务数据，迁移成本应该按自己的导出接口与备份能力评估。

稳定性。体验站重启或重置不代表线上服务行为。

常见问题

体验站能建多少个站点？ 数量限制属于环境配置，试用时把它当作「看功能形态」的场所；多站点管理是否满足需求，应结合自己的部署形态判断。

演示账号会被回收吗？ 公开演示环境通常定期清理，不要长期存放内容。

没有体验站权限怎么办？ 可以本地安装后按同一份清单走一遍，重点是操作路径而不是账号身份。

试用时该带自己的内容吗？ 建议带三到五篇真实文档的标题与结构去做内容模型验证，比用示例数据更容易看出字段是否够用。

看完试用怎么给结论？ 用「能不能做到」而不是「好不好用」下结论，把性能与安全相关的判断留到测试环境，报告里注明哪些结论来自体验站、哪些来自自测。