[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-875":3,"consumer-news-interaction-875":40,"consumer-news-related-875":43},{"detail":4,"item":35},{"card":5,"schemaVersion":22,"fields":23,"content":29},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":19,"tags":20,"resolved":21},"NEWS_ARTICLE:875","news","NEWS_ARTICLE",875,"资讯","别急着翻译 SKILL.md：我做了一个专门拆解 Skill 设计的工具","博客园","别急着翻译 SKILL.md：我做了一个专门拆解 Skill 设计的工具 第一次打开一份复杂的 SKILL.md，很多人的反应都是从头往下读。 每句话似乎都认识，连在一起却不一定明白：为什么这里用了 MUST？为什么执行前要读取这些文件？状态由谁维护？AI 做到什么程度才算完成？如果两条指令发生冲突","","\u002Fnews\u002F875",[17,18],"2026","综合技术",{},[18],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":24,"categoryName":18,"summary":13,"description":13,"publishTime":25,"updateTime":26,"sourceUrl":27,"language":28},"Raiden_xin","2026-09-01T11:20","2026-09-02T20:37:52","https:\u002F\u002Fwww.cnblogs.com\u002FRaiden-xin\u002Fp\u002F22787689","中文",{"format":30,"policy":31,"normalized":21,"html":32,"text":33,"wordCount":34,"hasBody":21},"HTML","NEWS_CONTENT_V1","别急着翻译 SKILL.md：我做了一个专门拆解 Skill 设计的工具\n\u003Cp>第一次打开一份复杂的 \u003Ccode>SKILL.md\u003C\u002Fcode>，很多人的反应都是从头往下读。\u003C\u002Fp>\n\u003Cp>每句话似乎都认识，连在一起却不一定明白：为什么这里用了 \u003Ccode>MUST\u003C\u002Fcode>？为什么执行前要读取这些文件？状态由谁维护？AI 做到什么程度才算完成？如果两条指令发生冲突，到底应该听谁的？\u003C\u002Fp>\n\u003Cp>真正难懂的往往不是英文，而是藏在文字背后的工作流。\u003C\u002Fp>\n\u003Cp>这也是我写 \u003Ccode>skill-analyzer\u003C\u002Fcode> 的原因。\u003C\u002Fp>\n\u003Ch2>它不是翻译器\u003C\u002Fh2>\n\u003Cp>\u003Ccode>skill-analyzer\u003C\u002Fcode> 的目标很明确：不只告诉你一份 Skill 写了什么，还要解释它为什么这样写。\u003C\u002Fp>\n\u003Cp>比如下面这条规则：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Read all contextFiles before implementation.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>直译很简单：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>实现前读取所有上下文文件。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>但只翻译到这里，实际上没有解决多少问题。\u003C\u002Fp>\n\u003Cp>更值得追问的是：这条规则在防什么？\u003C\u002Fp>\n\u003Cp>它防的是 AI 只看当前任务就开始写代码，遗漏需求、设计文档或者项目约束。它还隐含了一层权责划分：外部系统负责决定“应该读取哪些文件”，AI 负责完整读取并理解。换句话说，Context Discovery 和 Context Consumption 被分开了。\u003C\u002Fp>\n\u003Cp>这才是规则真正的设计价值。\u003C\u002Fp>\n\u003Cp>\u003Ccode>skill-analyzer\u003C\u002Fcode> 做的，就是把这些藏在字面下面的东西挖出来。\u003C\u002Fp>\n\u003Ch2>一份 Skill，至少要看懂五件事\u003C\u002Fh2>\n\u003Cp>分析一份 Skill 时，我最关心的不是它有多少章节，而是下面几个问题。\u003C\u002Fp>\n\u003Cp>第一，它到底要解决什么问题。\u003C\u002Fp>\n\u003Cp>有些 Skill 负责生成代码，有些负责审查，有些负责操作外部工具，还有些负责控制一套完整工作流。名字和简介只能告诉我们大致方向，真正的能力边界要从触发条件、输入、步骤和输出里判断。\u003C\u002Fp>\n\u003Cp>第二，AI 收到它以后会怎么行动。\u003C\u002Fp>\n\u003Cp>很多 Skill 表面上是一篇说明文，实际上描述的是一张流程图。里面可能有固定步骤、条件分支、循环、暂停点和人工确认节点。只有把这些内容重新排列成执行顺序，才能看出 AI 在每一步需要什么输入、产生什么输出，以及什么时候可以进入下一步。\u003C\u002Fp>\n\u003Cp>第三，谁说了算。\u003C\u002Fp>\n\u003Cp>一份 Skill 里可能同时存在用户要求、项目文件、CLI 状态、API 返回值、Artifact、内置规则和操作建议。这些信息不是同一个等级。\u003C\u002Fp>\n\u003Cp>用户可以提出需求，但未必能绕过系统状态；Guidance 可以帮助执行，但不能覆盖 \u003Ccode>MUST\u003C\u002Fcode>；AI 可以读取任务状态，却不一定有权自行修改状态。如果 Skill 没有说明冲突时的优先级，执行结果就很容易随着模型的理解发生漂移。\u003C\u002Fp>\n\u003Cp>第四，什么叫完成。\u003C\u002Fp>\n\u003Cp>这里需要区分两个经常被混在一起的概念。\u003C\u002Fp>\n\u003Cp>\u003Ccode>Completion Definition\u003C\u002Fcode> 回答的是“做到什么程度算完成”，例如指定功能已经实现。\u003C\u002Fp>\n\u003Cp>\u003Ccode>Completion Evidence\u003C\u002Fcode> 回答的是“凭什么证明它完成了”，例如构建通过、测试通过、场景验证通过。\u003C\u002Fp>\n\u003Cp>只有完成定义，没有完成证据，最后仍然可能退化成“AI 觉得差不多了”。对于需要稳定执行的 Skill，这通常是一个明显缺口。\u003C\u002Fp>\n\u003Cp>第五，有哪些设计值得复用。\u003C\u002Fp>\n\u003Cp>分析 Skill 的意义不应停留在评价别人写得好不好。更实际的收获，是把其中有效的做法提炼出来：先获取真实状态再行动、把上下文范围交给外部系统决定、明确暂停条件、保护任务范围、用客观结果证明完成。\u003C\u002Fp>\n\u003Cp>这些方法换一个业务场景仍然成立。\u003C\u002Fp>\n\u003Ch2>它具体会分析什么\u003C\u002Fh2>\n\u003Cp>\u003Ccode>skill-analyzer\u003C\u002Fcode> 会先完整读取目标 Skill，而不是看到主要流程后就停止。文件末尾的 Guardrails、Notes、Constraints 和完成条件，往往比开头的功能介绍更能决定 AI 最终会做什么。\u003C\u002Fp>\n\u003Cp>如果目标 Skill 引用了必要的规则文件或上下文文件，也需要继续追踪这些依赖。否则分析出来的只是一个孤立的 \u003Ccode>SKILL.md\u003C\u002Fcode>，不是它真实运行时受到的完整约束。\u003C\u002Fp>\n\u003Cp>完成读取后，它会重新还原执行流程，并从行为约束、上下文管理、状态管理、事实源、指令优先级、任务范围、异常处理和完成证据等角度拆解设计。\u003C\u002Fp>\n\u003Cp>最后还会反过来追问：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>作者在防止 AI 出现什么问题？\u003C\u002Fli>\n \u003Cli>哪些规则删除后会明显改变行为？\u003C\u002Fli>\n \u003Cli>哪些内容只是帮助理解的辅助说明？\u003C\u002Fli>\n \u003Cli>当前设计有没有冲突、遗漏或过度约束？\u003C\u002Fli>\n \u003Cli>如果自己写 Skill，哪些结构可以直接借鉴？\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>我希望它给出的不是一份“内容摘要”，而是一张 Skill 的设计剖面图。\u003C\u002Fp>\n\u003Ch2>哪些时候适合使用\u003C\u002Fh2>\n\u003Cp>当你下载了一份陌生的 Skill，想判断它是否值得安装时，可以先用它分析整体行为和权限边界。\u003C\u002Fp>\n\u003Cp>当你正在学习别人如何设计 Agent 工作流时，可以让它重点还原执行流程，看看规则如何控制 AI 的行动顺序。\u003C\u002Fp>\n\u003Cp>当你已经写好自己的 Skill，却发现执行结果不稳定时，可以重点检查指令优先级、状态事实源、暂停条件和完成证据。\u003C\u002Fp>\n\u003Cp>它也适合比较同一份 Skill 的两个版本。很多改动看起来只是增加了几条规则，实际影响的可能是 AI 的权限、任务范围或者完成判断方式。\u003C\u002Fp>\n\u003Cp>例如可以直接这样使用：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>使用 skill-analyzer 分析这个 SKILL.md。\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>也可以缩小范围：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>分析这个 Skill，重点检查指令优先级和完成标准。\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>或者比较版本：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>比较这个 Skill 的 v1 和 v2，说明工作流和行为边界发生了哪些变化。\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>它不替你做决定\u003C\u002Fh2>\n\u003Cp>\u003Ccode>skill-analyzer\u003C\u002Fcode> 不是一个自动打分器，也不会因为规则写得多，就判断一份 Skill 更专业。\u003C\u002Fp>\n\u003Cp>长并不等于严谨。重复规则可能是在强化关键约束，也可能只是缺少整理；人工确认节点可以降低风险，太多了也会让工作流变得支离破碎；严格限制 AI 的权限有助于保持稳定，但同样可能损失执行效率。\u003C\u002Fp>\n\u003Cp>因此，它会把“原 Skill 的设计”和“对这份设计的评价”分开。\u003C\u002Fp>\n\u003Cp>前者回答作者写了什么，后者讨论这些做法是否合理。这样既不会把分析者的偏好冒充成原文规定，也方便使用者根据自己的场景作出判断。\u003C\u002Fp>\n\u003Ch2>我更关心的是“为什么”\u003C\u002Fh2>\n\u003Cp>做 \u003Ccode>skill-analyzer\u003C\u002Fcode> 时，我给它定下的最终标准不是“能把 Skill 讲明白”，而是完成三层转换：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>看懂它写了什么\n        ↓\n理解它为什么这样写\n        ↓\n知道自己的 Skill 应该怎么写\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Skill 的价值从来不只在几段提示词里。它真正决定的是 AI 在什么情况下行动、依据什么行动、遇到问题时是否暂停，以及拿什么证明任务已经完成。\u003C\u002Fp>\n\u003Cp>当这些问题能够被说清楚，一份 Skill 才不再是堆叠起来的指令，而是一套可以检查、讨论和持续改进的工作方法。\u003C\u002Fp>\n\u003Cp>项目地址：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FRaidenXin\u002Fskill-warehouse\u002Ftree\u002Fmain\u002Fskill-analyzer\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">skill-analyzer\u003C\u002Fa>\u003C\u002Fp>","别急着翻译 SKILL.md：我做了一个专门拆解 Skill 设计的工具 第一次打开一份复杂的 SKILL.md，很多人的反应都是从头往下读。 每句话似乎都认识，连在一起却不一定明白：为什么这里用了 MUST？为什么执行前要读取这些文件？状态由谁维护？AI 做到什么程度才算完成？如果两条指令发生冲突，到底应该听谁的？ 真正难懂的往往不是英文，而是藏在文字背后的工作流。 这也是我写 skill-analyzer 的原因。 它不是翻译器 skill-analyzer 的目标很明确：不只告诉你一份 Skill 写了什么，还要解释它为什么这样写。 比如下面这条规则： Read all contextFiles before implementation. 直译很简单： 实现前读取所有上下文文件。 但只翻译到这里，实际上没有解决多少问题。 更值得追问的是：这条规则在防什么？ 它防的是 AI 只看当前任务就开始写代码，遗漏需求、设计文档或者项目约束。它还隐含了一层权责划分：外部系统负责决定“应该读取哪些文件”，AI 负责完整读取并理解。换句话说，Context Discovery 和 Context Consumption 被分开了。 这才是规则真正的设计价值。 skill-analyzer 做的，就是把这些藏在字面下面的东西挖出来。 一份 Skill，至少要看懂五件事 分析一份 Skill 时，我最关心的不是它有多少章节，而是下面几个问题。 第一，它到底要解决什么问题。 有些 Skill 负责生成代码，有些负责审查，有些负责操作外部工具，还有些负责控制一套完整工作流。名字和简介只能告诉我们大致方向，真正的能力边界要从触发条件、输入、步骤和输出里判断。 第二，AI 收到它以后会怎么行动。 很多 Skill 表面上是一篇说明文，实际上描述的是一张流程图。里面可能有固定步骤、条件分支、循环、暂停点和人工确认节点。只有把这些内容重新排列成执行顺序，才能看出 AI 在每一步需要什么输入、产生什么输出，以及什么时候可以进入下一步。 第三，谁说了算。 一份 Skill 里可能同时存在用户要求、项目文件、CLI 状态、API 返回值、Artifact、内置规则和操作建议。这些信息不是同一个等级。 用户可以提出需求，但未必能绕过系统状态；Guidance 可以帮助执行，但不能覆盖 MUST；AI 可以读取任务状态，却不一定有权自行修改状态。如果 Skill 没有说明冲突时的优先级，执行结果就很容易随着模型的理解发生漂移。 第四，什么叫完成。 这里需要区分两个经常被混在一起的概念。 Completion Definition 回答的是“做到什么程度算完成”，例如指定功能已经实现。 Completion Evidence 回答的是“凭什么证明它完成了”，例如构建通过、测试通过、场景验证通过。 只有完成定义，没有完成证据，最后仍然可能退化成“AI 觉得差不多了”。对于需要稳定执行的 Skill，这通常是一个明显缺口。 第五，有哪些设计值得复用。 分析 Skill 的意义不应停留在评价别人写得好不好。更实际的收获，是把其中有效的做法提炼出来：先获取真实状态再行动、把上下文范围交给外部系统决定、明确暂停条件、保护任务范围、用客观结果证明完成。 这些方法换一个业务场景仍然成立。 它具体会分析什么 skill-analyzer 会先完整读取目标 Skill，而不是看到主要流程后就停止。文件末尾的 Guardrails、Notes、Constraints 和完成条件，往往比开头的功能介绍更能决定 AI 最终会做什么。 如果目标 Skill 引用了必要的规则文件或上下文文件，也需要继续追踪这些依赖。否则分析出来的只是一个孤立的 SKILL.md，不是它真实运行时受到的完整约束。 完成读取后，它会重新还原执行流程，并从行为约束、上下文管理、状态管理、事实源、指令优先级、任务范围、异常处理和完成证据等角度拆解设计。 最后还会反过来追问： 作者在防止 AI 出现什么问题？ 哪些规则删除后会明显改变行为？ 哪些内容只是帮助理解的辅助说明？ 当前设计有没有冲突、遗漏或过度约束？ 如果自己写 Skill，哪些结构可以直接借鉴？ 我希望它给出的不是一份“内容摘要”，而是一张 Skill 的设计剖面图。 哪些时候适合使用 当你下载了一份陌生的 Skill，想判断它是否值得安装时，可以先用它分析整体行为和权限边界。 当你正在学习别人如何设计 Agent 工作流时，可以让它重点还原执行流程，看看规则如何控制 AI 的行动顺序。 当你已经写好自己的 Skill，却发现执行结果不稳定时，可以重点检查指令优先级、状态事实源、暂停条件和完成证据。 它也适合比较同一份 Skill 的两个版本。很多改动看起来只是增加了几条规则，实际影响的可能是 AI 的权限、任务范围或者完成判断方式。 例如可以直接这样使用： 使用 skill-analyzer 分析这个 SKILL.md。 也可以缩小范围： 分析这个 Skill，重点检查指令优先级和完成标准。 或者比较版本： 比较这个 Skill 的 v1 和 v2，说明工作流和行为边界发生了哪些变化。 它不替你做决定 skill-analyzer 不是一个自动打分器，也不会因为规则写得多，就判断一份 Skill 更专业。 长并不等于严谨。重复规则可能是在强化关键约束，也可能只是缺少整理；人工确认节点可以降低风险，太多了也会让工作流变得支离破碎；严格限制 AI 的权限有助于保持稳定，但同样可能损失执行效率。 因此，它会把“原 Skill 的设计”和“对这份设计的评价”分开。 前者回答作者写了什么，后者讨论这些做法是否合理。这样既不会把分析者的偏好冒充成原文规定，也方便使用者根据自己的场景作出判断。 我更关心的是“为什么” 做 skill-analyzer 时，我给它定下的最终标准不是“能把 Skill 讲明白”，而是完成三层转换： 看懂它写了什么 ↓ 理解它为什么这样写 ↓ 知道自己的 Skill 应该怎么写 Skill 的价值从来不只在几段提示词里。它真正决定的是 AI 在什么情况下行动、依据什么行动、遇到问题时是否暂停，以及拿什么证明任务已经完成。 当这些问题能够被说清楚，一份 Skill 才不再是堆叠起来的指令，而是一套可以检查、讨论和持续改进的工作方法。 项目地址：skill-analyzer",2509,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":39},"2026 · 综合技术","#2563eb","16 \u002F 10",[18],{"targetType":8,"targetId":9,"likedByMe":41,"likeCount":42,"commentCount":42,"contentLikeCount":42,"contentCommentCount":42,"sourceLikeCount":42,"sourceCommentCount":42},false,0,[44,51,58,64,71,78,85,92],{"id":45,"kind":7,"title":46,"summary":47,"image":48,"href":49,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":50},"NEWS_ARTICLE:838","AI 学习笔记：LLM 的微调实验","title: LLM 的微调实验 author: 凌杰 date: 2026-08-21 tags: LoRA, LLaMA-Factory, Qwen categories: 人工智能 [!NOTE] 笔记说明 这篇笔记对应的是《[[关于 AI 的学习路线图]]》一文中所规划的第三个学习阶段。其中","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F691082\u002F202609\u002F691082-20260902122904258-1285666483.png","\u002Fnews\u002F838",[18],{"id":52,"kind":7,"title":53,"summary":54,"image":55,"href":56,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":57},"NEWS_ARTICLE:843","介绍一下常用的Token鉴权方案","本文梳理 Session‑Cookie、JWT、OAuth2.0、SSO 主流 Token 鉴权方案，对比各方案适用场景。重点讲解生产级 JWT 双 Token 架构，给出 RS256 非对称加密、Redis 黑名单、网关统一鉴权等 Java 实战代码。剖析 JWT 注销、并发刷新、令牌泄露等落地痛","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F739056\u002F202609\u002F739056-20260902114155245-1924311389.png","\u002Fnews\u002F843",[18],{"id":59,"kind":7,"title":60,"summary":61,"image":14,"href":62,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":63},"NEWS_ARTICLE:854","分治：序列分治（CDQ）与点分治","分治：序列分治（CDQ）与点分治 一、分治思想概述 分治（Divide and Conquer）是算法设计中最核心的思想之一。它的基本策略是： 分（Divide）：将原问题划分为规模更小的子问题。 治（Conquer）：递归地求解子问题（若子问题足够小则直接求解）。 合（Combine）：将子问题的","\u002Fnews\u002F854",[18],{"id":65,"kind":7,"title":66,"summary":67,"image":68,"href":69,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":70},"NEWS_ARTICLE:863","弱模型不能裸奔：Agent Harness 凭什么真实有效","Harness 不是给弱模型贴的创可贴。它是把工程纪律——验证、门禁、不变量、路由——变成架构里一等公民的方式。模型每半年换一代，今天省钱的 Flash 明天可能就过时了，但那套'默认怀疑、机器校验、按决策密度调度'的流程会留下来，并且越跑越值钱。\n弱模型不能裸奔。给它穿上 harness，便宜才真","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830181633785-1171146572.jpg","\u002Fnews\u002F863",[18],{"id":72,"kind":7,"title":73,"summary":74,"image":75,"href":76,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":77},"NEWS_ARTICLE:865","焕新鸿蒙应用权限管理方案，应用授权体验再升级","作为用户或应用开发者，或许经历过类似的体验场景：使用应用的过程中，触发应用某些功能会需要访问你的位置、麦克风、相机等常用权限，若为了保护隐私拒绝授权后，想要使用功能时，再次打开却找不到设置入口；或开启流程繁琐，需要经过频繁跳转和设置。这一问题不仅影响用户体验，还可能造成应用功能不可用、用户流失，也制","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2396482\u002F202609\u002F2396482-20260901170248450-744043562.png","\u002Fnews\u002F865",[18],{"id":79,"kind":7,"title":80,"summary":81,"image":82,"href":83,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":84},"NEWS_ARTICLE:879","高并发下的抢红包设计：微信红包背后的算法与温情","本文拆解微信拼手气红包高并发实现，详解核心**二倍均值算法**，解决红包分配公平性问题。架构上依靠 Redis+Lua 脚本实现原子抢红包，规避超发与重复抢夺；结合 MQ 异步落库、热点 key 拆分、多层限流、定时对账兜底，支撑百万 QPS。给出 Java、Lua 核心源码，梳理超发、缓存一致性、","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F739056\u002F202609\u002F739056-20260901095345589-1940958188.png","\u002Fnews\u002F879",[18],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":91},"NEWS_ARTICLE:896","如何设计对外API接口","详解生产级对外 API 完整设计方案，围绕易用、安全、健壮黄金三角，覆盖 RESTful 规范、统一响应、签名验签防重放、AOP 注解实现分布式幂等、Redis 令牌桶限流、版本兼容、监控文档。附带可直接复用 Java 核心代码，梳理面试高频技术难点，搭配模拟面试场景，帮你避开线上坑点，快速掌握开放","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F739056\u002F202608\u002F739056-20260831134132446-55355388.png","\u002Fnews\u002F896",[18],{"id":93,"kind":7,"title":94,"summary":95,"image":14,"href":96,"meta":36,"badge":10,"author":12,"stats":-1,"accent":37,"coverRatio":38,"tags":97},"NEWS_ARTICLE:906","上周热点回顾（8.24-8.30）","热点随笔： · 从 PostgreSQL 到 Kubernetes：开源的护城河，从来不写在代码里 (张善友) · 代码都能让AI写了，我还学个屁？ (佛祖让我来巡山) · Vibe Coding 月提交量 29 亿次之后：GitHub 的危机、Azure 迁移，以及","\u002Fnews\u002F906",[18]]