pi-prompting

Pi 提示词

当 pi:pi-companion-forwarder 需要请 Pi 帮忙处理复杂的编码或调查任务时，使用此技能。

Pi 会运行用户配置的任意模型。默认情况下，此插件以 DeepSeek V4 为目标模型（审查任务使用 Pro，日常任务使用 Flash）。以下指南假设提示词可能运行在非推理模型（Flash）或推理模型（Pro）上。优先使用具体的编号清单，而非抽象指令——这两类模型都能可靠地遵循清单。

核心规则：

• 每次 Pi 运行优先只处理一个明确的任务。无关的请求应拆分为多次运行。
• 告诉 Pi 怎样才算完成。不要假设它会自行推断期望的最终状态。
• 只要缺乏依据的猜测会降低质量，就明确说明依据规则。
• 使用稳定的 XML 风格标签块，让提示词结构一目了然。
• 保持文字简短。处理流程时，优先使用编号清单，而非段落。

默认提示词模板：

• <task>：具体任务，以及相关的代码仓库或故障背景。包括文件路径。
• <output_contract>（JSON 场景使用 <structured_output_contract>）：规定确切的格式、顺序和简洁程度。
• <grounding_rules>：审查、研究或任何可能产生无依据说法的任务都必须包含。
• <action_safety>：可写入文件的任务必须包含——说明 Pi 可以操作的目录和文件类型。

何时添加其他标签块：

• 编码或调试：添加 <completeness_contract>，列出完成标准（测试通过、lint 无问题、涉及的文件）。
• 审查或对抗式审查：使用随附的 prompts/adversarial-review.md 和 prompts/review.md。不要自行编写另一份审查提示词。
• 研究或推荐任务：添加简短的 <sources> 标签块，列出 Pi 可以查阅的来源。

如何选择提示词形式：

• 如果任务是审查本地 git 更改，请使用内置的 /pi:review 或 /pi:adversarial-review 命令。这些提示词已包含审查约定。
• 如果任务是诊断、规划、研究或实施，且需要更直接地控制提示词，请使用 task。
• 对同一 Pi 会话中的后续指示，请使用 task --resume-last。只发送增量指示，而不是重述整个提示词，除非方向发生了重大变化。

工作规则：

• 明确的提示词约定优于含糊的暗示。
• 默认不要提高推理强度（--effort high）——DeepSeek Flash 不会因此受益，而 DeepSeek Pro 会耗费更长时间。提高强度前，先收紧提示词。
• 对于工具繁多或运行时间较长的任务，请让 Pi 在工作笔记中简要汇报进展，重点说明已取得的成果。
• 让所有说法都有观察到的证据作为依据。如果某项内容是假设，请明确标注。

提示词组装清单：

1. 在 <task> 中定义确切的任务和范围。
2. 说明输出约定——JSON、项目符号列表或普通文本——以及最大长度。
3. 决定 Pi 是否应自行判断并继续，还是应因缺少高风险细节而暂停。
4. 仅在任务需要时添加 <grounding_rules> 和 <action_safety>。
5. 发送提示词前，删除冗余指示。

了解子 Agent 的提示词编写

安装 pi-subagents 后：

• 对于包含并行工作流的任务，在 <task> 之前添加 <available_pi_subagents> 标签块。
• 建议的 Agent 分工：探索使用 scout，网页或文档研究使用 researcher，设计使用 planner，实施使用 worker，代码审查使用 reviewer。
• 对抗式审查或停止审查门禁提示词中，绝不要建议使用子 Agent（这些任务需要确定性行为）。
• 该标签块只是建议，并非命令——是否委派由 Pi 决定。
• 对于专门的多任务并行执行，请使用 /pi:parallel-rescue "task1" "task2" ...，而不是手动构造提示词。