Write Linters and Tools Before Code
7 hours ago
- 语言模型是非确定性的；它们不仅在措辞上，而且在结构上产生变化，这不能仅通过提示工程来解决。
- 解决方案是在让智能体生成内容之前定义可执行的结构（解析器、检查器、模式验证器、构建器），这样模型是在填充预定义的框架，而不是自行发明。
- 大语言模型是优秀的局部编写者，但却是糟糕的全局记账员；它们缺乏持久的状态，并且对长上下文的注意力不均匀，导致长文档中出现结构错误。
- 检查器将主观的风格指南转化为确定性的预言机，它们可以失败并给出精确的错误信息，将'这份文档好不好？'转化为一个带有行号原因的通过/失败测试。
- 关于结构（允许的元素、嵌套、标记、章节、元数据）的决策应该编码在工具中，留给模型的只有那些繁琐的工作——高容量、低分支、可验证的任务，如描述或总结。
- Markdown 需要严格的检查规则（例如，精确的标题等级、ASCII字符、强制章节），以防止智能体生成的文档破坏下游；检查器作为提示的作用比任何样式指南都要好。
- 对于二进制格式（docx、xlsx、PDF），避免让模型输出原始字节；而是让它通过API调用输出结构化数据，并使用确定性工具进行序列化和验证。
- 一个实用的工作流程：指定格式不变性，编写带有修复器的解析器/检查器，构建确定性序列化器，然后循环进行智能体生成、检查与修复，直到零错误，并由检查器控制代码仓库的提交。