岗位助手（数字员工）设计评估 · 2026-08-10

本文回答一个问题：这套"岗位助手"设计对不对、给谁用、怎么用、能帮企业到什么程度。

依据：代码静态结构 + 真实运行冒烟 + 前端/配置核实（非空想）。

一句话结论

内核成立，但当前是"监测型后台机器人"而非"对话型岗位助手"。 已验证能发现真实业务问题（5.2万条PPS质量问题、48.5万补货），但价值大多停在"发现+报告"，闭环（发现→建单→跟踪关闭）只接通了 7/61。设计要成立，必须补齐闭环与人在环，否则只是多了 61 个仪表盘。

六个问题逐条回答

1. 设计对吗？

方向对，定位有裂缝。

• 对的：把"角色"绑定到"后端业务系统(PLM/ERP/QMS)上的自主代理"这件事，是制造型企业真实痛点（跨系统巡检、数据质量、库存风险），不是伪需求。
• 裂缝：产品叫"岗位助手"(暗示增强人、被人驱动)，实现却是"定时后台监测 bot"(自主跑、产出报告)。隐喻与机制不匹配——用户会困惑"这到底是我招的助理，还是装在服务器上的定时任务？"

2. 这样的岗位助手，用户是啥？

两类，且当前第二类在实际上驱动系统：

• (a) 业务角色人员：工艺员、质量工程师、库管、设备员 —— 通过 DigitalStaff / AiWorkbench 对话触发，或被动接收巡检结论。
• (b) 企业数字化/IT 部门：作为运维方配置员工、看 cron、查结果卡。
• 现实：因为对话侧 LLM 默认关、MTClaw 没启，现在主要是 (b) 在跑，业务人员侧体验是休眠的。

3. 谁来使用？

• 触发方式 = cron 定时自主(44个) + 关键词路由对话(按需)，缺"事件驱动"(如"新NCR建好→自动跑根因分析")。
• 谁用 = 上述业务人员(被动收结果/主动问) + IT(配置监管)。目前 IT 主导。

4. 怎么使用？

打开 DigitalStaff.vue / AiWorkbench.vue → 自然语言提问(例："库存会不会缺料") → staff-router 关键词路由到员工 → 读 SCSAI/SCSAI/PPS 库 → 返回 StaffResultCard 或自动建单(NCR/CAPA)。另有 44 个员工按 cron 自动跑(每2h/每日)。

5. 能达成什么目的？

把分散在 PLM/ERP/QMS 的"数据异常、库存风险、质量偏差"自动发现并初步处置，削减人工巡检与跨系统核对成本。已证实能发现真实问题。

6. 能帮到企业吗？

能，但前提是补闭环。 只停在"发现+报告"≈高级仪表盘，价值有限；只有"发现→建单→跟踪关闭"跑通，才真正替代/增强人力，才算帮到企业。

三个真正的风险

1. 定位模糊（最大风险）：助手 vs 后台bot 没定清楚，导致"谁对结果负责、谁来处理 5.2万条问题"悬空。
2. 开环为主：54/61 员工只读不写；发现 5.2万问题却无驱动关闭的抓手 = 报告工厂。
3. 粒度虚胖：61 个员工更像"10 个数据源的 61 个薄包装"，关键词路由已出现误命中(如"修复"→供应商而非维修员工)。深度 > 广度。

把"助手"做实的 3 步建议

1. 定清楚定位：选一条主线(建议"质量/库存/设备异常的自动发现+建单")，把 5~8 个员工做到闭环，其余先降权为"只读监测"。
2. 补闭环：inspect/process-data/stock 这类"只读员工"的结论，自动转成 NCR/CAPA/补货建议单并落入待办，配人在环审批闸门(写动作必须留痕+可驳回)。
3. 启对话侧：把 LLM/MTClaw 打开并接好，让业务人员能"问一句"就触发对应员工，否则 DigitalStaff.vue 只是个空壳入口。

当前落地状态（与设计的差距）