AI辅助的建模设计工程实践
AI 辅助的建模设计工程实践
AI 已经能够承担大量代码实现工作。在建模开发中，它的作用还包括生成模型、编写激励，以及支持架构方案的反复调整。工程师需要处理的问题，也随之扩展到如何表达设计、组织任务，以及判断模型的结果。
这篇文章围绕 AI 辅助建模设计中的几个问题展开：怎样理解它的能力，怎样与它分工，怎样组织交互，以及怎样建立从设计到验证的工具闭环。
一、理解 AI 原理（主观理解与个人判断）
-
为什么是编程和数学？
-
我对 AI 的理解，主要来自工程使用中的观察。一个反复出现的现象是，任务越明确，AI 越容易完成；涉及隐含意图、复杂抽象和设计取舍时，结果就容易偏离预期。
-
编程具有比自然语言更严格的结构化表达。函数的输入输出、数据结构、接口和执行逻辑，都可以通过代码明确写出来。数学则在定义和规则的基础上进行推导。条件给全的数学问题与定义清楚的编程任务，都为求解提供了明确的要求。
-
在这个意义上，我更倾向于把“明确”看作 AI 擅长这类任务的重要原因。建模开发中的功能定义、接口实现和格式转换，也具有这样的特点。将要求表达清楚，是把工作交给 AI 的基础。
-
-
需要 LLM 更加人性化
-
理解用户指令中隐含的意思，修改代码之前主动了解整个工程
- 人性化体现在 AI 能否理解人的真实意图，并据此组织行动。例如，要求修改一段代码，往往隐含着了解相关工程和已有设计的要求。一个合适的协作者会先理解这些背景，再开始修改。
-
降低表达成本
- 人可以说明自己的目的，AI 能够理解其中隐含的意思，不必要求人把全部背景和条件逐一说明。
-
减少过程中的人工照管
- AI 能够主动获取信息、组织行动，人就可以减少对每个操作步骤的指挥。
-
形成长期、连续的协作
- 偏好、决定和经验能够延续，后续任务可以建立在过去的合作之上。项目中的设计共识，也能够在持续开发中得到保留。
-
提高应对非预期情况的能力
- 遇到没有预先规定的情况时，AI 能够结合人的目的作出合适判断，让工作继续推进。
-
二、氛围编程的本质
-
人类要放开 AI 的手脚，让 AI 自由发挥
-
我理解的氛围编程，是人类放开 AI 的手脚，让它自由发挥。
-
当代码实现交给 Agent 之后，人的工作方式也会发生变化。过去需要亲自完成的代码阅读、修改、编译和调试，可以由 Agent 连续执行。人通过对话表达目标、讨论设计，并关注关键的文档变化和结果。
-
这种工作方式需要给 AI 足够的实现空间。对于已经明确的任务，Agent 可以自行寻找相关代码、组织修改并运行验证。人把注意力放在目标、重要的设计和结果上，具体工作的推进则交给 Agent。
-
在建模开发中，这种分工尤其有意义。模型经常需要跟随设计变化而修改，激励和分析脚本也需要同步调整。让 AI 承担这些实现工作，可以加快设计与模型之间的往返。
-
三、理解 AI／Agent 的能力边界
-
缺乏高层级的设计能力
-
我曾用多线程程序来说明这个差别：AI 能够修复复杂多线程程序中的内存依赖问题，但难以设计出一个巧妙的多线程仿真平台。前一种工作已有相对明确的问题和约束，后一种工作需要形成一套合理的抽象，并用这套抽象组织整个系统。
-
这种差别也体现在 AI 对已有代码的理解上。从一个小的想法开始，通过讨论逐步形成设计，通常比较容易推进。设计一旦落实成代码，再让 AI 从实现中重新理解核心的、高层次的概念，就会困难得多。即使已有详细文档，它也可能遗漏重要关系，不能完整把握原来的设计意图。
-
因此，局部问题能够解决，并不意味着整体设计也能得到同样好的处理。能够写出可运行的功能，与能够提出合适的系统抽象，是不同层次的能力。
-
-
明确、批量的任务完成率最高，需要创新和设计的往往不理想
- 明确、批量的任务通常完成得更好，需要创新和高层次设计的工作，结果往往不够理想。
-
反复试错说明 Agent 已经陷入迷茫，不能从全局进行设计和开发
- 反复试错也是一个需要关注的表现。按我的理解，持续反复试错说明 Agent 已经陷入迷茫，不能从全局进行设计和开发。它可能仍然不断修改代码，但这些修改已经难以围绕整体设计展开。
四、把目标和实现分开
-
编译、调试和代码开发属于可以交给 AI 的实现工作
- 目标描述最终要实现的功能和效果。为了达到目标，需要形成架构、确定接口，并把工作组织成可以执行的任务。编译、调试和代码开发，则属于可以交给 AI 的实现工作。
-
将大目标拆成明确、清晰、可以直接开工的任务
- 使用 Agent 时，需要将大目标拆成明确、清晰、可以直接开工的任务。每个任务都应有清楚的输入、预期输出，以及必要的设计背景。这样，AI 可以在一个明确范围内工作，人的设计意图也能够落实到具体任务上。
-
用中间文件、流程和格式表达分层开发的中间状态
-
对于复杂项目，仅靠一段长对话承载全部信息会比较困难。中间文件、流程和格式，可以用来表达分层开发的中间状态。前一个阶段的结果写清楚，后一个阶段就可以根据这些结果继续工作，减少对整段对话上下文的依赖。
-
建模设计本身也有类似的分层表达。已有的建模方法把功能定义、硬件资源约束和时序信息分别组织起来，使不同层面的设计能够逐步补充。这些明确的定义，也为 AI 分阶段完成实现提供了输入。
-
五、智能体的最佳交互方式
-
遇到 Agent 把任务搞砸了
-
可以慢一点，进行步骤拆解，分步进行
- 遇到 Agent 把任务搞砸时，可以慢一点，把工作拆成步骤，分步进行。
-
可以先和 AI 讨论清楚，写个专门的文档
-
对于尚未讨论清楚的设计，可以先和 AI 形成共识，写一份专门的文档，再继续实现。
-
文档是这一过程的中介。它保存已经讨论清楚的概念和设计，也为后续实现提供可读取的背景。
-
-
先确定整体骨架，再通过讨论逐级细化到具体细节
- 讨论可以从最大的骨架开始，逐级细化到具体细节。先确定整体有哪些部分，再讨论各部分的职责和关系，随后进入具体实现。每次围绕相关的问题展开，逐步把设计表达完整。
-
-
支持人准确表达复杂的设计意图，并在协作过程中持续调整设计
-
智能体的交互方式，需要支持人准确表达复杂的设计意图，并在协作过程中持续调整设计。
-
对话便于讨论目标和想法，但复杂设计还包含大量结构关系和具体细节。软件架构、流水线、版图等设计，都需要把这些信息表达出来，才能继续讨论和修改。
-
-
结构化表达的方式和方法
-
用金字塔结构组织表达
- 金字塔结构是一种组织表达的方法。一个节点提出论点、结论或设计，子节点负责解释、细化或证明它。逐层展开之后，可以看清楚每个具体问题属于哪一层，以及它与整体设计的关系。
-
图形化更容易让人验收成果、检验结果
- 图形化表达则更便于人验收成果和检查结果。已有的交互设想包括通过图形界面调整关键参数和细节，也包括人直接编辑代码、文档和注释，由 AI 在旁协作。这些方式都服务于同一个目标：让设计意图能够被准确传达，并持续落实到结果中。
-
六、开发工作的完整工具闭环
-
设计 → 建模 → 波形 → 诊断工具
-
建模开发需要形成从设计、建模到波形分析和问题诊断的完整工具闭环。
-
在已有的建模工具设计中，波形、指令与模块调度日志、性能统计报告，都是运行结果的表达方式。它们让设计者能够观察模型实际执行时的行为。
-
设计有明确表达，模型能够运行，结果能够检查，诊断工具能够提供进一步分析所需的信息，才能支持一轮轮修改和验证。
-
-
通过编译、运行和测试，不断修正生成的代码
- 成熟的软件工具链，让 Agent 能够通过编译、运行和测试，不断修正生成的代码。对于建模工作，还需要把模型的运行结果表达成能够检查的信息，让后续修改有具体依据。
-
通过波形、golden 结果对比和关键仿真节点数据，快速检验建模成果
- 验收模型时，可以检查波形，与 golden 参考结果进行对比，也可以判断关键仿真节点的数据。这些手段支持从更高层次快速检验成果，让人能够围绕模型行为和结果作出判断。
七、AI 辅助建模开发的总结
-
AI 可以快速构建 Demo 级别的功能模型
-
AI 可以快速构建 Demo 级别的功能模型，使设计较快地落实为可以运行的程序。
-
以已有的 ISA 建模方案为例，指令功能可以通过读写寄存器、读写存储器等基本操作来表达。这些操作有明确的定义和接口，可以作为生成模型实现的输入。功能模型运行起来之后，就有了检查功能行为的具体对象。
-
这类工作将讨论中的设计转化为可执行的模型，也为后续补充性能约束提供基础。
-
-
AI 可以辅助生成接近真实需求的复杂激励和 benchmark
-
AI 可以辅助生成接近真实需求的复杂激励和 benchmark。模型开发中的工作范围，因此可以扩展到运行模型所需的输入和测试程序。
-
已有的建模目标包含在硬件完成之前提供软件仿真环境，用于软件开发和测试。激励与 benchmark 是使用这个环境的重要部分。AI 参与这些实现工作，可以支持模型与测试内容一起推进。
-
-
AI 可以加快架构设计和模型的迭代
-
AI 可以加快架构设计和模型的迭代。建模过程中，架构和微架构经常需要调整，模型也要随之改变。
-
已有的功能导向建模方案，将功能定义与性能特性分开，并允许逐步添加和校准性能参数。功能部分可以独立运行，资源竞争和时序约束可以继续补充。在这样的设计基础上，模型实现能够跟随架构方案逐步演进。
-
AI 承担实现和修改工作，运行环境提供评测结果，人再据此调整设计。建模、评测性能、修改架构和更新模型，由此成为可以反复开展的工程工作。
-