CHENGWAY.WANG在 2 号人事部，查假期、看工资条、发起审批等员工服务原本就存在，但分布在不同模块和小程序里。员工找不到入口，或不熟悉操作，最后仍要问 HR。
我发起并负责 AI 员工助手，希望用自然语言把这些已有能力交付给员工，同时探索企业愿意为什么样的 AI 服务付费。
项目概览
| 项目项 | 说明 |
|---|---|
| 所属产品 | 2 号人事部，企业级 HR SaaS |
| 服务对象 | 员工使用；HR 配置、维护与管理 |
| 我的角色 | 项目发起人、产品负责人 |
| 我的工作 | 场景判断、版本规划、产品与交互方案、高保真设计、研发协同推进、上线配套与复盘 |
| 交付范围 | V1.0 至 V3.1 四个版本均已上线，覆盖企业知识问答、个人数据查询、审批预填和员工服务统一入口 |
方案与交付由我和前后端、测试共同推进。以下界面均为项目设计稿，展示的是虚拟示例数据。
1. 从员工和 HR 两侧定义问题
对员工来说，问题通常很具体：“我还剩几天年假？”“工资条在哪？”“我要请假。”他们不关心这些需求属于哪个模块，也不应该先学会系统结构才能办事。
HR 面对的则是另一组问题：重复咨询不断打断工作；制度更新后需要维护回答口径；不同员工能看什么、哪些业务能开放，都必须可控。
因此，我把产品拆成两个相互配合的部分：
- 员工侧尽量简单，能直接获得答案，或进入明确的办理页面。
- HR 侧提供知识维护、范围配置、效果验证和用量管理。
对公司而言，这也是一条独立的 AI 增值服务探索线。产品除了能用，还需要有清楚的服务边界、计量方式和收费依据。
2. 先打基础，再沿两条路线扩展
V1.0 先解决制度、流程和手册类问答；V2.0 接入假期、考勤、排班等个人数据，并能给出审批入口。在此基础上，后续并行推进两个方向：
- 办理深度： V3.0 在原生审批页中帮助员工预填信息，同时补上独立小程序、语音输入和快捷操作。
- 服务广度： V3.1 整合已有员工服务，让工资条、档案、合同、培训等需求都能从同一入口触达。
两条路线共享同一套基础和业务系统，服务整合并不依赖审批自动填表。
3. 知识问答先解决维护、权限和验证
企业制度问答需要遵守企业自己的内容和权限。仅仅上传文档、接上模型，还不足以交付给员工。
方案把文档库和问答库分开：制度、手册通过文档上传；常见问题可以单独维护，也可以批量导入。知识库设置可见范围后，里面的内容自动继承，避免员工问到不属于自己权限内的信息。
HR 在内容旁边就能预览问答，不必先退出配置、再去员工端验证。这部分预览不扣点，也不进入总体使用统计，避免把配置测试混进真实使用。
我还区分了“没有权限”和“知识库没有答案”两种情况，分别给出引导。来源展示由 HR 配置；没有命中的问题可以在统计里筛出，继续补充内容。这样，知识库在上线后仍有维护和改进路径。
个人数据查询，重点是准确和好读
V2.0 的个人数据来自已有业务系统，沿用原来的用户身份和数据权限。模型负责理解问题与提取查询条件，结果按约定格式呈现，避免让模型重新发挥数字和业务结论。
我也没有把查询结果一律铺成逐日长表。以考勤为例：短周期给汇总和每日明细；较长周期突出异常日期；超过一个月则给汇总和原页面入口。排班同样区分短期明细与长期日历查看。
“余额为 0”“考勤正常”“未排班”“没有记录”也分别处理。它们对应不同的业务含义，不能统一回答成“没查到”。
4. 审批预填：让 AI 帮忙，但保留员工的确认权
V2.0 已经能找到审批表单，但跳转之后，员工仍要逐项填写。V3.0 将这一步纳入 AI 辅助范围：从对话理解审批诉求，进入原生审批页后，再识别并预填字段。
我把它限定为“先帮你填”，最终仍由员工检查、修改和提交，沿用原有审批流程。
这条链路里，几个细节比“能自动填”本身更重要：
- 识别和填充期间暂时锁定表单编辑，避免系统写入与人工输入互相覆盖，但允许员工返回或退出。
- 填充完成后恢复编辑，并高亮 AI 填过的字段；员工修改后，高亮消失，方便区分 AI 预填与人工修订。
- 只填无歧义信息。选项无法完全匹配就不填，不让模型猜企业的请假类型或业务选项。
- 超过 5 秒没有返回就结束 AI 填充，恢复普通表单；识别失败也不阻断员工继续办事。
我也为预填单独设计了衡量口径：记录进入审批次数、提交次数、AI 填充字段数，以及用户最终保留未修改的字段数，用来判断预填有没有被真正采纳。
5. 扩覆盖时，优先接入已有服务
审批预填适合深入解决某一条业务链路，但员工的其他需求不必都走同样的建设方式。
V3.1 优先复用现有服务页面：员工表达诉求后，助手返回简短说明和明确的服务按钮，点击后进入对应页面。工资条、合同、培训等功能不必全部重做成对话内执行。
服务清单沿用原有业务分类，覆盖服务、子功能、常见表达与跳转目标。身份和业务资格的最终校验仍由目标页面负责，自然语言入口不是新的权限捷径。
对高频操作，我也保留了快捷按钮。员工已经知道要打卡，就可以直接点，不必为了使用 AI 而多说一句话。
员工侧简化，企业侧保留管理权
统一入口还需要兼容不同企业的配置。总开关和服务范围沿用原有逻辑，保留 V2.0 已有查询项，再扩展新服务，不重置客户原来的设置。
配置项使用“我的档案”“我的面试”等稳定的服务名称，而不是“跳转档案”这类实现名称。即使以后从跳转升级为直接查询，企业也不需要重新理解和配置同一个服务。
快捷操作区最多展示 4 个入口，支持选择、删除和拖拽排序。企业个性化头像、名称与开场白单独配置；轻量职场陪伴也有独立开关，并明确不提供心理诊断等高风险专业建议。
6. 收费只对应真正提供的服务
作为企业付费增值服务，AI 员工助手按企业权益点数计量。计费规则要解决一个信任问题：企业只为 AI 真正提供的服务付费，配置测试、拦截和异常不该和成功服务混在一起算。
查到假期余额为 0，仍是一次有效查询；而功能未开启、身份不适用、没有记录或系统异常，则不应扣费。HR 在后台预览问答也不计入用量，避免把企业自己的配置测试算进账单。
这些规则与后台统计口径一致，企业能看懂每次扣费对应什么服务。机制本身可解释，但能否形成持续付费和复购，还需要经营数据验证。
7. 把新能力的触达一起纳入交付
服务接入完成，不代表员工知道能用。V3.1 的上线配套中，我将升级说明、体验入口和内容更新一起纳入方案：
- 在 PC 和移动端用 Banner、开场白说明新增能力。
- 提供预置问题和输入示例，让员工知道可以怎么问。
- 在 HR 后台和 PC 员工端提供小程序二维码，衔接配置体验与实际使用。
- 同步更新系统内置手册和问答，让助手对“自己能做什么”的介绍跟上版本。
其中一个容易被忽略的规则是：更新默认开场白时，只处理未修改过旧默认内容的企业，不覆盖客户已经写好的文案。企业已有的配置投入，也属于升级需要保护的产品资产。
产品规则、页面状态和运营配套放在同一交付范围，研发、测试与运营围绕同一套规则推进。
8. 上线复盘：用真实需求检验产品方向
版本上线后，我结合实际提问记录和已有访问路径，继续检查员工的诉求是否被完整承接。除了回答有没有命中，我也关注员工如何找到助手，以及拿到答案或入口后，能否继续办理。
复盘中，请假入口出现了重复使用；员工也会主动询问工资条等已有业务。这些需求提示我，助手的覆盖范围需要与员工对“人事服务”的整体认知对齐，而不能只按已经接好的查询接口定义。
这些观察进一步支持了独立入口、扩大服务覆盖和产品内引导的方向。服务接入、常见问法、按钮承接和企业配置放在一起考虑，员工表达的需求能直接跳到对应页面去办。
这也使后续验证的重点更明确：从员工找到入口开始，持续观察服务触达、业务办理和再次使用，而不只看一次对话的表现。
9. 这个项目留给我的产品判断
最初我主要按能力递进组织产品：先回答制度，再查个人数据，再帮助填写审批。真实使用提醒我，员工首先要找得到服务，知道它能做什么，才能走到能力验证那一步。
我的产品与设计工作在这里是连在一起的：先判断哪些问题直接回答、哪些交回业务页面，再把权限、字段核对、失败处理和上线引导落实到方案与界面中，并和研发、测试推进落地。
如果继续推进，我会优先跟踪从服务意图、按钮点击到最终办结的完整链路，再看重复使用和人工咨询变化。对企业服务中的 AI，是否真的让员工少绕一次路、少填一些内容，比一次回答看上去有多聪明更值得验证。