thinking vs non-thinking模式思考过程延迟适用场景thinking有类似CoT10-30sBug修复、架构设计、复杂推理non-thinking无2s代码补全、格式化、简单问答auto自动判断自适应日常开发# monkeycode.yaml model: provider: minimax model: m3 m3: mode: thinking # 强制thinking # mode: non-thinking # 强制non-thinking # mode: auto # 自动选择案例1并发数据竞争BugBug描述# 一个看起来没问题的代码但在高并发下会出现数据竞争 class OrderProcessor: def __init__(self): self.pending_orders [] async def process_payment(self, order_id: str): # 1. 检查是否已在处理 if order_id in self.pending_orders: return {status: already_processing} # 2. 加入待处理列表 self.pending_orders.append(order_id) # 3. 处理支付 result await payment_gateway.charge(order_id) # 4. 从列表移除 self.pending_orders.remove(order_id) return resultnon-thinking模式的输出# non-thinking: 快速给出了一个表面修复 class OrderProcessor: def __init__(self): self.pending_orders set() # 改成setO(1)查找 async def process_payment(self, order_id: str): if order_id in self.pending_orders: return {status: already_processing} self.pending_orders.add(order_id) result await payment_gateway.charge(order_id) self.pending_orders.discard(order_id) return result # ⚠️ 没有解决并发问题两个协程可能同时通过检查thinking模式的输出# thinking: 先分析了并发问题的根因再给出正确方案 思考过程 1. 问题asyncio中await会释放控制权两个协程可能在步骤1和步骤2之间切换 2. set()替换list()只优化了查找性能不解决并发安全问题 3. asyncio本身是单线程的但await点会导致协程切换 4. 需要用asyncio.Lock保护临界区 5. 还要考虑异常情况如果charge()抛异常order_id不会被移除 import asyncio class OrderProcessor: def __init__(self): self.pending_orders set() self._lock asyncio.Lock() # 临界区锁 async def process_payment(self, order_id: str): async with self._lock: # 原子操作检查添加 if order_id in self.pending_orders: return {status: already_processing} self.pending_orders.add(order_id) try: result await payment_gateway.charge(order_id) return result finally: async with self._lock: # 原子移除 self.pending_orders.discard(order_id)差异thinking模式找到了根因asyncio的协程切换并给出了异常安全方案。案例2SQLAlchemy N1查询Bug描述# 一个简单的API返回所有用户及其文章列表 router.get(/users) async def list_users(): users await db.execute(select(User)) return [{id: u.id, name: u.name, posts: [{title: p.title} for p in u.posts]} for u in users]thinking模式的思考过程1. 识别问题u.posts触发了lazy loadingN1查询 2. 分析原因SQLAlchemy默认lazy loading每次访问relationship都发一次SQL 3. 考虑方案 - selectinload2次查询1次用户1次所有文章 - subqueryload2次查询子查询方式 - joinedload1次查询JOIN方式 4. 选择selectinload避免JOIN导致的重复数据 5. 额外优化只查询需要的列减少数据传输# thinking模式输出 from sqlalchemy.orm import selectinload router.get(/users) async def list_users(): result await db.execute( select(User) .options(selectinload(User.posts)) # 批量加载文章 .order_by(User.id) ) users result.scalars().all() return [ { id: u.id, name: u.name, posts: [{title: p.title} for p in u.posts] } for u in users ] # 查询次数从N1降低到2性能提升10-100倍案例3内存泄漏Bug描述一个FastAPI服务运行几天后内存持续增长最终OOM。thinking模式的推理链1. 先分析常见的Python内存泄漏原因 - 全局缓存无限增长 - 事件循环引用 - 数据库连接未关闭 - asyncio Task未清理 2. 审查代码发现 - lru_cache装饰器没有设maxsize - 使用了全局dict作为缓存没有过期策略 3. 根因lru_cache(None) 无限增长的缓存dict# thinking模式输出 # 修复1限制lru_cache大小 from functools import lru_cache lru_cache(maxsize1024) # 设置上限 def get_user_permissions(user_id: int): ... # 修复2缓存增加TTL from cachetools import TTLCache # 最大1000条每条5分钟过期 api_cache TTLCache(maxsize1000, ttl300) # 修复3数据库连接确保关闭 from contextlib import asynccontextmanager asynccontextmanager async def get_db_session(): session Session() try: yield session finally: session.close()什么时候用thinking模式场景推荐模式原因代码补全non-thinking简单快速Bug修复thinking需要推理根因架构设计thinking需要多方案对比代码审查thinking需要理解上下文写单元测试non-thinking模板化性能优化thinking需要深入分析