我最近买了一个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 --status
fm 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 的边界内；橙色通路跨过设备边界。两条路径可能使用相近的开发接口，但数据去向和运行条件不同。
蓝色路径在 Mac 内完成推理，橙色路径需要访问云端模型。
对本地工具而言，需要明确选择设备端模型。使用 Python 时，创建 SystemLanguageModel()，再把它传入会话，比依赖隐含配置更容易检查。
设备端推理可以离线运行，但首次准备模型资产可能需要联网。工具若自行调用网络搜索或远程服务，整个工作流也就不再完全离线。
苹果在 WWDC26 演示中展示过 --model pcc。不过，我这台机器的本地手册只列出 system 模型。因此，不应把大会演示里的每一个选项，都当作当前机器上已确认可用的命令。
最快的入口：先用 fm 验证一个小任务
先运行 fm --help，可以看到当前版本真正提供的命令。下面原图左侧列出了 available、chat、count-tokens、license、respond、schema 和 serve；MODELS 区域则把 system 标为默认设备端模型。
完整帮助界面同时列出了交互聊天、单次生成和本地 API 服务入口。
如果只是想先和模型对话，可以直接进入交互界面：
fm chat下面是一次实际对话的完整截图。顶部显示 model: system，我输入 hello, who are you?，模型回答自己是苹果开发的基础模型，并列出内容生成、摘要、提取和分类等用途。模型的自我介绍只是这次对话的输出；确认正在使用哪个模型，应看界面的模型标识与程序配置。
聊天界面显示 system 模型已返回回答，底部同时展示本轮 token 与上下文用量。
注意截图底部的 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?' 的实际调用与英文回答。
respond 帮助展示了图片输入、结构化输出与会话保存等选项，底部单次问答已成功返回。
对接创作工具时，可以先关注四项：--instructions 设置任务要求，--schema 指定结构化输出，--no-stream 等待完整结果，--save-transcript 保存会话记录。截图中出现 --image 和 --tool，只说明当前 CLI 提供这些入口；本文的简单实测没有覆盖图片理解、OCR 或条码工具。三张截图均按原图保留，帮助页文字较密，手机阅读时可放大查看；关键命令在正文中另有可复制版本。
完成许可和系统设置后，先检查可用性：
fm available再尝试一个范围很小的中文任务：
fm respond --model system \
'请把下面的笔记改写成一句清楚的中文：本地模型负责摘要，程序负责保存文件。'上面这条改写命令在本机成功执行，实际返回：
本地模型负责摘要，程序负责保存文件。这次模型保留了原句。它证明中文输入与输出链路已经打通，却不能证明模型在复杂改写中一定能带来提升。
我还运行了：
fm count-tokens '本地模型负责摘要，程序负责保存文件。'本机返回 11。这只是该字符串的计数，不代表完整会话只占 11 个 token；会话还包含指令和其他内容。
测试中有一个容易误判的细节：在自动化工具的受限沙箱里，文本生成和计数都报过 ModelManagerServices.ModelManagerError error 1008；获得授权后，在沙箱外重跑则成功。因此，遇到该错误时，可以检查运行环境对系统模型服务的访问限制，不应仅凭错误编号就断言模型没有下载或地区不支持。本次对照也不足以解释所有 1008 错误。
本机手册还列出 chat、count-tokens 和 schema。分别可以用于交互对话、计算 token 数量、生成结构化输出的 schema。
如果需要把文章内容交给模型，不要只在提示词里写一个文件名。除非程序明确读取了文件，模型并不会自动看到文件内容。一个较短文本的调用示例如下：
from pathlib import Path
import subprocess
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 -m venv .venv
source .venv/bin/activate
python -m pip install apple-fm-sdk一个直接检查模型、读取笔记并生成摘要的示例：
import asyncio
from pathlib import Path
import apple_fm_sdk as fm
async def main():
model = fm.SystemLanguageModel()
available, reason = model.is_available()
if not available:
print(f"Model unavailable: {reason}")
return
session = fm.LanguageModelSession(
model=model,
instructions="用简体中文回答。只依据输入材料，不补充事实。",
)
notes = Path("notes.txt").read_text(encoding="utf-8")
response = await session.respond("请提炼三个要点：\n" + notes)
print(response)
asyncio.run(main())这个例子按官方接口编写，本次没有安装 SDK 或执行推理。正式集成还需要捕获生成错误，并给出可读的失败原因。
SDK 更值得关注的能力是结构化生成。通过 @fm.generable 描述输出类型，再把类型传给 respond(..., generating=...)，可以让结果符合程序需要的字段。
为了先验证这个思路，我没有安装 SDK，而是直接用 CLI 生成一个镜头脚本的 schema：
fm schema object --name Scene \
--string narration \
--string visual \
--string screen_text > scene-schema.json
fm respond --model system --no-stream \
--schema scene-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 --host 127.0.0.1 --port 8765这次我实际启动了服务，监听地址为 127.0.0.1:8765。先查询模型列表：
curl -sS http://127.0.0.1:8765/v1/models返回列表包含模型 ID system。随后发送一个非流式请求：
curl --max-time 60 -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。这里依据的是聊天界面的显示，没有另外通过 contextSize API 查询；其他机器应检查自己的实际值。
上下文需要容纳指令、历史对话、材料和生成内容。中文字符数不能直接当作 token 数。实用的处理方式是按主题切分材料，逐段提取要点，再用要点组织提纲；保留原文位置，方便最后核查，避免多轮摘要逐渐丢失条件。
做视频，它可以承担脚本环节
macOS 27 的设备端模型增加了图片理解能力，但理解图片与生成图片、视频是不同任务。不能把 Foundation Models 的文本和图片输入接口，当成直接输出 MP4 的接口。
我更关心的是，让它把已经核实的文章变成镜头计划。看下图中蓝色的脚本阶段：模型在这里生成结构化内容；后续的配音、字幕时间轴和渲染仍由各自工具完成。
模型负责文章到镜头脚本的转换，音频与视频文件由后续工具生成。
例如，先让模型把一段文字改成适合口述的句子，再为每段生成画面描述。程序检查字段、句子长度和原文对应关系，随后交给 TTS 生成旁白，依据真实音频安排字幕与镜头，最后渲染成 MP4。
这里的时长必须由实际音频确认，不能把模型估算当作最终时间轴。视频中的代码、数字和技术结论，也应继续与文章原稿核对。
安装了系统，为什么模型仍可能不可用？
苹果当前支持文档列出了设备、存储空间、语言和地区条件。支持简体中文，不代表所有地区和所有设备都能启用。
截至本次核查，苹果仍说明：中国大陆购买的支持设备暂时无法使用 Apple Intelligence；在中国大陆以外购买的支持设备，如果同时位于中国大陆且 Apple Account 地区为中国大陆，也暂时无法使用。
本次没有检查账户地区或系统开关，但 fm available 与实际生成结果已经证明：这台 Mac 在本次测试环境中可以调用设备端模型。其他机器仍应以自己的系统设置、可用性检查和实际调用结果为准。
云端模型还涉及网络、使用额度及接入条件。设备端没有云 API 的按 token 调用费用，也仍有算力、内存和耗电成本；不能把它理解成无限吞吐量的免费服务器。
我会从一个小功能开始
对自己的文章和视频工具，我会先接入“短笔记提取要点”，再尝试“单段文章生成镜头脚本”。先用固定材料检查遗漏、编造、字段错误和耗时，再决定是否扩大范围。
目前最明确的结论是：这台 Mac 已经成功调用设备端模型，命令行和本地 HTTP 两条路径都跑通了。 中文短文本、token 计数和简单镜头脚本已有实际结果。下一步值得验证的是自己的真实素材：是否遗漏条件、是否编造内容、是否能减少人工整理时间。通过这些检查，再把模型接入正式创作流水线。