岗位方案展示
海纳同舟 AI 落地执行方案
单部门试点推进路径
单部门试点 / 环境统一 / Skill 沉淀 / 逐步复制
本方案以单部门试点为起点，通过 2 人 AI 先锋队、统一工作环境、项目沉淀和首个 Skill 试跑，逐步推动员工在 AI 时代完成工作方式转型，让 AI 承接重复、繁琐、可标准化的工作，把人的精力释放到更高价值的判断、协同与业务增长上。
执行摘要
方案重点不在于工具演示，而在于围绕真实业务场景，建立试点机制、执行标准与复制路径。
推进范围
1 个部门先试点
推进路径
先锋队 → Skill → 复盘 → 复制
目标结果
形成组织级方法沉淀
试点必要性
先控制范围、先验证效果、先沉淀方法，再考虑跨部门复制。
先锋队机制
每个部门先抽 2 个人，负责提供真实任务、试用 Skill、反馈问题。
Skill 落地
先梳理工作，再选 1 个高频低风险场景，先跑通 1 个 Skill，并同步沉淀到项目库。
评估标准
重点评估使用率、效率、质量、稳定性与可复制性。
核心问题
目标不是让团队知道 AI，而是让首个部门先把 AI 用进真实工作流，并形成稳定复用。
启动方式
先确定试点部门，再组建 2 人 AI 先锋队，统一远程连接 Linux 服务器并拉取 GitLab 项目，先跑通 1 个 Skill。
最终沉淀
将试点结果沉淀为使用标准、Skill 模板、SOP 和跨部门复制方法。
试点原因
首轮推进不建议直接全公司铺开，而应先以小范围、可验证、可复制的方式完成单部门试点。
建议优先采用单部门试点，主要基于以下 4 点：
- 范围更小，组织阻力和沟通成本更可控。
- 更容易拿到真实成果，而不是停留在演示阶段。
- 更容易先沉淀出 Skill、SOP 和审核规则。
- 一旦跑顺，后续复制到其他部门会更有说服力。
推进原则
- 先小范围跑通
- 先用真实任务验证
- 先证明能稳定复用
- 再做跨部门复制
试点目标不是快速铺开，而是先把第一个部门打造成可复用的样板，再进入复制阶段。
试点部门选择
不是哪个部门声音大就先做哪个部门，而是先选最容易出效果、最容易标准化的部门。
部门筛选标准
- 工作高频、重复，日常执行密度高。
- 输入输出相对明确，容易做成模板。
- 风险相对可控，适合先由 AI 产出初稿。
- 部门负责人愿意配合，能提供真实任务样本。
- 结果容易量化，能看出节省时间和减少返工。
优先试点：私域运营部
这类任务重复度高、结构清晰，也最容易先做出一个能复用的 Skill。
优先试点：运营部
准备动作多、整理动作多，适合先从效率提升最明显的环节切入。
第二阶段可扩展
筛选逻辑
- 先看能否跑通
- 再看是否值得复制
- 不是先追求覆盖面最大
AI 先锋队机制
每个试点部门先抽 2 个人，不要求一开始就成为专家，但必须熟悉流程、愿意试、愿意反馈。
谁适合成为 AI 先锋队
- 熟悉本部门真实工作流程。
- 愿意尝试新方法，也愿意持续反馈。
- 能提供真实任务素材，而不是只做演示。
- 后续能带动同事一起复制使用。
2 人 AI 先锋队的职责
他们负责什么
- 提供高频任务样本和历史素材。
- 参与试用第一个 Skill，并记录使用体验。
- 反馈哪些结果稳定，哪些地方还不适合推广。
平台侧职责
- 搭建 Claude Code 的使用环境和服务标准。
- 把任务梳理成可执行的 Skill 模板。
- 组织试跑、复盘、优化和后续复制。
平台搭建方式
平台搭建的目标，不只是提供一个工具入口，而是建立一套能够让员工真正用起来的使用标准。
01 使用环境
- 统一使用 1 台 Linux 服务器。
- AI 先锋队成员通过远程方式接入。
- 账号、目录和访问边界提前配置好。
02 GitLab 项目
- 各部门按 project 管理。
- 从 GitLab 拉取对应部门仓库。
- Skill、SOP、样例文档统一沉淀。
03 使用标准
- 什么任务适合进 Claude Code
- 什么任务不能直接交给 AI
- 输出结果如何审核
04 反馈机制
- 每周收集试用问题
- 持续优化 Skill 结构
- 决定是否进入复制阶段
平台搭建逻辑
- 统一 Linux 服务器，能减少每个人本地环境不一致的问题。
- 统一远程接入，便于权限控制、经验复用和后续支持。
- 统一从 GitLab 拉取 project，便于版本管理和部门资产沉淀。
预期形成的工作方式
- 员工进入服务器后，直接进入自己部门对应的 project。
- project 内统一维护 Skill、提示词、SOP 和示例文档。
- 试点跑通后，不是口头传播，而是直接复制项目结构到下一个部门。
先把 Linux 服务器、远程接入和 GitLab 项目结构搭好，Claude Code 才能从个人尝试变成部门可复用的工作平台。
工具选型原则
工具选型的重点，不是只选一个工具或一个模型，而是先确定主平台，再为不同任务保留合适的补充能力。
| 维度 | Claude Code | Cursor | GPT 模型 |
|---|---|---|---|
| 主要定位 | 项目级工作平台 | 个人开发提效工具 | 通用补充模型 |
| 更适合的场景 | 多文件、终端、项目级任务 | 局部修改、补全、编辑器交互 | 脑暴、表达优化、快速问答 |
| 在本方案中的角色 | 主平台 | 补充工具 | 补充模型 |
主平台选择
- Claude Code 更适合进入真实工作流，而不是停留在局部补全。
- 更适合统一工作环境、项目结构和部门级沉淀。
- 更适合承载 Skill、SOP、流程文档和试点复制。
补充能力定位
- Cursor 适合研发成员在 IDE 内进行个人提效。
- GPT 适合开放式脑暴、表达优化和第二视角校验。
- 补充能力用于提升效率，不替代主平台沉淀。
选型结论
- 工具层以 Claude Code 为主平台，Cursor 作为补充。
- 模型层以 Claude 为主力，GPT 作为补充与交叉校验。
- 不同任务匹配不同能力，但平台入口保持统一。
工具选择的关键不在于“哪一个最火”，而在于“哪一个最适合成为组织的主平台”。
预算与采购建议
预算安排建议遵循“先满足试点最小闭环，再根据效果逐步扩容”的原则。
建议优先采购项
- 1 台用于试点的 Linux 云服务器。
- 试点部门 2 个 Claude 账号席位。
- 平台管理员 1 个管理与搭建席位。
- GitLab、SSH、目录模板和文档模板同步准备。
不建议一开始就大量采购
- 不建议全员一次性开通。
- 不建议先买很多工具再找场景。
- 不建议先追求大而全的平台建设。
- 先把一个部门的真实闭环跑通更重要。
采购判断逻辑
- 先满足试点最小可用。
- 再根据使用率和效果扩席位。
- 先让投入与结果一一对应。
账号采购建议
试点阶段
- 按人头开通，谁参与试点谁有自己的账号。
- 不建议多人共用一个 Claude 账号。
- 先覆盖：AI 项目负责人 + 2 位 AI 先锋队成员。
扩大阶段
- 如果第二个部门加入，再按新增成员补席位。
- 如果公司准备长期推进，再评估 Team / Enterprise 采购方式。
- 采购节奏跟着试点复制节奏走，不盲目超前采购。
投入说明
- 这不是一次性铺全公司的成本，而是一个部门试点的最小投入。
- 买的是可验证的试点能力，不是概念性预算。
- 只要第一个 Skill 跑通，后续扩部门时复用率会越来越高。
- 如果试点没跑通，就先优化方法，不急着继续扩投入。
采购安排应保持克制：先满足试点必需条件，先让结果跑出来，再决定是否继续扩席位、扩部门、扩投入。
权限设计
很多公司不是死在工具不好用，而是死在权限没先设计好。真正要先定义的，是谁能看什么、谁能改什么。
角色定义原则
1. AI 平台管理员
- 对应角色：AI 项目负责人或平台管理员。
- 负责 Linux 服务器、GitLab 项目、目录结构和成员开通。
- 可以看所有内容，也可以调整权限和项目结构。
2. 部门能力负责人
- 对应角色：部门 AI 先锋队负责人、技术负责人或业务负责人。
- 负责本部门 Skill、SOP、模板和项目内容维护。
- 可以修改本部门核心内容，但不能改全公司权限规则。
3. 部门共创成员
- 对应角色：参与试点的员工、开发、运营、分析人员。
- 可以使用本部门 project，提交任务素材、案例和反馈。
- 能协作完善业务内容，但不能直接改核心 Skill 标准。
4. 公司观察成员
- 对应角色：管理层、其他部门负责人、普通查看者。
- 主要看成果、案例、文档和可复制经验。
- 默认只读，不直接参与项目修改。
角色命名说明
- 这家公司推进 AI 的核心不是研发协作，而是跨部门落地和方法沉淀。
- 如果直接讲 Admin、Maintainer、Developer、Reporter，管理层未必立刻能理解职责边界。
- 建议先用业务能听懂的角色定义，再映射到底层系统权限。
skills 区
- 只允许 AI 平台管理员和部门能力负责人修改。
- 部门共创成员可以提建议，但不直接改正式版本。
- 原因：Skill 是部门能力资产，必须稳定、可控。
products / projects 区
- 项目成员和先锋队成员可以访问。
- 允许共创成员补充素材、案例、任务结果。
- 部门能力负责人负责最终整理和合并。
docs 区
- 全员可读，方便跨部门理解和复制。
- 正式文档由平台管理员或部门能力负责人维护。
- 案例和 FAQ 可以逐步开放共建。
关键权限规则
- 默认先给读权限，再逐步放写权限。
- Skill 的写权限必须比文档更收敛。
- 跨部门可复制的内容尽量开放读，不开放核心修改。
- 权限设计先于推广，否则很容易在第二阶段失控。
底层系统映射
- AI 平台管理员 ≈ GitLab / 服务器最高管理权限。
- 部门能力负责人 ≈ 本部门 project 的维护者权限。
- 部门共创成员 ≈ 本部门 project 的协作权限。
- 公司观察成员 ≈ 文档与成果区只读权限。
权限设计不是技术细节，而是组织落地的前置条件。先把“谁能看、谁能改”讲清楚，AI 试点才能扩到第二个部门而不失控。
资源架构
为保证试点能够稳定复制，需提前统一项目结构、资源分层与模板规范，但正文仅保留面向面试官阅读所需的核心架构。
部门项目结构
- 每个试点部门统一包含 skills、docs、products、examples 四类内容。
- skills 用于沉淀正式 Skill、边界说明与输入输出样例。
- docs 用于沉淀 SOP、FAQ、上手说明与培训材料。
平台资源分层
- 平台层保留共享模板、公共文档与统一规范。
- 部门层保留本部门 project、Skill、案例与业务素材。
- 权限按管理员、部门负责人、共创成员、观察成员分层管理。
模板化复制方式
- 首个部门跑通后，可直接复制目录模板与基础文档到第二个部门。
- 复制的不是零散经验，而是统一结构、统一模板与统一边界。
- 这样能够降低后续扩部门时的沟通和管理成本。
统一结构的价值
- 员工接入后不需要重新理解目录逻辑。
- GitLab、服务器目录与文档模板能够一一对应。
- 后续跨部门复制时可以直接复用，而不依赖个人记忆。
面向试点阶段的保留原则
- 方案正文保留架构原则，不展开过深的目录实现细节。
- 技术实现细节可在进入实操阶段后补充到内部文档。
- 面试材料优先体现判断逻辑与复制能力，而非展示过多技术树状结构。
附录A：试点支撑环境（概要）
为保证试点顺利启动，需提前完成服务器、账号、目录、GitLab 与基础安全配置。本附录仅保留面向方案层的概要要求。
环境基础
- 准备 1 台稳定可用的 Linux 服务器，作为试点统一工作环境。
- 完成基础安全加固、管理员账号配置与必要端口控制。
- 统一 shell、终端工具、公共目录与基础运行环境。
访问与权限
- 为试点成员分配独立账号或独立工作目录。
- 明确共享目录、本部门目录与只读区域的访问边界。
- 在正式试跑前完成首次接入验证。
项目与模板
- 在 GitLab 建立部门 project 结构，并与服务器目录一一对应。
- 提前准备 Skill 模板、SOP 模板、示例输入输出与 onboarding 文档。
- 确保试点启动时已有最小可用内容可直接调用。
环境就绪清单
- 服务器可稳定登录，管理员账号可正常维护公共目录。
- 试点成员可顺利连接并进入本部门 project 目录。
- GitLab 项目可正常 clone、pull 与更新。
- 模板、Skill、SOP 与 onboarding 文档已放置到位。
环境建设原则
- 支撑环境的重点不在于技术复杂度，而在于稳定、可控、可复用。
- 先完成统一环境，再开展试点试跑，避免成员在接入阶段流失信心。
- 先把目录、权限与模板建立清楚，再推动跨部门复制。
支撑环境的目标不是技术展示，而是保证试点成员能够稳定接入、稳定试跑、稳定复盘。
附录B：试点启动保障（概要）
为降低首次试点风险，需在启动当天围绕接入、试跑、反馈和文档更新建立最小保障动作。本附录保留方案层面的关键安排。
启动前确认
- 确认服务器、账号、目录与 GitLab 全部可用。
- 确认试点成员具备稳定接入条件。
- 确认首个 Skill、SOP 与示例材料已经到位。
当日试跑
- 仅选择 1 个真实场景启动试跑，不同步扩展多个场景。
- 围绕真实任务完成首轮输入、输出与人工审核闭环。
- 优先保证完整跑通，而非追求一次性最优结果。
当日反馈
- 记录接入、使用、输出与审核过程中的关键卡点。
- 当天收集首轮反馈，避免只依赖事后回忆。
- 优先修正文档、入口和流程上的明显问题。
当日收尾
- 更新 SOP、onboarding 文档与问题清单。
- 确认第二轮试跑是否继续沿用同一场景。
- 在首轮稳定前，不急于扩人或扩场景。
启动保障的观察重点
- 试点成员能否独立接入并进入本部门 project。
- 成员是否清楚 Skill、文档与案例的位置。
- 首轮输出是否能够顺利进入人工审核。
- 现场是否已经形成可迭代的优化意见。
启动保障原则
- 第一轮启动优先追求稳定，而不是追求惊艳效果。
- 第一天体验会直接影响后续持续使用意愿。
- 问题应在当天进入文档与复盘，而不是停留在口头说明。
试点启动保障的核心不是把第一天做得复杂，而是把第一次接入、第一次试跑与第一次复盘稳定跑通。
风险应急预案
真正能落地的方案，不只是有流程和工具，还要提前想好出问题时怎么处理。很多公司不是死在不会做，而是死在出问题后没人知道下一步怎么办。
服务器连不上
- 先确认云平台状态、IP、端口和安全组。
- 保留管理员兜底登录方式，避免全部依赖单一入口。
- 共享目录和项目目录定期备份，避免环境问题影响资产。
GitLab 拉不下来
- 先检查 SSH key、仓库权限和网络连通性。
- 准备最小可用的本地模板目录，确保当天试点不中断。
- 问题恢复后再把当天产出回写到 GitLab。
先锋队不会用
- 不追加大培训，先回到 onboarding 和示例任务。
- 优先修文档和入口说明，而不是怪员工不懂。
- 先保证他们能完成第一个任务，再逐步扩复杂度。
Skill 输出不稳定
- 先缩小适用范围，不急着扩场景。
- 补充输入样例、边界说明和人工审核规则。
- 先让 Skill 回到辅助初稿角色，不直接承担关键判断。
员工抗拒或使用意愿下降
- 先回到最减负、最见效的小场景。
- 用真实节省时间的数据说话，而不是继续讲概念。
- 先让先锋队跑出案例，再用案例带动其他同事。
应急原则
- 先保试点不中断，再追求问题彻底解决。
- 先保部门资产不丢，再处理环境细节。
- 先缩范围、降复杂度，不在问题没解决前继续扩人扩场景。
- 所有问题都要回写到 GitLab 文档，而不是只停留在口头说明。
重点兜底项
- 管理员兜底账号与备用登录方式。
- 最小可用模板目录和示例 Skill。
- 服务器目录与 GitLab 项目的定期备份。
- 上线当天问题记录表与责任人分工。
应急预案的意义不是证明会出问题，而是保证问题出现时，试点不会当场停掉，团队也不会失去信心。
工作梳理方法
工作梳理的重点，不是先写提示词再找场景，而是先把真实工作拆清楚，再决定首个 Skill 的范围。
工作拆解维度
- 高频重复：是不是经常做，而且很耗时间。
- 输入输出明确：资料和结果是不是相对固定。
- 低风险：AI 先出初稿是否可控。
- 可量化：是否能统计节省时间、减少返工。
梳理产出
梳理完成后，至少会有 3 个输出
- 部门日常工作清单。
- 候选 AI 场景优先级列表。
- GitLab 中该部门 project 的初始目录结构。
梳理原则
- 先梳理工作，再定场景。
- 先定场景，再写 Skill。
- 避免为了展示 AI 而硬找场景。
首个 Skill 设计
第一阶段建议每个部门先跑通 1 个 Skill，因为先跑通一个，比一开始做很多个更重要。
一个 Skill 必须定义清楚的 5 件事
- 它解决什么问题。
- 输入是什么，资料怎么给。
- 输出是什么，格式怎么统一。
- 人工审核点在哪里。
- 适用边界是什么，哪些情况不能直接用。
试点示例：私域运营活动复盘 Skill
优先选择这一类 Skill 的原因
- 活动复盘高频发生，而且每次都需要整理信息。
- 输入材料相对固定，适合做标准化结构。
- 结果容易比较，能直观看到效率提升。
Skill 定义方式
- 输入：活动数据、群聊记录、用户反馈、执行记录。
- 输出：标准复盘纪要、问题清单、优化建议。
- 审核：核心判断与结论由人工确认。
- 沉淀：把 Skill 说明、示例输入输出和 SOP 一起提交到 GitLab 项目。
试点推进阶段安排
考虑到环境搭建、权限配置、业务对接、场景梳理和试跑优化都需要时间，首个部门试点更适合按阶段推进，并以 8 周作为首轮验证周期。
阶段一：试点准备
- 时间建议：第 1-2 周。
- 确认试点部门、负责人和推进目标。
- 完成初步业务对接，了解主要工作流和候选场景。
- 同步试点范围、职责分工和配合方式。
阶段二：环境就绪
- 时间建议：第 3-4 周。
- 完成 Linux 服务器、账号、目录和权限配置。
- 完成 GitLab 项目结构、模板和基础文档准备。
- 确定 2 人 AI 先锋队并完成首次接入测试。
阶段三：Skill 试跑
- 时间建议：第 5-6 周。
- 进一步梳理真实任务，确认首个高频低风险场景。
- 编写第一个 Skill、使用 SOP 和审核规则。
- 准备示例输入输出和 onboarding 材料。
阶段四：复盘复制
- 时间建议：第 7-8 周。
- 由 AI 先锋队在真实任务中试跑。
- 记录效率、质量、稳定性和使用反馈。
- 复盘后决定是继续优化，还是复制到第二个场景 / 第二个部门。
为什么采用阶段式安排
- 前期不仅要定场景，还要完成业务对接和部门协同。
- 环境搭建、权限配置和首次接入验证本身就需要独立时间。
- 第一个 Skill 需要在真实任务中反复修正，不适合压缩得过短。
阶段安排的重点
- 先把准备工作做扎实，再进入试跑阶段。
- 把环境搭建和业务梳理分开，避免前期节奏过满。
- 把试跑和复盘留出足够空间，保证结论更可信。
复盘与复制
是否继续推广，不看讲得多好，而看这个试点能不能形成稳定结果。
使用率
- 先锋队是否真的在持续使用
- 是否愿意继续扩大到类似任务
效率
- 单项任务耗时是否下降
- 资料整理和初稿输出是否更快
质量
- 输出结构是否更稳定清晰
- 返工是否减少
可复制性
- Skill 能否复用到同类任务
- SOP 能否交给更多岗位采用
试点沉淀成果
组织层面
- 统一的 Claude Code 使用标准。
- 一套可复用的 Skill 模板和审核规则。
部门层面
- 真实案例、SOP 和培训样例。
- 一套可以复制到第二个部门的试点方法。
判断标准
- 如果 4 项指标未达预期，应继续优化 Skill，而不是盲目扩大范围。
方案总结
本方案的核心，不是把 AI 作为单点工具分发给员工，而是通过试点机制，把 AI 纳入真实工作流，并逐步沉淀为可复制的组织能力。
方案核心结论
- 从 1 个部门开始，而不是一开始全员铺开。
- 每个试点部门先抽 2 个人组成 AI 先锋队。
- 先统一 Linux 服务器、GitLab 项目和权限规则。
- 先梳理工作，再只跑通 1 个 Skill。
- 先复盘结果，再决定是否复制到更多部门。
预期形成的组织能力
- 形成统一的 AI 使用标准与审核边界。
- 形成可复用的 Skill 模板、SOP 和案例资产。
- 形成可扩展到更多部门的试点推进路径。
- 推动 AI 从工具尝试逐步走向组织能力建设。
最终效果
试点的最终目的，不只是完成一个部门的效率优化，而是逐步推动员工在 AI 时代完成工作方式转型：把重复、繁琐、可标准化的任务更多交给 AI，把人的时间释放到判断、创意、协同、经营和增长上。
对员工
从执行型劳动转向更高价值工作
对组织
把 AI 能力沉淀为可复制的生产体系
对业务
在降本增效之外，把业务增量与增长空间做大