黄金海岸
-
- 我自己收集的 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）GitHubGitHub - op7418/guizang-ppt-skill: AI-agent Skill for generating polished HTML slide decks: editorial magazine and Swiss layouts…AI-agent Skill for generating polished HTML slide decks: editorial magazine and Swiss layouts, image prompts, social covers, and a WebGL/low-power presentation runtime. - op7418/guizang-ppt-skill -
-
- 分享一份我在 kimi cli / cc 中常用的 (shadcn+twcss) 前端
DESIGN.mdinit 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-* - 拆解 AI 协作逻辑：Sub-Agents 与 Agent Teams 核心差异 | 推文
多数人面对复杂任务时会惯性地堆砌多个 Agent，这往往是错误的。设计的核心不在于 Agent 的数量，而在于任务所需的协作模式：是需要隔离执行的 Sub-Agents，还是需要实时通信的 Agent Teams。
目前的 AI 系统构建方式大多存在误区，当任务变得复杂，人们倾向于直接套用多智能体架构，但这其实是在增加不必要的系统开销。
Sub-Agents 更像是函数调用。它是一个被高度隔离的实例，拥有独立的系统提示词、工具集和上下文。它只负责把混乱的探索过程压缩成一个干净的信号返回给父级。这种模式追求的是并行与隔离，Sub-Agents 之间无法直接对话，也不能互相创建新实例。这就像是把任务分发给不同的专业外包，你只关心结果，不关心过程。
Agent Teams 则更像是一个动态运行的操作系统。它们强调协作，通过共享任务层和实时通信来同步状态。一个前端 Agent 发现变动，可以立刻通知后端 Agent。这种模式是持久且具有交互性的。
很多人习惯按角色拆分，比如规划者、开发者、测试者。有观点认为，这种做法会导致严重的上下文丢失。执行者不知道规划者的初衷，测试者也不了解执行者的决策细节。每一次交接都是一次信息熵增。
真正有效的拆分逻辑应该是基于上下文边界的。如果两个任务共享深层的背景信息，就把它们留在同一个 Agent 里。只有当上下文可以被干净地剥离时，才进行拆分。
设计时可以参考这五种模式：提示词链、路由、并行化、编排者-执行者、以及评估者-优化者。
如果任务本身很简单，或者 Agent 之间存在极强的依赖关系，强行引入多智能体反而会因为协调开销过大而导致系统崩溃。
与其思考需要多少个 Agent，不如问问：这个任务到底需要什么样的协调？ - 类似的，也是 TierHive 老板写的 #Debian 13 精简思路
https://tierhive.com/blog/tierhive-howto/debian-13-minimal-guide-reduce-ram-to-38mb-and-disk-to-275mb
#Linux #文章 - Claude Code + Obsidian + Git = 自动化知识库
不想整理文档？把文章/PDF 丢进 Obsidian，让 Claude Code 按你定的规则自动归类整理。
推荐结构：
• raw/ — 放原始资料（唯读）
• wiki/ — LLM 撰写与维护，含 index.md / log.md / overview.md
• AGENTS.md — LLM 操作手册
工作流：摄取→问答→定期 Lint，知识可持续迭代。P 人福音，再也不用翻山找文件。
Claude Code：https://claude.ai/code
Obsidian：https://obsidian.mdClaude
Claude CodeA shared Claude Code session on claude.ai/code - DeepSeek 研究员 Deli Chen（小红书 @陈小礼）发布了一组特殊提示词，可以用来在角色扮演（Roleplay）场景中，控制输出思考链是带有角色沉浸还是纯分析：
https://github.com/victorchen96/deepseek_v4_rolepaly_instruct -
