employee-motivation

name	employee-motivation
description	基于飞书数据资产（OKR、文档、周会表现，以及员工与 AI Agent 的交流内容）诊断员工的工作动机，采用麦克利兰成就动机理论（成就/亲和/权力）× 自我决定理论 SDT（自主/胜任/归属）双模型，输出细颗粒度、总分式、带证据链和支撑逻辑的诊断。支持员工自测与 Leader/HR 他评；当用户要求完整报告或沉淀结果时，同时生成文字总结、飞书云文档，并关联 Geometry Blue 画板。用户提到员工动机、动机诊断、什么在驱动他、如何激励、驱动力测评、该给他分什么活、团队缺什么类型的人时使用。每条结论都带飞书或 Agent 交流证据；行为不完全等于动机，结论为推断；不做性格标签、绩效打分或背对背画像。

员工动机诊断

基于员工在飞书上沉淀的真实工作资产，诊断「他被什么驱动、动机状态如何」，并按使用者视角给出对应建议。它不靠拍脑袋或单一问卷，而是用两个学术界公认的成熟动机模型做骨架，多维度、带证据链地推断。

面向任意岗位的员工，不限于工程团队。产出是发展性的：帮人更懂自己、帮管理者更懂成员，不给人贴标签、不打分。

首次使用请先读：两个模型在说什么（大白话版）

这枚 Skill 用两个模型叠加。别被名字吓到，本质很直白：

模型一 · 麦克利兰三需要 —— 判断「你被什么驱动」（方向）

• 成就：想把事做到最好、爱挑战难题。满足感来自「搞定一件难事」本身，不是钱或头衔。
• 亲和：想要好的关系和归属感。重视团队、协作、和同事的连接，孤立会让他没劲。
• 权力/影响：想影响别人、推动结果、有话语权。分「个人权力」（为控制而控制）和「组织权力」（为组织目标去影响），后者是好领导的底色。

模型二 · 自我决定理论 SDT —— 判断「你现在被满足了没」（状态）

• 自主：能不能自己决定怎么做、认同做事的理由（不是被逼）。
• 胜任：有没有「我有能力、在变强」的体验。
• 归属：有没有和人连接、被在意、属于团队的感觉。

两者怎么配合：麦氏告诉你「他朝哪个方向使劲」，SDT 告诉你「他这股劲现在顺不顺、被不被满足」。方向 × 状态，诊断才立体，而不是贴一个标签。

数据来源：以飞书工作资产为主

主要依据（工作产出，边界清晰）：OKR、员工文档、周会/会议表现，以及员工与 AI Agent 的交流内容（agent-agnostic——一个人和 AI 怎么对话，反映他关心什么、怎么思考和工作，是很好的动机信号）。

辅助信号：对话消息——仅作辅助，且在他评模式下必须对本人透明，绝不做背后扒消息下结论。

没有某类资产时，用现有的做诊断并标注证据不足，不硬凑。报告末尾的「证据覆盖」区会列出已读与未读的资产类型，缺口必须显性化。

Agent 交流证据：先判可及性，再采集

不同 Agent 的会话可及性差别极大：CLI 型 Agent 通常明文落盘可完整读取；桌面客户端 Agent 常把会话写进加密的 IndexedDB / LevelDB，取不到明文；企业版 Agent 一般需要通过平台的会话读取接口按 id 拉取。

只读到落盘的那一个，就会把「工具可及性」误当成「本人偏好」。 采集前必须先列出本人实际在用的 Agent 清单、逐个判定可及性，并用 context.agent_sources 声明本次覆盖与缺口。判定方法与偏差控制见 references/agent-evidence.md。

尤其注意一个高频误判：自发探索会话量暴涨，既可能是自主需求被满足，也可能是主线受阻后的精力转移。 两者外观相同，必须结合主线推进状态判断，并作为待确认问题交回本人。

两种模式与视角切换

模式	谁用	建议视角
员工自测（audience=self）	员工本人	站在员工视角：你的主导动机、当前满足状态、未来该争取什么机会、补哪一块
Leader/HR 他评（audience=manager）	直属管理者、HR	站在管理视角：该成员被什么驱动、该分什么活、怎么激励、团队缺哪种驱动、怎么补位

他评硬边界：只对自己直属成员、且过程对本人透明可复核，不做背对背分析。见 references/boundaries.md。

每条结论都要有支撑逻辑（核心特色）

诊断输出的每个维度，固定格式：

维度（如 成就需要）：倾向强/中/弱
  ├─ 支撑证据：来自哪个飞书资产的哪条具体行为
  ├─ 推断逻辑：为什么这条证据指向这个维度
  └─ 置信度 + 提示：行为推断，与本人认知可能有差

不给没有证据支撑的结论。行为不完全等于动机（写很多文档可能是成长驱动，也可能只是岗位要求），所以结论是推断，标注置信度，需本人确认或在 1:1 核实。

输出契约：短总览、长详情、具体到场景

用户要求完整诊断、报告、复盘或沉淀时，必须采用“总分式”文字结构，不能只给一段摘要：

1. 总：一句话判断 + 四行结论表，说明“被什么驱动 → 现在的状态 → 这意味着什么 → 所以该怎么办”。结论表只保留短判断和短证据锚点；每个结果尽量一句话，每行支撑论据不超过 2–3 条，完整观察句不得直接堆进表格。
2. 分：麦克利兰三需要和 SDT 三需求逐维度展开，每一维都写具体证据、推断逻辑、置信度、替代解释或不能由行为证明的部分。
3. 回到工作：说明什么真实工作场景会让当事人投入、什么场景会消耗，以及判断依据来自哪里。
4. 落行动：输出 3–5 条具体下一步，每条包含真实场景、动作、结果指标、时间锚点、决策/协作边界和复盘触发条件。
5. 收边界：列出证据窗口、已读取资产、未读取资产、权限缺口和需本人确认的问题。

文字风格：专业判断 + 人在场

完整报告默认采用“同事风格 + 咨询风格”的融合写法：

• 开头 2–4 句先给判断、关键证据和对当事人的意义；标题写“对象 + 判断”，不写空泛主题名。
• 每个详情小节按“判断 → 证据 → 推断 → 这意味着什么”展开。证据写具体项目、会议、文档和行为，避免只写形容词。
• 语气专业、克制、有温度。允许写“我判断”“我倾向于”“这里还不能确认”；减少机构腔、套话和术语堆叠。
• 结论表负责让人快速看懂，详情负责把证据讲透，行动负责把判断落到下一次真实工作。
• 段落短一些，长句承载细节，短句承载判断；每段只保留一个核心意思。

行动建议禁止停留在“提升影响力、加强沟通、主动协作、做好复盘”等抽象表达。每条行动必须挂到证据中的项目、会议、文档、客户流程或协作节点；证据不足时写“待补场景”，提出最小澄清问题，不编造项目、指标和期限。具体模板见 references/report-and-delivery.md。

跨 Agent 执行顺序

本 Skill 适用于任何能读取 SKILL.md、处理用户材料、执行本地脚本的 Agent，不依赖单一平台。平台侧元数据只负责发现与触发，核心流程以本文件与 AGENT-GUIDE.md 为准。

1. 确认模式与边界

确认是自测还是他评。他评时确认使用者是该成员的直接管理者、且成员知情。要对不归自己带的人做背后分析，停止并说明边界。

2. 收集飞书证据（只读、脱敏）

本人授权（自测）或对本人透明（他评）时，从飞书只读梳理证据，映射到六个维度。命令与信号对照见 references/feishu-evidence.md；Agent 交流部分的可及性判定与偏差控制见 references/agent-evidence.md。整理成脱敏输入（见 references/input-schema.md）。

signals 取值必须严格取自 schema 允许的九个值。写错会直接报错退出（退出码 3），不会被静默忽略——麦氏三需要没有 _low 变体，只有 SDT 三需求有。

3. 诊断

python3 scripts/diagnose.py --input tests/fixtures/case-achievement.json --audience self --format markdown
python3 scripts/diagnose.py --input tests/fixtures/case-achievement.json --audience manager --format markdown

不传 --audience 时读输入里的 context.audience，缺省为 self。--audience=manager 与 --audience manager 两种写法等价。

输出先给一张短结论表（三列：诊断维度 / 诊断结果 / 支撑论据；四行：{被什么驱动 → 现在的状态 → 这意味着什么 → 所以该怎么办}），把「驱动方向」和「满足状态」的关系用大白话讲通。表格中的支撑论据只写来源和短行为锚点；表格之后，再给每个维度的完整证据链（麦氏三需要 + SDT 三需求，各带完整支撑证据、推断逻辑、置信度、替代解释/需确认提示），再给场景化解释和 3–5 条具体下一步。完整结构见 references/report-and-delivery.md。

4. 团队构成诊断（可选）

python3 scripts/diagnose.py --team tests/fixtures/team.json --format markdown

汇总多名成员的驱动方向，看团队缺哪种驱动，给招聘/补位提示。只看分布，不对个人排优劣。

5. 落到行动

按诊断给出驱动对齐的授权与发展建议，见 references/driver-actions.md。优先从证据中选出 1–3 个真实场景，把建议改写成可执行动作；每条写明结果指标、时间锚点、决策边界和复盘触发条件。

6. 生成飞书云文档与 Geometry Blue 画板

当用户要求生成报告、沉淀结果或明确要求飞书云文档时，同时交付：

• 当前对话中的完整总分式文字总结；
• 一份包含完整证据链和具体下一步的飞书云文档；
• 默认规划 4 张由 geometry-board 产出的 Geometry Blue（蓝色波点）画板：开头 1 张总览，中段 2–3 张分别解释驱动、状态、场景或行动；用户只要摘要时可降为 1 张。
• 文档首屏顺序是硬约束：文档标题后立即插入总览画板，画板前不得出现说明段、引言、引用、相关链接、结论表或其他正文；总览画板之后再写开场判断与导航链接。
• 中段画板按主题分散插入：“驱动方向”“动机状态”“具体下一步”等对应段落之后各放一张，不把多张画板集中追加到文末。
• 画板内容采用经过真实飞书白板验证的蓝色—米色—深蓝参考版式：#375dfe 作为主蓝，#fdf0e0 作为底色，#1a2240 作为文字与边框，辅以白色信息块；使用大标题、强对比重点块、细边框、充足留白和短标签。总览优先使用左右分栏，证据类内容使用“维度｜行为证据｜判断”表格，状态与行动使用 3 张编号卡片。卡片文字与边缘线保持呼吸区，文字不贴边、不压线；底部文字与卡片内底至少保留约 24 px 视觉留白。
• 四张画板保持统一色彩、字体、线宽和留白规则，至少使用 3 种构图家族；每张只表达一个判断，文字保持短，完整证据留在正文。用户提供参考画板时，先读取并以参考画板的视觉系统覆盖默认样式。
• 文档开头或“相关链接”区写入 Skill 仓库、报告规范、画板 Skill 和各画板直达链接；链接写成飞书真实超链接，不只显示裸文本。

使用 lark-doc 创建或更新文档，使用本人 user 身份；首张总览画板必须插在文档标题之后、任何正文之前，中段画板插在对应主题段落之后。创建空白画板块后，记录 block_token，按 geometry-board 规则生成并检查 SVG/Scene JSON，再用 lark-cli whiteboard +update --input_format svg --as user 写入。写入后回读文档大纲、画板前后文本和画板资源，区分“已生成、已插入、已写入、已验证”。详细流程见 references/report-and-delivery.md。

飞书权限不足时保留文字总结和本地画板源文件，明确说明未完成的环节；不得切换 bot 身份绕过个人权限，也不得用静态截图冒充可编辑画板。

停止规则

• 要做背对背画像、性格标签、绩效打分或人员排序时，停止并说明边界。
• 证据不足时只给「假设 + 待核实」，不下定论。
• 读飞书前先确认身份与授权；消息类证据仅辅助且他评时必须透明。
• 只读到部分 Agent 的会话时，不把覆盖缺口当成本人偏好或投入差异；缺口写进 context.agent_sources。
• 遇到加密或二进制存储的会话，判定为不可及即止；不做解密尝试，不拿字节碎片或文件体积当证据。
• 结论用于发展性对话与授权，不进考核。