从一次AI编程实战聊聊：AI辅助设计，为什么人的判断力比以往更值钱
上篇文章我复盘了一次真实的AI协作设计过程 《一次与AI的"设计对话"》。
那些关键判断到底是怎么做出来的？为什么能问出那些问题？
今天这篇文章，我想聊聊更底层的东西：在AI时代，工程师的判断力从何而来。
一、AI时代，工程师最稀缺的能力不是写代码
先说个现象。
现在用AI编程工具的人很多，但多数人的用法是这样的：
需求 → 丢给AI → 拿结果 → 复制粘贴
这种用法有没有价值？有。但价值有限。
因为AI给的是标准答案——它会给你一个"差不多对"的方案，但很难给你一个**"这个场景下最合适"**的方案。
就像解题一样，AI能给你一个解题过程，但判断哪个解法最优、哪个假设有问题、哪个边界情况需要考虑——这些，依然需要人来做。
这就是为什么我说：在AI时代，工程师最稀缺的能力不是写代码的速度，而是卓越的决策能力。
二、充分讨论：让AI成为思考的伙伴
这次设计让我深刻体会到一件事：AI最强的能力不是写代码，而是快速呈现多种可能性。
传统模式：
需求 → 直接让AI生成代码 → 调试修改 → 完成
本次实践：
需求 → 多轮方案讨论 → 质疑和优化 → 达成共识 → 才考虑实现
通过对话，我们可以探索更多备选方案，发现盲点。充分的讨论让我们避免了"第一个想法陷阱"。
实践建议：
- 不要急于要代码，先让AI分析问题的本质
- 多问"为什么"，质疑每个设计决策的必要性
- 要求对比方案，让AI给出2-3个备选方案并分析优劣
- 记录决策过程，像这次复盘一样，保留思考的轨迹
案例回顾：如果没有充分讨论，我们可能会停留在第一版的复杂设计（1000+行代码、三目录结构、复杂状态机），而不是最终的极简方案（350行代码、单一索引、无状态文件）。
三、设计先行：架构思维比编码速度更重要
AI时代的悖论：
- 代码生成速度提升了10倍
- 但糟糕的设计带来的技术债务也增加了10倍
设计思维，比编码速度更重要。
在这次实践中，我有几个体会：
1. 先画架构图，再写代码
我们花了大量时间讨论文件流转、索引结构、并发控制，这些讨论避免了后续的重构成本。
2. 明确边界和职责
FallbackWriter只负责写入和滚动，IndexManager只负责索引管理，CompensationHandler只负责补偿。职责清晰，代码自然简洁。
3. 考虑异常场景
程序崩溃怎么办？磁盘满了怎么办？索引损坏怎么办？提前设计容错机制，而非事后补救。
核心观点：AI可以让编码速度提升10倍，但优秀的设计仍然需要人类的深度思考。设计的质量决定了项目的上限，AI只是帮助你更快地达到这个上限。
四、学会质疑：批判性思维是AI时代的护城河
回到上篇文章的案例。
AI给我的第一个方案，其实不算差。三目录结构、状态机、复杂索引……放在两年前，我可能就接受了。
但我没有。
为什么？
因为我有几个质疑的习惯：
质疑一：这个设计解决了什么问题？
三目录结构的目的是区分文件状态。但如果文件存在就代表待补偿、文件不存在就代表已完成，那状态字段是不是就多余了？
质疑二：这个设计带来了什么成本？
断点续传听起来很美好，但需要额外的索引来记录进度。数据库成功率>99.9%，10MB文件重读几百毫秒。这个成本值得吗？
质疑三：有没有被忽略的边界情况？
AI没有主动提到当前文件可能不被补偿的问题。这不是AI的错——它只是按标准模式生成方案。但边界情况，往往藏在标准模式的缝隙里。
这三个质疑，帮我把方案从"看起来完善"优化到了"真正可靠"。
五、让AI自我审视：高级技巧
这是我这次设计实践中最重要的发现：不要只让AI给出方案，还要让它审视自己的方案。
实践方法：
1. 要求AI自我批评
用户：请分析这个方案的缺点和潜在问题
AI：这个方案存在以下问题：
- 索引结构过于复杂，维护成本高
- 三个目录的管理增加了实现难度
- 状态字段可能冗余...
2. 要求对比多个方案
用户：请给出3个不同复杂度的方案，并对比优劣
AI：
方案A（复杂）：完整状态机+多目录+详细索引
方案B（中等）：单一索引+无状态文件
方案C（极简）：无索引+全量重试
推荐：方案B，平衡了可靠性和复杂度
3. 要求找出边界情况
用户：这个方案在哪些极端情况下会失败？
AI：
- 磁盘空间不足时...
- 程序崩溃时索引可能损坏...
- 并发读写可能冲突...
建议增加相应的容错机制
4. 要求优化建议
用户：这个方案还能如何简化？
AI：
- 可以去掉状态字段，靠文件存在性判断
- 可以用Properties替代JSON
- 滚动时可以迁移索引，避免孤儿数据
本次实践中的应用：
第1轮：AI给出初始方案（复杂索引+三目录）
↓
我问："这个方案是否过于复杂？能否简化？"
↓
AI自我审视："是的，可以去掉状态字段..."
↓
第2轮：简化方案（单一索引+无状态）
↓
我问："当前文件不补偿会有什么问题？"
↓
AI自我审视："低流量场景下会延迟补偿..."
↓
第3轮：优化方案（允许补偿当前文件）
↓
我问："滚动时索引如何处理？"
↓
AI自我审视："应该迁移索引，避免重复补偿..."
↓
最终方案：极简且完善的设计
核心原理：
- AI拥有广泛的知识，但缺乏主动的批判思维
- 通过提问，我们可以激活AI的"批判模式"
- AI能够发现自己方案中的问题，但需要你引导它去审视
核心观点：AI会给你"看起来合理"的方案，但只有人类才能判断"是否真的必要"。**质疑能力是将AI输出转化为优质方案的关键过滤器。**而让AI自我审视，是提升质疑效率的强大工具。
六、知识广度与深度：决策质量的基石
说到这里，可能有人会问：你凭什么能问出这些问题？是经验吗？是天赋吗？
我觉得都不是。
是知识广度。
这次设计涉及的知识领域包括：
文件系统
├─ 文件IO（BufferedWriter、RandomAccessFile）
├─ 原子操作（rename、临时文件）
└─ 并发控制（ReentrantReadWriteLock）
数据结构
├─ Properties vs JSON
├─ 索引设计（键值对 vs 嵌套对象）
└─ 队列模型（生产者-消费者）
分布式系统
├─ WAL（Write-Ahead Logging）
├─ 断点续传
└─ 幂等性保证
性能优化
├─ 延迟刷盘
├─ 批量处理
└─ 动态调整策略
软件工程
├─ 包装器模式
├─ 职责分离
└─ 渐进式优化
如果我不知道WAL是什么，我怎么判断AI的方案合不合理？
如果我不了解幂等性，我怎么知道数据库唯一约束能保证什么？
知识广度决定了你能看到多少可能性，知识深度决定了你能判断哪个可能性是真正值得追求的。
如何提升知识广度：
- 跨领域学习，不要局限于自己的技术栈
- 不仅知道"怎么用"，还要知道"为什么"
- 阅读开源项目源码，关注技术博客和论文
- 通过实际项目应用新知识
七、AI时代的卓越决策能力
最后，我想聊聊AI时代工程师的核心竞争力。
很多人担心AI会取代程序员。但从我的实践经验来看，AI取代的不是程序员，而是"只会写代码"的程序员。
为什么这么说？
因为AI在编程领域的价值，是加速执行——它能快速生成代码、快速尝试方案、快速迭代版本。
但定义问题、判断价值、权衡取舍——这些，依然需要人来完成。
AI可以给你10个方案，但决定哪个方案最优的是你。
AI可以写出代码，但判断这段代码是否真正适合当前场景的是你。
AI可以优化性能，但定义优化目标的是你。
这就是为什么判断力比以往更值钱——因为AI能做的事越来越多，而人需要做的事也越来越高端。
传统工程师的核心能力：
- 编码速度
- 算法能力
- 框架熟练度
AI时代工程师的核心能力：
- 问题定义能力：准确识别真正的问题
- 方案设计能力：设计简洁可靠的架构
- 决策判断能力：在多个方案中选择最优
- 批判思维能力：质疑和优化AI的输出
- 知识整合能力：跨领域知识的连接和应用
八、给AI时代工程师的建议
不要做的事：
- 盲目接受AI生成的第一个方案
- 跳过设计直接让AI写代码
- 停止学习和思考，完全依赖AI
- 追求技术的复杂性，忽视简洁性
要做的事：
- 充分讨论：让AI成为思考伙伴，多轮对话探索方案
- 设计先行：先明确架构和边界，再生成代码
- 学会质疑：批判性审视每个设计决策
- 持续学习：拓宽知识广度，加深理解深度
- 沉淀经验：记录决策过程，形成方法论
九、结语
这次审计日志降级方案的设计过程，让我深刻认识到：
AI不会取代工程师，但会使用AI的工程师会取代不会使用AI的工程师。
更重要的是：
在AI时代，工程师的价值不在于写代码的速度，而在于决策的质量。
- AI可以快速生成10个方案，但决定哪个方案最优的是你
- AI可以提供技术细节，但判断是否必要的是你
- AI可以优化代码性能，但定义优化目标的是你
卓越的决策能力 = 充分讨论 + 设计先行 + 学会质疑 + 知识广度
这四项能力，是AI无法替代的，也是AI时代工程师最稀缺、最有价值的核心竞争力。
愿我们都能成为善用AI、超越AI的卓越工程师。
这个系列是《一次与AI的"设计对话"》的姊妹篇。如果还没看第一篇，建议先看那个实战案例，再来看这篇方法思考。
完整仓库地址：
