作者: 启鑫

  • 使用AI编码时,应该何时初始化Git?我的实践心得

    最近我开始尝试用Vibe Coding的方式来开发项目,让AI来辅助编写代码。在这个过程中,我遇到了一个看似简单但值得深思的问题:应该等项目成型后再使用Git,还是从第一行代码就开始版本控制?

    • 代码决策的审计日志 – 记录了每一步为什么改动
    • AI优化的实验室 – 安全地尝试不同的Prompt和方案
    • 代码质量的守门人 – 通过commit记录强制你思考每一步的意义

    我的建议:项目第一天就运行git init。 这是我在实践中得出的最重要的经验之一。希望对你的AI编码之旅有所帮助!

    1. 为什么传统开发中人们会犹豫?

    在人工编写代码的年代,很多开发者会觉得:项目还不成熟,加入Git可能显得过度设计。等代码稳定了,功能明确了,再导入版本控制。这个想法在某个时代是可以理解的。

    但AI辅助编码改变了游戏规则。

    2. AI编码的独特挑战

    当你使用AI来生成代码时,出现了一些新的情况:

    2.1 生成质量的不确定性

    AI生成的代码可能一次就很完美,也可能需要多次调整。如果没有Git,你很难分辨哪个版本是有效的,哪个引入了bug。

    2.2 Prompt与代码的对应关系

    当某个功能出现问题时,你想回到某个特定的Prompt执行结果来对比。Git commit的message可以记录当时的Prompt,形成代码和指令的完整链条。

    2.3 实验和分支

    AI可能生成多个不同的解决方案。你想同时尝试不同的实现方式,然后选择最优的。分支管理在这里就变得非常有用。

    2.4 快速迭代的代价

    用AI编码的速度很快,一下子就生成了大量代码。如果中间有问题,往往很难定位改动是在哪一步引入的。频繁的小commit可以精确追踪问题源头。

    3. 我的实践结果

    我采用了以下工作流,效果很好:

    3.1 项目初期

    git init
    git add .
    git commit -m "Initial commit - project setup"

    3.2 每次AI生成重要代码段后

    git add .
    git commit -m "Feature: xxx - AI generated with prompt: [prompt关键字]"

    3.3 AI代码需要修改时

    git add .
    git commit -m "Fix: xxx - reviewed and adjusted manually"

    这样做的好处显而易见:

    1. 完整的进化链 – 从Prompt到初版代码,再到最终版本,整个过程都记录在案
    2. 快速定位问题 – 如果某个功能出问题,可以通过git log找到相关的所有commit
    3. 安全的实验 – 敢于尝试新想法,因为随时可以回滚
    4. 代码审查友好 – 使用git diff可以清楚看到每个步骤改动了什么
    5. 团队协作准备 – 即使目前是个人项目,这个习惯为未来团队合作打好基础

    4. 关键点

    4.1 Commit Message要清晰

    一定要在message中标注资源来源:

    • "Feature: xxx - AI generated" – 表示AI生成
    • "Fix: xxx - manual review"– 表示手工调整

    这样回头查看时一目了然。

    4.2 创建.gitignore

    从项目初期就排除不必要的文件:

    node_modules/
    __pycache__/
    .env
    *.log
    build/
    dist/
    .DS_Store

    针对你的项目类型调整即可。

    4.3 考虑创建分支

    对于不确定性较大的功能,创建特性分支尝试:

    git checkout -b feature/experimental-ai-solution
    # AI生成代码并测试
    git add .
    git commit -m "Experiment: xxx"
    # 如果成功,合并到main
    git checkout main
    git merge feature/experimental-ai-solution

    4.4 定期推送到远程

    即使没有团队合作,也建议推送到GitHub或其他平台作为备份:

    git remote add origin https://github.com/你的账号/项目名.git
    git push -u origin main
  • 标准化操作为什么重要

    很多团队都在追求效率、质量和稳定,但真正拉开差距的,往往不是某一个人有多强,而是整个团队有没有一套清晰、统一、可复制的做事方式。一个真正成熟的团队,最终拼的从来不是谁更会“救火”,而是谁更有能力把事情稳定地做对、持续地做好。

    很多人一听到“标准化”就会本能抗拒,觉得它意味着流程变多、动作变慢、灵活性下降。可现实恰恰相反。真正成熟的标准化,不是为了束缚人,而是为了减少混乱、降低失误、提升效率,并让团队在人员变化、业务扩张和复杂环境中依然能够稳定运行。

    不标准化短期看似灵活,长期一定会付出质量波动、重复出错、协作低效、培训困难和管理成本上升的代价。相反,长期坚持标准化,带来的不仅是效率提升,更是组织能力的沉淀、风险控制能力的增强,以及团队专业度的持续上升。如果一个团队长期依赖个人经验、临场发挥和口头传达,那么短期看似灵活,长期一定会付出代价。

    什么是标准化操作

    标准化操作,并不是把所有人变成“照本宣科的执行者”,而是把重复性工作中的关键动作、执行步骤、判断标准和交付要求沉淀下来,形成一套大家都能理解、都能执行、都能检查的统一方法。

    它的核心不是“限制每个人怎么做”,而是确保面对同一类问题时,团队能够以大致一致的方式处理,并尽可能得到稳定、可预期的结果。

    简单来说,标准化操作至少要解决四件事:

    • 这件事该怎么做
    • 谁来做,负责到什么程度
    • 做到什么标准才算完成
    • 出现异常时应该如何处理

    当这些问题被说清楚、写清楚、执行清楚,团队的很多问题就会自然减少。

    为什么一定要做标准化操作

    1. 把“个人经验”变成“团队能力”

    很多组织的问题并不是没人会做,而是只有少数人会做。平时靠这些关键人物顶着,似乎一切正常;一旦请假、离职、轮岗,问题就会立刻暴露出来。

    标准化操作最重要的意义之一,就是把原本分散在个人头脑里的经验,转化为组织可以共享、传承和复用的能力。这样一来,工作不会因为“某个人不在”就突然掉链子。

    2. 让执行结果更稳定

    同样一项工作,如果每个人都按自己的理解去做,最后出来的结果一定有差异。有的人做得细,有的人做得快,有的人只完成表面动作,有的人理解重点完全不同。

    标准化的价值,就是把这些“做法差异”尽可能缩小,让执行结果更稳定、质量更可控,而不是每次都靠运气。

    3. 降低错误和返工

    很多错误并不是因为团队不努力,也不是因为能力不够,而是因为没有统一流程、没有检查点、没有明确交付标准。于是一些本来可以避免的问题,最终变成了返工、补救和重复劳动。

    标准化操作的本质之一,就是把常见错误前置拦截,把关键动作固定下来,让团队少走弯路,少付出不必要的成本。

    4. 提高协作效率

    一个没有标准的团队,沟通成本通常都很高。每做一件事,都要反复确认做法、口径、范围和结果要求。很多精力不是花在真正执行上,而是花在解释和对齐上。

    一旦有了统一标准,很多事情就不需要反复问。大家知道该怎么配合、该交付什么、该在什么节点完成,协作效率自然会提高。

    5. 支撑组织规模化发展

    小团队可以靠默契,大团队必须靠机制。

    当业务扩大、人员增加、流程变长之后,如果还停留在“谁懂谁去做”“出了问题再补救”的阶段,组织就很难稳定扩张。标准化不是大公司才需要的东西,而是任何想长期发展的团队都绕不开的基础建设。

    不标准化,短期看灵活,长期代价很大

    很多团队在早期不愿意做标准化,原因很简单: 觉得麻烦,觉得现在还能运转,觉得“先干起来再说”。但问题在于,不标准化带来的成本,通常不是立刻爆发,而是慢慢积累,最后集中体现。

    1. 工作质量忽高忽低

    没有统一标准时,同样一件事今天这样做,明天那样做;这个人做出来是一个结果,换一个人又变成另一个结果。看似大家都在做事,实际上输出质量并不稳定。

    这种不稳定,会直接影响管理判断,也会削弱团队对结果的掌控力。

    2. 同样的问题反复出现

    如果团队没有把经验沉淀下来,就会陷入一种很常见的循环:问题发生一次,解决一次;过段时间又发生,再解决一次。表面上大家一直在处理问题,实际上只是不断重复过去的错误。

    不标准化最大的隐性成本,就是组织没有真正“学会”。

    3. 新人上手慢,交接风险高

    没有标准,新人只能靠别人带、靠自己猜、靠边做边学。这样的培养方式效率低,质量也不稳定。岗位交接时尤其危险,因为很多关键细节根本没有被明确记录下来。

    结果往往是:人虽然换了,工作却很难平稳接住。

    4. 管理越来越累

    没有标准,管理者就只能靠盯、靠催、靠经验判断。很多时候不是团队不会做,而是每个人理解不一样,导致管理动作必须一遍遍重复。

    表面上是执行问题,本质上往往是标准缺失问题。

    5. 组织容易形成“关键人物依赖”

    这类团队通常有一个明显特征:总有几个人特别忙,也总有几个人不可替代。一旦这些人不在,很多工作就推进不下去。

    这不是因为他们太重要,而是因为组织没有把方法沉淀成标准,导致能力长期停留在个人身上,而没有真正变成团队资产。

    长期坚持标准化,到底能带来什么

    标准化真正的价值,往往不是一两周就能看出来的,而是在半年、一年甚至更长时间里逐渐体现出来。

    1. 组织能力会持续沉淀

    长期标准化,不只是把动作固定下来,更重要的是把正确的方法、有效的经验和踩过的坑逐步沉淀下来。时间越久,这套体系就越成熟,团队的执行基础也会越稳。

    这意味着组织不再总是“从头开始”,而是在不断站在过去经验的基础上往前走。

    2. 效率提升会越来越明显

    很多人觉得标准化前期要花时间,所以误以为它会拖慢效率。但从长期看,标准化带来的不是局部提速,而是整体效率的持续提升。

    因为一旦沟通变少、返工变少、培训变快、交接变稳,团队的整体运转就会越来越顺。

    3. 风险控制能力更强

    标准化意味着关键动作有流程、关键节点有检查、关键岗位有交接、关键数据有留痕。这样的机制会显著提升团队应对突发事件、人员变动和业务波动的能力。

    真正成熟的团队,不是“平时很能干”,而是遇到变化时依然不乱。

    4. 更容易做持续优化

    如果每个人做法都不一样,就很难比较到底哪种方式更好,也很难总结哪里该优化。只有先把动作和标准统一起来,优化才有真实基础。

    所以,标准化从来不是僵化的代名词。恰恰相反,标准化是持续改进的前提。

    5. 团队专业形象会越来越强

    标准化程度高的团队,通常会给人一种很明显的感受:事情更稳、反馈更快、协作更顺、失误更少。

    这种专业感,不只是内部管理的收益,也会直接影响客户、合作方和管理层对团队的信任。

    推动标准化落地,关键不是“写文件”,而是真能执行

    很多团队也做标准化,但效果不好。原因往往不是方向错了,而是停留在“写了一份流程文件”这一步。

    如果标准化只停在文档里,它就只是材料,不是能力。

    真正有效的标准化,通常有几个共同点:

    • 先从高频、易错、影响大的工作入手
    • 标准写得足够具体,避免空话和口号
    • 让流程贴近真实工作场景,而不是脱离实际
    • 设置必要的检查点,确保执行不是流于形式
    • 根据实际问题持续更新,而不是写完就不再维护

    标准化最怕两件事:

    • 只有文件,没有执行
    • 只有流程,没有优化

    所以,标准化不是“一次性工作”,而是一种长期管理能力。

  • Docker 磁盘爆满实录:我以为镜像删干净了,结果系统还是报 No Space

    执行了 docker rmi,为什么磁盘空间还是 100% 占用?记录了一次服务器磁盘爆满的排查过程,深度解析 Docker 分层存储与构建缓存,并分享真正有效的深度清理命令。

    在日常开发和运维中,我习惯于用一个简单的命令来清理 Docker 镜像:

    docker rmi <IMAGE_ID>

    删除不再使用的镜像,释放磁盘空间,逻辑看似完美。直到有一天,我的服务器直接弹出令人绝望的红字:

    No space left on device

    我删光了所有能删的镜像,为什么磁盘还是满的?

    1. 现象:镜像删了,空间没回?

    当我意识到磁盘报警时,第一反应是检查 Docker 的占用情况:

    docker images  # 查看镜像列表
    df -h          # 查看系统磁盘状况

    诡异的现象出现了:

    • docker images 列表里只剩下几个业务镜像,加起来不到 2GB。
    • 但 /var/lib/docker 目录依然占用了 40GB+。

    这时候我才意识到:看到的“镜像”,并不代表 Docker 占用的全部空间。

    2. 分析原因:为什么 docker rmi 会失效?

    理解这个问题,必须看清 Docker 的底层存储机制。Docker 镜像并非一个独立的文件,而是像乐高积木一样层层堆叠的(Layer-based Filesystem)。

    2.1 镜像层(Layers)的“幽灵”

    当你用 docker rmi 删除一个镜像时,Docker 只会尝试删除该镜像特有的层。如果某些层被其他镜像引用,或者是构建过程中的中间层,它们就会留在磁盘上,变成无法通过 rmi 直接删除的“幽灵空间”。

    2.2 虚悬镜像(Dangling Images)

    在多次执行 docker build 后,旧的镜像会失去标签(Tag),变成 <none>:<none>。这些镜像往往不会出现在你常规的清理视线里,但依然实打实地占据空间。

    2.3 构建缓存(Build Cache)

    这是最隐形的“空间杀手”。特别是开启了 BuildKit 后,Docker 会产生大量的构建缓存。这些缓存完全不会显示在 docker images 列表中,却是磁盘爆满的元凶之一。

    3. 真正救命的命令:docker image prune

    当我发现手动删除(rmi)无能为力后,我使用了 Docker 官方提供的“深度清理”命令:

    docker image prune -a

    这条命令到底做了什么?

    1. 所有未被容器使用的镜像(即使它有 Tag)。
    2. 所有虚悬镜像(Dangling Images)。
    3. 所有孤立的镜像层。

    ⚠️ 安全提示: 只要你的业务容器正在运行,它所依赖的镜像就是安全的,不会被 prune 误删。但对于已经停止(Exited)的容器,其对应的镜像可能会被判定为“未使用”而被清理。

    执行后,我的服务器磁盘占用瞬间从 100% 降到了 15%。

    4. 进阶技巧:如何精准定位与排查?

    在盲目清理之前,我建议先用以下命令定位 Docker 的真实磁盘占用:

    docker system df

    输出会清晰地展示四类数据的占用分布:

    • Images: 镜像
    • Containers: 容器(包括日志和可写层)
    • Local Volumes: 本地卷
    • Build Cache: 构建缓存

    如果 image prune 仍不足以释放空间,可以使用终极命令:

    # 清理一切:停止的容器、未使用的网络、未使用的镜像和卷
    docker system prune -a --volumes
  • LM Studio 本地大模型教程:VS Code 使用 Claude Code 实现本地 LLM 调用与部署

    通过 LM Studio 的 Anthropic‑兼容本地服务,将本地 LLM 模型与 Claude Code 集成,使用户能够在 VS Code 或终端 中直接调用本地部署的语言模型进行交互。实现与本地模型的对接。支持更大的上下文长度、流式输出和函数调用等高级功能

    1. 环境说明

    • 操作系统:Windows 11
    • 本地模型工具:LM Studio
    • 编辑器:Visual Studio Code
    • VSCode 插件:Claude Code

    2. 安装 LM Studio

    2.1 下载并安装

    1. 访问 LM Studio 官网,下载 Windows 版本安装包。
    2. 安装完成后启动 LM Studio。
    3. 在“Models”页面下载大模型,例如:
       openai/gpt-oss-20b

    2.2 开启 Developer Mode(本地 API 访问)

    1. 打开:
       Settings → Developer → Local Server
    1. 设置监听地址:
       http://localhost:1234
    1. 启动 API Server,确保浏览器或 VSCode 可以访问:
       http://localhost:1234

    2.3 加载模型

    1. 点击 Load Model。
    2. 选择模型:
       openai/gpt-oss-20b
    1. 设置模型参数:
    • Context length:100000
    • GPU Offload:16 (根据显存大小调整)

    ⚠️ 注意:20B 模型对显存要求高,建议显卡显存≥24GB,或者使用 CPU Offload 功能。

    3. VSCode 配置 Claude Code

    3.1 安装插件

    1. 打开 VSCode。
    2. 扩展市场搜索:
       Claude Code
    1. 点击安装。

    3.2 配置环境变量

    1. 打开命令面板:Ctrl + Shift + P
    2. 输入:
       Preferences: Open Settings (JSON)
    1. 添加以下配置:
    {
        "workbench.colorTheme": "Experimental Light",
        "claudeCode.preferredLocation": "panel",
        "claudeCode.environmentVariables": [
            {
                "name": "ANTHROPIC_BASE_URL",
                "value": "http://localhost:1234"
            },
            {
                "name": "ANTHROPIC_AUTH_TOKEN",
                "value": "lmstudio"
            }
        ]
    }

    3.3 测试连接

    1. 在 VSCode 中打开 Claude Code 面板。
    2. 尝试发送一条简单的指令,例如:
       Hello
    1. 如果能正确返回结果,说明 VSCode 已经成功连接到本地 LM Studio 模型。
  • 通过组策略彻底关闭 Windows 11 小组件 (Widgets)

    Windows 11 任务栏左侧的“小组件”(Widgets)功能虽然可以提供天气和资讯,但经常会在后台运行并占用一定的系统资源。如果你不需要这些推送内容,希望系统更加轻量、干净,可以通过 Windows 自带的组策略功能将其完全关闭。

    操作步骤

    1. 打开组策略编辑器

    按键盘上的 Win + R 快捷键打开运行窗口,输入以下命令然后按回车:

    gpedit.msc

    这会打开“本地组策略编辑器” (Local Group Policy Editor) 窗口。

    2. 定位到小组件策略

    在左侧的导航树状列表中,依次展开以下路径:

    Computer Configuration (计算机配置)
    ↳ Administrative Templates (管理模板)
     ↳ Windows Components (Windows 组件)
      ↳ Widgets (小组件)

    3. 打开策略设置

    在右侧的策略列表中,找到名为 Allow widgets (允许小组件) 的选项,并双击打开它。

    4. 禁用小组件

    在弹出的配置窗口中,将左上角的选项从“未配置”或“已启用”更改为:

    Disabled (已禁用)

    5. 应用并保存

    点击窗口右下角的 Apply (应用),然后点击 OK (确定) 关闭该窗口。

    6. 强制更新策略

    为了让设置尽快生效,可以强制刷新一下系统策略:

    按 Win + R 打开运行,输入 cmd 后按 Ctrl + Shift + Enter(以管理员身份运行命令提示符)。
    输入以下命令并回车:

    gpupdate /force

    等待屏幕提示“计算机策略更新成功”。

  • 在 FortiGate 中配置 Spamhaus DROP 列表:实现恶意网段自动同步与拦截

    通过 FortiGate 外部连接器 (External Connectors) 自动化集成 Spamhaus DROP 威胁情报。该方案通过 curl 与 jq 提取恶意 CIDR 网段,并利用防火墙的 Threat Feed 功能实现动态同步,旨在为企业边界安全提供一层自动化的“零误伤”过滤屏障。

    一、 环境准备:获取并整理 DROP 列表

    Spamhaus 提供的 DROP (Don’t Route Or Peer) 列表包含了由恶意组织控制的网段。其原始格式为 JSON,需转换为 FortiGate 兼容的纯文本。

    1. 原始格式预览

    {"cidr":"1.10.16.0/20","sblid":"SBL256894","rir":"apnic"}
    {"cidr":"1.19.0.0/16","sblid":"SBL434604","rir":"apnic"}

    2. 数据提取脚本

    在你的 Web 服务器(或中转服务器)上运行以下命令,提取 cidr 字段并生成纯文本:

    # 下载、解析并保存为文本文件
    curl -s https://www.spamhaus.org/drop/drop_v4.json | jq -r '.cidr' > spamhaus_drop.txt

    注意:FortiGate 无法直接解析该 JSON 文件,因此必须通过上述步骤将其托管在内部或公网的 HTTP/HTTPS 服务器上。

    二、 FortiGate 配置步骤

    1. 创建外部连接器 (Threat Feed)

    1. 登录 FortiGate,进入 Security Fabric > External Connectors。
    2. 点击 Create New,在 Threat Feeds 类别下选择 IP Address。
    3. 参数配置详情:
    • Name: Spamhaus_DROP
    • URL: http://yourserver.com/spamhaus_drop.txt
    • Refresh Rate: 设置为 60 分钟(平衡实时性与服务器负载)。

    2. 状态验证

    保存配置后,在列表中观察连接器图标状态:

    • 绿色箭头:连接正常。
    • 红色感叹号:请检查 FortiGate 是否有权限访问该 URL,或 DNS 解析是否正常。
    • 查看内容:右键点击连接器选择 View Entries,确认是否已成功拉取 IP 列表。

    三、 应用安全策略

    获取列表后,必须将其应用到安全策略中才会生效。

    1. 进入 Policy & Objects > Firewall Policy。
    2. 创建一条新的拦截策略:
    • Name: Deny_Spamhaus_Inbound
    • Incoming Interface: WAN (外部接口)
    • Source: 选择刚才创建的动态对象 Spamhaus_DROP
    • Destination: All
    • Service: ALL
    • Action: DENY
    1. 关键操作:在策略列表中,手动将该策略 移至顶端 (Top)。

    提示:为了防范内网主机被感染后回连 C&C 服务器,建议额外创建一条 Source 为 Internal、Destination 为 Spamhaus_DROP 的拦截策略。


    四、 自动化更新

    为了确保列表始终最新,建议在 Web 服务器上设置 Crontab 定时任务:

    # 每小时自动更新一次列表
    0 * * * * curl -s https://www.spamhaus.org/drop/drop_v4.json | jq -r '.cidr' > /var/www/html/spamhaus_drop.txt