用 5 台 Mac mini 搭一套“睡觉也在干活”的 AI 系统（可一台起步）

你看到“月入 4.5 万美元”的故事，别急着热血。

真正值得抄的不是金额，是方法：用机器把重复沟通、重复解释、重复试错这堆破事打包丢掉。

那位大学生做的事，说白了就两点：

• 几台电脑长期在线，稳定跑本地 AI 和自动化任务
• 一份“规则文件”管住 AI 的嘴和手，让它按你的套路干活

你不一定要 5 台。一台 Mac mini 也能跑起来。多机器的意义是并行：你上课/上班时，它们在后台把产品、代码、文档、测试一起推进。

下面给你一套可落地的做法。照着搭，今天就能开始用。

你要搭的到底是什么：一个“多智能体工作间”

想象一个小工作间里有 5 个角色，每个只干自己那点事：

• 产品经理：把想法拆成任务，写清验收标准
• 架构师：选技术方案、目录结构、关键依赖
• 开发：写代码、补实现
• 测试：写用例、跑测试、找边界问题
• 文档：更新 README、接口说明、变更记录

它们不会互相抢话，靠一份规则文件对齐口径，再靠一个任务编排流程接力。

你获得的效果很直观：

• 早上打开电脑，看到“昨晚的提交 + 测试报告 + 待你拍板的问题”
• 不用每天花一小时对着 AI 重复解释“我们项目是啥、风格是啥、别乱改哪里”

听着就爽，对吧？😄

硬件怎么选：别被“必须很强”吓退

方案 A：一台 Mac mini 先跑通（推荐）

• Mac mini M2 / M2 Pro / M4 都行
• 内存尽量 16GB 起步，想更顺滑就 24GB/32GB
• 硬盘留足：模型文件 + 项目代码 + 日志，至少 512GB

优点：成本低、维护简单。

方案 B：多台 Mac mini 并行（你想抄故事就这么干）

把不同角色分给不同机器：

• 机器 1：产品与规划
• 机器 2：开发（主要写代码）
• 机器 3：测试（跑测试、静态扫描）
• 机器 4：文档与发布
• 机器 5：数据抓取/爬虫/监控

多台机器的核心价值：并行 + 隔离。测试跑挂了，不影响开发那台继续干活。

补一句现实问题：宿舍/出租屋用多台机器，电费和噪音要算进去。你可以接电表统计功耗，别月底被账单教育。

模型怎么跑：本地为主，云端兜底

你要的是“长期在线 + 成本可控”。组合拳通常是：

• 本地模型负责：代码改动、文档生成、一般问答、重复任务
• 云端模型负责：复杂推理、关键决策、疑难问题

本地部署：Ollama（简单到离谱）

Mac 上最省心的本地方案之一就是 Ollama。

安装完成后，你会得到一个本地模型服务。

你可以选模型：

• 追求代码能力：Qwen2.5-Coder 系列
• 追求通用：Qwen2.5 系列
• 机器内存一般：选 7B/14B 比较稳

你不需要一上来就追 32B/70B。跑得动、跑得稳更重要。

可视化与多会话：Open WebUI

Open WebUI 能让你像用网页版 ChatGPT 那样管理对话，还能配合本地 Ollama。

如果你要多角色多任务，有个界面管理会话非常省命。

关键中的关键：写一份“规则文件”，把 AI 关进笼子

故事里最值钱的点是“一个规则文件”。

没有它，你每天会遇到这些糟心事：

• AI 动不动重构全项目，改到你认不出来
• 写代码不按你的目录结构，今天一套明天一套
• 自作主张加依赖，搞出一堆你不想维护的东西

规则文件的目标就一句话：让 AI 像团队成员一样守规矩。

下面给你一个可直接复制的模板（按你的项目改几处就能用）。

文件名建议：AI_RULES.md 或 .cursorrules 或 CONTRIBUTING_AI.md（看你用的工具）

# AI 工作规则（必读）

## 角色
你是项目的“执行型工程师”。
不做拍脑袋的架构大改。
不做未经确认的产品决策。

## 输出风格
- 代码改动尽量小
- 优先补测试，其次写实现
- 每次提交说明：改了什么、为什么、怎么验证

## 禁区
- 不允许改动 /infra 目录
- 不允许更换技术栈
- 不允许新增重量级依赖（需要我确认）

## 项目约定
- 包管理：pnpm
- Node 版本：20
- 目录结构：
  - apps/web
  - packages/shared

## 工作流程
你每次接到任务，按这个顺序走：
1) 复述需求 + 写验收标准（不超过 8 条）
2) 提出 2 个实现方案：保守方案、激进方案（我选）
3) 我确认后再写代码
4) 写完跑测试，给出结果

这份东西看起来朴素，威力很大。

你把它当成“团队宪法”。AI 每次开工前都要读一遍，减少胡来。

多智能体怎么编排：给你两套常用玩法

玩法 1：同一台机器，多会话分角色（最快上手）

你在一个工具里创建 5 个对话：

• PM：只写任务拆解和验收标准
• ARCH：只出技术方案和目录建议
• DEV：只写代码和提交信息
• QA：只写测试与边界用例
• DOC：只写文档

每次需求进来，你把 PM 的输出复制给 ARCH，再复制给 DEV……接力跑。

优点：零部署复杂度。 缺点：手动搬运信息有点烦。

玩法 2：多台机器，一人一个角色（故事同款）

每台 Mac mini 跑一个固定角色：

• 固定提示词 + 固定规则文件
• 固定工作目录
• 固定任务队列（比如一个共享的 tasks/ 文件夹）

你做的事情就变成：

• 往 tasks/2026-xx-xx-feature-xxx.md 丢需求
• 早上来看 output/ 里的产物：PR、测试报告、文档更新

优点：并行，睡觉也在跑。 缺点：你得处理网络、共享目录、权限、日志、故障恢复。

给你一个“今晚就能跑”的任务模板

在项目里建一个 tasks/ 目录，丢一个任务文件：

tasks/feature-login-rate-limit.md

# 需求：登录接口限流

## 背景
线上有人在撞库。需要限制同一 IP 的登录请求。

## 验收标准
- 同一 IP 1 分钟最多 10 次登录尝试
- 超出后返回 429
- 日志记录：ip、时间、用户名（脱敏）
- 有单元测试覆盖

## 禁区
- 不改动现有 auth 流程
- 不引入 redis（先用内存方案）

## 备注
框架：NestJS

你把这个任务丢给 PM/ARCH/DEV/QA/DOC 接力。

你会明显感觉到：任务写清楚了，AI 的“乱发挥”会少很多。

避坑清单：踩一次就想砸电脑的那种

• 规则文件不更新：项目变了，规则不变，AI 会按旧地图乱走。
• 一次给太大任务：让它“做一个完整产品”，结果就是写一堆无法上线的半成品。任务拆到 1～3 小时能完成的粒度，效率才高。
• 没验收标准：你不写清楚“什么叫完成”，AI 就会用它自己的标准糊弄你。
• 不留日志：跑了一夜，第二天你不知道它干了啥，只能抓瞎。把关键输出都落到文件里。
• 让 AI 直接改主分支：真会出事。走 PR，至少你还能一键回滚。
• 全靠本地模型硬扛：遇到疑难杂症别死磕。关键节点用云端强模型做评审，省掉一堆无效尝试。

你该怎么把它变成“真实收益”

别一上来就想着做“宏大项目”。

更容易赚钱的路线是：

• 选一个你熟悉的垂直场景（比如：简历优化、短视频脚本、跨境商品标题、课程讲义）
• 用这套系统把“交付流程”自动化
• 把交付做成产品：模板 + SaaS + 订阅

你会发现，AI 真正帮你的不是“灵感”，是持续产出。

你在上课、开会、通勤时，它在跑任务。 你睡觉时，它在补测试、写文档、修 Bug。

这才是故事里那碗泡面的真正含义：把人从琐碎里解放出来，把时间换回去。

一句话行动建议

今晚就做两件事：

• 给你的项目写一份 AI_RULES.md
• 拿一个小需求，用“PM→ARCH→DEV→QA→DOC”跑完闭环

跑通一次，你就知道这套东西值不值。😏