bimeixishuai 最近的时间轴更新

bimeixishuai

V2EX 第 739110 号会员，加入于 2025-03-12 10:10:55 +08:00

bimeixishuai 提问技术话题好玩工作信息交易信息城市相关

上次发过的 AI 排障项目，这次整理成了可直接跑的 v0.1.0 MVP

程序员 • bimeixishuai • 3 天前 • 最后回复来自 bimeixishuai

家人们谁懂啊遇到下头 HR 了找个工作还遇到了订阅歧视

职场话题 • bimeixishuai • 3 月 19 日 • 最后回复来自 zjcolvin

AI 开始长期记住你了，但“你是谁”还不归你自己管

分享创造 • bimeixishuai • 3 月 17 日 • 最后回复来自 bimeixishuai

做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

程序员 • bimeixishuai • 3 月 16 日 • 最后回复来自 bimeixishuai

你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

程序员 • bimeixishuai • 3 月 10 日 • 最后回复来自 bimeixishuai

» bimeixishuai 创建的更多主题

bimeixishuai 最近回复了

3 天前

回复了 bimeixishuai 创建的主题 › 程序员 › 上次发过的 AI 排障项目，这次整理成了可直接跑的 v0.1.0 MVP

@gyl1989113 可以直接让 cc 帮你介入你想要暴露的一些内容，你把经验告诉他抽象为 skill 就可以快速体验效果

3 天前

回复了 bimeixishuai 创建的主题 › 程序员 › 上次发过的 AI 排障项目，这次整理成了可直接跑的 v0.1.0 MVP

@gyl1989113
可以借鉴，运维排错本身或者说只要可以抽象的排错逻辑就很适合这套思路。

很多运维问题其实也有固定排查顺序，适合把这些经验抽成 runbook ，让 AI 按顺序取证，而不是自由乱查。

不过当前这个仓库内置的能力更偏后端业务链路排障，不是开箱即用的运维平台。
如果要用在运维场景，一般需要自己补对应的 tool adapter 和 runbook/skill ，比如接 K8s 、Prometheus 、日志系统之类，再把平时的排错逻辑沉淀进去。

3 月 18 日

回复了 bimeixishuai 创建的主题 › 职场话题 › 家人们谁懂啊遇到下头 HR 了找个工作还遇到了订阅歧视

@unusualcat 哈哈太性情了

3 月 18 日

回复了 bimeixishuai 创建的主题 › 职场话题 › 家人们谁懂啊遇到下头 HR 了找个工作还遇到了订阅歧视

@Leeeeex 哇，你比我细心

3 月 17 日

回复了 bimeixishuai 创建的主题 › 分享创造 › AI 开始长期记住你了，但“你是谁”还不归你自己管

@metalvest
当前版本还不是自动维护，主要是“给材料 + AI 整理 + 生成初始 memory.json”，然后供不同工具读取。
后续维护我还在拆：用户主动改、AI 提建议再确认、以及少量低风险事实的受限更新。
这块弯弯绕绕有点多，还在研究。

3 月 16 日

回复了 bimeixishuai 创建的主题 › 程序员 › 做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

别收藏了，快来讨论哇

3 月 14 日

回复了 bimeixishuai 创建的主题 › 程序员 › 做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

@DonaldY
你说得对，确实是 skill 这类东西出来以后，我才有了这个想法的。

我真正想做的重点也是把排障经验和步骤固化下来，不是强调 Agent 直接拿线上 DB/Redis 权限。

文里这点我确实写得有点理想化了。真实落地时，更合理的接法应该是走企业内部已经封装好的日志/查询/观测平台，runbook 是上层逻辑，底层不一定是裸连生产系统。

反过来说，我现在也越来越觉得，adapter 层本身未必最难，真正难的是把团队里那些知道先查什么、什么证据算数的经验沉淀下来。

3 月 14 日

回复了 bimeixishuai 创建的主题 › 程序员 › 做了个给 AI Agent 用的排障框架：重点不是接更多工具，而是把排障流程收敛

为什么发布前 markdown 格式还没问题，发布完就成这样了

3 月 10 日

回复了 bimeixishuai 创建的主题 › 程序员 › 你的 AI 记忆，凭什么被平台锁定？ MIP：一个让 AI 记忆可移植的开放标准

@nachzugler
并不冲突，你这个其实很有参考价值，本质上已经是“memory + 文本知识库 + 工具调用”的一套工作流了。
我现在想验证的点和你这套不完全冲突，而是看要不要再抽一层更小的公共入口，让不同 AI 接手时先拿到一致的用户信息和基础约束。

举例：若是你的 openclaw 挂了，是不是就要请外援介入？比如告诉 cc 或者 codex 让他们帮忙修复，这时候或许就需要一个运维入口，这个入口里有 openclaw 运维过往，坑之类的，知道哪些能改哪些要请求询问。或许比让他们直接读 openclaw 文件夹下的一堆要好。

3 月 10 日

回复了 jedeft 创建的主题 › 程序员 › 分享一个高效的开发思路

可以用 gitworker ，切不同的分支并发编程

» bimeixishuai 创建的更多回复