AI on lategege 的技术博客

AI 时代，数据必须掌握在自己手里：从一次照片“回收失败”说起

Mon, 23 Mar 2026 12:45:00 +0800

我有时候会突然冒出一种冲动：把这些年散落在各个平台的东西，收回来。

不是出于什么宏大叙事，也不是突然开始“隐私觉醒”。更像是一种本能——你开始意识到，时间会把很多东西冲散，而你手里能抓住的，只剩下那些你确实拥有的部分。

那天我想收回的是照片。

准确说，是原图。

我翻到很早以前的某个平台相册。里面存着一段非常完整的时间线：某年某月去过哪里、拍过什么傻东西、那时候喜欢什么样的滤镜，甚至连当时的审美偏好都能从构图里看出来。你很难用“素材”或“回忆”去概括它，它更像一个人的私人档案——不是为了给别人看，而是为了多年后你自己回看时，能把自己从时间里捞出来。

我当时的念头很简单：把原图下载下来，放进自己的硬盘里，顺便整理一下。

结果很快就发现一个尴尬的事实：很多照片早就不是“原图”了。

它们看起来还像照片，缩略图也能打开，发到群里也不丢人。但你一旦认真起来——想裁切、想放大、想打印、想在大屏上看细节——你就会发现那是一层薄薄的皮：分辨率上不去，细节糊成一团，边缘带着明显的压缩痕迹。

这不是什么阴谋论。

平台为了上传更快、加载更顺滑、节省存储成本，会对图片做“优化”。而这种优化往往是不可逆的。真正令人难受的不是“它被压缩了”，而是你意识到：

你当年以为自己做的是备份，实际上你做的是迁移——把唯一的一份原图，迁移进了一个你无法控制的系统里。

后来手机换了、硬盘丢了、电脑重装了，你再回头想找那份原始文件时，发现自己已经没有第二条路。平台里剩下的那份，就是世界上最后一份，而它已经被处理过。

你会在那一刻理解一种很具体的“丢失”：不是文件丢了，而是未来被你提前掐掉了。

原图之所以叫原图，是因为它是一切后续可能性的起点：你以后想重新修图、想做相册、想把当年某张照片裁成封面、想认真地打印出来送人……这些事情都建立在“你手里有母版”这个前提上。当母版没了，你仍然可以看，但你很难再用。

这件事放在十年前，最多算遗憾。

放在今天，它变成一种更现实的焦虑：因为 AI 时代，“调用历史”这件事变得前所未有地重要。

照片不再只是回忆，它还是你个人视觉历史的一部分——你的生活轨迹、审美偏好、拍摄习惯、你去过的地方、你什么时候开始喜欢某种风格。你当然可以说“这些我不想给 AI”，这完全合理；但关键在于：你至少应该拥有选择权。

你要选择“不给”，前提是它本来就在你手里，而不是早就被平台压缩成了你无法再利用的版本；你要选择“给”，也应该是你清楚地知道给了什么、在哪里用、还能不能撤回。

更要命的是，这不是照片独有的问题。

你把笔记写在某个平台里，平台的标签、双链、数据库把它组织得很好；可一旦你想离开，导出的往往只是一堆文本残片。你和 AI 的对话越积越多，里面藏着你的真实问题、你的工作流、你的思考路径；可一旦你换一个助手，那些“过程”常常带不走，或者带走也变得不可检索、不可复用。

它们共同指向同一个结论：

云不是问题，“只有云”才是问题。

平台可以是工具，但不能是归宿。

把数据掌握在自己手里，也不是反科技，更不是自虐式的自建服务器；它只是一个很朴素的底线：你至少要保证自己拥有一份可用的完整副本，保证格式足够开放，保证出了事能回到昨天。

下面我把这件事拆成更具体的三条原则和一套“最低成本实践”，你照着做就能明显降低未来的后悔概率。

1) “掌握在自己手里”到底是什么意思？

我现在尽量用三个词来定义它（都很务实，不玄学）：

可导出：不是“有导出按钮”，而是导出来以后仍然可用。
可迁移：换工具不等于重建人生；迁移应该像搬家，而不是重装修。
可恢复：出事能回到昨天（至少能回到上周）。

这三条里，最容易被忽略的是第一条：很多平台的“导出”只保证它完成了一个动作，并不保证你拿到的是一份可以继续使用的资产。

2) 为什么 AI 时代这件事更急？

因为 AI 正在把“个人数据”从“静态存档”变成“可被调用的能力”。

同一个模型，喂进去的东西不一样，出来的效果会完全不同：

你有完整的照片母版 + 时间线 → 它可以帮你做更靠谱的整理、归档、选片、回忆生成（甚至只是做一本像样的相册）。
你只有压缩过的预览图 → 很多后续能力会直接降级，甚至不可用。

类似的事情也发生在笔记和对话里：如果你把写过的东西、做过的决策、踩过的坑都留成“可检索、可迁移”的形态，那么你完全可以把 AI 当作一个更强的检索与重组引擎；反之，AI 再强也只是一个没有你历史的“通用工具”。

一句话总结：

模型会平权，差异化来自你能否调用自己的历史。

3) 最低成本的“照片主权”实践：从母版开始

我现在对照片的处理原则很简单：平台负责分享，我负责母版。

你不需要一步到位上 NAS、上自建相册、上复杂的目录规范。先从最低成本的三步做起：

3.1 保留“母版库”：原图只认一个归宿

给自己一个明确的母版归宿：

你的电脑/移动硬盘/家用 NAS 都可以
关键是：它必须是你可控的存储，而不是某个账号登录后的“可见性”

然后建立一个非常朴素的目录规则，例如：

Photos/2026/2026-03 上海/
Photos/2025/2025-10 旅行/

只要你能坚持“原图先回家”，之后怎么优化都来得及。

3.2 开启 3-2-1 备份：别让母版只有一份

最推荐、也最不容易出错的备份理念就是 3-2-1：

3 份副本
2 种不同介质（比如：硬盘 + 云盘）
1 份异地（哪怕是放在家人家里一块硬盘）

你可以很现实一点：

先做到“母版库 + 另一个硬盘定期备份”
习惯建立后，再补“异地”

重要的是把备份变成一种例行动作，而不是等丢了以后才开始研究方案。

3.3 平台当“分发层”：上传前就接受它会压缩

把平台定位成“分发层”以后，你对它就不会抱不切实际的期待：

它压缩很正常
它改规则很正常
它哪天不给你原图导出，也很正常

你不需要因此生气，你只需要保证：这些变化不会伤到你的母版库。

4) 顺手把笔记和 AI 对话也做成“可迁移资产”

既然写到这里，顺手说一下另外两类最容易“悄悄散架”的个人数据：

笔记：尽量以 Markdown/纯文本为底，附件独立保存；不要把“只有某个平台能理解的结构”当作唯一形态。
AI 对话：把高价值对话沉淀成可复用的产物（例如：项目 README/ADR、复盘文档、提示词模板、检查清单），不要只留在聊天窗口里。

它们的共性是：你真正想保留的不是某次输出，而是可复用的过程。

结语：我不反云，但我拒绝“只有云”

我现在越来越相信一件事：平台会变，产品会关，规则会改，但你的生活不会因此暂停。

所以我不反对把东西放在云上——云很好用，协作也方便。

我拒绝的是“只有云”：当你把唯一的一份母版交给平台时，你其实把未来的选择权也一并交出去了。

把数据掌握在自己手里，说到底不是对抗谁，而是给未来的自己留一条退路。

一套我常用的 AI 开发效率工作流：提示词模板、代码审阅、笔记沉淀

Sun, 22 Mar 2026 01:50:00 +0800

AI 工具真正的价值不是“偶尔帮你写一段代码”，而是把一些重复劳动变成稳定流程：

需求澄清更快
代码审阅更仔细
笔记沉淀更容易

这篇文章分享一套我自己日常会用的工作流，偏实操，拿来就能用。

1) 提示词别追求万能，追求可复用

我常用的提示词结构很固定：

目标：你要它做什么（输出是什么）
上下文：项目背景、约束、已有方案
标准：什么算“好”（验收条件/风格/边界）
格式：用什么格式输出（Markdown/JSON/表格）

示例（需求澄清）：

你是资深后端架构师。请把下面的需求拆成可实现的技术方案。输出：接口清单、数据模型、边界条件、风险点、里程碑。约束：必须兼容现有数据库，不允许停机迁移。

2) 代码生成：让 AI 写“骨架”，人写“关键点”

更靠谱的分工：

AI：生成脚手架、样板代码、单测框架、重复性 glue code
人：数据模型、核心逻辑、关键路径性能、最终接口设计

好处是你不会把“系统设计责任”外包给模型。

3) 代码审阅：用清单驱动，而不是让它随便看看

我会让 AI 按一个固定 checklist 看：

逻辑正确性（边界条件、空值、并发）
安全（注入、鉴权、泄漏）
可维护性（命名、抽象、重复）
性能（N+1、缓存、批量）
可观测性（日志、指标、trace）

然后要求输出：

高风险问题（必须修）
中风险建议（最好修）
可选优化（有空再做）

这样输出会稳定很多。

4) 笔记沉淀：把对话变成“可以检索的知识”

对话内容如果不落地，很快就丢。

我建议固定两个产物：

项目 README / ADR：决策与理由（为什么这么做）
博客/知识库条目：踩坑与解法（怎么做）

并且每篇笔记尽量包含：

现象（症状）
原因（根因）
解决方案（步骤/代码）
验证方法（怎么确认修好了）

这其实就是给未来的自己省时间。

5) 例行复盘：每周把“高频问题”固化成模板

最有收益的一步：

回看一周里反复出现的问题
把最常用的提示词/检查清单/脚本变成模板

久了之后，你会发现 AI 变成了你工具链的一部分，而不是一个随机的“灵感来源”。

结语

AI 工具不缺，缺的是流程。

当你把它们嵌进“可复用、可验收、可沉淀”的工作流里，收益会非常稳定。

Chatglm、Stable Diffusion webui反向代理配置

Thu, 04 May 2023 02:23:50 +0000

最近在研究AI模型部署，遇到了一些问题，其中一个就是开放外网访问，像Chatglm、Stable Diffusion的webui普遍采用了Gradio这个高度封装的AI WebUI服务。Gradio如果不修改，默认启动后只会监听127.0.0.1，也就是只能本机使用，而对于局域网其他机器来说，肯定是需要访问的，所以需要修改启动脚本，这个启动脚本在不同模型的WebUI中配置大同小异，本质上都是最后在下面的代码中加入了server_name=0.0.0.0

//最终启动都会调用如下函数
demo.queue().launch(inbrowser=True,server_name=0.0.0.0)

1、针对Chatglm，使用方式就是修改目录下面的web_demo.py，找到上面的代码增加server_name即可

2、针对Stable Diffusion webui 则可以通过命令参数传入，如果是linux用户，执行./webui.sh --server-name 0.0.0.0 即可

上面虽然打通了局域网访问，但是外网访问还需要配置一下，虽然可以通过gradio的share=True参数达到外网访问效果，但是这种效果的本质是内网穿透，是连接到gradio服务器去实现的。如果家里有公网ip，又不想通过别人的服务器来实现，那就需要配置一个反向代理。

反向代理一般就是nginx，像gradio这种服务，除了http服务外还有websocket服务，所以nginx需要配置两项，一项是默认的location / ，另一项是websocket的 location /queue

server {
 listen 你对外的端口号(ipv4) ssl;
 listen [::]:你对外的端口号(ipv6) ssl;
 server_name 你对外ip地址或者域名;
 ssl_certificate 你的证书链;
 ssl_certificate_key 你的私钥地址;
 location / {
 proxy_connect_timeout 60;
 proxy_read_timeout 60;
 proxy_send_timeout 60;
 proxy_intercept_errors off;
 proxy_http_version 1.1;
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass webui服务的地址:端口号;
}
location /queue {
 proxy_pass webui服务的地址:端口号;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection Upgrade;
}

}

为什么websocket要配置location /queue 呢，这是我通过浏览器请求的wss地址分析得出的，Gradio的wss都会走/queue这个路径，proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection Upgrade;可以理解为将https协议升级为wss协议。

通过上面的配置，我们就可以在外网愉快的访问家里部署的AI WEBUI了。