把复杂留给系统，把好奇心留给自己。
Developer tools · AI engineering · Self-hosted systems
一个入口，连接原生协议与不可变字节。
把 AI 代码审查放进 Gitea / Forgejo 原生 PR 流程，而不是另造一个脱离代码现场的面板。
通过 Gitea Actions 监听 PR 与评论事件，按需获取完整或增量 diff，再提交带行级评论和 review decision 的结构化审查；Docker 与源码安装都使用隔离配置，不覆盖已有 OpenCode 工作区。
从一个问题开始，看看它最后长成了什么。
或者，浏览全部作品往下看看，想法怎样变成作品。
四个公开作品，从这里了解，也可以动手体验。
The through-line behind the repositories
我关心的不是堆叠更多技术名词，而是把复杂工程工作变成真正有人愿意使用、也能放心操作的工具。 公开项目横跨开发者工具、AI 辅助工程与自托管基础设施，但它们都在处理同一个问题：怎样让复杂度留在系统内部。
缩小操作面，贴近原生协议，让状态可见，并把“构建成功”和“已验证交付”明确区分。这也解释了为什么项目会反复出现 diff 预览、可恢复写入、协议兼容、离线部署、来源追溯与显式质量门禁。
按公开构建、核心工具与研究方向组织，而不是给自己打分
关于知识、网络、语音与系统，顺着一条线索继续读。
把不可变来源、可演进 Markdown、schema 与确定性 doctor 组合成长期知识层；Git 保存历史，Obsidian 提供人类界面，LLM 负责 ingest、query 与 lint。
OPEN QUESTION什么时候文本索引已经不够，值得引入更重的检索层？
这里只公开架构摘要；私有来源、日志与未批准页面不会随站点发布。
Start with the problem, its constraints, and the outcome you need
问题背景 · 已知约束 · 期待结果
如果与某个公开项目有关，也可以直接附上仓库链接或 Issue。