很多芯片工程师接触大模型工具之后用了一段时间就开始惦记着把 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(rWNS\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判断和决策留给人——这条分界线想清楚了选择困难症自然就好了。