在我现在的工作范围里，我最讨厌的事情就是用QuickBI搭建数据看板，虽然它功能很强大，但是配置一个大型看板最少要1个小时的时间，这还不算看板美化的时间。

Codex的compute use功能，可以直接操作浏览器，帮我完成这部分工作。目前遇到的问题就是，经常出异常问题，而且巨慢。

但这丝毫不动摇我要让Codex帮我搭建看板的决心。Codex笨，我会花时间改进。Codex慢，再慢我也不会自己在上手搭看板了。

有点明白为什么 AI 总爱说：
是...不是...
做...不做...
明确不是的，不做的，AI 才不会走偏。
人何尝不是如此，想想段永平的 stop doing list。

最近看了一篇关于携程的文章，里面有几个商业逻辑挺值得琢磨。

一、引流入口和利润来源，往往不是同一个东西。

携程的机票和火车票业务，本身几乎不赚钱，却是一站式旅行服务的重要入口。因为票务佣金太薄，所以用户在买票时，会不断遇到保险、贵宾休息室、快速安检等增值服务。

真正给携程贡献利润的，主要是酒店。酒店业务能直接赚钱，反而不需要如此用力地搭售。

这也提醒消费者：平台设计的每一个流程、默认选项和增值服务，背后通常都有明确的盈利逻辑。理解平台靠什么赚钱，至少能让自己在消费时多留意一些，避免在复杂页面里被默认勾选。

二、一门生意想获得稳定利润，产品和流量至少要占住一头。

酒店行业的一个问题是，同一区域、同一价位的产品往往高度同质化。当供给越来越多、消费者增长又跟不上时，单个酒店很难掌握定价权，只能依赖掌握流量入口的平台。

粗略来看，一门生意可以先拆成两部分：

一边是产品、服务和品牌；
另一边是渠道、流量和用户关系。

至少有一边足够强，生意才能站得住。

比如火车站里的店，最大的优势就是流量稳定，产品不需要特别突出；而一家产品足够好的餐厅，可以依靠口碑和消费者心智获得自然客流，不一定需要长期在平台上打折。

最危险的情况，是产品没有差异，流量又完全依靠付费购买。平台一旦提高价格，或者投放转化下降，利润就会迅速消失。

产品方虽然很难天然成为流量入口，但足够好的产品可以占据消费者心智。当消费者产生需求时，能够绕过平台直接想到某个品牌，产品优势也就逐渐转化成了流量能力。

三、真正有效的会员体系，必须让用户感受到“不一样”。

华住、亚朵等酒店会员体系之所以有价值，是因为用户能够明确感受到会员身份带来的不同：房型升级、延迟退房、积分、等级和专属服务。

一个有效的会员体系，不能只是偶尔发一张优惠券。它至少需要包含三种东西：

实际可感知的权益；
可以长期积累的进度；
能够形成身份认同的标志。

很多互联网会员的问题，是只有折扣，没有身份；只有积分，没有记忆；只有平台想留住用户，却没有给用户一个主动留下来的理由。

无论是实体产品还是互联网服务，把原本无形的价值变成用户能够看见、积累、展示和复用的东西，可能都是建立长期关系的重要方式。

四、供给越同质化，平台就越容易赚钱。

携程利润增长的另一个重要来源，是酒店商家为了获得流量而支付的广告费。

这几年，很多人在就业压力之下选择加盟、开店或者经营小生意。但当产品没有竞争力、自己又没有稳定流量时，就只能不断向平台付费购买曝光。

如果产品的转化能力不足，广告并不会自动带来利润，反而可能出现越投越亏的情况。

所以，做生意之前不能只问“能不能把店开起来”，还需要问：

自己到底掌握了什么？
是更好的产品，还是稳定的流量？
消费者为什么会选择自己，而不是旁边那家？
一旦停止投放，生意还能不能继续运转？

如果产品和流量两边都没有优势，加盟费、房租和平台广告，可能只是买来一种“自己正在做生意”的感觉。

这篇文章让我觉得，判断一门生意时，可以先问几个简单的问题：

它真正的利润来源是什么？
什么业务只是引流入口？
产品有没有不可替代性？
流量掌握在自己手里，还是需要不断向平台租用？
用户为什么会绕过平台，直接想到这个品牌？

很多生意表面上卖的是产品，实际上争夺的是流量；很多平台表面上提供交易服务，真正掌握的是需求分配权。

北京最近的晚霞真是绝了

自打 AI 越来越强了以后，知识付费这个赛道就基本上只剩下怎么用 AI 的知识，这一个细分领域了

我最近开始用智谱的 GLM 5.2之后，就把 Cloud Code 升级到了最新版。

升级到最新版以后，我发现如果用 GLM，实际上它还是不会触发自动压缩上下文的功能。

因为我最近也在并行使用 Claude Sonnet，在 Claude 里同时用这两个模型时，对比非常明显：
1. Claude Sonnet：右下角会有一个“Auto Compact”的提示，显示还有多少额度会自动压缩。
2. 其他模型（比如 GLM）：右下角只会直接提示“... Left”，显示剩余的 Context 额度和百分比，这种情况下就只能自己手动去触发压缩。

之前我也琢磨过，这种感觉就跟手动挡和自动挡的车似的。用手动挡（手动压缩）时，你得稍微留心一下，去考虑在工作任务和对话轮次的哪个节点开始压缩，才能让模型处于最佳状态。

这其实是个取舍问题。你可能会问，为啥不直接一直用 Claude 模型，不就万事大吉了吗？

我大概出于两个考虑：
1. 公司的 Token 虽然是免费给员工用，而且现在基本上不限量，但我担心的是，如果我只习惯在这些国际大模型上把事情搞定，那未来万一公司不提供 Token 了，或者我不在公司了，我自己用 AI 做事情的时候该怎么办？我必须得有一个在国内可以稳妥使用的模型作为后备。
2. 确实如我之前所说，GLM 已经比较符合我的工作流习惯，和我的工作流契合得挺好了，所以我才一直在坚持使用。

最近零散的想法挺多的，想到哪儿就记到哪儿吧。

今天在 Claude Code 里使用 plan mode，比之前用 plan mode 的产出好多了。以前是用不用 plan mode 结果都差不多，现在是它先用子 agent 去知识库先收集信息，再做计划，少量对我提问后，开始产出结果。最终调个一两版就完成了。
思考了一下原因应该是自己沉淀了足够多的知识库内容，以及不断精炼的 AI rules，每次出现问题增加的 hooks，迭代了十几版的 skill。

因为用的是 token plan 或者是公司的 token，对 token 的 ROI （投资回报率）毫不敏感。

这个毛病必须改掉。

要不以后花自己的 token 的时候，要么做不出来任何东西（token plan 被卡 5 小时用量），要么做出来东西亏钱（生成的内容比 token 还要贵，或是别人用起来成本高，时长上无竞争力）。

起因是自己正在看《Claude Code 实战》，读到其中 skill 的 description 预算机制时被点醒了。

我自己的 skill 都是 Claude Code 自己写的，实际上我不太关心它写的怎么样，我更在乎结果。

但是实际上每个 skill 中有多少无效的字符，我其实没有看过。

这么看下来，实际上有两个方向上现在做的不够好。
一个是不做约束，不断地在创作的过程中，或者是使用的过程中，额外消耗 token。
另外一种就约束过死，明确的告诉他要做什么，纯粹从一个创造工具沦陷为一个执行工具。

我现在有点理解为什么每一个高频的细分场景最好都有一个 Agent 了。

因为这种 Agent 可以用 Hooks（钩子）去做更强的校验。但如果不分场景只用一个 Agent 的话，逻辑就没法写进钩子里，只能存到 Memory（记忆）里。

而 Memory 实际上又不是每次都能强行召回的，就有可能会出现一些偏差。

自从换了 GLM-5.2 之后，重新把 Claude Code 更新到最新版本。

之前的问题是，使用 5.1 的时候，始终无法启动自动压缩，直到 API 报错，说 context 超过模型限制。

我以为我换了 5.2 以后，这个问题就会解决，不知道哪里来的自信升到了 2.1.19x。
用着用着发现，context 到了 100%之后还是不会自动压缩，但是也没有出现 API 因 context 爆了返回错误的情况。

我战战兢兢提问：
为什么没有自动压缩？

这个是 Claude Code 的 harness 决定的。

那我要不要压缩？
建议你一会儿压缩，否则我们本轮对话会丢失很多东西。

我觉得有道理，以前经常它跑着跑着就自动压缩了，虽然说不上结果偏差，但也觉得节奏不好。

我觉得我应该好好看看 Claude Code 的文档，看看后续版本的 harness 到底是怎么设计的。