Hermes-Skills/okx-auto-position/references/v4.5.46-stop-expain-just-act-2026-08-06.md

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