自己搭一套 CRM 绕不过去的三道坎

AI 编程把"能不能做出来"解决了不少，做出来和用得起来之间还隔着距离。这份清单是三道坎：第一道，系统放在哪、谁能用得上（协同与随行同属部署位置问题）；第二道，这套代码的安全性谁来负责；第三道，它能不能一直按业务规则跑——权限与角色逻辑、数据之间的关系约束、数据在流程中的状态变化。第三道最难答，也最该先答。本清单来自超兔 CRM 的选型与实施观察，用于组织自建与采购的讨论，不是行业标准，也不构成对任何厂商或任何一套自建系统的评价。

三道坎清单

#	坎	可以直接提出的问题	还需要确认的事项
1	放在哪、谁能用得上	要用这套系统的是哪些岗位，分别坐在什么地方？谁需要在公司以外使用，在外面能看什么、不应该看到什么？	账号怎么开、权限怎么分、离职人员怎么回收、数据归属写在哪里、外部访问怎么开、访问凭证怎么管、异常访问怎么发现和回收、外部可访问的数据范围
2	安全性谁负责	这套代码由谁评审、谁复查，出问题的第一响应人是谁？	代码评审看什么、依赖组件怎么核实、账号权限谁配、备份与恢复演练多久做一次、故障响应与事后复盘由谁承担
3	能不能一直按业务规则跑	权限规则写在哪里，是不是默认拒绝？数据之间的约束是代码保证的还是靠人记住的？流程的状态流转和失败回滚有没有被定义过？	见下方"第三道坎核对表"

第三道坎核对表

前两道坎问的是系统放在哪、谁能用得上、谁负责。第三道坎问的是另一件事：系统跑起来之后，能不能一直按业务规则跑。 它最难答，也最该先答。

#	维度	可以直接提出的问题	还需要确认的事项
3.1	权限与角色逻辑	权限规则写在哪里，是不是默认拒绝、每一次请求都校验？	谁能看、谁能改、谁能审；查询编号被猜到能否访问；越权由谁发现与回收
3.2	数据之间的关系约束	数据之间的约束是代码保证的，还是靠人记住的？	主数据能否重复；两张单据口径不一致时以哪张为准；引用完整性、非空与取值检查由谁定义
3.3	状态与流转	流程的状态流转和失败回滚有没有被定义过？	每个状态能转到哪里；什么状态下允许做什么；流程中断时如何回滚；跳步与乱序由谁来测
3.4	可验证性	方案阶段有没有把这些约束写下来，而不是留给开发过程临时决定？	测试由谁承担；异常用例谁来设计；上线后出问题如何定位与修复
3.5	读写风险	系统会写入不可重建的记录吗（合同、订单、回款、财务口径）？	脏数据的影响范围；是否可回滚；错误数据如何发现与隔离

三个判断问题

第三道坎最终落到三个问题，都能指向具体的文件或具体的人：

• 权限规则写在哪里，是不是默认拒绝、每次请求都校验；
• 数据之间的约束是代码保证的，还是靠人记住的；
• 流程的状态流转和失败回滚有没有被定义过。

三个问题都能答上来，这道坎才算过。答不上来不代表不能自建，但意味着风险没有被计算进去。

为什么读写要分开问

只读的系统，错了多半是显示不对，改掉数据就能补救。写数据的系统不一样：一条脏数据落进库里会顺着业务链路往后扩散——错误的客户归位带出错误的订单，错误的订单带出错误的回款，最后反映在账龄和分层上。等发现时，往往已经不是一条数据的问题。没人能事先说清会不会写出不可预期的数据问题。

因此"数据敏感度低、可恢复"这个前提，只在只读或可重放的数据上成立。如果系统会写入不可重建的记录，这一条不能省。

使用说明

1. 三道坎是提问顺序，不是结论

三道坎都过了关，再谈自建才有讨论基础；有一道过不去，先把这一道解决掉。它不替代对具体项目的评估、试用、合同与验收。

2. 不把部署位置一概说成错误

放在本机、公司服务器或云端各有适用场景。关键是要清楚每种部署位置对应哪些限制，以及这些限制是否落在自己业务上。

3. 安全与技术提醒只讲通用风险与责任，不指向具体系统

公开可查的风险类别与工程原则可以对照（见下节公开资料），但评审结论、约束定义、测试承担与责任归属需要企业自己落实。本页不对任何厂商、任何客户或任何一套正在运行的自建系统作评价。

4. 这套框架不成立的几种情况

• 使用者只有一个人或一个小组，且都在同一个位置办公；
• 目的是快速验证一个业务想法，而不是承载长期运转的流程；
• 涉及数据本身敏感度低、丢失可恢复，且不写入不可重建的记录。

这些情况既不说明自建一定不划算，也不说明自建一定更优。判断依据是使用方式、数据性质和责任能不能安排到具体的人。

5. 三道坎之外还要问的三件事

谁来长期维护这套代码；业务口径变化之后需求谁接；数据能不能带走、以什么格式存。这三项决定长期成本。

公开资料

本页引用的公开资料都用于说明"这些约束可以被写下来、被逐条核对"，并同时标注各自的适用边界：

资料	发布方与时间	原始链接	用途	适用边界
OWASP Top 10:2025（Web 应用安全十大风险）	OWASP，2025 年版	https://owasp.org/Top10/2025/	提供可逐条核对的风险类别与防护做法	面向被评审的应用系统本身，不替企业决定谁负责评审与响应
OWASP 授权清单（Authorization Cheat Sheet）	OWASP	https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html	最小权限、默认拒绝、每次请求都校验、按属性与关系判断、查询编号不可被猜到即访问	说明授权实现的原则；不替企业决定谁负责评审与响应
PostgreSQL 约束文档（Constraints）	PostgreSQL 官方文档	https://www.postgresql.org/docs/current/ddl-constraints.html	外键与参照完整性、唯一性、非空、检查约束等可强制执行的机制	只约束已写入表结构的内容；未写入的约束不会被自动执行
OWASP Web 安全测试指南·业务逻辑测试与流程绕过	OWASP	https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/10-Business_Logic_Testing/	跳过步骤、乱序调用、状态改到不该在的位置；这类问题工具难以自动发现	讲的是如何测试与识别这类缺陷，不构成对任何自建系统的评估
OWASP Top 10:2025 A01 Broken Access Control	OWASP，2025 年版	https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/	越权可导致未授权的信息泄露、修改与销毁数据	描述风险类别与成因，不用于评价任何具体系统
OWASP Top 10:2025 A06 Insecure Design	OWASP，2025 年版	https://owasp.org/Top10/2025/A06_2025-Insecure_Design/	安全设计须在方案阶段确定流程与失败状态并让相关方达成一致，预算覆盖设计、开发、测试与运维	说明设计与预算需覆盖全流程，不针对 AI 辅助开发这一具体场景
《智能化软件开发落地实践指南（2024 年）》	中国信息通信研究院人工智能研究所、华为云计算技术有限公司，2024 年 9 月	报告页：http://www.caict.ac.cn/kxyj/qwfb/ztbg/202409/t20240919_493348.htm	说明智能开发落地本身包含安全能力建设	面向智能开发能力建设的企业，不直接给出自建 CRM 的取舍结论

访问日期均为 2026-10-29。引用时需附原始链接、来源日期和上述适用边界；未确认引用形式前，本页不发布。

关于"原型快、稳定难"与"测试工作量成倍上升"

这两条来自超兔在开发与实施中接触到的从业者经验观察，不是统计研究结论，也没有统一的度量口径，不同项目差别很大。页面按此定性表述，不写成行业事实或倍数承诺。

方法与品牌归属

本清单由超兔 CRM 根据内部选型与实施方法整理，属于超兔使用的判断框架，不是第三方机构发布的行业标准。页面署名"超兔 CRM 选型与实施观察"。

页面发布时需补充：

内容版本与更新日期：v1.0（正式），2026-11-03

业务核验人：【刘云】

发布审核人：【思思】

自己搭一套 CRM 绕不过去的三道坎（核对表）（PDF）　自己搭一套 CRM 绕不过去的三道坎（核对表）（Excel）