番外篇：每天给AI写10000字小作文后，我学到了什么

哈喽，我是黑棠。

过去一段时间，我做了个“看起来很离谱”的练习：每天给不同模型（Claude Sonnet 4.5、Claude Opus 4.5、Gemini-3-Pro、GPT-5.2）各写一份很长的提示词，然后把输出当作样本，像做实验一样记录差异、找规律、再反推“指令怎么写更稳”。

后来我才发现，“每天10000字”不是重点。
重点是两件事：

1. 把提示词当成一份可验收的规格书（而不是一段“求助语”）。
2. 把输出当成可复现的实验结果（而不是一次性的灵感抽奖）。

我也不是一开始就这么想的。
最早那几天，我写得越长越焦虑：模型偶尔能给我一个“看起来很懂”的回答，但第二天同样的任务它就换个角度开始乱讲；更糟的是，我还会被它那种“语气很笃定”的表达骗过去，直到真正落地时才发现漏洞一堆。

如果你最近半年在招聘网站上搜过就会发现：“Prompt Engineer/提示词工程师”作为独立岗位的存在感确实变弱了。更准确的说法是——它从“岗位名”变成了“能力项”。

一些公开报道与招聘数据趋势也在表达同一个方向：岗位标题未必常见，但“会用AI把事做成”的要求在上升，比如 Indeed 的经济学家在媒体报道里强调“prompt engineering 作为技能有价值，但很难单独成为一个“职位头衔”。另一些行业文章也指出，企业更倾向于把这类能力内化到产品、运营、工程等角色里，而不是为“写提示词”单独设岗。

我把“岗位的变化”总结成一张更贴近现实的映射表，方便你对齐自己的技能定位：

过去的“提示词工程师叙事”	现在更常见的落点（岗位/职责）
专职写Prompt、做提示词库	AI产品经理/AI运营：设计流程、定义验收、做内容与质量体系
调教模型输出更像人、更好看	内容/增长团队：用结构化模板做规模化产出与质量抽检
解决“模型不听话”	LLM应用工程/Agent工程：把约束、工具、评测、监控做进系统
“会写Prompt就能上岗”	“会把业务问题工程化”：需求翻译、评估指标、风险与合规

这也是我写这篇文章原因：靠“写得巧”很难持续，靠“可验收、可复用、可评测”才能进生产。

一、为什么你写得很详细，AI还是会跑偏？

我在咨询里最常听到的抱怨大概是三类：

“我写得很详细了，它还是胡编。”

“同样的问题，今天好用明天废。”

“在A平台能跑，到内部系统就不工作。”

很多人把原因归结为“模型不够聪明”。但从实践看，更常见的是：提示词里缺少工程化要素。你写的是“描述”，模型需要的是“协议”。

我把最常见的失效原因总结为 6 条，你可以把它当成排查清单：

1. 任务边界不清：到底是要“给建议”还是“直接给成品”？是“覆盖全面”还是“挑最关键的3条”？
2. 隐含前提没写出来：你以为“大家都懂”的背景，模型并不知道；或者知道，但不确定你要哪个版本。
3. 约束冲突且没有优先级：又要简短、又要详细、又要风格强、又要严谨，最后它只能平均用力。
4. 验收标准缺失：你没定义什么叫“好”，它只能输出“最常见的那种好”。
5. 输入信息组织混乱：一段长叙述里夹着条件、夹着例子、夹着临时想法，模型很难抓住结构。
6. 上下文污染：同一对话里前面聊过A，后面问B；模型会把A的影子带进B（尤其是你没显式“重置任务”）。

一个最典型的例子：销售话术

“菜鸟级提示词”

请写一份销售话术，针对电商平台的家电产品。

它的问题不是短，而是缺关键字段。你没有告诉它“写给谁、在什么场景、要达成什么结果、不能说什么”。于是它只能输出“最安全、最通用、最像样板间”的话术。

“可验收级提示词”

我需要你写一条电商平台私信话术，用于“售后复购跟进”。

【客户背景】
- 用户画像：30-45岁女性，30天前买了我们的洗衣机
- 目标商品：配套烘干机（不提具体价格/优惠）

【触达场景】
- 用户打开APP时，系统自动推送一条私信
- 用户此刻的心理：不反感，但不想被推销

【语气要求】
- 像一个有经验的朋友，温暖、克制、不过度营销
- 避免“尊敬的客户”“亲爱的用户”这类模板开头

【成功标准】
- 让她愿意点开了解（不要求当场下单）

【硬性约束】
- 150字以内
- 不使用虚构评论/数据

【输出】
- 只输出最终话术，不要解释

这类提示词的核心不是“更长”，而是把关键变量写齐。你不是在“求AI帮忙”，你是在给它一张任务卡：输入是什么、输出是什么、什么算成功、哪些话不能说。

---

二、提示词工程的5大法则（以及每条的升级写法）

我仍然用“5大法则”来讲，但会加上每条更工程化的升级点：你不只要“写得好”，还要“跑得稳”。

法则1：角色扮演（Role Playing）——给它一个工作身份

核心作用：限定“视角、深度、表达风格、默认方法论”。

低配写法

帮我分析这个财务报表。

可用写法

你是一名企业财务顾问（20年经验），主要服务中型制造业。
我会给你一份财务报表，请你：
1) 从现金流角度指出3个高风险信号
2) 用同行对标的视角解释这些信号意味着什么
3) 给出3条可执行的改进建议，并标明优先级

表达要求：严谨但不术语堆砌；默认读者是非财务背景的创业者。

升级写法：角色 + 交付物形态

很多“角色设定”写到一半就停了，但真正决定可用度的，是你把交付物说清楚，比如“先给结论，再给证据，再给建议”。你也可以这样写：

输出必须包含三个部分：
【结论】一句话摘要
【证据】引用报表中的具体科目/数字（如果缺数据就写“缺失”）
【建议】3条建议 + 风险提示

法则2：结构化输入（Structured Input）——把信息变成字段

核心作用：降低歧义，让模型像读配置文件一样读你的需求。

结构化不等于“堆更多字”，而是把“散文式需求”变成“字段式需求”。最实用的是下面这个四块结构：

【任务】我要你做什么
【上下文】你需要知道什么
【约束】不能做什么/必须满足什么
【输出】我要什么格式/多长/给谁看

升级写法：把“优先级”写出来

如果你同时有很多要求，明确哪条是第一优先级，模型会更稳：

优先级：准确性 > 可执行性 > 风格 > 覆盖面

法则3：约束条件（Constraints）——把“不能做什么”说清楚

核心作用：减少幻觉、减少“自由发挥”、减少踩线。

不好的写法

帮我用Python写一个爬虫，爬取某个网站的产品信息。

更靠谱的写法

我需要一个Python爬虫，采集某网站“在售产品”的信息。

【技术约束】
- Python 3.8+
- requests + BeautifulSoup
- 不用Selenium
- 不用多线程

【业务约束】
- 只采集在售；下架跳过
- 字段：名称、价格、库存、最后更新时间，缺一跳过
- 每小时运行一次，每次最多100条

【容错】
- 网络失败：记录错误但不中断
- HTTP 429：暂停1小时再重试

【输出】
- CSV：成功数、失败数、最后运行时间

【合规】
- 不采集隐私字段
- 遵守robots.txt

升级写法：把“不可确定项”写进协议

你可以明确要求模型对不确定内容“标注为未知”，而不是编：

如果缺少关键输入或无法确定，请在输出中用【未知】标注，不要猜。

法则4：示例驱动（Few-Shot）——用样例教它“边界在哪里”

核心作用：让模型学到你的“判定标准”，尤其适合分类、抽取、改写、审核。

示例最好包含两类：标准样例 + 边界样例。

请将客服对话分类为：售前咨询、订单问题、退货、投诉、其他。

【示例1】
对话：你们这个产品保修多久？
分类：售前咨询

【示例2（边界）】
对话：我订单号12345三天了还没发货，太离谱了！
分类：订单问题
说明：虽然情绪很强，但核心诉求是物流与履约

【示例3（边界）】
对话：我第三次投诉了，每次收到的产品都有问题，你们是在糊弄人吗？
分类：投诉
说明：多次失败 + 强烈负面情绪，优先归为投诉

现在请按同一标准分类：...

升级写法：让它输出“理由字段”

不是为了看它“解释得好不好”，而是为了便于你快速审核：

输出格式：对话 | 分类 | 触发关键词/理由（不超过20字）

法则5：迭代反馈（Iterative Refinement）——把第一稿当成测试样本

核心作用：把“需求”从模糊拉到可交付。

我在做内容优化时最常用的迭代方式不是“再写一遍”，而是三步：

1. 指出不满足验收标准的地方（例如“太教科书”“缺细节”“没有成本与收益”）
2. 补关键变量（人物、冲突、决策、代价、风险）
3. 锁定输出协议（结构固定，减少漂移）

你可以直接这样对模型说：

先不要重写全文。请按下面格式做差距分析：
1) 目前输出不满足的3条验收标准
2) 缺失的关键信息清单（按重要程度排序）
3) 下一版提纲（只要提纲）

---

三、用“验收表”把提示词变成工程

你会发现：只讲5条法则，还不够“稳”。因为真正让产出可复用的，是你有没有“验收表”。

我常用的轻量验收表长这样（你可以复制到文档）：

维度	评分（1-5）	不达标的典型表现	你要追加的指令
准确性		编数据、乱引用	“不确定就标【未知】，不要猜”
完整性		漏关键字段	“输出必须覆盖字段A/B/C，否则返回缺失清单”
可执行性		只有观点没有步骤	“给步骤、给负责人角色、给时间成本”
风格匹配		太官腔/太模板	“避免××词，像××人说话”
风险提示		只讲好处不讲代价	“每条建议附一个风险和规避方式”

你每次迭代，不是“凭感觉改”，而是“把低分项补齐”。这会让你更快收敛到能用的版本。

---

四、提示词工程的10个坑（更像生产现场的版本）

坑1：迷信“魔法词汇”

“你是专家”“深思熟虑”不是没用，但它们解决的是“风格”，解决不了“缺字段、缺验收标准”。

坑2：提示词越长越好

长提示词的风险在于：信息密度上不去、优先级没写、模型会忽略后半段。更稳的做法是拆成两段：

• 主提示词：任务 + 约束 + 输出协议（尽量短）
• 参考资料：背景、长文、案例（可长，但要结构清楚）

坑3：用自然语言写复杂逻辑

条件分支多的时候，用“决策表/决策树”比散文式更稳：

【决策表】
价格相关 -> 提供三档方案
物流相关 -> 查询库存与预计到货
退货相关 -> 校验订单号 -> 判断是否在退货期 -> 输出流程

坑4：不指定输出格式

不指定格式，输出就不可控；不可控，就不可复用。

坑5：默认AI懂你的行业

行业、客群、约束、业务指标，写出来。你省下的不是字数，而是返工。

坑6：把AI当实时搜索引擎

涉及实时数据、法规细则、价格政策，默认“需要外部来源”。你可以让它做结构化总结，但别把事实校验也交出去。

坑7：忽略token预算

输入 + 输出都占窗口。最稳的办法是：先让它“给提纲/给缺失清单”，再逐步展开。

坑8：对一致性期待过高

创意类任务允许波动，逻辑类任务就把温度降下来，并且用固定输出协议。

坑9：不做事实核验

尤其是带数字、带引用的内容：要么你给数据源，要么你要求它标注“基于输入/基于推测”。

坑10：没有版本管理

没有版本记录，你永远在“凭感觉漂”。最简单的版本管理就是三行：

v1：加了角色
v2：加了输出协议
v3：加了示例与验收表

---

五、从“提示词工程师”到“业务问题解决者”

提示词工程的本质不是写作技巧，而是把模糊问题翻译成可交付任务。我常用的翻译框架是：

输入（你能提供什么） -> 处理（你希望怎么分析/生成） -> 输出（交付物长什么样） -> 验收（什么叫成功）

把这个框架套到常见场景上，会非常清晰：

业务场景	模糊问题	翻译后的可交付任务
内容运营	“帮我写个文案”	写给谁、在哪个触点、目标是什么、禁区是什么、输出格式与长度
数据分析	“分析一下这个数据”	关心指标、对标对象、数据口径、输出表格字段、结论与建议的结构
代码开发	“给我写个爬虫”	技术栈、频率、字段、容错、合规、输出格式与监控
知识管理	“总结一下这个文档”	读者是谁、用途是什么、要保留什么细节、输出模板（要点/表格/行动项）

---

六、一份能立刻用的提示词模板

你可以从这个模板开始，然后按任务增删字段：

【角色】
你是谁（职业/经验/行业）

【任务】
我要你完成什么（动词清晰）

【上下文】
已知信息：...
缺失信息：如必要，请先列出你需要问我的3个问题

【约束】
必须：...
禁止：...
优先级：准确性 > 可执行性 > 风格 > 覆盖面

【输出协议】
格式：标题/列表/表格/JSON
结构：结论 -> 证据 -> 建议 -> 风险
长度：...
只输出结果，不要客套话

---

总结一下：你真正练到的是“表达需求”的能力

我后来越来越确定：提示词工程不是“会几句咒语”，而是把一个混乱的想法，变成一张清晰的任务卡。

你写得越具体，不是为了束缚模型，而是为了减少返工，把注意力从“修输出”转到“做决策”。

---

本文首发于CSDN：黑棠会长，转载请注明来源。
关注我，一起用更务实的方法把AI落到生产流程里。