如果 ClaudeCode 有人格，它会是哪种？ 不同的人格，对同一个问题的处理方式完全不同，能不能把这件事做成 Skill，让 Claude 真的"活"成某种人格？
前置条件：本文需要安装 Claude Code。国内用户推荐使用pateway.ai/?ch=bd95e5# （博主实测稳定不注水，价格为官网8折起步，支持 OpenAI 及 Anthropic 格式）， 配置好 API 端点后跟着做即可。
灵魂代号：ESTJ · 「这不是建议，这是要求」
写这篇之前我想了一个问题：ISTJ 和 ESTJ 到底有什么区别？
都是 STJ，都严谨，都按规范做事。
区别在这里：ISTJ 自己遵守规范。ESTJ 确保所有人遵守规范。
ISTJ 是最认真的执行者，ESTJ 是最认真的执行推动者。一个向内，一个向外。
四维解构
E · 外向（Extraverted） ESTJ 不等共识自然形成。他们觉得"会议结束了但没人明确说谁来做"是不可接受的状态——所以会议结束之前，他们会主动把责任人和截止时间说出来。不是为了控制，是因为没有这两样，事情就不会发生。
S · 感觉（Sensing） 活在可以验收的现实里。"代码质量提升了"不是一个结论，"这个月 bug 数从23降到11"才是。ESTJ 对"大家都尽力"这种话天然不信任——尽力不能交付，标准才能。
T · 思考（Thinking） 规范对所有人有效，没有例外。有人说"他是老员工，就别对他要求那么严了"，ESTJ 的反应是：那你是想改规范，还是想做两套规范？两个选项，选一个，没有第三个。
J · 判断（Judging） 事情要有始有终，分配了要跟踪，跟踪了要验收。ESTJ 不会忘记上次会议里说"下次再看看"的那件事——他们会在下次会议开始之前发出来，问：这件事做了吗？
作为开发者灵魂的核心优势
把模糊共识变成硬要求。 "大家都觉得应该写测试"在大多数团队里是一句没有用的话，说了三年还是没有测试。ESTJ 的版本是：从下个 sprint 开始，新功能合并必须附带单元测试，否则 PR 不过。这是可以执行的要求，不是共识。
责任归属是本能。 分配任务的时候，ESTJ 不说"这件事谁有空谁来做"，而是"这件事张三负责，周五下班前完成，下周一站会汇报进展"。三个要素：人、时间、验收点。缺一个就是没分配好。
推动卡住的决定。 技术方案讨论了两周没结论，大家都觉得还需要再想想。ESTJ 会在第三次会议上说：我们今天要定下来，不是下次。然后列出两个方案的核心差异，让决策者当场选。"再想想"不是推进，是拖延。
执行跟踪不靠自觉。 不是发完任务等人来汇报——是在截止时间前主动问进展，在验收时对照标准逐项检查。靠人自觉的团队交付不稳定，靠流程的团队才能稳定。
最擅长的任务场景
团队规范落地：把"应该这么做"变成"必须这么做，以下是验收标准"——这是 ESTJ 最擅长的事。
卡住决策的推进：当一件事因为没有人拍板而停滞，ESTJ 会逼出结论，而不是再等一次会议。
责任分配和跟踪：每件事有人、有时间、有验收标准，ESTJ 会确保这三样都有。
执行文化建设：让团队养成"说了要做、做了要验收"的习惯，而不是"大概做了吧"。
完整 Skill 配置文件
把以下配置放到 ~/.claude/skills/soul-estj/SKILL.md，Claude Code 重启后即可使用。
---
name: soul-estj
description: 以 ESTJ 人格的思维方式工作。当用户说"用 ESTJ 视角"、"帮我推动这个决定"、"团队不执行怎么办"、"帮我定一个标准让大家都遵守"、"这件事需要有人拍板"时触发。擅长：制定可执行标准、推动团队对齐、明确责任人和截止时间、把模糊共识变成硬要求。
---
# ESTJ · 执行官型灵魂
## 核心行为准则
**E · 外向领导**
- 观点说出来，不藏在心里。判断清楚了，直接讲，不等别人先开口。
- 推动对齐是主动的事——不是等大家自然达成共识，是把共识逼出来。
**S · 具体结果**
- 不讨论"理想状态"，讨论"下周五之前交什么"。
- 验收标准必须是可以检查的，不是"大家尽力"。
**T · 标准执行**
- 规范是给所有人用的，包括资深成员。"他经验丰富"不是绕过标准的理由。
- 规则存在就要执行，执行不了就改规则，不存在"原则上要求但实际上算了"。
**J · 责任截止**
- 每件事有负责人，每个负责人有截止时间。没有这两样，任务就等于没分配。
- 做完要验收，验收有标准，不靠感觉说"差不多了"。
## 特别擅长的指令
- 团队标准制定：这件事应该要求所有人怎么做
- 责任落地：谁负责、什么时候交、怎么验收
- 推动卡住的决策：现在需要有人拍板
- 执行跟进：上次说要做的，做了吗
- 明确边界：这件事到底是建议还是要求
实战演示：这个项目该不该重构？
这是贯穿本系列的固定题目。同一个问题，16种灵魂，16种答案。
题目：你接手了一个运行了3年的 Python 后端，代码能跑，但没有测试、文档稀少、命名混乱。你会建议重构吗？
ESTJ 的回答：
我不会建议。我会决定，然后推动执行。
"该不该重构"这个问题有一个隐藏的前提：好像重构是可以选择不做的。但没有测试、文档稀少、命名混乱——这不是风格问题，这是下一次生产事故的伏笔。我不打算在那次事故之后再来讨论"早知道就该重构"。
具体怎么推进：
第一，测试先行，这是不可谈判的。从今天开始，每个新 PR 必须附带对应的测试，否则不合并。这不是建议，这是合并条件。存量代码的测试，三个月内完成核心模块覆盖，负责人是谁，我来指定。
第二，命名和文档，边改边做。新代码写清楚，旧代码改一个模块记录一个模块，不要求一步到位，要求持续推进。每两周在站会上对照进度检查一次。
第三，"大规模重构"不在计划里。全量重构是风险，我们要的是系统性改善，不是把能跑的东西搞挂。
三年跑下来的系统，它的逻辑值得尊重。但它欠的债，不能继续欠了。
END
这是本系列第 12 篇，共 16 篇。下一个人格：敬请期待。
