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

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

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

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

.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 的入口——两件事别搞混。

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

• 结构：塔尖是核心结论，第二层是分论点，第三层是具体论据——顺序不能倒。
• 原理：大脑处理信息量有限，你把拼好的图给对方看，对方只需判断对不对。
• 用法：结论 + 三个理由 + 具体证据，开会、写邮件、做汇报直接套模板。
• 潜规则：同一层论据必须 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() 这种全局监听。

agent-browser 和 Playwright CLI 的区别不在"谁更好"，而在谁在做决策——是 LLM 自己看着办，还是人写好每一步指令。

1. agent-browser 目标驱动：给自然语言目标，LLM 自己规划并执行
2. Playwright CLI 步骤驱动：open → click → fill，每一步都得人写清楚
3. agent-browser 用 Accessibility Tree + @ref，Token 仅为完整 DOM 的 5%
4. Playwright CLI 交互结果写磁盘，Agent 按需读，Token 比 MCP 方案省更多
5. agent-browser 直连 CDP 复用登录会话；Playwright CLI 默认隔离上下文
6. 容错逻辑相反：agent-browser LLM 语义兜底，Playwright CLI ref 变就挂
7. 两条路都能走，走反了就是纯烧 Token

Playwright MCP 和 Chrome DevTools MCP 不是竞品——一个负责"开"，一个负责"修"。

1. Playwright 做浏览器自动化（干活），DevTools 做性能诊断（找问题）
2. Playwright 基于 Accessibility Tree，Token 仅为原始 DOM 的 20-30%
3. DevTools 基于 CDP，能拿到网络瀑布、Lighthouse、堆快照等完整运行时数据
4. Playwright 支持全平台浏览器；DevTools 仅 Chromium
5. DevTools 独有 Trace 自动分析、Lighthouse 审计、V8 堆内存快照
6. Playwright 独有 Auto-wait、跨浏览器测试、结构化定位

一句话：日常交互用 Playwright，需要性能/网络排查时切 DevTools。

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 了。

AI Coding 的下半场不是 更强的模型，而是更难违反的流程。

1. Superpowers 是什么：一套 Claude Code 插件，注入 14 个 skill，强制 5 阶段不可绕过流程。
2. TDD 硬约束：RED-GREEN-REFACTOR 循环被写进 skill 代码，测试必须先失败才能写实现。
3. 官方收编信号：Anthropic 一月将其纳入官方插件市场——承认纯灵活无法规模化。
4. 数据说话：任务完成率 62% → 89%，token 消耗增加 37%。
5. 版本化管理：skill 是文本文件，可 git 提交、code review——团队第一次能把 AI 写代码的规矩版本化。
6. 动态 vs 静态：相比 .cursorrules 和 CLAUDE.md，skill 按任务状态精确触发，不打扰无关流程。
7. 一句话记住：把规则写进 skill 代码，不是 prompt 里。