2026-03-02(周一)

• 随记：
  • 调研监护仪自动化测试方法
  • 面试被鸽了
• 反思：
  • MCP is dead. Long live the CLI
  • 如果用 Claude code + MCP 来控制监护仪？

2026-03-03(周二)

• 随记：
  • 完成监护仪UI 自动化项目：Monitor-eye
• 反思：
  • 如果监护仪无法使用 VNC 远程控制，得另想办法

2026-03-04(周三)

• 随记：
  • 收到 offer，整理入职材料
• 反思：
  • 得开始构建 soulwork 测试用例集以及落地接口自动化

2026-03-06(周五)

• 随记：
  • 体检
  • 通过 mitmproxy 抓包导出所有接口，进行测试
• 反思：
  • 梳理测试大架构，后续怎么从 0 到 1 开展

2026-02-23(周一)

• 随记：
  • 确认AIGC方向
  • 创建了一个 job-hunter skill，分析了十几个岗位的匹配度
• 反思：

2026-02-24(周二)

• 随记：
  • 学习ai agent 测试方法
  • 安装 mitmproxy 进行手机端抓包
  • 借助 claude code 发现 soulwork 小程序的多个 P0/P1漏洞
• 反思：
  • mitmproxy 是 cli 版，对比其他抓包软件，目前在 AI 的加持下，cli 是最适配的

2026-02-25(周三)

• 随记：
  • 面试 soulwork
  • 安装 tailscale，成功在手机上可以使用 Claude code
  • 创建 tech 调研 skill
  • 使用 deepeval 来测试 soulwork
• 反思：

2026-02-26(周四)

• 随记：
  • api 转 cli https://github.com/alexknowshtml/api2cli
  • 跑通了 langsmith：设置了 50 个用例 x 4个评估器
• 反思：
  • DeepEval：想快速跑通评估+CI；LangSmith：需要 Tracing 可观测性+数据集管理+实验对比

2026-02-27(周五)

• 随记：
  • 通过 mcp，把 codex/gemini 全串起来，codex 用来审查代码，gemini 可以用来给文章配图
  • 面试后，整理了soulwork 的测试流程文档以及提到问题解决方案
• 反思：

2026-02-28(周六)

• 随记：
  • Keploy：API, Integration, E2E，其中集成测试最强 https://github.com/keploy/keploy
  • tech-radar skill 从全页读取优化成 goal-driven，预估节省 80% token
  • obsidian cli 配置，把文档全部同步到笔记
• 反思：

2026-03-01(周日)

• 随记：

  • 试玩了一下 Dify+n8n，出现了点问题，还是得靠 codex 解决。
  • 整理一套自动生成测试用例的 skill
  
  • [ ]

• 反思：

  • 有个 AI 应用工程师的岗位 JD，以前想的是原子化 skill，一直没有做个Agent，打通内部流程。

本周复盘

• Keep (继续保持)：*
• Improve (需要改进)：*
• Try (下周尝试)：*

• 一句话总结：
• 进度：

每日记录 (Daily Log)

2026-02-09(周一)

• 随记：
  • 修改 claude code 的输出风格 output_style为白描美学
  • 搭建 Obsidian，配置 Claude Code 通过 MCP 管理笔记
  • 整理 Claude Skill 构建指南总结
• 反思：
  • 后续看看 obsidian 里文章怎么双向链接，构建自己的知识库

2026-02-10(周二)

• 随记：
  • 整理文章2026 Agentic Coding Trends Report
  • 学习openclaw 的核心引擎 Pi，Pi 拥有所有代理中最短的系统提示（system prompt），只4 个基本工具：Read、Write、Edit、Bash。
  • andrej-karpathy-skills避免 claude code 乱写代码
• 反思：
  • Pi+skills 是否能构建垂直 agent

2026-02-11(周三)

• 随记：
  • 收拾东西回家
  • Obsidian 更新了 cli 版，后续可以更加方便使用 ai 控制
• 反思：
  • 后面还是搞个 mac mini

2026-02-12(周四)

• 随记：
  • 终于是到家了
• 反思：
  • OpenClaw接入类似小智esp32
  • Home Assistant

本周复盘 (Weekly Review)

• Keep (继续保持)：*
• Improve (需要改进)：*
• Try (下周尝试)：*

• 一句话总结：
• 进度：

每日记录 (Daily Log)

2026-02-02 (周一)

• 随记：
  • spotify 到期了，写一个本地音乐播放器
  • llm-eval 学习模块 1-2
• 反思：
  • 有点焦虑，注意力不集中了

2026-02-03 (周二)

• 随记：
  • 休息
• 反思：
  • 休息

2026-02-04 (周三)

• 随记：
  • 学习了 BDD基础
  • 安装了前端 skill：ui-ux-pro-max，做一个登录界面看看效果
• 反思：
  • 测试必须关注做什么，而不是怎么做
  • codex 和 claude code 马上又要发布新模型了，后续可以深入学习如何使用

2026-02-05 (周四)

• 随记：
  • 继续学习 BDD
• 反思：
  • 没心思学习了

2026-02-06 (周五)

• 随记：
  • 基于原来主题创建一个了新主题 hexo-theme-hanli
  • 做了一个自然语言转成 SQL 的 vanna-demo
• 反思：
  • 需要读一下 claude code 官方使用文档

2026-02-07 (周六)

• 随记：
  • 使用 brainstorm 制定了一个测试学习计划，已经快学完第一轮
  • 使用 brainstorm 发散下 AI 时代测试有什么不同
• 反思：
  • 今天使用了 codex5.3，感觉还是 cc 做计划，codex 执行

2026-02-08 (周日)

• 随记：
  • codex --yolo 也开启最高权限试了用 skill 学习，做中学和迭代是两个核心点，但是不如人意，没有 cc 好
• 反思：
  • 单接口如何随意串联起来 传统 vs AI
  • ODC(正交缺陷分类) RCA(根因分析)

本周复盘 (Weekly Review)

• Keep (继续保持)：*
• Improve (需要改进)：*
• Try (下周尝试)：*

来源：Boris Cherny (@bcherny) - Claude Code 团队成员分享的 10 个高效技巧

目录

1. Git Worktree 并行开发
2. Plan Mode 规划模式
3. CLAUDE.md 记忆文件
4. 自定义 Skills
5. 自主修 Bug
6. 提升 Prompting 技巧
7. 终端与环境配置
8. 使用 Subagents
9. 数据分析
10. 用 Claude 学习

1. Git Worktree 并行开发

核心理念

同时开启多个 worktree，每个运行独立的 Claude 会话，并行工作效率翻倍。

什么是 Git Worktree？

通常一个 git 仓库只有一个工作目录。Worktree 允许你从同一个仓库创建多个工作目录，每个目录可以切换到不同的分支。

1
2
3
4
5
6
7
8
9

普通方式：
my-project/          ← 只能同时在一个分支工作

使用 Worktree：
my-project/                    ← 主目录，在 main 分支
my-project/.claude/worktrees/
├── feature-a/                 ← 在 feature-a 分支
├── feature-b/                 ← 在 feature-b 分支
└── bugfix/                    ← 在 bugfix 分支

为什么配合 Claude Code 很强？

传统工作流：

1

让 Claude 做任务 A → 等待完成 → 再做任务 B → 等待完成 → 再做任务 C

Worktree + Claude 并行工作流：

1
2
3

终端1: cd worktree-a && claude "实现用户登录"     ← 同时进行
终端2: cd worktree-b && claude "修复支付 bug"    ← 同时进行
终端3: cd worktree-c && claude "写单元测试"      ← 同时进行

三个独立的 Claude 会话，互不干扰，同时工作。

实际操作

1
2
3
4
5
6
7
8
9
10
11
12

# 1. 创建 worktree（基于 main 分支）
git worktree add .claude/worktrees/feature-login origin/main

# 2. 进入并启动 Claude
cd .claude/worktrees/feature-login
claude

# 3. 查看所有 worktree
git worktree list

# 4. 删除 worktree（完成后清理）
git worktree remove .claude/worktrees/feature-login

设置快捷别名

在 ~/.zshrc 添加：

1
2
3

alias za='cd ~/projects/my-app/.claude/worktrees/a && claude'
alias zb='cd ~/projects/my-app/.claude/worktrees/b && claude'
alias zc='cd ~/projects/my-app/.claude/worktrees/c && claude'

2. Plan Mode 规划模式

核心理念

把精力花在计划上，让 Claude 一次性完成实现。

什么是 Plan Mode？

Claude Code 的一种工作模式。在这个模式下，Claude 只做规划，不写代码，直到你确认计划后才开始实现。

按 Shift+Tab 可以切换模式。

为什么要用 Plan Mode？

不用 Plan Mode：

1
2
3

你：重构 cli.tsx
Claude：好的，我来改...（改了一堆）...出问题了...再改...又出问题...
结果：来回折腾，浪费时间和 token

用 Plan Mode：

1
2
3
4
5
6
7

你：[Plan Mode] 重构 cli.tsx
Claude：这是我的计划：
  1. 先拆分 A 模块
  2. 再抽取 B 函数
  3. 最后更新 C 接口
你：确认 / 调整计划
Claude：按计划一次性完成

团队的实战技巧

技巧 1：双 Claude 审核

1
2
3
4
5

Claude A (Plan Mode)  →  写计划
                ↓
Claude B              →  以 Staff Engineer 身份审核计划
                ↓
Claude A              →  执行审核后的计划

技巧 2：出问题立刻回到 Plan Mode

1

执行中发现问题 → 不要硬推 → 立刻切回 Plan Mode → 重新规划

技巧 3：验证步骤也要规划

1
2
3
4
5

不只是规划"怎么构建"
还要规划"怎么验证"：
- 跑哪些测试
- 检查哪些边界情况
- 如何确认功能正常

3. CLAUDE.md 记忆文件

核心理念

CLAUDE.md 是你和 Claude 的共享知识库。投入时间维护它，Claude 的表现会越来越好。

什么是 CLAUDE.md？

CLAUDE.md 是 Claude Code 的「记忆文件」。每次启动时，Claude 会自动读取这个文件，了解项目背景和你的偏好。

1
2

~/.claude/CLAUDE.md          ← 全局配置，所有项目生效
项目目录/CLAUDE.md           ← 项目配置，仅当前项目生效

核心用法：让 Claude 自己写规则

关键技巧：每次纠正 Claude 后，说：

“更新 CLAUDE.md，确保你不再犯这个错误”

Claude 非常擅长为自己写规则。让它自己总结教训，比你手写更有效。

实战技巧

技巧 1：持续迭代

1

发现问题 → 纠正 Claude → 让它更新 CLAUDE.md → 错误率下降

技巧 2：项目笔记目录

1
2
3
4
5
6

项目/
├── CLAUDE.md              ← 指向 notes 目录
└── notes/
    ├── architecture.md    ← 架构说明
    ├── api-conventions.md ← API 规范
    └── pr-notes.md        ← 每次 PR 后更新

技巧 3：分层配置

1
2

~/.claude/CLAUDE.md     → 你的通用偏好（代码风格、语言等）
项目/CLAUDE.md          → 项目特定规则（框架、约定等）

CLAUDE.md 示例内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# 项目：电商后台

## 技术栈
- Next.js 14 + TypeScript
- Prisma + PostgreSQL
- TailwindCSS

## 代码规范
- 使用中文注释
- 组件用 PascalCase
- 工具函数用 camelCase
- 禁止使用 any 类型

## 常见错误（Claude 请注意）
- 不要用 moment.js，用 dayjs
- API 路由必须做权限校验
- 表单必须有 loading 状态

查看当前记忆

在 Claude Code 中输入 /memory 可以查看当前加载的记忆文件和 token 占用。

4. 自定义 Skills

核心理念

如果一件事你每天做超过一次，就把它变成 Skill。

什么是 Skills？

Skills 是 Claude Code 的自定义命令/工作流。你可以把常用操作封装成 /xxx 命令，一键执行。

1
2
3

/techdebt    → 自动查找重复代码
/sync        → 同步 Slack、GitHub 等信息
/review      → 按团队规范审查代码

Skills 存放位置

1
2

~/.claude/skills/           ← 全局 skills，所有项目可用
项目/.claude/skills/        ← 项目 skills，仅当前项目可用

创建一个 Skill

示例：/techdebt 技术债务检查

创建文件 ~/.claude/skills/techdebt.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

---
name: techdebt
description: 查找并清理技术债务
---

# 技术债务检查

请执行以下检查：

## 1. 重复代码
- 查找相似度高的代码块
- 建议抽取公共函数

## 2. 未使用代码
- 查找未使用的变量、函数、导入
- 列出可以安全删除的代码

## 3. TODO/FIXME
- 列出所有 TODO 和 FIXME 注释
- 按优先级排序

分享 Skills

把 .claude/skills/ 目录提交到 Git，团队共享：

1
2

git add .claude/skills/
git commit -m "添加团队 skills"

5. 自主修 Bug

核心理念

不要微观管理 Claude。给它目标，让它自己搞定。

方法 1：Slack MCP 集成

启用 Slack MCP 后，可以直接丢 Slack 链接给 Claude：

1
2

你：fix this https://ant.slack.com/archives/C07VBSH...
Claude：（自动读取 Slack 讨论）→ 理解问题 → 定位代码 → 修复

方法 2：直接指向 CI

1
2

你：Go fix the failing CI tests
Claude：（查看 CI 日志）→ 分析失败原因 → 修复代码 → 重新验证

方法 3：Docker 日志排查

1
2

你：分析这个 docker 日志，找出问题并修复
Claude：（读取日志）→ 定位错误 → 追踪到源码 → 修复

实战工作流对比

传统方式：

1
2
3
4
5
6
7

1. 看到 Slack 报 bug
2. 复制错误信息
3. 打开代码编辑器
4. 粘贴给 Claude
5. 解释上下文
6. 来回沟通
7. 最终修复

高效方式：

1
2
3

1. 看到 Slack 报 bug
2. 丢链接给 Claude，说 "fix"
3. 完成

关键心态

1
2

❌ "先看第 45 行，然后检查那个函数，可能是类型问题..."
✅ "fix this"

相信 Claude 的能力，给它空间自主工作。

6. 提升 Prompting 技巧

核心理念

你的 prompt 质量决定 Claude 的输出质量。

技巧 A：让 Claude 当你的审查者

1
2

你：Grill me on these changes and don't make a PR until I pass your test.
（严格审查这些改动，在我通过你的测试之前不要创建 PR）

1
2

你：Prove to me this works
（证明给我看这能正常工作）

技巧 B：不满意就重来

1
2

你：Knowing everything you know now, scrap this and implement the elegant solution
（基于你现在掌握的所有信息，推翻这个方案，实现一个优雅的解决方案）

为什么有效：

• Claude 第一次尝试时在「探索」问题
• 探索完成后，它对问题有了更深理解
• 第二次实现通常更简洁、更优雅

技巧 C：详细的 Spec 减少歧义

模糊：

1

你：添加一个登录功能

具体：

1
2
3
4
5
6

你：添加用户登录功能：
- 使用 email + 密码登录
- 密码至少 8 位，包含大小写和数字
- 登录失败显示具体错误
- 成功后跳转到 /dashboard
- 使用现有的 AuthContext

高效 Prompt 速查表

7. 终端与环境配置

核心理念

好的工具配置让你更高效。终端是你和 Claude 交互的界面，值得投入时间优化。

推荐终端：Ghostty

1

brew install --cask ghostty

状态栏配置：/statusline

使用 /statusline 命令自定义 Claude Code 状态栏：

• Context 使用量 - 知道还剩多少上下文空间
• 当前 Git 分支 - 确认在正确的分支工作

语音输入：说比打字快 3 倍

快捷键：连按两次 fn 键（macOS）

优势：

• 说话速度是打字的 3 倍
• 更自然地表达复杂需求
• prompt 会更详细、更清晰

完整环境配置清单

1
2
3
4
5
6
7
8
9
10
11
12

# 1. 安装 Ghostty
brew install --cask ghostty

# 2. 安装好看的字体
brew install --cask font-fira-code-nerd-font

# 3. 配置 Ghostty (~/.config/ghostty/config)
font-family = "FiraCode Nerd Font Mono"
font-size = 14

# 4. 开启语音输入
# 系统设置 → 键盘 → 听写 → 开启

8. 使用 Subagents

核心理念

Subagents 让你用多个 Claude 并行工作，同时保持主会话的上下文干净。

什么是 Subagents？

主 Claude 可以同时启动多个子代理，每个专注于不同任务：

1
2
3
4
5
6

主 Claude
    ├── Subagent 1: 探索入口文件
    ├── Subagent 2: 探索组件结构
    ├── Subagent 3: 探索工具实现
    ├── Subagent 4: 探索状态管理
    └── Subagent 5: 探索测试基础设施

技巧 A：加 “use subagents” 触发并行计算

1
2
3

你：explore the codebase, use subagents
你：分析这个项目的架构，use subagents
你：找出所有 API 端点，use subagents

技巧 B：卸载任务，保持主上下文干净

1
2
3
4
5
6
7
8
9

主 Claude                          Subagent
   │                                  │
   ├── "去分析 auth 模块" ──────────→ │
   │                                  ├── 读取文件
   │   （主上下文保持干净）              ├── 分析代码
   │                                  ├── 总结发现
   │ ←─────────── 返回分析结果 ────────┤
   │
   └── 基于结果制定重构方案

常用 Subagent 命令

快捷键

9. 数据分析

核心理念

让 Claude 帮你写 SQL、跑查询、分析数据。你可以 6 个月不写一行 SQL。

工作方式

Claude Code 可以直接使用数据库 CLI 工具：

1
2
3

你：查一下过去 7 天的日活用户数
Claude：（自动用 bq 命令查询 BigQuery）
       结果：DAU 平均 12,450，周环比 +8%

支持任何有 CLI、MCP 或 API 的数据库：

• BigQuery → bq CLI
• PostgreSQL → psql
• MySQL → mysql
• MongoDB → mongosh

实战示例

1
2
3

你：查一下昨天注册转化率
Claude：执行 bq query "SELECT ..."
       结果：注册转化率 3.2%，比前天提升 0.5%

1
2
3

你：检查昨天有没有异常数据
Claude：（自动跑多个查询，发现异常点）
       发现：支付成功率在 14:00-15:00 下降到 85%

好处

10. 用 Claude 学习

核心理念

Claude 不只是工具，还是你的学习伙伴。让它解释代码、画图、帮你理解新概念。

技巧 A：开启解释模式

在 /config 中设置输出风格为 Explanatory 或 Learning：

1
2
3
4
5

Claude：我要修改这个函数...

       **为什么这样改：**
       原来的实现有 N+1 查询问题，每次循环都会请求数据库。
       改用批量查询可以减少 99% 的数据库调用。

技巧 B：生成 HTML 演示文稿

1

你：生成一个 HTML 演示文稿，解释这个模块的工作原理

Claude 会创建带有清晰章节、代码高亮、流程图的专业演示。

技巧 C：用 ASCII 图理解架构

1

你：画一个 ASCII 图解释这个系统的数据流

输出：

1
2
3
4
5
6
7
8

┌─────────┐    ┌─────────┐    ┌─────────┐
│  Client │───→│   API   │───→│   DB    │
└─────────┘    └────┬────┘    └─────────┘
                    │
                    ▼
              ┌─────────┐
              │  Cache  │
              └─────────┘

技巧 D：间隔重复学习

1
2
3
4
5
6
7
8

你：/learn React 的 fiber 架构

Claude：请先解释你目前对 fiber 的理解。

你：fiber 是一种新的调度算法...

Claude：基本正确，但有几点需要补充...
       问题：fiber 如何处理优先级中断？

学习场景速查

总结

最重要的一点：Claude 能力很强，给它空间自主发挥。你的时间应该花在思考和决策上，把执行交给 Claude。

目标：搭建环境，调通 OpenAI 和 Claude API，理解核心参数含义。产出：一个封装好的 llm_client.py，支持调用两家 API。

核心原理：LLM 是个"概率预测机"

当你问 LLM："天空是？"的时候，它并不是直接想出"蓝色"这个词，而是在内部计算所有可能的下一个字的概率排行榜：

以下三个参数，就是在控制怎么从这个排行榜里选词。

1. Temperature（温度）：控制"胆量"

定义：控制模型在概率排行榜上选择时的随机性。

原理：

• 低温 (0 ~ 0.3)：模型变得保守，放大高概率词的优势，几乎只选 No.1。
• 高温 (0.7 ~ 1.0+)：模型变得狂野，把所有词的概率拉平（Flatten），低概率词也有机会被选中。

费曼比喻：

• temperature = 0.1 — 像一个严谨的会计。你问他在哪吃饭，他永远去评分最高的那一家。稳，但无聊。
• temperature = 0.9 — 像一个喝醉的诗人。你问他在哪吃饭，他可能会指着路边摊甚至垃圾桶说"试试这个"。容易出错，但偶尔有惊世骇俗的创意。

场景建议：

2. Top_p（核采样）：控制"候选池"

定义：不改变概率值，而是直接切断低概率的尾巴。也叫 Nucleus Sampling。

原理：模型从高到低累加概率，直到累加值达到 p（比如 0.9），只有在这个范围内的词才会被考虑，剩下的直接扔掉。

费曼比喻 — 招聘面试：

• top_p = 1.0 — 任何人都可以来面试，包括完全不靠谱的人。
• top_p = 0.1 — 只面试哈佛耶鲁毕业的（前 10% 的精英），绝对稳，但可能把"乔布斯"这种非传统天才拒之门外。

Temperature vs Top_p

行业惯例：通常只调其中一个，不要同时调两个，否则效果难以控制。

3. Max_tokens：控制"话唠程度"

定义：限制模型**生成（Output）**的最大 Token 数量。

注意点：

• 不包括输入：这是指模型输出的字数上限。
• 硬截断：如果模型话没说完就到了 max_tokens，它会戛然而止。
• 惨案现场：你让它返回 JSON，结果 max_tokens 太小，返回了 {"status": "succe...（后面没了），导致 json.loads() 直接报错。

Token 换算参考：

• 1 Token ≈ 0.75 个英文单词
• 1 Token ≈ 0.5 ~ 0.8 个汉字（取决于模型的 Tokenizer）

测试策略：API 调试阶段不要吝啬 max_tokens，设大一点（如 1024 或 4096），防止截断。

思路：

实现：

Clawdbot 是一个开源的个人 AI 助手，可以通过 Telegram、WhatsApp 等平台与 AI 模型交互，支持浏览器控制、文件操作等功能。

1. 购买 VPS

推荐 DMIT，选择 Los Angeles + Premium 网络，国内访问质量好。

注意：开着代理时 SSH 可能无法连接，需要把 VPS IP 加到代理的直连规则中。

2. 安装 Clawdbot

SSH 登录 VPS 后执行：

1
2
3
4
5

# 更新系统
apt update && apt upgrade -y

# 一键安装
curl -fsSL https://clawd.bot/install.sh | bash

按提示完成初始配置（选择 AI 模型、认证方式等）。

3. 访问 Web 管理页面

Clawdbot 默认只监听 localhost，需要通过 SSH 端口转发访问。

在本地 Mac 终端执行（不是服务器）：

1

ssh -N -L 18789:127.0.0.1:18789 -i ~/Documents/DMIT-zktmac1-id_rsa/id_rsa.pem root@你的服务器IP

然后在本地浏览器打开：http://localhost:18789/

4. 配置 Telegram

4.1 创建 Telegram Bot

1. 在 Telegram 搜索 @BotFather
2. 发送 /newbot，按提示设置名称和用户名
3. 复制获得的 Bot Token

4.2 配置 Clawdbot

在 VPS 上运行：

1

clawdbot configure --section channels

选择 Telegram，输入 Bot Token。

4.3 添加授权用户

在 Web 管理页面 → Channels → Telegram：

1. 点击 Allow From 旁边的 + Add
2. 添加你的 Telegram User ID

4.4 完成配对

在 Telegram 给 Bot 发送 /start，会收到配对码：

在 VPS 上执行配对命令：

1

clawdbot pairing approve telegram 你的配对码

5. 模型选择

推荐使用 OpenAI OAuth，可以利用 ChatGPT Plus 订阅额度。

在 Web 管理页面 → Config → Models 中配置：

6. 后台运行

1
2
3
4
5
6
7

# 安装 pm2
npm install -g pm2

# 启动并设置开机自启
pm2 start clawdbot
pm2 save
pm2 startup

常见问题

Q: SSH 连接被关闭？A: 检查代理设置，把 VPS IP 加入直连规则。

Q: Telegram 收不到回复？A: 确认已添加 User ID 到 Allow From，并完成 pairing approve。

• 一句话总结：
• 进度：

每日记录 (Daily Log)

2026-01-26 (周一)

• 随记：
  • 安装使用 clawdbot，整理一篇安装指南
  • blog 里的图片上传到 githup.io 不显示了，明天看看
• 反思：
  • 今天把 clawdbot 跑通踩了不少坑，但是有 AI辅助就轻松多了，搁以前肯定放弃了；所以说现在想学什么都很方便

2026-01-27 (周二)

• 随记：
  • blog 图片显示问题是路径错了，截屏粘贴显示完全路径就没问题
  • 钉钉接入 clawdbot，效果不搞好，代码是 cc 写的；飞书接入 clawdbot 没有调试成功
• 反思：
  • 一股脑接入钉钉、飞书，没有确定自己想要什么

2026-01-28 (周三)

• 随记：
  • 自己总想着造车，搞半天接入飞书失败；今天 githup 搜索到了有大佬已经写好了插件，让 cc 帮忙安装成功了。openAI 额度限制了，又开通了 MinMax
  • hexo-theme 主体在原有的基础上加上搜索和目录功能，但是目录感觉有点鸡肋
• 反思：
  • 明天想一下 hexo-theme 后续怎么搞
  • 还是看看测试全流程，整整 skill

2026-01-29 (周四)

• 随记：
  • 直接在本地 hexo-theme 里增加了搜索功能，后续看看能否导出成新的主题
  • 场景已跑通：Jenkins 构建结果通过 webhook 发送到飞书群，然后 clawdbot 对失败日志进行分析
• 反思：
  • 我看到有人通过 cc 配置硬件玩，感觉也可以玩玩

2026-01-30 (周五)

• 随记：
  • 整理了一份 llm-eval学习列表
  • 今天搭建环境，调通 OpenAI 和 Claude API，理解核心参数含义
• 反思：
  • clawdbot 暂时停了，等后续有新玩法

2026-01-31 (周六)

• 随记：
  • 给 blog 主题加上了菜单栏
  • 下午陪你鹏提车
  • 给老弟看看高校专项计划
  • 另开了个claude会员，两个轮番上阵
• 反思：
  • blog 主题暂时不加功能了，后面看到好的 UI，借鉴一下
  • 继续开整 llm-eval

2026-02-01 (周日)

• 随记：
  • 使用 brainstorm 创建一个迭代学习的 skill
  • 使用学习 skill 学习 zero-shot、few-shot 和 CoT prompt基础
  • 整理了一份 CC 之父的 CC 使用指南
  • 使用 glm4.7api 做了翻译插件，免费的 api，目前用起来还行
• 反思：
  • 学习时间无需太长，主要是效率；2-3 小时就能完成很多任务，需要合理安排计划（能否做一个计划 skill？）

本周复盘 (Weekly Review)

• Keep (继续保持)：*
• Improve (需要改进)：*
• Try (下周尝试)：*

• 一句话总结：
• 进度：

每日记录 (Daily Log)

2026-01-19 (周一)

• 随记：
  • 学习 skill 原理，reference+script+skill.md
  • 写个RAG-demo，openAI api 购买搁置
  • 把测试中的痛点拆解形成原子 skill
• 反思：
  • 还是更喜欢在 claude 里用 skill，token 不足，后续用 codex 写代码

2026-01-20 (周二)

• 随记：
  • 写一个 taxapp，复刻成功
• 反思：
  • 明天继续回归 skill

2026-01-21 (周三)

• 随记：
  • 生日🎂
• 反思：
  • 休息休息，明天再学

2026-01-22 (周四)

• 随记：
  • 将一些热门 githup 项目做成 skill
  • codex 解除了网络限制，之前都不知道，现在也可以快乐地制作 skill 了
  • 将 yt-dlp 做成快捷指令，更加方便了
• 反思：
  • 继续找一些软件测试相关的 githup 项目，做成 skill
  • 得好好学习一下快捷指令

2026-01-23 (周五)

• 随记：
  • Agent-browser skill 和 playwright-mcp
  • yt-dlp 快捷指令进度显示舍弃
  • python-testing-patterns skill
  • npx ctx7 来安装 skill
  • promptfoo 测试 prompt/api/agent
• 反思：
  • 还是得把测试全流程跑通
  • 搞清楚测试 prompt 的原理

2026-01-24 (周六)

• 随记：
  • 卸载 npm 方式安装的 cc，换成原生方式
  • 出去玩耍
• 反思：
  • 无～今天太疲惫 休息再说

2026-01-25 (周日)

• 随记：
  • 使用 brainstorm 规划 skill 功能，再用 skill-creator 构建 skill；创建了 api-test-generator skill，后续根据需求不断迭代
  • 学习 prompt、agent 测试流程
• 反思：

  • AI 测试的方向：

    1. 构建测试 Skill 库 - 把团队的测试经验沉淀为可复用的 Skill2. 人机协作 - Skill 处理重复性测试，人专注边界探索3. 持续演进 - 每次发现新问题就更新 Skill

  • 专用 Agent 架构 → 不需要了；通用 Agent + 专业 Skill → 正确路径

本周复盘 (Weekly Review)

• Keep (继续保持)：*
• Improve (需要改进)：*
• Try (下周尝试)：*

• 一句话总结：本周深度探索了 Claude Agent 开发与工作流（ApiFlowAgent 项目与 Brainstorm 插件结合），同时完成了网络分流与各种状态栏小工具（IP Monitor/养猫）的开发；但在高强度的 Token 消耗与复杂的全流程自动化探索中感到难以掌控，心态略有起伏，最终决定回归第一性原理重新审视接口自动化。
• 进度：
  • 研发项目： 完成 ApiFlowAgent 初始版（MVP），但决定重构思路；开发并上线 Mac 状态栏工具 ip-monitor 和 养猫游戏。
  • 基础设施： 解决 Claude Code 封号/分流问题（配置住宅静态 IP）；修复 Codex 代理冲突问题。
  • 生活/理财： 完成国区 PayPal 注册及汇丰 One 网银开通。
  • 技能/学习： 复习 JMeter；初步掌握 Claude Agent SDK；探索 PSB-guide 与 Brainstorm 结合的敏捷开发流程。

每日记录 (Daily Log)

2026-01-12 (周一)

• 随记：
  • 安装插件/superpowers:brainstorm，更新到 PSB-guide 流程
  • 使用/superpowers:brainstorm 写了一个 ip-monitor，ip 显示在状态菜单栏
  • 学习了 JMeter
  • 学习小火箭分流
• 反思：
  • JMeter 之前也学习过，现在也忘得差不多了。今天相当于复习了，但是没有整理操作文档。
  • claude code 封号搞怕了，想用静态 IP，但是太贵了；不然分流让刷推等主要流走其他节点—需要再考虑方案

2026-01-13 (周二)

• 随记：
  • 面试那边要做 agent，回来学习 agent，第一次申请 claude api
  • 用原始 api 写了个 agent demo，后面又用 sdk 写了个；后续再优化
• 反思：
  • /brainstorm 插件还行，但是只能把指定的 plan 拿来作为参考，要和 PSB-guide 流程结合起来，今天写 agent 没有 changelog ，后面就乱套了
  • 后续把/brainstorm 和 PSB-guide 结合成起来，整理输出一篇文档/

2026-01-14 (周三)

• 随记：
  • 养猫游戏 在状态菜单栏奔跑
  • 学习设置了分流，让 cluade 走住宅静态 ip
• 反思：
  • 今天就搞养猫游戏了，token 限额了，半天 bug 没解决

2026-01-15 (周四)

• 随记：

  • 终于是找到 codex 无法工作的问题，之前下载了个监控 token 的工具 Quotio，工具里开启了代理

    

  • 养猫游戏调试完成，后续再看看找个好图标。

  • 发现个 typora 主题，还可以https://theme.typora.io/theme/Phycat-Color/

• 反思：

  • 能够基于Claude Agent SDK构建通用型测试Agent，利用多元化Skill解决复杂测试场景，并将智能分析能力深度集成至CI/CD流程，实现智能化全流程闭环。

2026-01-16 (周五)

• 随记：
  • 开启项目 ApiFlowAgent，当前进度：完成了需求设计、AI 层、执行层、报告层和 CLI
  • 注册了国区 PayPal
  • 汇丰 one 到了，开通了网银，但是没找到怎么绑定 apple pay
• 反思：
  • 将brainstorm skill 和 PSB-guide 流程结合起来了，后续整一个文档，例如按照敏捷开发思路先跑来(MVP化)，PSB-guide 只用来 changelog/project-status/spec；取两者的精华组合起来
  • 之前 debug 养猫游戏消耗太多 token 了，导致今天 ApiFlowAgent 进度慢了，后续看看 cc 写完了代码，让 codex 来测试验证，减少点 token 消耗？

2026-01-17 (周六)

• 随记：
  • 完成了 ApiFlowAgent 初始版，后续得慢慢迭代
  • 在 codex 安装了 brainstorm skill，试试看
• 反思：
  • ApiFlowAgent 到后面感觉自己已经无法掌控了，还得多练
  • 目前无法掌控 agent接口自动化全流程，还是拆开来，基于第一性原理，接口自动化痛点是什么。但是有个要点，不能是单纯让AI 生成用例或者代码，需要流程化。agent 里最难的是自动生成用例，自动迭代，TDD 模式跑到没有错误为止。还是多次头脑风暴迭代后想一个好方法
  • 每天至少复现 x 上大佬分享skill 等内容

2026-01-18 (周日)

• 随记：
  • 退回原有模式，重新开展接口自动化
• 反思：
  • 最近一周心态有点不稳

本周复盘 (Weekly Review)

• Keep (继续保持)：
  • 极强的行动力与工具化思维： 遇到痛点（如 IP 监控、工作流卡顿）能立即动手写脚本或插件解决，不仅停留在想，而是落实到了代码上。
  • 持续的工作流优化意识： 不断尝试将 /brainstorm 插件与 PSB-guide 流程融合，试图建立更标准化的 MVP 开发模式（Changelog + Spec）。
  • 第一性原理思考： 在 ApiFlowAgent 项目失控时，能及时止损，反思“接口自动化的本质痛点”，而不是盲目堆砌代码。
• Improve (需要改进)：
  • Token 成本与收益控制： 在“养猫游戏” debug 上消耗过多 Token，导致主线项目进度受阻。需评估 Token 使用的优先级，非核心逻辑可尝试降级方案。
  • 文档沉淀习惯： 复习 JMeter 时未整理操作文档，导致知识复用率低；Agent 开发过程中的 Changelog 缺失导致了中期的混乱。
  • 心态管理： 本周后期因项目复杂度失控出现心态不稳，需接受“技术探索期的混沌状态”，避免急于求成。
• Try (下周尝试)：
  • 落地新工作流文档： 正式输出一篇关于 /superpowers:brainstorm 与 PSB-guide 结合的实操文档，固化“头脑风暴 -> MVP 规划 -> 状态追踪”的流程。
  • 策略调整： 尝试“Claude Code 写代码 + Codex 验证测试”的组合模式，降低 Token 消耗。
  • 回归 TDD 模式： 在接口自动化重构中，严格执行 TDD（测试驱动开发），先写断言/用例，再让 AI 生成代码，避免 AI 生成不可控的“幻觉代码”。
  • 微习惯养成： 每天复现一个 X (Twitter) 上大佬分享的 Skill 或 Prompt 技巧，保持技术敏感度。

为以下功能生成全面的测试用例

功能描述

“”"[在此粘贴需求文本、用户故事或功能说明]“”"

补充信息

接口定义（如有）

1

[粘贴函数签名、API 定义、请求/响应结构]

历史 bug 记录（如有）

• [简述历史上该模块或类似功能出过的典型问题]

上下游依赖（如有）

• [列出依赖的外部服务、数据库、第三方接口及其可能的异常情况]

分析步骤

请严格按以下步骤分析，不要跳步：

第一步：识别所有输入变量列出影响系统行为的所有因素：

• 显式参数：函数入参、请求字段、表单输入
• 隐式状态：用户登录态、数据库现有数据、配置开关
• 环境因素：网络状况、系统时间、并发请求

第二步：对每个变量做等价类划分用表格呈现：

第三步：生成用例矩阵使用 pairwise 组合策略，确保任意两个变量的取值组合至少被一个用例覆盖。

第四步：补充高风险场景基于补充信息中的历史 bug 和依赖关系，添加针对性用例。

输出格式

最终用例用 Markdown 表格输出，包含以下列：

优先级定义：

• P0：核心流程，阻塞发布
• P1：重要功能，需本迭代修复
• P2：边缘场景，可延后处理

为了保持项目整洁，建议按照以下目录归档文件：

1. 在项目根目录下新建一个文件夹，命名为 scripts。
2. 将通知用的 Python 脚本（如 ding_notify.py 或 feishu_notify.py）放入该文件夹。
3. 根目录保留 Jenkinsfile 和 requirements.txt（如果有）。

第二步：配置群机器人 (获取 Webhook)

选项 A：钉钉 (DingTalk)

1. 进入钉钉群，点击右上角 群设置 -> 智能群助手。
2. 点击 添加机器人 -> 选择 自定义 (通过Webhook接入)。
3. 安全设置 (必选)：推荐选择 “自定义关键词”，填入 “构建通知” (或你脚本中定义的其他词)。
4. 完成添加，复制并保存 Webhook 地址 (重点是 access_token 部分)。

选项 B：飞书 (Feishu/Lark)

1. 进入飞书群，点击右上角 设置 -> 群机器人。
2. 点击 添加机器人 -> 选择 自定义机器人。
3. 安全设置 (必选)：推荐选择 “关键词”，填入 “构建通知”。
4. 完成添加，复制并保存 Webhook 地址。

第三步：脚本功能准备 (Python 逻辑)

你需要准备的脚本应具备以下逻辑（无需贴代码，确认功能即可）：

1. 依赖库：使用 requests 库发送 HTTP 请求。
2. 获取 Token：优先从系统环境变量读取 Webhook 地址或 Token，也可以在脚本中设置默认值。
3. 状态判断：接收命令行传入的 SUCCESS 或 FAILURE 状态。
   • 成功：消息标头显示绿色，文案提示“构建成功”。
   • 失败：消息标头显示红色，文案提示“构建失败”。
4. 消息组装：包含项目名称、构建耗时、结束时间，以及跳转链接（Console 日志或测试报告）。
5. 发送请求：将组装好的 JSON 数据 POST 给机器人的 Webhook 地址。

第四步：Jenkins 流水线集成 (Jenkinsfile 逻辑)

在 Jenkinsfile 中配置以下流程：

1. Stage: 环境准备与测试
   • 检查环境：判断 venv 文件夹是否存在。
   • 创建环境：如果不存在，执行命令自动创建虚拟环境。
   • 激活环境：执行 source venv/bin/activate。
   • 安装依赖：安装 requests (发通知用) 和 selenium/pytest (测试用)。
   • 执行测试：运行自动化测试命令并生成报告数据。
2. Post: 构建后操作 (通知核心)
   • 配置 success (成功块) 和 failure (失败块)。
   • 再次激活环境：在发送通知前，必须再次执行 source venv/bin/activate。
   • 执行脚本：调用 Python 脚本，并传入 Jenkins 的环境变量（任务名、构建URL、耗时等）。

性能测试的核心目标是回答一个问题：系统能扛多大压力，瓶颈在哪里？

它不是简单地"压一下看看"，而是通过科学的方法，找到系统的能力边界和优化方向。

二、测试类型（按目的分）

怎么选择测试类型？

1
2
3
4
5

新系统上线前 → 基准测试 + 负载测试
大促活动前 → 压力测试 + 容量测试  
日常迭代   → 基准测试（回归）
核心系统   → 稳定性测试
秒杀场景   → 浪涌测试

三、测试场景（按业务分）

3.1 基础场景

3.2 进阶场景

3.3 混合场景设计示例

1
2
3
4
5
6
7

电商网站真实流量比例：
├── 首页浏览    40%
├── 商品搜索    25%
├── 商品详情    20%
├── 加入购物车   8%
├── 下单支付    5%
└── 用户登录    2%

混合场景的价值：单接口都没问题，混合起来可能有资源竞争。

四、性能指标体系

4.1 业务指标（用户视角）

响应时间的正确理解

1
2
3
4
5

平均 RT = 100ms  ← 看起来不错？
P90 RT = 150ms   ← 90% 的请求在 150ms 内
P99 RT = 800ms   ← 有 1% 的请求要 800ms！

结论：平均值会掩盖长尾问题，要看分位数

TPS vs QPS

1
2
3
4
5

TPS：一个事务可能包含多个请求（下单=查库存+扣款+创建订单）
QPS：纯粹的请求数量

接口压测一般说 QPS
业务压测一般说 TPS

4.2 系统资源指标（服务器视角）

CPU 指标详解

1
2
3
4
5
6
7

%user   - 用户态 CPU（应用代码）
%system - 内核态 CPU（系统调用）
%iowait - 等待 IO 的 CPU（磁盘慢）
%idle   - 空闲 CPU

iowait 高 → 瓶颈在磁盘，不是 CPU
user 高   → 瓶颈在应用代码

内存指标详解

1
2
3
4
5
6

used     - 已使用内存
free     - 完全空闲
buff/cache - 系统缓存（可回收）
available - 实际可用 = free + 可回收的 cache

看 available，不是 free

4.3 中间件指标（组件视角）

数据库（MySQL）

Redis

消息队列（Kafka/RabbitMQ）

4.4 JVM 指标（Java 应用）

五、常用工具

5.1 压测工具

5.2 监控工具

5.3 分析工具

六、性能测试流程

6.1 标准流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

1. 需求分析
   ├── 测试目标是什么？（TPS 达到 1000？RT < 200ms？）
   ├── 测试哪些场景？
   └── 测试环境要求？

2. 环境准备
   ├── 测试环境搭建（尽量接近生产）
   ├── 监控部署（Prometheus + Grafana）
   ├── 数据准备（测试数据量级）
   └── 压测工具准备

3. 脚本开发
   ├── 接口脚本编写
   ├── 参数化配置
   ├── 关联处理
   └── 脚本调试验证

4. 执行测试
   ├── 基准测试（摸底）
   ├── 负载测试（验证目标）
   ├── 压力测试（找极限）
   └── 稳定性测试（长时间）

5. 结果分析
   ├── 指标是否达标
   ├── 瓶颈在哪里
   └── 优化建议

6. 测试报告
   ├── 测试结论
   ├── 数据图表
   └── 问题和建议

6.2 瓶颈定位思路

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

RT 变长 / TPS 上不去
    │
    ├─ CPU 高？
    │   ├─ user 高 → 代码问题（算法、死循环）
    │   └─ iowait 高 → 磁盘问题
    │
    ├─ 内存高？
    │   ├─ 持续上涨 → 内存泄漏
    │   └─ GC 频繁 → 堆内存不够
    │
    ├─ CPU/内存都不高？
    │   ├─ 数据库慢查询？
    │   ├─ 连接池打满？
    │   ├─ 锁竞争？
    │   └─ 外部依赖慢？
    │
    └─ 网络？
        ├─ 带宽打满
        └─ 连接数耗尽

七、Q&A

7.1 基础问题

Q：你们性能测试关注哪些指标？

三层：业务指标（RT、TPS、错误率）、系统资源（CPU、内存、IO、网络）、中间件指标（数据库、缓存）。重点是把指标放在同一时间轴上看，找到瓶颈。

Q：RT 看平均值还是 P99？

P99 更重要。平均值会被大量正常请求拉低，掩盖长尾问题。比如平均 100ms，但 P99 是 2s，说明有 1% 用户体验很差。

Q：TPS 和 QPS 的区别？

TPS 是事务，一个事务可能包含多个请求；QPS 是纯请求数。接口压测一般说 QPS，业务压测说 TPS。

7.2 场景问题

Q：你们预估的 QPS 是怎么得出的？

两种方法：1）看生产监控历史峰值；2）业务推算：日活 × 人均请求数 ÷ 集中时段秒数，再乘 2~3 倍余量。

Q：混合场景怎么设计？

分析生产日志或埋点数据，统计各接口调用比例，按比例配置并发。比如浏览 60%、搜索 25%、下单 5%。

Q：秒杀场景怎么测？

用集合点让请求同时发出，关注：1）限流是否生效；2）库存一致性；3）系统是否雪崩。

Q：稳定性测试发现过什么问题？

内存泄漏（内存持续上涨不释放）、连接泄漏（连接数持续增长）、GC 时间变长、RT 逐渐上涨。

7.3 定位问题

Q：TPS 上不去，怎么排查？

先看资源：CPU、内存、IO 哪个高。如果都不高，看数据库慢查询、连接池、锁竞争、外部依赖。

Q：CPU 高怎么定位？

看是 user 高还是 iowait 高。user 高用火焰图找热点代码；iowait 高说明磁盘是瓶颈。

Q：内存泄漏怎么定位？

多次 dump 内存快照，用 MAT 对比，看哪些对象持续增长。

八、实战检查清单

测试前

• 明确测试目标（TPS、RT、错误率要求）
• 测试环境配置记录（CPU、内存、带宽）
• 监控部署完成（能看到实时数据）
• 测试数据准备（数量级合理）
• 脚本调试通过（单次请求正常）

测试中

• 逐步加压，不要一上来就拉满
• 实时观察监控，发现异常及时记录
• 每轮测试记录：并发数、TPS、RT、错误率、资源使用
• 出现拐点时停下来分析

测试后

• 整理各轮数据，画趋势图
• 定位瓶颈点
• 输出测试报告
• 提出优化建议

九、附录：常用命令速查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# CPU
top                    # 整体情况
vmstat 1               # 每秒刷新
mpstat -P ALL 1        # 每个核心

# 内存
free -h                # 内存概况
top -o %MEM            # 按内存排序

# 磁盘
iostat -x 1            # IO 详情
iotop                  # IO 排行

# 网络
iftop                  # 带宽监控
netstat -ant | wc -l   # 连接数
ss -s                  # 连接统计

# 进程
ps aux --sort=-%cpu    # CPU 排行
ps aux --sort=-%mem    # 内存排行

# Java
jstat -gc <pid> 1000   # GC 监控
jstack <pid>           # 线程 dump
jmap -heap <pid>       # 堆内存概况

总结

性能测试的本质是：给系统施加压力，观察表现，找到瓶颈，指导优化。

记住这个思考框架：

1

目标 → 场景 → 指标 → 执行 → 分析 → 优化

不是为了压测而压测，而是为了回答业务问题：系统能不能扛住？扛不住的话问题在哪？

🌟现在安装了/superpowers:brainstorm 插件，可以直接在 Claude Code 里规划

1.1 打开任意笔记工具，回答这两个问题

1
2
3
4
5
6
7

问题 1：我到底想做什么？
- 这是原型验证还是要上线？
- 写一句话描述项目核心价值

问题 2：MVP 包含哪些功能？
- 列出 3-5 个核心功能
- 其他功能放到 v1.1、v1.2

1.2 让 AI 帮你理清思路

打开 Claude，输入：

1
2
3

我想做一个 [你的项目描述]。

请问我 3 个最重要的问题，帮我理清没想明白的地方。

认真回答这些问题，把答案记下来。

1.3 生成项目规格文档

继续让 Claude 帮你整理：

1
2
3
4
5
6
7
8
9
10
11
12

基于我们的讨论，帮我生成一份项目规格文档，包含：

1. 产品需求
   - 解决什么问题
   - 目标用户
   - 核心功能列表（MVP）
   - 用户交互流程

2. 技术需求
   - 技术栈选择（请用：[你偏好的技术栈，比如 Python + FastAPI + SQLite]）
   - 项目结构建议
   - 第三方服务/API

把输出保存为 docs/spec.md。

第二步：配置阶段（10-15 分钟）

2.1 创建 GitHub 仓库

1
2
3
4
5
6
7

# 创建并克隆仓库
gh repo create my-project --private --clone
cd my-project

# 或者本地初始化
mkdir my-project && cd my-project
git init

2.2 创建目录结构

1
2
3

mkdir docs
mkdir .claude
mkdir .claude/commands

2.3 创建环境变量文件

1
2
3

touch .env
touch .env.example
echo ".env" >> .gitignore

在 .env 中提前填好所有 API key：

1
2
3

OPENAI_API_KEY=xxx
DATABASE_URL=xxx
# 其他需要的 key...

2.4 创建 CLAUDE.md（核心文件）

1

touch CLAUDE.md

填入以下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# 项目名称

一句话描述：[从 spec.md 复制]

## 项目目标

[MVP 要实现的 3-5 个核心功能]

## 技术栈

- 语言：Python 3.11
- 框架：FastAPI
- 数据库：SQLite
- [其他...]

## 项目结构

src/
  main.py
  models/
  routes/
docs/
tests/

## 开发规范

- 代码风格：[你的偏好]
- 提交规范：feat/fix/docs 前缀
- 测试要求：[有/无]

## 约束条件

- 不要使用 [某个你不想用的库]
- 不要 [其他限制]

## 当前状态

见 [project-status.md](./docs/project-status.md)

## 相关文档

- [项目规格](./docs/spec.md)
- [架构设计](./docs/architecture.md)
- [变更日志](./docs/changelog.md)

2.5 创建自动化文档

1
2
3

touch docs/architecture.md # 项目写完了再生成架构文档
touch docs/changelog.md
touch docs/project-status.md

docs/project-status.md 模板：

1
2
3
4
5
6
7
8
9
10
11
12
13

# 项目状态

## 已完成
- [ ] 项目初始化

## 进行中
- [ ] [当前任务]

## 待开始
- [ ] [下一个任务]

## 下次继续
从这里开始：[具体描述]

2.6 创建自定义命令（可选但推荐）

1

touch .claude/commands/update-docs.md

内容：

1
2
3
4
5

请更新以下文档以反映最新的代码变更：

1. docs/architecture.md - 更新系统架构
2. docs/changelog.md - 添加本次变更记录
3. docs/project-status.md - 更新完成状态和下次继续点

2.7 首次提交

1
2
3

git add .
git commit -m "init: 项目初始化"
git push -u origin main

第三步：构建阶段

3.1 启动 Claude Code

1

claude

3.2 让 Claude 先熟悉项目

1

请阅读 CLAUDE.md 和 docs/spec.md，确认你理解了项目目标和技术栈。

3.3 进入计划模式（重要！）

1
2
3

我要开始实现 [第一个功能]。

请先进入 plan 模式，列出实现步骤，不要直接写代码。

等 Claude 列出计划后，确认没问题再说：

1

计划看起来没问题，请开始实现。

3.4 每完成一个功能后

1

/update-docs

或者手动说：

1

请更新 changelog.md 和 project-status.md，记录刚才的变更。

3.5 遇到 Claude 犯错时

立即在 CLAUDE.md 的约束条件里添加：

1
2
3
4

## 约束条件

- 不要使用 print 调试，用 logging
- 不要把密钥硬编码  # ← 新增的规则

完整流程图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

┌─────────────────────────────────────────────────────────┐
│  第一步：规划（15-30分钟）                                 │
│  ├─ 回答两个核心问题                                      │
│  ├─ 让 AI 问你问题                                       │
│  └─ 输出 spec.md                                        │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  第二步：配置（10-15分钟）                                 │
│  ├─ 创建 GitHub 仓库                │
│  ├─ 配置 .env                                            │
│  ├─ 创建 CLAUDE.md                                       │
│  ├─ 创建 docs/ 文档                                      │
│  └─ 首次提交                                             │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  第三步：构建（循环）                                      │
│  ├─ 让 Claude 熟悉项目                                   │
│  ├─ plan 模式列计划                                      │
│  ├─ 确认后实现                                           │
│  ├─ 更新文档                                             │
│  └─ 犯错时添加规则                                        │
└─────────────────────────────────────────────────────────┘

核心机制：前缀键 (Prefix Key)

所有快捷键操作前，必须先按下“扳机”：Ctrl + b (松开后再按后续按键)。

1. 会话管理 (Session Management)

在普通终端 (Terminal) 中执行：

在 Tmux 内部操作：

2. 屏幕切分 (Pane Management)

注意：操作前需先按前缀键 Ctrl + b

3.设置鼠标移动!!!

tmux set -g mouse on 回车后，你就可以直接用鼠标滚轮滚动查看历史了，点击面板也会自动切换焦点

• 一句话总结：本周是工具化思维与AI工作流标准化并行的一周。通过开发多个实用小工具（Mock服务、JSON转换、X插件）验证了“Claude Code系统化流程”的有效性，技术上覆盖了从开发到运维（Jenkins/Prometheus）的闭环；但在情绪管理和AI账号稳定性上遭遇挑战，需尽快建立抗风险机制。
• 进度：
  • 开发产出： 完成 mock-service (FastAPI)、Web端JSON转断言工具、X(Twitter) 备注分组插件。
  • 运维/测试： 跑通 Prometheus+Grafana 监控、Jenkins+钉钉通知流，整理性能测试文档。
  • 方法论沉淀： 整理并实践了“Claude Code 系统化使用流程”及“PSB-guide”，验证了结构化开发对质量的提升
  • 个人成长： 完成简历大改版，接触 git worktree 与 tmux。

📝 每日记录 (Daily Log)

2026-01-05 (周一)

• 随记：
  • 完成 mock-service：一个基于 FastAPI 的轻量级 Mock 服务，支持通过管理页面动态配置接口规则，用于模拟第三方系统接口进行自动化测试
  • 学习使用 tmux 分屏等
  • 要大改简历，不能按照原来老旧的思路
• 反思：
  • 做 agent：第一个版本用 claude agent sdk 搭，先跑起来再说
  • Claude.md 到底如何使用
  • cc写，codex测试：节约token 先写框架，再小模块填充

2026-01-06 (周二)

• 随记：
  • 修改了简历
  • 测试下众安
  • Claude code 只会简单对话给需求，深入学习整理教程也有搞头
  • 自媒体要做：公众号、微博、小红书、推特、抖音
• 反思：
  • 刷手机真是浪费时间

2026-01-07 (周三)

• 随记：
  • 做了一个 web 端 json 一键转 JS/python 断言
  • 整理了一个系统性使用 Claude Code的流程
  • git worktree
• 反思：
  • 想跑通一下 cc系统性写项目，暂时没想到写什么；还是喜欢写些小工具

2026-01-08 (周四)

• 随记：
  • 写了一个 X 的插件：主要是备注、分组
  • 给 claude code 加了一个/command，指定中文写作风格
• 反思：
  • 写 X 插件时按照系统性使用 Claude Code的流程文档操作了前面的准备阶段，项目太小后面没有按照文档。但是，后面测试改动了几个版本，体会到按照流程走的好处。明天重新按照流程走一遍
  • 想整一个工具箱Zkit-web：将工具都放上去

2026-01-09(周五)

• 随记：
  • Prometheus + Grafana 部署使用
  • 性能测试文档整理
• 反思：一点事就影响了情绪，计划搁置

2026-01-10(周六)

• 随记：
  • CI/CD 自动化通知配置指南 (钉钉/飞书)
  • 性能测试文档整理
  • .gitignore 模板
  • 测试用例生成prompt
• 反思：
  • md表格无法在网页里显示，1 个小时未解决！

2026-01-11(周日)

• 随记：
  • 按照 PSB-guide 流程跑通了 UItest-Jenkins-ding，
• 反思：
  • tmd claude 又把我号封了！严重影响心情
  • 第一次按照较为全面的流程 vibe 一个项目，感觉确实不一样

💡 本周复盘 (Weekly Review)

• Keep (继续保持)：

  • 以造代学：高频产出实战工具（Mock/JSON/X插件），验证了“需求驱动”的高效性。
  • 流程落地：从随意开发转向遵循 “Claude Code SOP” 和 “PSB-guide”，工程质量显著提升。

• Improve (需要改进)：

  • 情绪风控：减少因工具故障（封号）或琐事（MD表格）导致的心态崩坏，建立备选方案意识。
  • 时间熔断：遇到非核心样式问题（如1小时修表格），应强制止损，拒绝低效内耗。

• Try (下周尝试)：

  • Zkit-web 集成：将本周的零散小工具整合为 Web 平台，借此完整跑通系统化开发流程。

    AI 容灾方案：配置Codex 或其他模型作为 Claude 的 Plan B，确保生产力不中断。

• 一句话总结：本周主要完成了 Postman Mock 的学习与实操，并 vibe 出一个 mock-chrome-plugin，最大的挑战是从零上手 Mock 技术并快速产出可用工具。
• 进度：
  • Postman Mock 学习 ✅ Done
  • mock-chrome-plugin 🚀 MVP 完成
  • HK 开卡完成

📝 每日记录 (Daily Log)

2026-01-02 (周五)

• 随记：
  • 学习 postman mock
  • vibe了一个mock-chrome-plugin
• 反思：
  • Gemini 的学习辅导功能特别实用，讲解很详细，对刚开始学的人特别友好。

2026-01-03 (周六)

• 随记：
  • 复习 postman mock，又实操了一遍
  • 准备 HK 开卡
  • 咸鱼找人gpt 军人认证
• 反思：
  • X的创作者收益增加，后续可以在X上输出，刚好去办张卡

2026-01-04 (周日)

• 随记：
  • HK 一日游

💡 本周复盘 (Weekly Review)

• Keep (继续保持)：
  • 学完即练的节奏，周五学 + 周六复习实操，知识留存率高
  • 善用 AI 工具辅助学习（Gemini 讲解）
  • 保持对新工具/新机会的敏感度（X 创作者收益）
• Improve (需要改进)：
  • 每日记录可以更结构化，比如区分「学习」「项目」「杂事」
  • 周末安排较松散，可提前规划好核心任务
• Try (下周尝试)：
  • 在 X 上发第一条技术/工具类内容，测试输出→反馈循环
  • 把 mock-chrome-plugin 完善一下，考虑是否值得公开分享
  • HK 卡到手后，跑通一次完整的收款流程

根本问题： 如何确保我的测试环境是干净、正确、且可重复的？ 核心原则： 任何测试的有效性都建立在一个稳定且配置正确的环境之上。以下命令是构建和维护这种环境的基石。

A. 文件系统：管理测试资产

这是我们的数字化工作台，存放着代码、数据、日志和脚本。

• 导航与检视 (我们在哪？这里有什么？)
  • pwd (Print Working Directory): 回答“我现在在哪里？”这个问题，获取当前位置的绝对路径。
  • ls -lah (List): 回答“这里有什么？”。 -l (长格式) 看权限和所有者，-a (所有) 看隐藏文件，-h (人类可读) 看文件大小。这是检查环境状态的第一步。
  • cd (Change Directory): 切换工作空间，去往你需要操作的地方。
• 创建与组织 (搭建工作区)
  • mkdir -p <路径>: 创建目录。-p 选项能一次性创建多层嵌套的目录，非常适合组织测试结果，如 mkdir -p test_results/run_20250927。
  • touch <文件名>: 创建一个空文件，常用于脚本中创建锁文件或日志占位符。
• 操作与管理 (移动和清理资产)
  • cp -r <源> <目标>: 复制文件或目录。-r 用于递归复制整个目录，是准备测试数据的常用操作。
  • mv <源> <目标>: 移动或重命名文件/目录。
  • rm -rf <文件/目录>: 删除文件或目录。-r 递归删除，-f 强制执行。这是一个高风险操作，使用前请三思。
• 精确定位 (大海捞针)
  • find <路径> -name "<模式>": 在指定路径下根据名称、类型、修改时间等多种条件查找文件。
    • 测试场景: find /var/log -name "*.log" -mtime -1 -> 查找过去24小时内被修改过的所有日志文件，是排查近期问题的利器。

B. 权限管理：控制访问权限

根本问题： 谁能对这个文件做什么？（读、写、执行） 这是导致自动化脚本失败最常见也最容易被忽略的原因之一。

• chmod (Change Mode): 修改权限。
  • 场景: 自动化脚本无法执行？ -> chmod +x my_script.sh (为脚本添加执行权限)。
  • 两种模式:
    • 符号模式 (易读): u+x (为所有者增加执行权限), g-w (为用户组移除写权限)。
    • 八进制模式 (高效): 755, 644。755 通常用于目录和脚本，644 用于普通文件。
• chown (Change Owner): 更改文件/目录的所有者和所属组。
  • 场景: 被测应用无法写入日志？ -> 检查日志目录的所有者是否为运行该应用的用户，如果不是，使用 chown -R app_user:app_group /var/log/app 修正。

第二部分：核心技能 - 从数据中提取洞见

根本问题： 系统出错了，日志里记录了什么？海量日志中，哪一句是关键信息？ 核心原则： 日志是系统行为的唯一事实来源。我们的任务不是“读”日志，而是“审问”日志，从中压榨出有价值的信息。

A. 查看日志：初步侦查

• cat: 一次性显示整个文件（仅适用于小文件）。
• less: 查看大文件的正确方式。 交互式查看，支持搜索 (/) 和翻页，不消耗大量内存。
• head/tail: 查看文件的开头/结尾。
• tail -f <文件名>: 实时问题分析的王者。 持续监控文件末尾的新增内容，可以将测试操作与系统日志输出实时关联。

B. 过滤与分析：沙里淘金

• grep (Global Regular Expression Print): 文本搜索的瑞士军刀。
  • 核心功能: 筛选包含特定模式的行。grep "ERROR" app.log。
  • 关键选项:
    • -i: 忽略大小写。
    • -C <数字> (Context): 显示匹配行的上下文，理解错误背景至关重要。
    • -v (Invert): 反向匹配，排除无关信息。
    • -r: 递归搜索目录。
• sed (Stream Editor): 行编辑器。 擅长对文本行进行批量替换、删除、插入。
  • 场景: sed 's/DEBUG/INFO/g' log.txt -> 将日志中的 “DEBUG” 全部替换为 “INFO”，便于分析。
• awk (Aho, Weinberger, and Kernaghan): 列处理器。 擅长将一行文本分割成多个字段（列）并进行处理。
  • 核心能力: 将非结构化或半结构化的日志数据化。
  • 场景: 从访问日志中计算平均响应时间。 grep "200 OK" access.log | awk '{sum+=$10} END {print sum/NR}' -> 筛选成功请求，并对第10列（响应大小）求和，最后打印平均值。

第三部分：控制被测应用 - 管理进程生命周期

根本问题： 我的应用启动了吗？它运行得怎么样？如何安全地启停它？ 核心原则： 建立一个“验证 -> 观察 -> 控制”的反馈回路来主动管理被测应用。

• ps aux | grep <应用名>: 验证 (Verify) 进程是否存在、状态如何。这是测试开始前的第一步检查。
• top: 观察 (Observe) 系统和进程的实时资源消耗（CPU、内存）。这是诊断性能问题的首选工具。
• kill: 控制 (Control) 进程的生命。
  • kill <PID>: 发送 SIGTERM (15) 信号，请求进程“优雅地”退出。
  • kill -9 <PID>: 发送 SIGKILL (9) 信号，强制终止进程。这是最后的手段。

第四部分：高级诊断 - 深入性能与网络

根本问题： 系统为什么慢？是 CPU、内存、磁盘还是网络的问题？API 调用为何失败？

A. 系统性能剖析

• 宏观监控 (发现症状):
  • free -h: 查看内存和交换空间使用情况。
  • vmstat: 全面了解 CPU、内存、I/O 的动态。
  • iostat: 深入分析磁盘 I/O 性能。
• 微观剖析 (定位病因):
  • perf: 专家的终极武器，能直接定位到代码函数级别的性能瓶颈。
    • perf stat <命令>: 快速获取一个操作的宏观性能指标。
    • perf top: 实时查看消耗 CPU 最多的函数。
    • perf record & perf report: 记录详细数据并离线分析，找出导致性能问题的具体调用链。

B. 网络诊断与测试

• 基础连通性:
  • ping: 检查两台主机之间网络是否通畅。
  • traceroute: 显示数据包经过的路由路径，定位网络延迟点。
  • nslookup: 验证域名解析是否正确。
• 端口与连接:
  • netstat -lntp: 查看哪些进程在监听哪些 TCP 端口。验证服务是否成功启动并监听在正确端口上。
• API 交互:
  • curl: API 测试的命令行王者。 模拟各类 HTTP 请求。
    • -X <方法>: 指定请求方法 (GET, POST, etc.)。
    • -H "<头信息>": 添加请求头 (e.g., “Content-Type: application/json”)。
    • -d '<数据>': 发送请求体。
    • -v: 显示详细的通信过程，用于调试。
    • -o <文件>: 将响应输出到文件。
• 安全文件传输:
  • scp -r <源> <目标>: 在本地和远程服务器之间安全地复制文件/目录。用于部署构建包、上传测试数据、下载日志报告。