提示词编写规范：让 AI 智能体一次做对的五个习惯

用智能体干活也有小半年了，从最早“想到哪说到哪”，到现在给每个常用任务都备一份固定提示词模板，最大的体会是：智能体时代，提示词就是新的代码。写得好的提示词可以复用、可以版本管理、可以沉淀成团队资产；写得烂的，每次都要返工，返工三次的成本早就超过认真写一次的成本。

下面五个习惯，是我自己踩坑总结出来的，条条都有对应的翻车现场。

习惯一：先讲目标，再讲步骤

新手最容易犯的错，是把提示词写成操作手册：“先打开 A，再点 B，然后把 C 填进去”。智能体最擅长的是规划，你替它把路走死了，它反而不会变通——页面稍微一变就卡住。

正确姿势是讲清楚要什么结果、验收标准是什么，步骤让它自己定：

目标：把这个目录下的日志按日期归档成 zip，放到 backup/ 下。
验收：backup/ 里每个 zip 解压后能还原出当天全部日志，且原目录的日志文件已删除。

目标 + 验收标准，剩下的交给它。步骤写得越细，智能体的发挥空间越小。

习惯二：把约束写死，不要靠默契

“你看着办”是对智能体最贵的一句话。它没有你的上下文，不知道哪些东西碰不得。

我的模板里现在固定有三行：

• 范围：只允许改动 src/ 下的文件，不准碰配置文件和依赖。
• 输出：先给方案再动手，动手前等我确认。
• 禁区：不确定的地方停下来问我，不要猜。

尤其是“不确定的地方停下来问我，不要猜”这一句，加上之后，幻觉式瞎改的次数断崖式下降。约束不是不信任，是把你的隐性知识显性化。

习惯三：给例子，不给形容词

“写清楚一点”“写专业一点”这种形容词，对人和对智能体一样无效。一个例子顶十句形容词，这就是 few-shot 的朴素版本。

比如让智能体写提交信息，与其说“写规范一点”，不如直接贴：

按这个格式写：feat(auth): 支持 token 自动刷新，冒号后一句话说清改了什么，不超过 50 字。

再比如让它生成测试数据，直接给一行期望输出的样例。例子给得越具体，返工越少。

习惯四：长任务分段验收

超过 15 分钟的任务，一次性下发等于赌博。我的做法是拆成里程碑，每段结束停一下：

分三步做，每做完一步停下来给我看结果，确认后再继续：

1. 先搭出最小可运行版本；
2. 再补边界情况处理；
3. 最后写 README。

分段验收有两个好处：一是早发现跑偏，二是每段的输出都可以单独复用。智能体在第二步翻车了，第一步的成果还在，不用从头再来。

习惯五：允许它说“不知道”

这是反直觉但最重要的一条。默认情况下，智能体被问住了会倾向于编一个看起来合理的答案，而不是承认不知道。

我的模板结尾现在固定加一句：

如果缺少关键信息，宁可停下来问我，也不要编造；引用外部资料时给出处。

加上这句之后，它开始会说“这个 API 的参数我不确定，我去查一下文档”——这才是你想要的助手，而不是一个自信的骗子。

一个完整的 before / after

需求：让智能体写个脚本，统计某个目录下各类文件的数量。

❌ Before（翻车版）：

写个脚本统计下这个目录里各种文件有多少个。

结果：它可能用 ls 管道拼凑，特殊文件名就崩；也可能直接 rm 了什么——你没说禁区。

✅ After（规范版）：

目标：统计 /data/logs 下按扩展名分组的文件数量，输出表格。
约束：只读操作，不准删除或移动任何文件；用 Python 写，兼容 Python 3.10。
输出示例：

.log   128
.tmp    12

不确定的地方先问我，不要猜。

同样的需求，after 版一次做对的概率高得多。差别不在智能体，在提示词。

结尾

提示词规范的本质，是降低沟通成本。你和智能体之间每一次返工，都是 tokens 和时间的双重浪费。把这五个习惯沉淀成你自己的模板库——目标先行、约束写死、给例子、分段验收、允许说不知道——用上一个月，你会发现智能体从“不太靠谱的实习生”变成了“靠谱的搭子”。

下一篇打算写：智能体节点搭建实战——把常用工作流固化成一键任务。感兴趣的话评论区说说你最想看哪个方向。