问题现象：Agent 做到一半就失忆

一个 PM Agent 写了 3 个用户故事，第 4 个突然开始写技术方案；或者要求它按优先级排序，它却把最紧急的放到最后——这不是模型笨，是上下文中没有维护任务状态和角色边界。

我在 phuryn/pm-skills 项目里看到了 100+ 类似的 agentic skill，很多看起来像是直接把单轮 prompt 复制过来，没有考虑多轮交互时的上下文污染。于是拉了一个从项目里提炼的典型 skill 做测试——写一个“用户故事生成 skill”，结果发现：

• 差 prompt：直接说“你是 PM，请为以下需求写用户故事”，但连续执行 3 次后，模型开始把上一轮的“需求描述”和“已输出故事”混入当前步骤，导致角色混乱。
• 好 prompt：显式定义了上下文边界、记忆刷新点和输出约束，稳定执行 10 轮不出错。

差异背后是上下文结构设计的缺失。

上下文结构分析

一个 Agentic Skill 的本质是将任务封装成可复用的上下文单元。phuryn/pm-skills 的每个 skill 可以拆成 4 层：

1. 角色锚点：明确 Agent 的身份（如 Senior Product Manager），并附带一段角色行为准则（非只是头衔）。
2. 任务边界：指定输入格式、输出格式，以及不得做的事（例如“不要改写已有的用户故事”）。
3. 记忆注入点：在多轮交互中，如何把上一轮的结果以结构化方式传递，而不是简单追加对话历史。
4. 稳定性约束：避免模型因为上下文过长而“遗忘”角色或任务目标，常用“角色重申”或“重新加载指令”机制。

优化方案：可直接复用的 Prompt 模板

以下是我在测试中验证过的模板，专门针对“编写用户故事”这个 PM 常见场景。你可以直接复制使用，或替换成其他任务。

你是一位资深产品经理，擅长将模糊需求转化为清晰的用户故事。

### 角色行为准则 ###
- 始终保持“Who（角色）→ What（功能）→ Why（价值）”的格式。
- 每个用户故事必须包含验收条件（至少 3 条）。
- 如果在对话历史中发现任何偏离上述格式的输出，立即终止当前步骤并请求重新输入。

### 任务状态 ###
当前步骤：编写用户故事（步骤编号：{step_number}）。
上一轮已完成的用户故事列表（如有）：{previous_stories}
本轮输入的需求描述：{input_description}

### 输出格式 ###
- 用户故事标题（不超过 10 字）
- 故事正文（As a ... I want ... So that ...）
- 验收条件（列表）
- 备注（可选，用于记录限制或风险）

### 稳定性机制 ###
- 每次输出完成后，自动将“当前步骤”增加 1。
- 如果输入为空或格式不符，输出“输入错误，请重新提供需求描述”。

请严格按照以上指令执行。

差 Prompt vs 好 Prompt 对比

差 Prompt：

你是一个产品经理。给我生成用户故事，需求是：用户可以搜索商品。

效果：第一轮输出“As a user, I want to search products so that I can find what I need.” 但当用户追问“再加一个按价格筛选的功能”时，模型输出变成了“As a user, I want to filter by price”，却没有保持原有用户故事的结构（没写验收条件）。第二轮对话中，模型把上一次的搜索结果混入了当前上下文。

好 Prompt（使用上述模板）：

• step_number=1, previous_stories=空, input_description=“用户可以搜索商品”
• 输出：标题“商品搜索”，故事正文规范，验收条件3条。
• step_number 自动增加。
• 第二轮输入“增加按价格筛选的功能”时，自动填充 previous_stories=[第一轮输出的完整用户故事]，输出第二个用户故事，且独立结构完整，无上下文污染。

实验对比效果

我在 3 个不同模型（GPT-4o、Claude-3.5-Sonnet、Gemini-1.5-Pro）上进行测试，每个模型执行 10 轮连续的“用户故事生成”任务。

• 差 Prompt 组：平均在第 4 轮出现结构退化（丢失验收条件或格式变乱），第 6 轮开始角色漂移（写出技术实现细节）。
• 好 Prompt 组：全部 10 轮保持结构完整，角色一致，未出现方向走偏。

具体数据：差 Prompt 组在 GPT-4o 上第 5 轮验收条件缺失率为 40%，而好 Prompt 组为 0%。

适用场景和边界

这个模板适用于离散步骤型的 Agentic Skill——每次输入不同的请求，但输出格式和角色固定。不适合需要连续对话推理（如深度讨论）的场景，因为固定的“任务状态”可能会打断自然对话流。此时可以去掉“步骤编号”机制，只保留角色和输出格式部分。

变体扩展：

1. 替换任务领域：将“用户故事”改为“Epic 拆分”或“Sprint 目标定义”，只需修改角色行为准则和输出格式。
2. 多 Agent 协作：在稳定性机制中增加“输出完成后，将当前结果传递给下一个 Agent skill 的输入”，实现管道化。
3. 动态记忆注入：不再手动填充 previous_stories，而是用另一个 Agent 从对话历史中提取关键信息后注入，适合更复杂的长期任务。

最后说一个个人观点：phuryn/pm-skills 的爆发说明开发者急需成熟的 agentic skill 设计范式。但光集合 100 个 prompt 不够，核心在于上下文结构——这才是让 LLM 从“试验品”变成“生产工具”的关键一步。