@zhongzhaoguo 啊，关于这个问题，我发现很多人一个 chat 聊一个月都不换，然后上下文爆炸。其实应该每天都 /new 一个 session 出来

@unusualcat 啊？！还有这猫腻，果然 openai 还是藏了一手，可恶🤪

打开 codex 果然可以看到了。就是 weekly usage 。多谢多谢🫰

@bingordinary 这个框架跟我在 hackernoon 上的这篇文章的想法是一样的
https://hackernoon.com/agent-behavior-specification-a-new-development-for-the-ai-era

但是你这个框架有个很直接的问题：想是一个给自己用的 repo 。别人看不懂怎么用，也不知道这些命令背后的含义。建议修改一下。通俗一点。如果你觉得无法抽象成很通俗的概念介绍给别的用户，那这个设计本身可能就是有问题的。

2026-1986 ，不是应该等于 30 岁吗？

deepseek 几乎就是免费了。为啥不用

100rmb 你还嫌贵？我今天刚刚从 sonnet 切过来，我用个豪华版都比 sonnet 便宜 7 倍

如果没有喜欢的城市为什么要定居？如果一定要定居建议成都，生活节奏慢

如果“给我做一个管理后台”就能做出一个管理后台。那这句话的信息量还不如“帮我搭一个 wordpress 后台”

@NakanoAzure 我自己倒是发明了一套，一直在犹豫要不要开源。我的核心是让 ai 写完代码别提交，然后生成一份交 commit request 的东西，格式是这样的：

然后它做完改动就会问你的意见，只有你说 approve 它才会提交代码

-----------把这些写到 CLAUDE.md 里面--------------------

## 单次改动规范(CR 规范)

### 颗粒度

每一次改动保持小颗粒度。颗粒度判断标准：

- **同层改动**：单次改动尽量只改同一层。改 service 就不改 router/view ；改业务逻辑 py 就不改 REST API 层。
- **一句话概括检验**：本次改动的 CR 中，Design （ feature ）或 Solution （ defect ）必须能用一句简短的话概括完。如果需要列多件事才能描述清楚，说明颗粒度太大，应拆分。
- **颗粒度不应过小**：如果本次改动本身就只涉及配置（例如某个 defect 就是配置错误，或本次只改 `CODER.md` / `.gitignore`），则配置单独成一个 CR 是合理的。但如果配置改动是为了支撑业务逻辑改动（例如为新功能新增依赖），则依赖变更与源码改动应合并在同一个 CR 里，不应拆开。
- **改动必须闭合**：每次改动都必须有验证手段，保证不会提交错误代码后再修改。验证方式按优先级：
1. 项目已有对应层的**单元测试** → 随改动一起更新，CR 的 Test Details 写测试摘要。
2. 项目已有**端到端测试** → 随改动一起更新，CR 的 Test Details 写测试摘要。
3. 无自动化测试 → 在 CR 的 Test Details 里写清楚**手动验证步骤**，告诉用户执行哪条命令或操作来验证本次改动正确。
4. 连手动验证都难以做到（例如改动依赖外部环境尚未就绪）→ 在本次改动中附上**临时测试脚手架代码**，CR 注明"下次改动删除脚手架"，下一个 CR 中去除。

### CR （ commit request ）

每次模型修改完代码**必须**不直接 commit ，并且生成一份 CR 。
CR 的作用是改动摘要，方便用户及其他 agent 了解改动。
CR 生成后回显给用户，并写入 `.cr.md` 文件。
只包含**项目规则 md 文件**的改动不用生成 CR

**项目规则 md 文件**: 定义项目规则的.md 文件，比如 `PROJECT.md`, `CR.md`, `TASKS.md`。

**CR 回显规则**：回显给用户的 Chat 版本必须与 `.cr.md` 完全一致，包含所有字段，不得省略任何一项。缺少任何字段的 CR 视为不合规。

#### CR 的 reply

CR 创建后等待用户 reply 。reply 分为以下几种：
- **approve**：回复"approve, <理由>"。进行**reply 后的 CR 文件操作**。最后执行 commit & push 。
- **reject**：回复"reject, <理由>"。回滚所有改动。并进行**reply 后的 CR 文件操作**。
- **remake**：回复"remake"。当 CR 混乱或内容有误时使用。模型基于 `git diff HEAD` 全量 diff 从头生成一份新 CR ，覆盖当前 `.cr.md`，回显给用户后继续等待 reply 。
- **ask**：用户通过多轮提问了解本次改动的细节，不造成任何代码改动。模型只回答问题，不执行任何操作，不重新生成 CR 。用户问完后再做出 approve 或 reject 的决定。
- **modify**：修改。用户可以：1. 自己手动更改并要求模型更新 CR ； 2. 让模型修改代码，模型自动更新 CR 。**更新 CR 时只在现有 `.cr.md` 基础上补充或修正变更内容，不得整体重做**——在受影响的字段（ Source Details 、Source Tree 、Test Result 等）追加或修改对应内容即可。更新后回显给用户并继续等待 reply 。只有收到 `remake` 指令时才从头重写 CR 。

#### reply 后的 CR 文件操作

approve 或 reject 执行完对应操作后：
- `.cr.md` 中增加 **Reply** 段落，写上 reply 的结果和理由。可选的结果有 approve, reject
- `.cr.md` 重命名为 `cr.<timestamp>.md`，`timestamp` 格式 `yyyyMMddHHmmss`
- 移入 `cr` 文件夹（不存在则新建）
- `cr` 文件夹会提交到 git ；`.cr.md` 已加入 `.gitignore`

#### CR 的格式

CR 分为 feature 和 defect 两种。

**Source Tree** 和 **Test Tree** 必须使用 ASCII 文件树格式，不可以用一句话代替，例如：
```
project/
├── src/
│ └── service.py ← updated
└── tests/
└── test_service.py ← new
```

**feature**
- **Design**：本次改动的设计摘要
- **Source Details**：源码核心细节，1~2 行代码，简短，不含测试改动
- **Source Tree**：本次改动的源码文件树（ ASCII 树）
- **Test Details**：测试改动摘要。细节见 **CR 的测试方式**
- **Test Tree**：本次改动的测试文件树（ ASCII 树）；细节见 **CR 的测试方式**
- **Test Result**：测试的结果。细节见 **CR 的测试方式**

**defect**
- **Root Cause**：defect 的根本原因
- **Solution**：修改方案摘要
- **Source Details**：源码核心细节，1~2 行代码，简短，不含测试改动
- **Source Tree**：本次改动的源码文件树（ ASCII 树）
- **Test Details**：测试改动摘要。细节见 **CR 的测试方式**
- **Test Tree**：本次改动的测试文件树（ ASCII 树）；细节见 **CR 的测试方式**
- **Test Result**：测试的结果。细节见 **CR 的测试方式**

#### CR 的测试方式
CR 中可选的测试方式有端到端测试，单元测试，无测试。他们有不同的处理方式。
**无测试**
本次改动不需要测试，比如更新 `PROJECT.md` 的文本内容，修改 `.gitignore` 等
- **Test Details**： `无变更`
- **Test Tree**： `无变更`
- **Test Result**： `无变更`

**单元测试**
模型自己在 `tests/unit`下新增，更改单元测试，执行单元测试，将执行结果摘要写入 Test Result （通过/失败条数、失败原因）
- **Test Details**：写出本次单元测试的测试目的，方式的摘要
- **Test Tree**：本次改动的测试文件树（ ASCII 树）
- **Test Result**：单元测试的结果

**端到端测试**
模型自己在 `tests/e2e`下新增，更改端到端测试，执行端到端测试，将执行结果摘要写入 Test Result
- **Test Details**：写出本次单元测试的测试目的，方式的摘要
- **Test Tree**：本次改动的测试文件树（ ASCII 树）
- **Test Result**：端到端测试的结果

@AlexaZhou 我每隔几天都可以找出一个 a 家吊打别家的例子。今天我用的 openclaw 遇到 gog 权限掉了的问题。op 自动帮我打开了授权网页。但是我一开始没在意，过了几分钟再去点授权，失败了。op 说没事，咱再来，然后又失败，然后又来，无限循环。问了 ChatGPT ，跟我分析了一堆。完全没用。还是无限循环。还叫我重新建立新 API key 。
问了 claude 。模型是 sonnet Medium 。大意是：“你是不是有一个授权窗口没有及时点？叫 openclaw 别再重试了，关掉浏览器，再叫 openclaw 授权一次，这次立即去点”
然后就解决了 boom

@Jensond 了解了

每天都要说一句：除了 A 家的都是垃圾。别用垃圾模型，只会浪费你的时间。但是 A 家的不让你用就另说了。。。

哈哈哈，就是这个问题。我经常说 ai 写的代码没有小问题，只有大问题

@Sorhyu 那这确实没法喷，无奈之举

每天都要说一句：除了 A 家的都是垃圾。想省钱就用最好的模型，便宜模型给你来几个死循环，一下额度就用完，比如 codex

看着都累。
- 每天都想说一句：除了 A 家的其他都是垃圾。你都用 cc 了为啥内核要用 o 家的。买椟还珠。一个便宜的模型，再便宜，给你来几个死循环，额度一下就满了。而且还浪费你的时间和注意力。就只用 cc ，用它默认的 sonnet 就够了。
- 尽量多/new session ，保证上下文小一点，工作效率高的时候花钱还少。有的事情直接开 subagent 做或者开 -p 模式做。这些模式下的 agent 上下文是干净的，只加载需要的上下文。
- 别总是 ai 写代码，ai 自己审核，ai 测试，中间啥都不管。你别让 ai 自己审核自己，浪费 token 。我常常说 ai 写的代码没有小问题只有大问题。你就时不时自己看下 ai 在写什么。然后夺命连环问，一个 pr 问它个 20 次，做到自己虽然不写，但是心里有数。有问题别自己改，写到 CLAUDE.md 里面防止它再犯

你做到这些 token 使用率暴跌 90%，bug 率暴跌 90%，还不用整这啊那啊的工具框架，现在的工具框架自己都是 ai 几天写出来的垃圾项目，大家又不傻。

我看着都累。你用的是什么 ai coding 的工具。怎么这么不相信它。你只不过是写代码而已。又不是开了一个 openclaw 然后放到了公网上。如果你开了 openclaw 并放到了公网上，请没事就把那个网页版的控制台 disable 掉。只用命令行和 TUI 可以规避很多风险

@cest 当 context 够大的时候 llm 会忘记任何事情，所以真正工作是不应该一个 chat 干到底的。时不时要 /new 一个新的出来，或者你干脆就 开 subagent 或者 Claude -p 会更好