从GitHub Copilot到Cursor，再到现在的Codex、Claude Code，现在大家聊的AI编程，早就不止是补全几行代码了，它正在参与软件开发的完整过程。
但我们团队实际跑了一阵子，发现一个问题：代码是写得快了，可项目的整体进度条，好像没怎么动。AI擅长告诉你怎么做，但你得先整明白：“到底要干啥”。
项目延期，十有八九不是代码敲得慢。你这边产品说“这排版不是我要的感觉”，那边设计说“交互有点别扭”，开发一看，字段和接口文档又对不上。到最后，AI写代码越快，我们推翻重来的手速也得跟上。
所以现在所以现在不少团队都换了个路子：让AI先进到产品前期，把需求、布局、交互这些事儿都敲定了，再甩给代码工具。下面说说我们目前在跑的一个流程，核心就两步：先用墨刀AI把产品长什么样定下来，再让Cursor/Codex把代码写出来。
一、为什么 AI 编程之前，先解决产品设计问题？
很多开发者用 Cursor 时，第一反应多半都是：太方便了。比如你跟它说“来个后台首页，要有数据卡片、趋势图、订单列表”，几秒钟它就能给你整一套出来。但是仔细看会发现，页面结构可能没错，但它不知道你的产品定位是什么，也不知道产品经理脑子里的真实想法。
同样是后台首页：
- A 产品希望突出销售数据，所以首页重点是 GMV、订单转化率、销售趋势。
- B 产品希望服务运营人员，所以重点可能是用户增长、活动效果、异常提醒。
没个明确的设计方案，AI就只会按着它见过的“标准”给你拼一个看上去还可以的页面。这也是现在好多人吐槽AI编程的地方——交付是快，但剩下的时间全在改。
所以我现在的习惯是，先别急着写代码，把需求变成看得见的东西。不是说搞那种像素级的设计稿，而是快速把几个核心问题定下来：页面分几块？信息谁大谁小？用户进来先点哪儿？哪些组件以后还能复用？以前这活儿得产品画线框、设计出视觉稿、开发再确认，来回折腾。现在用产品类的AI工具，你只管把想法说出来，它就能帮你把页面架子搭起来。
二、墨刀 AI 生成原型，再交给 Cursor/Codex 开发
就拿最常见的企业内部数据后台来说。
第一步：用 AI 明确页面结构
这时候先忍一手，别打开IDE。咱们先把需求掰开了揉碎了说清楚。把目标用户、核心诉求一股脑儿喂给墨刀AI。AI生成页面后，重点检查三个地方：
- 信息层级：最重要的数据得摆在C位，用户一打开就得看到。
- 组件设计：像数据卡片、表格、筛选器这些，想好哪些以后要复用，省的后面返工。
- 交互逻辑：比如点了卡片跳到哪，筛选条件支不支持组合查询。
第二步：从设计转换成开发信息
好多人用AI画完原型就完事了。但其实更核心的，是把这些设计转化成开发能直接用的信息。切换到代码模式，就能看到详细的前端代码结构了。这里我们选择的是生成Vue代码，也可以选React。这些信息对后面写代码太重要了。Cursor它不是不能干活，是怕你让它猜。你给的代码信息越细，它生成的代码就越像那么回事儿。
第三步：把活儿交给Cursor/Codex
等页面结构定稿了，再切到Cursor。这时候你可以直接扔给它：“就按这个原型来，搞个Vue3+TS的项目，组件拆细点，数据全用假接口留着以后接真数据。”这么干，AI给你的代码质量绝对上两个台阶。
这时候AI不用猜了，组件有几个、布局长啥样、哪里要动态数据，全给它交代清楚了。后续调整也简单，直接跟它说“订单列表改分页”、“筛选加个时间范围”、“给我接上/api/dashboard这个接口”，Cursor处理这些驾轻就熟。
三、AI 开发时代，重新设计工作流程
很多人刚接触 AI 工具，会关注“哪个 AI 写代码最准？”但真到了项目里，工具好坏只是小事，关键看你的工作流有没有跟着变。
你看现在这流程：AI参与了需求、原型、代码三个阶段，最后人来做优化和交付。但这不意味着产品、设计、开发就要下岗了，反而人的活儿更重了。产品经理得把业务目标想得更透，设计师得把关体验，开发得控住代码质量和技术债。AI就像个超级帮手，帮我们把那些重复、繁琐的活儿干了。
这套玩法对独立开发者来说很顺。
以前搞个MVP，得凑齐产品、设计、前端，跟攒局似的。现在一个人就行，先用AI把想法跑通，再让AI把代码撸出来，自己测一测，慢慢迭代。不过，目前AI也不是万能的。碰到复杂的业务逻辑、刁钻的交互、或者性能瓶颈，还是得开发者亲自下场。
注：文中部分配图由AI生成。