- 博客(105)
- 收藏
- 关注
RSS订阅原创 第二篇：RocketMQ事务消息——分布式事务的最终一致性方案
Producer的回查逻辑：根据消息中的业务参数（如商品ID、用户ID），查询本地事务的执行状态——比如检查Redis中的扣减流水标记是否存在、MySQL中的扣减流水记录状态是否为"已确认"。这样做的结果是——要么本地事务还没执行（半消息已发送但回滚），要么本地事务已执行（半消息已发送且提交）。RocketMQ的处理方式：Broker发现半消息超过一定时间（默认6秒）未被确认，主动向Producer发起回查请求——“你之前发给我的那条半消息，本地事务到底成功了没？半消息的本质是一条带"事务标记"的消息。
2026-05-14 00:00:02
454
原创 第一篇：RocketMQ架构与核心概念——一条消息从生产到消费的完整旅程
在秒杀系统专栏中，我多次提到"用RocketMQ做异步削峰"“用事务消息保证Redis扣库存和发消息的原子性”。但RocketMQ本身的工作原理，一直没有展开讲过。面试中，消息队列是分布式系统的核心考点：“RocketMQ的NameServer、Broker、Topic、Consumer Group分别做什么？“一条消息从生产到消费，经历了哪些步骤？“RocketMQ和Kafka、RabbitMQ有什么区别？为什么你的秒杀项目选RocketMQ？
2026-05-13 23:58:45
449
原创 细节补充第一篇：RocketMQ 的使用
本文深入探讨了RocketMQ在秒杀系统中的核心应用问题。首先解析了RocketMQ的三个核心组件：生产者（客户端）、Broker服务端（独立进程）和消费者（客户端）的通信机制。其次，详细说明了如何通过异步削峰将3000 QPS的请求降为800 TPS的数据库操作，关键是将同步数据库操作转为异步消息队列处理。文章掲示了流控机制的本质：并发队列数和消费线程数共同控制处理速度。最后指出TPS并非越高越好，需要根据系统瓶颈进行权衡。整套方案通过Redis挡峰值、MQ排队、消费者轻量操作实现了高效削峰填谷。
2026-05-13 11:26:23
371
原创 第八篇：Spring与微服务——从SpringBoot到SpringCloud的演进
本文探讨了从单体架构到微服务的演进过程，分析了Nacos、Sentinel和Gateway三大微服务核心组件的作用。Nacos作为注册中心和配置中心，解决了服务发现和配置管理问题；Sentinel通过限流、熔断和降级机制保障系统稳定性；Gateway作为统一入口，提供路由和过滤功能。文章还对比了单体与微服务的优缺点，指出微服务适合中大型系统，但初期需权衡开发效率与运维复杂度。最后强调微服务架构需要根据业务需求渐进式演进。
2026-05-12 23:10:01
523
1
原创 第三篇：CPU缓存——为什么有时候改了一行代码，性能差了百倍
本文通过一个Java二维数组遍历的性能差异实验，揭示了CPU缓存机制对程序性能的关键影响。实验显示按行遍历比按列遍历快15倍，这是因为CPU按64字节的"缓存行"读取数据，按行遍历能充分利用缓存的空间局部性。文章进一步解释了多核CPU下的缓存一致性问题，介绍了MESI协议如何维护缓存同步，并分析了"伪共享"现象——当不同线程修改同一缓存行中的不同变量时，会导致性能急剧下降。最后给出了通过填充数据避免伪共享的解决方案，展示了缓存优化对并发程序性能的重要影响。
2026-05-12 20:38:23
294
原创 第二篇：内存——你的变量到底存在哪
Java变量的存储位置直接影响性能。内存分为寄存器、缓存和主存，速度依次降低。栈通过指针移动管理，速度快但容量小，适合局部变量；堆需要垃圾回收，速度慢但容量大，存放对象和成员变量。字符串常量存储在常量池，复用性强。栈的快速访问得益于高缓存命中率，比堆快数十倍。理解变量生命周期和存储机制对优化代码性能至关重要，例如优先使用局部变量减少堆分配。硬件层面的缓存差异是性能差距的核心原因。
2026-05-12 00:00:13
414
原创 第一篇：只是想说清楚每行代码是由谁执行的，怎样执行的
本文通过一个简单的Java数据库操作示例，深入剖析了代码执行的完整过程。文章首先指出Java代码需要经过JVM编译和解释才能被CPU执行，强调CPU是唯一能执行指令的硬件。然后详细分解了数据库插入操作的四个阶段：CPU处理业务逻辑、发起网络IO、等待响应和恢复执行，揭示了IO密集型任务中CPU实际工作时间极短的特性。文章还解释了操作系统如何通过上下文切换实现多线程并发执行。最终得出结论：每行代码都由CPU执行，但在IO等待期间CPU会转而处理其他任务，这种机制使得计算机能够高效处理并发请求。
2026-05-11 23:58:02
309
原创 Redis工具类重构——从臃肿到优雅的门面模式实践
本文复盘了一个Redis工具类从1022行"上帝类"重构为门面模式的过程。原工具类将所有Redis数据类型操作混在一起，导致维护困难、扩展性差。通过拆分为1个门面类和7个操作组件，实现了职责分离和统一入口。重构解决了API混乱、性能陷阱等问题，使代码行数减少75%，调用方式更清晰，扩展性显著提升。关键收获包括：当类职责超过3条或代码超过500行时应考虑重构；门面模式适用于需要统一入口的多类型子系统；重构要保证API兼容性。该实践为类似工具类重构提供了可复用的设计模式。
2026-05-11 19:15:09
410
原创 第七篇：Spring扩展点——如何优雅地介入Bean的创建流程
本文深入解析Spring框架的四个核心扩展点：BeanFactoryPostProcessor、BeanPostProcessor、InitializingBean/@PostConstruct和Aware接口。这些扩展点允许开发者在Bean生命周期的不同阶段插入自定义逻辑。文章通过典型应用场景和代码示例，展示了如何利用这些扩展点实现属性覆盖、AOP代理、日志注入等功能，帮助开发者深入理解Spring的扩展机制。
2026-05-11 11:04:44
553
原创 第六篇：Spring用了哪些设计模式？——从单例到代理，拆解框架中的经典设计
本文从设计模式视角解析Spring框架的核心实现机制，重点剖析了单例模式、工厂模式、代理模式、模板方法模式等六大设计模式在Spring中的应用。单例模式通过容器管理保证Bean唯一性；BeanFactory作为IoC容器管理全局Bean生命周期，而FactoryBean封装单个复杂Bean的创建逻辑；AOP基于动态代理实现，区分JDK动态代理和CGLIB两种方式；JdbcTemplate采用模板方法模式封装JDBC固定流程。这些设计模式协同工作，共同构成了Spring框架的底层架构智慧
2026-05-11 11:02:03
533
原创 第五篇：Spring事务管理——@Transactional的底层实现与失效场景
摘要 Spring事务管理通过AOP动态代理实现，核心是TransactionInterceptor在代理对象中拦截@Transactional方法，自动管理事务开启、提交和回滚。事务传播行为定义了方法调用时的事务处理方式，REQUIRED会加入现有事务，REQUIRES_NEW会创建独立事务，NESTED则使用保存点实现嵌套事务。常见的事务失效场景包括：1）同类方法自调用绕过代理；2）非public方法无法被代理；3）异常被捕获未抛出；4）数据库引擎不支持事务（如MyISAM）。理解原理可避免事务失效问题
2026-05-10 23:45:45
371
原创 第四篇：SpringBoot自动配置——约定大于配置的底层原理
本文深入解析了SpringBoot自动配置的核心原理。传统Spring需要手动配置大量XML，而SpringBoot通过@SpringBootApplication注解实现自动配置，该注解由@SpringBootConfiguration、@EnableAutoConfiguration和@ComponentScan三个核心注解组成。这种机制大幅简化了Spring应用的配置工作，开发者只需关注业务配置即可。
2026-05-10 23:33:56
429
原创 第三篇：SpringMVC——一个HTTP请求在Spring中经历了什么？
SpringMVC采用前端控制器模式，DispatcherServlet作为统一入口。核心流程包含请求接收、Handler映射、拦截器执行、参数解析、方法调用和结果处理。HandlerMapping建立URL到Controller方法的映射，HandlerAdapter解析参数注解（如@RequestParam）。拦截器在预处理和后处理阶段介入，消息转换器处理请求/响应数据格式转换。该架构通过组件协作实现请求到响应的完整处理链路，为开发调试提供理论基础。
2026-05-10 23:31:28
418
原创 第二篇：Spring AOP——动态代理与切面编程的底层原理
Spring AOP通过动态代理技术解决OOP难以处理的横切关注点问题（如日志、权限、事务）。它采用JDK动态代理（基于接口）或CGLIB（基于继承）在运行时生成代理对象，将横切逻辑与核心业务分离。核心概念包括：切面（Aspect）封装横切逻辑，切点（Pointcut）定义拦截规则，通知（Advice）指定增强时机，连接点（JoinPoint）表示可拦截点。Spring Boot 2.x默认使用CGLIB代理，通过切面注解实现事务管理、日志记录等通用功能，使业务代码更简洁。
2026-05-10 23:27:20
395
原创 第一篇：Spring IoC容器——控制反转的本质与Bean的生命周期
Spring IoC核心机制解析控制反转（IoC）将对象创建权交给容器，依赖注入（DI）实现解耦，推荐构造器注入方式。容器选择上，ApplicationContext比BeanFactory功能更全面，适合实际开发场景。Bean生命周期包含实例化、属性赋值、初始化、销毁四个阶段，每个阶段都提供扩展点。循环依赖通过三级缓存解决单例Bean问题，但构造器注入导致的循环依赖无法处理。
2026-05-10 23:23:54
432
原创 第七篇：Redis分布式锁——从setnx到RedLock的演进之路
本文系统梳理了Redis分布式锁的演进历程，从基础的setnx+expire到RedLock算法，分析了各阶段的解决方案及其局限性。主要内容包括：1）原子化加锁的必要性；2）锁释放时的value验证机制；3）Redisson的WatchDog自动续期原理；4）可重入锁的实现；5）Redis集群下主从切换导致的锁丢失问题；6）RedLock算法的实现与争议。文章揭示了分布式锁设计中的核心挑战——在保证互斥性的同时兼顾可用性，并指出不同方案的适用场景，为技术选型提供理论依据。
2026-05-09 23:57:55
363
原创 第六篇：Redis Cluster——分布式缓存的进阶方案
在上一篇文章中，我们拆解了主从复制和哨兵机制——它们解决了单机Redis的高可用问题。所有节点存的是同一份全量数据。如果数据量超过单机内存上限，哨兵也无能为力。这就是Redis Cluster要解决的问题——把数据分散到多台机器上，每台只存一部分数据，突破单机内存瓶颈。面试中，Cluster是Redis进阶的必考题：“Redis Cluster的数据分片原理是什么？“为什么是16384个哈希槽？“MOVED重定向和ASK重定向有什么区别？“Cluster有什么局限性？
2026-05-09 23:56:52
407
原创 第五篇：主从复制与哨兵机制——Redis高可用的基石
本文深入解析Redis高可用机制，重点剖析主从复制和哨兵系统的工作原理。主从复制通过全量/部分复制实现数据冗余，但存在异步延迟问题；哨兵机制通过主观/客观下线判断实现自动故障转移，采用Raft算法选举Leader执行主从切换。文章对比了哨兵与Cluster方案的适用场景，并以秒杀项目为例展示哨兵配置实践。全文从原理到应用，系统阐述了Redis如何通过主从复制+哨兵机制构建高可用架构，解决单点故障问题。
2026-05-09 23:56:05
438
原创 第四篇：RDB与AOF持久化——宕机后数据怎么恢复？
Redis通过RDB和AOF实现持久化：RDB生成内存快照，恢复快但可能丢数据；AOF记录写操作，数据安全但恢复慢。生产环境建议同时开启，采用混合持久化（Redis 4.0+），结合两者优势。RDB使用fork和COW技术，AOF提供三种刷盘策略（推荐everysec），并通过重写解决日志膨胀。配置需根据业务对数据丢失容忍度和恢复时间要求权衡。
2026-05-09 23:51:53
472
原创 第三篇：缓存穿透、击穿、雪崩——从原理到解决方案
缓存穿透查询不存在的数据导致请求直达数据库。解决方案包括布隆过滤器拦截非法请求，或缓存空对象设置短过期时间。缓存击穿热点Key突然失效引发大量并发查询。可通过互斥锁保证单线程重建缓存，或采用逻辑过期时间异步更新数据。缓存雪崩大量Key同时失效或Redis宕机。建议多级缓存架构、过期时间随机化分散压力，结合熔断降级机制保护数据库。秒杀场景需特别注意锁的实现细节和布隆过滤器误判率控制。
2026-05-09 19:55:38
202
原创 第二篇：Redis的过期删除与内存淘汰——数据过期了怎么删？内存满了怎么办？
疑问：操作系统中的LRU用链表实现，Redis为什么不用？回答：因为精确的LRU需要维护一个双向链表，每次访问都要把节点移到链表头部。Redis单线程架构下，频繁的链表操作会严重影响正常命令的吞吐。过期删除用惰性+定期组合：惰性解决CPU峰值，定期解决内存泄露。两者各退一步，内存和CPU达到平衡内存满了用淘汰策略：allkeys系列从所有Key中淘汰，volatile系列只淘汰有过期时间的KeyRedis的LRU是近似的。
2026-05-08 23:59:39
347
原创 第一篇：Redis数据结构底层——String、List、Hash、Set、ZSet各自用什么实现的？
你可能每天都在用Redis的String、List、Hash、Set、ZSet，但面试官追问到底层时，很多人就答不上来了：“Redis的String和Java的String是一回事吗？“List底层是链表还是数组？“ZSet怎么实现O(log n)排序的？“为什么Redis不直接复用C语言的原生数据结构？这些问题考察的不是"会用"，而是"理解设计意图"。本文从底层实现的角度，逐个拆解Redis五大基本数据结构的内部原理。Redis的String底层是什么？SDS和C字符串有什么区别？
2026-05-08 23:59:09
569
原创 权限系统设计复盘——从RBAC模型到JWT双Token，方法级权限控制的完整实现
本文详细介绍了基于RBAC模型的权限系统设计与实现，涵盖数据库表结构、Spring AOP方法级鉴权、JWT双Token认证等核心模块。主要内容包括：1. RBAC权限模型的三级关系设计（用户-角色-权限），通过中间表实现灵活授权2. 五张核心表结构及权限编码规范（模块:操作格式）3. 使用自定义注解@RequirePermission和Spring AOP实现方法级权限控制4. JWT+Redis双Token方案解决单Token的安全问题5. 完整的认证-鉴权-刷新流程设计
2026-05-08 23:55:44
493
原创 第五篇：分布式锁实战——Lua脚本原子操作与库存扣减的强一致性
本文深入探讨了分布式锁在秒杀系统中的应用与实现。首先分析了单机锁在分布式环境失效的原因，指出分布式锁需满足互斥性、可用性和容错性三个条件。随后揭示了setnx+expire分开执行的死锁风险，提出原子命令解决方案。针对锁释放时的误删问题，介绍了基于Lua脚本的原子验证删除机制。最后重点阐述了秒杀项目中采用Lua脚本直接原子扣减库存的设计思路，对比了与Redisson方案的适用场景差异，强调在短流程、高并发场景下Lua脚本的性能优势。全文从原理到实践，系统性地解答了分布式锁的核心问题与技术选型考量。
2026-05-08 23:50:09
445
原创 第八篇：MySQL架构与主从复制——高可用的基石
本文系统讲解了MySQL主从复制原理与高可用方案。首先剖析了MySQL三层逻辑架构（连接层、Server层、存储引擎层）的分工协作。重点阐述了主从复制的核心机制：通过Binlog实现数据同步，涉及Dump线程、I/O线程和SQL线程的协同工作。详细对比了Binlog的三种格式（STATEMENT、ROW、MIXED），推荐生产环境使用ROW格式以确保数据一致性。针对主从延迟问题，分析了其成因并提出并行复制、读写分离等解决方案。最后探讨了主从切换策略及常见高可用架构，为构建可靠的MySQL集群提供了系统性指导
2026-05-08 17:43:59
269
原创 第七篇：慢查询分析与SQL优化实战
本文系统介绍MySQL慢SQL优化全流程，涵盖发现、分析与优化策略。首先讲解如何通过慢查询日志和监控平台发现慢SQL，并解读关键指标。重点剖析Explain工具的输出含义，识别全表扫描、临时表等危险信号。通过订单分页查询案例，演示如何通过联合索引、覆盖索引消除性能瓶颈。针对深分页问题，提出子查询和游标分页优化方案。最后指出JOIN优化的核心在于驱动表选择和关联字段索引。全文提供从理论到实践的完整方法论，帮助开发者系统解决慢SQL问题，提升数据库性能。
2026-05-07 23:47:03
159
原创 第六篇：Redo Log与Binlog——崩溃恢复的底层保障
MySQL通过WAL机制以顺序写日志替代随机写磁盘，提升性能。Redo Log：InnoDB物理日志，记录数据页修改，确保崩溃恢复。Binlog：Server层逻辑日志，支持主从复制和数据恢复。UPDATE执行流程包含SQL解析、两阶段提交等步骤，确保数据一致性。关键参数如innodb_flush_log_at_trx_commit和sync_binlog可优化事务安全。两阶段提交机制是保障事务安全的核心。
2026-05-07 23:45:35
161
原创 第五篇：MySQL锁机制——从行锁到间隙锁
本文深入解析了InnoDB的锁机制，包括表锁、行锁和间隙锁的分类与实现原理。重点分析了行锁如何通过索引记录锁定数据，间隙锁如何防止幻读，以及临键锁作为RR隔离级别的默认锁机制。文章还详细探讨了死锁的产生原因、排查方法和预防策略，通过实例展示了如何通过SHOW ENGINE INNODB STATUS分析锁等待情况。最后总结了索引质量对锁范围的影响，为开发者优化数据库并发性能提供了实用指导。
2026-05-07 17:20:13
387
原创 第四篇：事务隔离级别与MVCC——InnoDB的并发控制
MySQL事务通过ACID特性确保数据一致性，解决并发问题。InnoDB默认使用RR隔离级别，依赖MVCC机制实现多版本控制。MVCC核心由Undo Log版本链和ReadView组成，通过隐藏字段（DB_TRX_ID、DB_ROLL_PTR）记录事务版本。RC和RR隔离级别的差异在于ReadView生成时机：RC每次查询生成新ReadView，RR在事务首次查询时生成。RR级别通过MVCC避免大部分幻读，部分场景需间隙锁配合。MVCC与锁机制协同实现高效并发控制。
2026-05-07 17:03:13
198
原创 第三篇：覆盖索引与索引下推——让查询飞起来
本文深入解析MySQL查询优化的两大核心技术：覆盖索引和索引下推。覆盖索引通过将查询字段全部包含在索引中，避免回表操作，显著提升性能。索引下推则允许存储引擎在索引层提前过滤数据，减少不必要的回表。文章通过实战案例演示如何设计覆盖索引优化慢查询，特别是深分页场景，并对比两种技术的适用场景与协同效应。核心结论包括：避免SELECT*、遵循最左前缀原则、合理设计索引列顺序，以及如何权衡覆盖索引与索引下推的应用策略。
2026-05-07 17:00:30
208
原创 第七篇：大模型API调用——从Token到流式输出
Token作为计费单位，反映计算量，中英文Token比例不同。Temperature控制输出随机性，Top-p限制候选词范围，建议先固定Top-p再调Temperature。流式输出提升响应感知速度，优于普通请求。SSE比WebSocket更轻量，适合单向AI回答场景。生产环境需注意Nginx代理配置和API密钥安全。
2026-05-06 16:54:49
451
原创 第二篇：联合索引与最左前缀原则——从Explain看索引命中
联合索引与最左前缀原则核心原理：联合索引（a,b,c）按a→b→c排序存储，仅当查询包含最左列（a）时才能利用索引有序性。跳过最左列将导致索引失效。关键结论：索引失效场景：跳过最左列、对索引列运算、隐式类型转换。索引下推（ICP）可减少回表次数（MySQL 5.6+）。Explain的type、key_len、Extra字段可验证索引使用情况。优化建议：高频查询条件作为联合索引最左列。范围查询后的列无法使用索引。排序字段加入索引避免filesort。优先使用覆盖索引减少回表。
2026-05-06 15:45:19
226
原创 第一篇：MySQL索引底层——B+树为什么是首选？
MySQL选用B+树索引因其综合性能优势：树高仅3层即可支持百万级数据，大幅减少磁盘IO（2-3次查询）。相比哈希表，B+树支持高效范围查询；对比B树，其非叶节点不存数据使单页容纳更多键值，提升空间利用率。聚簇索引直接存储行数据，二级索引通过主键值触发回表查询。叶子节点双向链表结构优化了顺序访问，16KB页大小设计平衡了存储效率与查询性能。
2026-05-06 15:21:48
200
1
原创 AI辅助编程的边界——Cursor实战与工程判断力
AI辅助开发实践显示，大模型可快速完成60%基础代码实现（如1小时搭建推理网关），但存在边界条件缺失、异常处理不足等三大风险。开发者需聚焦架构设计与核心逻辑，AI更适合处理文档、脚本等非关键代码。核心竞争力转向问题定义能力、技术决策判断及代码审查力。未来开发者角色将向技术决策者升级，而非被取代。
2026-05-05 23:28:46
452
原创 大模型推理网关——从负载均衡到故障注入的完整设计
本文针对大模型API调用中的单点故障和限流问题，提出了一个支持负载均衡与容灾的HTTP网关设计方案。该网关通过责任链模式实现多层处理：鉴权层验证客户端权限，限流层采用滑动窗口控制请求频率，路由层按模型选择后端，负载均衡层通过权重轮询策略分配请求（根据API KEY配额设置权重），健康检查层定期检测并自动摘除故障节点。相比直接调用API，该方案解决了单KEY限流、配额不均、故障排查困难等问题，可显著提升大模型API调用的稳定性和资源利用率。
2026-05-05 19:32:25
451
原创 第八篇：LangChain不是“套壳”——它解决了什么实际问题
LangChain框架为复杂AI应用提供核心价值：1)通过流程编排抽象简化多步骤开发；2)Chain模块化固定流程；3)Agent支持动态决策；4)Tool扩展模型能力。对比直接调用API，其在复杂场景优势明显，但存在过度封装风险与Agent"迷路"问题。以课程问答为例，Chain适合固定检索生成流程，Agent更匹配开放式任务。需根据需求选择工具，LangChain对复杂开发具有独特价值但非万能。
2026-05-05 18:27:53
287
原创 第六篇：大模型的“记忆”——从上下文窗口到会话管理
大模型在多轮对话中依赖外部记忆机制，核心限制来自上下文窗口。BufferMemory全量存储对话历史，适合短对话和技术问答；SummaryMemory通过摘要压缩历史，支持长闲聊但可能丢失细节。128K大窗口存在注意力稀释问题，上下文过长会引发成本激增、早期信息遗忘及注意力分散。需根据场景权衡记忆深度与效率：精确性要求高的场景选择BufferMemory，长对话优先考虑SummaryMemory。记忆管理本质是对有限上下文资源的优化分配。
2026-05-05 18:11:10
554
原创 第五篇：RAG检索增强生成——让大模型学会“开卷作答”
RAG（检索增强生成）技术通过离线索引和在线生成两阶段优化大模型问答效果。离线阶段将文档切分（如500字块+100字重叠）并向量化存储；在线阶段混合向量检索与关键词检索，过滤低相关性内容后送入大模型生成回答。RAG解决了直接输入长文档导致的成本高、注意力分散和幻觉增多问题，尤其适合需要精准引用的场景（如课程问答）。其核心优势在于让模型仅处理相关片段而非全部文档，平衡了效果与成本。但需注意文档切分策略、检索算法选择和相关性过滤等关键环节的调优。
2026-05-05 09:41:21
483
原创 第四篇：Prompt Engineering——从随意提问到工程化调用
大模型Prompt Engineering的核心方法包括角色设定缩小语义空间、Few-shot示范输出模式和Chain of Thought分步推理。实验表明Prompt对模型输出有显著影响。输出格式约束可采用自然语言或结构化方式，各有优劣。课程问答项目的Prompt模板展示了实际应用。Prompt管理应从硬编码转向配置化，并建立量化评估体系，涵盖准确性、诚实性等维度。复杂任务应拆解为多步骤Prompt，每步专注单一目标以提升输出稳定性。这些方法将Prompt设计从经验转化为可复用的工程实践。
2026-05-04 22:30:55
470
原创 第三篇：大模型为什么会有“幻觉”——从训练方式到推理局限
大模型幻觉指模型生成看似合理但虚假的内容，源于训练目标（预测token而非验证事实）、生成机制（误差累积）及缺乏"未知"反馈。解决方法包括RAG技术（提供参考文档变"闭卷"为"开卷"）和Prompt工程（设定知识边界、要求引用原文、调整温度参数）。完全消除不可能，但可控制到可接受范围。需将大模型视为"表达力强但记忆不可靠的助手"，引导其基于参考而非记忆工作。
2026-05-04 22:25:27
421
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人