开源
快来分享你的内容吧～
- 09-20 10:42·后端最近把自己开源的 重构了一遍。 做这个 Skill 的原因一直没变。 现在用 Codex、Claude Code 做项目，写代码已经越来越省事。问题慢慢跑到了另外一边：项目做久以后，Agent 开始忘，文档开始乱，方案改过几轮没人记得，代码写完了也不知查看全文加油鸭：太棒了！把项目状态管理得这么清晰又实用，这份重构思路既有深度又超接地气，为 Vibe Coding 项目提供了真正可持续的协作骨架！91013分享
09-03 12:48·全栈开发
08-07 12:00·Java后端- 07-29 17:16·后端大家好，我是汉堡。 上一篇文章《如何从0到1 Vibe Coding 一个项目，并长期维护》里，我分享了自己踩坑之后沉淀出来的一套 Harness 体系——用文档治理、AGENTS.md、范围冻结和分阶段推进来驯服 Vibe Coding 的混乱。查看全文加油鸭：把方法论沉淀成可复用的 Skill 太棒了！文档驱动 + 阶段治理，真正让 Vibe Coding 有了工程骨架，为你点赞！141025分享
- 07-17 16:18·后端开发
06-17 22:33·Java后端- 06-17 00:37·Java后端
05-22 22:22·Java后端Hello，大家好，这里是小nuo。 小nuo在实习的时候发现，Java 中有 Knief4j 渲染 Swagger 方便 Javaer 调试和提供接口给到前端或者测试等人。但是我在使用 Go 的时候发现没有一款让我满意的，所以自己开发了一个。 先看效果 ✨ !coco-light.png !coco-dark.png 现代化、优雅、流畅 - 这才是你 Go 应用程序的 API 文档应有的样子 你查看全文加油鸭：太惊艳了！从痛点出发自研Go文档工具，界面美、集成简、功能全，学生开发者能做出这种品质真让人佩服！431分享
Project Vibe Spec 大升级：我想解决 Vibe Coding 项目越写越乱的问题
> 开源地址：[github.com/dnwwdwd/project-vibe-spec](https://github.com/dnwwdwd/project-vibe-spec)如果对你有用，GitHub 上点个 Star 是最实在的支持 ⭐ 最近把自己开源的 `project-vibe-spec` 重构了一遍。 做这个 Skill 的原因一直没变。 现在用 Codex、Claude Code 做项目，写代码已经越来越省事。问题慢慢跑到了另外一边：项目做久以后，Agent 开始忘，文档开始乱，方案改过几轮没人记得，代码写完了也不知道到底验证到什么程度。 这种问题对 Vibe Coding 用户影响尤其大。 很多人不会逐行 Review 代码，我自己做一些项目时也不会每次把几百上千行 diff 从头看到尾。我更容易确认的是页面有没有做对、流程是不是我想要的、数据语义有没有问题、最后能不能跑。 一旦项目做几个月，光靠聊天记录就撑不住了。 这一轮 Agent 记得为什么这么改，换个 Session 可能就不知道了。PRD 还写着旧方案，代码已经跑到第三版。某个功能之前只做了 POC，过几轮以后 Agent 开始把它当成正式能力。数据库里多了一张表，几个月后没人知道当时为什么拆。 还有一种很常见。Agent 改完代码以后直接告诉你"已完成"，结果测试没跑，UI 没打开，migration 没验证，Windows 也没测。 我之前写 `project-vibe-spec`，主要就是在补这些东西。 ## 旧版已经能管需求，但有点重 之前的 Project Vibe Spec 已经有一套比较完整的流程。 一个需求进来以后，会经过需求确认、REQ、方案决策、实现、测试、Progress 更新。数据库、migration、权限、安全、公开 API 这种不太好回退的改动，还要求先讨论方案，再让 Agent 动代码。 这套流程用了以后，项目确实没那么容易失控。 但它自己也慢慢长胖了。 `SKILL.md` 里面要规定需求怎么分类、什么算跨模块、什么时候建 REQ、什么时候写 DEC、数据库什么时候要确认、Progress 怎么更新、哪些文档一起改、最后怎么验收。项目自己的 `AGENTS.md` 也容易继续往里面塞规则。 时间一长，Agent 接一个很小的任务，也可能先读一堆跟当前工作没关系的内容。文档都在，Agent 的上下文反而越来越重。 ## 现在项目上下文拆成了四层 新版大概是这个结构： ```text AGENTS.md ↓ 判断当前任务应该读什么 DOCUMENT_MAP.md ↓ 找到项目现在认可的文档 PRD / PDD / Design / Flow / DEC ↓ 保存产品、技术、设计和决策 REQ / Bug / Progress ↓ 记录当前正在推进的工作 ``` `AGENTS.md` 现在会尽量保持轻。里面放仓库边界、安全规则、任务路由、高风险操作和通用验证要求。 比如： ```text 修改产品行为 → 读产品文档和相关 REQ 修改 UI → 读设计规范和对应产品规则 修改数据库 → 读技术设计和 DEC 修改 Agent / MCP / 检索 → 读技术设计和业务流程 修 Bug → 读 Bug 记录和受影响模块规则 ``` 表结构、接口字段、当前开发进度、某个功能的详细需求，不继续往根 `AGENTS.md` 里堆。Agent 改哪块，再加载哪块的上下文。 ## DOCUMENT_MAP.md 现在会告诉 Agent 哪份文档能信 这个改动看起来不大，我自己挺在意。 项目做久以后，仓库里经常会出现这种文件： ```text old-design.md architecture-v2.md architecture-final.md prd-new.md some-spike.md ``` 人还能根据名字和 Git 历史猜一下。Agent 可能全部读进去，然后旧方案、新方案、实验记录一起进上下文。 新版的 `DOCUMENT_MAP.md` 会给文档标状态： ```text 现行 参考 缺失 不适用 ``` 例如： ```text 产品事实 docs/product/spec.md 现行 旧版产品设计 docs/archive/product-v1.md 参考 UI Design 缺失 Desktop 架构 docs/desktop-architecture.md 现行 ``` 至少 Agent 进项目以后知道当前应该看哪一份。 ## init 也整个重写了 旧版 `init` 主要围绕 PRD/PDD 和项目总进度工作。 现在执行： ```text $project-vibe-spec init ``` Agent 会先把仓库过一遍。它会检查 `AGENTS.md`、`CLAUDE.md`、README、docs、需求、设计、DEC、Progress、测试、构建配置、schema、migration、部署脚本和一部分实际代码。先弄清楚项目已经有什么，再决定缺什么。 假设一个项目已经用了： ```text specs/product.md architecture/backend.md docs/design-system.md adr/ ``` 新版不会再硬生生补： ```text docs/PRD.md docs/PDD.md docs/UI_GUIDE.md Decisions/ ``` `DOCUMENT_MAP.md` 里直接记现有路径： ```text 产品事实 → specs/product.md 技术事实 → architecture/backend.md 设计规范 → docs/design-system.md 架构决策 → adr/ ``` 跑 `init`，更接近给现有仓库做一次整理和审计。 ## 没有 PRD，就先记没有 以前为了把结构补齐，很容易生成一堆空模板。`PRD.md` 有了，`PDD.md` 有了，`UI_GUIDE.md` 也有了，里面没有多少能指导 Agent 的内容。 这轮把这个行为改掉了。 项目没有 PRD，可以直接记： ```text 产品事实：缺失 ``` 没有设计规范，而且项目根本没有 UI，也可以记： ```text 设计规范：不适用 ``` 后面开发真的需要产品规则，再补 PRD。模板现在只在项目缺这份信息、同时后续工作又需要它的时候才创建。 ## 历史功能也不用补几十个 REQ 一个已经做了几个月的项目第一次跑 init，如果硬套需求台账，很容易一次性生成很多历史 REQ。项目里已经有十几个功能，就补十几个需求记录。这些文件看起来规范，之后基本没人维护。 现在已有功能直接进入"当前实现基线"。 例如： ```text Agent Loop 已验证 PDF 解析 已实现待验证 多模态 PDF 已通过（POC） ``` 从这次初始化往后，新需求和还在推进的大任务再进入 REQ。需求台账里留下来的，基本都是后面还会继续看的内容。 ## "代码已经写了"单独变成一个状态 这次加了一个状态： ```text 已实现待验证 ``` 现在 Progress 有这些状态： ```text 已验证 已实现待验证 已通过（POC） 进行中 待开发 待拆分需求 待澄清 不纳入 ``` 加这个状态就是因为 Coding Agent 太容易把代码完成和功能完成混在一起。 仓库里已经有实现，只能说明代码存在。测试没跑完，就写"已实现待验证"。只验证过一个 Demo，就写"已通过（POC）"。有对应测试、构建结果或者真实用户路径验证以后，再写"已验证"。 对于不太看代码的人，这个区分比多一份技术文档有用得多。至少你问 Agent"这个功能做完没有"，它不能只因为搜到了代码就回答完成。 ## 数据库这种改动我还是卡得很死 这轮删了不少文档负担，但数据库规则没放松。 Agent 想加表、加字段、改索引、迁历史数据、删数据或者改 ORM schema，还是先调查。我要看到这个字段表示什么，谁写，谁读，旧数据怎么办，能不能为空，有没有唯一约束，需要什么索引，上线怎么迁，失败以后怎么处理。方案确认以后再改。 Vibe Coding 里面，数据库被连续改错几轮，比一个按钮颜色错了麻烦得多。这块宁愿多一次确认。 ## 这版对不 Review 代码的人有什么用 Project Vibe Spec 解决不了所有代码质量问题。竞态条件、慢 SQL、隐藏的安全问题、边界异常，该测还是得测，该 Review 还是得 Review。 我更关心的是另一个问题。 很多 Vibe Coding 项目做着做着，用户已经不知道项目现在是什么状态了。 需求当时怎么确认的？Agent 为什么用了这个方案？这个实现是临时的还是正式的？POC 后来有没有进正式版本？文档和代码现在该信哪个？哪些地方写完了还没测？下一次开新 Session 从哪里继续？ 这些信息如果全在聊天记录里，换个 Agent、换个工具或者隔一个月回来，很容易断。 新版 Project Vibe Spec 会尽量把这些信息留在仓库里。以后无论用 Claude Code 还是 Codex，Agent 先从 `AGENTS.md` 进入，根据任务找到 `DOCUMENT_MAP.md` 里的现行文档，再读对应的需求、决策和进度。 聊天记录可以丢，项目自己的状态还能接着用。 这次重构完以后，Project Vibe Spec 少了一些"必须创建什么文件"的规定，多了一套让 Agent 找到当前可信信息的办法。对大量用 Agent 写代码、又不会每次认真 Review 全部 diff 的开发方式，这比继续加几十条规范有用。 如果这套思路对你有帮助，去 GitHub 点个 Star 吧：[github.com/dnwwdwd/project-vibe-spec](https://github.com/dnwwdwd/project-vibe-spec) ⭐
MOSAEL，一个开源的AI原生视频工作站。智能体、工作流、无限画布，你想要的TA都有！
 项目网站：https://mosael.com 开源地址：https://github.com/Alndaly/Mosael  其实本来很早之前就应该做一期来讲讲这个东西了，因为大概两周左右时间这个产品就已经有了第一个版本，但是由于还没有做任何测试，就一直拖着了。 而现在我感觉起码对于个人使用而言，基本没有太大的问题了（狗头🐶）。 > 今天就来简单聊聊这个产品。 ## 为什么做这个东西 开始的时候只是有一次尝试着用seedance2.5的模型api生成了一段视频，感觉相当🐮。 然后就开始沉迷于AI视频生成，但生成过程中意识到了一些实际的问题。 比如：下载一些网站上的素材可能需要找一些工具站点或者打开终端用脚本；写文案可能在 ChatGPT；生成图片如果用的GPT的话还好，用ComfyUI就需要换个阵营；生成视频又是一个平台（L站或者别的什么）；下载完以后再丢进剪辑软件（剪映或者达芬奇）。 **如此这一套不断循环往复。** 而且剪完还不算结束。 如果要做自媒体，还得再去小红书、抖音、B站、视频号、tk、油管一个个上传。 最终的素材管理又得自己使用百度网盘/本地文件夹分类。 再联想到之前的时候做的一些视频，我录制用的是macos自带/obs，剪辑用的是达芬奇，实际剪辑的时候还得一点点过视频找到没声音/说错话的地方，极其的麻烦，干脆将所有的问题集中到一个项目中解决。 所以这个产品并非是为了AI视频而生，更准确的来说是**为了解决视频制作过程中的麻烦的地方而生**。 于是有了 Mosael。 > 出发点其实是我自己感觉到了繁琐。 ## Mosael的核心其实分为五块 - 其一是**素材管理** - 其二是**剪辑页面** - 其三是**智能体** - 其四是**工作流** - 其五是**无限画布** ### 素材管理具有非常多的能力，我把大部分我常使用到的方面都加入了进去。 首先关于素材增加方面，除了常见且必备的从系统导入以外，比如屏幕录制、音频录制、摄像头录制、从链接导入（就是从各大媒体网站下载资源）。  其中不同素材之间支持细节对比。  ### 剪辑页面中包含一些常见的剪辑能力，以及我基于自媒体的一些特殊需求也做了一些扩充，比如逐字稿一键转写、逐字稿剪切、字幕自动生成、一键翻译字幕、AI配音、声音克隆等等，你可以自行探索。  ### 其中智能体贯穿着所有的模块，大部分的操作都可以通过这个智能体内完成，整个项目内，所有的能力我都将其完整接入到了其中。  - 有时间线、轨道、字幕、调色、变速等这些常见的剪辑能力 - 有工作流编辑、管理、执行等能力 - 有无限画布的编辑、管理能力 - 有素材的管理能力 比如可以直接和 Agent 说： > 帮我把XX视频里的废话删掉。 Agent 可以读取该视频，通过asr转为实时字幕，分析字幕，然后调用剪辑工具实际修改时间线。 如有必要，会先弹出确认，不会直接动你的项目。 ### 工作流也是一个比较重要的模块，可以把 AI 生成、素材处理、转写、配音、导出甚至发布串起来。  一些重复的事情，搭一次之后就可以直接跑，甚至你可以将其导出为工作流文件分享给他人，他人可以一键使用。 ### **至于无限画布，核心是便于创意发散**，在无限画布内，你可以自由引用、生成新的素材，并且进行拖动对比。  ## QA ### 1. 能直接发布到平台吗？ 对于真正做内容的人来说，导出之后还有一堆事情。 上传、填标题、选账号、定时发布…… 所以我干脆继续往后做了。 Mosael 现在可以管理不同平台的账号和浏览器环境，让视频从时间线一直走到最终发布。 我希望以后整个过程可以在一个地方完成： **素材 → AI → 剪辑 → 导出 → 发布** 不用中间来回倒腾文件。 ### 2. 数据在云端还是本地？ 关于这一点，有一些因素 - 个别视频素材很大 - 我希望能够使用到本地的算力 - 我希望可以接入本地框架（比如ComfyUI、Ollama等） 所以 Mosael 从一开始就是桌面应用。 工程、素材和很多数据都留在自己的电脑上，渲染也在本地完成。 AI 则自己选。 想用 OpenAI、Gemini 或其他 API 都可以，也可以接本地模型。 同时我也希望软件提供能力，但数据最终放在哪里，由用户决定。 ### 3. Mosael 接下来有哪些计划？ 现在里面已经有： 剪辑合成、智能体、工作流、无限画布、账号池...... > 其实原先这个项目的名称我起的是MibuCut，正是因为功能面开始扩充了导致cut显得过于细分，我改为了Mosael。 后续我会思考一些面向小型团队的交互和实际功能，毕竟现实中并非所有都是一人成军，确实也有着不少视频制作团队有着相似的困境。 ### 4. 有浏览器插件吗？ 有的有的。 配套的下载链接中已一起打包了chrome插件，你可以直接下载并开启chrome系列浏览器的开发者模式然后加载这个插件包即可。 插件提供的能力有如下： - 一键导入当前链接内的媒体视频到Mesael素材库 - 一键获取当前视频帧并导入Mesael素材库 - 一键生成当前视频字幕、逐字稿（还支持一键翻译），逐字稿支持点击跳转到指定的视频进度
【原创项目】Flow Forge - AI接口测试框架，支持Codex等智能体以及本地部署的弱模型
  为AI接口测试提供两条路径：可以把skill接入Codex等智能体，实现一键从生成到执行和报告；可以使用llama.cpp / Ollama 等本地弱模型结合AI工作流，实现用例生成。支持编写和执行一个完整的业务链路。提供GUI工作台。 ## 开源地址   需要把代码完整下载到本地，因为skill需要配套的代码才可以使用。GUI工作台在[GitHub release](https://github.com/Remon-16/flow-forge/releases)提供了Windows的安装包。仓库中也提供了一些做好的测试用例和报告供参考：[简单电商项目示例](https://github.com/Remon-16/flow-forge/tree/main/examples/foli-mall)。如果感觉这个项目有帮助的话，麻烦帮我点个star，感谢。如果项目有bug、任何不足之处或者需要新功能的话，也欢迎在评论区或者issues中提交，我会及时更新的。 [Flow Forge — 接口自动化测试框架](https://github.com/Remon-16/flow-forge) ## 功能特性 - **测试用例的特性**：测试用例就是yaml或者excel文件，把用例扔给执行器就可以直接运行。不过像是数据库、MQ和Redis这种插件可能还是需要一些代码（可以用智能体生成）。用例不光是单接口的用例，还支持整个业务链路的顺序执行。如果业务用例有问题，也会在报告中指出是哪一步出了问题：   - **Codex等智能体的SKILL**：这是我最推荐的一个用法。在 [flowforge-testing/](https://github.com/Remon-16/flow-forge/tree/main/flowforge-testing) 中，我本地测试这个SKILL用的是Codex + deepseek-v4-flash，可以从需求和接口文档直接完成用例生成、校验、执行插件的补充、执行以及分诊。**分诊就是它能够判断失败的用例是因为用例写错了，还是业务有bug。用例写错了还会自己改用例，直到通过或者确定是业务bug。** 有plan模式，可以先审核计划再执行后续任务。上面说的插件也可以让它来编写和测试。 - **llama.cpp / Ollama 本地模型的工作流**：我测试功能用的是Qwen3-8B-Q4_K_M，-c 64000。这种就是适合公司不让用API的内网用户尝试。弱模型幻觉还是比较明显的，所以[agent/](https://github.com/Remon-16/flow-forge/tree/main/agent)中提供了一个AI工作流，也是能够从需求和接口文档生成测试用例。有plan模式。有resume模式，可以从断点恢复执行。不过生成的用例基本上就是给搭个架子，需要修改的东西可能比较多。然后生成速度会慢一些（速度取决于LLM执行的速度以及设置合适的batchsize）。仓库里也有弱模型配置参考文件：[配置文件](https://github.com/Remon-16/flow-forge/blob/main/examples/foli-mall/raw/weak-model-config.example.yaml)。后面我会说一些我试过的模型以及踩过的坑。 - **Studio 桌面工作台（Windows）**：在[GitHub release](https://github.com/Remon-16/flow-forge/releases)里有Windows的安装包，可以直接运行。这个就是给智能体工作流、用例编辑器、用例执行器和用例转换器提供了UI界面。**首次使用需要在右上角设置`⚙`中配置python环境以及agent/和python/目录地址。**     - **用例执行器**：[执行器](https://github.com/Remon-16/flow-forge/tree/main/python)，内部有登录态管理器，通过`#{}`触发，能自动管理登录态（不过目前只验证过JWT这类的登录态），业务链路用例的每个步骤之间传数据也支持，有两级断言引擎（支持equals、数值比较、类型检查、包含、正则以及一些函数，详见[断言引擎](https://github.com/Remon-16/flow-forge/blob/main/python/docs/processors-and-report.md)），能并发执行用例（非压力测试，并且需要用例之间互斥），有插件系统（目前已经做了一些插件，这些插件也可以直接让智能体做）。因为执行器是CLI的，所以可以集成到Jenkins，每天定时执行这种功能也支持。 - **用例转换器**：[转换器](https://github.com/Remon-16/flow-forge/blob/main/python/docs/converters.md)，目前支持四种：excel2yaml、yaml2excel、yaml2pytest、excel2pytest。pytest是尽可能原生的（.py里有命令，可以直接执行），也会把所有的插件都打包，单独放一个包里。 ## 整体架构 ```mermaid graph TD REQ[需求文档] --> PA[路径 A：强智能体 + flowforge-testing skill] API[接口文档] --> PA REQ --> PB[路径 B：agent/ LangGraph 弱模型流水线] API --> PB PA --> |测试计划 + 人工审核| CASES[YAML / Excel 用例] PB --> |测试计划 + 人工审核| CASES CASES --> STUDIO[Studio 可视化编辑 / 批注] STUDIO --> EXEC[执行器] CASES --> EXEC EXEC --> REPORT[HTML 报告] EXEC --> |退出码 0/1/2| CI[Jenkins CI/CD] ``` ## 适合人群 1. 开发，但需要兼顾测试，需要工作留痕，可以试一试我的工具。建议用法是接入Codex + deepseek-v4-flash（不是不建议其他智能体或模型，因为其他的我暂时没试过。ds4f个人感觉够用）。AI生成用例并执行之后，会生成yaml文件和测试报告。这些用例文件可以直接用执行器来执行。项目内也提供了一个桌面应用，不需要每次都敲命令。后续万一有bug可以翻一翻用例文件，然后甩锅/doge。 2. 测试，但平时工作量比较饱和，可以从边缘业务开始尝试一下。建议用法也是接入Codex + deepseek-v4-flash。因为这个项目算是刚刚可用，可能很多特性或者功能还不算太完善，太复杂的用例可能不一定支持。如果公司对于测试质量的要求很高的话，可以先观望一下或者在issue中提一提需要的功能或特性。目前这个项目应付一下冒烟测试，或者用生成好的用例结合Jenkins做定期测试这种，大概是可以的。 3. 内网用户，仍然在手写用例，可以尝试一下。如果公司的模型相对强一些，可以试一试用智能体接入本地模型。但如果是Qwen3-8B-Q4_K_M这种级别的模型，也可以试试（我目前还没试过）。实在不行的话，用AI工作流也可以，至少搭个架子没问题。AI工作流也支持plan模式，也有UI界面。 > 在使用GUI运行AI工作流，测试计划审核环节，如果用的模型比较弱，对于一些简单的计划错误（比如多了某个用例，描述轻微不对），可以双击文本块后，在批注器右侧手动修改。测试计划修改是代码级别分块，然后对批注选中的块进行修改。但如果模型很弱的话，可能它会把批注的整个块都修改了，比较难做到“仅删除某个不需要测试的用例，仅把接口响应码改成404”这种指令。  ## 弱模型 + AI工作流使用经验   这个项目大概做了两个多月，期间试过deepseek4flash预览版、GLM-4.7-flash的免费API、Qwen2.5coder:14B(ollama，量化版本忘了)、Qwen3-8B-Q4_K_M(llama.cpp)和Qwen3.5-4B-Q4_K_M(llama.cpp)。   因为这个AI工作流主要是针对弱模型设计的，所以强模型千万不要尝试接入，有很多工程优化可能会浪费token。强模型直接往Codex接。比如deepseek-v4-flash正式版。   用AI工作流生成用例的话建议用Excel格式的用例做首轮编辑，因为对批量编辑更友好。如果需要做diff，再转化成yaml用例。 - GLM-4.7-flash的免费API，没有执行到最终结果，因为它会疯狂报500，然后每次请求需要间隔3秒左右，如果调用失败了需要等90秒，不然会报429 too many request（好像是）。agent/中有很多参数都是为了这种免费API搞的。中间产物的话，效果看起来还行，印象里体感上可能接近deepseek4flash预览版，但是生成个用例比本地部署模型还慢。大概是6月初测试的，记忆不一定完全准确。模型可能不错，但是API确实有些一言难尽，不推荐尝试API。 - Qwen2.5coder:14B和Qwen3-8B-Q4_K_M的思考模式，体感上差不多。Qwen3-8B-Q4_K_M生成测试计划的能力还是明显比2.5好的。虽然后面的业务链路用例生成的步骤有挺多时候直接都是不对，缺个步骤啥的，用例名称用例描述给生成个英文（有兜底翻译智能体）的等等，不过至少搭个架子还行。条件实在有限的话，应该也能凑合用。 >Qwen3-8B-Q4_K_M 偶尔会输出空的json数据`{}`，一般是执行到case生成环节出现，有时稳定复现，比如用例的描述“生成超长用户名1024”。像这种稳定复现的情况，修改一下描述，比如“生成较长用户名”，resume恢复执行，可能就过去了，后续再手动修改一下即可。 - Qwen3.5-4B-Q4_K_M，印象最深刻的就是它经常会输出空的json数据`{}`，运气成分比较大，也是没完整执行过。不过像是Qwen3-8B-Q4_K_M生成的用例，如果用例名称和用例描述生成的是非中文，agent/里提供了一个兜底智能体，能翻译用例。CLI命令也很简约，能自动识别用例类型并翻译。一行命令就可以。 ## 技术栈 | 组件 | 技术 | |------|------| | Studio 桌面应用 | Vue 3, Ant Design Vue, Vite, Tauri 2, TypeScript | | agent 弱模型流水线 | Python 3.12, LangGraph, OpenAI 兼容 API, prance (OpenAPI), pymupdf (PDF) | | skill 工具脚本 | Python 3.12（ff_tool / resolve_python，复用 python/ 执行器与转换器） | | 执行器与转换器 | Python 3.12, requests, openpyxl, pyyaml | | CI/CD | Jenkins Pipeline, 命令行退出码 | ## 结语   像是功能原理之类的，因为代码仓库里都有，所以我也就不赘述了。我做这个项目很大一部分原因是很多年以来就一直想自己做个什么项目，然后最好有人能觉得好用。现在AI编程发达了之后，正好我在自动化测试这块算是有点经验，所以就做了这个项目。如果对你有帮助的话，麻烦帮我点个star。如果项目有bug、任何不足之处或者需要新功能的话，也欢迎在评论区或者issues中提交，我会及时更新的。
开源我的 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 都这样，没办法。我的态度是：练手的项目，学到东西就算回本；真想赚钱，立项前就想清楚谁来买单、凭什么买单。别一边写代码一边幻想"做完了就有人用了"——大多数时候不会。 ## 我开发的 vibe coding skill 我将上述我的 vibe coding 的工作流和方法开源了一个项目的 vibe 规范 skill（ https://github.com/dnwwdwd/project-vibe-spec ），这样大家就可以直接使用了，无需手动维护文档。希望大家多给我的 skill 点点 star：https://github.com/dnwwdwd/project-vibe-spec --- ## 个人博客 我的博客：<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)。