我如何借助 AI 辅助编程让客服工作台完成跨平台蜕变

我是一个独立开发者，过去几年，我持续投入时间开发和维护升讯威在线客服与营销系统。从服务端、通信架构，到客服工作台、管理后台，再到各种业务功能，产品的每一个重要模块都凝聚着大量时间和精力。

我一直相信，好的软件产品需要长期打磨，也需要不断拥抱新技术。当 AI 成为开发者的得力助手，一个人的技术团队，也能释放出更大的创造力。

最近，我完成了一项期待已久的工作：将原有的 Windows 客服工作台升级为基于 .NET MAUI Blazor Hybrid 的新一代跨平台客户端。

它不仅能够运行在 Windows 上，也为 macOS 平台提供了支持。这次升级让我感触最深的，并不仅仅是 Blazor Hybrid 技术本身，而是 AI 辅助编程所带来的效率变化。

我将在本文中，分享我使用 AI 辅助编程的一些心得和收获。

背景

前几年好几次圈子里的朋友问我，有没有考虑过 MAUI 或者 Avalonia 重构一下客服工作台，能跨平台。我当时的态度斩钉截铁，不考虑。

我当时觉得专职客服的工作应该都是用 windows 平台，不太会大规模装备 mac，另一方面我是独立开发，如果用 MAUI 或者 Avalonia 把客服工作台重写一遍（原先是 WPF），这工作量很大。而同样的时间和精力，我去围绕稳定性、安全性、功能性开展工作，获得的回报更多，对我的用户价值也更高。

而且原有客户端已经积累了大量成熟的业务功能，包括实时通信、会话管理、客户信息、消息处理、文件传输、各种交互组件，以及大量与服务端配合的业务逻辑。要将这样一套成熟的软件迁移到新的技术架构，需要考虑的问题非常多：

如何重新规划客户端的整体架构。
如何复用已有的业务逻辑。
如何实现跨平台的窗口、文件和系统交互。
如何重新构建大量 UI 组件，同时保持原有业务行为。
如何处理不同操作系统之间的兼容性差异。
如何保证升级后的产品仍然稳定可靠。

这些问题，作为一个独立开发者来说，要全部解决，向用户提供企业级的产品，没有一年半载我都不敢想。

但是最近 2 年，经常有人问我客服工作台能不能支持 Mac、有没有 Mac 版本的开发计划。特别是前几个月，因为我没有实现对 Mac 版客服工作台的支持，错失了一个很可能是大客户的合作机会！这个客户在行业内有一定影响力，真的是连客服在内全都用 Mac 来办公（也许是老板喜欢 Mac？）。

当我站在 2026 年再次回顾这些问题的时候，我有了一个非常重要的帮手：AI。

AI 对我来说，不只是代码生成器

这次开发过程中，毫不讳言，我大量使用 AI 辅助完成代码编写和代码重构。在实际开发中，AI 协助我编写了大量代码。遇到技术问题时，我也不再需要完全依赖搜索引擎，在大量文档和技术讨论中反复寻找答案。

AI 非常明显的放大了个人开发者的能力边界和工作效率。过去许多年，我一个人需要在需求分析、架构设计、代码实现、UI 设计、测试排错和技术调研之间不断切换。

现在，AI 可以承担其中大量辅助性工作，让我能够同时推进更多事情。客观来说 AI 没有消除软件工程的复杂性，却大大降低了它的复杂性的成本。

AI 没有替我开发升讯威客服系统，但它让我有能力以更高的效率，完成原本需要投入更多时间和精力才能完成的工作。

如何让 AI 理解复杂业务需求

使用 AI 辅助编程，最容易犯的错误就是直接告诉 AI：「帮我实现一个 XXX 功能」。

对于简单功能，这种方式可能有效；但对于成熟软件中的复杂业务需求，往往会得到一个看似完整、实际上与现有架构不兼容的实现。

我的经验是：先让 AI 理解问题，再让 AI 编写代码。例如，在开发客服工作台中的客户信息面板时，我不会直接要求 AI 生成一个 Razor 组件，而是先提供现有组件结构、数据模型和交互要求，让它分析实现方案。

一个相对有效的提示词可以是：

复制代码

当前项目基于 .NET 10 MAUI Blazor Hybrid。

请先阅读以下相关代码，理解现有组件结构和业务逻辑。

本次需求：
1. 在客户信息区域增加访客扩展数据。
2. 保留原有客户资料展示逻辑。
3. 不要修改现有数据模型。
4. 组件应当保持独立，避免将业务逻辑放入父页面。

请先分析：
- 涉及哪些现有组件？
- 是否需要修改组件参数？
- 数据应该如何传递？
- 是否存在潜在的生命周期问题？

暂时不要生成代码，先给出实现方案。

这种方式能够让 AI 在编写代码之前先建立正确的上下文。尤其是在大型项目中，需求分析和实现方案往往比代码生成本身更加重要。

给 AI 设定明确的工程边界

AI 有一个特点：它倾向于给出自己认为合理的通用解决方案，但这些方案未必符合当前项目的技术规范。

例如，一个项目可能已经使用 Newtonsoft.Json，如果没有明确说明，AI 就可能在新代码中引入 System.Text.Json。又或者项目已经有自己的弹窗服务，AI 却重新设计一套弹窗管理机制。随着开发规模扩大，很容易造成代码风格混乱和架构不一致。

因此我会在开发任务开始之前，明确告诉 AI 当前项目的技术约束。

例如：

复制代码

项目开发约束：

1. 使用 .NET 10。
2. 使用 MAUI Blazor Hybrid。
3. UI 使用 Razor + CSS。
4. JSON 操作优先使用 Newtonsoft.Json。
5. 尽量沿用现有项目架构，不随意引入新的设计模式。
6. 不要为了简单功能引入不必要的 NuGet 依赖。
7. 优先考虑简单、直接、容易维护的实现。
8. 修改代码时尽量保持现有公共接口不变。

如果某项需求与上述约束冲突，请先指出，不要自行改变技术路线。

这是在给 AI 建立一个项目级的开发规范。对于长期维护的软件项目而言，这一点非常重要。AI 应该成为现有工程体系中的协作成员。

不要一次性让 AI 重写整个模块

AI 能够一次生成大量代码，但这并不意味着应该一次性让它完成所有工作。在实际开发中，我更倾向于采用小步迭代的方式。

例如，一个复杂的客服会话页面，可以拆分成：

创建基础页面布局。
实现会话列表。
实现消息展示区域。
实现客户信息面板。
实现左右分栏拖动。
实现弹窗交互。
处理异步状态更新。
优化整体样式和交互细节。

每完成一个阶段，就进行一次编译和运行验证。

这种方式有两个好处：

问题容易定位，不会在大量代码中寻找错误来源。
AI 能够根据上一阶段的实际结果继续工作，而不是始终建立在未经验证的假设上。

例如：

复制代码

上一阶段已经完成基础布局，并且编译运行正常。

现在只实现左右分栏拖动功能。

要求：
1. 左右面板宽度可以通过鼠标拖动调整。
2. 拖动过程中左侧面板不得小于 220px。
3. 右侧面板至少保留 50px 的空间。
4. 鼠标移出拖动区域后仍然能够继续拖动。
5. 不修改现有页面布局结构。

请只修改实现此功能所需的文件。

这比一句「帮我完善整个工作台」更加有效。把复杂任务拆解成可验证的小任务，是提高 AI 编程可靠性的关键。

让 AI 阅读现有代码，而不是凭空猜测

在成熟项目中，很多实现细节并不会体现在需求文档里。例如，一个弹窗可能已经有统一的生命周期管理机制；一个组件可能已经通过事件回调与父组件通信；一个服务可能已经封装了异常处理。

如果 AI 不知道这些情况，就很容易生成重复实现。因此，我越来越重视让 AI 直接阅读现有代码。

例如：

复制代码

以下是项目现有的弹窗组件和调用方式。

请仔细分析：
1. 当前弹窗的显示与关闭机制。
2. 组件生命周期如何管理。
3. 是否支持重复调用。
4. 是否存在并发调用问题。

现在需要增加一个新的业务弹窗。

请尽量沿用现有机制，不要重新设计一套弹窗框架。

这里有一个非常重要的原则：AI 应该优先适应项目，而不是让项目适应 AI。

对于已经运行多年的商业软件，历史代码中往往沉淀了大量业务经验。能够正确理解并延续这些经验，比生成一份漂亮的新代码更有价值。

对我来说，AI 辅助 = 新的开始

过去，我的开发效率很大程度上取决于自己能够投入多少时间；现在，我的开发效率还取决于能否把问题准确地交给 AI，能否有效地组织人机协作，以及能否快速验证 AI 给出的结果。编程能力并没有变得不重要，恰恰相反，工程经验越丰富，越能发挥 AI 的价值。

从一个想法，到一套成熟的在线客服系统，再到如今的跨平台客户端，这个过程让我更加确信：独立开发并不意味着只能做小而简单的产品。在合适的技术架构、持续的工程积累，以及 AI 辅助的帮助下，一个开发者同样可以完成相当复杂的工程项目。

有人说中年程序员通过 AI 获得了事业的第二春，我是赞同这个说法的，AI 是程序员新的时代红利，独立开发者的想象空间正在变得越来越大。

AI 辅助开发之下的全新客服工作台

说了这么多，疗效如何呢，看看 AI 加成之下的工作成果：

For Windows

For Mac

如果您感兴趣：

升讯威客服系统仍处于不断演进的过程中。

如果您曾经构建或部署过实时聊天系统，我非常期待与您交流心得。

🌐 官方网站：https://kf.shengxunwei.com
📘 技术文档：https://docs.shengxunwei.com

无论您倾向于使用托管版还是自行部署（Self-hosting），都可以免费试用。