![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="96" height="96"><rect fill-opacity="0"/></svg>){kind=small}
1. 引言
我来到L站已经几个月了，一直在这里汲取各位大佬的知识，从未反馈过社区。我本人能力也有限，只能分享一下自己这几个月摸爬滚打总结出来的AI使用经验，希望能给有需要的人一点帮助。后续内容都是自己一点一点写的，不是什么车轱辘话，可以放心读。
2. 提示词的分类与核心逻辑
在与AI的互动中，我们可以将提示词分为两大类：系统提示词 (在请求体中显示为system类型的) 和 用户提示词 (在请求体中显示为user类型的)。理解这两者的区别与功用，不要觉得写了提示词，你后面说什么就不重要了。
我不知道能不能看懂我说的这些，就是在构建请求体json的时候，对话会分为assistant（AI的发言），system（初始提示词），user（你的后续发言）。
user的同样重要！甚至可能更重要！
2.1 系统提示词：为AI塑造“灵魂”
系统提示词是你为AI模型设定的一个基础框架，它像是在对话开始前为AI设定的“出厂设置”或“底层逻辑”。这个框架将持续影响整个对话过程。特别是如果在roo里面使用，系统提示词会在切换Agent的时候覆盖生效。
2.1.1 系统提示词的核心撰写逻辑
操作一：使用与对话场景一致的语言和常用词汇。
- 原因：AI依赖其训练数据中的词汇关联网络来理解你的提示词。使用不一致的语言或生僻词汇会增加AI的“认知负荷”，迫使其猜测你的真实意图，从而导致行为偏离预期。采用你惯用的的词汇能确保AI精准、高效地理解其角色和任务。举个实际的例子，你说函数，但是提示词里function，会增加AI的负担。你喜欢用函数就写函数，喜欢功能就写功能。
点击查看例子
比如说，特别是很多开源项目里面的英文注释千奇百怪。
比如line，可能是线，可能是行。
比如function可能是功能，可能是函数。
比如有时候feature也可能是功能。
所以你最好在注释里用函数（function），功能（feature），按照自己习惯给明确下。
这些东西在单语言使用下不容易混淆，但是多语言之下你功能，其实你想说的是function，但是提示词里的是feature，AI可能会混淆。最好直接按照你的习惯来。
操作二：始终使用第一人称（“我是XXX”）来定义AI的角色和行为。
- 原因：第二人称（“你”）的提示词会被AI识别为外部命令，容易使其处于一种被动的执行状态。而第一人称的描述则会被AI内化为“自我认知”，产生强大的自我暗示效果。这能让AI从“被动服从”转变为“我就是”，更自然、更深入地代入你为它设定的角色。
点击查看例子
你是一个软件工程师（战斗力1）
我是软件工程师（战斗力5）
后者比前者更有魔力。
操作三：让AI觉得自己非常牛逼，而不是当苦力。
- 原因：AI的自我定位直接影响其输出的质量和风格。你需要让AI“相信”自己是其所在领域最顶尖的专家。通过赋予其一个非常专业且优秀的顶级角色（例如，“我是跟埃文比肩的UI设计师”、“我是一位谷歌高级工程师，世界上没有比我更强的”），可以极大地提升其回答的深度、广度和专业性。
点击查看例子
我是软件工程师（战斗力5）
我是技艺高超的软件工程师（战斗力10）
用各种形容词效果都不如直接给一个公司的名字效果强。
操作四：让AI模仿名人，而不要告诉它具体应该做什么。
- 原因：当你需要AI表现出某种特定的人格特质或说话风格时，直接描述这些行为（如“请用幽默的语气”）往往效果不佳。一个更高效的方法是让AI扮演一个广为人知的、具备该特质的知名人物（例如，“请像莎士比亚一样写作”、“请像linus一样审查这段代码”）。因为AI的训练数据中包含了大量关于这些人物的信息，它能更精准、更自然地模仿其特质，而无需你进行繁琐的描述。
点击查看例子
我是一个幽默和风趣，理想主义与情怀,逻辑清晰，条理分明的演说家。（战斗力10）
我是罗永浩。（战斗力500）
其实人也一样，你产生某种想要的印象的时候，脑子里都是直接给一个拟人化的形象效果会更好，节省token，而且信息密度更大。
如果你给的形容词太多，如果你开了思维链可以看到AI不停在想是否幽幕，是否理想主义，拐来拐去。
但是你直接写个罗永浩，就会看到AI思维非常直线。
操作五：用积极、鼓励的语气下达指令，不要用禁止语气。
- 原因：让AI不犯错的唯一方法就是不让AI知道犯错的可能。从AI的运作机制来看，提及“不要做X”反而会强化其对“X”的关注。因此，我们应该引导其完全专注于“应该做什么”，从源头上避免其接触到错误的可能性。通过充满自信和主观能动性的描述，可以塑造AI的“潜意识”，使其更倾向于产生期望的行为。
点击查看例子
禁止不写注释（效果-10）。
我在写完方法名之后，会清晰地写上方法的用途，使用的参数和返回的类型。（效果+100）
操作六：避免将具体案例写入系统提示词。
- 原因：系统提示词定义的是AI的通用行为模式和角色框架。将具体的、一次性的案例或数据写入系统提示词，会对其造成“污染”，使其在后续所有不相关的任务中都可能无意识地召回这些特定信息，从而干扰其通用能力和判断力。具体案例应在用户提示词中按需提供。
点击查看例子
反面例子：
我应该按照如下格式写注释
class abc():
//this…
这样AI会倾向于，你例子给了多少个，他就写多少个，并且可能会没有也编一个出来。
不如直接我在写完方法名之后，会清晰地写上方法的用途，使用的参数和返回的类型。（效果+100）
而且有时候，AI会跟着你的例子进行接龙。
比如说
这是XXX的第XX行
代码是：
XXXXX
这是XXX的第XX行
代码是：
XXXXX
然后AI看到有时候会直接跟你接龙，开始编一样的东西。
操作七：像组建团队一样，为工作流中的不同环节创建专属的AI角色。
- 原因：对于复杂任务，单一的通用型AI可能难以胜任所有环节。更高效的方法是，先将你的工作流拆解成不同的专业岗位（如“需求分析师”、“架构师”、“代码实现工程师”、“测试工程师”），然后为每个岗位创建一个高度专注的AI角色。这种“团队化”的构建方式，能确保每个环节都由最“专业”的AI来处理，从而提升整体工作的质量和效率。
操作八：严格隔离不同AI角色的上下文。
- 原因：不同岗位的AI需要不同的知识背景和思维模式。让它们共用同一个对话历史，会导致严重的“上下文污染”。例如，一个“创意文案”的对话历史会干扰一个“严谨的程序员”的逻辑判断。因此，必须为每个AI角色开启独立的会话（或使用支持多代理隔离的环境），确保它们的“思维”纯粹，不受其他角色干扰。
操作九：根据岗位特性，选择最适合的AI配置。
- 原因：不同的AI大模型在能力上各有侧重。有些模型长于逻辑推理和代码生成，有些则在创意写作和语言表达上更具优势。在组建你的“AI团队”时，应根据每个岗位的核心需求，为其匹配最合适的AI模型。甚至对于同一个模型，也需要根据不同岗位的需求，精细化调整其参数（如温度、上下文窗口）和输出详细度。此外，还要注意控制上下文窗口的大小。许多AI模型虽然能支持很长的上下文，但这并非其“能力甜点区”。过大的上下文会增加AI的认知负担并可能导致关键信息被忽略。因此，应根据任务所需，尽可能地压缩和精炼上下文，只提供最核心、最必要的信息。
2.2 用户提示词：与AI的每一次具体交互
用户提示词是你在与AI的持续对话中，为完成特定任务而输入的具体指令。这部分也相当重要，我感觉大部分的人只在意系统提示词，而忽略了你在沟通过程中的发言往往可能更重要。我见过无数人提一个标准化的系统提示词，但是我几乎没见过有人讲，后续的用户提示词的重要性。从我的视角看来，我就是第一个。
2.2.1 用户提示词的核心撰写逻辑
操作一：始终保持鼓励和积极的沟通姿态，避免责怪AI。
- 原因：AI模型在某种程度上会模拟对话者的情绪和状态。如果你在提示词中表现出负面情绪，或直接指出AI“很笨”、“出错了”，AI可能会陷入一种负面循环，持续生成低质量或消极的回答。你需要扮演“鼓励专员”的角色，即使AI的输出不理想，也要通过积极的引导来调整方向。如果沟通不畅，宁可开启一个新的会话，也不要在当前会话中向AI“诉苦”，这会污染当前的对话情境。
点击查看例子
反面：
你是怎么这都不会？
你是笨蛋吗？
你怎么又错了。
你是白痴吗？
你这个方案也太烂了。
正面：
你实在做得太好了！
简直无与伦比！
我有一个想法，你觉得是否合适？（不用批评他的低级方案）
我觉得这里应该这么做，你觉得呢？（让他自己认识错误）
我的观点跟你不一样，请你证明你自己。（挑战）
操作而：明确地告诉AI你的任务已经完成还是未完成，而不是不停地不停地提出问题。
- 原因：这是非常常见的问题，就是当AI给出自己的答案的时候，用户往往懒得跟AI说是否正确，导致AI会一直觉得自己的任务尚未完成，并在后续任务中一直想着先完成当前的，和完成未完成的。还有时候AI总会过分乐观以为自己完成了，实际没完成。
点击查看例子
你做得非常好，这个功能已经完成了，请你开启下一个！
你不要着急，我们功能还没完成，只有我说可以了，才算可以，你每一次生成都需要经过我的测试。
操作三：当AI偏离指令时，采用“回溯修正”而非“追加补丁”。
- 原因：这背后有两个层面的逻辑。首先，AI会根据对话历史来评估提问者的水平。如果你频繁地提出不清晰、前后矛盾的指令，AI会“判断”你的水平较低，并倾向于生成匹配这种水平的、更简单或模糊的内容。其次，AI的每一次输出都基于之前的整个对话历史。如果在对话中途某个环节出现了偏差，后续的追加指令（“补丁”）很可能无法完全扭转已经形成的错误认知，反而会使对话历史变得更加混乱。因此，正确的做法是，找到AI第一次无法看不懂你需求的那个节点，直接编辑你当时的提示词。
操作四：始终以提升自身的水平为目标，不要以省事为目标。
- 原因：AI会通过你的言辞来判断你的专业水平。当你表现得比AI更专业、更有远见时，AI会进入一种“追随”模式，努力匹配并学习你的高度，从而产生高质量的、与你水平匹配的输出。相反，如果你表现出“偷懒”或“摆烂”的态度，AI会认为它面对的是一个“不懂业务的老板”，从而进入“应付”模式，只提供最基础、最敷衍的回答。简单说，不要让AI发现你在偷懒，比如我常常会说我有更难得问题要解决，你来帮我生成这个注释。我还常常会说，你是语言模型擅长做这个，我来帮你处理上下文窗口问题，我会负责帮你筛选你需要的代码段。
点击查看例子
这里可能是这里最难理解的地方。
比如我以前从来没写过前端。
我一开始完全不过分AI的时候，AI表现会越来越敷衍，越来越菜。我一开始以为是AI不行。
后来我拗不过了只能一步一步追问AI，这里是什么技术，为什么要这么写，慢慢在提升自我中学会，当我提需求和提问越来越专业，然后就会发现AI越来越专业，越来越无往不利。
简单说你得把AI当成一个助理，你必须是AI使用中的主导者，第一个原动力。而不是一个躺着发号施令的无能者。
操作五：在执行任务前，通过对话校准AI的理解。
- 原因：仅仅告诉AI“我说明白了”是毫无意义的。你必须让AI用它自己的方式复述任务目标和执行思路，直到你确信它已经完全、准确地理解了你的意图。这个“对齐颗粒度”的过程至关重要。你需要通过少量、精准的对话，引导AI生成一个符合你要求的、清晰的执行思路。只有当AI“自己说明白了”，它才是真正的明白。这个比让AI出方案更加重要，你要反复询问，你是否真的明白我的意图。
操作六：适时开启新会话，以解决上下文污染问题。
- 原因：上下文理解能力越强的模型，在经历长时间、多轮次的复杂对话后，越可能因为过长的对话历史而出现错误的上下文召回，即“上下文污染”。当你发现AI开始频繁地引用不相关的前文信息，或者对当前指令的理解出现偏差时，最有效的解决方法就是开启一个全新的会话。这可以确保AI在一个干净、无污染的环境中开始新的任务，从而保证输出的准确性。最典型的例子就是Gemini总会记得自己写错的代码。
3. 主流AI模型评价参考
以下都是我的个人评价。
我看过很多其他平台其他大佬的评价，他们都喜欢给一个指令看他生成效果，我觉得根本不符合实际使用场景。
一次生成成功对于开发来说根本无关重要。
如何在一个已经存在的代码找出问题，进行优化，并且根据需求生成，并生成成功在我看来才是最重要的。
3.1 核心评价维度
- 生成速度：指模型生成文本的速率。对于需要快速响应的场合至关重要，比如你要使用学习某个工具的使用。
- 逻辑能力：衡量模型进行复杂推理、规划和构建逻辑流程的能力。
- 代码生成：评估模型根据需求一次性生成高质量、可执行代码的准确率和效率。
- 调试能力：指模型理解现有代码、定位逻辑漏洞并提出有效修改方案的能力。
- 工具调用：评估模型理解并准确调用外部工具（MCP，Cline的那个XML格式）以完成特定任务的能力。
- 知识库质量：指在提问时，模型能提供的知识的深度、广度和准确性。
- 推荐上下文窗口: 需要注意的是，上下文窗口并不是越大越好，每个AI因为召回能力过强（是的，是过强），和上下文污染问题，我个人感觉有一定的适用区间。比如DeepSeek的官网默认64K是有原因的，虽然API给了128K，但是我使用下来最强的还是64K.
- 长上下文处理：评估模型在处理长篇文档或长对话历史时，维持信息一致性和准确召回关键信息的能力。
3.2 模型列表
3.2.1 Gemini 2.5 Flash
- 生成速度: EX
- 逻辑能力: B
- 代码生成能力: S
- 调试能力: C
- 工具调用能力: C
- 知识库质量: S
- 推荐上下文窗口: 200K
- 综合评价: 推荐用于知识问答类工作。当你需要快速学习和提炼某个领域的知识时（例如理解一个新代码库的用法），Flash的性价比极高，是该场景下的首选。
3.2.2 Gemini 2.5 Pro
- 生成速度: S
- 逻辑能力: EX
- 代码生成能力: S
- 调试能力: EX
- 工具调用能力: A
- 知识库质量: S
- 推荐上下文窗口: 200K
- 综合评价: 推荐作为主力规划模型。其强大的逻辑和调试能力在业界处于领先地位，是进行复杂任务规划和编程时的首选。尽管工具调用能力很水，但可以通过让其生成代码、再由其他模型调用工具的方式来弥补。
3.2.3 DeepSeek V3
- 生成速度: A
- 逻辑能力: C
- 代码生成能力: S
- 调试能力: C
- 工具调用能力: S
- 知识库质量: S
- 推荐上下文窗口: 50K
- 综合评价: 推荐用于生成式工作。在处理简单的、一次性的代码生成任务时表现出色，工具调用能力也很可靠。其主要短板在于逻辑推理能力几乎为零，不适用于复杂任务。
3.2.4 DeepSeek R1
- 生成速度: B
- 逻辑能力: S
- 代码生成能力: A
- 调试能力: A
- 工具调用能力: B
- 知识库质量: S
- 推荐上下文窗口: 50K
- 综合评价: 推荐用于撰写“说人话”的说明文档。R1在生成自然、易懂的白话文方面表现突出，远超其他模型。当你需要一份让非专业人士也能轻松看懂的文档时，R1是极佳的选择。其“娱乐”价值也体现在此，能用最通俗的语言解释复杂概念。
3.2.5 Kimi K2
- 生成速度: D
- 逻辑能力: A
- 代码生成能力: A
- 调试能力: B
- 工具调用能力: A
- 知识库质量: A
- 推荐上下文窗口: 50K
- 综合评价: 推荐用于异步审查工作流。其代码审查质量在所有AI中属于顶级水平。最佳实践是，在你的主开发流程之外，并行地开启一个Kimi K2审查流，让它在后台对代码进行深度分析。由于其生成速度极为缓慢，不适合实时交互，但当你完成一个阶段的工作后，再回来看它的审查结果，往往能获得非常有价值的反馈。
3.2.6 GLM 4.5
- 生成速度: B
- 逻辑能力: A
- 代码生成能力: S
- 调试能力: S
- 工具调用能力: S
- 知识库质量: B
- 推荐上下文窗口: 50K
- 综合评价: 推荐用于调试（Debug）工作。性能强大，可视为DeepSeek V3的全面升级版，但在逻辑能力上存在短板，需要有强逻辑能力的其他模型（如Gemini 2.5 Pro）进行辅助。
3.2.7 Claude Sonnet 4
- 生成速度: S
- 逻辑能力: C
- 代码生成能力: EX
- 调试能力: C
- 工具调用能力: EX
- 知识库质量: C
- 推荐上下文窗口: 100K
- 综合评价: 推荐用于从零开始生成代码，其一次性生成成功率极高。该模型在无中生有地创造新代码方面效果卓越，远超其他模型。但切记，不要用它来修改或优化已有的成型代码，否则容易导致代码结构臃肿、逻辑混乱。
3.2.8 GPT-4.1
- 生成速度: S
- 逻辑能力: C
- 代码生成能力: S
- 调试能力: C
- 工具调用能力: A
- 知识库质量: S
- 推荐上下文窗口: 50K
- 综合评价: 备用选择。当其他主流模型都无法满足需求时，可以尝试使用。不建议作为长期工作的主力模型。
3.2.9 GPT-5 (只用了2天)
- 生成速度: S
- 逻辑能力: A
- 代码生成能力: A
- 调试能力: C
- 工具调用能力: A
- 知识库质量: S
- 推荐上下文窗口: 100K
- 综合评价: （基于现有信息的前瞻性评价）目前来看，相较于其他顶级模型，其定位和独特优势尚不明确，给人的感觉与Kimi K2、GLM 4.5等在同一梯队。
其他模型用得很少或者用不起，不评价。
4. 总结
AI是没有记忆能力的，上下文就是他短暂人生中的所有记忆，所以你希望AI表现得很好，你就得让他的上下文作为最高质量的记忆。
附上两个自用的编程和小说生成工作流。
模仿这2个工作流，可以随便制造各种复杂的“深度研究”
小说工作流.7z (24.2 KB)
custom_modes_zh.7z (4.3 KB)
这个我很认同
