懂业务的人，能用AI长出系统能力
主要观点
一个家具建材行业老板，先用12万元外包做ERP，开发一年却在上线一个月后亲手放弃；随后借助AI、零代码基础和持续学习，用一个月做出真正贴合业务的系统。复盘最有价值的部分，不是工具清单，而是如何把客资、成本、绩效、例外处理等隐性经验拆成可执行规则，再让AI参与架构和实现。文章也把这套经验延伸为FDE服务：深入传统行业，快速交付，并让客户能够自己修改。
关键要点
- 外包失败的根源不是单纯技术水平不足，而是业务语言与开发语言之间存在长期错位；“画原型—讲流程—反复沟通”虽痛苦，却反过来训练了需求表达和工程思维。
- 文中给出的六格需求模板把开发前的思考拆成背景、输入、输出、规则、例外、验收；其中任何一格填不出来，都意味着需求尚未真正想清楚，应该先与AI澄清而不是立即开工。
- AI降低了编程门槛，却没有消除学习成本。作者从Claude Code、Skill、MCP、claude.md、hooks等概念入手，每天投入至少两小时，说明真正的新门槛是建立与工具协作的工作流。
- 系统价值来自对行业细节的固化，而非功能数量：实时归集材料、人工、辅料和杂费来计算项目毛利，能让经营者在项目执行中干预，而不是事后复盘亏损。
- 管理规则被写进系统后，老板只处理被层层升级的例外；员工评分又与客户资源分配绑定，软件因此从记录工具变成了制度执行机制，也构成通用SaaS难以复制的部分。
- 面向外部客户的FDE服务，关键卖点被归纳为真正进入门店、车间或仓库理解业务，交付后教会甲方自己修改，并把响应速度置于功能堆叠之上；但案例的高强度投入和单一企业样本，也留下了可复制性与投入产出比的待验证问题。
建议带着这些问题阅读
- 文中这套系统在29人家具建材团队中有效，换到其他行业或更大规模团队时，哪些规则仍然成立？
- 自研系统的每月2000多元订阅成本之外，长期维护、数据治理和老板个人投入应如何计算？
- FDE项目怎样证明快速响应和深度理解业务足以覆盖交付、培训与后续维护成本？