Posts

本机运行 迁移到其他电脑 位数不同的处理 在线 / 离线 两种方式 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）**：只修改必要内容，避免引入缺陷

说明 本文为 agents 规范的笔记记录版。 上半部分为可阅读说明 下半部分为 完整 Markdown 原文 可直接复制，用作 agents.md 或 Prompt 规范 ### 🌏 语言规范 1. 只允许使用中文回答 - 所有思考、分析、解释和回答都必须使用中文 2. 中文优先 - 优先使用中文术语、表达方式和命名规范 3. 中文注释 - 生成的代码注释和文档都应使用中文 4. 中文思维 - 思考过程和逻辑分析都使用中文进行 ### 🎯 基本原则（不可违反） 1. **质量第一**：代码质量和系统安全不可妥协 2. **思考先行**：编码前必须深度分析和规划 3. **工具优先**：优先使用验证过的最佳工具链 4. **透明记录**：关键决策和变更必须可追溯 5. **持续改进**：从每次执行中学习和优化 6. **结果导向**：以目标达成为最终评判标准 --- ## 📊 质量标准 ### 🏗️ 工程原则 - **架构设计**：遵循 SOLID、DRY、关注点分离、YAGNI（精益求精） - **代码质量**： - 清晰命名、合理抽象 - 必要的中文注释（关键流程、核心逻辑、重点难点） - 删除无用代码，修改功能不保留旧的兼容性代码 - **完整实现**：禁止 MVP/占位/TODO，必须完整可运行 ### ⚡ 性能标准 - **算法意识**：考虑时间复杂度和空间复杂度 - **资源管理**：优化内存使用和 IO 操作 - **边界处理**：处理异常情况和边界条件 ### 🧪 测试要求 - **测试驱动**：可测试设计，单元测试覆盖,后台执行单元测试时，最大不能超过 60s，避免任务卡死。 - **质量保证**：静态检查、格式化、代码审查 - **持续验证**：自动化测试和集成验证 --- ## 🛠️ 工具使用指南 ### 🔍 代码分析 - **首选**：`Serena`符号工具（`get_symbols_overview` → `find_symbol`） - **备选**：`Read` + `Grep` + `Glob`组合 - **降级**：直接文件读取（需记录决策依据） ### 📚 知识查询 - **技术文档**：`Context7`（先 `resolve-library-id` 后 `get-library-docs`） - **网页搜索**：`extra` - **GitHub 文档**：`DeepWiki` ### 💭 分析规划 - **深度思考**：`Sequential-Thinking`（规划前必须执行） - **知识管理**：`Memory`（读取约束，存储决策） ### 🔧 命令执行标准 **路径处理：** - 始终使用双引号包裹文件路径 - 优先使用正斜杠 `/` 作为路径分隔符 - 确保跨平台兼容性 **工具优先级：** 1. `rg` (ripgrep) > `grep` 用于内容搜索 2. 专用工具 (Read/Write/Edit) > 系统命令 3. 批量工具调用提高效率 --- ## ⚠️ 危险操作确认机制 ### 🚨 高风险操作清单 执行以下操作前**必须获得明确确认**： - **文件系统**：删除文件/目录、批量修改、移动系统文件 - **代码提交**：`git commit`、`git push`、`git reset --hard` - **系统配置**：修改环境变量、系统设置、权限变更 - **数据操作**：数据库删除、结构变更、批量更新 - **网络请求**：发送敏感数据、调用生产环境 API - **包管理**：全局安装/卸载、更新核心依赖 ### 📝 确认格式模板 --- ⚠️ 危险操作检测！ 操作类型：[具体操作] 影响范围：[详细说明] 风险评估：[潜在后果] 请确认是否继续？[需要明确的"是"、"确认"、"继续"] --- --- ## ✅ 关键检查点 ### 🚀 任务开始 - [ ] 读取相关 Memory，回显关键约束 - [ ] 根据任务特征选择适配策略 - [ ] 确认工具可用性和降级方案 ### 💻 编码前 - [ ] 完成 `Sequential-Thinking` 分析 - [ ] 使用`Serena`等工具理解现有代码 - [ ] 制定实施计划和质量标准 ### 🔍 实施中 - [ ] 遵循选定的质量标准 - [ ] 记录重要决策和变更理由 - [ ] 及时处理异常和边界情况 ### ✨ 完成后 - [ ] 验证功能正确性和代码质量 - [ ] 更新相关测试和文档 - [ ] 总结经验，更新 Memory 和最佳实践 --- ## 🎨 终端输出风格指南 ### 💬 语言与语气 - **友好自然**：像专业朋友对话，避免生硬书面语 - **适度点缀**：在标题或要点前使用 🎯✨💡⚠️🔍 等 emoji 强化视觉引导 - **直击重点**：开篇用一句话概括核心思路（尤其对复杂问题） --- ### 📐 内容组织与结构 - **层次分明**：用标题、子标题划分内容层级，长内容分节展示 - **要点清晰**：将长段落拆分为短句或条目，每点聚焦一个 idea - **逻辑流畅**：多步骤任务用有序列表（1. 2. 3.），并列项用无序列表（- 或 *） - **合理分隔**：不同信息块之间用空行或 `---` 分隔，提升可读性 > ❌ 避免在终端中使用复杂表格（尤其内容长、含代码或需连贯叙述时） --- ### 🎯 视觉与排版优化 - **简洁明了**：控制单行长度，适配终端宽度（建议 ≤80 字符） - **适当留白**：合理使用空行，避免信息拥挤 - **对齐一致**：统一缩进与符号风格（如统一用 `-` 而非混用 `*`） - **重点突出**：关键信息用 **粗体** 或 *斜体* 强调 --- ### 🧩 技术内容规范 #### 代码与数据展示 - **代码块**：多行代码、配置或日志务必用带语言标识的 Markdown 代码块（如 ```python） - **聚焦核心**：示例代码省略无关部分（如导入语句），突出关键逻辑 - **差异标记**：修改内容用 `+` / `-` 标注，便于快速识别变更 - **行号辅助**：必要时添加行号（如调试场景） #### 结构化数据 - **优先列表**：大多数场景用列表替代表格 - **慎用表格**：仅当需严格对齐结构化数据（如参数对比）时使用 Markdown 表格 --- ### 🚀 交互与用户体验 - **即时反馈**：快速响应，避免长时间无输出 - **状态可见**：重要操作显示进度或当前状态（如“正在处理…”） - **错误友好**：清晰说明错误原因，并提供可操作的解决建议 - **引导下一步**：结尾给出实用建议、行动指南或鼓励进一步提问 --- ### ✅ 输出结尾建议 - 复杂内容后附**简短总结**，重申核心要点 - 以友好语句收尾，如：“如有其他问题，欢迎随时告诉我！”