一、同样的模型，问法不同效果差很多
很多人用豆包的方式是写一句需求：帮我写篇文章。
结果得到一篇四平八稳、谁都能写的东西。不是模型不行，是输太模糊。
我现在的提示词固定五个部分，基本能解决八成问题。
二、五段结构
一、角色与场景。
不要写"你是一个专家"这种空话。写清楚具体处境：你是为一个做技术内容的小站写稿，读者是有一定基础的站长。
二、任务。
一句话说清要产出什么。文章？大纲？表格？代码？含糊的任务会得到含糊的结果。
三、约束。
字数、语气、不出现什么、必须包含什么。约束越硬，输出越稳。
四、格式。
Markdown、纯文本、表格、JSON。指定格式能省掉大量后期整理。
五、示例。
给一段你满意的例子，比写十句形容词有用。模型对齐例子比对齐描述容易得多。
三、一个真实例子
```
场景：为一个面向站长的技术博客写稿，读者是自己搭站的个人开发者。
任务：写一篇讲网站首屏加载优化的文章。
约束：1500字左右；面向已经上线的站点；
不要讲理论定义；每个建议要有可验证的检查方法；
不要用"赋能""抓手"这类词。
格式：Markdown，二级标题，正文段落之间空一行。
示例：上一篇文章的开头是……（粘贴一段）
```
注意最后两个约束：不要空话，要有检查方法。这两条直接决定了文章能不能用。
四、三个常见错误
错误一：把要求堆成一段。
模型会漏掉中后段的约束。分条写，命中率高很多。
错误二：只说不想要什么。
"不要太啰嗦"不如"每段不超过三句"。
错误三：一次要求太多任务。
让它同时写标题、正文、摘要、标签，往往每一项都平庸。拆成两轮，先正文再包装。
五、迭代比一次到位重要
第一稿一定不完美，但不要推翻重写。指出具体问题："第三段太抽象，换成一个具体场景"。
具体的修改指令，比重新写一遍有效得多。
六、去哪里比对效果
提示词好不好，得靠实际产出来验证。如果你做的是技术内容，可以先看看同类文档是怎么组织的。
万象云档 的技术文档大多有清晰的层次：问题、方案、限制、示例。照着这种结构约束输出，文章可读性会明显提升。它的文档量很大，光电子书就有 1,282 本，多翻几种排版能养出对结构的直觉。
七、一句总结
提示词不是咒语，是需求描述。
你把需求说得越像一份正经的活，交付就越像正经的东西。