从一个真实的陪练场景说起

假设你是一家电销团队的管理者。新人入职第三天，你希望他能熟悉公司的话术，应对客户的各种异议。传统做法是让资深员工扮演客户，但资深员工有自己的业绩要扛，不可能随时陪练。如果把新人直接推上线，第一通电话可能就是一次客户投诉的起点。

在这个项目里，我们设计了这样一个场景：新人在工作台里选择一个名为“电销教练”的系统助理，设定“客户是犹豫型决策者，对价格敏感”的陪练场景，然后开始一场多轮模拟对话。AI扮演客户，新人扮演销售，每一轮对话都在检验他的话术是否合格。对话结束后，系统生成一份陪练报告，指出他在“价格异议处理”环节的薄弱表现，并给出改进建议。

这就是「AI数字员工」项目想要解决的核心问题：用一套可配置、可计费、可管理的AI工作台，替代企业在客服、电销、法务咨询、会议整理、新人陪练等岗位上重复性脑力劳动的投入。

问题定义：中小企业缺的不是AI，是“岗位化”的AI

过去两年，大模型的能力已经覆盖了大量文本处理场景，但中小企业真正需要的不是又一个聊天机器人，而是一个能“上岗”的数字员工。这个“上岗”包含三层含义：

第一，角色要可编排。 不同岗位需要不同的系统提示词、不同的开场白、不同的交互方式。一个法务顾问和一名电销教练，表面上都是对话，但底层的角色设定、话术策略、评估维度完全不同。

第二，消耗要可计量。 企业使用AI服务最怕的就是不可控的成本。项目引入“算力”作为统一计量单位，每一轮对话、每一次深度推理、每一场陪练，都对应明确的算力消耗，用户可以实时看到每次交互的花费。

第三，配置要可管理。 平台超管可以在管理后台调整功能单价、管理系统助理、配置Banner——这些在MVP阶段看似运营侧的功能，实际上决定了产品能否从一个演示工具演变为可运营的商业系统。

项目的产品目标在这时变得清晰：建设一个面向中小企业的AI数字员工SaaS，以统一工作台承载多类AI能力，用算力统一计量扣费，支持系统级助理与自定义助理的灵活编排。

用户画像与核心场景

MVP阶段的用户角色并不复杂，但边界必须分明。

个人用户是当前的核心使用者。他们的诉求是快速使用AI能力、看清消耗，工作台需要提供场景助理、AI对话、会议纪要、AI陪练、算力中心等能力的统一入口。这类用户的行为路径非常典型：登录工作台 → 查看算力余额 → 选择一个系统助理或自定义助理 → 开始对话或陪练 → 查看消耗与产出。

平台超管则是运营侧的关键角色。他们需要管理系统助理的上下架、配置功能单价、查看用户数据。没有超管后台，这个产品就无法回答“AI服务的成本如何覆盖”这个商业问题。

企业成员和企业管理员被规划在二期，届时将引入企业算力池和成员管理。做这个取舍的原因很直接：MVP阶段的首要任务是验证“角色编排 + 计费闭环”的核心逻辑是否成立。 如果个人用户无法在真实场景中感受到数字员工的价值，企业级的多租户能力即便建好了，也无从谈起。

角色编排：系统助理与自定义助理的互补逻辑

AI数字员工工作台中的“场景助理”模块，是整篇故事的枢纽。这个模块设计了两种助理形态：

系统助理是平台预置的标准化角色。通用助理、电销教练、法务顾问、客服专家等，它们的价值在于“开箱即用”的确定性。平台超管可以在管理后台配置这些助理的名称、图标、开场白和系统提示词，确保企业用户无需任何配置就能上手使用。对于大部分中小企业来说，这是他们接触AI数字员工的第一站。

自定义助理则是用户根据自身业务场景创建的弹性角色。用户可以自行定义名称、图标、开场白和系统提示词，从而把AI塑造成自己需要的角色。这种形态的价值在于“按需使用”的灵活性。一个做跨境电商的团队，可以创建一名“海外客服专家”，输入包含产品知识和售后政策的中英文混合提示词；一家律所可以创建“合同审查助理”，把常用的审查要点写入系统提示词。

这两种助理形态并非简单的功能叠加，而是一种角色编排的互补逻辑：系统助理保证质量的下限——即使是最普通的用户，也能获得一个经过验证的AI角色；自定义助理放开能力的上限——用户可以在系统设定的骨架之上，生长出适合自己业务的专属数字员工。

在数据模型层面，助理的字段设计准确支撑了这一逻辑：scope字段区分系统与用户、enabled字段支持软删除、sort控制展示顺序、greeting定义首次交互的体验。这种设计让后台管理系统助理、前台创建自定义助理成为可能，而不会被代码逻辑绑死。

关键能力如何支撑整个项目

在角色编排之上，项目的业务闭环还需要三块能力支撑：对话、会议纪要与AI陪练。

AI对话是整个工作台的基础能力。多轮上下文保证了对话的连贯性，深度推理开关让用户在“更快更便宜”与“更强更贵”之间自主选择。每一次助手回复都会展示消耗的算力值，这种透明化设计直接服务于用户对AI成本的信任建立。

会议纪要则把AI对话的文本能力延伸到了音视频场景。用户上传文件或提供文本提示后，系统输出转写全文、摘要、章节、待办、关键词甚至脑图。在MVP阶段，会议纪要以文件名作为输入锚点，后续可以扩展为更完整的会议管理闭环。

AI陪练是最能体现“数字员工”价值的功能。它不仅仅是对话，更是一个具备评估体系的训练系统。用户可以自定义陪练场景，AI模拟客户或用户进行多轮交互，结束时生成分析报告。这套机制让“新人培训”这种高成本、低效率的线下场景，第一次有了可量化、可回溯的线上替代方案。

这三块能力共同回答了“系统助理和自定义助理被创建之后，用来做什么”的问题。对话验证角色、纪要沉淀知识、陪练提升技能，三者在业务逻辑上形成闭环，而非功能的孤立堆叠。

技术实现与交付实践

本项目由郑州界外共行科技有限公司负责研发与交付。这是一家扎根郑州研发中心的软件外包与定制开发企业，具备 Java、PHP、Go、Vue 等主流技术栈的综合研发能力，核心成员来自一线互联网企业和专业交付团队。在“AI数字员工”项目中，他们承担了从需求分析、架构设计到开发实施与持续交付的全链路工作。

在技术路线上，项目明确了底层模型可插拔的架构原则——默认使用 DeepSeek，但可以切换其他 LLM。这一决策直接服务于成本控制和供应链安全：如果某家模型的服务价格波动或质量下降，平台可以在不改变上层业务逻辑的情况下切换模型。在 MVP 阶段，项目采用前后端分离的架构，PC 工作台与管理后台独立部署，既可静态演示，也可对接真实 API 进入正式运营状态。

郑州界外共行科技有限公司在项目落地中的关键贡献，是把 PRD 中“可计费、可配置、可管理”的目标转化为了实际可运行的代码逻辑。以计费闭环为例，MVP 阶段实现了消耗明细、长任务预扣、结算与失败退回等机制；以管理后台为例，套餐、功能单价、系统助理、Banner 等运营配置均可在后台动态调整。这些看似基础的能力，恰恰是 SaaS 产品从“能用”走向“可运营”的必经之路。

落地路径、风险与价值总结

从落地路径看，项目首先完成了一个关键动作：用可交互预览来验证产品逻辑。登录 → 充值（模拟）→ 助理对话 → 会议纪要 → 陪练报告 → 后台改价，这条演示链路覆盖了从用户端到管理端的完整业务流，并能生成可分享的预览链接。这种方式让产品在没有后端 API 的情况下，也能向潜在客户和合作方展示产品形态，极大降低了早期验证成本。

当前项目需要正视的风险主要有三方面：

第一，算力定价的合理性。 默认单价为 chat.message 每千 token 1 算力、chat.reason 每千 token 3 算力，这个价格是否与用户感知价值匹配，需要真实用户数据的验证。

第二，陪练报告的质量边界。 AI 陪练的分析报告如果泛泛而谈，用户的改进动机就会快速衰减；如果过于严苛，又可能打击使用者的信心。MVP 阶段需要在“有用”和“可用”之间找到平衡。

第三，自定义助理的上手门槛。 对于非技术背景的用户，编写有效的系统提示词本身就是一个挑战。后续产品迭代中，可能需要提供提示词模板库或引导式创建流程来降低门槛。

回到文章开头的电销新人场景。当这位新人通过“电销教练”完成了十场模拟陪练，系统记录下他的每一次进步，管理者可以看到他在“异议处理”维度的明显提升——这个瞬间，就是 AI 数字员工项目价值的真实证明。

从项目定位来看，系统助理与自定义助理的角色编排，是 AI 数字员工工作台的核心骨架；AI 陪练则是让这个骨架拥有“肌肉记忆”的关键功能。 前者解决的是“AI 能扮演什么角色”，后者解决的是“AI 如何帮人变得更好”。二者的结合，让这个项目不只是一个工具集，而是一套可以支撑企业数字化转型的 AI 人力基础设施。

下一步迭代的方向已经明确：接入企业成员体系与企业算力池，让数字员工从个人助手升级为组织能力；扩展会议室纪要的输入形态，从文件上传走向实时转写；丰富陪练报告的分析维度，从文本评估走向多维度能力模型。每一步迭代，都会让 AI 数字员工离“员工”这个称呼更近一步。