1. 两天做出能跑业务的 CRM这件事到底难在哪先说结论用 Codex 辅助写一个 CRM 客户管理系统两天跑通增删改查和进度跟踪对一个小团队来说完全可行。我这次做的系统现在有 8 个真实客户在用不是演示数据是销售每天打开就要跟进的那种。这篇文章不讲概念只讲落地settings.json 怎么配、TaoToken 统一 Key 怎么接、本地启动后怎么验证客户增删改查和 API 连通性。适合谁看如果你是小团队负责人、独立开发者或者手上有一堆零散客户需要管起来又不想花一个月搭后台这篇的路径可以直接抄。核心检索词就三个Codex、CRM、客户管理系统。我会把配置骨架和验证动作都写清楚你照着做两天内能跑出一套可用的客户管理后台。为什么是两天而不是两周因为真正耗时间的不是写代码而是想清楚数据结构和跟进流程。Codex 负责把重复的 CRUD、表单、列表、状态流转生成出来你负责判断“这个字段业务上要不要”“这个状态流转对不对”。我踩过的坑是一开始让 AI 自由发挥结果字段命名混乱后面改起来比重写还累。所以第一步一定是先把客户模型定死。这个 CRM 的核心不是功能多而是让销售每天打开就知道该跟谁聊。首页四个数字客户总数、正在联系、待跟进、即将到期。再往下是服务进度条从签约到拍摄到发布到直播每个环节实时更新。运营不用问销售不用确认看一眼就知道项目推到哪了。这种“管理进度”比单纯“记录信息”有价值得多。技术选型上我用的是一套轻量后端加一个管理后台页面数据库就是本地能跑的关系型库。重点不在框架而在接入层——所有模型调用走 TaoToken 统一 Key这样 Codex 生成代码、后续加功能、换模型都不用改业务逻辑。下面从接入开始讲。2. TaoToken 前置统一 Key 接入与 settings.json 骨架在写业务代码之前先把模型调用这条链路打通。TaoToken 的作用是给你一个统一的 API 入口和 KeyCodex 生成的代码里所有模型请求都指向它不用在每个文件里散落不同的地址和密钥。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。你需要先拿到 API Key。进入控制台创建https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 然后在 API Keys 页面生成一个 Keyhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。生成后复制保存后面配置里要用。settings.json 是整个项目的接入骨架。我把它放在项目根目录的 config 文件夹下Codex 生成代码时会读取这个文件里的 base_url 和 model 字段。下面是我实际在用的骨架你可以直接复制改 Key{ provider: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的Key填这里, model: claude-sonnet-4-20250514, timeout: 60, max_retries: 2, crm: { db_path: ./data/crm.db, page_size: 20, follow_up_days: 7, expire_warn_days: 3 } }几个参数说明一下。base_url 固定指向 TaoToken 的 API 入口不要加多余路径。model 字段决定 Codex 生成代码时默认调用的模型你可以按需换。timeout 设 60 秒CRM 里有些批量操作会慢一点。max_retries 设 2网络抖动时自动重试。crm 段是业务配置db_path 是本地数据库文件位置page_size 控制列表每页条数follow_up_days 是“待跟进”的判定天数expire_warn_days 是“即将到期”的提前提醒天数。注意api_key 不要提交到代码仓库。我是在 .gitignore 里把 config/settings.json 排除掉然后单独放一个 settings.example.json 做模板。配置写好后先别急着写业务。用一段最小请求验证 Key 能不能通。你可以让 Codex 生成一个 test_connection 脚本或者直接手写import json import requests with open(config/settings.json, r, encodingutf-8) as f: cfg json.load(f) headers { Authorization: fBearer {cfg[api_key]}, Content-Type: application/json } payload { model: cfg[model], messages: [{role: user, content: 回复 OK 两个字母即可}], max_tokens: 10 } resp requests.post( f{cfg[base_url]}/v1/chat/completions, headersheaders, jsonpayload, timeoutcfg[timeout] ) print(resp.status_code) print(resp.json())跑通这段说明 Key 和地址都对。如果返回 401检查 Key 有没有复制完整如果返回 404检查 base_url 是不是写成了带斜杠结尾或者多了路径。这一步过了再让 Codex 去生成 CRM 的业务代码它就会自动引用这个配置。3. 可复制配置Codex 生成 CRM 的 settings.json 与目录结构配置通了之后接下来是让 Codex 按你的业务生成代码。这里的关键不是提示词多花哨而是你把数据结构先定清楚。我用的客户模型字段如下你可以直接拿去让 Codex 生成对应的建表和接口{ customer: { id: integer primary key, name: text not null, contact: text, phone: text, stage: text default lead, owner: text, next_follow_up: date, expire_date: date, progress: integer default 0, note: text, created_at: datetime default current_timestamp, updated_at: datetime default current_timestamp } }stage 字段是客户阶段我用的是 lead、contacting、signed、delivering、done 五个值。progress 是服务进度百分比0 到 100。next_follow_up 和 expire_date 分别驱动首页的“待跟进”和“即将到期”两个数字。目录结构我让 Codex 按下面这样生成保持清晰crm/ ├── config/ │ ├── settings.json │ └── settings.example.json ├── app/ │ ├── main.py │ ├── models.py │ ├── routes/ │ │ ├── customer.py │ │ └── dashboard.py │ └── services/ │ └── llm.py ├── data/ │ └── crm.db └── tests/ └── test_customer.pyservices/llm.py 是统一调用层所有模型请求都从这里走读取 settings.json 里的 base_url 和 api_key。这样以后换模型或者加功能只改这一个文件。Codex 生成时给它明确指令“所有 LLM 调用必须通过 services/llm.py禁止在 routes 里直接写请求。”客户增删改查的接口我让 Codex 生成 RESTful 风格路径如下方法路径作用GET/api/customers客户列表支持分页和筛选POST/api/customers新增客户GET/api/customers/{id}客户详情PUT/api/customers/{id}更新客户DELETE/api/customers/{id}删除客户GET/api/dashboard首页四个统计数字生成完先别跑检查一遍字段名和 settings.json 里的 crm 段是否对应。我遇到过 Codex 把 follow_up_days 写成 followup_days 的情况导致待跟进计算不对。这种小错跑起来才发现不如生成后先扫一眼。4. 验证请求本地启动后跑通增删改查与 API 连通性代码生成完本地启动。我用的是 uvicorn 起后端cd crm uvicorn app.main:app --reload --port 8000启动后先看日志有没有报错。如果提示数据库文件不存在手动建一下 data 目录或者让 Codex 在启动时自动初始化。然后按顺序验证四个动作。第一个动作验证 API 连通性。调 dashboard 接口curl http://127.0.0.1:8000/api/dashboard正常返回应该是四个数字初始都是 0{total: 0, contacting: 0, follow_up: 0, expiring: 0}如果这里报 500大概率是数据库表没建。检查 models.py 里的建表逻辑有没有在启动时执行。第二个动作新增一个客户curl -X POST http://127.0.0.1:8000/api/customers \ -H Content-Type: application/json \ -d { name: 测试客户A, contact: 张三, phone: 13800000000, stage: lead, owner: 我, next_follow_up: 2025-06-20, expire_date: 2025-07-01, progress: 10, note: 首次接触 }返回里应该带一个新生成的 id。记下这个 id下一步用。第三个动作查列表和详情curl http://127.0.0.1:8000/api/customers curl http://127.0.0.1:8000/api/customers/1列表里应该能看到刚才新增的客户详情接口返回完整字段。如果列表为空但新增返回成功检查查询条件有没有默认过滤掉某些 stage。第四个动作更新和删除curl -X PUT http://127.0.0.1:8000/api/customers/1 \ -H Content-Type: application/json \ -d {stage: contacting, progress: 30} curl -X DELETE http://127.0.0.1:8000/api/customers/1更新后再查详情stage 应该变成 contactingprogress 变成 30。删除后再查列表这条记录应该消失。四个动作全过说明增删改查链路通了。最后验证模型调用链路。在 services/llm.py 里加一个测试函数或者在某个接口里触发一次模型请求确认它走的是 settings.json 里的 base_url 和 Key。我是在客户详情页加了一个“生成跟进建议”的按钮点一下会调模型返回一段话。这一步过了说明 Codex 生成的业务代码和 TaoToken 接入层是打通的。提示验证顺序很重要。先通 API 连通性再通增删改查最后通模型调用。反过来容易在多个错误之间来回猜。5. 本篇常见错排查Codex 生成 CRM 时的报错与配置坑第一个坑401 Unauthorized。九成是 api_key 没填对或者复制时带了空格。检查 settings.json 里 Key 前后有没有多余字符以及请求头是不是Bearer sk-xxx格式。如果 Key 确认没问题还是 401去控制台看这个 Key 有没有被禁用或者额度用完。第二个坑404 Not Found。通常是 base_url 写错。正确写法是https://taotoken.net/api不要加/v1在后面也不要以斜杠结尾。Codex 生成代码时有时会自作主张拼路径检查 services/llm.py 里的拼接逻辑。第三个坑数据库表不存在。启动时报no such table: customer。原因是建表逻辑没执行。让 Codex 在 main.py 启动事件里加一段初始化或者手动跑一次建表脚本。我是在 app/models.py 里写了一个 init_db 函数启动时调用。第四个坑待跟进数字不对。dashboard 返回的 follow_up 一直是 0但明明有客户 next_follow_up 是今天。检查 settings.json 里 follow_up_days 的值以及计算逻辑是不是用了而不是。另外注意日期格式数据库里存的是 date 还是 datetime比较时类型要一致。第五个坑Codex 生成的字段名和配置对不上。比如 settings.json 里写的是 page_size代码里读的是 pagesize。这种错误不报异常只是行为不对。生成后花两分钟对照一遍配置项和代码里的读取键名能省很多调试时间。第六个坑模型调用超时。CRM 里批量生成跟进建议时如果一次请求太多条容易超时。把 timeout 调到 60 以上或者改成异步逐条处理。我在 settings.json 里设的 max_retries 是 2配合超时重试基本能覆盖网络抖动。第七个坑端口被占用。uvicorn 起不来提示 address already in use。换端口--port 8001或者把之前的进程杀掉。这个不算配置问题但新手容易卡住。排障时如果拿不准是接入层还是业务层的问题先单独跑第 2 节那段最小请求脚本。脚本通了说明 Key 和地址没问题问题在业务代码脚本不通说明接入配置有误。这个二分法能快速定位。6. 接入与排障Key、文档与后续编码路径如果你在接入阶段卡住优先看两个地方。API Key 的创建和管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。文档里有完整的请求格式和参数说明比在代码里猜要快。验证模型是否正常工作时可以用模型对话页面直接发一条消息测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。如果那边能正常回复说明 Key 和模型都没问题问题就在你的代码配置上。如果你打算长期用 Codex 做编码和 Agent 类任务比如持续给这个 CRM 加功能、接自动化流程可以看一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它更适合高频编码场景不用每次单独配 Key。回到 CRM 本身。两天跑通之后我建议你先别急着加功能而是让真实用户用一周。我那 8 个客户用下来反馈最多的不是缺功能而是某些字段填起来麻烦、某些状态流转不符合实际。这些只有用起来才知道。Codex 改这些很快但前提是你知道要改什么。所以先跑通、先用、再迭代这个顺序别反。
