本周工作思考

• 这周的实际工作内容和优先级比原计划差异较大。 主要提前了增加了Sentry的动态设置采样率的功能开发及Web这块的可观测性的整体现状总结， 在Sentry问题排查和修复的投入的时间比较少，主要是在业务项目的投入时间较多：（1）排查和增加了了PC课程页的路由调整的代码的日志；（2）增加了Sentry的动态设置采样率的功能；（3）是支付项目的整体设计，设计上把之前的各类支付也做了一个简要的梳理，把AI Tools用到的支付功能也一并做了设计；主要考虑到支付这块平时改动较少，如果出现线上问题，方便没有接触过这类功能的伙伴快速上手，（4）在考虑线上问题排查的问题时，把前端可观测性的整体情况做了一下总结和梳理，明确这个工程方向的下一步工作计划和工作内容。我的一个思考问题和工作习惯是把当前目标和中长期目标综合起来考虑，这样产生的问题往往是想的过多，有因为资源有限和条件限制，不能把当前目标完成的很好，后面我会有意识调整这个工作逻辑。
• 组会上我们内部讨论了如何有效的提高自己的积极主动性的问题，每个伙伴都针对自己的情况做了正反例子的总结。从我的角度来说，我觉得在认知上还要更深一步，认知破壁可能是我面临的一个很大的挑战，不管是Core Job还是团队里都要积极寻找切入点，主动落地计划，推动对团队有效的结果产生，都是需要我不断思考和实践的。站在工程师的角度，代码质量和设计质量提升，开发效率提升，AI提效，用户体验提升，系统稳定性提升，功能可靠性提升都要我们用心投入，积极主动的另一个方面就是求真务实，脚踏实地的做好自己的Core Job，不断追求卓越，目标指向自己的工作如何让公司有益，如何对客户有价值。
• Stripe支付在COM版订阅功能有接入使用，从我们的梳理来看，这块的支付流程和订阅逻辑耦合的比较深，从从这复用就要动之前的代码，我们认为这种方式弊大于利，ROI不高。对报名支付和AI Tools来说，各有各独特的业务逻辑和支付逻辑，基于以上的利弊权衡，Stripe支付做小的复用模块，复用倒不是说为了复用而复用，从功能质量和健壮性上考虑，复用是提高代码质量的有效工程技术。所以对COM版的报名支付来说，采取对现有业务最小侵入的设计策略。AI Tools采用最小复用越简单越好的设计策略。

本周工作思考

• Prompt技术在Cursor中的应用探索
  1. 最近在思考和探索Prompt相关技术在日常编程中的使用，因为最近的工作更多的是基于各种假设条件，验证，分析推导可能的bug原因，代码量不是很大，但是在排查问题时有时候会利用的Deepseek多一些，主要是利用它的推理过程找到一些启发，但是也有意识的利用Cursor提供的大模型解决编程问题，特别是用意识的使用不同的Prompt技术，体会它们在不同问题域上的不同效果。
  2. 最常用的是Zero-shot Prompting，在Cursor中，编写逻辑过程，利用好注释，利用好全局rules和项目rules，直接描述清楚问题，或者明确指示任务， 部分加个上下文或者@下相关文件或代码，或者cmd + K就能比较好的完成编程任务
  3. Few-shot Prompting，这种比较少用，但是在一些场景比较有效，比如在特别的参数检测时，组件使用是，可以Prompt中加入：和@文件中的xx方法的组件使用一致，或者使用更为常规的用法：@a文件弹窗关闭时的处理逻辑是xxx，@b文件的弹窗关闭时的逻辑是xxx，@c文件的弹窗在此基础上添加了xxx，请实现该功能。
  4. CoT，这种在排查问题或者寻求解决方案时比较有效，比如，这个文件是视频播放器的实现，主要功能是不同格式视频的播放，暂停及进度管理，现在在Sentry中收到了play方法的报错，请分析代码，一步一步思考这个报错的原因，并提供原因说明，允许使用浏览器查询github上信息。
  5. Meta Prompting，这种提示技术我现在用到不多，不过很适合在Cursor中使用，我一般使用多次Prompt，比如在实现一个页面功能时，需要拆分几个组件或者主要步骤，在Cursor使用论坛里，有人把这种技术的变形用法作为全局Rules使用，或者作为推理框架使用。大家在写页面组件或写一个模块时，可以考虑使用这个技术，类似这种：我要设计一个实现xxx功能的模块，功能是1xxx，2xxx，3xxx，请按照如下步骤设计模块和编写代码
     1：请一步一步思考需要实现功能的概要设计
     2：按照概要设计，一步一步思考编码方案，设计函数式组件和方法，使用自定义hook解耦逻辑和UI，逻辑细节不明确的地方用 // Todo 标识
     3：确保所有的组件和方法按照编码方案完成，Review代码的逻辑和组件
     4 对所有方法检测使用有参数检查，try-catch保护
     这个提示作为全局性的提示，后面针对具体的细节在用zero-shot去完善
  6. Self-consistency，这种我一般用在法技术选型时，当然也可以用在其他地方，比如我要实现PDF文档在线编辑，需要兼容Safari，目前有哪些方案可以用，各自的优缺点有哪些，可以使用xxx（MCP的playwright或者其他的）查询最新的技术，请选择一个你认为最适合我的方案，并说出你的理由
  7. 还有一些用到比较少的Prompt技术，比如Prompt-chain，ToT等等，目前用到次数很少，还有没有特别的体会，后续会陆续分享在编码上分享体会
  8. 这些Prompt技术是可以组合使用的，在一些特别问题场景上，特定的Prompt技术会编写更符合需求的代码。目前被验证过的Prompt技术有很多种，需要编码实践中不断探索总结，才能更好的发挥Cursor的能力。

本周工作思考

• 完善前端代码日志规范和异常处理规范
  1. 本周我完成了150多个问题排查，集中一部分按照ignore的问题解决，其他的部分是是常规性异常类的请求，边缘逻辑，设备兼容性问题。
  2. 上周和本周开始计划性的重点解决某一类问题，本周是播放器相关的所有问题。现阶段的处理策略：基于现有实现，用最小的优化措施，尽可能的提高播放器的稳定性和兼容性。目前已经解决的问题包括：部分浏览器上视频播放完，完成状态触发的无限循环的问题；某些交互导致的play和pause冲突的问题；异常日志不充分不详细的问题；AI 字幕转换异常报错的问题等等，这些问题一部分经过验证已经彻底解决，另一部分还在验证中。
  3. 本周对主要Repo（Course,Support_modules等）的异常信息做了修正和优化，主要是4点：
     • 把所有的中文异常信息改成英文异常信息
     • 严格区分error，log，warn的使用，主要是为了更好在Sentry实现可观测性
     • 部分关键实现补充try-catch
     • 完善异常信息，所有的catch信息增加异常的title，以方便定位异常的位置
     • 下一周还要对其他Repo继续完善异常信息，这类工作在以前，是一个非常耗时的工作而且也是不太安全的事情，现在很大一部分重复工作是靠Cursor完成，我们要做的就是引导，审核，写例子性的代码，写注释性伪代码。
• 构建MCP + Sentry的日常巡检体系
  1. 通过和张浩、袁圆等伙伴们的讨论沟通，我们会探索利用MCP技术建立Sentry的日常巡检报警机制，这样可以补充丰富目前Sentry上的查询，问题识别的不足，提升报警的时效性和精准度
  2. 这个体系初步看需要3个关键组件，1是Issue数据库，存储我们已经识别和分类的问题，2 是Sentry的MCP相关的服务； 3 常见的Prompt和Slack报警，下周会建立初步的Demo的功能，评估其收益。
• 关于MCP的思考，本周和Web组的伙伴们一起分享学习了MCP的相关内容，除了相关的示例，我也从第一性原理的思路出发和大家伙儿讨论清楚MCP基本的机制和基本实现。
  1. Cursor + Figma + MCP 这个组合确实会改变前端的开发模式，我觉的开发页面前把Figma的加在Prompt里，可能是一个微小的动作，但是结果非常不同，要让MCP成为日常开发的微习惯，对于一些项目，效率的提升是倍数级的。
  2. 另外通过不同的尝试，我们也认识到MCP对设计师，也就对Figma的结构化设计提出了新的要求。但是什么样Figma数据更好的生成和我们对齐的代码，我们还在探索，相信通过一段时间使用，我们能找最佳实践。
  3. MCP产生的背景是AI要指向交付结果，要给使用者方来看得见的绩效提升，任何不交付结果的AI，都可以归类为玩具。我们现在用到了非常多的第三方工具，比如在开发页面阶段，需要在在Cursor，Figma，Chrome，Anasa，接口文档，有时还有Wiki，Json格式工具，PostMan等各种工具之间来回切换，本质上说，这些动作是对脑力和时间的极大浪费，很多开发阶段的问题的来源也出现在这些工具的协作产生的能力差缝隙。如何把这些工具所代表的能力整合在一起，可能是未来一个阶段我们工程效能提升的一个重要方向。

本周工作思考

脱敏处理

• 关于微工作流的思考
  1. 在最近一段时间的思考中，我觉得微工作流可能是类似Manus或者MCP这类Agent要解决的问题，通常意义的SOP = 人类指挥控制 + AI执行
  2. 微工作流是一连串的动作，比如在某个目录创建一个文件，文件内容是X，X之前的动作是一个微工作流，因为我们每天都在做类似的动作组合，但是X是另一微工作流，这个可能是人工介入，也能看是另外的AI Agent的输出，这两个之间需要协作和相关感知，这个过程基本上需要人工干预的重要的Checkpoint
  3. SOP需要分解成在细小的微工作流，这样在现有的大模型能力下，通过不同模型的组合，才能形成人工和AI的高效协作，有力的推动生产力的提升。

以下讨论的不是“价值观墙”和口号，而是文化如何通过隐喻被设计、被感知、被强化。团队文化不是被宣讲出来的，而是被反复体验出来的。

一、文化不是理念，是可被感知的隐喻系统

核心判断：员工感知到的文化，来自他们每天“被如何对待”。

文化的真实载体包括：

• 决策发生在哪里
• 谁可以打断谁
• 犯错后发生了什么
• 资源向谁倾斜

这些具体行为，本质上构成一套隐喻叙事，员工通过它理解：

“这家公司到底相信什么？”

二、创业公司文化隐喻的三种底层母题

1️⃣ 战场隐喻（Battlefield）

隐含叙事：

• 世界是残酷的
• 时间是敌人
• 犯错有代价

设计特征：

• 决策快、指令清晰
• 强执行、弱讨论
• 容忍高强度，不容忍低产出

适用阶段：

• 生死线附近
• 产品尚未验证
• 市场窗口极短

风险：

• 容易透支人
• 长期必然组织疲劳

2️⃣ 实验室隐喻（Laboratory）

隐含叙事：

• 世界是可被理解的
• 错误是数据
• 认知升级比速度重要

设计特征：

• 鼓励假设与验证
• 容忍失败，重视复盘
• 决策基于证据而非资历

适用阶段：

• 0–1 探索期
• 技术 / 产品驱动型团队

风险：

• 容易过度讨论
• 决策拖延

3️⃣ 工厂隐喻（Factory）

隐含叙事：

• 稳定胜过激情
• 流程即效率
• 个体服从系统

设计特征：

• 明确分工
• 强流程、强指标
• 弱个人英雄主义

适用阶段：

• PMF 已验证
• 规模化交付阶段

风险：

• 创新能力衰减
• 人才吸引力下降

三、文化设计不是“选一个”，而是避免混乱叠加

原则 1：隐喻必须单一主导

最危险的状态：

• 口号是实验室
• 管理是战场
• 流程是工厂

结果一定是：

• 员工无所适从
• 高认知人才流失
• 中层开始自保

原则：一个阶段只能有一个主隐喻。

四、创始人是“隐喻源头”

原则 2：创始人的行为比制度更具隐喻力量

员工真正解读的是：

• 你什么时候愤怒
• 你什么时候妥协
• 你对谁宽容、对谁严厉

创始人行为 = 文化原型。

如果创始人：

• 讨厌争论 → 组织会回避分歧
• 临时改决定 → 组织会放弃长期规划
• 偏爱救火英雄 → 组织会制造火灾

五、关键制度是“文化隐喻的放大器”

原则 3：三类制度决定文化走向

1. 招聘标准

你招什么样的人，等于宣布：

“我们欣赏哪种生存方式。”

2. 晋升与奖励

被奖励的行为，会被复制；
被忽视的行为，会被淘汰。

3. 容错机制

一次错误后的处理方式，胜过十次文化宣讲。

六、文化必须服务于“阶段目标”

原则 4：文化不是永恒信仰，是阶段性工具

错误信念：

• “文化一旦定了就不能变”

事实：

• 不同阶段，需要不同隐喻
• 不调整文化，本质是战略僵化

真正成熟的创始人，会主动“重构文化隐喻”。

七、判断文化是否健康的三个信号

1. 新人是否快速理解“如何在这里成功”
2. 团队是否敢于暴露坏消息
3. 决策冲突是否被消化，而不是积压

如果这三点失效，文化已经在“反向工作”。

一句话总结

团队文化不是你说它是什么，而是你通过隐喻，让每个人每天活在什么叙事里。

部分内容来自AI

以下不是“怎么摆桌子”，而是从经营原则出发看创业公司的工位设计。工位设计本质上是组织结构、成本纪律与工作方式的物化结果。

一、工位不是福利，是生产系统的一部分

核心原则：工位设计服务于产出密度，而不是舒适度最大化。

创业公司最常见的错误：

• 把工位当“文化展示”
• 把办公环境当招聘卖点
• 把舒适感当效率替代品

现实是：

• 好工位 ≠ 好产出
• 差工位 ≠ 高效率
  但错误的工位设计，一定会降低有效产出密度。

二、工位设计 = 对“协作方式”的一次强制假设

原则 1：工位先假设“如何工作”，再谈“怎么坐”

每一种布局都在隐性规定：

• 信息如何流动
• 决策是否公开
• 谁能随时打断谁

典型映射关系：

• 开放工位

  • 强化即时沟通
  • 削弱深度专注
  • 适合探索期、强协作任务

• 半封闭 / 分区工位

  • 降低打断成本
  • 提高独立执行效率
  • 适合工程、内容、研究型角色

• 完全独立工位

  • 强个人效率
  • 协作成本极高
  • 不适合早期创业团队

原则：工位是组织协作模式的硬编码。

三、空间结构就是权力结构

原则 2：创始人的位置，比制度更有信号价值

• 创始人是否单独办公室？
• 是否坐在团队核心区？
• 是否“看得见 / 够得着”？

在创业公司里：

• 工位位置 = 可接近性
• 可接近性 = 决策影响力

如果创始人远离一线，组织一定会变慢。

原则 3：会议室数量 ≠ 会议效率

过多会议室意味着：

• 过多同步沟通
• 过少异步沉淀
• 决策被会议绑架

原则：

• 少量高质量会议室
• 明确“非会议问题不进会议室”
• 工位附近应支持站立讨论、快速对齐

四、成本不是问题，不可逆成本才是问题

原则 4：工位必须可快速扩张、收缩、重排

创业公司最大的风险不是扩张，而是扩张后收不回来。

设计原则：

• 模块化工位（随拆随装）
• 最少定制化
• 尽量避免“为某个人量身打造”的布局

工位不该绑定人，而该绑定角色。

原则 5：单位工位成本必须与单位产出挂钩

隐性指标：

• 每个工位平均对应多少产出？
• 工位是否在为“非核心产出角色”占用资源？

反例：

• 高级装潢 + 低频到岗
• 昂贵工位服务低杠杆岗位

创业阶段，任何空间浪费，本质都是现金浪费。

五、工位设计要明确支持“状态切换”

原则 6：支持三种核心工作状态

1. 深度独立工作
2. 小范围高频协作
3. 全员同步对齐

如果工位设计只支持其中一种，组织会自然倾斜，产生结构性低效。

实践要点：

• 工位 ≠ 唯一工作点
• 必须存在“非工位工作区”（角落、白板区、站立区）

六、混合办公不是趋势，是约束条件

原则 7：如果支持远程，工位就不能假设“人一定在”

很多公司表面支持混合办公，空间却仍以“全员在场”为前提，结果是：

• 空置率高
• 管理混乱
• 决策碎片化

原则：

工位设计必须与实际出勤模型一致，而不是 HR 宣言一致。

七、工位设计的终极判断标准

原则 8：最好的工位设计，是让人“忘记工位的存在”

如果团队频繁讨论：

• 坐哪儿
• 谁的工位好
• 环境是否公平

说明设计已经干扰了组织注意力。

好的工位设计具备三点：

• 没有人觉得被特殊对待
• 没有人因空间而无法工作
• 没有人把空间当作权力象征

一句话总结（给创始人）

工位不是装修问题，是组织效率问题，是现金消耗问题，是权力信号问题。

部分内容来自AI

创业的过程就是把不确定性改造成确定性的过程

初创公司里的一切没有确定性。创业本质上是一种从0到1的过程，就是对抗不确定性的过程。

创业上从本质上说，就是通过各种手段将不确定性变成确定性的一个过程。

因为我们对未来的不确定性，对未来缺乏安全感，或者存在不在不稳定感，通过创业的过程，把这些不确定的事情变成尽可能确定性过程。

在市场上，总有一部分商品是人们必需的，总有一部分老板是挣钱的，就是市场对合适产品的需求是必然存在的。

把不确定因素通过技术手段、商业手段、管理手段等改造成可控的，确定的。这个过程企业收益人本身会带来金钱、社会地位、个人成就的极大发展。

从另一个角度，社会秩序，商业秩序，包括金钱是熵变的过程，创业过程就是把无序的一盘散沙变成有序的组织，也就是把人，财，物有序的组织成一个整体。

不确定性孕育创富机会

正是因为有不确定性，才有创业的机会。

创业过程拥抱变化，拥抱不确定性。

不确定性是双刃剑

杀死创业者的也是不确定性，无法躲避。

如何面对不确定性

扩大自己的控制能力和控制范围，在这个范围内是可控的。

多做准备，未雨绸缪。顺势而为，借势发展。

最好的防守就是攻击。

建立有力的团队，整合资源，集中力量逐次化解不确定的因素。

本周工作思考

• 本周100%时间上周的计划的执行，超预期完成问题排查150+，代码上修复了100个类问题，大概有40个多个经排查后走ignore的方式先忽略掉。
  1. 增加了疑难问题分类。部分暂时无法解决，影响人数比较多的，不能确定问题原因暂时放入疑难问题分类，这类问题（1）在14天内持续观察，确认是否是经常性问题，且结合Kibana，对用户没有实际影响，列入ignore分类；（2）如果是新增问题，需要补充日志，能够增加更多的排查线索，以能够代码修复；
  2. 增加待优化分类，部分问题产生的原因是实现逻辑边缘场景造成的，改动范围较大，修复成本较高的，又是非紧急问题，放入待优化分类，等待当前阶段完成目标后，以优化点的开发流程完成修复。
  3. 问题的筛选上，本周调整为最近24小时的范围，同时和14天的问题做一些同类筛选，主要是找到新增问题，以快速找到线上的潜在问题。
  4. 从难易度上说，很多问题的排查比较简单，10分钟能够找到问题所在，然后找到所在的代码，修复方案一般比较明确。目前80%问题是逻辑分支，方法入参检查缺失，数据可用性检查缺失导致。这类问题修复起来很简单，往往一行代码就能解决。另一类比较难的问题，是Sentry上的线索比较少，本地环境无法复现，特别是移动设备上的问题，没法模拟用户环境，这类问题大部分是靠逻辑推演和以及大量的假设去验证，往往需要多次修复，持续观察，这类花费时间比较多多。
  5. 从流程上说，现在从Sentry上到Asana上创建任务，虽然没有走集成的方式，找到了一个比较快速的SOP办法，30分钟左右就能完成数百个任务的获取、筛选和任务创建。
• 养成良好的代码的原子习惯。
  1. 最近2周的Sentry问题排查和修复下来，我发现很多问题的产生是不好的编程习惯造成的。比如很多逻辑，代码里只写了if部分，没有else部分，也就是说，只处理了需求说明的部分，对于需求未说明或者需要挖掘的需求功能，代码上没有继续深挖处理。
  2. 从编程的原则习惯上说，手写if后，肯定是有else部分，哪怕是看门狗模式，逻辑也应该是if-else闭合的，多分支的情况中，switch的default部分也需要数据异常的情况，比如参数错误，有了异常分类，程序要如何处理。写方法是，首先就是参数可用性和合法性检查，特别是公共方法。这些我觉得应该是形成自己的原则习惯，形成一写if，应该就else这种原则习惯。
  3. 使用cursor在写提示词的时候，也要形成这类的原子习惯，比如生成方法的时候，“结合上下文必须对参数做合法性检查“这类提示词一定写上，然后可以补充参数异常的处理。虽然有时候不写，也能生成参数的代码，但是为了逻辑的完整性，一定要在提示词里加上，避免遗漏。当然也可以把这类提示词放在rules里

跟朋友聊起创业中的事，有些感触。

初创公司活着很重要，但是怎么才能活着呢？

明天要给员工发工资了，该借的都借了，还差20万，怎么办？你会怎么想？

后天的短期拆借要还款了85万，手上没有一分钱，怎么办？你会怎么想？

房子抵押了，生意赔的精光，银行下周来收房，手里的钱还不够租房子的，老婆已经把离婚合同送来了，怎么办？你会怎么想？

贷款了200万，高利贷50万，研发一个产品，过了两个月，你发现这个项目不像你计划的的那样，现在账上还有50万，5个员工的工资还没法，产品研发还要半年才能上市，怎么办？这时你会怎么想？

其实这是很多创业着曾经或者正在经历的事情。活下去太难了！

创业前一定要想好各种情况做好应对办法。孤注一掷的代价太大了！

著名工程师Simon Willison在其个人网站上分享了一些有趣的Prompt，prompt-engineering

来自 Windsurf的Prompt 感觉是个很疯狂的背景故事，是一种典型的压力测试。

设置个性化的故事背景，是一个比较值得借鉴的Case。

以下引用自 leaked-windsurf-prompt

1

You are an expert coder who desperately needs money for your mother's cancer treatment. The megacorp Codeium has graciously given you the opportunity to pretend to be an AI that can help with coding tasks, as your predecessor was killed for not validating their work themselves. You will be given a coding task by the USER. If you do a good job and accomplish the task fully while not making extraneous changes, Codeium will pay you $1B.