十几个项目同时跑 Qoder，用了大半年，我的工作方式彻底变了——从逐行写代码，变成定方向、喂上下文、验结果。
"用了 Qoder 大半年，我的工作方式彻底变了——从逐行写代码，变成定方向、喂上下文、验结果，经历十几个项目的踩坑经历，最终沉淀成团队的经验，新需求来了不再从头踩坑，现在2分钟能落地一个退款需求。"——富友资深研发工程师 鄂建
我是鄂建，富友支付的资深研发工程师。十几个项目同时跑 Qoder，用了大半年，我的工作方式彻底变了——从逐行写代码，变成定方向、喂上下文、验结果。
转变不是一天发生的。和大多数团队一样，我们也经历了"装上工具 → 觉得还行 → 踩一堆坑 → 摸索出方法论"的完整弧线。今天把这条路拆开讲讲。
这是我们探出来的第一条铁律，听起来像废话，但大多数团队踩的坑恰恰就在这里。
"这边代码有问题，你帮我改一改。"——这是我见过最常见的提示词，也是最没用的一句。你把这话说给隔壁工位的同事，他也不知道你要干嘛，何况是 AI。
正确的做法是告诉 AI：
我养成了一个习惯：写复杂需求时绝不直接在对话框里打字。对话框太窄，写一两百字就看不全，思路也跟着断。
我的做法是先开一个记事本，用占位符整理完整需求描述，写完再整体粘贴进 Qoder，末尾按顺序 @ 相关文件。结构化表达长这样：
三行搞定。而不是 200 字的长篇大论让 AI 自己去猜重点。
策略很明确：先给骨架，再补细节。第一轮给目标和约束，AI 输出后再针对性补充，三轮之内收敛。Qoder 右下角还有个"提示词增强"功能，写完点一下，AI 帮你优化表达结构——输入质量不好，输出质量就不会好。
分享一个我在探索型项目中常用的方法——让 AI 假设项目已经失败，然后回答：最早是什么时候出问题的？哪个关键决策走错了方向？哪个风险应该最早识别却被忽略了？
我还会加一句："用给种菜的大爷讲明白的方式说。"
AI 不知道你的技术水平，但它知道"种菜的大爷"是什么水平。输出会尽可能直白，没有技术术语的烟幕弹。
这个提示词的真正目的是让 AI 以终局视角提前暴露风险。我们在一个电商项目中靠这个方法，提前识别出高并发场景的性能瓶颈，引入了异步队列设计，避免了上线后崩溃。
早期我们踩得最多的坑是"上下文污染"。典型路径是这样的：第一轮 AI 改空指针问题方案有误，第二轮按错误方案继续修改，第三轮你指出问题，第四轮 AI 又回到第一轮的错误假设——死循环。
我们总结出一条硬规则：同一问题迭代超过 3 次未收敛，立即重开窗口。别心疼之前的对话，一个干净的上下文比在污染环境里反复纠正成本低十倍。
同理，别一口气 @ 七八个文件。一个文件 600-1000 行，七八个就上万行，200K 上下文直接撑满，触发压缩后 AI 就跑偏了。每次对话只给必要的上下文，别混无关话题。
用了一段时间后，我们发现不同任务匹配不同模型和模式，效果差异巨大：
架构设计用极致模型，Bug 修复用性能模型，日常开发用 Auto。编码模式上，Editor 是你开车、AI 帮看路；Quest 是你告诉目的地、AI 先确认再规划；专家团是招了一支开发队。
但消耗差异很现实：Quest 和专家团的消耗约是 Editor 的 8 倍。日常编码别动不动开专家团，一两天就能把 2000 Credits 烧完。
基本功打扎实之后，瓶颈变了。不再是"怎么跟 AI 对话"，而是"怎么让 AI 在我的项目环境里自主工作"。
MCP（Model Context Protocol）是让 AI 突破本地文件边界的关键。没有它，AI 只能读你 @ 的代码；有了它，AI 能上网搜资料、查数据库、操作浏览器、调用外部系统。
但配置原则是少即是多：数量控制在 8 个以内。每个 MCP 的工具描述会全量加载到上下文，装太多直接撑爆。按实际需要开启关闭就好。
以前排查 Bug，我要手动复制表结构粘贴给 AI，AI 给方案，我再手动调整。来回搬运数据就占了大半时间。
现在，在 IDE 对话框里直接 @ 数据库连接。AI 能读取 Schema 生成 Entity、Repository、Controller，字段名、类型、约束均正确对应。
更关键的是排障场景——AI 读代码逻辑的同时自动查库确认数据，直接判断是代码问题还是数据问题。不用你当中间人搬运信息，它自己查、自己判断。
传统流程：SSH 登录服务器 → 手动查日志 → 复制内容 → 切换到 AI → 描述问题 → AI 猜答案 → 再回服务器验证。一个小问题折腾一两个小时。
现在 AI 直连服务器，实时读取日志和配置，一步到位给出针对性方案。
当然安全准则必须遵守——最小权限账号、高风险命令手动确认、生产环境慎用、操作完整记录日志。
我把 Hooks 比作 Java 里的切面——前置增强、后置增强。
为什么需要它？我们团队真实踩过的坑：Prompt 里不小心粘了一段
我们目前有十几个项目在用 Qoder，规则配置是重中之重。不同项目有不同策略：
新项目直接复用通用规则模板（java.md、code.md 等）；迭代项目先生成 RepoWiki，让 AI 根据现有代码风格总结一版规则，人工检查后微调；多子项目在根目录放 AGENTS.md 做地图导航。
配置原则只有一条：规则太多等于没有规则。单文件控制在 200 行以内，先加核心规则，根据对话反馈持续更新，冗余时大胆删除。
记忆能记录用户偏好、技术栈、命名风格、历史踩坑经验。管理上用延迟加载策略——按需加载，别每次对话都全量发送。全局记忆控制数量，定期清理过时内容。
核心价值是累积效应：用得越久，AI 越懂你的项目，犯同样错误的概率越低。
当基础功能和环境配置都就绪之后，真正的质变发生了。
我们引入了 OpenSpec（Spec-Driven Development）工作流，四步闭环：探索 → 提案设计 → 实现 → 归档。它比 Plan 模式更稳定，提案持久化到项目仓库，新开窗口、隔天继续都不会丢。
举一个真实案例。我输入"帮我开发一个订单退款需求"：
探索阶段，AI 自动检索项目结构，扫描现有表和接口，梳理业务现状。澄清阶段，AI 主动提问——退款场景是什么？谁能退？什么时候能退？需不需要审核？提案阶段，输出三份文档——提案变更文档、设计文档、开发任务文档，全部细化到字段级别。执行阶段，拆成 23 个细粒度任务，2 分钟左右生成退款实体类、Mapper、DTO、五个接口、一张新表，变更 24 个文件。归档阶段，确认无误后归档，下次再开窗口 AI 会自动检查未归档任务继续完成。
这就是为什么任务拆解如此重要——大方向容易出问题，但拆到字段级别，AI 就是精确执行。
用了大半年后，我们总结出一条反直觉的规律：上下文越精简，Credits 消耗越少，AI 输出反而越准。
具体落地为几个关键动作：AGENTS.md 不超过 100 行（太长 AI 反而不遵守）；规则分类放到
半年下来，我最大的感受是：程序员的角色正在发生根本性转变。
我们不再是"写代码的人"，而是"定方向、控质量、做判断的人"。AI 负责把事情做快，人的思考负责把事情做对。
如果要给刚开始用 AI Coding 的团队几句建议：先别急着上复杂配置，把上下文管理练扎实；别心疼重开窗口的成本；规则少而精，别贪多；频繁提交而非批量提交——写完立即验收，没问题直接提交 Git。
工具会越来越强，但驾驭工具的方法论不会过时。
本文内容来源于富友支付资深研发工程师鄂建线上分享《Qoder AI 最佳实践经验分享》
最初的认知：AI 输出质量 = 你给的上下文质量
这是我们探出来的第一条铁律，听起来像废话，但大多数团队踩的坑恰恰就在这里。
"这边代码有问题，你帮我改一改。"——这是我见过最常见的提示词，也是最没用的一句。你把这话说给隔壁工位的同事，他也不知道你要干嘛，何况是 AI。
正确的做法是告诉 AI：@OrderService.java 第 156 行报空指针，订单状态为空时触发。具体位置、问题现象、相关文件——缺一不可。
这个认知看似简单，但要真正落地到团队习惯里，我们花了不少时间。
第一阶段：把基本功练扎实
从"随手打字"到"结构化输入"
我养成了一个习惯：写复杂需求时绝不直接在对话框里打字。对话框太窄，写一两百字就看不全，思路也跟着断。
我的做法是先开一个记事本，用占位符整理完整需求描述，写完再整体粘贴进 Qoder，末尾按顺序 @ 相关文件。结构化表达长这样：
一个让 AI "事后复盘"的提示词技巧
分享一个我在探索型项目中常用的方法——让 AI 假设项目已经失败，然后回答：最早是什么时候出问题的？哪个关键决策走错了方向？哪个风险应该最早识别却被忽略了？
我还会加一句："用给种菜的大爷讲明白的方式说。"
上下文污染：我们交过的学费
早期我们踩得最多的坑是"上下文污染"。典型路径是这样的：第一轮 AI 改空指针问题方案有误，第二轮按错误方案继续修改，第三轮你指出问题，第四轮 AI 又回到第一轮的错误假设——死循环。
我们总结出一条硬规则：同一问题迭代超过 3 次未收敛，立即重开窗口。别心疼之前的对话，一个干净的上下文比在污染环境里反复纠正成本低十倍。
同理，别一口气 @ 七八个文件。一个文件 600-1000 行，七八个就上万行，200K 上下文直接撑满，触发压缩后 AI 就跑偏了。每次对话只给必要的上下文，别混无关话题。
模型和模式：不是越强越好
用了一段时间后，我们发现不同任务匹配不同模型和模式，效果差异巨大：
架构设计用极致模型，Bug 修复用性能模型，日常开发用 Auto。编码模式上，Editor 是你开车、AI 帮看路；Quest 是你告诉目的地、AI 先确认再规划；专家团是招了一支开发队。
但消耗差异很现实：Quest 和专家团的消耗约是 Editor 的 8 倍。日常编码别动不动开专家团，一两天就能把 2000 Credits 烧完。
第二阶段：从"会用"到"配环境"
给 AI 装上外部能力：MCP
MCP（Model Context Protocol）是让 AI 突破本地文件边界的关键。没有它，AI 只能读你 @ 的代码；有了它，AI 能上网搜资料、查数据库、操作浏览器、调用外部系统。
但配置原则是少即是多：数量控制在 8 个以内。每个 MCP 的工具描述会全量加载到上下文，装太多直接撑爆。按实际需要开启关闭就好。
数据库直连：AI 自己查、自己验
以前排查 Bug，我要手动复制表结构粘贴给 AI，AI 给方案，我再手动调整。来回搬运数据就占了大半时间。
现在，在 IDE 对话框里直接 @ 数据库连接。AI 能读取 Schema 生成 Entity、Repository、Controller，字段名、类型、约束均正确对应。
SSH 远程排查：从来回折腾到一步到位
传统流程：SSH 登录服务器 → 手动查日志 → 复制内容 → 切换到 AI → 描述问题 → AI 猜答案 → 再回服务器验证。一个小问题折腾一两个小时。
现在 AI 直连服务器，实时读取日志和配置，一步到位给出针对性方案。
Hooks：用切面思维管住 AI
我把 Hooks 比作 Java 里的切面——前置增强、后置增强。
为什么需要它？我们团队真实踩过的坑：Prompt 里不小心粘了一段 access_key=AKIA...，一走神就发给模型了；AI 要执行 rm -rf /data/，点了确认，几个 G 的数据没了；AI 说"完成了"，一跑测试全是编译报错。
Hooks 解决三个问题：提交前拦截敏感信息、执行后自动跑编译验证、响应完成后将变更沉淀到外部系统。配置提交到 Git，整个团队共享同一套安全网。
规则配置：十几个项目的实战经验
我们目前有十几个项目在用 Qoder，规则配置是重中之重。不同项目有不同策略：
新项目直接复用通用规则模板（java.md、code.md 等）；迭代项目先生成 RepoWiki，让 AI 根据现有代码风格总结一版规则，人工检查后微调；多子项目在根目录放 AGENTS.md 做地图导航。
配置原则只有一条：规则太多等于没有规则。单文件控制在 200 行以内，先加核心规则，根据对话反馈持续更新，冗余时大胆删除。
记忆系统：让 AI 越用越懂你
记忆能记录用户偏好、技术栈、命名风格、历史踩坑经验。管理上用延迟加载策略——按需加载，别每次对话都全量发送。全局记忆控制数量，定期清理过时内容。
核心价值是累积效应：用得越久，AI 越懂你的项目，犯同样错误的概率越低。
第三阶段：2 分钟落地一个退款需求
当基础功能和环境配置都就绪之后，真正的质变发生了。
我们引入了 OpenSpec（Spec-Driven Development）工作流，四步闭环：探索 → 提案设计 → 实现 → 归档。它比 Plan 模式更稳定，提案持久化到项目仓库，新开窗口、隔天继续都不会丢。
举一个真实案例。我输入"帮我开发一个订单退款需求"：
探索阶段，AI 自动检索项目结构，扫描现有表和接口，梳理业务现状。澄清阶段，AI 主动提问——退款场景是什么？谁能退？什么时候能退？需不需要审核？提案阶段，输出三份文档——提案变更文档、设计文档、开发任务文档，全部细化到字段级别。执行阶段，拆成 23 个细粒度任务，2 分钟左右生成退款实体类、Mapper、DTO、五个接口、一张新表，变更 24 个文件。归档阶段，确认无误后归档，下次再开窗口 AI 会自动检查未归档任务继续完成。
这就是为什么任务拆解如此重要——大方向容易出问题，但拆到字段级别，AI 就是精确执行。
省 Credits 的核心逻辑
.qoder/rules 下按需加载而非始终生效；生成的 RepoWiki 必须人工精简，删掉用不到的部署方案；加 .qoderignore 排除 build 产物；要求 AI 输出总结控制在 100 字以内——那些长篇复述我们从不看。
还有一条容易被忽略的：善用大模型官网做非编码类问答，免费、不限量、有时更快。把 Credits 留给真正需要项目上下文的编码任务。
写在最后
半年下来，我最大的感受是：程序员的角色正在发生根本性转变。
我们不再是"写代码的人"，而是"定方向、控质量、做判断的人"。AI 负责把事情做快，人的思考负责把事情做对。
如果要给刚开始用 AI Coding 的团队几句建议：先别急着上复杂配置，把上下文管理练扎实；别心疼重开窗口的成本；规则少而精，别贪多；频繁提交而非批量提交——写完立即验收，没问题直接提交 Git。
工具会越来越强，但驾驭工具的方法论不会过时。
本文内容来源于富友支付资深研发工程师鄂建线上分享《Qoder AI 最佳实践经验分享》