开发者版 OpenHuman：不只是「会写代码的 AI」

市面上的 AI 编程工具（Claude Code、Cursor）解决的是「写代码」这个动作。OpenHuman 对开发者的价值在另一个层面：它知道你的全部工程上下文——GitHub 仓库动态、issue 与 PR、Slack 里的技术讨论、日历上的发布安排、文档里的架构决策——然后在这些上下文之上回答问题、干活、给提醒。

内置工具集也足够干活用：文件系统、git、lint、测试、grep，外加浏览器与计算机控制。它是「懂你项目的助手」，不是又一个 IDE 插件。

用法一：仓库动态的自动感知

GitHub 接入后（OAuth 一键授权），每 20 分钟的 auto-fetch 会持续吸收你关注仓库的新动态：新 PR、新 issue、CI 失败、依赖更新。这意味着两种全新体验：

早上开工问一句：「昨晚仓库有什么需要我看的？」——CI 挂掉的、需要你 review 的、和你模块相关的 issue，一条条列清楚。不用挨个刷通知。

被动提醒：和你相关的关键事件（比如你负责服务的 PR 被阻塞），配合工作流可以设置主动推送——从「你去查」变成「它来说」。

用法二：带上下文的代码问答

「这个模块为什么这么设计？」这类问题，问普通 AI 得先贴一堆代码和背景，问 OpenHuman 直接问——它的记忆树里已经有你的架构文档、相关 issue 讨论、历史 commit 语境。

典型的高价值问题清单：

  • 「这个函数上次改动是谁、为什么改？」（git 工具 + 记忆树上下文）
  • 「我们在 issue 里讨论过的那个性能问题，最终结论是什么？」
  • 「按我们的架构约定，新服务该放哪个目录、怎么注册？」
  • 「这个依赖升级会影响我们哪些地方？」

最后一类问题的价值最大——依赖影响面分析需要同时读代码（grep/文件工具）、读变更日志、读团队讨论，恰好是跨来源上下文的强项。

用法三：CR 与 PR 的辅助处理

处理别人的 PR 时，让它先读一遍：「总结这个 PR 的改动意图、影响面、潜在风险，对照我们关注的问题点」。它基于 diff、关联 issue、历史讨论给出初筛意见，你的 review 从「从头读」变成「带着重点核对」。

自己提 PR 时反过来用：「检查我这次的改动是否符合团队规范，lint 和测试跑一遍」——内置的 lint/test/git 工具直接执行，产出检查报告。注意边界：它跑检查、给报告，merge 的决定永远是你做。

用法四：跨工具的工单与任务串联

GitHub 之外，接入 Linear/Jira 后，「任务」维度也进了它的上下文。日常问得最多的会变成：

  • 「我这周的待办里哪些被 issue 状态变化阻塞了？」
  • 「这个 bug 的工单、相关讨论、涉及代码分别是什么？」

工具链割裂（issue 在 Jira、讨论在 Slack、代码在 GitHub）是研发效率的隐形杀手，OpenHuman 的价值就是把这三种来源折叠进同一个记忆树——搜索的对象从「某个工具里的记录」变成「你的工作本身」。

用法五：会议与代码的闭环

结合会议工作流：技术评审会后问「会上定的重构方案，涉及哪些文件？」——它把会议转录里的决策和代码图谱对上，输出受影响的模块清单。技术决策的落地追踪，从「靠人记」变成「上下文里现成查」。

用法六：定时任务——研发例事自动化

内置 cron 与调度能力，适合固化这些研发例事：

「每天早上 9 点，检查我负责服务的 CI 状态和错误日志趋势，异常才提醒，正常不用说话。」

「每周五下午，汇总本周我的 commit、合并的 PR、关闭的 issue，生成周报初稿。」

第二条是所有开发者的刚需——周报自动化。它基于真实仓库数据生成初稿（本站写 SubBoost 自动刷新时说过「自动化管数据保鲜」的道理相同），你只需要补充主观部分。配合 teamai-cli 的摩擦信号，团队级经验沉淀也在同步发生。

避坑清单

写权限收紧到零。 读仓库、跑 lint/test 是它的舒适区；push、merge、改 CI 配置默认不授权——主干上的每个写操作都应该过你的手。它出报告，你做决定，这条线不模糊。

大范围扫描先圈范围。 「读完全部仓库再总结」即便有 TokenJuice 压缩也是重活——跨仓库分析圈定仓库清单和时间窗，一次性全量扫描留给季度级别的架构复盘，别当日常动作。

例行检查设「异常才提醒」。 巡检类工作流的输出规则写清楚：正常不说话，异常才出声——通知信噪比一旦掉了，你会开始忽略它的提醒，整套监控就白配了。

按仓库敏感度分级走模型。 私有的核心业务仓库问答切本地模型，公开仓库和通用技术问题走云端路由——分级粒度到仓库，比一刀切全本地或全云端都务实。本地模型档位怎么选，隐私模式篇有完整的硬件速查表。

关键结论复核后再引用。 它的 PR 初筛意见、bug 根因分析是「起点」不是「终点」——拿去和团队讨论之前，关键点自己过一遍代码，AI 漏看一个文件的代价由你承担。

周报范围圈清楚。 生成周报的汇总范围限定在你名下的 commit、PR、issue——范围不圈，它把全团队的提交都算进来，初稿反而要花更多时间删。

隐私边界：代码该不该进 AI

开发者对代码上 AI 一向敏感。OpenHuman 的答案分三层：数据本地存储（SQLite，不上服务器）；模型可切本地（Ollama/LM Studio）；隐私模式一键结构断云——由 Rust 核心强制，开了之后任何云模型都收不到一个字节。核心代码库的问答走本地模型，通用问题走云端路由，按敏感度分配，这条混合路线是务实的最优解。

开发者的 OpenHuman 用到位后，你会发现它更像「长在你机器上的技术合伙人」——知道全部上下文、随叫随到、偶尔主动提醒。接下来的问题是：这些上下文你能不能亲手管？答案能，而且这正是下一篇的主题。