把复杂的工程工作，做成真正能用的工具。
Developer tools · AI engineering · Self-hosted systems
一个入口，连接原生协议与不可变字节。
把 AI 代码审查直接放进 Gitea / Forgejo 的 PR 里，不用再切到另一个面板。
在 PR 里评论一句 /oc 或 /opencode，Gitea Actions 就会读取完整或增量的 diff，把行级评论和审查结论写回 PR。Docker 和源码两种安装方式都用独立配置，不会动到你已有的 OpenCode 工作区。除内置的 OpenAI、DeepSeek、Anthropic 外，也可以注册自建或第三方网关作为自定义 provider。
从一个问题开始，看看它最后长成了什么。
或者，浏览全部作品往下是作品、做事方式、常用工具和手记。
四个开源作品。展开看看各自解决什么问题，也可以直接上手试。
项目各不相同，衡量的标准是同一套。
我是 ccsert，主要做开发者工具、AI 应用平台和自托管系统。公开的作品有多协议制品仓库、嵌在代码托管平台里的 AI 审查、自托管的 PDF 翻译工作台，和一个 Rust 写的终端工具；工作中也参与企业 Agent 平台、研发交付流水线和基础设施迁移的建设。
我习惯把架构、协议、数据一致性和界面体验放进同一个问题里想：用的人怎样把事情做完，出错时能不能看懂发生了什么，系统又该怎样恢复。
判断一件事有没有做完，我会回到真实页面、运行日志和精确版本。少让使用者操心，尽量沿用原生协议，让状态看得见；构建通过和交付完成，是两回事。
按用在哪里来分组，不给自己打分。
State: public
State: public
State: toolbox
State: toolbox
State: toolbox
State: research
知识管理、网络、语音和 Linux 运行时，几条还在追问的线索。
原始资料保持不动，整理后的内容写成 Markdown，再用 schema 和确定性的 doctor 检查结构。Git 记录历史，Obsidian 给人阅读，LLM 负责导入、查询和检查。
还没想清楚的纯文本索引什么时候会不够用，值得引入更重的检索层？
这里只公开架构思路；私有资料、日志和没审过的页面不会出现在站点上。
说说你遇到的问题、手上的限制，和希望得到的结果。
问题背景 · 已知限制 · 期待的结果
如果和某个开源项目有关，直接贴上仓库链接或 Issue 就好。