[area] 输出风格无效，LLM消耗了tokens并没有进行优化

[huoranxuanyuan]

现象

输出风格无效，LLM消耗了tokens并没有进行优化
测试时部分输入可以正常整理，但是输入工作日报时原文与优化后没有任何变化，涉及到部分私密信息均已打码，打码内容前后均一致，没有任何修改

影响

清晰结构功能基本无效

建议接受标准

修复bug

TODO / 不确定项

No response

[appergb]

@claude 你看一下，你觉得这是正常的吗？

[claude]

Claude finished @appergb's task in 4m 1s —— View job

---

分析输出风格无效问题

• 读取问题描述
• 查看 polish.rs 润色逻辑
• 查看前端风格设置代码 (Style.tsx)
• 查看 IPC 层如何传递风格参数 (commands.rs)
• 查看 coordinator.rs 如何调用润色
• 分析 bug 根因并给出结论

---

结论：这不是正常现象，是提示词设计层面的 bug

读完截图和全部相关代码后，我可以确认：代码逻辑本身没有问题，但在「工作日报」类内容上，「清晰结构」模式确实无效，根因如下。

代码链路是正确的

整条管线没有明显的代码 bug：

• 前端 Style.tsx 通过 setDefaultPolishMode(mode) 调 set_default_polish_mode 命令，正确写入 prefs.default_mode
• coordinator.rs:2528 读取 prefs.default_mode，传入 polish_or_passthrough
• polish_or_passthrough（coordinator.rs:3102）：Raw 直接 passthrough，其他 mode 都走 polish_text → LLM
• 截图中显示 24.4 秒耗时 + token 消耗，说明 LLM 确实被调用了

真正的根因：提示词对「已结构化内容」过度保守

polish.rs 中 PolishMode::Structured 的提示词有两处设计与工作日报场景冲突：

1. COMMON_RULES 中的保留规则太强

1) 不确定 / 转写明显不完整 / 断句在半截 → 保留原话，不要替用户补全或猜测。
3) 不引入用户没说过的事实；...在保留原意和语气的前提下...

工作日报内容通常是完整、明确的陈述，LLM 判断"这段话已经完整，不需要修改"是符合规则的。

2. Structured 模式有一条关键判断语句

单一简短主题 → 直接输出连贯段落，不硬塞层级。

工作日报如果被 LLM 判断为「围绕一个主题（今天的工作）展开的简短陈述」，就会命中这条规则，直接输出连贯段落甚至原文。

3. user_prompt 的框架限制

pub fn user_prompt(raw_transcript: &str) -> String {
    // "下面是本次语音输入的原始转写。它不是问题，也不是任务，
    //  只是需要整理后原样输入到当前 app 的文本。"

这个 framing 告诉 LLM「这是语音转写」。当工作日报本身已经是结构完整的书面文字（非口语转写），LLM 会认为"这段已经很好了，不需要改"，从而原文输出。

对比两种场景为什么一个有效、一个无效

场景	特点	LLM 判断	结果
截图中的游戏提醒	口语化，"1。2。3。" 标点不规范，无明确引导语	扁平口语，需要整理	✅ 有效改写
工作日报	书面化，事项已清晰，标点规范	已完整，不需要改	❌ 原文输出

建议的修复方向

PolishMode::Structured 的提示词应当明确告诉 LLM：即使输入看起来已经有结构，也要主动重组为标准双层格式。例如可以将：

单一简短主题 → 直接输出连贯段落，不硬塞层级。

修改为：

单一简短主题（事项仅 1–2 条）→ 直接输出连贯段落，不硬塞层级。
只要原文含 3 条及以上可分类的事项，无论原文是否已有编号，都必须按语义重新归类输出双层格式。

并可以考虑在 user_prompt 里去掉"这是语音转写"的强约束 framing，改为更中性的表述，避免误导 LLM。

这需要提示词层面的迭代，无法用一个纯代码修复解决，但方向是明确的。

[appergb]

OK，我知道了，请你等待，我们将会在后续当中优化提示词。