用非母语写 Prompt

发布于:2026-09-01 2,685 字 9 分钟阅读

我发现,用中文给 Agent 写 Prompt 时,我总会不自觉地把话说得委婉。

“你可以先看一下这几个文件。”

“如果合适的话,最好顺便把测试也跑一下。”

“这里是不是可以考虑换一种实现?”

这些句子放在人与人的交流里很自然。它们不直接命令对方,而是给对方留下判断和拒绝的空间。可一旦拿来交代任务,真正的要求也被一起说弱了:到底必须看,还是可以不看?测试是不是交付的一部分?所谓“考虑”,最后需不需要真的修改?

换成英语,我反而会写得很直接:

Read these files first. Use the existing implementation pattern. Run the tests before you finish.

不是因为英语天然比中文直接。真实的英语职场交流往往同样委婉,甚至会用询问来表达要求。一句 “Can you take a look when you have time?” 表面给了选择,具体语境里却可能意味着:请处理这件事,而且不要让我再催。

我之所以能用英语把 Prompt 写得更直接,只是因为英语不是我的母语。

使用母语时,我们不只是在传递意思,也在自动处理关系。哪句话像命令,哪句话会让人难堪,怎样表达不同意见又不显得咄咄逼人,这些判断早已进入语感,不需要经过思考。要求还没写出来,就先被礼貌修整了一遍。

使用非母语时,这套反应没有那么灵敏。我掌握的表达更少,只能先抓住最基本的结构:做什么,作用于什么,做到什么程度,哪些事情不能做。

语言能力的不足,反而暂时拿掉了一部分人情世故。

这不意味着母语不适合写 Prompt,也不意味着应该故意对 Agent 粗鲁。非母语真正有用的地方,是制造了一点距离。它让我暂时离开熟悉的说话方式,重新检查一句任务说明里究竟有没有动作、边界和完成条件。

对人说话时,委婉有明确的作用。

成年人之间默认彼此独立,不能把对方当成等待规训和服从的对象。成熟的拒绝通常不会只扔下一句 “No”,而会说明现实约束,必要时提供替代方案。上级提出要求,也可能使用询问句,保留对方的体面与回应空间。

这种沟通不是把真实意图藏起来,而是同时照顾两件事:边界要清楚,关系也不能被破坏。话可以柔软,结论不能含糊。

Prompt 面对的却是另一种关系。

Agent 不会因为 “Read these files first” 受到冒犯,也不需要通过一句 “Would you mind” 来确认自己仍被平等对待。它更需要知道哪些内容是要求,哪些只是参考;什么必须完成,什么可以自行判断;遇到什么情况应该停下来问人。

如果沿用人与人之间的委婉表达,却没有把背后的真实意图一并写清,礼貌就会变成歧义。

例如:

如果方便的话,可以顺便检查一下移动端。

说话的人心里可能想的是“移动端必须验收”,只是习惯上不愿意说得像命令。Agent 读到的却可能是一个低优先级选项。更清楚的写法是:

完成前检查桌面端和移动端。普通细节按现有设计处理;如果需要改变交互方式,再回来问我。

它仍然给 Agent 留出了自主空间,只是把自主放在了正确的位置。是否检查移动端不是选择,怎样处理普通细节才是选择。

这也是直接与粗暴的区别。

粗暴是不给背景,不讲边界,只丢下一串命令;或者在结果不符合预期时,用讽刺和反问代替反馈。直接则是明确说出目标、约束和验收办法,并让执行者在这些边界内自行决定路径。

好的 Prompt 不是把“命令—服从”写得更强硬,而是把“自主—协商”的边界写得更清楚。

但很快我又遇到另一个问题。

这次写清楚了,不代表下次还会生效。换一个任务,甚至换一次会话,同样的边界可能又要解释一遍:完成前要运行测试,移动端也属于验收范围,不要为了修一个问题顺便改动无关文件。

我可以继续磨练 Prompt,把每一次纠正都补进下一次任务说明。这样做确实有用,但任务会越写越长,人也成了边界的搬运工。只要哪次忘记带上一条,已经解决过的问题就可能重新出现。

后来我意识到,我一直在修改句子,却没有改变边界存放和生效的方式。

非母语帮我解决的是表达问题:它迫使那些藏在语气和默契里的要求第一次显形。但如果一条要求需要在不同任务里反复解释,问题就不再是这一次说得够不够直接,而是一个长期有效的边界,被放在了只能服务当前任务的位置。

这时需要的不是一份更长的 Prompt,而是 Harness。

Harness 是围绕模型工作的那层系统。它负责重新提供必要的上下文、装载规则、开放工具、保存状态,并检查结果。模型不会因为上一次被我纠正过,就在下一次调用里自动继承那条纠正。对话看起来连续,是因为外围系统把相关内容再次交给了模型。

因此,边界也应该按照寿命和强度放在不同的位置。

只影响本次任务的目标和局部约束,仍然写进 Prompt。跨任务都要遵守的项目边界,可以放进 AGENTS.md。反复使用的方法,可以沉淀成 Skill。能够观察和执行的验收条件,交给测试。真正不能越过的权限,则应该由系统限制,而不是期待模型永远记得一句“不要这样做”。

这些东西并不会让输出变得绝对稳定。即使拿到同样的上下文,模型仍可能因为推理的不确定性、指令冲突或上下文负担而给出不同结果。Harness 的作用不是消灭变化,而是让重要的背景持续出现,让可以检查的结果接受检查,让不能承担的风险不再只依赖模型每次都作出正确判断。

这也让我重新理解了“用非母语写 Prompt”这件事。

非母语不是 Harness。它不保存状态,不装载规则,也不会验证结果。它只是一种很轻的边界显式化练习:当熟悉的语气和人际默契暂时失效,我不得不说清哪些结果必须交付,哪些判断可以委托,哪些情况需要回来询问。

这里仍然不能反过来迷信非母语。

词汇简单会让句子直接,也可能让判断变得粗糙。只会写 “This is wrong” 时,我们或许省掉了中文里的绕弯,却也没有说明错在哪里。非母语还能制造一种虚假的客观感:句子看起来简洁坚定,不代表目标本身已经想清楚。

更可靠的做法,是把非母语当成一次检查,而不是一条规则。

当中文 Prompt 写得很长、到处都是“可以”“最好”“方便的话”“要不”时,可以试着在脑中把它换成自己掌握的最简单的外语。离开熟悉的语气以后,往往更容易看见真正想说的几件事:

  • 哪个结果必须交付;
  • 哪些只是参考信息;
  • 哪些判断可以交给 Agent;
  • 哪些情况必须由人决定。

看清以后,再用中文重新写一遍也没有问题。

如果一条边界只在这次任务里重要,就把它写清楚。如果它下一次仍然重要,就让系统保存它。如果它真的不能被越过,就不要继续指望模型仅凭一句话记住。

我以为自己是在练习用另一种语言写 Prompt。后来才发现,我真正练习的是把隐性判断写成显性契约。

非母语让我看见边界。Harness 才让边界留下来。