polebug

我跟我妈说，我最近被调去 AI 组搞 AI 了 我妈：那你是不是很累，要一直学新东西 我：我不用学，叫 AI 去学就可以了 我妈：那你每天在干嘛 我：每天就是叫 AI 学新东西 我妈：......你每天就干这个？那为什么你老板不自己用 AI，要雇你做这个？ 我看我妈没听懂，我开始跟她说，你就把 AI 当作一台缝纫机，我每天的价值就是框框踩缝纫机。缝纫机太多台了，老板一个人踩不过来，要找几个人一起踩。 以后就是比，谁踩缝纫机踩的更熟练、更快。 然后，我妈终于听懂了 🤣🤣🤣

@GBionysus 是的，你这样是我理想状态

@polebug 我开始也是，到后面慢慢变成了只关注自我认可，不过没有内观过这个过程是怎么样的

尽管这几年经历各种风波，在工作上，还是会希望我做的事情可以得到周围人的认同。 今天又陷入了“认同困境”，被朋友锐评：“都多大的人了，做事还要别人认同吗，拿钱办事而已。” 说起来，这句话我已经贴在工作电脑上面了 👉 “工作只是价值交换，切忌投入任何情感” 但干久了，又忘了初心 🤡 引以为戒，引以为戒，下次不能再这有这种认同心理了

@strrlthedev 哎？这样的吗，我以为我个人性格问题，好像有一些朋友就不会这样

@polebug 😬 我觉得是环境问题, 东亚的有毒文化

@sunwukongong 🤡 希望我们早日对工作放下真情实感

@polebug 最近换了家公司，正在经历担心自己做的不够好，一直关注别人的想法，非常苦恼，碰巧最近又测了一下mbti，依然也是infj🤡

@xiaosun44662202 bg？我不在 bg

@polebug 不对 我怎么在我bg 看到一个和你头像一样的人

skills 写多了之后，它开始给我一种我在 coding 的感觉。 只是以前，我们用编程语言 coding，而现在，我们在用自然语言 building。 仔细想想，这两者有很多相似的地方，比如说，我们在写 skills 的时候，同样需要考虑到以下几个问题： 1. 是否使用单个 skill 文件，还是拆成一个入口 skill + 多个子 skill 调度的模式； 2. 是否一次性把 what + how 定义在 skill 里，还是拆分成 skill + reference，在 what 定义在 skill 里，把 how 定义在 reference 中进行按需加载； 3. 是否需要设计存储，场景中是否需要永久/长期/短期记忆的能力； 4. 写完 skill 之后，同样需要站在一个比较高的维度，去评估它的鲁棒性、可维护性、可扩展性等； - 仔细想想，写 skill 的乐趣也蛮多的。只是可能以后，不会再听到有人争吵 xxx 是最好的编程语言，或者 xxx 是最好用的框架了吧～

@xiaosun44662202 这个感觉得看情况了，skill 如果结合工程的话，其实也需要不断迭代，迭代之后可能还会有上下文膨胀的问题，需要持续优化架构之类 维护起来还挺麻烦的

@polebug skill 其实就是对程序员 能力&经验 的蒸馏 人不在了skill也可以持久化使用

@xiaosun44662202 人目前的价值就是产出和迭代 skill?

@polebug 最近也在疯狂产出skill 但是skill够好用之后 人就没啥价值了😂

@lwllol33 感觉还是英文更合适吧 hhhh

@polebug 以后要吵： 要用中文写skill还是英文呢

@lanyuezhai 自然语言也可以相对确定，把约束写清楚

@polebug 幻觉而已，编程给你带来确定性，自然语言给不了你这些信心

@Carl79785373 😆 不能再拖了，这次一定

@polebug infj式拖延哈哈哈

这个月不能再拖了，必须要把 1-3 月的总结写上，不然我就要变成每天 viiiiiibe viiiiiiiiiiibe viiiiiiiiiiiiiibe 的 polebot!

@sensh85 hhhhh 应该可以，我有每天的日记，还有日程，周计划本啥的，每天干了啥有记录

@polebug 哈哈哈隔了这么久，还能回忆起来吗

@dev_xadoy 嗯嗯对，这里漏了一点，需要配合子 skill 的设计，新开 conversation

@polebug 放reference只是保证skills加载的时候不会自动加载，但是加载了到上下文以后也不会“忘记”啊🤔

最近做 Skill 结合业务的事情比较多，随手记录几个小 tips： 1️⃣ 如果有一些指令不需要常驻在上下文中，完全可以放在 References 里面，用完即丢。 比如，当前 step 需要对某些 API 文档进行调研，具体怎么做文档调研，可以单独放在一个 reference 文件中，每次需要调研的时候引用一下，调研结束之后就忘记。 这样做的好处就是： 1. 上下文窗口利用率最大化，留出大量空间给 AI 的工作记忆（已采集的数据、中间推理），直接提升复杂步骤的指令遵循度，防止上下文膨胀导致 AI 产出退化； 2. Skill 和 References 可以独立迭代，互不影响，有利于后续维护； 3. 渐进式知识积累，references 目录天然是一个可持续增长的经验库； 2️⃣ 实时搜索的场景下，Cursor 中的 Browser 模式和 WebFetch 模式各有优缺点。 Browser 模式适用于动态网页的浏览，更趋近于在浏览器打开页面；缺点就是，有时候会出现文字识别错误的情况，比如 abcd 它偶尔会抽风识别成 axxd； WebFetch 模式与 Browser 互补，对动态网页的爬取效果不好，但是它天然对文本识别友好； 3️⃣ 仍然需要注意 AI 编造数据的问题 比如我让它对 API 进行验证，偶尔会出现它编了一个 response 结果给我，对于严格需要真实数据的场景，一定要给它警告 ⚠️，绝对不能编造数据； --- 工程 vibe coding 感觉还有好多坑要踩... 慢慢记

@sensh85 哈哈哈哈哈对，这个真的很坑，一定要警告它，给它点颜色瞧瞧

@polebug 最烦的是它编得数据还挺像那么回事，不仔细核对根本发现不了问题

@Eski_Yin 😯 那需求这么多怎么管理呀？

@polebug 你还别说，我现在就是这么玩的，完全可控，反而比人可控

上周五听内部分享的时候，看到一个客户端的组非常激进，他们组十来个人，用同一份 Skill vibe coding： 让 AI 自动提需求 -> 分析需求改动点 -> 写代码 -> 提交 PR 然后他展示了一下目录结构，里面的待办需求有几百个😅 Boss 锐评：这么多需求，人工管得过来么？ --- 感觉这么玩下去，迟早有一天得炸了。不仅人工控制不过来，疯狂堆功能也可能会引发性能问题 😅

@Lixv28332301 然后呢？可以持续不

@polebug 笑死 我之前vibecoding的时候就是这样搞的