TUI 右下角才显示 60%、70%，自动 compact 突然就触发了——这是用 OpenCode 最高频的困惑。原因不止一个，按可能性从高到低排：

1. 给输出 token 预留 buffer：TUI 显示 80% 触发压缩，真正留给"历史"的安全位可能只有 50% 左右。
2. Tool calls 占空间：一次 Bash 输出几百行、一次大文件读取直接干到 10k+ tokens，这才是隐形杀手。
3. Provider 实际限制比标称小：qwen3.7-plus 在 OpenCode 上硬卡 200k（issue #30838），即使模型标称 1M。
4. Compaction 循环 bug：issue #29450 报过一句话烧光 200k 的 case，先升级 / 换 provider 再说。
5. 手动控制：用 /compact 自己把握时机，/compact 50 保留最近 50 条消息不压。

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

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

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 让图形工具这层消失。

Loop Engineering 不是写更好的 prompt，是把"下指令的人"从自己换成一套你设计好的系统。

• Boris Cherny（Claude Code 负责人）："我已经不 prompt Claude 了，我的工作是写 loops"
• 从 ReAct 到 Ralph Loop 到 Claude Code /goal，底层逻辑是从"手工"到"工业"的范式迁移
• 六大构件：自动化触发、工作区隔离、技能沉淀、MCP 连接器、子代理分离、外部状态持久
• 关键前提：任务高度重复，验证可自动化，团队有充足 Token 预算
• 适合 CI 故障排查、依赖更新等标准化流程；不适合架构重构等需要人类判断的决策

Loop 越顺畅，人越容易停止思考——验证偷懒和理解债比 token 账单更危险。

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

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

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

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

.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，连接不会自动释放，导致内存泄漏

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

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

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

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