开源我的 Vibe Coding 工作流，已有人靠它把项目做完了

## 前言 > 如果这篇文章对你有帮助，欢迎先去给仓库点个 Star：[**project-vibe-spec**](https://github.com/dnwwdwd/project-vibe-spec)，这对我是很大的鼓励，也让更多人能找到这个工具。 大家好，我是汉堡。 上一篇文章《如何从0到1 Vibe Coding 一个项目，并长期维护》里，我分享了自己踩坑之后沉淀出来的一套 Harness 体系——用文档治理、AGENTS.md、范围冻结和分阶段推进来驯服 Vibe Coding 的混乱。 文章发出去之后，有鱼友来问我：**多个 AI Agent 接力做项目，怎么让它们互相"知道"彼此做了什么？** 答案就在那篇文章里。**多 Agent 之间通信和协作，唯一的方式只有文档。** 在项目根目录维护好 Agent 的"说明书"——Codex/OpenCode 对应 `AGENTS.md`，Claude Code 对应 `CLAUDE.md`——Agent 启动时自动注入，啥也不用说就知道项目的一切。 有人照着做了，昨天来告诉我：**"牛逼，用了文章里的内容之后，AI 的产出就稳多了，现在已经把项目做完了，感谢大佬。"** 这让我很开心。所以今天这篇文章，我想介绍一个更进一步的东西——我把那套方法论直接做成了一个可以复用的 **Agent Skill**。 --- ## 为什么要做成 Skill？ 上篇文章写的是**思路和方法**，但每次新建项目，你还是得自己手写 AGENTS.md、搭 docs/ 目录结构、想文档命名规范…… 重复劳动，而且容易遗漏。 所以我把这套体系沉淀成了一个开箱即用的 GitHub 仓库： > **👉 [https://github.com/dnwwdwd/project-vibe-spec](https://github.com/dnwwdwd/project-vibe-spec)** 如果这个 Skill 对你有帮助，欢迎点个 Star，这对我是很大的鼓励。 --- ## 这个 Skill 解决什么问题？ 回顾一下 Vibe Coding 的几个典型困境： - **上下文膨胀**：代码越多，AI 越难理解全貌 - **耦合蔓延**：改一处牵一发而动全身 - **意图退化**：没有文档，几轮对话后你自己都忘了当初为什么这么设计 - **多 Agent 失忆**：换一个 Agent 工具，之前的上下文全部归零 这些问题都可以追溯到同一个原因——缺乏工程化的文档治理。 `project-vibe-spec` 提供了一套完整的项目规范模板，让你在开始写第一行代码之前，就把"地基"打好。 --- ## Skill 里有什么？ ### 1. AGENTS.md 模板 这是整个体系的核心。AGENTS.md 干的事情只有一件：**让 AI 知道你的编码哲学和项目规范，不用每次都重复交代。** 对于 Codex/OpenCode，启动时会自动将项目级别和全局的 AGENTS.md 注入当前对话上下文。你啥也不用说，Agent 就知道： - 项目的技术栈和架构 - 代码风格和命名规范 - 禁止的行为（比如不要擅自改架构、不要顺手加功能） - 文档优先级和冲突解决规则 - 完成标准（DoD） ### 2. 文档治理体系 一套完整的文档分类规范： | 文档类型 | 命名格式 | 用途 | | --- | --- | --- | | **REQ** 需求文档 | `REQ-YYYYMMDD-XX-*.md` | 新功能或大范围改造前必写 | | **PROG** 进度日志 | `PROG-YYYYMMDD.md` | 每天一日志，记录完成了什么 | | **BUG** 缺陷记录 | `BUG-YYYYMMDD-XX-*.md` | 发现 bug 立即记录 | | **BIZ** 业务决策 | `BIZ-YYYYMMDD-XX-*.md` | 业务流程或实现策略的确认 | | **DEV** 技术方案 | `DEV-YYYYMMDD-XX-*.md` | 复杂模块拆解、阶段实施方案 | 这套体系的价值： - **上下文外挂**：AI 每次对话前先读相关文档，不会丢失上下文 - **可追溯**：三个月后回来，还能知道当初为什么这么设计 - **可交接**：换一个 AI 模型或工具，读一遍文档就能接手 ### 3. 分阶段推进模板（Phase 0 → Phase N） 大项目一口气让 AI 实现 = 灾难。必须拆阶段，每个阶段有明确的 DoD（Definition of Done）： | 阶段 | 内容 | DoD | | --- | --- | --- | | **Phase 0** | 文档体系初始化 | AGENTS.md、README.md、docs/ 结构就绪 | | **Phase 1** | 后端骨架 | 服务可启动、配置可读、数据库可初始化 | | **Phase 2\~3** | 核心链路 | 端到端链路跑通 | | **Phase 4** | 业务 API | 接口字段对齐、错误响应统一 | | **Phase 5** | 前端工程化 | 拆页拆组件、接入真实 API | | **Phase 6\~7** | 收尾上线 | 链路闭环、打包部署 | 每个 Phase 结束必须达到 DoD 才能进入下一阶段。这个纪律不能破。 ### 4. 范围冻结清单 v1 要做什么、不做什么，在一开始就写死。一旦范围冻结，后续开发中 AI 想"顺手"加功能时，你就可以说：**"不在 v1 范围，先记 REQ，下个版本再说。"** --- ## 怎么用？ 直接 clone 或 fork 这个仓库，把模板文件复制到你的项目根目录，按照说明填写你的项目信息即可。 ```bash git clone https://github.com/dnwwdwd/project-vibe-spec ``` 然后把 `AGENTS.md`、`docs/` 目录结构复制到你的项目里，根据你的项目实际情况填写内容。 --- ## 真实反馈 这套方法论有人真的用了。 有读者看了上篇文章之后，把这套文档治理的思路用到了自己的项目上。几天后来反馈：**AI 的产出稳定了很多，项目已经做完了。** 我写这篇文章、做这个 Skill，就是想把这套工程化方法变成别人可以直接用的东西，不用每个人再从头踩一遍。 --- ## 最后 Vibe Coding 的问题不在 AI 的能力，在我们给 AI 的上下文质量。 一个没有文档、没有规范、没有阶段划分的项目，再强的模型也推不动。换上完整的 Harness 体系——文档治理、阶段划分、范围冻结——用中等模型也能稳定推进。 `project-vibe-spec` 就是帮你把这个"地基"快速搭起来的工具。 仓库地址：<https://github.com/dnwwdwd/project-vibe-spec> 如果觉得有用，可以点个 Star，或者在评论区聊聊你的使用体验。 --- ## 相关文章 - [如何从0到1 Vibe Coding 一个项目，并长期维护](https://blog.hejiajun.com) --- *我的博客：[https://blog.hejiajun.com](https://blog.hejiajun.com)*

RKit：我常用的 uTools 工具的“轻量替代”

我以前一直用 `uTools`。 说实话，它在我这儿属于那种“装机必备”级别的工具：搜东西、翻译、截图、OCR、剪贴板……一堆日常零碎事，按个热键就能搞定。 但后来 uTools 越来越臃肿，也开始限制插件数量，这我还能忍，毕竟我平时用的插件也不多，最让我绷不住的是：**开始强制登录**了。 我不是说登录就一定不好，我只是很不喜欢“一个本来用来提升效率的小工具”，慢慢变成“需要账号体系才能用”的东西 于是我就去找“uTools 平替”。 我试了 `zTools`，确实和utools差不多，但用了一段时间总觉得有些地方不太对：要么是某个流程不顺手，要么是细节不符合我的习惯。也不是不能用，就是用的时候会忍不住嘀咕一句：“要是这里能这样就好了……” 结果我一想：我每天高频用的功能就那几个，**干脆我自己做一个算了**。 于是就有了 `RKit`。 --- ## RKit 是个啥？一句话 `RKit` 就是一个 **macOS 上的命令面板**(后面也会做 windows)，有点像 Spotlight： 按热键 → 弹出一个小面板 → 执行动作。 我不想做插件市场，也不想做一堆花里胡哨的功能。 我就想把我每天用的那几个能力做得**顺手、够快、够稳定**。 --- ## 它能干啥？就我常用的这几个 我现在最常用的是这些： - `截图`：区域截图 → 自动复制到剪贴板 → 顺手还能进内置编辑器改两笔 - `OCR`：对最近一次截图做文字识别（macOS 自带 `Vision`） - `翻译`：默认 Google GTX（不用 key），也可以配 Deeplx（自己搭个接口那种） - `剪贴板历史`：文本 + 图片，支持置顶/搜索，还能一键暂停采集 10 分钟 - `设置`：语言、热键录制、开机自启动、清理历史这些 你会发现，它就是“uTools 里我真正每天在用的那几个东西”。  --- ## 我做它最在意的点 ### 1）快：要像 Spotlight 那样“按下就出来” 默认热键是： - `Option + Space`：呼出/关闭 - `Esc`：关闭 我希望它是那种你不需要思考的动作： 手指一按，它就出现；你输入，回车，事情结束。 ### 2）别打扰：别把我从当前桌面/当前软件拽走 有些工具的面板会乱跳桌面，或者截图完又把焦点抢回去，这种我很难忍。 RKit 的目标是：**你在哪儿用，它就在哪儿出现**，尽量别干扰你的主工作流。 ### 3）本地优先：默认不联网 我个人比较敏感的一点是： 这种工具一旦开始“强制登录”，我就会下意识担心：我输入的东西、剪贴板、截图，会不会被上传、被统计、被分析？ RKit 的原则很简单： - 默认本地优先 - 只有“翻译”可能要联网（你选的翻译服务决定） --- ## 怎么装？（现在是未签名 ZIP） RKit 目前走的是 **未签名 ZIP** 发布（主打一个快，先让大家用起来）。 ### 安装步骤 1. 从 GitHub Releases 下载 `RKit.app.zip` 2. 解压得到 `RKit.app` 3. 把 `RKit.app` 拖到 `/Applications` 4. 打开运行 ### 如果被 Gatekeeper 拦了（无法打开 / 提示“已损坏”） 先确认你已经把 `RKit.app` 拖到了 `/Applications`，再执行： ```bash xattr -dr com.apple.quarantine /Applications/RKit.app ``` 然后 Finder 里右键 `RKit.app` → `打开`。 --- ## 权限这块：截图一定会要“屏幕录制” 截图功能需要 macOS 的“屏幕录制”权限： `系统设置 → 隐私与安全性 → 屏幕录制 → 勾选 RKit` 这块没啥好绕的，系统规则就是这样。 我能做的就是把引导写清楚、交互做顺，不搞那些“偷偷申请一堆你用不到的权限”。 --- ## 后续计划 我不会把 RKit 做成“全能工具”，我更想把它做成一种**很顺手的日常习惯**： 有什么我高频使用的功能，我会添加进去 也会尽快开发 windows 版本 --- ## 致谢 - Deeplx（DeepLX）：<https://github.com/OwO-Network/DLX> 感谢 DeepLX 开源项目：它使得在自建环境中通过本地 API 方式使用 DeepL 的免费网页翻译成为可能。 我就是使用本地部署的地址：  --- ## 最后 做 RKit 的起点其实很简单： 我只是想要一个“不臃肿、不强制登录、只做我常用功能”的工具。 如果你也跟我一样日常使用这几个工具，欢迎来试试看。 如果遇到什么问题，欢迎随时指出。 如果你觉得项目对你有帮助，欢迎点个Star，感谢！！ 项目地址：[https://github.com/Han-GR/rkit](https://github.com/Han-GR/rkit) 下载地址：[https://github.com/Han-GR/rkit/releases/download/v1.0.1/RKit.zip](https://github.com/Han-GR/rkit/releases/download/v1.0.1/RKit.zip)

如何从0到1 Vibe Coding 一个项目，并长期维护

我是汉堡。上篇文章《我的第一个 Vibe Coding 项目正式上线，Notus——原生 AI 笔记应用，且完全开源》结尾我说过，要写一篇关于如何持续 Vibe Coding 可长期维护项目的文章。这篇就是。 以下内容来自我自己的血泪教训和成功经验，希望能帮到正在 Vibe Coding 或准备入坑的人。 --- ## 一、我的 AI 博客项目是怎么死的 去年夏天，我买了 Trae 的会员版，打算自己开发一个 AI 博客功能，包含博客摘要、知识库、SEO 这些。刚开发的时候兴奋得很，看着功能一个一个被实现，越做越有干劲，周末好几次熬到凌晨三四点，差点熬穿了。甚至还幻想靠这个赚钱。 但很可惜，这个项目**夭折了**。 那会儿刚接触 Vibe Coding，对工程管理和 harness 相关的知识**极度欠缺**。每次都是想一个功能就让 AI 实现一个，AI 的上下文约等于没有。导致： - 改完 A，B 出问题 - 改完 B，C 又出问题了 - 改完 C，A 又挂了 无限循环，最后心态崩了，维护不过来就放弃了。 --- ## 二、Vibe Coding 的本质困境 Vibe Coding 有一个很形象的比喻——**抽卡游戏**。 刚开始开发的时候，看着自己的想法一个个被实现，就像抽卡前期中奖概率高得很，爽感拉满。但越到后面越难"中奖"： 1. **上下文膨胀**：代码量越大，AI 越难理解全貌，每次改动都是盲人摸象 2. **耦合蔓延**：组件之间相互依赖，改一处牵一发而动全身 3. **意图退化**：没有文档记录，几轮对话之后你自己都忘了当初为什么这么设计 4. **红利消失**：前期快速出功能的爽感过去后，维护成本指数级上升 以上所有问题指向同一个根源：**缺乏工程化管理。** 这个问题可以解决。下面就是我沉淀下来的方案。 --- ## 三、工欲善其事，必先利其器 工程化管理之前，先聊工具和模型的选择。 Vibe Coding 的效果，首先取决于你用的 Coding Agent 和 AI 模型。我个人推荐这几个 Agent 工具： - **Codex**（我的主力）/ **OpenCode**：启动时自动注入项目级别和全局的 AGENTS.md，Agent 啥也不用说就知道项目的一切 - **Cursor**：适合轻量级改动和代码补全 - **Claude Code**：Agent 能力强，适合复杂任务 模型方面，推荐 **GPT 5.6 Terra High、GLM 5.2、Claude 5** 等一线模型。 使用策略上，**用最强的模型做规划和设计，用中高模型做编码。** 比如用 Claude Opus 或 GPT 5.6 Sol High 来写项目的需求文档、总技术文档和各功能模块的实现文档——这些"地基"级别的产出，必须交给最强的脑子。具体的编码实现，交给中高模型来执行。 工具和模型选好了，下面聊工程化管理。 --- ## 四、规划永远比写代码重要一万倍 相信绝大多数人在没 AI 写代码时都喜欢先写后端，再写前端，包括我自己也是如此。但规划和写代码，到底哪个放在前面？ 盖房子最重要的是地基，地基打好了房子才能稳。求职市场里，架构师的工资永远比程序员高。规划和设计的份量，不用多说了。 **在让 AI 写一行代码之前，先用最强模型把需求文档、技术方案和各功能模块的实现文档写清楚。** 这些文档就是你的"地基"。 不一定每处都需要规划得那么细致。文档写得过于事无巨细，反而会让中等模型在执行时缺少自主性和发散性思维，变成了纯粹的"翻译机"。把握好粒度，关键路径细化，边缘逻辑给 AI 留发挥空间。 --- ## 五、合理的数据库表设计 在没有 AI 写代码的时代，数据库设计是顶要紧的步骤。你对业务的理解会直接体现在数据库设计上，而数据库设计的好坏会影响项目业务的复杂程度，进一步影响代码的可读性和可维护性。 用 AI 出方案时，**一定要 review 表的设计**。**能用一个表解决的，就不要用多个表。** 如果 AI 给出的方案不合理，果断和它沟通，选择较优的方案。 同时还要考虑系统后续的拓展功能，防止数据表频繁增删字段，甚至被迫重构表设计。同理，整体方案设计也要把后续拓展的可能性考虑进去——这和规划优先的思路是一脉相承的。 --- ## 六、写代码的先后顺序 在没有 AI 的时候，我习惯先写后端，再写前端，相信大多数人也是这样。但用 AI 写代码，**先写前端，再写后端。** 具体做法： 1. **把项目的完整需求文档发给 AI**，沟通需要多少个页面，每个页面有哪些详细功能。把沟通出的内容补充到需求文档中。 2. **出原型图。** 将需求文档发给 GPT 或 Claude 产出原型图。我个人强烈推荐 Claude Design——审美确实好，原型图不会偏离需求文档要求；而且产出的是 React 代码，可以直接用 Claude 或 GLM 5.2 搭建前端工程跑起来看到页面。如果用 GPT，则用 GPT Image 2 生成设计图，再通过 Codex 像素级还原，但需要注意设计图可能会偏离需求文档的功能。 3. **模拟数据，验证动态页面。** 根据数据库表 DDL 在前端模拟一些数据，测试页面是否全是动态渲染的。 到了这一步，你对 Vibe Coding 上瘾了。 先写后端的时候，大片代码不停输出却看不到任何视觉成果，难免有些失落和不安，总感觉 AI 没有遵循文档的要求。**先写前端让你在最短时间内看到产品长什么样。** 那种即时的成就感和掌控感，完全不一样。反正我自己是这么觉得的，哈哈哈哈。 --- ## 七、好的上下文与文档管理 经过 AI 博客项目的失败，我在开发 Notus 和后续项目的过程中，逐渐沉淀了一套 **Harness 体系**——给 AI 配一个"项目管理大脑"。 ### 7.1 AGENTS.md 模型都是有上下文限制的，虽然现在普遍一百万的上下文窗口，但放到一个庞大的项目中，根本不够看，特别是 GPT 这种 300k+ 的上下文更是难受。一般我自己一个对话最多实现 3\~4 个需求，防止 Agent 频繁压缩上下文导致准确度丢失。 控制对话长度之外，**让 AI 在每次对话开始时就能理解项目的一切**，这才是关键。 `AGENTS.md` 就是干这个的。每次开始一个新项目或维护旧项目时，我都会手写一个 AGENTS.md。对于 Codex/OpenCode 来讲，启动时会自动将项目级别和全局的 AGENTS.md 注入当前对话上下文——你啥也不用说，Agent 就知道关于项目的一切。 下面是一个脱敏后的 AGENTS.md 示例，思路供参考： ```plaintext [AGENTS.md](http://AGENTS.md) 本文件只规定 AI 编码 Agent 在项目仓库中的行为。产品需求、技术方案、数据库表和实施细节由项目文档维护，本文件不重复抄写。 **1. 基本行为** - 始终使用中文回复；代码、标识符、API、数据库字段和提交信息使用英文。 - 先查项目文档、现有代码和测试，再决定如何实现。文档已有答案时，不重复询问用户。 - 只修改当前任务涉及的内容，不顺手做无关重构，不为尚未发生的需求提前建设复杂抽象。 - 不能在当前任务中完成的部分要明确说明，不承诺后台交付。 **2. 权威文档** - 优先读取 `docs/` 中的 Markdown 版本：PRD（做什么）、技术设计文档（怎么设计）、实施文档（怎么推进）、进度文档（现在做到哪里）。 - 冲突优先级：AGENTS.md → 用户本次明确要求 → PRD → 技术设计 → 实施文档 → 进度文档 → 现有代码。 - 发现代码与文档不一致时，不得静默猜测，按高优先级文档确认目标，说明差异并同步修正。 **3. 开始任务前必须自主查询** - 查看进度文档，确认当前阶段、下一任务、前置依赖和阻塞。 - 在 PRD 中搜索相关页面、功能名和验收标准。 - 在技术设计中搜索相关模块、表、API、外部依赖和约束。 - 检查受影响代码、迁移和测试，沿用仓库已有模式。 **4. Vibe Coding 工作流** - 每个任务按最小纵向切片完成：文档定位 → 数据模型/迁移 → 后端服务 → API → UI → 测试 → 文档与进度。 - 数据库变化先写迁移和约束，再改 ORM、服务和 API。 - 需要改变产品范围、架构、表结构或实施顺序时，先更新对应文档，再编码。 - 一次优先交付一个可验证闭环，不并行铺开大量半成品。 **5. 代码结构与依赖方向** - domain/ 不导入具体框架或 SDK。 - API 不直接写 SQL，也不直接调用第三方数据源。 - 配置统一加载，不在业务代码中散读环境变量。 **6. 完成标准** - 相关测试通过；数据库迁移可从空库执行也能从上一版本升级。 - 外部 Provider 的失败、超时、空数据和过期状态已处理。 - 完成后必须更新进度文档的状态、证据、遗留问题和下一任务。 - "代码能运行"不等于完成；测试、文档和进度没有同步时，任务仍未完成。 **7. Git 与文档同步** - 未经用户明确授权，不推送远程、不发布版本。 - 提交只包含当前任务相关修改，不混入无关格式化或重构。 - 不提交 .env*、密钥、数据库、备份、日志、依赖目录和构建产物。 - AGENTS.md 只维护 Agent 行为和代码边界，不复制项目文档的细节。 ``` AGENTS.md 干的事情就一件：**让 AI 知道你的编码哲学和项目规范，不用每次都重复交代。** ### 7.2 文档治理 文档治理是 harness 体系的核心模块。**在让 AI 写代码之前，先让它把需求写清楚。** 我采用的文档分类体系： | 文档类型 | 命名格式 | 用途 | | --- | --- | --- | | **REQ** 需求文档 | `REQ-YYYYMMDD-XX-*.md` | 新功能或大范围改造前必写，明确范围、验收标准 | | **PROG** 进度日志 | `PROG-YYYYMMDD.md` | 每天一日志，记录完成了什么、遇到了什么问题 | | **BUG** 缺陷记录 | `BUG-YYYYMMDD-XX-*.md` | 发现 bug 立即记录，关联来源 REQ | | **BIZ** 业务决策 | `BIZ-YYYYMMDD-XX-*.md` | 业务流程或实现策略的确认和调整 | | **DEV** 技术方案 | `DEV-YYYYMMDD-XX-*.md` | 复杂模块拆解、阶段实施方案 | 关联规则： - **PROG 必须引用相关 REQ/BUG**，保证进度可追溯 - **BUG 必须引用来源 REQ**，知道这个 bug 是从哪个需求引入的 - **BIZ 必须引用对应 REQ**，业务决策不能悬空 这套体系的作用： 1. **上下文外挂**：AI 每次对话前先读相关文档，就不会丢失上下文 2. **可追溯**：三个月后回来，你还能知道当初为什么这么设计 3. **可交接**：换一个 AI 模型或工具，读一遍文档就能接手 ### 7.3 控制 Vibe Coding 的边界 Vibe Coding 的一个诱惑也是陷阱："顺手加一个功能"。 你以为只是"顺手"，但 AI 的上下文是有限的。每多一个功能点，就会引入新的耦合、新的边界情况、新的 bug 风险。 **范围冻结**就是在一开始把 v1 要做什么、不做什么写死。比如 RepoRadar 项目： **纳入 v1 的**：GitHub Search 抓取、规则过滤、去重入库、Agent 分析、仓库列表、配置中心、飞书推送... **明确不进 v1 的**：增速监控、批量提交、导出 CSV/Markdown、语义去重、多数据源接入... 一旦范围冻结，后续开发中 AI 想"顺手"加功能时，你就可以说：**"不在 v1 范围，先记 REQ，下个版本再说。"** ### 7.4 分阶段推进：Phase 0 → Phase N 大项目一口气让 AI 实现 = 灾难。必须拆阶段，每个阶段有明确的 **DoD（Definition of Done）**。 一套典型的阶段划分： | 阶段 | 内容 | DoD | | --- | --- | --- | | **Phase 0** | 文档体系初始化 | AGENTS.md、README.md、docs/ 结构就绪 | | **Phase 1** | 后端骨架 | 服务可启动、配置可读、数据库可初始化 | | **Phase 2** | 核心链路 1 | 端到端链路跑通 | | **Phase 3** | 核心链路 2 | 同上 | | **Phase 4** | 业务 API | 接口字段对齐、错误响应统一 | | **Phase 5** | 前端工程化 | 拆页拆组件、接入真实 API | | **Phase 6** | 通知与配置 | 链路闭环、热重载 | | **Phase 7** | 打包上线 | Dockerfile、持久化、基础回归 | 每个 Phase 结束必须达到 DoD 才能进入下一阶段。**这个纪律不能破。** --- ## 八、实战项目 Notus 下面是我怎么用这套体系把 Notus 从 0 到 1 做出来的。 ### 8.1 项目背景 Notus 是一个本地 AI 原生笔记应用，核心功能是文档编辑、知识库和 AI 创作。对标的其实是 notebookLM 和 YouMind，但完全开源、免费、数据本地存储。开发周期大约 20 天（非全职）。 ### 8.2 怎么用 Harness 体系 **文档先行。** 在写第一行代码之前，我先写了 PRD（产品需求文档），明确了 v1 范围、核心功能、技术选型。 **AGENTS.md 就位。** 项目初始化时就写好 `AGENTS.md`，让 AI 每次对话都先理解项目结构和规范。内容包括项目采用 Tauri + React 架构、前端组件目录结构、代码风格要求，以及禁止的行为（比如不要擅自改架构）。 **分模块推进。** 不是一口气让 AI 写整个应用，而是按模块来：先搭编辑器核心（Markdown 解析与渲染），再建知识库（文档索引 + 语义检索），最后做 Agent 创作（多文件改写 + 风格学习）。 ### 8.3 上下文管理 这是 Notus 开发中踩得最深的一个坑。 当项目代码量上去之后，AI 的上下文窗口根本塞不下全部文件。我的做法是： - **按需加载**：只把当前任务相关的文件喂给 AI，其余文件通过文档索引让 AI 知道"存在但不加载" - **摘要压缩**：对历史对话进行摘要压缩，保留关键决策和上下文 - **意图识别**：先让 AI 判断用户是想改写文章还是单纯闲聊，匹配不同策略 这些经验后来也直接体现在了 Notus 的 Agent 工程模块里。 --- ## 九、实战项目 RepoRadar ### 9.1 项目背景 RepoRadar 的起源其实很接地气——我在懒猫搬砖做副业，为了方便，写了个应用去爬 GitHub 开源仓库，自动判断能不能搬，然后推送到飞书群里。 但这次不一样。这次我一开始就用上了完整的 harness 体系。 ### 9.2 Harness 落地实践 **文档体系先行（Phase 0）**：在写任何代码之前，先把 PRD、AGENTS.md、docs/ 目录结构全部建好。PRD 作为总纲永久保留。 **范围冻结**：v1 只做 GitHub Search 抓取、规则过滤、Agent 分析、飞书推送。增速监控、批量提交、语义去重等全部推到后续版本。 **分阶段 7 步走**：从文档体系初始化 → 后端骨架 → 采集链路 → 分析链路 → 业务 API → 前端 → 打包上线，每一步都有明确的 DoD。 **接口契约先行**：在写代码之前先定义 API 契约（GET /api/repos、POST /api/submit 等），前后端以契约为准各自开发互不阻塞。 ### 9.3 和之前失败的 AI 博客项目对比 | 维度 | AI 博客（失败） | RepoRadar（成功） | | --- | --- | --- | | 文档 | ❌ 无，想到哪做到哪 | ✅ PRD + AGENTS.md + docs/ | | 范围 | ❌ 不断加功能 | ✅ v1 范围冻结 | | 阶段 | ❌ 无规划，一把梭 | ✅ Phase 0-7 分步走 | | 上下文 | ❌ 约等于没有 | ✅ 按需加载 + 摘要压缩 | | 结果 | 心态崩了 | 在掌控之中 | --- ## 十、心态 最后聊聊心态。 Vibe Coding 做久了，最大的坑不是 AI 不够强——是你自己的欲望。看到一个好玩的功能就想加，看到别人开源了什么就想自己也搞一个。但代码是一行一行堆出来的，每多一个功能，维护成本就往上翻。能复用的就别自己造，能用现成库的就别手写。我踩过太多这种坑：花三天写了个工具函数，后来发现 github上早就有成熟方案，比自己写的还好。 项目做着做着没动力了，我经历过好几次。归结下来就两个原因。 一个是**无力维护**。代码越堆越多，改一个地方炸三个地方，每次打开项目都有心理负担。这种情况只能靠前面说的工程化管理兜底——文档、范围冻结、分阶段推进。别等烂摊子收拾不了了才想起来，那时候已经晚了。 另一个是**不赚钱**。花了几百个小时做的项目，上线后用户没几个，更别提收入了。大部分 side project 都这样，没办法。我的态度是：练手的项目，学到东西就算回本；真想赚钱，立项前就想清楚谁来买单、凭什么买单。别一边写代码一边幻想"做完了就有人用了"——大多数时候不会。 --- ## 个人博客 我的博客：<https://blog.hejiajun.com> --- *下一篇预告：Notus 的 Agent 工程细节——上下文压缩、意图识别和工具调用的具体实现。*

code-documents-auto-skill v3.2.0：图片也能自动归类了，icon/logo终于归对了

## 前言 v3.1.2 带来了 `/docs-check` 自动检测和迁移旧文档结构，但有个问题一直被忽略：**项目里的图片文件全是盲区**。 `icon.svg`、`logo.png`、设计稿、架构图、测试截图……这些图片散落在项目各处，`/docs-check` 只扫 `.md` 文件，图片全部被跳过。更离谱的是，`icon.svg` 和 `favicon.ico` 被一视同仁地排除——可 icon 是设计资产啊！ v3.2.0 来解决这个问题。 ## v3.2.0 更新概览 🖼️ 图片归类支持 │ 🎨 icon/logo 归 design/ │ 🏷️ 关键词规则升级 📝 代码变更：+231 行 / -53 行，5 个文件 ## 🌟 核心更新 ### 1. 图片文件也能归类了 之前只扫 `.md`，现在扫描范围扩展到： **/*.md → **/*.md + **/*.png + **/*.jpg + **/*.jpeg + **/*.gif + **/*.webp + **/*.svg 归类示例： - docs/architecture-diagram.png → technical/ - docs/ui-mockup.png → design/ - docs/test-screenshot.png → testing/ - docs/flowchart.svg → design/ - icon.svg → design/ - logo.svg → design/ ### 2. icon/logo 终于归对了 旧版：icon.svg 和 favicon.ico 一样被排除 ❌ 新版：只有 favicon.* 被排除，icon.* / logo.* 归类到 design/ ✅ | 文件 | 旧版 | v3.2.0 | |------|------|--------| | favicon.ico | 排除（工程资源） | 排除（工程资源）✅ | | favicon.png | 排除 | 排除 ✅ | | icon.svg | 排除 ❌ | → design/ ✅ | | logo.svg | 排除 ❌ | → design/ ✅ | | icon-home.png | 排除 ❌ | → design/ ✅ | | nav-icon.svg | 排除 ❌ | → design/ ✅ | ### 3. 关键词规则大升级 新增关键词，图片和文档通用： - icon、logo、图标 → design/ 🆕 - flowchart、流程图、diagram → design/ 🆕 - screenshot、截图 → testing/ 🆕 - architecture、er-diagram、schema → technical/ 🆕 - bug、问题 → testing/ 🆕 - 无明确关键词的图片 → design/（默认）🆕 ### 4. 图片归类特殊规则 - 🎨 默认归 design/ — 图片大多与设计相关 - 🐛 含 screenshot/bug → testing/ - 🏗️ 含 architecture/er-diagram → technical/ - 📊 含 flowchart/mockup → design/ ## 📦 完整指令清单（6 个） | 指令 | 说明 | |------|------| | /docs <描述> | 智能助手，自动识别意图 | | /docs-scan | 全量扫描（文档 + 图片），生成完整文档 | | /docs-update | 增量更新，只更新变更部分 | | /docs-check | 检测文档结构 + 自动迁移 + 图片归类 | | /docs-prepare <任务> | 开发前准备，输出开发方案 | | /docs-archive | 归档模式，更新文档 | ## 🔄 升级方法 /plugin uninstall code-documents-auto@code-documents-auto-skill && rm -rf ~/.claude/plugins/cache/code-documents-auto-skill && /plugin install code-documents-auto@code-documents-auto-skill 然后跑一次 /docs-check 即可！ ## 💎 使用小贴士 1. 升级后跑一次 /docs-check，项目里散落的图片会被自动归类 2. 纯前端项目图标多，现在 icon/logo 都能正确归到 design/ 了 3. 测试截图放项目里也没问题，screenshot 关键词自动归 testing/ ## 链接 GitHub 仓库：https://github.com/Leo-skye-taylor/code-documents-auto-skill 如果这个项目对你有帮助，请给个 Star ⭐ --- 从 v3.1.2 到 v3.2.0 的完整变更日志：https://github.com/Leo-skye-taylor/code-documents-auto-skill/compare/v3.1.2...v3.2.0

code-documents-auto-skill v3.1.2：新增 /docs-check，一个命令自动修复旧文档结构

# code-documents-auto-skill v3.1.2：新增 /docs-check，一个命令自动修复旧文档结构 ## 前言 上次 v3.1.1 发布了智能助手 `/docs`，一个命令让 AI 自动识别意图。这次 v3.1.2 解决了一个更实际的问题：**从旧版升级上来的项目，文档结构全是旧的，手动迁移太痛苦**。 于是 `/docs-check` 诞生了——检测 + 自动迁移，零手动操作。 ## v3.1.2 更新概览 ``` 📦 1 个新指令 │ 🚀 4 大新特性 │ 🐛 3 个问题修复 📝 代码变更：+2083 行 / -189 行，9 个文件 ``` ## 🌟 头号新功能：`/docs-check` ### 检测 + 自动迁移 ```bash $ /docs-check 🔧 文档结构检测 + 迁移完成 ✅ changelog 结构: ❌ → ✅ ✅ 表格格式: 5 列 → 8 列 ✅ docs/ 子目录: 缺失 → 已创建 ✅ 标题质量: 不合格 → 已改进 ``` 检测范围和自动修复对照： | 检测项 | 旧状态 | 修复后 | |--------|--------|--------| | changelog 结构 | 单文件 | 文件夹 + 6 个核心文档 | | 表格格式 | 5 列 | 8 列（含"描述"列） | | docs/ 子目录 | 缺失 | 5 个标准子目录已创建 | | 标题质量 | 只填"feat" | 从文件夹名改进标题 | ## ✨ 四大新特性 ### 1. 智能文档归类 **旧行为：** 扫到 1 个文档问 1 次，用 cp 复制（原位置保留双份文件） **新行为：** 扫到 10 个文档只问 1 次，用 mv 移动（原位置不再保留，更清爽） 关键改进： - 🔄 **mv 替代 cp** — 原位置不再保留双份文件 - 🚫 **自动排除** `CLAUDE.md` 和 `AGENTS.md` — 工作流文件留在原位 - 📦 **批量处理** — 10 个文档 = 1 次提示，不是 10 次 ### 2. 前端项目智能识别 一个项目，一次扫描，只生成你需要的文档： | 项目类型 | database/ | middleware/ | |:---:|:---:|:---:| | 🎨 纯前端 | ❌ 跳过 | ❌ 跳过 | | ⚙️ 纯后端 | ✅ 生成 | ✅ 生成 | | 🌐 全栈 | ✅ 生成 | ✅ 生成 | | 📚 库/工具 | ❌ 跳过 | ✅ 生成 | | 🖥️ 桌面/移动 | ❌ 跳过 | ❌ 跳过 | ### 3. 统一 Changelog 结构 首次扫描现在和归档使用相同的文件夹结构，终于一致了： ```diff ❌ 升级前 (v3.1.0): changelog/ └── 2026-06-16-initial-scan.md ← 单文件 ✅ 升级后 (v3.1.2): changelog/ └── 2026-06-16-initial-scan/ ├── overview.md ├── files.md ├── technical.md ├── impact.md ├── testing.md └── deployment.md ``` ### 4. 升级 Changelog 表格 标题列不再只填 "feat"，现在有实际描述了： ```diff - | 2026-06-16 | feat | ... | + | 2026-06-16 | 添加智能助手命令 | 新增 /docs 统一入口 | feat | commands | AI | done | ``` ## 📦 完整指令清单（6 个） | 指令 | 说明 | |------|------| | `/docs <描述>` | 智能助手，自动识别意图 | | `/docs-scan` | 全量扫描，生成完整文档 | | `/docs-update` | 增量更新，只更新变更部分 | | `/docs-check` | **新增！** 检测文档结构并自动迁移 | | `/docs-prepare <任务>` | 开发前准备，输出开发方案 | | `/docs-archive` | 归档模式，更新文档 | ## 🔄 升级方法 ```bash # 一行命令升级 /plugin uninstall code-documents-auto@code-documents-auto-skill && \ rm -rf ~/.claude/plugins/cache/code-documents-auto-skill && \ /plugin install code-documents-auto@code-documents-auto-skill ``` 然后在已有项目中跑一次： ```bash /docs-check # ✨ 自动迁移到 v3.1.2 格式 ``` ## 💎 使用小贴士 1. 把 `/docs-check` 加入团队 PR 合并后的工作流 2. 日常开发直接用 `/docs <描述>`，让 AI 智能路由 3. 纯前端项目用 `/docs-scan` 现在更快了，跳过无关文档 ## 链接 GitHub 仓库：https://github.com/Leo-skye-taylor/code-documents-auto-skill 如果这个项目对你有帮助，请给个 Star ⭐ --- **从 v3.0.0 到 v3.1.2 的完整变更日志**：https://github.com/Leo-skye-taylor/code-documents-auto-skill/compare/v3.0.0...v3.1.2

告别丑陋的 Swagger UI，Coco 给你的 Go API 换上优雅新衣

Hello，大家好，这里是小nuo😎。 小nuo在实习的时候发现，Java 中有 Knief4j 渲染 Swagger 方便 Javaer 调试和提供接口给到前端或者测试等人。但是我在使用 Go 的时候发现没有一款让我满意的，所以自己开发了一个。   ## 先看效果 ✨   > 现代化、优雅、流畅 - 这才是你 Go 应用程序的 API 文档应有的样子   ## 你是否也遇到过这些问题？   通过 swaggo 或者 huma 写完 Go API 后： - 😫 Swagger UI 界面丑陋，用户体验差 - 🤯 如果要自己弄界面，又需要额外部署前端服务，麻烦 - 😤 如果用 Postman 或者 Apifox 文档和代码分离，维护困难 **是时候换一个方案了！**   ## 认识 Coco 🥥 <p align="center"> <img src="https://raw.githubusercontent.com/leehainuo/coco/main/docs/images/coco.png" alt="Coco 文档界面 - 亮色主题" width="175" > </p>  **Coco** 是一个专为 Go 开发者打造的 OpenAPI 文档渲染器，让 API 文档变得优雅且易用。   ### 核心亮点 🌟 - **⚡ 快速上手** - 三行代码完成集成 - **🔌 全框架可用** - 支持 Gin、Echo、Fiber、Chi、net/http 等所有框架 - **🎨 颜值即正义** - Vue 3 + TailwindCSS 精心打磨的界面 - **🧪 内置测试** - 无需 Postman，文档里直接测试 API - **🌓 主题切换** - 深色浅色主题，随心选择 - **🚀 零依赖集成** - 纯 Go 实现，前端完全内嵌到二进制 - **🌍 多语言** - 内置中英文，可扩展 - **📝 请求历史** - 自动保存测试记录   ### 对比一下 | 特性 | Swagger UI | ReDoc | **Coco** | |------|-----------|-------|----------| | 界面美观度 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | | Go 集成难度 | 中 | 中 | **超简单** | | 依赖项 | 需要前端资源 | 需要前端资源 | **零依赖** | | API 测试 | ✅ | ❌ | **✅** | | 主题切换 | ❌ | ✅ | **✅** | | 请求历史 | ❌ | ❌ | **✅** | | 部署方式 | 需要额外部署 | 需要额外部署 | **单二进制** | ## 快速上手 ⚡ ### 安装 ```bash go get github.com/leehainuo/coco ```` ### 基础使用 **只需三行代码！** ```go import "github.com/leehainuo/coco"   // 挂载文档路由 mux.Handle("/docs/", coco.New("./openapi.json")) ``` 启动服务，访问 `http://localhost:8000/docs/` 就能看到漂亮的文档了！ ### 与 Gin 集成 ```go package main   import ( "github.com/gin-gonic/gin" "github.com/leehainuo/coco" )   func main() { r := gin.Default() // 你的 API 路由 r.GET("/api/users", getUsers) r.POST("/api/users", createUser) // 挂载 Coco 文档 r.Any("/docs/*any", gin.WrapH(coco.New("./docs/swagger.json", coco.Title("我的 API 文档"), coco.Lang("zh"), coco.Theme("auto"), ))) r.Run(":8000") } ``` ### 配置选项 ```go coco.New("./openapi.json", coco.Title("自定义标题"), // 文档标题 coco.Theme("dark"), // 主题：light/dark/auto coco.Lang("zh"), // 语言：en/zh coco.EnableDebug(true), // 启用调试面板 coco.EnableExport(true), // 启用导出功能 coco.EnableHistory(true), // 启用请求历史 ) ``` ### 从远程 URL 加载 ```go coco.New("", coco.SpecURL("https://api.example.com/openapi.json")) ``` ### 与 Swag 配合使用 ```bash # 1. 使用 swag 生成文档 swag init   # 2. 使用 Coco 渲染 coco.New("./docs/swagger.json") ``` ## 支持的框架 ✅ **net/http** - Go 标准库 ✅ **Gin** - 最流行的 Web 框架 ✅ **Echo** - 高性能框架 ✅ **Fiber** - Express 风格的框架 ✅ **Chi** - 轻量级路由器 ✅ **以及任何兼容 `http.Handler` 的框架** 完整示例见：[GitHub - examples](https://github.com/leehainuo/coco/tree/main/example/framework) ## 实际效果 ### 📱 响应式设计 完美支持移动端、平板、桌面端 ### 🧪 API 测试面板 直接在文档中测试接口，支持： - 请求参数填写 - 请求头自定义 - 实时响应预览 - JSON 格式化显示 ### 📝 请求历史 自动保存所有测试记录，方便回溯和复用 ### 🌓 智能主题 - **亮色模式** - 清爽舒适 - **暗色模式** - 保护视力 - **自动模式** - 跟随系统 ### 🌍 国际化 内置中英文支持，用户可随时切换 ## 项目信息 - **GitHub**: <https://github.com/leehainuo/coco> - **文档**: <https://github.com/leehainuo/coco#readme> - **示例**: <https://github.com/leehainuo/coco/tree/main/example> - **License**: MIT ## 快速链接 - [完整文档](https://github.com/leehainuo/coco/tree/main/docs/zh) - [快速开始](https://github.com/leehainuo/coco#%E5%BF%AB%E9%80%9F%E5%BC%80%E5%A7%8B) - [框架集成示例](https://github.com/leehainuo/coco/tree/main/example/framework) - [问题反馈](https://github.com/leehainuo/coco/issues) ## 加入 Coco！ 🎉 Coco 是一个开源项目，小nuo欢迎任何形式的贡献！ 小nuo还是一个学生，经验还是不足，Coco 肯定存在很多的不足。Coco 很需要各位佬佬和童鞋们的帮助！！！才能变的更好 💕 ### 你可以： - 🌟 **给个 Star** - 这是对小nuo和各位贡献者最大的鼓励 - 🐛 **报告 Bug** - 帮助我们发现问题 - 📝 **改进文档** - 让文档更清晰易懂 - 🌍 **添加翻译** - 支持更多语言 - 💻 **贡献代码** - 实现新功能或修复问题 - 📢 **分享推荐** - 让更多人知道 Coco ### 贡献指南 查看 [CONTRIBUTING.md](https://github.com/leehainuo/coco/blob/main/CONTRIBUTING.md) 了解如何参与贡献。 ### 社区 - **GitHub Issues**: 提问题、提需求 - **GitHub Discussions**: 技术讨论、分享经验 - **Star & Watch**: 及时获取更新 ## 结语 如果你厌倦了 Swagger UI 的老旧界面，如果你想要更优雅的 API 文档体验，那就试试 **Coco** 吧！ **三行代码，优雅文档，就是这么简单！**  🥥 觉得有用？请给小nuo一个 Star！⭐ 发现问题？欢迎提 Issue！成为贡献者！🐛 **项目地址**: <https://github.com/leehainuo/coco>

Clipaste，又一个Mac剪切板工具

## 做这个软件的原因是，Paste太贵了，破解版不能iCloud同步，剪切助手也暂停开发了，PasteNow不支持横版，并且复制大文本滚动起来会非常卡顿，所以就动手开发了一个，欢迎鱼友们体验，付费开通了苹果开发者，可以支持iCloud同步，如果你觉得还不错，欢迎Star，同时也希望参与开源，一起完善这个工具 ## 项目地址 https://github.com/gangz1o/Clipaste # 📋 Clipaste Clipaste 是一个基于 **SwiftUI** 和 **SwiftData** 构建的 macOS 剪贴板管理器。 它的核心目标很明确：**历史记录再多、文本再大，也要保持响应迅速、滚动丝滑、内存占用可控。** ## ✨ 亮点 * 🚀 响应迅速，常用操作几乎即时完成 * 🧠 内存占用小，长时间运行也更稳定 * 🗂️ 面对超大剪贴板历史仍然保持顺滑不卡顿 * 📝 面对超大文本内容时依然流畅，不会因为内容变重而明显拖慢界面 * 🐸 后台自动ocr识别图片内容，支持搜索图片内文字 * 🔄 可迁移 **Paste**、**PasteNow**、**iCopy**，**Maccy** 的历史数据 * 🎏 UI 同时支持横向和纵向布局 * ☁️ 支持可选的 iCloud / CloudKit 同步 * 💕 开源免费 ## 🧩 预览 <div align="center"> <img src="https://cdn.nodeimage.com/i/Rehrs8FAKYh2SngzRtC9DBq4nqDoDMB8.webp" width="40%" /> <img src="https://cdn.nodeimage.com/i/Rehrs8FAKYh2SngzRtC9DBq4nqDoDMB8.webp" width="40%" /> </div> <br /> <div align="center"> <img src="https://cdn.nodeimage.com/i/i4Jab3co3VW1kOKL2zEkzIQNsiINGp9p.webp" width="40%" /> <img src="https://cdn.nodeimage.com/i/jRQP3zlsLV94nuvaoc7Cz781a8u50zVL.webp" width="40%" /> </div> <br /> ## 🏎️ 为什么是 Clipaste Clipaste 重点解决的是很多剪贴板工具在重负载场景下会暴露的问题： * 历史记录一多就开始卡 * 大文本一多就开始慢 * 滚动和搜索在重内容场景下不够稳定 Clipaste 的设计目标相反： * 历史记录很多时仍然保持丝滑 * 大文本内容仍然保持可操作性 * 搜索、预览、再次粘贴保持快速反馈 * 不靠明显增加内存占用来换取表面流畅 如果你用过 Paste 或 PasteNow，Clipaste 的差异点很直接： * 更强调大历史记录下的性能稳定性 * 更强调大文本内容下的响应速度 * 提供它们没有覆盖到的布局与开源可定制能力 ## 🔄 历史迁移 Clipaste 支持从以下应用迁移历史数据： * Paste * PasteNow * iCopy * Maccy 目标很简单：切换工具时，不需要放弃原有历史记录。 ## 🧱 技术栈 * **SwiftUI**：界面构建 * **SwiftData**：存储与迁移 * **CloudKit**：可选同步能力 * 原生 macOS 应用架构 ## 🖥️ 系统要求 * macOS 14.0+ * Xcode 16+ ## 📦 安装 推荐使用 Homebrew 安装： ```bash brew tap gangz1o/clipaste brew install --cask gangz1o-clipaste ``` 更新 Clipaste 有两种方式： * 使用应用内更新 * 通过 Homebrew 更新： ```bash brew update brew upgrade --cask gangz1o-clipaste ``` ## 🛠️ 本地构建 1. 用 Xcode 打开 `clipaste.xcodeproj` 2. 如果你要在本地运行带 iCloud / Push entitlement 的版本，请选择你自己的签名团队 3. 直接构建运行 如果你 fork 这个项目并准备自行发布，还需要替换你自己的： * Bundle Identifier * iCloud Container * Apple 签名配置 ## 🚢 发布 维护者可以通过仓库内的 GitHub Actions 工作流自动生成并上传 notarized DMG，详见 [RELEASING.md](RELEASING.md)。

做了一个自动投简历的agent skill job-hunter可以让你的agent帮你上boss还有鱼泡跟你与你简历的匹配度自动的投递简历 https://github.com/YIKUAIBANZI/job-hunter

🚀 学习实战 | 基于 Spring AI + LangGraph4j 的多模态 AI 面试系统（Java21 进阶项目分享）

大家好～ 最近在研究 **Spring AI + LangGraph4j**，花了点时间从 0 到 1 落地了一个**多模态 AI 面试系统**。 这个项目主要目标是模拟真实面试全流程：智能出题 + 多分支追问 + Qwen-Omni（文本/音频/视频）综合评估 + WebSocket 实时交互，采用 **主图 + 子图** 架构编排整个面试流程。 后端是整个项目的核心（也是我这次重点打磨的部分），前端只是配套的 Next.js 实现，方便大家本地一键跑起来体验。整体技术栈都是目前企业主流的生产级方案，踩了不少坑，也积累了一些实战经验，现在开源出来**供大家学习交流**，欢迎有同样在学 AI Agent、LangGraph、Spring AI 的同学一起讨论～ ### ✨ 核心技术栈 | 类别 | 技术栈 | |------------|-------------------------------------| | 后端框架 | Spring Boot 3.4.4 + Java 21（Virtual Threads） | | AI 框架 | Spring AI 1.0.0 + LangGraph4j 1.8.11 | | 多模态模型 | Qwen3.5-Omni-Plus（文本75% + 音频15% + 视觉10%） | | 实时交互 | WebSocket + Fun-ASR-Realtime + Qwen-TTS-Realtime | | 存储 | PostgreSQL + pgvector（向量检索） | | 其他 | MyBatis-Plus、DashScope SDK | ### 💡 主要亮点（后端核心功能） - **智能面试流程**：根据简历 + 岗位 JD 自动生成四类针对性题目（技术/项目/业务/软技能），支持并行生成 + 队列管理 - **多分支追问策略**：根据候选人回答质量动态选择「普通追问 / 低分深挖 / 高分挑战」三种路线 - **Qwen-Omni 多模态评估**：一次调用同时分析转录文本、原始音频、视频关键帧，带时间戳对齐 - **实时全双工交互**：WebSocket 推送题目 + TTS 音频，实时 ASR 转录（支持 VAD） - **主图 + 子图架构**：`InterviewAgentGraph` 主流程 + 批量出题子图 + 面试轮次子图，逻辑清晰可扩展 - **生产级容错**：LLM 熔断、重试、降级机制、递归深度保护，稳定性拉满 整个系统既能用于**个人模拟面试练习**，也能作为 **AI Agent 实战项目** 学习参考，代码结构和注释都比较清晰，附带详细的 `application-example.yml`。 --- **现在把完整后端项目开源啦**（前端仅作为附属配套）： **🔥 后端仓库**： [https://github.com/zunff/interview-agent](https://github.com/zunff/interview-agent) **🎨 前端仓库**： [https://github.com/zunff/interview-agent-frontend](https://github.com/zunff/interview-agent-frontend) 项目已包含环境配置示例，**直接 clone 就能本地跑起来**。 欢迎大家 **Star 支持**、Fork 实践，有任何优化建议、踩坑经验或者想一起完善功能的，随时在 Issue / PR / 评论区交流～ 一起把这个 AI 面试 Agent 打磨得更好！ 📚 学习永无止境，欢迎交流，一起进步！    **Star 就是对我最大的鼓励，也方便我后续持续更新！** 感谢各位～

AutoPublish - 多平台文章自动发布系统

<div align="center"> # AutoPublish - 多平台文章自动发布系统 一键将 Markdown 文章同步发布到掘金、CSDN、知乎、编程导航、语雀五大技术平台 </div> --- **项目地址：**[Github仓库](https://github.com/Mrchen-1600/Article-Auto-Publisher) ## 项目简介 `autoPublish` 是一个基于 Java + Playwright 的浏览器自动化工具，旨在解决技术博客创作者需要**手动将同一篇文章分别发布到多个平台**的重复劳动问题。 系统通过调用 DeepSeek AI 接口智能提取文章元数据（分类、标签、摘要），结合 Playwright 浏览器自动化技术，实现从内容解析到多平台发布的全流程自动化。 ### 核心亮点 - **一键多平台发布** — 支持掘金、CSDN、知乎、编程导航、语雀五大平台 - **AI 智能标签** — 自动调用 DeepSeek API 提取各平台适配的分类、标签和摘要 - **元数据缓存** — AI 生成的元数据本地缓存（`.meta.json`），避免重复调用 API - **YAML Front Matter 支持** — 可在 Markdown 文件头直接指定标签、分类和摘要 - **登录态持久化** — 浏览器 Cookie 本地保存，首次登录后无需反复认证 - **反检测机制** — 隐藏 WebDriver 自动化标识，绕过平台滑块验证 - **容错设计** — 单平台发布失败不影响其他平台，自动截图保存错误现场 --- ## 支持平台 | 平台 | 网址 | 功能 | 状态 | |:---:|:---:|:---|:---:| | 掘金 | juejin.cn | 自动填写标题、正文、分类、标签、封面、摘要，支持专栏收录 | 已跑通 | | CSDN | csdn.net | 自动填写标题、正文、标签（最多5个）、封面、摘要，支持专栏/原创声明/可见范围配置 | 已跑通 | | 知乎 | zhuanlan.zhihu.com | 使用文档导入功能发布正文，自动设置话题（最多3个）、创作声明 | 已跑通 | | 编程导航 | codefather.cn | ByteMD 编辑器自动填写，支持必选标签 + AI 推荐标签组合（最多7个） | 已跑通 | | 语雀 | yuque.com | 自动创建文档并填入内容，Base64 封面图片粘贴，保存为草稿 | 已跑通 | --- ## 技术栈 | 技术 | 版本 | 用途 | |:---|:---:|:---| | Java | 17 | 主开发语言 | | Playwright | 1.48.0 | Chromium 浏览器自动化 | | org.json | 20231013 | JSON 解析（AI 响应处理） | | DeepSeek API | — | AI 智能元数据提取 | | Maven | — | 项目构建与依赖管理 | --- ## 项目结构 ``` autoPublish/ ├── pom.xml # Maven 构建配置 ├── cookie/ │ └── PlaceHolder.txt # 浏览器数据目录占位文件 ├── src/main/ │ ├── java/com/mrchen/ │ │ ├── Article.java # 文章数据模型（标题、内容、各平台元数据） │ │ ├── Publisher.java # 发布器接口（getName + publish） │ │ ├── MultiPlatformPublisher.java # 主入口：配置加载、Markdown 解析、AI 调用、流程编排 │ │ ├── JuejinPublisher.java # 掘金发布实现 │ │ ├── CsdnPublisher.java # CSDN 发布实现（含图片自动压缩） │ │ ├── ZhihuPublisher.java # 知乎发布实现（文档导入模式） │ │ ├── CodeFatherPublisher.java # 编程导航发布实现 │ │ └── YuquePublisher.java # 语雀发布实现（Base64 封面粘贴） │ └── resources/ │ ├── config-example.properties # 配置文件模板（已脱敏，使用时请自行配置项目目录及API Key） │ └── myArticles/ # 文章与封面存放目录 │ ├── your-article.md # 你的 Markdown 文章 │ └── cover.png # 文章封面图 ``` --- ## 快速开始 ### 1. 环境要求 - **JDK 17** 及以上 - **Maven 3.x** - 稳定的网络环境（需访问各平台及 DeepSeek API） ### 2. 克隆项目 ```bash git clone <your-repo-url> cd autoPublish ``` ### 3. 安装 Playwright 浏览器 首次运行前需安装 Chromium 浏览器引擎： ```bash mvn exec:java -e -Dexec.mainClass=com.microsoft.playwright.CLI -Dexec.args="install chromium" ``` ### 4. 配置文件 将 `config-example.properties` 复制为 `config.properties`，并填入实际配置： ```bash cp src/main/resources/config-example.properties src/main/resources/config.properties ``` 需要修改的关键配置项： ```properties # 必改项 — 文章工作目录 workspace.dir=E:/java_project/autoPublish/src/main/resources/myArticles # 必改项 — 每次发布新文章时更新 target.file=你的文章标题.md target.cover=cover.png # 必改项 — DeepSeek API 密钥 ai.api.key=sk-your-actual-key ai.api.url=https://api.deepseek.com/chat/completions # 按需开启各平台（true/false） platform.juejin.enabled=true platform.csdn.enabled=true platform.zhihu.enabled=true platform.codefather.enabled=true platform.yuque.enabled=true ``` > 各平台的候选标签池、专栏、创作声明等详细配置请参考 `config-example.properties` 中的注释说明。 ### 5. 运行 ```bash mvn compile exec:java -Dexec.mainClass=com.mrchen.MultiPlatformPublisher ``` 或在 IntelliJ IDEA 中直接运行 `MultiPlatformPublisher.main()`。 > **首次运行**时，浏览器会以非无头模式启动。如果未登录过某个平台，请手动完成登录操作，Cookie 会自动保存到 `./cookie` 目录，后续运行无需再次登录。 --- ## 工作流程 ``` ┌─────────────────────────────────────────────────────────────┐ │ 启动多平台自动发布系统 │ └─────────────────────────┬───────────────────────────────────┘ │ ▼ ┌─────────────────┐ │ 加载配置文件 │ config.properties └────────┬────────┘ │ ▼ ┌─────────────────┐ │ 解析 Markdown │ 提取标题、正文、YAML Front Matter └────────┬────────┘ │ ▼ ┌────────────────────┐ │ 检查元数据缓存/来源 │ └────────┬───────────┘ │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌───────────┐ ┌────────────┐ │ 本地缓存 │ │ MD配置完整 │ │ 调用 AI API │ │.meta.json│ │ 直接使用 │ │ DeepSeek │ └────┬─────┘ └─────┬─────┘ └──────┬─────┘ │ │ │ └──────────────┼───────────────┘ │ ▼ ┌─────────────────┐ │ 启动 Chromium │ Playwright + 持久化上下文 └────────┬────────┘ │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 掘金发布 │ │ CSDN发布 │ │ 更多... │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └──────────────┼──────────────┘ │ ▼ ┌─────────────────┐ │ 输出执行报告 │ 成功/失败汇总 + 错误截图 └─────────────────┘ ``` --- ## Markdown 文章格式 系统支持可选的 YAML Front Matter，在文章开头用 `---` 包裹： ```markdown --- summary: 文章摘要，80字以内 tags: Java,架构,AI category: 后端 --- # 文章标题 正文内容... ``` | 字段 | 说明 | |:---|:---| | `summary` | 文章摘要，各平台通用 | | `tags` | 逗号分隔的标签列表，作为 AI 未启用时的兜底 | | `category` | 文章分类，作为全局默认分类 | 如果 Front Matter 信息完整，系统将跳过 AI 调用直接使用这些信息。未填写 Front Matter 时系统会自动调用 DeepSeek API 智能提取。 --- ## AI 元数据提取 系统通过 DeepSeek Chat API 实现以下自动化： - **智能摘要** — 自动生成 80 字以内的文章摘要 - **平台适配** — 根据各平台候选池，精确匹配最佳分类和标签 - **一次生成，永久缓存** — 结果以 `.meta.json` 文件保存在文章同级目录，重复运行直接读取缓存 缓存文件示例（`文章标题.md.meta.json`）： ```json { "summary": "本文探讨了企业级场景下 Agent 输出不符合规范的系统性解决方案...", "juejin_category": "人工智能", "juejin_tags": ["Agent"], "csdn_tags": ["人工智能", "AIGC", "ai", "架构", "后端"], "zhihu_topics": ["人工智能", "AI开发", "编程"], "codefather_tags": ["AI", "人工智能", "开源", "后端"] } ``` > 如果不想使用 AI，可在 Markdown Front Matter 中填写完整的 `summary`、`tags`、`category`，系统将自动跳过 AI 调用。 --- ## 配置参考 ### 全局配置 | 配置项 | 说明 | 示例 | |:---|:---|:---| | `workspace.dir` | 文章存放目录的绝对路径 | `E:/java_project/autoPublish/src/main/resources/myArticles` | | `target.file` | 要发布的 Markdown 文件名 | `my-article.md` | | `target.cover` | 封面图片文件名 | `cover.png` | | `user.data.dir` | 浏览器数据目录（保存 Cookie） | `./cookie` | | `ai.api.key` | DeepSeek API 密钥 | `sk-xxxxxxxx` | | `ai.api.url` | DeepSeek API 地址 | `https://api.deepseek.com/chat/completions` | | `article.default.tags` | 默认标签（兜底用） | `后端` | | `article.default.category` | 默认分类（兜底用） | `后端` | ### 平台配置 每个平台均支持以下通用配置模式： ```properties # 平台开关 platform.<name>.enabled=true/false # 平台编辑器 URL platform.<name>.url=https://... # 标签/分类候选池（AI 从中选择最匹配的项） platform.<name>.candidates.tags=标签1,标签2,标签3 ``` 各平台特有配置详见 `config-example.properties` 中的注释。 --- ## 常见问题 <details> <summary><b>首次运行时平台要求登录怎么办？</b></summary> 程序以非无头模式启动浏览器，你可以手动完成登录。登录后 Cookie 会自动保存到 `user.data.dir` 指定的目录（默认 `./cookie`），后续运行无需再次登录。 </details> <details> <summary><b>某平台发布失败会影响其他平台吗？</b></summary> 不会。系统采用独立 try-catch 包裹每个平台的发布流程，单个平台异常不会中断整体执行。失败时会在项目根目录生成 `error_snapshot_<平台名>.png` 截图供排查。 </details> <details> <summary><b>不想使用 DeepSeek API 怎么办？</b></summary> 在 Markdown 文件头添加完整的 YAML Front Matter（包含 `summary`、`tags`、`category` 三个字段），系统将直接使用这些信息，跳过 AI 调用。 </details> <details> <summary><b>支持哪些 AI 接口？</b></summary> 系统使用 OpenAI 兼容的 Chat Completions 接口格式，理论上支持所有兼容该格式的 AI 服务（如 DeepSeek、OpenAI、通义千问等），只需修改 `ai.api.url` 和 `ai.api.key` 即可。 </details> <details> <summary><b>语雀平台的 URL 如何配置？</b></summary> 语雀需要配置到具体知识库的链接，格式如：`https://www.yuque.com/<用户名>/<知识库名>`。程序会在该知识库下创建新文档并保存为草稿。 </details> --- ## 许可证 本项目仅供学习交流使用。