面经策

什么是提示词链接？如何实现？ ​

  • 标签：Prompt、提示词链接

🏛 业务架构师 ​

提示词链接（Prompt Chaining）指把一个大任务拆成多个提示词节点串行（或分支）执行，前一节的输出作为后一节的输入——用"流水线"替代"一锤子 mega-prompt"。

实现方式（以 LangChain LCEL 为例）：

python
chain = (
    {"outline": outline_prompt | model | parser}      # 1 生成提纲
    | content_prompt                                   # 2 提纲→正文
    | review_prompt | model                            # 3 审校润色
)

工程上就是"输出解析→注入下一提示的变量"的编排，LangChain 的 SequentialChain/LCEL、LangGraph 都是这个思想的落地。

为什么有效（业务价值）：

  1. 单步简化：每节只解决一件事，指令聚焦、遵循率高——复杂任务"一口气"完成的失败率远高于拆解后接力；
  2. 可插拔质检：节点之间插入校验器（格式检查、事实核对），不合格不往下游传——质量门禁；
  3. 可独立优化：哪个环节弱就单独迭代哪个（各自的提示词、甚至不同的模型——贵的环节用强模型，简单环节用小模型）；
  4. 成本可控：避免 mega-prompt 的冗长上下文每步全量计费。

典型应用：内容生产（提纲→初稿→审校）、数据分析（解读需求→生成 SQL→校验→分析结果）、RAG 后处理（答案生成→引用校验→格式化）。

取舍提醒：链越长延迟和故障点越多——节点数控制在 3~5 个；节点间传"结构化数据"而非自由文本（解析稳定）；全链路要 trace（哪节出问题一目了然）。

🏗 系统架构师 ​

提示词链接（Prompt Chaining）= 把一个大任务拆成多步，前一步的输出作为后一步的输入，串成调用链——每次 LLM 调用只干一件简单确定的事。

实现方式：

text
链1（抽取）：从工单中抽取结构化信息 → JSON
链2（分类）：根据 JSON 判定优先级与路由 → 标签
链3（检索）：按标签检索知识库 → 相关文档
链4（生成）：基于文档生成回复草稿 → 文本
链5（审查）：校验草稿合规性与引用 → 终稿

工程实现：LangChain LCEL 管道（chain1 | chain2 | ...）或 LangGraph 图编排；链间传结构化数据（JSON/Pydantic），每步配 Schema 校验与失败重试。

为什么比单一大 Prompt 好（架构逻辑）：

  • 单步确定性：每步任务简单 → 指令聚焦 → 准确率高；大而全的 Prompt 指令互相稀释；
  • 可观测可归因：每步输入输出可打点，出问题定位到环节（单 Prompt 是黑盒）；
  • 可组合可复用：抽取链、分类链变成组织资产，跨场景组装；
  • 成本可控：每步只带必需上下文（不是全量塞一个大 Prompt）；简单步骤可路由到小模型——模型分级降本；
  • 流程可插入工程逻辑：链间可以插规则、检索、人工审批——确定性代码与模型调用的混合编排。

代价：总延迟累加（N 次串行调用，可用并行化部分缓解）、中间结果质量传导（前步错后步全错——每步要配校验与兜底）。

选型：任务可分解、步骤间有明确数据契约 → 链接；需要模型运行时决定路径 → Agent。链接是"流水线"，Agent 是"循环"——生产系统优先流水线。

💻 全栈开发专家 ​

提示词链接（Prompt Chaining）：把一个大任务拆成串行的多个 prompt，前一个的输出作为后一个的输入——每个 prompt 只干一件事，简单可靠。

为什么有效：单 prompt 干多任务时模型注意力被稀释（顾此失彼）；拆开后每步指令聚焦、中间结果可校验可干预，错误能定位到具体环节。

实现方式（两种）：

1. LCEL 管道（LangChain 内）：

python
# 链1抽取 → 链2生成 → 链3校验
extract = prompt_extract | llm | JsonParser()
compose = (lambda d: prompt_gen.format(**d)) | llm | StrOutputParser()
verify  = (lambda s: prompt_check.format(answer=s)) | llm | JsonParser()

chain = extract | compose | verify

2. 应用层编排（更可控，生产推荐）：每步独立调用，中间落库，失败可重试单步、可人工介入修正中间产物再继续。

设计要点（工程经验）：

  1. 步间契约：上下游用结构化数据（JSON schema）交接，别用自然语言传话（每传一层失真一层）；
  2. 每步带校验：中间输出验证（schema/规则），不合格先重试本步（带错误信息），别让垃圾进下游；
  3. 并行分支：无依赖的步骤并行跑（RunnableParallel），链不等于串行；
  4. 路由链：入口按意图分发到不同链（RunnableBranch）；
  5. 成本账：链式=多次 LLM 调用，延迟相加——只对「单步确实做不好」的任务上链，简单任务单 prompt 更划算。

典型应用：长文摘要（map-reduce）、代码生成（先生成方案→再写码→再自检）、RAG 进阶（先改写query→再检索→再生成→再校验）。