如何量化我的 AI Coding 效率

在用 AI 辅助开发的这一年多里，我一直在回避一个问题："用了 AI 之后，你到底快了多少？"

不是因为不想回答，而是因为答不上来。每次只能说 "感觉快了很多"、"现在写样板代码基本不用动脑" —— 这些描述真实但无法量化。当老板问"AI 的 ROI 是多少"的时候，我能给的只有体感。

最近整理了 AI Coding 体系架构图，其中评价层让我意识到：评价不是给老板看的报表，而是让自己知道哪些该投入、哪些该砍掉。这篇文章记录从"靠感觉"到"建指标"的做法，重点是采集方式，不是成绩单。

文中的百分比、耗时和覆盖率都是填表示例，用来说明指标怎么采集、怎么读。它们不是经审计的个人成绩，也不对应任何公司的生产数据。

一、先搞清楚要衡量什么

1.1 一张纸写下来，我最关心的问题

在搭建任何指标之前，我先问自己：如果只能知道三件事，我最想知道什么？

真实答案是：

我想知道	为什么重要	现在我怎么判断
AI 写的代码有多少最终合入了 master？	衡量 AI 产出的有效转化率	靠记忆，不准
用 AI 之后，一个需求从开到合的时间变了多少？	这是最直接的生产力信号	完全没衡量过
哪些场景用 AI 最划算，哪些场景不如手写？	指导后续投入方向	靠直觉，不系统

这三个问题比任何学术框架都重要。模型好不好、token 消耗多少 —— 那是治理层的事。对我个人而言，有效产出才是唯一标准。

1.2 什么不要衡量

先把不该量的说清楚，比先说该量什么更重要。

不要衡量	原因
AI 代码行数 / 天	行数是最容易作弊的指标，AI 尤其擅长生成冗长代码
AI 对话次数 / 天	多轮无效对话只能说明 prompt 写得烂，不是效率高
单位 token 产出	不同模型 token 价格差异太大，这个指标没有可比性
"AI 替代率"（AI 代码行数 / 总行数）	鼓励用 AI 写一切，反而降低整体效率。有些东西手写更快
排行榜式对比	每个人的工作内容不同，跨人比较 AI 效率毫无意义

Kent Beck 和 Gergely Orosz 在《Measuring developer productivity? A response to McKinsey》里说过一个经典案例：Facebook 引入了开发者满意度调查，本来效果不错，管理层把它量化成分数后，又把这个分数塞进绩效考核，最后演变成"你给我打五分，我保你拿高绩效"的交易。指标一旦跟奖惩挂钩，就不再反映真实情况。

所以我给自己定的底线：这些指标只用于自我优化，不用于汇报，不用于比较。

二、我的实操框架：三个指标，五层采集

我把想要的东西压缩到三个核心指标，不贪多。每个指标都有具体的采集方式，不需要额外工具，用我现有的命令行就能跑。

2.1 核心指标一：AI 有效采纳率

定义：AI 生成的代码中，最终进入 master 的比例。

为什么这个重要：AI 生成 1000 行，最后合入 50 行，那实际有效采纳率只有 5%。高 AI 用量 + 低采纳率 = 大量时间花在改 AI 的代码上，还不如自己写。

我怎么采集：

bash

# 方法一：利用 git 提交信息中的 AI 标记
# 我在 AI 生成的提交中统一加了 [ai] 前缀
git log --oneline --since="2026-07-01" | grep "\[ai\]" | wc -l    # AI 参与的提交数
git log --oneline --since="2026-07-01" | wc -l                      # 总提交数

# 方法二：更细粒度 —— 统计合入的 AI 文件数
# 我用 spec.md 标记了哪些文件是 AI 首发（文件头部有 // @ai-generated）
git log --diff-filter=A --name-only --since="2026-07-01" \
  | grep -E '\.(ts|vue|tsx)$' \
  | xargs grep -l "@ai-generated" 2>/dev/null | wc -l

示例读数（近两周。演示这张表怎么填，不是经审计的个人成绩）：

维度	数值
AI 参与提交占比	约 60%（大部分工具性代码都是 AI 写的）
AI 代码最终合入率	估计 70% 左右（30% 左右被重写或废弃）
一次通过的 AI 提交占比	约 40%（大部分 AI 代码需要至少一轮修改）

拿到数据后的第一个发现：AI 参与提交占 60%，但一次通过率只有 40%。说明我花了不少时间在修正 AI 的输出上。如果能提升一次通过率到 60%，我的整体效率还能再提一截。

2.2 核心指标二：需求交付加速度

定义：用 AI 之后，同类需求从启动到合入的时间缩短了多少。

为什么这个重要：这是最接近"生产力"的指标。但前提是要有可比基线——你不能拿一个复杂需求跟一个简单需求比。

我怎么采集：

bash

# 用 git 提取需求的交付周期
# 假设你的分支命名规范是 feat/<feature-name> 或 task/<task-id>
# 找到分支的第一个和最后一个 commit 时间

git log --all --format="%H %ai %s" --since="2026-06-01" \
  --grep="feat\|fix\|task" \
  | awk '{
      # 按需求分组，计算每个需求的 first commit 到 merge commit 的时间差
      # 这部分逻辑需要按你的分支命名习惯调整
  }'

真实情况是，这个指标很难自动采集，因为需求粒度不统一。我的替代方案很简单：

手动记录，模板化。在每个需求开始时，在 Obsidian 的每日笔记里记一行：

text

> [AI需求] 价格策略页面重构
> 启动: 2026-07-23 09:00
> 类型: 页面重构（中等复杂度）
> 预计人工耗时: 3天 → 实际: ?
> AI 参与程度: 高（80% 代码由 AI 生成）

需求结束时补一行：

text

> 合入: 2026-07-24 16:00  实际耗时: 1.5天  节省: 50%

手动记录的好处是它强迫我在开始时做判断。一旦写下"预计人工耗时 3 天"，我就自然会在过程中衡量 AI 的实际价值。一个月积累 10 条记录，就可以看出趋势了。

示例记录（演示不同任务类型怎么对比，不是已验收的交付成绩）：

需求	类型	预计人工	实际耗时	AI 参与度	节省
定价模板表单组件	新增组件（业务逻辑重）	2 天	1.5 天	60%	25%
批量操作工具函数	工具函数（模式固定）	1 天	2 小时	90%	75%
状态机重构	重构（逻辑密集）	1.5 天	1 天	40%	33%
WebGL 着色器优化	算法类（需要专业知识）	2 天	0.5 天	70%（Claude 擅长）	75%

拿到数据后的发现：AI 的效率提升跟任务类型强相关。模式固定的工具代码（90% AI 生成，节省 75%）和需要专业知识的算法类（Claude 懂 WebGL，节省 75%）是收益最大的场景。业务逻辑重的表单（60% AI 但只省 25%）说明业务上下文传递还不够好。

这个发现直接指导了我后续的投入：重点优化 AI 理解业务上下文的能力（spec.md 的质量），而不是纠结模型选择。

2.3 核心指标三：场景性价比矩阵

定义：不同开发场景下，AI 的投入产出比。

为什么这个重要：用 AI 不是免费的——有 token 成本，更重要的是有心智成本（写 prompt、review AI 代码、修正错误）。有些场景 AI 省的时间还不够覆盖这些成本。

我怎么评估：不追求精确数字，用 定性 + 方向性 的分级就够了。

用一个简单的评估表格，每周回顾时填一次：

场景	用 AI 频率	单次耗时	单次省时	质量评分(1-5)	ROI 感觉	策略
新建组件（标准 CRUD）	高	写 prompt 5min + review 3min	省 1-2h 手写	4	✅ 高	持续使用
重构现有代码	中	写 prompt 10min + review 15min	省 30min 梳理	3	⚠️ 中	选择性使用
修复 Bug	中	描述问题 5min + review 10min	省 20min 排查	2	⚠️ 中	只用于已知根因的 bug
写单元测试	高	2min 给 AI 函数 + 1min review	省 30min 写测试	5	✅ 高	大力使用
写文档 / README	中	3min 描述 + 2min 润色	省 20min	4	✅ 高	持续使用
CSS / 样式调整	低	描述不清楚，反复改	省很少，可能更慢	2	❌ 低	不如手写或直接用组件库
架构设计讨论	低	10min 讨论	省 1h 冥思苦想	4	⚠️ 中	作为讨论伙伴，不直接采纳
解析报错 / 查文档	高	1min 粘贴 + 10s 阅读	省 10-30min 搜索	5	✅ 高	首选方案

拿到数据后的发现：写得最快的不一定最值。单元测试和报错解析省的时间绝对值不大，但省的是"打断心流"的切换成本。心神被打断后重新进入状态需要 15-20 分钟，AI 10 秒解决报错意味着我可以一直留在心流里。这个价值远比表面时间差更高。

三、落地：怎么让追踪不成为负担

搭指标最大的陷阱是：搭建花了一周，追踪只坚持了一周。 我经历了三轮迭代才找到可持续的方式。

3.1 第一轮（失败）：想一次性建个大盘

第一轮我试图搞个数据面板，自动采集所有指标——git 统计、AI 工具日志、token 消耗。花了两天搭了个雏形，然后就不想维护了。

失败原因：

采集链路太复杂，各种工具的数据格式不统一
看数据需要上下文——一个"AI 采纳率 60%"的数字，不结合具体项目上下文完全没意义
维护成本远超收益

3.2 第二轮（部分成功）：只追踪三个手写指标

第二轮我把指标压到了三个，用 Obsidian 每日笔记手动记录。能坚持。

每天的记录是这样的（写在 Z-day/YYYY-MM-DD.md 里）：

markdown

## AI Metrics

| 指标 | 今日 |
|------|------|
| AI 提交数 / 总提交数 | 3/5 |
| 省时感觉 | ⭐⭐⭐ （做了个批导，AI 基本全写了） |
| 最佳场景 | WebGL 着色器 —— Claude 直接给了可用的 GLSL |
| 最差场景 | 动态表单校验 —— context 太长 AI 乱了 |

### Prompt 墓地
今天浪费的对话：
- "把这个校验逻辑改成支持动态规则" → 改了 4 轮，最后手写了
  教训：动态规则这类需要理解整个校验体系的，单次对话不行，需要先喂 context

这个方案我坚持下来了。关键在于：它不只是一个指标记录，它还顺带做了"经验沉淀"。Prompt 墓地这个部分尤其有价值——记录下失败的对话比记录成功的更有用。

3.3 第三轮（在弄）：把 git 统计自动化，但只做最简单的

现在我在 hammerspoon（macOS 的自动化工具）里加了个定时脚本，每天凌晨跑：

bash

#!/bin/bash
# 统计昨天的 AI 相关提交
echo "=== $(date -v-1d '+%Y-%m-%d') AI Coding Stats ==="
echo "AI commits: $(git log --oneline --since="yesterday 00:00" --until="today 00:00" --all | grep '\[ai\]' | wc -l)"
echo "Total commits: $(git log --oneline --since="yesterday 00:00" --until="today 00:00" --all | wc -l)"
echo "---"

结果写到 Obsidian 日报的固定位置。自动化只做最机械的部分（数字），分析和反思仍然手动做——因为那部分才有真正的价值。

四、下一步：从"我"到"我们"

目前这套东西只在我自己身上跑。但过程中我发现几个团队维度也很值得追踪。下表「现状」列是填表示例，不是团队普查，也不算个人覆盖成绩：

维度	指标	现状	难点
CLAUDE.md 覆盖率	有多少项目有 CLAUDE.md	我管的项目 100%，其他团队 ~30%	需要推动其他团队采纳
spec.md 覆盖率	关键目录的 spec 覆盖	约 50% 的关键目录	维护动力不足，写一次就不再更新
Prompt 模板复用率	团队共享的 prompt 被复用次数	没有统计	需要工具支持
新人上手效率	用 AI + CLAUDE.md/spec.md 的新人 vs 传统方式	未测量	需要多个新人样本

这些目前还不急着追踪。先把个人指标跑稳了，再来谈团队推广。

五、反思：好的指标是镜子，不是鞭子

这一轮实践下来，我最重要的认知是：指标的价值不在于"证明 AI 有用"，而在于"发现自己的盲区"。

顺着上面的示例读数，会看到这几件事：

我对 AI 的依赖比想象中高。 AI 参与 60% 的提交比我自己感觉的"随手用用"要重得多。这个数字不是好或坏，但让我重新审视哪些场景可以再优化。
CSS 类的一直不如手写。 如果没有这个评估表格，我会继续让 AI 调样式，每次调三四轮。现在果断放弃这个场景，用组件库默认样式 + 最小手动调整，整体反而更快。
最大的效率提升不是省时间，是省心流。 这个维度在传统框架里很少被提及，但它对我的实际感受影响最大。AI 帮我守住不被打断的状态，比任何"节省 X 小时"都值。
Prompt 墓地是最增值的部分。 失败的对话记录了 AI 当前的边界——什么场景它搞不定、什么类型的任务需要人类先搭好骨架。这些边界在持续变化（模型在升级），但记录下来的模式有持久的参考价值。

如果你也在思考怎么量化 AI Coding，我建议从这三个问题开始：

我最想知道的三件事是什么？
有什么是绝对不能量的？（因为会扭曲行为）
我能每天花不超过 2 分钟持续追踪吗？

回答完这三个问题，你的框架自然就出来了。不需要大盘，不需要自动化，从每天一行笔记开始。

→ 相关：AI Coding 体系架构图全景分析 | 01-AI coding 最佳实践 | 08-AI coding 最佳实践（八）完结篇

在用 AI 辅助开发的这一年多里，我一直在回避一个问题："用了 AI 之后，你到底快了多少？"

文中的百分比、耗时和覆盖率都是填表示例，用来说明指标怎么采集、怎么读。它们不是经审计的个人成绩，也不对应任何公司的生产数据。

一、先搞清楚要衡量什么

1.1 一张纸写下来，我最关心的问题

在搭建任何指标之前，我先问自己：如果只能知道三件事，我最想知道什么？

真实答案是：

我想知道	为什么重要	现在我怎么判断
AI 写的代码有多少最终合入了 master？	衡量 AI 产出的有效转化率	靠记忆，不准
用 AI 之后，一个需求从开到合的时间变了多少？	这是最直接的生产力信号	完全没衡量过
哪些场景用 AI 最划算，哪些场景不如手写？	指导后续投入方向	靠直觉，不系统

这三个问题比任何学术框架都重要。模型好不好、token 消耗多少 —— 那是治理层的事。对我个人而言，有效产出才是唯一标准。

1.2 什么不要衡量

先把不该量的说清楚，比先说该量什么更重要。

不要衡量	原因
AI 代码行数 / 天	行数是最容易作弊的指标，AI 尤其擅长生成冗长代码
AI 对话次数 / 天	多轮无效对话只能说明 prompt 写得烂，不是效率高
单位 token 产出	不同模型 token 价格差异太大，这个指标没有可比性
"AI 替代率"（AI 代码行数 / 总行数）	鼓励用 AI 写一切，反而降低整体效率。有些东西手写更快
排行榜式对比	每个人的工作内容不同，跨人比较 AI 效率毫无意义

所以我给自己定的底线：这些指标只用于自我优化，不用于汇报，不用于比较。

二、我的实操框架：三个指标，五层采集

我把想要的东西压缩到三个核心指标，不贪多。每个指标都有具体的采集方式，不需要额外工具，用我现有的命令行就能跑。

2.1 核心指标一：AI 有效采纳率

定义：AI 生成的代码中，最终进入 master 的比例。

为什么这个重要：AI 生成 1000 行，最后合入 50 行，那实际有效采纳率只有 5%。高 AI 用量 + 低采纳率 = 大量时间花在改 AI 的代码上，还不如自己写。

我怎么采集：

bash

# 方法一：利用 git 提交信息中的 AI 标记
# 我在 AI 生成的提交中统一加了 [ai] 前缀
git log --oneline --since="2026-07-01" | grep "\[ai\]" | wc -l    # AI 参与的提交数
git log --oneline --since="2026-07-01" | wc -l                      # 总提交数

# 方法二：更细粒度 —— 统计合入的 AI 文件数
# 我用 spec.md 标记了哪些文件是 AI 首发（文件头部有 // @ai-generated）
git log --diff-filter=A --name-only --since="2026-07-01" \
  | grep -E '\.(ts|vue|tsx)$' \
  | xargs grep -l "@ai-generated" 2>/dev/null | wc -l

示例读数（近两周。演示这张表怎么填，不是经审计的个人成绩）：

维度	数值
AI 参与提交占比	约 60%（大部分工具性代码都是 AI 写的）
AI 代码最终合入率	估计 70% 左右（30% 左右被重写或废弃）
一次通过的 AI 提交占比	约 40%（大部分 AI 代码需要至少一轮修改）

拿到数据后的第一个发现：AI 参与提交占 60%，但一次通过率只有 40%。说明我花了不少时间在修正 AI 的输出上。如果能提升一次通过率到 60%，我的整体效率还能再提一截。

2.2 核心指标二：需求交付加速度

定义：用 AI 之后，同类需求从启动到合入的时间缩短了多少。

为什么这个重要：这是最接近"生产力"的指标。但前提是要有可比基线——你不能拿一个复杂需求跟一个简单需求比。

我怎么采集：

bash

# 用 git 提取需求的交付周期
# 假设你的分支命名规范是 feat/<feature-name> 或 task/<task-id>
# 找到分支的第一个和最后一个 commit 时间

git log --all --format="%H %ai %s" --since="2026-06-01" \
  --grep="feat\|fix\|task" \
  | awk '{
      # 按需求分组，计算每个需求的 first commit 到 merge commit 的时间差
      # 这部分逻辑需要按你的分支命名习惯调整
  }'

真实情况是，这个指标很难自动采集，因为需求粒度不统一。我的替代方案很简单：

手动记录，模板化。在每个需求开始时，在 Obsidian 的每日笔记里记一行：

text

> [AI需求] 价格策略页面重构
> 启动: 2026-07-23 09:00
> 类型: 页面重构（中等复杂度）
> 预计人工耗时: 3天 → 实际: ?
> AI 参与程度: 高（80% 代码由 AI 生成）

需求结束时补一行：

text

> 合入: 2026-07-24 16:00  实际耗时: 1.5天  节省: 50%

示例记录（演示不同任务类型怎么对比，不是已验收的交付成绩）：

需求	类型	预计人工	实际耗时	AI 参与度	节省
定价模板表单组件	新增组件（业务逻辑重）	2 天	1.5 天	60%	25%
批量操作工具函数	工具函数（模式固定）	1 天	2 小时	90%	75%
状态机重构	重构（逻辑密集）	1.5 天	1 天	40%	33%
WebGL 着色器优化	算法类（需要专业知识）	2 天	0.5 天	70%（Claude 擅长）	75%

拿到数据后的发现：AI 的效率提升跟任务类型强相关。模式固定的工具代码（90% AI 生成，节省 75%）和需要专业知识的算法类（Claude 懂 WebGL，节省 75%）是收益最大的场景。业务逻辑重的表单（60% AI 但只省 25%）说明业务上下文传递还不够好。

这个发现直接指导了我后续的投入：重点优化 AI 理解业务上下文的能力（spec.md 的质量），而不是纠结模型选择。

2.3 核心指标三：场景性价比矩阵

定义：不同开发场景下，AI 的投入产出比。

我怎么评估：不追求精确数字，用 定性 + 方向性 的分级就够了。

用一个简单的评估表格，每周回顾时填一次：

场景	用 AI 频率	单次耗时	单次省时	质量评分(1-5)	ROI 感觉	策略
新建组件（标准 CRUD）	高	写 prompt 5min + review 3min	省 1-2h 手写	4	✅ 高	持续使用
重构现有代码	中	写 prompt 10min + review 15min	省 30min 梳理	3	⚠️ 中	选择性使用
修复 Bug	中	描述问题 5min + review 10min	省 20min 排查	2	⚠️ 中	只用于已知根因的 bug
写单元测试	高	2min 给 AI 函数 + 1min review	省 30min 写测试	5	✅ 高	大力使用
写文档 / README	中	3min 描述 + 2min 润色	省 20min	4	✅ 高	持续使用
CSS / 样式调整	低	描述不清楚，反复改	省很少，可能更慢	2	❌ 低	不如手写或直接用组件库
架构设计讨论	低	10min 讨论	省 1h 冥思苦想	4	⚠️ 中	作为讨论伙伴，不直接采纳
解析报错 / 查文档	高	1min 粘贴 + 10s 阅读	省 10-30min 搜索	5	✅ 高	首选方案

拿到数据后的发现：写得最快的不一定最值。单元测试和报错解析省的时间绝对值不大，但省的是"打断心流"的切换成本。心神被打断后重新进入状态需要 15-20 分钟，AI 10 秒解决报错意味着我可以一直留在心流里。这个价值远比表面时间差更高。

三、落地：怎么让追踪不成为负担

搭指标最大的陷阱是：搭建花了一周，追踪只坚持了一周。 我经历了三轮迭代才找到可持续的方式。

3.1 第一轮（失败）：想一次性建个大盘

第一轮我试图搞个数据面板，自动采集所有指标——git 统计、AI 工具日志、token 消耗。花了两天搭了个雏形，然后就不想维护了。

失败原因：

采集链路太复杂，各种工具的数据格式不统一
看数据需要上下文——一个"AI 采纳率 60%"的数字，不结合具体项目上下文完全没意义
维护成本远超收益

3.2 第二轮（部分成功）：只追踪三个手写指标

第二轮我把指标压到了三个，用 Obsidian 每日笔记手动记录。能坚持。

每天的记录是这样的（写在 Z-day/YYYY-MM-DD.md 里）：

markdown

## AI Metrics

| 指标 | 今日 |
|------|------|
| AI 提交数 / 总提交数 | 3/5 |
| 省时感觉 | ⭐⭐⭐ （做了个批导，AI 基本全写了） |
| 最佳场景 | WebGL 着色器 —— Claude 直接给了可用的 GLSL |
| 最差场景 | 动态表单校验 —— context 太长 AI 乱了 |

### Prompt 墓地
今天浪费的对话：
- "把这个校验逻辑改成支持动态规则" → 改了 4 轮，最后手写了
  教训：动态规则这类需要理解整个校验体系的，单次对话不行，需要先喂 context

3.3 第三轮（在弄）：把 git 统计自动化，但只做最简单的

现在我在 hammerspoon（macOS 的自动化工具）里加了个定时脚本，每天凌晨跑：

bash

#!/bin/bash
# 统计昨天的 AI 相关提交
echo "=== $(date -v-1d '+%Y-%m-%d') AI Coding Stats ==="
echo "AI commits: $(git log --oneline --since="yesterday 00:00" --until="today 00:00" --all | grep '\[ai\]' | wc -l)"
echo "Total commits: $(git log --oneline --since="yesterday 00:00" --until="today 00:00" --all | wc -l)"
echo "---"

结果写到 Obsidian 日报的固定位置。自动化只做最机械的部分（数字），分析和反思仍然手动做——因为那部分才有真正的价值。

四、下一步：从"我"到"我们"

目前这套东西只在我自己身上跑。但过程中我发现几个团队维度也很值得追踪。下表「现状」列是填表示例，不是团队普查，也不算个人覆盖成绩：

维度	指标	现状	难点
CLAUDE.md 覆盖率	有多少项目有 CLAUDE.md	我管的项目 100%，其他团队 ~30%	需要推动其他团队采纳
spec.md 覆盖率	关键目录的 spec 覆盖	约 50% 的关键目录	维护动力不足，写一次就不再更新
Prompt 模板复用率	团队共享的 prompt 被复用次数	没有统计	需要工具支持
新人上手效率	用 AI + CLAUDE.md/spec.md 的新人 vs 传统方式	未测量	需要多个新人样本

这些目前还不急着追踪。先把个人指标跑稳了，再来谈团队推广。

五、反思：好的指标是镜子，不是鞭子

这一轮实践下来，我最重要的认知是：指标的价值不在于"证明 AI 有用"，而在于"发现自己的盲区"。

顺着上面的示例读数，会看到这几件事：

我对 AI 的依赖比想象中高。 AI 参与 60% 的提交比我自己感觉的"随手用用"要重得多。这个数字不是好或坏，但让我重新审视哪些场景可以再优化。
CSS 类的一直不如手写。 如果没有这个评估表格，我会继续让 AI 调样式，每次调三四轮。现在果断放弃这个场景，用组件库默认样式 + 最小手动调整，整体反而更快。
最大的效率提升不是省时间，是省心流。 这个维度在传统框架里很少被提及，但它对我的实际感受影响最大。AI 帮我守住不被打断的状态，比任何"节省 X 小时"都值。
Prompt 墓地是最增值的部分。 失败的对话记录了 AI 当前的边界——什么场景它搞不定、什么类型的任务需要人类先搭好骨架。这些边界在持续变化（模型在升级），但记录下来的模式有持久的参考价值。

如果你也在思考怎么量化 AI Coding，我建议从这三个问题开始：

我最想知道的三件事是什么？
有什么是绝对不能量的？（因为会扭曲行为）
我能每天花不超过 2 分钟持续追踪吗？

回答完这三个问题，你的框架自然就出来了。不需要大盘，不需要自动化，从每天一行笔记开始。

→ 相关：AI Coding 体系架构图全景分析 | 01-AI coding 最佳实践 | 08-AI coding 最佳实践（八）完结篇