深度解析gptel项目中的Markdown/Org模式标题层级处理问题

问题背景

在Emacs生态系统中，gptel作为一个强大的LLM交互工具，为用户提供了与大型语言模型无缝集成的体验。然而，在使用过程中，特别是在Markdown或Org模式下，用户经常遇到一个棘手的问题：AI生成的响应内容中的标题层级与对话结构不匹配，导致文档组织结构混乱。

核心问题分析

当gptel以聊天模式运行时（gptel-mode启用），系统会使用特定层级的标题（默认为三级标题）来区分用户输入和AI响应。然而，LLM在生成响应时并不了解这个上下文，经常会使用更高层级的标题（如一级标题），从而破坏文档的逻辑结构。

这个问题源于两个技术细节：

1. 在将对话内容发送给LLM处理时，gptel会剥离标题前缀
2. LLM缺乏关于当前文档标题层级的上下文信息

现有解决方案评估

方案一：调整系统提示

通过定制gptel-directives，可以在系统消息中加入当前模式和标题层级信息。这种方法对大模型（如GPT-4）可能有效，但对小模型效果不佳。

(setf (alist-get 'default gptel-directives)
      (lambda ()
        (concat
         "You are a large language model living in Emacs..."
         (when gptel-mode 
           (format "Current mode: %s, your response will be prefixed with '%s'"
                   (symbol-name major-mode)
                   (cdr (assoc major-mode gptel-response-prefix-alist))))))

方案二：后处理修正

更可靠的方案是在响应返回后进行处理。通过gptel-post-response-functions钩子，可以自动调整或移除响应中的标题：

(defun my/gptel-remove-headings (beg end)
  (when (derived-mode-p 'org-mode)
    (save-excursion
      (goto-char beg)
      (while (re-search-forward org-heading-regexp end t)
        ;; 转换标题为加粗文本
        (forward-line 0)
        (delete-char (1+ (length (match-string 1))))
        (insert-and-inherit "*")
        (end-of-line)
        (skip-chars-backward " \t\r")
        (insert-and-inherit "*")))))

(add-hook 'gptel-post-response-functions #'my/gptel-remove-headings)

进阶解决方案

对于希望保留文档结构完整性的高级用户，可以考虑完全放弃使用标题作为对话分隔符，转而使用自定义前缀：

(let ((prompt-prefix "@You:\n\n")
      (response-prefix "@AI:\n\n"))
  (setq gptel-prompt-prefix-alist 
        `((markdown-mode . ,prompt-prefix)
          (org-mode . ,prompt-prefix)
          (text-mode . ,prompt-prefix)))
  (setq gptel-response-prefix-alist 
        `((markdown-mode . ,response-prefix)
          (org-mode . ,response-prefix)
          (text-mode . ,response-prefix)))
  
  ;; 添加自定义外观
  (defface my/gptel-prefix-face
    '((t (:foreground "color" :weight bold :height 1.2 :inverse-video t)))
    "Custom face for gptel prefixes")
  
  (defun my/gptel-setup-font-lock ()
    (font-lock-add-keywords
     nil
     `((,(concat "^" (string-trim-right prompt-prefix) "\s*$") 
        . 'my/gptel-prefix-face)
       (,(concat "^" (string-trim-right response-prefix) "\s*$") 
        . 'my/gptel-prefix-face))))
  (add-hook 'gptel-mode-hook #'my/gptel-setup-font-lock))

最佳实践建议

1. 明确需求：如果文档结构比对话格式更重要，考虑使用自定义前缀而非标题
2. 模型选择：大模型对结构化提示响应更好，但需要更多token
3. 后处理优先：相比依赖LLM的正确行为，后处理更可靠
4. 测试验证：不同模型对结构化提示的响应差异很大，需要实际测试

技术深度分析

这个问题的本质是上下文丢失和语义理解偏差。LLM在生成响应时：

1. 无法感知Emacs缓冲区状态
2. 对Markdown/Org语法只有表面理解
3. 倾向于生成自包含的文档结构

gptel作为中间层，需要在以下方面做出权衡：

• 保留多少原始上下文信息
• 如何处理模型输出的后处理
• 如何平衡自动化与用户控制

未来改进方向

1. 动态上下文注入：在发送给LLM的请求中包含当前标题层级信息
2. 智能后处理：基于文档结构的自动标题层级调整
3. 模式感知：针对不同编辑模式采用不同的处理策略
4. 用户教育：提供更完善的文档说明常见问题解决方案

通过深入理解这些技术细节，用户可以更好地驾驭gptel的强大功能，在保持文档结构完整性的同时享受LLM带来的便利。