这两天，我用 Claude Design 和 Codex 重构了一套 CRM。
不是 demo，也不是做一个看起来很炫的前端页面，而是在一个真实业务系统里迁移功能。
老系统还在跑，生产接口要接，登录态要处理，权限要对齐，菜单要复刻，字段不能少，按钮逻辑不能乱，最后还要能在真实联调域名下跑起来。
做完以后，我最直观的感受是：
AI 带来的生产力提升，不是“代码写得更快”这么简单，而是整个开发反馈链路被压缩了。
以前一个人做这种迁移，通常是来回切：看老系统，查接口，写页面，跑本地，发现跨域，切域名，调接口，改样式，点浏览器，再发现权限逻辑不对，继续回头改。
这套循环很长，而且很容易被细节打断。
这次有 Codex 参与后，很多环节变成了连续推进。它可以读代码、改代码、跑命令、打开页面、看控制台、查接口请求，再根据截图继续修。人主要负责判断方向和验收标准。
这就是我感受到的最大变化。
不是少写了几行代码，而是少了很多来回切换、重复定位和低效试错。
一开始，我以为重点是页面
最开始的目标很直接：迁移几个核心页面。
要求也很明确：数据接真实接口，展示内容不能少，UI 换成新的风格，老系统已有逻辑不能丢，改完必须自己测试。
听起来像是一个前端开发任务。
但真正做起来，很快发现第一关不是页面，而是环境。
本地访问会有跨域问题，必须用业务联调域名启动；域名切换后，又遇到白屏、证书、端口占用、Cookie 不生效。最后环境稳定下来，才真正进入联调状态。
这一步让我意识到：真实业务系统里，页面不是第一关，环境才是第一关。
如果环境不通，AI 写再多代码也只是自嗨。
但这里 Codex 的价值已经开始体现出来了。它不是只生成代码，而是能一直跟着问题往下走：查启动方式、看页面状态、确认控制台错误、检查接口请求。
这些事情以前很消耗人的注意力，现在可以交给它持续推进。
Claude Design 定方向，Codex 做落地
这次 UI 不是让 Codex 凭感觉设计。
我先用 Claude Design 把几个核心页面的视觉方向定下来，包括首页、客户详情、当前班级这些页面。Claude Design 负责探索页面气质、布局结构、组件形态和交互方向。
Codex 的角色不一样。
它负责进入真实代码库，把设计稿拆成 React 页面和组件，接上真实接口，处理状态、权限、路由、菜单、表格、弹层、解密、编辑保存这些工程细节。
Claude Design 更适合做视觉和 UX。Codex 更适合做工程实现和联调。
我负责拿老系统、设计稿、真实数据不断验收。
比如当前班级页，设计稿里已经有整体结构、榜单、筛选区、班级信息区这些视觉方向。
但真正落到项目里，还要处理老师选择、班期刷新、业务线参数、分页、导出、权限、按钮逻辑和生产接口。
所以最后不是“AI 直接生成页面”。
更准确地说，是 Claude Design 先把页面应该长什么样跑出来，Codex 再把设计稿变成真实可用的业务页面，人负责持续判断哪里和老系统不一致。
这个流程比单纯让一个工具从零生成页面稳定很多。
配图为虚构示意：设计探索和工程落地分开做，效率会高很多。
生产力提升，来自反馈链路变短
这次最明显的生产力提升，不是 Codex 一次写出多少代码，而是它能把一个改动闭环跑完。
以前做一个功能，流程大概是：我看老系统，我找代码，我改代码，我跑构建，我开浏览器，我看控制台，我发现问题，我再回去改。
现在很多时候变成：我指出问题，Codex 找代码，Codex 修改，Codex 跑类型检查，Codex 构建，Codex 打开真实页面，Codex 看接口和控制台，Codex 把结果反馈回来。
人从大量机械执行里抽出来，更多在做判断。
这个字段是不是老系统也有？
这个按钮是不是该显示？
这个交互是不是和业务习惯一致？
这个接口参数是不是跟业务线有关？
这个页面到底算不算验收通过？
这是生产力提升最实际的地方。
不是“AI 替我写了代码”，而是它把很多原本分散的动作串成了一条连续流水线。
开发反馈从手工来回切，变成了人机协作闭环。
老系统虽然丑，但它是事实来源
重构 CRM 最容易犯的错，是把“重构”当成“重写”。
老系统可能不好看，交互也不现代，但它跑了很多年，里面藏着大量真实业务习惯。
比如订单详情、积分详情都不是简单表格。每个模块背后都有自己的接口和状态逻辑。
我后来定了一个原则：
内容和逻辑严格按老系统，UI 再按新设计稿优化。
老系统是事实来源。
Claude Design 是视觉目标。
Codex 负责工程落地。
人负责判断有没有迁对。
这个顺序不能反。如果先追求“新设计”，很容易把老系统里那些不起眼但很重要的逻辑丢掉。
截图反馈，比长篇描述好用得多
这两天修了很多细节。
有些是布局问题：模块被遮挡、右侧区域错位、按钮换行、表格横向滚动难看。
有些是交互问题：下拉选择失效、选完条件没有刷新、标签页重复打开。
有些是业务问题：接口参数不对、筛选项多了、积分详情没显示、手机号解密逻辑不完整。
这些问题如果只用文字说，很容易变成一句“这里再优化一下”。
但截图一框出来，范围就很明确。
比如CRM顶部区域，一开始有阶段提示的文字，视觉上很割裂。我直接截图反馈：不需要显示阶段提示，样式也没对齐。Codex 就回到对应组件，重新整理成统一的信息区。
这类反馈方式很高效。
一句模糊的“优化一下”，不如一张截图加一句明确要求。
真实系统里，不能只看代码
这次我一直要求 Codex 自己测试。
不是写完代码就说完成，而是每一轮重要修改后都跑类型检查、构建、真实页面、控制台、接口请求、按钮点击、指定测试数据。
这点很关键。
因为 CRM 这种系统，很多问题代码里看不出来。
页面看起来加载了，其实接口未授权。
分页组件看起来在，但真实数据一多就错位。
表单看起来能保存，但服务端校验不通过。
这些问题只有打开浏览器、连真实接口、点一遍才知道。
所以我觉得，AI 写代码必须配套 AI 自测。
只让它写，不让它测，最后成本还是会回到人身上。
抓包是最可靠的文档
有些逻辑，光看代码和页面不够。
比如某个条件选择后没有生效，我直接拿老系统抓包给 Codex，同时补充一句：业务线参数是根据产品线选择来的。
这比描述“选择条件后没刷新”有效得多。
因为它立刻能知道老系统真实接口长什么样，参数怎么传，哪些字段不能写死。后面它修完后，也会在浏览器里确认请求确实带了正确参数。
对这种老系统迁移来说，抓包就是最可靠的文档。
尤其是当项目没人能完整说清楚历史逻辑时，生产请求往往比文档更可信。
项目规约要尽早沉淀
中途我让 Codex 把项目规约整理成文档。
包括业务代码放哪里、公共组件怎么拆、接口必须走统一请求层、服务端状态怎么管理、新增代码什么时候需要中文注释、路由和菜单怎么对应、不能用假数据、不能随便新增抽象。
这个动作很有用。
因为 AI 长时间参与项目时，最怕的是风格漂移。今天这么写，明天换一种写法，后天又抽一个没必要的公共组件。
有了规约之后，Codex 后续改代码会稳定很多。它知道这个项目的边界，也知道哪些事情不能乱来。
说白了，就是不要让 AI 每次都像新来的临时工。
要让它逐渐像这个项目里的工程师。
AI 能提速，但方向盘还在人手里
这次做下来，我对 AI 编程的判断更现实了一些。
Claude Design 很适合做设计探索。
Codex 很适合做工程落地。
两者配合起来，确实能明显提高迁移速度。
但它们都不是自动懂业务。
你不告诉它老系统的逻辑，它就可能按“看起来合理”的方式实现。
你不告诉它字段不能少，它就可能简化展示。
你不要求它跑真实接口，它就可能停在假数据可用。
你不让它自己测试，它就可能把问题留给你点页面时发现。
所以 AI 编程真正的分工应该是：人负责目标、边界、业务判断和验收标准；AI 负责设计探索、代码实现、联调测试和重复修改。
人不是被替代，而是从“每一行代码都自己写”，变成“持续判断什么是正确的”。
这个变化挺明显。
生产力提升的本质，是人从执行细节里抽出来，把更多精力放到判断和验收上。
如果再做一次，我会这样开始
如果下次再用 AI 重构一个真实业务系统，我会一开始就准备这些东西：
一个能跑的真实联调环境；
一套可对照的老系统；
几个稳定的测试账号或测试数据；
核心页面的 Claude Design 设计稿；
关键接口抓包；
项目目录和代码规约；
每一轮都能执行的验收方式。
这些东西准备得越清楚，AI 越能发挥作用。
如果只给一句“帮我重构 CRM”，它大概率会写出一套看起来不错、但业务上不能用的页面。
真实系统迁移不是生成页面。
真实系统迁移是把一堆历史逻辑重新安稳地搬过去。
最后
这两天最大的收获是：AI 已经很会写代码了，但真实项目里，写代码只是其中一部分。
环境、接口、权限、数据、老逻辑、设计稿、测试标准，这些东西才决定最后能不能交付。
Claude Design 让我更快确定页面应该长什么样。
Codex 让我更快把页面落到真实代码和真实接口上。
但整个过程中，最关键的仍然是人的判断。
哪里必须和老系统一致。
哪里可以按新设计优化。
哪个字段不能少。
哪个按钮不该有。
哪个接口参数才是对的。
什么状态下才算测试通过。
AI 能帮你把事情做快。
但你要先告诉它，什么叫做对。
这次重构给我的真实感受是：过去一个人要在设计、代码、接口、测试之间反复切换。现在有了 Claude Design 和 Codex，很多环节可以并行推进。人的角色从“埋头搬砖”，变成“设定标准、校准方向、验收结果”。
这才是生产力真正被放大的地方。
本文来自转载程序员柯然 ，不代表发现AI立场，如若转载，请联系原作者；如有侵权，请联系编辑删除。
微信扫一扫 
