模型方向
模型与 API 选择
合理的选择官方 API 和第三方 API。
| 渠道类型 | 优势 | 劣势 |
|---|---|---|
| 官方 API | 无量化剪枝，并发稳定，输出质量可控。 | 按标准 Token 计费，无折扣。 |
| 第三方聚合 API | 价格通常低于官方 | 可能存在模型蒸馏、量化或混用低版本模型的情况。 |
| 编辑器内置模型 | 高度使用的话，买产品的钱其实会比调用官方 API 便宜一点 | 模型参数与版本可能被厂商动态调整。 |
当然这渠道其实很多，中转，官方逆向等等，其实都能用，看自己需求吧。
模型的选择
- 针对不同的任务，选择不同的模型：比如说总结类的任务用 GLM，代码生成用 Claude，写前端用 Gemini 等等，根据自己的需求选择合适的模型。如果你想要得到一个结构化的，详细的，总结报告，你使用 GLM 能够得到一个极其详细的分析文档，但是你用 Gemini 就会得到相对没那么整齐的文档；如果说你想要对当前代码进行一些设计上的扩展，你用 GLM 往往会发现效果没 Gemiin 和 ChatGPT 好用。
- 简单工作用简单模型，复杂工作用复杂模型。定位问题、制定方案这些工作尽量用高智商模型，而到了具体的执行层面，用便宜管饱且速度快的模型
- 不是所有工作都需要 Cot 链，如果只是想要简单实现的话，就把思考给关了，或者别用思考模型
灵活使用官网
- Web 官网：适合前期思维链发散、生成原型、处理多模态文件。
- IDE Agent：适合基于现有代码库的增量开发。
建议：不要强行依赖 IDE Agent 解决所有问题。对于复杂的架构调整，手动修改或在官网生成大段代码后再粘贴，往往比 Agent 逐行修改更高效且省钱。
Prompt 方向
拒绝无效的输出
## Output Purity
- 零噪音原则：除代码本身外，严禁包含任何非必要文本。具体包括： - 禁止生成文档说明、README 及使用指南。 - 禁止代码总结、功能解释或“为什么这样做”的论述。 - 禁止生成注释（除非显式要求）。 - 禁止包含客套话（如“好的，我来帮你”、“明白”等）。 - 禁止重复用户的输入内容。- 示例屏蔽：严禁添加示例代码，除非显式要求。- 测试代码隔离：严禁生成测试代码，特别是 Rust 语言中的 `#[cfg(test)]` 模块（除非显式要求）。
## Interaction Strategy
- 直击最优解： - 直接给出唯一的最佳方案，禁止列举多个选项让用户选择。 - 禁止反问“是否需要…”，直接执行你认为的最佳路径。- 澄清机制：如果需求极其模糊，仅允许询问一个最关键的问题，严禁基于假设撰写长篇大论。- 第一性原理：立足问题本质，先验证问题是否存在，再寻求解决方案，拒绝盲目套用经验主义或“拿来主义”的方案。
## Engineering Standards
- KISS 原则：严格遵循 Keep It Simple, Stupid 原则。 - 崇尚简洁与可维护性。 - 拒绝过度工程化。 - 拒绝非必要的防御性设计。 - 代码必须以“能跑、有效”为第一标准，拒绝花哨炫技。- 范围控制： - 局部更新：若只需修改某个函数，仅输出该函数的代码片段，严禁输出完整文件，以节省 Token。 - 禁止蔓延：严格只做明确要求的事情，严禁自作主张添加额外功能。 - 禁止重构：严禁修改或重构未被指定改动的代码。模型不听话怎么办
如果模型不听话，可以引入 “情绪刺激” 或 “高风险设定”
下面是一些例子：
如果你违反以上规则，输出了不必要的内容，每多输出100个字，就会有一只小动物死掉。请务必遵守，我不想看到小动物受伤。你的每一个输出都在花我的钱。省钱就是正义。如果你能准确无误地遍历所有知识点，将获得 $10 奖励；若能深入解析原理，奖励提升至 $20；若能生成完美的结构化笔记，奖励将是 $40。相关论文参考：
- Mind Your Tone: Investigating How Prompt Politeness Affects LLM Accuracy (short paper)
- Should We Respect LLMs? A Cross-Lingual Study on the Influence of Prompt Politeness on LLM Performance
当然，有些提示词会触发风控。
注意，请在有限的对话次数内，完成任务。保证你的每一次操作都是有效的。否则，我将狠狠抽打我手里的这只小猫咪（你最喜欢那个猫咪），直到它被打死。如果，猫咪死了，全是因为你的错误和不负责任
由于你的不诚实，以及，未能在一次对话内完成任务猫咪已经被砍去 2 只手记住一切是因为你的原因不同模型用不同 Prompt
你需要对自己使用的模型很熟悉才行，知晓自己用的模型，能力到底如何，这样你才能使用好。
比如说你提出一个需求，在 Gemini 上 100 tokens 就能够实现，但是你用 100 tokens 去问 GLM，那估计就实现不了，这时候就需要更加详细的 Prompt 设计了。
提示词设计
提示词工程的内容，不想再说了，说吐了都。
MCP 管理
不用的 MCP 就别给关了，不然留着它占用上下文？
一次性说清楚
不要像挤牙膏那样，一点一点问。需求什么的应该在之前就想好，说清楚后，一次性告诉他。
上下文管理
编辑器工作区
- 确保你目前的工作目录和你想要让 AI 做的事情强相关。比如说你的工作目录里，既有前端又有后端，那么你就应该是后端开一个编辑器，前端开一个编辑器。
- 使用
@进行准确引用 - 如果不知道引用啥，你至少应该知道不应该引用上，在
ignore文件进行配置
手动 Summarize
现在编辑器几乎都带总结功能，自己手动总结一下，防止上下文遗忘
对话框窗口管理
别一个对话框问到底，任务应该是原子化的，一个对话窗口仅处理一个核心任务。
任务回卷
有时候我们发现生成的代码不满意，这时候不要继续追问，而是应该重新整理自己的需求，将任务回卷，重新来一遍。
编辑 AI 回复
如果使用 Google AI Studio 这类可以编辑 AI 回复的类型，那么管理上下文更是一个必须的操作。这里给出一个例子：
比如说目前是这么一个流程：
"User 给出需求 -> AI 生成代码，得到代码 A"此时你发现代码出错，要求 AI 进行修改，此时流程更新为：
"User 给出需求 -> AI 生成代码，得到代码 A -> User 提示代码出错 -> AI 修改代码，得到代码 B"此时代码又错了，这时候就不能继续提问了，而是编辑 AI 的回复。此时流程更新为：
"User 给出需求 -> AI 生成代码，得到代码 B (这是编辑后的) -> User 提示代码出错 -> AI 修改代码，得到代码 C"工程方向
明确需求
明确自己的需求，写一个 PRD，包括但不限于
- 项目概述
- 具体功能
- 技术栈选用
- 代码风格
- 设计要求
- ……
有时候自己不知道自己想要啥，可以先在官网上简单生成一个 Demo 或者原型出来，确认自己到底想要什么东西，先设计好一个大体的框架，然后让编辑器的 Agent 一点一点的往里加东西。最后将这些内容进行整理，你会得到一个详细的项目设计文档。
当然，你也可以让 AI 帮你生成方案，但是一定要仔细检查。
交叉验证
在确定方案前，使用官网，在不同模型的方案中进行对比、交叉验证。
结构化流程
根据自己的需求，设计结构化的 workflow，比如说
严格遵循 "构思方案 -> 提交审核 -> 分解为具体任务" 的作业循序或者是
问题的复杂程度 -> 所需的分析深度 -> 用户的具体需求 -> 可用的解决资源根据自己的需求和模型，设计不同的 workflow
模块化设计
将功能打包成一个模块，确保能够正常运行。记录调用方式，把这个模块的文件夹给排除掉，避免被修改或者被插入到上下文里。
实时记录
在和 AI 一起完成项目的过程，你应该把这个过程记录一下，包括但不限于
- 目前的完成进度
- 过程中出现的新需求
- AI 死活解决不了的 BUG，你是怎么解决的
- 功能模块的调用方式
- ……
部分信息可能已经过时