系统提示词与任务拆解

学习目标

• 理解系统提示词和用户提示词的边界。
• 能把复杂任务拆成可执行、可验证的步骤。
• 能区分模型职责和程序职责。

核心概念

系统提示词适合放稳定规则：产品身份、回答边界、禁止行为、输出风格和高层处理原则。用户消息适合放本次任务输入。检索内容和业务数据应该作为上下文传入，而不是硬编码进系统提示词。

任务拆解是把一个大目标分成多个小判断。例如“帮我处理客户投诉”可以拆成识别问题类型、提取证据、判断紧急程度、生成回复草稿、标记是否需要人工介入。每一步都有输入、输出和验收标准。

好的拆解会减少模型一次性处理所有事情的压力，也让程序可以在步骤之间做校验、分支和重试。

示例与拆解

业务需求：

复制
当用户提交投诉时，人工智能需要判断问题、给出回复草稿，并决定是否升级给人工客服。

可以拆成：

复制
1[
2  {"step": "classify_issue", "owner": "model", "output": "category, urgency"},
3  {"step": "extract_evidence", "owner": "model", "output": "quoted_evidence"},
4  {"step": "validate_category", "owner": "program", "output": "valid_or_reject"},
5  {"step": "draft_reply", "owner": "model", "output": "reply_text"},
6  {"step": "escalate_if_needed", "owner": "program", "output": "route_to_human"}
7]

系统提示词可以保持稳定：

复制
你是客服工单助手。必须基于用户原文提取证据，不得编造政策。涉及退款、法律威胁或账号安全时，必须建议人工介入。

具体投诉内容则作为本次输入传入。

常见误区

• 误区一：把所有业务数据写进系统提示词。这样难维护，也容易过期。
• 误区二：拆解过细。每一步都调用模型会增加成本和延迟。
• 误区三：让模型执行确定性动作。例如真实退款、删除数据、发送邮件应由程序和权限控制。

小练习

把“自动审查项目提交并给出反馈”拆成 4 到 6 个步骤，标注每一步由模型还是程序负责。

实操检查点

为每一步补齐输入、输出和失败处理。只写步骤名称还不够，因为后续工作流编排要依赖这些边界。

复制
1{
2  "step": "review_with_rubric",
3  "owner": "model",
4  "input": "项目说明、提交说明、评分 rubric",
5  "output": "score, strengths, issues, next_actions",
6  "failure_handling": "JSON 校验失败时重试一次，仍失败则转人工"
7}

随堂测验

完成本章测验，重点检查你能否正确划分系统提示词、任务输入和程序控制。

本章总结

系统提示词定义稳定行为边界，任务拆解把复杂目标变成可验证步骤。人工智能工作流的稳定性来自清晰职责，而不是一次超长提示词。

下一步学习指引

下一章学习少样本示例和模板化，让提示词在重复业务场景中更稳定。