我现在怎么用 AI 编程：从 Copilot、Cursor 到 Codex 与 Qoder

我开始使用 AI 编程工具，并不是因为想追热点，而是因为自己本来就是前端工程师，工作里天然会遇到大量重复开发、样式调整、代码审查和联调问题。只要工具真的能提高效率，我就会一直试。

最早我用的是公司提供的 Copilot，类似 GitHub Copilot 这样的代码助手。后来逐渐过渡到 Cursor，再到现在同时使用通义灵码、Claude、Codex、Qoder 等 AI 编程产品。

回头看，这条路径不是简单换了几个工具，而是我的工作方式发生了变化：

Copilot 助手模式
→ Cursor Plan 模式
→ Skills / Rules / Qoder / Codex / MCP 组成的工作流模式

我还不能说自己已经有一套完全成熟的方法论。更准确地说，我是在把这些零散经验慢慢整理成一套“目标驱动的 AI 编程工作流”。

这套工作流的重点不是让 AI 多写几行代码，而是让 AI 进入需求理解、方案规划、代码执行、自动测试、代码审查和浏览器验收这条完整链路。

在这个过程中，我越来越确定一件事：

人和 AI 的边界，并不只取决于问题本身有多难，而更取决于反馈回路是否足够高效。

一个问题即使很复杂，只要结果能够快速呈现、测试和纠正，AI 就能参与很多。反过来，一个问题即使听起来不难，但没有清晰标准、无法构造场景、几天后才能知道结果，AI 就很难独立完成。

从代码助手，到工程协作者

早期的 Copilot 更像一个助手。它主要帮我补全代码、重构代码片段，减少重复输入。

这个阶段的开发流程没有发生根本变化：我负责理解需求、拆任务和写代码，AI 在旁边补几行、改一小段。

到了 Cursor 之后，体感最大的变化是 AI 从“助手模式”进入了“Plan 模式”。它不只是补全代码，而是可以先澄清需求，再生成开发计划，最后根据计划修改代码。

以前更像是：

我写代码，AI 补代码

现在更像是：

我描述目标，AI 调查工程、生成计划并执行任务

这也让 Vibe Coding 逐渐从开发者工具变成一种泛技能。很多非前端工程师已经可以通过描述目标生成页面、修改样式和实现基础交互。

这不代表前端工程师不重要了，而是前端工程师的价值必须往上迁移。单纯“画页面”的价值会被压缩，新的价值会转向：

目标定义
上下文工程
产品与设计判断
组件复用判断
工程约束设计
AI 工具编排
质量验收
系统交付

前端工程师不能只做代码执行者，而要成为 AI 编程流程的组织者和质量负责人。

我怎么和 AI 协作

我现在更愿意把 AI 当成一位有经验的前端同学，而不是一个只会接受指令的辅助工具。

1. 先说清楚目标，不要急着规定实现

我不会一上来就告诉 AI 具体代码应该怎么写，而是先把想要的效果讲清楚，而且要具体到页面状态、交互结果和验收标准。

然后我会让它先调查现有工程，再回答：为了达到这个效果，哪种方案更合适？需要修改哪些模块？有哪些潜在影响？

这并不是把技术判断全部交给 AI。AI 负责调查和提出方案，人负责确认方向和取舍。方案确认以后，再让 AI 落实到工程里。

2. 视觉任务尽量提供参考图

纯靠文字反复描述“再大一点”“再靠左一点”，效率通常很低。

我会直接提供 Figma 设计稿、参考产品截图或者当前页面截图，让 AI 对照真实画面实现。截图不是装饰，而是视觉上下文。很多间距、层级、比例和状态关系，一张图比几百字更准确。

AI 修改完成以后，我也会把新截图反馈给它，让它继续对比和调整。这本身就是一个视觉反馈回路。

3. 一次只解决一个问题

我会尽量让一次 AI 任务只解决一个问题，就像一个 PR 只处理一个问题。

如果一次抛出五六个问题，AI 很容易在修改 A 时顺手影响 B。最后既难验收，也很难判断回归是从哪里引入的。

任务越聚焦，修改范围越清晰，反馈就越容易归因。一次只修一个问题，不只是为了方便管理，也是在提高 AI 协作的稳定性。

如何把 AI 协作变成一套工程系统

只靠临时 Prompt，很难让 AI 稳定理解项目。它很容易遗漏业务背景、组件规范、接口约定和团队约束。

真正有效的方式，是把上下文、任务能力和验收方式逐步固化下来。

1. 用 Rules 和知识库稳定上下文

工程里会配置类似 Cursor Rules 的规则，并关联 Wiki 知识库，让 Cursor、Qoder、Codex 这类 Agent 工具理解业务背景和项目规范。

这些信息包括：

代码风格
组件使用规则
业务约束
接口约定
目录结构
高内聚、低耦合
最小改动原则

只要上下文准备得足够完整，AI 在业务逻辑、状态管理、接口字段和代码风格上的表现其实并不差。

2. 用 Skills 固化重复任务

我会逐步安装和集成包括 superpowers、Gstack 在内的 Skills，用来完善工作流。

Skills 的价值不是让 Prompt 变得更长，而是把一类任务沉淀成可复用能力。例如：

生成开发计划
分析 UI 还原要求
做 Code Review
生成测试用例
检查 PRD 完整性
辅助浏览器测试

每次遇到同类任务，不需要重新解释完整流程，AI 可以直接按已经确定的方法执行。

3. 用代码和配置表达可调整资产

我会尽量把需要反复变化的内容变成代码或结构化数据。页面 UI 的像素参数、BGM 配置、PixelRun 的数值、动画速度和关卡参数，都应该尽可能进入代码和配置。

代码能够被精确调整、复现、比较和回滚。只要一个资产可以被参数化，AI 就能参与修改，版本之间的差异也能被检查。

那些只能依赖手工拖动、又没有记录的调整，很难真正进入 AI 协作流程。

4. 用 Browser、Mock 和调试面板建立反馈回路

如果接口已经就绪，可以直接让 AI 打开页面进行测试。如果接口还没 Ready，我会通过 Chrome 插件或 MCP 生成 Mock 数据，再利用 Browser Use 这样的工具测试不同场景。

有些状态如果每次都依赖真实操作才能进入，反馈仍然很慢。因此我也会为项目准备开发调试面板，用它随时切换角色、数据、关卡、概率结果或异常状态。

实际迭代会形成一个很短的循环：

AI 修改代码
→ 刷新页面
→ 调试面板构造场景
→ Browser / 人工验收
→ 截图并反馈给 AI
→ 继续迭代

调试面板看起来只是一个开发工具，实际上是在提高反馈带宽。它避免为了复现一个边界场景反复走完整流程，也让人和 AI 都能更快看到结果。

一个完整任务如何进入这套工作流

在真实工作中，一个典型的 AI 编程任务不是从一句 Prompt 开始的，而是从上下文准备开始。

我的工程通常已经完成基础工程化处理，配置了项目 Rules，并关联 Wiki 知识库。当一个较大的需求过来时，我会把 PRD 的 Markdown 文档、Figma 设计稿截图和相关业务约束一起提供给 AI。

接下来不是立刻写代码，而是先生成两个中间产物：

UI 还原描述文件
整体开发计划 Plan

Plan 需要说明：

需要修改哪些模块
复用哪些已有组件
涉及哪些状态和接口
修改范围和潜在影响
需要覆盖哪些边界场景

在 AI 开始写代码之前，我会先 Review Plan。因为如果 Plan 错了，后面代码写得再快也是错的。我会通过对话继续修正它，直到方案接近真实需求。

Plan 确认以后，AI 才会结合 Repo、业务背景和项目规则进行开发。

开发完成后，再进入验收环节：

AI Code Review
→ 修复工程基础问题
→ 对照 PRD 检查完整性
→ 生成测试用例
→ Mock / 调试面板构造场景
→ Browser Use 验收
→ 人工判断与微调
→ 复盘并沉淀 Rules / Wiki / Skills

所以，这套流程不是 Prompt 驱动，而是：

Context + Plan + Review + Feedback Loop

AI 编程真正卡在哪里

目前来看，AI 编程最容易自动化的是代码生成，最难自动化的是生产级验收。

1. UI 还原缺少完全客观的标准

AI 可以很快生成一个页面，但要做到生产级设计稿还原仍然不稳定。

一个页面看起来只是视觉问题，背后实际包含素材、设计系统、业务组件、响应式状态、接口状态、权限逻辑和工程规范。

截图可以提高视觉反馈效率，却不能替代审美判断。AI 能够分析差异，但很难独立判断一个动画是否符合语义、一个间距是否符合产品气质。

2. 真实测试环境很难完整复现

很多业务不是打开页面就能测试。有些需求涉及灰度发布，需要灰度字段、账号、环境、Mock 数据、代理和登录态全部对齐，才能真正复现某个场景。

现在的浏览器测试也主要通过无障碍树、DOM 或截图识别页面状态。这个能力已经有用，但元素识别和视觉判断还不够稳定。

很多时候不是 AI 不会测试，而是环境没有办法给它提供稳定、完整的反馈。

3. 修改范围越大，结果越难归因

如果一次任务同时修改多个模块，即使最后出现问题，也很难快速判断是哪一步引入的。

这也是为什么我强调最小改动和一次只解决一个问题。AI 编程质量不只依赖模型和上下文，也依赖反馈能否被准确归因。

所以我现在的判断是：

AI 编程的瓶颈，正在从“代码生成”转向“上下文准备”和“生产级验收”。

谁能把上下文和反馈链路做好，谁才能真正把 AI 编程用到生产环境里。

哪些决定不能交给 AI

AI 可以参与很多工作，但有些事情不能因为它能给出答案，就把最终决定也交给它。

1. 产品和设计决策

产品最终长什么样、每一个设计点为什么存在，应该由人决定。包括经济体系、概率机制、信息层级、交互节奏，以及那些需要反复体验才能判断的细节。

AI 可以生成备选方案，但它不知道这个产品最终追求什么。如果直接让 AI “帮我设计一个”，它通常只能给出一个看起来合理、但缺少明确取舍的泛化方案。

2. 架构判断

AI 可以分析当前代码并提出重构建议，但哪里应该解耦、哪里应该内聚、哪里必须增加限制，往往取决于系统未来会怎么变化。

真正的架构决策需要结合业务演进、团队协作、历史包袱和维护成本。AI 看到的经常只是局部网络，所以可以让它提方案，但不能让它独自拍板。

3. 美术与审美拍板

AI 可以生成方案、对照截图和分析差异，但“这里好不好看”“动画是否符合语义”“哪种风格才属于这个产品”，最后仍然需要人决定。

审美不是把几个参数计算到最优，而是在大量可行方案里做有方向的选择。

4. 真实环境的最终交付

本地跑通不等于完成交付。代码部署到具体平台后，还可能遇到构建环境、权限、网络、账号、缓存、灰度和平台限制。

AI 可以帮助定位问题，但人仍然要补足真实环境上下文，解决平台问题，并对最终上线结果负责。

所以在这套工作流里，AI 更适合负责调查、生成、执行和验证，人主要负责：

定义产品目标
做产品与设计决策
判断架构边界
准备关键上下文
评审 Plan 与方案
设计验收标准
处理真实环境问题
判断结果能否上线
把经验沉淀回 Rules / Wiki / Skills

AI 可以提出方案，但不能替人完成取舍；可以参与执行，但不能替人承担最终结果。

我的目标驱动 AI 编程工作流 v0.2

把目前的流程压缩到一起，大概是这样：

人定义目标与验收标准
→ Rules / Wiki / Repo 提供上下文
→ PRD / Figma / 截图提供任务输入
→ AI 调查工程并生成 Plan
→ 人工 Review Plan 和关键决策
→ AI 自动开发与 Code Review
→ Mock / 调试面板构造场景
→ Browser / 截图形成反馈
→ AI 继续修正
→ 人工验收与上线
→ 经验沉淀回 Rules / Wiki / Skills

我不是直接让 AI 写代码，而是把它放进一个目标明确、上下文稳定、修改范围受控、结果能够快速验证的工程流程里。

结论：AI 编程不是 Prompt 魔法，而是反馈系统

我现在对 AI 编程的理解是：

AI 编程不是 Prompt 魔法，而是由上下文、计划、执行和反馈闭环组成的工程系统。

Copilot 阶段，AI 帮我补代码。Cursor 阶段，AI 开始帮我执行需求。到了 Skills、Rules、Qoder、Codex 和 MCP 阶段，我开始把整套协作流程工程化。

这套工作流还没有完全成熟，尤其是生产级验收仍然存在明显问题。但它已经改变了我的开发方式：我不再把自己定位成单纯写代码的人，而是逐渐转向目标定义者、上下文组织者、工具编排者和质量判断者。

未来真正重要的能力，不是能不能手写一个页面，而是能不能把复杂需求转化为清晰目标，把业务上下文转化为 AI 可执行的输入，再把生成结果放进一个可验证、可交付、可持续迭代的反馈系统。

FAQ

AI 编程会替代前端工程师吗？

AI 会替代一部分重复性编码工作，也会降低页面生成的门槛。但它不会直接替代真正能理解产品、系统、业务上下文和用户体验的前端工程师。前端工程师的价值会从“写页面”转向“定义目标、组织上下文、审查结果和推动交付”。

Cursor、Codex、Qoder 这类工具应该怎么分工？

Cursor 更适合日常开发、局部修改、Plan 模式和上下文内协作。Codex 更适合处理自动化任务、批量修改、测试和仓库级执行。Qoder 的 Expert / Spec 模式适合 Bug 修复、代码审查和较大需求的规范化处理。具体选择取决于任务复杂度和上下文要求。

AI 编程最重要的不是模型，而是什么？

最重要的是反馈系统。稳定的上下文让 AI 理解项目，明确的目标和修改范围让它正确执行，Browser、Mock、截图和调试面板让结果能够被快速验证。这些部分共同决定 AI 输出是否稳定。

为什么 AI 写代码很快，但上线仍然不容易？

因为真实业务不仅是代码问题，还涉及测试环境、账号权限、灰度字段、接口状态、Mock 数据、代理、登录态、平台限制和视觉还原。代码生成只是第一步，生产级验收才是真正决定能否上线的关键。

哪些决定不能交给 AI？

产品方向、设计取舍、架构边界、审美拍板和最终上线判断不能完全交给 AI。AI 可以参与分析、提供方案和执行任务，但人仍然要做最终决定，并对结果负责。