AI编程实战：用Cursor和Turtle提示词画出一匹能跑的马

前几天朋友家孩子问我：“叔叔，你不是写代码很厉害吗？帮我画一匹马。”我第一反应是打开编辑器，打算用程序画一匹像样的马。结果愣是憋了半天——写接口、调性能我都熟，但让代码画出一匹能看顺眼的马，远比我想象中难。后来我换了个思路，把整个任务交给AI编程工具，用AI辅助创作的方式从需求描述到代码生成、从图形迭代到动画演示，前后不到一小时就做出了一匹能跑起来、还能交互的小马。这个项目让我对“AI编程到底能帮我们做到什么程度”有了非常具体的认知，所以今天把整个过程拆开聊一聊。

这个项目适合几类人：想入门AI编程但不知道从什么练手开始的人、希望用AI辅助创作完成图形类小项目的人，以及那些跟“画图”天生八字不合但又要交差的人。我会把工具选型、提示词设计、代码迭代、踩坑排错的完整链路都写出来，所有操作步骤和代码都能直接复现。

1. 为什么是“画马”：一次被AI重构的创作流程

1.1 传统代码画马的三重门槛

先说问题在哪。用代码画一匹马，最直接的方式是Turtle、Matplotlib、p5.js或者SVG，但这些方案有一个共同点：你需要自己用几何元素去拼一匹马的形状。表面上是写代码，实际上是在做三件事：几何建模、坐标计算、审美表达。

几何建模是第一个门槛。马不是圆形也不是矩形，它是由躯干、脖子、头部、四条腿、尾巴、鬃毛组成的复合体。用圆形画身体、用线条画腿，画出来的是儿童简笔画；想画出真实的肌肉走向和奔跑姿态，就得引入贝塞尔曲线、样条插值这类工具。

第二个门槛是坐标计算。我早期用Turtle画过一个“四不像”，表面上看是四条腿和躯干都画了，但腿的位置和身体比例完全不对，看起来像一只被压扁的奇怪动物。问题出在坐标全是拍脑袋写的，没有经过比例换算。

第三个门槛是审美判断。程序能精确执行你的指令，但如果你描述的马本身就不协调，跑出来的图自然也不协调。传统流程里，你需要不断地改参数、刷新预览、再改参数，循环往复，非常消磨耐心。

1.2 核心难点：贝塞尔曲线与坐标控制

如果你用过绘图类编辑器，对贝塞尔曲线肯定不陌生。在代码画马的场景里，它是画“非规则曲线”的基础工具，马的背部弧线、脖子弯曲、尾巴的飘动感，基本都是靠贝塞尔曲线来逼近的。

一条三次贝塞尔曲线需要四个控制点：起点、终点、两个弯曲控制点。要画出马的脊背，你需要先确定背部的起点和终点对应的坐标，再人为设定两个控制点来制造“拱起”的弧度。问题就在这里：控制点差一点点，曲线形状就完全不同。你脑子里的“马的脊背弧度”和代码里坐标对应的“马的脊背弧度”之间，隔着大量试错。在没有可视化调试界面的命令行环境里，这种试错极其痛苦。

1.3 AI介入后创作流程如何重构

AI辅助创作带来的改变，不是帮你把代码写完了，而是把“用代码画马”变成了“用语言描述我要一匹什么样的马”。整个流程变成这样：

核心变化是：你从“亲自执行的画师”变成了“提出需求、验收结果的产品经理”。这并不意味着不需要技术功底——你仍然需要理解坐标、曲线、动画原理，才能判断AI生成的结果是否可靠。但它确实大幅降低了从想法到成品的门槛。

2. 技术选型：三条画马路线与两款AI编程工具的实际对比

2.1 三条画马路线：纯代码、AI绘图、AI编程

做这个项目时我梳理了一下，画一匹马其实有三条完全不同的技术路线：

我这次走的是路线C，同时用路线B作为辅助——先用AI绘画生成一张马的参考图，再去仔细看画面的结构细节，比如马的脖子怎么连接身体、四条腿的分布比例等。这条路线的优势在于，你得到的不是一个死图片，而是一个可以继续扩展的“活程序”。

2.2 为什么Cursor是这个项目的主力

AI编程工具现在很多，这个项目里我以Cursor为主。原因有三点。

第一，Cursor的对话式生成非常适合从零开始的探索型项目。你不需要先把项目结构搭好，只要在对话框里说清楚需求，它会直接帮你生成一个完整可运行的文件。对画马这种单文件项目来说，这种工作流非常顺畅。

第二，Cursor能感知当前打开文件的上下文。如果生成的代码有bug，你不用把报错信息复制来复制去，直接让它“看看当前文件哪里有问题”，它会自动定位问题并给出修改方案，省掉很多来回操作。

第三，它的内联编辑体验很好。AI改完代码后，你可以看到具体的diff，决定接受还是拒绝哪部分改动。这点在“审美细节”的迭代上尤其重要——AI有时候会把马的尾巴改成无法理解的形状，这时候你可以只拒绝改动尾巴的那一行，其他保留。

2.3 PyCharm里的AI辅助插件：何时选它

如果你的主力IDE是PyCharm，也不想来回切换编辑器，那有两条路：装AI辅助编程插件，或者直接用JetBrains AI Assistant。目前PyCharm里比较普及的AI辅助插件主要有GitHub Copilot、通义灵码、CodeGeeX等。

我的体验是，插件模式更适合“增量开发”场景：你手上已经有一个PyCharm工程，想在原有代码里增加画马函数、优化某个参数，这时候插件能在你写代码时实时补全，非常顺手。但如果你是从零开始探索“马怎么画才像”，插件模式不如Cursor的对话式生成来得直接。因为插件的核心是“补全你的代码”，而不是“理解你的项目目标”。

不过有一个补充场景：当你需要调试画马程序的数学计算时，PyCharm的调试器比Cursor强得多。设置断点、查看变量值、逐步执行，这些功能对排查坐标计算类的bug特别有用。我实际做法是：用Cursor生成和迭代代码，遇到需要精调的数学逻辑，把文件放进PyCharm里跑调试器。

2.4 用AI绘图给编程“打样”

这条经验是意外收获。最开始我让AI直接生成画马的代码，但AI对“马的脖子应该多长”“腿的关节应该在哪个位置”这些视觉细节的理解是模糊的。于是我换了个思路：先让AI绘画工具生成一匹侧身奔跑的马的照片或插画，再用这张图作为编程的目标参考。

具体做法是，把AI绘画生成的结果保存下来，打开后自己观察马的轮廓构成：身体是椭圆形，脖子从身体前上方斜伸出来，头部位于脖子顶端，四条腿分别从身体前后两侧向下延伸。这些观察结果再变成提示词，告诉编程AI“身体用横置椭圆，头部在身体右上方的椭圆，四条腿分别从这些坐标范围向下画”。参考图能把抽象的“像一匹马”变成具体的“几何元素如何组合”，这对AI编程的成图质量提升非常大。

3. 把“马”翻译成代码：提示词设计的完整思路与三版实战

3.1 提示词不是一句话，是需求文档

很多人用AI编程时，提示词习惯性只写“画一匹马”，然后抱怨AI写出来的东西没法看。其实问题不在AI，在于你给的需求只有一句话，信息量完全不够。好的提示词不是一句话，是一份微型需求文档，至少包含五个要素：角色、任务、输入、约束、验收标准。

• 角色：告诉AI它应该用什么身份来完成任务。比如“你是一名精通Python Turtle绘图的图形程序员”。
• 任务：说清楚要做什么，尽量具体。“写一个Python Turtle程序，画一匹侧面的马”。
• 输入：提供必要的背景信息。比如有没有参考图、马的姿态是站还是跑。
• 约束：限定实现范围。“只用Turtle库，不要用其他依赖”“画面尺寸为800x600”。
• 验收标准：让AI知道什么样子算完成。“程序运行后窗口内应显示一匹包含身体、头、四条腿、尾巴和鬃毛的马”。

这里有个逻辑：AI编程工具生成代码时找不到“马”的概念，它找到的是任务描述里隐含的几何元素和约束条件。你把验收标准描述得越清晰，它生成的代码就越接近你的目标。

3.2 三版提示词的迭代对比

我在这个项目里用过三版提示词，效果差异非常明显。

第一版提示词：

用Python画一匹马。

AI生成的代码只有十几行，用了圆形和线条组成一个极其抽象的形状。运行后窗口里出现的是一个三角形加四条线的“奇怪生物”。问题出在任务太泛，没有任何几何和结构约束，AI只能按它训练数据里的平均理解来生成，但“平均理解”通常等于“什么都差点”。

第二版提示词：

用Python Turtle画一匹侧面的马，包含身体、头部、四条腿、尾巴、鬃毛。

这版好一些，AI开始注意结构要素，但身体比例仍然不对。生成的马腿特别短，身体像一个被拉长的椭圆，头部甚至跑到身体里面去了。因为虽然说了“包含什么”，但没说明“这些部件分别画在哪、比例大概是怎样的”。

第三版提示词：

你是一名精通Python Turtle绘图的图形程序员。请用Python编写一个Turtle程序，在800x600的画布上画一匹侧面的马。马的躯干用横置的大椭圆表示，圆心在(-10, 0)，长轴长度约95，短轴长度约55；头部用一个小椭圆表示，中心在(80, 75)，长轴35，短轴25；脖子用一条粗线连接躯干右上方和头部；四条腿分别从躯干下方不同x坐标位置向下画直线，每条腿长65，腿的位置分别在x=-70、-45、35、65；尾巴从躯干左侧末端向上弯曲的弧线，鬃毛沿头部后侧用弧线表示。运行后应能看到一匹包含这些元素、结构清晰、比例协调的马。

这版提示词把位置、比例、绘制方式都写清楚了。AI生成的代码基本可以直接运行，而且画出来的马一眼就能认出来。你不需要懂得所有坐标怎么算，但你要能描述清楚大概的分布——这个能力是AI辅助创作时代最值得练的。

三版提示词对比如下表：

3.3 让AI“先想后写”的三个技巧

在提示词中加入“先思考再回答”的要求，效果会明显改善。原因很简单：AI跳过分析步骤直接写代码时，生成的代码往往缺乏整体规划；如果先让它梳理思路，它会自己检查需求是否完整，生成更可靠的代码。

三个技巧很实用：

第一个技巧是“要求AI先输出设计方案，再输出代码”。提示词里加一句“先简要说明你的绘制方案，再输出完整代码”。这一步会迫使AI先规划马的结构组合。

第二个技巧是“给AI限定实现范围”。明确说“不要引入额外的库，不要使用机器学习生成图片”，防止AI跑偏成调用一个本地不存在的模型库。

第三个技巧是“让AI自己检查遗漏”。提示词结尾加上“生成代码前检查是否覆盖了任务要求的全部元素”。相当于让AI在给自己代码做Review，很多缺元素、缺函数的问题在这一步就被消灭了。

3.4 提示词完成度自查清单

经过多次调试，我总结了一个提示词自查清单，每次让AI编程前都过一遍：

• 角色的限定是否明确
• 任务目标是否具体到“产出物”级别
• 几何元素的相对位置和比例有没有描述
• 是否写明颜色、尺寸、窗口等细节约束
• 是否要求“先方案后代码”
• 有没有给出验收标准
• 是否限定依赖库范围

这个清单实际上就是把“画一匹马”这种抽象需求翻译成AI能执行的具体指令的过程。提示词的质量直接决定生成代码的质量，AI编程时代最重要的能力之一就是“把需求描述到位”。

4. 从提示词到可运行程序：AI辅助创作的完整实操记录

4.1 第一版：别管美不美，先让它跑起来

拿到第三版提示词后，Cursor生成的代码是一个完整的Turtle程序。我直接运行，窗口里确实出现了一匹“马”：有褐色填充的躯干、头部、四条向下延伸的腿，还有尾巴和鬃毛的弧线。虽然细节粗糙，但结构是齐全的。

这一步我建议的心态是：第一版能跑就行，不要期待一次成型。AI编程的迭代模式决定了它最适合“先跑通，再优化”的策略。如果第一版能运行，说明提示词中的基本要素AI都理解了；接下来就是一轮轮反馈优化。

4.2 迭代：从“能看出是马”到“像一匹马”

第一版的问题很明显：脖子是用一段粗线硬连的，看起来像一块突兀的填充物；尾巴的弧线方向不对，挂在身体上像一条下垂的绳子；四条腿是均匀分布的垂直直线，没有关节，也没有蹄子，显得非常僵硬。

我针对这些问题逐条给AI反馈，每轮只说一个问题：

• 第一轮：“脖子那边看起来像一根粗棍子，能不能用渐变的曲线连接，让脖子和躯干过渡更自然？”
• 第二轮：“尾巴的弧线方向反了，应该从尾部向后上方飘，不是向下垂。”
• 第三轮：“腿不要画成均匀的直线，前腿和后腿之间要有距离差，腿末端加一点小分叉表示蹄子。”

每轮反馈Focous一个问题，AI改完继续运行，再检查，再反馈。三轮下来，整体画面已经有了“马”的形态，而且比例协调了很多。这个过程中我完全不用亲自去计算坐标，只负责用自然语言表达“哪里不对劲”。

4.3 进阶：让马跑起来——动画与交互

代码画马的乐趣在于它可以动起来。Turtle实现动画的核心机制是“擦除重绘”，每一帧先清屏，再把马画到新位置。为了让马有“跑动”的感觉，我让AI加入一个leg_offset参数，在每个绘制循环里交替改变四条腿的偏移量，营造出迈步的效果。

典型动画代码如下：

python复制import turtle

t = turtle.Turtle()
t.speed(2)

def draw_horse(x, leg_offset=0):
    t.clear()
    t.penup()
    # 身体位置随x移动
    # 腿的y坐标加上leg_offset
    # 填充颜色与轮廓
    t.goto(x, 0)
    # ... 绘制身体的代码
    pass

# 动画循环
for i in range(60):
    body_x = -250 + i * 8
    leg_offset = 15 if i % 2 == 0 else -15
    draw_horse(body_x, leg_offset)
    turtle.update()
    turtle.ontimer(lambda: None, 50)

实际实现时不需要你手写每一帧的绘制逻辑，你只需要告诉AI“做成奔跑动画，腿要交替摆动，身体向右移动”，它会自动把对应的代码补全。但你要理解动画的底层逻辑：Turtle默认是每画一步就刷新一次屏幕，如果不批量更新，动画会非常卡顿。这个坑在下一章详细说。

4.4 可以直接运行的最终版代码

下面是经过三轮迭代后的最终版代码。这一步是给你一个完整的参考，你不需要把这个代码背下来，重点看它如何把文本提示变成具体绘图指令。

python复制import turtle
import math

t = turtle.Turtle()
t.speed(8)
t.pensize(4)
t.pencolor("#3e2f1c")
t.fillcolor("#b07b45")

screen = turtle.Screen()
screen.bgcolor("#eaf6f6")

def ellipse(cx, cy, a, b):
    """以(cx, cy)为中心，画一个长轴a、短轴b的椭圆"""
    t.penup()
    t.goto(cx + a, cy)
    t.pendown()
    t.begin_fill()
    step = 6
    for deg in range(0, 360, step):
        rad = math.radians(deg)
        x = cx + a * math.cos(rad)
        y = cy + b * math.sin(rad)
        t.goto(x, y)
    t.end_fill()

# 身体
ellipse(-10, 0, 95, 55)

# 头（右上方的小椭圆）
ellipse(80, 75, 35, 25)

# 脖子：连接身体和头
t.penup()
t.goto(15, 35)
t.pendown()
t.pensize(18)
t.pencolor("#b07b45")
t.goto(62, 58)
t.pensize(4)
t.pencolor("#3e2f1c")

# 四条腿
for x in (-70, -45, 35, 65):
    t.penup()
    t.goto(x, -30)
    t.pendown()
    t.setheading(-90)
    t.forward(65)

# 尾巴
t.penup()
t.goto(-95, -5)
t.pendown()
t.setheading(20)
t.circle(-55, 80)

# 鬃毛
t.penup()
t.goto(55, 92)
t.pendown()
t.setheading(150)
t.circle(50, 70)

t.hideturtle()
screen.exitonclick()

这段代码在标准Python环境下直接运行，就能看到一个800x600画布，画布上是一匹有身体、头部、脖子、四条腿、尾巴和鬃毛的简笔马。它的填充色是棕色，背景是浅蓝色，这是我在提示词里指定的效果。

5. 画马过程中的踩坑实录：五类高频问题与排查链路

5.1 腿长在身体外面：坐标计算的累计偏差

第一版迭代时出现了一个很典型的bug：四条腿全部跑到身体下方以外去了，看起来像是踩在空气上。原因是AI生成坐标时，腿的x坐标和身体椭圆底部y坐标没有对齐，导致腿从错误的位置开始画。

排查链路是这样的：先看报警代码在哪一行，确认是画腿的循环；再检查循环中每个x值是否落在身体椭圆下方的x范围内；最后发现是腿的起点y坐标-30和椭圆中心y坐标0之间的差没有算对，椭圆短轴是55，底部y值应该是-55左右，而代码在-30就停住了。

修复方式很简单：把腿的起点y坐标改成-45，让腿从贴近椭圆的底部开始。这个问题提醒我，AI编程生成的代码在几何计算上容易出现“看着对、实际差一点”的问题，运行后用视觉检查几乎都能发现这类坐标偏差。

5.2 动画卡成PPT：Turtle刷新机制

第二个让我头疼的问题是动画卡顿。让马跑起来后，画面一帧一帧地跳，跑起来像PPT翻页，完全没有流畅感。

根源在于Turtle的刷新机制。Turtle默认在执行forward、goto等绘图操作时，每一步都立即刷新窗口。动画循环里每帧有几十上百个绘图操作，每一步都刷新一次，自然卡得不行。

解决方案是关闭自动刷新，手动控制更新时机：

python复制turtle.tracer(0)   # 关闭自动刷新
# ... 动画循环里的所有绘制代码 ...
turtle.update()    # 每帧结束后手动刷新一次

把这个逻辑加进去之后，动画流畅度提升非常明显。这个坑在普通的静态绘图中不会暴露，只有做动画时才会遇到，属于典型的“不做不知道”类问题。

5.3 画出来的马没有尾巴：提示词覆盖率问题

有一次我让AI调整马的姿态，生成的新代码里居然没有尾巴了。我当时以为是代码生成错误，从头检查了一遍，发现AI没画尾巴的原因是我新加的提示词里写了“调整腿部姿态”，但忘了提“保留原有尾巴和鬃毛”，AI误以为新的需求替代了旧需求。

这个问题本质上是提示词的覆盖率不够。修改需求时，老需求中你已经满足的部分也要明确保留。AI不会像人类一样“默认你能接受的东西就不动”，它会严格按描述执行，没说的部分就可能被丢弃。

修复方法是，每次提交新提示词时，把需要保留的元素重新列一遍：“在保留之前身体、头、尾巴、鬃毛的基础上，只调整腿的绘制方式。”这个习惯在后来的AI编程里帮我省了很多重复检查的时间。

5.4 AI生成了“看似合理”的报错代码

还有一种情况比上面几种更隐蔽：AI生成的代码看起来很完整，但运行时直接报错，而且报错信息指向一个根本不存在的函数名。

比如有一次AI生成代码里出现了t.reset_angle()，这个函数在Turtle标准库里根本不存在。AI为什么写它？因为训练数据里见过类似的调用，它在补全代码时“脑补”了一个函数。这种问题在小白手里非常容易踩坑，因为他们不愿意质疑AI的输出，直接跑就报错，报错后又不知道怎么改。

我的排查逻辑是：遇到报错，先把报错信息丢给AI，让它解释报错来源；如果AI解释含糊，再用查看器或官方文档确认该函数是否存在。AI编程的本质仍然是对已有知识的二次组合，不是凭空创造新库，任何它生成的库调用都应该能在官方文档里找到对应项。

5.5 同一段代码在不同电脑上显示不一样

最后一个是环境差异问题。我把项目发给朋友跑，他在自己电脑上运行时发现窗口只有一半，马的画面整体偏到窗口外。

原因很简单：我在提示词里指定了800x600画布，但朋友电脑的屏幕分辨率缩放比例是150%，窗口被系统放大后，画面超出可视区域。Turtle程序里可以用以下方式让窗口大小更安全：

python复制screen = turtle.Screen()
screen.setup(width=800, height=600, startx=0, starty=0)

另外，不同操作系统对Turtle的默认背景色和窗口标题处理也有细微差异。建议在提示词里显式指定窗口尺寸和背景色，而不是依赖默认值。

写在最后：AI编程画马教会我的三件事

这个项目做完后，我对AI编程和AI辅助创作的实际工作方式有了新的判断。

第一，AI编程工具真正提升效率的场景，恰恰是“从抽象到具体”的翻译过程。你不需要精确地写每一行坐标计算，但你必须能清晰描述“我要什么、大概在什么位置、什么比例”，AI才能真正帮你省时间。提示词写得好，AI帮你干活；提示词写得糙，AI帮你挖坑。

第二，AI生成的代码不一定对，它也会写错函数、算错坐标、遗漏需求。这时候判断力比生成力更重要。我不会画马，但我能一眼看出“这个腿的位置不对”，这份基于直觉的判断力来自长期看代码、看图形的积累，AI短时间内替代不了。

第三，把AI绘画和AI编程组合起来用，是一个很高效的工作流。先用AI绘画快速确认视觉目标，再用AI编程把这个目标变成可交互的程序。AI绘画负责“长什么样”，AI编程负责“怎么实现”，两条AI技术路线各管一段，组合起来能完成单靠一个工具很难搞定的项目。

最后再分享一个小技巧：做这类图形项目时，建议把每次有效的提示词保存下来，放到一个文档里命名成“prompts.md”。下次想画别的动物、做类似动画时，直接改需求描述里的主体词和比例参数就行，不用从零开始。AI辅助创作时代，会积累提示词，就等于会积累项目经验。