一次千赞项目的 pr
无心插柳 柳成荫，只是测试一下使用，觉得它的项目缺少本地测试的前端页面，vibe了一个 就给提交了，没想到被 merge了
Read more
传统 SaaS 转向 AI 时代，我目前的一点理解：先把数据能力变成 Agent 可调用的基础设施
最近我一直在思考一个问题：传统 SaaS 到底应该怎么转向 AI？ 一开始很容易想到的方向是：给原来的系统加一个 AI 助手。 比如在页面右下角放一个聊天框，让用户可以问数据、生成报告、总结内容、解释指标。这个当然有价值，但我现在越来越觉得，这只是比较表层的一种转型。 真正的变化，可能不是“在 SaaS 里面加 AI”，而是 SaaS 本身的能力形态发生变化。 过去的 SaaS，核心是给人使用。 人登录系统，看页面、点按钮、筛选数据、导出报表、判断问题，然后再去做决策。数据库是给 Web 页面供数的，后端 API 是给前端页面服务的，整个产品的中心是“人如何操作软件”。 但 AI 时代，尤其是 Agent 逐渐发展之后，
对 Python 应用场景的一次重新思考：FastAPI、协程、线程、数据库与任务系统边界
最近在重新设计一个任务系统时，我顺便把自己对 Python，尤其是 CPython 应用场景的理解重新梳理了一遍。 这次讨论的背景是一个典型的异步任务服务： 上游提交任务 API 立即返回 task_id 后台 worker 慢慢执行 用户通过 task_id 查询任务状态 任务主要是 LLM 调用、图片下载、外部 HTTP 请求这类 I/O 型工作。 一开始关注的是队列、Redis、PostgreSQL、worker 并发控制这些问题。但聊到后面，其实更核心的问题变成了： Python 到底应该放在什么位置？ 哪些并发适合 Python？ 哪些并发不要硬塞给 Python？ FastAPI、协程、线程、数据库之间应该怎么分工？ 这篇文章就是这次思考的整理。 一、我不想抛弃 Python，
Go 和 Python 的并发模型对比：进程、线程、协程、并发和并行到底怎么理解？
最近我在写 worker 任务系统的时候，重新理解了一遍 Python 和 Go 的并发差异。 以前写 Python，多 worker 经常要考虑： 多进程怎么管理？ 日志会不会串？ 一个 worker 崩了怎么办？ 怎么吃满多核心？ 后来换成 Go，发现一个进程里开多个 goroutine worker 就很自然： go worker(1) go worker(2) go worker(3) go worker(4) 日志也好管，状态也好管，而且单进程还能利用多个 CPU 核心。 一开始很容易误会成： Python 不行，Go 行 但更准确的理解应该是： Python 和
Python 进程和 Go 进程的区别：为什么 Go 单进程多 worker 用起来更爽？
最近我在做 worker 任务系统的时候，突然意识到一个很关键的问题： 以前写 Python，多 worker 的时候经常要小心日志串、文件切割乱、时间不好管理。 但是换成 Go 以后，一个进程里开多个 goroutine worker，反而可以比较自然地写到同一个日志文件里。 一开始我以为这是“Python 和 Go 写日志能力不一样”，后来想明白了，核心不是日志本身，而是： Python 常见 worker 模型：多进程 Go 常见 worker 模型：单进程 + 多 goroutine 这背后其实是两个语言在并发模型上的巨大差异。 一、进程、线程、goroutine 先分清楚 先把几个概念捋一下。 进程：操作系统分配资源的单位 线程：CPU 调度执行的基本单位
陕公网安备61011302002223号