AI擅长有清晰边界的编码任务，
比如定义一个函数或对象方法，
它几乎100%能写出满意的代码，
除非输入到输出存在多条路径，
亦即有多种处理方案，
此时AI理不清我的偏好，
实现过程容易偏离需求。
让AI生成更大颗粒度代码时，
情况就会逐渐变得复杂。
类是最小的程序结构单元，
是软件架构的底层支撑，
它的职责边界的划分，
它有哪些属性与方法，
是一种模式的归纳，
若这种模式对AI来说是常识，
则AI通常能给出较为满意的输出，
当这种模式是特定领域的，
例如一个垂直业务场景的模式，
AI的输出通常不尽我意，
我需要与之多轮对话，
沟通成本在增加，
AI效率会被逐渐侵蚀。
让AI生成多个类，
或者让它根据已有类生成新类，
这涉及到软件架构的理解，
架构设计是分层抽象思维活动，
是立体且网状的，
它闪现着领域特有的思维。
越高层次的抽象，
对应着越高阶的领域认知，
虽然更接近问题的本源，
但对AI和人提出了更高挑战，
这不仅是AI的伤心地，
也是我的伤心地。
它的能力发辉在这里会失控，
让我和它的沟通成本剧增。
这半个月以来，
一个具体神经网络训练上给我的折腾，
让我不满足AI生成的就事论事的代码，
而是有了"冲动"的想法，
写出一个能支撑这类神经网络训练的框架，
这个想法又激活了另一个想法，
写一个能完整支撑监督学习的训练框架，
这个想法进一步激发了更大的"野心"，
写一个能支持全部学习范式的通用训练框架。
以为凭借自己的经验，
加上AI的辅助，
一切应该是水到渠成，
确实也写出了初级版本，
甚至还对接了现有的问题，
但是每一次重新审视这个框架，
每一次会发现新的问题，
发现其根基存在不稳。
不断的与AI对话，
试图修补不足，
结果不是牵一发动全身，
就是顾此失彼，
这种反复折腾极耗精力。
到头来，
忽然间发现，
那个原始具体问题还在那里，
而我却陷入多层抽象的陷阱中，
好不容易才从中抽离出来。
我对AI结对编程，
终于"刻骨铭心"了一次，
折磨给了我深刻的教训。
软件开发不仅仅是编码，
更是一种抽象思维活动。
抽象思维活动是分层的，
具体问题只需偏向底层的抽象，
从具体问题到一般问题，
是更高层级的抽象，
需要有更高阶的认识。
抽象思维层次越低，
AI就越能胜任，
反之，
就越容易出错失控。
如果我把抽象活动，
限制在当前具体任务上，
通常可获得较为精确的AI方案，
但有可能是头痛医头。
如果希望得到更一般的方案，
最好是从当前感受到的痛点出发，
局部的进行抽象思考，
抽象的层次也只局限于，
比当前的抽象层次最多高一层。
层次过多，覆盖面太广，
与AI的沟通成本会急剧上升，
抵消甚至超过AI效率成本。
只着眼于眼前的方案固然不足，
但为应对想象中的未来问题，
而试图构造出一种普适方案，
更会陷入偏离当前的风险中。
------后记
这段反思，
从实践中来，
让我掉了不少头发，
到实践中去，
希望头发又长出来。