1. 项目也需要做一次“性格测试”你有没有遇到过这种情况接手一个开源仓库README 写得挺漂亮但真正翻代码时才发现——依赖装了三遍都跑不起来提交记录里全是“fix bug”“update”目录结构像被猫踩过的键盘。这时候你心里其实已经在给这个项目贴标签了这项目“性格”有点怪。Claude 工作流里有个很好玩的思路既然 MBTI 能把人拆成四个维度那项目也能。仓库结构、依赖管理方式、提交习惯、文档完整度、测试覆盖——这些特征组合起来其实能映射出一套可读的“项目人格画像”。YC 总裁 Garry Tan 开源的 gstack 仓库核心就是把开发流程拆成可重复调用的 skill从 office-hours 到 retro 形成完整生命周期。我们不需要照搬整套而是借它的“分阶段让模型承担不同职责”的思路做一个轻量版的项目 MBTI 诊断工作流。这篇要交付的东西很具体一套可复制的 Claude 工作流配置骨架包含 settings.json 和提示词模板然后带你在自己的项目上跑通一次完整诊断最后核对输出结果。适合谁适合手里有项目、想快速摸清代码库“脾气”的开发者也适合想用 Claude 做代码库分析但不知道从哪下手的人。2. 前置准备TaoToken 接入与工作区初始化在开始写工作流之前得先把模型调用通道准备好。我用的是 TaoToken 的 API 接入方式它的接口兼容主流格式配置起来比较直接。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。你需要先去控制台创建一个 API Key。打开 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 登录后在 API Keys 页面生成一个 key复制保存好。这个 key 后面会写进环境变量不要直接硬编码在配置文件里。然后确认你的本地环境有 Node.js 18 和 npm。Claude Code 类的工具通常通过 npm 全局安装或者你直接用 curl 调 API 也行。我这边为了演示工作流配置用的是 Claude Code 的 settings.json 机制它支持自定义 skill 和提示词模板。先建一个工作目录比如project-mbti在里面初始化mkdir project-mbti cd project-mbti npm init -y接着把 API Key 写进环境变量。Linux/macOS 下export TAOTOKEN_API_KEY你的keyWindows PowerShell$env:TAOTOKEN_API_KEY你的key如果你用的是 Claude Code可以在~/.claude/settings.json里配置模型端点。下面这节会给出完整的 settings.json 骨架。3. 可复制配置settings.json 与提示词模板3.1 settings.json 骨架Claude Code 的 settings.json 一般放在~/.claude/settings.json也可以放在项目根目录的.claude/settings.json做项目级覆盖。我们这里用项目级配置方便跟着仓库走。{ model: claude-sonnet-4-20250514, apiKey: ${TAOTOKEN_API_KEY}, baseUrl: https://taotoken.net/api, skills: { project-mbti: { description: 对项目做 MBTI 式性格诊断, promptFile: .claude/prompts/project-mbti.md, allowedTools: [Read, Glob, Grep, Bash] } }, permissions: { allow: [Read, Glob, Grep], ask: [Bash] } }几个关键点说明一下。baseUrl指向 TaoToken 的 API 端点apiKey用环境变量引用避免明文泄露。skills里定义了一个叫project-mbti的 skill它的提示词放在.claude/prompts/project-mbti.md。allowedTools限制了它能用的工具读文件、搜文件、跑命令但跑命令需要确认。3.2 提示词模板在项目根目录建.claude/prompts/project-mbti.md内容如下# 项目 MBTI 诊断提示词 你是一个代码库性格分析师。请对当前项目做一次 MBTI 式诊断输出四个维度的倾向和综合人格画像。 ## 分析维度 ### E / I外向 / 内向 - E 倾向依赖多、集成多、对外接口丰富、频繁与外部服务交互 - I 倾向依赖少、自包含、内部模块耦合低、很少调用外部 API ### S / N实感 / 直觉 - S 倾向代码风格务实、测试覆盖具体、文档写实现细节、提交信息直白 - N 倾向架构抽象多、设计模式密集、文档讲理念、提交信息偏概念 ### T / F思考 / 情感 - T 倾向错误处理严格、类型系统强、lint 规则多、CI 卡得死 - F 倾向注释多、README 友好、贡献指南详细、issue 回复温和 ### J / P判断 / 感知 - J 倾向目录结构规整、提交频率稳定、版本号规范、有明确 roadmap - P 倾向目录灵活、提交随性、版本号跳跃、实验性分支多 ## 执行步骤 1. 读取 package.json 或同等依赖清单统计直接依赖数量 2. 用 Glob 列出 src/ 或主要源码目录结构观察层级深度 3. 用 Grep 搜索 TODO、FIXME、HACK 出现次数 4. 读取最近 20 条 git log用 Bash: git log --oneline -20 5. 检查是否有测试目录、CI 配置文件、README、CONTRIBUTING 6. 综合以上特征给出四个维度的倾向判断和置信度 7. 输出一段 200 字以内的项目人格画像 ## 输出格式 维度 | 倾向 | 置信度 | 依据 --- | --- | --- | --- E/I | ... | ... | ... S/N | ... | ... | ... T/F | ... | ... | ... J/P | ... | ... | ... 综合人格XXXX 画像描述...这个模板的好处是把“性格判断”拆成了可执行的检查动作模型不会瞎猜而是真的去读文件、数依赖、看提交记录。3.3 触发方式配置好后在项目根目录运行 Claude Code然后输入/project-mbti如果 skill 没被识别检查 settings.json 的路径和 JSON 格式。也可以用命令行直接调claude --skill project-mbti4. 验证请求跑一次完整诊断4.1 准备一个测试项目为了验证工作流我拿一个真实的小型 Node 项目来跑。你可以用自己的项目或者临时 clone 一个开源仓库。这里用一个典型的 Express 项目做例子。先确认项目里有这些文件package.json、src/目录、.git目录。如果没有 git 历史诊断的 J/P 维度会缺依据建议至少有几个提交。4.2 执行诊断在项目根目录启动 Claude Code输入/project-mbti。模型会依次执行提示词里的步骤。你会看到它先读 package.json然后列目录再搜 TODO最后跑 git log。一次实际的输出大概长这样维度 | 倾向 | 置信度 | 依据 --- | --- | --- | --- E/I | I | 高 | 直接依赖 6 个无外部 API 调用自包含 S/N | S | 中 | 测试用例具体README 写安装步骤提交信息直白 T/F | T | 高 | TypeScript strict 模式ESLint 规则 40CI 卡 lint J/P | J | 中 | 目录按功能分层提交间隔均匀版本号语义化 综合人格ISTJ 画像描述这是一个务实、自包含、规则严格的项目。它不喜欢花哨的抽象 依赖控制得很克制测试写得具体CI 把关严格。提交节奏稳定 版本号规范适合长期维护。缺点是灵活性一般引入新范式时 可能需要较多改造。4.3 核对输出拿到结果后你自己核对几个点。依赖数量对不对打开 package.json 数一下。目录结构描述准不准对照实际文件树。提交习惯的判断有没有依据翻一下 git log。如果某个维度明显不准比如它说你是 P 但你的提交其实很规律那可能是提示词里的判断标准需要调。这时候改.claude/prompts/project-mbti.md里对应维度的描述重新跑一次。4.4 用模型对话做二次确认如果你想对某个维度深挖可以用模型对话单独问。打开 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 把项目的依赖清单和目录结构贴进去问它“这个项目的依赖策略偏外向还是内向”。这样能交叉验证工作流的输出。5. 本篇常见错排查5.1 skill 不生效提示找不到命令先检查.claude/settings.json是否存在JSON 有没有语法错误。可以用cat .claude/settings.json | python -m json.tool验证格式。然后确认promptFile路径是相对于项目根目录的不是相对于 settings.json 的。如果用的是全局配置~/.claude/settings.jsonskill 定义要放在全局的 skills 里项目级的会覆盖全局。5.2 API 返回 401 或 403大概率是 API Key 没传对。检查环境变量TAOTOKEN_API_KEY是否在当前 shell 里生效用echo $TAOTOKEN_API_KEY看一下。如果 settings.json 里写的是${TAOTOKEN_API_KEY}确认 Claude Code 支持这种变量替换。不支持的话改成从环境变量读取的配置方式或者用.env文件配合 dotenv。另外确认 baseUrl 是https://taotoken.net/api不要多加路径。API Key 可以在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 重新生成一个试试。5.3 git log 读不到J/P 维度缺失如果项目没有 git 历史或者 Claude Code 没有 Bash 权限git log 这步会跳过。解决办法是在 settings.json 的 permissions.allow 里加上 Bash或者提前把 git log 输出保存成文件让模型读文件。没有 git 历史的话J/P 维度可以退化成看目录结构和版本号。在提示词里加一句“若无 git 历史则根据目录规整度和 package.json 的 version 字段判断”。5.4 输出太笼统没有具体依据这是提示词写得太松。检查模板里每个维度是否有明确的检查动作。比如 E/I 维度要真的去数依赖不能只说“观察依赖情况”。把“统计直接依赖数量”这种可执行动作写进去输出就会具体。如果模型还是偷懒可以在提示词末尾加一句“每个判断必须引用至少一个具体文件或命令输出作为依据”。5.5 诊断结果和实际感受不符MBTI 本身就不是精确科学项目诊断也一样。如果结果偏差大先看置信度。置信度低的维度本来就不该全信。然后调整提示词里的判断标准比如你的项目依赖少但对外接口多那 E/I 维度就要加权考虑接口数量而不是只看依赖数。多跑几个项目把输出和你的直觉对比慢慢调提示词准确率会上来。6. 把诊断接进日常开发流跑通一次诊断只是开始。真正有用的是把它接进日常流程。比如每次接手新仓库先跑一次 project-mbti心里有个底。或者在发版前跑一次看看项目性格有没有漂移——依赖突然变多、提交变乱、TODO 堆积这些都是性格变化的信号。如果你想让这套工作流长期跑在编码和 Agent 场景里可以了解一下 Coding Plan它更适合需要持续调用模型的开发流程https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有更完整的配置说明和 skill 扩展示例。我自己的做法是把 project-mbti 的输出存到项目根目录的.project-mbti.md每次诊断覆盖更新。这样项目性格的变化就有了一条时间线比单次诊断更有参考价值。提示词模板也可以按团队习惯改比如加上“检查是否有安全审计配置”这种自定义维度。跑几次之后你会发现给项目做性格测试这件事比想象中更能暴露那些平时被忽略的结构问题。