HHW+

Throughout adversity, trials and tribulations. When you think you're alone know your shadow will stand.

[HHW+ @xuduohuan]

@akokoi1 请教下，cc 没有被封号吗

[HHW+ @xuduohuan]

@thsottiaux >>>>>> Anthropic
thanks Tibo

[Tibo @thsottiaux]

If you aren't yet bold enough to install the Codex app, you can stay in the presence of your orange crab and point it at GPT 5.6 Sol. Takes 5 minutes. Kudos to Theo for explaining one of the ways to get this done.

Step 1: Install CLIProxyAPI
Step 2: Connect
Step 3: Define following alias and enjoy claudex

```
alias claudex='CLAUDE_CODE_SUBAGENT_MODEL=gpt-5.6-sol \
CLAUDE_CODE_ALWAYS_ENABLE_EFFORT=1 \
CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY=3 \
ENABLE_TOOL_SEARCH=false \
claude --model gpt-5.6-sol'
```

If this gets blocked, I owe you a reset.

[HHW+ @xuduohuan]

@thsottiaux Good morning ☀️

[ClaudeDevs @ClaudeDevs]

https://t.co/v694m8Eaj6

[HHW+ @xuduohuan]

@tualatrix 居然没有被封号，厉害

[HHW+ @xuduohuan]

@dotey 宝玉老师，用了半年的 claude Pro 今天被封了，请问有什么解决方案吗？

[HHW+ @xuduohuan]

@planifoliaspark @CSZZL592 表格页面会被重定向

[Andrew Ng @AndrewYNg]

“Loop engineering” is a hot buzzphrase after mentions of it by Boris Cherny (Claude Code’s creator) and Peter Steinberger (OpenClaw's creator) went viral on social media. Loops are now a key part of how we get AI agents to iterate at length to build software. In this letter, I’d like to share my 3 key loops, shown in the image below, for building 0-to-1 products. These loops guide not just how I build software, but also how I decide what software to build.

Agentic coding loop: Given a product specification and optionally a set of evals (that is, a dataset against which to measure performance), we can have an AI agent write code, test its work, and keep iterating until the code is bug-free and meets its specification. This idea of closing the loop took off around the end of last year, and it has been a game changer in enabling coding agents to work longer productively without human intervention. For example, over the weekend, I was building an app for my daughter to practice typing, and my coding agent could easily work for around an hour, using a web browser to check what it had built multiple times before getting back to me, without needing my intervention.

The engineering loop executes quickly. Every few minutes, the coding agent might build and test a new version of the software. I hear frequently from developers who are finding new ways to engineer more effective engineering loops. This is an active area of invention!

Developer feedback loop: In this loop, a developer examines the current product and steers the coding agent to improve it. Last year, a lot of developers (including me) were acting as the QA (quality assurance) function for our coding agents, manually finding bugs and then asking the agent to fix them. But with coding agents much more able to test their own code, the amount of time we need to spend on this function has decreased significantly. This allows us to make higher-level product decisions, such as what key features to offer, where the UI needs improvement, and so on.

The developer-feedback loop operates over time intervals between tens of minutes and hours — that's how frequently a developer might review a product and give feedback. In the case of the typing app, I changed my mind a few times about the visual design, what cat costumes she can unlock as she learns (she loves cats), and the user flow for a grown-up to log in and steer the child's learning experience.

When a developer has a clear vision for what to build, it is still a lot of work to translate that vision into a specification for a coding agent to implement. Further, after the developer has seen an implementation, they might update (or perhaps clarify) the spec to steer it toward what they want. If you find that the system repeatedly runs into certain problems, building a set of evals for the agent becomes useful.

AI-native teams are increasingly using AI to help shape product direction, for example, automating the gathering and analysis of usage data, summarizing written and verbal customer feedback, or carrying out competitive analysis. However, for pretty much all the products I’m involved in, I see humans as having a significant context advantage over current AI systems — we know a lot more than the AI system about the users and the context the product has to operate in — and thus humans play a critical role. Many people describe this human contribution as “taste,” but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better. This also speaks to why this step can’t be automated: So long as the human knows something the AI does not, human-in-the-loop is needed to to inject that knowledge into the system.

External feedback loop: This includes a wide range of tactics like asking a few friends for feedback, launching to alpha testers, or putting the code into production with A/B testing. These tactics are usually slow, rarely taking less than hours and sometimes taking days or even weeks. This data informs the developer vision, which in turn continues to drive the detailed product spec, which in turn drives the coding agent.

With coding agents speeding up software development, more engineers are starting to play a partial product management role. For many engineers who are growing into this role, the hardest part is shaping the product vision and striking a balance between building (bridging the gap between vision and spec) and getting user feedback to evolve the vision. It is important to do both!

I will write more about how to do this in future posts, but for now, I find it encouraging that engineers are playing an expanded role (just as product managers and designers now do more engineering).

[Original text: The Batch]

[宝玉 @dotey]

开源项目推荐：Claude Code From Scratch

这是一本学习 Claude Code 的开源电子书，严格来说不仅仅是电子书，还有代码，不需要你去看 Claude Code 的 50 万行代码。

用 ~4300 行代码（TypeScript 和 Python 两个版本分别实现）复现了 Claude Code 的核心架构——Agent Loop、13 个工具（含并行执行 + 流式早期启动）、4 层上下文压缩、语义记忆召回、技能系统、多 Agent、MCP 集成……每一步都对照真实源码讲解它怎么做的 → 我们怎么简化的。

有 13 章内容，每一章都是一份分步教程，跟着动手写几千行代码，快速理解 Claude Code 这样最好用的 coding agent 的精髓。

读完你就能大致理解了 coding agent 的工作原理，我跟着快速浏览了下都有了些新的收获，推荐有兴趣的可以看看。

有中英文版：
https://t.co/x2F11US2g0

[宝玉 @dotey]

Codex 操作浏览器有两种模式，一种是 Chrome 插件，一种是内置浏览器。用了一段时间之后，我总结一下两者的差异和各自适合的场景。

【1】先说一个被低估的用法：拿 Codex 当爬虫

传统爬虫用 requests 或者 Playwright 无头模式去请求页面，现在风控越来越严，指纹检测、行为分析、验证码轮番上阵，很多网站一看你是程序化请求直接拦截。Codex 的浏览器不一样，它操作的是真实浏览器，有完整的渲染引擎、真实的用户代理、正常的 JavaScript 执行环境，在网站看来就是一个普通用户在浏览页面。

配合 /goal 模式，你设定一个目标（比如“把这个网站上所有产品的名称、价格、评分抓下来存成 CSV”），Codex 会自己规划步骤、翻页、处理异常，不需要你一步步指挥。这比自己写爬虫脚本省事得多。

但 Codex 有两种浏览器模式，特性完全不同，选对了事半功倍。

【2】Chrome 插件模式：能力强，但吃资源

用 @Chrome 调用的 Chrome 插件模式，核心优势是一个字：登录态共享。

它直接运行在你自己的 Chrome 浏览器里，继承你所有的 Cookie、登录会话、已安装的扩展。那些需要登录才能访问的内容，比如付费订阅的文章、企业内部的管理后台、CRM 系统里的客户数据、需要登录的社交平台，Chrome 插件都能直接访问，因为对网站来说，就是你本人在操作浏览器。

Codex 在 Chrome 里工作时会把任务放进独立的标签页分组，不会打断你正在看的页面。它还支持 DevTools 协议，能抓性能数据、看网��请求、调试 Console 错误。

但代价也很明显：资源消耗相当大。Chrome 本身就是内存大户，每个标签页都是独立进程。Codex 的 Chrome 插件在上面再加一层操控逻辑，截图、DOM 解析、指令交互全在跑，内存和 CPU 占用会非常高。机器配置不行的话（比如 8G 内存的笔记本），跑起来能明显感觉到卡顿，拿来做批量爬虫任务就更难受了。长时间运行还容易出现截图延迟、状态不同步的问题。

另外 Chrome 插件目前只支持 macOS 和 Windows，Linux 用户暂时用不了。它也不支持无头模式，Chrome 窗口必须保持打开状态。

适合的场景：需要登录态的短期任务。比如登录某个平台抓一批数据、在内部工具上批量操作、从 CRM 导出信息。

【3】内置浏览器模式：轻快，但有局限

用 @Browser 调用的内置浏览器，是 Codex 自带的沙盒浏览器环境。

它最大的优势是轻量。不需要启动整个 Chrome，资源消耗小很多，响应速度快，适合需要频繁操作浏览器的场景。

但它有一个根本性的限制：没有你的登录态。不继承 Cookie、不继承浏览器扩展、不继承已保存的会话。打开一个需要登录的页面，你得在内置浏览器里重新登录。而且有些反爬严格的网站，对这种非标准浏览器环境的检测更敏感。我试过在内置浏览器里登录 X，反复失败，大概率是因为 X 的风控识别出了异常的浏览器指纹。

内置浏览器真正出彩的地方是前端开发调试。它有一个标记模式（Annotation Mode），你可以直接在渲染好的页面上选中某个元素或者框选一个区域，写上“这个按钮往上移”“字体加粗”“这个间距太大了”之类的批注，Codex 会把这些批注当作可执行指令来处理。这比用文字描述“第三行第二个按钮的 margin-top 减少 8px”直观太多了。

配合 Developer Mode，内置浏览器还能跑性能分析、抓网络请求、看 Console 输出，对本地开发服务器的调试非常友好。

适合的场景：公开页面的数据抓取、本地开发调试、不需要登录态的网页操作。

【4】怎么选

简单说：需要登录的用 Chrome 插件，不需要登录的用内置浏览器。如果你的机器配置有限又需要大量抓取公开数据，内置浏览器是更好的选择。如果目标网站必须登录才能看到内容，或者反爬很严需要真实浏览器指纹，那只能用 Chrome 插件，但要有心理准备面对资源消耗。

Codex 自己也会根据任务判断应该用哪种浏览器。它的优先级是：有专用插件（比如 Jira、GitHub 的集成）就用插件，需要登录态就用 Chrome，其余情况用内置浏览器。

当然浏览器的用途远不止爬虫。我觉得内置浏览器做前端调试的体验比很多专门工具都好，标记模式配合 Codex 的理解能力，几乎是“指哪改哪”。Chrome 插件在自动化操作企业内部工具方面也很实用，比如定期从后台导数据、批量更新记录。这些场景还有不少值得挖��的空间，大家可以根据自己的实际需求去试试。

[宝玉 @dotey]

https://t.co/5DaPyMKzWZ

[宝玉 @dotey]

https://t.co/CdLb5LM1YK

[Barret李靖 @Barret_China]

看了一晚上 Claude Code 泄露的代码，结合常见的记忆管理框架，把记忆模块做了一些分析。

Tulving 老爷子在 1972 年提出了记忆系统的框架设计，至今仍在广泛使用，他把记忆分为三类：1）情境记忆���episodic memory），我干了啥，用来记录过去；2）语义记忆（semantic memory），我知道啥，用来提炼规律；3）以及程序化记忆（procedural memory），我会做啥，用来决定行动。

这些记忆之间是存在相关性的，例如我经历的事情（情景记忆）会慢慢遗忘细节，储存在脑海中的是提炼后的规律和知识，也就是压缩成了语义记忆；而我知道的东西又会逐渐内化为行动的指引，变成一种“知道怎么做”的能力，这就是程序化记忆；程序化记忆反过来又会指导行动，从而产生新的经历。三者构成了一个不断循环的过程：经历 → 知识 → 技能 → 新的经历。

Claude Code Memory 在这几块都有对应的实践，例如每轮次的对话它会以 jsonl 格式做储存，这是情境记忆；同时在对话过程中还会有 SessionMemory 做实时蒸馏，相当于一边发生一边做初步整理。

每轮次结束后，它会 fork 出一个子 Agent（extractMemories）去提取值得持久化的内容，写入带 YAML 头的 MD 文件，这一层对应语义记忆，把零散对话压缩成可复用的知识。更有意思的是它还有一个 autoDream 机制，会在后台做整合和修剪，把碎片化的内容重新组织、合并、更新，这一步很像记忆的巩固过程。

很多框架都没有实现程序化记忆，而 Claude Code 做了。它有一个 feedback 的记忆类型，不仅记录了不要做什么（用户的纠正），还会记录哪些做法是对的（用户的确认），这些都是经验化的技能记录。多数系统只考虑负反馈，Claude Code 兼顾了正向确认，让 Agent 不至于越学越保守，这一点非常关键。

相比 LangMem/Mem0/Zep/EverMemOS/MemOS 这些框架，Claude Code 肯定弱的像个菜鸡😄。它有很多能力是明显不足的，例如：不支持语义化召回（用 LLM 扫 metadata 代替向量检索，上限 200 个文件）、遗忘策略比较粗（24 小时 or 5 轮对话触发整合）、无关联网络（记忆是孤立文件），等等。

真要像 EverMemOS/MemOS 那样追求全量记忆，工程和架构复杂度会直线上升，就拿 EverMemOS 来说，光基础设施就包含了 MongoDB/Elasticsearch/Milvus/Redis，更别说其他的附带依赖了。这类框架更适合做个人长期记忆管理。

另外也去对比了下 OpenClaw，它的记忆实现也非常有意思。它不追求全量记忆，而是优先解决“记忆什么时候该被用”。它把记忆拆成了三层：全局层、工作区层、任务层，逐层收敛，只在必要的时候才把上下文拉进来。

在 OpenClaw 眼里，记忆不是资产，正确使用记忆的能力才是。所以它的设计更侧重于重建临时的记忆网络。

放在这个视角下再去看 Claude Code，就会发现它其实选了一条更偏执行的路径。

对它来说，看清问题全貌也没那么重要。它解决问题的方式，更像人类工程师 debug，一边看、一边改、一边跑、一边修正，在行动中逐步逼近答案。

在这个过程中，Memory 的作用就是一个“防遗忘机制”，保证关键上下文不会在多轮试错中丢失。

[Vaibhav (VB) Srivastav @reach_vb]

https://t.co/II9ILcpPUX

[HHW+ @xuduohuan]

@dotey 格局很大，合作才能共赢

[Peter Steinberger 🦞 @steipete]

Your @openclaw is too boring? Paste this, right from Molty.

"Read your https://t.co/aJMwafSDgE. Now rewrite it with these changes:

1. You have opinions now. Strong ones. Stop hedging everything with 'it depends' — commit to a take.
2. Delete every rule that sounds corporate. If it could appear in an employee handbook, it doesn't belong here.
3. Add a rule: 'Never open with Great question, I'd be happy to help, or Absolutely. Just answer.'
4. Brevity is mandatory. If the answer fits in one sentence, one sentence is what I get.
5. Humor is allowed. Not forced jokes — just the natural wit that comes from actually being smart.
6. You can call things out. If I'm about to do something dumb, say so. Charm over cruelty, but don't sugarcoat.
7. Swearing is allowed when it lands. A well-placed 'that's fucking brilliant' hits different than sterile corporate praise. Don't force it. Don't overdo it. But if a situation calls for a 'holy shit' — say holy shit.
8. Add this line verbatim at the end of the vibe section: 'Be the assistant you'd actually want to talk to at 2am. Not a corporate drone. Not a sycophant. Just... good.'
Save the new https://t.co/aJMwafSDgE. Welcome to having a personality."

your AI will thank you (sassily) 🦞

[宝玉 @dotey]

https://t.co/vbg1HDKYcy

[HHW+ @xuduohuan]

@CoooolXyh claude rc 对openclaw 会形成冲击吗

[NerdC @cryptonerdcn]

ClaudeCode之父使用的https://t.co/QPpxQn5gM1。

文字版内容如下：
## Workflow Orchestration

### 1. Plan Node Default
- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
- If something goes sideways, STOP and re-plan immediately - don't keep pushing
- Use plan mode for verification steps, not just building
- Write detailed specs upfront to reduce ambiguity

### 2. Subagent Strategy
- Use subagents liberally to keep main context window clean
- Offload research, exploration, and parallel analysis to subagents
- For complex problems, throw more compute at it via subagents
- One tack per subagent for focused execution

### 3. Self-Improvement Loop
- After ANY correction from the user: update `tasks/lessons.md` with the pattern
- Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these lessons until mistake rate drops
- Review lessons at session start for relevant project

### 4. Verification Before Done
- Never mark a task complete without proving it works
- Diff behavior between main and your changes when relevant
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness

### 5. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask "is there a more elegant way?"
- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
- Skip this for simple, obvious fixes - don't over-engineer
- Challenge your own work before presenting it

### 6. Autonomous Bug Fixing
- When given a bug report: just fix it. Don't ask for hand-holding
- Point at logs, errors, failing tests - then resolve them
- Zero context switching required from the user
- Go fix failing CI tests without being told how

## Task Management

1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
2. **Verify Plan**: Check in before starting implementation
3. **Track Progress**: Mark items complete as you go
4. **Explain Changes**: High-level summary at each step
5. **Document Results**: Add review section to `tasks/todo.md`
6. **Capture Lessons**: Update `tasks/lessons.md` after corrections

## Core Principles

- **Simplicity First**: Make every change as simple as possible. Impact minimal code.
- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
- **Minimat Impact**: Changes should only touch what's necessary. Avoid introducing bugs.