AI 重写 CRM 几个月没上线,卡在“谁说了算”
陈然和一家公司团队聊了两小时 AI coding 落地。他的判断是:开发一晚写完、测试要测三天,问题出在没人能拍板正确答案,换测试工具解决不了。
- 谁说的
- 陈然在 Pure Global 做产品和开发。他的搭档 DJ 说,公司高峰期国内有二十来个开发,现在基本只剩他们两人。文章来自他给一家公司做的 AI coding 落地讨论。
- 核心观点
- 他认为 AI 时代难的不再是实现,而是业务没想清楚。AI 碰到模糊的地方不会停下来问,会挑一个看似合理的解释写下去,于是所有没想清楚的地方都会以 bug 的形式堆到测试那里。他的解法是让懂业务、说了算的人端到端负责,也就是“更少的人,更大的权限”。
- 依据
- 依据有三个。第一,那家公司的报价模块折扣反算、服务费联动,每次修完一处又冒出新问题。第二,他自己做的 BI demo 给每个口径都编号,写明理由、配上测试,便宜的弱模型也能写对 SQL。第三,DJ 在泰国子公司和团队坐了两天,第二天写出进出口流程程序,又自己测了一周才交出去。
- 对你的意义
- 下一次让 AI 做报表或业务逻辑之前,先把关键指标的分母、边界情况写成带编号、写明理由、配有测试的定义,放进代码库;再指定一个人对结果负责,并给他改规则的权力。
- 争议·条件
- 团队里有反对意见:PM、开发、测试各有所长,应该靠协作流程来对齐。陈然自己也承认,监管、多国业务、历史合同带来的复杂是真实存在的,重写也有成本,需要 owner 判断值不值得。
陈然在这篇文章里复盘了一次讨论。一家公司几个人用 AI 重写内部 CRM,做了几个月没上线。团队问的都是 spec 写到多细、用什么端到端测试工具、硅谷有什么最佳实践。他只反复问一句:报价到底谁说了算?测试同事想“先假设大家都知道规则”,他说问题就在于没人知道。测试慢,是因为没人知道正确答案长什么样。
他自己的做法是把口径写清楚:每个口径都有编号、理由和测试,全放在同一个代码库,每张表、每个字段的注释都不能有歧义。比如待审批的工时算不算饱和度,一周跨两个月时工时归哪个月,这些都要写死。写清楚以后,便宜的模型也不用猜。他还提醒,集中的是决定权,知识不能集中。规则必须落在代码库里,人和 AI 都能读,外人拿到也能看懂。
他也说老板只对了一半。光要求员工都成为业务专家没用,专家得有权改价格体系、砍掉定制、决定重写,否则只会变成“非常懂业务、也非常痛苦的测试”。他的建议是挑一个系统,指定一个人全权负责。工具选型交给 AI 评估就行,下个月有更好的再换。