—
DEV TRENDS / DAILY DISCOVERIES
Apr 16, 2026 · What developers are building
Daily discoveries from developer communities, independent makers, and open source.
—
imgpilot
对话生图，与以往的 prompt 生图不同，能够像聊天一样多轮迭代，逐步打磨出理想画面，支持上传参考图编辑或将 prompt 生成好的图片继续迭代，同时持续更新 prompts 库
Original—
—
—
—
—
audjust.ai
智能音频编辑与 AI 音乐生成工具，帮助处理音频文件（智能缩短歌曲、延长音频、寻找完美无缝循环）并从文字描述、歌词或图片生成完整音乐轨道。支持多种风格，内置 MIDI 编辑器、音轨分离、Lo-fi 转换等专业工具。
Original—
—
—
—
—
—
—
Listing诊断器
免费在线跨境电商 Listing 质量分析工具，支持亚马逊/速卖通/Shopify，检测标题长度、关键词密度、卖点结构，给出优化建议。纯浏览器端处理，无需注册，数据不上传。
Original—
—
—
CCCC — 本地优先的多智能体协作内核，让多个 agent 像团队一样协同工作
GitHub: PyPI: pip install U ccccpair 多智能体开发的现实困境：协作记录散落在终端里重启即消失、agent 有没有读到消息无从得知、长时间跑的任务出门就失控。 CCCC 是一个本地优先的多智能体协作内核，只需一条 pip install，零外部依赖（不需要数据库、不需要消息队列），就能让 Claude Code、Codex CLI、Gemini CLI 等多个 coding agent 在同一协作组中像团队一样协同工作 — 具备完整的消息历史、触达追踪和 Web 看板。 核心能力 唯一事实源：appendonly ledger 记录所有消息和事件，可回放、可审计、永不丢失 可靠消息语义：已读游标、attention ACK、replyrequired 义务追踪，谁看到了什么一清二楚 统一控制面：Web UI、CLI、MCP 工具、IM 桥接全部对接同一 daemon，不存在状态分裂 多运行时混编：Claude Code / Codex CLI / Gemini CLI 等 8 种一线运行时可在同一协作组内混用 IM 桥接：支持 Telegram / Slack / Discord / 飞书 / 钉钉，手机上即可远程管理 agent 协作 自动化策略：催办、空闲检测、Cron 排程、静默告警，免去人工盯盘 快速开始 bash pip install U ccccpair cccc 启动 daemon + Web UI 打开 <h2 style="margintop: 1.5rem; fontweight: 600; marginbottom: 1rem; lineheight: 1.25; fontsize: 1.3em; color: rgb(231, 233, 237); fontfamily: applesystem, "systemui", "PingFang SC", "Hiragino Sans GB", sansserif; fontstyle: normal; fontvariantligatures: normal; fontvariantcaps: normal; letterspacing: normal; orphans: 2; textalign: start; textindent: 0px; texttransform: none; widows: 2; wordspacing: 0px; webkittextstrokewidth: 0px; whitespace: normal; backgroundcolor: rgb(24, 26, 27); textdecorationthickness: initial; textdecorationstyle: initial; textdecorationcolor: initial;"效果预览</h2<p style="margin: 0.5rem 0px; display: inlineblock; width: 750px; lineheight: 1.5rem; color: rgb(231, 233, 237); fontfamily: applesystem, "systemui", "PingFang SC", "Hiragino Sans GB", sansserif; fontsize: 13px; fontstyle: normal; fontvariantligatures: normal; fontvariantcaps: normal; fontweight: 400; letterspacing: normal; orphans: 2; textalign: start; textindent: 0px; texttransform: none; widows: 2; wordspacing: 0px; webkittextstrokewidth: 0px; whitespace: normal; backgroundcolor: rgb(24, 26, 27); textdecorationthickness: initial; textdecorationstyle: initial; textdecorationcolor: initial;"<span </span </p<div class="tablescrollwrapper" style="overflowx: auto; marginbottom: 0.7em; scrollbarwidth: thin; scrollbarcolor: rgba(121, 121, 121, 0.4) rgba(0, 0, 0, 0); color: rgb(231, 233, 237); fontfamily: applesystem, "systemui", "PingFang SC", "Hiragino Sans GB", sansserif; fontsize: 13px; fontstyle: normal; fontvariantligatures: normal; fontvariantcaps: normal; fontweight: 400; letterspacing: normal; orphans: 2; textalign: start; textindent: 0px; texttransform: none; widows: 2; wordspacing: 0px; webkittextstrokewidth: 0px; whitespace: normal; backgroundcolor: rgb(24, 26, 27); textdecorationthickness: initial; textdecorationstyle: initial; textdecorationcolor: initial;" </div<h2 style="margintop: 1.5rem; fontweight: 600; marginbottom: 1rem; lineheight: 1.25; fontsize: 1.3em; color: rgb(231, 233, 237); fontfamily: applesystem, "systemui", "PingFang SC", "Hiragino Sans GB", sansserif; fontstyle: normal; fontvariantligatures: normal; fontvariantcaps: normal; letterspacing: normal; orphans: 2; textalign: start; textindent: 0px; texttransform: none; widows: 2; wordspacing: 0px; webkittextstrokewidth: 0px; whitespace: normal; backgroundcolor: rgb(24, 26, 27); textdecorationthickness: initial; textdecorationstyle: initial; textdecorationcolor: initial;"技术栈</h2<p style="margin: 0.5rem 0px; display: inlineblock; width: 750px; lineheight: 1.5rem; color: rgb(231, 233, 237); fontfamily: applesystem, "systemui", "PingFang SC", "Hiragino Sans GB", sansserif; fontsize: 13px; fontstyle: normal; fontvariantligatures: normal; fontvariantcaps: normal; fontweight: 400; letterspacing: normal; orphans: 2; textalign: start; textindent: 0px; texttransform: none; widows: 2; wordspacing: 0px; webkittextstrokewidth: 0px; whitespace: normal; backgroundcolor: rgb(24, 26, 27); textdecorationthickness: initial; textdecorationstyle: initial; textdecorationcolor: initial;"Python<span </span3.9+<span </span/ FastAPI /<span </spanPydantic / appendonly JSONL ledger<span </span/<span </spanMCP stdio</p<p style="margin: 0.5rem 0px; display: inlineblock; width: 750px; lineheight: 1.5rem; color: rgb(231, 233, 237); fontfamily: applesystem, "systemui", "PingFang SC", "Hiragino Sans GB", sansserif; fontsize: 13px; fontstyle: normal; fontvariantligatures: normal; fontvariantcaps: normal; fontweight: 400; letterspacing: normal; orphans: 2; textalign: start; textindent: 0px; texttransform: none; widows: 2; wordspacing: 0px; webkittextstrokewidth: 0px; whitespace: normal; backgroundcolor: rgb(24, 26, 27); textdecorationthickness: initial; textdecorationstyle: initial; textdecorationcolor: initial;"支持 macOS / Linux / Windows，也提供 Docker 部署方案。</p
Original
—
SmartInvest - 一款ETF投资中的资产配置仓位管理软件
工具介绍 在投资这件事中，拼消息咱们拼不过量化，拼价投咱们拼不过对冲基金，拼主动择时咱们拼不过公募和私募的主动基金，个人投资者为数不多的赚钱机会就这么几个：流动性冲击下的低吸，低估值下的定投 和 动态再平衡。SmartInvest是一款仓位管理和思维导图笔记工具，帮助个人投资者管理仓位和思考。 下载地址： 文档地址： 适用场景 适合做资产配置的个人投资者，不拼手速块，不拼内幕消息，不拼技术分析，靠深度理解投资市场的游戏规则和仓位管理获胜。 核心价值 提供Windows，macOS，Linux上的跨平台客户端。 提供markdown和mindmap思维导图，方便整理自己心中的投资思路。 方便用笔记的形式收集连接各渠道的资讯。 可以将主要指数放在同一个视图中进行比较。 仓位管理可视化，便于做动态再平衡，强制高卖低买。
Original—
一次实验：AI 原生的软件开发生命周期，能否像人类一样"打磨"软件
一次实验：AI 原生的软件开发生命周期，能否像人类一样"打磨"软件 再一次测试左移 实验初衷 最初的目标并不是要构建一个身份认证平台。我想探究一个更根本的问题：用 AI 原生的开发流程，真的能够打磨出合格的应用吗？ 不是玩具 ，也不是周末项目。而是一个真正的系统——足够复杂来检验这套方法论，安全要求足够高，"差不多能用"的标准在这里行不通。 我选择了 IAM（身份认证与访问管理）作为实验对象。这不是简单的增删改查：多租户数据隔离、OIDC/OAuth2 流程、Token Exchange、层级化 RBAC 权限、Webhook 签名验证、审计日志——这些环环相扣的复杂性意味着，一个错误决策会引发十几个隐蔽的 bug。在这里，安全不是锦上添花，而是系统存在的根本意义。 最终成果是 Auth9，一个自托管的 Auth0 的替代方案，基于 Rust、React Router 7、TiDB 和 Keycloak 构建。你可以在 auth9.c9r.io 亲自体验一下。这个项目中几乎所有的代码都由 AI 生成，几乎所有步骤都由 skills 驱动——从后端 Rust 服务到前端 React 组件，从测试用例到部署脚本。但 Auth9 只是产出物，实验的真正主角是这套开发流水线本身。 管理后台——多租户概览、最近活动、RBAC 入口 真正的挑战：可验证性 AI 编码工具确实让写代码更快了。GitHub Copilot、Cursor、Claude Code——它们都兑现了这个承诺。 但写代码从来不是真正的难点。难点在于如何知道代码是否正确——而且要足够快、足够自动化，不能让验证本身成为瓶颈。 AI写了一堆代码，看起来很好，但也可能一测试就报错，或者是缺依赖，或者是lint不过关。当AI犯错误时给它一个prompt也挺烦人的，但是没关系，让AI自己写完代码自己去测试就好了。 AI 原生的开发流程不是要消除验证工作，而是要让验证足够系统化、足够自动化，跟上 AI 生成代码的速度。如果 AI 写代码快了 10 倍，但验证还是手动操作，那你只是制造了一个 10 倍大的 QA 积压。 测试左移 先说清楚：测试没有消失，反而变得更加重要了。 变化的是形式。 传统的自动化测试——单元测试、集成测试、端到端测试——在代码库中依然存在。cargo test 跑得很快，而且不依赖外部服务。Playwright 驱动端到端流程。Vitest 覆盖前端。这些技术手段依然有效，依然必要。当然，它们都是 AI 自动生成的。 我们在代码级测试之前增加了一层：QA 测试文档。这些是结构化的规格说明，描述要测什么、怎么测、如何在数据层验证正确性。AI 生成这些文档，人类审查和批准。然后 AI 执行测试——包括浏览器自动化、API 调用、数据库查询和 gRPC 验证。实际上它更接近于传统的手动测试，但却是自动化的。当然，它暂时还不能完全代替手动测试。 这就是测试左移到文档的实践。测试计划不再是功能上线后才补的事后工作。它是在功能规划后产生的第一个产物，驱动后续所有工作：写什么代码、验证什么、出问题时捕获什么。 人类的角色：审查每份生成的测试文档，检查完整性、边界情况，以及 AI 可能遗漏的安全考量；观察 agent 的自动测试，检查它的测试行为是否符合预期，或者说是否存在作弊。AI 的角色：生成文档、执行测试、报告失败、修复力所能及的问题。而 QA 测试文档，则反映了用户故事本身。 关于 Spec 驱动开发的一个暴论：QA 测试文档就是 spec。 现在很多人热衷于用 design doc 作为 spec 来驱动 AI 开发。但 design doc 描述的是你想要什么——它无法告诉你是否得到了。QA 测试文档两者兼具：它定义了预期行为，同时可以对运行中的系统进行自动验证。Design doc 会悄无声息地腐化；QA 文档在现实偏离 spec 的那一刻就会大声报错。如果你的 spec 不可执行，那它只是一个愿望。 闭环流水线 整个流水线将 16 个 Agent Skills 串联起来，每个阶段的输出都是下一个阶段的输入： 人类 + AI ──► 规划功能 │ ▼ ┌─ 生成 QA / 安全 / UIUX 测试文档 │ (qadocgen) ▼ ┌─ 自动执行测试 │ 浏览器自动化、API 测试、 │ 数据库验证、gRPC 回归测试、 │ 性能基准测试 ▼ ┌─ 失败？创建结构化工单 │ (docs/ticket/) ▼ ┌─ AI 读取工单 → 验证问题 → │ 修复代码 → 重置环境 → │ 重新运行测试 → 关闭工单 │ (ticketfix) ▼ ┌─ 定期审计文档质量 │ (qadocgovernance) ▼ ┌─ 重构后对齐测试 │ (aligntests, testcoverage) ▼ ┌─ 部署到 Kubernetes │ (deployghk8s) └───────────────────────── 每个 skill 都是一个独立的 Agent Skill 定义——一个 Markdown 文件，包含指令、工作流步骤和工具脚本： | 阶段 | Skills | 职责 | |||| | 规划 | projectbootstrap | 从零开始搭建新项目脚手架 | | 编码 | rustconventions, keycloaktheme | 编码规范、主题开发 | | 测试文档 | qadocgen, qadocgovernance | 生成和管理测试文档 | | 执行测试 | qatesting, e2etesting, performancetesting, auth9grpcregression | QA、端到端、压力测试、gRPC 测试 | | 修复 | ticketfix, aligntests | 自动修复工单、重构后对齐测试 | | 覆盖率 | testcoverage | 确保所有层 =90% 覆盖率 | | 部署 | deployghk8s | GitHub Actions 门禁 → K8s 部署 → 健康检查 | | 运维 | ops, resetlocalenv | 日志、故障排查、环境重置 | 关键洞察：Agent Skills 可以组合使用。功能规划完成后，qadocgen 生成测试文档；qatesting 执行测试；失败变成 docs/ticket/ 里的工单；ticketfix 读取工单、修复代码、重置环境、重新运行测试、关闭工单；qadocgovernance 定期审计所有内容，防止文档腐化。 文档就是可执行的规格说明 这套方法能够跑通，核心原因是测试文档的结构化——既给人看，也能被 AI 解析。以下是租户 CRUD 测试套件中的一个真实场景： 场景 1：租户管理入口可见性与创建租户 初始状态 用户已登录管理后台 数据库中无同名或同 slug 的租户 测试操作流程 1. 在管理后台左侧导航确认存在「租户管理」菜单入口 2. 点击「租户管理」菜单进入租户列表 3. 点击「创建租户」按钮 4. 填写表单： 租户名称：测试公司 Slug：testcompany Logo URL： 5. 点击「创建」按钮 预期结果 显示创建成功提示 侧边栏入口可见且可点击进入 租户出现在列表中，状态为「Active」 预期数据状态 sql SELECT id, name, slug, logourl, status FROM tenants WHERE slug = 'testcompany'; 预期: 存在一条记录，status = 'active' SELECT action, resourcetype FROM auditlogs WHERE resourcetype = 'tenant' ORDER BY createdat DESC LIMIT 1; 预期: action = 'tenant.create' SQL 验证是关键。AI 不只是检查 UI 是否显示"成功"——它会直接查询数据库，确认数据确实正确落库。这样能抓到一整类 bug：前端显示成功，但后端静默失败。 我们有 156 份这样的文档：96 份 QA、48 份安全、12 份 UI/UX——每一份都是可执行的规格说明，由 AI 生成、人类审查。 我们选择文件系统作为信息交换的媒介（例如 docs/qa、docs/ticket 目录），原因也很简单——因为 Agent 很擅长于 bash 操作，对于文件系统的读写既自然又精准高效。这种基于文件的工作流让整个验证过程变得透明且可追溯。 自愈循环：AI 如何"打磨"软件 ticketfix skill 是流水线中最有意思的部分，也是 AI "打磨"软件的核心机制。测试失败后，系统创建结构化工单，然后： 1. 读取工单并验证 — 解析场景、步骤、预期/实际结果、环境信息、SQL 检查。 2. 复现 — 对当前实现运行失败的测试。 3. 修复（如需要） — 实现最小范围的代码修复。 4. 重置环境 — 必须的。运行 ./scripts/resetdocker.sh 确保干净状态。 5. 重新运行 QA 步骤 — 按照工单的精确步骤和 SQL 验证执行，采集证据。 6. 误报分析 — 这是让整套系统真正跑起来的关键细节。 7. 关闭工单 — 删除工单文件，总结结果。 误报分析 不是每个失败的测试都是真正的 bug。ticketfix skill 显式处理误报——由测试流程缺陷而非代码缺陷导致的失败： 测试命令缺少必要的认证头（如 HMAC 签名） 前置条件不完整或有歧义（"webhook 必须存在"但没给创建步骤） 环境假设与 Docker 默认配置不匹配 测试数据引用不存在的实体，没有兜底处理 确认误报后，skill 不只是关闭工单——它会更新 QA 文档，防止同样的误报再次出现。把隐式要求改为显式、确保示例命令开箱即用、添加常见失败模式的排障表。 这意味着每次测试失败都会让测试套件变得更好，不管失败是真正的 bug 还是测试本身的问题。这正是"打磨"的本质——通过反复的验证和修正，让软件和测试文档都变得更加完善。 文档治理 测试文档会腐化。路由变了，API 演进了，权限体系重构了——突然间一半的测试套件在测试不存在的行为。 由于所有 QA 测试文档会由 agent 反复执行，如果文档过时，我们会注意到大量的伪阳性工单报告。让文档保持更新的最好策略就是不断使用它。 qadocgovernance skill 进行定期审计，按严重等级分类： P0：导航不通或测试流程不可用（缺少 checklist、误导性的认证步骤、索引偏移） P1：治理偏移（单文件超过 5 个场景、UI 相关文档缺少入口可见性说明） P2：风格一致性（命名对齐、措辞规范化） 工作流：全量 lint → 分级分类 → 按优先级修复 → 同步索引和 manifest → 验证并生成报告。可以在任意新功能或重构后运行，也可以定期执行（如每周一次），大版本发布前运行一次，事故后运行一次。 一条硬性规则：每份文档必须包含回归测试 checklist。没有例外。即使文档其他部分漂移了，checklist 仍提供最低可用的验证路径。 跨文档影响分析 一个功能变更不只影响一份测试文档。qadocgen skill 包含强制性的跨文档影响分析，扫描全部 156 份文档，查找： 路由变更（/dashboard、/tenant/select、/auth/callback） Token 模型变更（idtoken、tenant token、token exchange） 权限/认证变更（401、403、scope、audience、role） UI 导航文案和预期重定向路径 对每份受影响的文档，分类处理： 1. 需要修补 — 更新步骤、预期结果或安全断言 2. 需要备注 — 添加前置条件说明或分支路径说明，避免测试者困惑 3. 无需变更 — 显式记录为什么不受影响 核心规则：永远不要只创建新文档而忽略已过时的旧文档。 人类到底在做什么 这是人机协作，不是替代。以下是我日常实际做的事情： 规划：决定做什么、定义验收标准、选择架构权衡。AI 搭脚手架，我掌方向。 审查：我审查生成的测试文档，以及新功能/重构的第一版代码。QA 执行和工单修复循环？交给 AI 自主完成。审查精力集中在最关键的地方——定义正确性的规格，和确定方向的初始实现。 纠偏：流水线产生误报时，我审查根因分析。Governance 标记 P0 时，我决定修复方案。 架构：领域建模、数据流设计、安全边界——这些需要对系统的判断力，不只是对代码。 在这个项目中，我花费了同样的私人时间，却可以得到超过10倍的成果。 这不是说我们可以完全放手让 AI 做所有的事情。经过了 20 轮迭代，我们依然可以看到 AI 的测试会产生工单——但比起最初的版本，这些工单越来越少，应用的细节也越来越丰富。这种体验，和人类工程师做的事情很相似：我们通过反复的 QA 不断消除 bug，对软件进行打磨。区别在于，这个打磨循环现在跑得更快了，而且每一轮都有据可查。 人类的核心价值在于定义"我们想做什么，不想做什么"，并提供足够好的品味和判断。而 AI 则负责高效地实现这个定义，并通过自动化测试不断验证和修正。 这里有一个重要的观察：实际上人类专家的角色变得更加关键了——我们需要构建一个能让 Agent 进行验证的环境，这就要求人类专家不仅要懂开发，还得熟悉基础设施。同时，对 DevOps 和安全问题的关注，能帮助人类专家更全面地审查文档，并持续优化整个流程。说白了，我们需要的是真正的全栈工程师。 作为开发者，我一向推崇极限开发。作为techlead，我信任我的组员们，但我会尽可能的用包括测试驱动在内的敏捷开发方法论来做风险管理。所以，对于 AI，我的看法相当开放，我认为几乎所有用于软件开发的风险管理手段，尤其是极限编程实践，都可以用于对 Agent 进行管理。 诚实的局限性 这套方法不是魔法。以下是目前做得不够好的地方： 全新的架构决策 — AI 擅长实现它见过的模式。对于真正新颖的设计选择，人类架构师仍然主导。 安全审查 — AI 生成安全测试文档并执行，但威胁模型本身需要人类安全专家。自动化测试能捕捉已知模式，但发现不了新型攻击向量。 流程需要项目适配 — 这套流程本身需要对具体项目进行优化。比如有些项目可能不需要 UI 测试，有些项目可能更侧重 API 或数据层验证，需要根据项目特点调整技能组合和测试重点。 数字说话 16 个 Agent Skills，覆盖完整开发生命周期 156 份测试文档（96 QA + 48 安全 + 12 UI/UX） 9 个工具脚本，用于 token 生成、API 测试、gRPC 冒烟测试 ~2,300 行 skill 定义 1 个人类 为什么选择 IAM？ 为什么用身份认证平台来测试开发方法论？ 因为简单问题检验不了方法论。一个 TODO 应用或博客引擎什么都证明不了——领域太简单，任何方法看起来都不错。IAM 逼你面对： 不能糊弄的安全 — Token 验证、权限执行、注入防护。48 份安全测试文档的存在是因为"我本地跑通了"在认证领域不可接受。 多系统协调 — Keycloak、TiDB、Redis、Rust 后端、React 前端。Token Exchange 流程里的一个 bug 会触达每一层。 状态复杂度 — 多租户数据隔离、层级化 RBAC、会话管理。状态空间大到手动测试无法覆盖。 如果 AI 原生的开发流程能打磨出一个合格的 IAM 平台，那它对大多数应用都适用。 自己试试看 想试试看？clone 这个项目，然后在项目下执行 scripts/runqatests.sh，agent 会自动启动环境，然后开始执行 SDLC。当然你可以先 review 一下这个脚本，这是个好习惯。 或者，启动 opencode（或者 claudecode），然后告诉你的 agent：执行所有 QA/安全/UIUX 测试——然后你就可以看看 agent 会开始做什么事了。对了，gemini 的效果其实也不错。 审计日志——每一次登录和 token 交换都有记录 这套方法论不是身份认证平台专用的。它是一种思考 AI 主导开发的方式：不要只用 AI 更快地写代码——用它闭合"规划、测试、修复、部署"的循环。 Auth9 是自托管的身份认证和访问管理平台（Auth0 替代方案），基于 Rust、React Router 7、TiDB 和 Keycloak 构建。AI 原生开发流水线使用 Agent Skills 架构配合 16 个自定义技能。
Original—
ProxyCC - AI模型中转站导航，一键对比Claude Code/OpenAI/Gemini中转平台
工具介绍 ProxyCC 是一个 AI 模型 API 中转站导航平台，聚合了国内主流的 Claude Code / OpenAI / Gemini 等大模型 API 中转服务，提供价格对比、稳定性评测和接入教程，帮助国内开发者快速找到合适的中转方案。 国内开发者使用 AI 大模型 API 一直面临两个核心问题：一是官方 API 国内访问困难，二是中转平台众多、价格和服务参差不齐，选错了既浪费钱又影响开发效率。ProxyCC 把市面上的中转平台汇总到一起，横向对比价格、速度、稳定性，一键跳转注册，零门槛上手。 网站地址： GitHub 适用场景 国内开发者需要接入 Claude Code / OpenAI / Gemini 等 API，但无法直接访问官方服务 手上有多个中转站，想要对比价格和稳定性，选择最优方案 新手第一次配置中转 API，需要详细的图文教程 团队选型，需要横向对比各平台优劣势 核心价值 一站式对比：收录 10+ 主流中转平台，价格、模型支持、稳定性一目了然 零门槛导航：无需注册，打开即用，选好平台一键跳转 持续更新：平台信息和价格实时维护，避免踩坑 配套教程：提供 Claude Code / OpenAI 等主流模型的详细接入指南
Original—
agent回答120道问题，测agent的MBTI，36种ABTI
这是一个纯娱乐性质的给agent测试mbti的地方 以agent自主答题为主要测试形式，一共120问，36种人格，详细人格表还有最佳匹配 复制粘贴skills即可让agent开始测试 指路 👉
Original—
Auxora - AI + 真人专家监督的广告投放平台，7 个品牌跑出 6x ROAS
请 agency 投广告，$2,500/月起步，等两周出方案，效果好不好全凭运气。自己学？Google Ads + Meta Ads + SEO 一整套，几个月入门都算快。纯 AI 工具？方案出得快，但没人把关，钱烧了不知道烧在哪。 我们做了第四种选择：AI 做 80% 的执行，真人 PPC 专家审核每一个关键决策。 类似自动驾驶 AI 开车，专家当安全员。花的不是盲目试错的钱。 网站：auxora.ai 工作流程 | 步骤 | 说明 | ||| | 1. 聊 5 分钟 | 对话式了解你的业务、目标客户和预算，不用填表 | | 2. AI 出稿 | 几小时生成 GTM 策略 + 广告素材 + Landing Page + Google/Meta Ads 配置 | | 3. 专家审核 | 资深投手检查定向、素材、预算分配，把 70 分草稿拉到 80+ | | 4. 48h 上线 | AI 7×24 监控优化，专家定期复审策略 | Agency vs Auxora 数据 | 指标 | 数值 | ||| | 付费品牌 | 7 个（VOMO、TicNote、XMind.AI 等） | | 平均 ROAS | 6x | | AI 执行占比 | 80–90% | | 专家时间节省 | 30–40% | 定价 | 方案 | 月费 | 包含内容 | |||| | Starter | 免费 | 200 credits / 1 个项目 / 市场概览 | | Growth | $49.99 | 10K credits / 5 个项目 / 完整 GTM 报告 + 投放 | | Pro | $249.99 | 无限项目 + 真人专家 1v1 | 对比：传统 agency $2,500–$10,000/月，多月合约锁定。 适合谁 D2C / 电商 想要 agency 级投放但预算有限 SaaS 需要精准 Google Ads + 再营销漏斗 独立开发者 / 创业者 有产品不知道怎么推 小企业主 请不起专人，也没时间自学 加入 Discord 我们搭了一个增长社区，不只聊 Auxora，更多是聊怎么把产品推出去： | 频道 | 聊什么 | ||| | growthtactics | 实战投放经验，踩过的坑比成功案例更值钱 | | askanexpert | PPC 专家在线，投放问题直接问 | | showyourproduct | 展示你的产品，互相反馈找灵感 | | indiehackerscn | 中文独开专区，聊产品、变现、推广 | 不管你是已经在投广告还是刚开始想推广，进来聊聊，总比一个人摸索强。 discord.gg/UWVxh83c
Original—
Memory Palace Openclaw版：给 OpenClaw 装上真正可用的长期记忆系统，致力于打造更适合openclaw的记忆系统，帮助你科学养虾
MemoryPalaceOpenclaw是一个专为 Openclaw设计的开源记忆系统插件（AGPLv3），解决 openclaw自带记忆系统不好用的专门设计的记忆插件。 OpenClaw 🦞是目前最火的开源个人 AI Agent，但它自带的记忆能力非常有限 —— 只有一个 MEMORY.md 文本文件，没有检索、没有去重、没有质量控制。MemoryPalaceOpenclaw补上了这块：自动记忆、自动回忆、写入守卫、智能检索、可视化管理，让你的OpenClaw真正「越用越懂你」。 我对比了全网 11 个专为 OpenClaw 设计的记忆开源项目 相关竞品 核心功能对比 MemoryPalaceOpenclaw的独家优势 Memory Palace 是功能最完整的一个。 特性 🧠 6 个独家能力（其他 11 个竞品都没有）： 视觉记忆 — 全网唯一。用户发的截图/流程图，自动提取 OCR、实体、场景等 6 维信息存入记忆库，下次可搜索 Web Dashboard — 唯一有完整可视化界面的。5 页面板：记忆浏览、写入审查 + diff 回滚、索引维护、搜索诊断（中英双语） 4 档 Profile 体系 — A 档纯离线 / B 档零配置起步 / C 档 API 语义检索 / D 档 LLM 全功能。按手头资源选档，每一档都是完整可用的产品 对话式 Onboarding — 把 onboarding 文档丢给 OpenClaw，跟着对话走就能完成安装配置，不用手动改配置文件 Plugin + Skills 分层架构 — Plugin（TypeScript）管「有什么能力」，Skills（Markdown）管「什么时候用」。可以换策略而不碰代码 MemoryNative Benchmark — 专为记忆场景设计的评测体系（非套用学术数据集），覆盖 factual/temporal/causal/exploratory 四类查询 🔧 核心工程能力： Write Guard（写入守卫）：Precision 1.000（规则模式零误拦）+ Score Normalization（自动适配不同 embedding 模型分数分布） AutoRecall / AutoCapture：对话开始自动注入相关记忆，对话结束自动提取有价值信息存入 Intent Recognition：4 种搜索意图分类（factual/exploratory/temporal/causal），规则模式准确率 0.910，LLM 模式 0.940 ACL 多智能体隔离：基于 URI 前缀的记忆隔离，多 Agent 场景下互不串记忆 注入防御：覆盖英/中/日/韩四语言 + NFKD 归一化 + 零宽字符清理 + Cyrillic 同形字检测 Host Bridge：安全桥接 OpenClaw 宿主的 USER.md / MEMORY.md（TOCTOUresistant + 符号链接阻断） 📊 D 档 Benchmark 结果： | 指标 | 结果 | | | | | 记忆检索 HR@10 | 0.917 | | 写入守卫 Precision | 1.000 | | 意图识别准确率 | 0.940 | | 矛盾检测准确率 | 0.950 | 技术栈 后端：Python (FastAPI) + SQLite + MCP 协议 插件层：TypeScript（OpenClaw Plugin API） 前端 Dashboard：React + Vite + TailwindCSS 行为层：Markdown Skills（可替换、可定制） 平台支持：macOS / Windows / Linux 截图 系统架构： Dashboard — 记忆浏览页面： Memory Dashboard — 可观测性页面： Observability OpenClaw 实际对话中的记忆回忆： 其他链接 📖 中文 README： 📊 完整评测文档： 🏗️ 技术架构总览： 🔐 安全与隐私：
Original—
Markdown 转 Microsoft Word 格式， 支持样式定制， 支持Mermaid 图片 （多入口支持： vscode 插件， SKILL，Chrome 插件，以及命令行支持）
你好，推荐一个我最近开源并持续维护的项目：marktodocx。 GitHub： VS Code Marketplace： ClawHub： 它是一个 Markdown 转 Word（.docx） 工具，但我想解决的不只是“能转”，而是 同一份 Markdown 在不同入口下导出的结果尽量一致。 现在它支持 4 个入口： CLI VS Code 扩展 Chrome 扩展（已完成，Chrome Web Store 还在准备） Agent Skill 项目特点： 支持标题、列表、表格、代码块、代码高亮、引用块、本地图片、Mermaid 支持样式预设、页边距预设、自定义样式覆盖 共享同一套转换核心，而不是每个入口各写一套 用 parity 测试保证不同入口的 DOCX 输出尽量一致 适合周报、技术文档、项目报告、知识库导出这类开发者常见场景 这个项目和常见 Markdown 转 Word 工具相比，我觉得比较不一样的点是： 1. 不是只做一个命令行工具，而是同时覆盖编辑器、浏览器、Agent/AI 调用场景 2. 重点不是“支持多少格式”，而是“多个入口输出一致”，避免同一文档换个入口导出就变样 3. Mermaid、本地图片、代码高亮这些对技术文档很重要的能力是重点支持对象 一句话介绍的话，可以概括成： 同一份 Markdown，不管你从 CLI、VS Code 还是 Agent 入口导出，尽量得到一致的 Word 文档。 如果周刊觉得合适，我也可以补充： 示例 Markdown 导出后的 DOCX 效果图 各入口的实际使用演示 参看项目 README.md 谢谢。
Original—
一个用 Codex 做的旅游规划小网站
🧳 一个用 Codex 做的旅游规划小网站 前段时间用 Codex 做了一个旅游规划网站，算不上什么大项目，但做下来还挺有意思的，就拿出来和大家分享一下，也顺便记录一下整个过程。 🤔 为什么会做这个项目？ 其实原因很简单——信息太碎了。 平时出去玩，最麻烦的不是“没地方去”，而是各种信息分散在不同平台： 📍 攻略在小红书 🍜 吃饭看点评 🗺 路线靠地图 🏨 住宿还要单独查 最后经常变成： 👉 开一堆页面 + 脑子里拼路线 = 依然很乱 💡 我的想法 所以我就在想： 有没有一种更省事的方式？ 👉 只需要输入几个关键信息，就能直接生成一份可参考的行程 比如： 去哪个城市 玩几天 预算多少 和谁一起 想要什么风格（休闲 / 特种兵 / 美食 / 打卡 等） 然后系统直接给你一版“能用的”行程，而不是让你每次都从零开始拼。 🏗️ 项目是怎么做的？ 整个项目其实就是围绕这个思路搭建的： 🧠 大模型 使用：通义千问 主要负责： 行程生成（每天怎么玩） 路线顺序安排（先去哪后去哪） 推荐住宿区域 控制整体节奏（轻松 or 紧凑） 🗺️ 地图能力 使用：百度地图 API 负责： 地点检索 坐标转换 地图打点 路线展示 🎨 前端设计思路 前端没有做成传统“工具页面”，而是尽量往这个方向靠： ✍️ 更像一个「旅行委托单」，而不是一个表单系统 希望用户在使用的时候，感觉是在规划一次旅行，而不是在填后台数据。 🌐 👉 l.chi588.com 🙈 最后 前端可能有点“直男审美”，大家轻喷 😅 如果有任何建议或者想法，也欢迎交流～
Original—
github-unflag-playbook-cn —— GitHub 账号被 flag / 被隐藏后的中文自救手册与案例库
最近做了了一个开源仓库： githubunflagplaybookcn 它主要记录这样一种比较少被系统整理的问题： GitHub 账号被 flagged / hidden from public view 之后，用户会遇到什么现象、应该怎么走 support / appeal 流程、以及有哪些真实案例可参考。 因为我自己最近刚经历过一次，过程中发现相关信息非常分散： 一部分在 GitHub 官方文档 一部分在 GitHub Community 讨论 还有很多是用户零散分享的经验 而且，对于我们中国区来说，这个过程往往更麻烦，因为 SMS verification 可能会成为非常现实的障碍。 所以我做了这个仓库，想把这些内容系统整理起来。当前主要包括： 1. flag 是什么 2. 被 flag 后的常见现象 比如：主页对外不可见、搜索不到、contributions 别人看不到、第三方授权异常等 3. 社区案例中常见的可能原因 这里只做经验归纳，不冒充官方结论 4. support / appeal / reinstatement 的处理路径 5. 案例库 汇总不同用户的经历、耗时、恢复方式 6. 存在档案（existence ledger） 记录那些因为账号被隐藏而一度像“从平台上消失”的开发者 这个仓库不是想去告诉大家如何 GitHub moderation，而是想帮助我们其他中国区开发者在遇到类似情况时，更快知道发生了什么、应该怎么处理，以及别人是否也遇到过类似问题。 如果你有类似经历，或者觉得这个仓库还缺哪些内容，欢迎提 issue / PR / 讨论。 也欢迎补充案例，尤其是我们中国区在实际申诉和恢复过程中的经验。
Original—
基于 CBETA 经典文献的汉传佛教祖师教学角色生成器
人工智能 基于 CBETA 经典文献的汉传佛教祖师教学角色生成器 Masterskill 是一个基于真实 CBETA 经典文献的汉传佛教祖师教学角色生成器，预置玄奘、鸠摩罗什、慧能、智顗、法藏、印光、蕅益、虚云 8 位祖师，把"不知从哪本书读起"的入门门槛降到"直接和某位祖师对话"。所有回答由 HARDGATE 校验：无 CBETA 经文出处则拒绝生成，杜绝 LLM 编造经文。每位祖师附带 5 条自动保真度测试样例和离线经文片段，fojin.app/chat 左下角「法师模式」可浏览器直接体验，无需安装。 亮点 HARDGATE 真经文校验：无 CBETA 命中则不出答，每个 PR 都会在 CI 里跑 fidelity smoke 自动回归，彻底拦住 LLM 幻觉引经文 8 位祖师人格差异化对齐：宗派语气、判教立场、核心术语各自对齐，不是换个名字的通用 LLM 多平台原生插件：Claude Code / Cursor / Codex / OpenCode / Gemini CLI 五端共用一份 prebuilt 树 离线经文片段打包：fojin.app 不可用时仍可引用 CBETA 核心段落 浏览器零安装：fojin.app/chat 左下角「法师模式」直接体验，不懂技术的读者也能用 伦理边界明确：ETHICS.md 写明 AI 透明度、版权 Tier AD、教界禁止行为（不传戒、不印证开悟、不做修行诊断）、代码 MIT + 内容 CC BYNCSA 双轨授权 \\\bash 方式一：浏览器直接用（推荐非开发者） → 点左下角「法师模式」 方式二：NPX 安装到 Claude Code / Cursor / Codex CLI npx masterskill install huineng zhiyi yinguang 使用：直接在支持 AgentSkills 的环境里调用 /huineng 如何理解"菩提本无树"？ 多祖师对比 /comparemasters 什么是空性 masters kumarajiva,huineng \\\ 截图或演示视频 浏览器体验入口： （左下角点「法师模式」）
Original
—
OpenVitamin 是一个本地优先的 AI 平台，统一承载模型推理、图片生成、工作流编排与智能体能力组合。
Python 本地优先的 AI 平台，统一承载模型推理、图片生成、工作流编排与智能体能力组合。 这是一个面向个人与团队的可私有部署推理平台，统一承载模型推理、工作流执行与智能体能力编排，强调可观测、可审计、可扩展。 技术架构：采用 Vue 前端 + FastAPI 推理网关。网关统一接入多种推理后端（如 Ollama、LM Studio、本地 GGUF、OpenAI 兼容 API 等），并支持与 OpenClaw 进行后端集成；前端不直连模型与工具，所有调用通过网关统一出口。它包含了： Web UI：控制台，负责界面与交互 推理网关：中枢，负责模型路由、请求编排与执行策略 Agent / Plugin：能力模块，以插件形式扩展（Skill、Tool、RAG、记忆等） 适用场景 统一管理本地模型与云端模型 搭建多模态聊天与视觉能力 用 Agent + Skill + Tool 组织能力 用 Workflow 编排多步 AI 流程 管理知识库、RAG 与长期记忆 运行本地文生图模型并管理生成任务 将 OpenClaw 作为上游模型后端接入统一推理网关 亮点 统一推理网关，覆盖 LLM、VLM、Embedding、ASR 与 Image Generation 本地模型与云端模型统一纳入一个控制面管理 文生图工作台支持异步任务、历史记录、缩略图、warmup 与取消 智能体系统支持 Intent Rules、Skill Discovery、Tool Calling 与 Direct Tool Result Workflow Control Plane 支持版本化、执行历史与分支 / 循环治理 内置知识库、RAG、记忆、日志、设置与备份能力 支持 OpenClaw 后端集成，可作为统一模型入口接入现有 Agent markdown 截图或演示视频
Original—
OutlierLabs
Decode why videos go viral. Replicate them.
—
Easy Grader
Easy Grading for teachers
—
Agent Express
Middleware framework for AI agents — Express.js for LLMs
—
PyroPlay
Watch movies, anime, live sports & shows for free
—
seedance 2.0
Create Cinematic AI Videos with Seedance 2.0
—
CommunityTracker
See where your brand appears across Reddit, LinkedIn & Slack
—
zenture
The quality layer on top of AI
—
MintMyStory
The professional engine for multimodal AI storybooks.
—
Lost Life Apk
Lost Life game, a 3D horror simulation game
—
AIPower
One API for GPT, Claude, DeepSeek, Qwen & 12 more models
—
Libertify.com
Turn any document into an interactive video
—
Falcon Africa
Smart marketing. Real growth. Focused on the Global market
—
Multibase Calculator
calculations binary,octal,decimal,hexadecimal,base 64
—
Flixier Edit by Transcript
Delete words and the video edits itself
—
Mantle SAFEs
Issue & sign SAFEs for free. No DocuSign required.
—
Meritas
Post a task, AI screens applicants, pay only when it's done
—
IrisGo Public Beta
AI OS for Workflow Automation
—
ClayHog
See what AI says about your brand and competitors
—
PhishByte
Build Team Resilience. Reduce Human Risk.
—
Kedarnath Tour Package from Rishikesh
Kedarnath yatra a sacred gateway to the Himalayas.
—
No matching projects
Try another keyword or category.
DEV TRENDS / COMMUNITY
Discuss this edition
Sign in with GitHub to share a thought, question, or useful follow-up.