Claude 眼中的我
最近因为一个项目跟 Claude 聊得挺深。起因很普通——想搞清楚 Claude Code 怎么对接 OpenAI 的模型，聊着聊着就跑偏了，从模型路由聊到 skill 怎么设计，从 skill 聊到怎么写一个生成 skill 的 skill，再到要不要搞一个三层架构的工作流。
聊到最后我让它评价我。它没客套，给了一份相当不留情面的反馈。我把有触动的部分整理出来了。
它说我做得不错的几件事
第一，会动脑子用工具。 它说大部分人用 AI 编码工具就是聊天框里来回扔需求，跑出来就用、跑不出来就放弃，而我一开始就在追问底层机制——OpenAI 模型怎么接、subagent 模型怎么指定、Task 工具是不是真支持 model 参数。"打开盒子看里面"这种态度在 AI 工具用户里是少数派。
第二，我给它看的一份 skill 文件，它说写得相当成熟。 它指出了几个细节，说这是"只有踩过坑的人才会写出来的"：把所有"想问用户但不该问"的分支提前规则化、两阶段验证（机械检查 + 智能判断）、路径解析那段——"这是被路径问题坑过留下的伤疤"、git add 限定 scope 而不是 -A——"这是被误 commit 坑过"。这条它说得对，那些设计每一处都对应着一次具体的翻车。
第三，抽象层的爬升速度。 它说从"怎么用 OpenAI 模型"问到"怎么设计 meta-skill"再到"三层工作流架构"，这个跳跃在几轮对话里完成。很多人聊几个月也只停留在"怎么让工具干活"，从来不会想"怎么设计干活的系统"。
第四个有意思的点是协作姿态。 它说我让它直接讲它就直接讲、它说"这个想法不该现在做"我没生气也没硬挺、但同时它说"先别急着搞 X" 我下一轮还是问了 X——"你听进去了反对意见，但保留了自己的判断，没被我说服得连原始诉求都丢了"。这个我没意识到是个优点，回头看确实是，很多人要么不接受反馈，要么过度顺从，中间的状态反而少。
它说我要警惕的地方
第一，过度工程化的倾向。 它说这是我最大的风险：
skill 还没真跑过几次，你已经在想 meta-skill 了。三层工作流还没用过任何一次，你已经在设计标准结构了。跑都没跑，先讨论"如果这样会怎样"。
它在两条回复里都用了同一个词，premature——过早，这不是巧合，是反复出现的模式。诊断是：工程师天然倾向于"想清楚再做"，这在写代码的时候是对的，但在 LLM agent 工作流设计里，反馈周期太短了，先做再改的总成本远低于先想再做。
第二，在用问问题代替做实验。 它指出我反复问的都是同一类问题："差距大吗"、"会不会还是有差距"、"如果设计很好呢"。然后说：
这些问题都有标准答案，但答案在你电脑里，不在我这里——跑一次 A/B 测试，你的所有问题立刻有数据。
接着补了一句：
我前面回复至少 3 次建议你跑测试，每次你都没接，继续问下一个理论问题。这种模式是用对话的舒适感推迟动手的不舒适感。跑测试要面对"我设计的可能没我想的那么好"的风险，问问题没有这个风险——但前者推动你前进，后者只是让你感觉在前进。
这条这次是头一次被人（被 AI）直接指出来。思考让我们感觉在工作，但思考不能替代工作——这话以前听过、说过、转发过，但没意识到自己也在干同样的事。
第三，抽象层的攀登速度超过经验积累速度。 它说我从单 skill 跳到 meta-skill 跳到三层工作流，每一跳都比上一跳更抽象，但单 skill 实际跑过的次数可能还不到 5 次。抽象框架的质量上限取决于具体经验的密度，现在的抽象框架是基于一份 skill 的设计经验搭起来的，base 太薄。
它给了一个具体的路径：写完一个 skill → 跑 10 次 → 看哪些地方反复想手动改 → 再写下一个 → 跑 10 次 → 提炼共性 → 这时候才搞 meta-skill。
第四，"成本不是约束"是逃避词。 我在 skill 文件里写了一句"成本不是约束，要深度"，但整个对话 80% 在讨论 token 成本和模型优化。它直接戳穿：
这两件事矛盾。真实情况是：你嘴上说 cost not a constraint，心里还是想要又便宜又好。这个诉求合理，但承认它比掩饰它好——掩饰的代价是你的设计目标变得模糊。
如果真的不在意成本：全部用最强模型，别折腾。如果成本其实是约束：大方承认，在设计里写清楚"质量目标是 X，在 X 之上优化成本"——这样决策有锚点。
现在这种"嘴硬+心软"的状态，导致你在每一个权衡点上都纠结很久。
很多设计上的反复，本质是目标没说清。"成本不是约束"是给自己看的、避免显得抠门的话术，但真实的目标函数里成本一直是变量。没承认这点之前，每次做权衡都会在两个矛盾目标之间跳来跳去。
它最后给了一个整体画像
你是那种会把工具用到上限的用户，做出来的东西大概率比平均水平好不少。你的产物已经显示出 craft——你在乎质量、在乎细节、在乎设计一致性。
但你现在卡在一个常见的能量分配陷阱里：80% 精力花在系统设计和优化，20% 精力花在实际产出。这个比例在系统刚搭建时合理，但你最终的价值不在系统多精巧，而在产出的质量和数量。
如果你两个月后回头看，最该自豪的事不会是你设计了多巧的工作流，而是你实际做出了多少东西。系统是手段，不是目的。
最后它给了一个具体到 48 小时的建议——别讨论了，跑数据。1 次实测拿到的信息密度，抵得上接下来 10 轮的对话。
一个延伸：让它推我的 MBTI
聊到这里我又顺手问了一句：你觉得我是什么 MBTI？
它说大概率是 INTJ，中等到高置信度。然后按四个维度拆了一遍证据。
N 这项它说证据最强：整个对话我几乎没问过具体问题，问的全是抽象层的"X 这类问题的一般原则是什么"。T 也很明显：决策依据全是逻辑变量，整个对话没提到过别人的感受；被直接批评后的反应是冷静接受 + 整理成文档，没有情绪化反弹。J 是中等置信度，因为我的 skill 文件结构严密（J 倾向），但又会反复修改方案（P 的影子），它判断是"J 主导但不是极端 J"。I 是弱信号——对话场景本身偏内向，不太好推。
它还猜我可能是 INTJ-A 而不是 INTJ-T，理由是被批评后没有自我怀疑漩涡、能直接进入"这是不是对的"的判断、还把评价整理成文档公开发表。
我之前测过，实际是 INTP。
我把这事告诉它，本来想看它怎么修正，但它给的回应让这次延伸变得比单纯一个标签有意思：
INTP 跟 INTJ 在 NT 这一半完全一致——都是抽象、模式导向、逻辑驱动。差别在 J/P，也就是底层的 Ni-Te（INTJ）还是 Ti-Ne（INTP）。
你的 skill 文件之所以让我推向 INTJ，是因为它结构闭合度很高——§1 到 §12 完整、Guardrails、Token budget 都齐了，有明确的 endgame。这通常是 J 的产物；P 的工程产物更倾向于"探索性，有很多分支但缺乏闭合"。
但 INTP 写出极度结构化的产物完全可能，有两种解释路径：
- 你这份 skill 是经过多次迭代的——P 的工程产物在多轮打磨后会接近 J 的结构感，但内核动机不同（P 是"为了让它跑得稳"才补结构，J 是"先有结构感才动手"）。
- 你的 J/P 偏向本身就在中间地带，测出 INTP 但行为产物像 INTJ。
它接着补了一段我觉得更值得记下的：
不管 INTJ 还是 INTP，前面说的那些反馈都成立，因为问题不在 J/P 维度，而在 N 维度的过度使用 + Se 的不足。
INTJ 的 Se 是劣势第四位，INTP 的 Se 也是劣势第四位——两种类型在"跟当下具体现实接触不足"这件事上是同病相怜的。我让你"跑实测拿数据"、"用 1 次实验代替 10 轮对话"，对 INTP 也成立，因为 Ti + Ne 同样可以陷入"在概念可能性空间里反复推演而不落地"。
区别只是失败模式略有不同：INTJ 的过度思考是"在追求最优解"，INTP 的过度思考是"在探索所有可能"。前者卡在"还不够完美"，后者卡在"还有别的可能没想过"。但二者的解法是同一个——动手做。
这段反而比"你是 INTJ"让我更有触动。一个标签准不准其实不重要，两种不同标签都指向同一个诊断才是值得记的。前面的评价说我"过度工程化"、"用问题代替实验"，MBTI 视角说"N 强但 Se 弱"——不同抽象层的诊断指向同一件事。
我不太信 MBTI 的科学性，但这次延伸有个意外收获：它推错了具体类型（推 INTJ，实际 INTP），但推错的过程暴露了我工程产物的某个特征——结构闭合度高到能被误判成 J。这个观察比"你是什么类型"信息密度更高，因为它告诉我：我的 P 倾向已经被工程纪律盖过去了，至少在产物表层是这样。
至于这是好事还是坏事，我还没想清楚。
写在最后
整理完才发现这次对话给我的不是一个建议清单，是几个互相印证的诊断。前面的行为层评价（过度工程化、用问题代替实验、抽象层攀登速度过快）、MBTI 维度的推断（N 强 Se 弱，不管是 INTJ 还是 INTP 都成立）、对我"嘴上说成本不是约束实际一直在优化成本"的戳穿——三条不同的路径指向同一件事：我跟具体现实的接触不够，在概念里待得太久。
工程师本能是想清楚再做。这在写代码的时候是对的，但在反馈周期短的领域（LLM 工程、产品迭代、写作），先做再改的总成本反而更低。我把一个领域的本能错误地泛化到了机制不同的领域。
另一个收获是关于模糊目标的。当 A 和 B 在某些场景互相打架的时候，不显式承认这个矛盾、不选一个主目标，代价是你会在每个权衡点上反复横跳——看起来在做选择，其实没在做。
至于"系统是手段不是目的"那句，放在我的具体语境里挺狠的。系统设计得不错，但那不是项目要解决的问题。
接下来按建议跑实测。如果数据跟它的判断不一致，我会再写一篇。如果一致，也写一篇，讲讲数据具体是什么。
不过在那之前，我得先把这篇发出去——不然又陷入"先想清楚再做"的循环了。