如何在GitHub上查看自己提过的Issues

Ne0inhk

— 5 min read
如何在GitHub上查看自己提过的Issues

如何在GitHub上查看自己提过的Issues

在GitHub参与开源项目或团队协作时，提交Issues是反馈问题、提出功能建议的核心方式。随着参与的仓库和项目增多，如何快速找到「自己曾经提交的Issues」、跟踪处理进度？本文介绍三种方法，帮你高效管理个人的Issues记录～

方法一：右上角「Your issues」快捷入口（最直接）

GitHub在界面右上角提供了专门的「Your issues」按钮，一键直达个人Issues管理页面。

步骤1：登录GitHub账号

打开 GitHub官网，登录你的账号（若未登录，需输入用户名/密码或通过第三方认证）。

步骤2：点击「Your issues」按钮

在页面右上角功能区，找到带有「Issues」图标的「Your issues」按钮（通常位于搜索框右侧、通知/头像区域附近），点击它。

GitHub右上角的「Your issues」按钮

（点击后直接跳转到「你的Issues」聚合页面）

步骤3：筛选“自己创建的Issues”

进入页面后，默认展示 Assigned to me（分配给你的Issues）。

默认展示“分配给我的Issues”

若只想看自己提交的Issues，点击页面中的「Created by me」选项卡，列表会自动切换为“由你发起的所有Issues”。

切换到“Created by me”筛选自己提交的Issues

（筛选后，列表仅包含你作为发起者的Issues）

方法二：直接访问个人Issues专属链接

GitHub为每个用户生成了个人Issues专属链接，可直接在浏览器打开，自动筛选“由你创建的Issues”：

  • 链接格式：https://github.com/issues?q=author%3A{你的GitHub用户名}
  • 示例（假设用户名为octocat）：https://github.com/issues?q=author%3Aoctocat
直接访问专属链接的效果

小技巧：把链接加入浏览器书签，下次可直接打开，无需重复筛选～

方法三：通过通知订阅页面关联Issues动态

除了直接查看Issues，还可以通过通知订阅页面管理“与你相关的内容更新”（包括Issues的评论、状态变更等通知）。直接访问链接：

https://github.com/notifications/subscriptions

在这个页面，你可以：

  • 查看订阅的仓库/话题：若某个仓库的Issues有更新（如他人回复、状态变更），会通过通知推送给你；
  • 管理通知规则：自定义是否接收某个仓库的Issues评论、提及等通知；
  • 间接跟踪“关注仓库中，与你相关的Issues动态”。

注：此页面更侧重于「通知订阅管理」，若需直接查看自己提交的Issues列表，前两种方法更高效～

进阶：高效筛选与管理自己的Issues

在个人Issues页面，结合搜索语法和筛选条件，可更精准找到目标Issues：

按「仓库」筛选

想查看「某个特定仓库中提交的Issues」，使用以下搜索语法：

repo:用户名/仓库名 is:issue author:你的用户名

示例（查看octocat/hello-world仓库中自己提交的Issues）：

repo:octocat/hello-world is:issue author:octocat

按「状态」筛选

  • 查看未关闭的Issues（仍在处理中）：在搜索框中加入 is:open；
  • 查看已关闭的Issues（已解决/关闭）：在搜索框中加入 is:closed。

按「关键词」搜索

记得Issue标题/内容的关键词？直接在搜索框输入关键词（会匹配标题和正文内容）。

实际场景示例

场景1：跟踪开源项目的Bug反馈

你在numpy/numpy仓库提交了Bug报告，想知道维护者是否回复或修复：

  1. 用「方法二」的专属链接打开个人Issues列表；
  2. 用搜索语法 repo:numpy/numpy author:你的用户名 快速定位该仓库的Issues。

场景2：团队协作中的需求管理

在公司内部仓库（如company/project-x）中，你提交了多个需求类Issue。通过「Your issues」页面，可快速统计：

  • 已完成的需求：筛选 is:closed；
  • 待处理的需求：筛选 is:open。

场景3：清理过时的Issues

若发现自己过去提交的某个Issue已无意义（比如问题已自然解决），可在个人Issues列表中找到它，点击进入详情页后手动「Close issue」。

总结

GitHub提供多种便捷方式查看自己提交的Issues：

  • 右上角「Your issues」：最快捷的一键入口，适合日常快速查看；
  • 个人专属链接：适合书签收藏，直接访问无需筛选；
  • 通知订阅页面：辅助管理“关注内容的通知”，间接关联Issues动态。

结合「筛选语法+关键词搜索」，能更高效跟踪问题进度，让开源协作或团队开发更顺畅～

若你是项目维护者，也可用类似方法（调整筛选条件为author:他人用户名）查看他人提交的Issues，及时响应社区/团队反馈～

Read more

开源GraphMindStudio工作流引擎：自动化与AI智能体的理想核心

开源GraphMindStudio工作流引擎：自动化与AI智能体的理想核心

引言 GraphMindStudio是一个完善的开源引擎，从前端到算法。整体分为多层架构，前端使用UnityUI，动态计算排布。后端工作流引擎完全模块化解耦，能够实时观测，控制节点的运行，后基于上下文反应式ECS重构，提高运行效率；顶层Json使用占位符架构抽象重复节点逻辑为通用逻辑。 工作流完全基于既定配置运行，极其的稳定。但是被底层逻辑被设计为支持动态更新，即可以在任何逻辑中更新任何运行的工作流。这个技术目前应用在编译逻辑上，如果编译失败了就添加一个节点再重新调用大模型生成一次代码，带着报错。 我认为这样的设计远好于相较于完全依赖于大模型，所有的逻辑都使用大模型完成的完全自主智能体。 工作流的运行结果在模板的基础上可以很大范围的确定，而节点动态更新的能力完全能够实现大模型的自主运行，且是更高级的抽象，支持多步，或者选择已有配置进行运行。 这个框架是一个高效、稳定、强大而完整的逻辑架构。不仅能用于AI代码生成，AI图片生成，可以应用于任何适用于工作流的领域。 publicstaticFunc<object, Task<object>> CompileCheck =async(obj

By Ne0inhk

2026年AI OCR发展前瞻：开源可部署模型实战趋势解析

2026年AI OCR发展前瞻：开源可部署模型实战趋势解析 1. 引言：OCR技术正迎来“平民化”爆发期 你有没有遇到过这种情况：手头有一堆扫描的合同、发票或者产品说明书，想把里面的内容提取出来编辑使用，结果手动敲键盘敲到眼花？传统OCR工具要么收费贵得离谱，要么识别不准还得反复修改。但现在，情况完全不同了。 2026年，AI驱动的OCR技术已经不再是大公司的专属武器。像 cv_resnet18_ocr-detection 这样的开源可部署模型正在快速普及，普通人也能在自己的服务器上一键搭建一个高精度的文字检测系统。更重要的是，这些模型不仅免费，还支持本地运行、数据不出内网、可定制化训练——真正实现了“我的文档我做主”。 本文要讲的，就是一个由开发者“科哥”构建并开源的OCR文字检测WebUI系统。它基于ResNet18骨干网络，集成了检测、批量处理、微调训练和ONNX导出功能，界面友好，部署简单，特别适合中小企业、个人开发者甚至教育场景使用。 我们不聊复杂的算法原理，只聚焦三件事： * 它能做什么？ * 怎么快速用起来？ * 未来这类模型会怎么发展？ 看完这篇，

By Ne0inhk
GitHub热榜----上帝视角玩转未来！MiroFish：基于群体智能的万物预测引擎

GitHub热榜----上帝视角玩转未来！MiroFish：基于群体智能的万物预测引擎

摘要：你是否想过像《黑客帝国》或《西部世界》那样，构建一个平行的数字世界？或者在小说写到瓶颈时，让书中人物自己“活”过来推演结局？今天介绍的开源项目 MiroFish，正是一个基于**多智能体（Multi-Agent）**技术的通用群体智能引擎。它能通过你上传的“种子信息”，自动生成成千上万个具备独立人格和记忆的智能体，在数字沙盘中演化未来。 🚀 前言：当 AI 拥有了“社会属性” 在 ChatGPT 单打独斗的时代，我们问它：“如果发生X，会产生什么后果？”它只能基于训练数据给出概率性的回答。 但在 MiroFish 构建的多智能体系统 (MAS) 中，AI 不再是一个孤独的对话框。MiroFish 让无数个 AI 智能体组成一个社会，它们有记忆、有性格、有社交关系。当你在系统中投入一个变量（比如一条突发新闻），你会看到这些智能体如何反应、

By Ne0inhk
开源AI编程工具对决：Superpowers技能库与OpenSpec规范驱动，谁更胜一筹？

开源AI编程工具对决：Superpowers技能库与OpenSpec规范驱动，谁更胜一筹？

文章概要 在AI辅助编程领域，Obra/superpowers库与Fission-AI/OpenSpec库代表了两种截然不同的技术路径。前者致力于构建可复用的AI编程技能库，后者则倡导以规范（Spec）为核心的驱动开发模式。本文将深入对比两者在核心理念、工作流程及适用场景上的核心差异，探讨它们如何分别解决AI开发中的效率与一致性难题，并分析在项目演进中应如何取舍。 前几天在咖啡店，我无意中听到邻桌两位程序员在激烈争论。一位坚持说：“AI编程助手最大的价值就是帮我快速写出新代码，我需要的是更多‘技能’。”另一位则反驳：“不对，AI最该解决的是代码一致性，我们团队现在最缺的是‘规范’。”这让我立刻想到了最近在GitHub上观察到的两个项目：Obra的superpowers技能库和Fission-AI的OpenSpec规范驱动框架。它们恰好代表了这两种截然不同的思路。 我打开superpowers的仓库，第一印象是它像一个为AI助手精心打造的“瑞士军刀”工具箱。它的核心理念非常直接：将常见的、复杂的编程任务封装成一个个可复用的“技能”（Skill）。这就像给AI安装了一个插件商店，当需要

By Ne0inhk