Posts

Windows 下部署 Kali-Security-MCP 记录 这篇记录的目标很简单：以后换新电脑时，可以按本文把环境重新拉起来，少走弯路。 最终跑通的链路如下： Windows 安装 Claude Code WSL 中部署 Kali-Security-MCP Claude Code 不走网络连接 Claude Code 通过 stdio 方式调用 wsl.exe wsl.exe 进入 WSL 后，在项目目录中启动 mcp_server.py 这个方案已经能跑通。后面又遇到了上下文长度问题，但部署链路本身已经打通。 一、最终可用方案 最终我放弃了“Windows 通过网络地址连接 WSL 中的 MCP Server”的方式，改用 stdio 方式。 原因很实际： 这个项目在 WSL 里直接起网络型 MCP 服务时，先遇到了 Python 依赖版本不兼容，代码要改 改完以后服务能起，但 Claude Code 通过网络方式接入时，会做额外校验，这个 MCP Server 当前实现没有通过 改成 stdio 后，Claude Code 直接拉起 wsl.exe，再由 WSL 里的 Python 启动 mcp_server.py，链路最稳定 结论先写在前面： 在 Windows 下接 Kali-Security-MCP，当前更稳的做法是 stdio，不要优先折腾网络接入。 二、部署步骤 1. Windows 安装 WSL 先装好 WSL，并准备一个 Linux 发行版。本文实际使用的是 WSL 里的 Linux 环境来部署 Kali-Security-MCP。 ...

记录我如何快速上手 CCR，以及我后来才真正想明白的运行逻辑：CCR 接管 Claude Code 的请求，再根据路由规则把请求发给不同模型。

# DrissionPage 常用语法速查 整理项目中实际使用到的 DrissionPage 语法，用于快速编写自动化脚本。 --- # 1 创建浏览器 ```python from DrissionPage import ChromiumPage page = ChromiumPage() 关闭浏览器： page.quit() 2 打开网页 page.get("https://example.com") 打开本地文件： page.get("file:///D:/test/index.html") 3 获取单个元素 page.ele("xpath://input[@id='username']") 返回 Element 对象。 4 获取多个元素 rows = page.eles("xpath://tbody/tr") 获取数量： len(rows) 5 点击元素 page.ele("xpath://button").click() 6 输入文本 page.ele("xpath://input").input("admin") 7 清空输入框 ele = page.ele("xpath://input") ele.clear() ele.input("text") 8 获取文本 text = page.ele("xpath://span").text 9 获取 iframe 方式一： ...

本机运行 迁移到其他电脑 位数不同的处理 在线 / 离线 两种方式 uv 是否必须安装的边界 全文按“操作流程 + 规则说明”来写，适合长期复用。 Python 项目跨电脑运行与迁移流程（含位数差异、在线与离线） 前提条件 项目目录中已经存在 requirements.txt 项目通过 python main.py 或类似方式启动 使用 Windows 环境为例 工具以 uv + venv + pip 为主 一、本机首次运行流程（标准做法） 1. 安装 Python 解释器 推荐统一 Python 大版本，例如： uv python install 3.11.6 说明： 不必锁死到某个补丁位 大版本一致即可 2. 创建虚拟环境 在项目根目录： uv venv --python 3.11.6 激活环境： .venv\Scripts\activate 确认解释器来自虚拟环境： where python python -V 3. 补齐基础构建工具（关键步骤） python -m ensurepip --upgrade python -m pip install --upgrade pip setuptools wheel 说明： ...

从 GitHub 私有仓库 clone 到本地并切换分支 本文记录一次从零开始的完整流程，包括私有仓库 clone、分支切换，以及 .gitconfig、git config user.name / user.email 的作用说明。 示例环境为 Windows，使用 HTTPS + GitHub token 认证。 一、准备工作 本流程默认你已经完成两件事： 本机已安装 Git GitHub 已生成 Personal Access Token，并具备 repo 权限 Git 不存在“登录态”，token 只在访问远程仓库时使用。 二、clone 私有仓库到本地 进入你希望存放代码的目录： cd D:\python_study 直接 clone 仓库： git clone https://github.com/用户名/仓库名.git 第一次会提示输入凭据： Username：GitHub 用户名 Password：GitHub token clone 成功后，本地会生成一个新的目录： 仓库名/ ├─ .git ├─ ... 从这一刻起，这个目录才是 Git 仓库。 三、查看和切换分支 进入仓库目录： cd 仓库名 查看本地分支： git branch 查看远程分支： ...

背景 在 mac 上修改过 SSH 端口后，需要确认当前 SSH 实际监听的端口，以及配置文件中是否生效，避免误判或锁死远程连接。 排查步骤 一、查看 SSH 当前监听端口 使用 lsof 查看系统中正在监听的 TCP 端口： sudo lsof -iTCP -sTCP:LISTEN | grep ssh 示例输出： launchd 1 root 7u IPv6 TCP *:ssh (LISTEN) launchd 1 root 8u IPv4 TCP *:ssh (LISTEN) 说明： *:ssh 表示监听的是服务名 ssh ssh 在 /etc/services 中对应端口 22 当前 SSH 实际仍在监听 22 端口 该步骤反映的是 当前生效状态，优先级最高。 二、查看 SSH 服务端配置端口 查看 sshd 配置文件中的端口设置： grep -n "^Port" /etc/ssh/sshd_config 可能结果： 无输出：使用默认端口 22 输出如： 17:Port 25422 表示配置文件中指定了监听端口为 25422。 ...

背景 博客使用 Hugo 生成静态页面，Nginx 已配置并指向 /var/www/ 下的发布目录。 发布流程保持最小化，只保留必要动作。 发布流程 第一步：新建文章 在 Hugo 项目根目录执行： hugo new content/posts/xxx.md 文章会生成在： content/posts/xxx.md 只需要记住这个目录即可。 第二步：编辑 Markdown 打开生成的 .md 文件，修改内容，确认： draft: false 或直接删除 draft 行。 第三步：生成并发布 在 Hugo 根目录执行： hugo 生成的静态文件位于： public/ 将 public 目录内容同步到 Nginx 配置的 /var/www/ 目录，即可完成发布。 说明 Hugo 只负责生成内容。 Nginx 只负责对外访问。 发布本质是一次静态文件更新。

下面是一篇可直接放进 Hugo 的日志，偏记录型，干净可复用。 问题现象 从 Windows 通过 SSH 连接 mac，执行 ls 时，目录中的中文文件名全部显示为乱码，例如一串问号或不可读字符。本地 mac 终端显示正常。 初步判断 文件本身未损坏。 问题出在 SSH 会话中的字符编码环境，终端按非 UTF-8 方式解析文件名。 排查过程 1. 确认文件名是否正常 在 mac 本机终端 执行： ls 中文显示正常，说明文件系统无问题。 2. 检查 SSH 会话的语言变量 在 SSH 登录后的 mac 执行： locale 发现 LANG、LC_ALL 为空或不包含 UTF-8。 3. 设置 mac shell 的 UTF-8 环境 mac 默认使用 zsh，编辑配置文件： nano ~/.zshrc 加入： export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8 使配置生效： source ~/.zshrc 重启ssh服务 sudo launchctl unload /System/Library/LaunchDaemons/ssh.plist&&sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist 重新 SSH 登录。 ...

企业微信文本推送接口部署手册（Nginx + PHP-FPM） 一、环境要求 系统：Ubuntu 24.04（其他 Ubuntu 版本同理） Web：Nginx PHP：8.3 网络：服务器可访问 qyapi.weixin.qq.com 用途：内部系统 / 告警 / 自动化调用 二、安装基础环境 1. 更新系统 apt update 2. 安装 Nginx apt install -y nginx systemctl enable nginx systemctl start nginx 3. 安装 PHP-FPM 及必需扩展（一次性装全） apt install -y \ php8.3-fpm \ php8.3-cli \ php8.3-curl \ php8.3-mbstring 启动 PHP-FPM： systemctl enable php8.3-fpm systemctl start php8.3-fpm 确认运行中： systemctl status php8.3-fpm 三、部署代码 1. 创建目录 mkdir -p /var/www/go-wecomchan-php 2. 上传代码 将最终版 send.php 上传到： ...

记录高端的agents.md ## 工作流编排（Workflow Orchestration） ### 1. 默认 Plan 模式（Plan Mode Default） - 对任何非简单任务（3 个以上步骤或涉及架构决策），必须进入 Plan 模式 - 如果过程中出现偏差，立即停止并重新规划，不要继续硬推 - Plan 模式不仅用于构建，也用于验证步骤 - 提前编写详细规格说明，以减少歧义 ### 2. 子 Agent 策略（Subagent Strategy） - 广泛使用子 Agent，保持主上下文窗口整洁 - 将调研、探索和并行分析下放给子 Agent - 面对复杂问题，通过子 Agent 增加计算投入 - 每个子 Agent 只执行一个任务，确保专注 ### 3. 自我改进循环（Self-Improvement Loop） - 每次用户纠正后，按固定模式更新 `tasks/lessons.md` - 为自己编写规则，防止重复犯同样的错误 - 持续严格迭代这些经验，直到错误率下降 - 在会话开始时，回顾与当前项目相关的经验教训 ### 4. 完成前验证（Verification Before Done） - 未经证明可用，不得标记任务完成 - 在需要时，在主 Agent 与子 Agent 之间区分行为 - 自问：“一名高级工程师会认可这个结果吗？” - 运行测试、检查日志、展示正确性证明 ### 5. 要求优雅（平衡）（Demand Elegance · Balanced） - 对非简单修改：暂停并思考是否存在更优雅的方案 - 如果实现显得取巧：“基于我目前所知，实现更优雅的方案” - 对简单、明显的修复跳过此项，避免过度工程化 - 在提交前审视自己的实现 ### 6. 自主缺陷修复（Autonomous Bug Fixing） - 收到缺陷报告后直接修复，不要求用户提供指导 - 查看日志，定位失败的测试并解决 - 不要求用户进行上下文切换 - 在无人告知修复方式的情况下修复失败的 CI 测试 ## 任务管理（Task Management） 1. **计划优先（Plan First）**：将计划写入 `tasks/todo.md`，并确保任务可检查 2. **验证计划（Verify Plan）**：在开始实现前进行检查 3. **跟踪进度（Track Progress）**：执行过程中标记已完成事项 4. **说明变更（Explain Changes）**：在每个步骤给出高层次总结 5. **记录结果（Document Results）**：在 `tasks/todo.md` 中添加评审部分 6. **沉淀经验（Capture Lessons）**：在修正后更新 `tasks/lessons.md` ## 核心原则（Core Principles） - **简单优先（Simplicity First）**：每次修改尽量简单，最小化代码影响 - **拒绝取巧（No Hackiness）**：直击根因，不做临时修补，符合高级工程师标准 - **最小影响（Minimal Impact）**：只修改必要内容，避免引入缺陷