RAPTOR流程图编程：从六个符号到算法迁移的完整教程

简介：面向编程初学者与算法入门者的 RAPTOR 可视化程序设计教程，以 PPT 形式完整讲解流程图式编程的核心理念和操作方法。内容涵盖学习 RAPTOR 的理由、基本程序界面与输入、输出、赋值、过程调用四种基本符号；变量命名规则、赋值过程与变量值设置，以及数值和字符串两种数据类型的注意事项；同时介绍未定义引用、拼写错误、类型不可直接比较等常见报错原因，并讲解 pi、e 等预定义常量和给程序添加语句符号的具体步骤。资源包内为单份 PPT 演示文稿，大小约 3.88MB，便于本地播放或课堂展示。目前已有 1077 人学习，适合高校《可视化计算》课程、编程启蒙培训或自学算法基础使用。通过本教程，读者能直观理解程序执行流程与计算思维，掌握用流程图描述算法、验证逻辑的方法，并为后续过渡到 C++、Java 等高级语言打下平缓学习阶梯。

1. RAPTOR 不是什么玩具：从流程图完成第一次“可运行”的程序设计

很多人第一次听说 RAPTOR，是看到一张张像电路图一样的流程图，觉得这顶多是文科生眼里的“画图工具”。实际用一轮就会改观：RAPTOR 把流程图直接当程序跑，变量在赋值框里变值，选择框的箭头决定走哪条路，循环框一框框转给你看。它对“看不懂语法”的新手非常友好，也特别适合拿来对照 C、Java、Python 里那些抽象的控制结构。我一般在教循环和数组之前，先让学生在 RAPTOR 里把逻辑跑通，再把同样的逻辑翻译成文本代码，学习阻力会小很多。这套方法对应到编程教学素材里，最常出现的就是以“RAPTOR 程序设计教程”命名的课件，下面我把其中的关键内容拆开讲：从六个符号开始，到变量、子过程、三种算法，再到用批处理命令行批量验证结果的落地办法，最后把最容易翻车的地方单列一章。

2. 认识六个符号就能开始编程：RAPTOR 的变量、数组与子过程

2.1 六个符号对应的三类控制结构

RAPTOR 的绘图工具栏上长期只有六个基础符号：赋值、调用、输入、输出、选择、循环。别看数量少，它正好完整覆盖了结构化程序设计的三种基本结构——顺序、选择、循环。

赋值符号用来给变量写值，比如sum <- sum + i；调用符号用来执行一个定义好的子过程；输入符号把用户在终端的输入写进变量，输出符号把结果打印出来。选择符号是菱形，一个入口两个出口，条件为真往左，条件为假往右，对应文本语言里的 if/else。循环符号在教学中最容易混，它是一个带退出条件的框，RAPTOR 的做法是“进入循环体之后先执行一轮，再检查退出条件是否成立”，这一点和很多学生脑补的 while 循环行为不一样，后面避坑章节会专门展开。

把这六个符号映射到 C 语言，可以看到极其工整的对应关系：赋值符号对应等号表达式，选择对应 if 分支，循环对应 do-while，调用对应函数调用。也就是说，学会 RAPTOR 并不是学一套孤立的画图规则，而是在为后面写文本代码预演控制流的走向。这也是为什么很多《程序设计基础》课程把 RAPTOR 放在大一前几周，等学生能画清楚“输入 → 计算 → 输出”的流程，再进入 C 语言语法。

2.2 变量是全局的：RAPTOR 作用域和文本语言最大的差别

RAPTOR 的变量管理方式值得单独说，因为它是新人从流程图过渡到 C/Java/Python 时最容易误解的点。RAPTOR 的变量默认是全局的，你在主流程里建了一个n，进了子过程还能直接读到同一个n；反过来，子过程里随手改了一个名字，主流程里也可能受影响。这跟 C 语言里局部变量、全局变量的隔离规则完全不同，更像早期 BASIC 或 JavaScript 未声明变量的随意风格。

实际教学里，这个问题会在学生做“两个数交换”子过程时集中暴露。C 语言里写swap(a, b)期望把主程序里的两个变量换掉，需要传地址或用指针；RAPTOR 里因为全局变量特性，你直接改子过程里的形参，有时候会成功，有时候又不会，根源在 RAPTOR 的参数传递方式上。

RAPTOR 的子过程参数默认按值传递：调用时把值复制一份送进子过程，子过程内部怎么改，外面变量的值不变。但因为全局变量的存在，如果子过程内部直接使用了与全局变量同名的变量，RAPTOR 会操作全局的那个——于是出现“有时候改了有效，有时候无效”的玄学现场。所以我在课上定的规矩是：子过程里的变量尽可能加前缀，比如p_count、p_sum，避免和主流程变量同名；需要子过程返回结果时，用返回值或者把结果写入一个明确约定的全局变量，不要靠“碰巧同名”。

2.3 从启动到跑通：用命令行运行第一个 .rap 文件

用图形界面拖符号跑程序当然直观，但是真到了批量验证作业的时候，一个一个点鼠标效率太低。RAPTOR 提供了一种批处理运行方式：在命令提示符里调用rapid.exe /b 文件名.rap，执行过程中不弹图形窗口，输出直接打印到标准输出，可以重定向到文本文件里做自动化比对。这个能力在检查学生作业、跑测试用例时非常实用。

我一般会先把测试用例写到一个输入文件里，再用标准输入重定向喂给程序，命令大概是这样的：

C:\RAPTOR\rapid.exe /b assignment01.rap < test_input.txt > result.txt

参数说明：/b是 batch 模式的开关，必须写在整个命令里；< test_input.txt把文件内容作为程序需要的输入；> result.txt把输出写到结果文件。这样一次能跑一批学生作业，再用fc或diff对比标准输出，几秒就能定位谁的程序边界条件没写对。

提示：RAPTOR 的输入符号在批处理模式下必须保证输入文件里的行数足够，少一行程序会停在等待输入状态，结果文件里只输出到一半。

用命令行还有一个隐藏好处：逼着学生把输入格式严格固定下来。很多学生在图形界面里试的时候，输入随意输，输出靠肉眼比对，逻辑边界错误根本发现不了。一旦进入文件重定向比对，输入多一个空格都可能造成结果不一致，这本身就是程序设计实践里“程序健壮性”的启蒙。

3. 把流程图翻译成 C/Java/Python：RAPTOR 到文本代码的映射表与迁移思路

3.1 一张映射表把 RAPTOR 对照成文本语言

RAPTOR 学习不能止步于画图，最终要迁移到真实项目里。这中间最关键的一步是建立“符号 → 语句”的翻译映射。我常用的对照表如下，C、Java、Python 三列给到最常见的对应写法：

表格里最容易出问题的是“循环”那一行。RAPTOR 的循环语义接近 C 的do-while，但很多人画图时心里想的却是while(条件)，导致翻译成 C 代码后把do-while改成while，程序行为立刻不一样。我在迁移训练里会专门让学生做一个练习：把同一个 RAPTOR 循环分别翻译成do-while和while两个版本，再改成判断条件相反的写法，体会“先判断后执行”和“先执行后判断”的差别。

数组方面，RAPTOR 默认下标从 1 开始，而 C、Java、Python 默认从 0 开始，这也会引发连锁 bug。流程图里访问a[1]是第一个元素，到了 C 里写a[1]却成了第二个元素。因此翻译数组逻辑时，所有下标都要整体减一，这是最容易成片扣分的点。

3.2 什么时候学 RAPTOR 最能帮到程序设计实践

RAPTOR 不是用来替代 C 或 Java 的，它最合适的定位是“正式写代码之前的一块试验田”。如果你手里已经有一个项目任务，比如实现一个学生成绩统计，我建议的顺序是：先在 RAPTOR 里画出主流程，找到需要循环遍历的数组；再为统计、排序、查找这些子功能建子过程；最后在 RAPTOR 里用冒烟数据跑通，再打开 IDE 照着流程图写 Java 或 Python。

这样做的价值在调试阶段尤其明显。文本代码一旦跑出错误，新手区分不开“逻辑错了”和“语法错了”，常常在编译错误上耗掉大量时间。RAPTOR 图形环境中语法错误几乎没有，程序跑偏了能直接从箭头上看出走到了哪个分支，学生可以专注做逻辑验证。等逻辑在流程图层面被确认没有问题，再进入文本代码，编译报错就只剩下类型和语法层面的事，问题定位范围一下子小了很多。

对于互联网程序设计、Web 开发这类真实工程场景，RAPTOR 的作用会减弱一些，它毕竟画不出 HTTP 请求和数据库连接。但是“登录流程”“订单状态流转”这些业务逻辑，用 RAPTOR 画出来再转成后端伪代码，依然比直接写代码更容易让团队对齐。我的用法是把它当业务流程图和代码之间的中间产物，而不仅仅是大一课程作业。

3.3 翻译一段判断闰年的流程图到 Java 代码

用一个具体例子走一遍完整迁移过程。判断闰年的逻辑是：能被 400 整除，或者能被 4 整除但不能被 100 整除。先在 RAPTOR 里搭流程：输入年份year→ 选择框判断year % 400 == 0→ 上述条件为真时输出“闰年”；为假时再判断year % 4 == 0且year % 100 != 0，成立则闰年，否则输出“平年”。

这个例子在 RAPTOR 中要注意，选择框的判断条件不能直接写复合条件里嵌一组括号再取反，RAPTOR 支持and、or、not运算符，但是新手容易把优先级写错。我在图上一般写成两个选择框串联，不用复杂的取反表达式，降低读图难度。与之对应的 Java 代码如下：

import java.util.Scanner; public class LeapYear { public static void main(String[] args) { Scanner sc = new Scanner(System.in); int year = sc.nextInt(); if (year % 400 == 0) { System.out.println("闰年"); } else if (year % 4 == 0 && year % 100 != 0) { System.out.println("闰年"); } else { System.out.println("平年"); } } }

这里的映射逻辑是：RAPTOR 的第一个选择框对应 Java 里最外层的if，第二个选择框对应else if，两个条件都用到了取余运算符%，和流程图里的判断条件完全一致。学生在 RAPTOR 里验证完“公元 2000 年是闰年，1900 年是平年”，再到 Java 里跑同一组数据，会明显感觉到流程图的判断分支和代码的分支是一一对应的，这个“一一对应”的体感就是迁移能力建立的过程。

4. 三种拿得出手的练习：累加、回文、排序在 RAPTOR 里怎么搭

4.1 累加求和：看清循环与计数变量

累加求和是最小规模的完整程序设计案例，适合用来检验学生是否真懂循环。题目：输入正整数n，计算1 + 2 + ... + n。很多学生在 RAPTOR 里画出来的循环方向是“先加再判断”，导致结果多算一项；还有学生把计数变量初始值写成 0，累加变量也写成 0，最后输出直接少 1。

我建议的流程图结构分四步：初始化sum <- 0和i <- 1；进入循环，先把sum <- sum + i；然后i <- i + 1；接着判断i > n是否成立，成立则退出循环。这四步对应的正是 RAPTOR 循环符号最典型的用法——一定要手动维护计数变量，RAPTOR 没有像 C 语言那样的for(i=1;i<=n;i++)一步到位写法。

用批处理模式验证时，我一般准备三组输入：n=1检查最小边界，n=5检查常规计算，n=100检查循环次数较多时结果是否稳定。输出分别应为1、15、5050。如果n=1的结果不是 1，基本可以断定循环结构画成了“先判断后执行”的形式，需要回头检查循环退出条件的位置。

4.2 回文判断：用索引同时访问首尾

回文串判断比累加多一个数组概念，练的是下标配合。题目：输入一个字符串或数字序列，判断正序和逆序是否相同。RAPTOR 中字符串处理能力偏弱，所以我把这道题限制在数字数组上：先输入n，再输入n个数字存入数组a，判断a[1]到a[n]是否构成回文。

算法流程通常是：设left <- 1，right <- n；循环条件是left < right；每次比较a[left]与a[right]，一旦不相等，直接输出“不是回文”并退出整个流程；相等则left <- left + 1，right <- right - 1。这里最关键的参数是循环退出条件，我见过大量学生写成left <= right，在偶数长度时多比较一次，在奇数长度时中间元素被自己和自己比较，程序虽然不报错，但输出的结论依然正确——问题在于逻辑不够严谨。

RAPTOR 的数组下标从 1 开始，所以左指针初始值应写 1，不是 0；右指针初始值是n，不是n-1。如果在 C 语言里复刻，下标整体减一，右指针要改成n-1。这个差异点我在课堂上反复强调：RAPTOR 调试通之后转到 C 语言，第一件事就是把所有下标画一条“减一”的线。

4.3 冒泡排序：数组下标和交换的边界

冒泡排序是 RAPTOR 教学里最能暴露问题的算法，因为它在流程图层面要把两层循环嵌套画出来，还要在交换时处理临时变量。题目：输入n个数字，按升序输出。外层循环控制排序轮数，内层循环控制每一轮的相邻比较。

RAPTOR 里我通常用两个 Loop 符号嵌套。外层循环的计数变量是i，初始值 1，每轮结束加 1，退出条件是i >= n；内层循环计数变量是j，初始值 1，退出条件是j >= n - i。内层每次比较a[j]和a[j+1]，如果前者大于后者，就交换。

交换操作必须借助第三个变量temp，写成三步：temp <- a[j]，a[j] <- a[j+1]，a[j+1] <- temp。这组赋值顺序是铁律，少一步或多一步都会把数组写乱。我的验证数据固定用五组：逆序输入5 4 3 2 1，完全有序输入1 2 3 4 5，含重复值3 1 2 3，只有一个元素7，以及两个元素2 1。这五组跑过，排序算法的边界基本就稳了。

有个细节值得注意：RAPTOR 在嵌套循环退出条件的设置上，外层和内层的判断先后容易设计反。内层应保证每一轮最多比较到“未排序区最后一个位置”，所以退出条件要写成j >= n - i，而不是固定的j >= n - 1。如果写成后者，每一轮都把整个数组扫一遍，算法虽然还能得出正确结果，但多做了无效比较，放到 C 语言里就是性能隐患，数据量一大就会拉开差距。

5. 跑 RAPTOR 必踩的五个坑：现象、原因与解决手册

5.1 循环少跑或多跑一轮：退出条件的位置不对

现象：同一个累加程序，有的学生算出来的结果比标准答案多一项，有的少一项。原因：RAPTOR 的 Loop 符号是“先执行循环体，再判断退出条件”，这个语义和 C 语言while的“先判断再执行”刚好相反。如果学生画图时把退出条件放在循环体入口位置，就会画出弱智版“先判断再执行”，但实际上 RAPTOR 做不到，退出条件只能在循环体尾端判断，于是程序必然先执行一轮。解决：把循环体内的赋值操作想清楚再画，检查退出条件所在的位置一定在循环体最后，并且手动跟踪n=1这一组数据，验证执行次数是否等于 1。

5.2 数组越界不报错：RAPTOR 的宽容会掩盖错误

现象：程序里访问了a[0]或a[n+1]，RAPTOR 不弹错误，甚至能跑出“看似合理”的结果。原因：RAPTOR 对数组下标的检查很松散，访问越界位置时不抛运行时异常，只是取到一个不确定的值。这比 C 语言还危险——C 至少在某些实现下会段错误，RAPTOR 直接把错误吞了。解决：在关键数组访问之前，增加一个选择框检查索引范围；同时养成从 1 开始下标、不写a[0]的习惯。对学生作业批量检查时，专门找边界输入，比如n=1时访问a[2]的操作都应视为不合格。

5.3 子过程改了参数，主流程变量没变

现象：写了一个排序子过程，调用后回主流程打印数组，发现数组还是原来的顺序。原因：RAPTOR 的子过程参数默认按值传递，子过程内部复制了一份参数值，修改不影响调用处的变量。这和很多学生从 C 语言函数那里学到的“数组作为参数传递时能直接改原数组”的经验冲突。解决：如果子过程中确实要修改数组，把数组整体的操作放在主流程中完成，或者把排序结果作为返回值赋给主流程变量。在流程图层面最直观的做法是子过程执行完排完序的逻辑后，再通过赋值符号把结果写回全局数组变量。

5.4 批处理模式下输入不够：程序挂住不出结果

现象：用命令行批量运行学生作业，结果文件只有半截输出，进程卡住。原因：rapid.exe /b模式下，程序如果执行到 Input 符号，会等待标准输入；输入文件里行数不够，程序就一直等在那里。解决：先核对每个.rap程序需要的输入个数，再构造输入文件。我自己的习惯是输入文件末尾故意多放一空行，减少因换行符缺失导致的问题。另一个麻烦是有的程序在中间某个分支还会额外读取输入，比如异常分支里重新要求输入，这时输入文件的行数要在标准用例基础上预留余量。

5.5 学生照抄流程图却理不清逻辑：被 PPT 里的“标准答案”带偏

现象：只要教程 PPT 里给过完整流程图，全班交上来的东西几乎一模一样，问任何一个人“为什么要这么画”，很少有人能讲清。原因：图形化编程的复制成本太低，拖拽符号比敲代码省力，学生直接照抄，没有经历自己纠错的过程。解决：我把验证用例作为强制要求，每个算法至少带三组测试数据并截图输出结果；再规定流程图里每个选择框和循环退出条件旁边必须手写一句注释，说明这个判断在做什么。这一步能有效逼着学生把“画对了”变成“想明白了”。

6. 用 RAPTOR 验收学习成果：从画对流程图到改对边界条件

6.1 用“单步执行”验证每一步逻辑

RAPTOR 图形界面里有一个逐步执行按钮，每次只走一个符号，同时能看到变量区的值实时变化。我在验收学生作业时，要求他们必须把单步执行的过程录下来或者口头讲一遍，重点讲清楚循环进行到第几轮、此刻i和sum分别是多少。这个方法比只看最终输出有效得多，因为很多学生最终结果对了，但中间逻辑是歪打正着。

具体操作上，我会给一个固定的“验算模板”：输入n=5，单步跟踪累加程序，要求学生在i=3这一轮暂停，说出当前的sum值。正确情况是前两轮加完1+2=3，第三轮执行完应为 6。如果学生对不上这个数，说明他的计数变量或累加次序有偏差，这时直接看流程图箭头的走向就能定位问题。

6.2 一套可复制的验收清单

结合前面所有案例，我总结出一份验收清单，适用于大多数 RAPTOR 入门练习：

这套清单的价值在于把“程序跑出结果”作为最低要求，把“每一步都能解释”作为真正标准。我自己带训练时，最常说的话是：RAPTOR 里跑对了不是本事，把同样逻辑移植到 C 或 Java 里还跑对，才算把程序设计实践落了地。后来我要求学生在交作业时附上自己在命令行里跑rapid.exe /b的截图，翻车率明显下降，因为没法再用图形界面的“手工输入 + 肉眼比对”糊弄边界条件了。希望这套做法能帮你在用 RAPTOR 教或学的路上少走几段弯路。

本文还有配套的精品资源，点击获取