从想法到可用脚本：一次 AI 辅助 SKILL 开发实践

Hi，大家好。

上次文章的结尾挖了个坑，说要和大家分享用 AI 辅助编写 SKILL 脚本的实战案例。

今天，我来填坑了！

先不讲过程，直接给大家看下我使用 AI 撰写的脚本成品 —— 一个支持 DRC/LVS/xRC 一键批量验证的工具：

在今天的文章中，我会以其中的“批量 DRC”功能为例，手把手带你走一遍，从一个模糊的想法开始，我是如何通过向 AI 提出问题，一步步将它变为现实的。

Part 1 . 从一个简单的需求开始

作为版图工程师，每次画完一个 Cell，都要跑一遍 DRC/LVS 检查，于是你打开 Calibre，配置 Rule 文件，指定输出路径，点击运行…… 等待结果出来后，再打开报告查看错误数量。

进入后仿阶段时，还需要对必要的模块，进行一遍 xRC 的后仿提取流程。如果要验证多个 Cell，那就要重复 N 遍 ……

虽然这个过程已经很熟练了，但我们总是会有偷懒的想法，比如 “能不能把每天重复的 DRC/LVS 流程自动化？”

这个想法很好，但很模糊。

经过长时间的和 AI 对话实践，我知道如果直接把这个模糊的想法丢给 AI，它大概率会回敬你一堆让你怀疑人生的代码。🤨

所以，真要实现起来，第一步不是直接冲上去让 AI 写代码，得先让它帮我把想法，梳理成一份能看懂的需求清单(prd.md)。

第一次对话：向 AI 描述你的目标

我们可以把 AI 当作一名技术顾问，第一次对话时，向它描述你的目标，然后请它帮你梳理实现路径：

你看，我这个 Prompt 的核心不是让 AI 给我代码，而是帮我理清思路和告诉我你需要什么信息。

然后 AI 就会像一个项目经理，帮你把模糊的想法，拆解成一份结构清晰的需求文档，让你清楚的知道下一步需要做什么，准备什么。

AI 把 DRC 自动化分解为“设计准备”、“DRC环境配置”、“执行参数设置”、“DRC执行阶段”、“结果处理阶段”和“清理和通知”这 6 个主要步骤，以及告诉我需要准备“设计相关的库名、cellName、viewName”、“工艺文件信息”、“输出目录日志位置”和“错误处理策略”。

第二次对话：提供必要的信息

现在我们已经梳理好了思路，下面就得把任务细节信息交代清楚。我当时整理了一份详细的需求清单，一次性“喂”给了它。

AI 在获取需求后，很快就交付了第一版代码，一个能对单个 Cell 执行 DRC 的脚本就这样诞生了：

Part 2 . 脚本的优化迭代

脚本的功能框架看起来都不错，但当我在 Virtuoso 中测试时，果不其然，代码报错了。😣

我遇到的第一个错是：ERROR: Failure to open input file *.gds。

这时，我的第一反应，不是直接把这个错误丢给 AI 问 “怎么办”，而是想先凭经验分析一下：

“这个打开 GDS 的步骤是在哪个阶段发生的？”

所以，我手动使用命令行运行了一遍 Calibre 命令，执行后 Calibre 也出现了报错信息。

我这才发现我漏掉了一个关键步骤，目前我本地的 DRC 规则文件是初始配置，Calibre 运行时并不知道要去检查哪个 GDS。平时手动操作时需要修改 Rule 当中的 GDS 和 Cell 名称这些信息，而我没有把这些提供给 AI，自然是会出错的。

第三次对话：完善 DRC Rule 文件配置

分析清楚后，我向 AI 解释了具体情况：

以及提出了解决方案的想法：创建临时规则文件，配置具体的 GDS 路径信息。

AI get 到了我的意思，它加上了创建临时文件的功能：

好了，问题解决。

有时候我们在遇到脚本错误，可先凭自己的经验分析错误。如果能定位问题，将分析过程提供给 AI，能提高解决效率。

第四次对话：实现批量处理能力

单个 Cell 的 DRC 验证成功后，我开始考虑更实用的场景：批量处理。

我想要实现“批量处理”功能，但还是只有零散想法，不确定哪种实现方式更好，我拿不定主意。

这时与其自己苦思冥想，不如把这个开放性问题抛给 AI：

它像一个架构师一样，为我设计了三种设计方案，还分析了各个方案的优缺点：

这能打开你的思路，帮你从一个更高维度审视问题，做出决策。

最后我采用了它推荐的“混合方案”：

方案敲定，AI 也很快生成了第一版批量处理的代码：

然而，又被一个错误拦住：Error* return: return can only be used within a prog . 这次问题出在了 SKILL 语言的语法细节上。AI 在一个 let 代码块里，想当然的用了 return() 函数，但这在 SKILL 里是不允许的。

这里，我直接把“具体的错误信息”和“对问题的分析”发给了 AI，希望它能快速定位问题修复代码：

解决了语法问题后，批量 DRC 功能也能跑通了。

第五次对话：文件组织优化

随着功能的完善，我发现了新的问题：所有生成的 GDS 文件、日志、报告都散落在当前目录，几十个文件混在一起。

当即给它提了个新需求：把每个 cell 生成的文件，都归档到各自独立的文件夹里：

AI 理解了需求后，询问了一些细节：环境类型、目录创建失败的处理策略、Calibre 命令的工作目录切换等。

我们最后一起敲定的目录结构设计如下：

这听起来是个很简单的文件操作，对吧？AI 很快就重构了代码。但当我再次运行时，一个诡异的事情发生了。

CIW 窗口打印出了 “✓ 目录创建成功”，但下一行却又报错 “✗ 无法创建目录，停止处理”。

这次我不知道问题出错在哪了，因为现在的脚本内容已经很庞大了，靠我自己去定位有点难。所以，我将 CIW 窗口中的完整日志输出直接发给了 AI，让它来调试和修复脚本。

它在获得了完整的上下文后，准确定位到了问题：一段 if 语句因为 SKILL 语言的‘隐式返回’特性，在成功执行后却返回了 nil，导致了后续的逻辑判断失败。

第六次对话：统计 DRC 错误的单元和个数

到这个阶段，脚本的核心功能已经很完善了，但我希望能获得更直观和准确的验证结果。仅仅知道 DRC 检查是否“成功”是不够的，我还需要知道每个 Cell 是 PASS 还是 FAIL 以及具体的错误数量。

这次，我向 AI 提出了一个详细的需求，我将这个版本定义为 v1.4。核心思路是：

这次协作的很顺利，脚本运行后没有出现错误。最终输出的统计报告，内容和格式，都非常满意。😄

我跑下整个库的 DRC 验证，给大家看下实际运行的结果：

Part 3 . 为脚本加入图形用户界面 (GUI)

在完成了核心功能的开发后，脚本虽然已经“能用”，但它还是一个需要通过命令行参数来运行的工具。

对于不熟悉 SKILL 语言的伙伴来说，还是有着使用门槛，他需要记住命令的格式、理解每个参数的含义、再手动输入长长的文件路径。像这样的路径设计，会增加他们的使用阻力。

所以，为了让这个工具能真正地在团队中推广开来，我进入了脚本开发的第三阶段：

为脚本创建一个图形用户界面 (GUI)。

我的目标，并非简单地加一个“外壳”，而是要与 AI 协作，设计出一个易用的交互界面。

下面，我会通过三次对话，来介绍 GUI 的设计过程：

第七次对话：共同构思 GUI 界面布局

刚开始使用 AI 辅助 GUI 设计时，我那会儿的工作流是：先手动绘制一份界面草图，抓头挠耳的构思老半天，直到把所有细节都想清楚后，才交给 AI 去完成脚本编写。但慢慢的协作经验变多，其实更应该选择快速开始，而不是纠结于完美方案。

所以这一次，我跳过了绘制草图的步骤，选择直接与 AI 开启关于界面设计的讨论：“根据现有脚本的参数，请帮我设计一个 GUI 界面。”

它提供了具体的组件建议，交互逻辑和一个文本输入框和单选框的基础布局：

+-------------------------------------------------------------+
|              批量 DRC 验证工具 v1.0
+-------------------------------------------------------------+
|                                                         
| 库名 (Library):      [______________________________]       
|                                                         
| DRC 规则文件:        [______________________________]  [浏览]
|                                                             
| Layer Map 文件:      [______________________________]  [浏览]
|                                                             
|-------------------------------------------------------------|
|                                                             
| 运行模式 (Mode):                                            
|    (o) 处理整个库                                           
|    ( ) 处理指定单元格                                       
|                                                             
| 单元格列表 (Cells):                                         
|    +------------------------------------------------+    
|    | INV,NAND2,                                    
|    | TIE1                                          
|    | (每行一个或用逗号分隔)                        
|    +------------------------------------------------+
|                                                             
+-------------------------------------------------------------+
|                                     [ 运行 DRC ]     [ 关闭 ]
+-------------------------------------------------------------+

在这个基础版本中，我发现库和 Cell 列表依旧需要用户手动输入，这点和我们追求的友好界面不符。于是，我继续和它讨论改进方向：能否让用户“选择”而非“输入”？

这整个过程中我们的对话一来一回，通过纯文本沟通，将一个模糊的界面想法逐步细化，最终敲定了界面的整体布局和组件类型。整理成可视化表单预览后，大概是这样：

第八次对话：让 AI 撰写 GUI 设计文档

以上这些关于讨论界面布局的对话，都散落在各个对话框中。在团队里协作过的人都知道，这种沟通方式像极了我们用聊天工具去敲定一个技术方案，这些临时的共识是脆弱的。它们很容易被遗忘，或是在后续的执行中被曲解。

如果我现在直接让 AI “根据我们的讨论写代码”，它很可能会基于对我们对话的模糊印象去自由发挥，最终交付一个偏离我们共识的版本。

所以，我多走了一步，让 AI 把这些零散的对话，沉淀下来：“请将我们刚才的对话内容，整理成一份详细的 GUI 设计方案文档。”

这份文档就像一份给 AI 的 “README”，把我们在对话中敲定的界面布局，和实现这个布局所需的技术细节，都明确的规定了下来。

有了这份设计文档，下一步就简单了：让 AI 严格按照这份文档，把代码写出来。

第九次对话：加入 GUI 界面功能

我将我们最终的设计文档 GUI_DESIGN 和上一版不带界面的脚本 runDrcBatch.il 一起发给了它：

这个 Prompt 的核心就是“约束”，给到 AI 的任务就是将设计文档 1:1 的“翻译”成代码。

AI 交付的代码在核心功能和布局上符合预期。尽管在最终运行成功前，我还是遇到了几个 SKILL 语法错误，但得益于我们的设计规范，整个过程并未发生大的返工。

Part 4 . 成果展示

经过多轮对话的反复打磨，最初那个“让 DRC 流程自动化”的模糊想法，终于变成了一个人人都能轻松上手的实用工具。

现在，我来展示一下最终的使用效果：👇👇👇

两种模式，兼顾效率与易用

为了满足大家的使用习惯，这个工具同时保留了两种操作模式：

runDrcOnCells("myLib" "INV,TIE1" "/path/to/drc.rules" "/path/to/layer.map")

runDrcOnLibrary("myLib" "/path/to/drc.rules" "/path/to/layer.map")

batchDrcGUI()

同时，你还可以将脚本绑定到 Toolbar 工具栏，创建一个专属按钮，彻底告别命令输入方式。

一目了然的验证报告

无论是哪种模式，当任务执行完毕后，脚本都会在 CIW 窗口打印出一份清晰的总结报告。你一眼就能看出哪些单元通过了检查，哪些单元需要你进一步关注。

========================================
 BATCH DRC PROCESSING SUMMARY
========================================
Total cells processed: 5
           Successful: 5
               Failed: 0
========================================
  DETAILED RESULTS BY CELL:
----------------------------------------
  TIE1                 : 0 errors
  INV                  : 2 errors
  NAND2                : 0 errors
  NOR2                 : 1 errors
  BUFFER               : 0 errors
========================================

实际应用场景

这个工具的价值，就是把我们从重复性的操作中解放出来：

功能扩展

虽然这次我们主要实现了 DRC 功能，但因为我们在一开始就和 AI 一起打好了模块化的基础，整个框架很容易扩展。

Part 5 . 方法论

至此，我们已经完整回顾了工具从 0 到 1 的开发故事。但故事背后，更值得分享的是“方法”。

如何与 AI 对话，一步步转化为稳定可靠的代码？

小步快跑，快速迭代

你不可能通过一个 Prompt，就让 AI 直接给你最终的完美脚本。容易成功的路径，是应该把一个大目标分解成一系列小任务，然后逐一攻克。

我的开发路径是这样的：单cell验证 → 修复规则文件 → 批量处理 → 文件组织 → 错误统计 → GUI界面。

每一步都建立在上一步的稳定版本之上。这样即使某一步出现问题，我们修复起来也相对轻松，不会推倒重来。

对话的质量，决定了产出的质量

与 AI 的每次交互，都是在用你的输入换取它的输出。你输入给 AI 的对话质量，直接决定了它输出成果的质量。

在我们的实践中，这主要体现在两个方面 ——

1. 当你提出需求时：提供“结构化的指令”，而不是“模糊的想法”。

   • 在增加 GUI 功能时，我们没有直接说“给我做一个 GUI”，而是通过讨论，将需求沉淀为一份详尽的设计文档。

   • 多花几分钟，把你的需求、上下文、约束条件思考清楚，远比拿到一堆不符合预期的代码再去修改要高效得多。

2. 当 AI 犯错时：提供“可复现的线索”，而不是“无效的抱怨”。

   • AI 写的代码会出错，这再正常不过。关键在于你如何向它反馈错误。无效的抱怨，比如“你的代码跑不通”，对解决问题毫无帮助。

   • 有效的反馈，应该包含：具体错误信息、你的分析和期望的修复方向。

当你把这些信息一起交给 AI 时，它能基于这些线索，快速定位问题并给出精准的修复方案。

把 AI 的“错误”变成项目规则

在合作中，我发现 AI 对于 SKILL 这种小众语言，它会反复在同一个语法点上栽跟头，比如混淆 let 和 prog 的区别、when 语句的用法，甚至一本正经的编造出一些根本不存在的函数。

一次又一次地纠正同一个错误，是低效的。我意识到，简单的纠错是不够的，需要一种方法，让 AI 从自己的错误中学习，并记住这些教训。

在开发结束后，可以让 AI 对之前的对话历史进行了一次复盘，让它梳理并总结出自己犯过的所有语法错误，并形成一份《SKILL 编程错误总结与规范指南》，供后续的开发遵守。

这样，通过引导 AI 复盘和总结，你可以将它的错误转化为项目的知识资产，构建一个越来越可靠的合作伙伴。

你才是项目的主导者

AI 的强项在于规划代码结构、提供技术方案、语法纠错以及生成文档。而你的强项是在于定义目标和方向、提供垂直领域的专业知识、以及对最终方案进行决策。

你需要发挥自己的专业经验，去弥补 AI 的认知局限。比如，AI 不知道 SKILL 处理中文字符有 Bug，也不知道 Virtuoso 环境的具体限制。这些都需要你来提供关键信息，并纠正它的“幻觉”。

写在最后

回顾整个开发过程 ……，AI 让我把时间花在了更有意思的地方 —— 比如琢磨下一个该“偷”什么懒，以及，如何更优雅地偷懒。

它不会替代我们的经验判断，不会替代我们对业务的理解，也不会替代我们的创新思考。但它能帮我们快速实现想法，高效解决问题。

对于我们来说，关键是要学会如何与 AI 协作，如何发挥各自的优势。

最后再给大家几个我的建议：

1. 不要害怕尝试

   • 从一个小需求开始，体验 AI 协作开发的过程。

2. 保持批判思维

   • AI 的建议不一定都是对的，要结合实际情况判断。

3. 注重实践验证

   • 代码能跑起来才是硬道理，要在真实环境中测试。

4. 持续总结优化

   • 每次协作都是学习机会，要总结经验和教训。

希望今天分享的这套工作流，能帮助你把 AI 变成你的 “SKILL 编程” 伙伴。

⋅ END ⋅