1. 为什么 CRM 这类项目不能一上来就让 Codex 写代码做 CRM 客户管理系统最容易踩的坑就是需求还没想清楚直接让 Codex 生成页面。我试过把一个模糊的做个客户管理后台丢给模型结果它给我生成了一个字段堆砌的表格页客户和联系人混在一起销售漏斗用静态数字硬编码权限逻辑完全没有。页面看着能跑但业务方一看就说这不是我要的。问题出在哪CRM 的核心不是页面好不好看而是业务关系能不能对上。客户和联系人是一对多还是多对多销售机会分几个阶段、每个阶段对应什么操作不同角色销售、主管、管理员能看到哪些数据、能做哪些操作这些没定下来模型只能自己脑补生成的代码越往后改越乱。更稳的做法是分两步走先用墨刀 MCP 把产品结构和交互原型定下来再让 Codex 拿着明确的页面、流程和字段去写工程代码。墨刀本身带了不少现成的设计场景和组件接上 MCP 后这些能力直接在 Codex 对话里就能调不用在几个工具之间来回倒腾提示词。前期规划和视觉探索本来就要跑好几轮如果全让代码模型做花费不小还容易跑偏先用墨刀 AI 把 PRD 和 React 原型弄出来方向定了再开发总体上更省。这篇文章就拿一个中小型销售团队的 CRM 后台当例子把想法→原型→可运行 React 代码的完整链路走一遍。适合需要快速验证产品概念的前端和产品同学跟着做能跑通 CRM 核心页面的代码生成与本地运行。2. 前置准备TaoToken 接入与墨刀 MCP 配置2.1 为什么需要 TaoTokenCodex 本身是代码模型但在这套流程里它要调用墨刀 MCP 来生成 PRD 和原型同时还要处理工程代码的生成和修改。如果你用的是按量计费的 API 通道建议先把 TaoToken 的接入配好这样 Codex 在调用模型时走统一的 API 入口不用在多个平台之间切换密钥。TaoToken 的 API 地址是https://taotoken.net/api官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先去控制台创建一个 API Key然后在 Codex 的配置里把 base_url 指向 TaoToken 的 API 地址。2.2 在 Codex 中接入墨刀 MCP墨刀 MCP 能生成交互原型、React 应用和 PRD 文档结果是保存到你的墨刀个人空间同时返回任务信息、预览链接和具体内容。官方推荐使用 OAuth 授权。在 Codex 的 MCP 配置里添加一个服务参数如下{ mcpServers: { modao: { type: streamable-http, url: https://modao.cc/agent-py/ai/mcp, auth: oauth } } }如果你用的是config.toml格式的客户端对应的片段是[mcp_servers.modao] type streamable-http url https://modao.cc/agent-py/ai/mcp auth oauth完成配置后根据 Codex 的提示跳转到墨刀登录并授权再回来确认连接状态即可。OAuth 的好处是不用复制个人令牌用起来省事还能避免令牌误传到聊天记录或代码仓库。如果当前客户端暂时不支持 OAuth也可以在墨刀或墨刀 AI 页面点击右上角头像进入令牌设置创建个人空间令牌。手动配置时使用相同的服务器地址并增加请求 Header{ mcpServers: { modao: { type: streamable-http, url: https://modao.cc/agent-py/ai/mcp, headers: { modao-token: 你的个人空间墨刀令牌 } } } }注意千万别把真实令牌发到公开对话、截图、日志或 Git 仓库里。可以先让 Codex 用个人空间墨刀令牌当占位符写好配置然后自己在本地换上真的。保存后刷新一下 MCP 服务没生效就重启客户端。通过 MCP 生成内容和墨刀 AI 网页端用的是同一套个人空间权益。如果生成失败就去检查账号登录状态、积分或权益、MCP 连接状态和服务器地址。3. 可复制配置Codex 提示词模板与项目骨架3.1 第一步生成结构化 PRD连上墨刀 MCP 之后调用前你给的需求细节越多出来的东西就越能用。我用的提示词类似这样请用墨刀 AI 为中小型销售团队设计一个 CRM 客户管理后台。 核心页面包括 1. 数据概览 2. 客户列表与筛选 3. 客户详情和跟进记录 4. 销售机会漏斗 5. 成员与权限设置 先生成结构化 PRD说明用户角色、页面结构、核心字段和主要业务流程。 确认后再生成桌面端 React 交互原型重点完善列表筛选、详情抽屉、 新增跟进记录和销售阶段切换。先出 PRD主要是把页面背后的业务关系定下来。比如客户和联系人怎么关联、销售机会分几个阶段、不同角色能看哪些数据这些都会直接决定后面的组件设计和数据结构。3.2 第二步生成 React 交互原型PRD 确认没问题再让墨刀生成 React 应用。如果只是快速确认页面结构和活动页出 HTML 原型就够了如果产品有筛选、弹窗、状态切换这类交互React 原型后续查看、复制和二次开发都更方便。拿到预览链接后先把原型当正式产品用一遍。比如找客户快不快加跟进顺不顺手空状态全不全危险操作有没有确认弹窗。这时候改页面比代码写完再回头改划算多了。3.3 第三步让 Codex 接手工程实现原型确认后就可以让 Codex 接手工程实现。最好把技术约束、验收条件和实施顺序一起给出来。例如请基于刚才生成的 CRM React 原型在当前项目中实现可运行版本。 技术要求 - 复用项目现有 React、TypeScript 和组件库 - 保留原型的信息架构与主要交互 - 将模拟数据收敛到独立的数据访问层 - 补齐加载、空数据、请求失败和表单校验状态 - 先分析现有代码结构再分阶段实施 - 完成后运行类型检查、测试和构建接下来让 Codex 先拆页面和组件再建类型、接口层和状态管理最后接上真实后端。涉及到核心操作还得补权限校验、错误处理、日志、响应式适配和自动化测试。原型里的静态数字要换成接口数据别觉得页面能点就算完事了。3.4 项目目录骨架参考Codex 生成代码时建议让它按下面的结构组织方便后续联调src/ api/ client.ts # 统一请求封装 customers.ts # 客户相关接口 opportunities.ts # 销售机会接口 components/ CustomerTable.tsx CustomerDrawer.tsx FollowUpForm.tsx OpportunityFunnel.tsx pages/ Dashboard.tsx CustomerList.tsx CustomerDetail.tsx Settings.tsx types/ customer.ts opportunity.ts hooks/ useCustomers.ts useOpportunities.ts4. 验证请求本地启动与接口联调4.1 本地启动代码生成完成后先在本地跑起来。以 Vite React TypeScript 为例npm install npm run dev启动后打开浏览器重点检查几个核心页面页面验证点预期结果数据概览统计卡片是否渲染显示客户总数、本月新增、成交金额客户列表筛选和分页按状态/负责人筛选后列表更新客户详情抽屉打开显示基本信息和跟进记录时间线销售漏斗阶段切换点击阶段后显示对应商机列表权限设置角色切换不同角色看到不同菜单项4.2 接口联调如果后端接口还没准备好可以先让 Codex 生成一个 mock 层。在src/api/client.ts里加一个开关const USE_MOCK import.meta.env.VITE_USE_MOCK true; export async function requestT(url: string, options?: RequestInit): PromiseT { if (USE_MOCK) { const { mockHandler } await import(./mock); return mockHandlerT(url, options); } const res await fetch(${import.meta.env.VITE_API_BASE}${url}, { headers: { Content-Type: application/json }, ...options, }); if (!res.ok) throw new Error(请求失败: ${res.status}); return res.json(); }然后在.env.local里设置VITE_USE_MOCKtrue VITE_API_BASEhttp://localhost:3000/api这样前端可以先跑通交互等后端接口就绪后把VITE_USE_MOCK改成false即可切换。4.3 用 TaoToken 验证模型调用如果你在 Codex 里配置了 TaoToken 的 API 通道可以用一个简单的请求验证连通性curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: 回复 OK}] }返回正常说明 API 通道没问题。如果要在对话里验证模型效果可以去模型对话页面直接测试如果是长期编码和 Agent 场景建议用 Coding Plan 来管理调用额度。5. 本篇常见错排查5.1 墨刀 MCP 连接失败最常见的原因是 OAuth 授权没完成或者令牌过期。先检查 Codex 的 MCP 服务状态如果显示未连接重新走一遍授权流程。手动配置令牌的话确认 Header 名称是modao-token不是Authorization。另一个坑是服务器地址写错。正确的地址是https://modao.cc/agent-py/ai/mcp不要多加斜杠或路径。5.2 Codex 生成的代码跑不起来通常是依赖没装全或者 TypeScript 类型报错。先跑npm run build看具体报错把错误信息贴回给 Codex让它针对性修复。不要一次性让它改太多文件按页面逐个修。如果组件库版本对不上检查package.json里的依赖版本让 Codex 按你项目现有的版本生成代码而不是它默认的最新版。5.3 原型和代码不一致这种情况一般是提示词里没把原型链接或 PRD 内容带上。让 Codex 重新读取墨刀返回的预览链接和结构化内容明确告诉它以原型的信息架构为准。如果差异太大回到墨刀调整原型重新生成一版再让 Codex 接手。5.4 接口联调时跨域本地开发时前端和后端端口不同浏览器会拦跨域请求。在 Vite 的vite.config.ts里加代理export default defineConfig({ server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true, }, }, }, });然后把VITE_API_BASE改成空字符串请求走相对路径/api由 Vite 代理转发。6. 把这套流程用起来我一般按产品方案、交互原型、前端实现、接口联调、测试验收这五个阶段走。墨刀 MCP 管前两步把模糊的想法变成能讨论、能预览的方案Codex 管后面的工程实现在真实代码库里持续改和验证。这套组合的好处不光是出活快还能避免方向不清带来的重复开发。用专业产品工具把需求和体验想清楚再用代码模型把方案落地。对个人开发者或小团队来说基本覆盖了从规划到第一个可用版本的全过程而且成本比较可控可以反复复用。如果你在接入过程中遇到 MCP 配置或 API 调用的问题可以去接入文档查具体的参数说明需要管理密钥就去 API Keys 页面创建和轮换长期做编码和 Agent 开发的话Coding Plan 能帮你把调用额度管起来。先把墨刀 MCP 和 Codex 的链路跑通再拿一个真实的 CRM 需求走一遍你会发现前期多花半小时定原型后面能省下好几轮返工。