<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Neal&#39;s Blog</title>
    <link>https://madneal.com/post/</link>
    <description>Recent content in Posts on Neal&#39;s Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>© This post is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License，please give source if you wish to quote or reproduce.</copyright>
    <lastBuildDate>Sat, 20 Jun 2026 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://madneal.com/post/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>从1243元跌回935元：近一年黄金到底变弱了吗？</title>
      <link>https://madneal.com/post/au9999-gold-trend-2026/</link>
      <pubDate>Sat, 20 Jun 2026 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/au9999-gold-trend-2026/</guid>
      <description>数据口径：上海黄金交易所 Au99.99，单位为人民币/克。
数据区间：2016-12-19 至 2026-06-18。
图表按中国市场习惯使用 红色表示上涨，绿色表示下跌/回撤。
 如果只看过去一年，黄金不是简单上涨，而是经历了一轮非常典型的：
加速上涨 → 极端冲高 → 深度回撤 → 高位震荡。
1. 先看近一年的结论    指标 数据     2025-06-18 收盘 781.85 元/克   2026-06-18 收盘 935.86 元/克   近一年涨幅 19.70%   近一年最高收盘 2026-01-29，1243.02 元/克   近一年最低收盘 2025-06-27，763.30 元/克   从低点到高点最大涨幅 62.85%   从高点到样本末日回撤 -24.71%    一句话总结：黄金长期仍强，但短期已经从极度亢奋回到高位震荡。
2. 近一年日线和均线：主升结束了吗？ 截至 2026-06-18：
   指标 数值     样本末日收盘价 935.</description>
    </item>
    
    <item>
      <title>博客考古：从漏洞、工具到生活折腾</title>
      <link>https://madneal.com/post/%E5%8D%9A%E5%AE%A2%E6%96%87%E7%AB%A0%E9%98%B6%E6%AE%B5%E6%80%A7%E6%80%BB%E7%BB%93/</link>
      <pubDate>Fri, 19 Jun 2026 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/%E5%8D%9A%E5%AE%A2%E6%96%87%E7%AB%A0%E9%98%B6%E6%AE%B5%E6%80%A7%E6%80%BB%E7%BB%93/</guid>
      <description>前言 最近翻了一下自己的博客，感觉像是在翻一个大型考古现场。
有些文章现在看还挺有意思，有些文章则属于“当年我为什么会写这个”的系列。早期有不少内容就是学习笔记，甚至有些只是把一个小问题解决了顺手记一下。现在再把这些文章全部端上来，其实没什么意义。毕竟人总不能一直回味自己当年怎么配置环境、怎么写第一个 demo。
所以这篇文章不打算做一个完整目录。完整目录这种东西博客本身已经有了，再写一遍除了显得勤奋，其实也没啥用。这里更像是笔者给自己做一次“技术路线复盘”：哪些文章代表了一个阶段，哪些东西后来真的影响了我的方向，哪些坑虽然当时痛苦，但现在回头看也挺值。
简单来说，这篇文章不是“我的全部文章总结”，而是“我觉得还值得拿出来说几句的文章”。
安全：从看热闹到修系统 安全应该是这个博客后面最主要的内容。最开始写 XSS、CSRF、SSRF 的时候，更多还是在分析一个个具体漏洞。这个参数怎么进来的，为什么能打到页面，为什么这里能绕过，为什么框架没有兜住。那时候写漏洞文章，会有一种解谜的快感。
但写着写着就会发现，漏洞分析最有意思的地方不是 payload 本身，而是背后的错误假设。开发以为这里不会被外部访问，浏览器以为自己只负责执行规则，框架以为开发者知道自己在干什么，最后大家都觉得自己没问题，问题就出来了。
比如 XSS 这类问题，很多时候不是“不知道要过滤”这么简单，而是你要理解数据从输入到展示到底经过了多少层。富文本、模板、DOM、编码、浏览器解析，每一层都可能有自己的脾气。SSRF 和开放重定向也类似，它们会不断提醒你：系统边界从来不是你画在架构图上的那条线。
后来写 MyBatis、GORM、Kibana、Webpack 这些文章，关注点就更偏开发侧了。很多漏洞并不是因为技术多高深，而是大家太相信默认行为了。ORM 很好，框架也很好，但框架不会替你理解业务，也不会替你判断输入是否可信。这个道理听起来简单，真到代码里就不一定了。
相关文章导航：
 XSS 漏洞知解 123 富文本场景下的 XSS 偶遇 XSS 漏洞 跨站请求伪造（CSRF）攻击 服务端请求伪造（SSRF）攻击 白名单，被谁饶过了？ MyBatis 和 SQL 注入的恩恩怨怨 AI 审代码，靠谱吗？ 让你的SQL盲注快起来 Kibana 任意代码执行漏洞 hey,我能看到你的源码哎 黑产代码解密&amp;ndash;利用canvas加载代码 使用浏览器作为代理从公网攻击内网 ChatGPT账户接管 - 通配符网页缓存欺骗 通过 Cookie Tossing 劫持 OAUTH 流程  安全工程：不只是把洞挖出来 只会发现漏洞是不够的。这个道理说起来很简单，但真正做企业安全的时候会特别明显。
如果一个漏洞提上去之后没人修，或者责任人不准，或者状态没人跟，或者修完没人验证，那这个漏洞和写在本子上的愿望差不多。安全真正麻烦的地方，往往不是技术本身，而是怎么把事情推进下去。
这也是为什么我后来写了 GShark、安全运营平台、被动扫描器、Burp 插件、Zeek、Qradar、SAST 这些内容。它们看起来不像单个漏洞那么刺激，但更接近实际工作。安全运营平台那篇其实印象挺深，倒不是因为技术多复杂，而是因为需求太碎。各种角色、权限、状态、通知、资产、漏洞、事件，像一堆线头缠在一起。你不把它们一根根捋顺，后面就会一直打结。
GShark 也是类似。一开始只是想监测 GitHub 敏感信息，后面慢慢就会想到 GitLab、SearchCode、权限、任务、前端体验、误报处理。安全工具做着做着，最后都会变成工程问题。工具能不能长期跑，能不能让别人愿意用，能不能降低处理成本，这些问题比写一个扫描规则更难。
相关文章导航：</description>
    </item>
    
    <item>
      <title>不到一分钟拿到可用 PoC：Julen Garrido Estévez 测试 Burp AI  </title>
      <link>https://madneal.com/post/burp-ai/</link>
      <pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/burp-ai/</guid>
      <description>原文：不到一分钟拿到可用 PoC：Julen Garrido Estévez 测试 Burp AI 
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
 不到一分钟拿到可用 PoC：Julen Garrido Estévez 测试 Burp AI Hassan Ud-Deen | 2026 年 1 月 16 日 00:00（UTC）
注：本文为客座文章，由渗透测试人员 Julen Garrido Estévez（@b3xal）撰写。
 方法论
 关键结果
 示例
 关键心得
 提示词模板
 从渗透测试视角看 Burp AI
  渗透测试人员 Julen Garrido Estévez（@b3xal）想验证 Burp AI 是否能在日常工作中带来真实价值：它能否加速向量发现、PoC 生成与上下文分析？是否值得消耗 credits？哪种提示词（prompt）写法效果最好？</description>
    </item>
    
    <item>
      <title>Go 版本不一致？别慌，这是特性！</title>
      <link>https://madneal.com/post/toolchain/</link>
      <pubDate>Sat, 30 Aug 2025 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/toolchain/</guid>
      <description>故事的开端：一场“奇葩”的争论 最近，我和一位可爱的同事，因为一个项目的 go.mod 文件，产生了一点小小的“学术分歧”。文件长这样：
// go.mod go 1.21.1 toolchain go1.22.9 同事认为这种配置“非常奇葩”，并抛出了一个灵魂拷问：“你本地用 go1.22.9 的工具链编译，线上服务器（CI/CD 环境）用的却是 go1.21 的基础镜像来构建，这能不出问题吗？这不就是经典的‘我电脑上好好的’吗？”
说实话，我一开始还没 get 到他说的“线上版本”是啥，后来才明白他指的是我们项目构建镜像所基于的 golang:1.21。他的核心论点是：开发环境和生产环境的 Go 版本不一致，是危险的。
为了说服我，他甚至搬出了“AI 军师”，进行了一场“人机对话”。
AI 的“第一次接触”：危言耸听 同事提问： go.mod 中 Go 版本与 Toolchain 版本不一致会带来什么问题？
AI 回答（摘要版）：
 哇，这可不得了！当 go 版本和 toolchain 版本不一致时，会引发一系列灾难性后果：
 语言语义和编译行为不一致：编译器优化策略不同，二进制文件体积和性能会有差异。 API 可用性错配：旧工具链编译不了新代码，新工具链用了新 API 在旧环境也跑不起来。 依赖解析差异：go mod tidy 的结果可能不一样，go.sum 文件会在不同开发者之间反复横跳。 构建标志和行为变化：CI/CD 和本地产物的可复现性降低。 安全与合规隐患：你可能会错过新工具链里的重要安全修复。 团队协作噩梦：开发者 A 和 B 构建出的二进制文件性能、大小、告警都不同，定位问题难于上青天。  AI 总结： 为了天下太平，请务必保持版本统一！CI 用什么，你就用什么！
 好家伙，这说得头头是道，一套组合拳下来，差点就把我打懵了。如果真如 AI 所说，toolchain 这玩意儿不就成了“潘多拉魔盒”？</description>
    </item>
    
    <item>
      <title>AI 审代码，靠谱吗？</title>
      <link>https://madneal.com/post/gorm/</link>
      <pubDate>Fri, 22 Aug 2025 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/gorm/</guid>
      <description>背景：一道出乎意料的笔试题 最近在校招面试中，我发现一道关于 GORM SQL 注入的笔试题，所有人的答案都错了。题目代码大致如下：
func UsersHandler(c *gin.Context) { groupId := c.Query(&amp;#34;group_id&amp;#34;) var group GroupModel // 注意这里的用法 	err := DB.First(&amp;amp;group, groupId).Error if err != nil { c.Status(404) return } c.JSON(http.StatusOK, gin.H{ &amp;#34;group&amp;#34;: group, }) } 问题是：这段代码是否存在 SQL 注入漏洞？
正确答案是：会。
说实话，这个答案起初也让我感到意外。在日常业务开发中，我们很少会这样直接将变量传给 First 函数。First 通常用于获取按主键排序的第一条记录，更常见的做法是通过 Where 方法来构建查询条件。这不禁让我怀疑：这道题本身是不是有问题？
初探源码：First 函数的内部实现 简单看了一下 First 函数的实现：
// First finds the first record ordered by primary key, matching given conditions conds func (db *DB) First(dest interface{}, conds .</description>
    </item>
    
    <item>
      <title>CVE-2025-55188：7-Zip 任意文件写入漏洞</title>
      <link>https://madneal.com/post/cve-2025-55188/</link>
      <pubDate>Mon, 11 Aug 2025 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/cve-2025-55188/</guid>
      <description> 安全研究员 Landon 发现了一个新披露的 7-Zip 漏洞，编号为 CVE-2025-55188。该漏洞的 CVSS 评分为 2.7，影响 25.01 之前的版本，可能允许攻击者在提取存档文件时执行任意文件写入操作——在某些情况下可能升级为任意代码执行。
根据报告，“_在 25.01 之前的 7-Zip 中提取恶意制作的存档文件允许任意文件写入，可能导致任意代码执行_。”
该问题源于在提取过程中对符号链接的处理不当。7-Zip 在解压存档文件时会跟随符号链接，这意味着恶意存档文件可以将提取的文件指向预期目录之外的位置——覆盖系统上的关键文件。
漏洞利用需要特定条件：
 Linux – 任何在 25.01 之前版本的 7-Zip 上运行的用户，提取支持符号链接格式的存档（如 .zip、.tar、.7z、.rar）都会受到影响。 Windows – 漏洞利用是可能的，但较为困难。提取过程必须具有创建符号链接的权限，可能在以下情况下发生：  7-Zip 以管理员权限运行。 Windows 处于开发者模式。 启用了其他特殊权限。   一旦触发，攻击者可能会覆盖敏感文件，如 SSH 密钥或 .bashrc，从而留下持久后门或执行命令。
虽然 CVSS 2.7 的评分可能表明严重性较低，但如果攻击者可以控制存档文件的内容和目标的提取环境，其影响可能很严重。Landon 警告称，“_在一次提取过程中，攻击者可能多次尝试利用此漏洞写入敏感文件_。”
此类攻击可能：
 破坏安全外壳 SSH 认证。 修改启动脚本以实现持久化。 篡改配置文件以绕过安全控制。  修复已包含在 7-Zip 版本 25.01 中。用户应：
 立即从官方 7-Zip 网站更新至 25.01 或更高版本。 避免从不信任来源提取存档文件。 处理未知文件时使用沙盒或隔离环境。  相关文章:  CVE-2025-0411: 7-Zip 安全漏洞可导致代码执行 – 立即更新 7-Zip 中的两个漏洞可能触发拒绝服务攻击 7-Zip CVE-2025-0411 的 PoC 允许攻击者绕过 MotW 并运行恶意代码 CVE-2025-0411: 针对乌克兰的攻击中利用了 7-Zip 漏洞 CVE-2022-29072: 7-Zip 权限提升漏洞  </description>
    </item>
    
    <item>
      <title>mac mini，真香？</title>
      <link>https://madneal.com/post/mac-mini/</link>
      <pubDate>Mon, 24 Feb 2025 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/mac-mini/</guid>
      <description>距离上次换 iMac 2020 已经有4年多的时间。最近 mac 国补的价格，感觉不买就在亏钱一样。本来是在 iMac 和 mac mini 之间犹豫，但是现在新版本的 iMac 只有 24 寸，并且只有 4.5 k。另外还有一个重要的问题是京东没有 vesa 版本的 iMac，但是我只想买 vesa 支架友好的显示器。后来，又听同事说 m4pro 芯片是 m4 芯片性能的将近2倍。果断拿下了 mac mini m4pro 丐版配置，m4 pro (24 G 内存 + 512 G 存储)。对于来说基本足够了，苹果的内存是黄金做的，实在是加不起。
更换 mac mini 之后，最大的问题就是显示器了。之前是 iMac + studio display 的配置，但是市面上 5k 显示器的选择屈指可数。如果降级选择 4k 选择器感觉反而越来越次了，而且太次的 4k 显示器我也看不上。参考了市面上的几款主流的 5k 显示器作对比：
5K显示器横向对比（5120×2880分辨率）    优缺点 未来视野 RV100 优派 VP32UQ 酷优客 Pro5K 三星 UR55     优点 价格便宜，性价比高 品牌有保证，综合素质可以 外观最好看，vesa支架友好，性价比较高 品质有保证   缺点 品质不稳定，容易踩坑 外形老土，外接电源，雾面屏 新品牌 性价比低，外接电源，不如加钱上 studio display    其实对比几款显示器，其实优缺点都挺明显的。优派的显示器我是拿到手体验了，然后的确是有两个大的方面我是接受不了，一个就是雾面屏，另外就是那么大的外接电源。显示器最恶心的缺点就是外接电源，和板砖一样难受，所以外接电源一律是不考虑。</description>
    </item>
    
    <item>
      <title>通过 Cookie Tossing 劫持 OAUTH 流程</title>
      <link>https://madneal.com/post/cookie-tossing/</link>
      <pubDate>Thu, 06 Feb 2025 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/cookie-tossing/</guid>
      <description>原文：Hijacking OAUTH flows via Cookie Tossing
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
 我们最近在瑞士苏黎世的Area41会议上展示了我们的 GitHub Action 研究。在会议的第一天，Thomas Houhou 进行了一个有趣的演讲，介绍了如何利用 Cookie Tossing 攻击来增强 Self-XSS 问题的影响，使其变得值得报告。这次演讲非常精彩，展示了一些新颖的 Cookie Tossing 在劫持多步骤流程中的应用。作为一种技术，Cookie Tossing 常常被忽视或不为人知，关于这一主题的发表内容也很少。
我们希望扩展目前有限的研究，看看 Cookie Tossing 攻击还可能导致哪些额外的影响。我们发现，Cookie Tossing 可以用来劫持 OAUTH 流程，并导致身份提供者（IdP）的账户接管。
什么是 Cookie Tossing? Cookie Tossing 是一种技术允许一个子域名（例如 securitylabs.snyk.io）在其父域名（例如 snyk.io）上设置 cookie。在我们查看一些问题场景之前，先来了解一下 HTTP cookie 是什么。
什么是 HTTP cookies？ 根据 RFC 6265 的定义，Cookie 是服务器与用户的网页浏览器之间交换的一小段数据。这些 Cookie 对于网络应用至关重要，因为它们能够存储有限的数据并帮助维护状态信息，从而解决 HTTP 协议固有的无状态特性。通过 Cookie，用户会话可以持续，偏好设置可以被保存，并且可以提供个性化的体验。</description>
    </item>
    
    <item>
      <title>NilAway：实用的 Go Nil Panic 检测方式</title>
      <link>https://madneal.com/post/nilayay/</link>
      <pubDate>Sat, 30 Nov 2024 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/nilayay/</guid>
      <description>原文：NilAway: Practical Nil Panic Detection for Go
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
 Uber 由于 Go 语言的高性能，广泛采用其作为实现后端服务和库的主要编程语言。Uber 的 Go monorepo 是 Uber 最大的代码库，包含 9000 万行代码（并且还在增长）。这使得编写可靠 Go 代码的工具成为我们开发基础设施的重要组成部分。
指针（保存其他变量的内存地址而不是其实际值的变量）是 Go 编程语言的一个重要组成部分，有助于高效的内存管理和有效的数据操作。因此，程序员在编写 Go 程序时广泛使用指针，出于多种目的，如原地数据修改、并发编程、数据共享优化、内存使用优化以及支持接口和多态性。虽然指针功能强大且被广泛使用，但必须谨慎和明智地使用它们，以避免诸如空指针解引用导致的 nil panic 等常见陷阱。
nil panic 问题 nil panic 是指程序尝试解引用一个 nil 指针时发生的运行时 panic。当一个指针为 nil 时，意味着它不指向任何有效的内存地址，尝试访问它指向的值将导致 panic（即运行时错误），错误信息如图 1 所示。
图 1：Nil panic 报错</description>
    </item>
    
    <item>
      <title>Home Assistant 小米门铃视频本地存储</title>
      <link>https://madneal.com/post/xiaomi/</link>
      <pubDate>Sat, 29 Jun 2024 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/xiaomi/</guid>
      <description>小米的门铃，免费的云存储时间只有 72 小时，希望保存更多时间的视频，只能去充钱。后来网上搜了一下，通过 Home Assistant 的小米插件可以实现这样的功能。刚好家里有一台闲置的 Macbook 用来发挥余热不是刚好。其实我之前已经安装好了，只不过手残把镜像文件删掉了，这样刚好出个教程从头来一次。
Home Assistant 安装 Home Assistant 支持多种安装方案，不过他们主推的是他们自己的一款软硬件一体的方案。其实家里是有一台软路由的，不过软路由担心把网络搞出问题，还是选择使用那台闲置的 Mac。官网里面也包含了 MacOS 的安装方案。因为 Home Assistant 用的是比较低版本的 Linux 系统，所以基本都还是需要使用虚拟机。首先需要安装 VirtualBox。另外就是需要下载 Home Assistant 的镜像文件。对于虚机，有一个推荐的配置，下面都以贴图的形式展现。
这个步骤里面的虚拟硬盘，记得需要使用前面下载下来的 vdi 文件。
接着需要把虚机的网络里面去配置桥接，官方文档里面说必须要使用有线连接网络，但是我的笔记本使用 WIFI 也没有什么问题。
系统全都配置好了之后，就直接启动系统，等待系统初始化好后即可。系统初始化好后，即可进入页面 http://homeassistant.local:8123/ 。一般进入页面的时候可能还需要等待一段时间初始化。
初始化完成后，创建账户。
选择家庭地址
进入主页
以上就是 Home Assistant 的安装，主要就是一个虚机的配置，其它基本只要下一步就可以。不过这个还是只是第一步，还需要安装 HACS，它是一个插件商店，通过这个商店才可以去安装小米的插件。
HACS 安装 HACS 需要尝试通过终端去安装，我尝试过直接在虚机里面去直接执行命令，但是是不可以的。需要安装终端插件去执行命令，这里我推荐使用 Terminal &amp;amp; SSH 插件，比另外一款插件好用，另外一款插件总是初始化失败。在设置里面，找到 Add-ons，然后在 ADD-ON 商店里面去搜索，不过这里有一个坑是默认搜不到这个插件的，需要在设置里面把高级模式打开。
插件安装好了，可以参考官方文档去安装 HACS。按照 Terminal 插件之后就可以直接执行命令：
wget -O - https://get.hacs.xyz | bash -  安装完毕后，需要重启一下 Home Assistant，可以直接在终端里面通过 reboot 来进行重启。安装重启之后，还需要在 Settings &amp;gt; Devices and Services &amp;gt; Add Integration &amp;gt; HACS 里面添加一下。因为 HACS 需要使用 github 去更新，你可能还需要一个 github 账号来进行配置，输入验证码后，即配置成功。</description>
    </item>
    
    <item>
      <title>大佬，您这是在借鉴嘛</title>
      <link>https://madneal.com/post/export-to-markdown/</link>
      <pubDate>Thu, 27 Jun 2024 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/export-to-markdown/</guid>
      <description>今天闲来没事看到一篇文章，感觉质量挺好的，就想翻译一下。之前写过一个将文档导出成 markdown 的插件，因为这个插件一开始是为了翻译 Medium 文章开发的，但是后来因为 Medium 的 json 接口启用了，所以这个插件后面也不怎么维护了。不搜不知道，一搜吓一跳，居然发现一个和插件差不多的插件，不会吧，这么烂的插件也有人抄？后来仔细看了一看，这个大佬应该是在借鉴我的插件，辛苦地改了几个中文。
两款插件名名字几乎一模一样，只是这个借鉴者加了一个后缀：掘金翻译计划版。不确定和掘金有没有关系，我知道掘金是有一个翻译项目的，以前我也参与过。
对比 插件介绍 我的插件 李鬼插件 代码对比 上面的简洁基本上已经展现了浓重的李鬼味道，本着客观严谨的态度，我还是去看了一下代码。
我的插件 李鬼插件 除了一个 js 文件的引用，几乎可以说是一模一样了。核心的文件是 widget.js 这个文件，这个属于插件自身的 js 文件。
从这代码对比，可以看得出这个借鉴者巨大的工作量。
总结 鄙人的这款插件是在 GitHub 上开源的，当时也是出于个人需求搞得这么个小玩意，但是没想到居然还有李鬼借鉴，还真是离谱他妈给离谱开门。大家如果有空的话，还是动一下发财的小手点一下 Report，这个李鬼插件还是下架比较好。我也联系了这个开发同学，希望他能及时下架。</description>
    </item>
    
    <item>
      <title>如何使用 Git 撤消（几乎）任何操作</title>
      <link>https://madneal.com/post/git-undo/</link>
      <pubDate>Sun, 12 Nov 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/git-undo/</guid>
      <description>原文：How to undo (almost) anything with Git
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
 任何版本控制系统最有用的功能之一就是能够“撤消”错误。在 Git 中，“撤消”可能意味着许多略有不同的事情。
当你进行新的 commit 时，Git 会及时存储你的仓库在该特定时刻的快照；之后，你可以使用 Git 返回到项目的早期版本。
在这篇文章中，我将介绍一些你可能想要“撤消”所做更改的常见场景，以及使用 Git 执行此操作的最佳方法。
撤销一个“public”修改 场景： 你刚刚运行了 git push，将你的修改 push 到 GitHub，现在意识到有一个 commit 有问题。你想把这个 commit 撤销。
撤销： git revert &amp;lt;SHA&amp;gt;
结果： git revert 将创建一个与给定 SHA 相反的新 commit。如果旧 commit 是“matter”，则新 commit 是“anti-matter”——旧 commit 中删除的任何内容都将添加到新 commit 中，而旧 commit 中添加的任何内容都将在新 commit 中删除。</description>
    </item>
    
    <item>
      <title>Google Drive 的信息检索</title>
      <link>https://madneal.com/post/drive/</link>
      <pubDate>Mon, 28 Aug 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/drive/</guid>
      <description>对于使用 Google 全家桶的公司，Google 文档类的信息泄露也时常发生。出现这种情况主要的原因是文档的权限设置问题，用户可能将文档配置为 anyoneCanFind, anyoneWithLink, domainCanFind, domainWithLink，这四种权限都属于比较公开的权限。后两个属于在域内可以查看到文档，一般来说也是不提倡如此设置，尤其是文档中包含敏感信息的。
Auth 如果要使用 Google Drive 的 API，毫无疑问，Google Workspace 的 Auth 则是第一步。对于 Auth，一般可以通过 OAuth 或者 service account 来进行实现，但是 service account 有一个问题是，默认这个 service acount 并没有赋予这个 servive account 这个域内所有资源的访问权限。必须要将这个文档分享给 service account，它才可以访问。这将会影响到对于 domainCanFind 以及 domainWithLink 的文档的搜索。解决办法是需要 delegate domain-wide authority,相当于是对于这个 service account 进行额外的授权，详细的介绍可以参考这个文档。当然，这个授权需要管理员账号来进行，如果申请比较麻烦的话，还可以通过使用 OAuth 的方式来进行认证，这也是 Google Drive API 文档指引中介绍使用的方式。
通过 OAuth 来使用 Drive API 也需要三个步骤：
 启用 API 配置 OAuth 应用 生成 Credentials  详细介绍可以参考谷歌的文档介绍，基本上每一步都有详细的介绍。建议可以按照文档的方式来进行操作，OAuth 生成方式会用到一个 credentials.json 文件。如果对 OAuth 流程比较了解的话，应该知道流程中会有一个授权的流程。Go 的官方文档已经提供了一个授权的 demo，通过运行代码可以获取 autorization code，通过 aurhorization code 可以生成 token.</description>
    </item>
    
    <item>
      <title>菜腿的骑行通勤</title>
      <link>https://madneal.com/post/%E9%AA%91%E8%A1%8C/</link>
      <pubDate>Sat, 12 Aug 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/%E9%AA%91%E8%A1%8C/</guid>
      <description>现在，自行车骑行越来越流行。B 站上经常可以刷到各种骑行的视频。当时，就想着平常上下班开车特别堵车，骑自行车既可以通勤，还可以减肥，一举两得。选车的时候也没有特别讲究，都说迪卡侬售后比较好，平常也喜欢在迪卡侬瞎逛，在店里也稍微试骑了一下。三月份的时候就直接在迪卡侬买了最基础的公路入门车 rc100。选的是到店自提，有 100 块的优惠券，加上安装了站脚和水壶架，差不多 1700 多一点。虽然说这个车一直涨价到 1799，但还是非常火的入门公路车之一。推荐到店自提，自己安装可能还是有一点麻烦，自提会省心不少，还可以帮你把配件也一起安装了。
好多人一买车了，就各种装备，比如码表、自行车灯、手机支架等等。考虑到自己只是上下班通勤而已，才买的时候还偶尔出去骑行一下，但是后面除了上下班，基本也不骑。高德地图足够使用了，可以记录速度和里程，用来统计骑行继续就基本够用了。自行车灯买过一个，可是还没用几天，就被人偷了。手机支架就多多买了一个很便宜的硅胶支架，还挺稳，手机没有掉过。在迪卡侬买过一个骑行裤，但我感觉似乎并没有什么用，穿着也不是特别舒服，不知道是不是因为买的不够贵的原因。一般如果骑行不超过两个多小时的话，应该也不太需要骑行裤，而且骑行裤通勤的话也不太方便。
对于我个人而言，自行车在通勤上更加有优势一点。如果开车去公司的话，路程15公里左右，大多数情况早上基本都要 50 分钟多，遇到更堵的时候甚至要一个多小时，也是家常便饭。遇到最夸张的一次是堵了我将近两个小时。另外，开车去公司还要交停车费。自行车通勤，现在基本稳定在40分钟左右，最快的记录 36 分钟，通勤距离将近 12 公里。通勤时间上来说，自行车比开车其实还更节约时间。
后来从三月份开始就基本断断续续用自行车通勤，一般不下雨的时候骑自行车，下雨就开车。梅雨季那段时间，雨水比较多，那段时间基本都是开车。下雨的时候骑自行车还是挺不方便的，后来买过一款迪卡侬的徒步的雨衣，99.9，使用过一次，基本还能用。但是如果是那种大雨，其实本身骑行雨衣基本就不太管用了。另外，骑行的比较重要的装备就是手套了。不仅可以防晒，握车把会舒服一些，而且万一摔了的话，对于手掌还有一点保护。骑行一共就摔过两次，一次是前面的电动车突然急刹车，另外一次是电动车自己骑太快滑到了把我撞到了，还好两次我基本都没有受伤。骑行的时候还是需要注意安全，不要骑行过快，和他人要保持安全距离。另外就是往旁边移动的时候，一定要先往后面看看。
市区通勤的话，路况还是比较重要的。公路车比较吃路况，但是现在路面经常各种各样的补丁，导致骑起来非常不舒服。另外就是红绿灯多的话也非常影响配速，后来自己摸索了一条路，基本是最快的，这个是地图导航没有的路线。大部分的公路车用的都是法式嘴，也是这一次我知道了有法式嘴、英式嘴、以及美式嘴。英式嘴比较古老，以前那种老式自行车使用的，美式嘴最通用，汽车以及一般的电动车都是美式嘴，而公路车一般用的都是法式嘴。法式嘴的特点就是细长，并且把塑料帽拧下来之后还要把上面的金属帽拧松。之前一开始补气的时候一直打不进去，后来才知道是这个原因。
夏季骑行最大的困难就是太阳比较大，比较热。前面的一段时间基本都放弃不骑了，太热就不想骑。后面，上海的一场大雨把我四个轮子和两个轮子的电动车都跑坏了，就只能骑自行车了。现在习惯了，感觉骑行太舒服了，那种破风疾驰的感觉实在太爽。早上六点多的时候是骑行最舒服的时候，不热并且太阳也基本没有，我偶尔起来的早的话，就直接出发去公司了。本来是买了迪卡侬的渔夫帽遮阳，但这个渔夫帽有一个问题就是帽檐经常被风吹到上面或者下面，吹到上面不能遮阳，吹到下面遮挡视线，不太好用。后面入了洛克兄弟的骑行帽，可以把脸部和脖子全部遮挡。有了悍匪造型的加成，现在骑行感觉没有一点问题。
如果你的通勤距离和我类似，建议你可以试试自行车通勤。可能比开车或者地铁更加方便快捷。当然说到最开始的初衷，减肥，反正我是一点也没瘦，自从骑车后，就比以前更饿，吃得更多，没有长胖就已经不错了。</description>
    </item>
    
    <item>
      <title>GitHub 更新了 RSA SSH host key</title>
      <link>https://madneal.com/post/github-rsa/</link>
      <pubDate>Fri, 24 Mar 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/github-rsa/</guid>
      <description>今天在 push 自己 GitHub 仓库代码的时候遇到了报错，后来发现是 GitHub 已经将 RSA SSH host key 进行了更新。依据官方博客，GitHub 于 3月24日 05:00 UTC 时间 由于安全原因将 RSA SSH host key 进行了更新。主要是为了避免 GitHub 用户的 git 操作被任何不法分子监听。这个变更仅影响基于 RSA 的 SSH 协议使用 GitHub 进行 git 操作的用户。变更也只影响 RSA 算法，不影响 ECDSA 或者 Ed25519 用户。
GitHub 这周发现了他们的 RSA SSH 密钥在公共仓库中暴露。根据他们的调查结果，这个问题暂不涉及 GitHub 任何系统或者用户信息被窃取。依据他们的解释是保险起见进行 host key 的更新。
报错信息可能如下：
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!</description>
    </item>
    
    <item>
      <title>行车记录仪对比 - 盯盯拍mini5 vs 海康威视C8</title>
      <link>https://madneal.com/post/%E8%A1%8C%E8%BD%A6%E8%AE%B0%E5%BD%95%E4%BB%AA/</link>
      <pubDate>Sun, 12 Feb 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/%E8%A1%8C%E8%BD%A6%E8%AE%B0%E5%BD%95%E4%BB%AA/</guid>
      <description>最近把之前的盯盯拍 mini5 行车记录仪换下来了，换了海康威视 C8。这两款行车记录仪都是小鹏官方商城里面的行车记录仪，之前卖的是盯盯拍 mini5 和 mini3，但后来不知道盯盯拍就下架了。下架之后只有海康威视的这个型号。我算行车记录仪的重度用户，经常拿来举报违章，所以好用的行车记录仪非常重要。盯盯拍是市面上比较受欢迎的 4K 行车记录仪之一。使用将近两年的时间，基本没有什么特别大的毛病，不过前段时间在老家行车记录仪经常重启，可是回到上海之后又莫名其妙正常了。不过还是购入新的海康威视的让售后帮忙安装，因为网上关于这两款行车记录仪的对比评测不算特别多，所以分享一下对于这两款行车记录仪的使用对比。
外形 盯盯拍：⭐⭐⭐⭐⭐
海康威视：⭐⭐⭐
因为网上都有两款行车记录仪的照片，这里就不再贴图。行车记录仪的屏幕个人觉得特别鸡肋，因为行车记录仪只是作为记录使用，屏幕并没有什么作用，可能还会干扰视线，浪费电能。这两款行车记录仪都是不带屏幕的。盯盯拍 mini5 体型比较小，外形比较好看，质感比较好一些。不过这样带来的负面影响就是散热比较差，夏天特别烫手。有的时候可能会因为高温重启。海康威视相对来说体积大一些，散热好一些，镜头可以上下调节。但这一点基本上也没大的区别，因为行车记录仪一旦安装之后也不需要调整镜头。
新的行车记录仪是让小鹏的售后安装的，安装的比较整洁，线材都埋在了摄像头的盒子里面。当然也是因为三目摄像头的原因，记录仪也安装在比较靠下的位置。但是颠簸路面的状况会有一点点异响，可以接受。
APP 海康威视：⭐⭐⭐⭐⭐
盯盯拍：⭐⭐⭐
行车记录仪的 APP 对于行车记录仪来说特别重要，因为这是使用行车记录仪最频繁的场景。海康威视有一个独特的优势就是小鹏车机里面集成了 APP，可以在车机里面使用行车记录仪。不过限制只有 P 档的时候才能使用，我觉得是比较鸡肋。因为我之前使用行车记录仪的场景基本都是打开 APP，连接行车记录仪，然后 APP 就自动下载违章视频，有空的时候再去举报。盯盯拍的 APP UI 方面设计的比较精细一点，海康威视的相对来说就比较古老一点。但是，盯盯拍每次打开还有开屏广告，没有海康威视干净。虽然看起来丑了一点，但是明显干净了很多。盯盯拍之前 APP 经常无法连接强制退出，不过后面某个版本修复之后就没遇到过这种问题了。因为两款行车记录仪都是支持 5G WIFI 的，所以下载速度还是比较 OK 的。
因为 APP 的连接原理都是手机连上记录仪的 WIFI，从连接速度上面来说，海康威视要比盯盯拍快，而且盯盯拍还经常有连接失败的情况。视频预览的形式也不一样，盯盯拍是把回放视屏连接在了一起，而海康威视则是一段段的视频，这一点盯盯拍更好一点，预览视频更直观。
成像 盯盯拍：⭐⭐⭐⭐⭐
海康威视：⭐⭐⭐⭐
专业的参数评测可能网上已经有对比了。按照之前盯盯拍的使用体验来说，虽然是 4K 的行车记录仪，但是如果想拍清楚车牌的话，基本上必须一个车身位的距离才能拍清楚。强光环境，或者夜晚环境，可能都会差一点。还有就是那种车速特别快的，基本也是拍不清楚的。两款记录仪参数上来说基本上一致，只不过海康威视的光圈大一些而已。成像质量最好的一般都是在隧道里面，有稳定光源的。如果希望进行违章举报的话，必须要拍清楚车牌。所以一般为了拍清楚违章车辆的车牌，可以稍微靠近违章车辆，拍清楚车牌，这样举报成功率才会高一些。
不过两款行车记录仪的图片角度来看，盯盯拍的似乎更好一点，海康威视不知道是不是因为镜头角度的问题，拍出来的画面有一点点畸形的感觉，没有盯盯拍看起来那么自然。从画面成像的角度来看我更喜欢盯盯拍。另一方面盯盯拍的图片的水印看起来也更舒服一些。
停车监控 海康威视：⭐⭐⭐⭐
盯盯拍：⭐⭐⭐
因为这两款行车记录仪小鹏商城里面都是降压线版本，所以都有停车监控的功能的。盯盯拍的停车监控有两种功能，一种是缩时录影，另外一种是持续录像。缩时录影就是隔几十秒拍一张，这种主要是避免行车记录仪消耗太多电量，导致小电瓶没电。但有一次我我车在停车场被蹭，通过缩时录影拍到了别人的车牌，但因为不是实时的录像，也不能作为直接的证据。所以缩时录影也比较鸡肋，基本上只能简单的录一下。持续录像的话，主要的问题就是 4K 视频占用存储比较大，可能录不了多长时间就被覆盖了。另外就是小电瓶可能经常就没电了。海康威视是只有持续录制的选项，可以选择录制的时间，但是默认也是缩时录影的形式。不过感觉海康威视的停车监控似乎比盯盯拍稳定一些，盯盯拍之前经常因为小电瓶电压的问题关闭了。
可拓展性 海康威视：⭐⭐⭐⭐
盯盯拍：⭐⭐⭐
这两款行车记录仪都是支持 4G 模块的。通过 4G 模块可以远程查看行车记录仪摄像头的实时画面。之前大多数新能源汽车可以远程查看的，不过去年因为数据安全的问题就被政府叫停了，现在市面上车辆的摄像头都不能直接查看了，虽然我觉得特别不合理，因噎废食。海康威视的 4G 模块可以外接，可拓展性相对来说更强一点。盯盯拍则是集成到支架上面，如果要升级的话，相对来说更麻烦一点，需要将原有的支架拆除，更换为新的支架。
存储方面，盯盯拍只支持内置存储，这也是更换行车记录仪的原因之一。因为之前买的是64 GB 的版本，64 GB 对于 4K 行车记录仪来说还是太小了，不够用。海康威视使用 SD 卡来进行存储，拓展性相对来说好一点。不过最大也就只支持 128 GB，如果可以支持到 256 就好了。</description>
    </item>
    
    <item>
      <title>为什么 2022 年是漏洞赏金奖破纪录的一年</title>
      <link>https://madneal.com/post/github-bug-bounty/</link>
      <pubDate>Mon, 16 Jan 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/github-bug-bounty/</guid>
      <description>为什么 2022 年是漏洞赏金奖破纪录的一年  原文：Why 2022 was a record-breaking year in bug bounty awards
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
 每年，GitLab 的应用安全团队 都会回顾 GitLab 漏洞赏金计划的亮点。
对于整个行业的安全团队来说，2022 年是忙碌的一年，我们很幸运收到了大量出色的报告，帮助我们确保 GitLab 及其客户的安全。 随着我们在 2021 年 11 月 增加我们的漏洞赏金奖励金额和研究人员参与度的提高，我们在 2022 年期间奖励超过 100 万美元，打破了新纪录！
如果没有我们的漏洞赏金社区的合作，我们就不会取得今天的成就，我们认为这些奖励非常有益，而且钱花得值。
2022 年的数字[](##2022-by-the-numbers)  在 221 份有效报告中获得总计 1,055,770 美元的奖金，高于去年的 337,780 美元！ 三名研究人员在他们的多份报告中获得了 10 万美元以上的收入，另外七名研究人员的收入超过了 2 万美元。 2022年共收到424名研究人员的920份报告。 解决了 158 份有效报告并公开了 94 份 - 今年，我们收到了一些信息泄漏报告，与漏洞不同，这些报告不需要公开 GitLab 问题。 今年有 138 名安全研究人员提交了一份以上的报告，表明他们对我们的计划做出了积极的贡献。 向提交三份或更多有效报告的研究人员授予八份 GitLab Ultimate 许可证。  注：数据为截至 2022 年 12 月 16 日。</description>
    </item>
    
    <item>
      <title>CircleCI 20230104 安全事件报告</title>
      <link>https://madneal.com/post/circleci-incident/</link>
      <pubDate>Sat, 14 Jan 2023 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/circleci-incident/</guid>
      <description>CircleCI 20230104 安全事件报告  原文：CircleCI incident report for January 4, 2023 security incident
译者：madneal
welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me
LICENSE: MIT
 2023 年 1 月 4 日，我们提醒客户 一起安全事件。 今天，我们想与您分享发生的事情、我们学到的知识以及我们未来不断改善安全态势的计划。
我们要感谢我们的客户对于重置密钥的关注，并对此次事件可能对您的工作造成的任何干扰表示歉意。我们鼓励尚未采取行动的客户采取行动，以防止未经授权访问第三方系统和存储。此外，我们要感谢我们的客户和社区在我们进行彻底调查期间的耐心等待。为了实现负责任的披露，我们已尽最大努力在共享信息的速度与保持调查的完整性之间取得平衡。
本报告包含:
 发生了什么？ 我们怎么知道这个攻击向量已经关闭并且可以安全构建？ 与客户的沟通和支持 如何判断我是否受影响？ 可能有助于您的团队进行内部调查的详细信息 我们从这次事件中学到了什么以及我们下一步将做什么 关于员工责任与系统保障措施的说明 安全最佳实践 结语  发生了什么？ 除非另有说明，否则所有日期和时间均以 UTC 报告。
2022 年 12 月 29 日，我们的一位客户提醒我们注意可疑的 GitHub OAuth 活动。此通知启动了 CircleCI 的安全团队与 GitHub 的更深入审查。</description>
    </item>
    
    <item>
      <title>CPE 获取指南</title>
      <link>https://madneal.com/post/cpe/</link>
      <pubDate>Fri, 02 Dec 2022 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/cpe/</guid>
      <description>在我们考取 ICS 的认证之后，是需要通过 CPE(Countinuing Professional Education) 来进行证书的维持的。以 CISSP 为例，3年是需要 120 CPE 来进行证书的维持的。官方的文档已经详细说明了获取 CPE 的各种途径，如果按照官方的说明，满足要求的难度是比较低的。我在取得 CISSP 认证之后，不到一年的时间已经获得 98 CPE 了，距离要求已经很接近了。所以就分享自己一些获取 CPE 的手段来进行分享。
Webinars 基本上是一些讲座或者分享之类的，听一次基本都可以获取一个 CPE。而且现在目前 ISC 上面大多数在线的会议或者课程学习，如果可以获取 CPE 的话，你只要填了你的 ID 的话，过一段时间就会帮你自主申报，不需要你自己来申报的。不过这种在线分享，一般很多没有在线字幕，而且内容也比较杂，所以我就听说一两次，不是特别的感冒。我自己的话不是特别推荐，虽然说这是获取 CPE 的手段之一，但好歹自己也在这个过程中学点东西，这样也更有价值。
Professional Development Institute 这是我最为推荐的部分。在 PDI 里面提供了各种各样的课程，这些课程一般是英文为主，涉及的方向也比较多，比如应用安全、安全运营之类的，制作一般都比较精良。虽然里面的内容大多数都是偏理论的居多，但是如果拿去写材料什么的还是比较好的。课程可能会随着内容的多少，其 CPE 分值也不相同，有的 5 分，有的可能只有 1 分。不过这些课程都需要经过考试的，基本上分数达到 70% 以上就可以过关了。
其它 其它像回答 InforSecurity Professional 杂志上面的 quiz 也可以去获取 CPE 的，不过我觉得还挺麻烦的，因为答案可能还不太好找。参加一些安全会议也是可以获取 CPE 的。另外值得分享的是，参加 ISC 的一些志愿活动也是可以获取 CPE 的。我有次参加了一次志愿活动，一共持续了 3 天，一次性给了 21 个 CPE，还是比较多的。</description>
    </item>
    
    <item>
      <title>小鹏 P7 之殤</title>
      <link>https://madneal.com/post/xp-problem/</link>
      <pubDate>Sun, 25 Sep 2022 00:00:00 +0000</pubDate>
      
      <guid>https://madneal.com/post/xp-problem/</guid>
      <description>不知道这会不会是我最后一次写关于小鹏的文章。虽然我算不上是小鹏的狂热粉丝，但之前也算是好感多一点，之前也分享过几篇文章关于车辆使用以及辅助驾驶方面的经历。但是最近的售后问题实在是我对小鹏失望加失望。
事情经过 首先描述一下问题发生的一个比较完整的时间线：
2022.08.13 去上海闵行小鹏服务中心检查辅助驾驶方向盘一直微调的问题，售后技师借口无法试车，不了了之。小鹏闵行服务中心一位女性售后人员在车辆交付之后没有直接交付给顾客，让顾客白白等了将近一个小时，她说她以为我已经走了，她车子都没有交付给我。
2022.08.22 辅助驾驶出现不可启用的问题，又向远程技术支持反馈问题。远程技术支持反馈是软件 BUG，未得到合理解决。
2022.08.27 去闵行服务中心继续排查辅助驾驶 NGP 使用时方向盘持续修正的问题，陪同技师经历两个小时左右的试车，最后观察到了问题现象。后技师说可能是软件问题，安装了软件补丁，但实际效果暂未知。
2022.09.12 辅助驾驶第二次不可用，且无法恢复。电机异响（电机异响的问题其实早就出现了，后面是特别严重，基本上就跟地铁运行的声音一致），去上海闵行小鹏服务中心检查确认电机问题以及辅助驾驶问题，当时售后技师说电机的问题已经非常严重了，需要留店检查维修。当时售后接待人员承诺的代步车权益是每天 3000 积分的补偿方案，从我交车的时间到我提车的时间（这也是后面埋下的伏笔之一）。
2022.09.18 售后这边提出的维修意见是需要更换电机，更换电机还需要用户去车管所登记去变更电机编号。而且辅助驾驶的问题没有根本解决。打客服电话投诉，投诉受理。
2022.09.19 售后给出车辆维修表，需要同时更换电机以及辅助驾驶芯片。对于赔偿方案闭口不提，和400客服踢皮球。期间配合进行车管所预约，预约到最早的变更日期是10月24号。期间咨询售后人员，不变更电机号，汽车无法合法上路。
2022.09.24 售后提出车辆要开始维修，询问代步车权益问题。他说车辆维修之后先拿回去，可是车子换过电机之后需要及时去车管所变更，否则是不可以上路的。售后提出让消费者把一个电机有问题的车子开回去，后面再来修，就为了不承担他们承诺赔付的代步车权益。不知道他们有没有考虑过消费者的生命安全，有没有考虑过道路行人的生命安全。
下面放上两段9月24日和售后的录音，总结概括就是预约的时间太长了，我们不想赔你代步车权益，你把车子先开回去吧。
问题总结 其实这一次的问题主要是包括两个问题，一个是电机的质量问题，第二个就是辅助驾驶的问题。小鹏 P7 的电机质量问题，出现这个问题的我并不是唯一的车主，网上搜一搜应该也有很多类似的方案。但是小鹏在解决问题的时候总是非常被动，总是消费者要花费巨大的时间和经历去推动他们去处理。车辆提车不到一年半的时间，行驶里程不足两万五千公里，就出现电机质量问题和辅助驾驶问题，需要更换电机以及辅助驾驶芯片。
第二个就是辅助驾驶的问题。一直我的观点都是辅助驾驶仅仅就只是辅助驾驶，并不能代替人完全去接管车辆。所以我在使用辅助驾驶的过程中一直都是握着方向盘去使用的。自从提车辅助驾驶使用以来，也一直陆陆续续出现过各种问题。包括出匝道突然靠近马路沿，各种幽灵刹车，使用过程中方向盘一直在不断微调，到最后的辅助驾驶不可用的阶段。当然，一种新兴技术在出现的过程中肯定在所难免会出现一些 Bug，我也经常积极反馈这些问题，并向他们上传日志，甚至配合提供行车记录仪视频。但是，小鹏往往给的答复往往都是模棱两可的，也并没有彻底的修复问题，就说可能是什么 Bug。
下面这段视频是当初提车没多久，NGP 在使用过程中突然有撞墙的一个举动，在快出匝道的时候突然往墙壁靠拢。还好当时及时接管了。当时也反馈给了他们的远程技术支持，​后来一段时间我都不敢使用 NGP 了。
后面 ACC 在北横通道又出现两次幽灵刹车的问题：
后面 ACC 在另外一个地道又连续出现两次幽灵刹车：
以上基本上就是我三次向他们反馈的问题，其实期间辅助驾驶也是各种小问题不断，比如 NGP 突然降级，速度从80降到60，幽灵刹车问题，莫名其妙勒安全带，以及上面提到的使用过程中方向盘持续调整以及辅助驾驶不可用的问题。而小鹏在解决问题的过程中似乎没有一点点主动性，能听到最多的也就是抱歉。
小鹏售后处理问题非常有意思的一点是，就是一定要求消费者拍视频举证。如果消费者无法提供举证视频的话，那就不能帮你维修。比如之前喜闻乐见的门把手收不回去的问题，辅助驾驶方向盘调整的问题。特别有意思的是他们要求一定要清楚拍摄辅助驾驶出现问题的时候去拍摄问题，完全没有考虑到可操作性，可能我需要在开车的时候头上一直顶着手机去录影才可以。他们在解决问题的时候从来不想着自己主动去排查问题，而一味地让消费者提供视频证据，并且不考虑实际可行的程度。每次地提问，也只能得到不痛不痒的，毫无帮助的回答。
这个视频是 9 月 24 号当时拍摄的视频，包括当时出现的辅助驾驶不可启用的问题。并且如果你注意听一下的话，已经可以听到电机的声音非常大了，即使在车辆在高架上行驶，有风噪胎噪的情况下，电机的声音依然非常明显，和地铁行驶的声音差不多。
总体而言，之前在辅助驾驶使用过程中遇到的问题，我都是积极反馈，上报日志，提供视频证据，从来没有进行过投诉，也没有要过赔偿。可是这次电机质量问题以及辅助驾驶的问题让我真的对小鹏的售后简直是无语加无语，处理问题不主动，出了事情就往消费者身上一推，没有一丝一毫的担当。从来没有站在消费者的角度考虑过问题。
总结 毫无疑问，目前的新势力造车搞得如火如荼。小鹏在新能源汽车上面的确有自己厉害的地方，P7 当然也有它身上很多的优点。但是如果一个厂家没有办法保证产品质量，没有办法保证售后服务，那么这个品牌在未来的路上可能走得也不会太远，其口碑也会越来越差。</description>
    </item>
    
  </channel>
</rss>