Claude Design 是 Anthropic 2026 年 4 月推出的 AI 设计工具，社区在 4 天 内逆向出开源替代 Huashu Design，GitHub Star 一个月破 1.7 万。

1. 本质是 skill：一套注入 AI Coding 终端的设计 skill 文件，自然语言描述需求，Agent 自动生成成品，不是 SaaS 产品。
2. 七大交付能力：交互原型、可编辑 PPTX、60fps 动画、信息图、设计变体、风格顾问、5 维评审。
3. 品牌资产协议：5 步硬流程——问→搜→下载→提取色值→固化 spec，绝不从记忆猜品牌色。
4. Junior Designer 工作流：先问澄清问题、先出占位符、尽早展示——理解错比晚发现便宜 100 倍。
5. 反 AI Slop 规则：禁止紫渐变、emoji 图标、Inter 字体、过度圆角，用 oklch 色域和 CSS Grid。
6. 一句话总结：Claude Design 是更好的图形工具，Huashu Design 让图形工具这层消失。

RLHF 是大模型从"能用"到"好用"的关键一步。它不解决"模型知不知道答案"，而是解决"答案像不像人话"。

• 三阶段工作流：SFT 教指令遵循 → 奖励模型学打分 → PPO 用打分信号优化策略。
• 奖励模型的核心任务：给任意 prompt+response 打出标量分数，替代人类实时标注。
• PPO 的奖励不是纯 RM 分，而是 RM 分减 KL 惩罚——防止模型为刷高分胡说八道。
• PPO 对超参极度敏感，RM 不准确会导致优化跑偏，这是 RLHF 最大的工程难点。
• DPO（NeurIPS 2023）直接砍掉奖励模型和 RL，把偏好对齐变成分类问题。
• DPO 更稳定更省资源，已成 RLHF 主流替代方案。

SSE 和 STDIO 是 MCP 的两种传输方式，区别不在通信模式，在进程边界——STDIO 面向本地进程，SSE 面向远程服务。

• STDIO：客户端 fork 子进程，通过 stdin/stdout 收发 JSON-RPC，零网络开销
• SSE：客户端连远程 HTTP 端点，服务端推送事件，需处理鉴权和网络延迟
• 选择逻辑：本地工具用 STDIO，远程共享服务用 SSE，场景决定选型
• 核心差异：STDIO 进程由客户端管理生命周期，SSE 服务端独立部署
• MCP 演进：原始 HTTP+SSE 已被 Streamable HTTP 替代，不再需要双通道拆分
• 关键提醒：本地工具用 SSE 是自找麻烦，多了端口、CORS、鉴权，收益为零

对齐是把"会说话的模型"变成"能帮忙的助手"的关键一步。

• 问题：基座模型只会续写 token，不会服从指令。
• 定义：对齐 = 让输出符合有用、诚实、无害 三 个标准。
• SFT：用"指令→回答"样例做监督微调，教会模型执行任务。
• RLHF：人类打分排序 → 训练奖励模型 → PPO 强化学习优化。
• DPO：直接从偏好数据学习，省掉奖励模型，训练更稳定。
• 代价：过度对齐有"对齐税"——创造力下降，安全与能力需要取舍。
• 现实：对齐不是一锤子买卖，用户反馈是最好的持续对齐信号。

.vscode/launch.json 不是 Claude Code 的配置文件，但它是 Claude Code 获得调试能力的"基础设施"——MCP 调试服务器通过它让 AI 学会打断点、查变量、单步执行。

1. launch.json 的归属：它是 VS Code 调试器的配置，定义"怎么启动调试器"——用 Node 还是 Python、传什么参数、设什么环境变量。
2. Claude Code 怎么调试：通过 MCP 服务器（如 Claude Debugs For You）桥接——Claude 发指令 → MCP 翻译 → 调 VS Code Debugger API → 读 launch.json → 启动调试。
3. Claude Code 自己的"launch config"：不在 .vscode/，在 .claude/settings.json（权限和钩子）+ CLAUDE.md（项目指令）+ .mcp.json（工具集成）——它定义的是"AI 怎么跑"，不是"程序怎么跑"。
4. 核心区别：launch.json 回答"程序从哪里启动、参数是什么"；Claude Code 配置回答"AI 能改哪些文件、能用什么工具、每一步要遵循什么流程"。
5. 一句话记住：launch.json 是程序的入口，Claude Code 配置是 AI 的入口——两件事别搞混。

AI 模型的流式输出本质是单向长文本推送，SSE 比 WebSocket 更合适，多数场景不需要双向通道。

• SSE：基于 HTTP，服务端到客户端单向推送，内置自动重连，零额外握手成本
• WebSocket：全双工双向通信，需要协议升级，实现复杂、资源开销大
• 选择逻辑：AI 问答是客户端发一条请求、服务端流式返回文本，单向通道完全够用
• 双向需求：语音对话、实时协作编辑才需要 WebSocket，纯文本问答不需要
• 坑 ①：HTTP/1.1 下同一域名最多 6 个 SSE 并发连接，多标签页可能占满
• 坑 ②：组件卸载时忘记手动关闭 EventSource，连接不会自动释放，导致内存泄漏

金字塔结构说白了就一句话：先给结论，再用论据逐层支撑。

• 结构：塔尖是核心结论，第二层是分论点，第三层是具体论据——顺序不能倒。
• 原理：大脑处理信息量有限，你把拼好的图给对方看，对方只需判断对不对。
• 用法：结论 + 三个理由 + 具体证据，开会、写邮件、做汇报直接套模板。
• 潜规则：同一层论据必须 MECE——相互独立、完全穷尽，否则金字塔就塌了。
• 边界：适合说服和汇报，不适合头脑风暴——没结论时硬套就是在忽悠。
• 误区：多数人习惯先列数据再推结论，这是把金字塔倒过来建，谁都看不懂。

函数组件 re-render 的根因只有一条：引用变了。state 更新、props 变化、父组件渲染、context 值变化——本质上都是"某个引用不等于上一次的引用"。

• React.memo 决定"要不要渲染"：props 浅比较通过就跳过，不通过就走正常流程
• useCallback / useMemo 保证"引用稳定"：让 memo 的浅比较真正生效，否则每次渲染新引用，memo 形同虚设
• 三者是组合拳：只用 memo 不缓存引用 → 白用；只缓存不用 memo → 也白用
• 拆分组件 +状态下移 往往比加 memo 更治本：把频繁更新的状态隔离在小范围组件内
• 列表用 id 做 key，保证增删排序时最小 DOM 更新；纯分页无排序删除可用 index，反而更高效
• React 19 的 React Compiler 自动处理记忆化，但理解原理仍然是排查性能问题的基础

input:checked 改成父元素边框高亮、img 存在时父容器切两栏布局、表单校验状态动态联动——以前这些都需要 JS 去监听子元素状态再回头改父元素。:has() 的出现，把"子元素状态驱动父元素样式"这件事直接搬进了 CSS。

1. 核心能力：:has() 是名副其实的父选择器，根据子元素/后代/兄弟的状态反向匹配父元素或前面的兄弟。
2. 浏览器覆盖：Chrome 105+、Safari 15.4+、Firefox 121+ 已全部支持，2024 年底起可以在生产环境放心用。
3. 性能真相：锚定到具体类（.card:has(img)）的开销是微秒级；只有 div:has(...) 这种宽泛选择器 + 频繁 DOM 变更时才是问题。
4. 能用 CSS 就别用 JS：表单校验态切换、空状态检测、数量查询这些场景，:has() 替代 JS 后代码量减半、不会漏同步。

性能提醒：:has() 选择器锚定越具体越好，避免 body:has()、*:has() 这种全局监听。

AI Coding 工具越来越多，配置文件越来越乱——CC Switch 用一个 GUI把 Claude Code、Codex、Gemini CLI 等工具的 Provider、MCP Server、Skills 全管起来，一键切换，不用再手改 JSON。

1. What：桌面应用，系统托盘常驻。50+ 内置 Provider 预设，一键盘切换 API 供应商，所有工具的配置自动同步。
2. Why：Claude Code 一天切三次模型，Codex 用 Kimi，Gemini CLI 用 DeepSeek——三个工具三套配置，手动改早晚改出问题。
3. How：Tauri 2 + React + Rust。本地 SQLite 存配置，内置代理做请求转发和自动故障转移。配置修改走原子写入，不会写到一半断电变砖。
4. 隐藏能力：MCP 双向同步——在 CC Switch 加一个 MCP 服务，Claude Code 和 Codex 都能用。Skills 从 GitHub 一键安装，自动检测更新。
5. 一句话记住：你不需要手动改 settings.json 了。