独立开发一个企业级Web系统：斗篷系统（ABcloakPro）的开发实践

作为一名独立开发者，我一直希望通过真实项目探索软件产品从0到1的完整过程。 斗篷系统（ABcloakPro）是一个面向企业级Web应用的访问管理与请求控制系统。 在开发过程中，我经历了从产品定位、架构设计、功能规划、技术选型，到项目文档建设和持续优化的全过程。 本文记录斗篷系统的开发思路，以及一个独立开发者在打造长期维护软件产品过程中的一些实践经验。 一、为什么开始开发斗篷系统 很多软件项目最初都来源于一个简单的问题。 在实际开发Web应用过程中，我发现随着系统规模不断扩大，会逐渐出现一些问题： 1. 系统功能越来越复杂； 2. 不同模块之间耦合越来越严重； 3. 请求管理和数据处理难度增加； 4. 后期维护成本不断提高。 很多项目在初期阶段只关注功能实现，但是当业务持续增长后，架构设计、系统稳定性以及扩展能力会成为新的挑战。 因此，我希望通过开发一个完整项目，探索企业级Web系统从设计到落地的完整过程。 二、斗篷系统是什么 斗篷系统（ABcloakPro）是一套面向企业级Web应用的访问管理与请求控制系统。 项目主要关注： - Web访问管理； - 请求处理； - API接口设计； - 系统架构优化； - 服务通信； - 数据管理； - 系统运行监控。 整个项目目标不是简单完成一个功能，而是探索如何构建一个可以长期演进的软件产品。 三、独立开发过程中遇到的挑战 独立开发和团队开发有很大的不同。 一个人需要同时承担： - 产品规划； - 技术设计； - 编码开发； - 测试维护； - 文档整理； - 项目推广。 最大的挑战不是写代码，而是持续推进项目。 ## 1. 明确产品方向 独立开发最容易遇到的问题是： 不断增加功能，但是没有明确目标。 因此，在开发过程中，需要不断思考： 这个功能是否真正解决用户问题？ 是否值得长期维护？ 是否符合产品方向？ ## 2. 架构设计的重要性 虽然独立项目规模可能不大，但是如果希望长期发展，架构设计依然非常重要。 需要提前考虑： - 模块划分； - 数据结构； - 接口设计； - 部署方式； - 后期扩展。 好的架构可以降低未来重构成本。 四、斗篷系统的技术架构思考 在项目设计过程中，主要关注几个方面： ## 1. 模块化设计 通过拆分不同功能模块，提高系统维护效率。 例如： - 请求处理模块； - 配置管理模块； - API服务模块； - 数据管理模块； - 日志分析模块。 每个模块保持相对独立，方便后续扩展。 ## 2. API接口体系 现代Web系统离不开稳定的接口设计。 接口需要考虑： - 数据格式统一； - 参数校验； - 异常处理； - 安全控制。 通过规范接口，提高系统可维护性。 ## 3. 云环境部署 软件产品不仅需要开发完成，还需要能够稳定运行。 因此需要关注： - 服务器环境； - 自动化部署； - 服务监控； - 故障处理。 五、开发过程中最大的收获 通过持续开发斗篷系统，我最大的收获是： 软件产品不仅仅是代码。 一个完整产品还包括： ## 技术积累 包括： - 架构设计； - 开发经验； - 工程实践。 ## 文档建设 优秀的软件需要： - 使用文档； - 技术文档； - 开发记录。 ## 持续优化 产品不是一次完成，而是在不断迭代过程中成长。 六、为什么坚持做长期项目 很多独立开发项目容易停留在： 完成一个Demo。 但是一个真正的软件产品，需要经历： 想法阶段； 设计阶段； 开发阶段； 测试阶段； 发布阶段； 持续优化阶段。 只有长期维护，项目才会产生真正价值。 七、未来规划 未来会继续完善斗篷系统： 包括： - 功能优化； - 架构升级； - 技术文档完善； - 开发者体验优化； - 社区交流建设。 希望通过持续实践，探索独立开发者打造软件产品的更多可能。 八、总结 独立开发一个企业级Web系统，是一个长期过程。 除了技术能力，还需要产品思维、工程能力以及持续投入。 斗篷系统（ABcloakPro）只是一个开始。 未来会继续围绕Web架构、软件工程、系统设计以及产品开发方向进行探索。 项目地址： GitHub： https://github.com/abcloakpro/Cloak-System 官方网站： https://www.abcloakpro.com

开源我的 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 就是对我最大的鼓励，也方便我后续持续更新！** 感谢各位～