如果放在半年前，有人告诉我，我可以自己动手开发一套联盟客CRM系统，我大概率是不相信的。
毕竟，我不是程序员，也没有什么软件开发经验。平时接触最多的还是联盟营销、品牌推广和独立站运营。
至于代码、数据库、前后端开发这些东西，以前虽然听说过，但真要让我自己动手，基本上是七窍通了六窍，一窍不通。
不过，做了这么多年联盟营销和联盟客，我一直有个想法：能不能自己做一套真正适合联盟客开发的管理系统？
因为实际做过联盟客开发的朋友应该都清楚，从寻找潜在联盟客、筛选匹配对象、获取联系方式，到发送开发邮件、跟进合作进度，整个流程涉及的环节并不少。
市面上当然有不少联盟营销工具和CRM系统，但不同工具的功能侧重点不一样，数据也比较分散。想把这些工作串联起来，很多时候还是需要在多个平台之间来回切换。
以前也考虑过自己做一套，但不会写代码始终是个绕不开的问题。如果专门找技术团队开发，不仅需要投入资金，后续的功能调整和维护也是持续的成本。
直到今年开始尝试AI来开发，我才觉得，这件事或许真的可以自己试一试。
于是，今年4月，我开始折腾自己的联盟客CRM。
最开始并没有想那么远，只是希望把日常工作中需要的一些功能做出来，方便自己使用。
至于后来会折腾成什么样，当时确实没有想到。
今天就想聊聊这半年多的经历。不是什么技术教程，也谈不上成功经验分享，更多是一个联盟客，尝试借助AI，把自己的业务想法变成实际工具的过程。
从一个想法，到第一次动手
真正开始做的时候，我遇到的第一个问题，不是代码怎么写，而是根本不知道应该从哪里开始。
以前使用AI，更多是写文案、整理资料、分析数据，偶尔让它帮忙处理一些网站上的代码问题。但从零开始开发一套独立的软件，还是第一次。
当时也想过，是不是应该先系统学习一下编程，至少弄清楚前端、后端和数据库这些基础知识，再开始动手。
但转念一想，自己的目的并不是成为程序员，而是想解决实际工作中的问题。
既然AI已经能够辅助编程，为什么不先试试看？
于是，我开始把脑子里的想法整理成具体需求，再交给AI来帮忙实现。
最初的要求并不复杂。
比如，建立一个统一管理联盟客资料的页面，能够记录网站、邮箱、社交媒体等信息，为不同联盟客设置开发状态，再逐步加入搜索和筛选功能。
这些都是平时工作中经常会用到的东西，自己对业务逻辑也比较熟悉。
但很快就发现，自己知道想要什么，和能够把需求准确地描述给AI，完全是两回事。
有时候觉得已经说得很清楚了，生成出来的页面却和预想的不一样。有时候只是想增加一个简单的功能，实际操作时却发现还涉及其他文件和配置。
更麻烦的是，自己看不懂代码。
AI生成一大段代码以后，我甚至不知道应该把它放在哪里，也不清楚哪些文件可以修改，哪些不能随便动。
遇到报错，只能把错误信息复制给AI，让它帮忙分析原因，再按照提示一步步操作。
有时候一个问题来回折腾好几次，最后才发现可能只是某个配置没有设置正确。
现在回头看，那时候的开发方式确实挺原始的。
基本就是提出需求、生成代码、运行测试，遇到问题再继续修改。
不过，也正是在这个过程中，我开始慢慢接触开发环境、项目文件、前后端和数据库这些以前不太了解的东西。
这些知识并不是提前系统学习过的，而是在实际操作中遇到问题，再一点点弄明白。
当然，很多时候即使问题解决了，我也未必完全理解其中的技术原理，但至少项目开始有了实际进展。
从最初只是和AI讨论想法，到创建项目、配置环境，再尝试让程序运行起来，我算是真正迈出了第一步。
而且，AI有一个很容易让人上头的地方。
当你发现一个功能真的能够实现以后，就会忍不住想：既然这个可以做，那是不是还能再增加一点别的东西？
于是，原本只是想做一个简单的管理工具，功能开始越加越多。
能在自己电脑上运行，就算做成了吗？
从今年4月到6月，我陆陆续续做出了一些功能。
联盟客资料可以集中管理了，基础的搜索、筛选和状态记录也逐渐有了相应的实现。
虽然还不完善，但已经有了一套能够在自己电脑上操作的CRM。
对于当时的我来说，还是挺有成就感的。
以前总觉得，开发软件需要专业的技术团队。现在自己借助AI，居然也能一点点做出一个能实际操作的系统。
不过，随着功能增加，问题也开始多起来 - 最明显的就是各种BUG。
有时候页面能够正常显示，但数据没有按照预期保存；有时候刚修复一个功能，增加其他内容以后，原来的地方又出现异常。
还有些问题更加麻烦。
明明只是要求AI修改一个地方，结果它顺带调整了其他代码。当前问题可能解决了，但过一段时间才发现，原本正常的功能受到了影响。
那时候的我，也没有足够的能力判断它究竟改了什么。
只能继续把问题反馈给AI，再一轮轮尝试。
折腾久了才发现，AI生成代码确实很快，但大量时间其实花在了后面的检查和修复上。
不过，虽然BUG不少，我也没有想过就此停下来。
毕竟，一个原本只存在于脑子里的想法，已经变成了自己能够实际操作的工具。
到了7月，在出海指南线下的网红营销分享会，还分享了AI时代下的联盟营销。
→ AI时代下的联盟营销
当时聊到了如何借助 AI，把联盟客搜索、筛选、建联、跟进和数据分析这些环节逐步串联起来。
其实，这也是我开发CRM时一直希望实现的方向。
当时的CRM仍然只能在本地运行，功能也不够完善，各种BUG还需要继续处理。
只能说，理想很丰满，现实很残酷。
不过，那次分享后也让我开始认真考虑一个问题。
既然已经花了几个月做出一个自己能够使用的版本，接下来是不是可以再往前走一步？
不只是让它在自己的电脑上运行，而是尝试把它做成一套真正能够在线使用的产品。
于是，从7月底开始，我逐渐把开发重心转向了线上版本。
从本地到线上，才发现真正的难题刚开始
最开始，我对线上部署的理解其实很简单。
无非就是把本地代码放到服务器上，配置好域名，让系统能够通过浏览器访问。
真正开始做以后才知道，这里面涉及的事情远不止这些。
首先就是数据管理。
本地使用时，基本只有自己一个用户，很多问题可以按照自己的习惯处理。
但如果未来有不同用户使用，每个人的联盟客资料、联系方式、邮件记录和合作信息，就必须有明确的权限和隔离机制。
总不能A用户登录以后，还能看到B用户的联盟客名单。
这也是我第一次比较认真地接触用户权限、身份验证和数据隔离这些概念。
以前做管理工具，更多关注信息能不能保存、页面能不能正常展示。
现在则需要考虑，这些数据应该由谁访问、如何修改，以及出现异常时应该怎么处理。
除此之外，还要面对服务器配置、接口调用、数据库迁移和数据备份等问题。
很多东西在本地能够正常运行，换到线上环境以后，却不一定能够按照原来的方式工作。有时候是环境配置不一致，有时候是接口没有正常返回数据，还有时候需要检查后台的运行情况。
这些问题不像页面按钮没有反应那么直观。
对于没有技术基础的我来说，光是弄清楚问题发生在哪个环节，就需要花不少的时间。
也是在推进线上开发的过程中，我开始更加深入地使用GitHub管理代码。
以前觉得GitHub只是一个存放代码的平台。后来才逐渐理解，版本记录、分支和代码提交这些功能，对于一个需要长期维护的项目有多重要。
尤其是当AI一次修改多个文件时，如果没有清晰的记录，出现问题以后，很难知道应该从哪里恢复。
所以，开发也开始有了更多需要遵循的流程。
不是每次生成代码以后，直接覆盖原来的文件就可以了。哪些修改需要保留，哪些涉及数据库，哪些可能影响已经完成的功能，都需要更加谨慎地处理。
那段时间，我经常面对一份包含很多步骤的开发方案。
有些步骤涉及服务器，有些涉及数据库，还有些需要在不同工具之间切换。
对懂技术的人来说，可能只是正常的开发操作。但对我来说，每个新环节都意味着还要继续学习。
有时候前面的步骤都顺利完成，到了最后才发现某个配置不符合要求，又得重新排查。
不过，这段经历也让我对整套系统有了不同的认识。
以前看到一个CRM页面，主要关注功能够不够用、操作方不方便。
后来再看同样的页面，就会想到它背后的数据从哪里来、不同用户能不能正确访问，以及系统更新以后，原来的数据和功能会不会受到影响。
从7月底到8月，我主要就在这样的过程中不断推进线上版本的开发。
原本以为，解决了线上运行的问题，后面就可以把精力集中到增加功能和优化界面上。
但进入9月以后，我发现还有另一件事情需要认真处理。
那就是前面已经做出来的功能，并不一定都符合整套产品的实际需求。
写代码不难，难的是不断返工
进入9月以后，这套联盟客CRM开发系统已经积累了不少页面和模块。
但当我开始从整体产品的角度重新检查时，才发现有些之前做过的功能，还需要重新调整，甚至重新设计。
这个阶段其实挺容易产生挫败感的。
因为明明已经花时间做过了，为什么现在还要重新做？
后来逐渐发现，问题并不一定出在代码上，而是自己最初对产品的考虑还不够完整。
比如，系统已经有了联盟客管理页面，也能够搜索和筛选资源。
但如果按照实际开发联盟客的工作流程重新操作，就会发现还有很多需要考虑的细节。
搜索到一个潜在联盟客以后，下一步应该怎么处理？如果这个资源已经存在于CRM中，系统应该如何识别？不同开发阶段的信息应该在哪里查看？后续跟进时，能不能快速找到之前的沟通记录？
这些事情，平时使用表格或者不同工具时，可以凭自己的经验去处理。
但如果想把它们整合到一套CRM中，就需要让各个模块之间真正建立联系。
否则，即使每个功能单独都能使用，实际工作时仍然需要反复切换页面，甚至重新手动整理数据。
所以，我开始按照实际联盟客开发的顺序，重新梳理系统里的业务流程。
哪些步骤应该衔接，哪些信息需要共享，哪些功能只是看起来有用，但并不是当前最需要解决的问题，都需要重新判断。
除了业务流程，界面设计也需要统一。
前期很多页面是按照当时的需求分别完成的，单独看可能没有什么问题，但放在一起，就会发现布局和操作方式存在不少差异。
有的页面信息比较密集，有的留白过多；有的操作入口很直观，有的却需要找半天。
而CRM是一套需要反复使用的工作系统。
如果一个操作每天需要重复几十次，那么即使只是多点几下鼠标，长期下来也会影响效率。
所以，后来我也开始更加重视界面原型、信息层级和交互的一致性。
有些页面明明已经能够使用，却还是需要重新调整布局。
这部分工作不像开发新功能那么明显，但同样花费了不少时间。
与此同时，我也开始让 AI 对整个项目进行更全面的检查。
到了10月，我对CRM 做了一次全局审计。
当时的结果显示，规划中的28个界面，已有22个对应的页面组件，仍有 6 个缺失；部分业务页面也还没有独立的访问路由。
看到这个结果，还是有些意外的。
因为平时一直在开发，也能看到越来越多的页面和功能，很容易觉得系统已经比较完善了。
但真正拿最初的规划逐项对照，才发现还有一些内容没有完成。
而且，页面组件已经存在，也不代表对应的业务功能就一定完整。
这次检查让我开始重新审视整个项目的进度。
以前可能更关注已经开发了多少功能，现在则会更加在意哪些流程真正能够完整使用，哪些地方还有缺口。
有时候花了几天时间，没有增加任何新页面，只是在调整原来的设计，或者补齐某个业务环节。
从表面上看，好像没有什么明显进展。
但如果这些问题一直不处理，即使继续增加功能，后面也可能需要花更多时间修改。
当然，这些返工也不能全部归结为AI的问题。
很大一部分原因，还是自己对软件产品开发缺乏经验。
我熟悉联盟营销业务，知道日常工作中有哪些问题需要解决，但这不代表一开始就能够把所有需求转化成完整、合理的软件设计。
很多事情，只有真正做到那一步，才会发现之前考虑得不够周全。
这也是这半年让我感受比较深的一点。
让 AI 写出一个功能并不难，难的是让这些功能真正组成一套符合业务需求、能够持续完善的产品。
而经历了这些调整以后，我也开始改变自己与AI协作的方式。
这半年，我是怎么学会和 AI 一起开发的？
如果说这半年在AI编程方面有什么实际收获，我觉得并不是学会了多少代码，而是逐渐形成了一套适合自己的协作方式。
直到现在，系统里的大部分代码仍然依靠 AI 编程工具完成。
但相比最开始想到什么就直接让 AI 去做，现在会更加关注一项开发任务应该怎样安排。
首先是把需求尽量说清楚。
以前可能只会说：“帮我优化一下联盟客管理页面。”但现在会尽量说明当前存在什么问题，希望调整哪些内容，哪些功能必须保留，以及最终应该达到什么效果。
如果涉及业务逻辑，还会把实际使用场景一起描述出来。
因为 AI 可以帮助设计技术方案，但联盟客开发过程中哪些信息最重要、哪些操作最常用、什么样的流程更符合实际工作习惯，还是需要自己判断。
其次是把复杂任务拆开。
以前经常希望 AI 一次性完成整个模块，最好连页面、数据处理和相关功能都一起做好。
后来发现，任务范围太大，反而不容易判断每一步是否符合预期。
所以，现在遇到比较复杂的需求，我会先让 AI 梳理现有实现，再区分哪些属于页面调整，哪些涉及业务逻辑，哪些需要修改数据库。
确认顺序以后，再分阶段执行。
这样虽然不一定是最快的方式，但每完成一部分，都能够及时检查结果。
第三，是先检查，再修改。
现在遇到问题，我通常不会马上要求 AI 直接修复，而是先让它检查相关代码，说明可能的原因和影响范围。
如果涉及比较重要的模块，还会要求先给出方案，确认以后再执行。
因为有时候 AI 给出的方案看起来很完整，但未必适合当前项目。
尤其是涉及多个文件时，不能只看当前问题有没有解决，还需要知道这次修改可能影响哪些地方。
第四，是把技术测试和实际业务验收分开。
以前AI告诉我“已经完成”“测试通过”，我往往就会继续下一个任务。
现在则会进一步检查，页面实际效果是否符合要求，业务操作能不能正常完成，原来的功能有没有受到影响。
技术测试可以帮助发现很多问题，但它并不能代替对实际业务需求的判断。
对于一套联盟客CRM来说，最终还是要看它能不能按照预期完成日常工作。
最后，是把一些反复验证有效的方法整理成固定规则。
比如，修改之前先检查现有项目，不随意调整无关文件；涉及重要数据和权限时，需要先确认风险；完成修改以后，要说明实际变更内容，并进行相应验证。
这些要求并不是一开始就制定好的，而是在开发过程中逐渐积累起来的。
这其实和做联盟客开发有点类似。
刚开始可能每找到一个资源，都需要自己判断、记录和跟进。
但做得久了，就会形成一套相对固定的筛选标准和工作流程。
AI也是一样。
如果每次遇到问题，都只是临时向AI提问，很多经验很难真正积累下来。
但如果把已经验证有效的方法整理下来，后续遇到类似任务时，就可以少走一些弯路。
当然，这并不意味着现在的我已经能够判断所有技术问题。
遇到不熟悉的方案，依然需要不断查资料、追问和验证。
只不过，相比最开始完全依赖AI给出结果，现在至少知道应该怎样提出要求、检查过程，以及判断最终效果。
我不一定需要亲自写出每一段代码，但必须知道自己究竟想做什么，以及怎样判断它有没有做好。
这可能就是这半年里，我在使用AI方面最大的变化。
折腾了半年，这套 CRM 现在做到哪一步了？
说了这么多，这套 CRM 现在究竟能不能用了？答案是可以。
经过这段时间的开发和完善，目前已经有了一套自己能够实际使用的CRM，部分日常联盟客开发和管理工作，也可以直接在系统中完成。
这对我来说，已经是一个实实在在的进展。
不过，自己能够使用，和正式开放给其他用户使用，仍然是两个不同的阶段。
现阶段，我可以按照自己的工作习惯使用系统，遇到不够完善的地方，也能够继续调整。
但如果未来要面向其他品牌方或者联盟营销从业者开放，就不能只考虑自己的需求。
不同用户可能有不同的开发流程、资源管理方式和操作习惯，系统也需要具备更好的稳定性和可维护性。
所以，这套CRM目前还没有正式对外上线。
至于未来希望把它做成什么样，我的想法其实没有太大变化。
还是希望围绕联盟客开发这件事，把资源发现、筛选评估、邮件建联、合作跟进和数据管理这些环节逐步整合起来。
当然，这些是整个产品的发展方向，并不意味着所有规划中的功能现在都已经完整实现。
我也没有打算把它包装成什么能够彻底改变联盟营销行业的产品。
市面上已经有不少成熟的联盟营销平台和管理工具，各自都有不同的定位和优势。
我想做的，只是从自己比较熟悉的业务出发，尝试把一些繁琐、重复的工作整合起来，让日常联盟客开发和管理变得更方便一些。
至于这套CRM未来究竟能够走多远，现在还不好说。
但至少对我来说，这半年最大的收获，或许不只是做出了一套自己能够使用的工具，而是开始尝试用一种以前没有想过的方式，去解决工作中遇到的问题。
以前遇到一些现有工具无法满足的需求，更多是寻找替代方案，或者调整自己的工作流程去适应工具。
现在则多了一种选择：能不能借助 AI，按照自己的实际需求，尝试把工具做出来？
当然，有了这种可能性，不代表事情就变得简单了。
真正动手以后才会发现，从想法到实际应用，仍然需要投入大量时间，也有很多需要学习的地方。
但至少，技术不再是让我一开始就放弃这个想法的理由。
对于联盟营销，我有自己的理解；对于软件开发，我依然只是一个不断摸索的新手。
而AI恰好让我有机会，把这两个原本不太相关的领域连接起来。
这套CRM还没有正式上线，距离我最初设想的样子，也还有一些需要完善的地方；但我会继续把它做下去。
毕竟，半年前的我，大概也不会想到，自己真的能够走到今天这一步。
而接下来会发生什么，或许也值得期待。
以上。