我最近买了一个Macmini M6芯片的，买来就提示升级Macos 27系统，我想弄清一个很实际的问题：Mac mini 已经运行 macOS 27，能不能直接调用系统里内置的 AI 模型，为自己开发工作和AI工具提供能力？可以，苹果已经提供正式入口。macOS 27 自带fm命令，开发者还可以使用 Foundation Models 框架和苹果的 Python SDK。本机的fm手册甚至列出了serve，可以启动 Chat Completions API 服务。但“系统支持”“模型可用”和“生成效果够好”，是三个需要分别确认的问题。这次检查也正好碰到了第一道实际门槛。我的 Mac 上，已经能找到什么？2026 年 10 月 19 日，我对这台 Mac mini 做了只读检查：系统报告为 macOS 27.0.1，终端能找到/usr/bin/fm，本机还有对应的fm(1)手册。最初执行fm --help时，程序提示尚未同意 CLI 条款。随后，我在终端运行sudo fm license，阅读条款并输入yes，完成了这一步。注意下面截图末行的You have agreed to these terms.。这是许可接受成功的真实终端记录，图片保留了完整终端记录；许可确认与模型能否生成内容，仍需分别检查。再次执行：fm license--statusfm available本机分别报告条款已接受，以及：Agreed to license FM1 version 1.0 on Oct 19, 2026 at 12:51 AM. System model available之后的实测使用设备端system模型，完成了中文文本生成、token 计数、结构化输出和本地 HTTP API 请求。测试没有安装 Python SDK，也没有调用 PCC 云端模型。系统里的 AI，不只有一条运行路径Foundation Models 是苹果提供的模型访问接口。默认的SystemLanguageModel对应设备端模型，适合把推理能力嵌入自己的程序。它不要求我们先下载一份开放权重，再自己维护推理引擎。但 Apple Intelligence 的产品功能还会涉及云端能力。macOS 27 的框架增加了 Private Cloud Compute，也就是苹果的私有云计算模型。框架还能接入其他模型提供方。看下图：蓝色通路停留在 Mac 的边界内；橙色通路跨过设备边界。两条路径可能使用相近的开发接口，但数据去向和运行条件不同。对本地工具而言，需要明确选择设备端模型。使用 Python 时，创建SystemLanguageModel()，再把它传入会话，比依赖隐含配置更容易检查。设备端推理可以离线运行，但首次准备模型资产可能需要联网。工具若自行调用网络搜索或远程服务，整个工作流也就不再完全离线。苹果在 WWDC26 演示中展示过--model pcc。不过，我这台机器的本地手册只列出system模型。因此，不应把大会演示里的每一个选项，都当作当前机器上已确认可用的命令。最快的入口：先用 fm 验证一个小任务先运行fm --help，可以看到当前版本真正提供的命令。下面原图左侧列出了available、chat、count-tokens、license、respond、schema和serve；MODELS区域则把system标为默认设备端模型。如果只是想先和模型对话，可以直接进入交互界面：fm chat下面是一次实际对话的完整截图。顶部显示model: system，我输入hello, who are you?，模型回答自己是苹果开发的基础模型，并列出内容生成、摘要、提取和分类等用途。模型的自我介绍只是这次对话的输出；确认正在使用哪个模型，应看界面的模型标识与程序配置。注意截图底部的165 / 8,192 (2% used)：这个会话界面显示上下文容量为 8,192 token，当前占用为 165 token。旁边还显示本轮输入 106、输出 59。这给出了本机交互会话的实际观察值，不能把它推广为所有 Mac 的固定规格，也不能把 8,192 理解为可输入的汉字数。chat适合手动试提示词；要让脚本拿到一次调用的结果，可以使用respond。下面原图展示了fm respond --help的完整选项，底部还保留了一次fm respond 'What is Macmini?'的实际调用与英文回答。对接创作工具时，可以先关注四项：--instructions设置任务要求，--schema指定结构化输出，--no-stream等待完整结果，--save-transcript保存会话记录。截图中出现--image和--tool，只说明当前 CLI 提供这些入口；本文的简单实测没有覆盖图片理解、OCR 或条码工具。三张截图均按原图保留，帮助页文字较密，手机阅读时可放大查看；关键命令在正文中另有可复制版本。完成许可和系统设置后，先检查可用性：fm available再尝试一个范围很小的中文任务：fm respond--modelsystem\'请把下面的笔记改写成一句清楚的中文：本地模型负责摘要，程序负责保存文件。'上面这条改写命令在本机成功执行，实际返回：本地模型负责摘要，程序负责保存文件。这次模型保留了原句。它证明中文输入与输出链路已经打通，却不能证明模型在复杂改写中一定能带来提升。我还运行了：fm count-tokens'本地模型负责摘要，程序负责保存文件。'本机返回11。这只是该字符串的计数，不代表完整会话只占 11 个 token；会话还包含指令和其他内容。测试中有一个容易误判的细节：在自动化工具的受限沙箱里，文本生成和计数都报过ModelManagerServices.ModelManagerError error 1008；获得授权后，在沙箱外重跑则成功。因此，遇到该错误时，可以检查运行环境对系统模型服务的访问限制，不应仅凭错误编号就断言模型没有下载或地区不支持。本次对照也不足以解释所有1008错误。本机手册还列出chat、count-tokens和schema。分别可以用于交互对话、计算 token 数量、生成结构化输出的 schema。如果需要把文章内容交给模型，不要只在提示词里写一个文件名。除非程序明确读取了文件，模型并不会自动看到文件内容。一个较短文本的调用示例如下：frompathlibimportPathimportsubprocess text=Path("notes.txt").read_text(encoding="utf-8")result=subprocess.run(["/usr/bin/fm","respond","--model","system","--no-stream","请概括以下材料，不补充外部事实：\n"+text],capture_output=True,text=True,timeout=120,check=True,)print(result.stdout)这里由 Python 读取文件，再把内容交给模型。示例适合短笔记；长文需要分段，也要处理超时、模型不可用和生成失败。它没有使用 shell 拼接命令，正文中的特殊字符不会被当成 shell 指令执行。开发 Python 工具，可以直接用官方 SDK苹果维护了apple-fm-sdk，导入名称为apple_fm_sdk。官方仓库列出的基本要求包括 macOS 26.0 及以上、Python 3.10 及以上、Xcode 26.0 及以上，以及在兼容 Mac 上启用 Apple Intelligence。具体的新能力仍要看系统与 SDK 版本。建议在工具自己的虚拟环境里安装：python3-mvenv .venvsource.venv/bin/activate python-mpipinstallapple-fm-sdk一个直接检查模型、读取笔记并生成摘要的示例：importasynciofrompathlibimportPathimportapple_fm_sdkasfmasyncdefmain():model=fm.SystemLanguageModel()available,reason=model.is_available()ifnotavailable:print(f"Model unavailable:{reason}")returnsession=fm.LanguageModelSession(model=model,instructions="用简体中文回答。只依据输入材料，不补充事实。",)notes=Path("notes.txt").read_text(encoding="utf-8")response=awaitsession.respond("请提炼三个要点：\n"+notes)print(response)asyncio.run(main())这个例子按官方接口编写，本次没有安装 SDK 或执行推理。正式集成还需要捕获生成错误，并给出可读的失败原因。SDK 更值得关注的能力是结构化生成。通过@fm.generable描述输出类型，再把类型传给respond(..., generating=...)，可以让结果符合程序需要的字段。为了先验证这个思路，我没有安装 SDK，而是直接用 CLI 生成一个镜头脚本的 schema：fm schema object--nameScene\--stringnarration\--stringvisual\--stringscreen_text>scene-schema.json fm respond--modelsystem --no-stream\--schemascene-schema.json\'把这句话变成一个镜头脚本：本地模型在 Mac 上处理笔记，不需要把笔记发到云端。用简体中文填写字段。'本机生成结果如下，仅调整了缩进和字段展示顺序，字段值保留原样：{"narration":"本地模型在Mac上处理笔记，不需要把笔记发到云端。","visual":"展示本地处理笔记的场景，例如在Mac电脑上编辑文档，没有网络连接的图标。","screen_text":"本地处理笔记，无需上传云端"}三个字段都返回了字符串，程序可以继续读取；不过，画面描述仍很笼统，还需要细化成可执行的视觉方案。“没有网络连接的图标”也只是模型提出的画面建议，不是它检测到的机器网络状态。还有一个实际踩到的问题：手写的普通 JSON Schema 被当前 CLI 拒绝，报出Invalid schema。改用fm schema object生成的文件后成功。因此，入门教程最好直接使用工具生成的 schema；不要默认任何 JSON Schema 写法都能兼容。字段稳定后，程序才方便连接后续步骤。但结构符合要求，不代表旁白事实正确，也不代表场景时长合理，这些仍要验证。已有 API 客户端，能不能直接连接？本机fm(1)手册明确写到：fm serve可以启动 Chat Completions API 服务，并提供--host、--port和 Unix socket 选项。这为已有 HTTP 客户端提供了值得验证的接入路径。例如，可以按手册启动一个仅监听本机的服务：fm serve--host127.0.0.1--port8765这次我实际启动了服务，监听地址为127.0.0.1:8765。先查询模型列表：curl-sShttp://127.0.0.1:8765/v1/models返回列表包含模型 IDsystem。随后发送一个非流式请求：curl--max-time60-sS\http://127.0.0.1:8765/v1/chat/completions\-H'Content-Type: application/json'\-d'{"model":"system","messages":[{"role":"user","content":"请用一句中文解释本地推理。"}],"stream":false}'实际返回的choices[0].message.content是：本地推理是指在设备本地进行计算，而不是将数据发送到云端进行处理。这次响应中的usage报告：输入 63 token，输出 29 token，总计 92 token。这些是该次请求返回的用量记录，不是模型速度或质量的基准测试。服务日志显示两个 HTTP 请求均返回200，测试结束后已停止服务。因此，目前可以确认：已有 HTTP 客户端能够通过本机/v1/chat/completions发起简单的非流式文本请求。客户端若需要填写基础地址，对应的是http://127.0.0.1:8765/v1，模型名称为system；具体仍要看客户端如何拼接路径。这不等于所有客户端都已兼容。流式输出、图片消息格式、工具调用和其他可选参数，本次没有逐项测试。对一个新的 Python 项目，官方 SDK 更方便表达模型可用性检查；对已经有 HTTP 模型接口的工具，本地服务已经有了一个可复现的最小接入例子。写文章，先把它放进材料处理环节我会优先让设备端模型处理已经收集好的材料：提取要点、归类笔记、压缩段落、给出标题候选，以及检查术语是否前后一致。这些任务范围清楚，也便于逐条对照原文。对于“研究一个新技术，再写出事实准确的长文”，单独调用设备端模型并不足够。检索、来源管理和事实核查仍需要工具与人工判断。上下文长度也不能照搬旧教程。苹果的 macOS 27 示例展示了较新设备上 8192 token 的上下文，同时提供contextSize查询接口。前面的fm chat实拍界面也显示这台机器的会话容量为 8,192 token。这里依据的是聊天界面的显示，没有另外通过contextSizeAPI 查询；其他机器应检查自己的实际值。上下文需要容纳指令、历史对话、材料和生成内容。中文字符数不能直接当作 token 数。实用的处理方式是按主题切分材料，逐段提取要点，再用要点组织提纲；保留原文位置，方便最后核查，避免多轮摘要逐渐丢失条件。做视频，它可以承担脚本环节macOS 27 的设备端模型增加了图片理解能力，但理解图片与生成图片、视频是不同任务。不能把 Foundation Models 的文本和图片输入接口，当成直接输出 MP4 的接口。我更关心的是，让它把已经核实的文章变成镜头计划。看下图中蓝色的脚本阶段：模型在这里生成结构化内容；后续的配音、字幕时间轴和渲染仍由各自工具完成。例如，先让模型把一段文字改成适合口述的句子，再为每段生成画面描述。程序检查字段、句子长度和原文对应关系，随后交给 TTS 生成旁白，依据真实音频安排字幕与镜头，最后渲染成 MP4。这里的时长必须由实际音频确认，不能把模型估算当作最终时间轴。视频中的代码、数字和技术结论，也应继续与文章原稿核对。安装了系统，为什么模型仍可能不可用？苹果当前支持文档列出了设备、存储空间、语言和地区条件。支持简体中文，不代表所有地区和所有设备都能启用。截至本次核查，苹果仍说明：中国大陆购买的支持设备暂时无法使用 Apple Intelligence；在中国大陆以外购买的支持设备，如果同时位于中国大陆且 Apple Account 地区为中国大陆，也暂时无法使用。本次没有检查账户地区或系统开关，但fm available与实际生成结果已经证明：这台 Mac 在本次测试环境中可以调用设备端模型。其他机器仍应以自己的系统设置、可用性检查和实际调用结果为准。云端模型还涉及网络、使用额度及接入条件。设备端没有云 API 的按 token 调用费用，也仍有算力、内存和耗电成本；不能把它理解成无限吞吐量的免费服务器。我会从一个小功能开始对自己的文章和视频工具，我会先接入“短笔记提取要点”，再尝试“单段文章生成镜头脚本”。先用固定材料检查遗漏、编造、字段错误和耗时，再决定是否扩大范围。目前最明确的结论是：这台 Mac 已经成功调用设备端模型，命令行和本地 HTTP 两条路径都跑通了。中文短文本、token 计数和简单镜头脚本已有实际结果。下一步值得验证的是自己的真实素材：是否遗漏条件、是否编造内容、是否能减少人工整理时间。通过这些检查，再把模型接入正式创作流水线。
我最近买了一个Macmini M6芯片的，买来就提示升级Macos 27系统，我想弄清一个很实际的问题：Mac mini 已经运行 macOS 27，能不能直接调用系统里内置的 AI 模型，为自己开发工作和AI工具提供能力？可以，苹果已经提供正式入口。macOS 27 自带fm命令，开发者还可以使用 Foundation Models 框架和苹果的 Python SDK。本机的fm手册甚至列出了serve，可以启动 Chat Completions API 服务。但“系统支持”“模型可用”和“生成效果够好”，是三个需要分别确认的问题。这次检查也正好碰到了第一道实际门槛。我的 Mac 上，已经能找到什么？2026 年 10 月 19 日，我对这台 Mac mini 做了只读检查：系统报告为 macOS 27.0.1，终端能找到/usr/bin/fm，本机还有对应的fm(1)手册。最初执行fm --help时，程序提示尚未同意 CLI 条款。随后，我在终端运行sudo fm license，阅读条款并输入yes，完成了这一步。注意下面截图末行的You have agreed to these terms.。这是许可接受成功的真实终端记录，图片保留了完整终端记录；许可确认与模型能否生成内容，仍需分别检查。再次执行：fm license--statusfm available本机分别报告条款已接受，以及：Agreed to license FM1 version 1.0 on Oct 19, 2026 at 12:51 AM. System model available之后的实测使用设备端system模型，完成了中文文本生成、token 计数、结构化输出和本地 HTTP API 请求。测试没有安装 Python SDK，也没有调用 PCC 云端模型。系统里的 AI，不只有一条运行路径Foundation Models 是苹果提供的模型访问接口。默认的SystemLanguageModel对应设备端模型，适合把推理能力嵌入自己的程序。它不要求我们先下载一份开放权重，再自己维护推理引擎。但 Apple Intelligence 的产品功能还会涉及云端能力。macOS 27 的框架增加了 Private Cloud Compute，也就是苹果的私有云计算模型。框架还能接入其他模型提供方。看下图：蓝色通路停留在 Mac 的边界内；橙色通路跨过设备边界。两条路径可能使用相近的开发接口，但数据去向和运行条件不同。对本地工具而言，需要明确选择设备端模型。使用 Python 时，创建SystemLanguageModel()，再把它传入会话，比依赖隐含配置更容易检查。设备端推理可以离线运行，但首次准备模型资产可能需要联网。工具若自行调用网络搜索或远程服务，整个工作流也就不再完全离线。苹果在 WWDC26 演示中展示过--model pcc。不过，我这台机器的本地手册只列出system模型。因此，不应把大会演示里的每一个选项，都当作当前机器上已确认可用的命令。最快的入口：先用 fm 验证一个小任务先运行fm --help，可以看到当前版本真正提供的命令。下面原图左侧列出了available、chat、count-tokens、license、respond、schema和serve；MODELS区域则把system标为默认设备端模型。如果只是想先和模型对话，可以直接进入交互界面：fm chat下面是一次实际对话的完整截图。顶部显示model: system，我输入hello, who are you?，模型回答自己是苹果开发的基础模型，并列出内容生成、摘要、提取和分类等用途。模型的自我介绍只是这次对话的输出；确认正在使用哪个模型，应看界面的模型标识与程序配置。注意截图底部的165 / 8,192 (2% used)：这个会话界面显示上下文容量为 8,192 token，当前占用为 165 token。旁边还显示本轮输入 106、输出 59。这给出了本机交互会话的实际观察值，不能把它推广为所有 Mac 的固定规格，也不能把 8,192 理解为可输入的汉字数。chat适合手动试提示词；要让脚本拿到一次调用的结果，可以使用respond。下面原图展示了fm respond --help的完整选项，底部还保留了一次fm respond 'What is Macmini?'的实际调用与英文回答。对接创作工具时，可以先关注四项：--instructions设置任务要求，--schema指定结构化输出，--no-stream等待完整结果，--save-transcript保存会话记录。截图中出现--image和--tool，只说明当前 CLI 提供这些入口；本文的简单实测没有覆盖图片理解、OCR 或条码工具。三张截图均按原图保留，帮助页文字较密，手机阅读时可放大查看；关键命令在正文中另有可复制版本。完成许可和系统设置后，先检查可用性：fm available再尝试一个范围很小的中文任务：fm respond--modelsystem\'请把下面的笔记改写成一句清楚的中文：本地模型负责摘要，程序负责保存文件。'上面这条改写命令在本机成功执行，实际返回：本地模型负责摘要，程序负责保存文件。这次模型保留了原句。它证明中文输入与输出链路已经打通，却不能证明模型在复杂改写中一定能带来提升。我还运行了：fm count-tokens'本地模型负责摘要，程序负责保存文件。'本机返回11。这只是该字符串的计数，不代表完整会话只占 11 个 token；会话还包含指令和其他内容。测试中有一个容易误判的细节：在自动化工具的受限沙箱里，文本生成和计数都报过ModelManagerServices.ModelManagerError error 1008；获得授权后，在沙箱外重跑则成功。因此，遇到该错误时，可以检查运行环境对系统模型服务的访问限制，不应仅凭错误编号就断言模型没有下载或地区不支持。本次对照也不足以解释所有1008错误。本机手册还列出chat、count-tokens和schema。分别可以用于交互对话、计算 token 数量、生成结构化输出的 schema。如果需要把文章内容交给模型，不要只在提示词里写一个文件名。除非程序明确读取了文件，模型并不会自动看到文件内容。一个较短文本的调用示例如下：frompathlibimportPathimportsubprocess text=Path("notes.txt").read_text(encoding="utf-8")result=subprocess.run(["/usr/bin/fm","respond","--model","system","--no-stream","请概括以下材料，不补充外部事实：\n"+text],capture_output=True,text=True,timeout=120,check=True,)print(result.stdout)这里由 Python 读取文件，再把内容交给模型。示例适合短笔记；长文需要分段，也要处理超时、模型不可用和生成失败。它没有使用 shell 拼接命令，正文中的特殊字符不会被当成 shell 指令执行。开发 Python 工具，可以直接用官方 SDK苹果维护了apple-fm-sdk，导入名称为apple_fm_sdk。官方仓库列出的基本要求包括 macOS 26.0 及以上、Python 3.10 及以上、Xcode 26.0 及以上，以及在兼容 Mac 上启用 Apple Intelligence。具体的新能力仍要看系统与 SDK 版本。建议在工具自己的虚拟环境里安装：python3-mvenv .venvsource.venv/bin/activate python-mpipinstallapple-fm-sdk一个直接检查模型、读取笔记并生成摘要的示例：importasynciofrompathlibimportPathimportapple_fm_sdkasfmasyncdefmain():model=fm.SystemLanguageModel()available,reason=model.is_available()ifnotavailable:print(f"Model unavailable:{reason}")returnsession=fm.LanguageModelSession(model=model,instructions="用简体中文回答。只依据输入材料，不补充事实。",)notes=Path("notes.txt").read_text(encoding="utf-8")response=awaitsession.respond("请提炼三个要点：\n"+notes)print(response)asyncio.run(main())这个例子按官方接口编写，本次没有安装 SDK 或执行推理。正式集成还需要捕获生成错误，并给出可读的失败原因。SDK 更值得关注的能力是结构化生成。通过@fm.generable描述输出类型，再把类型传给respond(..., generating=...)，可以让结果符合程序需要的字段。为了先验证这个思路，我没有安装 SDK，而是直接用 CLI 生成一个镜头脚本的 schema：fm schema object--nameScene\--stringnarration\--stringvisual\--stringscreen_text>scene-schema.json fm respond--modelsystem --no-stream\--schemascene-schema.json\'把这句话变成一个镜头脚本：本地模型在 Mac 上处理笔记，不需要把笔记发到云端。用简体中文填写字段。'本机生成结果如下，仅调整了缩进和字段展示顺序，字段值保留原样：{"narration":"本地模型在Mac上处理笔记，不需要把笔记发到云端。","visual":"展示本地处理笔记的场景，例如在Mac电脑上编辑文档，没有网络连接的图标。","screen_text":"本地处理笔记，无需上传云端"}三个字段都返回了字符串，程序可以继续读取；不过，画面描述仍很笼统，还需要细化成可执行的视觉方案。“没有网络连接的图标”也只是模型提出的画面建议，不是它检测到的机器网络状态。还有一个实际踩到的问题：手写的普通 JSON Schema 被当前 CLI 拒绝，报出Invalid schema。改用fm schema object生成的文件后成功。因此，入门教程最好直接使用工具生成的 schema；不要默认任何 JSON Schema 写法都能兼容。字段稳定后，程序才方便连接后续步骤。但结构符合要求，不代表旁白事实正确，也不代表场景时长合理，这些仍要验证。已有 API 客户端，能不能直接连接？本机fm(1)手册明确写到：fm serve可以启动 Chat Completions API 服务，并提供--host、--port和 Unix socket 选项。这为已有 HTTP 客户端提供了值得验证的接入路径。例如，可以按手册启动一个仅监听本机的服务：fm serve--host127.0.0.1--port8765这次我实际启动了服务，监听地址为127.0.0.1:8765。先查询模型列表：curl-sShttp://127.0.0.1:8765/v1/models返回列表包含模型 IDsystem。随后发送一个非流式请求：curl--max-time60-sS\http://127.0.0.1:8765/v1/chat/completions\-H'Content-Type: application/json'\-d'{"model":"system","messages":[{"role":"user","content":"请用一句中文解释本地推理。"}],"stream":false}'实际返回的choices[0].message.content是：本地推理是指在设备本地进行计算，而不是将数据发送到云端进行处理。这次响应中的usage报告：输入 63 token，输出 29 token，总计 92 token。这些是该次请求返回的用量记录，不是模型速度或质量的基准测试。服务日志显示两个 HTTP 请求均返回200，测试结束后已停止服务。因此，目前可以确认：已有 HTTP 客户端能够通过本机/v1/chat/completions发起简单的非流式文本请求。客户端若需要填写基础地址，对应的是http://127.0.0.1:8765/v1，模型名称为system；具体仍要看客户端如何拼接路径。这不等于所有客户端都已兼容。流式输出、图片消息格式、工具调用和其他可选参数，本次没有逐项测试。对一个新的 Python 项目，官方 SDK 更方便表达模型可用性检查；对已经有 HTTP 模型接口的工具，本地服务已经有了一个可复现的最小接入例子。写文章，先把它放进材料处理环节我会优先让设备端模型处理已经收集好的材料：提取要点、归类笔记、压缩段落、给出标题候选，以及检查术语是否前后一致。这些任务范围清楚，也便于逐条对照原文。对于“研究一个新技术，再写出事实准确的长文”，单独调用设备端模型并不足够。检索、来源管理和事实核查仍需要工具与人工判断。上下文长度也不能照搬旧教程。苹果的 macOS 27 示例展示了较新设备上 8192 token 的上下文，同时提供contextSize查询接口。前面的fm chat实拍界面也显示这台机器的会话容量为 8,192 token。这里依据的是聊天界面的显示，没有另外通过contextSizeAPI 查询；其他机器应检查自己的实际值。上下文需要容纳指令、历史对话、材料和生成内容。中文字符数不能直接当作 token 数。实用的处理方式是按主题切分材料，逐段提取要点，再用要点组织提纲；保留原文位置，方便最后核查，避免多轮摘要逐渐丢失条件。做视频，它可以承担脚本环节macOS 27 的设备端模型增加了图片理解能力，但理解图片与生成图片、视频是不同任务。不能把 Foundation Models 的文本和图片输入接口，当成直接输出 MP4 的接口。我更关心的是，让它把已经核实的文章变成镜头计划。看下图中蓝色的脚本阶段：模型在这里生成结构化内容；后续的配音、字幕时间轴和渲染仍由各自工具完成。例如，先让模型把一段文字改成适合口述的句子，再为每段生成画面描述。程序检查字段、句子长度和原文对应关系，随后交给 TTS 生成旁白，依据真实音频安排字幕与镜头，最后渲染成 MP4。这里的时长必须由实际音频确认，不能把模型估算当作最终时间轴。视频中的代码、数字和技术结论，也应继续与文章原稿核对。安装了系统，为什么模型仍可能不可用？苹果当前支持文档列出了设备、存储空间、语言和地区条件。支持简体中文，不代表所有地区和所有设备都能启用。截至本次核查，苹果仍说明：中国大陆购买的支持设备暂时无法使用 Apple Intelligence；在中国大陆以外购买的支持设备，如果同时位于中国大陆且 Apple Account 地区为中国大陆，也暂时无法使用。本次没有检查账户地区或系统开关，但fm available与实际生成结果已经证明：这台 Mac 在本次测试环境中可以调用设备端模型。其他机器仍应以自己的系统设置、可用性检查和实际调用结果为准。云端模型还涉及网络、使用额度及接入条件。设备端没有云 API 的按 token 调用费用，也仍有算力、内存和耗电成本；不能把它理解成无限吞吐量的免费服务器。我会从一个小功能开始对自己的文章和视频工具，我会先接入“短笔记提取要点”，再尝试“单段文章生成镜头脚本”。先用固定材料检查遗漏、编造、字段错误和耗时，再决定是否扩大范围。目前最明确的结论是：这台 Mac 已经成功调用设备端模型，命令行和本地 HTTP 两条路径都跑通了。中文短文本、token 计数和简单镜头脚本已有实际结果。下一步值得验证的是自己的真实素材：是否遗漏条件、是否编造内容、是否能减少人工整理时间。通过这些检查，再把模型接入正式创作流水线。