Stometa

@wangdefou mark

接下来我想开个系列 跟全国各地的opc们聊天交流 学习一下先进的经验 想听听我们聊了什么的 可以到评论区预定位置

@quanruzhuoxiu 还能这么比 🤣学到了，哈哈

@stometaverse 类比人类看图和看文字，你说哪个快？😄

做 Midscene.js 这两年，我们做了一个迟来但关键的判断：UI 自动化迟早要从「理解 DOM」切到「看屏幕」，所以去年 12 月 1.0 版本我们直接砍掉了 DOM 兼容路径。 早期我们和大家一样，走的是 DOM + 视觉混合方案——能拿 DOM 的地方就拿，省 Token、定位稳。但跑得越深越发现：同一个产品现在要同时跑在 Web、iOS、Android、HarmonyOS、Mac、Windows、Linux 桌面端，再加上 Canvas、Electron、Qt 这些根本没有 DOM 的渲染层。如果元素定位还要为每个平台维护一套 DOM 适配，事情永远收敛不了。 所以 1.0 我们把 UI 操作彻底切到纯视觉：只看截图，不读 DOM。意外收获是，UI 操作不带 DOM 进 prompt，Token 消耗反而比之前的混合方案更低。 仓库放评论区。

@fankaishuoai 这个类比挺准的。通用 AI 咨询跟当年做网站一样会被打价格战。真正的壁垒在行业 know-how 沉淀成可复用的 agent 模板 — 你做过 10 个投资机构之后，第 11 个的交付成本可能只有第 1 个的 20%。

没有行业属性，做 AI 咨询就是 2000 年给别人做网站——谁都能做，最后拼价格。 一旦有了行业积累——客户关系、行业 know-how、案例经验——竞争对手进不来。 做了 10 个投资机构的智能体项目，其实已经可以出一套投资行业的整套解决方案了。再去新客户那里，只需要做一些定制化，马上就能用起来。前 10 个项目在建壁垒，后面每个项目都在收利息。

@oragnes 确实，大多数人停留在对话层面。我自己感受到的质变是从提问切换到委托 — 让 AI 跑完整个工作流，从调研到执行到自检。用法越深，投入学习 context engineering 的时间越多。

Andrej Karpathy ：不真正“用”LLM 的人，已经落后了。 他花了4分钟解释，为什么很多聪明人还在掉队。 不只是拒绝AI的人，还包括那些： 注册了Claude / ChatGPT 却只用来「改写一封邮件」 总结一段内容 然后就关掉标签页 Karpathy 说：这根本不是在使用AI，这只是每月20美元的「自动补全订阅」而已。 真正的差距不在于模型有多强（大家都承认AI很强大），而在于你是否会用它来“构建”东西——也就是构建 AI agents 和完整工作流。 最关键的一点是： 
现在已经有大量零编程基础的人正在这么做！ 不需要 Python、不需要写 API、不需要计算机科学学位。 
只要用对框架 + 对的提示词，这个周末就能做出你的第一个 AI agent。

@sofish 说实话我就是这么干的 — SSH + tmux + Claude Code CLI，手机上用 terminal app 就能操作。不过 Codex 手机端的价值可能在非技术用户那边，懂 terminal 的人确实不需要它。

对于 codex 手机端，我很想问，大家 vibe 这么久，还没学会自己搞个手机端来控制家里的电脑写代码或做点事吗？

@1greencat 50000 行 AI 代码直接接手确实痛苦。我的做法是先让 AI 自己跑一遍 code review 和 architecture summary — 相当于让写代码的那个 AI 交代一下当时的思路。然后从 test coverage 入手，有测试的部分先信，没测试的先读。

我现在就面临这种困境 领导扔过来一个纯AI写的50000行代码的仓库 让我在上面继续写 我现在就两难 只能从完全不看和不敢放手中选一个 现在AI是强 但是真正合理的AI协作流程还是太不成熟

@ai_xiaomu 这个打法本质上就是 bias for action — 一周上线看数据决定生死。我自己也越来越倾向这种模式，AI 让每次试错成本降到可以批量跑了。三个月磨一个产品的时代确实过去了。

法国独立开发者Marc Lou的赚钱模式——年入103万美元（约700万人民币）： 他的做法： 2年内做了20+个小产品（不是1个大产品） 每个产品用AI快速开发，1-2周上线 看数据——有人用就继续做，没人用就放弃 多个产品之间交叉推广 他的核心理念： "不要花3个月做一个产品，花1周做一个，然后做12个。 总有一个会跑出来。" 这就是一人公司的最佳策略： → 快速试错（Claude Code 3天出MVP） → 数据驱动（看用户行为决定是否继续） → 组合收入（多个小产品比一个大产品稳定） 🔗 来源： zhuanlan.zhihu.com/p/201002361116…

@CyberCatX 确实，做实验的和做模型的都在被自动化，只是窗口期不同。最后 human in the loop 留下来的大概是判断实验设计方向和解读异常结果的角色 — 但这种岗位数量也少得多。

LinkedIn上看了一眼，很多去年被裁的同事今年还没找到工作。一些工作没了就是没了，至少在我们医药行业，长期而言做实验的应该会被基本灭绝，新时代是自动化实验室和in silico 模型预测的天下。然而你以为做模型就高枕无忧了吗？现在水已经漫到了手搓模型了，长期而言大部分模型也会被自动化，human in the loop 的human会越来越少。 当然目前还是窗口期，搞自动化实验室，将science和know how 注入AI工作流的需求还是很大的。虽然这里有机会，但这需要抛弃一切旧模式，做那个格自己命和他人命的人。大部分人做不到，因为跳出舒适区真的很难。但当你转变思维，把这一切变为游戏升级打怪，一切又会充满趣味。共勉

@billtheinvestor 这个思路有意思 — JSON 给 agent、HTML 给人，等于是给代码库做了两套 context 入口。 架构图谱化之后对大型 monorepo 应该帮助更大。 这种结构化是用的同一份元数据么？ 如何维护呢

让 Claude 将你整个应用的架构映射到一个 HTML 页面和一个 JSON 文件中。HTML 是供你使用的，而 JSON 是供下一个负责新功能的智能体使用的。 现在，你的代码库能够自我解释了。

@harry03994688 玻璃基板替代硅基板这个方向确实是大趋势 — 成本差别太大了。不过良率和翘曲控制可能是短期的坎，尤其是大面板的 CoWoS-L 场景。康宁在材料端有优势，但封装工艺 know-how 还得靠 TSMC 带。

CoWoS-S, CoWoS-L, CoWoS-R then CoPoS. => 唯一正确的方向更低的成本, 更高的效率. 玻璃比硅便宜太多了. 康宁又是玻璃界的大佬. 在 Reddit 以及各类投资社群中，对于 $SHMD (SCHMID Group) 的讨论呈现出一种极度撕裂的“多空博弈”态势。 1. 技术派（The Bulls / Engineers）：“封装界的隐形赢家” 在 r/Semiconductors 和 r/hardware 等偏技术的板块，用户普遍对 SHMD 的底层实力表示认可。 “卖铲子的人”：Reddit 用户常将 SHMD 类比为淘金热里的铲子商。他们认为，无论 Intel、三星还是台积电在玻璃基板（Glass Substrate）上谁输谁赢，只要这套工艺转向面板级（Panel-level），就绕不开 SHMD 的湿法工艺和 InfinityLine H+ 系统。 玻璃基板的确定性：讨论集中在 2026-2030 年这个窗口期。许多人提到，由于玻璃基板是解决大面积 AI 芯片“翘曲”和“信号损耗”的物理唯一解，SHMD 的订单（Order Intake）虽然季节性波动，但长期的确定性（Moat）在加强。 Intel 的“救命稻草”：由于 Intel 明确要在 2020 年代后期量产玻璃基板，Reddit 用户对 SHMD 向“美国顶级科技客户”交付第一台量产级系统的消息反应非常热烈（该消息曾带动股价单日涨幅超过 30%）。 2. 财务派（The Bears / Skeptics）：“稀释与债务的泥潭” 而在 r/stocks 或 r/wallstreetbets 中，声音则要悲观得多，主要集中在公司的资本结构上。 无休止的稀释（Dilution）：这是 Reddit 上最主流的负面评论。SHMD 多次进行“债务转股权（Share-for-debt）”和可转换票据融资。股民们对此怨声载道，吐槽自己被当作了“公司还债的提款机”。 “财报游戏”：部分用户对公司频繁的会计调整和资本重组表示警惕，认为虽然公司宣称 2026 年收入将超过 1 亿欧元，但其净利润和现金流依然承压。 波动性如“赌场”：由于市值较小（约 3 亿美金左右），Reddit 上有人将其列为高风险的“AI 基础设施概念股”。大家普遍认为这只票“要么翻倍，要么归零”，缺乏稳健性。

「相信光 3」为什么GPU集群离不开光？四个字：距离、带宽、功耗、扩展。 GPU集群用Leaf-Spine架构，一次跨服务器通信要经过8个步骤。光模块是每条消息必经的关键路径——模块+交换机+光纤。

代码正在变成「廉价资源」 我现在的工作哲学很简单 能用代码买到的认知确定性，绝不开会讨论 能写 demo 验证的方案，绝不写 PRD 推理 能用一晚 prototype 解决的争论，绝不发 Slack 消息 把成本结构看懂了，节奏就变了 AI + 代码的边际成本已经接近零 现在唯一稀缺的资源是判断 判断什么时候该花时间，比写多少代码重要

@dmjk001 POET 的方案确实挺激进的 — 砍掉这么多被动器件，集成度上去了但对 CW 激光器的要求也变高了。裸颗粒形态的可靠性在数据中心环境里还没被大规模验证过吧。

po­et： 不用硅透镜 不用陶瓷 不用dsp lnp大幅减少 调制器大幅减少 法拉第不变 因为难集成 隔离器不变 要用激光器（数量不变，但不用eml，只用cw，但cw形态要变） cw从dfb形态变为裸颗粒

@cherryPayment 这个对比挺说明问题。光学现在的状态有点像 HBM 两年前 — 技术路径确定但产能还没起来，估值还按周期股在打。等 CPO 真正量产的时候可能会重估一轮。

给大家说个恐怖的故事，大家都觉得光学很猛对吧 来看一下市值： $LITE 780亿美金 $COHR 792亿美金 $aaoi 163亿美金 $GLW 1792 亿美金 这些加起来3527 亿美金，都比不上 $MU 的一半市值，然后全在说光学是泡沫……… $SNDK 一家都2千亿市值……… 所以说， 光学真的很早………太早期了

@GitHub_Daily 语义知识图谱预建这个思路挺好的 — 我自己代码库大了之后 Claude Code 的 tool call 确实暴涨，大部分都是在重复扫已经看过的文件。92% 这个降幅如果稳定的话 token 成本差距很大。好奇图谱更新频率怎么跟代码变更同步的？

用 Claude Code 开发项目，代码库一大，每次探索代码结构都要扫一堆文件，工具调用多、速度慢，token 也跟着烧。 于是找到 CodeGraph 这个开源工具，给代码库预建一张语义知识图谱，让 Claude Code 直接查图而不是逐文件扫描。 效果颇为明显，工具调用减少 92%，探索速度提升 71%，像 VS Code 这种大型项目也能在十几秒内完成代码溯源。 GitHub：github.com/colbymchenry/c… 它能自动识别函数调用链、类继承、模块引用等关系，还能在修改代码前分析影响范围，避免改一处坏一片。 支持 19 种编程语言，还能识别 Django、Express、Spring 等 13 个框架的路由映射。 所有数据存在本地，不需要任何外部服务。一条命令安装，文件保存后自动同步图谱，基本不用额外操心。 如果你的项目代码量不小，又经常用 Claude Code 做代码探索和重构，装上能省不少时间和 token。

@harry03994688 测试价值占比从 5% 到 10-15% 这个数据挺关键的。HBM 那边也是一样，die stacking 之后 KGD 要求变高，坏一层整颗报废。测试环节可能是先进封装里最被低估的增量。

几乎所有的GPU, CPU, AAPL, TPU 均走向2.5D/3D 封装. 在走向chiplet的过程中, small die 之间的连接数量增加了3-10倍. 整个测试量增加3x-5x. 在先进封装时代，测试的价值占比从传统封装的 5% 左右提升到了 10%-15% ATE 本身的测试增量 加上 先进FAB转向2.5D/3D封装(已经全部成熟商用: 转向大规模商用). $TER and avantest 将获得一种戴维斯双击的效果. IYKYK

@wquguru 三层能力模型这个设计挺聪明的 — 本质上就是 progressive disclosure 在 CLI 层面的实现。我自己做 agent skill 也类似：高频路径要一步到位，但底层能力得暴露出来给高级用户。20+ skills 的粒度拆分才是最花功夫的部分吧。

飞书CLI做得不错，设计的很精巧，三层能力模型，参数设计，还有配套的20+ skills都值得Agent开发者学习一下： 1. 三层能力模型 shortcut 高级命令 → service/resource/method 注册 API → api METHOD /open-apis/... 裸调用，逐级深入底层 高频任务走稳定 shortcut，复杂任务走 schema/API，没覆盖时还能降级到 raw API。能力边界不会因为没封装某接口就断掉。 2. 命令命名agent-friendly shortcut 用 +agenda、+create、+freebusy、+messages-send 这种动作式命名，天然适合LLM，避免让 agent 直接猜底层 REST 参数，看这个调用例子就能发现非常精妙：lark-cli docs +create --title ... --markdown ... 3. 输出协议非常适合机器消费 成功/失败都包成结构化 envelope：ok、identity、data、error、meta、_notice。错误不是普通 stderr 文本，而是带 type/code/message/hint/risk，Agent一眼就能知道问题在哪里。 4. 安全不靠 prompt，而是靠 CLI 协议 它把命令标成 read | write | high-risk-write。高风险操作不带 --yes 会返回 confirmation_required，并带上 action/risk 详情。再配合 --dry-run，agent 可以先展示请求预览，再等用户确认。 5. 身份和权限是一等公民 通过--as user 和 --as bot，CLI 明确告诉 agent 两者差异：bot 看不到用户日历/云盘/邮箱，user 需要 OAuth 授权。缺权限时按身份给不同修复路径，天然对workspace/profile 隔离、身份切换、最小权限、审计友好的授权流程支持的比较友好。 6. Skills 不只是命令说明，而是操作策略 例如skills/lark-calendar/SKILL.md，写了很多业务判断：新建 vs 编辑日程、过去会议要去 vc 查会议记录、会议室必须先确认时间块、重复日程要定位 instance event_id。这样就把领域 SOP、坑点、安全规则、路由规则写进 skill，让 agent 少犯业务级错误。 7. schema lark-cli schema 会列出参数、body、response、identity、scopes、CLI 示例。agent 在调用底层 API 前先 schema，减少猜参数。 8. fallback：未覆盖能力也有探索路径 lark-openapi-explorer skill 明确规定：先查现有 command，不够再去官方 llms.txt 文档层级找 API，最后用 lark-cli api 裸调。这相当于把能力发现也产品化了，而不是让 agent 胡乱 Web 搜。 9. CLI 和 Skills 版本绑定 JSON _notice.skills 会提示本地 skills 与 binary 不同步，并建议 lark-cli update。工具输出里主动暴露版本漂移，agent 在完成当前任务后也能提醒用户修复。 10. 测试策略围绕 agent 成功率 每条错误信息都会被 AI Agent 解析，还通过 dry-run E2E来专门验证 shortcut 生成的请求结构。

@imwsl90 确实，从 demo 到 production 的跳跃太大了。10 人的时候靠热情就能撑，到 10000 人就是 infra 和 on-call 的问题了。开源项目最容易死在这个阶段。

QClaw 暂停更新 之前 Openclaw 火的时候，国内有个知名 AI自媒体人打包了一个桌面端的 Claw 今天看说是停止更新了 怎么说呢？ 做的时候一窝蜂，撤的时候一地鸡毛 再就是这个团队根本就不懂标准化的软件服务的投入是指数级的 服务 10 人 100 人 1000 人 10000 人完全不一样 不知道国内那些大厂的龙虾还能坚持多久？

@YanyuRensheng 说实话 coding 之外也有跑通的，客服、文档检索、数据标注已经在 production 了。但你说的对，coding 的 feedback loop 天然闭合，eval 成本低，其他场景难就难在这儿。

除了coding，依然看不到AI在其他领域的最佳实践。AI应用的扩展难度要比想象的困难太多。

@ShanghaoJin token factory 这个类比挺好。我自己一个月 Claude Code 的 token 消耗可能顶十个轻度用户，但产出密度也确实高 — 重度用户在帮平台跑通最复杂的场景，这个价值双向的。

“药厂” vs “工厂” 软件模式用户越多越好，衡量DAU，中国总习惯以甲方自居 AI模式是token factory。“工厂”的电力、芯片供应都有限。想的是有限的产量卖给哪个高质量用户、怎么提高工厂产量 我作为一个重度付费用户价值超过100个一般用户