玩转Claude Code(五)-Skills详解

大家好,我是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的核心加载机制:渐进式披露,有效解决了"知识库无限大"和"上下文窗口有限"的矛盾。 ...

April 10, 2026 · ByteZhou

AI浪潮下的职场重构:普通人如何在变局中找到位置

引言:当技术革命不再是均富机 人工智能正在以前所未有的速度重塑职场生态。这次不一样——它不只是提升效率或创造新需求,而是在压缩存量工作的人力成本。一个设计小组从五人变成两人加一堆算力,被优化的不仅是岗位数量,更是整个中产阶层的生存逻辑。 一、职场竞争逻辑的根本转变 从专业能力到工具使用效率 传统晋升路径建立在专业积累之上——十几年积累的经验、人脉,被视为不可替代的核心竞争力。但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的时候,会用的价值就是零。 ...

April 4, 2026 · ByteZhou

"古法编程"真的一去不复返了...

这两天晚上抽空用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 需求澄清 这个视频智能文稿生成器的需求萌芽很简单,我就想能不能把那些优秀的演讲、访谈、自述等视频(或者从国外搬运的)给一键转成图文内容(智能优化后的),然后拿到头条、小红书啥的平台"去灌水",万一有篇爆了呢… ...

April 3, 2026 · ByteZhou

玩转Claude Code(四):Slash Commands详解

大家好,我是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的分层加载类似,自定义命令也有两层作用域:项目级、个人级。 ...

March 29, 2026 · ByteZhou

玩转Claude Code(三):记忆系统"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",我们来看个例子。下面是一个经典的单一代码仓库项目: ...

March 27, 2026 · ByteZhou

玩转Claude Code(二):基本交互范式"@"和"!"

这一篇,我们正式进入 Claude Code**(后文简称CC)**的世界。 CC提供了一套简洁强大的交互模型,它的核心交互范式就浓缩在两个异常简单的符号里:@和!。 @:CC"感知"世界的感官,用来获取外部世界的信息。对用户来说,使用@给CC提供上下文信息,把以前的”粘贴复制“操作浓缩成一个@符号。例如,输入@Test.java,意味着告诉CC,“你先把Test.java文件看一遍,我们后面的讨论,都得基于你了解Test.java”。 !:CC”改变“世界的"手",用来"执行操作",影响外部世界。这里所说的CC"执行操作",大多是指执行Shell命令。通过!符号,把执行命令的操作无缝融入对话过程中,减少了用户的割裂感。 下面,让我们深入这两个指令。 @:Claude Code的"眼睛" 在对话流中,@指令可以随时为CC提供上下文信息,让它能"看到”你项目的全局。 @引用单个文件 这是@指令最常用的方式,可以引用任何文件,代码、配置、数据库sql、文档等等,用法如下: @/path/file @文件时,CC支持Tab自动补全(就像补全bash命令一样),@后输入前几个字符,再按下Tab就能自动补全了。下面,我们来看两个@单文件的例子。 解释代码 你拿到一个全新的代码文件,想迅速理解,可以直接@代码文件喂给CC,让它给你逐行解释: @server/src/main/java/com/github/liyue2008/rpc/server/Server.java 请详细解释一下代码 可以看到,CC会读取`Server.java`文件,输出一份"逐行注释"的代码解释,你不用手动复制粘贴代码了。 提取文件核心内容 你拿到一篇复杂的英文论文,想让CC帮你分析并提取核心内容,把提取的内容输出到一个结构化的文件中: @raft.pdf 请分析并提取该文件的核心内容,用中文组织输出,输出篇幅控制在2篇以内,生成一个`result.md`文件并写入当前目录 可以看到,CC会读取`raft.pdf`文件内容,分析后按要求用中文输出提取的核心内容,并尝试生成`result.md`结果文件,在获得我们的授权后,将结果文件写入当前目录下: @引用整个目录 当需要宏观视角时(横跨多个文件),此时,@可以引用整个目录: @/path/directory CC在用@读取目录时,默认能感知Git,它会先找到根目录下.gitignore文件,然后把.gitignore中指定的目录和文件全部忽略掉,不会去加载。这样既减少了token浪费,又避免了无关文件的干扰。我们同样来看一个@目录的例子。 分析新项目 你刚拿到一个全新的项目,对它一无所知,想快速上手,可以直接把整个项目目录喂给CC(不超过上下文最大窗口的前提下),让CC帮你分析新项目的整体架构、主要功能、核心流程等: @./ 请分析当前项目的整体结构、主要功能、核心流程和相关依赖 可以看到,CC扫描了整个项目,把相关Java代码都读了一遍,整体分析理解后,输出了详细的项目结构、核心流程、主要依赖等,堪比资深的研发同事为你做项目简介。 @作为CC的"眼睛",将真实世界的信息转化为CC能够理解的上下文。掌握@,是掌握Claude Code的第一步。 !:Claude Code的"手" 在对话流中,!指令可以随时执行Shell命令(无需退出CC),打通"想"(云端大模型)和"做"(本地环境)之间的壁垒。 手动执行命令 这是!直接的用法,在对话中手动执行Shell命令,用法如下: ! {shell_command} 我们来看一个例子。 查看当前目录所有文件 你想看一下项目的当前目录中有哪些文件,直接执行: ! ls -alh 终端会执行这个Shell命令,把结果返给CC: !命令的输出,会自动加入当前对话的上下文中,被CC所感知。这个特性很强大,后续对话可以基于!命令的输出,做进一步的操作。 上面的例子中,列出了当前目录下的所有文件,现在我们在README.md文件后加一句话: 在`README.md`文件后追加一句话: "测试!命令的输出能被感知到"。 CC直接在`README.md`末尾加上了这句话。 Claude Code自主执行命令 让CC自主决定执行什么命令(what)、什么时候执行(when),这才是!的AI原生用法。当CC判断需要执行Shell命令来完成任务,它会主动发起Tool Call(工具调用),先找你审批,等你审批通过后,它才执行。 我们来看一个例子,我想知道当前连的局域网的公网ip是多少,可以直接问CC: 请帮我查一下,当前局域网暴露的公网ip是多少? CC思考之后,想发起一个Bash调用(执行curl命令)查询公网ip,它先来找你审批,你同意后,它才执行Bash调用: 最后查到公网ip,结束本次任务。 以上,就是Claude Code的核心交互范式,掌握了@和!,你就拥有了与Claude Code协作的基础能力。 用户发出指令 -> CC用@看 -> 云端大模型思考 -> CC用!做 -> 执行结果反馈给用户,这个反馈循环,就是我们与Claude Code的协作日常。 ...

March 25, 2026 · ByteZhou

玩转Claude Code(一):基本介绍与环境搭建

跟着我一起玩转Claude Code! 1、基本介绍 Claude Code是Anthropic公司推出的CLI AI Agent(命令行AI智能体),最初锚向的是AI Coding工具,但发展到现在,我对它的理解,已经不仅仅只是一个"编程Agent"了。 纵观市面上主流的 AI Coding 工具,GitHub Copilot、Windsurf、Cursor等,百花齐放。“御三家” Codex(OpenAI的)、Gemini(Google的)、Claude Code(Anthropic的)均有各自的特点和擅长的赛道,但个人体验后,我愿称Claude Code为"最强"(纯个人观点,非引战)。 Claude Code的核心设计理念就是一个**“自主自治的工作流引擎”**,它能从整体上理解项目全局上下文,自主规划并执行复杂的端到端任务,拥有Hooks、Commands、Skills、MCP等丰富的自定义扩展能力,是团队中不可或缺的"自己搬砖的虚拟成员"。 缔造了"事实标准":Claude Code可以说是CLI AI Agent领域的开创者,许多"游戏规则"都是它定的,比如 “@“注入上下文、”!“执行shell命令、”/“发起斜杠命令等,后续的工具大多都借鉴效仿了其设计。 实现了完整方法论:Claude Code将SDD方法论实现得最完整、最体系化,包括上下文管理、安全限制、MCP扩展等。掌握了它,也就掌握了底层的使用思想,可以无缝切换到其他工具。 拥有最繁荣的生态:Claude Code凭借其强大的先发优势形成了正向的生态循环,吸引大量用户使用,催生出更多第三方工具和更多模型的支持,国内的主流模型都提供了对Claude Code的支持,比如minimax、GLM、Kimi等。掌握了它,你就接入了一个不断发展的AI生态。 AI时代,我认为每个开发者都要掌握Claude Code的使用。但相比开发者而言,我更推荐产品经理来学习Claude Code,一旦你掌控了它,就拥有了一支由"架构师”+“技术leader”+“资深研发者们"组成的专业"虚拟研发团队”,配合你强大的产品思维,完全可以"一人成军”,踏上OPC(一人公司)之路。 2、环境搭建 现在正式开始搭建环境,总体思路就是:Claude Code Agent + 国产大模型。 Anthropic公司原生的大模型真的太贵了,另外,它也封禁了国内ip(通过香港的vpn跳过去好像也不行)。国内用户一般做法是,给Claude Code这辆"超跑"换一个"国产引擎"(国产大模型),它的"驾驶操作"是一样的,无非就是"驾驶体验"要稍差一点,一旦你学会了如何"驾驶",可以无缝切回它的原生"引擎"。 2.1 安装Claude Code 我的环境是macOS,以macOS为例来说明如何安装Claude Code。 我在macOS中采用Homebrew来安装Claude Code,先安装Homebrew,再用Homebrew来安装Claude Code。 打开终端,先安装xcode: xcode-select --install xcode安装后,用官方脚本安装Homebrew: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Homebrew安装后,根据终端的提示,把Homebrew的环境变量写到用户的配置里,M芯片的Mac用户执行以下命令: echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zshrc source ~/.zshrc Intel芯片的Mac用户则执行以下命令: echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.bash_profile source ~/.bash_profile Homebrew安装好后,可以验证一下是否能用: ...

March 23, 2026 · ByteZhou

基于Claude Code的SDD实战(三):任务拆解及自动实现

大家好,我是bytezhou,上一篇进行了SDD第二步-技术规划,今天将进入本次SDD实战的收尾-任务拆解及自动实现。 1、任务拆解 AI技术规划后输出 plan.md,距离代码,中间还缺少一步:把宏观的plan.md,拆分成一系列带依赖关系的、原子化的具体开发任务 tasks.md。技术细节已经齐全,但这个阶段要注意拆分的任务粒度和执行顺序。输入以下Prompt: @specs/spec.md @plan.md 你现在是技术leader,请根据`spec.md`和`plan.md`,**将`plan.md`中的技术方案,拆分成原子化的、详细的、带依赖关系的、可被直接执行的任务列表。** 核心要求: 1. 任务粒度:每个任务只实现最小化的功能(只涉及一个文件的变更)。**务必禁止:"实现所有功能"的大任务。** 2. TDD:必须遵守"测试先行",先生成测试、再去实现。 3. 并行标记:对没有依赖关系的任务,标记【P】。 4. 执行顺序(以下面的为准): **1: 数据结构定义** **2: Github数据获取(请遵循TDD)** **3: 生成Markdown文件(请遵循TDD)** **4: 程序入口集成(请遵循TDD)** 完成后,将生成的任务列表写入到项目根目录下的tasks.md文件中。 下面是AI拆分任务的过程: 最终,AI会生成一份详尽的任务列表 tasks.md,我把它贴出来: # down_issue 任务列表 ## 执行顺序 1. 数据结构定义 (types.go) 2. GitHub 数据获取 (parser + github) 3. 生成 Markdown (markdown) 4. 程序入口集成 (cmd) --- ## 阶段一:数据结构定义 ### 1.1 【P】创建 github/types.go - 定义数据结构 **文件**: `internal/github/types.go` **内容**: 定义 Issue、PullRequest、Discussion、Comment 结构体,以及 ItemType 枚举和 Content 接口 **依赖**: 无 **任务**: 实现以下数据结构和接口 ```go // ItemType 表示 GitHub 内容的类型 type ItemType int const ( TypeIssue ItemType = iota TypePullRequest TypeDiscussion ) // Issue 表示 GitHub Issue type Issue struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // PullRequest 表示 GitHub Pull Request type PullRequest struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Discussion 表示 GitHub Discussion type Discussion struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Comment 表示评论/回复 type Comment struct { Body string Author string CreatedAt time.Time } // Content 统一的内容接口 type Content interface { GetTitle() string GetBody() string GetAuthor() string GetCreatedAt() time.Time GetURL() string GetComments() []Comment } ``` --- ## 阶段二:GitHub 数据获取 ### 2.1 【P】创建 parser/parser_test.go - URL 解析测试 **文件**: `internal/parser/parser_test.go` **依赖**: 无 **任务**: 编写表格驱动测试,覆盖以下用例: - 有效的 Issue URL (`https://github.com/owner/repo/issues/123`) - 有效的 PR URL (`https://github.com/owner/repo/pull/123`) - 有效的 Discussion URL (`https://github.com/owner/repo/discussions/123`) - 无效 URL 格式 - 缺失关键部分 ### 2.2 【P】创建 parser/parser.go - URL 解析实现 **文件**: `internal/parser/parser.go` **依赖**: 无 **任务**: 实现 `Parse(url string) (*ParseResult, error)` 函数 - 解析 GitHub URL,识别类型(issue/pull/discussions) - 提取 owner、repo、number - 返回 ParseResult 或错误 ### 2.3 【P】创建 github/github_test.go - GitHub API 测试 **文件**: `internal/github/github_test.go` **依赖**: types.go **任务**: 编写表格驱动测试,使用 HTTP test server mock GitHub API - 测试 FetchIssue - 测试 FetchPullRequest - 测试 FetchDiscussion - 测试 404 错误处理 - 测试网络错误处理 ### 2.4 【P】创建 github/github.go - GitHub API 客户端 **文件**: `internal/github/github.go` **依赖**: types.go **任务**: 实现 `Client` 接口和 `NewClient(token string) Client` - FetchIssue(owner, repo string, number int) (*Issue, error) - FetchPullRequest(owner, repo string, number int) (*PullRequest, error) - FetchDiscussion(owner, repo string, number int) (*Discussion, error) - 使用 net/http 调用 GitHub REST API - 支持 GITHUB_TOKEN 认证 ### 2.5 【P】创建 parser/parser.go 的 GetFilename 函数测试 **文件**: `internal/parser/parser_test.go` (追加) **依赖**: parser.go **任务**: 追加测试用例测试 GetFilename 函数 - Issue: `{owner}_{repo}_issue_{number}.md` - PR: `{owner}_{repo}_pr_{number}.md` - Discussion: `{owner}_{repo}_discussion_{number}.md` ### 2.6 【P】创建 parser/parser.go 的 GetFilename 函数实现 **文件**: `internal/parser/parser.go` (追加) **依赖**: parser.go **任务**: 实现 `GetFilename(itemType ItemType, owner, repo string, number int) string` ### 2.7 创建 fetcher/fetcher_test.go - fetcher 测试 **文件**: `internal/fetcher/fetcher_test.go` **依赖**: parser, github **任务**: 编写表格驱动测试 - 测试 Fetch 成功获取 Issue - 测试 Fetch 成功获取 PR - 测试 Fetch 成功获取 Discussion - 测试无效 URL 错误 ### 2.8 创建 fetcher/fetcher.go - 数据获取实现 **文件**: `internal/fetcher/fetcher.go` **依赖**: parser, github **任务**: 实现 `Fetch(url string, client github.Client) (Content, error)` - 组合 parser.Parse 和 github.Client.Fetch* - 返回统一的 Content 接口 --- ## 阶段三:生成 Markdown ### 3.1 创建 markdown/markdown_test.go - Markdown 生成测试 **文件**: `internal/markdown/markdown_test.go` **依赖**: github/types.go **任务**: 编写表格驱动测试 - 测试 GenerateIssue 生成正确格式 - 测试 GeneratePullRequest 生成正确格式 - 测试 GenerateDiscussion 生成正确格式 - 测试 GetFilename 返回正确文件名 ### 3.2 创建 markdown/markdown.go - Markdown 生成实现 **文件**: `internal/markdown/markdown.go` **依赖**: github/types.go **任务**: 实现以下函数 - `Generate(content github.Content) string` - `GenerateIssue(issue *github.Issue) string` - `GeneratePullRequest(pr *github.PullRequest) string` - `GenerateDiscussion(discussion *github.Discussion) string` - `GetFilename(itemType parser.ItemType, owner, repo string, number int) string` --- ## 阶段四:程序入口集成 ### 4.1 创建 cmd/down_issue/main.go - CLI 入口 **文件**: `cmd/down_issue/main.go` **依赖**: parser, github, fetcher, markdown **任务**: 实现 CLI 入口 - 解析命令行参数 (flag) - 处理 -o/--output 输出目录参数 - 调用 fetcher.Fetch 获取内容 - 调用 markdown.Generate 生成文件 - 错误处理和退出码 ### 4.2 创建 Makefile - 构建脚本 **文件**: `Makefile` **依赖**: 无 **任务**: 定义以下目标 - `go build` - 构建项目 - `go test` - 运行所有测试 - `go vet` - 代码检查 - `clean` - 清理构建产物 ### 4.3 创建 go.mod - 模块定义 **文件**: `go.mod` **依赖**: 无 **任务**: 定义模块名 `github.com/user/down_issue`,Go 版本 >= 1.26 --- ## 任务状态汇总 | 序号 | 任务 | 文件 | 依赖 | 状态 | |------|------|------|------|------| | 1.1 | 创建 github/types.go | internal/github/types.go | 无 | ⬜ | | 2.1 | 创建 parser/parser_test.go | internal/parser/parser_test.go | 无 | ⬜ | | 2.2 | 创建 parser/parser.go | internal/parser/parser.go | 无 | ⬜ | | 2.3 | 创建 github/github_test.go | internal/github/github_test.go | types.go | ⬜ | | 2.4 | 创建 github/github.go | internal/github/github.go | types.go | ⬜ | | 2.5 | 追加 parser GetFilename 测试 | internal/parser/parser_test.go | parser.go | ⬜ | | 2.6 | 实现 parser GetFilename | internal/parser/parser.go | parser.go | ⬜ | | 2.7 | 创建 fetcher/fetcher_test.go | internal/fetcher/fetcher_test.go | parser, github | ⬜ | | 2.8 | 创建 fetcher/fetcher.go | internal/fetcher/fetcher.go | parser, github | ⬜ | | 3.1 | 创建 markdown/markdown_test.go | internal/markdown/markdown_test.go | github/types | ⬜ | | 3.2 | 创建 markdown/markdown.go | internal/markdown/markdown.go | github/types | ⬜ | | 4.1 | 创建 cmd/down_issue/main.go | cmd/down_issue/main.go | 所有模块 | ⬜ | | 4.2 | 创建 Makefile | Makefile | 无 | ⬜ | | 4.3 | 创建 go.mod | go.mod | 无 | ⬜ | --- ## 并行执行分组 **【P】第一组(无依赖,可并行)**: - 1.1, 2.1, 2.2, 2.3, 2.4 **【P】第二组(依赖第一组,可并行)**: - 2.5, 2.6, 2.7, 3.1 **第三组(依赖第二组,顺序执行)**: - 2.8, 3.2, 4.1, 4.2, 4.3 【再次提醒:一定要审查!】 ...

March 21, 2026 · ByteZhou

基于Claude Code的SDD实战(二):技术规划

大家好,我是bytezhou,上一篇给大家实践了SDD第一步-定义意图,接下来进入SDD第二步:技术规划。 传统范式下,产品经理输出PRD后,架构师拿着这份PRD进行技术选型(用Java还是Go)、架构设计(整体流程、分层设计)、模块划分(微服务拆分、数据建模)、API设计(前后端交互接口等)等,产出项目概要设计、详细设计文档等。 SDD范式下,“业务"映射在澄清后的、结构化的需求规范spec.md中,AI作为"架构师”,我们开发者则作为"工作流设计者",指挥引导"AI架构师"把高层级的spec.md,“编译"成一份详尽的、结构化的技术规划方案 plan.md。废话不多说,我们进入正题。 切回项目目录,打开Claude Code(关闭plan mode),我们先来根据spec.md,指定技术栈,生成项目结构,同时让AI生成一份API声明(不一定严格遵守),作为后续输入(指导它思考)。输入以下Prompt: 1 2 3 4 5 @specs/spec.md 你是一名资深的Go语言架构师,请严格参考Go语言最佳实践(特别注意包内聚原则),根据`spec.md`,规划并创建整体的项目目录结构。 生成目录后,请在项目根目录下创建`api.md`文件,描述一下各个包对外暴露的主要接口(Interface/Function签名),作为后续开发的指导。 AI会迅速执行以上操作,按照Go最佳实践来生成项目结构,下面是它的执行过程: 可以看到,AI不仅创建了项目目录、生成了api.md,还进行了go mod初始化和makefile的生成,一气呵成。 以下是生成的 api.md: # API 文档 本文档描述 `down_issue` 项目各包对外暴露的主要接口,作为后续开发的指导。 --- ## 1. `internal/parser` - URL 解析 ### 职责 解析 GitHub URL,提取 owner、repo、number 及类型信息。 ### 接口签名 ```go // ItemType 表示 GitHub 内容的类型 type ItemType int const ( TypeIssue ItemType = iota TypePullRequest TypeDiscussion ) // ParseResult 解析结果 type ParseResult struct { Type ItemType // 类型:Issue、PR、Discussion Owner string // 仓库所有者 Repo string // 仓库名 Number int // 编号 } // Parse(url string) (*ParseResult, error) // 解析 GitHub URL,返回解析结果 // 支持格式: // - https://github.com/{owner}/{repo}/issues/{number} // - https://github.com/{owner}/{repo}/pull/{number} // - https://github.com/{owner}/{repo}/discussions/{number} // 错误:URL 格式不正确时返回错误 ``` --- ## 2. `internal/github` - GitHub API 客户端 ### 职责 封装 GitHub REST API 调用,获取 Issue、PR、Discussion 及其评论。 ### 接口签名 ```go // Issue 表示 GitHub Issue 数据结构 type Issue struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // PullRequest 表示 GitHub Pull Request 数据结构 type PullRequest struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Discussion 表示 GitHub Discussion 数据结构 type Discussion struct { Number int Title string Body string Author string CreatedAt time.Time URL string Comments []Comment } // Comment 表示评论/回复 type Comment struct { Body string Author string CreatedAt time.Time } // Client GitHub API 客户端接口 type Client interface { // FetchIssue 获取 Issue 及其评论 FetchIssue(owner, repo string, number int) (*Issue, error) // FetchPullRequest 获取 PR 及其评论 FetchPullRequest(owner, repo string, number int) (*PullRequest, error) // FetchDiscussion 获取 Discussion 及其评论 FetchDiscussion(owner, repo string, number int) (*Discussion, error) } // NewClient(token string) Client // 创建 GitHub API 客户端 // token: 可选的 GITHUB_TOKEN,用于私有仓库或提高 API 速率限制 ``` --- ## 3. `internal/fetcher` - 数据获取逻辑 ### 职责 组合 parser 和 github 包,提供高层的数据获取接口。 ### 接口签名 ```go // Content 统一的内容接口 type Content interface { GetTitle() string GetBody() string GetAuthor() string GetCreatedAt() time.Time GetURL() string GetComments() []github.Comment } // Fetch(url string, client github.Client) (Content, error) // 根据 URL 自动识别类型,获取对应内容 // 返回 Content 接口,支持 Issue、PR、Discussion 的统一处理 ``` --- ## 4. `internal/markdown` - Markdown 生成 ### 职责 将获取的内容转换为格式化的 Markdown 文件。 ### 接口签名 ```go // GenerateIssue(issue *github.Issue) string // 将 Issue 转换为 Markdown 格式字符串 // GeneratePullRequest(pr *github.PullRequest) string // 将 PullRequest 转换为 Markdown 格式字符串 // GenerateDiscussion(discussion *github.Discussion) string // 将 Discussion 转换为 Markdown 格式字符串 // Generate(content github.Content) string // 统一生成接口,根据 content 类型自动选择对应生成函数 ``` ### 输出文件名格式 ```go // GetFilename(itemType parser.ItemType, owner, repo string, number int) string // 返回格式: // - Issue: {owner}_{repo}_issue_{number}.md // - PullRequest: {owner}_{repo}_pr_{number}.md // - Discussion: {owner}_{repo}_discussion_{number}.md ``` --- ## 5. `cmd/down_issue` - CLI 入口 ### 职责 命令行接口,协调各模块完成下载任务。 ### main.go 逻辑 ```go // 用法: // down_issue <url> # 下载到当前目录 // down_issue <url> -o <path> # 下载到指定目录 // 主要流程: // 1. 解析命令行参数(url, -o output-dir) // 2. 调用 parser.Parse() 解析 URL // 3. 创建 github.Client(可选使用 GITHUB_TOKEN) // 4. 调用 fetcher.Fetch() 获取内容 // 5. 调用 markdown.Generate() 生成 Markdown // 6. 调用 markdown.GetFilename() 获取文件名 // 7. 写入文件到指定目录 ``` --- ## 模块依赖关系 ``` cmd/down_issue/main.go │ ├── parser.Parse() │ └── 返回 ItemType, Owner, Repo, Number │ ├── github.NewClient(token) │ └── 返回 github.Client 接口 │ ├── fetcher.Fetch(url, client) │ ├── 调用 parser.Parse() │ ├── 调用 github.Client.Fetch*() │ └── 返回 Content 接口 │ └── markdown.Generate(content) └── markdown.GetFilename() ``` --- ## 错误处理约定 - 所有错误使用 `fmt.Errorf("包名: 描述: %w", err)` 包装 - 网络错误、解析错误、API 错误直接透传 - 不存在的资源返回标准 error,由 main.go 输出到 stderr 并以非零状态码退出 这是一份非常详尽的api文档,包含了各模块的职责描述、核心数据结构定义、主要接口声明、模块间的依赖关系等,项目已经初具"骨架”。 ...

March 19, 2026 · ByteZhou

基于Claude Code的SDD实战(一):定义意图

大家好,我是bytezhou,今天实践SDD研发范式,直观感受一下SDD的强大威力! 环境: macOS:14.8.4 Claude Code:v2.1.26 模型:MiniMax-M2.5(非广告,它的Coding Plan套餐性价比高,这儿有邀请链接https://platform.minimaxi.com/subscribe/token-plan?code=9BE5kxxIhC&source=link,刚在码字时,MiniMax-M2.7发布了…) (另外,关于Claude Code的安装配置和基本使用,这里就不详细展开了,后面打算单独出一个Claude Code系列,给大家分享一下我的使用心得) 需求的萌芽: 每次逛github的时候,对于一些我感兴趣的开源项目,它的Issues、PR、Discussions我都会去看,里面一些讨论挺有价值的,有时候就想能不能把它们留个档,但打开github页面一个个去复制也太傻了,此时,做个小工具的想法油然而生。 模糊的想法: “我要做个小工具,给它一个github的URL链接,就能把对应的Issues、PR、或Discussions的内容扒下来,不用存数据库,转成一个带格式的markdown文件就行。这个小工具就做成命令行的形式吧,简单方便。” 传统范式中,这种模糊的想法,需要产品经理和"用户"反复沟通、来回掰扯、深度挖掘,最终达成一致,输出一份PRD(需求文档)。 SDD范式下,由AI作为产品经理,开发者作为"用户",我们开发者和AI通过多轮的探索式对话,来进行"需求澄清",把"模糊的想法"转化成结构化的需求规范spec.md,这就是SDD的第一步,意图定义。下面,我们进入正题。 第一轮对话: 打开终端,创建一个目录,切进去 启动Claude Code,输入下面的Prompt,向AI提问: 1 2 3 4 5 我现在想实现一个小工具`down_issue`。 你是一位经验丰富的产品经理,现在需要你向我提问,帮我澄清需求,最终产出一份高质量的`spec.md`。 我初步想法是:做一个命令行工具,输入一个GitHub的Issue、PR、或Discussion的URL,它就能自动把内容扒下来并将其转换为Markdown文件。 现在请开始提问。 AI作为产品经理,会向你输出一系列高质量问题: 第二轮对话: 基于第一轮对话AI提出的问题,我做出了如下回复: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 **1. 关于输出:** - 文件默认保存在当前目录。**可选** 可通过命令行参数 -o 来指定输出目录。 - 文件名采用 {user}_{repo}_{issue_number}.md,或者 {user}_{repo}_{pr_number}.md **2. 关于内容范围:** Issue/PR/Discussion都必须包含:标题、作者、创建时间、主要内容、所有评论。 **差异处理**: - 对于PR:不用下载diff。 **必须**:保留原始URL链接。 **3. 关于认证与权限:** 默认支持公开仓库即可。 **认证方式(可选):**仅支持通过环境变量 `GITHUB_TOKEN`传入PAT。 **4. 关于媒体处理:** - 仅保留图片的引用(URL引用)即可,无需下载图片。 **5. 关于错误处理:** - 如果Issue不存在,直接报错退出即可,错误信息打在标准输出上。 - 超时直接透传错误信息即可,不用重试。 AI思考后,会进一步帮你"具象化"问题,下面是它给到的回复: ...

March 19, 2026 · ByteZhou