06｜核心：如何打造C语言自动判题系统里的核心提示词？
一、课程简介
实战案例：一个真实的 C 语言自动判题系统 开发历程，来自一位老师的真实需求——用 AI 让批改作业的工作效率提升 10 倍。
核心洞见：在真实项目里，提示词需要和应用里的其他程序紧密配合，需要更"靠谱"，而非更复杂或更智能。
二、客户需求分析
▸ 场景与痛点
|
|
|
|---|---|
| 现状 |
|
| 痛点 |
|
| 需求 |
|
| 目标 |
|
▸ 两个核心技术问题
-
自动化运行：C 程序通过命令行运行，可接收多个输入参数，如何自动化？ -
智能判断：学生输出和老师答案可能有文字表述差别，不能用完全相等逻辑，如何做到智能化判断？
三、系统设计：明确哪些用 AI，哪些用传统程序
▸ 核心设计思路
★不要试图完全实现一个流程的 AI 自动化，相反，将 AI 设计嵌入到原有工作流中会更加顺利。
▸ 系统流程概览
┌─────────────────────────────────────────────────┐
│ C 语言自动判题系统 │
├────────────────────┬────────────────────────────┤
│ 题库系统 │ 判题系统 │
│ │ │
│ ① 题干 → AI生成答案│ ① 学生作业 → AI拆解参数 │
│ ② 答案 → AI生成判例│ ② 命令行运行 → 获取输出 │
│ ③ 答案 → AI转命令行│ ③ AI判题评分 │
│ ④ 命令行编译运行 │ ④ 人工综合评分 │
│ │ │
└────────────────────┴────────────────────────────┘
★备注：C 程序的编译和运行不适合用 AI 替代，采用脚本直接编译运行；而题干→答案、答案→判例、答案→命令行、作业拆解、结果判分这 5 个节点可以用 AI 实现。
四、6 个核心提示词详解
整个系统一共设计了 5 个核心提示词（分别对应 5 个 AI 节点），以下是完整详解：
1️⃣ QUESTION_TO_ANSWER（题干生成答案）
职责：根据题干自动生成标准答案
要求：可运行、无 bug | 风险：答案生成可能存在 bug
提示词模板：
根据我给的题干和输出例子，写出C语言程序，
题干如下：
"""
{题干}
"""
输出例子如下：
"""
{例子}
"""
注意C语言程序输出要有明确的分隔符，以便后续我提取，格式如下：
$$$start$$$
C语言程序
$$$end$$$
★大模型正常情况下会在输出的 C 语言程序前后加上
$$$start$$$和$$$end$$$，便于后续程序提取。
2️⃣ ANSWER_TO_TEST_CASE（答案生成判例）
职责：根据题干和答案自动生成程序测试用例
要求：用例全面、准确 | 风险：判例生成可能不如人写得好
★⚠️ 真实项目教训：该功能在实际运行阶段被废弃——AI 给出的判例与人工设计的差别较大，尤其是每个判例的分值权重评估不准。最终方案改为参考 AI 生成的判例，大部分用人工修正。
3️⃣ ANSWER_TO_COMMAND_LINE（答案生成命令行）
职责：把输入变量的输入方式由键盘输入改为命令行接收输入（scanf → argv）
要求：参数识别准确、不改原代码逻辑 | 风险：注意遗漏参数
提示词模板：
我在做一个判题系统，下面是答案的C语言程序，
要求把输入变量的输入方式有键盘输入改为命令行接收输入
...
下面是答案C语言程序:
"""
{程序}
"""
注意C语言程序输出要有明确的分隔符，以便后续我提取，例如：
$$$start$$$
C语言程序
$$$end$$$
4️⃣ DECOMPOSE_HOMEWORK（作业拆解）
职责：只让学生作业总结程序中的参数（参数名、顺序、类型），保留学生的错误代码不动
要求：参数识别准确、顺序一致 | 风险：注意和答案的参数顺序一致
★💡 重要经验：在逻辑严谨的场景下，多用大模型的总结能力；在逻辑宽松的场景下，才适合用大模型的生成能力。
提示词关键部分：
输出所有的参数名字和每个参数的argv,以及变量类型就行，下面例子的x,y,z就是学生作业里的输入参数变量示示子
"x": "argv[1],int",
"y": "argv[2],string"
"z": "argv[3],float"
输出是一个json串即可，不要任何额外说明和代码。
★为什么不用 AI 直接转命令行？因为大模型总会试图修改学生作业里的错误代码，而判题需要保留原始错误。妥协方案：只让 AI 总结参数格式，程序单独替换参数。
★🎯 省 token 技巧：原始版本包含题干和标准答案，最终发现只用学生答案效果也很好，去掉题干和答案后节省 50% token 消耗。
5️⃣ EVALUATE_RESULT（结果判分）
职责：对比 AI 输出的答案和学生作业，判断每个用例的结果
要求：只要变量输出值一致就要判对 | 风险：可能存在误判
★🔥 这是修改次数最多、印象最深的核心提示词！
最终版（简洁、靠谱）：
你的角色是一个判断学生作业的系统，你根据下面数据直接判断结果，不要写程序，
答案和学生作业输出的结果：
"""
{答案输出}
"""
...
判断原则是逐个用例里面进行，按用例1，用例2这样的顺序分别提取数据比对....
输出要求包含的格式如下：
"用例1" :
"输入参数": "yy"
"结果" : "正确" 或 "错误"
"错误说明" : "xxx"
输出用json格式，只要json输出不要任何额外分析说明,不要任何说明，我只要json格式的结果就行
初始版（有幻觉问题）：
你的角色是一个判断学生作业的系统，我给你提供题目的题干，答案，答案输出和学生作业输出...
题干...
答案和学生作业输出的结果：
...
★❌ 初始版的问题：大模型总是以为要让它按题干写出代码或按作业输出写出代码，加入"不要按题干输出代码"等限定后仍无法完全避免幻觉。
✅ 最终版解决方案：只让大模型处理答案输出和作业输出的比对，把更多提示词内容用来限定输出比对的规则，反而效果更好。
五、提示词调教四大挑战
挑战 1：初步实现——提示词模板化
提示词最终要嵌入代码中，需要考虑兼容不同的输入内容，所以与其说是提示词，不如说是提示词模板。
技巧：用分隔符标注内容
"""
{题干}
"""
大模型输出也要设计分隔符，便于后续程序提取：
$$$start$$$
C语言程序
$$$end$$$
挑战 2：多平台适配——每个大模型都不一样
一份提示词在不同大模型上运行效果可能不同！作者的开发流程：
GPT 调试提示词（开发调试阶段）
↓ 效果满意后
讯飞大模型接口编程实现（代码上线）
⚠️ 例如在 GPT 里分隔符是 $$$start$$$，在讯飞里变成了 $start$，需要单独调整提示词才让大模型"听话"。
解决办法：使用不易混淆的分隔符，如 __start__ 和 __end__。
挑战 3：成本考量——token 消耗不能忽视
-
一个学生判题消耗几千 token，100 人一次判题消耗 20 万 token -
还需要考虑重复判题的情况 -
平台给的几百万 token 配额，程序运行起来很快就不够用
两个省钱技巧：
-
优化提示词 — DECOMPOSE_HOMEWORK 去掉题干和答案，节省 50% token 消耗 -
缓存策略 — 学生作业未修改时，命令行版本固定，不必重复调用大模型
挑战 4：幻觉问题——"题干幻觉"
EVALUATE_RESULT 第一版提供题干+答案+答案输出+学生作业输出，大模型总是以为要让它写代码。
解决思路：让大模型做的事越少、越专一，幻觉就越少。最终只比对学生输出和答案输出。
六、两个特例处理
特例 1：随机数题目
★有些题目涉及随机数生成（如生成随机整数数组）。解决方案：要求"答案和学生作业使用相同数据"，即先固定随机种子再执行。
特例 2：字符图形输出
★有些题目要求用字符组成金字塔等图形（如
*构成的金字塔）。AI 需要准确判断这类文本形态的图形输出是否正确。
七、核心经验总结
1. 提示词设计原则
-
逻辑严谨场景 → 用大模型的总结能力（可靠） -
逻辑宽松场景 → 用大模型的生成能力（有创造性） -
让大模型做的事越少、越专一 → 幻觉越少
2. AI 应用嵌入工作流
★不要试图完全实现一个流程的 AI 自动化，相反，将 AI 设计嵌入到原有工作流中会更加顺利。
3. 5 个提示词一览
|
|
|
|
|
|
|---|---|---|---|---|
| QUESTION_TO_ANSWER |
|
|
|
|
| ANSWER_TO_TEST_CASE |
|
|
|
|
| ANSWER_TO_COMMAND_LINE |
|
|
|
|
| DECOMPOSE_HOMEWORK |
|
|
|
|
| EVALUATE_RESULT |
|
|
|
|
八、知识点总结（10 条）
-
C 语言自动判题系统的核心需求是提高老师批改作业的效率，通过 AI 实现自动判题功能，效率提升 10 倍 -
设计系统时，需要明确哪些部分可以用 AI 实现（如判题、参数识别），哪些用传统程序实现（如编译运行） -
提示词工程是开发关键，需要定义每个提示词的职责范围、输入输出参数，并预判可能产生的问题 -
初步实现提示词需要考虑兼容不同输入内容：使用分隔符标注内容，设计输出的分隔符便于后续程序处理 -
多平台适配是提示词开发中的挑战，不同大模型可能需要微调甚至重写提示词 -
成本考量是重要问题，需要优化提示词减少 token 消耗，并使用缓存策略避免不必要调用 -
C 语言判题系统的6 个核心提示词：QUESTION_TO_ANSWER、ANSWER_TO_TEST_CASE、ANSWER_TO_COMMAND_LINE、DECOMPOSE_HOMEWORK、EVALUATE_RESULT -
在逻辑严谨的场景下多用大模型的总结能力，逻辑宽松的场景下才适合用生成能力 -
将 AI 设计嵌入到原有工作流中比追求全自动化更加顺利 -
让大模型做的事越少越专一，幻觉就越少——这是整个项目最核心的实战经验
九、思考题
★在 C 语言自动判题系统中，老师提到学生有抄作业的情况，这种情况可以尝试用提示词解决吗？怎么解决？
💡 欢迎在评论区分享你的思路！
★📌 上节回顾：提示词是一切应用的基础——Zero-shot、结构化提示词、Debug 技巧 📌 下节预告：C 语言自动判题系统的用户界面与控制逻辑
★💬 如果觉得有收获，欢迎分享给更多朋友一起学习，也欢迎在评论区交流你的提示词实战经验！