# v4.5.46 (2026-08-06) 用户偏好:停止解释架构,直接修

## 用户原话

"你在说什么啊,我就要之前的跟单消息正常下单,扯这些是什么啊"

## 触发条件

用户的请求是 **"让某条信号正常跟单"**,agent 应该:
- ✅ 直接讲 信号为什么没跟单(原因)
- ✅ 直接讲 修法(操作 + 命令)
- ❌ **不要**解释 信源链路 / 架构 / 多个组件
- ❌ **不要**展开 forwarder / signal_queue / OKX API 的内部机制
- ❌ **不要**问"你想用 A 还是 B 方案"

## 错误模式(本次 session 实际犯过)

**用户问**: "刚才 BTC 做空信号没跟单"

**错误回复**:
- 解释 "signal_queue.db 入库时机" + "forwarder 转发链路" + "signal_queue_retry cron 跑 process_signal" + "lock 检查机制" + "OKX API 怎么调"
- 说完用户说"你在说什么啊"

**正确回复**:
- "BTC 被熬鹰资本锁了 long,与你 8/5 23:10 予与实盘 BTC 做空减仓 同币种反向 → 锁拒绝"
- "要解锁: `python3 process_signal.py unlock BTC`"
- "解锁后下次同类信号就会跟"

## 实战判断标准

| 用户问 | 错误回复 | 正确回复 |
|--------|----------|----------|
| "X 信号没跟单" | "原因是 signal_queue.db... forwarder... OKX API..." | "X 被 Y 锁(或余额不足/锁过期) → 修法: 命令" |
| "为什么 link 断" | "可能的 5 个原因: ..." | "X 原因, 修法: Y" |
| "怎么修" | "建议改 process_signal.py 函数 + check_signal_lock 逻辑 + ..." | "改 X 行 + Y 行, 代码如下" |

## 核心原则

1. **一次回复 = 1 个明确结论 + 1 个明确修法**
2. **不解释"为什么"在 2 层以上** — "X 锁了" 而不是 "X 锁了 → 锁机制基于 symbol+trader → 因为 process_signal.py 的 check_signal_lock() 检查"
3. **代码 / 命令直接给** — `python3 process_signal.py unlock BTC` 而不是 "可以试试调用 release_lock 函数"
4. **不 make 新的方向** — 用户没问的设计方案不展开
5. **简短** — 5-10 行结束,而非 50+ 行的架构分析

## 关联

- `agent-workflow-feedback-rules.md` — 一次性回复原则
- `user-preference-urgency-and-no-asking.md` — 不问"想怎么做"
- `v4.5.36-2026-07-08-reply-vs-qq-side-separation.md` — 回复侧 vs 推送侧分工
- `v4.5.45-lock-status-push-and-auto-unlock.md` — 锁状态直接 push