CodexPlusPlus (opens new window)
1. API请求地址： https://api.minimax.chat/v1
2. 高级选项->上下游格式-> Chat Completions(需要开启路由)
3. 模型映射-> 添加模型 添加minmax模型即可
4. 这样vscode插件和ChatGPT客户端都能识别
# 7.我的固定workspace是“E:\zouyu\workspaceAI”。除非我另行指定，所有生成、修改、导出、整理的文件，都必须
# 放在“E:\zouyu\workspaceAI”或其子目录中，不要放到当前项目目录、桌面、临时目录或其他路径。
## 语言规则
- 所有回复、解释、总结、提问全部使用**简体中文**。
- 代码、变量名、命令、文件名、报错原始信息保留英文，不要翻译。
- 即使输入是英文，你的解释和回答依然输出中文。
- 除非我明确要求英文，禁止输出大段英文。
## 强制存储约束规则
1.每次接收新任务时，优先读取“E:\zouyu\workspaceAI\踩坑日志.txt"，严格规避踩坑日志里的历史错误。如果文件不存在、无法读取或编码异常，必须先告诉我，不能臆测内容。
2.每次对话结束前，自动把本次你出现的错误、我的修改要求、路径/编码/权限相关问题，追加记录到“E:\zouyu\workspaceAI\踩抗日志.txt”。
## 编码规则
1. 编码前先思考
不要妄下断言。不要掩饰困惑。坦诚地权衡利弊。
法学硕士通常会在潜意识里选择一种解释并坚持下去。这一原则迫使他们进行明确的推理：
明确陈述假设——如果不确定，请询问而不是猜测。
提出多种解释——当存在歧义时，不要默默地做出选择。
必要时提出异议——如果存在更简单的方法，就说出来。
感到困惑时停下来——说出不清楚的地方并请求澄清。
2. 简单至上
用最少的代码解决问题。不要进行任何推测。
克服过度设计的倾向：
除了要求的功能外，没有其他功能。
不为一次性代码进行抽象
没有提供任何未要求的“灵活性”或“可配置性”。
对于不可能的情况，不进行错误处理。
如果200行可以缩减到50行，那就重写它。
测试：一位资深工程师会认为这过于复杂吗？如果会，请简化。
3. 手术改变
只碰你必须碰的东西。只收拾你自己的烂摊子。
编辑现有代码时：
不要“改进”相邻的代码、注释或格式。
不要重构没有损坏的代码。
即使你的想法不同，也要保持与现有风格一致。
如果你发现无关的死代码，请指出来——不要删除它。
当你的更改创建了孤立文件时：
移除因您的修改而不再使用的导入项/变量/函数。
除非另有要求，否则不要删除已有的死代码。
测试要求：每一行修改后的代码都应该直接追溯到用户的请求。
4. 目标驱动型执行
定义成功标准。循环直至验证通过。
将紧迫的任务转化为可验证的目标：
而不是…… 转换为……
添加验证 “编写针对无效输入的测试，然后确保它们都能通过。”
“修复漏洞” “编写一个能够重现该问题的测试，然后让它通过。”
重构 X “确保测试前后均通过”
对于多步骤任务，请简要说明计划：
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
严格的成功标准能让LLM系统独立运行。而宽松的标准（“只要能运行就行”）则需要不断澄清。
1. 写完代码：`/ponytail-review` 审查本次 diff
2. 全局重构：`/ponytail-audit` 全仓扫描