低头喝水之前还是正常的,一抬头就这样了,一瞬间不敢相信自己的眼睛 已经排除显卡问题,因为换到其他主机上也是这样
没有进水或挤压之类的意外 也没有很长时间一直亮屏
买来大约 5 年,LG,4K HDR 60 帧 当年还蛮贵,现在估计换一个也就 2K 吧
也很奇怪,每年 618 之前几天都会坏一个东西
这样能修吗?修起来贵吗
]]>不过，最近 Cursor 和 SpaceX 的合作让我有些担心。SpaceX 在隐私安全和版权保护方面的态度，至少从公开观感上看，并不能让我完全放心。
Claude Code 这边有 OpenCode 这样的开源选择，可以接入自己部署的本地模型，也可以选择更合规、可控的模型提供商。那我想请教一下大家， 有没有比较推荐的 Cursor 替代品，最好能满足下面几个条件？
那一年，我十四岁。
爷爷养了一大群鸭子，四百多只。灰白色的羽毛连成一片，远远看去，像是谁把一朵云扔到了田野里。
于是我成了放鸭人。
每天早上天刚亮，爷爷挑着鸭食，我扛着竹竿，一起往河边走。
鸭子，看起来傻乎乎的，其实最不好管。尤其是刚放下水的时候。栅栏门一开，四百多只鸭子瞬间炸开，像一盆水泼出去。东边几十只往稻田里钻，西边一群扑腾着往河汊子游，还有几只愣头愣脑的，站在原地发呆。
我拿着竹竿在后面追，跑得满头大汗，嗓子喊哑了。鸭子却根本不理我。
那时候我经常觉得委屈——为什么连鸭子都不听我的？
爷爷却从来不急。他慢悠悠走过去，竹竿往水面一点，嘴里发出几声奇怪的口哨声。鸭群竟然一点点聚拢回来，像听懂了命令一样。
后来我问爷爷怎么做到的。爷爷笑了笑：“鸭子刚下水的时候饿。饿的时候谁也管不住。等吃饱了就好。”
那时候我听不懂。很多年以后才明白——人其实也一样。饿的时候、穷的时候、慌的时候，谁都很难讲道理。
我最喜欢的时间是下午三四点。太阳开始往西边偏，河面上铺着一层金光。鸭子们吃饱了，嗉子鼓鼓的，三三两两漂在水面上。有的打盹，有的梳理羽毛，有的慢悠悠转圈。整个世界忽然安静下来。
我坐在河边，竹竿横在膝盖上，什么都不做，就看着它们。那种感觉很奇怪——明明什么都没有发生，可心却特别安静，像所有烦恼都被河水带走了。
那个时候的我还不知道，人生很多最难熬的时候，其实都需要这样的时刻：什么都不想，什么都不争，只是安安静静地坐一会儿，让心缓过来。
有一个画面，我看了一整年，却从来没有看腻。
鸭子找食的时候，会突然把头扎进水里，屁股朝天，两只脚蹼在水面上扑腾。过几秒钟再猛地抬起来，嘴里往往叼着一颗小螺丝，然后仰起脖子，咕咚一声吞下去。再继续下一个猛子。一个，又一个，不停重复。
我坐在岸边看，看久了，甚至会学着它们的频率——等它们钻下去，我屏住呼吸；等它们抬起头，我跟着出一口长气。我就那样坐着，守着这群只顾低头填饱肚子的家伙，一直坐到太阳偏西，也不觉得时间难熬。”
还有一段时间，是冬天。
那时候田里的稻子已经收完了，风很硬，吹在脸上像刀子一样，河水也冷得发黑。鸭子反而更难管了，因为田地空了，它们可以去的地方更多。
我们这一片放鸭的，不止我们一家。村里有两户人家养鸭，所以鸭子是分片区放的，各自守各自的地界，不能越界。一越界就容易踩进别人家的田里。
收完稻子的田看起来很干净，但其实更危险。稻子割完以后，田里会留下很多禾桩，那是用镰刀割出来的断口，一根一根立在泥里。表面看只是短短的茬子，但边缘很锋利，走快一点，一不小心就会划到腿。
我那时候穿着胶鞋，鞋底厚，但鞋筒不够高。冬天下田久了，水早就渗进去，脚一直是湿的，时间长了反而麻木。
鸭子一乱跑，我就得跟着下田去拦。脚在泥里一深一浅地踩着，禾桩就在脚边一根根掠过去。
有一次，我追一群往别人田里钻的鸭子。
当时注意力全在鸭群上，没有看脚下。
田里全是禾桩，一根一根立在泥里。
我踩进去的时候，其实已经被划了很多次，但当时完全没有感觉，只是一直往前追。
脚是麻的，不知道疼，也不知道已经受伤。
直到把鸭群赶回河边，我才停下来。
停下来以后，才觉得不对。
裤腿变得很沉，鞋里也是湿的。
低头一看，两条小腿都在流血。
血不是一下子流出来的，而是一路慢慢渗出来的，混在泥水里，看不太清楚，只是一直往外扩散。
那一刻我才第一次真正明白，放鸭子这件事，不是“看着一群鸭子”那么简单。它是要用身体去换的，换秩序，换责任，换那四百只鸭子不跑散。
我还是把鸭群赶回了河边，像什么都没有发生一样。只是走路的时候，腿开始一点一点发热，隐隐作痛。
真正难熬的是晚上。
鸭子回棚以后，爷爷要守鸭棚，我得一个人回家。从鸭棚到家有六里路——一条田埂路，过后便是树林路。白天走起来不算什么，天一黑就完全变了样。两边全是庄稼，风吹过来沙沙作响，远处偶尔有狗叫。还有几座坟头孤零零蹲在田边，白天看是土包，晚上看像坐着的人。
我很害怕。真的害怕。
十四岁的男孩子，已经知道什么叫逞强了，所以我从来不说。每次都是硬着头皮往前走，脚步越来越快，最后几乎变成小跑。可恐惧这种东西，不是靠跑就能甩掉的——它始终跟在你后面，离你半步远。
后来有一天，我学会了一个办法：唱歌。
一开始只是小声哼，后来发现不管用，于是越唱越大声，唱到最后，几乎是在喊。我没有会唱的歌，全是瞎编，想到什么唱什么。有时候唱鸭子，有时候唱爷爷，有时候唱今天捡到了多少螺丝。有时候干脆反复唱：“我不怕。我不怕。我不怕。”
声音在田野里飘出去很远。月亮听见过，星星听见过，路边的狗尾巴草也听见过。
唱着唱着，胆子居然真的大了。因为声音一出来，人就不再觉得自己是一个人——好像黑夜里有个同伴陪着你。那个同伴，就是自己的声音。
春天过去，夏天过去，秋天过去，冬天也过去了。
我跟着爷爷放了一年鸭子。学会了看天气，学会了赶鸭群，学会了在泥巴路上走一天不喊累，也学会了一个人面对漫长的黑夜。
这一年没有课本，没有考试，没有成绩单。可我学到的东西，一点不比学校里少——只是没人给我打分。
一年后，爷爷忽然对我说：“不能放一辈子鸭子。去学门手艺吧。”
他说得很平静，像在说明天会下雨一样。可我知道，放鸭子的日子要结束了。
第二天，我把竹竿靠在鸭棚墙边，回头看了一眼河面。鸭群还在水里觅食，和往常一样。没有谁知道我要离开，也没有谁在意。
生活就是这样。你以为很重要的告别，很多时候连告别都算不上——只是转个身，路就变了。
我沿着田埂往回走。没有再唱歌，因为这一次，前面已经有另一条路在等我了。
后来我修车，跑长途，进东莞，学电脑，写代码，创业。
在那里，我第一次学会了忍耐，学会了孤独，也学会了在没人帮你的时候，自己给自己唱歌。
四百只鸭子陪着我，走出了学校，也走进了生活。
很多年以后，我开始写 php/Golang 时，才发现那一年学到的，其实一直在用。
但我到现在也说不清，那到底算不算“学会了什么”。
]]>背景是工作上兴趣上会拉到不同的 Android 项目，它们由于迭代维护时间不同，依赖使用的 JDK 也会不同。
之前手工编程都用 AS 打开还好，AS 会提示让指定一个 JDK ，并且这个 JDK Path 也不会影响到团队其他同事的使用。
但现在大部分情形下 Agent 编程了，纯命令行跑的时候就麻烦了，要么就给 Agent 强调编译时要注入什么版本的 JDK 环境变量，要么就得让 Agent 自己试，多不环保啊（
所以抽空研究了下这个“两不管”——Android 认为已经有 AS 的私有配置了（我猜的）、Gradle曾认为只需要考虑 gradle.properties的中空地带，和 Agent 一起弄出了这个 patch project 。
希望这个 patch 能帮你的 agent 节省一些 token （笑
如果有帮到你，欢迎 star ，谢谢~
]]>我是 97 年的，男，心理学专业，小时候在豫东农村长大，小学一年级跟爸爸去了深圳，一直在那念书，学习能力一般，高中读文科，2016 年考到了兰州的一个很普通的本科。对科研有兴趣，但是考研考了好几次都考不上，最终是 2023 年考到了中科院某研究所读研，然后硕转博到现在。
家庭情况也挺一般的，甚至可以说比较差。读书、青少年时期一家人是在深圳租房住，妈妈没工作，照顾我和我姐，爸爸在五金厂打工。现在是姐姐结婚了，爸爸还在五金厂打工，每月 5000 左右，妈妈在家种田（一亩半的地，其实根本挣不到钱），或者起早贪黑的去果园帮人干活，家里没什么积蓄。基本情况就是这样。
按理说我家这情况，我就踏踏实实工作，比如我 2020 本科毕业的之后的 12 月又考研了一回，两次考研距复试线都是 10 分以内，第一次是差了 1 分，心情非常沮丧，但是 2021 年元旦就去打工了，先是在坪山的一个模具厂做计划、报关等等，过完年重新找工作去做了用户研究，那时候想的是，攒点钱，找个对象，踏踏实实过日子。
可能是家庭环境的原因，按现在流行的说法，是认知局限性吧，非觉得读书才有出路。第二次考研虽然没考上中科院的研究所，但是调剂到了某个还行的医科大学，21 年 8 月份去读了一个月觉得和自己想的不一样，就退学了，决定继续工作吧，22 年疫情挺无聊的，在外包公司，不忙，那时候花了好几个月研究 run 的可能性，加了群、博主等等，同时暑假又动了考研的念头，边工作边复习，很骄傲地说没有因为考研耽误了挣钱，这次是擦线过了，于是 23 年入学。
这三年并不顺利，没有一篇文章，科研进展很是滞后。做认知神经科学，有很多东西自己都不懂，但也不愿意去问，课题组很强，十几个人，有几个清北的，大部分是比较好的 985 和国科大的本科生，两位导师本科都是北大的，非常聪明、踏实的科研工作者，相比之下自己真是阴暗的老鼠，作息上也是，下午了去实验室，夜里四五点回去，只是因为晚上夜里没人找。越来越自卑，越来越觉得辜负了老师的信任，越这么想越内耗，越不想开始干活，反正老师也不打卡，我不找导师，导师也很少、极少找我。
今天研二的师妹找导师签字去大厂实习，这是课题组头一遭，课题组给的补助挺多的，所以大家要么偷偷的短期的实习、要么就是不去实习，大部分人都不实习。非常感慨年轻人知道自己要什么、要去争取什么，这是我想发这个贴子的直接原因吧。
有件事印象很深：读高中的时候班主任夸我同桌说我同桌知道自己想要什么，我觉得对人最大的夸奖就是夸对方知道自己想要什么、要做什么。克尔凯郭尔在《日记》里说"我真正缺乏的是我心里明白我要做什么"。
继续说回科研，真觉得做科研挺难的，第一学历如此之差，侥幸博士毕业，去读博后，读完之后，找到教职依然是很难，何况很多普通本科、大专的教职工资也不高。最顺利的情况读完博后都 35 左右了。
如果是工作的话，真不知道从事什么样的工作。很多时候真想当个三和大神，挣一天花一天的。我初中毕业毕业去打暑假工打过一个月，开注塑机，也饶有兴致。后来读大学的时候大二，周六周末跑三份家教、也送过肯德基的外卖，送过一个月，也去普通的五金厂做过文员、港科大的科创公司也做过、外包公司驻场华为、出海的电子烟公司等等...现在家里还有一亩多地，真想像瓦尔登湖那样，耕种、读书求得内心的平静。
最后一个问题是太孤独了，非常的性压抑，科研单位不像大学，很少看到年轻的面孔，也没有什么社团等等，初中初恋的同学孩子都上幼儿园了，我还是处，甚至是懒得维系什么可能的亲密关系（有一个快聊了一年的网友，天南海北的，基本没可能见面、结婚）。
]]>
低头喝水之前还是正常的,一抬头就这样了,一瞬间不敢相信自己的眼睛 已经排除显卡问题,因为换到其他主机上也是这样
没有进水或挤压之类的意外 也没有很长时间一直亮屏
买来大约 5 年,LG,4K HDR 60 帧 当年还蛮贵,现在估计换一个也就 2K 吧
也很奇怪,每年 618 之前几天都会坏一个东西
这样能修吗?修起来贵吗
]]>之前长期做前端/跨端/ToB SaaS ，近两年在一家线下门店 SaaS 公司做技术合伙人，负责商业球房 SaaS 、收银端 Electron 、Android 点单机、小程序、IoT 灯控、设备监控、越南版 i18n 等，从 0 到 1 和复杂业务落地比较多。
最近两年重度使用 AI 辅助研发，目前每月 Token 使用量大概 10 亿左右，长期使用 Cursor + Claude / GPT / Gemini 等前沿模型。不是简单“让 AI 写代码”，而是围绕真实项目沉淀了一套 AI-Native 工程流程：
除了纯软件，我也深度参与过软硬件一体化落地，包括灯控设备、Android 大屏点单机、收银设备、音箱等硬件的选型、供应商技术对接、成本评估和现场联调。做过串口 / MODBUS / GPIO / Android 原生插件 / Electron 收银端等软硬件结合场景，比较清楚从“软件功能写完”到“客户现场真的能用”中间会踩哪些坑。
我比较适合的方向：
我不是算法科学家，也不包装自己做大模型训练、CUDA 、底层推理优化。我的优势是：
希望找的机会：
不太适合：
如果你正在做 AI 应用、企业 Agent 、SaaS AI 化、AI Coding 研发效能，或者你是创业者但缺一个能把想法快速落地的人，可以聊聊。
联系方式： 邮箱： wangshanbo1932@gmail.com 备用邮箱： 627257359@qq.com
可以先发项目背景、当前阶段、你希望我解决的问题，我会直接判断是否合适。
]]>欢迎反馈，持续迭代中 🚀
]]>3 月的时候，我看到同事有在用扣子平台生成播客语音，用豆包生成图片，他把图片和语音用剪映拼接起来，又加了点字幕就投稿了。内容全是 AI 写的，图也是 AI 生成的，他只是最后用剪映合成了。我惊讶的是他的数据特别好，蹭到了多个名人事件，迅速涨到一万多粉开通了伙伴计划。我那时候一边看，就在想如果把这个流程全自动化，那做视频岂不是很方便！
3 月的时候，我看到同事有在用扣子平台生成播客语音，用豆包生成图片，他把图片和语音用剪映拼接起来，又加了点字幕就投稿了。内容全是 AI 写的，图也是 AI 生成的，他只是最后用剪映合成了。我惊讶的是他的数据特别好，蹭到了多个名人事件，迅速涨到一万多粉开通了伙伴计划。我那时候一边看，就在想如果把这个流程全自动化，那做视频岂不是很方便！
4 月 24 日 DeepSeeK 发布了 V4 版本，我用了一下 v4-flash 模型，速度真快、效果真好、价格真想！当他晚上开始，我就开始设计我脑海里想要的 AI 视频生成软件，2 天时间，第一版软件就做好了。我就开始用它开始做视频投稿，那个时候的视频大概长这样，也没啥播放量。
虽然播放不怎么样，但是流程几乎是全自动的。大概流程是，我把几千字的新闻内容输入到 AI 软件里，后面软件就是全自动执行了。AI 软件把内容发送给 DeepSeek 根据我频道要求生成对话内容和图片提示词，然后使用豆包播客大模型根据内容生成对话语音、Seedream 生成图片、ffmpeg 做合成。
播放量虽然还行，但还是平平无奇，直到 4 月 28 日，那天上午突然爆出新闻大热点。我中午回家吃饭，把热点内容输入软件，软件根据我的流程，过一会就自动生成了对应的新闻内容视频，我投上去没过多久就破了 100w 播放，涨了 2000 多粉丝！从哪开始，一切就步入正轨了！经过 2 个月的努力，我现在的软件长这样个样子：
在前不久，我也发布了这款 AI 软件，在直播间简单宣传了下，结果来了二十多个网友申请试用。甚至有几个网友氪金让我给他定制频道，他们用他生成自己内容的视频。这一切看起来很梦幻！上一个软件我也在这里给大家分享过，上一个书签管理器，结果并没带来多少用户，而且这个软件不但带来了用户，还真真实实带来了收益。我用了十多亿的 Token 做的软件，终于收回了一些成本，并且也确实给用户带来了很大的价值。
有的用户用它来，介绍行业知识。有的用户来用它宣传自己的产品，获取客户。有的用它来做养娃知识分享，自己也能学习养娃知识。还有的朋友，用它做各种新闻报道视频，迅速抓热点生成视频。
目前软件还是处于小范围试用，我写了详细的试用文档，方便大家自己配置，根据教程做出第一个视频来。
软件依旧有不足之处，我每天根据用户们的诉求进行大量迭代和优化，获得很多客户好评。
最后如果你也想体验这款软件，或者仅仅想简单看看比上文更多的细节，可以打开我整理好的飞书文档了解： https://shunying.feishu.cn/wiki/VA6fw0YVci5E6vkcGdScyGKZnNb
马上年过 40 的我，依旧在小公司里拧螺丝，但心里一直有个小小的愿望：希望有一天能做这样一款软件，很多人用上后，都说太棒了，这 TM 就是我要的！
]]>先说结论：坚定不移使用 DeepSeek 。当然我现在事宜 ChatGPT 为主，因为纯用 ChatGPT 根本不够用，经常两天就用光一周的额度，所以开始 ChatGPT + Claude （接入 DeepSeek ），双 AI 协同工作。
Deepseek 确实便宜顶用，我充了 20 元用了很久也没用完，最近开始用得多了，用量上来，又充了 50 元。
智谱本来是冲着 lite 套餐去得，结果压根抢不到，就买了 29.9 元的资源包，结果一个任务包没完成，2 小时用光了。之前也使用过免费赠送的额度，但真要自己花钱买，发现分分钟破产。
起因是我的英文书写水平一般，想借助在 Reddit / X / Hacker News 之类的网站发评论来帮助练习，过去当我有不知道怎么表达时我的做法是
复制文本 → 打开 ChatGPT / 翻译工具 → 说明要改成什么语气 → 复制结果 → 粘回网页
次数多了之后就觉得很打断思路，所以做了一个偏“就地处理”的英文写作辅助插件。 它主要做几件事：
我自己的定位不是做一个很重的 AI 编辑器，而是解决一个小场景： 当你已经在网页输入框里写东西时，希望快速把英文表达修一下，而不是切来切去。 目前还是早期版本，功能比较克制，主要想先验证这个场景是不是有人需要。
Chrome Web Store： https://chromewebstore.google.com/detail/%E8%A8%80%E4%BF%AE/ipdcaanfbcbnbcjafppclolhdgdmkkac
动图 3.gif 
]]>For the past few months, SpaceXAI has been jointly training a model with Cursor, which will be released in Cursor and Grok Build soon.
We look forward to working closely with the Cursor team to advance our frontier AI capabilities
SpaceX 已行使选择权，通过全股票交易收购 @cursor_ai ，旨在打造全球最实用的人工智能模型。
过去几个月里，SpaceXAI 一直与 Cursor 合作训练模型，该模型即将在 Cursor 和 Grok Build 中发布。
我们期待与 Cursor 团队紧密合作，共同推进前沿人工智能能力的发展。
]]>真假自辩
不辨的话，48 小时也就知道了😄
最近又搞了一个新的活，请看⬇️ ⬇️ ⬇️
痛点：我之前阅读了《哲学家的故事》和《西方哲学史》从而对西方哲学历史和哲学思想非常感兴趣，但是除了哲学家的概念比较难理解，也会因为人名太多，概念太复杂，从而看到一半就忘了前面的内容，剩下的内容也一知半解。
其中的经过：
现在 AI 这么强大，以及咱们也是一个 OPC 呀。 于是我就利用 Google AI Studio 帮助自己开发了一个西方哲学家的脉络图帮助自己更好的理解西方哲学内容。这也算是利用 AI 进行信息的转化。整个项目是从昨天中午开始，目前写完 post 结束，全程不超过 24 个小时，完全采用 Google AI studio 进行开发，除了其中的背景音乐是用 suno 生成（不得不说，AI 新时代了，所有的工作和任务，都应该先想想是不是可以用 AI 完成再动手，不然我肯定现在还在吭哧吭哧纠结 youtube 音乐的版权问题）
很好的开源的结果：这个工具是出于我的个人需求开发的，使用起来我发现非常好用，一下就懂了很多哲学思想是怎么出现的，有解决了什么问题，因此分享给大家。
目前这个纯前端的最小可行性产品（ MVP ）已经上线，它涵盖了从古至今主要西方哲学家的全景图谱，核心功能包括：（附图请见文末）
🔗 历史传承线索：一眼看清哲学家之间的师承、致敬与宿命对抗。
🧠 思想与生平闪卡：点击任意哲学家，直观解构其核心思想与生平。
⚔️ 双人对标（ VS 模式）：任选两位哲学家，横向对比他们的核心论点冲突。
👑 降维层级排序：按历史影响力和思想层级重组图谱，看谁才是哲学史上的“真巨人”。
[求拍砖与共创] 网页已经开源/部署在：
https://service-122906596293.europe-west2.run.app
这个工具完全因我个人需求而生，但好东西不该独享。如果大家在使用时觉得缺少了哪位哲学家，或者有什么更酷的交互想法，欢迎在评论区拍砖，期待和社群里同样热爱哲学与技术的朋友一起迭代它！
]]>如果你最近在关注：
1.AI 应用落地 2.云原生架构 3.Serverless / 大模型应用 4.企业数字化
可以考虑去现场看看，免费预约参会
代码在判断 URL 是否为前端静态资源请求时，错误地使用了 strings.HasPrefix （简单子字符串前缀匹配）而非严格的路径段匹配。攻击者可通过构造特殊的 URL （如 /dashboard../data/config.yaml ）绕过安全检查，利用路径遍历读取服务器上的敏感配置文件
无需任何身份验证，攻击者可获取配置文件中的 jwt_secret_key 。利用该密钥，攻击者可伪造管理员 JWT ，实现对整个监控仪表盘的完全控制
https://github.com/nezhahq/nezha/security/advisories/GHSA-5c25-7vpj-9mqh https://nvd.nist.gov/vuln/detail/CVE-2026-53519
]]>尽量加微信聊，不经常在论坛
]]>520 去医院看牙加感冒；
525 去洗牙；
后面一直牙龈肿；
6 月 8 号白天 38.4 ，心跳 143 ；晚上感觉烧的厉害，吃了布洛芬片剂（牙医之前开的）没量体温，吃了个阿莫西林和护肝片，后来怕是肝衰竭没继续吃阿莫西林，不过消化没问题，不腹胀；
不确定时间开始右侧腰部不舒服；
6 月 11 表哥送一堆菜，四个大西瓜，然后给一表弟送过去分，之后加重；
12 号几乎无法躺着睡觉；
13 号因为无法躺着休息，上午继续上班，11 点左左去找医院堂哥开药，要饭后吃，对面拉面馆点完辣条后拿不动筷子，让堂哥接到医院住院；大腿肌发炎，隔膜增厚；
查看了结果。炎症很厉害，胸膜炎加肺炎；
总结：
不感冒不咳嗽唯一感染源可能是牙龈，医生不该在没有在炎症没控制好的情况下给我洗牙；
可能是 8 号发烧时候牙龈都感染进入了血液；
12 号左左可能因为隔膜轻度受损，被血液里来自牙齿的东西感染了，进入肺部。
诸位一定小心身上的小炎症，他破圈了就麻烦了。
]]>
芦苇 Reed · 发现值得看的内容，关注你感兴趣的更新
App Store 下载 · 直接体验 H5 · 了解更多
我们的 ios 应用，90% 的页面都是 web 页面，但是我们页面打开速度很快 [录屏： https://screenapp.io/app/v/DKPHE7vRm6 ] 。（ ps：使用 web 技术栈一方面是因为技术背景是前端，另外一方面是 web 可以一端开发多端使用，当然现在 AI 也非常擅长写 web ，相比 ios 和 安卓。）
开发一个这样的应用成本高吗？
现在我们有很多可以浏览的内容平台，比如小红书、知乎、豆瓣、公众号等等。我平常也喜欢用，但是平台有自己的价值导向，哪怕我狂点不喜欢，也还是会看到很多不想看的内容，所以我想做一个以优质内容为核心的内容平台。
或许一些平台的价值导向也是内容质量，但是最后做到却很难，而我们也在摸索尝试，我们前期通过人工运营的方式（当然也会结合算法做最终的内容推荐），精选了大量我们认可的内容，希望通过这些内容去吸引那些珍视时间、渴望获取高质量内容的人。
]]>
因为我的 DeepSeek 半个月就干了将近 400 块，还是跟 Z.ai lite & chatgpt plus 一起用的
消耗太猛了，想换国内的 浏览了一些贴子，Kimi Mimo MiniMax 风评都很差 那就只有 GLM 的了，但是看了很多帖子都没人能抢到。。 只能在 Z.ai 开通，算算账国外版也贵不了多少。。干脆就直接开 Z.ai max 套餐 以后就猛猛炫 GLM 了！其他的都不开会员不充钱了！
🚀 You’ve been invited to join the GLM Coding Plan! Enjoy full support for Claude Code, Cline, and 20+ top coding tools — starting at just $18/month. Subscribe now and grab the limited-time deal! 👉Join now: https://z.ai/subscribe?ic=QGS1HKZVJ8
]]>曾经历过一次印象深刻的产研项目复盘，会议接近尾声时研发负责人突然说到：其实我们对产品经理要求不高，就是把需求讲清楚，别让我们猜。这句话没有指责，却藏着深深的无奈。
产品经理和研发之间似乎存在着天然对抗：需求变更频繁、信息不透明、沟通成本高昂等等。打破这种恶性循环，往往不靠过人的天赋，而需要一些基础且重要的品质，归纳成关键词就是“靠谱”二字。本文从研发视角，聊聊五项能让研发团队愿意合作且认可的靠谱产品经理特质，并附上实用模板。
很多产品经理容易陷入一个误区，以为产出 PRD 就是完成工作。实际上文档只是载体，真正重要的是背后的思考完整度。
研发最怕遇到的是背景真空型需求，产品经理拿着竞品截图说，这个功能我们也要做，下周上线。当被问到用户是谁、解决什么问题、不做会怎样时，回答是老板要求的或者行业都这样。这种需求本质上是把决策风险转嫁给了研发团队。技术同学被迫在信息不完整的情况下做技术方案，就像让厨师不看菜谱直接炒菜，出锅后又说味道不对。
第一层：业务逻辑自洽。需求服务于什么业务目标？用户路径是否闭环？数据指标如何定义？这些问题的答案不需要长篇大论，但必须经得起推敲，体现出产品思考和判断。
第二层：技术边界感知。不需要会写代码，但要大概知道哪些改动是改个字段，哪些改动是动架构。曾经有个产品经理要求在一周内实现实时音视频通话，却不知道团队从未做过相关技术储备。这种预期错位会直接摧毁团队信任。
第三层：替代方案准备。技术实现总有成本高低之分。如果主方案遇到技术阻碍，是否有降级方案能保证业务目标部分达成？带着选项和研发沟通，会比带着单选题来更让人接受。
研发的时间是线性消耗的。每开一个低效会议，每看一份结构混乱的文档，都是在透支团队的信任额度。
文档方面，见过太多产品经理把 PRD 写成产品说明书，却忽略了技术最关心的异常流程。一个完整的 PRD 应该像代码一样有清晰的层级结构：入口在哪里，正常流程怎么走，每个决策节点的判断条件是什么，异常情况如何兜底。特别重要的是状态流转图，很多 Bug 都源于对状态定义的不一致。
低效会议是另一个重灾区。有些产品经理习惯把研发团队当成思维导图工具，在会议上现场梳理需求。正确的做法是：会前把背景信息给足，会上只做决策和答疑。如果一个会议超过四十分钟还在讨论要不要做，那这个会议就不该开。
语言表达的精确度也很关键。避免使用搞一下、优化一下、处理一下这类模糊动词。研发需要知道具体的业务规则：判断条件是什么，触发时机是什么，数据格式要求是什么。模糊不清的描述会导致实现偏差，最后变成需求理解错了的相互指责。
需求变更在互联网行业不可避免，但如何处理变更最能看出产品经理的段位。
首先要建立变更的透明机制。很多产品经理习惯私下找研发改需求，觉得小改动没必要走流程。这种善意的偷懒实际上很危险，它破坏了项目的整体视图，也让其他协作方失去同步。所有变更都应该被记录，包括变更原因、影响范围、时间点。这不是为了追责，而是为了让团队对项目状态有共同认知。
其次要学会说延迟满足。当业务方提出紧急需求插入时，靠谱的产品经理会先做影响评估：这会挤占哪些已排期的需求？会带来多少额外工作量？然后带着这些数据去和业务方谈判，而不是直接把压力传导给研发团队。有时候，保护研发团队免受频繁打扰，会比满足单个业务需求更重要，且容易赢得信任。
最后要正视技术债。很多产品经理把重构、代码优化视为研发的私事，在排期时不断压缩这部分时间。短期看交付速度提升了，长期则是持续损耗团队战斗力。靠谱的做法是在业务需求和技术健康度之间找到平衡，让研发知道你在为他们争取合理的代码优化时间。
产品经理和研发的关系，很容易被组织层级扭曲成甲方乙方。但真正高效的协作，应该基于共同解决问题为出发点。
让研发参与需求早期阶段是关键。很多产品经理习惯把需求捂到自认为完美时再抛给技术评审，这时候研发只能做可行性判断，很难对需求本身提出建设性意见。提前让技术同学了解业务背景，他们可能会提出你没想到的实现路径，或者指出某个看似简单的功能背后的技术陷阱。
在业务压力下维护技术团队的决策空间也很重要。当业务方质疑为什么这个功能要做这么久时，产品经理应该能解释技术复杂度，而不是跟着一起催进度。这种背书会建立深厚的信任储备。
上线后的反馈闭环常被忽略。研发写了几千行代码，往往不知道最终产生了什么业务价值。定期同步功能上线后的数据表现、用户反馈，让技术同学看到自己的工作如何影响实际业务的，这种正向反馈是最好的激励。
这是考验产品经理决策能力的高频场景，当业务咬死 deadline ，质量又关乎长期健康，如何抉择？
普通产品经理会选择逼研发加班，用人力换时间。这种做法短期有效，但会快速消耗团队信任和个体健康；优秀产品经理会寻找第三选择。重新梳理需求范围，把功能按维度拆成优先级，保证核心链路先上线；或者寻找技术捷径，用临时方案支撑业务验证，同时承诺后续重构时间。关键是让研发参与这个权衡过程，而不是单方面下命令。
最糟糕的情况是隐瞒风险，承诺做不到的事情，最后让研发团队背锅。这种行为的破坏力是长期的，一旦信任破裂，后续所有需求都会遇到更高的沟通成本和更保守的技术评估。
需求背景是否清晰（用户场景、业务目标）
流程图是否覆盖所有分支/逆向/异常状态
非功能性需求是否说明（性能、兼容性、安全）
数据需求是否明确（埋点、统计口径）
是否有明确的验收标准
这个功能涉及哪些系统模块的改动？
是否有外部依赖（第三方接口、硬件设备）？
并发量预估是多少？现有架构能否支撑？
历史数据是否需要迁移或兼容？
是否有合规或安全风险？
变更内容简述
变更原因（业务调整/技术限制/用户反馈）
影响范围（功能模块、已开发部分、测试用例）
预期工作量变化
相关方确认并公示
成为研发心目中靠谱的产品经理，本质上是一个去自我中心化的过程。放下产品经理是需求造物主的幻觉，把自己定位为信息枢纽和决策支持者。
靠谱不是天赋，是一系列可训练的行为习惯。需求多想一层，文档写细一点，变更提前说，压力多自己扛。这些动作做久了，会发现研发团队对你的态度从被动接需求变成主动参与，从防备质疑变成善意提醒。这种协作关系的升级，可能比任何方法论都更能推动产品成功。
]]>AI 电销方向 · 实时语音 Agent 全职 · 语音工程 · 急招
Kapibala AI · WE ARE HIRING · 2026
Kapibala AI Limited 正组建全球化 AI 团队，聚焦 Sales AGI——覆盖获客、触达、谈判、成交、交付全链路的商业智能体，运行于主流 IM 平台和电销领域。产品已进入付费内测，被头部加密交易所、Web3 / RWA 、跨境广告等客户采用，Pre-Seed 轮 1000 万美元已完成。
本岗位是 Sales AGI 语音能力的工程实施者——把 STT / LLM / TTS 三段式对话模型，通过实时语音框架拼接成一套低延迟、高并发、稳定可用的电话语音系统，让 AI Agent 真正能自动拨打电话、用本地语言与客户实时对话。
自有海外支付资源池，支持账号注册 / 续费闭环，不依赖第三方通道，整体成本与稳定性可控。
自建账号池系统，支持自动轮转、自动补充与失效恢复机制，保障持续可用性与服务稳定。
主推用 gpt5.5 pro 号池 0.25 倍率,根据成本动态调整,保证用户最佳利益
支持站长批量接入 可根据流量规模提供额外倍率优惠
]]>核心功能：
更多功能看 GitHub
]]>本文原始发布在: https://www.sunai.net/t/1407
本文使用 claude opus 4.8 协助编写
我身边不少人对 vibe coding 是有怨气的。模型已经够强了，Claude Code 这种工具也摆在面前，但他们的结论往往是：AI 写的代码不可靠，能跑但不敢上线，改一处崩三处，review 起来比自己写还累。
我自己用下来感受完全不一样。同样的模型、同样的工具，产出质量差距很大，差别基本不在模型，而在你有没有把"你这个人/你这个团队的工程判断"喂给它。大多数人把 AI 当成一个许愿池，丢一句话进去等结果；而真正能让 AI 稳定产出可上线代码的方式，是把你脑子里那套"什么叫写对了"的标准，固化成它每次都会读的东西。
这篇就讲我是怎么做的——核心是一个自己写的 code skill 。下面用的所有例子都来自我自己维护的 czl-code-skill 仓库。
skill 这个概念不复杂：一段带触发条件的、可被 AI 按需加载的规则文档。Claude Code （以及 Codex 、Gemini 这些支持同一套 skill-creator 标准的工具）会在合适的时机把它读进上下文，然后照着里面的规则干活。
它和你随手发给 AI 的一段 prompt 的区别在于两点：一是持久，写一次，之后每个会话、每个项目都能复用，不用每次重新交代；二是带路由，它不是一坨平铺的长文档，而是一个入口加一堆分领域的细则，AI 按当前任务只读相关的那部分。
那为什么要写"自己的"，而不是用网上现成的规范？因为编程这件事根本没有放之四海皆准的标准。命名风格、目录结构、该不该用 go:embed、空数据返回 null 还是空对象、Cookie 还是 localStorage 做认证——这些每个团队的答案都不一样，而且很多答案是你踩过坑才定下来的。
AI 不知道你踩过哪些坑。它的默认行为是"统计意义上最常见的写法"，而最常见的写法对你的项目往往恰好是错的。我写 skill ，本质上是在做一件事：把我脑子里那套隐性的工程判断显性化、文档化，让 AI 每次都按我的标准来，而不是按互联网平均水平来。
举个我自己的例子。我的 skill 里硬性规定了新项目根目录必须按端拆分成 server/ web/ desktop/，即使只有一个后端加一个前端也不许扁平化，不许在仓库根放 Go 源码。这不是什么通用真理，是我的偏好。没有这条规则，AI 十有八九会把 main.go 直接丢在根目录——因为大量开源项目就是这么干的。有了这条规则，它每次都拆得很整齐。
这是被问得最多的问题。Claude Code 本来就会读 ~/.claude/CLAUDE.md（全局）和项目根的 CLAUDE.md（项目级），把规则写那里不就行了？
不行，而且这俩根本不是一个东西。我是这么分工的：
项目级 CLAUDE.md 是"这个项目当前长什么样"的快照。 它写的是事实，不是规范：这个项目用什么架构、有哪些目录约定、对外接口的路径和错误码、哪些地方有反直觉的坑（"该模块禁用 SSR 因为……"）。它是给"未来接手这个项目的 AI 或人"看的说明书。我的 skill 里专门有一节约束它怎么写，第一条就是禁止写流水账——不许写"本次新增/本次修复"，不许写日期戳加改动列表，不许堆 changelog 。判断标准我写得很直白：一句话三个月后读起来像考古笔记，就不该出现在 CLAUDE.md 里。同时限定项目级不超过 300 行，超了多半是塞了流水账。
skill 是"我这个人写代码的方法论"，跨项目不变。 改动该大改还是小修怎么判断、动手前要穷举哪些边界、写完怎么自审、文件多长该拆、命名用哪种 case——这些和具体项目无关，是我对"什么叫写好代码"的定义。它们不该塞进每个项目的 CLAUDE.md 里重复一遍。
还有一个很现实的原因：体积。如果把我所有规范都堆进 ~/.claude/CLAUDE.md，那玩意会变成几千行的巨物，每个会话无脑全量加载，挤占上下文不说，还拖慢响应、稀释注意力。skill 的路由机制天然解决这个——主文件很小，细则按需读。这点下面专门讲。
一句话区分：CLAUDE.md 回答"这个项目是什么样"，skill 回答"我写代码该怎么写"。 前者随项目走，后者跟着我走。
结构上就两层：
顶层一个 SKILL.md，是唯一带 frontmatter 的入口文件。 frontmatter 里写 skill 名字、描述和触发词——触发词很关键，它决定了 AI 在什么场景会想起来加载这个 skill 。我的触发词列得很细："写代码、改 bug 、重构、新建项目、改 UI 、加 API 、改 CLAUDE.md 、Dockerfile 、命名规范、Go 包结构、PWA 、Service Worker 、拆文件、文件太长……" 列得越具体，命中越准。
SKILL.md 正文我只放三样东西：默认架构（新项目默认用什么技术栈）、规则优先级（用户要求 > 现有项目约定 > 领域规范 > 默认规则，冲突时照这个顺序来）、还有一张触发词到 references 的路由表。正文不展开任何细则，每条规则就一句话要点加一个指向 references 的链接。
references/ 目录放具体规则，每个文件一个领域，都是普通 Markdown ，不带 frontmatter 。 我现在拆成了这些：coding-standards.md（通用编程规范）、go-backend.md（ Go 后端）、nextjs-frontend.md（ Next.js ）、frontend-design.md（ UI 视觉，下面还按颜色/字体/布局/loader 再拆了子文件）、pwa.md、stripe-webhook.md 等等。
路由表长这样（节选）：
| 任务关键词 | 必读 references |
|---|---|
| 通用规范 / 改动幅度 / 自审 / 命名 | coding-standards.md |
| Go 后端 / 包结构 / GORM / 时区 | coding-standards.md + go-backend.md |
| Next.js / static export / Shadcn | frontend-common.md + nextjs-frontend.md |
| PWA / Service Worker / manifest | pwa.md |
AI 接到任务，先读小小的 SKILL.md，从路由表查出该读哪几个 references ，再去读那几个。改 Go 后端就不会去加载一堆 UI 视觉规范。
有个写作上的硬约束我一直在坚持：skill 和 references 里只写规则和逻辑，不写代码块。 字段名、命令名、API 名用反引号标一下就够了，连反例正例都改写成自然语言描述。原因是代码块特别容易过期，而且会诱导 AI 去照抄那段具体代码而不是理解背后的规则。例外只有极少数确实需要"必须能直接复制"的东西——比如 PWA 那个 no-op service worker 的完整实现、品牌 loader 组件的完整实现，这种才允许放整段代码。
这是我觉得最反直觉、也最值钱的一条经验：skill 的质量上限，很大程度上由"拆得够不够细"决定，而不是"写得够不够多"决定。
很多人写规范文档的直觉是堆成一个大全。一个文件几千行，从命名到部署到 UI 到安全全在里面。这个东西的问题不是它"不全"，而是它没法被精确加载。AI 要么全读（上下文爆炸、注意力稀释），要么不读（规则形同虚设）。
我的做法是反过来的：一个方向、一种特定要求，就单独一个文件。 颜色规范、字体规范、响应式规范、布局组件规范、loader 规范，我全拆开了。frontend-design.md 只是个主索引加全局 token 清单加自检清单，具体到配色去读 1-color.md，具体到布局组件去读 4-layout-and-components.md。
这么拆有三个好处，按重要性排：
1-color.md，不用在巨型文件里翻来覆去找。判断拆不拆，我用的标准和我对代码的标准是同一套——基于职责，不是基于行数。一个 references 文件只承担一个领域的规则。如果一个文件同时在讲后端错误处理和前端动画，那它就该拆，哪怕它才 200 行。反过来，一个讲 Go 后端完整规范的文件就算 500 行，只要它职责单一、删哪段都伤完整性，那就不拆。
顺带说，这条"按职责拆而非按行数拆"的原则，我同时也写进了 skill 里去约束 AI 写的代码。skill 里的硬规则是：单文件、单函数承担的独立职责不超过一个；行数（文件 400 / 组件 300 / 函数 80 ）只是触发你停下来评估一次的信号，评估结论完全可以是"职责单一，不拆"；但文件超 600 行 / 函数超 200 行还决定不拆的，必须在文件头注释里写清楚为什么不拆——写不出来就说明其实该拆。规则自己也遵守自己定的规则，这种一致性本身就让整套东西更可信。
把 skill 装到 ~/.claude/skills/czl-code-skill 只是第一步。装了不代表会被用——AI 有它自己的判断，可能觉得"这个小任务不用加载吧"就跳过了。我吃过这个亏：明明装了 skill ，它改个小文件时压根没读，产出还是默认风格。
解决办法是在 ~/.claude/CLAUDE.md 里显式下一道强制加载的指令，把"什么时候必须加载 skill"这件事本身也变成硬规则。我的全局 CLAUDE.md 里有这么一段（这里贴的是我实际在用的）：
强制加载 czl-code-skill （硬规则）
违反本节属于硬错误，不是"风格问题"。本节优先级高于任何"任务太小""我已经知道了""快速回答"的自我判断。
触发条件：只要本次任务涉及"代码 / 项目 / 配置 / 工程文档"中的任何一项，必须通过 Skill 工具加载
czl-code-skill，由 SKILL.md 路由到对应 references ，然后才能继续后续动作。
关键设计有这么几点，每一点都是被实际问题逼出来的：
这一层是很多人漏掉的。光写 skill 不够，你得用更高优先级的全局指令保证它真的被读进去，否则写得再好也是摆设。
前面讲的都是结构和加载机制。但 skill 真正决定代码质量的，是里面装了什么规则。如果让我只保留三条，我会保留下面这三条——它们直接对应"AI 写的代码为什么不可靠"这个问题的根因。
AI 写代码有两个非常稳定的失误模式：一是只顺着你描述的那条正常路径写，边界和异常分支全靠运气；二是写完就交付，从不回看自己写了什么。这俩加起来，就是"能跑但不可靠"的全部来源。这三条规则就是专门治这两个病的。
动手前：穷举边界与分叉。 我在 skill 里要求，接到需求或 bug 后，先在脑子里（或 todo 里）显式列出六个维度的清单，再动笔。不是写注释，是逼它"想过"：
清单不要求每条都写代码处理，但要求每条都明确表态——处理、显式忽略、还是不适用。选"忽略"或"不适用"的，要在交付说明里点出来让我能复核。这一条把"AI 顺着 happy path 开写"这个最大 bug 来源直接堵死了。
动手后：完工自审。 单个需求改完，不许立刻交付，先用 reviewer 的视角重走一遍。我列了九条，核心几条：
自审发现的问题当轮直接修掉，不许写进 TODO 留给下一轮（除非正交于本次需求、或依赖外部资源拿不到）。
还有一条我也归在这组里：改动幅度决策。 AI 有个很坑的默认倾向——把"最少行数变更"当成最安全的方案，结果就是绕开真正的痛点、在烂代码上继续打补丁。我在 skill 里明确写："现有项目优先"指尊重既有架构，不是默认选最小改动。每次非平凡改动都要做一次幅度评估：先识别有没有结构性痛点（重复逻辑、错误抽象、修一处带一串），再评估"局部修补 vs 一次性重构"两条路，然后给出明确推荐而不是把两条路一摆让我选，最后由我拍板。同一段逻辑在三处以上重复、抽象已经和实际用法偏离、某模块反复出问题、用户描述的是"每次都要……"这种痛点——这些信号出现时，倾向推荐重构。
这三条（穷举边界、完工自审、幅度决策）是整个 skill 的灵魂。架构和命名规范决定代码长得好不好看，这三条决定代码可不可靠、敢不敢上线。如果你的 skill 里只来得及写三条，写这三条。
最后一条，也是最容易被忽略的：skill 不是一次写完就放那的，它是活的。
我的工作流是这样的：每次和 AI 协作中，只要冒出一个"值得落盘的东西"，我就把它写进 skill 。什么叫值得落盘？标准很简单——这个东西换个项目、换个会话还会再遇到，而且我不写下来 AI 下次还会犯同样的错或者错过同样的判断。
几个真实例子，都是后来补进 skill 的：
go:embed 把前端产物嵌进二进制。我当时没说要这么干，它自作主张。我意识到这是个会反复出现的默认行为，就在 skill 里加了一条：Go 托管前端一律用 http.FileServer 挂 out/，禁止 go:embed，单二进制零依赖分发是唯一例外且要在 CLAUDE.md 记录。stripe-webhook.md，把"强制用 metadata.app 标记项目归属、入口处按归属过滤、验签和返回码语义、幂等"全写进去。下次任何项目接 Stripe 都不会再踩。每一条规则背后，基本都是一次真实的踩坑或一次真实的"AI 默认行为不符合我预期"。skill 的价值就在于：同样的坑我只踩一次，之后它替我记住。 这是它和一次性 prompt 最大的区别——prompt 是消耗品，skill 是资产，会复利。
具体怎么维护我也有约束，免得它自己也长成一坨流水账：加新规则前先判断属于哪个 references 文件，在已有小节里扩展，确实无法归入才新建文件；同类规则不在多个文件重复写，用相对链接交叉引用； SKILL.md 主索引保持精炼，详细规则下沉到 references 。改完一定要跑同步脚本推到各个工具的 skill 目录，否则本地实际加载的还是旧版。
把这七条连起来看，其实是一个很朴素的逻辑：
AI 不可靠，不是因为模型笨，是因为它不知道你的标准，也没有强制它对照标准的机制。skill 干的就是这两件事——把你的工程判断显性化成它每次都读的规则，再用全局指令强制它每次都读。
写自己的 skill ，按方向拆细、按需加载，把"动手前穷举边界、写完必自审、该重构就推荐重构"这几条灵魂规则装进去，再持续把每次踩的坑沉淀回来。做到这些，你会发现 AI 写的代码不仅快，而且是真的敢上线的那种可靠。
vibe coding 不是把脑子交出去，是把你脑子里那套标准，变成 AI 的标准。
]]>
专家模式，经常用不了
]]>