在实际个人计算场景里，“反 AI 电脑”（Anti AI Computer）并不是一台没有操作系统的铁盒子，也不是一句玩笑话。它最早出现在 Hacker News 的 Show HN 栏目中，作者把一台电脑刻意设计成不集成 AI 助手、不上报行为、不默认依赖云端大模型的形态，用来对抗今天几乎无处不在的“AI 化默认值”。这个思路后来被很多开发者拿去改造自己的写作机、开发机和家用电脑。
对开发者来说，反 AI 电脑并不是拒绝技术进步，而是重新划定边界：哪些计算必须由本地程序确定完成，哪些数据可以离开机箱，哪些 AI 能力可以接受，哪些必须从网络层拦住。这篇实践指南会沿着硬件选型、操作系统、网络出站控制、软件栈替换、最小验证和故障排查这条主线，完整走一遍搭建“Anti AI Computer”的过程。
适合对隐私敏感的用户、想摆脱 Copilot 默认行为的开发者、做本地优先工具的人，以及关注 AI 工程实践但不想被云端厂商锁定的人。读完可以按文章顺序搭出一台可验证、可审计、能日常使用的反 AI 电脑。
1. 先理解“反 AI 电脑”到底在反什么
1.1 反的是“默认被接管”，不是“不用程序”
需要先澄清：反 AI 电脑的核心立场不是拒绝所有智能算法，而是拒绝把 AI 助手、云端大模型、行为采集当成电脑的默认状态。
今天从 Windows 的 Copilot、macOS 的 Siri，到浏览器里的 AI 摘要、代码编辑器里的补全插件，共同特征是默认开启、默认联网、默认把输入内容发给厂商服务器。用户往往没有在知情的情况下做出选择，甚至关掉这些功能需要翻好几层设置。
“反 AI 电脑”的做法是把默认值反过来：所有功能默认在本地完成，所有联网行为默认被审计，所有需要 AI 的场景单独开启，而不是开机就有。
举个例子。普通电脑第一次开机后，系统会引导用户登录厂商账号、开启云同步、注册 AI 助手；反 AI 电脑第一次开机后，应该看到的是一条终端提示符，或者一个不包含任何云服务的桌面环境。这里不是要剥夺用户使用 AI 的权利，而是要让“使用 AI”成为一次明确的决定，而不是出厂设置。
1.2 三个核心设计原则：本地、确定、可审计
反 AI 电脑的配置决策可以归结为三条原则。
第一是本地。数据默认不出机箱。输入法不上云，浏览器不同步，笔记存纯文本，文件索引在本地完成。任何需要把文本、代码、屏幕内容送到远端的行为都要单独解释理由。
第二是确定。同一份输入得到同一份输出。代码编译、文档渲染、脚本执行都应该可复现，不应因为远端模型版本变化而改变结果。确定性是工程调试的基础，也是“电脑听你的”最直接的体现。
第三是可审计。任何出网请求都能被看到、被解释、被关闭。系统里可以没有“信任 AI 厂商”这个默认设定，但必须有“我允许这台电脑连接谁”的明确记录。
这三条原则是后面所有配置的检验标准。判断一台电脑是否算反 AI，不是看它有没有装 AI 软件，而是看默认流程里数据会不会外流、行为是否可以复现、策略是否经过审计。
1.3 与“普通电脑”和“完全禁用 AI”的差别
为了避免概念混淆，用表格对比三种电脑形态。
| 维度 | 普通办公电脑 | 反 AI 电脑 | 完全禁用 AI 的电脑 |
|---|---|---|---|
| 系统 AI 助手 | 默认开启 | 不安装或彻底关闭 | 不安装 |
| 浏览器同步 | 默认开启 | 关闭或自建本地同步 | 关闭 |
| 编辑器补全 | 默认接 Copilot 类插件 | 只使用本地规则和 linter | 不使用 |
| 出站网络 | 默认允许遥测 | 白名单加审计 | 尽量断开 |
| 可解释性 | 低 | 高 | 高 |
| 日常效率 | 依赖云服务 | 依赖本地工具链 | 依赖本地工具链 |
从表格可以看出，反 AI 电脑和“完全禁用 AI”的电脑差别并不大，区别在于前者允许在明确授权下单独开启本地模型能力，而后者干脆不讨论 AI 能力。Show HN 上的 “My Anti AI Computer” 更接近前者：把控制权和知情权放在第一位，而不是单纯把 AI 功能全部删掉。
2. 硬件与系统选型：从源头减少 AI 预装
2.1 选硬件时要关注的四个层面
真正决定一台电脑“AI 化程度”的，不是 CPU 里有没有 NPU，而是三层绑定：固件、系统、云服务。
第一层是固件。主板和 BIOS 里的更新模块、远程管理、遥测功能会直接影响后续系统行为。反 AI 电脑建议选择有良好 Linux 支持、固件更新路径简单的设备，不追求最新功能，而要确认这台机器不会因为某个硬件而强制安装厂商管理软件。
第二层是硬件驱动。显卡、声卡、无线网卡如果只有闭源驱动，并且必须联网安装配套软件，就要特别警惕。尤其是一些 AI PC 的 NPU 驱动，厂商往往要求配套应用才能工作。对反 AI 电脑来说，取舍很直接：用不上就不装。
第三层是系统预装。预装 Windows 的设备自带大量 OEM 应用和云端服务，品牌机和游戏本尤其明显。购买使用 Linux 作为默认系统的设备，或者选择不带操作系统的准系统，可以减少后续清理成本。
第四层是网络环境。反 AI 电脑应该接在自己可控的路由器后面，而不是依赖厂商提供的云网关。这样后面配置 hosts 和防火墙规则时，整条链路才是清晰的。
这里有个常见误区：认为“AI PC 芯片等于 AI 电脑”。实际上 NPU 只是一个计算单元，反 AI 电脑完全可以不启用它。反过来，一台没有 NPU 的老机器，如果安装了 Copilot、OneDrive 和浏览器 AI 摘要，一样是“AI 化电脑”。关键在于软件和网络，不在芯片。
2.2 操作系统：为什么优先选择 Linux
如果目标是反 AI，Linux 是目前维护成本最低的起点。
Windows 的问题不是不能用，而是默认值太不利：Copilot 与系统搜索集成，Recall 类功能会周期性保存屏幕内容，遥测默认开启。虽然可以通过组策略和注册表关闭一部分，但每次功能更新都有重新开启的可能，长期维护成本高。
macOS 同样带有 Siri、iCloud 和本地推理等默认项，而且硬件绑定让用户很难替换系统层行为。对于“想保留 Mac 硬件但不想被云服务绑定”的用户，只能依赖手动关闭，无法做到系统级可控。
Linux 发行版默认没有 Copilot，没有强制云账号，没有系统级屏幕截屏索引。它的包管理器能提供透明的依赖关系，防火墙规则直接可读，进程和网络行为都可以审计。选择 Debian、Fedora 或 Arch 的 minimal 安装，就能得到一个几乎不含 AI 组件的底座。
对于必须在 Windows 下运行的软件，建议把 Windows 放进虚拟机，并为虚拟机单独设置网络策略。这样既能保留必要的兼容性，也不会污染反 AI 主机的默认状态。
2.3 安装后的第一步：关闭系统级 AI 组件和遥测
如果因为驱动或软件原因必须使用 Windows，至少先完成下面这些动作。具体菜单位置以实际系统版本为准：
| 项目 | 操作 | 说明 |
|---|---|---|
| 关闭 Copilot | 在隐私和安全性设置中关闭；通过组策略关闭系统级入口 | 防止搜索栏和桌面挂件拉起 AI 面板 |
| 关闭 Recall 快照 | 在隐私和安全性中暂停保存屏幕快照 | 避免屏幕内容周期性写入并可能同步 |
| 降低诊断数据 | 诊断数据改为“必需”级别 | 减少行为上报频率 |
| 使用本地账号 | 不要登录微软账号 | 避免跨设备同步和训练数据关联 |
| 移除预装 AI 应用 | 使用 PowerShell 卸载 Copilot 相关包 | 从入口移除 AI 组件 |
对应的 PowerShell 卸载命令如下：
Get-AppxPackage *Copilot* | Remove-AppxPackage Get-AppxPackage *WindowsAI* | Remove-AppxPackage注意：不要直接照搬网上的“一键禁用”脚本而不看内容。很多脚本会同时修改注册表、计划任务和服务，可能破坏系统更新。建议一条条执行，记录每一步修改，并把命令纳入版本管理。
Linux 侧要简单得多。安装基本系统后，不要安装厂商提供的语音助手、云通讯录和同步软件。用systemctl list-units --type=service检查开启的服务，把不认识的网络服务逐个禁用：
systemctl list-units --type=service --state=running sudo systemctl disable 某个不认识的网络服务3. 网络层控制：让电脑默认不把数据送出机箱
3.1 先盘点电脑会主动连接哪些目标
反 AI 电脑的网络策略不是“先全放开，有问题再关”，而是“默认拒绝，白名单放行”。动手配置之前，先做一次出站盘点。
| 目标类型 | 典型目标 | 常见触发时机 | 反 AI 处理 |
|---|---|---|---|
| 系统遥测 | Windows Telemetry、Linux Apport | 开机、更新后 | 关闭或屏蔽 |
| AI 助手 | Copilot、Siri、云端 LLM API | 快捷键、搜索栏、编辑器 | 不安装 |
| 浏览器同步 | 浏览器账号同步 | 登录、标签页变化 | 关闭同步 |
| 崩溃上报 | Crash Reporter | 程序崩溃 | 关闭 |
| 更新服务 | 系统更新、包管理器源 | 定时任务 | 保留白名单 |
| AI 开发插件 | AI 补全类插件 | 打开编辑器 | 隔离或删除 |
这里有一个判断标准：如果某个程序连接的目标域名无法解释、无法从官方文档查到、并且涉及私有数据入口，就应该先断网再升级，而不是先信任再排查。
3.2 用 hosts 文件做第一道静态屏蔽
最简单、可读性最高的控制器是/etc/hosts。Windows 下对应路径是C:\Windows\System32\drivers\etc\hosts。把已知 AI 服务的域名指向本机地址，让解析直接失败：
127.0.0.1 copilot.microsoft.com 127.0.0.1 login.microsoftonline.com 127.0.0.1 api.openai.com 127.0.0.1 app.cloud-ai-example.com ::1 copilot.microsoft.com ::1 api.openai.com但一定要理解 hosts 的边界：
- 它只拦截 DNS 名称解析，不拦截 IP 直连。
- 对使用 DoH（DNS over HTTPS）的浏览器可能无效，因为浏览器可以不读取系统 hosts。
- 在 IPv6 网络下，只写
127.0.0.1不够，需要同时写::1。 - AI 服务的域名经常变化，维护成本高。
所以 hosts 适合做“第一道明确提示”，不适合做“最后一道防线”。
3.3 用 nftables 做默认拒绝的出站规则
在 Linux 上，比 hosts 可靠的是状态防火墙 nftables。它工作在 IP 层，按目的地址、端口和进程标记做决策，不依赖 DNS。
先启用网络过滤服务：
sudo apt install nftables sudo systemctl enable nftables修改/etc/nftables.conf，加入一个针对 AI 目标地址的出站拦截集合：
table inet anti_ai { set ai_targets { type ipv4_addr elements = { 203.0.113.10, 198.51.100.20 } } chain output { type filter hook output priority 0; policy accept; ip daddr @ai_targets drop } }配置里的203.0.113.10和198.51.100.20只是示例地址，实际部署时要通过域名解析得到的真实 IP 更新集合。因为 AI 服务的 IP 池经常变化，更稳妥的做法是允许自己真正需要的服务，其他全部拒绝。
生产环境推荐白名单模式：只放行系统更新源、包管理服务器和少量必要 API，其余出站全部 drop。但这种配置会显著增加日常使用成本，适合专用工作机，不适合第一台反 AI 实验机。
注意：屏蔽出站目标保护的是本机隐私。它只涉及本机自身的数据控制策略，不涉及任何外部链路改造。反 AI 电脑关心的是这台机器能不能把数据留下。
3.4 浏览器层加固：同步、摘要、插件三件事
浏览器是反 AI 电脑上最容易泄漏数据的地方。常见泄漏路径有三种：
- 账号同步。浏览器登录后，历史记录、密码、扩展数据进入厂商账户。
- AI 摘要。地址栏、右键菜单、PDF 阅读器里的 AI 功能会把当前页面内容发到云端。
- 插件。某些 AI 助手扩展拥有读取全部页面内容的权限。
对应的加固顺序如下：
- 退出浏览器账号同步。密码用
pass或 KeePassXC 管理，书签用本地文件加版本管理。 - 关闭浏览器内置 AI 入口。Edge 关闭 Copilot 侧栏，Chrome 关闭 AI 实验开关。
- 插件最小化。只保留开源、权限明确的扩展，不要安装来源不明的 AI 助手。
- 对“Computer Use”类型的 AI 智能体保持零容忍。任何允许外部智能体操作浏览器的方案，都不应该出现在反 AI 电脑上。
4. 软件栈替换：把“AI 助手优先”改成“本地工具优先”
4.1 高频工具的替换清单
反 AI 电脑不是“少装软件”，而是“每个软件都必须能解释自己在做什么”。下面是常见高频场景的替换方案。
| 场景 | 默认 AI 化方案 | 反 AI 替代方案 |
|---|---|---|
| 写作 | Copilot、云文档 AI | Markdown 加本地拼写检查 |
| 笔记 | 云笔记加 AI 助理 | 纯文本加 git 本地仓库 |
| 搜索 | 搜索引擎 AI 摘要 | RSS 加本地全文检索 recoll |
| 编程 | Copilot、AI 补全插件 | 文档、linter、测试 |
| 翻译 | 浏览器 AI 翻译 | 本地词典加可选翻译 API 白名单 |
| 日程 | 云端助理 | 本地日历文件加 cron 提醒 |
| 邮件 | 云端 AI 摘要 | 本地邮件客户端加规则过滤 |
这张表不是否定工具效率，而是在“效率”和“可审计”之间重新选择优先级。刚切换时，最明显的损失是编辑器里没有自动补全，最明显的收益是不用再担心代码被自动送到第三方。
4.2 搜索和阅读：恢复“人找信息”而不是“信息找 AI”
普通电脑的使用习惯是：遇到问题，打开浏览器，输入问题，点 AI 摘要。反 AI 电脑的对应习惯是：遇到问题，先查本地文档和man，再查书签收藏，最后才联网搜索原文。
阅读侧建议启用 RSS 聚合，把信任的网站订阅到本地阅读器。搜索引擎只用于找原文，不要点击 AI 总结类卡片。
关于编程场景，有一点很重要：反 AI 电脑并不阻止你学习 AI 工程实践，而是要求你先理解正在运行的工具。你可以在这台电脑上写 AI 应用客户端代码，但所有请求都应该指向明确配置的 API 白名单端点，并且有日志记录。这本身就是一种更严谨的 AI 应用开发习惯。
4.3 如果一定要用大模型，边界在哪里
“反 AI 电脑”和“完全不用大模型”之间不是非黑即白。常见折中方案是只运行本地模型，例如通过 Ollama 部署小型开源模型，并配合严格网络配置，确保推理过程中没有数据出网。
安装 Ollama 后，需要手动确认服务不会自动访问外部模型仓库：
sudo systemctl edit ollama.service在 override 文件里设置：
[Service] Environment="OLLAMA_HOST=127.0.0.1"然后限制服务网络。即使是实验环境，也要确认模型文件来自官方仓库，服务只监听127.0.0.1，不暴露到局域网或公网。
严格派的做法是不安装任何推理运行时。这主要是取舍问题：当你不把“必须有 AI”作为预设目标时，直接不装才是最省心的。反 AI 电脑的价值恰恰在于，它允许你自由选择这个取舍，而不是被厂商默认值替你做决定。
5. 用最小案例跑通一个反 AI 电脑验证闭环
5.1 最小环境建议
用一台安装 Debian 或 Fedora stable minimal 的机器作为验证机。安装包只选基础工具：
sudo apt install vim git curl wget rsync ripgrep tcpdump nftables aspell pandoc不安装任何云客户端、同步盘、语音助手和浏览器 AI 插件。浏览器使用 Firefox，关闭同步并安装开源拦截扩展。这一套就是反 AI 电脑的最小闭环底子。
5.2 验证出站行为：开机后看五条命令
安装完成后，不要急着配置大量屏蔽规则，先用命令观察电脑到底在连什么。
第一条，查看所有外部 TCP 连接：
ss -tup第二条，查看本机监听的端口：
ss -lunp第三条，查看正在运行的系统服务：
systemctl list-units --type=service --state=running第四条，抓取任意网卡上的外发 443 连接：
sudo tcpdump -i any "tcp port 443" -n第五条，查看最近的 DNS 解析记录：
sudo journalctl -u systemd-resolved --since "1 hour ago" | grep "Query"正常结果应该是一屏以内、目标可解释。如果看到频繁连向不在规则里的 AI 域名，说明还有组件没有被清理。
5.3 一条不经过 AI 的文章写作流程
验证不只是看网络，还要跑一遍真实工作负载。以写一篇文章为例：
- 用
vim创建 Markdown 文件。 - 用
aspell做拼写检查。 - 用
git管理版本。 - 用
pandoc导出 HTML 或 PDF。 - 用
rsync备份到本地磁盘。
全程没有 AI 补全、没有云端同步、没有自动摘要。输出结果稳定可复现。记账场景可以用纯文本加ledger或hledger结算，数据同样保存在本地。
5.4 验证结果怎么判断
反 AI 电脑是否成立，可以用下面这张检查清单逐项确认：
| 检查项 | 预期结果 |
|---|---|
| 开机 5 分钟内是否有无法解释的出站连接 | 没有，或全部在白名单 |
| 编辑器、浏览器是否登录了厂商账号 | 否 |
| hosts 和 nftables 规则是否随系统启动生效 | 是 |
| 关闭自研工具后，是否还有进程频繁访问 443 端口 | 否 |
| 进行一次写作或编程流程，结果是否可复现 | 是 |
| 日志是否记录了所有出站行为 | 是 |
6. 常见问题排查：为什么“明明关了 AI 还是被 AI 化”
6.1 现象：系统更新后又出现 AI 组件
现象：Windows 功能更新后，Copilot 或类似组件又被装回来。
原因：功能更新可能重置部分系统组件的启用状态，OEM 预装包也可能通过更新任务重新安装。
检查方式：查看系统更新历史，对比更新前后的已安装应用列表。
处理方案：把关闭动作写入可重复执行的脚本，不要依赖系统设置面板“点一次就完事”。在 Linux 上，对应做法是清理 OEM 仓库和自动安装任务的依赖。
6.2 现象：hosts 屏蔽不生效
现象：已经往/etc/hosts写入 AI 域名，但浏览器仍然能打开对应的 AI 页面。
原因：浏览器使用 DoH 绕过了系统 DNS，或者目标服务通过固定 IP 直连，也可能是 IPv6 地址没有被屏蔽。
检查方式：打开浏览器设置，查看 DNS 是否被设置为“安全 DNS”；在终端执行dig +short确认域名当前解析结果。
处理方案：把浏览器安全 DNS 改为“使用系统设置”，或者改用 nftables 按 IP 拦截。不要只依赖单个 hosts 条目。
6.3 现象：某些软件不联网就拒绝运行
现象：关闭网络后，输入法、同步盘或开发工具直接报错退出。
原因：软件把许可证校验、遥测上报或在线配置作为启动前置条件，默认没有开启本地运行模式。
检查方式：查看程序运行日志，确认报错是缺少许可证还是缺少网络。
处理方案：优先替换为支持本地模式的替代软件。对于必须联网的开发工具，把它放进独立的虚拟机或容器，在防火墙里只放行最小域名。不要为了使用某个软件而开放整个出站规则。
6.4 现象：网站出现“系统检测到异常流量”提示
现象：访问某些站点时，页面显示 “We're sorry... but your computer or network may be sending automated queries” 或类似验证页。
原因：这通常是网站侧的风控模块根据出口 IP、浏览器指纹和请求频率做出的判断，不一定与反 AI 配置直接相关。使用共享出口 IP、启用大量拦截扩展、请求频率异常都可能触发。
检查方式：先确认是否同一网络下所有设备都出现该提示，再检查是否有脚本在后台高频请求。
处理方案：暂停来源不明的浏览器扩展，降低请求频率，等待风控解除。如果是公司或学校网络环境，联系管理员确认出口 IP 是否被标记。不要尝试通过修改请求特征来规避验证，正确做法是恢复正常浏览器行为并走正常访问流程。
6.5 现象：开发工具插件偷偷上报
现象：在反 AI 电脑上安装了某个带 AI 补全的编码插件，防火墙日志显示它在非工作时段访问未知域名。
原因：很多 AI 编程插件把“代码补全”和“遥测上报”绑定在一起，用户无法只开启补全、关闭上报。
检查方式：用tcpdump或防火墙日志确认目标域名，再对照插件官方文档确认开关位置。
处理方案：把这个插件视为需要单独隔离的组件；或者删除插件，改用本地 linters 和测试体系。处理客户数据或生产代码的机器，隔离优先于便利。
7. 反 AI 电脑的工程实践与扩展方向
7.1 学习环境、工作环境、生产环境要分开
不要把反 AI 电脑当成一套一成不变的配置。在三类环境里，策略强度完全不同。
| 环境 | 建议策略 | 核心目标 |
|---|---|---|
| 学习实验机 | hosts 加简单规则，保留搜索 | 建立概念和习惯 |
| 开发工作机 | 白名单出站，隔离 AI 插件 | 保护源代码 |
| 生产或客户数据机 | 默认拒绝，物理隔离，日志审计 | 保护数据 |
如果你正在从事 AI 工程实践或 AI 模型部署相关的工作，反 AI 电脑不会成为阻碍。它完全可以和开发任务共存：一台反 AI 主机承载日常写作和代码管理，另一台隔离的容器或虚拟机承载模型推理实验。这样既能掌握 AI 技术，也保住了个人数据的控制权。
7.2 可复用的新机器启用检查清单
每次在一台新电脑上启用反 AI 策略时，按下面的顺序执行：
- 安装 minimal 系统，不登录任何厂商账号。
- 关闭遥测、系统 AI 助手、设备级屏幕截屏功能。
- 配置 hosts 和防火墙出站规则，默认拒绝未知目标。
- 浏览器退出同步
