第71期 · 2026年9月12日

折叠 iPhone 预购前，用两台现有手机拼出样机，亲手验证阅读、拍照和收纳是否顺手。

折叠 iPhone 发布、预购即将开始时，准备换机的人最想知道的不是铰链动画有多漂亮，而是自己的日常动作会不会真的变顺。产品让用户拿出两台现有 iPhone，分别模拟折叠屏的左右两半，再用一枚可打印的简易铰链固定位置。配对完成后，两块屏幕会随开合状态改变布局，用户可以直接尝试阅读长文、拍照取景、分屏聊天、看地图和把手机塞进口袋。

每个任务都有明确的体验步骤。比如阅读时测试跨屏排版，拍照时测试展开后取景是否更宽，聊天时测试键盘和内容区如何分配。用户在完成动作后标记顺手、别扭或无变化，并补一句自己的感受。系统把结果按任务整理成一页对比，指出哪些动作因屏幕变大而改善，哪些动作反而增加了折叠、握持或收纳负担。

第一版只需要支持两台 iPhone 的同步显示、几种固定开合状态和一组高频任务，不模拟真实铰链的重量、厚度或所有第三方应用。用户还可以把体验报告分享给家人，邀请对方按同一套任务试一次。这样，预购前的决定来自自己真的走过一遍日常，而不是被发布会里的演示带着走。

目标用户

面向已在使用 iPhone、并认真考虑预购 iPhone Duo 的换机者。他们通常在发布会后产生兴趣，却无法在付款前长时间体验真机。此时，参数和演示已经足够多，缺的是把自己的阅读、聊天、地图与收纳习惯走一遍。家人共同出资或共用设备时，也需要一份能对照讨论的结果。

最小切入点

用原生 iOS 应用连接两台 iPhone。Multipeer Connectivity 可负责附近设备发现、配对和状态消息同步。 Nearby Interaction 可在支持的设备上提供距离与方向，但首版不必依赖它。 开合状态先由用户点选闭合、半开和展开，打印铰链只负责固定位置。两端使用同一任务状态机，分别渲染左右内容区。首批只做阅读、聊天、地图和拍照取景，不尝试运行或复刻第三方应用。报告保存在主设备，可导出为图片或网页链接。

为什么是现在

Apple 于 9 月 9 日发布首款折叠 iPhone Duo，并宣布 10 月 16 日开启预购；准备换机的人需要在付款前判断大屏、多任务与收纳是否适合自己。 截至 9 月 12 日，这轮“iphone duo”搜索仍在持续，搜索量为 2000000+，增幅为 1000%。

最强反方

两台手机之间的边框和缝隙，会明显扭曲连续屏幕的阅读与取景感受。现有手机的重量、厚度和尺寸也不同，口袋测试尤其容易给出错误结论。应用只能模拟预设界面，无法证明真实第三方应用会如何适配。配对延迟或两端状态错位，会让用户把工程问题误认为产品问题。打印铰链还带来制作门槛和机身刮伤风险。若报告没有反复强调模拟范围，错误建议会迅速损害购买决策工具的可信度。

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

横屏素材改竖屏时，自动跟随真正的说话者或动作生成可编辑运镜，判断不稳的片段交给人确认。

短视频编辑把横屏采访、比赛或直播素材改成竖屏时，最烦的不是裁切本身，而是画面总在错误的人身上。用户把视频拖进时间线，圈选主讲人、球员或当前动作，产品便生成一条可编辑的虚拟摄像机轨迹。轨迹会在安全区域内保持稳定，避免人物的头顶和字幕被切掉；当系统预测下一位即将接话或接球时，还会提前平滑移动画面。

编辑可以直接在时间线上拖动关键点、调整跟随力度和安全区。每次自动移动都保留为可修改的运镜数据，而不是把裁切结果烘焙成一条无法挽回的视频。多人对话时，编辑可选择“当前说话者优先”或“全员保持可见”，动作素材则可按球、车或手部等主体跟随。

遇到遮挡、多人重叠、快速出画或主体置信度突然下降，产品暂停自动决定，把片段标成待确认，并显示它当时看到的候选主体。第一版先覆盖常见人物和运动物体，输出 Premiere、剪映或 Final Cut 可继续编辑的关键帧轨迹，不负责替编辑完成字幕、调色和最终剪辑。

目标用户

核心用户是经常把播客、采访、课程和赛事素材改成竖屏的剪辑师。他们通常在横屏母版已经定剪后，才接到 Reels 或 Shorts 的交付任务。此时字幕、切点和节奏大多不能重做，只能快速补出可靠构图。素材越长、人物切换越多，逐镜打关键帧越难按期完成。

最小切入点

技术核心可拆成主体轨迹、镜头规划和导出三层。用户在首帧圈选后，用 SAM 2 向后传播主体掩码。它支持点、框或掩码提示，也允许在后续帧纠正结果。 采访素材再做离线说话人分段，并与人脸轨迹匹配。镜头规划只生成位置、缩放和贝塞尔关键点，再加入头顶、字幕区和速度约束。首版先支持单主体与双人采访，不做任意球类的接球预测。导出先落在 Final Cut Pro 的 FCPXML；该格式可描述项目时间线，供应用与 Final Cut Pro 交换数据。

为什么是现在

一条2026年9月11日的r/EntrepreneursGrind帖子抱怨，试过3个横屏转竖屏工具后，结果仍只是居中裁切；现有方案没能稳定跟随说话者或动作。 截至9月12日，该帖记录为2分、0条评论，问题出现在创作者正把YouTube横屏内容改成Reels的交付节点。

最强反方

说话人分段和人脸对应一旦错配，镜头会持续跟错人。提前移动若猜错下一位发言者，成片会出现无缘由的摇镜。比赛素材还会遇到遮挡、镜头切换和高速小物体，单一跟踪模型很难覆盖。为减少误报，系统必须保存置信度、候选主体和人工修改历史，这会增加存储与界面复杂度。FCPXML 导入后的坐标、缩放和插值也要逐版本验证。若编辑仍需通看全部素材，自动化带来的省时价值会明显下降。私密采访和未发布赛事素材还会限制云端处理，迫使产品承担本地推理的性能成本。

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

研究者收到 AI 数学证明时，让独立审查代理寻找最弱推理节点，并附上可复现的反例过程。

数学研究者收到一份流畅的 AI 证明，却怀疑其中某个引理只是被漂亮措辞掩盖了。用户上传证明、依赖的定义和可运行代码，产品把论证拆成一条可检查的依赖链，再交给多个相互隔离的审查代理。每个代理承担不同任务：寻找反例、检查隐含假设、尝试重建引理，或用小规模枚举验证关键步骤。

审查代理不能只说“这里可能有问题”。它必须指出具体的推理节点，给出触发失败的输入、未满足的前提，或一段可以复跑的搜索程序。界面按证明结构展示争议点，研究者点击某个节点，就能看到哪些代理独立发现了同一问题，哪些只是提出尚未证实的怀疑。

作者修改证明后，系统只重跑受影响的分支，并保留上一轮结论。通过的部分会显示验证方法和运行范围，尚未覆盖的部分则明确标出边界。第一版聚焦形式化程度较高、可用符号计算或有限搜索检查的数学证明，不承诺替代同行评审，也不把代理的多数意见当成正确性证明。

目标用户

核心用户是正在复核 AI 生成证明的数学研究者。他们通常已读完主要思路，却卡在一个过于顺滑的引理上。此时手工检查每条依赖很慢，直接要求模型自证又容易重复原错误。产品适合在组会、预印本提交或回复审稿意见前使用。用户需要的是可复跑的失败证据，而不是另一个总体置信分。

最小切入点

入口接受一份带编号的证明，以及定义、引用引理和代码附件。先让模型提取命题、前提和引用关系，再由用户确认依赖图。可形式化的节点转成 Lean 4 文件，调用内核检查与 `#print axioms`。 其余节点分派给隔离代理，分别做反例搜索、前提审计和引理重建。有限对象上的检查放进受限容器，并保存随机种子、输入与输出。首版只支持 Lean 4 和可执行脚本，不处理纯图示证明。节点内容采用哈希缓存，修改后按依赖关系重跑。

为什么是现在

9月11日，Hacker News 上关于一份数学与 AI 声明的帖子引发讨论；截至9月12日，该帖排名第1，记录580 points和640 comments。 声明同时指出，部分 AI 数学结果被仓促公布，缺少充分写作与方法提炼，使研究者更常面对难以快速复核的证明材料。

最强反方

把自然语言证明拆成正确依赖图，本身就可能引入误读。若节点边界错了，后续代理会精确地检查错误对象。反例搜索只能覆盖给定范围，未找到反例很容易被误读为通过。形式化步骤还可能把原命题改成更容易证明的版本。多代理运行会带来明显的模型与计算费用。未公开证明上传到云端，也会触发保密和抢先发表顾虑。继续做的前提，是让作者确认命题映射，并把“已检查”与“已证明”严格分开。

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

活动观众各自操控一块字形网格，在舞台上共同拼出会变化的标题并留下动画回放。

活动主持人准备在舞台上展示一个标题、口号或嘉宾名字时，可以把观众从看字的人变成造字的人。主持人输入文字并选择字形风格后，产品把每个字拆成可分配的网格模块。观众扫码进入房间，每台手机领取一小块区域，通过滑动、旋转和点亮完成自己的局部动作，舞台投影则实时合成全场正在拼出的文字。

屏幕上的提示只告诉每个人这一块要变成什么，不要求观众安装应用或理解字体设计。主持人可以把过程设成倒计时拼字、两队竞速或接力变形；某一块迟迟没有响应时，系统会把它交给附近另一位观众接手。投影端显示整体进度，手机端保留自己的模块和队伍状态。

第一版可先支持单行标题、有限字库和浏览器扫码参与，输出一段活动结束后的完整字形动画。它不试图替代专业动效软件，也不要求每位观众精准绘图。产品的乐趣正在于几十个人各自完成一个小动作，最后在舞台上看到一个只有这群人共同做出来的结果。

目标用户

核心用户是需要在婚礼、校园晚会、发布会或年会中安排短互动的主持人和活动执行者。最合适的时刻，是开场、嘉宾登台或品牌口号揭晓前。此时全场注意力已经朝向舞台，却缺少一次人人都能立即参与的动作。扫码后只负责一小块，也能避免复杂规则拖慢流程。

最小切入点

先把有限字库离线栅格化，保存每个字的模块坐标和允许动作。房间服务通过 WebSocket 同步模块状态、队伍进度和主持指令。 手机端只渲染领取区域，并发送滑动、旋转与点亮事件。服务端用心跳和超时队列回收无响应模块，再分给仍在线的参与者。投影端按事件日志合成全局画面，结束后重放同一日志生成动画。首版不做任意字体解析，也不处理多行排版。

为什么是现在

截至9月12日观测，GLYPH Immersive 位于 Product Hunt 新品流第8位，模块化网格字形正在获得产品社区的可见度。 这让活动团队更容易把静态标题设想成由现场观众共同完成的互动内容。

最强反方

现场网络抖动会让模块状态不同步，投影上的字可能长时间缺角。回收过快会抢走参与者正在完成的区域，回收过慢又会拖垮倒计时。不同手机的触控精度和页面休眠，还会增加误操作与断线。字库过少会限制活动主题，扩充字库则要持续校正每个字的可读性和动作路径。主持人还需要彩排、备用房间和一键收尾，否则一次卡顿就会破坏舞台节奏。

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

新月观星前，按地平线、光污染和夜间规则预订私人观测位，不必临时寻找能合法停留的黑暗地点。

新月临近时，城市观星者和天文摄影爱好者会发现，真正难找的不是月相日期，而是一个够黑、看得开、允许深夜停留的地方。产品把郊外农场、营地和私人土地拆成可预订的夜间观测席位。场主标注可见地平线方向、附近光源、停车方式、电源、卫生设施和是否允许赤道仪等设备，用户则输入器材、人数和预计到达时间。

预订页面不只显示地图上的一个点，还会给出当晚月亮位置、目标天体方向和天气风险。到场后，观星者用低亮度路线完成签到，手机自动切换红光界面，避免车灯和屏幕打扰其他人。场主可以设置人数上限、安静时段和车辆进出规则，观测结束后再开放下一批席位。

第一版先围绕新月周末接入少量可核验场地，支持预约、规则确认和天气取消，不负责保证看到某颗天体，也不替用户处理野外安全。观星者得到的是一个能真正待上一晚的地点，场主则把闲置土地变成有边界、有礼仪的夜间体验。

目标用户

核心用户是住在城市、已有望远镜或摄影器材的观星者。他们通常在新月前几天确认云量、拍摄目标和同行人数。此时普通营地可能灯光过强，公共暗夜点又未必允许深夜停车。他们需要在装车出发前，把视野、规则和可取消性一次确认。

最小切入点

用 PostGIS 保存席位坐标、地平线方位扇区和邻近光源。Skyfield 可按地点与时段计算月亮高度、方位和月相。 天气接入 NWS API 的逐小时预报与警报，首批仅覆盖美国场地。 场主上传四向夜景、停车路线和设备限制，由人工完成首轮核验。预订只做席位、人数、车辆、规则确认和天气取消。暂不承诺可见性，也不做野外导航或自动安全判断。

为什么是现在

美国对“new moon september 2026”的搜索量达到 500+，增幅为 75%，新月日期正推动观星者安排当月夜间出行。这轮搜索热度 9 月 11 日已经回落，需求会从查日期转向临近出发前寻找合法、可过夜且光线可控的地点。

最强反方

每新增一块场地，都要核实产权、分区规定、夜间经营许可和邻里限制。场主还需处理跌倒、车辆受困、设备损坏及恶劣天气带来的责任。视野和灯光资料若只靠自报，很容易与到场体验不符，人工复核会拖慢扩张。新月附近若遇连续多云，集中退款会侵蚀收入，也让场主失去信心。供给太稀时，用户仍要长途驾驶，平台难以形成复购。红光签到只能减少干扰，不能替代清晰路线和现场安全措施。

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