跳转到内容

Blog

最近一段时间太累了......

这是一篇记录3月份到四月中旬下旬的经历感受。

这段时间的经历和感受主要是公益站和注册机。这些日子大家都在薅奥特曼的羊毛, 我还寻思着这么多都公益站的账号都是哪里来的。于是在机缘巧合下寻找到了一个能用的注册机。 从部署new api 到 CPA 再到注册机,既是开始也是噩梦降临。

这段时间总是会有第三方中转站的商家把一些过时的漏洞爆出来掀桌子,导致很多人都来薅羊毛,薅的人多了渠道就会不稳定, 这样一来,没有掌握渠道的商家就会被迫去找新的渠道,或者自己去找漏洞。于是就会有不同的渠道,例如 代充、注册机等。

这段时间在L站,很多大佬都在薅羊毛,薅来的羊毛都用在用一张,让更多人认识到了AI模型。特别是御三家,这三个模型也是公认的最强模型。

注册机可以说是利用bug来批量注册账号,用来薅free账号的额度,最开始我也就只注册一些账号,几十个差不多就够用了。但是那些滥用的人一次性注册 几万甚至几十万。这时候我就已经知道了,这个渠道最后会被封掉。大家会变成奥特曼的免费质检机器和测试员。最开始的渠道可以存活很久,几周,一个月 我最早的账号存活了一个多月,最短存活的账号只有几个小时。注册机也是,最开始的验证没有多少,后续注册账号越来越严格,风控也越敏感。最后还出现了连坐 机制和特征识别。只会封的月来越多。一开始一周或者好几天才会更新一次,到后面,一天更新一次,注册机一直都在改的路上…

公益站不能说他们的做法是对的,也不能说是错的。在某种意义上还是说给奥特曼做宣传了。大家也都知道,免费的也就是图一乐,它并不稳定,速度也不快 。 安全性也难以保证。所以,公益站的尽头是付费

在任何中转站或者模型的chat页面中,需要时刻保持数据脱敏。在很多中转站中,都存在着数据泄漏的风险,后台是可以直接保存上下文日志的。 甚至在这些中转站中出现了非常恶心且没有职业道德的行为,直接把用户的上下文数据拿去卖钱。

这段时间虽然很累,但是也有收获。压力很大,但是也动力了我去学习更多的知识。 也希望大家分享在使用这些中转站或者模型的时候,能够提高安全意识,保护好自己的数据.

全程 Vibe Coding 做了一个股票分析系统,我的一些技巧

最近全程 Vibe Coding 了一个股票分析系统。

第一版大概用了 15 个小时。

比较有意思的是,这 15 个小时里,大部分实现都不是我一行一行写出来的,而是 Codex 按照我给的计划自己往前推进。

我做的更多是给方向、补充约束、看结果、提调整意见。

这次体验让我对 Vibe Coding 又有了一些新的感受。

以前说 AI 写代码快,更多是在说“它能帮我补代码、修 bug、写页面”。

但这一次,我更明显地感觉到:如果前置计划足够清楚,Codex 真的可以像一个执行力很强的工程协作者,把一个项目从 0 推到第一版可用。

当然,这里说的是股票分析系统的工程实现。

它不是投资建议系统,也不代表生成出来的分析结果就可以直接用于决策。

我关心的重点,是这次 Vibe Coding 的工程过程。

很多人用 AI 做项目,第一句话可能是:

帮我做一个股票分析系统。

这句话当然可以开始,但它太空了。

AI 会做,但它只能根据自己的理解去猜。

它会猜页面长什么样,猜后端接口怎么设计,猜数据怎么组织,猜你想要哪些分析指标,猜要不要登录,猜要不要缓存,猜要不要图表。

猜得多了,项目就容易偏。

这次我没有让 Codex 猜。

我先给了一个非常详细的计划方案。

里面包括系统目标、技术栈、模块边界、页面结构、数据流、接口设计、核心功能、优先级、实现步骤、验收标准。

不是一句“做个系统”。

而是告诉它:

  • 这个系统先解决什么问题
  • 第一版做到什么程度
  • 哪些功能必须有
  • 哪些功能可以后面再补
  • 前端有哪些页面
  • 后端有哪些接口
  • 数据怎么流转
  • 什么情况下算跑通

这一步非常关键。

因为 AI 的执行力很强,但它需要一个明确的方向。

方向越模糊,它越容易“看起来很努力”,但做出来不是你想要的东西。

把 AI 当执行团队,而不是许愿机

Section titled “把 AI 当执行团队,而不是许愿机”

这次我最大的体会是:Vibe Coding 不是许愿。

不是我说一句“我要股票分析系统”,然后等它变出一个完整产品。

更好的心态是,把 Codex 当成一个执行团队。

我负责产品判断和架构方案。

它负责大量实现、联调、修复和补齐细节。

这两件事不能混在一起。

如果我把方向也完全交给 AI,它可能会做得很快,但最后会越来越像“它理解中的产品”。

如果我只把它当自动补全,那又浪费了它完整读项目、改项目、跑命令、修错误的能力。

比较舒服的方式,是把目标和边界给清楚,然后让它充分执行。

就像你带一个工程同事做项目。

你不会只说“随便做个股票系统”。

你也不会每一行代码都盯着他写。

你会说清楚目标、约束、优先级和验收标准,然后让他推进。

Codex 也是这样。

我现在越来越觉得,给 AI 的计划不能只是“想法列表”。

想法列表对人有用,但对 AI 来说还不够。

它更需要任务链。

比如不要只写:

做股票列表、股票详情、分析报告。

而是写成:

  1. 先搭建项目结构,确认前后端能启动。
  2. 再实现股票基础数据模型和接口。
  3. 再做股票列表页面。
  4. 再做股票详情页。
  5. 再接入分析指标。
  6. 再补图表展示。
  7. 最后跑构建,修复类型和样式问题。

这样 Codex 就知道先后顺序。

它不会一上来就纠结一个复杂图表,也不会在后端模型没定的时候先写一堆页面。

任务顺序越清楚,它越能自主推进。

这次第一版能比较顺地跑下来,很大一部分原因就是计划里已经把路径铺好了。

AI 不是不知道怎么做。

它最怕的是不知道先做什么,做到哪里停,什么叫完成。

股票分析系统很容易一开始就想做复杂。

各种指标、K 线、财务数据、新闻情绪、行业对比、AI 解读、风险提示。

这些都可以做。

但第一版不能全塞进去。

我这次的策略是先跑通主链路。

先有股票列表。

再有详情页。

再有基础分析。

再有图表和展示。

先让用户能点进去、看得到数据、读得到分析结果。

第一版最重要的不是完美,而是闭环。

闭环跑通以后,再优化体验、样式、指标和数据质量。

这对 Vibe Coding 尤其重要。

因为 AI 很擅长在已有结构上继续补东西。

但如果一开始结构就混乱,它补得越快,后面整理成本越高。

所以我更愿意先让它完成一个清晰的小闭环,再逐步加功能。

这次我没有只让 Codex 写代码。

我让它自己读项目、改文件、跑构建、看报错、继续修。

这是 Vibe Coding 和普通聊天式写代码很不一样的地方。

以前用 AI,很多时候是它给一段代码,我复制过去,然后自己跑。

报错了,再贴错误回来。

这个过程其实很割裂。

而 Codex 可以在项目里直接工作,它能看到文件结构,也能运行命令。

所以我更倾向于让它完成一个闭环:

  • 先理解项目
  • 再修改代码
  • 再运行检查
  • 再根据错误修复
  • 再继续验证

我只在关键节点做判断。

比如它修复方向不对,我再介入。

比如它做得太复杂,我让它收回来。

比如页面气质不对,我重新描述目标。

其他重复的调试工作,就交给它自己处理。

这会省很多精力。

Vibe Coding 里,人最重要的工作之一是验收。

不是 AI 写完就结束了。

尤其是股票分析系统这种项目,表面看起来能跑,不代表真的对。

我会检查几个东西:

  • 页面是不是能正常打开
  • 列表和详情是不是能串起来
  • 接口返回结构是不是稳定
  • 空数据和异常状态有没有处理
  • 构建是否通过
  • 图表是否遮挡
  • 分析文案是否过度自信
  • 有没有把展示工具写成投资建议

最后这个点很重要。

股票分析系统可以做趋势展示、指标汇总、风险提示、数据对比。

但它不能给人一种“照着买就行”的感觉。

所以我会让它在文案和产品边界上保持克制。

这也是人要负责的地方。

AI 可以帮你实现功能,但什么东西该不该这样表达,还是要人判断。

这次还有一个感受:提示词当然重要,但上下文更重要。

如果项目结构、技术栈、计划方案、验收标准都很清楚,提示词不需要写得多花。

你只要说:

按计划继续实现下一阶段。

或者:

根据当前报错修复构建问题。

或者:

保留现有架构,不要引入新的复杂依赖。

它就能接着往下做。

但如果上下文缺失,你写再多漂亮提示词,它也可能跑偏。

所以我现在更重视前置文档。

把项目目标、模块边界、接口约定、数据模型、优先级写清楚。

这些内容既是给人看的,也是给 AI 看的。

文档越清楚,AI 越像一个熟悉项目的协作者。

文档越模糊,AI 越像一个手很快但刚进组的人。

这次 15 个小时做出第一版,我并不觉得自己“没参与”。

只是参与方式变了。

以前我更多是在写代码细节里消耗时间。

现在我更多是在做这些事:

  • 定义目标
  • 拆分阶段
  • 控制范围
  • 判断取舍
  • 验收结果
  • 修正方向

这其实更像产品负责人加架构师的角色。

AI 把大量执行工作接走了,但人的判断没有消失。

甚至更重要了。

因为执行速度越快,方向错了的代价也越大。

以前方向错了,可能写两小时才发现。

现在方向错了,AI 可能很快帮你实现一大片。

所以 Vibe Coding 不是让人不用思考。

它是把人的思考从“怎么写这一段代码”,往上推到了“这个系统应该怎么长出来”。

我觉得最重要的一句话是:计划越清楚,AI 的自主执行能力越强。

Codex 这次能在 15 个小时左右把第一版跑通,不只是因为它代码能力强。

更重要的是,我给了一个足够具体的计划。

它知道要做什么,知道先做什么,知道做到什么程度算完成,也知道哪些地方不要越界。

Vibe Coding 的技巧,不是写一句神奇提示词。

而是把你的想法整理成 AI 可以执行的工程上下文。

你给它一个模糊愿望,它会给你一个模糊结果。

你给它一个清晰方案,它就能变成一个很强的执行者。

这也是我现在越来越喜欢 Vibe Coding 的原因。

它不是替我做决定。

它是在我把决定说清楚以后,能够将任务推进到验收版本。

聊聊我对 MCP 的一点理解

全称模型上下文协议(Model Context Protocol)。这是由 Anthropic 推出的一项开放标准,目标是为大型语言模型和 AI 助手提供一个统一、标准化的接口,使 AI 能够轻松操作外部工具并完成更复杂的任务。

通过使用 MCP,Claude 或 ChatGPT 等 AI 应用程序可以连接到数据源(如本地文件、数据库)、工具(如搜索引擎、计算器)和工作流(如专门的提示词),从而使它们能够获取关键信息并执行任务。 可以将 MCP 想象成 AI 应用程序的 USB-C 接口。正如 USB-C 为连接电子设备提供了一种标准化方式一样,MCP 也为连接 AI 应用程序和外部系统提供了一种标准化方式。

就拿我开发的 AI LocalBase 来说吧。AI LocalBase 是一个本地化的知识库和数据管理工具,它可以帮助用户在本地存储和管理各种数据,并通过 AI 助手进行智能查询和操作。 虽然是本地化,但它也可以支持 OpenAPI 和 MCP 协议。通过 MCP 协议,AI LocalBase 可以和 Claude、Cursor、Codex 这类 AI 应用连接起来,使用户能够通过自然语言与本地知识库进行交互。

MCP 协议连接层架构示意图

放到 AI LocalBase 这个项目里看,MCP 其实没有那么玄。

本质上,它还是启动一个后端服务,然后暴露一个符合 MCP 协议的接口,给其他 AI 应用看。

只不过这个接口不是普通业务接口。

普通 HTTP API 更多是给前端页面、脚本或者其他服务调用的。调用方需要提前知道接口路径、参数格式和业务含义。

MCP 接口面对的是 AI 应用。它要让对方能够先发现能力,再决定怎么调用。

比如 AI LocalBase 后端启动后,可以暴露一个 MCP 入口。Claude、Cursor、Codex 这类工具作为 MCP Client 连进来之后,先问后端:

你有哪些工具?

你有哪些资源?

你支持哪些操作?

后端再把自己的能力按 MCP 的方式描述出去。

例如:

  • 可以列出知识库
  • 可以检索某个知识库
  • 可以读取文档片段
  • 可以生成带来源的回答
  • 可以查看索引状态
  • 在有权限时,也可以上传文档或重建索引

这样一来,AI 应用访问的就不是 AI LocalBase 的网页,而是 AI LocalBase 暴露出来的一组能力。

架构上大概就是上面这张图表达的链路:AI 应用通过 MCP Client 连到 AI LocalBase 后端暴露的 MCP 入口,再由后端去访问知识库、文档、向量索引和检索服务。

这个时候,AI LocalBase 就不只是一个可以打开的本地知识库工具了。

它还变成了其他 AI 应用可以调用的知识库后端。

这也是我理解 MCP 的一个关键点:它不是替代业务系统,而是让业务系统把自己的能力用一种标准方式暴露出去。

真正有价值的地方,不是“我又多写了一个接口”,而是这个接口背后有一套能力发现、工具描述、权限控制和调用返回的协议约定。

所以 MCP Server 不是把所有内部接口原样丢给 AI。

更好的做法是站在 AI 应用的视角重新整理能力。

比如对外暴露 search_knowledge_base,而不是暴露一堆底层查询接口。

比如返回检索结果时,不只返回文本,还要返回来源、置信度、文档 ID、chunk 信息,方便 AI 继续组织答案。

比如写入、删除、重建索引这种操作,就不能和普通查询放在同一个权限层级里。

说白了,MCP 的工程价值在于:让后端服务多了一层面向 AI 应用的能力出口。

如果用代码表达,它其实可以很朴素。

下面这些不是完整实现,更像是把核心链路拆开看:后端启动时挂一个 /mcp 入口,然后在这个入口里处理 MCP 的初始化、工具发现和工具调用。

比如在 Go + Gin 后端里,可以大概这样挂路由:

func RegisterRoutes(r *gin.Engine, cfg Config, deps Dependencies) {
api := r.Group("/api")
if cfg.MCP.Enabled {
mcp := NewMCPHandler(deps.KnowledgeBaseService, deps.SearchService)
api.POST(
"/mcp",
RequireAPIKey(),
RequireScope("mcp:read"),
mcp.Handle,
)
}
}

这里的重点不是 /api/mcp 这个路径本身。

重点是:AI LocalBase 后端启动以后,多暴露了一个 MCP 协议入口。其他 AI 应用不是直接访问页面,而是通过这个入口发现和调用后端能力。

MCP 请求底层可以理解成一类 JSON-RPC 消息。后端收到请求以后,根据 method 分发到不同处理逻辑。

type MCPRequest struct {
JSONRPC string `json:"jsonrpc"`
ID any `json:"id,omitempty"`
Method string `json:"method"`
Params json.RawMessage `json:"params,omitempty"`
}
func (h *MCPHandler) Handle(c *gin.Context) {
var req MCPRequest
if err := c.ShouldBindJSON(&req); err != nil {
c.JSON(http.StatusBadRequest, rpcError(req.ID, -32700, "invalid json"))
return
}
switch req.Method {
case "initialize":
c.JSON(http.StatusOK, h.initialize(req.ID))
case "tools/list":
c.JSON(http.StatusOK, h.listTools(req.ID))
case "tools/call":
c.JSON(http.StatusOK, h.callTool(c.Request.Context(), req.ID, req.Params))
default:
c.JSON(http.StatusOK, rpcError(req.ID, -32601, "method not found"))
}
}

tools/list 可以理解成 AI 应用进来以后先问一句:你这里有什么能力?

后端返回的不是普通菜单,而是一组工具描述。

func (h *MCPHandler) listTools(id any) MCPResponse {
return MCPResponse{
JSONRPC: "2.0",
ID: id,
Result: map[string]any{
"tools": []map[string]any{
{
"name": "list_knowledge_bases",
"description": "列出当前用户可以访问的知识库",
"inputSchema": map[string]any{
"type": "object",
"properties": map[string]any{},
},
},
{
"name": "search_knowledge_base",
"description": "在指定知识库中检索相关文档片段",
"inputSchema": map[string]any{
"type": "object",
"properties": map[string]any{
"knowledgeBaseId": map[string]string{"type": "string"},
"query": map[string]string{"type": "string"},
"topK": map[string]any{"type": "integer", "default": 5},
},
"required": []string{"knowledgeBaseId", "query"},
},
},
},
},
}
}

当 AI 应用决定调用 search_knowledge_base 时,后端再把这个工具调用转成内部业务服务调用。

func (h *MCPHandler) callSearchKnowledgeBase(
ctx context.Context,
args SearchKnowledgeBaseArgs,
) (MCPToolResult, error) {
hits, err := h.search.Search(ctx, SearchRequest{
KnowledgeBaseID: args.KnowledgeBaseID,
Query: args.Query,
TopK: args.TopK,
})
if err != nil {
return MCPToolResult{}, err
}
return MCPToolResult{
Content: []MCPContent{
{
Type: "text",
Text: formatSearchSummary(args.Query, hits),
},
},
Structured: map[string]any{
"query": args.Query,
"hits": hits,
},
}, nil
}

这里其实就能看出 MCP Server 的位置了。

它不是向量数据库。

它也不是 RAG 本身。

它只是把 AI LocalBase 已经有的检索能力,包装成 AI 应用能发现、能理解、能调用的工具。

客户端配置也可以很简单。比如一个支持 HTTP MCP 的 AI 应用,可能只需要知道 MCP 服务地址和访问凭证:

{
"mcpServers": {
"ai-localbase": {
"type": "http",
"url": "http://localhost:8080/api/mcp",
"headers": {
"Authorization": "Bearer lb_xxx"
}
}
}
}

这样配置之后,AI 应用就可以把 AI LocalBase 当成一个外部能力源。

用户问问题时,AI 应用可以先通过 MCP 调用 search_knowledge_base,拿到相关文档片段,再基于这些片段组织回答。

所以从代码角度看,MCP 并不是多神秘的东西。

它就是一层协议适配。

只不过这层适配面向的是 AI 应用,所以它不只要能调用,还要能描述能力、限制权限、返回结构化结果,并且让后续的 Agent 工作流继续往下走。

关于逆向项目的一些想法

继上一次爬虫架构设计的博客记录,回顾写一写当时做逆向项目的一些经历和感受。 肯定没有当时那样的心情了,但还是想把一些想法记录下来,算是对这个项目的一个总结和反思。

最近看到不少分享逆向的文章,感觉挺有意思,也想记录一下自己在做这类项目时的一些想法和体会。 这个项目还是比较典型的逆向项目,涉及到代码分析、参数破解、请求模拟、数据处理等多个环节。 也是AI协助下的一种风口和未来趋势,虽然AI不能完全替代人工判断,但确实能加速很多分析和调试的过程。

某游戏大厂的虚拟物品交易平台。 需要从这个平台上获取一些数据,但官方没有提供公开的API接口。 所以只能通过逆向分析前端代码和网络请求,来找到合适的接口和参数,再模拟请求获取数据。 接口返回的数据分成两部分:一部分是基本的列表数据,另一部分是需要额外请求才能拿到的详细数据。 js的代码是经过混淆的,参数生成也比较复杂,涉及到一些加密和动态生成的逻辑。

标注:这篇博客不粘贴代码,只使用文字的方式来描述分析和思考的过程,避免泄露任何敏感信息(🐶狗头保命)。

使用的浏览器 Network,看 XHR 、 Fetch、resource,进行断点调试,分析。 再分析请求参数、Headers、Cookie、响应结构。尝试请求接口,看看能不能拿到数据。 分析 JavaScript 代码,找到请求相关的函数,看看参数是怎么生成的,是否有加密、混淆、动态生成等。

关键点:

  • 请求的大致流程
  • 解密放在哪个环节
  • 需要哪些参数,参数是怎么生成的,有没有解密方法

可以先对请求附近的函数入手,虽然被加密,整体逻辑还是可以拎得清楚的。 探查逻辑后,对关键函数进行断点。全局搜索可疑函数。最先知道的应该是解密函数, 找到它的调用关系,看看它的输入输出是什么。也可以在请求的过程中,在控制台打印一些参数,调用方法,看看它们的变化。

总计耗时三天,第一天主要是分析请求,参数,熟悉请求流程和代码,第二天主要是分析代码和找到解密方法,第三天主要是把请求流程跑通。

第一天不用急着找解密逻辑,先把请求流程摸清楚,得先了解项目,为什么要加密,加密的目的是什么?

  • 只是为了防止被爬
  • 还是保护数据
  • 还是为了压缩数据大小以方便传输

如果是第三种,只是为了方便传输,那么解密方法可能就是一个简单的压缩算法,或者是一个常见的加密算法,可能在网上就能找到相关的解密方法。 需要注意的就是前后会有一些步骤,是否需要配合渲染流程,进行一些前置处理,或者是后续的处理。

很多时候,逆向项目的第一步确实是抓包。

但这只是开始。

真正麻烦的地方往往在后面:

  • 参数是不是动态生成的
  • Token 是否有时效
  • Cookie 是否会失效
  • 请求频率是否有限制
  • 数据结构是否会变化
  • 失败任务能不能恢复

先跑通一次流程,后续的流程会很快

我觉得逆向项目里最考验人的,不是某一次成功请求。

而是你能不能把它从“脚本”做成一个能运行的系统。

比如:

  • 失败要能重试
  • 账号要能管理
  • Cookie 要能维护
  • 请求要控制频率
  • 数据要能落库
  • 异常要能被发现
  • 任务要能继续跑

这些东西看起来不如破解一个参数酷,但它们才决定项目能不能真正用起来。

现在做这类项目,AI 工具确实能帮很多忙。

它可以帮你分析代码片段,解释混淆逻辑,整理调试思路,甚至帮你把 JavaScript 逻辑改写成 Python。 甚至可以将加密的数据给AI看一下,确定加密的类型,或者帮你分析加密算法的逻辑。

但它也有局限。

它不知道真实请求环境,不知道站点当时的状态,也不知道你的 Cookie、代理、网络和账号到底发生了什么。

所以最后还是要自己判断。

AI 可以加速排查,但不能代替现场判断。同理,AI 也会犯错。

逆向项目很容易让人沉迷在某个技术细节里,非常容易上瘾。

但值得沉淀的,不是某一次参数破解成功,而是过程中形成的分析方法和工程意识。

技术会变,接口会变,规则也会变。

但观察问题、拆解问题、验证问题的能力,会一直留下来。

Vibe Coding 一段时间后,我的一些新感受

Vibe Coding 又用了有一段时间。

一开始接触它的时候,更多是新鲜感。看到 AI 能读项目、改文件、跑命令、修问题,会觉得这东西多少有点离谱。

但用久一点之后,新鲜感会慢慢退下去,剩下的就是一些更真实的体感。

它确实提高了效率。

但它也不是魔法。

以前做一个功能,很多时间会花在重复劳动上。

比如找文件、改样式、补类型、处理小 bug、跑构建、看报错。

这些事情不难,但很碎。

碎事情多了,人就容易烦。

Vibe Coding 最大的变化,是它把这些碎事情接过去了一部分。很多时候,我只需要描述清楚目标,它就可以帮我把第一版做出来。

这带来的不是简单的“少写几行代码”。

而是反馈变快了。

以前一个想法可能要等自己慢慢写完,才能知道效果行不行。现在可以更快看到一个版本,然后再判断它是不是对。

这点很重要。

因为很多想法不是想出来的,是做出来之后才知道哪里不对。

AI 写代码很快。

有时候快得让我有点不放心。

它会非常自信地修改文件,也会非常自然地补一些它认为合理的逻辑。

问题是,它的“合理”不一定等于我的“合适”。

比如一个页面,它可能会加很多解释文案,让功能看起来更完整;但我的博客更适合保持安静、简洁。

比如一个样式,它可能会顺手加背景、卡片、动效;但我可能只需要一个很轻的交互反馈。

所以用 Vibe Coding 越久,我越觉得验收很重要。

不是它写完就结束了。

而是它写完之后,我要重新看一遍:

  • 有没有改过头
  • 有没有偏离原来的设计
  • 有没有引入不必要的复杂度
  • 有没有破坏已有习惯
  • 有没有只是“看起来很努力”

有时候 AI 的代码没错,但气质不对。

这就需要人来判断。

以前我会觉得提示词很重要。

现在我觉得,上下文更重要。

一个项目里已经有自己的结构、命名、样式、内容风格和取舍习惯。如果 AI 不理解这些,它就很容易写出一个“能跑但不像这个项目”的东西。

所以我现在更愿意先让它读代码。

先看现有文件。

先理解已有逻辑。

再让它动手。

这和人接手项目其实是一样的。一个靠谱的人不会上来就重构,他会先看看这个项目原来是怎么长出来的。

AI 也一样。

给它足够的上下文,它会更像协作者。

不给上下文,它就更像一个手很快的陌生人。

Vibe Coding 用得越多,我越不觉得人会变得不重要。

相反,人要负责的东西变得更靠前了。

以前我主要关心“怎么实现”。

现在我更多关心:

  • 要不要做
  • 做到什么程度
  • 放在哪里合适
  • 会不会影响长期维护
  • 这个功能是不是符合产品气质

AI 可以帮我往前推,但方向还是要自己定。

如果方向不清楚,AI 只会更快地把混乱实现出来。

这也是我最近很明显的感受:Vibe Coding 不是让人不用思考,而是把思考的位置往上抬。

以前卡在代码细节里。

现在卡在产品判断里。

听起来好像还是会卡。

但卡得高级一点。

还有一个很现实的问题:AI 参与越多,项目越需要规则。

比如文件怎么命名,文章放哪里,数据抽到哪里,样式怎么复用,哪些信息不能写进仓库。

如果这些规则不清楚,AI 每次都会根据当下情况做一个“看起来可以”的选择。

短期没问题。

长期就会慢慢乱。

所以我最近反而更重视项目规范。

比如博客按年份月份归档,URL 用 slug 固定;友链和技术栈抽到 data;部署信息用 .env;新增文章用脚本生成。

这些事情看起来不酷。

但它们能让 AI 更好地工作,也能让未来的自己少骂几句过去的自己。

现在再看 Vibe Coding,我已经不太把它当成一个炫技词了。

它更像一种新的工作方式。

不是我把所有事情交给 AI。

而是我负责目标、边界、判断和验收,AI 负责承担大量具体执行。

这个分工如果配合得好,效率确实会高很多。

但如果人自己没想清楚,它也会很快把问题放大。

所以我现在对 Vibe Coding 的感受很简单:

它不是让开发变得不用动脑。

它是让开发者必须更清楚地知道,自己到底想要什么。

决策会变得越来越重要。

第一次迁移生产服务器

好消息,服务器迁移完成了。

坏消息,迁移服务器花了近四小时。这要是生产停机迁移,这不事不得凌晨干。

但我没有,这是一次停机的迁移…

这还是我第一次遇到服务商要跑路。有一说一,机器很稳,也会提前30天发公告,如此的一家服务商就这样没了,挺可惜的,我倒是希望你活下去。

以前总觉得服务器迁移这种事离我挺远,直到通知的时候,才发现:哦,倒霉事落到我身上了。

这次主要迁移的是一些 Web 服务、数据卷。

大部分都跑在 Docker 里,包括:

  • cpa
  • new-api
  • 博客
  • PostgreSQL
  • Redis
  • Nginx
  • SSL 证书

需要备份data volume,重新部署 Docker Compose,重新配置 Nginx,重新申请 SSL 证书。

每一层看起来都不复杂,但它们连在一起,就开始有点会折磨人了。

这次耗时比较长,主要还是因为没什么服务器迁移经验。

平时部署一个服务还好,看文档,用docker-compose。

但迁移不一样。

迁移是你要先把旧环境拆开,再在新环境里重新拼起来。

比如 Docker volume 看起来恢复了,但数据库不一定真的恢复对了。

Nginx 配置看起来写了,但请求不一定真的进了你想要的 server block。

SSL 证书看起来签了,但域名不一定都覆盖到了。

这几个“不一定”,加起来就是一个下午。

整个过程中最让我头大的还是 Nginx。

主域名访问时,一直出现 nginx welcome page。

二级域名访问却没问题。

这个页面真的很神奇。

就是这个熟悉的家伙:

/etc/nginx/sites-enabled/default

删掉默认站点,再 reload Nginx,主域名才终于正常。

这件事给我的感觉就是:有时候不是你没配置,而是有默认配置。

这次迁移过程中,我也一直在让 GPT 帮我看问题。

它确实很有用。

尤其是排查方向、解释报错、整理命令的时候,可以节省不少时间。

但它也会帮倒忙。

比如有些时候,它会默认你的服务器结构是标准的。

但实际情况是:你的服务器可能有 conf.d,也可能有 sites-enabled,还可能有 certbot 自动生成的配置。

它说得很有道理。

但是服务器情况不一定是gpt说的那样。

所以最后还是要自己去看:

Terminal window
nginx -T

真实配置永远比想象中的配置重要。

折腾了几个小时后,服务终于都恢复了。

博客可以访问,new-api 正常,cpa的数据没丢,统计服务也能起来,主域名和二级域名都能用,SSL 证书也处理好了。

那一刻没有什么特别激动的感觉。

更多是松了一口气。

这次最大的感受是:

时间的流逝,非常快。折腾一会,几个小时没了。

需要树立工程意识,迁移服务的环节流程需要熟悉,才能避免踩坑。要有自己的判断,不能轻易全部的交给 GPT。

服务器迁移不是单纯的搬数据,更是一个重新搭建环境的过程。 每个单独的docker容器挂在的数据卷。 在备份项目和数据卷的时候注意有没有嵌套的卷。 运维也不容易…

AI 编辑器工具的一点观察

最近一直在想一类工具。

类似 Cursor 这样的 AI 编辑器工具平台。

从去年开始,市面上出现了很多新的编辑器产品。它们大多不是从零开始做一个全新的 IDE,而是选择基于开源的 VS Code 平台继续往上搭。

这个选择其实很现实。

VS Code 已经有成熟的编辑体验、插件生态、终端、调试、文件管理和开发者习惯。重新做一套编辑器,成本太高,也很难让开发者迁移。

所以大家更愿意站在 VS Code 的基础上,把真正的差异放到 AI 能力上。

我用过一些类似工具,比如腾讯的 CodeBuddy、阿里的 Qoder,还有字节的 Trae。

它们给人的第一感觉都很熟悉。

因为底层体验都绕不开 VS Code。

文件树、编辑区、终端、快捷键、插件习惯,这些东西不用重新教育用户。开发者打开之后,不会有太强的陌生感。

所以现在这类工具的竞争,已经不太是“谁更像一个编辑器”。

大家的地基差不多,真正的差异开始出现在 AI 层:

  • 谁能更好地理解项目。
  • 谁能更稳地修改多文件。
  • 谁能把任务拆得更清楚。
  • 谁能在执行过程中少犯错。
  • 谁能把结果验证到位。

这些问题,开始比传统编辑器功能更重要。

每个平台都会有自己想强调的 Agent 能力。

比如阿里的 Qoder,有“专家执行团”这种偏多角色协作的设计。

Trae 里也有 Solo 这种更偏独立执行任务的模式。

这些名字背后,其实都在回答一个问题:

AI 到底应该以什么方式参与开发?

是作为一个回答问题的助手?

还是作为一个能拆任务、改代码、跑命令、检查结果的执行者?

我感觉现在的趋势很明显:大家都不满足于“问答式 AI 编程”了。

单纯聊天已经不够。

开发者真正想要的是:

我给你一个目标,你能不能理解项目,然后一步步把事情做完?

这就是 Agent 开始变重要的原因。

最早 AI 编程给人的印象,更多是代码补全。

写一半,它补一半。

后来变成 Chat。

你问它一个问题,它回答你一段解释,或者给一段代码。

现在越来越多工具在往执行系统走。

也就是:

读项目 -> 理解需求 -> 修改文件 -> 运行检查 -> 根据结果继续调整

这个变化很大。

因为它改变的不只是“写代码速度”,而是开发流程本身。

以前 AI 像是一个在旁边回答问题的人。

现在它开始像一个能参与工作的协作者。

当然,这并不意味着可以完全放手。

Agent 越强,人越需要判断方向。

它可以帮你做很多具体事情,但你仍然要知道目标是什么、边界在哪里、什么东西不能乱改、结果是否真的符合需求。

最近还有一个新的趋势:很多平台开始推出移动端。

这件事挺有意思。

以前开发工具基本都绑定在电脑上。哪怕是 AI 编辑器,本质上也还是一个桌面工作台:打开项目、读文件、改代码、跑命令。

但移动端出来之后,入口变了。

它更像是把 Agent 从编辑器里拆出来,放到一个随时可以对话的地方。

有些未完成的工作,或者临时想到的事情,不一定非要坐到电脑前才能处理。

比如:

  • 路上想到一个需求,让 Agent 先整理方案。
  • 临时发现一个 bug,让 Agent 先定位可能原因。
  • 让它继续某个没做完的任务。
  • 让它总结项目状态。
  • 让它根据上下文生成一个待办清单。

这时候手机不是用来完整开发的。

它更像一个轻量入口。

真正的执行可能还是在云端、远程环境或者本地项目里完成,但人和 Agent 的交互,不再必须发生在电脑前。

这会让 AI 编程工具从“编辑器产品”继续往“工作流产品”走。

桌面端负责深度开发,移动端负责随时调度。

我觉得这类工具后面的竞争,可能不只是模型本身。

模型当然重要。

但真正拉开差距的,可能还有这些东西:

  • 上下文组织能力。
  • 项目索引能力。
  • 多文件修改能力。
  • 终端和测试集成。
  • Agent 任务规划。
  • 错误恢复能力。
  • UI 和交互设计。
  • 对开发者工作流的理解。

如果只是接入一个模型,其实很容易被复制。

但如果一个工具能把模型、编辑器、终端、文件系统、Git、测试和任务流整合得很顺,那它就会变成真正的平台。

这也是为什么大家都在做自己的 Agent。

模型是发动机,但工具平台决定这辆车怎么开。

用这些工具的时候,我有一个很明显的感受:

它们都还在快速变化。

有些时候很惊艳,一个任务丢进去,它可以读项目、改文件、跑检查,最后给出还不错的结果。

有些时候也会很狼狈,改一半跑偏,理解错上下文,或者给出看似完整但实际没验证过的结果。

所以我现在更愿意把它们看成一种新的工作流,而不是一个稳定成熟的终点。

它们正在把开发者从“每一行都自己写”推向“定义目标、审查过程、把控结果”。

这和我之前接触 Vibe Coding 的感受也能连起来。

AI 工具越强,人的角色越往上移。

不是不写代码了,而是不再只盯着代码本身。

如果移动端这个方向走通,开发者和工具的关系会再变一次。

以前是:

我打开编辑器,然后开始工作。

以后可能会变成:

我想到一个任务,先丢给 Agent,让它继续推进。

这也是为什么移动端值得关注。

它不一定是为了在手机上写代码,而是为了让 AI 参与工作的入口变得更随身。

下一个 AI 编辑器工具平台会是什么样子?

Section titled “下一个 AI 编辑器工具平台会是什么样子?”

从对话到主动编辑,现在把 Agent 装进口袋,下一个阶段呢?

我觉得它可能不只是更聪明的聊天窗口,也不只是更强的代码补全。

AI 编辑器正在从“写代码的工具”,变成“管理开发过程的入口”。

如果说过去的编辑器是人操作代码的地方,那么下一代 AI 编辑器,可能会变成 Agent 和人一起推进项目的地方。人不再只是盯着每一行代码,而是更多地定义目标、判断方向、确认结果。

六一这天,云服务商给我开了个玩笑

六一这天,云服务商给我开了个天大的玩笑。

AI爆发,硬件暴涨,云服务商的成本也在暴涨,撑不住的已经倒下。这股风也吹到了我这里。

怎么说呢。

儿童节,成年人收到的是服务器搬家通知。

服务商还是比较良心,提前30天发布了公告。

接下来这段时间,我会把博客迁移到新的服务器上。

迁移后域名仍然保持不变:

blog.veyliss.top

所以已经添加友链的伙伴,不需要修改链接。

如果中途出现短暂无法访问、解析异常、证书刷新、服务重启之类的问题,也不要惊慌。

不是我跑路了。

是我的服务器先跑路了。

这次也算给我提了个醒:个人博客看起来只是一个小站,但只要还在持续更新,它就不是随手放在那里的页面。

域名、服务器、证书、备份,这些平时不太显眼的东西,也在支撑它继续跑下去。

总之,友链伙伴如果发现本站偶尔打不开,不用紧张。

我还在。

只是服务器在搬家。

七年后和初中同学小聚

周六,和初中一位同学小聚了一下。

算起来,这是七年后第一次见面。

时间过得真的很快。快到有时候会觉得,中间这些年像是被按了快进键。以前还在同一个教室里上课,后来各自读书、工作、生活,再见面的时候,已经隔了这么久。

但很奇妙的是,有些人很久不见,再坐下来聊天,也不会觉得完全陌生。

只是大家身上都多了一些时间留下来的东西。

他是动漫专业的。

我们聊着聊着,很自然地就聊到了 AI。

聊到 AI 对行业的冲击时,能感觉到那种复杂的情绪。

一方面,AI 确实很强。图片生成、视频生成、分镜、角色设计、动作参考,这些东西正在变得越来越快。很多过去需要大量时间打磨的环节,现在似乎被压缩了。

另一方面,这种强也会让人不安。

不是简单地说“AI 会不会取代谁”,而是整个行业的工作方式正在被改变。学了很多年的技能,突然要面对一个速度极快的新工具,这种感觉并不轻松。

聊这些的时候,我也会想到自己的行业。

IT 这边其实也一样。

代码生成、Agent、自动化测试、需求分析、文档总结,AI 也在一点点进入开发流程。它不是停在旁边给建议,而是开始坐到工作台上,参与具体的产出。

所以我们虽然专业不同,但聊到 AI 的时候,感受是相通的。

大家都在面对同一个问题:

当 AI 开始参与创作和工作,我们到底应该怎么重新理解自己的能力?

那天聊了很多。

聊学习,聊生活,聊以前的同学,也聊未来。

有些话题其实很普通,但因为很久没见,反而显得珍贵。

我们会聊以前谁去了哪里,谁现在在做什么,也会聊这些年自己经历了什么。很多事情说出来的时候,好像只是几句话,但背后其实已经走过很长一段路。

我发现,和老同学聊天有一种特别的感觉。

老同学知道我很早之前的样子。

不是现在这个写代码、做项目、折腾博客、学习 AI 的我,而是更早一点、更青涩一点的我。

所以重逢时,会有一种时间被拉开的感觉。

我能从对方身上看到过去,也能从彼此现在的状态里看到这些年各自的变化。

回来的时候,心里有一点感慨。

这段时间我好像一直在写技术、折腾项目、看 AI、做博客。

这些东西当然重要。

但那天和同学坐下来聊天,突然又觉得,生活本身也很重要。

很多时候,我们会把生活当成技术之外的“空白时间”。写完代码,修完 bug,部署完服务,学习完一个概念,剩下的才叫生活。

但其实不是。

生活不是支线。

它不是等工作和学习都完成后才出现的东西。

和朋友见面,聊一些没有明确产出的事情,回忆过去,想想未来,这些也都是很重要的部分。

这次小聚没有什么特别宏大的主题。

就是七年后见了一位初中同学,聊了很多,也感受到 AI 对不同行业都在产生影响。

动漫也好,IT 也好,大家都在重新适应这个变化很快的时代。

最后还是想感叹一句:

IT 除了代码,还有生活。

技术会一直往前走,项目也会继续做,AI 也会越来越强。

但人不能只活在代码里。

偶尔见见老朋友,聊聊过去和以后,也挺好。

做 AI 本地优先知识库三个月后,我发现 RAG 没那么简单

上周基本都在更新我的 AI 本地优先知识库。

说是更新,其实更像是把一个放了一个多月的项目重新捡起来,拍掉灰,再试着往前推几步。

从发布到现在,差不多快三个月了。

项目地址是:veyliss/ai-localbase

Star 到了 300+。这个数字说大不大,说小也不小。对一个个人项目来说,能被三百多人点一下星,已经说明它至少击中过一小部分人的需求。

但我也很清楚,中间有一个多月没怎么更新,所以 Star 涨得慢下来也很正常。

开源项目有时候像一条很细的火线。你持续更新,它就偶尔亮一下;你停下来,它就慢慢变暗。不是项目突然没价值了,而是互联网上每天都有太多新的东西流过去。

重新看这个项目的时候,第一感觉是:

它还是一个 Demo。

不是不能用,也不是只有一个空壳。

它已经能跑起来,方向也比较明确:本地优先、知识库、AI 问答、RAG、个人数据掌控。

但离“一个成熟产品”还有距离。

Bug 还不少,体验也不算很好。有些流程能走通,但不够顺。有些功能看起来有了,但真的连续使用时,边角问题会一个个冒出来。

这也是个人项目很真实的一面。

发出来的时候,更多是在表达一个想法:

我想做一个本地优先的 AI 知识库。

但真正要让别人舒服地用起来,靠一个想法远远不够。

这次回来更新,主要做了两件事:优化 UI,优化检索。

UI 的问题比较直观。一个工具能不能让人继续用下去,很多时候不是取决于它有没有某个大功能,而是打开之后顺不顺、清不清楚、有没有那种“我愿意继续点下去”的感觉。

检索就更核心了。一个知识库项目,如果检索不准,后面 AI 回答再漂亮也没有意义。

RAG 的链路里,LLM 往往是最显眼的部分,但真正影响回答质量的,很多时候是前面的检索。

这也是我这几天最明显的感受:

RAG 不是接一个模型,再塞一点文档,就自然变聪明。

真正做起来才发现,RAG 的难点不只在“调用大模型”。

模型只是最后一步。

前面还有一整套不太显眼、但很要命的链路:

  • 文档怎么解析。
  • 内容怎么切分。
  • 怎么向量化。
  • 怎么检索。
  • 怎么重排序。
  • 怎么拼上下文。
  • 怎么让答案有依据。

以前看 RAG 的概念图,会觉得它很清晰:

用户问题 -> 检索资料 -> 交给模型 -> 生成答案

但真正落到项目里,它就不是一条那么干净的线了。

文档内容可能很乱,切分可能切断语义,向量检索可能召回不准,模型可能忽略上下文,回答可能没有引用依据。这些问题不会在 Demo 截图里出现,但会在真实使用里一点点暴露。

也正因为这样,我越来越觉得 RAG 是一个工程问题,不只是一个 AI 概念。

这个项目一开始很强调本地优先。

我很喜欢这个方向。

知识库本来就带有很强的个人属性。笔记、文档、想法、项目资料,这些东西放在本地,用户自己掌控,会让人更安心。

所以最开始我很自然地选择了 Ollama。

本地模型、本地运行、本地数据,听起来非常完整。

但现实很快给了我一巴掌。

太慢了。

在普通机器上,本地模型的体验并不好。回复一次两次都很勉强,更不用说连续对话、长上下文、知识库检索之后再生成回答。

本地优先的理念是好的,但如果体验慢到让人不想继续用,那它就会从“安全感”变成“阻力”。

这件事让我重新思考一个问题:

本地优先是不是等于只能使用本地模型?

后来我觉得,不一定。本地优先更重要的是数据和控制权。用户的数据应该尽量保存在本地,知识库应该由用户自己掌控,项目不应该强绑定某个平台。

后面我加入了 API 接入能力。

这样项目不再只依赖 Ollama,也可以接入市面上很多模型。

这不是放弃本地优先,更像是给项目留出两个出口:

想要完全本地,可以走 Ollama。
想要更好体验,可以走 API。

我现在更愿意把它理解成:

数据本地优先,模型选择开放。

这个取舍比一开始更现实,也更接近一个工具真的要被使用时的样子。

这几天还有一个很强烈的感受:自己的知识储备还不太够。

以前以为做一个 AI 知识库,重点是把产品形态搭起来。现在发现,产品形态只是外壳。里面真正难的是检索、向量化、上下文组织和回答质量。

向量化这块尤其明显。Embedding 模型怎么选?中文效果怎么样?切片多大合适?什么时候只用向量检索,什么时候要结合关键词检索?要不要重排序?

这些问题都不是一句“接入向量数据库”就能解决的。它们需要实验,也需要积累。

我现在还在补这些东西。

所以,如果给这个项目现在的状态做一个描述,我会这样写:

方向是对的,但还不够好用。

它已经证明了一些事情:

  • 本地优先知识库是有需求的。
  • AI 问答和个人知识库结合是有吸引力的。
  • 但体验、速度、检索质量和稳定性都还需要继续打磨。

Star 300+ 当然让我开心。

但我也知道,Star 不是产品成熟的证明。

真正的证明是:有人能把它装起来,导入自己的资料,连续用几天,还愿意继续打开。

这比 Star 更难。

写到这里,感觉这不是一篇项目总结,更像是给自己留的一张便签。

提醒自己不要被概念骗得太轻松。

RAG 很热,本地优先也很好听,AI 知识库也很有想象空间。

但真正做起来,还是那些很具体的东西:

  • 一个按钮是否清楚。
  • 一次检索是否准确。
  • 一段回答是否有依据。
  • 一个模型是否太慢。
  • 一个新用户能不能顺利跑起来。

这些东西不酷,但它们决定项目能不能从 Demo 往前走。

项目现在还不成熟。

但至少,它还在往前。

这几天重新更新它的时候,我又找回了一点刚开始做它时的感觉:不是很确定,但挺想继续看看它能长成什么样。