1 认识 Grevo
Grevo 是上海复旦微电子集团股份有限公司研发的 FPGA 应用开发 Agent 平台。你可以描述需求、提供工程资料并确认关键设计选择；Grevo 协助推进开发任务，将设计文件、代码、开发进度和决策记录组织在同一工程中。
从通用能力进入插件工程开发
Grevo 具备通用 Agent 能力，也具备基于平台提供的插件开展 FPGA 工程开发的能力。插件工程开发是 Grevo 的核心能力，也是本指南的主要使用路径。
| 能力 | 适合的任务 | 使用方式 |
|---|---|---|
| 通用 Agent 能力 | 解释概念、理解代码、讨论问题、处理一般任务 | 直接描述问题或任务 |
| 插件工程开发能力 | 按 FPGA 开发流程推进需求、方案、实现、验证与评审，组织工程产物 | 首次发起时明确输入插件开发提示词 |
首次开始插件工程开发时，请输入以下提示词。
使用插件进行工程开发。
可以在这句话后面直接补充工程需求。该工程的后续会话会自动沿用，无需在每轮对话或后续会话中重复输入。
- 01 / 首次开始明确使用插件
输入“使用插件进行工程开发”，并补充任务目标。
- 02 / 推进任务确认问题，检查产物
与 Agent 明确需求和方案，按阶段查看文件与证据。
- 03 / 后续会话直接继续工程
插件能力自动沿用，无需重复输入启用提示词。
你可以获得什么
把需求落实为可检查的工程产物。 围绕具体任务，逐步形成需求说明、模块划分、接口定义、RTL、验证材料和评审记录。
看清工程进展与待处理问题。 工作流展示阶段和产物状态，帮助你找到当前任务、缺失材料和需要进一步处理的问题。
保留设计选择的依据。 决策记录保存关键问题和确认结果，便于在修改、评审和交接时理解方案背景。
你负责确认需求、约束和关键方案，审查改动与结果。Agent 负责在任务范围内推进工作并提供产物与依据。判断某项检查是否完成，应查看相应的执行记录和证据。
2 完成第一个工程任务
本章使用“双时钟域数据采集与触发记录”作为示例场景。首次任务先完成需求澄清和方案设计，得到可以审阅的需求说明、模块划分与接口定义。后续可以在同一工程中继续实现和验证。
第一步 进入项目并准备任务
登录 Grevo 后，从门户进入 Agent 工作台。首次登录、账号设置或进入工作台遇到问题时，可先查看基础使用指南。
认识工作台。 下图显示尚未打开项目时的工作台。左侧资源管理器和中间欢迎区域都提供“新建项目”“打开项目”入口，右侧显示最近的项目。
| 入口或状态 | 如何使用 |
|---|---|
| 新建项目 | 开始一个新的工程任务时，从这里创建项目 |
| 打开项目 | 继续已有工程时，从这里打开目标项目 |
| 最近的项目 | 查找近期使用的项目；首次使用时可能为空 |
| 未打开项目 | 当前尚未进入工程，需要先新建或打开项目 |
新建或打开项目后，进入该项目的 Grevo 会话。开始前确认当前项目名称，再按下一步启用插件工程开发。
第二步 首次启用插件工程开发
将以下内容复制到消息输入区并发送。第一句用于调用平台提供的插件工程开发能力。
使用插件进行工程开发。
我需要设计一个双时钟域的数据采集与触发记录模块。一个时钟域负责接收采样数据，另一个时钟域负责控制和读取；收到触发后，需要保留触发前后的一段数据供读取。
本次先完成需求澄清和方案设计。请先列出需要我确认的问题，包括数据位宽、采样与控制时钟、触发来源、记录长度、复位方式、读取接口和异常处理方式。信息不足时，请明确列为待确认项。
关键问题确认后，请生成需求说明、模块划分和接口定义，并说明文件位置、设计依据以及尚未解决的问题。本次先不进入 RTL 实现。
后续会话会自动沿用本工程的插件开发能力。 完成本次启动后，你可以直接提出后续任务。
第三步 检查第一次回复
先阅读 Agent 对目标的理解与待确认问题，检查它是否覆盖了你的任务范围。对不清楚的术语，可以要求解释后再回答。对暂时无法确定的参数，明确说明“待确认”，并要求标记它会影响哪些设计。
第四步 回答关键问题并确认范围
按照 Agent 列出的问题逐项答复。回答应包含数值、单位和行为约定；对两个时钟域分别说明相关条件。下面是一种回复格式，其中方括号内容需替换为你的实际要求。
本次需求确认如下：
采样数据位宽：【位宽】。
采样时钟与控制时钟：【频率及相互关系】。
触发来源与触发条件：【说明】。
触发前后记录长度：【分别填写采样点数】。
复位方式、读取接口与异常处理：【说明】。
仍未确定的项目：【列出，或填写无】。
请整理确认结果，说明对方案的影响，并在本次约定的范围内继续。
第五步 找到并检查方案产物
Agent 完成本次任务后，请它列出产物及文件位置。打开对应文件；使用工程管理中的工作流和产物卡片查看进度，使用决策记录核对已确认的问题。存在架构图时，可以结合模块层级和接口关系阅读方案。
| 本次检查对象 | 你要确认的内容 |
|---|---|
| 需求说明 | 采集、触发、记录、读取的行为已写清；数值与单位和你的确认一致 |
| 模块划分 | 每个模块职责明确；采集、控制、记录与读取之间的关系有说明 |
| 接口定义 | 主要接口和信号有定义；位宽、方向、所属时钟域等信息可查 |
| 决策与待确认项 | 关键选择有依据；尚未解决的问题和影响没有被遗漏 |
目标与边界是否清楚？
验收条件是否可检查？
各模块负责什么？
数据与控制如何流动？
信号与时钟域是否明确？
复位和握手如何约定？
方案依据是什么？
哪些问题仍未解决？
第六步 完成本次体验并决定下一步
当你能找到上述产物、理解关键方案选择，并确认剩余问题时，就完成了本次方案设计体验。首次体验的完成不代表整个工程已完成实现或验证。
如需继续，可以直接发送下面的后续任务，无需再次输入插件启用提示词。
请根据已经确认的需求和方案，列出 RTL 实现计划与验收方法。先说明还有哪些前置条件未满足，以及本次准备修改或新增哪些文件，待我确认后继续。
如果结果不符合预期，指出具体条目和差异，让 Agent 修改对应产物，再重复检查。
3 从任务输入到项目推进
开始新任务或接续已有工作时，先明确目标、约束、预期成果与本次范围，并提供相关材料。待 Agent 理解任务后，再结合执行计划推进各阶段，持续检查产物和待确认问题。
准备任务信息
| 信息 | 建议说明的内容 |
|---|---|
| 目标与范围 | 要完成什么功能或解决什么问题；本次推进到哪一步 |
| 工程背景 | 相关模块、已有文件、当前阶段、已经确认的方案 |
| 设计约束 | 接口、时钟与复位、数据规模、性能或资源目标；有指定器件时提供型号 |
| 交付物 | 需要哪些设计文件、代码、测试材料或报告 |
| 验收条件 | 要检查的功能、边界行为、错误场景和结果依据 |
| 协作要求 | 哪些选择需要先确认；允许修改的范围；需要保留的行为 |
不确定的信息可以写为“待确认”，要求 Agent 帮助梳理。提出性能要求时，应区分目标值、估计值和已测得的结果。
使用已有资料和工程
把与任务相关的需求、代码和报告提供给 Agent。文件需要能被当前项目访问；仅粘贴本机文件路径，不能据此认定 Agent 已经获得文件内容。可通过页面提供的文件或上下文入口选择资料，也可直接粘贴必要的文本片段。
开始修改前，先请 Agent 列出它实际读到的材料、对工程的理解与缺失信息。指定参考文档时，同时说明采用哪个版本，避免旧方案和新需求混用。
请先阅读我提供的工程资料，列出已读取的文件，概括模块职责、接口与关键约束，指出还缺哪些信息。本次只分析，不修改文件。请特别检查这些资料与当前任务是否一致。
检查回复中的文件清单与摘要。若材料未读到或理解不对，先补充资料或纠正理解，再进入实施。
复制一个完整的任务模板
以下模板用于已经启用插件开发的工程。首次发起插件工程开发时，在模板前加上“使用插件进行工程开发”。方括号内的内容需要替换。
我的任务目标是：【目标】。
当前工程情况是：【模块、已有文件和当前进展】。
必须满足的约束是：【接口、时钟与复位、性能等条件】。
本次需要交付：【产物及范围】。
验收时需要检查：【行为、边界情况和证据】。
可以修改的范围是：【文件或模块】。
需要先向我确认的事项是：【方案选择或不确定条件】。
请先检查信息是否充分，再提出执行计划。
确认任务并进入工作流
提交任务和资料后，先核对 Agent 对目标、范围与交付物的理解，补充缺失条件并确认执行计划。接下来，通过工作流查看进展，在关键方案、需求变化和阶段结束时核对结果。
插件工程开发将工作组织为阶段、步骤和产物。打开工程管理中的工作流页面，可以查看当前阶段、步骤进度和相关产物。具体阶段划分以当前项目的执行计划为准。
理解工作流和关键确认点
| 典型阶段 | 主要工作与产物 | 用户重点确认 |
|---|---|---|
| S1 需求发现 | 梳理目标、需求和待确认问题 | 需求是否完整，验收条件是否明确 |
| S2 系统方案设计 | 明确系统分工与方案 | FPGA 承担什么职责，与其他部分如何连接 |
| S3 FPGA 方案设计 | 模块划分、接口、数据流与验证策略 | 架构和约束是否符合目标 |
| S4 模型开发 | 模型计划、性能分析与验证材料 | 模型范围、假设与对照方法是否合适 |
| S5 RTL 实现 | RTL、实现清单与相关检查 | 实现与方案是否一致，风险是否处理 |
| S6 验证签核 | 测试用例、回归结果、覆盖率与验证报告 | 实际执行了什么，证据是否支持结论 |
| S7 交付复盘 | 验收、复盘和交付评审 | 交付物是否齐全，限制是否写清 |
阶段名称用于组织流程。“验证签核”阶段的名称本身不代表所有验证或器件时序签核已经通过；需要查看具体执行范围、工具记录和报告结论。
查看阶段和产物状态
在工作流中展开当前阶段，查看步骤与产物卡片。可用的卡片可以进入报告或源文件；“产物缺失”表示对应材料尚未生成；“解析失败”表示存在文件，但内容无法按预期格式解析。
工程管理和报告主要展示 Agent 写入的工程数据。希望修改结果时，应明确提出要修改的源产物和原因，完成后再检查相关页面是否更新。
若看到阶段已过期或存在告警，先让 Agent 解释原因、受影响的产物和下一步检查范围。不要仅根据进度百分比决定工程可以交付。
确认计划和处理提问
复杂任务开始前，可以先要求 Agent 给出计划，列出预计改动、检查方法和需要你确认的事项。界面提供计划模式时，也可用该模式先讨论方案。
Agent 提出方案问题时，应核对问题的背景和影响后再作答。工程中的决策记录可用于查看已确认的问题、答复和时间，帮助你追溯设计选择。
文件改动与命令执行可能出现需要确认的操作。阅读确认内容，检查对象、范围和目的，再决定是否允许；实际确认方式以当前页面提供的控制项为准。
在执行过程中纠正方向
发现目标理解有偏差时，明确指出需要纠正的条目和正确要求。需要暂停当前工作时，使用停止操作；之后先核对已经产生的改动，再决定如何继续。停止任务不等于撤销已经完成的修改。
请先停止扩大修改范围，汇总本次已经完成的操作、改动文件和检查结果。我的修正要求是：【要求】。请先分析已有产物受到的影响，给出调整计划。
修改需求后更新相关产物
需求变更可能影响接口、代码、测试和已有报告。说明变更前后的差异，让 Agent 先分析影响，再执行调整。变更完成后，核对相关产物和验证依据是否同步更新。
原需求为：【原要求】。新需求为：【新要求】。请列出受影响的设计、接口、代码、测试和报告，说明哪些原有结论需要重新检查。先给出修改与验证计划，待我确认后执行。
结束一个阶段前检查依据
检查本阶段的交付物是否齐全，已确认需求是否有对应结果，仍未完成的工作是否列明。存在风险或待确认项时，说明它们会影响什么，再决定是否进入下一阶段。
可以要求 Agent 汇总“完成项、对应证据、未完成项、风险与建议下一步”。汇总中的结论需要能够回到工程文件和执行记录中核对。
4 检查开发成果
适用场景：Agent 完成任务、准备阶段评审，或需要判断某次修改是否满足需求。先检查需求与产物的对应关系，再检查实现和验证依据。
从需求找到证据
请 Agent 列出本次任务对应的需求、交付文件和检查结果。在需求追溯或需求满足度报告中，查看未闭环条目、差距说明和匹配证据。对关键结论，打开原文件进一步确认。
请按需求逐项列出对应的设计、代码或验证证据，说明文件位置、满足情况和剩余差距。没有执行验证的项目，请明确标为尚未验证。
阅读不同类型的成果
| 成果 | 建议检查的内容 | 常见的后续操作 |
|---|---|---|
| 模块架构图 | 层级、接口与数据流是否和方案一致 | 定位相关模块，核对接口定义 |
| RTL 与文件差异 | 修改范围、接口行为和需求对应关系 | 指出具体差异，补充检查要求 |
| 需求追溯报告 | 每项需求是否有产物或验证证据 | 定位未闭环需求并安排补充任务 |
| 架构一致性检查 | 检查范围、问题明细和评审依据 | 查看问题影响并要求修正 |
| 验证报告 | 用例、实际执行结果、失败项和覆盖范围 | 复核日志，补充用例或重新执行 |
| 阶段评审 | 待处理项与证据完整度 | 补齐材料，再检查结论 |
架构图与报告为只读展示时，应通过对话提出修改要求，让 Agent 更新对应源产物；更新后重新检查相关视图。
区分产物与验证结果
生成 RTL、测试用例或验证报告，不足以单独证明功能正确。应核对是否实际执行了相应检查、使用哪些输入和条件、覆盖哪些范围，以及是否仍有失败项或未验证事项。
对于 PASS、HOLD 等结果，应同时阅读检查范围和问题明细。对话中的总结应与工程中的实际证据一致。
检查时序预算和风险
时序架构与时序预算报告用于理解目标频率、时钟关系、模块预算和风险。查看报告时，先确认采用的目标与假设，再检查风险模块及建议措施。
时序预算是设计早期的评估，不代表实际时序签核结果。最终时序应以布局布线后的签核工具报告为准。
可以按以下顺序检查：
- 确认报告中的目标频率、时钟周期等约束与你的需求一致。
- 查看模块预算、裕量与风险模块，区分目标、预测和实际工具结果。
- 请 Agent 解释风险依据、可能影响以及建议的调整方案。
- 调整后核对相关设计、预算与检查结果是否更新。
请解释当前时序预算报告中的风险模块，列出评估依据和假设，说明建议如何影响延迟、资源与接口行为。请单独列出仍需实际工具验证的结论。
结合波形理解行为
已有仿真波形时，通过页面提供的波形查看功能打开相应文件，检查其格式是否受支持。可结合信号、光标和缩放观察行为。波形查看用于检查已有结果，是否实际完成仿真仍需核对执行记录。
先确定要验证的需求与用例，再查看相关时钟、复位、数据和控制信号。重点对照触发条件、数据顺序、边界行为与预期结果，并核对波形对应的代码和测试版本。
请说明当前波形对应哪次仿真、使用什么代码和测试输入，以及本次需求应该重点观察哪些信号和时间区间。若证据不足，请说明缺少什么。
审阅代码改动
展开对话中的文件改动 Diff，检查新增、删除和修改的内容。重点核对变更是否超出约定范围、接口是否发生变化、关联测试是否同步处理。
需要恢复文件时，先确定要恢复到哪个状态以及保留哪些后续工作，再提出恢复要求。不要把“停止任务”或“还原未保存内容”当作已保存工程改动的完整回退。
5 保存并继续工作
需要将项目开放给其他成员查看或编辑时，见基础使用指南：项目访问与共享。本章说明如何接续工程任务。
继续已有工程时，先核对项目和当前进展，再发起下一项任务。该工程后续会话会自动沿用已启用的插件开发能力，无需重复发送启用提示词。
在后续会话接续任务
进入目标项目后，可打开历史会话查看背景，也可以在后续会话中要求 Agent 先根据工程资料梳理现状。插件能力的沿用不代替对当前需求、文件与任务范围的核对。
请基于当前工程，概括已确认需求、当前阶段、已有产物、未完成事项和最新改动。本次我希望继续：【任务】。请先核对需要用到的资料，再提出下一步计划。
阅读摘要，确认它引用了正确的工程资料。若需求在其他材料中更新过，应一并提供，避免沿用旧要求。
在离开前留下清楚的进度
在结束一次工作前，可要求 Agent 总结已完成事项、生成文件、检查结果和待处理问题。对重要阶段产物，通过页面提供的文件下载入口保存所需文件，并核对下载内容。
请汇总本次工作，列出新增或修改的文件、关键决策、实际执行的检查与结果，以及尚未完成的工作。请给出下一次继续时需要优先处理的事项。
准备交付时，还应核对说明文档、工程文件和验证材料是否齐全，列明已知限制与未验证事项。需要整包导出、分享或版本恢复时，先确认当前页面是否提供对应功能及其操作范围。
网络异常后先核对状态
若页面刷新、网络中断或登录失效，重新进入目标项目后，先查看任务状态、最近消息和已有文件。确认工作停在哪里，再决定继续或重试，避免重复提交同一项修改。
不同页面状态下的后台任务行为，应以平台的实际提示和任务记录为准。若无法确定任务是否仍在执行，可在恢复访问后先请求状态说明，或通过问题反馈入口寻求帮助。
管理会话与工程文件
使用清楚的会话名称描述任务，例如“采集模块接口确认”或“触发记录边界测试”。删除会话或文件前，阅读当前页面给出的影响和可恢复性说明；不要假定删除会话会同时删除工程，也不要假定所有删除都能恢复。
6 解决使用中的问题
账号登录、项目权限、额度或有效期的问题，见基础使用指南。本章处理工程开发过程中的问题。
排查时先确认当前项目、任务状态和相关文件，再判断是输入不足、等待确认、执行失败，还是展示问题。保留错误信息，便于进一步定位。
只得到一般回答 没有按工程流程推进
先检查首次发起工程开发时是否输入过“使用插件进行工程开发”。这句话用于调用产品核心的插件工程开发能力。若尚未输入，请发送该提示词并补充本次任务目标。
若本工程已经启用，后续会话会自动沿用。此时应继续检查任务是否足够明确、是否进入正确项目、是否有待确认问题或执行异常。仅凭回复形式，不能确定插件调用是否失败；必要时请求 Agent 说明当前采用的工作流程，并结合任务记录反馈问题。
工作流或决策记录中没有数据
检查当前打开的是否为目标工程，以及 Agent 是否已经生成了对应的工作流产物或决策记录。首次使用时，同时核对是否明确要求使用插件进行工程开发。
可以要求 Agent 列出已生成的相关文件和位置。文件尚未生成时，先明确本次应完成的任务；文件已经存在但页面未显示时，刷新相关视图，并保留异常信息进一步排查。
产物卡片显示缺失或解析失败
“产物缺失”表示对应产物尚未生成。先核对阶段和执行计划，判断它是否应当已经产生。
“解析失败”表示文件存在，但其内容格式不能正常解析。查看卡片的诊断信息，让 Agent 检查对应源文件，修正后再查看展示结果。
当前 【阶段与产物名称】 显示 【缺失或解析失败】。请检查对应源文件、当前任务进展和诊断信息，解释原因，并给出修复方案。请保留仍然有效的已有内容。
Agent 长时间没有继续
先查看最新消息是否需要你补充信息或确认操作，再检查任务是否仍在运行或已显示失败。不要只根据等待时间判断原因。
若显示失败，保留错误信息和相关任务背景。重试前先确认已经完成了哪些步骤，避免重复修改。无法确定状态时，通过问题反馈提供当前项目、时间和现象。
报告显示通过 是否可以直接交付
先检查报告覆盖的需求、实际执行项目、使用的条件和未完成事项。报告只支持其检查范围内的结论，不能自动证明所有功能、时序或应用条件都已满足。
交付前按验收条件核对证据；有差距时，将其明确列入后续任务或交付限制。时序预算与实际时序签核的区别见第 4 章。
想撤销 Agent 的修改
先查看 Diff 和当前文件，确定需要恢复的范围与目标状态。停止任务只能中断后续执行；已完成的修改需要另行处理。
我希望恢复 【文件或模块】 到 【明确的目标状态】，并保留 【后续有效工作】。请先列出受影响的文件与恢复方案，说明是否有可核对的原始内容，待我确认后再处理。
若缺少可恢复的原始版本，应先补充材料或确认处理方案。不要仅依据“已恢复”的文字答复判断完成，应检查实际文件和必要的验证结果。
已有波形但无法查看或理解
检查文件格式、文件是否完整，以及它是否对应当前任务。文件较大时，解析可能需要时间。若仍无法打开，记录错误提示并反馈。
如果能够打开但不知道看什么，要求 Agent 对照当前需求说明要观察的信号、时间区间和预期行为。把波形与相关用例、日志和代码版本一起检查。
提交问题反馈
通过 Grevo 的问题反馈入口，描述期望发生什么、实际发生什么，以及问题出现前的操作。能够引用相关对话时，将其与截图或日志一起提供。
建议包含当前项目与任务、发生时间、复现步骤、页面错误信息，以及与问题相关的文件或报告名称。联系方式按需要填写。
可使用下面的描述结构：
我在 【项目与任务】 中，于 【时间】 执行了 【操作】。
期望结果是 【结果】，实际出现 【现象及错误信息】。
复现步骤为 【步骤】。已尝试 【处理方式】。
相关会话、产物和附件为 【名称或位置】。