这篇帖子讨论的是 Claude Code（Anthropic 的命令行编码代理）如何通过 CLAUDE.md、Skills、subagents、plugins 和 MCP（Model Context Protocol，用于让代理接入外部工具与数据源）来日常编码。评论区把重点放在这些机制到底是实质能力，还是只是不同入口的 prompt 模板。很多讨论还延伸到 Codex CLI、OpenCode、AGENTS.md、Nix 和 LSP 等，用来比较是否能做成更可迁移、可复现、少锁定的 agent 工作流。围绕 code review、测试、环境隔离和失败回退的争论，实际上是在问：AI 代理究竟应该替人思考，还是只负责执行一套由人定义好的脚手架。
很多人认为 Claude Code 里的 commands、skills、subagents、plugins，本质上都是把一段固定 prompt 塞进模型，只是安装位置、来源和运行上下文不同。有人指出，/config、/model 这类才是真正的 harness 控制，而 /code-review、/simplify 之类更像文本模板，不该和前者混在同一套 slash command 里。于是有人主张把 prompt 插入机制和工具级控制拆开，最好让用户能直接看到、编辑和复用这些模板，而不是背一堆 / 前缀和 flags。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
Anthropic 团队在回复里表示，/code-review 会继续收敛成内建 skill，它的核心价值是把审查流程显式化，并让独立 subagents 从多个角度检查 bug、test、语言坑和重复代码。支持者认为，这比直接让模型随口 review code 更稳，因为它把审查维度写得更明确，类似早期提示模型 step by step。也有人欢迎 free-form 输入和更高 effort level，但对 xhigh、ultra 这类标签的可靠性保持怀疑，尤其质疑它们是否真能做到宣传里的彻底性。还有人担心 `--fix` 会在没理解问题前就先生成坏 patch。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
关于 language server plugin 的建议，多个用户给出了很强的反例：他们在 Rust、Python、Dart 上长期装了 LSP，却几乎没见 agent 真正调用过一次。即使 harness 会自动注入 diagnostics，实际命中率也很低，很多告警要么无关、要么是旧问题，最后还带来额外 RAM 开销。大家更愿意让模型自己跑 ripgrep、cargo clippy、dart analyze、ty check 这类直接的 CLI 工具，而不是依赖常驻 LSP。于是那种“最高影响插件”的说法被认为被高估了。
不少人觉得 Skills 这个抽象本身就太模糊：同一个词既能装前端最佳实践，也能装必须严格执行的 runbook，还能装某个工具的使用说明。有人建议明确分成三层：Agents 负责人格和偏好，Prompts 负责可重复任务模板，Tools 负责 CLI、MCP 和脚本。这样 CLAUDE.md、AGENTS.md 这类项目说明文件就更像配置入口，而不是把所有东西都塞进一个技能抽屉里。评论里对这个“术语过载”的不满很强。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
更底层的担忧是，Claude 仍然经常忽略 CLAUDE.md 或把指令重新解释一遍，所以很多人宁愿把测试、lint、commit 规范、spec 文件和反馈循环都做成确定性的脚本。有人强调先定义好 success，再让模型跑验证和迭代，而不是一边改一边信任它的理解。也有人指出，模型经常会写出看似正确但实际什么都没测到的 tests，或者在大范围重构时留下难查的局部最优。对这些人来说，CLAUDE.md 只是配置层，不是 containment layer。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
围绕成本和锁定，很多评论都在问：如果 Claude 下线 8 小时，或者价格突然翻倍，团队能不能平滑切到别的模型。有人建议直接把 Claude Code CLI 接到 DeepSeek、Gemini、Codex 或 OpenCode 上，尽量把项目配置做成可迁移的；也有人认为真正的风险不是某个产品，而是把提示词、CLAUDE.md 和工具链都绑定到单一供应商。另一些人则抱怨 Claude 太慢、token 太贵，或者对 ultra 之类的高价模式持怀疑态度。也有少数人提到本地/自托管模型，但认为硬件和电费并不便宜，现实上更像是多供应商可切换，而不是完全自建。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14]
另一个很实用的主题是把 agent 放进可复现、可约束的环境里，而不是指望它自己想起来该做什么。有人强推 Nix、bubblewrap、Docker、VPS 和 Linux namespace，让开发、测试、部署共享同一套环境；也有人用 pre-commit 脚本、固定的 typecheck/test/lint 流程，逼模型在每一步都先验证再继续。类似地，VOCABULARY.md、严格的 commit 模板、项目级 spec 文件，都是为了减少歧义并把机械步骤交给脚本。讨论的重心不是“让模型更聪明”，而是“让流程更确定”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
不少评论根本是在吐槽文章本身：说它空话太多、内容浅、像 AI 写的，而且读起来像在用一套陈词滥调把优化 agent 工作流包装成新发现。有人直接模仿那种过度圆滑的 AI 口癖，认为这类文风已经变得一眼可辨；也有人说文章只是把很基础的实践重复了一遍，并没有真正提供新知识。少数人则反过来说，这类回到基础的整理对新人仍有价值，只是表达方式太像 slop。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
CLAUDE.md: Claude Code 读取的项目级说明文件，用来放规则、偏好、工作流和术语约定。
AGENTS.md: 另一种项目约定文件，常被拿来做更通用、跨 harness 的代理指令入口。
subagent: 独立运行的子代理，通常用干净上下文做审查、分工或并行任务。
MCP: Model Context Protocol，一种让模型接入外部工具、服务和数据源的协议。
LSP: Language Server Protocol，语言服务器协议，用于类型检查、诊断、补全等开发支持。
Nix: 用于可复现构建和环境管理的工具/生态，常被用来锁定开发、测试和部署环境。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。