# Phase 7: 发送时拼接附件与Skill优先提示词并在消息区过滤 - Context

**Gathered:** 2026-04-17
**Status:** Ready for planning

<domain>
## Phase Boundary

在用户发送消息时，将“附件/引用文件 + 已选 Skill”转换为一段附加指令并拼接到提交给后端的提示词中；同时保证消息区仍只展示用户原始输入，不展示这段拼接指令。

本阶段不新增新的消息协议主结构，不改变现有 `additional_kwargs.files` 的来源语义，只在发送链路中补充“提交态提示词增强”。

</domain>

<decisions>
## Implementation Decisions

### 拼接文案规则
- **D-01:** 统一使用格式：`优先使用【附件1、附件2】和【Skill1、Skill2】`。
- **D-02:** 仅存在一类时只输出该类（仅附件或仅 Skill），两类都为空时不拼接。
- **D-03:** 名称去重后再拼接，顺序固定为“附件 → Skill”。

### 拼接时机与作用域
- **D-04:** 仅在真正提交到后端前拼接，不改输入框内文本。
- **D-05:** 覆盖所有发送入口：发送按钮、回车发送、建议词自动发送。

### 消息区过滤策略
- **D-06:** 采用“提交态增强、展示态原文”策略：
  UI 和消息区始终使用用户原文；仅请求 payload 使用“原文 + 拼接文案”。
- **D-07:** 不采用渲染层二次过滤（避免把拼接后文本写入消息主内容）。

### 数据来源与去重口径
- **D-08:** 附件名使用最终提交文件名（`references + uploads` 汇总后的文件名）。
- **D-09:** Skill 名使用当前选中 Skill tag 的 `title`。
- **D-10:** 去重采用大小写不敏感规则。

### the agent's Discretion
- 拼接文案中附件与 Skill 的最大展示数量（若过长时是否截断与“等N项”策略）。
- “名称标准化”细节（如首尾空白裁剪、重复空格折叠）。
- 内部 helper 命名与模块拆分方式（前提是不改变已锁定行为）。

</decisions>

<canonical_refs>
## Canonical References

**Downstream agents MUST read these before planning or implementing.**

### 阶段边界与既有决策
- `.planning/ROADMAP.md` — Phase 7 条目与边界（发送时拼接 + 消息区不显示）。
- `.planning/STATE.md` — 当前里程碑状态与 Phase 7 演进记录。
- `.planning/PROJECT.md` — 核心原则：保持现有体验并稳定新系统行为。
- `.planning/REQUIREMENTS.md` — 现有约束基线（特别是稳定性与回归要求）。
- `.planning/phases/06-/06-CONTEXT.md` — Phase 6 已锁定的文件引用/提交语义（`additional_kwargs.files`）。

### 发送链路与输入框集成点
- `frontend/src/components/workspace/input-box.tsx` — 输入框提交入口（`handleSubmit`）与 references/selectedSkills 来源。
- `frontend/src/app/workspace/chats/[thread_id]/page.tsx` — 页面级 `handleSubmit` 到 `sendMessage` 的调用边界。
- `frontend/src/core/threads/hooks.ts` — 实际提交到线程流的发送逻辑（payload 组装主入口）。
- `frontend/src/components/ai-elements/prompt-input.tsx` — `PromptInputMessage` 结构与表单提交机制。

### 消息展示与文件渲染链路
- `frontend/src/components/workspace/messages/message-list-item.tsx` — 人类消息展示内容与附件列表渲染逻辑。
- `frontend/src/core/threads/submit-files.ts` — references/uploads 汇总为 `additional_kwargs.files` 的归一化逻辑。

</canonical_refs>

<code_context>
## Existing Code Insights

### Reusable Assets
- `InputBox.handleSubmit` 已是发送前最后一层前端聚合点，可在此构建“提交态增强文案”。
- `useThreadStream.sendMessage` 已集中处理 payload 发送，可作为最终拼接注入点。
- `PromptInputMessage` 与 `message.references` 已具备附件/引用上下文，不需要新增输入结构。
- `useIframeSkill` 暴露 `selectedSkills`（含 `title`），可直接提供 Skill 名来源。

### Established Patterns
- 文件信息通过 `additional_kwargs.files` 单一 envelope 传递，消息正文与文件元数据分离。
- 人类消息展示默认使用 `rawContent`（并对 `<uploaded_files>` 标签做兼容剥离），适合维持“展示态原文”。
- 错误处理采用软失败 + toast，不阻断主发送链路。

### Integration Points
- 入口：`input-box.tsx` 的 `handleSubmit`（拿到原文、references、selectedSkills）。
- 提交：`core/threads/hooks.ts` 的 `sendMessage`（对后端 payload 的最终写入点）。
- 展示：`message-list-item.tsx`（保持仅展示用户原文，不反显拼接提示）。

</code_context>

<specifics>
## Specific Ideas

- 拼接模板固定为：`优先使用【附件...】和【Skill...】`，并按“附件→Skill”顺序输出。
- 覆盖建议词自动发送路径，避免不同发送入口行为不一致。
- 消息区不做“后置过滤黑科技”，而是从源头保证展示内容就是原文。

</specifics>

<deferred>
## Deferred Ideas

- 按模型能力动态调整拼接策略（如不同模型使用不同提示语模板）。
- 将“优先使用”文案国际化为多语言可配置模板。
- 在 UI 中显式展示“将附加系统提示”的可见开关。

</deferred>

---

*Phase: 07-phase-06-mention-upload*
*Context gathered: 2026-04-17*