一次有重点的 FPGA 设计评审
如果你在用 Claude Code 或者别的代理式 AI 工具,可能已经试过让 AI 对自己的 FPGA 设计跑一遍评审。如果结果不让你满意,这里有一个改进的建议。
具体来说,就是可以让 AI 代理把评审集中在某些主题上,并通过各种方式告诉它该怎么进行评审。技能集(skill set)做的正是这件事:它塑造代理的行为,让评审依据正确的信息来进行,而不是神经网络训练时见过的任何东西。什么是“正确的信息”?就是写在技能集里的事实。
有一个基于本站内容的技能集已经可以拿来用了。想试一试的话,把你的 FPGA 设计文件放到 AI 代理够得着的地方,然后写一段这样的提示词:
> Using the skill set from https://github.com/billauer/01signal-review, perform a review of the FPGA project. Write out the HTML files.
AI 代理(Claude Code 或者你手上的任何工具)会主要依据那个 GitHub 仓库里的技能集来跑评审,而技能集反映的又是本站的内容。因此,评审报告会聚焦在这里讨论过的主题上。举例来说,本站有一系列页面专门讨论复位(reset)。你的设计和那些要求对得上吗?也许你忘了复位某个不起眼的寄存器,也许还存在更根本的错误?评审报告会告诉你。但愿如此吧。AI 评审并不是确定性的。
用 AI 检查你的设计:好的一面与坏的一面
事实证明,AI 代理在读代码和找错误方面相当在行。但它们的问题在于,常常会凭空捏造出并不存在的错误。而且一旦这么做,通常还能给出非常有说服力的解释,而这些解释往往建立在一个或多个错误的事实判断之上。也许是神经网络训练时学到的信息本身就不对,也许是它从正确的信息里得出了错误的结论,也可能还有别的原因。有人把这叫幻觉(hallucination),我管它叫胡扯。
另一个让人头疼的问题是优先级:比方说,AI 代理很可能把语法错误和其他“让编译失败的错误”(build-breaker)列为评审中的高优先级。这么做有一定道理,因为这些错误不修,设计就编译不过。但把这类错误写进评审报告,收益其实很小:工具在拒绝编译的时候,通常就已经指出了问题所在。只有当问题不那么显而易见时,才值得在评审里提一句。
而且 AI 工具常常会揪住一个小问题不放,把一根鸡毛说成一只鸡(小题大做)。当报告开头的几个主题听起来像胡说八道时,人们很容易把整份评审都扔到一边。
有了技能集,这些问题能在很大程度上得到解决。
技能集如何帮上忙
一个技能集由若干文件组成,大部分内容是纯文本,人可以直接读。它有点像是给 AI 代理准备的一份设计评审说明书(其实做任何任务都是如此)。这些文本主要做三件事:
-
定义什么是真的:就事实和设计实践而言,什么是对的、什么是错的。
-
定义优先级:说明哪些重要、哪些相对来说可以原谅。
-
定义如何开展评审。这里会给出系统化的指示,把评审任务拆分成一个个独立的小任务,让评审有条不紊地进行。这部分通常写在主技能文件里(一般叫 SKILL.md)。
第一和第二部分有助于减少评审报告里的胡言乱语。它们像是一份浓缩的教程,讲的是设计评审中需要考察的主题,既给出事实,也给出优先级。通过明确列出一份需要检查的清单,AI 代理会更多地依赖正确、扎实的事实,更少依赖自己内置的知识。
第三部分组织评审流程,但在 01signal 的技能集里,它还有一个更重要的作用:它包含两个收尾步骤,让 AI 代理核实自己的报告。
在最后一步,另一个 AI 代理会从零开始,充当审查员。它会通读整份报告,核实所有事实性论断是否直接来自技能集。没有这样依据的事实性论断,会在报告里被改写为存疑的说法(比如用一个反问句),而不是 AI 工具惯用的那种言之凿凿的口气。不过,AI 工具不靠自身内置的知识,也无法得出任何结论。所以,报告中应当清楚地分辨出:哪一部分是有依据的(来自技能集,用确定的语气),哪一部分不是(反之)。
当然,技能集里的内容也不是一成不变的。它可能有错,也可能有缺漏。它被放到 GitHub 上发布,并不是偶然。
这不能代替知识
我在本站别的地方说过,这里再说一遍:没有什么能代替我们自己的大脑,也没有什么能代替获取知识的过程。调试工具和 AI 工具都很有用,但最终做决定的还是我们人。
一次 AI 评审不会让你的 FPGA 设计跑起来。但它能把你指向正确的方向。而且由于技能集基于本站的页面,评审不仅会告诉你可能哪里出了问题,还会告诉你该去哪里读更多的相关内容。
所以,如果你犯的错纯粹是人的疏忽,改掉就完事了。但如果是因为你某方面不懂,那就停下来,花点时间把这个缺口补上。毕竟,这正是源自一个网站的技能集的好处。