Claude Code发布快一年了，很多人还在摸索怎么用好它。最近Affaan开源了一个非常实用的配置合集，他是Anthropic黑客马拉松的冠军得主，用Claude Code从零构建了zenith.chat这个产品。
这套配置是他10个多月密集使用的结晶，包含了生产级别的agents、skills、hooks、commands和MCP配置。
先说几个有价值的部分：
关于Token优化，很多人不知道同时启用太多MCP会严重压缩上下文窗口。200k的窗口可能直接缩水到70k。他给的建议是配置二三十个MCP，但每个项目只启用不超过10个，保持工具数量在80以下。
关于Memory Persistence，这是一个非常聪明的设计。通过hooks在session开始时自动加载上下文，结束时自动保存状态。这解决了Claude Code会话之间记忆断裂的问题。
他设计了一套完整的Agents体系，每个都有明确的职责边界：planner负责规划，architect负责架构决策，code-reviewer做质量审查，还有专门的安全审查、构建错误修复、端到端测试等等。这种分工让Claude Code的输出更加专业和可控。
Skills部分覆盖了前后端开发的主要模式，包括React和Next.js的最佳实践、API设计、数据库和缓存模式、TDD工作流等。还有一个continuous-learning的skill，可以从session中自动提取模式形成可复用的知识。
Hooks的设计也很巧妙。比如有一个hook会在你编辑代码时自动检测console.log并发出警告。这种小细节能帮助养成更好的编码习惯。
安装方式很灵活，可以作为plugin一键安装，也可以手动复制需要的组件。他还贴心地把所有脚本用Node.js重写了，全面支持Windows、macOS和Linux。
最后他强调了一点：这些配置是他个人工作流的产物。建议从你认同的部分开始，根据自己的技术栈调整，删掉不需要的，加入自己的模式。
系统设计正在成为区分工程师和程序员的分水岭。对于即将踏入职场的应届生来说，这已经不再是可选项，而是必修课。
首先说清楚什么是系统设计。简单理解，写代码是给一个小程序写指令，而系统设计是规划如何让数百万用户流畅、可靠、快速地使用你的应用，即便某个部分出了故障也能正常运转。它像给一栋大楼画蓝图，你需要决定系统需要哪些组件、这些组件如何连接和通信、如何应对海量用户和服务器崩溃等现实挑战。
为什么应届生必须学这个？Google、Amazon这类产品公司在校招时已经开始考察系统设计，他们想看到你能进行全局思考，而不仅仅是写出局部代码。就连TCS、Infosys这类服务型公司，现在也会问一些基础的低层设计或简单的扩展性问题。好消息是，应届生面对的题目通常比较简单，比如设计短链接服务、停车场系统、限流器、电梯或基础的社交媒体动态，不会让你设计整个Netflix后端。面试官关注的是你的逻辑思维能力、做权衡的能力以及清晰表达想法的能力。
系统设计分两大类。高层设计关注宏观架构，描述主要组件如何连接；低层设计关注细节实现，包括类、方法和设计模式。以WhatsApp为例，高层设计考虑用户发消息到API服务器再到消息队列最后送达朋友手机的完整链路，低层设计则考虑如何设计Chat类以及它的发送和接收方法。
掌握正确的思维方式至关重要。系统设计没有标准答案，面试官真正在意的是你的推理过程和权衡取舍。每次设计都应该遵循这个流程：澄清需求、估算规模、画出高层架构、深入细节、讨论权衡。画图是成功的一半，建议使用Draw.io或Excalidraw这类免费工具。
接下来是8周学习计划。第一周掌握基础概念和面试方法论，理解功能性需求与非功能性需求的区别，搞懂CAP定理，银行系统偏向一致性，社交媒体偏向可用性。第二周学习扩展性和网络基础，包括水平扩展与垂直扩展、负载均衡、CDN等。第三周深入数据库存储，理解SQL和NoSQL各自的适用场景、ACID与BASE的区别、分片和复制策略。第四周攻克缓存和消息队列，掌握不同缓存策略以及Kafka、RabbitMQ的基本用法。第五周学习API设计和微服务架构，了解REST、gRPC、GraphQL的差异，关注AI和大语言模型API集成这类新趋势。第六周专注低层设计，牢记SOLID原则，练习停车场、电梯、图书馆等经典题目。第七周学习高可用模式和监控，包括熔断器、重试机制以及Kubernetes基础。第八周进入实战演练，练习URL短链接、限流器、社交媒体时间线等经典问题，配合模拟面试。
几个实用建议。每天投入4到6小时，自己动手画架构图，录制自己讲解设计的过程控制在45分钟内，在GitHub上实现3到5个设计方案形成作品集，争取完成8到10次模拟面试。亚马逊面试偏重低层设计，Google偏重高层设计基础，校招外的社招高峰期通常在2月到5月。
学习资源方面，Gaurav Sen的YouTube播放列表非常适合入门，GitHub上的system-design-primer项目涵盖了所有核心概念，GeeksforGeeks和roadmap.sh提供了清晰的知识图谱。
系统设计的核心不在于背诵标准答案，而在于理解权衡并像工程师一样思考问题。
Claude在编程方面确实非常出色，跟普通大模型相比简直是降维打击。但有一个问题值得所有使用者注意：它是“近视眼”。
因为它从来看不到完整的代码全貌，只能通过grep搜索找到相关代码片段。一旦grep返回了跟bug描述相似的代码片段，它往往就不再深入探索了，直接在不相关的地方“修复”问题，或者基于这些碎片化的信息来回答问题。
随着代码库不断膨胀，这个问题会越来越严重。如果使用者自己不了解代码结构，Claude就会不断重复造轮子，在应用的不同位置为相同功能创建重复实现。
有个真实案例很能说明问题：有人让Claude给一个按钮添加键盘快捷键，结果它复制了整个处理逻辑而不是调用已有的按钮处理函数。后来修改功能时，按钮和快捷键的行为就出现了不一致。
社区里已经有不少人在探索解决方案：
第一种是让Claude先绘制代码架构地图，包括主要子系统、职责划分、共享服务、容易重复的区域等，然后要求它每次操作前都参考这张地图并持续更新。
第二种是用CLAUDE.md文件预先定义项目结构、关键模式、哪些东西不能重复实现。
第三种是建立完整的文档体系，用Mermaid图表展示整个应用的连接关系，在每个主要模块下都放置readme文件，再配合文档更新工具来维护。
还有开发者分享了自己的做法：定期安排“停下来清理”的时间，专门检查文档、更新文档、合并重复代码。
有人提出了一个更根本的观察：这不仅仅是上下文窗口的问题，模型本身就被训练成“找到相关内容就停止搜索”的行为模式。
这个讨论揭示了一个重要认知：AI写代码很强，但绝不意味着人可以完全放手。架构思维和全局视野仍然需要人来把控。代码库越大，使用者对整体结构的理解就越关键。
说到底，当前最有效的方法还是建立一套外部记忆系统，让模型在每个重要步骤都能参考和更新，弥补它在长期记忆上的不足。
研究论文不是教科书，它们是面向专家的压缩论证。如果你像读博客一样去读论文，几乎必然会误解其中的内容。
首先要搞清楚一篇论文究竟在做什么。大多数论文无非是以下四类之一：更精确地定义问题、提出新方法、分析现有方案的失败或局限、对已有方法做增量改进。真正具有革命性的论文少之又少。如果你总期待看到颠覆性突破，反而会错过论文真正的贡献。
读论文的正确姿势是打乱顺序读。线性阅读效率太低。建议按这个顺序：摘要看论点和范围，图表看实际变化，结论看作者认为什么重要，引言看背景和框架，方法部分放到最后。这样做是为了在接触细节之前先搭建好心智框架。
尽早识别核心贡献。问自己一个问题：相比前人的工作，这篇论文改变了什么？可能是一个新假设、一个新目标、一种简化方案，或者一个更好的权衡取舍。如果你没法用一句话说清楚这个变化，就继续读，直到能说清楚为止。
要把假设和结果分开看。大多数论文之所以有效，是因为它们建立在特定假设之上。仔细寻找数据条件、简化处理、约束条件和理想化模型，然后问自己：这东西离开实验室还能用吗？这一步能避免盲目照搬。
把公式当作契约来读。公式定义了研究与现实之间的约定。对于每个关键公式，搞清楚每个项代表什么、忽略了什么、如果这个项出错会导致什么问题。不需要推导每一步，但要推导那条关键路径。
带着怀疑的眼光读实验部分。图表很有说服力，但细节才重要。检查基线设置、选择的指标、超参数配置和失败案例。没有展示失败案例本身就是一个信号。
把论文纳入你的知识图谱。一篇论文应该能连接到你已经知道的东西上。明确地把它和之前的方法、已知的局限性、其他表述方式、其他领域关联起来。孤立的理解会很快遗忘。
在合适的时候果断停止阅读。不是每篇论文都需要完全理解。当你已经理解了核心想法、知道它的位置、知道它什么时候会失效，就可以停下来了。深度理解可以等到真正需要的时候再来。
把阅读转化为输出。单纯的阅读是被动的。做以下任意一件事：用简单的话重新表述想法、画出算法草图、实现一个简化版本、向别人解释一遍。输出会揭示你到底理解了多少。
最后一条原则：不要问自己“我理解这篇论文了吗”，而是问“我能解释它为什么有效、什么时候会失败、我会不会用它吗”。
能回答这个问题，才算真正读懂了。
记录了超过2000个科幻创意和发明创造以及超过4300种科幻作品系列的基本资料，将不同类型科幻概念的作品按字母和时间分类汇总，也就是说大家可以用它来查询某一个科幻概念最早出现在什么作品里，有些还挺让人意外的。
最近开发者圈子里流传着一个有趣的玩法：用本地开源模型驱动Claude Code，实现完全离线、零API费用的AI编程助手。| 帖子
先说清楚一点：这套方案用的是Claude Code的工具链和交互框架，底层跑的是本地开源模型，并非Anthropic的Claude模型本身。但这恰恰是它的价值所在，你获得了一个能读写文件、执行终端命令、理解项目上下文的本地AI代理，数据完全不出本机。
整个搭建过程分四步：
第一步，安装Ollama作为本地模型引擎。Ollama负责托管AI模型并支持工具调用，安装后在后台静默运行。模型选择上，高配机器可以拉qwen3-coder:30b，普通配置用qwen2.5-coder:7b或gemma:2b也能跑。终端执行ollama run加模型名即可下载。
第二步，安装Claude Code本体。Mac和Linux用curl命令，Windows用irm命令，一行搞定。安装完用claude --version验证。如果之前登录过Anthropic账号，需要先登出。
第三步是关键，把Claude指向本地。默认情况下Claude会连Anthropic服务器，需要手动重定向。设置三个环境变量：ANTHROPIC_BASE_URL指向localhost:11434，ANTHROPIC_AUTH_TOKEN随便填个值比如ollama，再加上CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1关闭遥测。
第四步，进入任意项目目录，用claude --model加模型名启动，就能开始干活了。
评论区有些争议值得关注。有人质疑本地模型不支持工具调用，作者明确回应：支持。也有人反馈配置后无法创建文件，作者建议确保上下文长度超过32k，并尝试不同模型。还有人指出qwen3-coder:30b相比顶级闭源模型仍有差距，gemma:2b作为代理几乎不可用，而且要跑得流畅需要不错的硬件。
这套方案的真正意义在于提供了一种可能性：当你需要处理敏感代码、受限于网络环境、或者单纯想省钱时，本地AI代理是个可行选项。它不会取代云端大模型的能力上限，但在特定场景下足够实用。
至于什么时候能本地跑Opus 4.5？正如作者调侃的，得先问问Anthropic什么时候开源。
这背后的原理其实很直观。大语言模型本质上是因果语言模型，每个 token 只能“看到”它前面的内容。这意味着当你问“先给背景，再提问题”和“先提问题，再给背景”时，模型的理解深度是不同的。重复提示词相当于让每个 token 都有机会“看到”完整的上下文，弥补了单向注意力的先天缺陷。
研究团队在 Gemini、GPT、Claude、Deepseek 等七个主流模型上进行了测试，覆盖 ARC、GSM8K、MMLU-Pro 等多个基准。结果相当惊人：70 组测试中，提示词重复赢了 47 次，输了 0 次。
更妙的是，这个方法几乎没有代价。重复发生在可并行化的预填充阶段，生成的 token 数量和延迟都不会增加。输出格式也完全不变，可以直接无缝替换现有系统。
一个有趣的观察是：那些经过强化学习训练的推理模型，往往会自发学会在思考过程中重复用户的问题。提示词重复技术本质上是把这个“好习惯”前置到了输入阶段，用更高效的方式实现了类似效果。
研究还测试了几个变体。比如重复三次，在某些任务上效果更好。而单纯用句号填充到相同长度则毫无作用，证明提升确实来自语义重复本身。
当启用“逐步思考”等推理模式时，提示词重复的效果变得中性到略正面。这也符合预期，因为推理过程本身就包含了对问题的复述。
这项研究给我们的启示是：有时候最简单的方法反而最有效。在追求复杂提示工程技巧之前，不妨先试试这个零成本的小技巧。对于那些对延迟敏感、不适合开启推理模式的场景，提示词重复可能是一个值得尝试的默认策略。
论文还列出了十几个未来研究方向，包括只重复部分提示词、用小模型重排序、探索多轮对话场景等。这个看似简单的发现，或许能打开一扇理解 Transformer 注意力机制的新窗口。
Reddit上一个帖子引发了热议：为什么AI热潮中，大家都在做同样的事？
又一个聊天应用，又一个AI助手，又一个“智能工具”。仔细一看，要么早就存在，要么别人做得更好更成熟。很多功能明明一个插件就能搞定，却有人砸钱订阅、烧电费，只为造一个OpenWebUI的低配版。
评论区炸了，但观点出奇地冷静。
有人说这是学习的代价。就像织毛衣，市面上有的是成品，但自己动手的过程本身就是收获。99%的项目不会有人用，但那1%的人可能正在默默打磨下一个OpenWebUI。
有人看得更远：真正在做创新的人，根本不会在网上聊这些。他们怕被抄。
一位25年经验的系统工程师说了句扎心的话：那些你觉得在“偷懒”的年轻人，正在用你看不懂的方式快速迭代。这让他想起当年自己碾压老一辈的样子。
最有意思的是历史视角。BBS时代，人人写BBS；网页时代，人人做网站；文件共享、视频流媒体，每一波新技术都是这样。大量重复，少数突围，最后沉淀出真正有价值的东西。
有人提到dot com泡沫。1999年光搜索引擎就有几十上百个，泡沫破了，但Google活下来了。泡沫清除的是泡沫，不是技术本身。
还有一个更深的洞察：AI正在让“个人定制软件”成为可能。以前想要一个功能，要么忍受现有工具的不完美，要么花几周自己开发。现在几分钟就能让AI生成一个刚好满足需求的小工具。不完美，但刚好够用，而且完全按自己的想法来。
这或许才是真正的变革：不是谁做出下一个独角兽，而是每个人都能拥有为自己量身定制的工具。
当然，泡沫确实存在。那些把周末vibe coding的产物当成改变世界的天才发明的人，迟早会醒。但在喧嚣之下，真正的建设者正在安静地工作。
一位开发者的总结很到位：我不是在做产品，我是在交学费。只不过这次的学费，是付给Anthropic和OpenAI的。
Anthropic团队今天宣布将Claude Code中的Todos升级为Tasks。这个看似简单的改动，实际上标志着AI编程工具正在从“执行单一指令”向“管理复杂项目”演进。
随着模型能力的提升，如何让AI充分发挥潜力成为关键课题。Opus 4.5已经能够更长时间地自主运行，并更好地追踪自身状态。团队发现，对于简单任务，Claude其实已经不需要TodoWrite工具来提醒自己该做什么了。
真正的挑战在于更大的项目。当开发者开始用Claude Code处理跨越多个子代理、多个上下文窗口甚至多个会话的长期项目时，原有的Todos就显得力不从心了。项目天然具有复杂性，任务之间存在依赖和阻塞关系，需要在不同会话间进行协调。
Tasks的设计正是为了解决这些问题。它的核心特性包括：
任务可以相互依赖，依赖关系存储在元数据中，这更贴近真实项目的运作方式。
任务存储在文件系统中，多个子代理或会话可以协同工作。当一个会话更新任务状态时，所有正在处理同一任务列表的会话都会收到通知。
任务文件存放在 ~/.claude/tasks 目录下，开发者可以基于此构建自己的工具。
要让多个会话协作处理同一个任务列表，只需设置环境变量：
CLAUDE_CODE_TASK_LIST_ID=groceries claude
这个机制同样适用于 claude -p 命令和 AgentSDK。
值得一提的是，这个功能的诞生也受到了社区的启发，特别是Steve Yegge的Beads项目。社区的响应同样热烈，已经有开发者构建了任务看板可视化工具、文档集成方案等周边生态。
从更宏观的视角来看，Tasks代表了一种思维转变：AI编程助手正在从“工具”进化为“协作者”。当AI能够理解任务间的依赖关系、能够跨会话保持状态、能够与其他AI实例协同工作时，它就具备了参与真正软件工程的基础能力。
这让人想起一个有趣的问题：当AI能够自己管理任务、自己循环迭代时，人类开发者的角色会如何演变？也许答案是，我们会从“写代码的人”变成“定义问题和验收结果的人”。
我今年54岁，做了几十年物理研究，用数学探索宇宙、解决问题、构建系统。如果你的工作现在或将来会涉及数字，这份路线图或许能帮你真正学会数学。
学习分两个阶段。前25条是基础框架，之后是职业应用。
先从代数开始。学会干净利落地操作符号。这一关过不去，后面全是噪音。代数的核心是规则和结构，不是计算速度。慢下来，直到每一步都显而易见。
把方程理解为因果关系。别急着求解，先搞清楚什么影响什么。
接下来是几何。学习形状、距离、角度的行为规律。这能训练出公式给不了的直觉。同时用视觉和代数两种方式理解几何，把图形翻译成方程，再翻译回来。
尽早引入向量。向量统一了代数和几何，别拖延这一步。
三角函数的本质是角度和旋转，不是三角形。把正弦和余弦当作函数来学。通过单位圆理解三角函数，而非死记恒等式。能画出来，才算真懂。
预备微积分连接函数、三角和代数，它的任务是让微积分变得可预测。如果这部分感觉模糊，停下来解决它。微积分会惩罚薄弱的基础。
微积分从导数开始，导数就是变化率。先别管公式，把概念搞清楚。导数回答的问题是：如果我稍微改变这个，会发生什么？不断练习问这个问题。
用微积分建模行为，而非计算表达式。大多数真实问题止步于建模阶段。
积分是累积。面积只是一个例子。永远问自己：什么东西在被加起来？
微积分二难，因为技术性强。别死记技巧，学会判断每个工具何时适用。从概念上理解极限，它解释了微积分为何有效。
然后学逻辑和基础证明。这能磨砺推理能力，防止隐藏假设。证明训练的是严谨，不是优雅。逐行跟踪论证，直到没有任何东西感觉像魔法。
线性代数应该早学，不是晚学。它解释多变量系统的结构。把矩阵理解为变换，而非表格。这个思维转变至关重要。
特征值描述稳定性和长期行为。它们是思想，不是计算。
多元微积分反映现实。大多数系统依赖不止一个输入。偏导数分离影响因素，梯度指示方向。明确学习约束问题，无约束的数学很少是真实的。
只有完成这些，才去学概率和统计。当你理解了变化和结构，不确定性才有意义。
基础完成，进入应用：
工程：微积分加线性代数加约束条件，用于建模、优化和稳定性分析。
机器学习：线性代数加概率加优化，其他都是实现细节。
数据科学：统计加线性代数加基础微积分，重点在假设，不在工具。
金融：微积分加概率加线性系统，变化率和风险主导一切。
物理：微积分、线性代数、微分方程，几何和对称性比公式更重要。
经济学：多元微积分加优化，模型的生死取决于假设。
计算机图形学：线性代数加几何加三角函数，一切都是变换。
控制系统：线性代数加特征值加微积分，稳定性是核心问题。
研究：证明加建模加抽象，知道为什么比结果更重要。
最后一条现实：你不会每天用到所有数学，但薄弱的基础会立刻暴露。
数学学习最大的误区是追求速度和技巧。真正的数学能力来自对概念的深刻理解，来自不断追问“为什么”和“如果改变会怎样”。慢就是快，基础就是天花板。
Reddit上的LocalLLaMA社区最近上演了一出黑色幽默。
一位用户花500美元淘到了一张冷门的W6800 32GB显卡，测试后发现效果出奇地好，于是兴冲冲地写了篇详细评测分享给社区。结果第二天醒来，他盯上的所有W6800全部售罄，最便宜的价格直接翻倍突破1000美元。
他亲手把自己想买的第二张卡买贵了。
评论区有人搬出了加州淘金热的典故：当年发现金矿的人没有四处声张，而是先悄悄买光了周边所有的铲子、淘金盘和采矿设备，然后才告诉大家这里有金子。最终靠卖工具成为加州第一个百万富翁的，是商人Samuel Brannan，而不是挖金子的人。
这个故事放在今天的本地大模型圈子里，讽刺意味更浓。当显存成为跑大模型的硬通货，每一篇“这卡真香”的帖子都可能成为价格上涨的导火索。有人调侃：别推理了，改行倒卖显卡吧。
社区里关于性价比显卡的讨论也很有意思。MI50凭借32GB显存和1TB/s带宽，曾经160美元就能入手，堪称穷人福音。但软件生态是硬伤，基本只有llama.cpp和ComfyUI能用，想做微调或者跑专业推理引擎就抓瞎了。P40现在200美元以下，3090依然是主流推荐，而Strix Halo的128GB内存让一些人蠢蠢欲动——当然，前提是别再发帖推荐了。
还有人挖出了一个冷知识：AMD V620其实和W6800是同一张卡的服务器版本，eBay上只要450美元，只是没有显示输出。但对于纯跑推理的人来说，这根本不是问题。
这场闹剧背后折射出本地大模型社区的真实生态：大多数人的显存还不到16GB，真正拥有24GB以上推理设备的可能只有几百人，但每个人都在焦虑地寻找下一个性价比之王。价格一旦涨上去就很难降下来，而社区的每一次“安利”都在加速这个过程。
所以下次发现什么好东西，记得先买够再说。
