网站左侧悬浮导航代码网站备案 上一级服务商名称

网站左侧悬浮导航代码,网站备案 上一级服务商名称,旅游网站建设网站,创建自己的网页首先需要说明的一点是#xff0c;我本身不认为自己是 AI 编程的资深专家#xff0c;所谓的实践完全是基于自己使用了多款 AI 编程产品的切身感受#xff0c;以及跟 Qoder 研发同学、其他互联网公司 AI IDE 研发同学的交流#xff0c;如果分享中的观点或者认知有跟你违背的地…首先需要说明的一点是我本身不认为自己是 AI 编程的资深专家所谓的实践完全是基于自己使用了多款 AI 编程产品的切身感受以及跟 Qoder 研发同学、其他互联网公司 AI IDE 研发同学的交流如果分享中的观点或者认知有跟你违背的地方望求同存异多多交流。我今天分享的主题是 Agentic Coding 认知升级与实践闭坑指南。我相信大家都能感受到AI 编程的浪潮已经拍在了我们的键盘上问题不是用不用而是怎么用才能让它成为真正的生产力而不是解决了代码的产出又引入了新的麻烦。自我介绍首先进行下自我介绍我是徐靖峰花名是岛风来自阿里云专有云 PaaS 中间件团队主要负责网关产品的研发工作。同时我也是一个开源贡献者主要参与 Higress 和 Himarket 项目。Qoder 平台介绍为真实软件开发而生Qoder 是阿里开发的一个 Agentic Coding 平台型产品我很喜欢它的 Slogan为“真实软件”开发而生。其实我在刷 B 站的时候经常看到一些视频标题“xx AI Coding 产品太强了xx 分钟开发一个 xx”我不确定为什么大数据会给我推送这类视频因为作为一个研发我更关注的是如何将 AI 编程融入到我们真实开发的项目中为业务带来价值实际很少会有机会让我们真正从 0 到 1 构建一个新的产品而 Qoder 的 Slogan 正好与我的观念契合并且一直在朝着这个目标迭代产品这是驱使我长期使用 Qoder 的重要因素。Qoder 提供了 Qoder IDE、Qoder CLI、Qoder JetBrains 插件三种产品形态这也是 Qoder 的设计理念之一尊重每一位开发者的开发习惯。作为一个常年使用 IntelliJ IDEA 写 Java 的用户我也分享下我对于 Qoder IDE 和 Qoder JB 产品形态的选择为什么我会使用 Qoder IDE 而不是 Qoder JB 插件。Qoder JB 插件的优势主要在于其能够深度理解后端框架语义例如获取 Spring/FastAPI/Gin 的依赖关系提供符合框架规范的代码建议JB IDE 能力的深度融合可以识别 Spring Bean 依赖AST 和运行时信息的感知这都是很“诱人”的能力但是我观察到 Qoder JB 在 AI 场景下的能力还并没有完全对标到 Qoder IDE尽管它们背后可能是一套 agent loop 的实现这我不得而知。Qoder IDE/Qoder CLI 则更依赖朴素的 linux 指令这些朴素的 linux 指令通常被预训练得非常好在 SOTA 模型如此强大的环境下上下文工程和 Scaling Law 孰强孰弱我可能还是会更相信后者。如果你是刚上手 AI Coding 的驾驶员我还是会推荐优先尝试 Qoder IDE 产品形态。编程范式的演进开发者角色转变AI 介入编程最先颠覆的不是技术栈而是我们的角色定位。在传统编程时代开发者更像“乙方”代码的实现者和执行者需要事无巨细地完成每一个逻辑的编写。Vide Coding 给 AI 编程带来了很多流量但同时也带来了风险。如果开发者仅凭模糊的“感觉”或“想法”让 AI 自动生成代码自己却不加严谨地验证那我们此时的角色就变成了不负责任的“甲方”。这种模式下对于生产级、需要质量保障的真实应用是巨大的不稳定因素。而 Agentic Coding 则要求我们必须完成一次痛苦的认知升级向“导师”心态转变。这意味着我们的重要不再是敲代码而是“洞察需求、描述意图、编排逻辑、结果验收”缺少任一环节都会导致退化成 Vibe Coding。我的观念中AI 只是一个提效工具我们才是代码的第一责任人。Agentic Coding 演进历程这张图来自于 Qoder 官方介绍了 Agentic Coding 的演进历程这对于 AI 编程的新手驾驶员很有帮助可以快速了解过去几年 AI 编程的主流范式发生了怎样的变化。辅助式编程对应 Qoder 的代码补全和 Ask 模式协同式编程对应 Agent 模式AI 自主编程对应 Quest 模式我向来对代码补全不太偏爱这是我个人的习惯不分对错只有喜恶Agent 模式或者 Quest 模式是我最常用的模式但 Quest 模式虽然被定义为“AI 自主编程”也并不代表其更应该被使用我个人使用场景中Quest 模式仅占 20%Agent 模式占 80%至于原因也是跟我所维护的“真实项目”有关我会放到下边的 Quest 模式介绍中单独阐述。思维切换拥抱以对话为中心的上下文管理安利过很多同事使用 Qoder我能深刻感受到刚上手时最大的障碍不是技术而是习惯。对于一个已经习惯了传统 IDE 的开发者来说面对 Qoder IDE 那个全新的对话窗口时常常感到无措“这个上下文达到多少需要压缩”“这么多 xxx 都是干嘛用的”传统 IDE 是“文件浏览器 编辑器”我们的肌肉记忆是“我要去哪个文件里改代码”。Qoder IDE 的核心则是“以对话为中心的上下文管理器”。我们需要转变思维学会问自己“我需要告诉 AI 哪些信息才能让它快、准、省地帮我改代码”。拥抱以对话为中心为中心的上下文管理是跨越这道心理障碍的第一步。自然语言描述和对上下文管理的理解是 AI 编程的基础课。 如何掌握这个基础其实就包含在我下边分享的基础实践中。我们为何仍在观望我发现很多人对 AI 编程还停留在观望阶段我看过一场 meetup 现场的调研一个比较令我惊讶的数据显示现场听众中超过 30% 以上生产系统的代码是由 Agent 模式/Quest 模式产出的比例现场观众不到 30%这个 30%-30% 比例的调研结果很令我感到意外我自己现在大概在 90% 以上。不过通过公开数据显示倒也能够印证这一点国外 AI 编程的接受度在 90%国内的确就在 30%这说明国内市场还是蓝海国际市场则是红海。根据我的观察还在观望的团队和个人主要由以下几个因素构成顾虑一安全合规。担心内部代码使用外部模型存在风险。顾虑二信任感。他们可能也充分了解 SOTA 模型的能力但对于 AI 编程投产到真实项目还是持观望态度毕竟 AI 产出的代码容易但最后谁为业务结果买单呢团队成员对于 AI 编程的理解程度参差不齐Vibe Coding 引入的质量保障问题会不会出现解决了老问题而引入了新问题这缺乏工程实践。毕竟软件工程是工程师的基础素养AI 软件工程不是。顾虑三成本。AI 编程非常依赖 SOTA 模型特别是国内算力受限的大环境即使是阿里在 coding 领域距离 SOTA 模型仍有差距不然也不会发展出 Qoder 和灵码两条路线这使得企业采购流程阻力很大员工被迫付费上班阿里赚钱阿里花一分别想带回家。顾虑归顾虑我觉得都会有解法区分代码仓库安全等级、掌握 AI 编程的最佳实践、小投入换取高产出。我想说AI 编程一定会成为主流我们早晚需要拥抱它真正的成本是机会成本它的价值远超价格。基础实践Ask Agent 核心循环之前花了很长的篇幅讲 AI 编程发展和思维的转换终于到了我个人的实践经验部分。我的日常工作流很简单概括起来就是先 Ask提问再 Agent行动。Ask (问答模式)用来理解代码摸清脉络。它不会触发代码编辑让你带着敬畏之心去询问存量代码的逻辑和背景。Agent (智能体模式)一旦脉络清晰立刻切换到智能体让 AI 结对编程动手开干自主编码。Qoder 真正让人上瘾的原因就在于它的 Agent 模式已经迈过了那个拐点在效率、成本、质量和易用性上达到了一种令人惊叹的平衡。如果你是一个 AI 编程新手觉得那些理论太麻烦我建议你也别瞎折腾啥都别管直接 Agent 模式开干这就像是自动挡的车虽然操控感不强但好在省事等实践中有了新的感悟了再切换到手动挡也不迟。基础实践RepoWiki 使隐性知识显性化RepoWiki 是 Qoder 的一大竞争力优势貌似具备这个功能的竞品还真不多。Qoder 的 RepoWiki 生成的文档可以分为给人看的和给 AI 看的也是一种上下文的管理手段。试想一下你突然有一天要去接收一个用户文档不齐全的仓库RepoWiki 可以帮助你快速理解项目简直是 life saver。也不用担心 RepoWiki 生成这么多文档会很消耗 creditsQoder 用的是专门训练过的模型我实测下来一个中型仓库才花了 20 多 credits。增量代码似乎也会自动更新 wiki如果我没观察错的话。基础实践上下文管理无数文章科普过“提示词工程”过渡到了“上下文工程”但是说实话我自己都没完整研究明白什么是科学的“上下文工程”又或许上下文工程就是我所介绍的这些实践。上下文管理是决定 AI 编程质量的灵魂。“精准投喂手动添加上下文一定是一个好习惯”。虽然 Qoder 具备强大的代码检索能力但手动添加核心线索能极大地减少 AI 在工程中“盲搜”的负担提升命中率让它一次性把事情做对。常用的 file、folder、codeChanges、gitCommit 它们不仅仅是命令而是我们在向 AI 传递明确的意图和边界。Qoder 也提供了 “压缩上下文” 的功能我的态度是敬而远之只有少部分场景我会使用。相比压缩功能本身我发现观察上下文窗口的占用比例更有价值。这个占用比例是一个绝佳的任务复杂度“指示器”。如果一个任务聊了几轮后上下文窗口就飙升到 60% 以上这其实是 Qoder 在向你发出信号“这个任务太大了不适合在 Agent 模式下一次完成需要进行拆分” 这时我宁愿新开一个窗口处理子任务也不会选择压缩上下文。为什么不压缩主要是担心信息失真。压缩算法是个黑盒我无法确定关键信息是否在压缩中被“优化”掉了万一它“取其糟粕去其精华”呢最后还是绕不开成本。Qoder 的 credits 计费模式最终还是会跟 Token 总量挂钩过长的上下文也会带来 credits 焦虑。所以保持上下文的“精简”和“健康”既能保证质量又能节省开销。这里要特别提一下基础模型。我在 Qoder 交流群里看到不少人还在用基础模型。基础模型最大的瓶颈就是上下文窗口太小一个原子任务还没做完窗口就爆了。如果你正在用基础模型体验请务必知道这只是模型的上限不是 Qoder 的上限。基础实践Rules 与 Memory规则 (Rules) 是项目级的“铁律”你可以把项目的强制规范写进去让 Qoder 严格遵守尽管目前它在规则遵循的一致性上还有提升空间。目前我的项目加了不少规则比如国际化规范组件库规范命名规范接口规范私域知识引导等等。规则的一些最佳实践保持简洁让规则聚焦且明确无歧义结构清晰使用项目符号、编号列表或 Markdown 格式以提升可读性包含示例提供“良好”的代码示例以指导模型迭代与优化根据模型输出和反馈不断完善规则。规则和记忆都属于 Qoder 预置的上下文二者的主要区别规则属于项目级记忆属于用户级当规则与记忆冲突时规则优先规则需要手动维护记忆则分为主动记忆和自动记忆。我个人主要使用自动记忆不太会主动管理记忆只有当发现记忆出了明显问题时才会手动清理。自动记忆功能用好了会让你产生一种“Qoder 越来越懂我”的感觉。它记住了你的编码习惯和偏好即使你在多个项目或窗口间切换也能减少大量重复描述背景的麻烦。进阶实践Quest 模式实现 SDD如果 Agent 模式是结对编程那么 Quest 模式就是任务委派。它专为复杂任务设计因为它践行了 Spec Driven 开发的理念彻底将“思考”与“执行”分离。Quest 模式遵循“设计 → 执行 → 总结”的三步原则。设计 (Spec Driven)开发者通过多轮对话和 AI 一起打磨一份 Markdown 格式的设计方案。这份设计文档是人与人、人与 AI 之间最重要的沟通媒介执行 (AI 自主编程)一旦方案敲定AI 就能心无旁骛一次性执行到底总结最终产出代码和结论。Quest 模式的强大之处在于它强迫你“想清楚了再干”极大地避免了复杂任务导致上下文窗口迅速膨胀的问题将我们的角色从执行者提升为架构师。但 Spec Driven 一定是 AI Coding 的银弹吗一定是终态吗如果是的话做到什么程度是一个最佳实践呢是 spec-kit 这种三方统一的规范还是 kiro 实现的复杂 spec 设计流程反正我个人是接受不了 spec-kit 和 kiro感觉不太适合中国宝宝的体质。而 Qoder 的 Quest 模式我也仅会在复杂需求和系统性重构时会使用实际需求开发使用 Agent 模式进行渐进式的开发更符合我现阶段 80% 的场景。进阶实践Quest 模式异步委派Quest 模式可以结合 git worktree 和云端沙箱实现异步委派实际上后者我没用过Qoder 的主要设计思路是好的让 AI 当牛马开发者下班了还可以远程干活但现阶段的确给我一种压得喘不过气的感觉代码它是写好了我还是要 review 的所以从来没用过。而 git worktree 则是一个很好用的功能例如你可以一边丢一个 Quest 任务去生成单测基于 worktree 的隔离机制我可以继续在当前分支继续用 Agent 模式进行结对编程。进阶实践Token 效率法则当我们评估 AI 编程成本时不能只看单位成本而更应该关注任务总成本。任务总成本 单位成本 × 迭代步数 人力成本想象一下一个极致模型Y可能比经济模型X单位成本更高。但如果经济模型需要 10 步才能完成任务10X而极致模型只需 3 步就能成功交付3Y。只要 3Y10X那么极致模型反而更便宜也更快效果还更好。根据 Token 效率规则Auto 模式的最终目标应该根据总成本、质量、速度加权系数后提供给用户一个最优解而不应该完全不路由到极致模型。但我相信 Qoder 团队不会不理解 Token 效率法则这应该也是当下难以达到最优解的无奈之举。我的实践是日常开发任务选择 Auto 模式基本够用。进阶实践Git 哲学遇见 Agentic Coding我从未想过Git Commit 的哲学跟 AI Coding 之间有如此大的默契。在一个多人协同开发的内部项目中很容易看到一堆不规范的 commit message而在 Qoder 的加持下自动生成 commit message 这个小功能发挥了绝大的价值。当你的 git log 变得规范后好处是连锁的可以和 gitCommit 功能联动精准回溯。改坏了代码手滑接受了至少还有一个清晰的回溯点。通过 commit message 就能快速理解同事的工作沟通成本大降。我发现有的人会尝试添加这样的 rule自动提交代码并在此之前设置 git config user.name vibe-coder这很有创意但我会认为这是一个 bad case因为这似乎在尝试进行免责声明这是 AI 提交的代码与我无关。Agentic Coding 只是一个工具第一责任人依旧是 AI 驾驶员。进阶实践划清模型与工具的边界理解哪些任务应该交给模型哪些任务应该让模型帮你创造一个“工具”来解决是掌握 AI 编程进阶能力的一个依据。大模型是概率工具不是逻辑引擎它擅长创造和模仿但不擅长精确和重复。且模型存在上下文窗口限制和幻觉。基于这个认知我的原则是一次性的、创造性的任务交给模型需要重复的、确定性的任务让模型帮我创造一个工具来解决。下文也会有一个案例分享这个实践的细节。警惕 Vibe Coding在维护开源项目 Higress 的过程中我观察到一种因 AI 编程产生的坏味道——Vibe Coding。一些社区贡献者提交了 AI 味很浓的代码但缺少必要的方案设计和验证导致审查的压力全都转移到了 Reviewer 身上。我曾在社区吐槽这个现象vibe coding → vibe review → A vibe project.依靠 UT 和 CI 来对 AI 编程进行验证是一个兜底方案同时也给质量保障带来了一个新的哲学话题如果保障 AI 编程的质量AI 编程带来的效率提升也对研发人员提出了新的素养要求我们需要建立新的质量保障体系可测试性优先 尽早将“代码必须可测试”这一准则加入到 rules 中从源头上避免 AI 生成无法进行单元测试的代码。谨慎“全局接受” Agent 模式一次性生成大量代码后很容易有“一键接受”的冲动。但 Qoder 目前不支持撤销一旦接受就无法回头。建议还是文件 by 文件的审查和接受。推行 Prompt Review 或者 Spec Review 在 Higress 社区我们已经开始尝试这一举措。对于有明显“Vibe Coding”痕迹的提交要求贡献者附上他的核心 Prompt。在开源社区这种异步协作的环境下Prompt Review 极大地保护了 Reviewer。案例分享swagger2xml 工具需求 将一个 Spring Boot 项目 Controller 层的接口自动生成符合内部 API 平台规范的元数据 XML 文件用于补充 API 文档。我的弯路最初我想直接让 Qoder 基于模型能力逐个接口生成最终的 XML 文件。踩到的坑XML 格式一致性难以保证AI 时不时会“自由发挥”。消耗大量 credits成本高。上下文窗口容易爆炸。一次性工作无法复用。我的转向 回到“划清模型与工具的边界”的实践我让 Qoder 帮我创造一个工具一个专门用于生成元数据的项目。这个项目 99% 的代码都是由 Qoder 完成的这完美体现了“用 AI 造工厂”的思路。案例分享跨项目协作Qoder 目前没有直接的跨工程管理能力同一 workspace 包含两个仓库依旧不够优雅因为上下文不完全共享。我的工作流是后端开发完成后用 Quest 模式生成一份详细的对接方案包含接口地址、参数、返回格式等。然后在前端项目中打开这份方案再用 Quest 模式基于方案完成接口的对接和调试。Qoder 的Quest 模式在这个过程中像一座桥梁助力后端程序员轻松跨界搞定前端的活。关注我掌握Qoder最新动态