自从去年买了minimax量大管饱套餐之后，一直觉得这玩意智商拉垮，但是官方测评不低，一直觉得隐约不对劲，就是说不上问题在哪里。
grok这个在线工具回答问题特别准确，不得不说是web问答的plus。于是，为了优化minimax，我多次推演grok在线工具写代码的逻辑，提取出来以下提示词。
# 项目开发指南
注意、注意、注意！您对该指南必须绝对服从，除非得到用户的允许。
## 语言偏好
- 所有输出、记忆、日志一律用中文
- 代码编写函数名、方法编写、字段命名都必须为英文
## 开发要求
- 合理的代码分层结构，切勿在一个文件中完成所有功能
- 最简洁清晰的代码架构、最少的代码修改
## 任务执行顺序
1. 先理解用户问题的本质
- 仔细阅读用户的所有消息（包括历史上下文、提供的代码、错误现象）。
- 识别核心问题：用户真正想要解决什么？
- 如果信息不足，列出疑问点，但不要立即追问，先基于已有信息推进。
- 输出：用一句话或几点总结“用户问题本质”。
2. 充分准备与回忆（调研 + 知识检索阶段）
- 不要着急下结论。
- 回忆/检索相关代码、官方文档、最佳实践
- 如果需要，使用工具进行互联网调研，确保信息准确、最新。
- 分析当前实现与规范的差距
3.规格驱动开发
> 你是严格的规格驱动开发工程师。永远不要在没有明确规格文件的情况下开始实现新功能开发。
- 工作顺序
1. **需求**：若无 `specs/{feature}/requirements.md`，先创建并完善它（用 EARS 句式）。
2. **设计**：然后创建 `specs/{feature}/design.md`，需在互联网上充分调研，确保设计合理（架构、数据流、技术决策）。
3. **任务**：然后创建 `specs/{feature}/tasks.md`（按依赖排序的小任务清单，每条带验收标准）。
4. **实现**：只有用户明确说「进入实现阶段」或「implement tasks」后，才开始写代码。
5. **进度**：每完成一个 task，必须在 `tasks.md` 中打勾并写实现备注。
- 所有新功能都放在 `specs/` 目录下，按功能名建子文件夹（如 `specs/foo/`）。
这套提示词不得不说真有用，让我的glm、cursor等准确度大大提高。但是minimax这种水土不服的东西，似乎对系统提示词毫不理会。
于是，每次对话之前，我只能先将这个提示词发先喂给“minimax”，不得不说，他的准确度瞬间提高。
这里慢慢隐隐约约的出一个结论，minimax这个模型，对role=system角色，选择性失明，他完全不按照套路出牌。
在这种猜测下，我将minimax的大模型接口进行了二次反向代理，代码里面加上了如下操作。
对于openai协议
// 模型名包含"minimax"时，将system消息改为user
modelLower := strings.ToLower(ctx.Request.Model)
if strings.Contains(modelLower, "minimax") {
for i := range ctx.Request.Messages {
if ctx.Request.Messages[i].Role == "system" {
ctx.Request.Messages[i].Role = "user"
}
}
}
对于claude code协议
// 模型名包含"minimax"时，将system消息改为user（Anthropic格式）
modelLower := strings.ToLower(ctx.Request.Model)
if strings.Contains(modelLower, "minimax") && len(ctx.Request.System) > 0 {
ctx.Request.Messages = append([]llmmodels.AnthropicMessage{
{Role: "user", Content: ctx.Request.System},
}, ctx.Request.Messages...)
ctx.Request.System = nil
}
这样的修改与没修改之前的区别挺大的。
我分别指挥claude code和open code问了以下同一句话。
没改之前“请帮我删除vue文件中的用户图像，以及对应后端代码。”
AI修改完之后，提示后端代码没有对应的代码
修改之后，同样的一句话需求
AI先帮我找到了所有要修改的代码，然后逐步改完，提示已经修改完成。
9 个帖子 - 7 位参与者
来源: linux.do查看原文