即刻App年轻人的同好社区
下载
🎉 我的开源项目突破 500stars 啦
年初的时候，我想要研究 Claude Code 的上下文工程，自己开发了一个小工具捕获 Claude Code 的请求，生成一个清晰的 HTML 文件。
后来同事觉得有用，就把它开源到 Github，上个月有自媒体博主发现我的项目，联系我说想在他的教学视频中使用我的项目，之后项目的 Star 数量就开始增长。
这段时间不断有用户提 Issue 和 PR，claude-tap 现在支持了大多数本地 Coding Agent，例如 Claude Code、Codex、Kimi Cli、Qoder、OpenCode、Pi，也支持 OpenClaw、Hermas 这类工具。
如果你对 Coding Agent 底层怎么运行、上下文工程，包括系统提示词、工具、消息怎么设计，欢迎使用 claude-tap
链接：github.com
欢迎 Issue 和 PR，如果对你有用的话，求点一个 Star，谢谢❤️
年初的时候，我想要研究 Claude Code 的上下文工程，自己开发了一个小工具捕获 Claude Code 的请求，生成一个清晰的 HTML 文件。
后来同事觉得有用，就把它开源到 Github，上个月有自媒体博主发现我的项目，联系我说想在他的教学视频中使用我的项目，之后项目的 Star 数量就开始增长。
这段时间不断有用户提 Issue 和 PR，claude-tap 现在支持了大多数本地 Coding Agent，例如 Claude Code、Codex、Kimi Cli、Qoder、OpenCode、Pi，也支持 OpenClaw、Hermas 这类工具。
如果你对 Coding Agent 底层怎么运行、上下文工程，包括系统提示词、工具、消息怎么设计，欢迎使用 claude-tap
链接：github.com
欢迎 Issue 和 PR，如果对你有用的话，求点一个 Star，谢谢❤️
4 00
🎉claude-tap Stars 数量超过 400 啦
同步一下 claude-tap 的更新，有很多用户反馈自己使用的不是Claude code或者Codex，希望能支持其他Coding Agent，现在 claude-tap 支持更多 Coding Agent CLI 了：
Claude Code / Codex CLI / Gemini CLI / Cursor CLI / OpenCode / Kimi / Pi / Hermes
claude-tap可以捕获这个客户端的 API 请求，转存到本地一个好看的 HTML 文件里，方便你学习 Coding Agent 的上下文工程
github.com
如果你觉得有用的话，欢迎 Star，也欢迎提 Issue 和 PR，我会及时处理
同步一下 claude-tap 的更新，有很多用户反馈自己使用的不是Claude code或者Codex，希望能支持其他Coding Agent，现在 claude-tap 支持更多 Coding Agent CLI 了：
Claude Code / Codex CLI / Gemini CLI / Cursor CLI / OpenCode / Kimi / Pi / Hermes
claude-tap可以捕获这个客户端的 API 请求，转存到本地一个好看的 HTML 文件里，方便你学习 Coding Agent 的上下文工程
github.com
如果你觉得有用的话，欢迎 Star，也欢迎提 Issue 和 PR，我会及时处理
2 02
#豆包输入法
今天看到豆包发布了豆包输入法 Mac 版本，体验了一下感觉还不错，所以就想把手机上的输入法也换成豆包输入法
Onboarding 的时候被小小的惊艳到了，豆包在跳转设置设置页授权的时候，唤起了一个视频浮窗。这个视频是固定画面，教你点击哪几个按钮开启授权
它利用 iOS 的小 trick，解决了用户授权跳转到设置页后不知道点击哪里的问题
今天看到豆包发布了豆包输入法 Mac 版本，体验了一下感觉还不错，所以就想把手机上的输入法也换成豆包输入法
Onboarding 的时候被小小的惊艳到了，豆包在跳转设置设置页授权的时候，唤起了一个视频浮窗。这个视频是固定画面，教你点击哪几个按钮开启授权
它利用 iOS 的小 trick，解决了用户授权跳转到设置页后不知道点击哪里的问题
4 20
分享读了几篇 LLM 复盘报告的感受
最近 Anthropic、OpenAI、智谱都发布了一篇各自线上问题的复盘 blog，分别是：
- Claude Code 近期质量下降的复盘
- GPT 模型莫名其妙输出“哥布林”的复盘
- 智谱 GLM-5 输出乱码、复读、生僻字的复盘
联想到去年 Anthropic 和 OpenAI 也有过类似用户侧体验降级的复盘，趁着假期，今天把几篇博客整体拿出来一起学习了一下，看看有没有共性，以及对 Agent 开发者有哪些启发。
异常的表现：
用户侧感受到的“模型表现下降”，其实不只有一种形式。
- 有些表现得像能力下降，比如 Claude Code 更容易遗忘上下文、推理接不上
- 有些是风格和人格的问题，比如 GPT-4o 某个版本变得过度谄媚，太容易顺着用户说
- 有些是表达习惯异常，比如 GPT 系列模型突然更容易输出“哥布林”这类很突兀的词
- 还有一些是更明显的输出异常，比如智谱 GLM-5 在复杂 Coding Agent 任务里出现乱码、复读、生僻字
这些问题不像传统软件 bug 那样明显，也不一定容易发现和复现；它们不一定会直接体现在 benchmark 榜单上，但真实用户在连续使用过程中会冷不丁感受到模型表现不如预期。
问题的原因：
不同于传统软件，大模型和 Agent 产品表现不如预期，可能是系统中任何一个环节出问题导致的。从下到上，可能是模型问题、推理引擎层问题，也可能是 Agent 产品 harness 问题。
- 模型问题：去年 GPT-4o 某个版本表现得过于谄媚、今年 GPT 模型输出“哥布林”概率升高，都属于模型层的问题。再往底层追溯，可以反映为训练数据质量问题，以及训练时的奖励信号问题。更谄媚的表现和“哥布林”输出，在训练过程中更容易被奖励模型判定为好的输出，最终结果就是训练出来的模型不符合预期。
- 推理引擎问题：去年 Claude 有一段时间降智明显，当时 Anthropic 官方多次表态不会因为成本或者负载因素主动降低服务质量，最终排查出来是推理链路中的底层问题。
智谱的博客里也提到了类似的问题：GLM-5 在标准推理环境下表现正常，但在高并发、长上下文的 Coding Agent 场景下，会偶发乱码、复读、生僻字。最后定位到的不是模型本身，而是大规模推理系统里的状态管理和缓存一致性问题。
- Agent 产品 harness 问题：Claude Code 在某个版本降低默认的思考等级，本意是希望平衡智能水平和响应延迟，最终导致输出质量降低；某些 bug 导致推理历史被错误清理，后续轮次接不上前面的思考，表现出来就是用户感觉 Claude Code 更容易遗忘；还有一段为了防止模型输出太冗长的系统提示词，也导致了编码质量下降。
漏放的原因：
还有一个比较深的感受就是，即使 LLM 公司内部已经有不少发布前准出机制，仍然会有一些导致用户负反馈的 bug 或变更漏到线上。一些谄媚的表达无法通过量化指标来识别、大规模推理时才会概率性出现的 bug 无法简单在内部环境下复现。
这说明模型的评测和准出机制仍然有覆盖不到的方面。包括后置的用户反馈通道，以及用户反馈的复现、定位和修复工具链，也需要更多提升。
对 Agent 产品开发者的启示：
- Agent 产品交付的是端到端体验。
模型本身的能力和品性很重要，但 Agent harness 如何让模型在具体产品场景里稳定发挥，同样重要。开发者首先要定义清楚自己希望产品表现出什么能力、边界和风格，再结合对模型的手感，通过评测、消融实验、上下文组织、工具设计和默认配置，调配出一个合适的 Agent 环境。这个过程本身就是 Agent 开发者的差异化价值。
- 用户反馈和内部指标都重要，互相校准。
用户反馈更贴近真实体验，很多“模型变差了”“有点怪”“不如以前好用”的问题，往往是用户先感知到；但用户反馈也会比较稀疏、有噪音，并且样本有偏。内部指标更稳定、覆盖面更广，也更适合做版本对比和持续监控，但它不一定能完整代表真实用户体验。所以更好的方式不是二选一，而是把用户反馈当成问题发现信号，再把高质量反馈沉淀成内部评测、回归用例和上线准出标准。
- 建立更短的用户反馈到问题修复闭环。
用户说“产品变笨了”通常是一个模糊症状，不能直接复现。在保证用户隐私的前提下，Agent 产品尽可能保留必要的调试信息，结合用户反馈形成可分析的 bad case，引入 Coding Agent 直接进行问题复现、原因分析、代码修复、评测准出流程，让整个过程的链路更短，更少人工介入。
相关链接：
- Anthropic：An update on recent Claude Code quality reports, anthropic.com
- OpenAI：Where the goblins came from, openai.com
- 智谱：Scaling Pain：超大规模 Coding Agent 推理实践, zhipuai.cn
- Anthropic：A postmortem of three recent issues, anthropic.com
- OpenAI：Sycophancy in GPT-4o, openai.com
- OpenAI：Expanding on what we missed with sycophancy, openai.com
最近 Anthropic、OpenAI、智谱都发布了一篇各自线上问题的复盘 blog，分别是：
- Claude Code 近期质量下降的复盘
- GPT 模型莫名其妙输出“哥布林”的复盘
- 智谱 GLM-5 输出乱码、复读、生僻字的复盘
联想到去年 Anthropic 和 OpenAI 也有过类似用户侧体验降级的复盘，趁着假期，今天把几篇博客整体拿出来一起学习了一下，看看有没有共性，以及对 Agent 开发者有哪些启发。
异常的表现：
用户侧感受到的“模型表现下降”，其实不只有一种形式。
- 有些表现得像能力下降，比如 Claude Code 更容易遗忘上下文、推理接不上
- 有些是风格和人格的问题，比如 GPT-4o 某个版本变得过度谄媚，太容易顺着用户说
- 有些是表达习惯异常，比如 GPT 系列模型突然更容易输出“哥布林”这类很突兀的词
- 还有一些是更明显的输出异常，比如智谱 GLM-5 在复杂 Coding Agent 任务里出现乱码、复读、生僻字
这些问题不像传统软件 bug 那样明显，也不一定容易发现和复现；它们不一定会直接体现在 benchmark 榜单上，但真实用户在连续使用过程中会冷不丁感受到模型表现不如预期。
问题的原因：
不同于传统软件，大模型和 Agent 产品表现不如预期，可能是系统中任何一个环节出问题导致的。从下到上，可能是模型问题、推理引擎层问题，也可能是 Agent 产品 harness 问题。
- 模型问题：去年 GPT-4o 某个版本表现得过于谄媚、今年 GPT 模型输出“哥布林”概率升高，都属于模型层的问题。再往底层追溯，可以反映为训练数据质量问题，以及训练时的奖励信号问题。更谄媚的表现和“哥布林”输出，在训练过程中更容易被奖励模型判定为好的输出，最终结果就是训练出来的模型不符合预期。
- 推理引擎问题：去年 Claude 有一段时间降智明显，当时 Anthropic 官方多次表态不会因为成本或者负载因素主动降低服务质量，最终排查出来是推理链路中的底层问题。
智谱的博客里也提到了类似的问题：GLM-5 在标准推理环境下表现正常，但在高并发、长上下文的 Coding Agent 场景下，会偶发乱码、复读、生僻字。最后定位到的不是模型本身，而是大规模推理系统里的状态管理和缓存一致性问题。
- Agent 产品 harness 问题：Claude Code 在某个版本降低默认的思考等级，本意是希望平衡智能水平和响应延迟，最终导致输出质量降低；某些 bug 导致推理历史被错误清理，后续轮次接不上前面的思考，表现出来就是用户感觉 Claude Code 更容易遗忘；还有一段为了防止模型输出太冗长的系统提示词，也导致了编码质量下降。
漏放的原因：
还有一个比较深的感受就是，即使 LLM 公司内部已经有不少发布前准出机制，仍然会有一些导致用户负反馈的 bug 或变更漏到线上。一些谄媚的表达无法通过量化指标来识别、大规模推理时才会概率性出现的 bug 无法简单在内部环境下复现。
这说明模型的评测和准出机制仍然有覆盖不到的方面。包括后置的用户反馈通道，以及用户反馈的复现、定位和修复工具链，也需要更多提升。
对 Agent 产品开发者的启示：
- Agent 产品交付的是端到端体验。
模型本身的能力和品性很重要，但 Agent harness 如何让模型在具体产品场景里稳定发挥，同样重要。开发者首先要定义清楚自己希望产品表现出什么能力、边界和风格，再结合对模型的手感，通过评测、消融实验、上下文组织、工具设计和默认配置，调配出一个合适的 Agent 环境。这个过程本身就是 Agent 开发者的差异化价值。
- 用户反馈和内部指标都重要，互相校准。
用户反馈更贴近真实体验，很多“模型变差了”“有点怪”“不如以前好用”的问题，往往是用户先感知到；但用户反馈也会比较稀疏、有噪音，并且样本有偏。内部指标更稳定、覆盖面更广，也更适合做版本对比和持续监控，但它不一定能完整代表真实用户体验。所以更好的方式不是二选一，而是把用户反馈当成问题发现信号，再把高质量反馈沉淀成内部评测、回归用例和上线准出标准。
- 建立更短的用户反馈到问题修复闭环。
用户说“产品变笨了”通常是一个模糊症状，不能直接复现。在保证用户隐私的前提下，Agent 产品尽可能保留必要的调试信息，结合用户反馈形成可分析的 bad case，引入 Coding Agent 直接进行问题复现、原因分析、代码修复、评测准出流程，让整个过程的链路更短，更少人工介入。
相关链接：
- Anthropic：An update on recent Claude Code quality reports, anthropic.com
- OpenAI：Where the goblins came from, openai.com
- 智谱：Scaling Pain：超大规模 Coding Agent 推理实践, zhipuai.cn
- Anthropic：A postmortem of three recent issues, anthropic.com
- OpenAI：Sycophancy in GPT-4o, openai.com
- OpenAI：Expanding on what we missed with sycophancy, openai.com
13 05
我的主业是做 Agent 开发，经常需要研究 Claude Code / Codex 的上下文工程，以前社区有一个 claude-trace 不适配最新的 Claude Code，所以我重新做了一个
claude-tap 能把 Claude Code / Codex 的真实请求抓出来，生成一个本地 HTML trace viewer，方便研究学习
它有以下特点：
- 同时支持 Claude Code 和 Codex
- 可以查看所有的 LLM Call 的细节，并使用 HTML 渲染出好看的页面
- 连续的请求之间可以进行对比，方便查看新引入的差异
- 所有数据都存在本地
欢迎试用 / issue / star：
github.com
claude-tap 能把 Claude Code / Codex 的真实请求抓出来，生成一个本地 HTML trace viewer，方便研究学习
它有以下特点：
- 同时支持 Claude Code 和 Codex
- 可以查看所有的 LLM Call 的细节，并使用 HTML 渲染出好看的页面
- 连续的请求之间可以进行对比，方便查看新引入的差异
- 所有数据都存在本地
欢迎试用 / issue / star：
github.com
9 06
聊聊 Kimi Code 的体验
这周不小心把 CodeX 周套餐用满了，又因为上周 Claude 被封了号，一下子没有任何 Coding Agent 可以用。 我付费试了下 Kimi Code，用了一周末，聊聊体验。
先说优点：
1. Kimi Code 的 TUI 展示逻辑很好，比 Claude Code 和 CodeX 更清晰。 它有独立的 input 输入框，整体的对话输出和工具调用过程也更直观，很容易看懂 Agent 在做什么。
2. 另一个让我比较惊喜的是会渲染 Markdown table。 在我现在的开发工作流中，我会并发打开多个 Coding Agent，我不关心每个 Agent 在写什么代码， 更关注测试是否充分（尤其是端到端的冒烟测试）。
Kimi Code 会在完成任务后，把测试结果清晰地用 tavle 渲染出来， 表格形式比普通的 bullet points 更直观，用 Codex 我经常看不懂它做了哪些测试，遇到什么问题。
再说说缺点：
我觉得 Kimi k2.6 距离一线的国外闭源产品（例如 Claude Opus 4.6、4.7，GPT 5.5）还是有差距。
昨天遇到一个比较严重的 Bug： 我让它补充线上的环境变量，结果把原有变量全部删除了，只保留新补充的， 这直接导致线上不可用。
还好我有做端到端测试，很快发现问题后让它修复了。
总的来说，瑕不掩瑜。
我会继续使用 Kimi Code，但主力还是 CodeX。 一些小需求，或者 CodeX 用量用满的时候，会用它作为补充。
这周不小心把 CodeX 周套餐用满了，又因为上周 Claude 被封了号，一下子没有任何 Coding Agent 可以用。 我付费试了下 Kimi Code，用了一周末，聊聊体验。
先说优点：
1. Kimi Code 的 TUI 展示逻辑很好，比 Claude Code 和 CodeX 更清晰。 它有独立的 input 输入框，整体的对话输出和工具调用过程也更直观，很容易看懂 Agent 在做什么。
2. 另一个让我比较惊喜的是会渲染 Markdown table。 在我现在的开发工作流中，我会并发打开多个 Coding Agent，我不关心每个 Agent 在写什么代码， 更关注测试是否充分（尤其是端到端的冒烟测试）。
Kimi Code 会在完成任务后，把测试结果清晰地用 tavle 渲染出来， 表格形式比普通的 bullet points 更直观，用 Codex 我经常看不懂它做了哪些测试，遇到什么问题。
再说说缺点：
我觉得 Kimi k2.6 距离一线的国外闭源产品（例如 Claude Opus 4.6、4.7，GPT 5.5）还是有差距。
昨天遇到一个比较严重的 Bug： 我让它补充线上的环境变量，结果把原有变量全部删除了，只保留新补充的， 这直接导致线上不可用。
还好我有做端到端测试，很快发现问题后让它修复了。
总的来说，瑕不掩瑜。
我会继续使用 Kimi Code，但主力还是 CodeX。 一些小需求，或者 CodeX 用量用满的时候，会用它作为补充。
1 01
最近我开始越来越多地用 Typeless 做语音输入。
一开始主要是在 Vibe Coding 时用，后来慢慢延伸到手机上，甚至在微信里跟人聊天时也开始用了。然后我发现一个很微妙的问题：
语音输入降低了我的表达成本，但不一定降低对方的理解成本。
原因很简单。
手动打字的时候，我们会天然地压缩信息。
因为每敲一个字都有成本，所以会更斟字酌句，想清楚再发。最后写出来的内容通常更短，但信息密度更高。
但语音输入不一样。它太顺了。一旦输入成本足够低，人就会更倾向于“把脑子里正在想的东西直接流出来”，而不是先压缩、再表达。
结果就是发的人更轻松了，读的人要消费更多信息，反而更累了。
但有意思的是，如果接收者不是人，而是 Agent，情况几乎完全反过来。
对 Agent 来说，语音输入反而更有价值。
因为它拿到的不只是结论，而是更多原始上下文、犹豫、跳跃、补充和细节。那些对人类读者来说有点冗余的东西，对 Agent 往往都是有用的 context。
所以我最近越来越强烈地感觉到：
未来我们可能需要区分“写给人”的语言，和“写给 Agent”的语言。
对人，最好还是压缩、编辑、提炼。
对 Agent，反而可以更完整、更流式、更少修饰地输入。
Typeless 让我们的表达方式从“人类友好型”转变成了“模型友好型”。
一开始主要是在 Vibe Coding 时用，后来慢慢延伸到手机上，甚至在微信里跟人聊天时也开始用了。然后我发现一个很微妙的问题：
语音输入降低了我的表达成本，但不一定降低对方的理解成本。
原因很简单。
手动打字的时候，我们会天然地压缩信息。
因为每敲一个字都有成本，所以会更斟字酌句，想清楚再发。最后写出来的内容通常更短，但信息密度更高。
但语音输入不一样。它太顺了。一旦输入成本足够低，人就会更倾向于“把脑子里正在想的东西直接流出来”，而不是先压缩、再表达。
结果就是发的人更轻松了，读的人要消费更多信息，反而更累了。
但有意思的是，如果接收者不是人，而是 Agent，情况几乎完全反过来。
对 Agent 来说，语音输入反而更有价值。
因为它拿到的不只是结论，而是更多原始上下文、犹豫、跳跃、补充和细节。那些对人类读者来说有点冗余的东西，对 Agent 往往都是有用的 context。
所以我最近越来越强烈地感觉到：
未来我们可能需要区分“写给人”的语言，和“写给 Agent”的语言。
对人，最好还是压缩、编辑、提炼。
对 Agent，反而可以更完整、更流式、更少修饰地输入。
Typeless 让我们的表达方式从“人类友好型”转变成了“模型友好型”。
15 34
