#工作流

SOP 型内容生产者,很擅长阉割掉 Claude Code 的智力 我见到一些「创作者」非常依赖所谓的 SOP、工作流去生产内容,他们觉得「智能体」加上系统提示词生产内容,和用 claude code 没区别 在他们的工作环境里,上下文是不重要的(其实是根本没有),反正都是把一堆提示词灌进大模型,你怎么灌都是灌,Agent 除了用起来比 chatbot 不方便一点,可以说是毫无优势了 这里会造成一个死锁 因为原有的生产方式没有有效沉淀内容 -> 所以使用 Agent 的初期效果和 chatbot 没区别 -> 所以继续使用 chatbot -> 所以坚信 Agent 除了用起来不方便没有其他区别 但真正好的 AI 协作方式是定义目标和约束,而不是定义步骤 在定义步骤的情况下,你希望的是 prompt1 -> prompt2-> prompt3 -> prompt4 即便迁移到 claude code,也不过是 skill1 -> skill2 -> skill3 -> skill4,垃圾依然是垃圾 而在定义目标和约束的情况下,我希望智力可以通过我积累的内容得以涌现 当我试图把内容改成所谓的「更大人群面选题」时候,claude code 会提醒我,我曾经写过如何用一个更窄的选题,同样做出好内容 当我找不到观点的时候,claude code 不仅可以推理出观点,还可以检索到我曾经被数据验证过的观点,而不是把「观点」和「观点」混为一谈 当我用 skill 去写所谓的「爆款标题」的时候,claude code 会告诉我,我迭代标题的过程、我对标题的理解、我此时此刻写的标题,和我写标题的 skill,不是一件事,而是有内在关联的四件事 Agent 会在我的足够有密度的上下文里,找到我自己看不见的连接,有力量的不是模型能力,是上下文密度 不认可 Agent 创作的「创作者们」,认为 claude code 无法升级他们的 SOP 他们觉得调用一个又一个 skill,和你切换一个又一个「智能体」有啥区别? 我的看法是:这是一群使用旧工具极其熟练的人,旧工具带来的回报越大,他们就越是认为旧工具带来的 SOP 价值连城。于是任何无法融入旧 SOP 的新工具,都是垃圾工具 没关系,只要你永远看不见「上下文」,你就永远正确,「智能体」就永远无敌,你就永远立于不败之地,新范式就永远是花花架子 可是,真正有问题的,到底是新的工具,还是被困在旧范式里面的人? 等汽车遍布马路的时候,我们再来看看到底是谁在骑马 这一天不会太久远,比你想象的快十倍
ginobefun
4个月前
Skills explained: How Skills compares to prompts, Projects, MCP, and subagents Claude Skills 不就是把提示词存个文件夹吗? 看了两篇关于 Skill 的好文章,做下阅读笔记。 很多人初次看到 Claude 的 Skills 功能,第一反应是:这不就是把提示词存成文件吗?这个判断其实低估了它的意义。 Anthropic 专门写了篇长文解释 Skills 与 Prompts、Projects、MCP、Subagents 的区别。这篇文章值得关注,因为它不只是介绍功能,而是在说明 AI 应用开发的底层逻辑转变。 从第一性原理看,Skills 的存在有其必然性。大语言模型需要上下文才能工作,但上下文窗口有限是物理约束,重复输入相同信息显然低效。面对这个矛盾,合理的解决方案就是建立按需加载的知识模块系统。 官方给出了清晰的定位:Prompts 是即时指令,Skills 是可复用流程,Projects 提供知识库,Subagents 是专职助手,MCP 负责连接外部系统。这五个组件各有分工,配合使用才能发挥完整价值。 举个实际例子。你可以创建一个代码审查的 Subagent,只给它 Read、Grep、Glob 这些只读权限,不给 Write 和 Edit 权限。当你修改代码时,Claude 会自动委派这个 Subagent 做安全检查,既保证了审查流程,又避免了误改代码的风险。再配合 Skills 里定义的安全审查标准,整个流程就能自动运行。 这里有三个关键点值得注意。 第一,Skills 不是功能增强,而是范式转变。过去用 AI 是即兴发挥,现在可以系统沉淀工作方法。 第二,五个组件需要配合使用。单独用 Skills 只有 30% 效果,配合 Projects 的背景知识、MCP 的数据连接、Subagents 的任务分工,才能构建出生产级的工作流。 第三,未来的护城河不在于调用哪个模型,而在于你积累了多少精心设计的 Skills。这跟 npm 生态类似,先发优势会越来越明显。 对做 AI 产品的人来说,现在可能是时候从写花式提示词,转向设计可复用工作流了。