#GitHub

sitin
3天前
sitin
5天前
最近又刷到 4 个挺小众、但都很有“动手感”的 GitHub 开源项目 1.CursorLens 现在做产品演示、录教程、录操作视频的人越来越多,但很多录屏工具不是太重,就是导出和编辑体验很别扭。 CursorLens 这种就属于很实用的那类:录屏、摄像头、麦克风、字幕、注释、光标特效这些常用功能基本都给你配齐了,而且整体思路明显是站在创作者和开发者视角做的。 说白了,这种工具不一定是什么“革命性创新”,但它如果顺手,你就会高频用,最后反而特别值钱。 2.OpenBrowserClaw 它有一种“把 AI 助手这件事做轻了”的感觉。现在很多人一提 Agent,第一反应就是要部署、要服务器、要折腾环境,门槛一下就上去了。 但这个项目是直接把浏览器变成运行场,很多事情一下子就简单了。你会发现,真正阻碍大多数人用上 AI 助手的,不一定是能力不够,而是前面的配置流程太烦。 像这种尽量不折腾基础设施、直接把能力塞进浏览器里的方案,我会很看好,因为它更接近普通人真正愿意用的形态。 3.给 Linux 做 Windows 11 风格剪贴板历史的项目 它特别典型:一个看起来不大、但用起来会很上头的需求。很多 Linux 工具的问题不是不能用,而是“能用,但不好用,也不好看”。 这个项目很讨巧,它抓的不是底层大创新,而是日常体验里的那个痛点:剪贴板历史、快捷呼出、多屏适配、GIF、表情这些东西,一旦做顺了,幸福感真的很强。 我一直觉得,开源世界最打动人的地方之一,就是总有人愿意为这种“别人觉得小,但自己每天真会用”的需求认真做产品。 4.AetherViz Master 现在很多人都在讲 AI + 教育,但大部分时候还是停留在“帮你写点内容”“帮你整理资料”这个层面。真正更有价值的,其实是把抽象知识变得更直观、更可感知。 像物理、数学、化学这些内容,很多时候不是学生不努力,而是你光靠文字和静态图真的不够。能把知识点直接转成 3D 交互网页,这件事本身就很有吸引力。 哪怕最后它不是一个大而全的平台,只要能把“理解成本”往下拉一点,我觉得就已经很有意义了。
sitin
1周前
针对 OpenAI Codex 最新推出的 Subagents 功能,Github 上最新出现了它的 awesome 系列项目“Awesome Codex Subagents”,收录 136+ 个专门针对软件开发各环节设计的 AI 助手,覆盖 10 大技术领域。项目采用 Codex 原生的 .toml 配置格式,可直接集成到 Codex 工作流中。 重温一下什么是 Subagent? Subagents 是领域专精、任务单一的 AI 协作者: · 独立上下文 — 每个 Subagent 拥有隔离的上下文窗口,避免任务间信息污染 · 显式委派 — 不会自动触发,需用户在提示词中明确指定调用哪个 Agent · 模型路由 — 根据任务复杂度自动选择合适模型 · 沙箱分级 — 审计类 Agent 为只读模式,开发类 Agent 可写入工作区 智能模型路由策略 gpt-5.4 — 用于深度推理场景 · 架构评审、安全审计、金融逻辑等复杂任务 · 示例:security-auditor、architect-reviewer、fintech-engineer gpt-5.3-codex-spark — 用于快速扫描场景 · 信息检索、轻量级研究、快速合成 · 示例:search-specialist、docs-researcher、agent-installer 沙箱模式设计 · Read-only 模式 — 审查类、审计类代理(如代码审查员、安全审计员),只分析不修改 · Workspace-write 模式 — 开发类、工程类代理(如后端开发者、DevOps 工程师),可创建和修改文件 -- 10 大类别全景 -- 01. 核心开发(11 个) 前端/后端/全栈开发者、UI 设计师、微服务架构师、API 设计师、Electron 桌面应用专家、WebSocket 实时通信工程师等 02. 语言专家(24 个) Python/TypeScript/Rust/Go/Java/C++/C#/Kotlin/Swift/PHP/Elixir 等语言专精 Agent,涵盖各主流框架(React、Vue、Angular、Django、Laravel、Rails、Spring Boot、Next.js 等) 03. 基础设施(15 个) DevOps 工程师、K8s 专家、Terraform/Terragrunt 工程师、Docker 专家、Azure/GCP/AWS 架构师、SRE、网络安全工程师、事件响应专家等 04. 质量与安全(16 个) 安全审计员、代码审查员、渗透测试员、性能工程师、混沌工程专家、可访问性测试员、合规审计员、架构评审员等 05. 数据与 AI(12 个) ML 工程师、LLM 架构师、MLOps 工程师、数据工程师、数据科学家、NLP 工程师、PostgreSQL 专家、Prompt 工程师等 06. 开发者体验(13 个) Git 工作流管理、文档工程师、重构专家、MCP 开发者、构建系统工程师、依赖管理专家、CLI 工具开发者、Slack 平台专家等 07. 专业领域(12 个) 区块链开发、游戏开发、IoT 系统、支付集成、量化分析、风险管控、SEO 优化、Microsoft 365 管理、嵌入式系统等 08. 业务与产品(11 个) 产品经理、业务分析师、技术写作、UX 研究员、内容营销、客户成功、项目管理、Scrum Master、销售工程师、法律顾问等 09. 元与编排(12 个) 多 Agent 协调器、工作流编排器、任务分发器、上下文管理器、性能监控器、错误协调器、知识合成器等 10. 研究与分析(7 个) 竞品分析师、市场研究员、趋势分析师、搜索专家、文档研究员、数据研究员、综合研究分析师等 最佳适用场景 · 大型项目需要多人协作式 AI 工作流 · 复杂任务需多 Agent 并行处理(如同时审查代码正确性、安全性和文档一致性) · 团队希望标准化常见的开发任务(PR 审查、Bug 调查、重构规划)
sitin
2周前
最近在 GitHub 看到一个挺有意思的项目:everything-claude-code。 它本质上不是一个简单的提示词合集,而是一整套 Claude Code 的完整配置工具箱。里面把 Agents、Skills、Hooks、快捷命令、Rules、MCP 全都打包好了。 简单理解就是:别人已经帮你把 Claude Code 调教成一个成熟的 AI 工程团队,你直接拿来用就行。 特点: 第一点是:很多人其实还没真正用对 Claude Code。 很多人把它当成一个“会写代码的聊天机器人”,让它写个函数、改个 bug。但这套配置的思路完全不一样——它把 Claude 拆成多个 Agent 角色。比如: ·Planner Agent:先规划架构再写代码 ·Code Reviewer Agent:提交前自动审代码 ·Safety / Testing Agent:专门盯质量 一下子就从“AI 写代码”,变成了 AI 团队在开发软件。 第二点是:工程化真的很重要。 很多人用 AI 编程遇到的最大问题其实不是模型能力,而是 上下文越来越乱,写到后面逻辑崩掉。这个仓库的做法是通过 Rules + Skills + TDD 流程,强制 AI 按 RED → GREEN → REFACTOR → VERIFY 的节奏推进。 说白了就是: 不是让 AI 随便写,而是把它 放进一个严格的软件工程流程里。 还有一个我挺喜欢的点是 MCP 的使用。 通过 GitHub MCP、Supabase MCP 这些工具,Claude 可以直接操作仓库、数据库、部署环境。很多原本要在 IDE、终端、数据库之间来回切换的事情,它可以一口气帮你做完。 总之,Claude Code 真正的威力,不是在“会写代码”,而是在“会组织开发流程”。
聊聊我现在的 vibe setup: - core dev agent:与 cc 的长程深度会话,详尽交互与核心产品 plan,直接在 main 上跑。 - research agents:根据我的 github star 和我自己的 x 书签写各种 plan,提交到 github issue - dev agents:只要存在 issue 必须根据对应的 issue 创建可行分支 - test agents:在所有分支不断 24/7 review 并提高测试覆盖率 - marketing agents:根据 commits 寻找宣传点(外部产品化的就是 shipcast)并制作文字图片和视频素材。 - hook agents:根据各种 webhook 实现 agents 之间的信息传递。 我的核心开发仍然是以和 cc 的长程会话为主,因为我觉得自己想不清楚的问题,让许多 agents 自己去研究也肯定想不清楚,这可能是目前唯一深度参与的 human in the loop 部分。 我最近在写 wanman 一人公司这个产品的时候发现,很多 agents matrix 强调产品的通用性,因为解决的工程问题都是相似的(见上一条推)但在用户真正使用产品的时候得到的交付产品,却存在着极大的不确定性,难以评估交付质量。这个问题我还没想到要如何使用 agents 来实现,我们面向的软件工程,从确定性延续到不确定性的架构,本身需要一段时间去适应,我在想,也许作为用户也在不断适应使用软件的心理预期变化。因此在目前,如果为人类用户设计不确定性较强,但同时又是面向大众需求的产品的时候,领域从极端收敛的方向开始实现,或许是个不错的思路。