AI工坊AI工坊

1. 官方提示词指南

本章节参考 MiniMax 官方文档编写：

针对 MiniMax M 系列模型（当前最新为 M2.7）的特性，以下提示词撰写规范有助于显著提升输出质量与任务执行准确率，适用于 MiniMax Agent、MiniMax 开放平台 API 及各类编程助手场景。

通用原则

指令明确具体

模型更适合处理目标、约束和输出要求都明确的任务。直接说明要做什么、优先考虑什么，以及什么样的结果才算好。一个简单的检验方法：把 Prompt 给一个完全不了解任务背景的同事看，如果他会困惑，模型也会。

效果欠佳示例：

创建一个可视化网站

效果更佳示例：

创建一个企业级数据可视化网站。

要求：
- 包含图表、筛选器、下钻视图和导出操作。
- 优先满足业务分析师快速浏览数据的需求。
- 使用精致的仪表盘布局，不要做成营销落地页。
- 先返回实现计划，再开始写代码。

补充约束意图

向模型解释某个约束为什么重要时，它更容易做出正确取舍。意图说明尤其适合格式、安全、可访问性和工作流约束。

效果欠佳示例：

禁止使用文档符号

效果更佳示例：

你的回复将由文本转语音模型朗读。请只使用纯文本，避免文档符号，并让句子短一些，保证朗读时自然流畅。

用示例引导输出

精心准备的示例（few-shot 或 multishot prompting）通常比抽象的风格描述更稳定。示例应当相关（贴近真实使用场景）、多样（覆盖边界情况和模糊输入）、具体（展示真实的输出风格，而非仅是话题）。对于分类、结构化抽取、边界情况判断这类任务，建议提供 3-5 个差异化示例。

效果欠佳示例：

将每条工单分类为：bug、需求、咨询。

效果更佳示例：

将每条工单分类为：bug、需求、咨询。

示例：
- "打开设置时应用崩溃" → bug
- "为导出面板添加深色模式" → 需求
- "如何导出为 PDF？" → 咨询
- "申请新的导出选项后崩溃了" → bug（崩溃才是工单本身，需求只是背景）
- "这是预期行为吗？" 无其他细节 → 咨询（未确认前不要归为 bug）

使用模板

对会反复执行的任务，建议将 Prompt 写成带命名变量的可复用模板，便于用同一套 Prompt 测试多组输入、对比版本，并长期保持行为稳定。

效果欠佳示例：

礼貌地回复这条客户投诉。

效果更佳示例：

你是 [产品名] 的客户支持专家。

客户消息：
[客户消息]

可使用的已知事实：
[已知事实]

请写一封回复，要求：
- 第一句先承认客户遇到的问题。
- 只能基于上述已知事实解释下一步处理方式。
- 除非已知事实中明确出现，否则不要承诺补偿、退款或具体时间。
- 结尾给客户一个清晰的下一步动作。

匹配输出语言

当输入是多语言混合，或希望输出固定为某种语言时，请明确说明，例如"即使素材是英文，也请用中文回复"。否则模型通常会跟随主要输入语言。

输出与格式

清晰的段落结构

当 Prompt 中包含指令、素材、示例、约束和输出要求等多类内容时，为每段加上标签让模型区分。粗体标签或带冒号的小标题比连续段落更清晰。

效果欠佳示例：

看看这个发布计划，告诉我哪里需要改进。要实用一点。读者是销售团队。我们关注企业客户和合作伙伴打法。再做个表格。

【很长的发布计划】

效果更佳示例：

任务：审阅发布计划，并找出最值得优先改进的部分。

背景：读者是销售团队。优先关注企业客户和合作伙伴打法。

素材：
【很长的发布计划】

输出格式：
返回表格，列包括：领域、问题、建议、优先级。
每条建议都要可执行，并控制在 40 个汉字以内。

设定角色、格式与长度

角色设定最好同时说明专业背景、工作范围和判断标准。输出要求需明确章节、字段和长度限制，方便人和程序一起校验。

效果欠佳示例：

你是资深工程师。帮我 review 这段代码，简洁一点。

效果更佳示例：

你是资深后端代码 reviewer，重点关注正确性、可靠性和可维护性。

待审阅的 diff：
[diff]

严格按以下结构返回：
1. 摘要 —— 最多 3 条
2. 阻塞问题 —— 表格，列为 文件、风险、修改建议
3. 非阻塞建议 —— 最多 5 条

不要重写整个文件。只提出与该 diff 直接相关的修改建议。

长上下文

Token Plan 模型支持长上下文窗口，输入和输出容量都很大。长上下文效果更好时，通常具备清晰分隔的素材、索引信息，以及放在素材之后的具体任务。

任务放在素材之后

对于长输入，将问题或任务写在素材之后而非之前，任务越靠近模型回答位置，越容易保持关注。在所有长上下文技巧中，把任务放在 Prompt 末尾对回答质量的提升最大。

为素材建索引并分隔

为长素材建立时间或来源索引，并明确分隔不同来源，有助于模型在冲突时优先采用更可信的来源。

效果欠佳示例：

阅读下面所有内容，总结重点。

【很长的会议记录、需求文档、访谈材料和代码片段】

效果更佳示例：

按时间顺序列出素材：

**launch-plan** —— 2026-04-12
【发布计划】

**pricing-notes** —— 2026-04-18
【定价笔记】

**meeting-transcript** —— 2026-04-21
【会议记录】

任务：为发布负责人产出一份管理层简报。如果来源互相冲突，优先采用日期最新的来源，并指出冲突。

输出格式：
- 决策摘要 —— 最多 5 条
- 风险 —— 用表格列出，并标注来源
- 待确认问题 —— 负责人、阻塞点、下一步动作

工具调用

Token Plan 模型支持工具调用。好的工具调用 Prompt 会定义何时使用工具、何时不要使用、以及如何把工具结果合并进最终回答。

工具定义

为每个工具写清楚名称、用途、输入、返回结构和失败处理方式。模型在决定是否调用工具前，应先理解工具契约。

效果欠佳示例：

需要时使用搜索工具。

效果更佳示例：

工具：search_docs

用途：搜索内部文档库，获取产品或政策相关事实。

适合使用：
- 用户询问当前产品行为、限制、价格或发布说明。
- 在做出可能随时间变化的事实判断前，需要来源支撑。

不适合使用：
- 用户只要求改写、排版或头脑风暴。
- 用户提供的上下文已经足以支持回答。

参数：
- query：简洁的关键词查询
- product_area：可选，产品或功能领域

返回：结果列表，每条包含标题、URL、日期和摘要。

失败处理：如果连续两次搜索失败，停止重试，并说明哪些信息无法验证。

并行调用

当多个工具调用彼此独立时，明确要求模型并行调用。只有当一个结果会决定下一次查询或动作时，才保持顺序调用。

效果欠佳示例：

查一下文档、Issue 和更新日志，告诉我这个 bug 有没有修复。

效果更佳示例：

请并行检查以下彼此独立的信息源：
- 文档搜索 —— 当前预期行为
- Issue 搜索 —— 相似 bug 反馈
- 更新日志搜索 —— 近期修复记录

所有结果返回后，再回答：
- 这个 bug 是否已经修复？
- 哪个来源支持该结论？
- 用户下一步应该做什么？

避免过度调用

在 agentic 工作流中需明确停止规则。模型应该在工具能实质提升回答质量时使用工具，而不是为了显得忙碌。

效果欠佳示例：

使用任何可用工具解决这个任务。

效果更佳示例：

仅在工具能实质提升回答质量时使用工具。

规则：
- 如果问题是概念解释或只依赖用户提供的上下文，请直接回答。
- 涉及当前价格、版本、事故或政策时，先搜索再下结论。
- 进行删除、购买、发送消息或外部写入前，必须先请求确认。
- 如果同一个工具连续失败两次，停止重试并说明阻塞点。
- 工具参数保持最小、明确、具体。

思考与推理

控制推理深度

当任务涉及规划、调试、权衡或长链路执行时，可明确要求模型深入分析；当任务只是抽取、改写或排版时，建议要求模型直接回答。

效果欠佳示例：

每个请求都一步一步思考，然后回答。

效果更佳示例：

请对这个迁移方案进行更深入的分析。

先分析：
- 兼容性风险
- 数据迁移顺序
- 回滚策略
- 发布前必须通过的测试

然后只返回最终方案：
1. 推荐方案
2. 关键风险与缓解措施
3. 发布检查清单
4. 待确认问题

最终回答中的推理过程保持简洁，不要输出隐藏思维链或无关探索。

降低幻觉

对于模型可能编造事实的任务（引用、API 接口、版本相关行为、客户数据），需明确授权它可以拒绝回答，并提供可引用的参考资料。常用做法有三种：允许拒绝（明确告诉模型在不知道时怎么回答）、来源引用（要求模型引用或标注所使用的素材）、先约束再生成（在任务之前说明允许使用的来源、时间范围或产品版本）。

效果欠佳示例：

回答用户的账单问题。

效果更佳示例：

仅根据下方政策回答用户的账单问题。

政策：
[账单政策]

如果政策无法支持答案，请回复：
"我无法根据现有政策确认这一点——请联系账单支持。"

请在回答末尾引用你所依据的具体政策原文。

长任务处理

对长时间运行的任务，每次只给模型少量当前目标。这样更有利于模型维持状态、记录决策，并避免同时推进太多半相关任务。

单窗口状态跟踪

模型可以在一个长上下文窗口内保持较强的任务状态。建议把当前计划、进度和待确认问题保留在 Prompt 或项目记录中。在支持上下文压缩的工具中使用时（例如 Claude Code），请保持 system prompt 简洁，避免在临近上下文容量阈值时任务提前终止。

多窗口工作流

当任务天然可以分阶段推进时，建议使用多个窗口：

  1. 分阶段处理：第一个窗口搭建框架、测试和脚本，后续窗口继续遍历剩余任务。
  2. 结构化测试：要求模型创建 tests.py 或 tests.json 跟踪测试，有助于长期迭代。
  3. 初始化脚本：创建 init.sh 启动服务器、运行测试，避免新窗口重复操作。
  4. 重启 vs 压缩：单个连续任务适合压缩，新任务或方向大幅变化时建议开启新窗口。
  5. 充分利用上下文：要求模型在进入下一部分前，把当前部分彻底完成。

推荐 System Prompt：

这是一项非常冗长的任务。请充分利用可用上下文窗口。进入下一部分前，请先彻底完成当前部分，避免任务完成前耗尽 tokens。

评估与迭代

对重要 Prompt，建议像管理产品配置一样进行版本化管理。保留一小组评估样例，对比不同 Prompt 版本，并记录每次修改的原因，避免只为某一个漂亮示例优化 Prompt 却无意中破坏其他常见场景。

效果欠佳示例：

随便试几个 Prompt，直到答案看起来更好。

效果更佳示例：

Prompt 迭代流程：
1. 定义成功标准 —— 正确性、格式遵循、工具调用准确性、语气。
2. 准备 10-30 个代表性测试样例，包含边界情况。
3. 用当前 Prompt 和候选 Prompt 跑同一批样例。
4. 并排比较输出，记录退化案例。
5. 只有当候选 Prompt 提升目标指标，且没有破坏必需行为时，才更新 Prompt。
6. 保存简短变更记录 —— 改了什么、为什么改、哪些样例变好了。

评论

0 条
还没有评论，来写第一条吧