在使⽤ Qoder 进⾏ AI 编程的过程中，认知转变是第⼀步。我们从“写代码的⼯匠”转变为“定
义意图的协作者”——核⼼能⼒从“写代码”变为“控制 AI ⽣成、验证产物、整合结果”。以前是
Talk is cheap, show me the code；现在是 Code is cheap, show me the talk——如何通过对话驱动 AI 产出有价值的产物，成为新的核⼼竞争⼒。

1.1 任务拆解：⼀次只做⼀件事

任务拆解是 AI 编程中最重要的实践原则。就像软件⼯程中的“单⼀职责原则”⼀样，每次交给
AI 的任务应该是明确、可执⾏的单⼀任务。模型能⼒越弱，任务粒度就需要拆得越细。即使
使⽤国内模型，只要任务拆解到位，⽣成效果也能达到⾮常好的⽔平。
实践要点：

• 避免⼀次性提出过于宏⼤的需求（如“帮我复刻⼀个 12306”），⽽是拆解为具体⼦任务
• 具体化任务描述：“帮我设计⼀个数据表”、“实现某个接⼝”、“编写某个单元测试”
• 遵循“先完成再完美”原则：先实现基本功能，再迭代优化体验和细节
• 不要追求⼀次性完成复杂功能，可以多次迭代逐步完善

1.2 写好提示词：清晰、完整、⽆歧义

提示词⼯程并未过时，它仍然是每个开发者必备的核⼼技能。提示词的要求是：清晰具体、中
肯详细、避免歧义。从结构层⾯看，⼀个好的提示词应包含四个要素：背景信息、具体任务、
输出要求和约束条件。以下结合原⽂示例详细说明这四个要素的具体写法：
① 背景信息：说明场景与问题的由来
背景信息⽤于告诉 AI 当前的业务场景和问题的起因，让它理解你为什么需要这个功能。例
如：“我们的客户经常在⾮⼯作时间提出常⻅问题，需要提供⼀个⾃助服务的解决⽅案”。这样 AI 就能理解这是⼀个⾯向客户的⾃助服务场景，⽽不是内部⼯具。
② 具体任务：明确告知要做什么
具体任务要明确告知 AI 需要产出什么样的产物。例如：“创建⼀个问答⽹⻚，展示⼗个常⻅问
题和对应的答案”。这⾥不仅说明了产物类型（⽹⻚），还明确了内容范围（⼗个问题）和形
式（问答式）。
③ 输出要求：对产出结果的格式与质量要求
输出要求⽤于约定最终产物的呈现⽅式。例如：“布局要清晰，问题按照重要性排序，答案要
简单明了”。这⾥包含了布局、排序逻辑、内容⻛格三个维度的要求，让 AI 明确知道“好”的标
准是什么。
④ 约束条件：提供参考样例或限制边界
约束条件⽤于限定⻛格边界或提供参考标杆。例如：“样式类似淘宝的帮助中⼼⻚⾯，但尽量
简洁”。通过给出具体的参考对象和⻛格偏好，AI 就能准确理解你对“好看”的定义，⽽不是按
⾃⼰的理解⾃由发挥。
常⻅问题与改进⽅式：

• “⽤ JSON 进⾏反序列化”→ 应说明使⽤什么框架、什么版本
• “这个界⾯太丑了”→ 应明确说明什么⻛格是“好看”（简洁/花哨/某参考⻚⾯）
• “帮我修复”→ 应提供详细报错信息、⽇志、截图等上下⽂
• 将反复使⽤的指令沉淀到 Rules ⽂件中，避免每次重复编写

Qoder 最突出的亮点之⼀是提示词的⾃动优化功能：
对话框输⼊初步想法后，点击输⼊框的"优化输⼊"按钮 ✨，它不仅仅是对⽤户输⼊内容的简
单优化，⽽是结合当前正在开发的项⽬上下⽂来编写更精准的提示词。同时⽀持中英⽂互换，
帮助⽤户理解如何撰写⾼质量的提示词。当⽤户发出模糊指令时，Qoder 会⽣成具体的优化建
议，让⽤户速学提示词写作技巧。

1.3 上下⽂⼯程：提供充⾜且准确的信息

上下⽂⼯程是提示词⼯程的升级版本。⼤模型具有上下⽂⻓度限制，⽽且上下⽂越⻓能⼒下降
越严重、费⽤越⾼、响应时间越⻓。因此需要把指令、知识和⼯具进⾏精⼼选择和组合，把最
关键的信息提供给模型。
具体做法：

1. 在代码中适当添加注释，帮助 AI 理解业务逻辑，显著提升⽣成质量
2. 提前定义好类和函数的结构，不要完全依赖 AI ⾃动⽣成
3. 有技术⽅案时，将其加⼊上下⽂，让 AI 基于⽅案编写代码
4. 利⽤ MCP（Model Context Protocol）扩展能⼒边界，让 AI ⾃动获取所需信息
5. 只提供必要的上下⽂信息，避免⼤量⽆关内容增加消耗

1.4 模型选型：在效果与成本之间权衡

在允许的范围内选择最适合的模型。简单任务（如学习源码、⽣成⼩ Demo、写单元测试）可
以使⽤国内基础模型；复杂任务（如架构设计、难题调试）应使⽤全球sota模型。实践中常常
出现这样的情况：⽤普通模型折腾⼀⼩时都搞不定的问题，⽤⾼级模型可能五分钟⼀句话就解
决了。
Auto 模式：由 Qoder ⾃动根据任务复杂度选择最佳模型，兼顾效果与成本
建议根据任务复杂度灵活切换模型等级。对于重要且复杂的任务，不要吝啬额度使⽤⽐较弱的
模型——节省的时间和避免的返⼯远超过模型成本差异。同时，尽量拥抱主流技术栈（如
React、Spring Boot、Python 等），偏⻔技术栈的⽣成效果会明显下降。

1.5 规则系统：让 AI 遵循团队规范

Rules（规则⽂件）是让 AI 编程⾛向稳定的关键。通过在项⽬中配置 .rules ⽬录下的
Markdown ⽂档，可以将团队的命名规范、编码规范、安全审查要求、架构设计准则等沉淀下
来，让 AI ⾃动遵循这些规范⽣成代码。这就像给新⼊职的员⼯提供内部规范⼿册⼀样。
Rules 可以包含：

• 核⼼代码开发规范：确保⽣成有效、可运⾏的代码
• 命名⻛格规范：保持与现有项⽬⼀致的命名⻛格
• 安全审查要求：代码安全检查规则
• 架构设计准则：⾼可⽤、性能、安全性考量
• 内部函数库与组件复⽤规则：避免 AI 重复造轮⼦

规则⽂件可以通过 Git 在团队内共享，让所有成员使⽤统⼀的规范。这也可以持续迭代完善
——在实践中发现新问题时及时补充规则，形成良性循环。

1.6 版本控制与及时回退

版本控制在 AI 编程中⽐以往更加重要。当完成⼀个⼩的完整功能时应⽴即提交（Git
Commit），这样即使后续 AI ⽣成的代码出了问题，也可以⽤ Git 快速回退到正确状态，⽽不
需要在 IDE 中⼀轮⼀轮地回退。Qoder 本身也⽀持单次编写的回退操作，但版本控制系统更
加可靠。

1.7 对话管理：及时开新对话

上下⽂窗⼝越⻓，模型能⼒下降越严重。“⽀持”某个上下⽂⻓度并不代表在该⻓度下能做得好
——就像⼀个⼈说能⼀天读⼗本书，但并不意味着读完⼗本书都能记住内容。建议完成⼀个功
能就开新对话，如果必须继续当前对话，可以使⽤ Qoder 的“压缩当前上下⽂”功能。

1.8 问题修复策略

当遇到 AI 来回修改都⽆法解决的问题时，需要采⽤更系统的⽅法：

1. 描述清楚问题：提供完整的错误信息、⽇志、截图
2. 说明已尝试的⽅案：避免 AI 反复使⽤已失败的⽅法
3. 明确期望结果：让 AI 知道你真正想要什么
4. 提供详细信息：⽇志、截图、报错栈等越详细越好

1.9 单元测试与代码审查

AI ⽣成代码的真正价值不在于短时间内⽣成⼀万⾏代码，⽽在于⽣成⼗⾏有效的、能够合并
进主⼲的代码。因此，写完功能后⼀定要多写单元测试，并让 AI 帮助做代码审查。只有经过
验证的代码才能保证质量，这是 AI 编程从“⽣成代码”到“产出价值”的关键⼀步。

1.10 Spec 驱动开发：规范编程与氛围编程的结合——quest模式

实践中应将 Vibe Coding（氛围编程）与 Spec Coding（规范编程）结合使⽤。对于创业团队
或个⼈项⽬，可以以 Vibe Coding 为主快速探索想法，但具体每周的任务仍需规范驱动；对于
企业团队，应以 Spec Coding 为主确保稳定交付，同时在探索性任务中⽤ Vibe Coding 快速
验证⽅案。两者结合才是成熟的 AI 编程实践。
Qoder 的quest模式采⽤ Spec 驱动的⼯作流：先与⽤户核对需求（平台、难度、功能范围、
视觉要求等），消除歧义后⽣成专业的技术⽅案，明确先做什么、后做什么，确认⽅案后再开
始编码。这种⽅式的产出质量远⾼于直接让 AI ⽣成代码的⽅式。

1.11开启记忆功能

Qoder 具备记忆功能，在设置中打开记忆设置，在写代码的过程中会⾃动记录⽤户的偏好、
⻛格等关键信息。在后续开发新功能时，会⾃动提取相关记忆，使⽣成的代码更符合⽤户的习
惯和项⽬⻛格。⽤户也可以⼿动管理这些记忆，进⾏修改或删除。

1.12 MCP 生态与能力扩展

Qoder ⽀持 MCP（Model Context Protocol），这极⼤地扩展了其能⼒边界。⽤户不仅可以
作为 MCP 的消费者（使⽤现有⼯具），还可以作为⽣产者（将⾃⼰的接⼝、⼯作流或智能体
封装成 MCP 服务）。通过将业务知识沉淀为 Rules 和知识库，再通过 MCP 挂载到 Qoder，
可以实现更加复杂的⾃动化任务。

总结

AI 编程⼯具正在重塑软件开发的⼯作⽅式。Qoder 作为这⼀领域的先⾏者，通过提示词智能
优化、仓库 Wiki、Spec 驱动模式、记忆功能、Rules 系统和 MCP ⽣态等特性，为开发者提
供了强⼤的 AI 编程体验。
掌握最佳实践的核⼼在于三点：第⼀，感知模型的能⼒边界，把任务拆到模型能很好执⾏的粒
度；第⼆，把任务交代清楚，让 AI 知道你想要什么；第三，提供充⾜和准确的上下⽂，让 AI
有⾜够的信息来完成任务。
Qoder/QoderWork-Teams版本:https://market.aliyun.com/detail/cmgj00072560.html
具体使⽤参考链接：https://docs.qoder.com/zh/extensions/hooks