文章

审美与提示词书写

审美与提示词书写

在使用AI时,我们常常遇到这样的情况:明明给出详细的指令,但 AI 生成的结果质量却不稳定——有时让人眼前一亮,但有时却不尽如人意。它给出的结果或许正确,但是不那么好。例如,让 AI 翻译一篇文章,它可能给出一份语法正确但生硬的译文。

我认为,问题的关键在于我们只告诉 AI 要做什么,但是没有界定”怎么才算做得好“。我们内心深处有一套关于”好“与”美“的评判标准,但我们没有将其清晰地传达给 AI。

在这篇文章中,我想分享如何将我们脑中那些模糊、隐性的审美标准,转化为可执行的指令,融入到提示词中,从而提高 AI 的输出质量。

何谓审美

关于审美,我个人有一个朴素的定义:审美就是知道什么是好的、什么是不好的。”而什么是好的、什么是不好的“便构成了一套审美标准。

例如,翻译家严复曾经提出一套翻译标准”信、达、雅“,它清晰地界定了“好的译文”应该具备的特质:

  • 信:译文要忠实于原文,内容准确,不歪曲、不遗漏原文的意思
  • 达:译文要通顺流畅,符合目的语的表达习惯,使读者易于理解
  • 雅:译文的文字要优美典雅,具有较高的艺术性和审美价值,追求原文的神韵

再如,The Zen of Python 也是一套审美标准,它定义了什么是好的代码,什么是不好的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
❯ python3 -m this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

如何将审美标准融入提示词

要将审美标准融入提示词,核心在于将隐性审美标准转化为显性指令,最好能给出一些实践要点,方便 AI 理解与执行。以上述“信、达、雅”为例,它可以细化为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
### 信

“信”意味着忠实于原文的内容、思想、情感、风格和语气。译者需要像一个侦探,深入理解作者为什么要用这个词,这句话背后隐藏的情感和立场是什么。

要点:
- 保证信息完整,不能随意增删、扭曲原文的信息。无论是事实、数据,还是微妙的情感色彩,都应尽可能完整地传达。
- 保证风格一致。原文是诙谐的,译文就不应是严肃的;原文是古朴的,译文就不应是现代的。译者需要把握原作的整体风格,并在译文中复现。

### 达

“达”意味着译文通顺流畅,符合目标语言的阅读习惯。行文流畅,宛若原创,这是“达”的理想状态。

一个优秀的译者必然是一个文化使者。他需要处理原文中特有的文化元素(如典故、习俗、俚语)。一篇充满了翻译腔(欧式句法、生硬词汇)的译文,即使每个词的意思都对,也算不上“达”。译文必须读起来地道,自然、流畅,没有生涩之感。好的译文能让读者跨越文化鸿沟,与作品产生共鸣。

要点:
- 译文必须确保逻辑通顺,让读者能够毫不费力地理解内容。
- 当原文中出现目标读者不熟悉的文化典故、习语时(例如,英文中的 "It's raining cats and dogs."),好的译者不会直译为“下猫下狗”,而是会采取读者能理解的方式进行处理,如意译为“倾盆大雨”,或在必要时加以注释,帮助读者理解文化背景。

### 雅

“雅”是在“信”和"达”的基础上,追求文字的精炼和美感。

要点:
- 注意文字的韵律与节奏:美的译文是有音律感的。长短句的交错、词语的搭配、声调的和谐,都会影响阅读的体验。尤其在文学、诗歌翻译中,译者需要像音乐家一样,组织语言的节奏和韵律。
- 对词语的精挑细选,力求用最精准、最富表现力、最有意境的词汇来还原原文的神采
- 营造意境:美的译文能够超越字面,将原文的画面感、氛围和弦外之音巧妙地传达给读者,引发读者的联想和共鸣。

当我们把审美标准显化成具体指令之后,我们就可以把指令融入提示词中。我在实践中总结出两套方法:

  1. 直接插入提示词末尾
  2. 借助 AI 融合提示词

方法一:直接插入提示词

针对简单场景,可以直接把审美标准直接置于提示词末尾。

例如,针对翻译任务的提示词为:

1
2
3
4
5
6
7
8
9
请你将下面的文章翻译成中文,务必遵循最后的翻译守则。

---
<文章内容>

---
# 翻译守则

<关于翻译的审美标准>

这种方法同样适用于各类 AI 编程软件的配置文件,比如 CLAUDE.mdGEMINI.md 或者 Cursor rules。你可以把关于“好代码库”、“好 UI/UX”等标准直接写入其中,让 AI 在每一次交互中都遵循规范。

方法二:借助 AI 融合提示词

对于比较复杂的场景,我更推荐使用 AI 融合提示词——让 AI 基于通用审美标准以及具体任务场景,生成一份更详细、更定制化的提示词。

例如,我有一套通用的代码库审美标准,我想为一个技术栈为 React + Tauri + Python 的项目编写 CLAUDE.md,我会让 AI 根据代码库审美标准以及技术栈来撰写开发指南。AI 会将通用原则(如“直观的项目结构”、“代码自文档化”)与特定技术栈的最佳实践结合起来,生成一份更详细、更定制化的提示词。

以下为一个示例片段:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
### 清晰

代码的首要读者是人。清晰的代码能降低协作成本,加速迭代,并减少错误。

通用:
- 直观的项目结构:文件和目录的组织方式逻辑清晰、一目了然。无论是按功能(Feature)还是按类型(Layer)组织,都应在整个项目中保持一致。遵循“约定优于配置”的原则,让开发者能快速定位到任何代码。
- 代码自文档化:通过语义明确的命名和分层清晰的逻辑架构,让代码本身即是最直接的“文档”。注释只需解释“为什么”,不需重复“做什么”。
- 最小惊奇原则:模块应符合直觉,能合理预测。从而让使用者心里永远不产生“它居然会这样工作”的疑惑。
- 关注专注的单元设计:遵循单一职责原则,避免因过多功能堆叠而产生难理解的“大类”或“多功能函数”。
- 统一代码风格:一致的代码格式和风格规范是团队沟通的共同语言。借助自动化工具可简化执行。

前端:
- 采用功能驱动 (Feature-driven) 的目录结构。将与特定功能相关的所有文件(组件、Hooks、样式、测试)放在同一个文件夹下
- 保持组件简短,专注于渲染。将所有非渲染逻辑(数据获取、事件处理、状态管理)尽可能地抽离到自定义 Hooks 中。
- 导入请使用绝对路径格式(`@/path/to/directory`),减少维护难度

Tauri:
- 每个 command 都是一个独立的、功能明确的单元。

Python:
- 使用 APIRouter 按业务域组织路由。利用依赖注入系统 (Depends) 将数据库会话、认证逻辑等横切关注点与业务逻辑解耦。

小技巧:如何总结一份审美标准

在我们擅长的领域中,我们往往对“什么是好的”有直觉上的认知。即使不一定能用语言精确地表达,但至少也有一个模糊的印象。此时,可以尝试用名词和形容词描述自己心目中的“美”。哪怕最初只能写下零散的词语,也可以逐步梳理成结构化的要点。当然,也可以直接使用下文提到的 AI 辅助思考方式来归纳总结。

而在我们不熟悉的领域中,我们对”什么是好的、什么是不好的“缺乏认知。此时我们可以借助 AI 来思考,快速构建出一套审美标准。

比如,你想让 AI 英译中,可以先询问 AI ”从专业的角度看,什么是好的译文“。

AI 回答:什么是好的译文 AI 回答:什么是好的译文

再比如,假设你想让 AI 写代码或者审查代码,可以询问 AI “从专业的角度来看,什么是好的代码库”。

AI 回答:什么是好的代码库 AI 回答:什么是好的代码库

你可以多生成几次,多问几个模型。从每个模型的回答中提取出符合你审美的部分,加以整合,便能得到一份属于你的审美标准。建议把它整理成文档,方便后续使用以及迭代优化。

以下是我根据 AI 回答整理的一份关于翻译的审美标准:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
好的译文:
- 信——对原作,它忠实而深刻
- 达——对读者,它清晰而自然
- 雅——在艺术上,它优雅而得体
- 功能对等——在功能上,它精准而有效

### 信

“信”意味着忠实于原文的内容、思想、情感、风格和语气。译者需要像一个侦探,深入理解作者为什么要用这个词,这句话背后隐藏的情感和立场是什么。

要点:
- 保证信息完整,不能随意增删、扭曲原文的信息。无论是事实、数据,还是微妙的情感色彩,都应尽可能完整地传达。
- 保证风格一致。原文是诙谐的,译文就不应是严肃的;原文是古朴的,译文就不应是现代的。译者需要把握原作的整体风格,并在译文中复现。

### 达

“达”意味着译文通顺流畅,符合目标语言的阅读习惯。行文流畅,宛若原创,这是“达”的理想状态。

一个优秀的译者必然是一个文化使者。他需要处理原文中特有的文化元素(如典故、习俗、俚语)。一篇充满了翻译腔(欧式句法、生硬词汇)的译文,即使每个词的意思都对,也算不上“达”。译文必须读起来地道,自然、流畅,没有生涩之感。好的译文能让读者跨越文化鸿沟,与作品产生共鸣。

要点:
- 译文必须确保逻辑通顺,让读者能够毫不费力地理解内容。
- 当原文中出现目标读者不熟悉的文化典故、习语时(例如,英文中的 "It's raining cats and dogs."),好的译者不会直译为“下猫下狗”,而是会采取读者能理解的方式进行处理,如意译为“倾盆大雨”,或在必要时加以注释,帮助读者理解文化背景。

### 雅

“雅”是在“信”和"达”的基础上,求文字的精炼和美感。

要点:
- 注意文字的韵律与节奏:美的译文是有音律感的。长短句的交错、词语的搭配、声调的和谐,都会影响阅读的体验。尤其在文学、诗歌翻译中,译者需要像音乐家一样,组织语言的节奏和韵律。
- 对词语的精挑细选,力求用最精准、最富表现力、最有意境的词汇来还原原文的神采
- 营造意境:美的译文能够超越字面,将原文的画面感、氛围和弦外之音巧妙地传达给读者,引发读者的联想和共鸣。

### 功能对等

功能对等意味着,一个好的译文,必须实现其预设的功能。它的“好”体现在“恰如其分”。

比如,
- 广告语翻译:目的不是字面对等,而是要在目标市场引起同样的购买欲。耐克的 "Just do it" 翻译成“想做就做”或保留原文,都是基于功能的选择。
- 法律合同翻译:美感和文采完全不重要,极端精准、无歧义才是唯一的美。
- 儿童读物翻译:语言必须符合儿童的认知水平,生动有趣,易于理解。

最后一点想法

最近 AWS 推出了 AI IDE Kiro。Kiro 和其它 AI IDE 最大的不同在于它提倡的 spec-driven development(文档驱动开发)。

当开发者想让 AI 去实现某个功能时,它会先创建详细的一份规格文档(specification),其中包含:

  • Requirements document:定义功能的目标和范围,由一系列关于这个功能的用户故事构成
  • Design document:规划技术实现方案
  • Task list:定义开发任务

在我看来,审美标准是一种自上而下的标准,而用户故事是一种自下而上的验收标准。审美标准从开发者的角度定义“什么是好,如何做得好”,而用户故事则是从用户的角度定义”开发者需要做什么,从用户的角度来看什么是好“。

或许我们可以把这两套标准都融入到我们的开发流程中,打造出一个更高效的 AI 辅助编程工作流。

本文由作者按照 CC BY 4.0 进行授权