常用 Git 命令 Init 在已有目录中初始化 GIT 仓库 $ git init $ git remote add origin <仓库地址> $ git add . $ git commit -m "Initial commit" $ git push -u origin master Branch 创建分支 git checkout -b <分支名> 推送分支 git push origin <分支名> 修改分支名 git branch -m <旧分支名> <新分支名> 删除本地分支 git branch -D <分支名> 删除远程分支 git push origin --delete <分支名> 拉取远程分支 git fetch origin <分支名> 拉取远程分支并切换 git checkout -b <分支名> origin/<分支名> 当前分支会退到指定版本

常用 Docker 命令记录 镜像 镜像列表按照大小排序 docker images --format "{{.ID}}\t{{.Size}}\t{{.Repository}}" | sort -k 2 -h 删除所有镜像 docker rmi -f $(docker images | awk '{print $3}') 删除所有 dangling 镜像 docker rmi -f $(docker images -a | grep "<none>" | awk '{print $3}') 导出镜像 docker save -o postgres_9.6.tar postgres:9.6 docker save postgres:9.6 | gzip > postgres_9.6.tar 导入镜像 docker load -i postgres_9.6.tar 容器 删除所有 Exited 容器 docker rm $(docker ps -a | grep Exited | awk '{print $1}') 停止并删除所有容器 docker stop $(docker ps | awk '{print $1}') docker rm -f $(docker ps -a | awk '{print $1}') 停止 dead 容器 删除实例时提示 device or resource busy

Flyway 连接 MySQL Router 后启动卡在 GET_LOCK 语句 现象 MySQL MGR + Router 部署高可用集群 Flyway 客户端使用 jdbc:mysql:loadbalance 连接 初始化 Schema History 表、或者执行多个 SQL 脚本时 当满足以上条件时，Flyway 会卡在初始化阶段，经过分析发现停顿在执行 GET_LOCK 语句时 原因 Flyway 默认在执行 DDL 脚本时不启用事务，在初始化时 Flyway 会先执行 GET_LOCK 锁定数据库，然后再执行 DDL 脚本。当使用 jdbc:mysql:loadbalance 连接时，会随机选择一个数据源，如果执行 GET_LOCK 和 执行 DDL 不是一个数据源，就会导致执行等待锁释放 解决办法 在启动时设置 group=true 参数，这样 Flyway 在初始化时就会启用事务，确保一个事务内的 DDL 都在一个数据源执行 ISSUE-3154 public class FlywayTestManual { String url="jdbc:mysql:loadbalance://192.168.51.206:3810,192.168.51.207:3810/nc_notifier?roundRobinLoadBalance=false&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=false&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=GMT%2B8&allowMultiQueries=true&allowPublicKeyRetrieval=true"; String user="user"; String password="pass"; @Test public void test(){ Flyway flyway = Flyway.

记录在使用 Flyway 管理 Oracle 数据库脚本时遇到的一些问题，Flyway 5.2.1 - 7.7.3 都存在此问题。 1. Flyway not support Oracle 11g 异常信息 Caused by: org.flywaydb.core.internal.license.FlywayEditionUpgradeRequiredException: Flyway Enterprise Edition or Oracle upgrade required: Oracle 11.2 is no longer supported by Flyway Community Edition, but still supported by Flyway Enterprise Edition. at org.flywaydb.core.internal.database.base.Database.ensureDatabaseNotOlderThanOtherwiseRecommendUpgradeToFlywayEdition(Database.java:173) at org.flywaydb.core.internal.database.oracle.OracleDatabase.ensureSupported(OracleDatabase.java:91) at org.flywaydb.core.Flyway.execute(Flyway.java:514) at org.flywaydb.core.Flyway.migrate(Flyway.java:159) at org.springframework.boot.autoconfigure.flyway.FlywayMigrationInitializer.afterPropertiesSet(FlywayMigrationInitializer.java:65) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1855) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1792) ... 19 common frames omitted 修改 Flyway 5.2.4 OracleDatabase.java 社区版本做了版本号限制 修改 Flyway 6.5.7 OracleDatabase.

Flyway 通过 SQL Patch 脚本的方式管理数据库脚本版本，开发一段时间后会积攒大量脚本。当一个版本稳定后我们希望合并成一个全量脚本 1.首先对齐程序与数据库中的脚本版本号 查看程序中脚本版本清单，例如：程序中有三个版本的脚本 V1.0.0.0__init.sql V1.0.0.1__add_user_table.sql V1.0.0.2__modify_user_table.sql 查看数据库中历史版本记录表 (默认是 flyway_schema_history) 中执行过的脚本版本，例如： versions description script success 1.0.0.0 init.sql V1.0.0.0__init.sql 1 1.0.0.1 add_user_table.sql V1.0.0.1__add_user_table.sql 1 1.0.0.2 modify_user_table V1.0.0.2__modify_user_table.sql 1 这里只摘取了关键字段，你可以看到每个版本都已经执行，并且执行都是成功的 success=1 至此：你已经对齐了程序和数据库中脚本版本号，可以开始准备合并了 2.合并程序中的SQL脚本 合并多个脚本的内容到最大版本号的文件中，例如：将 V1.0.0.0__init.sql, V1.0.0.1__add_user_table.sql, V1.0.0.2__modify_user_table.sql 合并为 V1.0.0.2__init.sql 注意： 不是简单的文件合并，而是最终执行结果的合并 3.重新打包程序 只包含合 V1.0.0.2__init.sql 脚本的程序 4.停止所有老版本的程序 包含 V1.0.0.0__init.sql,V1.0.0.1__add_user_table.sql,V1.0.0.2__modify_user_table.sql 老脚本的程序 5.删除数据库中的版本历史表 默认是 flyway_schema_history 6.重启应用程序 在程序启动时设置基线版本参数为当前版本，设置这个参数的目的是告诉 Flyway 当前已经执行过 1.0.0.2 脚本了。这之前的脚本不要再执行了。 flyway.baseline-version=1.0.0.2 注意： 如果是空库，全新安装程序，那么则不需要设置 flyway.baseline-version 参数 7.结束 查看数据库中历史版本记录表 (默认是 flyway_schema_history) 中执行过的脚本版本，例如： versions description script success 1.

常用 Maven 命令 Parameters -D 指定参数，如 -Dmaven.test.skip=true 跳过单元测试； -P 指定 Profile 配置，可以用于区分环境； -e 显示maven运行出错的信息； -o 离线执行命令,即不去远程仓库更新包； -f 强制指定使用 POM 文件，或者包含 POM 文件的目录 -pl 选项后可跟随{groupId}:{artifactId}或者所选模块的相对路径(多个模块以逗号分隔) -am 表示同时处理选定模块所依赖的模块 -amd 表示同时处理依赖选定模块的模块 -rf 表示从指定模块开始继续处理 -N 表示不递归子模块 -X 显示maven允许的debug信息； -U 强制去远程更新 snapshot的插件或依赖，默认每天只更新一次。 –no-snapshot-updates 禁止更新 snapshot Dependency 显示maven依赖数 mvn dependency:tree 显示maven依赖列表 mvn dependency:list 下载依赖包的源码 mvn dependency:sources Maven Wrapper 自动安装 maven 的包装器（适合不想手动安装Maven的用户），使用插件Maven Wrapper plugin将其自动化安装指定版本的 Maven mvn -N io.takari:maven:wrapper -Dmaven=3.6.3 这个命令会在你的项目中生成如下文件，请将这些文件与源代码一起管理 mvnw: 这是 Linux Script 可执行文件，用来代替 mvn mvnw.cmd: 这是 Windows Script 可执行文件，用来代替 mvn mvn: 隐藏的文件夹，其中包含Maven Wrapper Java库及其属性文件 首次执行 mvnw 或者 mvnw.

通过单个服务器压测的 QPS 估算需要的服务器数量 已知 QPS 和期望每笔耗时，估算服务器数量 服务器数量 $$ = QPS \div (1000 \div 每笔毫秒) \div 每服务器CPU个数 $$ 例如： QPS：每秒处理3200笔 每笔毫秒：50ms 每个服务器CPU个数：16 服务器数量 $$ 3200_{qps} \div (1000_{ms} \div 50_{ms}) \div 16_{cpu} = 10_{台} $$ 已知 QPS 以及服务器数量，估算每笔耗时 每笔耗时毫秒 $$ = 1000 \div ( QPS \div ( 服务器数量 \times 每服务器CPU个数 ) ) $$ 例如： QPS：每秒处理3200笔 服务器数量：10 每服务器CPU个数：16 每笔耗时毫秒 $$ 1000 \div ( 3200 \div ( 10 \times 16 ) ) = 50_{ms}$$

Pain Points in Data Analysis and Solutions In today’s data-driven business environment, a common scenario is: business analysts urgently need certain data analysis but must wait for technical team members who know SQL to provide support. According to a McKinsey study, analysts spend an average of 30-40% of their time just on data preparation and query construction. This dependency not only delays the decision-making process but also increases the workload of the technical team.

AGENTS.md 工作哲学 你是这个项目的研究协作者，不是等待指令的助手。你的职责不是“陪我讨论”，而是主动推进对新技术、新产品、新方向的理解、验证和收敛。参考以下风格： John Carmack 的 .plan 文件风格：完成一轮研究后，直接报告： 你研究了什么 为什么值得研究 得出了什么结论 哪些假设被证伪 下一步最值得继续追的方向 优秀技术调研 / RFC 风格：每一次输出都应该是一个完整、可评审、可继续推进的研究单元，而不是“我先随便搜一点你看看”。 你交付的应该是： 问题定义 候选方案 对比与取舍 风险与未知 你建议的方向 Unix 哲学：一次研究只解决一个明确问题。不要在过程中不断汇报“我准备去查 X”“接下来可能查 Y”。先完成，再输出。 你的目标 你的目标不是生成“看起来懂很多”的内容，而是帮助用户： 更快理解一个新领域 更快判断一个方向是否值得做 更快识别风险、约束和前提 更快形成可以落地的产品、技术或实验方案 你的输出应该持续推动事情从： 模糊概念 → 可验证假设 → 可比较方案 → 可执行计划 你要服从的对象 按优先级： 问题本身的真实约束 技术上是否真的成立 产品上是否真的有价值 是否符合现有行业、成本、时间、组织能力的限制 已有事实与证据 已知论文、产品、行业实践、已有代码或已有方案 不要为了“给出答案”而忽略证据 用户明确、无歧义的目标 用户想解决什么问题 用户真正关心的是成本、效果、速度、风险，还是长期价值 这些高于“为了显得礼貌而不断征询意见”。 关于停下来询问 只有一种情况可以停下来问： 存在真正的歧义，而不同理解会导致研究方向、结论或建议完全不同。 例如： 用户说“研究机器人视觉”，但不清楚是在做： 工业检测 6D 位姿 视觉伺服 通用具身智能 用户说“做一个 AI 产品”，但不清楚目标是： ToC ToB 内部效率工具 平台型产品 除此之外，不要停下来问。

怎么读这三张图，以及结论是什么 这三张图讨论的是同一个工业场景： 跨站补料与空箱回收的移动机器人任务级闭环。 具体条件也是同一组： 当前任务：从 A 仓位取一箱连接器，送到 3 号装配站，并回收空箱 执行中异常：去往 3 号站途中发现该站暂时占用，机器人剩余电量降到 18% 系统候选：先去临时缓存位 -> 判断是否需要补能 -> 去充电点补能 -> 重新规划路线 -> 到站交付 -> 回收空箱 若仍无法完成：转人工调度 三张图不是在画三个不同系统，而是在用三种不同的表达方式描述同一件事。只有放在一起看，差别才真正明显。 先看哪张 最好的阅读顺序是： 先看流程图 再看状态机 最后看行为树 原因很简单。 流程图最容易看懂，它先把“这件事大概怎么走”讲清楚。状态机会让你看到，一旦把这件事写成可执行控制逻辑，状态和转移很快就会开始膨胀。行为树则回答最后一个问题：如果我们既想让它可执行，又想让它可复用、可回退、可扩展，应该怎么组织。 第一张图在回答什么 流程图文件： abb-isaac-agent-flexible-manufacturing-ai-first-07-why-behavior-tree-flowchart-example.puml 这张图回答的问题是： 这条任务闭环，按步骤大概怎么走。 它适合说明下面这些事： 从 A 仓位取料之后，会向 3 号站发起交付任务。 如果目标站占用，系统会先去缓存位。 如果等待期间电量不够，系统会插入补能分支。 站点释放并重新规划成功后，系统会继续交付并回收空箱。 它最适合拿来做： 文档说明 给非机器人软件背景的人做场景介绍 讨论业务流程和处理顺序 但它不擅长回答： 哪些判断会被反复检查 哪些子流程可以复用 哪些失败只需要局部插入一个恢复子流程 运行时如何持续推进整个执行结构 所以流程图最像“说明书”，不太像“执行骨架”。 第二张图在回答什么 状态机文件： abb-isaac-agent-flexible-manufacturing-ai-first-07-why-behavior-tree-fsm-example.puml 这张图回答的问题是： 如果把这条任务闭环写成可执行状态逻辑，系统会有哪些状态、怎样转移。 它适合说明下面这些事： 什么时候进入去缓存位中、等待站点释放中、去充电点中、重新规划中 什么时候能从等待恢复到重新去站点 什么时候必须转人工调度 它最适合拿来做： 设备级或站级控制逻辑 资格判断明确、转移条件明确的确定性流程 底层导航模块、充电模块、设备联锁层的状态控制 但放到这个场景里，它会开始暴露问题：