Bestony | 白宦成的 RSS 预览

Claude Tag 产品分析

2026-09-10 22:04:08

Claude Tag 这个产品市面上的仿品很多，但我看到的绝大多数的产品仿品仿其型而未有仿其神。这背后是本身绝大多数仿品的团队都是 TO C 创业者出身，导致对于他们来说，并未看出背后的很多设计的原因。而作为一个真的干过 TO B 的产品经理，我觉得大家其实做的都还是 TO C 的产品，由于实在看不过眼（~~觉得在座的都是垃圾~~），我决定自己写一篇对于 Claude Tag 的拆解，方便大家参考和使用。

对于 Claude Tag 来说，其神在于：

访问按地方配，不按人配。 配置的单位是 scope——整个组织（Default Slack access）、一个 Workspace、一个 Channel——Access Bundle 挂在 scope 上，往下继承；一个 Channel 拿到的是它自己、它的 Workspace、组织三层 Bundle 的并集
记忆跟地方走，不跟人走。 Memory 只有两层：Public Channel 里产生的记忆在整个 Workspace 内共享，Private Channel 只读共享层、写自己那一份；
用组合来在不同地方配置 Agent。你可以通过组合 Access Bundle，在不同的位置，给 Agent 组合出各种用法的能力，从而让 Agent 真正解决问题。

如何开通 Claude Tag

花钱就行，50 刀起步；我花了 70 刀；50 刀是用来开 Claude Teams 权限；剩下 20 刀是 Claude Tag 日常消耗的（我觉得对于很多小公司来说，Claude Tag 的一大痛点可能在于成本太高，因为不是按照订阅算的 Token，而是按照真实的消耗算的 Token，那你可能真的得思考，我真的有必要上 Claude Tag 么？以及会考虑选择使用更便宜的 Sonnet 模型作为 Claude Tag 的主模型）。

Claude Tag 怎么使用

比较简单粗暴，当你完成 Claude Tag 连接之后，接下来直接 at Claude 做事就行；过程中可能会涉及到你要去做一些前置授权等。

但需要注意的是，目前 Claude Tag 的所有使用必须放在 Channel 中进行；私聊是无法使用 Claude Tag 的，它只能在 Channel 中使用，你需要把它放在任何一个 Channel 中使用；不过好在是，我测试了，其实你可以在 Private Channel 中使用 Claude Tag。所以你依然可以和他一起工作。只是 Private Channel 会在管理后台看不到 Channel Name

Claude Tag 产品原语

在看 Claude Tag 的细节功能上，我们需要先理解 Claude Tag 的产品原语，以便于我们对齐对于 Claude Tag 的理解，并且让你对于 Claude Tag 的产品理解有一个更加形象的认知，避免快速沉浸到产品的具体功能细节里。同时也更好的帮助理解不同功能的服务层级。

整个 Claude Tag 从产品原语上，你可以定义包括三个大类：Space（任务和行为发生在哪）、Capability（能执行和发生什么样的任务）、Control（如何控制这些任务的发生）。

Space 又可以进一步细分为 Organization、Workspace 和 Channel，后两者可以直接对应到 Slack 的相同概念（Claude Tag 如今还是和 Slack 有较深的绑定），且 Channel 是会话中的最小单元。和 Slack 一一对应可能是源自 Claude 团队自己在用，所以也就没做更多其他品类的兼容。Session 和 Routines 则是会发生在这些 Space 中的具体的会话；Session 是由人类触发的行为，而 Routines 则是由时间触发的行为。底部的 Environment 则是两个 Session 的运行环境；

Capability 则可以细分为四个子类：Repositories、Domains、Plugin、Credentials ； Repositories 可以提供让 Claude Tag 访问的权限，你可以同时链接多个不同 Github Org 的多个 Repo，从而让 Agent 可以在多个 Repo 中协作。Domains 则给 Claude Tag 了网络访问权限，通过 Domains 的配置，让 Claude 可以访问到目标的网站，从而获取到必要的信息，从而确保 Agent 的网络行为是可管控的，避免出现信息异常出网的情况。credentials 则提供了不同 SaaS 服务的链接能力，在完成授权后，Agent 会获取到对应的授权，以及一些预制好的 API 请求方式，从而你可以让 Claude Tag 在整个过程中，可以访问到一些外部的 SaaS，从而搞定所有的工作。Plugin 则是一个我们大家相对熟悉的概念，之前在 Claude Code 当中就有，Claude Tag 使用的 Plugin 基本上是一致的；不同的是 Claude Tag 不会执行其中的 Hook，但对于 Skill 和 MCP 都是完全支持的。

在 Capabilities 最下方，还有一个虚线的 Access Bundle；Access Bundle 是一个 Capabilities 的打包合集，其中包含了Repositories、Domains、Plugin、Credentials、Instructions。你可以在某个 Channel 中找到专属的配置，也可以直接添加一个 Access Bundle，来批量管理这些内容；从而，你可以非常快速的将一组预设好的 Access Bundle 给应用到某个特定的 Channel 上。从而快速完成不同 Channel 的配置。这里有一个特殊的是，Instruction 也是可以放在 Access Bundle 当中一起传递的；不过在产品的原语中，我将他放在了 Control 中。所以这里 Access Bundle 横跨了 Capabilities 和 Control。

在 Control 中，则汇聚了各种对于 Agent 的控制能力（aka：让 Agent 更好的做事），这里包括了我们刚刚提到的 Custom Instruction、Memory、Auto mode allow rules、Channel name rules、Channel name rulesd等一系列细节产品功能，这里比较重要的是 Custom Instruction 和 Memory。Custome Instrucion 会出现在 Org、Channel 级别的配置当中，对应的描述会出现在 Agent 的 System Prompt当中，引导 Agent 行为。Memory 则记录了你在和 Agent 之间的交互中产生的信息，支持频道级别的 Memory 和全局的 Memory ，从而可以实现一些很有意思的用法（比如 Claude Tag 宣发中的一个 Case: 不同用户在不同 Channel 中和 Claude 聊同一件事，Claude Tag 会主动告知另外一个用户所做的决策）。其他我们就不再专门讲述，稍后会按照具体的功能细节时再说。

当你了解了 Claude Tag 的产品原语、定位和他们之间的关系之后，我们就可以来看看他的一些底层设计机制和数据状态了，能帮你更好的理解后续的一些功能设计。

Claude Tag 的一些数据设计

对于整个 Claude Tag 来说，你可以认为数据大概是这个样子的。

所有的数据都归属于某个特定的组织；组织下可以拆分多个不同的 Workspace（就像你可以是 Openai + 对应的 FDE 组织）。图的上部
每个 Workspace 里可以有一整套独立的 Channel、Memory 等机制；图的中左部。
当你进入到每个 Workspace 之后，你会看到 Workspace 内部的 Memory（工作区级别的），然后里面可以有不同的 Channel 来进行日常的沟通和不同工作的分配。比如有的做 A，有的做 B；有的做 C；大家分布在不同的 Channel 里；图的中下部
每个 Channel 中有自己的 Channel Memory 、Custom Instruction、Access Bundle、Plugin、Credentials、Repository 等一系列 Agent 运行所需要的信息。用户可以根据自己的需要选择合适的内容。图的中右部。
Channel 内部，会同时出现多个 Session 或 Routine。且由于存在自定义 Environment 的能力，可能会出现部分运行在 Anthorpic 的 Runtime 里，部分运行在用户自建的 Runtime 里。

上面的这种数据组织方式，很好的满足企业对于数据的管理诉求：

Claude Tag 的一些产品设计细节

围绕这上述的产品原语、产品数据设计；和面向 To B 的产品设计，里面出现了大量很符合 To B 产品直觉的产品设计。

Claude Tag 是组织买给你的，所以组织、Workspace、Channel 当中，都要能够给你的 Channel 设定不同的 Custom Instruction，从而确保你在使用 Claude Tag 做应该做的事情。正常情况下时按照顺序一层层拼接。

一个公司可能会存在不同的部门和分公司；不同的产品团队也可能会使用不同的 Slack Workspace ，从而更好的做好权限管控。因此，要支持一个 Claude Tag 能连接多个 Slack workspace。

一个 Agent 想要完整的完成一系列工作，不是简单的 Prompt 、Skill 就能解决，依赖MCP、鉴权、Skill和一定的指引。如果一个 Agent 要被持续复用（比如做客服 Channel 用），那么提供一个打包的 Access Bundle 就是必要的。

由于每个 Channel 都不是从 Day 1 就开始思考 Access Bundle，和目前这种 Channel 中除了 Access Bundle 还能单独配置 Credentials（在单独Channels 里叫 Connector ）、Plugin 的能力，我猜测大概率他们是先有 Channel 级别的单独配置，后面共享多了，干脆提供了单独的 Acess Bundle。目前已经出现每个 Channel，很快可能就会去掉 Channel 级别的配置，直接改 Channel 上的默认的 Acess Bundle 就行。

在让 Agent 工作时，会涉及到一个 Agent 可能有多种职能，因此允许 Access Bundle 的叠加

由于在 Slack 的对话式交互中，进行权限审批是一个复杂和不好判断的事情，因此，设计了 Auto mode allow rules，允许用户根据需要，写一些简单的规则，来让 Agent 自己进行 Auto mode 下的判断。一方面相信 Agent 的能力；另一方面，也给了企业足够的控制权。对于 Claude 还不擅长的业务领域，提供了足够的逃生空间。

因为要把 Claude Tag 用在对外客服，因此支持 Claude Tag 被 Guest 访问；但对于不把 Claude Tag 用作客服场景的企业来说，可以直接关掉这个 Feature。

Claude Tag 似乎改了一次计费逻辑；在上个月我刚开通的时候，是你充值多少用多少；上个月两个任务花了我 $10 ；我赶紧把默认模型改成了 Sonnet 5 ；但今天写这个 Blog 的时候发现，似乎也变成了 Credit 的机制。如果是这样的话， Claude Tag 还蛮香的。

如果是将 Claude Tag 用在客服支持等场景，可能会出现某些特定规则的群名，这些群名可能是希望 Claude Tag 加入或者不加入的，所以这里还会有专门的 Channel Name Rule；有白名单有黑名单；白名单会自动加入；黑名单则是绝不加入。对于一些做客服的场景，完全可以把 Channel 名写成 [Channel Support]，然后等 Claude Tag 自己进去做支持。

Claude Tag 的 Memory

Memory 是如此的重要，以至于我认为我一定要专门开一章来写它。如果你要做仿品，只做一件事，那我认为就是做这个 Memory 体系。

Claude Tag 也为其产品设计了 Memory 的机制，

你可以看到，Claude Tag 的 Memory 是以树的形式来组织的：

你会先在 workspace 级别的 Memory 中，看到每个 Channel 中的 Memory ，但这里其实是各 Memory 的 Channel 的总结，更多是一个 Summary；而不是完整的 Memory；

而 Channel 级别的 Memory，你需要切换到 Channel 的选项中，查看详情。

在实际的使用时，memory.md 会作为索引，加载到 System prompt 中，Agent 根据需要，自己加载别的文件

且系统会根据相关性，通过对 Description 的二次判断，正式判断是否需要加载 Memory 当中的细节，并取前4K 放在 context 中，方便 Agent 进一步自己去读。

Claude 一个 Channel 中可以有多个 Session （每个 Threads 都是一个新的 Session），Claude Tag会在开始处理任务的时候加载 Memory，因此，如果某个 Threads 写入了 Memory，另外一个 Threads 大概率需要到下一次调用时才能加载到。

在写入 Memory 的时候，Claude Tag 是在本地以文件夹和文件的方式组织 Memory， Agent 在必要的时候，写入相关的 Memory，当然，你也可以自己主动和他说。

Claude 会把 Memory 写入到 Channel 和 Silo 文件夹；这两个文件夹的区别主要在于silo存储的是 workspace 级别的 Memory；而 Channel 存储的是本 Channel 自身的 Memory，这样就可以同时兼顾本 Channel 和全局的 Memory，从而确保 Agent 能及时获得必要的 Memory；同时，因为 Agent 可以同时看到两组 Memory，就可以有所取舍，将 memory 放在合适的位置。

===== 我在沙箱里看到的目录（文档未描述） =====
/tmp/claude/memory
`-- team
    |-- channel
    |   |-- .memory-sync
    |   |-- .memory-sync-basis
    |   |-- MEMORY.md
    |   |-- bestony-language-and-timezone.md
    |   |-- claude-tag-custom-instructions-layering.md
    |   |-- claude-tag-primitives-review.md
    |   `-- report-delivery-format.md
    `-- silo
        |-- .memory-sync
        |-- .memory-sync-basis
        `-- channel
            |-- C0BQB2J46D6
            |   |-- MEMORY.md
            |   `-- report-delivery-format.md
            `-- C0BQB5WPQD6
                |-- MEMORY.md
                `-- bestony-timezone.md
7 directories, 13 files

Claude Tag 的审计功能

作为一个 To B 的产品，审计功能是必须的。 Claude Tag 也提供了一些基础的审计能力，分三个大类：Scheduled Work、Memory 和 Network Event。

Scheduled Work 能够查看 Agent 的定时任务；不过也会发现 Agent 在执行任务的时候，也会把一次性任务当成 Scheduled Work 录入，从而导致展示在这里。

memory 则是整个 Org 级别 Memory 的展示，你可以根据需要查看和编辑某些 Memory。

Network Event 则是可以真的查询某个 Agent 对于网络的调用情况（还记得前面配置的 DOMAIN 么？）。

选择要查询的时间范围，就可以查询对应时间范围内的网络请求并分析。

Claude Tag 的 Custom Runtime

作为一个企业级产品，企业肯定会希望能够让运行行为发生在企业可控的网络环境，这样就可以充分利用企业内部的各项资源来完成这个目标。

Claude 支持创建一个 Self Hosted Environments ，来控制 Cloud Session 运行在哪个服务上

可以通过后台的配置，创建一个新的 Self Hosted Environment 来配置自己的 Runner，从而在企业内部使用的时候，就可以直接使用内网的设备来运行任务，执行各项内部基建。

再配合 Access Bundle 中的 Domains 的配置，可以开启对内网服务的访问权限。

辅以 Federated cloud access 链接到内部的 Gateway、授权服务，来实现整个内部的权限管控、安全控制，从而更好的服务企业，让企业更敢于使用 Claude Tag。

Claude Tag 的统计看板

Claude Tag 为用户提供了一个非常简单的统计看板

不过，最核心的 —— 哪个 Channel 最烧钱依然是有的

Access Bundle 的一些细节

Access Bundle 的 Credentials 除了已经提前集成好的服务，还可以加入自己自定义的 MCP 和 API Server

在使用 API & MCP 接入的时候，可以配置多种不同的授权方式，来满足绝大多数常见的业务场景，确保你能接入绝大多数业务。

Repositories 的的支持需要你将 Claude 的 App 安装到你的 Org 里，才能使用。

如果你有多个 repo ，也可以配置具体要用哪个 repo

我觉得比较好玩，但觉得很合理的设计包括：给用户一个 prompt，发给 github account owner 来做 link

在配置 Plugin 的时候，你可以选择多个 Plugin 放在同一个 Bundle 里，来方便使用和配合。还可以接入组织自己的 Organization，来方便使用组织内部特有的 Skill & MCP。

总结

这篇文章一边写一边截图，花费了将近 3 个小时，希望内容能帮到你，更好的思考 —— Claude Tag 到底给用户提供了什么。绝不是简单的将模型链接到 Slack 上；

背后的功能、实现，对于 TO B 功能的考究，都是很值得学习的。

都看到这了，我猜你肯定想试试看这类产品？那不妨试试我最近参与开发的一个开源项目 —— https://github.com/first-tree-ai/opentag 。我承认，我们还没做到很多这篇文章中提到的 Claude 的功能，但，在路上了，不是么？也欢迎你参考进来一起开发。

如何选择 DeepSeekHarnes / Claude Code/Codex/ Pi

2026-08-26 15:40:26

文章将 Agent 工具分为 Coding Agent 产品、Agent SDK 和 Agent Framework，建议先根据使用目的选择类别，再比较具体工具。Coding Agent 的选择取决于预算、模型偏好、自定义需求以及是否想尝试递归自进化。

Agent SDK 适合保留现有 Coding Agent 能力并接入自定义交互界面；Agent Framework 则用于自行定义 memory、工具和 Agent loop。作者认为 DeepSeek Harness 目标宏大、仍在发展，短期不作为主力工具，但其递归自进化方向值得持续关注。

最近会和一些朋友聊到关于不同的工具选型，我发现很多朋友对于不同的 Agent 开始有一些混淆的理解，为了帮助大家更好的选择不同的工具，我写了这篇文章，希望帮助到你做选择。

你要做什么？

大家虽然在聊 Agent，但可能聊的不是同一个 Agent；有的人需要一个开箱即用的 Agent；有的人需要一个能够丰富自定义的 Agent，方便发挥自己的想法；有的人需要感受“未来科技”；还有的人，只是要开发一个自己的 Agent。

这里面会存在不同的需求，对应需要的东西也有所不同；简单来说，你可以在这个表里找到答案

类型	目的	选择
Coding Agent 产品	我想用 AI 写代码	Codex Claude Code Pi OpenCode Grok Build ？DeepSeek Harness
Agent SDK	我想编程式调用 Coding Agent	Codex Agent SDK Claude Code Agent SDK OpenCode SDK Pi SDK
Agent Framework	我想定制一个自己的 Agent	pi ？deepseek-harness

这里面每个分类对应的是不同的人，首先，你需要先根据自己的目的，把自己分到对应的分组类型里，然后再在分组类型内部，找合适的配合。

Coding Agent 产品怎么选

Coding Agent 产品也会分不同的人和喜好：

如果你是拿来干活，且预算充足，那么官方的 Claude Code 和 Codex 一定是你最优解，使用最尖端的模型，帮你把事快速干完；如果你想要做一些配置，市场上基本上能看到你所需要的绝大多数教程，应有尽有。Grok Build 是上面二者的平替；如果你是 Twitter（现 X.com）的蓝 V 用户，那么 Grok 还送了你免费额度，也很不错。
如果你是拿来干活，但缺少预算，或者更倾向于使用国内的模型，那么 OpenCode 是一个不错的选择，也是一个成型的产品，拥有不错的 TUI 和交互；能够帮助你快速landing，教程的量级也不错，能够找到绝大多数的教程和说明。
如果你已经体验过了上面的两个 Coding Agent，但同时也有自己的想法，觉得他们太过冗余，或者是有太多你用不上的功能，那么极简，但带有插件机制的 Pi 是你的最优选择。相比于同样拥有插件机制的 dsh，pi 其实拥有更稳定的核心和插件生态，能够帮你快速先构建属于你自己风格的 Coding Agent。
如果你想试试 RSI（Recursive Self-Improvement，递归自进化），那么 DeepSeek Harness 就是一个不错的选择，你可以让 Agent 给自己写插件，一边开车，一边换轮子。

Agent SDK 产品怎么选

如果你想要使用现存的 Coding Agent，但又不喜欢它们所提供的交互界面，那么你可以考虑使用 Agent SDK，自己构建交互的界面。比如把 OpenCode 接入到你的飞书上，那么就要考虑使用 Agent SDK。它可以帮助你在保留原有 Agent Harness 设计的基础上，让你拥有可编程调用的能力，从而接入你自己实现的交互界面。

在这个部分，选择主要取决于你在用什么 Coding Agent 和其 Harness，选择其官方提供的 Agent SDK 即可；有的是通过 Http Server 调用，有的是通过进程调用，但总体来说，都帮你封装了底层 Harness 的复杂度，你主要围绕 Agent 和 Session 的概念去设计你的交互界面即可。

Agent Framework 怎么选？

到了 Agent Framework，基本上已经比较深了，你可能在定制一个自己的 Agent，比如我最近在定制一个翻译的 Agent，就是要自己去定义它的 memory、tool、agent loop 等不同的方案，这个时候我就需要 Agent Framework；

这个时候你可以选择自己手搓一个 Agentloop，或者也可以像我一样，直接引用 Pi 的 agent-core 和 pi-ai 来完成 agent 的开发。

deepseek harness 也是一个不错的选择，社区有插件来帮助你去实现功能。

我自己对于 DeepSeek Harness 的看法

我觉得 DeepSeek Harness（DSH）要解决的问题很宏大，这意味着不会很快；再加上当下 DSH 还是按照一个软件工程产品在开发，所以我短期不会把它用作主力的 Coding Agent；但递归自我改进（Recursive Self-Improvement，RSI）本身是有意思的，是值得关注的，所以 DSH 我会持续关注和尝试，作为一个观测对象来学习。

什么时候卖出？

2026-08-25 09:49:17

作者回顾了从基金到股票、再回到基金的投资经历，认为买入相对容易，卖出则难以判断。投资的本质是参与社会产出的分配，因此不应仅因市场变化或担心卖飞而出售资产。

卖出可分为换仓和变现：换仓应选择更有利于参与社会产出分配的资产，变现则应以实际资金需求为依据。若暂时用不到这笔钱，就不必卖出。

我从买基金，到买股票，再到买基金，其实经历了几个循环；目前持仓中，大头是基金。

在过去很长一段时间里，我都没想明白一件事 —— 什么时候卖？

买对我来说，不难。我本身就有保持储蓄的习惯，所以每个月固定存入一笔钱进行储蓄；然后购买资产。这已经成为我数年来的习惯了；也让我攒了一笔躺平保障金。但，如何卖是个很难的问题，怎么才能卖在合适的位置？怎么才能确保没有卖飞？

曾经我和 C 哥聊过卖期权，C哥的建议是：不要卖，等用到的时候再卖。我当时没太懂这个背后的原理；最近我终于明白了背后的逻辑。

投资我们到底在投什么？

我们投资本质上是参与社会整体产出的分配；分配有很多种，包括按劳分配（工资）、按资产分配（投资）等等多种多样。

我们的投资的目标是让自己能够更多的参与到社会产出的分配当中；如果我们只持有现金，就没办法很好的参与分配，因为现金只是现金，没有投入再生产，无法增强其自身效益。

而基于这个目标，我们什么时候应该卖出投资：我们认为不再需要参与到社会分配当中的时候；或者说，花掉这笔钱对我们更重要的时候。所以，答案很简单：用不到，就不卖。

是真的不卖么？

即使是卖，也分两种卖，一种是换仓，一种是变现；对于前者而言，判断标准也清晰很多：我们换仓的标的应该是比之前的标的能够更好的参与到社会产出分配当中。而对于后者而言，就回到前面的判断：不用不卖。

观《牛来》后记

2026-08-18 11:12:10

先说评价：牛来这部电影在票价合适的时候，是可以考虑去看的；虽然制作稀烂，但故事本身的元素还行；现场也氛围很轻松，如果你去一个人很多的场次，会很欢乐。

最近《牛来》很火，作为一个乐子人，我自然也想去凑热闹；于是便看看附近的影院是否有《牛来》上映。大多数排片都在晚上十一点以后了，对我来说太晚，就考虑跑远一点，最后在三公里外的大学门口的影院找到了一个九点五十开演的，果断买了票。

买票的时候，惊讶的发现。。。接近满场最好的几个位置已经没有了，不过好在是个小场，所以我买了边座倒是也不影响。到了晚上快开场的时候，看到这场已经彻底满座了。

观影体验

电影制作

坦诚的讲，《牛来》的制作极差，画质拙劣、镜头语言奇怪（会有一些奇怪的镜头，镜头之间的切换能让人产生眩晕）。

在非主角牛的时候，建模之简单可以看下图

给我一种 ——“诶，这个是大学生毕业习作吧。。。”的感觉。

对应的音效也很廉价，虽然感觉不像是买来的成品音频，但也有点诡异。

现场体验

虽说制作比较拙劣，但现场体验不错，可能是因为大家本身对于《牛来》的预期并不高，甚至是负面预期来的，奔着“我倒要看看《牛来》有多么的拙劣”的理念来的，所以反而从一开始，大家就很开心，我们从开场笑到结尾。

如朋友 bobo 所说，《牛来》其实和世界杯之类的线下观看，给大家了一个共同观赏的场域，给大家一个狂欢节，大家可以不用像看其他电影一样，不敢评论，不敢哈哈大笑。在《牛来》所有人都可以开怀大笑。

这些体验，是当下压抑的我们一个不错的选择。

因此，如果你要去看《牛来》，一定要选一个人多的场子，这样才好玩。

故事

《牛来》的故事其实底色还不错，讲述了一只小牛的成长的故事，其中杂揉了亲情、友情、成长、责任，还借助了南柯一梦的形式，在最后回溯到开始。

整个故事中，牛群和豹拉的误解、牛妈妈的牺牲，都让牛来本身的故事性丰满。如果同样的剧本，用更新的技术去制作，可能是一个还不错的小电影（不一定能是大片级别，但绝对算不上差）。

片尾曲

《牛来》的片尾曲是导演的妈妈演唱的，唱法颇有60-70年代生人的习惯，吟唱和长音，对于我来说，颇有种听自己母亲唱歌的感觉。

如果你想听原版，https://www.bilibili.com/video/BV13DbU6eEHe/?vd_source=bc2eca30591cc528ff3e3111c03da942 这个视频中有个盗录的版本，可以感受一下。网易云的版本（https://music.163.com/song?id=3422318789&uct2=U2FsdGVkX1/1O5dEeyaVq+DdVNFnVYekj94YfKKdztk=）会更好听，但没有原版的情绪那么充沛。

总结

如果你周围有 30 块钱左右一场，且人比较多的场次，去看看，还不错；但如果是自己在家看的话。。。我觉得大可不必折磨自己，这个电影还是去电影院感受一下氛围比较好。

观《老式喜剧》后记

2026-08-17 19:21:16

因为小学背过《雷雨》，演过《雷雨》，我对于人艺就很好奇。后面从深圳去北京工作，有了机会，我就曽和太太一起去人艺看了《蔡文姬》，后面种种原因，就一直没看；那一场有杨立新和濮存晰，还挺好的，不过时间久了，有点忘了hhh。

最近收到了人艺的新的推送，鬼使神差就点进去了，发现《老式喜剧》的演员是李幼斌（李云龙！）。于是就重新起了兴趣，决定去人艺看看老式喜剧。

提前买票，然后坐车前往人艺，等待入场；在等待入场的时候，我还在人艺的文创书店买了杯咖啡，在等咖啡的时候，发现他们正在卖阿尔布卓夫的《戏剧六种》，我发现里面有老式喜剧的剧本，果断下单买了剧本来看。

就老式喜剧这部剧而言：

我个人觉得李幼斌演的很好。他和他太太一起演爱情戏剧很不错（真夫妻就是好磕)
我是奔着给李幼斌一张票钱去的，毕竟以前也看过盗版的亮剑（我一直觉得应该买一份亮剑的盘存着，蛮好的电视剧）。
我觉得老李的给人的感觉和这部剧很搭，剧中他扮演的是一个60岁的，从战场上下来的外科医生，和李云龙很搭。

当然，也有一些事情让我感受到了话剧的有意思的地方：

并不是完全按照剧本演的，因为我买了《戏剧六种》刚好就看到了一些台词，其实老李并没有讲，但并没有影响整个剧的情绪表达。很好！
看这部剧给我种草了俄罗斯 Lube 乐队，他们的《Позови меня тихо по имени》很好听

给大家看点剧照，推荐大家去看看！很好！

BTW,我觉得现在去看话剧真的是我圆梦的一部分，可以在线下看一些小时候看的电视剧的演员，蛮独特的体验。

对平台存在敬畏

2026-07-01 17:33:15

我曾经一度对于「平台产品经理」是没感觉的。毕竟大家都是产品经理，做平台有什么了不起的？大家干的不都是产品经理的活么？你有什么差异。

但，后面，发生了一件事，让我记忆犹新，从而对于「平台产品经理」和平台级业务的感知和敬畏加深。

那时我刚加入飞书开放平台，作为飞书开放平台的技术型产品经理，我要去推动一个产品上的 API Breaking Changes。如果在产品发布前就触发了 Breaking Changes，就一定要提前告知客户，不然会直接出现事故，要追责。所以，我就发布了通告，进行客户的告知。

看起来很正常，且做的事情逻辑也对，是么？

但其实那次被定义为事故，事后组织了复盘。

之所以被称为事故，是因为，我的客户告知，进行了一次大面积告知，我的通知告知了所有的开发者客户，但实际上真正可能受影响的客户并没有那么多，我的过度告知反而给平台带来了巨大的解释成本和服务成本。

这个事情很小，但非常明显的体现出了普通产品和平台型产品的很大区别，普通产品大家的影响面可能是非常有限的，但平台型产品，特别是 TO B 的平台型产品，你的影响面可能是数以万计的用户和客户。一个处理不好，可能就是所有人要陪着你一起去跪客户的。

Bestony | 白宦成修改