Nuwa Skill 实测——把大师装进 Claude Code
Nuwa Skill 实测——把大师装进 Claude Code
适读人群：想让 AI 辅助更有深度、不只是执行命令的开发者 | 阅读时长：约12分钟 | 核心价值：用真实的代码和文章测试案例，告诉你 Nuwa Skill 实际能带来什么不同
有一段时间，我觉得 Claude Code 帮我写代码越来越熟练，但有一个问题始终挥之不去：它帮我做事，但它不挑战我。
意思是说，我说"帮我优化这段代码"，它就去优化。我说"帮我设计这个 API"，它就去设计。执行力很强，但很少有人来问我：你确定这是对的问题吗？这个方向值得走吗？
以前有同事或者前辈，会在你讲完你的方案之后，直接告诉你："这个思路本身有问题。"这种反馈才是真正有价值的。
Nuwa Skill 想解决的就是这个问题。它是由 AI 从业者 Allen Chan（@alchaincyf）开发的一套 skill，把保罗·格雷厄姆（Paul Graham）、安德烈·卡帕西（Andrej Karpathy）、纳瓦尔·拉维坎特（Naval Ravikant）等人的思维方式蒸馏成了 skill，让 Claude Code 可以用这些人的视角来看你的代码、文章、产品决策。
项目地址：https://github.com/alchaincyf/nuwa-skill
我装了之后做了一批测试，把真实结果写在这里。
先说这个 skill 的机制
Nuwa Skill 的核心不是模拟这些人说话，而是提取他们的判断框架。
比如 Paul Graham 的框架里有几个核心要素：做难的事情（Do things that don't scale），关注真实用户而不是想象用户，写作清晰是思维清晰的体现，简洁比复杂更接近真相。
这些不是随机的语录，是他在几十篇文章里反复强调的判断标准。Nuwa Skill 把这些标准结构化了，让 Claude 在评估你的东西时，用这套标准而不是泛泛的"这是优点，这是缺点"。
安装方式在仓库 README 里有说，按步骤来就行。我不在这里复述安装流程，聊真实使用体验。
测试一：拿一段我写的 Java 代码让"大师们"评判
我拿了一段实际项目里的代码，一个用户权限校验的服务层逻辑。代码能跑，测试通过，但我自己对它有点不满意，说不清楚哪里。
代码大概是这样的：
@Service
public class PermissionService {
@Autowired
private UserRepository userRepository;
@Autowired
private RoleRepository roleRepository;
@Autowired
private PermissionRepository permissionRepository;
public boolean hasPermission(Long userId, String resource, String action) {
User user = userRepository.findById(userId).orElse(null);
if (user == null) {
return false;
}
if (user.isSuperAdmin()) {
return true;
}
List<Role> roles = roleRepository.findByUserId(userId);
for (Role role : roles) {
List<Permission> permissions = permissionRepository.findByRoleId(role.getId());
for (Permission permission : permissions) {
if (permission.getResource().equals(resource)
&& permission.getAction().equals(action)) {
return true;
}
}
}
return false;
}
}用 Paul Graham 视角评估的结果（部分）：
"这段代码最大的问题不是技术问题，是它在用复杂度掩盖一个没想清楚的设计决策。你的权限模型是什么？RBAC？如果是 RBAC，为什么不直接用成熟的实现？如果不是，那你的模型是什么，你自己说得清吗？代码是思维的镜子，这段代码反映出来的是：你知道要做权限校验，但你没有为这个系统里的权限是什么建立清晰的模型。"
"N+1 查询的问题在这里，但这不是主要问题。主要问题是这个方法的调用方要怎么知道 resource 和 action 该传什么字符串？是散落在代码各处的字符串常量吗？还是有个枚举？如果是字符串，这个系统的权限边界在哪里，你说不清楚。"
我看完第一反应是：对，这是我说不清楚哪里不好的地方。
用 Karpathy 视角评估的结果（部分）：
"每次调用 hasPermission 都在数据库查询 roles 和 permissions，这在高频调用场景下是不可接受的。权限数据的更新频率是多少？如果是分钟级或小时级，缓存是必须的。但更深的问题是：你没有对这段代码的性能特征做过测量，对吗？你应该先测量，再优化，而不是在不知道瓶颈在哪里的情况下讨论优化。"
Karpathy 的评估更偏工程实现，PG 的更偏设计和思维。这两个视角是不同的，不是重复的。
测试二：拿一篇文章草稿让 Paul Graham 评
我有一篇关于"为什么中小公司不应该过早引入微服务"的草稿，大概 2000 字，写了一半，感觉论点有点散。
PG 视角给的反馈里有一段我觉得很准：
"你在这篇文章里说了很多'微服务的成本'，但你没有说清楚这些成本对谁是成本。对一个有 50 个工程师的公司，微服务的运维成本是可以承担的；对一个 5 人团队，同样的架构会压垮团队。你的结论是对的，但你的论证是普适的，而有价值的观点往往是具体的，不是普适的。"
"文章的开头你用了一段背景介绍，把微服务是什么解释了一遍。你的读者知道微服务是什么，不需要你解释。直接进入你的核心判断，把背景介绍去掉。"
我把第一段背景介绍删掉了，文章的开头直接变成了核心论点，确实好多了。
什么时候用哪个"大师"有价值
用下来的体验是：不同的"大师"适合不同类型的问题。
Paul Graham 适合：
- 早期架构决策（这个方向值得走吗？）
- 产品或技术文章的论证结构
- 判断一个复杂设计是不是在用复杂度掩盖思维不清晰
他的风格是会质疑你的前提，而不只是在你给定的前提下优化。这有时候很有价值，有时候会让你觉得答非所问。
Karpathy 适合：
- 工程实现层面的审查（有没有潜在的性能问题、扩展性问题）
- 机器学习相关的技术选择
- 技术方案的可操作性评估
他的风格更工程化，会关注可测量性、可实验性，以及"你有没有实际测量过你的假设"。
Naval 适合：
- 判断一件事值不值得做（优先级、杠杆率）
- 技术债的取舍决策
- 长期来看什么是更重要的
Naval 的视角更偏战略，对技术细节的关注不多。我拿代码让他看，效果不好。但拿"我要不要花一个月重写这个模块"这种决策来问，他的回答质量挺高的。
几个真实的使用坑
坑一：不要把 Nuwa Skill 当代码补全工具用
Nuwa Skill 是评估工具，不是生成工具。如果你想让"Paul Graham 帮我写代码"，它给出的东西会很奇怪，因为这不是它的设计用途。
它的价值在评估和质疑，不在生成。
坑二：有时候"大师"会过度批评
有一次我把一段其实还行的代码给 PG 看，它给出了一大堆"这个假设是错的"、"这里的复杂度是不必要的"。我花了十分钟认真看完，发现有三分之一是真的问题，三分之二是在过度解读。
这是这类 skill 的通病：为了看起来有深度，它倾向于把问题说得比实际更大。用的时候要有自己的判断，不能全信。
坑三：上下文很重要
只给一个函数，"大师"能给出的评估是有限的。给出完整的业务背景、系统约束、已有的设计决策，评估质量会高很多。
我最好的一次使用体验是：把业务背景（这是什么系统）、当前代码、我已经考虑过的方案和排除理由，打包一起发给它，然后让 PG 看。这种情况下给出的评估最有价值，因为它能在真实约束下思考。
我的最终判断
Nuwa Skill 不是每天都用的工具。我的用法是：在做重要决策之前，或者有一个东西做完了但感觉不太对、说不清哪里不对的时候，拿出来用一次。
它的价值不是替代你思考，是给你一个不同角度的强力质疑。这种质疑有时候很有价值，有时候会让你浪费时间。
值不值得装？值，但要知道它能干什么和不能干什么。
如果你以为装了它，Claude 就会变成保罗·格雷厄姆，那你会失望。如果你把它当成一个"在你的思维盲区里踢你一脚"的工具，它挺好用的。