组织架构设计原则

解决什么问题

组织架构设计往往卡在“影响因素多、模式选择难、步骤不清晰”这三个层面：

• 影响因素复杂：业务战略、规模阶段、技术栈、文化基因交织，难以快速锁定核心约束；
• 模式选择模糊：职能型、矩阵型、事业部型各有适用场景，缺乏可对比的判断框架；
• 步骤落地断层：从现状分析到变革执行，中间缺少可复核的中间产物和异常值检查机制。

技能如何工作

核心能力围绕“信息提取→结构化检查→可复核输出”展开，具体包括：

• 自然语言解析：直接从用户原话或上传文件中提取组织架构设计相关事实，仅追问完成任务的最少必要项；
• 字段口径校验：检查时间范围、重复值、异常值，生成可复核的明细表（如“设计步骤”中的阶段划分是否符合逻辑）；
• 判断依据分离：将事实、参数、假设、待确认项分开呈现，避免“看似精确但无法溯源”的结论；
• 结构化脚本支持：需要确定性计算时，将已确认信息写入内部临时JSON，调用 python scripts/run.py --input --output 生成中间产物（不展示给用户）。

关键步骤分为四步：

1. 提取已确认事实：从用户输入中识别业务目标、现有架构、关键约束等，不要求填写内部JSON或员工编号；
2. 检查字段与异常：验证时间范围（如“近3年组织调整记录”）、重复值（如重复出现的岗位名称），输出异常清单；
3. 分离呈现逻辑：将事实（如“部门A去年新增3个岗位”）、参数（如“设计步骤假设为5步”）、判断依据（如“基于行业基准模型”）、待确认项（如“是否考虑海外分部”）分开展示；
4. 生成可交付成果：先在对话中给出结论和关键明细，再按任务生成Markdown、CSV、XLSX等结构化文件，支持直接下载使用。

适用边界与注意点

• 不涉及外部数据核验：若涉及行业基准或政策原文，会标明来源、样本时间和适用范围，无法核验时明确标注假设和待确认项；
• 不声称已执行操作：不宣称已发送、申报、审批或写入业务系统，除非宿主工具实际执行并回读结果；
• 输入不足时诚实反馈：当用户材料缺失关键信息（如“现有架构图纸”），输出待补充清单，而非用模糊表述替代未知事实。