Hi there 👋

看到个项目，code graph，顾名思义应该是把项目代码给构建成图谱，拖延到今天来实测一下效果 仓库地址：GitHub - colbymchenry/codegraph: Pre-indexed code knowledge graph for Claude Code, Codex, Gemini, Cursor, OpenCode, AntiGravity, Kiro, and Hermes Agent — fewer tokens, fewer tool calls, 100% local · GitHub 安装 code graph mac 安装命令 1 curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh 安装 MCP 配置 初始化项目 进入一个最近在开发的目录，开始索引 1 2 cd your-project codegraph init -i 接下来他会扫描仓库的文件并且在本地新建数据库 大概流程是这样的： 显示已折叠代码（21 行） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 你的代码目录 │ ▼ Tree-sitter 解析源码 │ ▼ 抽取符号(Symbol) 函数、类、方法、变量、路由 │ ▼ 分析关系(Edge) 调用关系 继承关系 导入关系 引用关系 │ ▼ 写入 SQLite │ ▼ 生成 .codegraph/ 官方文档里提到，CodeGraph 会把符号、调用图、文件结构等信息存到 SQLite（FTS5）数据库中，并把项目数据放在 .codegraph/ 目录下。 ...

不知不觉半年未曾在夜半而想起写小札了。这个分区诞生那天起就注定了它惨淡的更新热度。因为我无法做到高强度持续的情感饱满，小札对我而言就是满而溢出的产物，只不过容器也会变化内容也会变化，所以注定是无规律无迹可寻，不过半年确实过长，无非是太过于偷懒了。 近来对偷懒更加觉得焦虑，今天刷到一篇文章，作者提到自己三十多岁恨不得和二十多岁十多岁的人换命，大学生也许都还认为时间像一块丰腴的肥皂，一时半会用不完。 非也，我感知到肥皂变小已经不是一天两天，说不清究竟是什么在飞快的急速的似乎异于常人的把我推动，推动到快速接近未来，是即将成家的责任，父母日益年迈的身体，还是这异常发展迅速的时代。 我就是00后，大学毕业后单从求职环境，到就职后的几年经历的业内大革新，大模型在三个月进行一次迭代，项目在一周进行一次更新，ai让一个人能完成十个人的活也让一个人承担上了十个人的压力。越是接触ai越感到焦虑。从chatgpt正式问世第一次在那个窗口聊天到如今codex打开几个threads日消耗几亿个token，我有时候忙到分不清是我在驾驭ai还是ai在驾驭我，我只能选择yes or no。 对于未接触到这一切的人们而言，只需要一点点🤏行动力就能戳破这个薄膜，人们将极速的从0到达60的水平，而我焦虑的是这件事情变得没有任何门槛了，一句话的描述能抵过了我过去一个月的学习产出的成果，我不知道如何保护自己，我开始慌，我一遍疯狂加班学习最新的技术，大量的跟风，却回头发现自己无差别接收最新信息的时候付出了很大的代价去过滤初级信息。而经过一轮一轮消化的产物你可以说它不新，被加工，但你永远无法否认被一环一环传播也是一种过滤的过程，有一句玩笑话，当你在这个ai时代，只要你学的够慢，你就会发现不用学了。我们在一年前针对语音交互智能系统辛苦调优在工程上优化ASR到TTS的推理速度，为了在用户说完话后系统能在最短的时间发出回答的声音做出的努力在某一个月一个realtime的api更新碾压到一文不值。快速调头是个人和小团队在这个时代唯一且最强大的对抗武器，传统笨重的打磨思维不再有效，这会让人持续紧绷持续紧绷，随时随地vibecoding，手机上疯狂approve yes or no，这一切热度都会像泡沫一样疯狂膨胀。 吹起泡沫的是风，我不能随着泡沫增长，我得抓住这个风，看着风在眼前消失的滋味非常难受，但是越着急越抓不住，冰瀑三尺非一日之寒，我感知到肥皂变小泡沫变大，在这个泡沫炸开让所有人都感知到之后，下一个泡沫我需要做好准备，无论是看书，健身，学习，尝试。 这确实是一个黄金时代，前人不断惊叹青春的逝去感慨年轻人对时代的馈赠一无所知，我自感无法和同龄人一样再心安理得把这些挥霍在无意义的琐事和廉价的娱乐中，只要肯抬头看一眼，时间的收网并非遥不可及，只是远远的看一眼便能感受身上已被勒的紧迫窒息。 我试图找个高大上的句子来引用结尾却找不到丝毫存活，哪怕让豆包看看它也束手无策，那我就顺着新想到的思路接着讲讲。首先是我深知焦虑过度无益且一口吃不成胖子，但是我始终没能践行自己的认知，差点火候。前段时间刷到一位作者的文章讨论人需要掌握火候，讲得很好，串通中庸无为如如三家传统宗教的智慧，无非就是做菜放盐的适量，这个适量，其实做了几次就知道了，人的学习率很高，不需要回归很多次就能学会。那么我觉得写此文也是在此提醒我一下，要注意火候。坚持会是一个好的习惯，但是硬抗不是长久的方案。 此时此刻我正在完善我的简易skills hub，希望一切能如我所愿，不如也没事，我有的是手段。 放个梗图给以后笑一笑

今天写 mitmproxy 那篇的时候，顺手试了一下一个很有意思的 skill，分享一下： helloianneo/ian-xiaohei-illustrations，好多天前关注的，忘了是在哪看到的，发现最近热度蛮高。 截止写本文，作者在群里分享，它在这周 GitHub 新仓库搜索结果里排第二。 这个仓库名字很直白，就是 Ian（作者） 风格的小黑怪诞正文配图生成 Skill。 本质上它不是一个很复杂的项目。甚至可以说，它简单到让我有点恍然大悟：哦，我之前每次都开着语音和叫 image2 生图其实可以做的优雅一些。 而是把一套稳定的审美、角色设定、构图禁忌、prompt 模板和 QA 规则，塞进一个 SKILL.md 里，然后让 Codex 在需要配图的时候按这个流程走。 可以。 在 mitmproxy 文章里试了一下 最近那篇文章是这个： mitmproxy 实战以及抓包Claude Code | 安落滢 Blog - 技术分享与生活记录 里面有一段是在讲证书信任和中间人代理。这个概念如果只用文字写，其实也能讲清楚，但正文读起来会有点干。 于是我就让这个 skill 给 mitmproxy 生成了配图。 一半是「浏览器信任 mitmproxy 之后，中间站可以看见 HTTPS 流量」： 另一半是「没有证书不让拆，有证书才能拆开看再封回去」： 效果其实还挺好。 画面不是 PPT 那种规规矩矩的流程图。它能把这种偏抽象的链路，变成一个比较容易记住的画面。 这对博客很有用。 但我想继续改 目前这个 skill 最大的特点是「小黑」。 小黑蛮简单的，黑色实心，白点眼，细腿，没什么表情，认真做一些很荒诞但成立的事。这个设定很合适，也很容易让模型稳定复现。 但是我后面应该不会一直用小黑。 倒不是它不好，而是我还是想慢慢做一点更有我自己味道的角色。博客写久了之后，配图其实也会变成一种个人标识。现在用小黑是借别人的视觉语言，后面如果能变成自己的角色，那就更像我的博客了。 可能不是很复杂的 IP。 也许只是一个更固定的主角、几个常见表情、一套动作库、一点颜色习惯。 另一个问题是一句话能力 现在这个 skill 已经能工作，但我觉得还没有到「我一句话，它就能把完成的图片做出来」的程度。 我想让他 和之前 卡兹克的 writer skills 结合一下，先让 agent 读我的文章，然后根据我留下的指示和上下文，生成配图。 ...

这个工具是 boss 推荐的，尽管他想到的使用场景是大炮打蚊子（指 在 windows wsl 安装 mitmproxy 来抓宿主机 web 页面的 restful 接口，而实际 console 的 network 足矣）但是也不去纠正了，我来试试这个工具的真实能力。 GitHub - mitmproxy/mitmproxy: An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers. · GitHub 看到这个的时候心中暗喜，我以为开箱即用，配个证书就行。 1 brew install mitmproxy 我刚开始以为他只有 cli 工具，没想到还有 web，那真的很方便了。 结果装完就遇到 Apple could not verify mitmproxy is free of malware that may harm your Mac or compromise your privacy. 啊？第一次在 homebrew 装完的东西碰到这个问题。我一时怀疑装错了。 问了下 G 老师，说 app 身上还带着 quarantine 标记，首次运行的时候拦我一下 xattr -dr com.apple.quarantine /opt/homebrew/Caskroom/mitmproxy/*/mitmproxy.app ...

agent 发展到现在，已经有很多成熟的方案了，但是为了更高的设计一致性和项目掌握度，需要从 0-1 设计一套。期间会借鉴参考很多开源项目。项目全程遵循 KISS 原则。 概念和技术栈选择 查了一下 agent 的概念其实比较久远，很早以前的经典理论我们不提，本文只针对目前的 生成式 AI 所代表的 agent。 对于 agent 的执行机制，你可能听说过 ReAct （reasoning and acting）ReAct 来自 2022 年论文《ReAct: Synergizing Reasoning and Acting in Language Models》1，概念如下 可以说这是 agent 最基本和常见的执行框架，属于评估优化式的架构，也就是通过迭代反馈不断改进输出来逼近目标。 而在两年前还有一些 workflow 产品比如扣子、dify 等，也常被误称为 agent/智能体。但其实他们还是链式处理任务的工作流为主。 我定义智能体的一个核心边界就是他能自己决定使用什么工具以及怎么使用。 截止到开始本项目之前，市面上已经有了很多类似产品，各有特色，但是最底层的原理还是一样的。现在需要在一些业务场景用到或者开发一个平台来提供 agent 服务，所以需要从自构建开始保证设计的一致性和对系统的了解性。 在技术栈的选择上，选择全力投入 python，如果熟悉 python 语法，借助 python 的生态。开发agent 的 MVP 将降低很多心智负担，但是显而易见的缺点是对底层控制降低（比如一些隐形的 runtime error 和性能消耗），但是个人判断，结合我的技术栈掌握和现处公司项目的情况，我决定第一个发行版本将全量使用 python 构建，后续选择使用 Rust 语言作为 热点模块 的替换直至开发团队掌握 rust 技术栈后进行全量重构。（如果这个项目胎死腹中也无需谈什么未来。） 架构设计 基于 ReAct 架构设计的基础思路 还是比较容易的，这里参考王二老师的文章，列一些功能和设计思路。2 ...