提示词编写指南

一、核心理念

平台 Agent ≠ ChatGPT

平台 Agent 拥有工具调用能力——它可以主动检索知识库、翻页阅读文档、生成文件、编辑二进制文档。 更重要的是，平台内置了Skill 技能系统，Agent 能调用专业技能来完成特定领域的复杂任务。

提示词不是越长越好

本手册列出了十大技法，但绝大多数场景不需要全部用上。Agent 本身有不错的理解和规划能力，很多简单任务一两句话就能做好。

简单任务示例——以下提示词已经足够：

帮我看看知识库「需求分析验证」里这两个文档的主要差异，重点关注驾驶模式相关的需求。

/document-editing /docx
把知识库里那个 EEA 文档的每个子需求加上编号，格式是 GAC_{功能名}_{序号}。

什么时候需要写得更细？ 当你发现 Agent 跑完一遍之后：

• 漏了文档没读 → 加"逐个文档扫描"的约束
• 编号格式不对 → 加精确的格式规则和示例
• 对比太粗糙 → 加对比维度清单
• 中间丢了进度 → 加分阶段落盘

核心原则：先用简单提示词跑一遍，不满意再针对性加约束。 本手册里的技法是你的"工具箱"，按需取用，不是每次都要全套上。

二、Skill 技能系统——平台的"专家模块"

什么是 Skill？

Skill 是平台预置的专业能力包。每个 Skill 封装了特定领域的操作流程和专业知识。用户在提示词开头用 /skill名 触发，Agent 就会按照该 Skill 的专业流程来执行任务。

常用 Skill 速查

怎么在提示词中触发 Skill？

在消息开头加上 Skill 标记即可：

/document-editing /docx

任务：为 EEA 文档中的每个子需求项添加唯一编号……

Skill 可以组合使用——上面的例子同时触发了 document-editing（负责知识库文档检索定位）和 docx（负责 Word 文档的 XML 级别编辑）。它们的分工：

简单说：document-editing 负责"找到位置"，docx 负责"修改内容"。

什么时候需要触发 Skill？

三、十大核心技法

先看这里：不是每个技法都要用到

下面的技法按"什么时候真的需要写这么细"分成了三个等级：

经验法则：

• 2-3 个文档的简单分析 → 一段话描述清楚任务 + 指定知识库就够了，Agent 自己能搞定
• 10+ 个文档的系统对比 → 需要用上分阶段、索引表、落盘等技法
• 编号/格式化/超链接等精确操作 → 规则必须写死，否则 Agent 会自作主张
• 一次性的探索分析 → 先用简单提示词跑一遍，看哪里不满意再针对性加约束

技法 1：先总结建索引，再精确对比 🟡

详细度建议：2-3 个短文档直接让 Agent 对比就行，不需要先建索引。5 个以上文档、或单个文档超过 50 页时，建索引的收益才明显。

问题：10 份文档，每份几十上百页，Agent 的上下文窗口不可能一次放下全部内容。直接让 AI "对比所有文档" → 必然丢信息。

解法：分两步走——

第一步：逐文档扫描，生成带"定位信息"的摘要索引

让 Agent 逐个文档读取（可以分页翻读），对每个文档输出一份"摘要条目表"，每条摘要必须包含：

• 条目名称（如"驾驶模式默认值"）
• 条目属于哪个功能模块
• 来源定位信息（文档名 + chunk_id）

这样做的目的是：把散落在几百个 chunk 里的信息，压缩成一张结构化的索引表，但不丢失回溯路径。

提示词写法示例：

逐个文档做完整扫描，一个文档全部读完再读下一个。
每个文档读完后，提取以下信息并保存为索引表：

| 文档名 | 功能模块 | 条目名称 | chunk_ids | 分类维度 |

⚠️ chunk_ids 是后续精确回查的关键，必须记录。
⚠️ 每个文档全部读完再开始下一个，不能只读开头就跳过。

第二步：基于索引表做横向对比

有了索引表，Agent 就知道"驾驶模式默认值"这个条目在 10 个文档中各自出现在哪个 chunk。需要对比时，用 list_chunks(chunk_ids=...) 精确取回原文，不需要重新全文搜索。

提示词写法示例：

基于索引表，对每个需求条目做横向对比：
1. 从索引表取出该条目在各文档中的 chunk_ids
2. 用 list_chunks(chunk_ids=..., window=5) 取回完整上下文
3. 逐文档比对描述差异，填写对比表

每条对比必须标注来源引用（文档名 + chunk_id），不能凭记忆概括。

为什么这样比"直接对比"好？

技法 2：分阶段执行 + 中间落盘 🟡

详细度建议：如果任务 3-5 轮就能完成，不需要刻意分阶段。任务预计超过 10 轮、或中间有明确的"里程碑产物"时，分阶段 + 落盘才有意义。

问题：复杂任务（如分析 10 个文档的需求差异）可能需要 Agent 执行几十轮。如果不分阶段，一旦中间出错，所有工作白费。

解法：把任务拆成明确的阶段，每个阶段完成后立即用 write_file 保存中间产物。

提示词写法示例：

⚠️ 每完成一个阶段，先用 write_file 落盘产物，再继续下一阶段。

阶段 1：方法论提取（1 轮）
  1. 读取方法论文档，提炼分析框架
  2. write_file → 方法论摘要.md

阶段 2：全量文档扫描（3-5 轮）
  1. 逐个文档扫描，建立索引
  2. write_file → 文档索引表.md

阶段 3：逐组对比分析（多轮）
  1. 对每个对比组执行穿透分析
  2. 每完成一个对比组，立即 write_file 落盘

阶段 4：汇总报告生成（1 轮）
  1. 用 execute_code 生成 Excel 报告

关键细节：

• 阶段间传递上下文：后续阶段开始前，让 Agent 先 read_file 读取前一阶段的产物。这样即使中间 Agent 上下文被压缩，也不会丢失关键信息。
• 进度追踪：对于批量任务，让 Agent 维护一个待办清单，标记每个子任务的完成状态。

开始前，列出所有对比组 ID 作为待办清单。
每完成一个对比组并 write_file 后，更新清单状态（✅/⏳）。
每轮输出结尾报告进度：「已完成 M/N 个对比组」。
清单全部 ✅ 才能进入下一阶段。

技法 3：横向交叉提取——从 N 个文档中抽出相同条目 🟡

详细度建议：两个文档之间找对应关系，Agent 通常自己能搞定，只需告诉它"对比这两个文档"。文档数量多（5+）或文档结构差异大时，才需要明确写出"确定基准 → 搜索匹配 → 反向检查"的流程。

问题：10 个文档里都有"驾驶模式"相关的描述，但每个文档的章节结构、命名方式、粒度都不一样。怎么让 Agent 把这些"对应"的内容找出来？

解法：三步走——确定基准 → 语义搜索匹配 → 上下文验证。

步骤 1：确定基准文档

从所有文档中选一个"条目最全"的作为基准（比如内部需求规格书），以它的条目列表为锚点。

确定基准文档：
- 优先：内部 CTS → 外部 CTS → 条目最多的文档

步骤 2：逐条语义搜索

对基准文档中的每个条目，到其他文档中做语义搜索。注意：不能只按标题做精确匹配，因为不同文档对同一功能的命名可能不同。

对每个需求条目，在其他文档中查找对应描述：

a. 精确读取（优先）：如果索引表中已记录 chunk_ids，
   直接用 list_chunks(chunk_ids=...) 取回

b. 搜索匹配（兜底）：如果索引表中没有对应记录，
   用 search(query=需求关键词描述, doc_ids=对应文档) 查找
   ⚠️ query 要用自然语言句子，不要拆成关键词
   ⚠️ 用 top_k≥5，不要假设都是一对一关系

c. 上下文验证：对搜索命中的 chunk，
   用 list_chunks(chunk_ids=..., window=5) 展开前后文确认

步骤 3：反向检查

扫描完基准文档的所有条目后，还要反过来检查——其他文档中是否有基准文档没覆盖的条目？

反向检查：扫描其他文档，
找出基准文档未覆盖但这些文档有的条目 → 标记为"新增/建议补充"

技法 4：维度发现——让 AI 自己从文档中发现分类体系 🟢

详细度建议：只有当文档存在多个平行分类（如同时按车型、架构、动力类型区分）时才需要。如果文档结构简单、没有交叉分类，这个技法可以跳过。

问题：汽车行业文档通常按多个维度分类（车型平台、电子架构、动力类型……），如果提示词里预设了维度，可能漏掉文档中实际存在的新维度；如果不指定，AI 可能随意混淆。

解法：告诉 Agent"从文档中发现维度，不要预设"，但给出参考示例帮助理解。

提示词写法示例：

发现需求的分类维度：
这是本阶段最关键的一步。
同一个功能在文档中可能按某些维度区分成多个变体。
你需要发现这些分类维度。

常见维度举例（仅供参考，以实际文档为准）：
  - 车型平台（AH8 / A8R / A5R ……）
  - 电子电气架构（EEA2.5 / EEA3.0 ……）
  - 动力类型（燃油 / 混动 / 纯电 ……）
  - ……可能还有其他

不要猜测，只记录文档中实际出现的维度和对应的值。

为什么要发现维度？

因为对比必须在同一维度值下进行。比如 AH8 的驾驶模式和 A8R 的驾驶模式是不同的东西，不能放在一起对比。维度发现后，后续所有分析都要遵循。

核心原则：必须在同一维度值下对比，不跨维度值比较。
不同动力类型的信号是不同的（如 EV 的 VCU 信号 vs PHEV 的发动机信号），
不能混在一起比。发现的每个分类维度在分析时都要贯彻到底。

技法 5：强制引用溯源——每条结论都必须有出处 🟡

详细度建议：日常探索性分析（"帮我看看这个文档讲了什么"）不需要强制引用。但如果分析结果要交付给他人审阅、或者作为正式报告，引用溯源就很重要——没有出处的结论无法验证。

问题：AI 容易"凭印象概括"——看了一堆文档后，输出的结论既没有来源，也无法验证。

解法：在提示词中明确要求每条结论都必须附带引用。

提示词写法示例：

⚠️ 核心约束（每一步都必须遵守）：
- 每条结论必须标注引用（文档名 + chunk_id + 原文摘录）
- 禁止从 text chunk 凭印象概括
- 如果某条目只有文字描述没有数据支撑，标注「无数据，仅文字描述」

引用格式建议统一：

差异说明：默认驾驶模式不一致
  - 文档 A：标准模式 (CTS.docx, chunk_id: a1b2c3, 原文："默认驾驶模式为标准模式")
  - 文档 B：ECO 模式 (内部CTS.docx, chunk_id: d4e5f6, 原文："默认值=ECO")

这样做的好处：

1. 可审计——用户看到结论可以直接通过 chunk_id 回查原文
2. 防幻觉——Agent 必须真的读过才能写出 chunk_id
3. 可迭代——发现引用有误时，可以快速定位修正

技法 6：对比粒度控制——告诉 AI 到底要比什么 🟡

详细度建议：如果只是想快速了解"两个文档大体上有什么不同"，不用写对比维度清单，Agent 会自动做高层级概述。但如果需要信号级、参数级的细致对比，就必须明确告诉 Agent 要比哪些维度——不说它就不会主动深入。

问题：AI 默认会做高层级的功能对比（"两个文档都有驾驶模式功能"），但真正有价值的是细节层面的差异。

解法：在提示词中明确列出对比维度清单。

提示词写法示例：

⚠️ 对比粒度要够细，不能只比功能描述，还要对比：
- 涉及的信号定义（输入/输出信号名、收发规则、发送类型、解析逻辑）
- 配置参数（配置码、下线配置、诊断配置）
- 默认值和恢复出厂设置值
- 选项集合（数量、具体取值、排列顺序）
- 触发条件和状态转换逻辑
- 阈值和参数范围

这些细节层面的不一致往往是实际开发中最容易出问题的地方。

同时定义差异分类标签，让结果更结构化：

差异类型标签：
- 一致：描述完全对齐
- 细化：A 比 B 更详细
- 简化：A 比 B 更简略
- 缺失：某个文档完全没有该条目
- 冲突：同一条目在不同文档中描述矛盾
- 新增：某个文档有而基准文档没有的条目

技法 7：二进制文档编辑——知识库文档的完整编辑闭环 🔴

详细度建议：只要涉及修改知识库中的 Word/Excel/PPT，这个流程必须遵守——不是写不写的问题，而是 /document-editing Skill 本身就会按这个流程走。用户需要理解这个流程，才能在出问题时知道是哪一步有问题。

问题：知识库中的 Word/Excel 是二进制文件，不能直接用文本编辑器改。而且编辑后如果不更新 ES 索引，后续搜索就找不到新内容。

解法：遵循平台的 Copy → Edit → Snapshot → Verify 四步闭环。

提示词写法示例：

/document-editing /docx

步骤：
1. copy_kb_document 将知识库文档拷贝到 workspace
2. 用 ES 检索定位要修改的位置（unified_search）
3. execute_code 编辑文档 → write_file_bytes 保存
4. snapshot_and_index 创建 ES 快照（⚠️ 必须，否则后续搜不到）
5. 用新 ws_doc_id 抽样搜索验证修改正确

关键概念：ES-first 原则

知识库中的二进制文档已经被 DeepDoc 解析成了 chunks 并索引到了 ES（Elasticsearch）。读取这些文档的内容时，必须优先用 ES 检索，不要用 read_file。

关键概念：snapshot_and_index

每次编辑产出新文件后，必须调用 snapshot_and_index 创建 ES 快照。不做这步 = 后续 Agent 搜索不到新文件的内容。

execute_code → write_file_bytes（文件存到 MinIO）
    ↓
snapshot_and_index（创建 ES 索引 → 拿到新 ws_doc_id）
    ↓
用新 ws_doc_id 搜索验证

⚠️ 多步编辑时每步都要 snapshot：如果任务分为"编号 → 超链接 → 格式化"三步，每步产出新文件后都要 snapshot_and_index，不能只在最后一步做。

技法 8：多任务串联——前置任务的输出是后续任务的输入 🔴

详细度建议：只要有两个以上任务存在先后依赖，必须写清楚输入输出路径和依赖关系。这不是"可选的细节"——不写的话，Agent 很可能在任务二中重新做一遍任务一已经完成的工作，或者找错文件。

问题：复杂项目往往需要多个任务串联执行，后面的任务依赖前面任务的产出物。如果不明确标注依赖关系和文件路径，Agent 容易搞混。

解法：在提示词中明确标注每个任务的输入/输出文件路径，以及任务间的依赖关系。

提示词写法示例：

任务一：需求文档编号

文档路径
- 输入: EEA3.0组合仪表_V3.4.docx
- 输出: EEA3.0组合仪表_V3.4_numbered.docx

---

任务二：需求文档交叉引用

前提：必须使用任务一输出的已编号文档（_numbered.docx），
      不要对文档重新编号。

文档路径
- 输入:
  - GAC_系统需求规格书_V6.5.docx
  - EEA3.0组合仪表_V3.4_numbered.docx（任务一的输出）
- 输出:
  - GAC_系统需求规格书_V6.5_linked.docx
  - EEA3.0组合仪表_V3.4_linked.docx
  - 需求映射表.xlsx

命名约定：用后缀区分版本——_numbered（已编号）、_linked（已加超链接）、_highlighted（已高亮）。这样每个中间版本都可追溯。

核心要点：

• 明确标注"前提"：防止 Agent 在任务二中重复做任务一的工作
• 写明文件路径：输入输出都列清楚，Agent 不需要猜
• 禁止篡改前置产物：任务二"只添加超链接，不要修改编号或文本内容"

技法 9：操作类任务的精确规则定义 🔴

详细度建议：编号、格式化、超链接等"操作类"任务，规则必须写死。这是所有技法中最不能偷懒的一个——分析类任务 Agent 说错了你还能看出来修正，操作类任务做错了可能批量污染几百个条目，很难发现。

问题：编号、标注、格式化等"操作类"任务（区别于"分析类"），需要极其精确的规则定义。稍有模糊，Agent 就会自作主张。

解法：用"格式 + 范围 + 排除 + 计数规则 + 示例"五要素定义操作规则。

提示词写法示例（编号规则）：

编号规则

- 格式: GAC_{一级功能名称}_{序号}
- 只编号 X.X 级别的子需求标题（如 3.1, 3.2），不编号 X.X.X 或更深层级
- 不编号目录页、一级标题、详细描述段落
- 每个一级功能下的子需求从 01 开始独立计数
- 编号添加在正文中子需求标题的末尾，不要修改目录

示例
  原文:
  3. 外灯系统与信息娱乐系统(IDC仪表)交互需求
    3.1. 前雾灯指示灯
  编号后:
  3. 外灯系统与信息娱乐系统(IDC仪表)交互需求
    3.1. 前雾灯指示灯 (GAC_外灯系统与信息娱乐系统(IDC仪表)_01)

五要素拆解：

提示词写法示例（映射规则）：

匹配规则

根据需求名称和内容语义匹配：
- 一对一：完全对应的需求
- 一对多：一个外部需求对应多个内部需求
- 多对一：多个外部需求对应一个内部需求

映射示例
  GAC文档: SYNCORE_IDC_告警与指示灯_FUNC_0007
     ↕ (双向超链接)
  EEA文档: GAC_外灯系统与信息娱乐系统(IDC仪表)_01

技法 10：验证闭环——编辑完必须用 ES 抽样检查 🟡

详细度建议：Agent 默认会做基本的代码级验证（assert 计数等）。如果你对结果精度要求高（比如编号要绝对准确、超链接不能错位），在提示词中加上验证步骤可以让 Agent 自查。日常不太要紧的编辑可以省掉这一步，自己打开文件看一眼就行。

问题：代码执行（批量编号、创建超链接、格式修改）容易出现 off-by-one、匹配遗漏、映射错位等 bug。如果不验证就交付，用户拿到的可能是错误的产物。

解法：在提示词中明确写出验证步骤和验证标准。

提示词写法示例：

验证要求

1. 用 ES 搜索第一个和最后一个编号，确认序号连续、没有偏移
   search(query="GAC_外灯系统_01", doc_ids="new_ws_doc_id")
   → 期望返回"前雾灯指示灯"相关 chunk

2. GAC 文档中点击 FUNC_XXXX → 应跳转到 EEA 文档对应需求

3. EEA 文档中点击 GAC_编号 → 应跳转到 GAC 文档对应位置

4. 两份文档放同一文件夹后链接可正常跳转

为什么不能只靠代码内部验证？

代码可以 assert 检查行数/计数，但无法验证语义正确性（编号是否对应到了正确的需求项、超链接是否指向了正确的位置）。ES 搜索是唯一能从"用户视角"验证内容的方式。

四、提示词结构模板

模板 A：分析对比类（读文档 → 出报告）

角色
  你是 [具体领域] 的 [具体角色]。

任务
  用知识库「XXX」中的 [方法/标准]，分析知识库「YYY」中的 [目标文档]。

核心原则
  1. [分析约束，如"同维度对比"]
  2. [引用要求，如"每条结论标注来源"]
  3. [质量要求，如"分析粒度到最小层级"]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阶段 1：[名称]（预估轮数）
  步骤：
    1. [具体操作，包括用哪个工具]
    2. [具体操作]
  输出产物：[文件名]
  ⚠️ 完成后用 write_file 保存

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阶段 2：[名称]（预估轮数）
  ⚠️ 开始前先 read_file 读取阶段 1 产物
  步骤：
    1. [具体操作]
  输出产物：[文件名]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阶段 N：汇总报告
  用 execute_code 生成最终报告（Excel/Word）
  报告结构：[Sheet/章节说明]
  质量要求：[具体标准]

模板 B：文档编辑类（改知识库中的文档）

/document-editing /docx

任务一：[操作名称]

[操作规则]
- 格式: [具体格式]
- 范围: [哪些内容要操作]
- 排除: [哪些内容不操作]
- 计数/匹配规则: [具体规则]

示例
  原文: [修改前]
  修改后: [修改后]

文档路径
- 输入: [源文件名.docx]
- 输出: [源文件名_后缀.docx]

验证要求
  [如何验证结果正确]

---

任务二：[操作名称]

前提：必须使用任务一输出的 [_后缀.docx]，不要 [重复之前的操作]。

重要约束
- [明确禁止的操作，防止 Agent 篡改前置产物]

[操作规则]
- [具体规则]

文档路径
- 输入:
  - [文件A.docx]
  - [任务一的输出文件.docx]（任务一的输出）
- 输出:
  - [文件A_后缀.docx]
  - [文件B_后缀.docx]
  - [映射表.xlsx]

验证要求
  [如何验证结果正确]

五、常见反模式（写提示词的坑）

反模式 0：不触发 Skill 就让 Agent 编辑文档

❌ "帮我修改知识库里这个 Word 文档的第三章"

Agent 没有被激活 document-editing 技能，会尝试用 read_file 读取整个二进制文件（乱码），或者用 execute_code 从头写一个新文件（丢失原有格式）。

✅ /document-editing /docx
   修改知识库中 EEA 文档第三章的标题格式……

反模式 1：一句话提示词

❌ "帮我对比一下这几个文档的差异"

Agent 会随机挑几段对比，不完整、不可控。

✅ 按本手册的结构，分阶段、分步骤地描述任务。

反模式 2：不指定知识库范围

❌ "搜索驾驶模式相关的内容"

Agent 会搜索所有知识库，结果稀释。

✅ "在知识库「需求分析验证」中搜索驾驶模式相关的内容"
   或：search(query="驾驶模式设置功能", kb_ids="需求分析验证")

反模式 3：不要求保存中间结果

❌ 让 Agent 一口气分析完 10 个文档再出报告

中间任何一步出问题都会导致后续结果不可信。

✅ 每完成一个子任务（每个文档/每个对比组），立即 write_file 保存。

反模式 4：让 AI 凭记忆比对

❌ "根据你刚才读的文档，总结差异"

Agent 的上下文会被压缩，"刚才读的"内容可能已经丢失。

✅ 需要对比时，重新用 list_chunks(chunk_ids=...) 取回原文，
   不能依赖之前轮次的记忆。

反模式 5：不控制对比粒度

❌ "对比两个文档的差异"

Agent 会做高层级概述（"两者都有驾驶模式功能，A 多了几个选项"）。

✅ 明确列出对比维度：信号定义、配置参数、默认值、触发条件……

反模式 6：关键词碎片化搜索

❌ search(query="灯光 故障 报警 位置灯")

把关键词拆开会破坏向量检索的语义质量。

✅ search(query="灯光故障报警功能，包括位置灯和转向灯故障检测")
   用自然语言整句描述，embedding 质量最高。

六、图片/UI 对比的特殊技法

当任务涉及截图对比（如 HMI 设计稿对比）时，有额外的技法：

1. 先建图片索引再对比

对两个知识库的每个 doc_id 调用 list_chunks，提取所有含 image_url 的图片 chunk。
将每张图归属到功能模块。
跨知识库配对：将 A 和 B 中同一功能模块的图片配对。
落单图片（无法配对）单独列出。

2. 图片描述必须来自 describe_image

⚠️ 所有 UI 描述必须来自 describe_image 的实际图像分析，禁止凭印象概括。
⚠️ 禁止跳过 describe_image 直接写结论。

3. 结构化对比维度

对比这些截图，按以下维度分析：
  1. 布局结构（元素位置、层级、分栏方式）
  2. 交互控件（开关/滑块/选项卡/弹窗的类型和状态）
  3. 信息密度（同一屏展示多少功能项）
  4. 视觉风格（配色、圆角、间距、字号）
  5. 功能差异（A有B无 / B有A无 / 相同功能不同实现）

七、平台工具速查

写提示词时可以引用的工具操作：

检索类（读取文档内容）

文件操作类（生成 / 编辑文件）

Skill 触发

八、完整案例

案例 A：多文档需求差异分析（分析对比类）

角色
  你是汽车 HMI 需求分析专家。

任务
  分析知识库「XXX」中多份需求文档的差异，生成结构化对比报告。

核心原则
  1. 必须在同一维度值下对比，不跨维度值比较
  2. 分类维度从文档中发现，不预设
  3. 每条结论必须标注引用（文档名 + chunk_id + 原文摘录）
  4. 最终输出为 XLSX 报告

⚠️ 每完成一个阶段，先用 write_file 落盘，再继续下一阶段。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阶段 1：全量文档扫描 + 维度发现（3-5 轮）

  目标：读完所有文档，发现分类维度，建立条目索引。

  步骤：
  1. list_documents → 列出所有文档
  2. 逐个文档完整扫描（list_chunks 分页翻读）
  3. 提取：文档类型、功能模块、分类维度、条目→chunk_id 映射

  输出产物：
  - 文档清单表.md
  - 分类维度.md
  - 对比分组矩阵.md
  - 需求索引表.md（条目名 → chunk_ids）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阶段 2：逐组穿透对比（多轮）

  ⚠️ 开始前 read_file 读取阶段 1 产物

  按对比分组矩阵，逐个对比组执行：
  1. 确定基准文档
  2. 从索引表取 chunk_ids → list_chunks 精确取回
  3. 在其他文档中搜索对应条目（search → list_chunks 验证）
  4. 填写对比表，标注差异类型和引用
  5. 反向检查：找出基准未覆盖的条目

  每完成一个对比组 → write_file 落盘
  每轮报告进度：「已完成 M/N 个对比组」

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

阶段 3：汇总报告（1 轮）

  用 execute_code + openpyxl 生成 XLSX：
  - Sheet 1：总览（文档清单 + 维度 + 差异统计）
  - Sheet 2-N：逐对比组分析
  - 末尾 Sheet：缺失清单 + 引用索引

案例 B：需求文档编号 + 交叉引用（文档编辑类）

/document-editing /docx

任务一：需求文档编号

为 EEA 文档中的每个子需求项添加唯一编号。

编号规则
- 格式: GAC_{一级功能名称}_{序号}
- 只编号 X.X 级别的子需求标题，不编号 X.X.X 或更深层级
- 不编号目录页、一级标题、详细描述段落
- 每个一级功能下的子需求从 01 开始独立计数
- 编号添加在正文中子需求标题的末尾，不要修改目录

示例
  原文: 3.1. 前雾灯指示灯
  编号后: 3.1. 前雾灯指示灯 (GAC_外灯系统与信息娱乐系统(IDC仪表)_01)

文档路径
- 输入: EEA3.0组合仪表_V3.4.docx
- 输出: EEA3.0组合仪表_V3.4_numbered.docx

---

任务二：需求文档交叉引用

前提：必须使用任务一输出的 _numbered.docx，不要对文档重新编号。

重要约束
- 只添加超链接，不要修改文档中的编号或文本内容

匹配规则
- 一对一：完全对应的需求
- 一对多：一个外部需求对应多个内部需求
- 多对一：多个外部需求对应一个内部需求

文档路径
- 输入:
  - GAC_系统需求规格书_V6.5.docx
  - EEA3.0组合仪表_V3.4_numbered.docx（任务一的输出）
- 输出:
  - GAC_系统需求规格书_V6.5_linked.docx
  - EEA3.0组合仪表_V3.4_linked.docx
  - 需求映射表.xlsx

验证要求
  1. GAC 文档中点击 FUNC_XXXX → 跳转到 EEA 文档对应需求
  2. EEA 文档中点击 GAC_编号 → 跳转到 GAC 文档对应位置
  3. 两份文档放同一文件夹后链接可正常跳转

九、提示词优化迭代技巧

推荐的迭代方式：从简到繁，逐步加约束。

第一轮：简单提示词
  → 跑一遍，看 Agent 怎么理解你的任务

第二轮：针对性加约束
  → Agent 跳过了某些文档？加 "逐个文档扫描，不能跳过"
  → Agent 对比太粗？加对比维度清单
  → Agent 编号格式不对？加精确规则 + 示例

第三轮：固化为模板
  → 效果满意后，把提示词保存下来，下次类似任务直接复用

具体加约束的手段：

1. 加 ⚠️ 警告——Agent 对带警告符号的指令更敏感，放在容易出错的步骤前
2. 给正例和反例——"不能只写'样式相似'（❌），要写'A 用圆角卡片 B 用直角列表'（✅）"
3. 控制批次大小——如果 Agent 一次处理太多条目会出错，用 每次最多处理 5 个条目 限制
4. 善用分隔符——用 ━━━ 或 ═══ 分隔阶段，让 Agent 清楚地看到任务边界
5. 不要一次加太多约束——每轮只针对上一轮发现的问题加 1-2 条，加太多反而让 Agent 顾此失彼