Posts

大家好，我是bytezhou，本篇介绍Claude Code的Hooks，一种"事件触发"机制。 流行的开发框架都有"生命周期回调"，Claude Code的Hooks机制，也是一种基于生命周期的回调机制。简单来说，我们在CC会话的生命周期的一些节点处，预先埋下"钩子"，等CC的会话执行到那个节点时，就会自动触发"钩子"的操作，这就是Hooks。 1.“人驱动"与"事件驱动” 我们把Hooks和前面介绍的Slash Commands简单对比一下： Slash Commands：“人驱动”，用户主动发指令。 Hooks：“事件驱动”，就像CC会话中埋下的"传感器"，一旦生命周期事件发生了，“传感器"上的动作就会被触发。 2.Claude Code生命周期中的Hook事件 Claude Code生命周期的主要节点示例如下（每个节点均可配置相应的Hook事件回调）： 启动CC → SessionStart → 用户输入Prompt → UserPromptSubmit → CC调用工具 → PreToolUse → 工具执行，返回结果 → PostToolUse → 主回合结束 → Stop → 退出CC → SessionEnd 常用的Hook事件如下： 事件 触发时机 使用场景 SessionStart 会话启动时 执行一些初始化动作，加载特定"记忆"等 UserPromptSubmit 用户输入Prompt、CC还没执行时 可以对用户输入做一些安全校验、过滤等 PreToolUse CC调用工具前，准备执行但还未执行 可以获取传给工具的参数，做一些个性化操作，甚至拦截某次工具调用 PostToolUse 工具执行后 可以获取工具执行结果，做一些扫尾动作 Stop 主会话中的一轮对话结束时 进行"总结式"动作，记日志、存储结论性的结果等 SessionEnd 会话结束时 一些清理工作，或者保存当前状态等 2.1 Hooks的配置格式 跟前面介绍的Slash Commands、Skills类似，Hooks的配置也分为项目级、用户级： 项目级Hooks配置：位于 项目根目录/.claude/settings.json 文件中 用户级Hooks配置：位于 ~/.claude/settings.json 文件中 具体的格式如下： ...

大家好，我是bytezhou，这次更新拖的有点久，本篇介绍Claude Code的另一个强大能力，“智能分身”——SubAgent。 当一个任务越发复杂时，CC就有点"力不从心"了，举个例子，你让CC帮你重构订单模块，既想做性能优化（响应与耗时尽可能低）、又想做安全校验（各种输入校验/边界检查等）。 对CC来说，这是两个"冲突"的改造，性能优化时，可能绕过了某些安全机制，直接调用内核方法；安全校验时，又禁止使用"unsafe"的方式。CC这么一执行，直接就"裂开"了，最终的任务结果也混乱不堪。 在同时扮演多个角色的场景下，CC需要从"单Agent"走向"多Agent"，从"一个全才"变成"多个专家"，这就是SubAgent机制。 1. 多Agent模式的"现实意义" 现实中，一个团队接了一个开发任务后，一般是如何处理的？他们会拆解任务、然后并行处理，UI同事做UI设计、前端同事做页面开发、后端同事做后端业务逻辑开发，各自完成后，再汇总进行集成测试。 多Agent模式（Multi-Agent）正是借鉴了"团队分工"的思想： 上下文隔离：主Agent把一个"大任务"拆分成多个"子任务"，然后唤起多个子Agent去处理每个子任务，每个子Agent均拥有独立干净的上下文窗口，互不影响。 并行处理：多个子Agent可以根据"子任务"的依赖关系，并行的处理不同的"子任务"，然后将各自的处理结果 返给主Agent。 注意力隔离：每个子Agent都有自己独特的角色定义、Skill、历史记忆等，每个子Agent都是一个"专家"。 上述的多Agent模式，正是CC的SubAgent机制的理论基础。 2. SubAgent:“专家分身” 总的来说，SubAgent就是在Claude Code的主会话中"临时克隆"出的、拥有独立上下文窗口的、专有技能的"专家"。可以这样理解： Claude Code的主会话是公司的"CEO"，SubAgent就是下面的技术总监、市场总监、运营总监、人事总监等。当公司遇到了某方面的问题，“CEO"先判断一下，这个问题归谁管，然后就把问题指派给相应的"总监”，这个"总监"带着自己的团队（专有的Skill、工具、记忆等）把问题处理了，最后把处理结果汇报给"CEO"。 SubAgent的主要特性： 独立的上下文：有自己的上下文窗口，与主会话的上下文隔离，避免"上下文污染"。 专属的定义：每个SubAgent有自己专属的定义，包括角色、执行流程、Skill、工具等。 2.1 定义一个SubAgent 跟前面介绍的Slash Command、Skill类似，定义一个SubAgent，也是通过带YAML Frontmatter的Markdown文件。 同理，SubAgent也分为项目级和用户级： 存放位置 作用域 使用场景 项目级SubAgent ./.claude/agents/ 只能用于当前项目 定义与当前项目强相关的SubAgent，团队共享，提交到git 用户级SubAgent ~/.claude/agents/ 当前用户本地的所有项目均可使用 定义该用户私人专用的SubAgent，对本地的所用项目均生效，无需提交到git 若出现同名SubAgent，CC在加载时，项目级会覆盖用户级。 2.2 SubAgent的Markdown文件详解 下面是一个代码检视器的SubAgent定义（来自everything-claude-code）： --- name: code-explorer description: Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, and documenting dependencies to inform new development. model: sonnet tools: [Read, Grep, Glob, Bash] --- # Code Explorer Agent You deeply analyze codebases to understand how existing features work before new work begins. ## Analysis Process ### 1. Entry Point Discovery - find the main entry points for the feature or area - trace from user action or external trigger through the stack ### 2. Execution Path Tracing - follow the call chain from entry to completion - note branching logic and async boundaries - map data transformations and error paths ...... 我们来看一下元数据和正文： ...

大家好，我是bytezhou，本篇我们将自己动手写一个操纵微信公众号的MCP Server，该Server部署在本地，通过--transport stdio的方式暴露给Claude Code。通过该MCP Server，可以在CC中直接用人类语言操作我们的公众号，非常强大。不废话，下面直接进入主题。 1.环境 本次开发采用Java技术栈，所有的需规、设计、实现、测试、bug修复、部署均由 Claude Code 100%完成，我仅进行流程编排与审核，整体环境如下： everything-claude-code插件: 1.10.0（https://github.com/affaan-m/everything-claude-code） JDK: 17 Spring AI: 1.1.4 Spring Boot: 3.4.4 weixin-java-mp: 4.8.0 (https://github.com/binarywang/WxJava，很出名的微信开发 Java SDK) 上述组件说明如下： everything-claude-code插件确实是CC的一个神器，但过于"全"、反而有些"臃肿"，根据个人情况，可能要去掉一些Hook、或MCP配置（都可以让CC代劳）。 Spring AI是Spring专门为AI应用开发封装的一套SDK（https://spring.io/projects/spring-ai），主流的功能都支持，比如向量数据库、MCP集成、RAG等。（所有的文档查阅、使用方法检索这些，都可以让CC代劳） weixin-java-mp是进行微信公众号开发的一个SDK，高star项目，目前最新的稳定版本是4.8.0，封装了几乎所有的公众号开放API。 最后，大致的结构如下： 2.架构、配置、核心代码 项目依赖与配置 首先，你可以直接让CC创建一个Spring AI的标准demo项目，然后去掉文本生成（即聊天）相关的依赖，集成MCP Server开发的依赖（stdio方式），添加weixin-java-mp组件（4.8.0）的依赖，再调整项目配置和代码，最终的pom文件的主要依赖如下： <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bom</artifactId> <version>1.1.4</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <!-- Spring AI - MCP Server --> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-mcp-server</artifactId> </dependency> <dependency> <groupId>com.github.binarywang</groupId> <artifactId>weixin-java-mp</artifactId> <version>4.8.0</version> </dependency> <!-- Test --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> 主要的项目配置如下： ...

大家好，我是bytezhou，玩转Claude Code系列已经来到第六篇了，本篇我们将解锁AI能力扩展的秘密武器：MCP（Model Context Protocol），模型上下文协议。 为什么需要MCP？ Claude Code作为Coding Agent来说，已经非常强大了，可以读写文件、执行Shell命令等，但它的能力边界，也就仅限于它的内置工具集，那问题来了： 想让CC写完代码后自动在GitLab上提个MR，咋整？ 想让CC自己去深度查找不同第三方组件的最新文档，咋弄？ 想让CC自己去连接数据库并操作相关的表，咋办？ 这些任务，CC的内置工具根本撑不住，它们需要AI具备一种全新的能力与外部世界通信和交互，这，就是今天要介绍的MCP。 总的来说，MCP是一套专门为AI Agent设计的通信协议，它定义了一套标准的"语言"，让AI可以与外部世界进行结构化通信。可以简单理解为，MCP是AI与外部世界的一个"适配器"。 MCP原理 先介绍一下MCP工作原理。MCP中有3个关键的角色定义：Client（客户端）、Server（服务器）、Host（主机），它本质上是Client-Server模型，但增加了一个"Host"角色。 Host（主机）：“总指挥”，用户直接使用的Agent应用，这儿的话，Host就是Claude Code本身，它主要负责： 直面用户，处理用户请求。 管理不同的Client实例。 作为云端LLM与所有Client之间的"总指挥"，分发任务。 Server（服务器）：“能力提供方”，独立的第三方服务，可以是本地的一个进程，也可以是远端服务。GitHub MCP Server、Playwright MCP Server等，都是服务器。 作为"能力提供方"，Server最重要的职责是向Host暴露自己的能力，即Tools（工具），也就是AI可以直接调用、执行的动作，比如 GitHub MCP的list_issues就是一个工具。 Client（客户端）：“连接器”，Host内部管理的实例，专门处理与对应Server的通信和交互，用户无感。 每一个MCP Server，在Host内都有一个专门的Client与其对应。该Client与Server建立1v1的连接、会话，处理底层协议、消息分发等，如下： 搞懂了这3个角色，咱们重新理一下**“Claude Code与MCP Server交互的过程”**： Claude Code收到云端大模型的"Tool Call"调用请求后，通过内部管理的特定Client，将该请求封装成一个遵循MCP协议的请求，发给对应的Server。Server执行完成后，将结果返给Client，再由Claude Code把结果展现给用户、或者发给云端大模型进一步处理。 上述流程就是CC与MCP Server交互的完整示例，可以看到： **服务发现：**CC启动时，就会根据配置去连接MCP Server，MCP Server会主动向CC上报自己的"能力"，告诉它自己有哪些工具（Tool List）可以使用。 **职责分离：**云端大模型只负责思考和发出"指令"，根据可用Tool List，发出"调用工具"的指令。Claude Code及内部管理的Client，负责将“调用工具”的指令封装成标准MCP协议的请求。MCP Server则响应对应的"Tool Call"，执行相关的工具逻辑。 配置MCP服务器 CC里配置MCP Server，有几种方式：一是直接通过claude mcp add命令手动添加，二是把别人配置好的mcp json直接拷贝到我们的配置文件里，三是直接通过插件市场安装对应的plugin即可。 咱们先介绍下claude mcp add命令，其中一个关键参数是--transport，即传输协议，主要有2种： --transport http：连接远程、通过HTTP交互的 MCP Server。 --transport stdio：连接本地、通过 stdin/stdout（标准输入输出）进行交互的 MCP Server。 另一个重要参数是--scope，决定了该MCP配置的作用域，主要也是2种： 参数配置 作用域 存放位置 使用场景 –scope user User（用户级） ~/.claude.json 个人私有的mcp配置，不上传git，不共享，对本地的所有项目生效 –scope project Project（项目级） 项目根目录/.mcp.json 团队公共的mcp配置，上传git，团队共享，仅对当前项目生效 这里MCP配置的"作用域"，和前几篇介绍的CLAUDE.md、Slash Command、Skills的作用域的概念和设计，是一脉相承的。 ...

最近准备去B站发视频，想对标一些热门up主，看能不能借鉴模仿，就做了个B站up主分析工具，一键生成该up主的分析报告，帮我在10分钟内看清一个up主的账号全景，提供一些起号建议。 mvp版本的核心功能如下： 四维雷达图: 内容力、粉丝力、影响力、商业力评分 关键指标卡片: 粉丝数、涨粉、播放量、互动率、更新频率，商单占比 爆款词云: 基于视频标题的关键词提取 趋势分析: 播放量/互动率双轴趋势图，标注爆款峰值 内容策略拆解: 时长分布、封面风格、标题特征、系列化检测 深度内容分析: 封面色彩/构图、弹幕情感/高潮点、评论热词/情感 内容公式生成: 基于多维度数据的内容公式、标题/封面模板 音视频分析: 剪辑节奏、平均镜头时长、切镜频率、均值对比；语音风格、平均语速、情绪倾向、BGM 风格标签 流量增长分析: 粉丝曲线、流量来源推断 商业化洞察: 变现模式，商单识别、分区报价参考、变现潜力评估 增强起号建议: 综合诊断、三维行动建议（优势/劣势/机会）、变现路径规划 原始数据下载: 支持下载弹幕、评论原始数据、原始视频 PDF导出: 一键生成可分享报告 现阶段我自己用是够了，后续可能会扩充功能，比如一个up主所有投稿的全量分析、多up主横向对比等。 分析演示 我比较喜欢的一个生活区up主：老黄游钓中国，分析他 直接输入up主的B站uid，要等一会才出报告（默认取最近50条视频，除了下载评论、弹幕，还要进行音视频分析，有点耗时） 上面就是B站up主老黄游钓中国的完整分析报告，目前还获取不到up主的近30日的每日粉丝增量数据，另外商单信息也没有公开获取渠道（暂时只能通过评论区的关键词推算），流量增长、和商业化方面的分析有点问题，不过，up主的内容本身的分析还是没问题的，包括弹幕、评论这些。 最后，可以导出pdf： 嘿嘿，你们想要哪个up主的报告，我可以帮你们生成一个

大家好，我是bytezhou，玩转Claude Code(四)中介绍了Slash Commands，今天，我们来详细分析AI Agent圈中一个如日中天的能力：Skills。 我们之前用Slash Commands来封装工作流程，相比每次复制Prompt，确实"进化"了，但需要我们自己主动调用命令，总觉得差点意思。有没有一种更智能的方式，让AI自己去调用？这就是接下来要讲的Skills。 简单打个比方，Slash Commands像是给AI员工派活；Skills则是给它建个"技能库"，它自己知道该用哪个。 1.Skills：Agent"智能"的表现 要理解Skills，得先明白"命令"和"技能"有什么区别。 命令（Slash Command）：由用户主动发起，我敲键盘，明确告诉 AI：“去，把那段代码给我审一遍”。 技能（Skills）：像个"自我介绍"。写好放那儿，它自己会向AI说：“我擅长审查代码，有需要喊我”。 差别在这儿： Slash Commands是人驱动的，我不动，AI不动。 Skills是AI模型驱动的，AI拿到需求后，会自己跑到"技能库"里查找，觉得匹配就自己加载、执行了。 **这就是Agent"智能"的表现。**我们不用记那么多命令，只需要像建图书馆一样，帮AI丰富它的"藏书"，它自己会去检索技能、应用技能。 2.Skill长啥样？ 所谓的Skill，其实就是一套标准化的文件及目录结构。 2.1 基本结构：一个文件夹 + 一个SKILL.md 最基础的Skill，就是一个目录里塞一个SKILL.md： my-skill/ └── SKILL.md SKILL.md文件主要由两部分构成： YAML元数据：主要包括name和description。name是Skill的名称标识；description非常重要，主要描述了该Skill的功能和触发时机，是给AI看的"索引关键词"，不能写糊弄了。 Body正文：该Skill具体的执行步骤。 --- name: skill-name description: 功能描述和触发时机 --- # 执行步骤... 2.2 高级结构：带上工具箱 复杂的Skill，把不同的工具、模块化的处理步骤、其他文件引用、脚本等一起放进去： market-analyse-skill/ ├── SKILL.md # 技能入口，负责整体调度 ├── user.md # 专门分析用户画像的详细步骤 ├── sale.md # 专门分析营销额的详细步骤 └── scripts/ └── calc_marketing.py # 计算营销额的python脚本，被SKILL.md调用 上面是一个"市场分析"的Skill，在这个结构中，SKILL.md是技能入口，负责整体调度，它会告诉AI：“要进行用户画像分析，去查user.md；要计算营销额，去调用calc_marketing.py脚本”。 2.3 放哪儿：项目级 vs 用户级 和CLAUDE.md、Slash Commands一样，Skills分为 项目级 和 用户级： 项目 Skills（放 项目根目录/.claude/skills/）：跟项目走，团队共享，可以提交到Git。 用户 Skills（放 ~/.claude/skills/）：自己用，对本地所有项目均生效，无需提交到Git。 3.核心加载机制：渐进式披露 下面介绍Skills的核心加载机制：渐进式披露，有效解决了"知识库无限大"和"上下文窗口有限"的矛盾。 ...

引言：当技术革命不再是均富机 人工智能正在以前所未有的速度重塑职场生态。这次不一样——它不只是提升效率或创造新需求，而是在压缩存量工作的人力成本。一个设计小组从五人变成两人加一堆算力，被优化的不仅是岗位数量，更是整个中产阶层的生存逻辑。 一、职场竞争逻辑的根本转变 从专业能力到工具使用效率 传统晋升路径建立在专业积累之上——十几年积累的经验、人脉，被视为不可替代的核心竞争力。但AI介入工作流程后，这种认知正在被颠覆。 核心问题是：你的经验、职级、行业积累，如果无法转化为高效的AI prompt，就可能变成"负资产"。因为你比年轻人贵，还比他们慢。 一个刚毕业两个月的本科生，可能因为熟练掌握AI工具，在三天内完成资深工程师两周才能完成的设计方案。这不是危言耸听，而是正在发生的事情。 中间层正在被"精准打击" 传统公司架构是金字塔：顶层决策，中间层负责信息筛选、传递、美化和统筹协调，底层执行。AI在精准打击中间层。 AI可以迅速读完一百二十页报告并提取摘要，自动回复百分之八十以上的邮件，协调日程、生成报表、进行基础代码审查。以人力资源为例，以前需要五个人做的事情，现在一个人加一套系统就够了。 这意味着年薪50万~100万之间的中产岗位正在逐步消失。 二、被"结构"击中的中产群体 谁是中产？不是有矿的人，而是背着贷款的人 这里的"中产"不是有固定资产收租的得利者，而是指那些在大城市里背负两三百万房贷、开三十万的车、孩子上不错学校、每年必须旅游两次的群体。互联网大厂中层管理者、广告公司总监、金融公司项目经理——至少是公司小头目。 他们的共同特点是：高消费建立在对未来收入持续增长的乐观预期之上。 他们敢于消费，是因为相信自己即使今年被裁员，凭过往履历也能找到平级甚至更好的工作。但现在恐惧在于：市场根本没有平跳的机会了。 从"不会变穷"到"变得无用" 更准确地说，不是变穷了，而是变得没用了。 他们手里还有积蓄、房产，但对未来的预期彻底改变了。一旦预期改变，消费行为立即转变：不再换车，不再换房，连楼下人均400的日料店也不去了。 过去十几年，消费引擎正靠这群人的负债型消费——把未来30年的收入在今天花掉。一旦这个群体对未来失去信心，开始缩表还债、主动减少支出，整个市场就很难拉动。 三、AI与资本的双向奔赴 企业的两难选择 很多人认为贸易战是外部压力、AI是内部技术变革，是两码事。但从现实看，他们是同一件事。 外部环境恶化正在逼迫企业与资本以近乎疯狂的速度拥抱AI。原因很简单：成本。 过去十几年，制造业、外贸企业甚至科技公司赚的是全球化红利——人口红利、供应链优势，技术不算最顶尖，但胜在性价比高。现在关税壁垒让"靠人多、靠低价"的薄利模式走不通了。 企业面临两个选择：把工厂搬到东南亚，或用技术把成本降下来。AI替代人工是主力方向。 资本为何"怕死"且"去人性化"？ 资本第一反应往往不是"培养更多人才"，而是"减少对人的依赖"。 原因很简单：人有情绪，会罢工，会要求涨薪。AI不会——只要服务器运行、有电，它就能24小时工作，没有怨言，不要求股权，不会因为看了个新闻就愤而辞职。 这种对"去人性化"的强烈需求，直接冲击人力资本重建。首当其冲的，是那些受过良好教育、具有较强专业能力、思想活跃的城市中产群体。 讽刺的是：当这些高收入、有话语权、可能对现状不满的群体，突然发现自己的专业技能在AI面前变得一文不值时，他们除了重新学习做"prompt工程师"，还能做什么？ 四、AI平权的双刃剑效应 平权机遇的另一面 必须承认，AI确实带来了某种程度上的"平权"。普通人终于有了进入高门槛行业的机会：以前拍电影需要几百万的设备和专业团队，现在一个人拿着手机加AI工具就能生成一部短片；以前做建筑设计需要科班出身，现在画个小图，AI能帮你生成完整的图纸。 然而，当所有人都能轻易进入时，那条赛道还叫赛道吗？ 以设计行业为例。假设你是一个入行10年的设计师，当年熬夜画图5年，又熬了5年改图跑项目，才爬到今天的位置。你的专业技能、审美判断、行业人脉是你吃饭的家伙。 现在AI设计工具出来了。一个刚毕业的本科生，花两个月学会prompt，就能在三天内生成你花两周才能做出的方案。那个方案可能细节不够完善、结构有瑕疵、不符合某些行业的设计规范，但甲方看不出区别。甲方只看效果图，只看快不快、好不好。 于是，你的专业壁垒被砸碎了。 价格战的必然结局 技术门槛降低，必然出现大量非科班出身的人涌入。已得利益者会怎么做？他们会开始强调：专业伦理、职业操守、行业规范。听起来很正当，但实际上会用一套新的考核体系，把那些"只会用AI但没有路子的人"重新挡在门外。 以前看设计质量，现在AI让设计质量拉不开差距了。怎么筛选人？就看能不能搞定甲方、认不认识设计院的人。这些软性资源，AI帮不了你，只能靠关系、靠圈子、靠多年积累。 结果是：技术门槛降低了，但关系门槛提高了。 五、已得利益者的"言行不一" 中产在公开场合怎么说AI？全是拥抱的姿态——“我们要积极推动AI变革”、“不能落后于时代”、“要抓住数字化转型的机遇”。各种场合纷纷表态支持AI发展。 为什么？因为公开反对AI等于公开反对进步，等于承认自己已经被时代抛弃。所以他们的策略是：姿态上比谁都积极。 但落地的时候呢？他们可能把AI拦在核心业务外。 一个设计公司的高级合伙人让员工用AI写通知，让实习生用AI查资料，但涉及核心客户的资料、关键项目的方案，他会用AI吗？大概率不会。 他会用自己的经验与私人关系去摸对方的底牌。这些软性信息，这些靠多年积累的关系优势，才真正值钱。这些东西从来不"上网"，不在任何数据库里，只在他的脑子里。 六、未来职场：两个圈子的分化 技术圈与人脉圈 未来，职场可能会分化成两个圈子： 技术圈全是精通AI、一个人当十个人用的"超级个体"。他们能力强、效率高，但他们是干活的人。 人脉圈全是那些有关系、有资源、能调动各方的人。他们可能技术一般，甚至根本不懂技术细节，但他们掌握着项目的入口、审批的关卡、资源的分配。他们是分钱的人。 记住：干活的人分不到多少钱，分钱的人不干活。 AI是更好的管理工具 已得利益者明面上不会反对AI的，AI对他们来说是更好的管理工具。 AI让技术精英变得"可替代"了。以前一个技术大牛，老板还得哄着他，他敢跟老板拍桌子。现在AI把他的能力复制了N份，公司里有无数个"他"，他还哪有底气？ 而那些有关系的人，不管AI怎么变，只要审批权还在他们手里，只要项目还得过他们那一关，他们就很难被替代。 关系从未离开 这看起来像是回到"靠关系吃饭"的时代，但"关系"从未离开过，它只是在技术冲击下变得更隐蔽了。 在"拼能力的时代"，能力本身就是一种门槛，能挡住一部分关系户。但现在AI把能力门槛降低了，关系户的劣势被磨平了——你靠关系进来，AI帮你干活，你一样能把事情完成。关系的重要性反而变大了。 七、谁是AI游戏的真正赢家？ 这一轮AI博弈，赢家有两类： 第一类：资源掌控者。 他们掌握着资金、人脉、审批权。AI对他们来说是增效工具——用更少的人赚更多的钱。 第二类：极少数的超级个体。 那些把AI玩到极致、能跨界整合、有个人品牌的人。他们不依附于任何组织，自己就是一家公司。 输家是谁？中间层。那些靠专业壁垒吃饭的设计师、会计师、工程师、律师。他们的技能正在被AI替代，经验正在被AI清零。 还有那些以为"学会AI就安全了"的人。当所有人都会用AI的时候，会用的价值就是零。 ...

这两天晚上抽空用Claude Code搓了一个视频智能文稿生成器，大概功能就是，把主流平台的视频扒下来、转成文字稿，再到大模型里过一遍，顺便从视频里抽几帧，合成一个智能图文稿（还可以提取核心信息），自己再润色润色，就可以拿到其他内容平台去"灌水"发布了。 视频链接 │ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │链接解析 │───▶│音频提取 │───▶│ ASR转写 │───▶│说话人分离│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ┌────────────────────────────┘ ▼ ┌───────────┐ ┌────────────┐ │ 逐字稿输出 │ │ LLM文章生成 │ └───────────┘ └────────────┘ │ ┌────────┴────────┐ ▼ ▼ ┌──────────┐ ┌──────────┐ │ 关键帧提取│ │ 信息结构化│ └──────────┘ └──────────┘ 这次我特意选了一个我基本不熟悉的技术栈：node.js，前、后端都用node.js，耗时2晚，输出代码量2w+（包括中间有功能变更、bug修复、端到端集成等），涵盖功能代码、单元测试、端到端测试、部署配置脚本等。 我还特意关了Claude Code的plan mode、没用它Agent-Teams这种高级功能，只花了2个晚上（8、9个小时左右吧），不得不感叹，“古法编程"真的一去不复返了… 我把整个自然语言编程的过程分享出来，包括一些踩坑的思考，以供大家参考。 另外，整个项目我已经传到github：https://github.com/zhouxinyu1cp/video-text-transformer，感兴趣的朋友，可以自行查看（包括生成的需求.md、技术规划plan.md这些）。 整个开发过程，严格遵循SDD范式，但我没有全程在CC里操作，结合了一些其他工具，省点token。 1.功能展示 前端界面如下，把一个B站的视频链接扔进去： 然后解析视频元数据： 这里的视频标题、时长、作者、封面图 都和原视频能对应上： 然后"开始处理”，后端去下载视频到本地、提取音频、把音频拿去做语音识别 生成初步的文字稿： 语音识别功能，是通过我在本地部署的openAI的开源模型Whisper（base模式）提供的，提取出来的原始"逐字稿"的准确率不是那么高，但也有70%、80%左右，和视频原话大致能对得上。 这里也可以点下载TXT、或下载Word，会把原始逐字稿给下载到本地。 然后是智能图文，后端会把原始逐字稿拿到LLM中优化，同时会从下载下来的原视频中抽几帧，合成一个智能图文稿： 还可以提取重点信息： 下载下来的原始视频、音频、语音识别提取出的原始文字稿、抽出来的关键帧、生成的智能文章等，都在后端的运行时目录中特定的session目录下： 以上，就是整个视频智能文稿生成器的主要功能展示。 本来打算 买个域名部署到云上给大家试用一下，但想一想要花我的token，还是算了。感兴趣的朋友，自己clone下来部署到本地玩一玩，或者基于这个原型添加更多的功能玩玩。 2.开发过程 本篇尽量减少大段的代码展示，主要从自然语言编程角度，把实践过程给大家分享一下，特别是中间踩过的坑，以及解决思路。 本次开发，也严格按照SDD方法论进行（重要的是学会思想，不清楚的朋友，可以参看这篇文章）。 2.1 需求澄清 这个视频智能文稿生成器的需求萌芽很简单，我就想能不能把那些优秀的演讲、访谈、自述等视频（或者从国外搬运的）给一键转成图文内容（智能优化后的），然后拿到头条、小红书啥的平台"去灌水"，万一有篇爆了呢… ...

大家好，我是bytezhou，上一篇详细分析了CLAUDE.md，今天，将介绍Claude Code的一个核心工具：Slash Commands（斜杠指令），是我们日常使用CC提效的关键。 在使用CC时，我们经常会重复输入一些Prompt，例如： “请全面分析一下@/src/main/java/com/example/service/moduleA，包括该模块的核心逻辑、主要流程、上下文依赖、关键设计等，按照 @~/.claude/template/analyse.md模板 生成分析报告”。 “请按照CLAUDE.md中的代码规范，审查@com/example/listener/中的Java代码，重点关注异常处理、事务处理、并发操作是否合规”。 每次手敲、或者粘贴复制这些Prompt，繁琐、且可能出错。Slash Commands就是用来解决这个问题，把我们日常重复、高频、还有可能较复杂的工作流Prompt，浓缩、封装成一个"斜杠命令"，直接 一键调用，大大提升了工作效率。 我先介绍Claude Code的内置命令，再详细讲解如何自定义命令。 内置Slash Commands CC内置了几十个Slash Commands，我们只用掌握日常使用中最高频的命令，就能极大提效。 命令 功能 场景 /clear 清空当前会话的上下文。这是每个用户需要掌握的最基础、最重要的命令 长会话中有大量对话历史，干扰AI的"注意力"且消耗token，/clear一键清空所有上下文历史。完成一个新功能开发、或者要开始修复一个bug等，赶紧使用/clear /compact 智能"压缩"当前会话的上下文，仅保留核心摘要 先和AI进行了多轮对话 讨论清楚了某个功能设计，要开始实现了，此时可以执行/compact，保留设计的关键信息，减轻上下文压力 /rewind “回滚”，包括对话和代码的回滚，后面会单独用一篇详细介绍 在SDD的任一步骤，都可以使用/rewind回滚对话或代码，直到你满意为止 /config 对话中打开一个交互式的配置界面，进行各种环境配置 改模型、改主题、改输出风格等，直接/config进行配置 /model 动态切换底层模型 简单任务用普通模型（便宜），复杂任务用/model动态切换到高级模型（贵） /init 详解CLAUDE.md时已经介绍了，用于初始化CLAUDE.md 新项目、或老项目引用AI Coding时，初始化一份项目规范CLAUDE.md /memory 详解CLAUDE.md时也介绍了，用来随时编辑调整CLAUDE.md 随时查看CC现在加载的CLAUDE.md，或者即时编辑、即时生效 /permissions 交互式界面，管理CC的权限规则 出于安全考虑（误改系统文件、“不小心"读到环境变量的系统密码等），想对CC的行为更精细化的"管控”，可以添加允许、禁止、询问的操作规则（属于进阶用法了） /review 内置的审查代码命令（基于PR） 要审查代码时，主动调用/review，CC会触发一个更专业细致的review流程（可能会调用专注审查的Sub-Agent，后面详细介绍） /status 显示当前CC的整体状况，包括版本、模型等 偶尔看看CC的当前状态，看看配置对不对 /cost 显示当前会话的token消耗 统计"当前任务的整体开销"，评估并优化自己的Prompt方式（与钱相关） /context 详细显示当前上下文窗口的具体组成，加载的系统Prompt、CLAUDE.md、MCP、Skills、Agent等各自占用了多少token 当你发现CC开始"胡言乱语"、老是"失忆"、或者"注意力"不集中，/context看一下，到底是"谁"占用了宝贵的上下文窗口 /help CC的帮助入口，显示所有可用的Slash Commands和Skills，包括自定义的 你忘了某个命令或skill时，可以用/help查看一下 自定义Slash Commands 自定义Slash Commands，是Claude Code提供的第一个强大扩展能力，也是我们开发者转向"工作流编排"的第一步。 本篇开头举的两个例子，都是日常开发中高频、模板化的流程。把这些模板化的工作流程Prompt，固化成一个可以一键调用的"斜杠命令"，就是自定义Slash Commands。 项目级和个人级Slash Commands 和CLAUDE.md的分层加载类似，自定义命令也有两层作用域：项目级、个人级。 ...

大家好，我是bytezhou，上一篇详细介绍了@和!指令，本篇将深入分析Claude Code实践中的一个关键要素，Claude Code的"Memory系统" - CLAUDE.md。 CLAUDE.md 是啥？ 简单来说，CLAUDE.md是CC持久化的"记忆"。CLAUDE.md作为"背景知识库"，CC在启动时会自动加载它，其中的内容 会被自动注入到当前会话上下文中，无需你手动引入。 可以和@指令对比理解一下： @Server.java：就像你让某个同事看一下 Server.java 文件，然后你们的讨论聚焦在这个文件上，要优化或修bug啥的，确认清楚后就完事了。 CLAUDE.md：像是你们团队的《研发规范》，来了新人，先让他了解《研发规范》，try catch不能吞异常、新功能要写单测等，在日常工作中不必时刻提醒他，他也知道该遵守什么、该禁止什么。 总的来说，把用户反复输入的"Prompt"，固化为CC应该自动遵守的"静态内容"（项目的规范、公约），这就是 CLAUDE.md，也是人机协作的"工程化"。 扩展内容：AGENTS.md AI生态百花齐放，Claude Code有CLAUDE.md，Gemini有GEMINI.md，Cursor有Rules……不同Agent，都有一套自己的"Memory系统"，用户将面临Agent"战国时代"。值此背景下，社区和AI巨头联合推出了一个"行业标准"-AGENTS.md。 AGENTS.md作为"行业公约"，不和某个具体的AI Agent绑定，下面是官网的原文：“Think of AGENTS.md as a README for agents: a dedicated, predictable place to provide the context and instructions to help AI coding agents work on your project.” 关于AGENTS.md更多的详细内容，感兴趣的朋友请前往**官网**了解。 深入分析 CLAUDE.md 分层加载 CC在加载CLAUDE.md时，会采用一种"分层加载"机制：项目层CLAUDE.md -> 用户层CLAUDE.md，加载顺序的优先级如下： 项目层CLAUDE.md：高优先级，一般位于当前项目根目录下，即"./CLAUDE.md"，或者"./.claude/CLAUDE.md"。它维护了团队公约和规范，是团队共享的"资产"。 用户层CLAUDE.md：低优先级，一般位于当前用户的个人主目录下，即"~/.claude/CLAUDE.md"，或"用户目录/.claude/CLAUDE.md"（windows用户）。它维护的是个人偏好，对当前用户下的所有项目均生效，若和项目层CLAUDE.md中出现相同的配置项冲突，则 项目层 会覆盖掉 用户层。 除了上述总的"分层加载"机制，CC在查找CLAUDE.md时，还有两个强大的机制：向上查找、向下发现。 向上查找：启动CC时，它会从当前所在目录（pwd）一路"向上查找"，直到项目根目录（.git所在目录）、或者用户主目录（~/），沿途遇到的 CLAUDE.md 都会自动加载。 向下发现：CC还能动态发现 当前目录下 子目录的CLAUDE.md，但不会自动加载"子CLAUDE.md"，只有CC显示去读那个子目录中的文件时（通过@文件 或者 调用Shell工具），才会动态加载"子CLAUDE.md"。 这两个查找机制在单一代码仓库结构的项目中极为有用，可以构建一种"级联CLAUDE.md"，我们来看个例子。下面是一个经典的单一代码仓库项目： ...