第36期 · 2026年8月8日

新模型发布后回放脱敏真实任务，找出质量退化、成本变化和可安全放量的条件。

新模型刚发布，应用负责人最怕被排行榜说服后直接切流量。她先从日志中导出脱敏的历史请求，保留原提示词、检索片段、工具返回值和用户实际选择的结果。产品把同一批任务送给新旧模型重跑，允许团队为格式、事实、拒答、延迟和单次成本分别设定门槛。

结果页不拿一个平均分掩盖问题。它把相近的退化归成几类，例如报价字段漏填、日期答错、原本能处理的请求突然拒答。每一类都会收敛成一条最短的可复现案例，左侧是旧输出和线上结果，右侧是新输出与触发它的上下文。负责人点开即可改提示词、补评测样本，或把这类请求暂时继续路由给旧模型。

通过门槛的任务会进入一张放量卡：先覆盖哪些低风险请求、出现何种错误就停止、成本涨到什么数值必须回退。每次彩排都保留模型版本、参数和数据快照，下一版模型发布后能直接比较问题是否真的消失。

首个版本接受 JSONL 格式的任务回放和人工标记的预期结果，重点覆盖文本生成与结构化输出。它不接管线上路由，也不替团队上传原始客户数据；上线决策仍由负责人确认。

目标用户

面向已有线上 LLM 功能的应用负责人或评测工程师。新模型发布后，团队通常要在性能宣传、成本压力和上线期限间做选择。此时最缺的不是另一张通用榜单，而是旧流量在新模型上的具体变化。尤其适合掌握历史请求，却没有专职评测团队的中小型产品组。

最小切入点

导入层先定义稳定的 JSONL 结构，容纳提示词、检索片段、工具返回和预期结果。模型调用采用可配置 HTTP 适配器，保存模型名、参数与响应元数据。结构化输出先用 JSON Schema 做确定性校验。事实、拒答和格式问题由规则评分与人工标签共同判断。退化聚类可先用文本嵌入加层次聚类，再让用户确认分类。首版不接线上路由，只导出放量卡和可复现案例。

为什么是现在

DeepSeek V4 Flash 0731 于7月31日公布评测结果，较高榜单分数会促使应用团队考虑换模，却不能回答真实业务是否退化。 8月8日，该 Hacker News 帖位列第3，记录为421分和251条评论，迁移判断因而更容易成为团队眼前的问题。

最强反方

历史请求可能含客户信息、内部检索内容和工具返回，脱敏规则稍有遗漏就会阻断采购。回放也未必复现线上状态，动态检索结果和外部工具可能已经变化。生成任务缺少唯一正确答案，自动评分容易把风格差异误判为退化。聚类若合并了不同根因，最短案例会给出错误修复方向。新旧模型双跑还会增加调用成本和等待时间。若结果最终仍需大量人工逐条复核，团队可能继续使用现有脚本和表格。

打开可分享详情与开发任务书

出门办事前按数字负担筛选地点，找到能用现金、柜台或普通网页完成的路线。

准备出门停车、吃饭、买票或办事的人，输入起点、要完成的事情和能接受的步行距离，再勾选“可用现金”“不要下载应用”或“不要短信验证码”等限制。地图不会先按距离排序，而是先计算每个地点要经历几次下载、注册、登录和付款跳转。

用户看到的是一条可走的办事路线：哪家停车场可投币或网页付款，哪家餐馆能拿纸质菜单，哪个柜台能现场购票。每个地点都附上规则来源、最近核实日期和到店者留下的照片。若某个入口只能通过应用预约，路线会直接标明这一步，避免人已经站在门口才发现卡住。

到店后，用户可拍下告示或付款页面，补充“现金可用”“必须注册”或“网页已失效”。新证据先进入待核验队列，和商家官网、场馆说明或多名近期反馈交叉确认后才更新地图。常走的路线还能订阅，在常用地点改成强制下载应用时收到提示。

首个版本可从一个城市的停车、餐饮和公共服务开始，优先覆盖信息最容易过期的入口。它不代替商家收款，也不保证每个地点都无需手机，只负责让用户在出发前看清数字步骤。

目标用户

主要用户是准备去陌生街区办事的人。出发前几分钟，他们已确定目标，却不知道入口是否强制安装应用。对手机存储不足、没有本地号码、依赖现金或不愿建账户的人，这一步会直接决定能否完成任务。同行带着老人、孩子或时间紧张时，也需要提前排除会卡住的地点。

最小切入点

先限定一个城市，只覆盖停车、餐饮和公共服务。地点底表可接 Google Places API，读取坐标、营业状态、照片及支付选项。 该接口缺失支付数据时会留空，因此不能直接当作“不可用现金”。 另建人工核验表，记录现金、普通网页、柜台、应用、账户和验证码。前端先做网页地图，不要求用户安装应用。路线计算采用步行距离与数字步骤的加权排序。用户上传照片后，以 OCR 提取文字，再进入人工复核。首版不做自动全城抓取，也不承诺实时准确。

为什么是现在

8月6日，一条 X 帖子集中抱怨扫码看菜单、每件事建账户等门槛。截至8月8日记录，发布后累计点赞 11179 / 转发 2592 / 浏览 212284，说明出门前筛掉这些步骤已成为具体诉求。

最强反方

地点规则变化快，旧照片可能让用户到店后仍然受阻。维持可信度需要持续复核，人工成本会随覆盖范围迅速上升。商家官网常只写“支持移动支付”，不说明是否必须注册。用户照片还可能包含车牌、人脸或付款信息，必须做隐私处理。数字步骤也很难统一计数，网页跳转和第三方支付会因设备而异。一旦路线把关键地点标错，用户会同时损失时间和停车费用。首城若没有足够密度，路线规划就会退化成零散地点列表。

打开可分享详情与开发任务书

读完冷门书时，把感想留在章节旁，等下一位读到这里的人用语音接话。

读完一本冷门书却找不到同好时，读者选择自己读到的版本和章节，把一段不超过两分钟的语音感想钉在具体页码旁。她可以说某个角色为何让自己不舒服，也可以留下一句想请人回答的问题。发布前先设定剧透边界，内容只对确认读到相应位置的人开放。

下一位读者完成同一章节时，书页会送来这段语音。对方可以用短语音、文字或另一段标注回应，系统把来回接话排成一条小链，并保留每段话对应的阅读位置。两人不必恰好在线，讨论仍能从同一个细节开始，而非从“你觉得这本书怎么样”重新破冰。

如果一条感想长时间没人接，产品会在下一位读者完成该章节后重新递出。读者也能把某条链设为只收回应，不公开昵称；想继续深聊时，再由双方确认是否交换私信入口。书读到后半段，早期留言不会提前露出后续剧情。

首个版本围绕 ISBN 版次、章节和页码建立阅读进度门槛，先支持语音与文字接力。它不做公开热榜，也不向未读完的人推荐含剧透的讨论。

目标用户

核心用户是刚读完冷门小说、绝版书或小语种译本的人。此刻情绪和疑问仍很具体，却很难在现有社交关系里找到同版本读者。她不想写公开长评，也不愿加入需要持续活跃的书友会。她只想把某个细节说出来，并在后来者读到这里时获得回应。

最小切入点

先用 Google Books API 按 ISBN 检索版本，保存书名、封面、版次标识和页数。 章节目录往往不完整，首版应让用户手动选择章节并填写页码。进度门槛在服务端判断，只返回不超过用户当前位置的留言。语音直接上传对象存储，同时保留文字回应，不急着做自动转写。匹配队列按版本、章节和等待时长排序，再递给刚完成该章节的人。跨版本匹配先只按章节名提示确认，避免把页码比例当成可靠对应。

为什么是现在

2026 年 8 月 7 日，一条 X 帖直接许愿匹配刚读完同一本书的人；发布后累计点赞 55 / 转发 7 / 浏览 1737，让读完后无处接话的问题再次变得可见。

最强反方

冷门书带来的首要代价是等待时间。用户录完语音后长期收不到回应，很容易把产品判断为空城。不同版次的页码和章节还可能错位，一次提前解锁就会造成剧透。进度只能依赖用户申报，无法确认对方真的读到那里。语音还增加审核、骚扰处理、存储和隐私删除成本。有人朗读大段原文时，也需要处理版权投诉。若接力质量持续偏低，匿名机制会进一步削弱责任感，最终破坏读者留下真诚感想的意愿。

打开可分享详情与开发任务书

做饭时按实际下锅和盛出重量记食材，出锅就得到整锅及每份的真实热量。

做一锅咖喱、炖菜或炒饭时，用户把空锅放上厨房秤后按下开始。每加入一种食材，应用读取重量变化，用户扫包装条码、拍标签或说一句“加了两勺橄榄油”确认品类。屏幕只显示刚加入的重量和整锅累计值，做饭的人不必在油烟里手输一长串克数。

食材录完后，产品把条码数据库中的能量和营养信息换算到实际下锅量。出锅时再称一次可食用总重，系统能把蒸发、骨头或未吃部分和原料重量区分开来。盛饭时把盘子放上秤，取走多少克，就显示这盘实际拿到了整锅多少比例和对应热量。

常做的菜会变成可复用模板。下次用户只需确认肉换了多少、油多倒了多少，产品便沿用其余食材。家庭多人分餐时，每个人也能用自己的盘子称取，不再默认一锅必然等分成四份或六份。

首个版本优先支持条码食品、常见食材和手动校正的营养条目，并保留每次计算来源。它不提供减重建议或医疗判断，重点是把真实下锅量和真实盛出量记清楚。

目标用户

核心用户是已经称原料、记录热量，却常做一锅多人分食的人。最需要它的时刻，是锅已上火、双手沾水或油时。此时逐项解锁手机和输入克数最容易漏记。另一关键时刻是家人各自盛饭，固定四等份无法反映每个人实际拿走的量。

最小切入点

先做原生移动端，并只适配一种可稳定读数的蓝牙厨房秤。应用把稳定后的重量差记为待确认食材，保留撤回、合并和手动校正。包装食品通过系统条码扫描取码，再查询 Open Food Facts；常见原料用 USDA FoodData Central 搜索和详情接口补齐。 首版不做图片识菜，也不自动判断骨头和残渣。成品熟重与每盘取用量都由秤直接记录，计算结果保存食材条目、数据源和换算过程。

为什么是现在

8 月 6 日，一条 X 帖直接许愿，希望按自制食谱的成分列表计算总热量。 截至 8 月 8 日，该帖记录为发布后累计点赞 5 / 转发 0 / 浏览 53，说明这项具体录入摩擦已被用户公开说出。

最强反方

秤的漂移、锅铲触碰和中途端锅，会制造错误重量差。每次误判都需要用户停下来确认，省下的输入可能又被校正吃掉。油、酱汁和带包装食材还会遇到单位或营养条目不一致。骨头与未吃部分无法仅靠出锅称重区分，必须增加残余称量或手动说明。兼容多种秤会带来协议、断连和售后成本。若结果常与用户现有记录相差明显，透明的来源记录也难以挽回信任。

打开可分享详情与开发任务书

夜里举起手机对准天空，立即看见该方向的超大质量黑洞及其距离故事。

夜里散步、露营或带孩子看星星时，用户打开手机并对准天空。应用根据所在地、日期、时间和手机朝向，只挑出此刻位于地平线以上的超大质量黑洞。屏幕上的方向箭头带人转向下一个目标，不要求用户先认识星座或读懂密集的全天图。

每个目标是一张短卡：它所在星系的方向、距离、质量，以及它发出的光走到地球用了多久。用户点开后可以听一段一分钟讲解，例如“你现在朝向的这个方向，光在恐龙出现前就已经出发”。卡片会清楚标注这些黑洞通常无法用肉眼直接看见，屏幕展示的是根据天文目录定位的天空方向。

转动手机时，附近目标按方位依次浮出。用户可选择“离我最近”“质量最大”或“今晚最容易讲给孩子听”的路线，完成几个目标后生成一张带地点、时间和朝向的黑洞明信片。阴天或光污染严重时，应用仍能作为方位探索使用，不假装提供肉眼观测结果。

首个版本使用公开黑洞目录、星表和手机罗盘，先服务于户外抬头探索。它不模拟望远镜画面，也不把尚有争议的候选天体写成确定发现。

目标用户

核心用户是带孩子夜间散步或露营的家长。他们刚抬头产生好奇，却无法从密集星图里挑出能讲的目标。此时同行者的注意力很短，也不适合学习星座坐标。应用直接给出转身方向和一句故事，能让这段户外空闲立刻变成共同探索。

最小切入点

先从DR20及其增值目录筛选一组可核验对象。 仅保留坐标、红移和质量出处清楚的目标。后端按地点和时刻，把赤经赤纬换算为高度角与方位角。客户端读取定位、时钟和姿态传感器，再计算箭头偏差。首版只做单一手机平台，并限制为精选对象。距离和光行时间采用固定换算口径，卡片同时标注数据来源。先不渲染全天星图，也不模拟望远镜画面。

为什么是现在

7月30日至31日，SDSS发布DR20全天分布图，并开放黑洞测绘数据和查询工具。 8月8日的Hacker News快照中，相关页面位列第14，获134分和35条评论，让更多人看到全天图，却仍需把它换成脚下可用的方向。

最强反方

罗盘会受车辆、金属装备和手机壳干扰，箭头可能明显偏离。用户若连续找不到目标方向，很快会怀疑整套定位。目录中的可见信号常来自活动星系核或类星体，并非黑洞本体。 红移、距离和质量还可能采用不同估算口径，短卡容易把不确定性抹平。亲子讲解需要逐条核对，编辑成本会随目录扩张。错误箭头或夸大的故事一旦进入明信片，会直接损害科学可信度。

打开可分享详情与开发任务书