孩子王用 Qoder 把一周的前后端需求缩到一天交付，造出跑着 400 个场景、300 个智能体的智枢 AI 平台
别人给业务加 AI，孩子王先把研发团队变成了 AI Native
很多公司谈 AI 转型，谈的是给业务加几个 AI 功能。孩子王想得更靠前一步：先把"造软件"这件事本身变成 AI 原生的。它的抓手，是 Qoder。
一个前后端需求，从一周变成了一天
过去写一个前后端一体的业务需求，是人把需求拆成任务，一行行敲代码，工具在旁边补全几句。孩子王的研发团队换了种方式：他们用 Qoder，把目标和验收标准描述清楚，打造了其内部的 AI 平台智枢，其交付周期从之前将近大半年缩短到两个月。
Qoder 是一款面向真实软件开发的 Agentic 编码平台。它和普通的代码补全工具不同，会先读懂整个代码库，再像工程师那样系统地推进任务。落到实际开发里，几项能力改变了团队的节奏。
面对一个模块多、前后端交织的系统，最大的门槛是"读不懂这套代码"。Qoder 的 Repo Wiki 会自动把埋在代码里的架构梳理成文档，随代码变更持续更新，还能提交进 Git 让全团队共享同一套认知。开发者问"这块怎么实现的"，不用翻源码就有答案。孩子王研发团队在 AI 平台智枢在开发过程中，由多名研发人员协同参与，通过 Qoder 的 Repo Wiki 实现了复杂模块的高效协同，特别是在 Agent 编排和知识库相关模块持续迭代和集成的过程中，发挥了重要作用。
真正做需求时，团队用的是 Quest Mode：描述清楚目标和验收标准，它会先对齐范围、设计方案，再端到端地写代码、自己验证、自己修。前后端一体意味着同时动多个技术栈的文件，这正好是它多文件修改和长程执行的用武之地。在智枢平台的skills市场这个需求的研发过程中，其中涉及前后端交互，研发同学使用Quest Mode 模式，在描述清楚skills市场的功能需求和页面交互后，在一天左右就能完成。
为了让 AI 写出来的代码贴合自家业务、而不是一堆要返工的样板，团队把编码规范、业务上下文、评审标准打包成项目级 Skills，让智能体写代码和审查时自动照着来；再用 MCP 把 Qoder 接到内部的工具和系统上。
这套变化的意义，不在于"代码写得快了多少"，而在于研发团队的默认工作方式，从"人写、AI 帮"变成了"人定义、AI 交付"。这才是 AI Native 该有的样子。
造了十几个专家智能体，公司新增了十几支真实团队
孩子王用这套方式造出来的最重要的东西，就是自研 AI 平台智枢，它以千问大模型为基座，集成了知识库、工作流、Skills 能力，具备多 Agent 协同、长短记忆上下文，支持钉钉和 H5 等通道交互。
今天智枢上跑着 400 多个业务场景、300 多个智能体，还沉淀出十几个"专家智能体"——数据分析、财务、供应链、客服、内容创作等岗位，每一个都对应着公司里一支真实的团队。其中值得一提的是大部分skills技能也是通过Qoder优化后创建出来的。
"会不会用AI" 写进了绩效考核
工具和平台之外，孩子王把转型落到了组织上。CTO 线和 HR 线一起牵头，一边升级研发协作方式，一边把"会不会用 AI"放进能力考核。
工具能省时间，但省下来的时间拿去干什么，才决定转型的深浅。对孩子王来说，Qoder 省下的开发时间，变成了团队去搭平台、打通场景、沉淀方法论的时间。
写在最后
对一家零售公司来说，最难的不是买到多先进的工具，而是把工具用成组织的能力。孩子王正在做的，是后一件事。
孩子王走过的路，有几个前提条件值得对照：
- 什么信号说明该从研发切入： 业务侧 AI 需求排队超过 3 个月、研发交付跟不上业务诉求、瓶颈在产能而不是想法。
- 怎么选第一个试点需求： 别挑最简单的（证明不了什么），也别挑最复杂的（变量太多容易失败）。挑一个边界清楚、涉及多技术栈、传统方式大概要一周的需求。
- 什么条件下 Repo Wiki 价值最大： 代码库超过几十万行、多人协同、新人看不懂旧代码。两三个人的小项目未必需要。
- 怎么决定先建哪些 Agent： 不要从"AI 能做什么"出发，从"公司有哪些团队在重复干同一类活"出发。孩子王的做法是把每个专家智能体对应到一支真实团队（财务团队→财务专家、供应链团队→供应链专家），这样 Agent 的边界、用户和评估标准都是现成的，不用从零设计。先挑人力密集、规则明确、输出标准化的团队做第一批。
- 什么时候推到组织层面： 不是一开始就喊全员 AI 化（没有成功案例支撑没人信）。先有标杆、先有数字，再推机制。