create-colleague

create-colleague skill 概览

create-colleague skill 是做什么的

create-colleague skill 的作用，是把真实同事留下的工作痕迹沉淀成可复用的 AI skill。它的核心并不是泛泛地写人物简介，而是提炼一个人如何工作、如何沟通、如何做判断，从文档、聊天记录、截图、邮件以及 Feishu、DingTalk 等工作平台中，还原出一个真正可用的协作型画像。

谁适合安装 create-colleague

如果你在做 Skill Authoring，希望在同事离职、转岗或交接之后，把关键工作方法和隐性经验保留下来，这个 create-colleague 很适合你。尤其当团队里的材料本来就分散在各种办公工具中，而你又不满足于“帮我写一个像这个人的 prompt”这种松散方式时，它的价值会更明显。

它和普通 prompt 的区别

普通 prompt 可以模仿语气，但 create-colleague skill 追求的是两类不同产物：一层是用于完成任务的 work skill，另一层是用于表达与沟通风格的 persona。仓库里还提供了 Feishu、DingTalk、email 以及文件输入等摄取路径，所以相比把零散片段手动粘进聊天窗口，它更接近一套可落地的工作流。

用户在安装前最关心什么

大多数人决定要不要上 create-colleague，通常会看四件事：你的源材料支不支持、安装是否绑定特定 agent 环境、首次生成之后能不能继续编辑、以及结果能不能持续演化。就这些点来说，create-colleague 在 Claude Code 风格的 skill 工作流里最完整，既支持自动采集，也支持手动整理，而且仓库明确设计了更新/演化流程，方便后续纠错和追加新材料。

最适合与不适合的使用场景

当你手里确实有一个人“怎么做事”的证据时，就该用 create-colleague：比如消息记录、文档、邮件、截图，或者比较完整的文字说明。反过来，如果你只是想做一个虚构 persona、一次性的轻量风格模仿，或者一个泛化的团队角色模板，那就不建议用它。这个 skill 做的是基于证据的提炼，不是凭空 roleplay。

如何使用 create-colleague skill

先把 create-colleague 安装到正确的 skill 目录

仓库给出的安装方式是 git clone，不是 npx。在 Claude Code 里，应当把它以 create-colleague 这个名字安装到项目级或全局 skills 目录下：

# project-local
mkdir -p .claude/skills
git clone https://github.com/titanwings/colleague-skill .claude/skills/create-colleague

# or global
git clone https://github.com/titanwings/colleague-skill ~/.claude/skills/create-colleague

如果是 OpenClaw：

git clone https://github.com/titanwings/colleague-skill ~/.openclaw/workspace/skills/create-colleague

这一步很关键，因为 skill 的触发方式和生成结果的输出路径，默认都依赖这个命名后的安装目录。

测试 collector 之前先装好依赖

实际的 create-colleague install 路径，取决于你打算接入哪些来源。基础要求是 Python 3.9+。如果想启用更完整的摄取能力，还需要安装一些可选依赖：

pip3 install pypinyin
pip3 install playwright
playwright install chromium
npm install -g feishu-mcp
pip3 install python-docx openpyxl

如果这些依赖不装，skill 仍然可以通过手动上传和文本输入工作，但部分自动采集和文件转换链路就不能用了。

用正确的触发方式启动 skill

在支持的 agent 环境中，调用方式是 /create-colleague。仓库里也写了自然语言触发方式，比如让它创建一个 colleague skill；此外还有更新类命令，如 /update-colleague {slug} 和 /list-colleagues。如果你的测试计划是“先装上再看看能不能正常唤起”，那第一步就应该验证这些触发行为是否生效。

搞清楚 create-colleague 需要什么输入

create-colleague 想生成高质量结果，最好同时提供两类输入：

1. 关于这个人的结构化基础信息
2. 这个人实际如何工作的证据

工作流通常会先收集姓名、角色、级别、公司背景、性格线索，以及你对这个人的主观印象。然后再摄取 Feishu 消息、DingTalk 文档、导出的 JSON、邮件、截图、PDF、markdown 或直接粘贴的文本等材料。如果你只给基本人设信息，不给工作痕迹，最后的输出通常会比较浅。

把模糊请求改成高质量的 create-colleague prompt

一个比较弱的请求是：“Make a skill for Alice.”

更强的 create-colleague usage prompt，通常会明确这些信息：

• 这个人是谁
• 他/她做的是什么工作
• 你手里有哪些材料
• 你希望生成的 skill 擅长什么
• 哪些来源的信号最强
• 哪些内容不应该被推断

例如：

/create-colleague

Name: Alice
Role: Staff backend engineer
Company context: B2B SaaS, billing platform
What I need: a skill that reproduces her incident response style, API review standards, and communication tone with PMs
Sources: 2 Feishu doc links, 1 exported message JSON, 6 screenshots of architecture notes, 3 handoff emails
Important: prioritize technical judgment and escalation habits over personality mimicry
Do not infer management style from jokes or casual chat

这种写法可以减少模型对表层语气的过拟合，也更有助于把 work/persona 两层能力拆开。

选择合适的采集路径

仓库提供了多条 source pipeline，而你选哪条，直接影响实施成本和可靠性：

• tools/feishu_auto_collector.py：有 Feishu app credentials 时最合适
• tools/feishu_browser.py：适合抓取需要浏览器登录才能访问的内部文档
• tools/feishu_mcp_client.py：通过 token 流程访问 Feishu 文档
• tools/dingtalk_auto_collector.py：DingTalk 采集路径
• tools/email_parser.py：处理 .eml 或 .mbox
• tools/feishu_parser.py：解析导出的 Feishu JSON

如果团队拿不到 app credentials，那么浏览器方案或手动文件方案，往往才是更现实的起步方式。

优先读这些文件

如果你想快速判断 create-colleague 是否适合自己，建议按这个顺序看：

1. SKILL.md：看触发逻辑、允许使用的工具和整体工作流
2. INSTALL.md：看实际环境怎么搭、依赖怎么选
3. README_EN.md：看支持哪些来源，以及面向用户的产品定位
4. docs/PRD.md：看目标输出模型和后续演化流程
5. prompts/：如果你准备改分析行为，再深入看这里

比起在 repo 目录树里随便翻，这条阅读路径更容易快速得到足够做安装决策的信息。

理解生成结果的输出结构

这个仓库在产品设计上，把输出拆成了三层：

• 一个 Work Skill
• 一个 Persona
• 一个可直接使用的合并版 SKILL.md 风格结果

这个拆分对落地很重要。如果你主要想保留“这个人怎么把工作做好”，那就可以弱化 persona 的影响；如果你更在意沟通还原度，就可以加强 persona 证据。相比一个混在一起的 prompt，这个 skill 更实用，因为它把能力和风格视为不同信号来处理。

预期 create-colleague 是一个迭代过程

更合适的 create-colleague guide 心态，是把第一次运行当成草稿生成。仓库支持“evolution mode”：你可以在复核后继续追加文件、修正错误推断、细化行为定义。对于真实工作场景里的同事建模来说，这比一开始就试图写出一个完美的一次性 prompt 更靠谱。

能明显提升输出质量的实用建议

高信号输入通常包括：

• 以决策为主的对话，而不只是社交闲聊
• 明确写出标准、取舍或 review 意见的文档
• 覆盖多个任务的样本，而不是单一孤例
• 你明确补充的“这个人绝不会这么做”的纠偏说明

低信号输入通常包括：

• 只有截图、没有上下文
• 只有夸赞性的描述
• 只有正式文档、没有体现决策风格的证据
• 多个人的材料混在一起却没有标注

输出会写到哪里，以及这为什么重要

安装文档提到，在偏 Claude Code 的使用方式下，生成的 colleague skills 默认会写到 ./colleagues/ 下面。这是一个很实际的问题：正式推广前，你需要先决定这些生成物应该放在 repo 里、团队共享工作区里，还是某个个人环境里。很多团队低估了生成型 skill 的后续维护成本。

create-colleague skill 常见问题

create-colleague 适合 Skill Authoring 新手吗？

适合，前提是你已经能安装基于 repo 的 skill，并且能准备好源材料。整个流程是有引导的，但它不是一个一键式的消费级应用。如果你对数据来源怎么选、以及如何批判性审阅生成结果有基本把握，效果会明显更好。

create-colleague 比普通 prompt 更好吗？

多数情况下是的，尤其当你的真实需求是保留某位同事的工作模式，而不只是模仿他说话口吻。它的额外价值来自结构化 intake、现成的 collectors、work/persona 拆分生成，以及明确的更新路径。如果你的需求只是“用更直接的风格来写”，那普通 prompt 可能已经够用了。

哪些源材料效果最好？

最理想的是带任务上下文的材料组合：围绕决策的消息串、review comments、内部文档、流程说明、交接邮件，以及体现取舍 reasoning 的样例。如果你希望生成出来的 skill 在工作上也站得住，仅有 personality 相关材料是不够的。

create-colleague 必须依赖 Feishu 或 DingTalk 吗？

不需要。它们是重要的采集选项，但不是硬性前提。你也可以使用 PDFs、markdown、截图、邮件、粘贴文本以及导出文件。这意味着 create-colleague 不局限于纯 Feishu 工作流，在其他环境里同样可用。

什么情况下不该安装 create-colleague？

如果你要的只是一个简单风格预设、一个虚构角色，或者想靠很少的证据就获得对某个人“高度准确”的模拟，那就不建议选 create-colleague。另外，如果你的环境跑不起来所需的 skill tooling，或者数据访问模型本身不允许导出/采集必要材料，也应当直接跳过。

生成后的 colleague 可以继续更新吗？

可以。仓库明确支持继续追加文件、修正错误推断，并对已生成的 colleague 做持续演化。这也是很多人更愿意选 create-colleague、而不是静态手写 prompt 的关键原因之一。

如何改进 create-colleague skill

给 create-colleague 提供证据，而不只是形容词

想让 create-colleague 结果更好，最快的办法是把“很严谨”“说话有点冲”这种标签，换成可验证的证据：

• 他/她反复出现的 review comments
• 什么样的工作会被接受，什么样会被打回
• 展现其默认结构化方式的文档
• 事故处理中实际发过的 escalation 消息
• 不确定时常用的表达方式

证据越具体，生成出来的 work skill 就越可执行，persona 也越不容易变成夸张 caricature。

把技能信号和人格信号分开

很多用户会把“这个人懂什么”和“这个人说话怎么说”混在一起。更好的做法是显式标注：

• work inputs：specs、code review notes、runbooks、architecture comments
• persona inputs：聊天语气、冲突风格、幽默感、表达异议的方式

这样更容易让 skill 保持 work/persona 的区分，而不是最后只产出一个模糊的模仿品。

标注来源可靠性

不同输入不应该被一视同仁。你可以主动告诉 skill，哪些材料是权威来源、哪些更新、哪些噪声大。比如：

• “These review comments reflect current standards”
• “These 2022 chats are outdated”
• “This screenshot is second-hand and may be inaccurate”

这样能减少错误推断，也有助于 create-colleague 优先采用更可靠的证据。

用具体补丁去修正第一版草稿

当第一版输出不对时，不要只说“感觉不太像”。更有效的修正方式应该像这样：

• “He prefers rollback first, not hotfix-in-place”
• “She is concise with peers but much more explanatory with junior engineers”
• “Do not make him sound sarcastic in formal docs”
• “Her strongest skill is requirements clarification, not system design”

这种具体补丁，比笼统的不满更容易合并进下一版。

如果要自定义行为，就去看 prompt 文件

如果你准备改 create-colleague 对证据的分析方式或合并逻辑，prompts/ 目录值得重点读。像 intake.md、work_analyzer.md、persona_analyzer.md、work_builder.md、persona_builder.md、merger.md、correction_handler.md 这些文件，基本决定了输出质量是怎么被塑造出来的。如果你觉得默认的 work/persona 权重不适合自己的场景，就应该先从这里看起。

注意这些常见失败模式

create-colleague 最常见的质量风险包括：

• 过度抓语气，却没有真正构建工作能力
• 在材料稀少或偏差很大的情况下推断过多
• 把多个同事混成一个 profile
• 把旧材料当成当前行为
• 把公司流程误认成个人风格

这些不是抽象的 AI 问题，而是生成出来的 colleague 为什么会显得假、或者在实际使用中不够有帮助的直接原因。

通过收窄目标任务来改进 create-colleague

如果你的第一次结果显得太宽、太散，那就先把目标收窄。可以先让它生成一个只针对某个领域优化的 colleague skill，比如 incident response、architecture review、customer escalation，或者和 PM 沟通。相比一开始就想完整复刻一个人，先做一个范围更小的版本，通常更真实，也更有用。

团队推广前先建立 review loop

如果这个生成出的 skill 要给别人一起用，那最好让一个真正和原同事深度合作过的人来 review。重点确认：

• 这个 skill 明确应该做什么
• 它绝不能声称自己会什么
• 哪些场景必须升级处理
• 它的沟通风格是否准确到足以实用

在真实团队环境里，这是改进 create-colleague for Skill Authoring 最稳妥的方法之一。

让安装路径和维护方式可持续

如果想让 create-colleague 长期可用，就要尽早统一三件事：生成出来的 colleagues 放在哪里、更新怎么做版本管理、团队官方支持哪些可选 collectors。一个只能在某位维护者笔记本上跑通的 skill，可信度远不如安装和更新政策都清晰的方案。

提升 create-colleague usage 的最简单原则

如果只记一条实用规则：少给一些材料，但要给更高质量、标注清楚的材料，然后用有针对性的纠错去迭代。这是提升生成结果质量、也最能改善整体 create-colleague usage 体验的高杠杆做法。