焕德“你们用Claude写代码改bug不亏，但拿它给项目做体检这件事，才是最近这批开源工作流里最让我眼前一亮的方向。”如果你最近刷社交媒体，应该已经见过那张图：一个软件的Git仓库被Claude跑完一套流程后，输出了类似“ENFJ型项目”“INTJ型代码库”这样的性格报告。这个思路的来源，是YC总裁开源的一整套Claude工作流——把MBTI这套人格测试方法论，整个搬到软件工程领域，给项目做了一次性格体检。一开始我觉得这就是个噱头，但当我真正复现、跑通、并拿自己的项目实测之后，才发现这套工作流真正值钱的不是MBTI四个字母，而是它在背后设计的一整套“如何让Claude客观审视一个项目”的评估流水线。
这篇内容我会从底层原理讲到复现细节，再讲实测结果和避坑经验，保证你拿到的不是一张花哨的报告，而是一套能落地到你自己项目中的诊断工具。
1. “项目MBTI”到底在测什么：四个维度的工程化转译
1.1 为什么MBTI可以给“项目”做测试
MBTI把人的性格拆成四个对立维度：外向/内向、直觉/实感、思考/情感、判断/感知。放在人格上，这四个维度描述的是一个人获取能量、处理信息、做决策、安排生活的方式。仔细想想，一个软件项目其实也有“行为模式”——它从外面吸收需求的方式、它在代码里做技术决策的风格、它对待用户和内部质量的优先级、它组织和推进迭代的纪律性，本质上都是项目长期演进中沉淀下来的“性格”。
这套工作流的开发者做的，就是把MBTI的四个维度重新翻译成软件工程语境下的评估项。它不是在测代码好不好，而是在测一个项目“像什么样的团队带出来的孩子”。同一个功能，一个偏“直觉”型项目可能倾向于用新框架、重写边界，一个偏“实感”型项目则可能选择最小改动、快速合入。这两种选择没有对错，但代表了项目的性格倾向。这个视角比单纯的代码质量评分更能反映一个项目的演进风格、团队文化、技术审美的潜在偏差。
1.2 四个维度的工程化转译
原版MBTI的四组字母，在这里被映射成四组工程问题。这套映射逻辑是整个工作流的骨架，我实测之后觉得翻译得相当精准：
- E（外向）与 I（内向）：关注一个项目对外部输入的敏感度。E型项目很擅长从用户反馈、市场变化、社区issue里获取能量，需求文档频繁更新，版本迭代速度受外部反馈驱动；I型项目则更依赖内部自驱，倾向于自己定义方向，外部输入需要经过详细的转化才能进入开发流程。
- N（直觉）与 S（实感）：关注技术决策的抽象程度。N型项目喜欢平台化、抽象层、架构重组，在重构和新技术引入上非常积极；S型项目偏好具体可验证的改动，一切以眼前问题和确定性优先，对“以后可能用得上”的抽象设计容忍度很低。
- T（思考）与 F（情感）：关注价值判断的决策基准。T型项目在取舍时主要看性能指标、成本、资源占用、可维护性等硬性数据；F型项目在决策时会把开发者体验、用户情感、社区口碑、可访问性这些“软性”因素摆到很高优先级。
- J（判断）与 P（感知）：关注流程的纪律程度。J型项目有严格的CI/CD、commit规范、版本发布节奏和deadline管理，流程异常会被视为事故；P型项目则保留大量探索空间，分支活跃、规格松散、经常在最后一刻调整计划。
实际运行时，工作流不是简单地二选一，而是为每个维度输出1-10的分数，并给出支撑证据。比如它不会只告诉你“这个项目偏J”，而是会给出“CHANGELOG显示固定双周发布节奏、PR模板强制关联issue、CI配置中commitlint检查启用”这类具体依据。
1.3 它和传统代码质量指标的分工
有一个关键点我刚开始也误解了：这套工作流不是来替代SonarQube、CodeClimate、linter这类工具的。静态扫描工具看的是“代码健不健康”，这套工作流看的是“项目像谁、怎么长大的、适合往哪走”。一句话概括就有很多直接拿到手就能用的价值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 这个开源工作流真正值钱的地方：一套可拆解的评估流水线
“用Claude给项目做MBTI测试”表面上看只是给它写一段很长的提示词，让模型读一遍仓库然后给结论。但如果你真的试过就知道，直接让Claude读几十个文件然后给个性格结论，大概率会得到一份幻觉严重、前后矛盾、还搂不住证据的报告。这套开源工作流真正厉害的地方，是把评估拆成了一条有清晰边界的流水线。
2.1 整体流水线：三阶段四输出
工作流整体分三个阶段。第一阶段是“信号采集”，它不是让Claude漫无目的地读代码，而是先定义好需要从哪些文件类型里读取性格信号——README、CONTRIBUTING、CHANGELOG、issue模板、PR模板、docs目录、关键源码文件、CI配置。每种文件对应不同的性格观测维度。第二阶段是“证据提取”，Claude需要从这些文件里抽取出中性的事实描述，不评判好坏，只记录“这个项目在哪些地方表现出什么样的行为倾向”。第三阶段才是“性格判定与报告生成”。
这个设计非常聪明。它把一次容易被幻觉污染的大任务，拆成了“先提取事实、再基于事实打分、最后生成报告”的三步链式调用。每一步的输出都是下一步的输入，而不是让模型一口气从头编到尾。实际测试下来，报告的可解释性有了很明显的提升。
2.2 核心系统提示词的写法
这套工作流开源代码里最核心的部分，是一组system prompt。以我复现时的理解，它的写法有几个关键特征值得直接抄作业：
一是“角色锚定”。系统提示词会先把Claude定义成一个“资深软件架构师兼组织文化分析师”，强调你不评价代码对错，只观察行为模式。这个锚定极大减少了Claude在分析时“忍不住去修bug”的冲动。二是“证据优先”。每输出一个维度的判断，必须附带至少一条从输入文件中提取的直接引用或客观描述，禁止无证据推测。三是“分步执行”。提示词要求Claude先输出各维度分项评分表，再撰写综合报告，而不是一段话糊完。
我基于这套思路写了一个极简版的核心提示词，片段如下，仅供参考：
text复制你是资深软件架构师与团队文化分析师。你的任务不是判断代码好坏，而是通过仓库信号推断这个项目的“行为性格”。
请阅读以下文件摘要，按四个维度打分（1-10）：
1. 外部输入敏感度（E/I）：项目迭代多大程度由外部反馈/社区驱动，多大程度由内部规划驱动。
2. 抽象偏好（N/S）：项目更倾向于抽象平台化方案，还是具体直接的最小改动。
3. 价值决策基准（T/F）：在取舍中更看重硬指标，还是更看重体验、口碑、情感因素。
4. 流程纪律性（J/P）：开发流程、发布节奏、规范执行的严格程度。
输出格式要求：
- 先输出四个维度的评分表，每个分数必须附一条来自文件摘要的直接证据。
- 再输出100字以内的项目性格概述。
- 最后输出一段“给项目维护者的建议”，不超过150字。
这个提示词的细节可以按项目风格再调，但三个核心要素——角色锚定、证据优先、分步执行——缺一不可。
2.3 为什么要分步推理而不是一次生成
我从实际对比中感受特别深：如果一次性把所有文件丢给Claude直接给结论，它给出的报告往往“看起来很合理，但经不起追问”。比如它会说“项目偏N”，但当你问它“为什么偏N”时，它给不出具体的文件出处，或者会开始编造一些文件里不存在的抽象层设计。这就是典型的幻觉。
而分步推理之后，每个维度的分数都有了明确的证据支撑，后续报告哪怕观点有偏差，读者也能通过证据链条去反驳和调整。这个方法其实不是什么黑科技，但在这个场景里极其有效——因为MBTI测试本身就是主观评估，主观评估最怕的就是没有锚点。
3. 复现准备：三种跑法，从零配置到接入CI
如果你看完上面的逻辑决定自己试一把，下面这部分是实操向的。我按从易到难列了三种跑法，选哪种取决于你的使用场景。
3.1 前置条件：API Key和Claude Code安装
不管哪种跑法，前提都是有一个可用的Claude API Key。如果你已经有API权限，直接在环境变量里配置好：
bash复制export ANTHROPIC_API_KEY="sk-ant-..."
如果你更喜欢在终端里交互式操作，可以安装Claude Code。现在网上安装相关的帖子很多，但核心其实就三步：装好Node.js环境、用npm全局安装、在项目目录里登录授权。以macOS/Linux为例：
bash复制npm install -g @anthropic-ai/claude-code
cd your-project
claude
安装完之后哪怕不跑这套MBTI工作流，日常写代码、复盘commit、生成PR描述都很好用。它是跑法二的基础。
3.2 跑法一：Python脚本直连API
这是最轻量、最适合接入CI或定时任务的方式。核心逻辑非常简单：读取指定文件列表的内容，拼成输入，调用一次Anthropic API，把结果打印出来。下面是我实际在用的简化版脚本，拿过去改改路径就能跑：
python复制import os
from anthropic import Anthropic
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
# 1. 收集项目信号
file_paths = [
"README.md",
"CONTRIBUTING.md",
"CHANGELOG.md",
".github/ISSUE_TEMPLATE/config.yml",
".github/pull_request_template.md",
"docs/architecture.md",
]
contents = []
for path in file_paths:
if os.path.exists(path):
with open(path, "r", encoding="utf-8") as f:
contents.append(f"### 文件: {path}\n{f.read()[:8000]}")
project_signal = "\n\n".join(contents)
# 2. 拼装 prompt（简化版）
system_prompt = """你是资深软件架构师...（省略，使用上文的核心提示词）"""
user_prompt = f"以下是我的项目文件摘要，请完成项目性格评估。\n\n{project_signal}"
# 3. 调用 Claude
response = client.messages.create(
model="claude-sonnet-4-20250514", # 以你当前账号可用模型为准
max_tokens=2000,
system=system_prompt,
messages=[{"role": "user", "content": user_prompt}],
)
print(response.content[0].text)
这里有两个细节很关键。第一，读文件时要截断长度，我每个文件最多取前8000字符，避免超长内容稀释注意力。第二，模型名一定要填你当前账号确实可用的版本，否则会报model not found。如果你不确定，在Claude Code里跑一次简单对话就能查到可用模型。
3.3 跑法二：Claude Code + Skill
如果你不想写Python脚本，想直接在项目目录里跑，可以把它做成一个Claude Code的Skill文件。在项目根目录建一个 .claude/skills/project-mbti/SKILL.md，内容大致是：
markdown复制---
name: project-mbti
description: 对当前项目执行一次MBTI性格评估
---
读取项目中的README、CONTRIBUTING、CHANGELOG、issue/PR模板、docs目录，
按四个维度对项目性格打分并输出报告。
输出格式：
- 四维评分表（1-10，附证据）
- 项目性格概述（100字内）
- 给维护者的建议（150字内）
保存后，在项目目录里启动 claude，直接说“跑一下project-mbti”，Claude Code会自动读取Skill文件并按既定流程执行。这种方式的优点是不用维护独立脚本，整个评估逻辑都沉淀在项目配置里，换人接手也一目了然。
3.4 跑法三：n8n/Dify编排（可选）
如果你本身就在用n8n或Dify这类工作流平台，也可以在这个基础上搭建更复杂的自动化。比如定时触发Git拉取、自动执行评估、把结果写入数据库或推送到企业微信群。我在实际使用中，是把跑法一的Python脚本封装成了一个可执行文件，然后在n8n里用HTTP Request节点调用，再拖一个Webhook节点把结果推给团队。这样做的好处是评估结果有历史存档，可以观察一个项目在几个版本迭代后性格的变化趋势。
但我不建议一上来就这么重。先把最基础的跑法一跑通，看到报告，理解了输出逻辑，再考虑编排也不迟。
4. 完整实测：把Git仓库喂给Claude，看它输出什么
光讲逻辑和配置有点干，我把自己的一个实际项目跑了一遍，把过程和输出贴在下面，你可以对照自己的项目做演练。
4.1 输入样本怎么准备
我测的是一个开源Android工具库，仓库不大，但文件类型齐全。我按工作流的默认配置采集了以下信号：
| 文件/目录 | 预期观测维度 |
|---|---|
| README.md | 项目定位、对外沟通风格 |
| CONTRIBUTING.md | 协作入口、规范意识 |
| CHANGELOG.md | 发布节奏、变更组织方式 |
| .github/ISSUE_TEMPLATE/ | 外部反馈的收集方式 |
| .github/pull_request_template.md | 代码合入门槛 |
| docs/architecture.md | 抽象程度、设计文档习惯 |
| app/src/main/java/ 下3个核心类 | 代码组织与技术风格 |
每个文件取前8000字符，约等于一份浓缩的项目档案。这里有个小经验：不要试图把所有代码都塞进去，Claude的上下文窗口虽然大，但信息密度会显著影响判断质量。你给它30个文件，它反而容易在次要文件上花费过多注意力，导致核心维度的证据提取不充分。精选6-10个高信号文件，比全量扫描效果好得多。
4.2 实测代码：一次真实的API调用
我用的是第二节里的Python脚本，核心提示词按工作流的开源版本做了微调——把“证据优先”改成必须引用“文件路径+原文片段”。这个改动非常值得强调：如果不限制引用格式，Claude给出的证据经常是“README中提到了XX理念”这种模糊表述，无法核查。加了路径和原文引用之后，每条证据都可以去仓库里验证，报告说服力翻倍。
4.3 输出报告长什么样
那次实测的输出，简化后大约长这样：
| 维度 | 分数 | 证据示例 |
|---|---|---|
| E（外向7 / 内向3） | 7 | CHANGELOG中新增功能大部分标注了对应issue编号，且issue来源多为用户反馈 |
| N（直觉6 / 实感4） | 6 | docs/architecture.md详述了未来插件化改造计划，代码中已有抽象接口预留 |
| F（情感6 / 思考4） | 6 | README中大量强调“易用性”“新手友好”“社区贡献感谢” |
| J（判断5 / 感知5） | 5 | CI配置完整但release流程为手动触发，没有固定发布节奏 |
综合判定：ENFJ型项目（外向、直觉、情感、判断）
概述：这是一个非常重视外部反馈和社区体验的项目，迭代方向主要由用户需求驱动，同时在架构上保留了一定的前瞻性设计。流程上具备基础规范但还谈不上严格纪律，整体处于“社区驱动+适度规划”的成长型状态。
给维护者的建议：继续保持对用户反馈的高响应度；当前最值得加强的是把发布节奏固定下来，让社区建立预期；架构抽象层目前适中，不建议在用户需求还没完全收敛前大规模扩展。
这个结果和我对这个项目的长期观察相当吻合。它确实是一个用户反馈驱动、社区导向明显、流程还在成长期的项目。
4.4 报告怎么读：不止看四个字母
如果你自己跑出来的结果和自己的直觉不太一样，先别急着怀疑工作流。我发现解读报告时最有用的是看“维度分数”，而不是四个字母本身。比如E7/I3和E5/I5是完全不同的项目，虽然它们都叫“E型”，但前者可能是狂热用户驱动的社区产品，后者只是略微外向的技术工具。分数比字母信息量大多了。
还有一个非常重要的点：这个报告描述的是“这个项目的当前状态”，不是“这个项目的本质”。项目性格会随着重构、团队调整、发布策略改变而迁移。所以建议你每次跑完都存档，过几个版本后再跑一次，对比变化。我实测过一个老项目在两次大重构前后，N/S维度从4涨到了7——这是一个很好的信号：重构确实让它的抽象程度提升了。
5. 报告别急着当标签：五个坑和三个正经用法
5.1 五个坑：从“性格”到“状态”的认知切换
我踩过的坑和看到别人踩的坑，主要集中在五个地方。
第一个坑是“把结果当命运”。拿到一个“P型项目”就说团队纪律性差，这是最典型的误读。MBTI人格测试本身就有争议，更何况是对项目的拟人化测试。分数低不代表“坏”，只代表“当前状态如此”。一个P型项目可能正在探索期，这个状态下流程松散是正常的，甚至是有益的。
第二个坑是“拿不同类型项目横向比较”。用这套测试去比较一个2C产品和一个基础库是没什么意义的，它们性格本来就该不同，强行比出优劣只会误导决策。更有价值的比较是“自己的项目vs自己的目标”：如果你的目标是把项目做成高纪律、高可靠的基础设施，但测出来是大开大合的P型，那这个差距才是值得关注的。
第三个坑是“忽略时间维度”。我见过有人把项目MBTI报告当成永久标签，一年后还在用。项目性格是会变的，尤其在团队大换血、技术栈切换、发布节奏调整之后。建议至少每个大版本跑一次，版本之间的性格迁移本身就是一个有价值的观测指标。我自己的经验是，当你重构了架构、引入了更严格的CI流程后，很可能从P型偏向J型，这种变化值得记录和解读。
第四个坑是“只看字母不看分数”。E7和E5可能差得很远，但都显示为E。如果你只记录字母、不记录分数，过几个月回看会丢失大量信息。我在Git仓库里每次跑完都把完整报告存成一个markdown文件，方便后续对比。
第五个坑是“把建议当圣旨”。工作流末尾生成的“给维护者的建议”是基于文件信号的一个合理推测，只供参考。你的实际情况、近期规划、团队能力、资源约束都在模型视野之外，所以它说“建议增加发布节奏”不代表你下一周就要去改发布流程。建议把它当作一个思考起点，而不是行动清单。
5.2 三个正经用法
绕开这些坑之后，这套工作流在下面三个场景里是真的有用。
场景一是“新成员入职适配”。新人刚接手一个项目时，最大的问题不是看不懂代码，而是“看不懂这个项目的脾气”。读一遍工程文档和读一份性格报告是完全不同的体验。给新人一份项目MBTI报告，能让TA在很短时间内建立对项目的整体预期：这个项目偏保守还是偏激进、流程细不细、社区导向强不强。我团队里新来的同学反馈，“看完报告再读代码，理解速度明显快了”。
场景二是“技术选型与重构前的对照”。当你准备给项目引入一个大改动时，先跑一次MBTI，然后问自己一个问题：这个改动和项目当前的性格匹配吗？如果这是个S型（实感、保守）项目，你却打算做一次激进的架构抽象，那大概率会遭遇巨大的团队惯性阻力——这个时候不是说你不能做，而是你提前知道了阻力来源，可以针对性设计推进策略。反过来，如果项目明显偏N型，但你的方案是最小改动、零抽象，那可能需要调整方案去匹配项目的长期演进方向。
场景三是“开源项目的社区方向校准”。我拿它测了几个开源项目之后发现一个规律：社区活跃度高、PR合入率高的项目，通常E和F维度都比较高。如果你运营一个开源项目，测完之后发现E维度偏低，说明你的项目在用户反馈收集上可能有盲区——比如issue模板不友好、CHANGELOG更新不及时、社区贡献指南缺失。每条证据都是可以落地的改进点。
6. 把它改造成自己的诊断模型：边界与扩展
6.1 哪些项目不适合这种测试
实测中我发现几类项目不适合直接套这套工作流。
第一类是纯代码仓库、零文档。如果只有一个src目录，没有README、没有CHANGELOG、没有CONTRIBUTING，Claude能提取到的“性格信号”非常有限，报告基本等于从代码风格里硬猜，参考价值不大。
第二类是极早期的实验性脚本。一个刚写了两天的原型脚本确实有性格，但这种性格大概率一周后就变了，测了意义不大。我建议至少等项目的文档、issue、commit历史积累到一定规模再跑。
第三类是非常同质化的自动生成项目。比如脚手架一键生成的CRUD模板，文件除了业务表名不同，其他都一模一样。这类项目测出来的报告会非常“模板化”，基本就是Claude对脚手架本身的刻板印象，对你没有增量信息。
6.2 定制自己的评估维度
这套工作流在原作者的四个维度上，其实完全可以扩展出更多适合你自己的维度。比如我给自己团队的内部项目定制过两个额外维度：
- “技术债容忍度”维度：看项目是倾向快速实现而后补重构，还是一开始就要求设计完备。
- “协作开放度”维度：看项目是否鼓励外部贡献、issue响应速度、文档完备程度。
方法也很简单：在系统提示词里增加对应的维度定义和评分标准，同时在输入信号里补充相关的文件类型。比如想看协作开放度，就把README里的贡献指引、issue模板的详细程度、PR review流程都列进去。
更进阶的玩法是把这套评估迁移到其他领域。我试过用同样的三步流水线，给一个内部项目的“新人上手体验”打分，核心提示词换成“你是开发者体验专家，评估新成员从clone仓库到跑通第一个demo的顺畅程度”，效果也很好。这套工作流最通用性的价值，其实是“把模糊的定性判断，拆成有证据支撑的定量评估”。
6.3 我的一些个人体会
这套工作流我用了小半年，最大的感受是：它最大的价值不是给项目一个确定的类型标签，而是迫使你把项目里的各种信号系统性地摆到桌面上，解释给另一个“智能体”听。这个过程本身就会让你重新审视自己项目的文档质量、issue管理、发布纪律。
我自己有一个项目，第一次跑出来是典型的“ENFP”——外向、直觉、情感、感知，非常符合它早期野蛮生长的状态。后来我按照报告里的建议，陆续补了CONTRIBUTING指南、固定了发布节奏、整理了roadmap，半年后再跑，J维度从4涨到了7。那次变化让我对这套工作流从“有点意思”变成了“值得常用”。
最后再分享一个小技巧：你可以把每次的评估报告按版本号存档，比如 docs/project-mbti/v1.2.md。这样不只是看单次结果，还能看到一个项目的“性格演化史”。这份演化记录，往往比单次报告更能反映一个项目真实的成长路径。