--- title: "用非母语写 Prompt" author: "Shawn Jiang" lang: zh date: 2026-09-01 canonical: https://tplog.dev/zh/essay/prompting-in-a-non-native-language/ translations: en: https://tplog.dev/en/essay/prompting-in-a-non-native-language/ ja: https://tplog.dev/ja/essay/prompting-in-a-non-native-language/ --- # 用非母语写 Prompt 我发现，用中文给 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 才让边界留下来。