这是我们平台一位匿名用户的真实案例。他想解决的问题很具体公司内部的客户信息、订单信息和产品订单记录比较分散一旦业务人员调整历史跟进情况、报价记录、订单信息就容易断档。这类问题在很多公司里都不陌生。客户资料可能在表格里订单记录可能在不同文件里沟通细节可能还留在某个业务人员手上。平时还能凑合用一到交接就容易出现信息找不到、上下文接不上、客户跟进不连续的问题。所以他希望搭建一个可以在公司局域网内运行的轻量 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”而是说清楚客户表需要哪些字段订单和客户怎么关联先做哪些页面现在具体报什么错哪些文件不要改希望输出完整文件还是只输出修改片段。这些细节看起来不大但会直接影响模型给出的代码能不能落地。
这是我们平台一位匿名用户的真实案例。他想解决的问题很具体公司内部的客户信息、订单信息和产品订单记录比较分散一旦业务人员调整历史跟进情况、报价记录、订单信息就容易断档。这类问题在很多公司里都不陌生。客户资料可能在表格里订单记录可能在不同文件里沟通细节可能还留在某个业务人员手上。平时还能凑合用一到交接就容易出现信息找不到、上下文接不上、客户跟进不连续的问题。所以他希望搭建一个可以在公司局域网内运行的轻量 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”而是说清楚客户表需要哪些字段订单和客户怎么关联先做哪些页面现在具体报什么错哪些文件不要改希望输出完整文件还是只输出修改片段。这些细节看起来不大但会直接影响模型给出的代码能不能落地。
 JS ToolKit构建完整医学影像应用)
