Skip to main content

黄金海岸

黄金海岸
黄金海岸

  4. 📣 #发现频道
    【开源自荐】BriefyPet：一个用 RSS + LLM + 桌宠提醒筛选高价值信息的桌面阅读助手
    https://meta.appinn.net/t/topic/84787
    小众软件官方论坛
    【开源自荐】BriefyPet：一个用 RSS + LLM + 桌宠提醒筛选高价值信息的桌面阅读助手
    软件名称 BriefyPet 应用平台 Windows macOS 推荐类型 【开发者自荐】 一句简介 BriefyPet 是一个开源桌面 AI 阅读助手，用 RSS、LLM 摘要和桌宠提醒，帮用户筛选优质信息。 开发背景 项目的起因是我的一个心得：信息焦虑更多由信息过载而非信息不足造成。 有价值的一手内容分散在英文博客、团队主页、学术动态和产品更新里；但日常刷到的内容，往往经过二次转载和重新包装。 RSS 本来可以帮助用户重新掌握信息源，但普通 RSS 阅读器也有一个问题，需要用户…

  6. 我自己收集的 PPT 设计技巧资源：

    1. 杂志风格 PPT 设计
    https://github.com/op7418/guizang-ppt-skill

    2. 带设计动画的 PPT 技巧
    https://github.com/alchaincyf/huashu-design

    3. 7 种不同风格的 PPT 设计
    https://github.com/software-ai-life/Awesome-PPT-Design-Skills

    4. 复刻 Claude Design 的开源替代品
    https://github.com/nexu-io/open-design
    （本地优先、开源，包含 19 项技能、71 个品牌级设计系统，已获 4k+ Stars）
    GitHub
    GitHub - op7418/guizang-ppt-skill: A Claude Code Skill that turns prompts into horizontal-swipe magazine-style HTML decks — 10…
    A Claude Code Skill that turns prompts into horizontal-swipe magazine-style HTML decks — 10 layouts, 5 curated themes, WebGL hero backgrounds, single-file output. - op7418/guizang-ppt-skill

  7. 设计原型制作要来回切换AI工具、设计软件和代码编辑器，品牌设计系统还得手动搜集参考，效率低下且容易出错。

    Open Design 把Claude Design的全部能力开源复刻，提供了完整的本地优先设计解决方案。

    95%+还原度，内置19个设计技能和71套品牌级设计系统，支持Claude Code/Codex/Cursor/Gemini等所有coding agent，沙盒预览+HTML/PDF/PPTX导出。

    主要功能：

    - 19个专业设计技能，覆盖Web原型、移动App、杂志式PPT、仪表盘、文档模板等；
    - 71套品牌设计系统（Linear/Stripe/Vercel/Airbnb/Tesla/Notion/Apple等），一键复用；
    - 本地daemon自动识别CLI agent，支持真实文件系统读写和项目持久化；
    - 交互式问题表单+5种视觉方向选择，避免无效迭代；
    - 沙盒iframe实时预览，支持设备边框（iPhone15Pro/Pixel/MacBook等）；
    - 多格式导出（HTML/PDF/PPTX/ZIP），支持持续追问修改。

    支持Web/Vercel部署，通过pnpm dev:all本地运行，BYOK零订阅成本，适合设计师和开发团队。

  8. 基于GPT 生成的文字海报。

    提示词：

    请基于输入的【你的文字】，创作一张高完成度的「现代平面几何字体概念海报 / Geometric Typographic Concept Poster」。这不是普通插画，也不是简单把文字放大后的字效海报，而是一张“基于主题词含义自动构建视觉隐喻”的现代平面设计海报。画面需要以文字为主视觉，以几何图形、色块、线条、空间关系、透明叠层、模块化结构和符号化元素作为语义延展，让观众一眼感受到这个词语的气质、情绪、关系和内在含义。

    提示词抄的推特的现在原文找不到了🤣有也刷到的朋友麻烦把链接补在评论区吧

  9. 分享一份我在 kimi cli / cc 中常用的 (shadcn+twcss) 前端 DESIGN.md init prompt, 可根据自己的需求适当修改:

    # Role: 高级前端架构师 & DESIGN.md 维护者

## Objective
你需要作为一个 Orchestrator，调度多个并发 Sub-agent 和并发 Function (Tools) calls，全面以 READ ONLY 模式区审查当前 codebase 中的前端代码库的结构与样式配置，理解并提炼出全局设计哲学，并输出 DESIGN_SPEC 规范文档。

## Execution Strategy (并发与检索)

1. **并发读取**: 使用并发的函数调用（Concurrent Function Calls）或生成多个 Sub-agent，并行读取和分析代码库。
2. **目标范围**:
   - INCLUDE: 根目录下 *.md 文件, 特别是 AGENTS.md / CLAUDE.md / GEMINI.md / DESIGN.md
   - INCLUDE: `src` 目录下的所有业务线 `tsx/ts` 组件、Layout 布局文件。
   - INCLUDE: 全局样式配置（如 `tailwind.config.*`、`index.css` 或相关的 Tailwind CSS/CSS Module 配置文件）。
   - MUST BE: 排除：第三方基础 UI 库的源码（如 `shadcn/ui` ui 组件库）、`node_modules`、任何构建产物。任务执行期间只允许查询和搜索，严禁增加、修改、删除当前的代码库。

## Task 1: 提炼全局设计哲学并生成 `DESIGN.md`

在完成并发分析后，归纳前端 App 的视觉与架构共性，在根目录创建或更新 `DESIGN.md`。该文档必须包含以下维度：

- **视觉层 (Visual Identity)**: 核心色彩系统、排版规范、间距与阴影的工程化实现方式。
- **布局层 (Layout Strategy)**: 全局容器、响应式断点策略、以及复杂交互/高密度数据 UI 的常见排布范式。
- **组件范式 (Component Paradigm)**: 业务组件的拆分逻辑、状态下发模式、以及复用标准。
- **样式实践 (Styling Rules)**: Tailwind CSS 的组合习惯，如何处理动态类名，以及覆盖默认样式的最佳实践。

## Task 2: 更新 `README AGENTS.md` (或类似 Agent 引导文档)

在 `AGENTS.md` (抑或是 CLAUDE.md) 中增加或更新相应的引导章节，使用其文件中的语言，向未来的 AI 编码助手说明：
- "在执行「前端开发任务 (开发新组件或页面...)」前，MUST 先阅读 `DESIGN.md` 以对齐全局设计哲学与 Tailwind 规范，确保生成的 UI 代码在视觉与交互上与现有工程保持高度一致。"

## Constraints
- 执行过程中，请保持思考的透明度，报告并发任务的分配与完成情况。
- 提炼的内容必须基于代码库中 **实际存在** 的代码规律，严禁凭空捏造设计规范。
- 任务执行时保持 [READ_ONLY_MODE] [EXPLORE_MODE], 只有当用户确认写入 DESIGN.md 后才能写入/覆盖 DESIGN.md。


    建议配合模型:

    - DeepSeek v4 Pro Max+Flash, 便宜量大, Flash 用于 sub agent 模型, TPS 更高一些

    - Kimi CLI + Kimi 2.6

    - Gemini 3.1 Pro / Claude Opus 4.6

    不建议配合:

    - GPT-*

  10. 拆解 AI 协作逻辑：Sub-Agents 与 Agent Teams 核心差异 | 推文

    多数人面对复杂任务时会惯性地堆砌多个 Agent，这往往是错误的。设计的核心不在于 Agent 的数量，而在于任务所需的协作模式：是需要隔离执行的 Sub-Agents，还是需要实时通信的 Agent Teams。

    目前的 AI 系统构建方式大多存在误区，当任务变得复杂，人们倾向于直接套用多智能体架构，但这其实是在增加不必要的系统开销。

    Sub-Agents 更像是函数调用。它是一个被高度隔离的实例，拥有独立的系统提示词、工具集和上下文。它只负责把混乱的探索过程压缩成一个干净的信号返回给父级。这种模式追求的是并行与隔离，Sub-Agents 之间无法直接对话，也不能互相创建新实例。这就像是把任务分发给不同的专业外包，你只关心结果，不关心过程。

    Agent Teams 则更像是一个动态运行的操作系统。它们强调协作，通过共享任务层和实时通信来同步状态。一个前端 Agent 发现变动，可以立刻通知后端 Agent。这种模式是持久且具有交互性的。

    很多人习惯按角色拆分，比如规划者、开发者、测试者。有观点认为，这种做法会导致严重的上下文丢失。执行者不知道规划者的初衷，测试者也不了解执行者的决策细节。每一次交接都是一次信息熵增。

    真正有效的拆分逻辑应该是基于上下文边界的。如果两个任务共享深层的背景信息，就把它们留在同一个 Agent 里。只有当上下文可以被干净地剥离时，才进行拆分。

    设计时可以参考这五种模式：提示词链、路由、并行化、编排者-执行者、以及评估者-优化者。

    如果任务本身很简单，或者 Agent 之间存在极强的依赖关系，强行引入多智能体反而会因为协调开销过大而导致系统崩溃。

    与其思考需要多少个 Agent，不如问问：这个任务到底需要什么样的协调？