Reddit AI Coding - 2026-06-23¶
1. 人们在讨论什么¶
1.1 可靠性故障成了当天最主要的工作流风险 🡕¶
跨 subreddit 最强的共同信号不是新模型发布，而是服务正在出问题。Claude Code 用户描述了运行变慢、500 错误，以及会话退化到他们“基本上又回到手写代码”的程度；与此同时，Antigravity 用户也报告了类似的依赖风险——当他们用它去收尾 Claude 或 Codex 已经开始的工作时，同样会出问题。至少有 4 条高信号帖子和评论，在 r/ClaudeCode 与 r/google_antigravity 里共同支撑了这个主题。
u/MessageEquivalent347 说 Claude Code 已经变得“又慢又卡”，而 u/CochainComplexKernel 的高赞回复（得分 31）补充说，更大的问题是它看起来“更笨了”，还会产出隐藏错误，最后还得用户手动修掉（帖子）（79 分，73 条评论）。
u/Historical-Car-8489 和 u/active_slotter 分别发帖贴出了完全相同的 Claude 报错字符串——“API 错误：500 服务器内部错误”——其中一张附图还显示 Claude Status 页面同时列出了“多个模型的错误率升高”以及仍然可见的 Fable/Mythos 暂停通知（帖子）（43 分，45 条评论）；（帖子）（53 分，49 条评论）。
同样的模式并不只出现在 Anthropic 工具里。u/Shik3i 说 Antigravity 连当备用工具都已经不可用了，而 u/BeyondAdventurous167（得分 17）表示，自从 3.5 Flash 发布后，服务质量就一直在变差（帖子）（74 分，80 条评论）。
讨论要点： 好几条回复都把 Reddit 本身当成状态页。u/The_Mr_Suit（得分 8）说：“我真的是直接打开 Reddit 看是不是出了什么事。”而 u/SoundDr（得分 5）自称是 Antigravity DevRel，也进到故障讨论串里询问具体模型和区域信息。
与前日对比： 这延续了 6 月 22 日关于可靠性的故事。昨天的报告已经写到用户不信状态页、转而在讨论 outage；到了 6 月 23 日，又新增了直接的 500 错误截图，以及更广泛的“它又慢又更差了”的用户证词。
1.2 GLM 5.2 从基准榜单里的新鲜话题，变成了在线备用方案 🡕¶
开放模型替代方案的势头还在继续增强。6 月 22 日围绕 GLM 5.2 和 MiniMax M3 的讨论仍在延续，但到了 6 月 23 日，话题已经从围观排行榜，转向了更具体的路由建议：怎么接入 GLM、什么时候该用它替代 Claude，以及怎么把它接进自动化智能体流水线。
u/sandofvega 认为，既然 Fable 5 已经不再参与采样，GLM-5.2 几乎就是“当前可用的第 1 编程模型”，而帖子附图也显示它在 Arena.ai 上总榜排名第 2，仅次于 Fable 5，高于多个 Claude 变体（帖子）（197 分，84 条评论）。
这条讨论的重点已经不只是纯粹的质量，而是接入方式。u/01KidCharlemagne（得分 16）说，Cursor 用户可以通过 Nebius 的自定义模型配置接入 GLM，而 u/montesremotedev（得分 19）则说，模型种类够多，几乎就是他们还继续保留 Cursor 的主要原因。
u/julianfromstagewise 更进一步，直接把 GLM 5.2 推荐成 outage 期间的在线备用方案，说它已经在日常编码里取代了 Opus，而且 API 成本大约只要后者的五分之一（帖子）（37 分，63 条评论）。最详细的回复来自 u/siberianmi（得分 6），他描述了一套基于 Pi 的工作流：先用 Opus 做规划，再把具体编码分派给智能体，在智能体控制之外跑自动化测试和审查，并且 10 天内已经处理了“超过 120 个 issue”。
讨论要点： 社区对 GLM 的热情并不是无条件的。u/P1zz4-T0nn0（得分 15）称它是“benchmaxxed”，意思是它会狂烧 thinking tokens，到了更深的任务就会掉链子；另一条回复则提到偶尔会看到 overload 警告。
与前日对比： 6 月 22 日只是确认 GLM 已经是一个可信的榜单竞争者；到了 6 月 23 日，人们已经开始把它真正接入路由层，拿来当 outage 对冲方案。
1.3 开发者持续在围绕智能体工作流建设基础设施，而不只是做终端应用 🡕¶
当天最强的一批 builder 帖子，并不是给单一提示词套壳的应用，而是工作流界面、运行时基础设施，或者那些默认智能体已经进入日常工作的高技术门槛演示。这个主题横跨了课堂 demo、逆向得到的客户端、技能管理工具，以及复古游戏实验。
u/ImplementInternal673 分享了一个基于浏览器的摄像头风格重绘项目，用户可以通过手势控制；源码显示它在浏览器里用了 Google MediaPipe Hand Landmarker，并通过 fal-ai 的 flux-2/klein/realtime endpoint 做实时风格迁移（帖子）（255 分，28 条评论）；CameraRealtimeStyle。
u/jkFujinami 发布了一个面向 Antigravity 2.0 的浏览器客户端，它复用了 Language Server，注入类似 Electron 的全局对象，并通过 HTTP/2 提供原版 UI，从而可以在普通浏览器甚至手机上运行（帖子）（51 分，7 条评论）；repo。
u/alvinunreal 则做了一个更偏运营层面的工具：LazySkills。这是一个终端 UI，可以盘点已安装的智能体技能、检查哪些助手实际上能看到它们，并标记损坏安装或失效链接（帖子）（17 分，2 条评论）；site；repo。
其他技术含量很高的项目也延续了同样的模式。u/No-Wishbone7899 介绍了一个用 Rust 和 wgpu 做的 41 万粒子实时水模拟，Claude Code 帮助把确定性物理 crate 包和渲染外壳拆分开来（帖子）（62 分，11 条评论）。u/lee337reilly 则把 Quake 移植到了 WebAssembly，加入了程序化地图、捕获/分享工具，甚至还加了一个 copilot 控制台命令（帖子）（16 分，2 条评论）；repo；在线演示。
讨论要点： 即便这些帖子看起来有些玩票性质，落实到开发细节时却一点也不轻。CameraRealtimeStyle 的说明文件明确写了 MediaPipe + fal + Node/Express；Antigravity 客户端的说明文件记录了直接访问语言服务器的方式以及浏览器传输约束；Quake 的说明文件则写清了 WebAssembly、SDL2 适配层和社交分享功能。
与前日对比： 6 月 22 日的 builder 故事本来就已经很强，但 6 月 23 日更明显地偏向了为智能体工作流本身服务的工具：浏览器远程访问、技能管理，以及围绕 AI 编程搭建的自动化界面。
1.4 分发和变现依旧比构建更难 🡒¶
这些变现讨论串并没有说“写代码很难”；相反，它们把发出来的成本视为很低，把获取受众看成真正的瓶颈。证据一部分来自对拥挤赛道的分析，另一部分则来自规模不大但很具体的收入截图。
u/javialvarez142 提问说，为什么那些 AI 卡路里追踪器 clone 明明已经明显饱和，还是能做到大约 $1k-$5k 的 MRR，而附图也展示了一长串几乎一模一样、但依然在赚钱的产品（帖子）（102 分，49 条评论）。
最高赞的解释来自 u/WanderingGalwegian（得分 103）。他认为，这个品类的运转方式更像订阅制健身房：反复出现的情绪驱动、高流失率，以及足够多会不断“重置购买决策”的新买家，所以还能再养活一个 clone。另一条分数较低的回复来自 u/bugra_sa，他说真正难的不是扫描器本身，而是在 churn “把账算不过来”之前的分发经济学。
u/Capable_Cut_382 则给出了一个规模更小、但更干净的佐证：一个缩略图工具在 11 个月后总收入突破 $50，一共拿到 9 笔付款，而他最大的体会是“让别人发现你的产品，比写代码难多了”（帖子）（35 分，10 条评论）。
讨论要点： 这些讨论串并不只是单纯庆祝“做得快”。它们一再把“能做出来”和“能分发出去”分开来看，这也是为什么收入截图和品类截图，比泛泛而谈的成功故事更有分量。
与前日对比： 这个主题很稳定。6 月 22 日也有关于收入和市场饱和的讨论，而 6 月 23 日进一步增加了证据，表明 builder 们把发现、留存和受众匹配视为真正的约束条件。
2. 令人困扰的问题¶
可靠性与输出质量下滑¶
Severity: High. 最大的挫败感不只是宕机本身，而是 outage、响应变慢，以及对输出质量信任下降这三件事叠在一起。u/MessageEquivalent347 报告说 Claude Code 已经变得“又慢又卡”，而 u/CochainComplexKernel（得分 31）表示，更糟的是它看起来“更笨了”，还会引入需要用户自己兜底的错误（帖子）（79 分，73 条评论）。u/active_slotter 和 u/Historical-Car-8489 发的独立帖子则显示，用户碰到的是完全相同的 500 错误消息，并且还要去查状态页或 Reddit 才能确认是不是服务故障（帖子）（53 分，49 条评论）；（帖子）（43 分，45 条评论）。
从这些讨论串本身就能看出大家的应对方式：切去 GLM、等 outage 过去，或者干脆回退到手写代码。这是值得构建的方向，因为它直接关系到一个核心需求：当某个模型或提供商失效时，怎么让活跃的开发循环不中断。
代码库重复探查带来的 token 消耗¶
严重程度：对重度用户为高，对其他人则为中。u/DanyrWithCheese 说，Claude Code 即使已经配好了 Graphify、handoff 和记忆文件，面对一个大约 500 个文件的代码库，还是会把 10%-30% 的配额窗口花在“先搞懂仓库”这件事上（帖子）（48 分，54 条评论）。高信号回复几乎都指向同一个诊断： u/HappyPoodle2（得分 49）建议先建立索引，而 u/donk8r（得分 15）则说，真正的成本不是代码库大，而是“一遍又一遍地冷启动式重新发现”。
大家的应对方式包括用 /init、维护 CLAUDE.md、强制先 grep/搜索再行动，或者把仓库搜索交给 subagent。这也是值得构建的方向，因为评论里其实已经把理想修复方案说得很清楚了：持久化的仓库地图、强制 index-first 的查找方式，以及更小的任务范围，而不是反复做大范围侦察。
定价与打包方式把 builder 推向别扭的系统架构¶
Severity: Medium. u/TheGalaxyOfTerror 描述了一种反复出现的 builder 挫败感：订阅便宜到足以让人围绕终端会话和智能体绕行方案来设计系统，而不是直接调用 API，哪怕这样会额外增加技术复杂度（帖子）（52 分，24 条评论）。抱怨的重点不是 API 不好，而是产品边界本身在激励大家做出别扭的折中。
类似的挫败感也出现在迁移到 GLM 的讨论串里：成本和可用性，正把人们推向混合模型路由，而不是单一、干净的一套技术栈（帖子）（37 分，63 条评论）。这也是值得构建的方向，因为如果能提供感知定价的编排、公平用量的 API 组合包，或者更好的成本控制，就能拿掉这些用户明说自己并不想做的架构决策。
难点不在把产品做出来，而在分发¶
Severity: Medium. 无论是卡路里追踪器还是 TextBehindObject 的帖子，都把“发布出来”视为相对直接，把“被人发现”视为真正障碍。u/Capable_Cut_382 写道：“让别人发现你的产品，比写代码难多了。”即使这只是一个收入做到 $50 的小成功故事，这个判断依然很明确（帖子）（35 分，10 条评论）。u/WanderingGalwegian（得分 103）对饱和卡路里追踪器的解释，也完全是从买家心理和订阅经济学出发，而不是编码难度（帖子）（102 分，49 条评论）。
大家会靠内容营销、自然传播和反复重发来应对，但这些讨论串暗示，真正更需要的是分发工具，而不是又一个代码生成器。如果这类工具能降低获客成本、更早验证需求，或者提升在拥挤 AI 产品品类里的留存分析能力，那就有价值。
3. 人们期望的功能¶
包含一定 API 用量的订阅访问¶
这是数据里最直接、也最明确的诉求。u/TheGalaxyOfTerror 明确提出，希望订阅也能在公平用量限制下附带 API 访问能力，因为当前定价正在把开发者推向终端会话绕行和智能体脚手架，而这些东西原本根本不是他们想搭的（帖子）（52 分，24 条评论）。这不是情绪性诉求，而是一个非常实际的需求：用户想要更简单的架构，以及更低成本的实验路径。
Opportunity: Direct. 这个需求具体、反复出现，而且直接连着活跃 builder 的实际行为，不是模糊偏好。
能跨会话保留的持久仓库记忆¶
这条 token 使用讨论，本质上就是一份更好的上下文持久化产品规格说明。u/DanyrWithCheese 希望智能体不要每次新会话都重新学习同一个仓库，而 u/donk8r（得分 15）和 u/More-Subject-5348（得分 12）的回复，则把理想形态描述得很清楚：index-first 查找、稳定的项目地图、更窄的范围控制，以及更好的 handoff 纪律（帖子）（48 分，54 条评论）。现有工具虽然部分覆盖了这个问题，但这些回复暗示，智能体并不能稳定遵守这些约束。
Opportunity: Competitive. 这个需求真实存在，但很多人已经在用 Graphify、Caveman、CLAUDE.md、/init 和 subagent 模式去尝试解决它。
能走出桌面 IDE 窗口的智能体工作流¶
两条不同的帖子指向了同一个空缺。u/jkFujinami 做浏览器版 Antigravity 客户端，是因为原生桌面应用本质上只是包了一层本地 Language Server 的 Electron 外壳；而 u/AchillesFirstStand 则说，他们愿意花大约 $500 买一个像 Tony Stark 那样的大屏界面，让自己可以一边站着或走动，一边监控和引导 AI 编程（帖子）（51 分，7 条评论）；（帖子）（24 分，63 条评论）。浏览器客户端是务实做法；全息墙的说法则更偏愿景，但两者都指向一种更环境化、更可移动的智能体监督方式。
Opportunity: Aspirational. 大家显然想要这个方向，但证据还比较早期，且分散在严肃工具和玩笑式人体工学需求之间。
更适合 AI 构建微型产品的分发支持¶
这些变现讨论串即使没有直接说“应该有人来做这个”，也已经隐含了这种愿望。共同痛点并不是把应用写出来，而是找流量、验证需求，以及在大量近似产品并存的品类里扛住 churn（帖子）（102 分，49 条评论）；（帖子）（35 分，10 条评论）。今天的证据表明，相比又一个通用代码生成器，builder 们会更看重分发 intelligence。
Opportunity: Direct. 这个问题是商业上立刻存在的，现有讨论也把分发视为真正稀缺的资源。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Opus 4.8 | LLM | (+/-) | 在混合智能体工作流中仍会用于规划和最终审查 | 发生事故时会 outage、运行变慢，且信任度下降 |
| GLM-5.2 | LLM | (+/-) | 排行榜表现高于多数对手，API 成本低于 Opus，越来越常被拿来当备用模型或规划/审查模型 | 接入通常需要自定义模型配置；有些用户报告会 overload 或表现出高 token 消耗 |
| Antigravity | IDE / 智能体客户端 | (-) | 工作正常时可作为第二提供商，也可作为智能体运行时 | outage、性能退化，以及关于定价/额度的抱怨 |
| Graphify / repo indexers | 代码库索引 | (+/-) | 如果智能体先查索引，可以减少冷启动扫描 | 如果智能体还是直接重新探索文件，帮助就不大 |
| Pi / OpenCode / stagewise-style harnesses | 智能体编排 | (+) | 允许用户把规划、开发、测试和审查路由到不同模型 | 配置比单模型工作流更复杂 |
| GitHub Copilot CLI | 编程智能体 | (+) | 被用来交付像 WebAssembly Quake 移植这样体量不小、还带分享/捕获功能的项目 | 今天的证据主要还来自一条 showcase 帖子 |
| MediaPipe Hand Landmarker + fal realtime | 浏览器媒体栈 | (+) | 支持在浏览器里做手势驱动的实时摄像头风格重绘 | 需要外部模型服务和实时流水线调参 |
| LazySkills | 智能体技能管理 | (+) | 提供一个统一位置来查看可见性、损坏安装和跨助手的安全操作 | 仍处早期，今天数据里的讨论深度有限 |
整体满意度正在按使用场景分裂。对很多用户来说，Claude 仍然是参照系，但 6 月 23 日的讨论串显示，人们已经在主动维护备用路径，而不再默认某一家提供商会一直可用。GLM-5.2 是最明显的受益者：u/sandofvega 在 Cursor 一侧的讨论里把它描述成当前仍在采样中的最佳编程模型，而 u/julianfromstagewise 和 u/siberianmi（得分 6）则描述了当 Claude 不可用或太贵时，如何把 GLM 路由进自动化 issue 流水线（帖子）（197 分，84 条评论）；（帖子）（37 分，63 条评论）。
主要的权宜方案模式，是把职责拆开：用一个模型做规划或审查，用另一个模型做开发，测试则完全放在智能体之外运行。token 消耗讨论串又补上了第二层方法论：借助 Graphify、CLAUDE.md、/init 或 subagent，强制模型先索引/搜索再行动，避免它在每次新会话里都把配额浪费在重新认识 repo 上（帖子）（48 分，54 条评论）。因此，竞争态势的重点已经不是抽象意义上的“谁是最佳模型”，而是谁能保持可用、保持可负担，并且能塞进一个可路由的工作流里。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| CameraRealtimeStyle | u/ImplementInternal673 | 根据左右手势实时重绘摄像头画面风格 | 让实时摄像头风格化变得可交互、免手动操作 | MediaPipe Hand Landmarker、fal flux-2/klein/realtime、Node.js、Express、浏览器 JS |
Beta | 帖子（255 分，28 条评论）；repo |
| 41 万粒子水模拟 | u/No-Wishbone7899 | 运行一个由 GPU 驱动、带实时渲染的流体模拟 | 展示智能体辅助架构下的高性能图形/物理工作流 | Rust、wgpu、WGSL、Position-Based Fluids |
Alpha | 帖子（62 分，11 条评论） |
| Antigravity 浏览器客户端 | u/jkFujinami | 让 Antigravity UI 能在普通浏览器和手机上运行 | 摆脱桌面 Electron 外壳依赖，并支持移动端/LAN 访问 | TypeScript、ConnectRPC、HTTP/2 reverse proxy、Antigravity Language Server | Alpha | 帖子（51 分，7 条评论）；repo |
| Quakelike | u/lee337reilly | 将 Quake 移植到 WebAssembly，并加入程序化地图和内建分享功能 | 把老游戏引擎变成一个浏览器原生实验，同时叠加智能体辅助功能开发 | C、WebAssembly、SDL2 shims、GitHub Copilot CLI、Claude Opus 4.8 | Shipped | 帖子（16 分，2 条评论）；repo；demo |
| LazySkills | u/alvinunreal | 提供一个用于盘点、校验和更新智能体技能的 TUI | 让技能扩散和损坏安装问题在多个助手之间变得可见 | Go、terminal UI、GitHub 源码扫描 | Shipped | 帖子（17 分，2 条评论）；site；repo |
| TextBehindObject | u/Capable_Cut_382 | 帮助创作者在缩略图中把文字放到物体后方 | 加快一种常见的创作者设计任务，并验证细分创作者需求 | 公开资料未说明具体 Web app 技术栈 | Shipped | 帖子（35 分，10 条评论）；site |
CameraRealtimeStyle 之所以特别突出，是因为它的 README 把交互模型写得非常明确：手势识别完全留在浏览器本地，只有风格化后的帧才会发往 fal 的实时 endpoint。这也是 6 月 23 日反复出现的模式：builder 们用智能体来加速开发，但真正有意思的工作，在于交互设计和运行时管线，而不只是提示词怎么写。（帖子）（255 分，28 条评论）
Antigravity 浏览器客户端则是另一个“基础设施优先”构建的强例子。repo README 写到，它会直接和 Language Server 通信，注入类似 Electron 的全局对象，并通过 HTTP/2 让浏览器能够持续承载原版应用所依赖的长连接流。这让它与其说是一个换皮，不如说是现有智能体运行时的一层可移植性封装。（帖子）（51 分，7 条评论）
Quakelike 则展示了同一趋势更具创意的一面。它的在线 demo 和 README 已经不只是一个裸移植：程序化地牢、copilot 控制台命令、GIF 捕获、可分享状态和触屏控制，让它更像一个面向公众的成品，而不只是内部实验。（帖子）（16 分，2 条评论）
今天反复出现的构建模式包括：浏览器优先的控制界面、围绕智能体工作流的基础设施，以及那些“小而真实”、已有使用或收入证明的创作者工具。多个 builder 解决的重点，都是 AI 编程周边的工作流，而不是编程模型本身。
6. 新动态与亮点¶
关于 AI “slop” 的研究正在被打包成可复用工具¶
u/iamjohncarterofmars 做的不只是又一条批评 AI 写作的观点帖。这个帖子总结了一项针对大约 89,239 条 Reddit 帖子的研究，主题是人们如何识别 AI 写作痕迹；它给破折号、句子节奏过平等信号做了排序，并链接到一个 GitHub repo，把这些发现封装成可复用的 unslop-* skills、数据集、图表和脚本（帖子）（199 分，83 条评论）；repo。真正值得注意的并不是抱怨本身，而是产品化这一步：社区讨论正在被转化成可安装的 QA 工具。
指令文件正在变成可分享的制品¶
u/umwew 挖出了一份 F# 仓库里的 copilot-instructions.md，而截图聚焦的是其中一个直白写着 “No bullshit” 的部分：它要求 Copilot 把构建失败视为自己的责任，并且要主动抓取诊断信息，而不是找借口（帖子）（48 分，4 条评论）。
这里的信号在于，提示词/指令类资产正在被当作可复用的工程制品来对待，而不只是本地配置。
7. 机会在哪里¶
[+++] 感知可靠性的多提供商编排 —— 6 月 23 日最强的信号，是用户已经不再相信单一提供商会一直在线。Claude 的故障讨论串、Antigravity 的故障讨论串，以及围绕 GLM 备用/路由方案的讨论，全都指向同一个需求：当某个模型变慢、退化或彻底失效时，怎么让工作继续推进（帖子）（79 分，73 条评论）；（帖子）（74 分，80 条评论）；（帖子）（37 分，63 条评论）。这个方向很强，因为它直接连着真实痛点、现有绕行行为，以及用户对混合模型流水线的采用意愿。
[++] 持久化的 repo 上下文基础设施 —— token 消耗讨论串为某类产品给出了异常明确的需求：稳定的项目地图、index-first 查找、更窄的范围控制，以及更少的冷启动探索。用户已经在尝试用 Graphify、CLAUDE.md、/init 和 subagent 去打补丁，这既说明需求存在，也说明这个方向竞争已经不小（帖子）（48 分，54 条评论）。
[++] 面向 AI 构建微型产品的分发工具 —— 这些变现讨论串表明，builder 们认为代码生成已经很充足，稀缺的是注意力。品类截图、缓慢但真实的收入截图，以及评论里对 churn 的解释，都支持那些能帮助验证细分市场、获取用户，或更早发现留存问题的产品（帖子）（102 分，49 条评论）；（帖子）（35 分，10 条评论）。
[+] 面向智能体的浏览器与环境化控制界面 —— Antigravity 浏览器客户端已经是一个具体落地案例，而 Tony Stark 风格界面的请求，则展示了相邻需求：人们希望能用更少受限于桌面的位置，去监督长时间运行的智能体（帖子）（51 分，7 条评论）；（帖子）（24 分，63 条评论）。这个信号仍处于浮现期，而非成熟期，但方向已经很清楚。
8. 要点总结¶
- 可靠性已经取代新鲜感，成了头号关切。 当天高信号最高的帖子都在讨论变慢、500 错误和 outage 确认，而不是新功能或新发布。（来源）（79 分，73 条评论）
- GLM 5.2 正在变成运营层面的备用方案，而不只是基准测试里的谈资。 用户讨论的是怎么绕过接入限制、怎么利用成本优势，以及如何围绕它设计带路由的生产式工作流。（来源）（37 分，63 条评论）
- 最好的 builder 帖子越来越集中在工作流基础设施上。 浏览器客户端、技能管理 TUI 和实时控制界面，获得的实质性关注都比泛泛的“我做了个应用”故事更多。（来源）（51 分，7 条评论）
- 持久化 repo 上下文这个问题，依然严重到会实打实烧掉配额。 那条关于 token 成本的讨论，读起来就像一份详细的 index-first、会话持久化编程智能体需求文档。（来源）（48 分，54 条评论）
- 对于 AI 构建的产品，分发仍然比代码生成更稀缺。 哪怕饱和的卡路里应用依然能赚钱，讨论的重点也还是发现和留存，哪怕是在很小的收入突破故事里也是如此。（来源）（102 分，49 条评论）