© Ohad Zwigenberg/Associated Press
今年不少出圈的 AI 视频，基本都有一个共同点：套了个熟悉的 IP 壳。
宫崎骏风格的短片、宝可梦版的日常场景、AI 重制的海贼王和龙珠——只要 IP 够经典，AI 生成的内容就能从「电子垃圾」秒变「同人创作」，评论区瞬间炸开。
Sora 2发布后，Sam Altman 还专门发推说，这些视频应该被理解成「互动式同人小说」。这话说得挺聪明，既规避了版权的坑，也点出了 AI 视频的真实处境。
AI 视频和 IP的结合，现在正卡在一个很微妙的位置：用户想玩，品牌怕乱。
这个矛盾不解决，AI+IP 就永远只能是小打小闹。
最近几个月，海螺 AI 和蜜雪冰城、青春有你 3 成员、以及一些原创 IP 的合作，给出了一些不一样的思路。
这些合作有一些共同的底层逻辑：授权是明确的，创作是可控的，用户玩得也确实开心。
AI 公司在这里不只是生成工具，它还在同时管授权、引导创作、连接用户和品牌。
用户也不再只是看 IP，而是能进到 IP 里面去玩。这件事如果做成了，IP 的价值可能会被重新定义。
如果要评一个最愿意把 IP 放到网上乱跑的品牌，蜜雪冰城大概永远不会掉队。前段时间在 B 站霸榜的雪王大战东方明珠，以及一连串雪王防御战、四大门派围攻东方明珠……都是网友随手一玩就能冲上热门的那种内容。
▲ 视频来自百变雪王大赛，创作者@小龙问路
对大多数品牌来说，蜜雪冰城算是最能读懂互联网的那一类。它很知道，雪王这个角色的生命力，不靠广告，不靠代言，靠的就是用户玩出来的那堆梗。而蜜雪冰城 × 海螺 AI 的「百变雪王杯」视频大赛，恰好踩中了这种互联网的创作方式。
海螺没有拍一条雪王广告给你看，而是用 AI 直接把雪王 IP 的「玩法」开放了。你想让雪王去旅游？行。想让它进剧情？也行。想把它变成下一个段子的主角？随便。
换句话说，雪王从一个被展示的角色，变成了一个可以被接着玩的入口。
▲ 活动目前在获奖公示阶段，但雪王相关的创作，相关模板可以继续使用
以前买一个雪王手办，我们得到的是所有权。它被放在桌上、玻璃柜里，价值是静止的。现在用海螺的 AI 模板做一个雪王短片，我们获得的变成了参与权。在很多年轻用户的消费账单里，这种能被自己动手改写的体验，往往比实物本身更上头。
而为了让这件事成立，海螺和蜜雪冰城之间的授权方式其实相当克制，给到的是形象图，允许在模版中生成并创作，但整个创作行为都保持在一个清晰、可控的框架里。
例如，在官方发布的联合 PV 里，海螺用自己的 Hailuo02 视频生成模型、首尾帧技术，让雪王形象在任何生成内容中都保持一致性，动作自然、表情真实。
▲ 正值全运会，让雪王来个 109B，向前翻腾四周半屈体，用户可以选择海螺最新的 Hailuo 2.3 视频生成模型；图为海螺 Media Agent 生成页面，支持无限画布
这让品牌放心开放，也让我们放心玩耍。
而海螺 AI 推出的雪王视频模板，本质上是一整套雪王创作工具包。用户每点一次、改一个姿势，都在创造属于自己的数字周边。它的价值，也从普通的视频「被观看」，变成了比买十个雪王手办更能让人上头的「被使用」。
▲ 在海螺 Q版童趣页面，可以直接体验百变雪王模板，体验链接：https://hailuoai.com/generate/ai-agent/436634640615985161
此外还有百变雪王杯创意大赛的线下门店宣传、PV 联合官宣、官方回顾展示……每个环节都在告诉用户，这份创作不是我们的自嗨，是同样值得被留下来的纪念。
在这种机制下，IP 不再躺在博物馆里等待被仰望，它像一盒乐高，等待被用户重新拼搭出新的可能性。
过去几年，品牌追求的是调性统一。AI 时代，现在要学会的是容忍一千种民间版本。用户玩出来的梗，有时候比官方物料更有生命力。
海螺在这里的角色，就是让这「一千种民间版本」保持在一个健康、合法、可持续的范围里。不侵权、不撞车、不乱、不让用户背锅。
在如今的 AIGC 环境里，这四件事都极其稀缺。
但让用户参与只是第一步。参与要真正变成创作力，需要一个关键动作：用户的作品能被官方看见、被认可、被用起来。
在 11 月初举行的「天天爱白日梦」限定演出，就是海螺 AI 在娱乐领域以及 AI + IP 合作上，一次更激进的实验。
来自综艺青春有你 3 天天组的五位成员，第一次对粉丝的 AI 视频现场 Reaction，全场都炸了。
▲ 来自综艺《青春有你3》的天天组，DayDay 兄弟团，陈俊宇、刘琦、时尚、魏宏宇、杨昊铭，在海螺天天爱白日梦活动现场
如果说雪王杯是让用户的作品进入了公共舞台，那么和艺人的合作，则把用户的 AI 创作第一次推向了商业级的线下场景。
以前的追星规则很简单，买票，看人，灯光越好，舞台越大，你离偶像越远。但现在的粉丝，渴望的是另一种关系，不只要看见偶像，更想被偶像看见。
这场合作就抓住了这一代粉丝，最细微也最强烈的心愿。粉丝在家用海螺做的 AI 视频，各种离谱剧情、集体跳「明月几时有」的整活、还有「骑牛」的玩梗，最后都被投上了演唱会的大屏，艺人抬头看到自己的二创，观众在下面尖叫。
更让人意外的是，他们还模仿了一遍粉丝视频里的动作和装扮，在台上真人复刻了一遍 AI。那种作品被继续、被回应的瞬间，普通工具给不了，也是传统演出永远给不了的回馈机制。
▲ 粉丝玩了好几年的刘琦「骑牛」梗，通过海螺 AI 生成了视频，投放到大屏，还被正主模仿
而 AI 也成了活动的主角，整个活动现场的视觉全部由 AI 生成，包括活动主视觉、开场视频、每首歌的现场大屏画面，都是通过海螺 AI 生成。艺人方授权形象、声音与 BGM，海螺做一套独家的视频模板。粉丝们则在海螺上，用这些元素创作短视频，就像是和偶像合拍了一支 MV。
就像活动现场那些让人笑出声的整活视频一样，海螺 AI 没打算做太多的限制。不设置所谓的「高级感」门槛，也不限制风格；在这个舞台上，用户的脑洞才是唯一的规则。
▲ 海螺 AI 上艺人全网独家 AI 模板，用户可使用艺人形象和声音，在活动期限内生成 AI 视频，目前活动已结束
这场合作里，AI 已经不是单纯工具的角色。粉丝做视频，艺人能看到；艺人有反应，粉丝能感受到。这条线，以前是断的，现在接上了。
品牌、AI、艺人、粉丝，构成了一个四边形的情感闭环。追星不再是单向的，也不再是遥远的。
当技术超出工具的范畴，开始重塑人和人之间的关系时，粉丝经济的玩法，可能真的要变一变了。
当用户的表达能力、参与能力被系统性打开之后，下一件自然发生的事情就是：有人开始原创。
这类创作者，我们在各个平台都能看到一点影子，他们不满足于做梗图、玩段子，更想把故事讲完整。
而海螺的作用，也从提供参与工具，变成了提供原创孵化的土壤。听上去有点夸张，但这些事确实已经发生了，国风系列短片、短剧《白咒》，就是最典型的两个例子。
▲ 海螺近期的人生电影活动，鼓励用户用 AI 创作自己的电影大片
先说国风系列，国风某种程度上，本身就是一个热门 IP，但能合适的用好国风这个概念并不容易。海螺 AI 视频在这系列有《花木兰》、《聊斋志异：燕赤霞》、以及《聊斋燕赤霞Ⅱ：猫将军》多部短片作品。
其中花木兰，获得北京电影学院动画学院奖评委会特别奖、聊斋燕赤霞也拿到了腾讯视频首届「AI 短片创作大赛」二等奖。
这套作品摆脱了传统的玩梗二创，努力在影像表达上做到一些真正的新原创设计。创作者在海螺 AI 的能力基础上，把构图、灯光、叙述节奏、镜头语言都重新组织了一遍，做出了具有统一审美、统一叙事风格的成片。
▲获奖作品《花木兰》，由海螺 AI 生成，来自光影几何（海螺超创@猫大人爱睡大觉），视频链接
再看短剧《白咒》，这部短片是今年上半年 4 月份发布的，使用的模型还是 Hailuo 1.0 系列，但仍然在社交媒体上引起了大量讨论。AI 视频早期常见的问题，在这个六集短片《白咒》里都有，但创作者的表达欲和风格探索，却在这些限制中显得更突出。
对于这类创作者来说，工具并不是全部。他们需要从能生成，到能发布，能进入更大舞台。海螺在这条链路上，做的是把创作者遇到的阻力降低，从生成工具，到赛事合作，再到寻找商业落地机会。
▲海螺 AI 短剧《白咒》已经在优酷上线
十月份最新发布的 Hailuo 2.3，在肢体动作、风格化、微表情等部分已有明显提升。大模型竞技场文生视频榜单，以及 artificial analysis 的统计，MiniMax 的 Hailuo 02 和 Hailuo 2.3 都保持在国产 Top 3 的行列。
首尾帧、智能分镜、角色一致性……这些原本属于电影工业的能力，现在落在个人创作者手里。当专业创作的门槛被技术拉平，个人作品和商业内容之间的界线，也开始变得模糊。
在这些 IP 合作案例里，海螺不只是帮用户表达一个想法，更像是在帮他们把想法变成作品，把作品变成可以被看见、被记住的东西。
一个创作者，在这里能经历的，是从参与→共创→被认可→原创孵化→作品产品化，这条在 AI 时代才可能走通的路径。
以前 IP 是被品牌方创造出来的，现在可能是被用户玩出来的。海螺在做的，就是把这条路铺得更平一点。
过去十年的内容生态像一座剧场。创作者在台上，观众坐在台下，彼此的距离由生产和消费的分工维持。几乎所有商业模型、平台规则、作品标准，都建立在这条界线上。
但 AI 正在悄悄拆掉这堵墙。
从雪王，到明星演出，再到原创孵化，海螺AI的这些合作案例证明了一件越来越清晰的事：AI 带来的最大机会，不只在于效率，而在于把消费者关系重写一遍。
年轻人要的，不是拥有某样东西，而是进入某件事里。
品牌向用户敞开参与的大门，用户的创造力就能变成品牌资产的一部分。创作者被技术托住，他们的作品就能变成新一代的文化原点。IP 与 AI 的合作不再是冒险，而是在共同完成一场更大的叙事。
这条路能不能走通，现在下结论还早，但至少有像海螺 AI 这些产品开始在试了。
当「参与」本身开始变得比「拥有」更值钱时，整个内容产业的游戏规则，可能真的要变了。
#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。
© Saher Alghorra for The New York Times
© Siphiwe Sibeko/Reuters
© Dave Sanders for The New York Times
Loose words confuse, and one of the words used most loosely in macOS is permissions. This explainer tries to separate them from other access controls.
The access permissions of files and folders are set in their attributes in the file system, stay with that item, and are applied universally for all apps and processes that try to access them.
The simplest and most basic of access controls, these can be inspected and changed in the Finder’s Get Info dialog for all accessible files and folders. They control the ability of apps and other code to read from and write to each file and folder. Normally, if you’re the named owner of a file or folder, you expect to have both read and write access, and that ensures the apps you run with user privileges can open, edit and save changed files.
Permissions are relatively crude controls, so Access Control Lists (ACLs) can refine those permissions with more specific restrictions. They were introduced in Mac OS X 10.4 Tiger in 2005, and are now applied as standard to some widely used folders including the Home folder. The presence of ACLs is normally indicated in the Get Info dialog by the words You have custom access.
No matter what security controls and privacy protection might give you access to, they can’t override the fundamental limits imposed by permissions, and can only limit access further.
The macOS security system imposes its own controls according to its rules. Most obvious among those are System Integrity Protection (SIP) and sandboxing.
SIP was introduced in 2015 with El Capitan, and primarily puts system folders, files and some components, including certain extended attributes, beyond the reach of even the root user. The only way to get past SIP is to disable it, a serious undertaking as it has more general effects on security.
Sandboxing is security protection that limits the files individual apps can access by imposing a sandbox as set by their entitlements. It’s therefore determined by the app trying to access files, and doesn’t apply to apps that don’t run in the sandbox. As an app’s entitlements are baked into its signature, there’s nothing a user can do to alter them.
macOS designates certain locations and resources as being private, and protects them using its Transparency, Consent and Control (TCC) system. Although it has a longer history, this was first implemented in its current form in macOS 10.14 Mojave in 2018, and since then has grown with every new major version of macOS. Privacy protection operates outside of file attributes, using a rule-based system applied to each app, and applies to command tools and other processes as well.
Among the folders this protects are the Desktop, Documents, Downloads, and those on removable storage. While access to individual folders is controlled, if you do encounter problems it’s usually simplest to add that app to the list of those with Full Disk Access, in Privacy & Security settings, in the first instance. That can leave a lot of apps with unnecessary access to private data, so you should periodically check through the list of apps with Full Disk Access to ensure they all still require it. Remember that Full Disk Access can’t override restrictions imposed by permissions or ACLs.
In Tahoe, privacy-protected folders include:
Unlike permissions and security controls, there’s no command line interface to these controls, which can only be accessed by the user in Privacy & Security settings. As a result, TCC uses an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied. For example, when you run commands in Terminal, the privacy settings used by TCC are those of the Terminal app, while helper apps are normally the responsibility of their parent app.
Privacy protection is built around the user’s consent and intent. When a process tries to save a file to a protected folder that it doesn’t already have access to, you should be prompted to give your consent before TCC allows that. Alternatively, when an app tries that, it should display the File Save dialog, where you can express your intent to save the file to that folder. Without consent or intent, TCC should block that file from being saved there unless that app has been given Full Disk Access in Privacy & Security settings.
Privacy protection is the most complex and opaque of these, and can present the toughest problems to solve.
Some who use SilentKnight for the first time discover that their Mac has been running for months with one of its security systems disabled. As macOS doesn’t have a dashboard to warn you of such dangerous settings, you may not notice until it’s too late. This article explains how to check those essential security settings on Macs with T2 or Apple silicon chips, and how to put them right. Intel Macs without T2 chips are different, and are covered in a previous version.
Running your Mac in Full Security ensures it gets full protection from its Secure Boot technology. In an Apple silicon Mac this prevents it from loading third-party kernel extensions, and requires recent approved versions of macOS. Check this in System Information by selecting the Controller item in its Hardware section, or in SilentKnight.
This is controlled in Startup Security Utility, accessed from Recovery. Note that it only works with the paired Recovery system, the one you normally use; Apple silicon fallback Recovery doesn’t have this ability.
If you need to run kernel extensions or other software that can’t be loaded in Full Security, use Startup Security Utility to set the Mac to Reduced Security, and enable kexts. Avoid doing this if at all possible.
Settings are different for Intel Macs with T2 chips, where there are three levels of boot security, and the most common reason for reduction from Full Security is to enable that Mac to boot from external drives, something that Apple silicon Macs can do in Full Security.
Since El Capitan, macOS has protected all its system files, even down to bundled apps, using System Integrity Protection. This should make it impossible for malware or other software to change those protected files. SIP is also required for a wide range of other security protection, and should be fully enabled unless you have a compelling reason for disabling it partially or completely. In Apple silicon Macs, its status is reported in System Information’s Controller item, but Intel Macs instead give it in the Software section. It’s also checked by SilentKnight and Skint.
You can turn SIP off, something very occasionally needed to perform certain essential tasks. Doing so requires you to start up in Recovery mode, enter a command in Terminal there, and restart; Apple silicon Macs also need to have their boot security reduced in Startup Security Utility before SIP can be disabled.
To enable SIP, start up in Recovery mode, open Terminal, and type the following command:csrutil enable; reboot
Once that’s done your Mac will restart in normal mode, and you should confirm that SIP is reported as enabled.
If you ever do need to disable SIP, do yourself a favour and put a sticky note on your Mac’s display to remind you to turn it back on.
Gatekeeper runs checks on apps when they’re opened, and those can include scans for known malicious software using XProtect. As part of your Mac’s frontline protection against malware, you should leave those enabled unless there’s a compelling reason to temporarily disable them. However, I don’t know of anywhere in the macOS GUI that informs you whether these checks are being performed, although they are reported by SilentKnight and Skint.
If it has been disabled, you may be able to enable it using the commandspctl --enable
but chances are that you will instead need to invokesudo spctl --global-enable
requiring you to authenticate using your admin password. Be careful with those commands: the hyphens before enable and global-enable aren’t long dashes, but two separate hyphens.
When you install Big Sur or later, the vast majority of its system files are saved in its System volume. For your Mac to boot from this, it has to be turned into a snapshot, sealed using a tree of cryptographic hashes, and the master seal ‘signed’ by a hash, which is compared against that set by Apple. This signed system volume is extremely secure and thoroughly reliable. On Intel Macs, this is only reported in Disk Utility, but Apple silicon Macs list it in System Information as well. It’s also reported by SilentKnight and Skint.
The SSV should always be enabled. If it isn’t, you’ll need to re-install macOS.
Intel Macs with T2 chips and Apple silicon Macs encrypt the whole of the Data volume on their internal SSD. By default, that uses an internally-generated key that’s used automatically when any user logs in. Although it provides good security in most situations, you’re far better off enabling FileVault, as that protects the encryption key with your password as well. This imposes no overhead on accessing encrypted data, and provides valuable protection for your data at no cost.
Check whether FileVault is enabled in Privacy & Security settings, where you can enable it if it’s not already turned on. SilentKnight checks it as well.
To ensure your Mac and its apps are best protected from malware, keep its firmware and macOS up to date. As those are updated together, Macs with T2 or Apple silicon chips that are running the most recent release of their major version of macOS will also be running the current firmware, which no longer needs to be checked separately. Check the version of macOS in the About This Mac command at the top of the Apple menu.
Apple lists current supported versions of macOS on its Security Releases page. Those, and versions of security data software, are also listed and detailed here on this page.
If your Mac is running an older release of macOS and its firmware, update them together using Software Update in General settings.
This anti-malware scanner performs automatic background scans to detect and remove a wide range of malicious software. It’s normally scheduled to run at least once a day, when your Mac is awake but not busy, and supplied with mains power. You’re wise to check that its scans are being run correctly, and will probably want to know if it has detected and remediated any malware. SilentKnight and Skint run a quick check of its activity over the previous 36 hours, and XProCheck provides detailed reporting and analysis.
Over the last year or so, XProtect Remediator has been using a timer during its scans, and automatically cancelling them if a scan takes longer than allowed. On many Macs, most scans are terminated early, and that results in warnings from SilentKnight and Skint. If you’re concerned, check the reports in XProCheck, where you’ll see that plugin was cancelled with a status_code of 30, as is typical with the timer.
SilentKnight does all of those and more.
Each of the main security services in macOS such as XProtect relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.
Currently, those most frequently updated are XProtect and XProtect Remediator, the former being updated most weeks. However, Sequoia changed the way that XProtect’s data is updated, and it’s now intended to occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.
This article details each of the main security data files found in macOS 26 Tahoe, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, left frozen in time, or removed completely. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.
XProtectPayloads, alias XProtect.app and XProtect Remediator
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app in the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every month or so using Software Update or a substitute.
XProtectPlistConfigData
These are whitelists and blacklists used by XProtect. Since Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle in the Data volume; the secondary is also in the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and can used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Tahoe is also intended to update the primary bundle via a CloudKit connection to iCloud. This is routinely updated every week, at the same time as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, if a more recent version is available.
Bastion
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. This doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb, and reports them to Apple as security intelligence. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated irregularly.
AppleKextExcludeList
Latest version: 21.0.0, 9 September 2025 (26.0 release).
This is a huge list of kernel extensions that are to be treated as exceptions to Tahoe’s security rules, and is stored in the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist. At one time, this was a blacklist of kexts to block, but in Mojave 10.14.5 that changed, and it has since been a list of over 18,000 kexts that are given exceptional treatment, as explained here. However, this doesn’t appear to apply to Apple silicon Macs, as they have their own separate rules about which kexts to allow and which to block, that are far more stringent. Accordingly, this list should go away in macOS 27.
IncompatibleAppsList
Latest version: 260.200 (26.0 release).
This is a bundle in the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.
MRTConfigData
Last version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored in the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but is installed later as a security data update.
Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database in the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db and may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database isn’t currently used.
Gatekeeper E Configuration Data (GKE), alias Gatekeeper Compatibility Data
Latest version: 1.0 dated 2 October 2019.
This was an SQLite database in the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since. Although this is still downloaded and installed, it’s nowhere to be found in Tahoe, and appears to be a historical remnant.
Last updated: 19 September 2025.
Login
