为什么提示词这么重要前两篇文章发布后收到不少读者反馈说为什么同样的需求描述你生成的效果比我好那么多。我回头看了一下大家发给我的需求描述发现问题出在提示词上——要么太模糊做个好看的网站要么一次塞太多做一个完整的电商系统包含商品管理、购物车、支付、订单、后台…AI 根本不知道从哪开始。这其实不是 MonkeyCode 独有的问题是所有 AI 编程工具的通病。但 MonkeyCode 的特殊性在于它面向的用户群体更广——很多使用者不是专业开发者对怎么跟AI说话这件事没有经验。所以这一篇我专门记录自己在使用 MonkeyCode 过程中摸索出来的提示词技巧。不是理论教程就是实际使用中反复试错后的经验总结。提示词的五要素我先说一个自己在使用中总结的结构然后逐条展开。一个靠谱的提示词最好包含这五个要素背景、目标、要求、约束、参考。不需要每次五个都写满但心里要有这个框架。背景你是谁、用在什么场景。比如我是一个老师想做一个课堂随机点名工具。这一句话能让 AI 理解你的使用场景生成的代码会更贴合实际需求。目标你想要做什么。这是最核心的部分。比如做一个网页应用能导入学生名单随机抽人支持排除已点过名的。要求具体功能点。比如支持手动导入名单粘贴文本即可、有开始和暂停按钮、抽中的人名字会大字显示在屏幕中央。约束不要什么。比如不要用框架纯HTML就行、不需要后端数据保存在浏览器本地。参考有类似的参考对象就说出来。比如界面参考苹果官网的简洁风格主色调用蓝色。这五个要素不是模板表格是你描述需求时自然包含的信息。你不需要写背景xxx 目标xxx这样的格式但描述的时候这五个维度的信息最好都有。三个实战案例光说理论没用下面用三个我在 MonkeyCode 上实际做过的需求来演示。案例一倒计时页面反面写法我最初的需求描述做一个倒计时页面结果AI 给了我一个最朴素的倒计时——黑底白字没有标题没有样式只有数字在跳。能用但完全不是我想要的。改进写法帮我做一个新年倒计时页面。要求页面上显示距离新年还有多少天多少小时多少分多少秒背景用深色渐变中间有大字标题新年倒计时底部加一个简单的烟花动画效果。不要用外部依赖纯HTML和CSS和JS就行。结果生成的页面有渐变背景有大字标题倒计时逻辑正确烟花动画用 Canvas 实现。整体完成度从勉强能用变成了可以直接用。差别在哪第一次只给了目标没有要求、约束和参考。第二次把具体功能点、视觉风格、技术约束都说清楚了AI 就知道该往哪个方向做。案例二数据统计工具反面写法帮我做一个CSV数据分析工具结果AI 生成了一个能上传 CSV 文件、显示表格的工具。功能有了但很基础没有统计图表没有筛选功能。改进写法我是做运营的需要一个CSV数据分析小工具。功能1. 上传CSV文件后显示前10行预览2. 自动统计每列的数据类型、空值比例、唯一值数量3. 数值列显示最大值最小值平均值4. 有一个下拉框可以选择列选中后画该列的分布柱状图。界面要简洁数据不要上传到服务器全部在浏览器本地处理。结果生成的工具包含数据预览、统计摘要、分布图表三个模块界面布局合理所有处理在本地完成。基本一步到位。差别在哪数据分析工具太宽泛AI 不知道你要分析什么。改进版把使用场景运营人员、具体功能点四个明确功能、技术约束本地处理都说了AI 就能精准执行。案例三迭代修改这个案例不是说初始提示词而是说生成第一版之后怎么追加修改。假设第一版生成后你觉得统计摘要的表格太宽了在小屏幕上溢出。反面写法表格太宽了结果AI 可能会大幅重构表格结构甚至删掉一些列来适应宽度。改是改了但可能改过头。改进写法统计摘要的表格在小屏幕上会横向溢出请改成响应式布局窄屏幕下表格可以横向滚动不要删掉任何列。结果AI 加了 overflow-x: auto 和滚动容器保留了所有列问题解决。经验修改指令要说清楚两件事——具体哪里有问题、你期望的结果是什么。只说问题不说期望AI 会用自己的判断来修但它的判断不一定符合你的想法。分步迭代最重要的技巧如果只能记住这一篇里的一个技巧那就是不要一次性描述一个完整项目要分步骤来。举个例子你想做一个待办清单应用。包含增删改查、分类标签、优先级、到期提醒、数据统计看板。一口气全说出来AI 大概率会生成一个结构混乱、逻辑不完整的半成品。正确的做法是分几步走第一步做一个待办清单的网页能添加任务、标记完成、删除任务。界面简洁左边任务列表右边输入框。等这步生成完成、预览确认基本没问题后再追加第二步给每个任务加一个优先级标签高中低三档用不同颜色区分。然后再第三步加一个分类功能任务可以归入不同分类。每一步都等上一步确认OK了再追加AI 是基于已有代码继续修改的每一步的改动范围可控出问题的概率低很多。这个方法听起来慢实际上比一次性生成→发现各种问题→反复大改快得多。我做过对比同一个待办应用一次性描述全部需求跑了三轮还没跑通分步迭代两轮就基本成型了。不同模型对提示词的口味差异上一篇聊了不同模型的特点这里补充一点不同模型对提示词的敏感度不一样。GLM对中文口语化描述的容忍度最高。你写帮我搞一个那种可以滑动的图片轮播它能理解。但如果你能写得更具体做一个左右滑动的图片轮播组件支持自动播放和手动切换效果会更好。Qwen对中文需求的理解最准但也最容易理解过度——你没说但它觉得需要的它会主动加。好处是细节考虑周到坏处是可能加了你不想要的东西。用 Qwen 时约束要写清楚不要加xx功能。DeepSeek速度快但对模糊描述的容错率低。如果提示词写得不具体DeepSeek 容易跑偏方向。用它的时候最好把功能点一条条列清楚。Kimi在多文件项目中对提示词的处理最好。你描述一个涉及多个文件的需求它能合理拆分文件结构和引用关系。但简单任务用它有点浪费。常用提示词模板整理一些我在 MonkeyCode 上反复使用的句式模板新手可以直接套初始需求帮我做一个[功能描述]的[网页/应用/工具]界面参考[某个网站/某种风格]支持[功能1]、[功能2]、[功能3]不要用[某种技术/框架]数据保存在[本地/服务器]迭代修改把[某个部分]改成[某种样式/效果]加一个[功能描述][某个功能]有bug具体表现是[现象]请修复优化[某个部分]的[性能/样式/逻辑]反馈修正不要[某个功能/效果]去掉[某个部分]太[大/小/挤/空]请调整整体方向不对我想要的是[重新描述]三个最常见的坑最后总结三个新手最容易踩的坑坑一描述太模糊。做个好看的网站——好看的标准是什么什么类型的网站AI 不知道只能猜猜中概率很低。解法把好看具象化给参考、给配色方向、给布局结构。坑二一次要太多。恨不得一句话描述完整个系统。AI 一次处理太多功能点每个都浅尝辄止最后什么都不精。解法分步骤迭代每步聚焦一个功能模块。坑三不满意但不反馈。生成后觉得不对劲但又不说直接重新开始。浪费了之前的上下文。解法直接告诉 AI 哪里不对、你想要什么基于已有代码修改比重来快得多。下一篇预告这一篇讲的是怎么描述需求下一篇准备进入实战场景——前端页面开发实战从原型到上线的完整流程记录。会记录一个具体的前端项目从需求拆解、分步生成、调试修改到最终上线的全过程。系列目录 MonkeyCode使用手记 · 系列目录索引MonkeyCode使用手记 · 系列目录本页面是「MonkeyCode使用手记」系列的索引页随文章更新同步维护。 系列持续更新中记录长期使用 MonkeyCode 的真实体验、踩坑经验和版本跟踪。系列文章序号标题状态链接一初次相遇——打开浏览器就能写代码✅ 已发布查看上一篇MonkeyCode使用手记二模型横评——GLM、Kimi、Qwen、DeepSeek 到底选哪个
