HN Weekly 中文
← #796

把 Claude Code 当作主力工具：CLAUDE.md、Skills、Subagents、Plugins 与 MCP

查看原文 HN 讨论

文章摘要

这是一篇实战指南，讲述如何把 Claude Code 当作日常主力工具来使用。作者的核心理念是：应把 Claude Code 当作一个”可编程的 Agent”而非聊天机器人，最根本的原则是”给 Claude 一个验证自己工作的方式”——这个验证回路能让它不断迭代改进，从而大幅提升产出质量。

文章围绕几大组件展开。CLAUDE.md 是一本”活的规则手册”，在每次会话开始时加载，因此应当刻意保持精简，记录的不是详尽文档，而是项目特有的”坑”和约定。作者倡导一种”复利式工程”（compounding engineering）——在犯错后让 Claude 自己把教训写进规则，”更新 CLAUDE.md 以免重蹈覆辙”成为一句反复出现的指令，从而逐步积累团队的制度性知识。Skills（技能） 把重复的提示词变成可调用的斜杠命令，存放在 .claude/skills/<name>/ 目录里，作者建议：”如果你把同一段指令输入了两次，那就意味着有一个技能等着被写出来。”Subagents（子代理） 在独立的上下文中运行、权限受限，能避免主会话上下文膨胀；其关键价值在于”链式调用以获得全新视角”——在一个会话里实现、在另一个不带前文偏见的会话里评审。Plugins（插件） 则把技能、代理和 MCP 服务器打包在一起，而 MCP（模型上下文协议） 通过标准接口把数据库、设计工具、错误追踪器等外部工具暴露给 Claude。

文章还给出了大量日常工作流建议：早晨先审查子代理夜间完成的工作、每周运行 /insights；做新功能时先规划再实现、最后用子代理评审；修 bug 时先在测试中复现；批量改动用 /batch 分发到并行代理；并行会话则用 3-5 个 git worktree 配合”写手/评审”模式。作者还总结了来自 Anthropic 团队的核心洞见：高 effort 的 Opus 胜过需要更多纠正的小模型；用 worktree 并行而非靠 checkpoint；维护让 Claude 持续更新的笔记目录。全文的核心信息是：”配置（setup）才是真正的工作，执行只是验证。”

HN 评论精华

  1. “还要读多少篇 AI 写的肤浅指南”：高赞评论者 mindwok 发出了一句颇具代表性的抱怨：”我还要读多少篇这种由 AI 写的、关于如何使用编程 Agent 的肤浅指南？天哪，什么时候才是个头？”这条评论戳中了许多人对此类内容泛滥的疲惫感。

  2. 组件过多亟需整合：用户 mil22 一针见血地指出，命令、技能、子代理和插件这几套东西亟需整合。他举例说，光是”评审代码”这一件事现在就有五种做法：写一个已被弃用的 .claude/commands/review.md、用一个 /code-review 技能、用一个 /pr-review 子代理、装一个 /code-review 插件，或者干脆直接让 Claude 评审代码——而它们本质上都只是 Markdown 的变体，最后一种”直接问”在大多数情况下效果几乎一样好。

  3. Claude 宕机时怎么办：用户 netdevphoenix 抛出一个尖锐的现实问题——如果你的代码库是用这套流程靠 Claude 搭建的，而 Claude 宕机了 8 小时，你还能高效、流畅、有生产力地接管这个代码库吗？这触及了对 AI 编程深度依赖的隐忧。downsplat 的经验则提供了一种平衡答案：他在 10 万行以上的中型代码库上用 Claude，认为它是很好的生产力倍增器，但他仍不愿放手太多自主权——即使 Claude 高层把握得不错，他依然会看代码、给反馈、来回调整 3-4 轮，以确保自己对代码库始终保有掌控感。

  4. Nix 集成是头号杀手锏：用户 sshine 分享了他的”头号杀手锏”——Nix 集成。工具链、密钥、环境以及 Agent 自行修改环境的能力都源自单一来源，开发机、CI、部署环境完全一致，编译和运行在每台机器上都必然成功。他还大量使用 /branch 和 /rename 做上下文检查点与分叉，并几乎只在沙箱中运行。

  5. 确定性的步骤应固化为脚本：用户 rkuska 指出，文章里写进 CLAUDE.md 的那套 typecheck/test/lint 流程，他更倾向于放进 pre-commit 钩子，因为”Agent 很不稳定，经常跳过这些步骤”，凡是能确定性化的东西他都做成脚本强制执行。他还吐槽 Claude 和 Codex 写的 commit message 都很糟糕。也有人对这套理念整体持怀疑态度：sandrello 认为这种话术暴露了生成式 AI 的”邪教与忽悠”一面——付费产品本应开箱即用，而这套说法等于承认产品不过是个”空盒子”，要靠用户自己用第三方插件和 Markdown 把它变得有用。