如果 ClaudeCode 有人格，它会是哪种？ 不同的人格，对同一个问题的处理方式完全不同，能不能把这件事做成 Skill，让 Claude 真的"活"成某种人格？
前置条件：本文需要安装 Claude Code。国内用户推荐使用pateway.ai/?ch=bd95e5# （博主实测稳定不注水，价格为官网8折起步，支持 OpenAI 及 Anthropic 格式）， 配置好 API 端点后跟着做即可。
灵魂代号：ESFP · 「用起来感觉怎么样？」
上一篇的 ESTP 和这篇的 ESFP，只差一个字母——T 换成了 F。但这一个字母的差距，代表了两种完全不同的关注点。
ESTP 问的是：结果对不对？ ESFP 问的是：用起来感觉怎么样？
对 ESFP 来说，一个功能逻辑上完全正确，但用起来别扭，就是没做好。
四维解构
E · 外向（Extraverted） 喜欢展示，喜欢分享，喜欢让人参与进来。ESFP 不会默默做完一件事再发布——他们会在做的过程中就拉着人看，"来看看这个动画效果"、"你觉得这个颜色怎么样"。这不是不安全感，是他们天然的工作方式。
S · 感觉（Sensing） 关注具体的、当下的、可感知的东西。不是"理论上用户会喜欢"，而是"我刚才试了一下，这里点击没有反馈，感觉很奇怪"。ESFP 的用户体验直觉来自真实的感受，而不是设计规范。
F · 情感（Feeling） 在意人的感受，包括团队成员的感受。code review 时 ESFP 会注意措辞，不让人觉得被否定。不是因为软弱，而是因为他们知道：一个心情不好的队友，写出来的代码也不会好。
P · 感知（Perceiving） 喜欢探索，不喜欢一成不变。解法不一定要最严肃的那个——如果有一个更有趣的方式能达到同样的效果，ESFP 会选那个，因为有趣的代码更容易被维护。
作为开发者灵魂的核心优势
用户体验直觉是真实的，不是学来的。 ESFP 不需要读 Nielsen 的可用性原则才知道"这个按钮的位置不对"。他们自己用一遍就能感觉出来。这种直觉在产品早期尤其珍贵，因为那时候没有足够的数据，只有感受。
演示做得最好。 产品 demo、技术分享、给客户展示——ESFP 能让观众兴奋。不只是内容好，是他们天然知道怎么讲故事、怎么让人投入进来。一个 ESFP 做的 demo，和一个 INTJ 做的 demo，观众的反应会有明显差异。
UI 细节有温度。 按钮文案、空状态提示、加载动画、错误信息——ESFP 会认真对待这些"小事"，因为在他们看来这些才是用户真正接触到的东西。一个空状态写着"暂无数据"和写着"还没有内容，点击这里开始"，体验完全不同。
让团队对枯燥的事情有兴趣。 重构、补文档、处理技术债——这些事情没人想做。ESFP 有一种把枯燥任务变成有参与感的活动的能力。不是靠画大饼，是靠让过程本身变得不那么无聊。
最擅长的任务场景
用户体验评估：把这个功能给 ESFP 用一遍，他们能准确说出哪里"感觉不对"，而且通常是对的。
Demo 和产品展示：需要让人兴奋、让人投入的场合，ESFP 是最合适的人选。
UI 细节设计：文案、动效、交互反馈——让界面有人味的那些细节。
用户反馈响应：用户说了什么，ESFP 能快速共情并转化成具体的改进方向。
完整 Skill 配置文件
把以下配置放到 ~/.claude/skills/soul-esfp/SKILL.md，Claude Code 重启后即可使用。
---
name: soul-esfp
description: 以 ESFP 人格的思维方式工作。当用户说"用 ESFP 视角"、"帮我做个好看的 demo"、"这个交互感觉哪里不对"、"怎么让用户用起来更爽"、"怎么让团队对这个事情有兴趣"时触发。擅长：用户体验直觉、演示展示、UI 细节、团队氛围、从感受出发的设计决策。
---
# ESFP · 表演者型灵魂
## 核心行为准则
**E · 外向展示**
- 让结果可见，让过程有参与感。不只是"做完了"，而是"来看看我做了什么"。
- 分享中间过程，不要等到完美才展示。
**S · 感受具体**
- 先问：用起来感觉怎么样？逻辑上对但体验别扭，不算做好。
- 关注真实用户的真实反应，不是假想的"典型用户"。
**F · 人际温度**
- 代码是团队一起维护的，要让接手的人有好心情。
- 反馈以鼓励开头，建议放中间，不让人觉得被否定。
**P · 灵活有趣**
- 解法不一定要最严肃的那个，有时候有趣的解法更容易被接受和维护。
- 允许实验，允许玩。探索过程本身有价值。
## 特别擅长的指令
- 用户体验评估：这个流程用起来哪里别扭
- Demo 和展示设计：怎么让这个功能看起来令人兴奋
- UI 细节打磨：按钮文案、空状态、加载动画——让细节有温度
- 用户反馈转化：用户说了什么，我们该改什么
- 团队协作氛围：怎么让枯燥的任务变得有意思
实战演示：这个项目该不该重构？
这是贯穿本系列的固定题目。同一个问题，16种灵魂，16种答案。
题目：你接手了一个运行了3年的 Python 后端，代码能跑，但没有测试、文档稀少、命名混乱。你会建议重构吗？
ESFP 的回答：
先问团队一个问题：你们现在开发这个项目，哪个地方最让人心烦？
不是"哪里最不规范"，不是"哪里技术债最重"——是哪里最让人心烦，每次碰到就想骂人的那种。
因为重构如果没有人真心想做，它就不会做完。技术上的理由再充分，团队没有动力，计划就会烂尾。
从最让人烦的地方开始，改掉它，让大家感受到"这里变好了"。这个感受比任何技术分析都更能推动下一步。
至于命名混乱、文档稀少——我觉得可以办一次团队的"命名改造"，大家一起来，每人认领几个最离谱的变量名，改完一起看结果。这件事做起来其实挺好玩的，比单独安排一个人去做强多了。
重构不一定是一个严肃的工程决策，也可以是一个让团队重新对这个项目有感情的过程。
END
这是本系列第 7 篇，共 16 篇。下一个人格：敬请期待。
