35CRM投后管理

解决什么问题

投后团队经常要在 35CRM 里反复查同一类数据：客户是谁、投了哪些金融产品、对应哪张认申购单。手工点页面费时，直接写接口又容易踩中文编码、日期格式、响应结构不一致的坑。这个技能把查询路径固化下来，让你用自然语言就能完成常规检索，不需要临时拼脚本或猜字段。

它不追求覆盖 CRM 全量能力，只聚焦产品投后管理中最常被问到的三张数据表：客户、金融产品、认申购单，以及按客户名称或产品名称反查认申购单的组合查询。

如何工作

核心能力

• 查询客户列表：POST /customer/list
• 查询金融产品列表：POST /productFinance/list
• 查询认申购单列表：POST /contractOrderFinancePrimary/list
• 组合查询：按客户名称或产品名称查认申购单
• 统一解析响应：resp.get('rows') or resp.get('data') or []

关键步骤

1. 检查配置：每次会话开始时确认环境变量 CRM_BASE_URL 与 CRM_AUTH_TOKEN 已设置，避免请求发出后才发现缺配置。
2. 凭据复用：同一会话中不再重复索要 Token，减少交互噪音。
3. 按需查询：先明确你要查的对象和字段，再调用对应接口。字段说明分散在 customer.md、product-finance.md、contract-order-finance.md 中，可按索引查阅。
4. 组合查询：当你只知道客户名称或产品名称时，按 contract-order-finance.md 的组合工作流先定位基础对象，再反查认申购单。
5. 分步写入 JSON：先收集字段定义和数据，再按步骤写入结构化 JSON，而不是一次性吞下整张表。

工程细节

• 含中文的请求必须通过 Python 脚本 crm_query.py 执行，不能直接用 Bash curl，否则编码容易出问题。
• 涉及 multipart 请求时，使用 curl --data-binary @- 并通过 subprocess 发送。
• 日期格式统一为 Y-m-d H:i:s，必须带时间部分，例如 2026-06-05 00:00:00。
• enums.md 里定义了时间常量、dbType 和 searchCondition 通用结构，写查询条件时可以参考。

适用边界与注意点

只读，不写入

这个技能仅提供查询功能，不支持新增客户、修改产品、编辑认申购单等写操作。任何数据变更仍需回到 35CRM 原生界面或其他有权限的系统完成。

Token 失效必须立即停止

如果查询返回 HTML 页面而不是 JSON，或返回 success: false 且提示认证相关错误，说明 CRM_AUTH_TOKEN 已过期或不可用。此时必须停止后续操作，提示用户：「CRMAUTHTOKEN 已失效，请提供新的 Token。」严禁自行调用登录接口或猜测凭据。

字段需要分步确认

接口返回的数据量可能很大，一次性拉全表再过滤并不现实。更稳妥的方式是先确认字段口径，再按需索要数据，逐步写入 JSON，避免返回冗余字段或超出预期的数据范围。