万元级边缘算力方案：Mac Mini在几个知识库项目的部署实践
做企业知识库项目，私有化部署是绕不开的话题。有些行业有明确的合规要求，数据必须落在自己的服务器上；还有一些中小企业，数据本身可能并没那么敏感，但老板出于个人偏好也倾向于做本地化。这类项目的交付方式都是软硬件一体，不光要调好模型，还要把算力设备一起配好。
中大型企业的算力配置相对好办，要么用企业自己的私有云，要么采购 GPU 服务器，具体实施上负责把应用跑起来就行。但中小企业预算有限，往往也没有专职运维人员来维护 Linux 环境。
过去大半年给几个这样的客户做部署，最后都选了 Mac Mini 作为算力终端。Mac Mini 体积小、功耗低、自带 macOS 系统，买回来开箱即用，不用折腾驱动和环境配置。对于知识库问答这种低并发场景完全够用。
这篇试图说清楚：
模型选型时内存怎么分配、怎么把所有依赖打包做离线部署、Mac Mini 的服务器化改造（防止睡眠、自动登录、开机自启）、网络配置让 IP 保持稳定、远程监控和持续运维的设计思路。最后也聊一些关于边缘算力普惠、知识库应用和大模型落地的思考。
以下，enjoy：
1、模型选型：内存怎么分配
Mac Mini 的统一内存是 CPU 和 GPU 共享的，所以跑大模型的时候，内存分配需要提前规划。以 M4 Pro 64G 配置为例，内存开销主要分三块：LLM 问答模型占大头，Embedding 向量化模型相对固定且占用较小，剩下的是 macOS 系统和 Docker、数据库等基础服务的运行开销。
64G 内存，扣掉系统和服务的固定消耗，实际可用于模型的大约是 50G 左右。如果选 M4 Max 128G 的配置，可用空间会更宽裕，但价格也贵不少，具体根据客户预算来定。
1.1、14B、20B、30B 怎么选
业内做 RAG 落地，问答模型一般都在 14B 到 30B 之间选。具体选哪个尺寸，主要看几个因素：
推理能力：14B 和 30B 的差距是肉眼可见的。14B 模型在简单问答、信息抽取这类任务上表现不错，但如果知识库涉及比较复杂的技术内容，需要模型做一些推理和归纳，30B 会明显更稳。20B 是个折中选择，目前 Qwen 系列有 qwen3:14b 和 qwen3:32b，20B 这个档位可以看其他模型比如 gpt-oss。
响应速度：模型越大，推理速度越慢，这个没什么好说的。首 Token 延迟（TTFT）主要取决于上下文长度——输入给模型的 Prompt 越长，等待时间越久。同样的上下文长度，30B 的等待时间大概是 14B 的两倍左右。如果用户对响应速度比较敏感，14B 体验会更好。
内存占用：Q4 量化的情况下，14B 大概占 10G 左右，30B 大概占 20G 左右。加上 Embedding 模型（一般 2-3G）和系统开销，64G 机器跑 14B 绑绰有余，跑 30B 也问题不大。128G 机器跑 30B 会更从容，并发承受能力也更强。
我的做法是如果客户预算有限用 64G，默认上 14B，后续根据实际使用效果再决定要不要升级；如果预算充足用 128G，直接上 30B。
至于 70B 这个量级，理论上效果更好，但在实际项目里很少用。一方面内存占用太大（35-40G），留给系统和其他服务的余量紧张；另一方面，如果数据治理和上下文工程做得扎实，知识库结构清晰、检索准确率高、Prompt 设计合理，其实不需要这么大的模型。因为模型能力是用来兜底的，不是用来弥补数据质量问题的。
1.2、Embedding 模型
Embedding 模型相对简单，选一个和 LLM 同系列的就行，比如用 Qwen 的 LLM 就配 qwen3-embedding。好处是语义空间一致，检索和生成的匹配度会更好。Embedding 模型一般都比较小，4B 左右，内存占用 2-3G，不是瓶颈。当然，也可以按需选择 8B 版本。
1.3、为什么用 Ollama
Ollama 在 Mac 上的体验很好，毕竟原生支持 Apple Silicon，不需要额外配置 MPS，ollama pull 下载模型、ollama list 查看、ollama rm 删除，管理起来很方便。API 兼容 OpenAI 格式，现有代码几乎不用改。
有一点需要注意，Ollama 默认会在空闲一段时间后自动卸载模型释放内存。对于交付场景，客户一般希望模型始终驻留在内存里，避免用户第一次提问时等半天。配置方法是设置环境变量 OLLAMA_KEEP_ALIVE=-1，表示永不卸载。这个可以写到开机自启脚本里，后面会讲到。
2、可移植性设计：让部署过程可复制
做边缘部署，怕的是在自己电脑上能跑，到客户那边跑不起来。确实第一次用 mac mini 做部署的时候，碰到了很多坑。之所以写这篇文章也是因为部署了三四个客户了，觉得有一些相对来说比较成型的经验，不一定是最佳实践，但确实能用。这一部分的话就来分享些这种可复制的细节设计。
2.1、网络环境的坑
一开始设计的部署方案挺美好的：写一个 first_time_setup.sh，一键搞定所有事情——检测软件、下载模型、创建虚拟环境、安装依赖。结果第一个客户到现场配置 Mac Mini 的时候发现，一键压根跑不起来。
问题出在网络环境。首先忽略了一个问题，就是客户的 Mac Mini 虽然能联网，但访问外网很不稳定。pip install 从 PyPI 下载依赖，时快时慢，有时候直接超时；ollama pull 拉模型，模型托管在 HuggingFace，国内访问受限；docker pull 拉镜像，Docker Hub 经常卡住；brew install 装软件，Homebrew 源在 GitHub，能成功算运气好。
在现场折腾网络是最痛苦的事情，因为你不知道是网络的问题还是配置的问题，排查起来效率极低。所以后来的做法是先在自己电脑上把所有东西下载好，直接打包带过去。
2.2、需要提前准备的安装包
一台干净的 Mac Mini 要跑起 RAG 系统，需要这些东西：
基础软件：Python 3.11 从 python.org下载 .pkg 安装包，大概 43MB；Docker Desktop 从 docker.com下载 .dmg，大概 600MB；Ollama 从 ollama.com下载 .dmg，大概 100MB。这些都是官网直接下载，存到移动硬盘里带过去。
Ollama 模型：模型是大头，一个 14B 的量化模型大概 10G，加上 Embedding 模型，整体打包下来十几个 G。Ollama 的模型存储在 ~/.ollama/models/ 目录，直接打包复制就行：
# 在有网络的开发机上
cd ~/.ollama
tar -cvzf ollama_models.tar.gz models/
# 复制到 Mac Mini 后
cd ~/.ollama
tar -xvzf ollama_models.tar.gz
# 验证模型
ollama list
这一步实测特别省事，比在现场等几个小时下载模型强多了。
Docker 镜像：如果系统用到了 Docker 容器（比如 MinIO 做对象存储），镜像也需要提前下载：
# 在有网络的机器上
docker pull minio/minio:latest
docker save minio/minio:latest -o minio_image.tar
# 在 Mac Mini 上
docker load -i minio_image.tar
Python 依赖：这个稍微麻烦一点，因为 pip 的离线安装不太方便。我的做法是把整个虚拟环境打包过去，连同 venv 目录一起。或者简单点，先把 requirements.txt 里的依赖都下载成 wheel 文件：
pip download -r requirements.txt -d ./packages
然后到客户那边离线安装：
pip install --no-index --find-links=./packages -r requirements.txt
2.3、代码里的路径处理
开发阶段，代码里有时候会写死路径，比如：
CHROMA_PATH = "/Users/weidongdong/Downloads/Projects/xxx/chroma_db"
这在本地开发没问题，但部署到客户的 Mac Mini 上就会报错——路径不存在。解决方案是把所有路径改成相对于项目根目录的动态路径。其实最好的做法是在项目开发初期就统一使用相对路径，这样无论代码复制到哪台设备，都能直接运行：
from pathlib import Path
PROJECT_ROOT = Path(file).parent.parent # 项目根目录
CHROMA_PATH = str(PROJECT_ROOT / "chroma_db")
模型配置也可以改成从环境变量读取，提供默认值：
import os
OLLAMA_LLM_MODEL = os.getenv("OLLAMA_LLM_MODEL", "qwen3:14b")
OLLAMA_EMBEDDING_MODEL = os.getenv("OLLAMA_EMBEDDING_MODEL", "qwen3-embedding:4b")
这样如果后续要换模型，改一下环境变量就行，不用动代码。
2.4、向量数据库的选型与可移植性
向量数据库的选型上，常见的开源选项有 ChromaDB、FAISS、Milvus 等。对于边缘侧部署的中小企业场景，我一般选用 ChromaDB，原因很简单：够用、省事、易迁移。
Milvus 是分布式架构，适合大规模数据和高并发场景，但部署起来需要 etcd、MinIO 等一堆依赖，对于几万条文档、几个人用的场景来说太重了。FAISS 性能很好，但它是个库而不是数据库，没有持久化和元数据管理，需要自己封装一层。ChromaDB 是文件型的本地数据库，单机部署、零依赖、开箱即用，对于中小企业的私有化场景刚刚好。
关于向量维度的问题也顺道解释下，理论上维度越高，向量能表达的语义信息越丰富，检索精度可能更高。但在实际项目里，维度高意味着存储空间更大、检索速度更慢、对内存的压力也更大。目前主流的 Embedding 模型输出维度在 768 到 1536 之间，对于企业知识库这种规模（几千到几十万条文档），1024 维左右的模型已经完全够用。盲目追求高维度，收益有限，成本却实实在在。
ChromaDB 的另一个好处是可移植性好。它是文件型数据库，所有数据都存在本地目录里。只要满足两个条件，就可以直接把开发机上的数据库复制到客户机器上用，不需要重新入库：
第一，整个 chroma_db/ 目录跟着项目一起打包。
第二，目标机器的 Embedding 模型版本要一致。因为向量数据库里存的是向量，不同模型输出的向量维度可能不一样，或者即使维度一样，语义空间也不同。
这一点大大简化了交付流程，在开发机上把知识库入库完成后，直接复制整个项目目录到客户机器，开箱即用。
3、Mac Mini 服务器化改造
Mac Mini 买回来是一台普通电脑，要让它变成一个合格的边缘算力终端，实现开机自启、无人值守、稳定运行几个月不出问题——需要进行一系列服务器化配置。这部分内容看起来琐碎，但也都是在实际交付过程中踩坑总结出来的。
3.1、防止自动睡眠
Mac Mini 作为服务器用，除了最开始配网外，客户现场一般不会接显示器。但 macOS 的默认行为是一段时间没人操作就自动睡眠。这对于需要 24 小时运行的服务来说肯定不行。macOS Ventura 及以后版本，需要配置三个地方，缺一不可：
系统设置 → 显示器 → 高级 → 「当显示器关闭时防止自动睡眠」开启
系统设置 → 锁定屏幕 → 「不活动时关闭显示器」设为「从不」
系统设置 → 电池 → 选项 → 「防止自动睡眠」开启
如果系统设置不生效（遇到过一次），还有个命令行工具 caffeinate 可以用：
caffeinate -s
这个命令会保持系统唤醒状态。可以通过 LaunchDaemon 让它开机自动运行，算是兜底方案。
3.2、自动登录
这个坑更隐蔽。Mac Mini 重启后，如果停留在登录页面等着输密码，那么 ~/Library/LaunchAgents/ 下的开机自启服务都不会启动。
也就是说，Ollama、Docker、Streamlit 这些服务都不会运行，因为 LaunchAgents 是用户级服务，需要用户登录之后才会被触发。如果设备是无人值守的，没人去输密码，服务就一直起不来。
解决方案是配置自动登录：系统设置 → 用户与群组 → 点击右下角「自动登录为...」→ 选择固定的账户。
有一个注意事项：如果这个选项是灰色不可选，通常是因为启用了 FileVault（macOS 的全盘加密）。对于内网部署的服务器，物理访问本身就是受控的，可以考虑禁用 FileVault：
# 查看 FileVault 状态
fdesetup status
# 禁用 FileVault（需要重启）
sudo fdesetup disable
但需要特别说明下：禁用 FileVault 会降低数据安全性。但考虑到客户的 Mac Mini 都放在有门禁的办公室里，物理访问本身就是受控的，所以这是可接受的折中。
3.3、开机自启：LaunchAgents
macOS 的服务管理机制是 launchd，类似于 Linux 的 systemd。用户级服务的配置文件放在 ~/Library/LaunchAgents/ 目录下，是 XML 格式的 .plist 文件。
一个典型的 RAG 系统需要配置三个服务的开机自启：
Ollama。Ollama 安装后默认就会注册开机自启，一般不需要额外配置。如果没有自启，可以手动创建 plist 文件。
Docker 容器。如果用到了 Docker（比如 MinIO），需要配置 Docker Desktop 开机启动，同时让容器在 Docker 启动后自动运行。这里有个坑：Docker Desktop 启动需要时间，如果容器启动命令执行太早，Docker daemon 还没就绪，就会失败。我一开始设的是 30 秒延迟，结果有时候还是不够，调到 60 秒之后稳定了：
sleep 60 && docker start minio
应用服务。比如 Streamlit 应用，需要等 Ollama 和 Docker 都就绪之后再启动。同样用延迟来控制启动顺序。
还有一个坑：在 launchd 环境下，source venv/bin/activate 有时候会失败——可能是权限问题，也可能是环境变量的问题。解决方案是绕过 source，直接调用虚拟环境里的可执行文件：
cd /path/to/POC && source venv/bin/activate && streamlit run app.py
cd /path/to/POC && /path/to/POC/venv/bin/streamlit run app.py
这样就不依赖 shell 的 source 机制了，稳定性好很多。配置好之后，用 launchctl load 加载服务，然后重启 Mac Mini 验证一下是不是真的能自启。
3.4、其他细节
禁用屏幕保护程序。无显示器场景下，屏幕保护程序没意义，反而消耗系统资源。在「系统设置 → 屏幕保护程序」里关掉就行。
HDMI 虚拟插头。有些 Mac 在没有显示器连接时会有奇怪的行为，比如分辨率被重置、某些 GPU 相关功能不可用。我没遇到过这个问题，但网上有人反馈过。如果遇到这类情况，可以买一个「HDMI 虚拟插头」（Headless Ghost），十几块钱，插上后 Mac 会认为有显示器连接。
4、网络配置：IP 稳定性
Mac Mini 部署好之后，团队其他成员需要通过浏览器访问上面的服务。这就需要一个稳定的 IP 地址，不然今天是 192.168.1.100，明天变成 192.168.1.108，每次客户内部都要通知大家更新地址，很麻烦。
默认情况下，路由器使用 DHCP 动态分配 IP 地址，Mac Mini 重启、路由器重启、或者 DHCP 租约到期后，IP 都可能变。要解决这个问题，有两种常用方案。
4.1、方案一：手动设置静态 IP
这是最直接的做法。在 Mac Mini 上操作：系统设置 → 网络 → Wi-Fi（或以太网）→ 详细信息 → TCP/IP → 配置 IPv4 选择「手动」，然后填写 IP 地址、子网掩码、路由器地址。
这里有个容易漏的步骤：设置完 IP 之后，还要切换到 DNS 标签页，手动添加 DNS 服务器，比如 223.5.5.5（阿里云）或 8.8.8.8（Google）。我第一次部署的时候就踩了这个坑：只设置了 IP，没设置 DNS，结果能 ping 通，但浏览器打不开网页。排查半天才发现——没有 DNS 服务器，系统不会自动帮你解析域名。
这个方案的适用场景是客户 IT 不让动路由器配置，或者图省事快速搞定。
4.2、方案二：路由器端 MAC 绑定
这种方案不需要改 Mac Mini 的任何配置，而是在路由器后台设置：让路由器记住这个 MAC 地址的设备，每次都分配同一个 IP。
操作步骤：先查看 Mac Mini 的 MAC 地址（系统设置 → 网络 → Wi-Fi → 详细信息 → 硬件，或者命令行 ifconfig en0 | grep ether），然后登录路由器管理页面，找到「DHCP 服务」或「静态地址分配」或「地址绑定」，添加绑定规则。
这个方案的好处是 Mac Mini 保持默认的 DHCP 配置，DNS 由路由器自动分配，不会出现域名解析的问题。即使 Mac Mini 重置网络设置，IP 也不会变。如果客户的 IT 人员愿意配合，这个方案是最省心的。
4.3、有线还是无线
对于服务器场景，有线网络比 Wi-Fi 稳定很多。延迟更低、带宽更高、不受无线干扰影响。如果 Mac Mini 放置位置允许，我一般会优先建议客户用网线。
4.4、macOS 防火墙
如果发现其他电脑无法访问 Mac Mini 上的服务，可能是防火墙拦截了。可以在「系统设置 → 网络 → 防火墙」里检查一下，或者用命令行：
# 查看防火墙状态
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
# 如果是开启状态，临时关闭
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate off
对于内网服务器，关闭防火墙通常是可接受的。
5、远程监控与持续运维
系统部署在客户内网，但初期调试阶段需要远程监控实际使用情况：用户问了什么、检索了哪些文档、回答质量如何、有没有点踩。这些数据是后续优化的基础。
5.1、本地存储 + 云端同步
考虑到客户网络环境的不确定性，监控数据的采集采用「先本地存储，再定时同步」的策略。
本地存储。每一次问答的完整链路数据都写入本地 SQLite 数据库，包括原始问题、改写后的问题、检索到的文档列表、响应时间、用户反馈等。SQLite 是文件型数据库，零依赖，不需要额外部署数据库服务。
云端同步。写一个定时任务，每天把 SQLite 数据文件上传到阿里云 OSS。我在自己电脑上下载 OSS 文件进行分析。这样即使客户网络时好时坏，数据也不会丢。
5.2、安全设计：最小权限
上传到 OSS 需要 Access Key，这个 Key 会打包进交付的系统里。如果客户（或别人）拿到这个 Key，会不会有问题？
主账号的 Key 权限太大，可以读写删除任何数据，风险肯定不能接受。解决方案是在阿里云 RAM 创建一个最小权限子账号，只允许 PutObject（上传），不允许 GetObject（读取）、DeleteObject（删除）、ListBucket（列举）。
效果是即使这个 Key 泄露了，攻击的人最多只能往 Bucket 里写垃圾文件，不能读取或删除任何已有数据。最坏情况就是存储空间被撑大，定期清理即可。
5.3、两种运维模式
根据不同客户对数据合规的要求程度，实际操作中有两种模式：
远程运维。大部分中小企业客户对合规要求不那么严格，在服务合同的约束下，问答数据可以定时同步到云端。我定期下载分析，发现问题后远程沟通解决方案。这种模式效率高，响应快。
本地运维。对于合规要求更严格的客户，所有数据只保存在客户本地，不出域。这种情况一般是每月或每季度安排人现场服务，导出数据分析后现场部署更新。成本更高，但满足严格的数据不出域要求。
5.4、持续优化的节奏
交付不是终点，对于知识库这类系统，交付只是起点。知识库需要持续补充新文档，检索策略需要根据实际使用情况调优，边缘 Case 需要处理。
通常和客户约定的优化节奏是：第一个月收集初期使用数据，处理高频问题，补充缺失文档；第三个月分析用户反馈，优化检索策略；第六个月整体评估系统效果，确认是否需要模型升级。六个月后进入稳定期，按需维护。
还有一点很重要：推动使用和反馈收集是关键。很多知识库项目建好了没人用，技术上线只是第一步，真正的挑战是让员工养成使用习惯，并且愿意给反馈。
这一点我会在服务合同里明确和企业管理层讲清楚：后续优化的前提是用户反馈率要达到一定水平。具体来说，每一次问答之后，员工需要点赞或点踩，表示回答是否有帮助。不能完全没有反馈。如果大部分用户用完就走，不留下任何反馈，后续的优化就没有数据支撑。
为什么这么强调反馈？因为系统能不能从 80 分优化到 95 分，很大程度上取决于客户是否配合做人工标注。点赞点踩本质上就是一种轻量级的人工标注，反馈哪些回答是好的、哪些是差的，然后我才能针对性地调整检索策略或补充知识库。没有这些反馈数据，优化就只能靠猜。
为了保证反馈率，后台会设置相关的看板，统计每周的使用量和反馈率。管理层可以在周会上过一下这个数据，或者系统自动发邮件提醒。把这个机制建立起来，反馈率自然就上去了。
6、可复用的部署工具包
做了几个 Mac Mini 部署项目之后，沉淀下来一套可复用的部署工具包。这套工具包主要包含三类内容：
第一类是自动化部署脚本。包括环境检测、依赖安装、服务配置等流程的自动化。这些脚本把上面讲到的各种踩坑经验都封装进去了，比如启动顺序的延迟控制、虚拟环境的激活方式、离线安装的处理逻辑等等。如果直接上手写，这些细节很容易遗漏，到现场才发现问题会很麻烦。
第二类是 macOS 系统配置模板。主要是 LaunchAgents 的 plist 文件模板，已经包含了常驻内存、自动重启、环境变量注入等关键配置。直接改几个路径就能用，不用从零开始研究 launchd 的 XML 语法。
第三类是运维相关的工具。包括日志同步脚本、云存储权限策略、部署检查清单等。这些是交付之后持续运维需要用到的东西。
这套工具包的价值在于：它不是简单的脚本罗列，而是把多个项目踩过的坑、验证过的配置、优化过的流程都封装进去了。如果你也有类似的项目需要部署到 Mac Mini 上，用这套工具包可以少走很多弯路。
7、写在最后
跳出这篇文章本身，最后再聊几点形而上的思考。
7.1、边缘算力正在变得普惠
三十年前，比尔盖茨推动了 PC 的普及，让计算能力从大型机房走进了千家万户。今天，大模型算力也在经历类似的过程，从云端机房走向边缘终端。
英伟达25年10月也发布了面向个人的 AI 超算 DGX Spark，128GB 统一内存，3999 美元，大小和 Mac Mini 差不多。两台 DGX Spark 组网可以直接跑 405B 的大模型（FP4 精度），已经逼近目前开源的最大模型。不过 DGX Spark 跑的是基于 Ubuntu 的定制系统 DGX OS，更适合开发者和研究人员做模型训练和原型验证，对于普通企业用户来说上手门槛还是偏高的。苹果的 Apple Silicon 则走了另一条路，macOS 本身就是成熟的桌面操作系统，买回来开机就能用，不需要额外配置开发环境。
回到我们讨论的中小企业私有化部署场景，Mac Mini 的优势恰恰在于它普通到客户自己就能维护，不需要专职的 Linux 运维。当然，如果客户有技术团队、预算充足、对推理性能有更高要求，DGX Spark 是更强的选择。但对于大多数场景来说，Mac Mini 够用。
7.2、知识库是企业大模型应用的数据底座
知识库这个概念，从 23 年到 25 年讲了三年，听起来似乎有点过时了。各路自媒体上天天宣传的是复杂的 Agent、工作流编排、多模态，一个比一个高大上。但实际接触下来会发现，很多中小企业压根还没把知识库这件事整明白，甚至还没开始动起来。
知识库解决的是企业知识资产的数字化、结构化问题，这是所有上层大模型应用的前提。没有这个数据底座，工作流也好、智能体也好，都是空中楼阁。
而且知识库的价值不只是问答机器人那么简单。先在内部把售前答疑、售后支持、内部培训这些场景跑通，积累语料和反馈数据；然后可以往外延伸，做客户自助答疑、线索筛选、营销内容生成等等。从内部效率工具到对外业务赋能，知识库是一个可以持续扩展的基础设施。
7.3、不要被高举高打迷惑
过去一年聊过的几家中大型企业的大模型应用项目，对外号称已经投产，有成百上千个智能体。但问过内部人员才知道，日均 Token 消耗量上千万的使用场景，比例远不到三分之一。也就是大部分场景都在试水，大部分员工也是浅尝辄止，最后这套系统最大的价值都变成了给领导汇报和对外宣传的素材。
这不是说中大型企业的做法是错的，它们有自己的节奏和逻辑，适合更高举高打的打法。我和团队选择聚焦中小企业，更多是当前阶段经过试错之后的一种经营策略选择。一方面是商业回报上更 make sense。中小企业决策链路短，能直接接触公司一把手，对齐预期之后半个月内做完 POC，一个多月就能拿到第一笔款，然后小步快跑持续迭代。另一方面是能快速积累工程实战体感。每一个项目从需求调研、数据治理、模型调优到边缘部署，全链路走一遍，踩过的坑都是真实有效的。
像这篇文章讲的售前售后问答场景，还有之前分享过的售前报价 Agent，虽然不那么洋气，但都是围绕具体场景解决具体问题，确确实实能节省客户的人力、提高效率。回归常识，小步闭环，这是我目前相信的大模型应用落地最佳姿势之一。
从 26 年开始，我把精力更多放在可交付的项目合作上，不再提供纯咨询。经过过去一年的实践发现，项目能不能顺利交付，很大程度上取决于双方在一开始是否有基础的预期共识。所以现在项目合作和 POC 只对知识星球成员开放。星球里日常会分享各个行业、各个垂直场景的落地案例和工程细节，也有不少一线从业者在里面交流。加入之后对我的做事方式和能力边界会有个基本了解，沟通起来效率更高，交付质量也更有保障。
工具包已上传至知识星球《企业大模型应用从入门到落地》，欢迎加入获取。
（星球成员限时 1 元兑换视频课程）。
