网上有个问题，新学计算机的同学问："在AI之前，你们都是手敲代码的吗？"
老程序员看了，普遍会心一笑。
但这个问题其实问得很好——因为几年后，说不定会出现另一个版本："你怎么还在手敲代码，是不会用AI吗？"
每一代人对"正常的工作方式"都有自己的定义，而这个定义会随工具更新而改变。
以前认为手敲代码是天经地义的事，不是什么特别了不起的能力，只是当时没有别的选择。现在某些人开始认为用AI写代码是天经地义的事，也不是什么取巧，只是现在有了更好的工具。
在芯片设计领域，这个变化已经在发生，只是速度比软件行业慢一些。
现在的场景是：有人在用AI生成基础的Verilog模块框架，有人用AI来解读综合工具的报错，有人让大模型帮忙整理设计文档和规范。这些都是真实存在的使用方式，也都在降低某些重复性工作的门槛。
AI能帮你生成一段同步FIFO的初始代码，或者给出一个状态机的模板，这些没问题。但当综合工具报出一条约束冲突，或者仿真波形里出现了一个只在特定激励序列下才出现的时序违例，AI给的答案需要有人去判断是不是对的。
Warning: set_multicycle_path may cause hold violation at path: From: u_arb/grant_reg/Q To: u_proc/data_in_reg/D这条警告，AI可能会建议加一个set_multicycle_path -hold约束。但这个建议是否适用于当前设计，取决于这条路径的实际时序关系，不是模板能覆盖的。
工程判断力不会被AI替代，因为那需要对具体项目上下文的深度理解。
所以"你怎么还在手敲代码"这个问题，将来有一天可能是真诚的质疑，不是嘲讽。
合理的回答应该是：这段代码有特定的设计约束，AI生成的版本我审查过，有几处边界处理不符合项目规范，改起来比重写复杂，所以手写了。
这种回答，展示的是对AI工具的清醒使用，是对工程判断力的运用。
真正的问题从来都不是"手敲还是AI写"，而是：无论用什么方式写出来的代码，你能不能保证它是对的？
这个标准不会变，无论工具如何迭代。
手敲过代码的经历有价值，但不要把它变成一种执念，阻碍对新工具的拥抱。工具的变化是中性的，重要的是那个使用工具的判断力。
