如何给 WorkBuddy 有效反馈——"不错"不是反馈

# 无效反馈
"不错"                        ← 不错在哪？它不知道
"再改一下"                    ← 改什么？它只能猜
"感觉不对"                    ← 什么感觉？什么算"对"？
"不是这样"                    ← 哪样？你心里有，它没有

# ❌ 无效
你：这个方案不太对

# ✅ 层次一：具体化
你：方案的方向对——用缓存加速查询。
   但具体实现有两个问题：
   1. 缓存 key 用了用户 ID，会导致不同数据集共享同一个 key
   2. 过期时间 60 秒太短，这个数据一天才变一次

# ✅ 层次二：不只针对这次，建一个范式
你：这次缓存 key 的问题，不是只这次加 user_id。
   以后所有缓存 key 都要包含"影响 key 唯一性的所有参数"。

   可以建一条规则：缓存 key = 业务域:实体类型:参数哈希
   比如 order_cache:user_orders:md5(user_id+status+date_range)

   以后写缓存，先确认 key 包含了所有影响查询结果的参数。

# ✅ 层次三：让 WorkBuddy 理解你的决策逻辑
你：这次你建议用 Redis Cluster，我拒绝了。不是 Redis 不好。
   是因为这个项目只有单机部署，Redis Cluster 的复杂度（分片/故障转移）
   比它带来的好处多。

   我的选型逻辑是：
   复杂度 < 需求规模。超过需求的方案，再"好"也不是好方案。

   以后建议时，先评估一下方案复杂度和我实际需求的匹配度。

[肯定方向] 用装饰器统一处理错误是对的。
[指出问题] 但 @handle_errors 里不要吞掉所有异常——只吞已知的业务异常。
[给范式] 以后异常处理：已知异常 → 返回明确错误码；未知异常 → 抛出让上层决定。

[指出偏差] 我让你做缓存层，你给我做了分布式缓存中间件。这是方向跑偏。
[澄清需求] 当前只需要本地内存缓存（dict-based），不需要分布式。
[防止复发] 下次如果需求里有你判断"可能需要"但没明确要求的复杂度层级——问我，不要自己加。

[可接受] 代码能跑，逻辑对。
[不够好] 但三个地方的数据校验逻辑是复制的，不是复用的。
[给范式] 重复出现三次的代码 → 抽成函数。同一个逻辑在一个系统里只应在一处定义。

[为什么改] 昨天我说用方案 A，今天改方案 B。因为刚发现方案 A 在并发场景下不安全。
[不是它错] 不是你昨天推荐错了——是信息不完整，我当时没给并发约束。
[范式] 以后评估方案时，如果信息不完整可能导致方案在扩展场景下不成立——先问，别直接定。

# 值得反馈的（满足任一即反馈）
→ 方案方向性错误
→ 重复了之前的错误
→ 有一个可以推广为"规则"的模式
→ 做得超出预期

# 不值得反馈的（跳过）
→ 格式差异（交给格式化工具）
→ 细节偏差已在下一轮自然修正
→ "感觉不对"但说不清哪不对（先想清楚再反馈）

# 每一次有效反馈 = 一次协作模型的更新
class CollaborationModel:
    def update(self, feedback):
        if feedback.is_specific:
            # 更新"这个场景怎么做"
            self.patterns[feedback.scene] = feedback.correction
        if feedback.has_rule:
            # 更新"这类场景的通用处理"
            self.rules.add(feedback.rule)
        if feedback.explains_why:
            # 更新"他的决策逻辑"——更深层的更新
            self.decision_model.adjust(feedback.reasoning)