- 博客(1356)
- 收藏
- 关注
RSS订阅原创 用飞算 JavaAI 做了一个校园化学实验室危险品耗材领用管理系统｜我的炫技赛参赛实录
本文介绍了作者参加飞算JavaAI炫技赛时开发的校园化学实验室危险品耗材领用管理系统。该系统通过区分危险品与普通耗材管理，构建了从申请、审批到出库的完整闭环流程，并实现了库存预警、操作留痕等功能。作者利用飞算JavaAI的智能引导功能快速生成工程骨架，再针对实际业务需求进行调整，重点关注数据字段设计、状态流转和权限控制。系统通过集中展示关键信息，帮助管理员高效处理异常情况。文章强调了AI辅助开发的价值在于快速搭建可继续完善的基础框架，而非替代人工需求分析和安全审核。最后，作者分享了参赛经验并鼓励开发者尝试用
2026-07-14 11:15:00
11
原创 模型推理延迟优化实验：从 2 秒到 200 毫秒的逐层剖析
分层打点是优化的起点：不知道瓶颈在哪里就优化，是"盲人摸象"。LatencyBreakdown 框架告诉你每毫秒花在哪里。FlashAttention 是"免费午餐"：不损失精度，Prefill 加速 2-3 倍，应该是第一个做的优化。推测解码是 Decode 阶段的最强武器：用一个 10% 大小的小模型"先猜一步"，每次生成多个 token。精度和速度永远在博弈：INT8 量化、推测解码都以微小精度换大幅速度。关键在于判断你的任务能否容忍这个损失。
2026-07-14 11:12:30
18
原创 后端数据库连接池配置：为什么 10 个连接比 100 个更快
连接数不是越多越好：数据库的 CPU 核心数是硬上限。公式(2 * CPU) + 磁盘数是科学的起点。监控比配置更重要这四个指标是连接池的"生命体征"。没有监控的连接池就是在盲飞。自适应调整是未来的方向：根据利用率动态调整连接数可以应对突发流量和低谷期，但需要设置 absoluteMax 防止失控。连接泄漏是头号杀手：try-with-resources 是最低成本的预防手段。那次把 10 改成 100 带来的教训，让我学会了在改参数之前先"看数据"。每一个配置参数的优化都应该从监控开始。
2026-07-14 11:09:09
20
原创 智能重试策略：从死循环到指数退避，一个后端实习生踩过的坑
重试策略看起来简单，但做好很不容易。区分错误类型：不是所有错误都值得重试。参数错误重试 100 次也没用。指数退避 + 随机抖动：这是防止"重试风暴"的标准做法，不是可选项。熔断器是重试的搭档：如果你发现自己写了很多重试逻辑，但没加断路器，请立刻加上。幂等性是重试的前提：对非幂等接口的重试，必须携带幂等键。从"死循环 + sleep(1000)"到"指数退避 + 断路器 + 错误分类"，这段成长之路上的每一个坑都在教我：系统性思考比写代码本身更重要。
2026-07-14 11:04:59
16
原创 HashMap 的负载因子与扩容策略：为什么默认值是 0.75
负载因子越高，数组利用率越高，内存更省。0.99 的负载因子意味着只有 1% 的桶是空的——空间利用极好。但负载因子越高，同一个桶内堆积多个元素的概率也越高。链表长度超过 8 时，Java 会自动将链表转为红黑树（O(log n) 查找），但转换本身有开销。负载因子越低，扩容越频繁。每次扩容需要 O(n) 的时间遍历旧表并 rehash。Java 的设计者在注释中给出了精确的数学推导。假设哈希函数是理想的（元素在桶间均匀分布），元素落入每个桶的事件服从泊松分布。
2026-07-14 11:00:19
45
原创 AI推理加速：题解生成场景中的模型量化与批处理优化
量化与批处理是"免费的性能午餐"——不需要换更大的 GPU，不需要更贵的模型。量化不是一刀切：敏感层保持高精度，非敏感层激进量化，这是混合精度的核心思想。批处理要有超时机制：不能让"等 batch 凑满"变成"无限等待"。max_wait_time 是体验的最后一道防线。量化精度需要量化评估：不要凭感觉认为 "INT8 效果一定差"。要像那样，用余弦相似度、任务指标（BLEU/ROUGE）来度量。长度分桶是批处理的进阶优化：当 prompt 长度方差大时，按长度分组可以避免"长尾请求拖慢批次"的问题。
2026-07-14 10:57:00
91
原创 分支预测对算法性能的影响：排序后的数据为什么跑得更快
排序后数据跑得更快，本质上是 CPU 分支预测器在"有规律"的数据模式下工作得更好。这个现象不仅影响遍历循环的速度，更深刻影响着算法选择、数据结构设计和性能优化的方向。关键启示有三个：第一，处理有序数据远比处理随机数据快——在算法设计中应先排序再批量处理。第二，简单的条件赋值可以用位运算消除分支，但不一定总是更快，需要实测。第三，性能优化应该由 profile 数据驱动，而非直觉。
2026-07-14 10:50:29
38
原创 记忆化搜索的性能边界：缓存命中率比缓存大小更重要
记忆化搜索的性能不是"越大越好"，缓存命中率才是真正的 KPI。影响命中率的三个核心因素是：状态的访问模式（局部性）、状态空间的稀疏度、以及缓存的淘汰策略。在工程实践中，分析问题确定状态访问模式是第一步。有局部性的（如连续 DP）用简单的 lru_cache 就够。高稀疏度的（如状态压缩 DP）用多级缓存更有优势。状态完全连续的，自底向上用数组比任何记忆化都要快。记住：一个优化的记忆化搜索，不是在代码里加个@lru_cache就完事了，而是理解了状态的访问规律后做的精确选择。
2026-07-14 10:42:39
49
原创 AI辅助性能调优：从火焰图到自动诊断的全流程实践
AI 负责模式匹配：火焰图→热点方法→优化建议，这是机器擅长的快速扫读。人类负责因果推断：锁竞争还是 GC？架构问题还是参数问题？这需要领域理解。数据质量是天花板：你给 AI 多精确的数据，它就还你多精确的建议。所有优化建议都必须基准测试验证：AI 可以告诉你"可能 slow"，但不能替你确认"优化后确实 faster"。未来，我相信性能调优会走向"数据自动采集 → LLM 分析 → 人工确认 → 自动部署验证"的闭环。
2026-07-14 10:35:19
36
原创 刷题系统的高并发优化：千人同时提交，判题队列怎么不炸
判题系统的高并发优化不是单纯的"加机器"，而是从架构层面进行解耦和缓冲。四个核心策略构成了优化的完整蓝图：消息队列做异步削峰、多级缓存做重复过滤、动态扩缩容做弹性伸缩、优先级调度做资源倾斜。这个架构的本质是用时间换空间、用异步换吞吐。消息队列允许提交请求在高峰期排队等待，而不必承受瞬时冲击。当面试官问"判题系统怎么支撑高并发"时，不要只说"加机器"，而要说清楚消息队列的削峰原理、缓存的去重价值、以及动态伸缩的资源利用率。
2026-07-14 10:24:29
43
原创 接口性能压测方案：QPS 不只是数字，背后是系统能力的投影
QPS 不是系统性能的目标，而是系统能力的测度结果。真正有意义的问题是：在当前 QPS 下，P99 延迟是多少？CPU 利用率是多少？数据库连接池有多大压力？是否可以线性扩展？一个完整的压测方案应该包含：基准压测（建立基线）、压力压测（找瓶颈）、稳定性压测（验证长期表现）、脉冲压测（验证弹性）。每个阶段都要监控 CPU、内存、GC、线程池、连接池的多维指标。记住：一个"QPS 达到 5000"但没有附带延迟分布、资源使用率的压测报告，和一个只写"项目已完成"的周报一样——缺少关键信息。
2026-07-13 11:08:19
11
原创 多 Agent 协作刷题：一个出题、一个解答、一个评测的分工模式
负责根据用户的能力画像和薄弱点，生成针对性练习题目。它的输入是用户的刷题记录（哪些题型做得好、哪些容易卡住、最近刷的频率），输出是一个结构化的题目描述（问题陈述、输入输出格式、约束条件、预期难度）。出题 Agent 的核心能力需求：理解算法题的结构和难度分层、能创建有效的变体题目（同一模式不同表述）、以及根据用户反馈动态调整题目难度。负责解答出题 Agent 生成的题目。它需要完整的算法能力——读懂题目、选择算法、编码实现、分析复杂度。
2026-07-13 11:03:09
48
原创 后端服务限流架构：从单机令牌桶到分布式全局限流
限流从固定窗口到滑动窗口再到令牌桶的演进，本质上是对"流量应该如何被限制"这个问题的不断深入理解。固定窗口只看"总次数"，滑动窗口看"时间段内的次数"，令牌桶看"速率和突发"。在工程选型上：单机场景用 Guava RateLimiter，简单可靠；分布式场景用 Redis + Lua 滑动窗口，原子操作无需额外锁；如果需要全局精确的速率控制，Redis 令牌桶提供了突发流量的兼容性。记住：限流的 KPI 不是"拒绝了多少请求"，而是"在系统承载范围内通过了多少合理的请求"。
2026-07-13 10:58:38
65
原创 AI 代码补全在算法场景中的精度优化：通用模型 vs 算法专用微调
通用代码补全模型在算法场景中的短板源于训练数据的偏差——工程代码的模式与算法代码的模式存在显著差异。通过在高质量算法题解上微调（Fine-tuning with FIM），可以将补全准确率提升约 20-30%。但微调不是银弹。补全准确率的上限受到算法题本身的复杂性限制——有些题目需要跨越多行代码的宏观推理，而当前 FIM 格式只能看到前缀和后缀，缺乏更宏观的题目理解。未来的方向可能是结合 RAG（检索增强生成），让模型在补全时能"看到"相似题目的解法和常见的模式模板。
2026-07-13 10:53:28
76
原创 树状数组的索引设计：lowbit 不是魔法，是二进制规律的直接推论
lowbit 不是"魔法"，它是二进制补码和进位规则的直接推论。理解了x & -x为什么恰好等于"最低位 1 的值"，树状数组的整个索引体系就自然揭示了：BIT[i] 覆盖 [i-lowbit(i)+1, i]，前缀和就是不断减 lowbit，更新就是不断加 lowbit。树状数组是"精巧的工程实现"的典范。它只用了数组和位运算，就实现了 O(log n) 的前缀和与更新操作。它的简洁背后是对二进制规律的深刻理解——理解了这个规律，你不仅能写出树状数组，还能在面试中解释它为什么正确。
2026-07-13 10:50:08
179
原创 题解语义匹配：用向量检索找到“和你卡在同一个地方的题解“
题解语义匹配的核心是用 CodeBERT 等预训练模型将题解和用户描述映射到同一语义空间，然后通过向量检索找到最相关的内容。这比传统的关键词搜索更能理解用户的真实意图。工程上需要权衡的三个关键点：编码器的选择（通用 vs 领域微调）、向量索引的类型（精确 vs 近似）、以及后处理的过滤策略（标签、题目、难度）。这个架构不仅适用于题解检索，也可以扩展到技术文档搜索、代码库探索等场景。搜索题解的本质，不是找"对的答案"，而是找"适合你的解释"。语义匹配让这个目标从口号变成了工程现实。
2026-07-13 10:44:28
156
原创 布隆过滤器的概率分析：误判率不是随口说的，要算出来
布隆过滤器的误判率不是一个经验值，而是一个精确的数学结果。在给定元素数 n 和误判率 p 后，最优位数组大小 m 和哈希函数个数 k 可以通过公式直接计算。理解这组关系，就能在面试或系统设计中给出有说服力的参数选择。布隆过滤器完美体现了"用概率换空间"的工程思想。它不追求绝对正确，而是将"极少发生的误判"作为可接受的代价，换取空间的大幅节省。这种思想在大型分布式系统的缓存穿透防护、去重、黑名单过滤等场景中反复出现。
2026-07-13 10:41:08
135
原创 图的最短路径算法进阶：Bellman-Ford 的负环检测与工程实践
Bellman-Ford 的核心价值不在效率，而在能力——它解决了 Dijkstra 最大的盲区：负权边和负环检测。V-1 轮松弛的数学基础是"最短路径最多 V-1 条边"，第 V 轮检测的原理是"多余 V-1 条边还能缩短路径意味着存在负环"。在工程实践中，SPFA 提供了有效的加速手段，但需要注意其最坏情况。当需要完整的最短路径信息时，标准 Bellman-Ford 加提前退出优化已经足够应对大部分场景。理解这个算法的底层数学直觉，比记住它的代码实现更有价值。
2026-07-13 10:38:28
219
原创 个人算法能力画像：用 AI 给刷题数据建模，生成能力雷达图
算法能力画像把"我感觉我 DP 还行"变成了"你在二维 DP 上的独立解题率为 72%，在一维 DP 上为 85%，但背包问题上只有 30%——建议加强背包问题训练"。这种量化带来两个好处：知道自己真正的短板在哪，以及能看到训练是否在改善这些短板。核心方法是从刷题数据中提取五维特征（模式广度、模式深度、解题效率、AI 独立率、迁移能力），用加权评分和时间衰减模型生成动态画像。这个框架的实现不依赖 AI 模型，但结合 AI 后可以做更深入的分析——比如分析代码风格变化、识别思维定式等。
2026-07-13 10:33:28
167
原创 刷题系统的评测引擎架构：从单体判题到分布式评测集群
从单体到分布式的评测引擎架构演进，本质上是在解决三个问题：安全性（隔离不可信代码）、可扩展性（支撑高并发提交）、公平性（保证评测结果的准确一致）。核心架构组件包括：消息队列做请求缓冲、语言池化做资源隔离、优先级调度做任务排序、沙箱执行做安全保证。每层的设计决策都不是孤立的——沙箱的选择影响评测速度，评测速度影响调度策略，调度策略影响用户体验。理解判题系统的全链路，不仅是工程能力的体现，更是在设计刷题平台时做出正确 trade-off 的前提。
2026-07-13 10:27:08
192
原创 分布式 ID 生成方案对比：雪花算法、号段模式与数据库自增
分布式 ID 生成的本质矛盾是：唯一性要求串行化，高性能要求并行化。三种方案各用不同的方式解这个"串行与并行"的矛盾——雪花算法用时间戳做天然分区、号段模式用批量分配减少串行化频率、数据库变体用步长交错实现伪并行。没有银弹方案。选型需要权衡性能、一致性、可读性和运维复杂度四个维度。理解每种方案"牺牲了什么来换取什么"，比记住它们的实现细节更重要。
2026-07-12 16:04:31
3
原创 智能代码片段推荐：根据当前解法自动匹配可复用的工具函数
代码片段推荐的核心不是"搜到相关内容"，而是"在用户还没意识到需要时，就给出对的东西"。这要求推荐引擎理解代码的语义，而不只是匹配关键词。三个关键设计决策：语义向量匹配作为核心排序依据、标签索引用于候选集快速召回、使用频率作为时间衰减的加权因子。这个架构不仅适用于刷题场景，也可以扩展到日常开发的代码复用中。当你下次写def gcd时，如果你的 IDE 自动在侧边栏提示你"你之前写过这个函数，要复用吗"，这就是推荐引擎在起作用。
2026-07-12 16:00:21
72
原创 后端接口超时处理：设置超时不只设一个数字
超时不是"一个数字"能解决的问题。它是一个多层次的系统性配置，需要从网关、应用、数据库三个层级递进。核心公式是"下游 < 中游 < 上游"，每一层预留足够的网络开销。更重要的是，超时必须配合降级策略。超时后不能只会抛异常——要给用户一个能接受的结果，比如缓存数据或默认值。同时，所有"超时后"的代码路径都必须正确释放资源，包括线程、连接、锁。
2026-07-12 15:55:41
60
原创 刷题效率实验：有 AI 辅助 vs 纯手写，时间与正确率的双盲对比
AI 辅助刷题的效率提升是真实存在的——大约 35% 的时间节省和 18% 的 AC 率提升。但这个数据附带了重要的前提：AI 是辅助工具，不是替代方案。如果你用 AI 直接生成答案而不思考，短期 AC 率可能更高，但长期算法能力反而会退化。最佳用法是让 AI 做"思路启发"和"语法助手"，而核心推理和代码实现仍然靠自己。这次实验让我更确信一件事：AI 时代最值钱的能力，不是熟练使用 AI 工具，而是知道什么时候该听 AI 的、什么时候必须自己思考。
2026-07-12 15:50:31
55
原创 贪心算法的正确性证明：不是“看起来合理“就算对
贪心算法的难点从来不是代码，而是正确性证明。三种核心证明方法——交换论证、归纳法、贪心选择性质——覆盖了绝大多数贪心问题。日常刷题时，建议养成"每想到一个贪心策略，就问自己怎么证明它"的习惯。如果证明不了，就用随机测试验证器辅助检查。当你在面试中不仅能写出贪心代码，还能用交换论证法证明它，面试官看到的就不是一个"记套路"的人，而是一个"有数理思维"的人。
2026-07-12 15:46:11
140
原创 AI 题解准确性评估框架：正确性、完整性、可读性的三维打分
AI 题解的评估不应该只靠"能不能 AC"。正确性、完整性、可读性三个维度共同构成了一份好题解的评价标准。这个框架的价值不在于打分本身，而在于它把评估过程标准化了。当你在优化 prompt 时，可以用这个框架对比不同 prompt 的输出质量。当你在审核 AI 生成的题解时，可以用它快速筛选出需要人工复查的部分。题解质量的上限，就藏在这三个维度里。
2026-07-12 15:42:40
159
原创 数据库索引底层：B+ 树不是面试背完就够，还要知道为什么
B+ 树的优势不在算法复杂度，而在对磁盘 I/O 模型的深刻适配。它的三大设计支柱——大分支因子（减少树高）、叶子链表（加速范围查询）、所有数据在叶子层（等深平衡）——每一项都对应着一个数据库查询的物理约束。理解这一点后，面试时就不会只答"B+ 树"三个字。你能说清楚分支因子和磁盘页的关系、为什么范围查询是 B+ 树的优势场景、以及什么情况下应该换用 LSM-Tree。这才是从"背答案"到"真理解"的跨越。
2026-07-12 15:36:50
162
原创 最小生成树：Prim 与 Kruskal 的实现差异与选型决策
Prim 和 Kruskal 在数学上是等价的，工程上却各有优劣。选型的决定性因素有三个：图的稀疏度（决定复杂度主导项）、数据表示形式（邻接矩阵还是边列表）、以及是否需要增量计算。但更重要的是对底层数据结构的理解。Prim 的效率依赖堆的性质——堆的插入和删除决定了它的实际表现。Kruskal 的效率依赖并查集的平摊分析——路径压缩和按秩合并缺一不可。如果面试时你不仅能写出这两种算法的代码，还能解释为什么会这样选择，那面试官会看到一个超越"刷题模板"的候选人。
2026-07-12 15:30:20
169
原创 AI 学习助手的长期价值评估：刷题数量不是 KPI，思维能力才是
AI 学习助手在刷题场景中的长期价值，不在于它能让你刷得更快、AC 得更多，而在于它能否帮你建立更深的算法思维模型。可以从"模式广度、模式深度、独立解题率"三个维度来量化这种思维能力。一个好的 AI 刷题助手应该像一个苏格拉底式的教练——用提问引导思考，用提示代替答案，用归纳帮你看到题目背后的模式。刷题数量只是一个过程指标，最终的 KPI 应该是：当遇到一道从未见过的题目时，你能不能在没有任何工具辅助的情况下，独立找出解法。
2026-07-12 15:12:14
166
原创 刷题 Agent 的多轮对话设计：怎样让模型记住上一轮的推理链
推理链记忆的本质，是把多轮对话从一个"重新开始"的模式变成"增量推理"的模式。它不需要保留完整的对话历史，而是保留推理中最关键的三个组成部分：思路拆解、中间结论和边界警示。在工程实现上，核心要点有三个：用模型自身的结构化抽取替代规则匹配、在 system prompt 层面注入而非在对话中混入、为每道题独立维护推理链并在切换题目时清理。对于刷题 Agent 而言，记住推理链不是锦上添花，而是让 AI 从"一次性解题工具"进化到"持续性学习伙伴"的关键一步。
2026-07-12 15:01:48
157
原创 从实习生到合格后端：半年技术成长的客观复盘
代码能力的提升不是代码行数的累积，而是思维方式的刷新。"能跑"是一维思维（只关注功能），"可观测"是多维思维（功能、性能、稳定性、可维护性同时关注）。每一次思维刷新背后，都是一个真实的踩坑经历——线上故障、Code Review 的批评、重构的痛苦。这些经历比看任何教程都深刻。
2026-07-11 10:15:57
25
原创 学习路径的 A/B 实验设计：怎么证明 AI 推荐比固定路线更有效
A/B 实验不是简单地比较两组的平均值。它涉及：分流机制的设计（哈希分流保证一致性）、统计显著性检验（t-test + 置信区间）、效应量评估（Cohen's d）、以及避免实验偏差（辛普森悖论、新奇效应）。在教育类产品的实验设计中，还需要额外关注伦理边界——不能让任何一组用户接受明显有害的学习方案。
2026-07-11 10:10:57
64
原创 后端接口限流设计：令牌桶、漏桶与滑动窗口的代码实现
限流算法的选择依赖三个条件：是否允许突发、精度要求有多高、并发量有多大。固定窗口最简单但有边界问题，滑动窗口精确但内存开销大，令牌桶和漏桶用桶容量参数灵活控制突发行为。在大多数后端 API 限流场景中，令牌桶是综合最优解。
2026-07-11 10:08:18
78
原创 AI 面试追问的深度设计：表面答案正确，追问一层就露馅
追问是检验理解深度的有效手段。AI 面试模拟器的追问设计，本质上是模拟面试官的思维过程：从答案出发，找到逻辑链条中的薄弱环节，逐层挖掘。好的追问能让"背答案型"和"理解型"的回答者快速区分开来。
2026-07-11 10:02:27
62
原创 计数排序与基数排序的工程应用：非比较排序在什么场景值得用
非比较排序在特征匹配的场景下性能卓越（大量数据 + 小值域），但适用范围有限。选型时最常犯的错误是：看到 O(n) 就用，忽略了数据特征是否满足前提条件。默认用内置排序，只在确认数据特征适合非比较排序时才切换。
2026-07-11 09:56:57
167
原创 多模型投票在题解验证中的应用：一个模型容易出错，三个会好多少
多模型投票是降低单一模型偏见和错误的有效手段，但它不是万能药。它的效果取决于模型的独立性、各模型的准确率以及投票策略的选择。在实际应用中，建议从双模型开始（成本可控），关键场景扩展为三模型。全票通过的策略用于安全第一的场景，多数投票用于平衡场景。
2026-07-11 09:51:27
173
原创 生产环境 OOM 排障复盘：一个实习生遇到的真实内存泄漏
看趋势：内存是持续增长还是间歇性峰值？前者是泄漏，后者可能是业务特征。看对象：Heap Dump 中占比最大的是什么对象？它的引用链是什么？看缓存：缓存是否设置了容量上限和过期时间？看连接：数据库连接、HTTP 连接是否被正确关闭和归还？看线程：ThreadLocal 在线程池环境中是否被清理？OOM 不是问题本身，是问题最后的表现。在它之前一定有内存使用率持续上升的征兆。建立内存监控，在 75% 告警时介入，比在 100% OOM 时救火要好得多。
2026-07-11 09:47:47
180
原创 图的连通性判断：Tarjan 与 Kosaraju 的实现细节与复杂度对比
Tarjan 和 Kosaraju 的理论复杂度相同，但工程选择不同。Tarjan 胜在常数更小，Kosaraju 胜在思路更直观。在很多实际场景中，Kosaraju 的实现简单性带来的维护优势，可能超过 Tarjan 的微小性能优势。选型时考虑的是「谁更好维护和调试」，而不仅是「谁的理论常数更小」。
2026-07-11 09:43:07
179
原创 AI 驱动的个性化刷题方案：从千人一面到千人千面的工程挑战
千人千面的个性化刷题，核心挑战不在算法——推荐系统的技术已经相当成熟。真正的挑战在数据——没有足够的用户画像数据，推荐就是盲猜；没有足够大的题库，选择空间就有限。一个可用的个性化系统，需要同时解决冷启动测评、动态调整、兴趣与需要平衡这三个工程问题。从千人一面到千人千面，不是算法升级，是系统工程能力的升级。
2026-07-11 09:38:26
175
原创 刷题 Agent 的失败模式分析：什么时候 AI 给的答案靠不住
AI Agent 的失败不是随机的，而是有模式的。识别这些模式，建立自动检测机制，是为 Agent 构建安全护栏的关键步骤。不追求 Agent 永远不犯错（不现实），追求的是当它犯错时，能检测到、能补救、能避免把错误输出给用户。
2026-07-11 09:33:56
159
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人