AI编码实战 | 0 行手写代码，2 天重构 2 万行 Vue 项目
作者：vivo AI 技术团队- Liu Shudong
在不手写一行代码的情况下，用自然语言指挥 BlueCode AI 编程助手，在 2 个工作日内完成了一个 4 年历史、2 万行 Vue 项目的全面重构——157+ 个文件变更、108 个单元测试从零建立、包体积下降 30%、Element Plus 完全移除。
文章的核心观点是：AI 辅助开发的关键不在 AI 本身的能力，而在于人为 AI 建立的约束体系——通过 Skills 技能包注入领域知识、AGENTS.md 沉淀项目规范、飞轮效应让错误只犯一次，将模糊目标转化为 AI 可精确执行的高质量指令，从提出需求到代码合入，甚至本篇分享也是AI生成。
1分钟看图掌握核心要点👇
关于 BlueCode：
BlueCode 是 vivo 内部的 AI 编程助手（CLI 形态），类似业界的 Claude Code，支持通过自然语言指令完成代码生成、重构、调试等开发任务。它原生支持 Skills 技能包机制与 AGENTS.md 项目规范注入，能够将团队的领域知识和工程规范沉淀为 AI 可复用的约束体系，是本文实践的核心工具载体。
一、先说清楚：“0 行手写代码”是什么意思？
不是说我什么都没做。
我做了这些事：
- 诊断：跑 npm outdated，看构建产物体积，找出问题
- 决策：决定分几个阶段、先做什么后做什么、什么该删什么不该删
- 指令：用自然语言告诉 BlueCode 要做什么
- 验收：看 BlueCode 改完的代码，确认逻辑正确
- 纠偏：BlueCode 犯错时指出来，追加约束
我没做的事：
- 没有打开编辑器手写任何一行代码
- 没有手动修改任何文件
- 没有手动 copy-paste 代码片段
所有代码变更——包括 Vue 组件、TypeScript 类型、composable 函数、单元测试、CSS 样式、构建配置——100% 由 BlueCode 在终端中直接编写。
二、项目现状：4 年老项目，债务清单很长
千询是 vivo 内部的 AI 对话产品，前端基于 Vue 3 + Vite + Arco Design Vue。
4 年快速迭代积累了大量债务：
- Vite 3（已 EOL）、TypeScript 4.9、axios 0.24 — 主要依赖全线落后
- SessionView.vue 2400+ 行 — God Component，SSE + 消息 + 分享全塞一个文件
- Arco Design + Element Plus 双框架并存 — Element Plus 只用了一个 Popover
- highlight.js 全量 939KB — 190+ 语言全部打包，实际只用 15 种
- 大量实验性功能所剩下冗余代码、测试覆盖待完善等等
三、2 天产出
不光代码产出，还有重构日志和详细分析，甚至汇报ppt+分享blog，资深工程师独立完成需要 12-16 个工作日。BlueCode 协作下 2 个工作日。
四、我和 BlueCode 各做了什么？
这才是本文最想讲清楚的事。
我的角色：导演
BlueCode 的角色：全栈执行者
注意：以上所有代码、测试、样式、文档，没有一行是我手写的。全部通过自然语言指令由 BlueCode 在终端中完成。
五、实际对话长什么样？
举几个真实的例子，感受一下“0 手写代码”的工作方式：
例 1：代码拆分
我：把 SessionView 中所有 SSE 相关的变量和函数提取到
src/hooks/useSSEStream.ts，保持行为不变，改完跑 build
BlueCode：[读取 SessionView.vue] → [分析 SSE 相关代码边界]
→ [创建 useSSEStream.ts] → [修改 SessionView import]
→ [运行 npm run build] → 构建通过 ✅我说了一句话。BlueCode 读文件、分析边界、创建新文件、改旧文件、跑构建——全自动。
例 2：测试编写
我：给 chatStore 的 setLoading 写单元测试，
覆盖 per-session loading 的四种场景
BlueCode：[读取 store 源码和 types] → [生成 4 个测试用例]
→ [运行 npx vitest run] → 4/4 passed ✅例 3：UI 迭代
背景：完成了代码层面的重构，但 UI 还是旧的， Figma 社区有大量的开源的产品设计稿——侧边栏卡片化、渐变按钮、透明顶栏、胶囊型输入框，这套现代设计语言正好契合我们的产品定位。
但直接照搬并不可取——我们的功能形态、信息密度与通用模板并不完全一致。所以我让 BlueCode 做的是"参考其设计语言"：提取设计稿中的视觉规范（间距、圆角、配色、组件形态），结合我们自己的业务场景重新落地，并明确约束改动范围只在样式层。
我：参考这份 Figma 设计稿的视觉语言（间距体系、圆角规范、配色方案、组件形态），
重构当前页面的 UI 风格，使其符合现代 AI 对话产品的设计趋势。
[粘贴开源 Figma 设计稿链接]
约束：
1. 只改 CSS/Less 和模板 class，不动组件逻辑
2. 保留我们自己的品牌色与 Logo
3. 适配我们已有的功能模块（如 XX、XX），不是 1:1 复刻
BlueCode：[通过 Figma MCP 读取设计稿节点树]
→ [分析布局结构、间距、圆角、配色、阴影]
我：未读会话加个视觉指示
BlueCode：[加了红点 + pulse 动画]
我：太突兀了，像通知未读数
BlueCode：[改成文字呼吸发光]
我：不够明显
BlueCode：[改成图标缩放脉冲]
我：跳动太频繁了
BlueCode：[改成底部流星拖尾]
我：拖尾太花哨，去掉
BlueCode：[改成极细进度流光]
我：底部轨道也去掉
BlueCode：[去掉轨道底色，只留扫过的高光]6 轮对话，每轮 BlueCode 响应时间 10-30 秒。总共不到 10 分钟。如果自己手写 CSS 做 5 次迭代，至少 30-40 分钟。
例 4：复杂架构设计
我：切换会话时如果正在 SSE 生成，不要中断，让它在后台继续
BlueCode：[分析现有 SSE 架构] → [提出三层隔离方案]
→ [修改 useSSEStream.ts: per-stream 闭包]
→ [修改 chatStore: session 感知 setLoading]
→ [修改 SessionView: bgStreams Map + 路由 watcher]
→ [写 4 个单元测试]
→ [运行 type:check + vitest] → 全部通过 ✅这个功能涉及 3 个文件的深度改造、40+ 处现有引用的兼容性、loading 状态竞争的处理。
值得展开说说这个"三层隔离"方案。原来的架构下，SSE 流实例是一个全局唯一的 ref，chatStore.loading 是一个全局唯一的 boolean。切换会话就会调 stopMessage() 中断生成——用户必须等一个回答完成才能看另一个会话。
BlueCode 的方案：
第一层（useSSEStream.ts）：
每次 fetchChat() 内部创建独立闭包——currentSource（当前 SSE 实例）、streamSessionId（捕获当时的会话 ID）、destroyStream()（仅销毁自己的流）。后续调用不会覆盖前一个流的引用。
第二层（chatStore）：
setLoading(false, sid) 增加一行判断——只有 sid === loadingSessionId 时才清除。这样后台流结束时不会清掉前台的 loading。而现有 40+ 处 chatStore.loading 引用零改动。
第三层（SessionView.vue）：
bgStreams = new Map() 缓存被切走的流。切走时存 { source, msgList, loading }，切回时恢复。后台收到消息时路由到 bgStreams 的 msgList 里。
还有一个精巧的细节：SSE close 事件触发时，StreamText 缓冲区可能还有未渲染完的文本。BlueCode 加了 waitDrain 安全网——每 50ms 轮询缓冲区是否清空，清空后才调 destroyStream()。这种边界 case 的处理，说实话比很多人工编码更周全。
BlueCode 独立完成了方案设计 + 编码 + 4 个单元测试。我只说了一句“切换会话时不要中断 SSE”，从指令下达到全部测试通过，不到 30 分钟。
六、为什么 BlueCode 能做到？— 背后的方法论
“0 手写代码”不是 BlueCode 天生就能做到的。第一天如果不做准备，BlueCode 会犯各种错。关键在于我做了这几件事：
1. Skills 技能包 + find-skills 自动安装：AI 给自己装插件
现在主流的 AI 编程助手（Claude Code、BlueCode 等）都支持 Skills 系统，可以给 AI 加载特定领域的知识和工作流规范。这不是某一家的专属能力，而是 AI 编程助手生态的通用机制。
关键是：我从头到尾没有手动安装过任何一个技能。 全部由 find-skills 自动完成。
find-skills 是一个“元技能”——AI 在执行任务时，遇到新类型的工作会自动触发 find-skills，判断自己缺什么能力，自己搜索、自己安装、自己用。整个过程不需要我干预。
实际发生的流程：
BlueCode 开始做依赖升级
→ 自动触发 find-skills → 发现 vite、refactor-plan → 自动安装
BlueCode 开始写 InjectionKey 类型
→ 自动触发 find-skills → 发现 typescript-advanced-types → 自动安装
BlueCode 开始拆分 God Component
→ 自动触发 find-skills → 发现 refactor-method-complexity-reduce → 自动安装
BlueCode 开始写单元测试
→ 自动触发 find-skills → 发现 vue-testing-best-practices → 自动安装
BlueCode 开始做 UI 重设计
→ 自动触发 find-skills → 发现 frontend-design → 自动安装最终累计自动安装了 12 个技能，覆盖项目技术栈的每个角落：
装技能前 vs 装技能后的对比非常明显：
没装 vue-testing-best-practices 之前，
BlueCode 写 Pinia Store 测试会忘记 setActivePinia(createPinia())，直接 useAppStore() → 报错 “getActivePinia was called with no active Pinia”。要来回改 2-3 次。装了之后一次就对。
没装 web-performance-optimization 之前，
BlueCode 会建议用 React.lazy() 的方式做代码分割（明明是 Vue 项目）。装了之后知道用 defineAsyncComponent + Vite 的
manualChunks。
没装 refactor-plan 之前，BlueCode 会直接上手改代码，改到一半发现依赖没升级、类型没定义。装了之后会先生成分阶段计划，每步有验证标准。
一句话总结：Skills 让 AI 从通才变成专家，而 find-skills 让这个过程全自动——AI 自己判断缺什么能力，自己搜索，自己安装，自己用。 12 个技能全部由 find-skills 自动安装，我没有手动装过一个。首次正确率从 ~60% 提升到 ~95%，这在 100+ 次代码变更中省下的返工时间非常可观。
2. AGENTS.md：AI 的“入职文档”，越用越准
AGENTS.md 是由 AAIF 基金会推行的开放标准，已被 OpenAI、Google、Anthropic 等主流 AI 编程工具采纳为事实标准， AI 编程工具每次启动会话时自动读取，相当于给新入职的同事写了一份"项目须知"：
## Build & Run Commands ← 告诉 BlueCode 怎么构建和测试
npm run dev / npm run build / npm run type:check / npm run test
## Tech Stack ← 技术栈版本信息
Vue 3.5 + Vite 5 + Pinia 2.3 + Arco Design Vue + TypeScript 5.8
## Project Structure ← 目录结构说明
src/api/ → API 函数
src/hooks/ → Composition API composables
src/store/ → Pinia stores
src/views/ → 页面和页面级组件
## Code Style ← 代码规范
2 空格缩进，分号，单引号，printWidth: 80
vueIndentScriptAndStyle: true
组件 PascalCase，composable useXxx，store useXxxStore
## Pinia Store Pattern ← Store 的写法模板
Options API: defineStore('name', { state, getters, actions })
## Composable Pattern ← Composable 的写法模板
export function useXxx(params?: Ref<T>){ ... return { state, action } }
## Testing ← 测试框架和模式
Vitest + jsdom + @vue/test-utils
beforeEach → setActivePinia(createPinia())
## Important Notes ← ⚠️ 关键约束（最重要的部分！）Important Notes 是核心中的核心。 每一条都是踩过坑之后加的硬约束：
- Do NOT remove @arco-design/web-vue/dist/arco.css from main.ts
- Do NOT add comments to code unless explicitly asked
- CSS theme variables follow --theme-backound-N convention
(preserve the "backound" typo for consistency)
- The app uses a custom SSE implementation(src/utils/sse.ts),
not native EventSource
- After any code change, always run: npm run type:check
- Private npm registry at https://npm.vmic.xyz, use --legacy-peer-deps“不要做什么”比“要做什么”更重要。因为 BlueCode 的默认行为是积极优化——看到它认为“多余”的配置就想删，看到“不规范”的写法就想改。你需要明确告诉它哪些东西不能动。
3. 飞轮效应：错误只犯一次，越用越可靠
这是整个方法论的核心机制：
BlueCode 犯错（例：删了 arco.css → 全站样式崩溃）
↓
记录到 refactor-log/09-lessons-learned.md（9 条经验教训）
↓
提炼为 AGENTS.md 的 Important Notes 约束
↓
BlueCode 下次启动会话 → 自动读取 → 同类错误不再发生
↑ │
└──────── 约束越多，犯错越少 ──────────────────┘我在 refactor-log/09-lessons-learned.md 里记录了 9 条教训，每条都对应一个 AGENTS.md 约束。
举几个例子：
教训 1：BlueCode 删了 arco.css → 全站组件样式丢失
→ 约束：Do NOT remove @arco-design/web-vue/dist/arco.css
教训 2：BlueCode 移除了 Vite 配置中的 Vue runtime compiler 别名
→ 约束：Do NOT modify vite.config resolve
.alias unless explicitly asked
教训 3：升级 marked v15 后 renderer API 变了，BlueCode 没发现
→ 约束：After upgrading any parsing library, verify runtime behavior
实际数据——约束数量和返工次数的关系：
约束越多，返工越少。这不是线性关系，是指数级改善。到 Phase 9 之后，BlueCode 的产出几乎可以直接合入。
这也是“0 手写代码”能成立的核心前提——不是 BlueCode 一开始就完美，而是通过飞轮效应让它快速变得可靠。
4. 精确的任务拆解：用 AI 听得懂的方式下指令
BlueCode 擅长执行边界清晰的任务，不擅长模糊的大目标。这是“0 手写代码”能否成立的关键——你的指令越精确，BlueCode 的执行就越准确。
反面教材：
我：帮我重构 SessionView
BlueCode：（开始大刀阔斧地改，同时动了 SSE 逻辑、分享逻辑、UI 渲染，
改到一半发现 import 循环引用，回滚，重新来...）正确做法：
我：第一步，把 SessionView 中所有 SSE 相关的变量和函数提取到
src/hooks/useSSEStream.ts，保持行为不变，改完跑 npm run build
我：第二步，把分享和收藏相关逻辑提取到
src/hooks/useShareAndStar.ts，参考 useSSEStream 的写法
我：第三步，build 通过后跑 npx vitest run 确认测试全绿每步都有三个要素：做什么 + 参考什么 + 怎么验证。
更多例子：
❌ "优化性能"
✅ "把 highlight.js 改为按需导入，只注册这 15 种语言：
javascript, typescript, python, java, cpp, go, rust, sql,
bash, json, yaml, xml, css, html, markdown
注意注册别名映射（js→javascript, ts→typescript, py→python）"
❌ "移除 Element Plus"
✅ "先 grep 一下项目里所有 Element Plus 组件的使用点，列出来给我看"
（看完后）
"只有一个 ElPopover，在 PanelMessage.vue 里。改成 Arco 的 a-popover，
用非受控模式 + @popup-visible-change 事件回调"5. 给模式，不给描述：一句话胜过 200 字需求文档
这是效率最高的指令方式：
❌ "写一个 composable，接收 sessionId 参数，返回 isStreaming 状态
和 startStream/stopStream 方法，内部用 SSE 实现……"（200 字需求文档）
✅ "参考 useSSEStream.ts 的写法，提取 mermaid 渲染逻辑"（一句话）BlueCode 会自动模仿参考文件的风格——命名规范（useXxx）、类型定义方式（interface + 泛型）、导入路径（@/ 别名）、错误处理模式（try-catch + Message 提示）。比你写 200 字需求描述准确得多。
这在整个重构中反复验证：提取 4 个子组件时，我只给了第一个的详细指令，后面三个都是"参考 ThinkingPanel 的写法"。BlueCode 自动保持了一致的代码风格。
七、BlueCode 犯的错 — 诚实复盘
AI 辅助不是完美的。既然说“0 手写代码”，那 BlueCode 犯的错也必须交代清楚：
错误 1：删了 arco.css 全量导入
BlueCode 在分析 main.ts 时，看到 import '@arco-design/web-vue/dist/arco.css' 这行，认为"既然已经配了按需导入插件，全量 CSS 是多余的"，直接删了。
结果：Arco 组件全部变成无样式的裸 HTML。按钮没有背景色，弹窗没有边框，下拉菜单飘在奇怪的位置。
根因：项目用的是 unplugin-vue-components 做组件自动注册（JS 部分按需），但 CSS 仍然依赖全量导入。BlueCode 不理解"JS 按需 ≠ CSS 按需"这个隐含关系。
错误 2：升级 marked 后未验证 renderer
marked 从 v11 升级到 v15，Renderer 方法签名从位置参数改成了 token 对象：
// v11：markedRenderer.code = function(code, language) { ... }
// v15：markedRenderer.code = function({ text: code, lang: language }) { ... }TypeScript 编译通过，Vite 构建也没问题。BlueCode 报告“升级完成，build 通过”。但实际上，用户发一条包含代码块的消息，markdown 渲染就崩溃——因为 code 参数收到的是一个 token 对象，调 .replace() 直接 TypeError。
根因：BlueCode 不会主动跑运行时测试。它只验证编译和构建，看不到浏览器里的渲染结果。
关键结论：
每个错误都只发生在 Phase 3-4（早期）。 记录到 AGENTS.md 约束后，后续阶段同类错误完全消失。到 Phase 9 之后，BlueCode 的代码可以直接合入，几乎零返工。
这说明 BlueCode 的“学习能力”非常强——前提是你把教训写成它能读到的约束文件。
八、给想尝试的团队
"0 手写代码"的前提条件
- 项目有清晰的技术栈（Vue/React/...） — BlueCode 有对应的 Skills 支持
- 你熟悉项目架构 — 你得知道该改什么、不该改什么
- 你能验收代码质量 — BlueCode 写的代码你得看得懂、能评判对不对
- 你愿意花时间写 AGENTS.md — 前 30 分钟的投入，省后面 30 个小时的返工
适合 BlueCode 的场景
- 大规模重构 — 批量文件修改、类型迁移、依赖升级后的适配
- 测试编写 — 给源码，BlueCode 能生成覆盖边界条件的测试用例
- 代码拆分 — 从 God Component 提取 composable / 子组件 JS → TS 迁移 — 理解参数实际类型，补全类型定义
- UI 快速迭代 — 样式调整、动画效果、交互细节的试错
- 文档生成 — 重构日志、分享材料、API 文档、blog
不适合的场景
- 你不熟悉的项目 — 看不懂 BlueCode 的代码就无法验收，“0 手写”变成“0 质量”
- 需要大量运行时调试 — BlueCode 看不到浏览器，CSS 渲染效果需要你自己确认
- 涉及隐含业务规则 — “这个接口在灰度环境下返回格式不同”这类知识，BlueCode 无从得知。
快速上手清单
□ Step 1: 确保 find-skills 可用
→ find-skills 会在 AI 执行任务时自动触发，搜索并安装所需技能
→ 你不需要手动安装，AI 会自己判断缺什么能力
□ Step 2: 写 AGENTS.md
→ Build Commands（怎么构建/测试）
→ Tech Stack（版本号）
→ Code Style（命名/缩进/导入规范）
→ Important Notes（⚠️ 不要做什么）
□ Step 3: 建立飞轮
→ 维护一份 lessons-learned 文件，BlueCode 每犯一个错，立即写入
→ 沉淀共性问题写入AGENTS.md 约束
□ Step 4: 拆解任务下指令
→ 每个指令包含：做什么 + 参考什么 + 怎么验证
→ 不要一次给 10 个文件的任务
□ Step 5: 给模式，不给描述
→ "参考 useSSEStream.ts 的写法" > 200 字需求文档核心公式
BlueCode 产出质量 = Skills × AGENTS.md 约束 × 任务拆解精度
你的角色不是写代码，是：
诊断 → 决策 → 指令 → 验收 → 纠偏工程师的价值不在于手写代码的速度，而在于做正确的决策和把控产出质量。BlueCode 让“手写代码”这个环节可以被跳过，但“决策”和“验收”永远是人的工作。
九、数据总结
十、最后
4 年积累的技术债，2 天还清。0 行手写代码。
这不是因为 BlueCode 是万能的——它同样犯过删 CSS、忘验证 renderer 的错误。真正起作用的是飞轮效应：每个错误只犯一次，约束越积越多，到后期几乎零返工。
更重要的是，这套方法论并不绑定 BlueCode。无论是 Claude Code、Cursor、Copilot 还是其他 AI Coding Agent，底层逻辑是相通的——AI 的能力上限由模型决定，但 AI 的产出质量由人建立的约束体系决定。Skills 沉淀领域知识、AGENTS.md 固化项目规范、飞轮机制让错误只犯一次，这三件事换到任何一个 AI 编程工具上都同样成立，做好这三件事，“0 手写代码”就是自然的结果。
工具会迭代、模型会更替，但“为 AI 建立约束”这件事，是每个开发者在 AI 时代都需要长期投资的核心能力。
浙公网安备 33010602011771号