AI on Time Friend

用 /insights 审视你的编码习惯

Mon, 27 Jul 2026 16:30:00 +0000

Claude Code 用了一段时间, 自我感觉挺良好. 直到有朋友跟我说: “你试试 /insights.”

运行 claude 进入会话, 输入:

/insights

等个几十秒, 浏览器里自动弹出一个 HTML 报告. 它会分析你过去 30 天的 Claude Code 会话, 拆成几个板块: 你在什么项目上花了多少时间、最常用哪些工具、语言分布、以及——最扎心的——你的工作流里哪些地方在反复浪费 Token.

所有数据都来自本地的 ~/.claude/ 会话日志, 报告不会离开你的电脑.

报告的结构

概览数据

最上面一个 “At a Glance” 卡片, 展示核心统计: 会话数、总消息数、代码修改行数、活跃天数.

我第一次跑出来是 38 个会话, 659 条消息, 22 天活跃. 看一眼大概就知道自己用得有多勤.

使用模式

报告用柱状图展示了几个维度:

最常用的工具: 你会发现自己的 Edit 用了多少次, Bash、Read、Write 各占多少比例
编程语言分布: TypeScript、Python、Markdown 各占百分之几——这个分布有时候会让人意外
任务类型: 代码生成、调试、重构、测试编写各占多少
会话时长: 平均每条会话多久, 平均回复时间多少

我第一次看到自己 18% 的时间花在 Markdown 上时, 重新思考了一下自己的工作流——原来写文档占了我这么多精力.

使用风格分析

报告会生成一段自然语言描述, 分析你的工作风格. 不止是数字, 而是一段像人写出来的评语.

从终端到团队, Agent 工作流怎么长大

Sat, 18 Apr 2026 17:00:00 +0000

头几个月, 我一个人在终端里用 Claude Code, 感觉效率提升很明显。但很快遇到一个问题: 我下班关了电脑, agent 也停了。我需要的东西, 只能在我坐在电脑前的时候才能跑。

如果你的使用场景也是"只有我在的时候才用", 那 Claude Code 完全够用。但当你开始想: 这个 CR 能不能自动帮我 review? 这个依赖更新能不能每周一自动跑? 你就需要想怎么让它离开你的电脑还能干活了。

第一步: 把重复劳动做成脚本

最简单的方式就是把常用的 agent 任务写成脚本。比如我每两周要升级一次项目的依赖:

claude -p "把 package.json 里的依赖升到最新 minor 版本, 跑测试, 有 break 就修"

用 --output-format json 可以拿到结构化的输出。需要流式处理的话用 stream-json, 每行一个 JSON 对象。

再进一步, 把这些脚本扔到 crontab 或者 CI 里:

# 在 GitHub Actions 或 crontab 里跑
claude -p "review 最近变更的代码, 检查安全问题" \
 --output-format json --allowedTools "Edit,Bash(git *)"

--allowedTools 限制了 Claude 只能做什么操作——批量跑的时候尤其重要, 防止它乱搞。

Review Agent 的代码, 和 Review 同事的不一样

Fri, 03 Apr 2026 13:25:00 +0000

Review 同事写的代码, 和 review agent 写的代码, 是两套不同的事。

一起干活久了, 多少知道同事写代码的习惯——谁喜欢用 reduce, 谁总忘记处理边界。但 agent 没有"习惯", 它的每一次输出都取决于那次会话的上下文。

Review agent 代码的时候, 我养了几个自己的检查点。

第一: 看它改了不该改的地方吗

Agent 最大的问题不是写不对, 是管不住自己。它可能为了修一个 bug, 顺手把旁边的配置也改了, 或者把另一个函数的重命名顺便带上了。

Diff 文件里所有不在任务范围内的改动, 都是危险信号。

第二: 看它处理边界了吗

Claude 写的 happy path 通常很漂亮。问题出在用户输入为空、网络请求超时、权限不足的时候——这些分支常常没覆盖。

Review 的时候我会专门盯着 if/else 的分支看: 所有 else 和 catch 里的逻辑是真的处理了错误, 还是只是打了个 log 就过去了?

第三: 看测试是真测还是假测

这是 agent 最喜欢偷懒的地方。写出来的测试看起来跑过了, 但仔细一看——mock 了整个函数, 断言了一个硬编码的值, 或者测了一个从来不会失败的条件。

我有个检查习惯: 把测试里的数据换一批, 看看它还能不能过。换数据就挂的测试, 说明测的是假逻辑。

第四: 看代码风格是不是和项目一致

Agent 有自己的默认风格——它写出来的代码可能技术上没问题, 但跟你们项目里现有的代码风格格格不入。

命名风格、错误处理模式、甚至空行的习惯——这些不一致不会让代码出 bug, 但会让维护的人很痛苦。如果发现风格不一致, 回 CLAUDE.md 里加一条规则, 下次就好了。

这五类任务别交给 Agent

Sun, 22 Mar 2026 08:50:00 +0000

用了几个月 agent, 很容易进入一种状态: 什么东西都想扔给它干。

但有些任务真的不适合——不是 agent 能力不够, 是让它干的风险和收益不成正比。

一、涉及生产数据的操作

直接在生产数据库上跑 SQL——哪怕是 SELECT——我不放心。Claude 不会故意搞破坏, 但它可能因为理解偏差, 扫了全表导致数据库打嗝。操作生产环境的配置、直接改线上服务的部署配置——这类事我坚持自己来。回滚一次的时间比让 agent 操作省的时间多得多。

二、安全敏感的变更

改登录逻辑、权限校验、加密解密——这些我从来不交给 agent。不是因为 Claude 写不对, 而是这类代码出事就是大事, 而且漏洞往往不在明面上。

我的做法: agent 可以写 draft, 但每一行我都要亲自 review, 并且要额外找个同事再看一遍。不信任叠加——两层人眼比一层可靠。

三、需要人类判断的决策

“这个按钮是放左边还是右边"“这个错误信息用户能看懂吗"“这个 API 的返回值要不要加个字段”——这些没有对错之分, 只有"合不合适"的问题。

Agent 没有产品 sense, 也没有用户的上下文。让它在两套方案里选一个, 它选的方案可能从技术角度看最优, 但从产品角度看完全不对。

四、模棱两可的"看看”

“帮我看看这个项目有什么可以改进的地方”——没有范围、没有标准、没有截止条件。Claude 会去读几百个文件, 然后把上下文塞满, 最后给你一个泛泛的报告。

如果你真的想做代码审查, 给范围: “只看 src/api/ 下的错误处理逻辑, 找潜在的空指针风险”。

五、跨多系统的协调

需要改 A 服务、等 B 服务部署完、再看 C 服务的响应有没有变化——这种跨系统的流程, agent 做不了。不是因为技术不行, 而是每一步之间可能有你无法预料的依赖, agent 不知道什么时候该等、什么时候该继续。

当然, 这些"不适合"的边界不是固定的。随着你越来越了解 agent 的能力边界, 有些之前不敢放手的任务, 后来发现其实可以。

Agent 和 Assistant 是两回事

Sat, 14 Mar 2026 15:40:00 +0000

刚用 Claude Code 的时候, 我花了不少时间纠结一个问题: 它到底是 agent 还是 assistant?

看了不少文章, 大部分试图给这两个词划一条清晰的线——assistant 一次一步, agent 自主完成目标。但实际用下来的感受是, 大多数工具两种模式都能切, 分界线没那么分明。

真正有意义的区别不是产品叫什么, 而是谁发起、谁控制、在哪里跑。

Assistant 模式: 你每步都要盯着

用 Claude Code 最基础的用法就是这样: 你打一句 prompt, 它动一下, 你看一眼, 然后你打下一句。

你在每一轮都掌握控制权。你决定下一步做什么, agent 只是执行。这种模式下:

你全程在场, 不太会出大问题
但你的注意力被绑死了——它动一下你就要看一下
适合探索性的工作: 调试、原型、架构讨论

Agent 模式: 定好目标就放手

把目标扔给 Claude, 它自己去读代码、改代码、跑测试, 最终给你一个结果。

这时候你的角色变了——你不再是驾驶员, 而是定目标的人和审结果的人。中间的过程你不需要每步都看。

这种模式下:

你的注意力可以解放出来, 同时干别的事
但风险也高了——它可能走偏了等你回来才发现
适合有清晰完成标准的任务: 重构、迁移、批量修测试

最实用的分法: 看触发方式

抛开理论, 实际工作中最好用的区分方式其实是谁触发的:

你在终端里敲命令 → Assistant 模式
定时任务跑起来的、GitHub Webhook 触发的、CI 里自动执行的 → Agent 模式

我自己最有价值的体会是: 不用纠结它该叫 agent 还是 assistant, 而是建立一条 pipeline——用 assistant 模式试出一个可靠的工作流, 然后把它变成定时跑的 agent 任务。

几轮对话后 Claude 变笨了

Fri, 06 Mar 2026 11:10:00 +0000

用了几个月 Claude Code 之后, 我遇到了一个奇怪的现象: 同一个会话, 做到后面感觉 Claude 变蠢了。

不是你的错觉, 也不是模型的问题。是上下文炸了。

上下文是怎么炸的

Claude 的工作记忆是有限的。会话一开始, 它清楚地记得目标是什么、做了哪些决策、还有哪些事没做完。到了第 50 轮, 上下文里塞满了走过的弯路、讨论过的方案、和你争论的对话历史。

输出质量下降是必然的。

每轮对话都是检查点

Claude Code 有一个很方便的机制: 每发出一条 prompt 就会自动创建一个快照。不只是记对话, 还会快照被修改的文件状态。

按两次 Escape 或者输入 /rewind, 会打开回退菜单。你可以选择:

只回退对话
只恢复代码
两者都回退
从某个节点开始压缩

有了这个, 你可以大胆地让 Claude 尝试高风险方案。不行就回退, 不丢任何代码。检查点会随会话保存, 关掉终端回来还能继续回退。

但要注意: 检查点只追踪 Claude 通过编辑工具做的修改。通过 Bash 命令或外部进程改的东西不在此列。它不是 git 的替代品。

几个习惯, 保持上下文干净

走偏了立刻打断

按 Escape 中断它。按两次 Escape 打开回退菜单, 可以回滚到之前的状态。

我踩过的一个坑: 当 Claude 反复回到一个错误假设的时候, 我下意识用了 /compact。结果它把那个错误假设也保留了, 问题没解决。正确做法是:

最好的是 /clear 清空, 用更精确的 prompt 重新开始
如果你想保留当前的关键上下文, 用 /compact 只保留 API 变更相关的部分, 丢掉调试过程——加上 focus 指令告诉它该留什么

常用命令

/clear: 任务之间清空上下文, 别让上个任务的逻辑污染下个任务
/compact: 加 focus 指令, 用在长而连贯的会话里, 保留关键部分丢掉噪音
Subagent: 把大量研究类的工作交给它, 在独立上下文里完成, 还你一个总结
/rename: 给重要的会话打标签, 方便之后找回

我自己用的土办法

每次完成一个逻辑单元——一个函数、一个组件——就 git commit, 然后 /clear, 再开始下一个。

我的 CLAUDE.md 里都放了什么

Thu, 19 Feb 2026 16:20:00 +0000

最讽刺的事情是什么? 你一边抱怨"每次新会话都要重新跟 Claude 解释项目背景", 一边项目根目录里根本没有 CLAUDE.md。

别笑, 我之前就是这个状态。

后来发现有个偷懒的办法——直接跑 /init。Claude 会自动分析你的项目结构、检测构建工具和测试框架, 生成一份初始的 CLAUDE.md。如果已经有 CLAUDE.md 了, /init 不会覆盖, 而是建议改进。

CLAUDE.md 的本质

Claude Code 启动的时候会自动读这个文件, 把它当作用来理解项目的起点。你项目怎么跑测试、目录结构是什么、有哪些不能碰的约定——写进去, 它自己就知道了。

第一类: 命令

最常见的用法——把命令写进去, 省得每次说:

## Commands
- 测试: npm test
- 构建: npm run build
- 单文件测试: npx jest src/xxx.test.ts
- Lint: npx eslint src/

有了这些, Claude 自己知道该跑什么, 不用你再说"跑一下测试"。

第二类: 架构约定

有些东西 Claude 看代码看不出来:

## Architecture
- 状态管理用 Zustand, 不用 Redux
- API 请求统一走 src/api/ 下的封装
- 不要直接改 src/core/ 里的文件, 只能通过扩展接口

第三类: 团队规范

Linter 管不了, 但 review 的时候一定会被说的:

Agent 改完的代码, 你敢直接合吗

Thu, 05 Feb 2026 09:45:00 +0000

Claude 改完代码说了一声"Done", 你看了一眼觉得差不多, 就合并了。然后周一线上挂了。

没有可运行的检查, agent 觉得"做完了"和你觉得"做完了"是两码事。最贵的 bug 不是崩溃, 是安安静静返回了错误结果。

最简单的: prompt 里加一句

最轻量的做法, 就是在 prompt 末尾加一句话:

改完之后跑一下测试, 不通过就继续修.

Claude 改完代码会自己去跑 npm test, 挂了就回头看代码, 修好了再跑。全过程不需要你介入。

但这有个问题——它只按照自己理解的标准来验证。如果你的测试覆盖率不够, 或者"完成"的定义比跑通测试更复杂, 就需要更多层。

分层往上加

第一层: prompt 内检查

就是上面说的, 告诉它跑测试。日常小改动用这个就够了。

第二层: 定义完成标准

在 prompt 里说清楚什么算"做完":

每次修改完运行 npm run build && npm test, 把输出发给我.

这样你至少能看到它跑了什么、输出了什么, 不是它说 done 你就信。

第三层: 不让它糊弄

加一句关键的:

修复根因, 不要掩盖错误.

这能防止 agent 用空的 try-catch 或者假的 fallback 数据来敷衍你。

第四层: `/goal` 条件

把验证条件设成会话级的 goal, 每次修改后自动检查:

/goal 测试全部通过, 构建产物不超过 200KB

Claude 会在每轮修改后重新检查, 不满足就继续改, 不需要你每次都说"再跑一下测试"。

写 Prompt 一次过的秘诀

Thu, 22 Jan 2026 14:15:00 +0000

用了一段时间 Claude Code, 你会发现大部分翻车的会话不是模型不行, 是你自己的 prompt 有问题。Claude 能猜你的意图, 但你没法指望它会读心。

把任务范围卡死

“帮我优化一下这段代码”——这种 prompt 出来什么结果全看运气。什么叫优化? 性能、可读性、还是裁掉冗余代码?

好的 prompt 应该说清楚文件、场景和验证方式:

给 src/auth.ts 写一个已登出用户的边缘用例测试, 不要用 mock.

任务范围越小, 结果越可控。模糊的 prompt 只有在一种情况下有用——你真的想让 agent 给意见的时候。“这个文件你有什么改进建议"就很合适, 但记得限定范围, 别让它自己逛到几百个文件里去。

指一个现成的例子

Claude 从真实代码里学规范比从文字描述里学快得多。你不需要跟它解释"我们项目的命名规范是驼峰、接口前缀有 I 开头”——

参考 src/services/user.ts 的写法, 用同样的模式实现这个新接口.

一句话, 比一百字描述都有用。

报 Bug 按固定格式来

我 debug 的时候用这个格式, 很少出问题:

症状: 用户登录后跳到 404 页面
位置: src/router/index.ts 第 42-56 行的路由守卫逻辑
修复标准: 登录后跳到 redirect 参数指定的页面, 没有 redirect 就去首页

再加一句 “先写一个能复现的测试再修”, 能防止它改完了但什么都没修。

用 `/btw` 处理临时小问题

有时候你做到一半, 突然想确认一个不相关的事——“这个包的 API 签名是什么样的?"。如果用主会话问, 它会污染上下文。用 /btw 这个包的 API 签名是什么 问, 答案会以浮层显示, 不进对话历史, 不占上下文。

用 Plan → Code 循环管住你的 Agent

Thu, 08 Jan 2026 10:30:00 +0000

刚用 Claude Code 的时候我有个毛病: 打开终端, 直接敲一句话告诉它帮我改什么, 然后看着它一顿操作, 最后发现方向完全不对。

后来想明白一个道理——Agentic Coding 和写代码是两套不同的技能。写代码的时候你的手跟着脑子走, 但用 agent 的时候, 你的价值在于"定义目标"和"审核结果", 而不是替它打字。

那怎么让 agent 不走偏? 我总结了四个步骤: 探索 → 规划 → 编码 → 提交。

第一步: 先探索, 别动手

Plan 模式是 Claude Code 的只读模式。启动的时候加个参数:

claude --permission-mode plan

会话里按 Shift+Tab 可以在 Plan 和 Accept-Edits 之间切换, 或者直接打 /plan。

为什么要先探索? Claude 对项目的理解完全取决于你给了什么上下文。让它自己把相关文件读一遍, 画出一张地图, 比你凭直觉说"去改那个文件"要靠谱得多。

碰到特别棘手的架构问题, 我习惯在 prompt 里加一句 “think carefully before proposing anything”。多数情况下, 它前面的推理越仔细, 后面的返工就越少。

不过也别教条。如果任务很小——修个 typo、改个变量名、加一行日志——直接让它做就行, 不需要走完整个 plan 流程。官网文档也说了: 如果你能用一句话描述完改动内容, 那就跳过 plan。

TensorFlow中的Tensor是什么?

Fri, 18 Sep 2020 00:00:00 +0000

Tensor(张量)

“张量”一词最初由威廉·罗恩·哈密顿在1846年引入。对，就是那个发明四元数的哈密顿：

Tensor实际上就是一个多维数组（multidimensional array）
Tensor的目的是能够创造更高维度的矩阵、向量。

色彩的例子

彩色图像文件（RGB）一般都会处理成3-d tensor，每个2d array中的element表示一个像素，R代表Red，G代表Green，B代表Blue

多维数组

把三维张量画成一个立方体：

更高维的张量:

初始化一个向量

0维

tf.tensor(1).print();

1维

tf.tensor([1, 2, 3, 4]).print();
// or
tf.tensor1d([1, 2, 3]).print();

2维

tf.tensor([[1, 2], [3, 4]]).print();
// or
tf.tensor2d([[1, 2], [3, 4]]).print();

3维

tf.tensor([[[1], [2]], [[3], [4]]]).print();
// or
tf.tensor3d([[[1], [2]], [[3], [4]]]).print();

4维

tf.tensor([[[[1], [2]], [[3], [4]]]]).print();
// or
tf.tensor4d([[[[1], [2]], [[3], [4]]]]).print();

5维

tf.tensor([[[[[1], [2]], [[3], [4]]]]]).print();
// or
tf.tensor5d([[[[[1], [2]], [[3], [4]]]]]).print();

6维

tf.tensor([[[[[[1],[2]],[[3],[4]]],[[[5],[6]],[[7],[8]]]]]]).print();
// or
tf.tensor6d([[[[[[1],[2]],[[3],[4]]],[[[5],[6]],[[7],[8]]]]]]).print();