很多芯片工程师接触大模型工具之后，用了一段时间，就开始惦记着把 LLM skill 替换成普通脚本。

这些工程师被训练出了一种本能：能确定的事情，绝对不交给不确定的东西。

Skill 能做什么，脚本能做什么

脚本的核心优势是确定性。给定输入，产出固定输出，没有废话。跑仿真、批量重命名网表文件、解析 log 提取时序违例，这些事情交给脚本，干净利落。

# 典型的适合用脚本的场景：从 timing report 里提取 WNS
import re

def parse_wns(report_path):
with open(report_path) as f:
for line in f:
   m = re.search(r'WNS\s*=\s*([-\d.]+)', line)
if m:
   return float(m.group(1))
return None

这种任务，格式固定，规则明确，一行正则搞定，用 LLM 反而是杀鸡用牛刀。

但 skill 的价值不在这里。Skill 处理的是模糊性——需求不清晰、边界不确定、需要理解上下文才能做决策的场景。

比如，让工程师描述一个 RTL bug 的现象，skill 能根据波形描述、模块结构、历史 comment，帮你缩小排查范围。这件事脚本做不了，规则写不出来。

什么时候该用 skill

判断标准其实只有一个：任务的核心步骤能否被穷举。

能穷举的，写脚本。不能穷举的，用 skill。

芯片验证里的 coverage 分析，哪些 corner case 没有覆盖到——这是个需要理解设计意图的问题，不是纯粹的数据统计。工程师可能觉得"这个我自己能做"，但他忘了，每次都要翻文档、对照 spec，这些时间加起来很可观。

真正的问题是信任

工程师不信任 skill，根源不是技术问题，是心理问题。

芯片出了问题，流片失败，要溯源责任。用了一个"黑盒"工具，没办法解释为什么这么做——这在芯片研发团队里是高风险行为。

这种心态是合理的，但不应该成为拒绝新工具的借口。解法是增加可审计性：skill 给出建议，工程师做最终决策，过程有记录。

Skill 和脚本不是替代关系。确定性任务给脚本，模糊性任务给 skill，判断和决策留给人——这条分界线想清楚了，选择困难症自然就好了。