# hooks
中文名为钩子，实际常用于代码某些执行阶段触发某些逻辑，如结尾触发检测或测试，使得代码编译正常。

安全防线、质量守卫、审计日志，全部由 Hooks 在“幕后”自动完成，高频用于自动化或安全控制；

cursor中hooks配置：https://cursor.com/cn/docs/hooks
claude code: https://code.claude.com/docs/en/hooks-guide

# 实践
针对vue3代码：高频用于eslint 运行没问题后再给到执行，可以有效降低AI带来的语法等问题。

配置：Cursor Hook（钩子），用来在 AI Agent 每次“结束回答”时自动做一次 ESLint 检查

文件位置：.cursor/hooks.json

```js
{
  "version": 1,
  "hooks": {
    "stop": [
      {
        "command": "node .cursor/hooks/local-lint-check.mjs",
        "timeout": 300,
        "loop_limit": 3
      }
    ]
  }
}

```

:::info{title="相关信息"}
含义：

stop：事件类型。当 Agent 一轮任务“停止/完成”时触发（也就是 AI 觉得自己干完活、准备把结果交给你之前）。
command：触发时运行的命令，这里就是执行那个 .mjs 脚本。
timeout: 300：脚本最多跑 300 秒，超时就中断。
loop_limit: 3：最关键的一点——如果 hook 让 Agent 继续修（返回了 followup_message），最多循环 3 次，防止无限循环。
:::
.cursor/hooks/local-lint-check.mjs

```js
#!/usr/bin/env node
/**
 * Cursor stop hook: lint changed src files with the same ESLint rules as `npm run local`
 * (vite-plugin-eslint in config/vite.config.dev.ts).
 */
import { spawnSync } from 'node:child_process'
import { readFileSync } from 'node:fs'

const MAX_OUTPUT_CHARS = 8000
const LINTABLE_FILE = /\.(vue|ts|tsx|js|jsx)$/i

function readHookInput() {
  try {
    const raw = readFileSync(0, 'utf8')
    return raw ? JSON.parse(raw) : {}
  } catch {
    return {}
  }
}

function runGit(args) {
  const result = spawnSync('git', args, {
    cwd: process.cwd(),
    encoding: 'utf8',
    shell: process.platform === 'win32',
  })
  return (result.stdout || '').split(/\r?\n/).filter(Boolean)
}

function getChangedLintableFiles() {
  const files = new Set()

  for (const file of runGit(['diff', '--name-only', 'HEAD', '--', 'src/'])) {
    if (LINTABLE_FILE.test(file)) files.add(file)
  }
  for (const file of runGit(['diff', '--cached', '--name-only', 'HEAD', '--', 'src/'])) {
    if (LINTABLE_FILE.test(file)) files.add(file)
  }
  for (const file of runGit(['ls-files', '--others', '--exclude-standard', 'src/'])) {
    if (LINTABLE_FILE.test(file)) files.add(file)
  }

  return [...files]
}

function runEslint(files) {
  const npx = process.platform === 'win32' ? 'npx.cmd' : 'npx'
  const result = spawnSync(
    npx,
    ['eslint', ...files, '--max-warnings', '0', '--format', 'stylish'],
    {
      cwd: process.cwd(),
      encoding: 'utf8',
      shell: process.platform === 'win32',
      env: process.env,
    }
  )

  const output = [result.stdout, result.stderr].filter(Boolean).join('\n').trim()
  return {
    ok: result.status === 0,
    output,
    exitCode: result.status ?? 1,
  }
}

function emit(result) {
  process.stdout.write(`${JSON.stringify(result)}\n`)
}

const input = readHookInput()

if (input.status === 'aborted') {
  emit({})
  process.exit(0)
}

const changedFiles = getChangedLintableFiles()

if (changedFiles.length === 0) {
  emit({})
  process.exit(0)
}

const { ok, output, exitCode } = runEslint(changedFiles)

if (ok) {
  emit({})
  process.exit(0)
}

const truncated =
  output.length > MAX_OUTPUT_CHARS ? `${output.slice(0, MAX_OUTPUT_CHARS)}\n...(输出已截断)` : output

const fileList = changedFiles.map((f) => `- ${f}`).join('\n')

emit({
  followup_message: `本地 Lint 检查未通过（规则与 npm run local 开发服一致）。请修复以下问题：

检查文件：
${fileList}

\`\`\`
${truncated || `eslint 退出码 ${exitCode}`}
\`\`\`

可本地复现：npx eslint ${changedFiles.join(' ')}`,
})

process.exit(0)

```
代码每次跑完，都会自动触发eslint check
使得：

:::info{title="相关信息"}
每当 AI 觉得自己写完代码要收工时，自动对它改过的前端文件跑一遍 ESLint。过了就放行；没过就把报错自动丢回给 AI 让它继续修，最多重试 3 次。 相当于给 Agent 装了一道“交作业前的自动质检关卡”，保证它给你的代码不会有 lint 错误
:::
```js
已修复 Prettier 格式问题：将「复用HEX」表单项和 a-option 的多行属性合并为单行。npx eslint 现已通过（exit code 0）。
```

```js
已修复 detail.vue 中的 2 处 Prettier 格式问题：
第 117 行：将 a-button 的多行属性合并为单行
第 726 行：将三元表达式合并为单行
对上述两个文件的 ESLint 检查已通过。
```


```js
已修复：将 fetchReuseHexCandidates 及其依赖的 isPersonalUploadedHex、sortReuseHexOptions 提前到 resetImportState 之前定义，消除 no-use-before-define 报错。
上述 3 个文件的 ESLint 检查均已通过。
```

AI编程中hooks理解

# 背景
对安卓底层启动进行验证，得知其链路流转顺序，可以得知：
1. App.java — 应用级全局初始化， 整个应用进程只初始化一次，与具体界面无关；
2. MainActivity.java — 主界面 / 业务入口；
3. 
总结：App.java 做应用级基础设施初始化；MainActivity.java 做主界面和业务逻辑。先 App 后 MainActivity 是 Android 标准流程
# 过程验证及结论
已知代码：
app/src/main/java/com.xiaob.remotecalibtation/App.java
```java
@SuppressLint("RestrictedApi")
    protected void asyncInit() {
        Log.i(TAG, "asyncInit");
        Xui.setLogLevel(XLogUtils.LOG_I_LEVEL);//日志级别
    }
```

app/src/main/java/com.xiaob.remotecalibtation/ui/MainActivity.java

```java
@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.at_activity_main);
        Log.i(TAG, "asyncInit");
    }
```
对应用执行启动后，可以发现

```sh
2026-07-03 18:23:46.298 13203-15667 remoteCalibration_App   com.xiaopeng.remotecalibration       I  asyncInit
2026-07-03 18:23:46.437 13203-13203 MainActivity            com.xiaopeng.remotecalibration       I  asyncInit
```
结论为：
```js
启动顺序为什么是先 App 再 MainActivity
这是 Android 的正常生命周期：
进程启动 → Application.onCreate()（App.java）
再启动 Launcher Activity → Activity.onCreate()（MainActivity.java）

```
针对App.java — 应用级全局初始化

```java
    @Override
    public void onCreate() {
        super.onCreate();
        sAppInstance = this;
        isSyncInit = true;
        init();
    }

    @CallSuper
    protected void init() {
        Log.i(TAG, "init");
        syncInit();
        if (isSyncInit) {
            ThreadUtils.execute(this::asyncInit);
        } else {
            asyncInit();
        }
    }
```

:::info{title="相关信息"}
职责：整个应用进程只初始化一次，与具体界面无关。

syncInit()（主线程，同步）

PathManager 路径管理
Xui UI 框架
ApplicationLifecycleCallback 生命周期回调
asyncInit()（后台线程，异步）

BugHunter 崩溃/异常监控
网络模块（NetworkChannelsEntry、HttpsUtils、IHttp）
埋点（DataLogModuleEntry）
环境配置（EnvironmentConfig）
网络变化监听（ConnectionChangeReceiver）
启动 OSSUploadService、初始化 TestReporterSDK
打印版本信息
另外还提供 getInstance()、getHttp() 等全局访问入口，并在 onTerminate() 里清理 Service 和 Receiver。
:::
针对MainActivity.java — 主界面 / 业务入口

:::info{title="相关信息"}
职责：远程标定测试的主界面，负责 UI 和业务交互。

主要工作包括：

加载布局 at_activity_main，初始化标题栏（VIN、CFC、版本、任务名、诊断状态等）
初始化 DataFileViewModel，从远端或本地加载测试任务
加载 TestCaseListFragment 展示测试用例列表
配置环境切换监听（EnvironmentConfig + RetrofitClient）
标定执行：startExecutor、interruptOperation、recoverXcpData、filterInvalidData 等
关闭前检查是否有任务在执行；onDestroy 时停止长时间 DAQ 读取
:::
# 简要图

```js
flowchart TD
    A[进程启动] --> B[App.onCreate]
    B --> C[syncInit: 路径/XUI/生命周期]
    B --> D[asyncInit 后台: 网络/埋点/Service]
    B --> E[MainActivity.onCreate]
    E --> F[UI + ViewModel + 加载任务 + Fragment]
    D -.->|提供全局能力| F
```

# 其他补充
App.java调用链：

```js
onCreate() → init() → syncInit() → asyncInit()
```
避免在 Application.onCreate 里把网络、埋点、Service 等全塞进主线程，减少启动卡顿；同时保证 UI 相关（XUI 等）在主线程先就绪。

:::info{title="相关信息"}
onCreate

super.onCreate()：走系统 Application 生命周期

sAppInstance = this：保存全局单例，供 getInstance() 使用

isSyncInit = true：标记「异步初始化要放到子线程」

调用 init()

init

先执行 syncInit()（主线程，必须尽快完成）

再根据 isSyncInit 决定 asyncInit() 怎么跑：
:::

:::info{title="相关信息"}
syncInit()（主线程） — 启动立刻要用的：

路径、XUI（字体缩放 / 全屏弹窗 / 单例 Toast）
应用生命周期回调
asyncInit()（后台） — 可延后的：

BugHunter、网络模块、HTTPS、埋点
环境配置、网络变化监听
启动 OSSUploadService、TestReporterSDK
打印版本信息
:::

安卓初始化相关事项

SDD规范驱动开发

# 背景
AI时代，很多人接手老项目，上来就是直接coding，但受限于Agent上下文，通常会可能改动会这边动一点，也改的不够彻底，结果就是看似改了一点，也成功了一点点，就是达不到预期

新项目：先opus4.7规划API_REFERENCE.md architecture.md module-deps.md API_REFERENCE.md  schema.md，同时svg格式查看，然后对一下这些md是否OK（过程可能需要多次），之后再分拆需求，针对局部编码

# 思路
1. 找相关的人聊，可能每个人懂一点，拼起来，整理为md(AI介入：AI 能帮你整理疑点清单、草拟问题)；
2. 查看所有的资料，比如Wiki、readme（AI介入：AI 读 README、wiki、Confluence、jira 比你快十倍）；
3. clone代码、全部读一遍（AI介入：让 AI 扫一遍仓库，生成一张模块图、数据流图，md下来）；
4. 搭建环境，Run起来；
5. 核心接口关注，curl跑一遍（AI介入：让 AI 从代码里梳理出所有接口清单 + curl 示例，md下来）；
6. 针对疑点去深挖代码（AI介入：AI 能扫描代码给你找调用链路）；
7. 画流程图：针对核心流程（AI介入：核心的链路大致可以画出来，但隐形的约定等需要个人补充）；
8. 改代码，过程需要遵循先小改，拆分多个部分；
9. 验收：确保主流程OK、相关的业务场景OK、同时找独立同等水平及以上的人review（AI介入：do checklist）；

# 注意点（80% 的完成度当成 100%）
1. 判断哪些代码不能动：像“// 勿动，某某对接方需要”的注释；
2. 注意隐性约定，如接口对接约定的定义；

# 做法
1. AI 主导做 80%，翻资料、浏览代码结构、访接口都在这里，放手让 AI 做就行。
2. 人机对半 AI 做 50%，找人聊、搭环境、深挖、画链路、动手改都在这里，整门课大部分功夫花在这一档。
3. 人主导 AI 做 20% 或更少，判断代码能不能动、对接方是谁、最终验收、上线风险识别都在这里。

记住那句话：20% 的盲区，经常就是 100% 的事故。AI 做不到的那 20%，你不主动补，它就是 0。

# 心法
1. 读 README 和根目录docs的文档;
2. 看目录和包组织。Java 项目看 pom.xml 的 module 划分;python项目看requirements；
3. 找核心入口，HTTP 服务找 controller 和 main 函数；
4. 画出项目全景，架构图、模块依赖图、核心数据流图，关键是要动手画！！！
5. 梳理接口和数据模型；
6. env、Run；
7. 带着需求深挖代码，有目标的读胜过无目标的读一百倍；
8. 沉淀成 AI 能读的文档：CLAUDE.md（项目特定的上下文备忘录）和 SKILL.md（可复用的操作模板）；

# 其他注意点
1. 先规划，规划直接上cot能力强的模型，如opus4.7
2. 分拆成若干小需求，每个需求尽量一个chat，除非相关性很强才放一起；
3. 后端尽量F12补货到具体的请求后直接全部copy，再补充需求去chat；
4. 前端尽量获取到path再组合请求去问题，减少Agent全屏查找的成本；
5. 新模型生成时，带上单元测试；
6. 新需求，直接把参考代码目录放进去，直接引用目录，并带出具体的参考部分，再去让AI参考生成需求；
7. 情非得已，尽量不要动旧接口，只增不减；
8. 改动时，@引用代码部分，再补需求去chat；

# 现状
现在日常：
cursor（主，pro会员opus4.7可以支持约10天） + CC（DS-v4-pro，反应比cursor慢） +qoder(opus4.7 3000次) +copilot（opus4.7 300次） +灵犀（放弃了，已删除）

# 汇报
1. .claude目录
2.  docs目录：API_REFERENCE.md architecture.md module-deps.md API_REFERENCE.md  schema.md
如果没必要上传，可以.ignore忽略以上目录

如果要写项目相关的md文档，直接引用@doc再去生成各种汇报的md，再必要补一些图即可

hooks

背景

SDD 规范驱动开发（Spec-Driven Development）培训文档

背景

背景