捕蛇者说

很有意思，也很有价值： - Bub 的设计初衷，是可以在群聊中生活的 Agent - 对于普通人来说，龙虾可以增加新能力，这一点是最迷人的，这另他们发现，不必与艰深的代码去对接（Markdown 也是代码），而是直接通过交流，来实现目的 - 如何形成更加优质的 Skill？用一个线上能力强的大模型，推动采用本地小模型的 Subagent 使用 Skill，然后在大模型可以根据输出的质量，然后完善 Skill - 模型能力越来越强，同等难度的任务，随着时间推进，需要的模型尺寸越来越小 - 设计过程中发现，不再写死 Bub 怎么回复，反而对话变得灵动

听完了，想写一点我自己的感受。 实际上，只有互联网或信息技术或类似的前沿技术的企业内，技术部门可能成为「盈利部门」，因为事业部导向的组织架构也只有技术能成为规模性收入的来源的企业才有可能落地。 大部分传统企业，所有的技术部门都是 cost center，都要面对这样的困境——你如何阐述你作为公司 cost 的价值，尤其是企业进入非扩张期的时候。 这件事会有两面可以作为思考。 从管理层面，从上往下： 我认为科技管理的核心并不在于技术层面从上往下指导或决策，核心在于「治理」，在于想清楚结合企业的实际情况，科技的成本应该在整个科技能力体系里怎么投，怎么产生价值，怎么性价比最高。 因此，任何一个「员工和管理层价值理解的错位」，本质上都是治理问题，都是管理问题。 动态的平衡开发和测试的关系，动态的平衡业务技术投入和工具技术投入之间的关系，都是管理者的职责，只有从上往下才是正解。如果被迫的从下往上去推（比如多次提到的 ppt 阐述价值），都是管理的缺位，治理能力的缺失。（当然我说的是理想情况，但这不是心必须向往之吗）。 从工作层面，从下往上： 我一直认为工程师们比如理解自己的技术在整个部门，企业，业务架构里的位置，能自己从更大的大局里脱离此山中的看待自己手里的工作。 第一，有助于你更清醒的评估自己工作的在公司内的前景，职场不吃亏；第二，能逼迫自己去思考非技术的问题，包括商业，企业管理等等，也更公平的看待自己的想法究竟是不是完善和合理的。 作为非直接业务相关的技术部门，如果你实际上站在了 cost center 内的核心价值位，那其实也是不必要焦虑的，因为你很可能间接但非常重要的给公司产生了不可替代的价值。 --- 这一期内几位朋友说到的内容都非常真实，甚至这些可能才是大部分技术人日常的常态（谁能一直在公司核心发展的业务C 位呢）。 只有嘉宾朋友的最后一个观点我不太完全能同意，我觉得「找风口」应该是创业者的其中一个核心逻辑，但对打工者来说可能始终是高风险的。 在一个超过十年，十五年，或者更长的职业生涯里，风口转瞬即逝，技术从业者需要留下更多自己的东西，技术之外的东西，也许才能更在高速增长的行业里更从容一些。

大学时候很爱听 Teahour，几乎每一期都听过。今天突然想：“Teahour停更了，好可惜，再没有哪个技术播客节目带给我那样的震撼🫨” 但后来又想，可能现在的技术播客都比Teahour更好，只不过我已经不是那个啥也没见过的大学生了。