减少噪声、提高复用和降低不确定性

尽可能多的信息、尽可能少的噪声

对于LLM来说，其做的工作就是根据输入的信息，生成输出文本。 输入的信息越有效，LLM工作得也越好。

如果你的目的是为了开发某一个软件，写某个程序，那么，编写提示词的时候，要尽可能输入多的有效信息，尽可能地减少被LLM获取到的无效信息（即噪声）。

什么是有效信息和噪声：

对于一个软件开发的提示词而言：

有效信息例子：

• 软件应当使用的架构
• 程序的逻辑设计
• 功能需求等

噪声例子：

• 我的心情
• 今天的天气
• 粗口和脏话

对于在项目中开发单个feature而言： 有效信息例子：

• 与这个feature相关的已有代码
• feature的需求
• 开发这个feature时可能踩的坑

噪声例子：

• 与其他feature相关但是与本feature无关的代码

为了尽可能避免在开发某个新的feature时，引入噪声，可以选择每开发完成一个feature就发起一个新的会话。

基于agent探索项目，一般是先探索项目整体信息和某些公共代码。因此，也可以选择在agent在此阶段的消息对会话进行fork。

复用

计算机的发展的一条线索就是不断发掘可复用的做法并将其封装为更高级的做法。

案例是：

• 用某些电路元件做出某功能——>发现此功能经常需要被做——>把这个功能封装成一个新的电路元件
• 某段代码实现了一个需求——>发现这段代码经常需要被反复写——>把这段代码封装成一个函数、类

类似的，在我们使用agent的时候，就会有这样的做法：

• 某些提示词要求agent完成一个工作——>发现这段提示词经常需要被反复写——>把这段提示词封装成一个Skill

这就是Skill的由来。

对于一个agent使用者而言，如果这个skill经常在多个项目中被使用。

要求agent遵循某种特定的代码规范、要求agent，那么这个skill最好作为全局skill存在。

如果只与单个项目有关，就应该作为项目级 skill / 项目文档 / agent 规则存在，而不该污染全局配置。

降低不确定性

众所周知，LLM的本质是基于已有的token，推测出下一个token。对于LLM能否正确得到对于用户需求来说最好的那个“下一个token”，实际上是具有高度不确定性的。

可以庸俗且不严谨地说，能力越强的LLM能得出更好的“下一个token”的概率更高。

有这样一个案例。学校要求学生提交的作业都遵循某一个特定的排版格式的word文档。 有学生选择使用agent直接生成这个格式的word文档，有学生则选择先用agent编写一个程序，可以将agent生成的md文档转换成要求格式的word文档。

显然，后者的做法是更好的，因为使用一个转换程序，降低了llm生成的不确定性。

我们来做一个不严谨但是却能反映现实的思考：

对于一个“不错”的LLM来说，生成符合要求格式的文档，并完美符合要求，概率可能是80%。

但是，如果先让LLM生成LLM最擅长的md文档，这个文档完美符合转换程序输入的要求的概率可能是95%。而使用提前编写好的转换程序来将md文档转换成符合格式要求的word文档，这个过程的成功的概率可能是99%。那么综合来看，95% * 99%，生成完美符合要求的文档要求的成功概率就要大于直接生成文档的80%。

为什么？因为程序如果已经编写好了，并且写的足够好，那么它每一次运行几乎都不可能失败，除非考虑到某些极端的情况或者程序本身有未排除的bug。

使用后者的策略，可以尽可能能降低agent在完成“生成符合格式的文档”这个过程的不确定性。此外，编写转换格式的程序，这个程序在后续还可以复用，降低了后续再次编写文档时，或者需要对文档进行调整时，人的工作量和LLM的token消耗量。