企业官网建设流程全解析

这是我们平台一位匿名用户的真实案例。他想解决的问题很具体：

公司内部的客户信息、订单信息和产品订单记录比较分散，一旦业务人员调整，历史跟进情况、报价记录、订单信息就容易断档。

这类问题在很多公司里都不陌生。

客户资料可能在表格里，订单记录可能在不同文件里，沟通细节可能还留在某个业务人员手上。平时还能凑合用，一到交接，就容易出现信息找不到、上下文接不上、客户跟进不连续的问题。

所以，他希望搭建一个可以在公司局域网内运行的轻量 CRM 系统，用来统一管理客户信息和订单信息。

项目以 Cherry Studio 对接ArkAPI调用大模型，依靠 AI 完成需求拆解、代码开发、BUG 排查工作，省去商用 CRM 持续订阅成本、压低自研的时间人力消耗。项目初始提示词内容如下：

从一句提示词开始

这次实践的起点，是一句很直接的提示词：

CRM 客户管理系统，你能通过编制 Python 代码帮我编写一个吗？请参照我给你的样本制作。

这句话说明了目标：做一个 CRM，用 Python 编写，并参考已有样本。

但真正落地时，“做一个 CRM”还是太大了。它还要继续拆成很多具体问题：

• 是否需要登录；

• 客户信息有哪些字段；

• 订单如何关联客户；

• 是否需要查询和导出；

• 是否需要用户权限；

• 数据放在哪里；

• 最后是单机使用，还是局域网多人访问。

所以，AI 先帮他判断项目结构。

一开始，AI 给了两个方向：单文件版和分模块版。

单文件版更容易上手，所有代码放在一个文件里，适合快速试一版。分模块版会把程序拆成不同文件和目录，后续维护、排错和扩展更方便。

最后，他选择了分模块版。

这个选择对后面的推进很重要。CRM 不只是一个页面，它至少涉及登录、客户、订单、用户、导出、备份等模块。如果所有逻辑一开始都堆在一个文件里，后面每改一次都会更难判断问题出在哪里。

这里第一个经验很简单：

让 AI 写代码之前，先让它帮你把结构拆清楚。

从框架到可运行系统

确定分模块方案后，AI 开始帮助用户生成一套基于 Flask + SQLite 的 CRM 项目框架。

从对话记录看，系统后来逐步包含了这些功能：

• 用户登录和退出；

• 客户信息管理；

• 订单信息管理；

• 用户管理；

• Excel 数据导出；

• 数据库备份；

• 权限控制；

• 局域网访问配置。

这中间不是一次完成的。

更接近真实情况的是：

先让项目启动，再解决登录问题；

登录能进系统后，再测试客户新增、订单管理、数据导出；

基础功能跑通之后，再考虑局域网内其他同事怎么访问。

有一段调试过程很典型。

用户把运行日志发给 AI。AI 根据日志判断：程序本身已经启动，但提交登录表单后没有跳转，问题可能出在表单校验、账号初始化或密码匹配上。

后来用户再次提供日志，AI 看到登录请求已经出现重定向，才判断登录成功。接着，它建议继续测试首页、客户管理、订单管理、用户管理等功能。

这说明，AI 辅助开发时，日志比一句“不能用”更有用。

如果只说“系统不能用”，模型只能猜。

但如果把运行日志、报错信息、相关文件和最近改过的内容一起给它，它就更容易判断问题出在哪里。

真正费时间的，是调试

很多人第一次用 AI 写代码，会把注意力放在“生成代码”上。

但这个案例里，真正有参考价值的部分，反而是后面的调试。

一个内部工具只要开始迭代，很快就会遇到各种细节问题：

• 登录页面不跳转；

• 客户新增没有保存；

• 订单页面显示异常；

• 模板文件被覆盖；

• 路由参数不匹配；

• 导出按钮正常，但页面其他部分不见了；

• 局域网访问还要检查主机 IP、防火墙和监听地址。

其中一个问题是：

订单列表页修改后，只剩下了导出按钮。

AI 判断，这可能不是导出功能的问题，而是模板文件被覆盖了。也就是说，原本完整的订单列表页面，被替换成了一小段按钮代码。

后面又出现过路由参数不匹配的问题。AI 没有继续凭空猜，而是建议先看真实项目里的几类信息：

• 当前项目目录结构；

• Flask 路由列表；

• 订单相关 Python 文件；

• Order 和 Customer 模型定义；

• 当前订单列表模板；

• 导出功能相关代码。

很多代码问题不是单个文件的问题，而是几个文件之间没有对齐。比如模板里写了一个路由名，但真实路由需要额外参数；或者页面里引用的字段名，和模型里定义的字段名不一样。

这类问题不能靠猜。

要把真实路由、模型、模板放在一起看。

所以，让 AI 排错时，不要只贴最后一行报错。

更有效的方式是同时给它：

1. 当前项目结构 2. 相关文件内容 3. 完整报错信息 4. 最近改过什么 5. 哪些功能必须保留 6. 希望它只处理哪一部分

上下文越清楚，AI 越不容易为了修一个问题，又改坏另一个地方。

最终效果

根据该用户的反馈，这个 CRM 系统已经可以在公司局域网内运行，并实现了客户信息和订单信息的管理。

它不是一个完整替代专业 CRM 的产品，更像是一个轻量内部管理工具。

它解决的是一个具体问题：

把原本分散在不同人员、不同文件里的客户和订单信息，集中到一个统一入口，方便后续查询和交接。

这个结果不夸张，但很实用。

对一些小团队或企业内部试点来说，这种路径有一定参考价值：

• 先从真实业务问题出发；

• 用 AI 辅助拆解系统模块；

• 生成基础代码框架；

• 通过日志和报错逐步修复；

• 在局域网中小范围试运行；

• 再根据实际使用情况决定是否继续升级。

长对话要及时收口

这位用户最后总结了一个经验：对话轮次很多的时候，要及时让 AI 做摘要，再开新对话继续。

这个经验很实际。

这类项目一旦聊久了，里面会混着很多旧信息：旧版本代码、已经修过的问题、新加的功能、还没解决的报错。上下文越长，模型越容易把前后版本搞混。

比较稳的做法是，每完成一个阶段，就让模型整理一次：

请总结当前项目结构、已经实现的功能、关键文件、已经修复的问题、还没解决的问题，以及下一步建议。然后拿这份摘要开新对话继续。

该用户也提到，如果重来一次，会把提示词写得更具体一些。

比如不要只说“帮我做一个 CRM”，而是说清楚：

• 客户表需要哪些字段；

• 订单和客户怎么关联；

• 先做哪些页面；

• 现在具体报什么错；

• 哪些文件不要改；

• 希望输出完整文件，还是只输出修改片段。

这些细节看起来不大，但会直接影响模型给出的代码能不能落地。