在去年的时候，我曾经研究过如何在苹果的carplay播放视频的问题。之所以研究这个，纯粹也是闲的蛋疼，并不是真的有那么大的需求要在车机上看视频。

至于在车机播放视频，今年早些时候在安卓的车机上测试过是可以播放的，甚至能用方向盘的多功能按键进行切换，在车机上通过zlink连接的华为的hi car，之前的文章可以点击这里查看。

去年研究的时候主要是基于https://github.com/thomasdye12/TDS-Carplay这个开源项目，实现方式也比较简单，调用私有api创建一个车机上的全屏窗口，去年的时候申请apple的communication权限始终没通过，直到前几天终于通过了。

也不知道苹果是什么处理逻辑，有时候真的答非所问，问就是已经有了drive task权限，翻来覆去就是要么说权限已经有了要么就是没反应了，开发者论坛，工单都提过，甚至电话支持也申请过，问就是帮忙反馈，反馈了就没动静了。

这次也不知道是哪路神仙想起来了，竟然顺利通过了。此时又想起来这个项目，重新跑起来：

iOS26 is not supported,这比49年入国军还惨，这依然是50年了，毛都没有了。就离谱，当然，主要原因按照自己的分析以及ai分析给出的结论在于苹果收紧了carplay端的权限管理：

提示信息来源：
Section(header: Text("Getting Started")) {
    Text("IOS 26 IS NOT SUPPORTED")
        .tint(.red)
        .fontWeight(.bold)
    NavigationLink(destination: Help()) {
        Label("Help", systemImage: "questionmark.circle")
TDS实现逻辑：
1.Hook 私有方法，强制创建全屏车机窗口
_shouldCreateCarWindow → 永远 YES
__supportsCarFullScreen → 永远 YES
2.拿到系统的 CPWindow，把 UIImageView / AVPlayer / WKWebView 直接贴上去播画面
3.表面挂一个 CPMapTemplate（地图模板） 当“合法壳”，实际内容是自定义全屏 UI
再绕过 clientPushedIllegalTemplateOfClass:（非法模板检查）

针对iOS26的系统库分析：

当然，更主要可能是来自于这个问题，新的权限判断是通过hasNavigationEntitlement而不是__supportsCarFullScreen，单独这一项就足够让当前这个app彻底崩溃了。

那么，事情到这里，似乎已经是无解了，但是事实真的如此吗？感觉并不是，去苹果应用商店搜索carplay能找到一堆播放视频的东西，下载了两个，一个只能添加网络视频地址，我没有，所以没法测试，另外一个cartv集成了视频播放功能，在车机上竟然成功了：

手机端界面：

播放页面投屏：

屏幕镜像方式：

那么基于这两种方式也就实现了：

1.app直接在车机播放视频

2.通过屏幕镜像录屏流的方式实现屏幕镜像。

不得不说，第一个发现在这个东西的还真特娘的是个天才。

既然知道了原理，那么要实现这个东西也就简单了，之前已经有了communication权限，那么就可以向车机传送数据，能传送数据那么在创建出对应的窗口来应该就可以了。说干就干，直接上手开撸，当然，主要还是靠ai撸，参考项目目前已经没有什么参考意义了，直接起个新的xcode项目开始实现这些功能。

有了思路之后，写代码其实没什么困难，困难的是代码之外的问题该如何解决，投屏镜像完成之后，兴冲冲的跑到车上测试：

纳尼，怎么跟我想象的不一样呢，这是为虾米啊，苍天啊大地啊，怎么可以酱紫呢。

这，只能说，开头很顺利，失败的也很迅速。当然，这个东西的根源要找起来也简单，就是前面提到的hasNavigationEntitlement，也就是mobileprovision里面对应的com.apple.developer.carplay-maps权限，完整权限列表：

<key>com.apple.developer.carplay-communication</key>
<true/>
<key>com.apple.developer.carplay-driving-task</key>
<true/>
<key>com.apple.developer.carplay-maps</key>
<true/>

而申请com.apple.developer.carplay-maps这个权限，要求app必须要有导航功能，并且是 turn-by-turn的导航才可以，需要提供的资料也比较多，包括app截图，规划，语音播报信息等等。

等拿到权限之后就可以创建一个CPMapTemplate至于里面塞什么东西，那就全看自己的意愿了。这也是cartv之类的视频播放实现方式。

简单视频播放，可以通过推送视频流的方式来实现，同样也是cartv的实现方式，最终app实现效果：

车机等待界面：

视频效果：

至于为什么要做这个东西？

那肯定是，因为姐姐我可以做，我能做，我还做出来了！

osX 27
xcode 27 更新之后，hbuilder 会报下面的错误：
uniapp Command failed: open -a Simulator Unable to find application named 'Simulator'

问题的关键在于新的模拟器不叫Simulator，叫做 Device Hub，要解决这个问题也简单，直接吧Device Hub 复制一份出来 改名叫做Simulator就可以了。

如果模拟器不兼容，通过下面的命令安装universal版本

xcodebuild -downloadPlatform iOS -buildVersion 26.5 -architectureVariant universal

实际效果：

中秋节，今年的中秋节哪里都没去，就在家呆着。也正因为如此，终于有时间研究了一下comfyui这个东西。

第一次看到这个东西是在腾讯的cnb的网站首页上，基本第一页铺满了comfyui相关的内容。

之前也曾折腾过不少ai相关的东西，局限于自己的硬件环境，太多的东西可远观而不可亵玩焉。这10g的显存跑点东西的确也捉襟见肘，当到处都在鼓吹几十块钱的成本做个漫剧能挣几千的时候，也该来体验下这漫剧到底是怎么玩的了。

comfyui本质上是个工作流引擎，图形化的工作流引擎。介绍完了，更多的内容可以参考官网内容。

当然，晚上也有不少的封装版本，所谓的封装就是继承了python的运行环境，省去了各种部署步骤的繁琐。前几天看到秋叶comfyui 的整合包，想着也能省事一回，就直接下载了这个安装包。

相对来说的确是方便了不少：

comfyui本身也继承了一些工作流，需要注意的是，对接comfyui官方服务器接口的工作流是收费的。

实际生成效果感觉也能说的过去：

即梦：

comfyui 本地模型 Minimax H3:

上面的几个视频用来替换了findu.co 官网的背景视频。

收费的好处就是性能会好很多，基于confyui线上的视频处理模型生成视频效率明显会高很多，例如似水流年提供的创意 老虎追人的这个视频。

还有基于导演工作流生成的视频，勉强能玩，就是显卡性能太差，耗时太长了。

人物的还原度相对来说比较一般，另外，测试音频以及一些资源缺的也比较多。所以实际的效果并不是十分理想，当然，最重要的还是分辨率问题，有钱的话用付费云节点自然会更快更更好。

至于怎么实现工作流，其实就是不断的拖组件，连线，跟纺织工差不多，如果自己不想连，可以直接让ai来实现工作流，自己微调就可以了，毕竟ai万能的时代，没有必要什么东西都自己搞。

显存不足，导致占用了大量的共享内存，好在物理内存相对来说还算是充足。

当然，基于minimax也可以实现动作模拟，原视频：

即梦ai的收费复刻效果：

minimax h3的本地化效果（第一段音轨没有复制，每次生成5s，需要多次生成进行合并）：

原图参考，就是头图。

生成效率的确是个大问题，还有一点就是显卡性能导致有时候会卡死，当然，这个卡死我也不知道是真死了还是假死，反正就是没反应了。如果要体验建议至少500G的空闲磁盘空间，目前我在用的各种模型文件占用260G磁盘空间。

下载模型可以考虑使用迅雷，速度还是不错的：

至于怎么提高速度，简单粗暴换显卡，啥？你问多少钱？

也不是很贵对吧？对个der啊 ，对！？

想当个新时代的纺织工也没那么容易，毕竟这『纺车』也挺贵的！

周六中午，对象带着孩子从老家回来，本来想做个凉拌猪头肉的，然而，为了自己的减肥大计，最终还是放弃了那软糯可爱，肥肥腻腻的猪头肉。只是，没了猪头肉，这凉拌黄瓜难免太素了一点。用平底锅煎了三个鸡蛋放了进去，之前也用过海螺，整体来说味道还是不错的。

为了减肥的确是放弃了很多，也改变了很多。吃东西不在那么放肆，饭量也下降了很多。以前觉得自己战斗力能有20，现在战斗力可能也就真的只剩下5了，名副其实的战五渣。

自从自己开始跳绳，目前已经用坏了好几套了。家里苟且偷生的几个跳绳，也或多或少有些问题了。昨天买的新的跳绳到了，这次跳绳的球子比之前的大了很多。

除了运动，有点时间也尝试了一下其他的东西。让ai生成视频，各种生图，生视频的ai到现在看来依然没有多少免费可用的，简要浏览了一下confyui，还未开始尝试，而至于即梦之类的app，也只有一条收费途径。

当然价格也很不错，这么一条视频10块钱没了。网上各种教你做短剧，基本也没什么靠谱的，如果这么那么靠谱他自己就干了，又怎么会引入各种竞争者，最后不过是卖token和积分的赚的盆满钵满。

世界的运行法则其实并没有什么变化，种地的不挣钱，卖化肥卖农药的发家了；搞养殖的不赚钱，卖饲料的发财了。至于现在？用ai开发app 做短视频的不挣钱，卖token的财富自由了。

当然，除了动作模仿，我还试了下情景短剧的生成，也不是纯粹的短剧，其实是给我的两个app： 闺蜜圈 和 Findu 做了两只广告短片。

当然，这个东西的成本也不低。闺蜜圈的相对来说简单一点，花费了大约1000积分。

findu 视频成本就高了，为了生成这个东西消耗了workbuddy 原来免费的 750积分+充值后的300积分。

workbuddy 月度会员2000积分+ 赠送2000积分，按月订阅99.相当于每1000积分25块钱，也就是说这两个视频每个值25块钱。

至于挣钱？别做梦了，靠这个东西怎么可能能挣钱呢~~

所以，如果要想出点东西，唯一的途径就是往里砸钱，砸完了之后，可能连个响都听不到。

挣钱不容易，花钱，那可太tm简单了。

更简单更好用的大姨妈记录app：https://guimiquan.cn

5.2.16
数字版本号：556
日期：2026-09-18

苹果:
1.支持 健康 数据同步 
2.支持记录腰围数据 
3.修复了一些已知bug 

安卓：
1.支持记录腰围数据 
2.修复了一些已知bug

APP以及小程序二维码，扫描即可安装体验：

距离上次更新又过了四个月了，四个月时间陆陆续续做了一些东西，当然主要还是针对iOS的healthkit，目前可以从苹果健康直接导入历史数据了，并且在记录的时候如果开启了同步开关，在闺蜜圈记录数据之后会自动同步到苹果的健康app。

昨天用codebuddy做了个视频，花了400积分。

当然，如果大家感兴趣可以关注我的抖音，每天分享健康知识。

跟着姐姐一起涨知识哦，各种各样的小知识。

前段时间买了好几条瑜伽裤：单条的瑜伽裤、跟短裤一体的、跟短裙一体的。基本都是淘宝买的，并没有在抖音上浏览过相关内容。但是，那段时间拼命给我推送瑜伽裤的短视频，还带配文：起得来就晨跑，起不来就夜跑。话说，这个跑步是非跑不可吗？

对象叔叔家的孩子今天结婚，昨天下午就带着宝子一起回老家了。家里就剩下我跟猫猫，原本想着找个电影看看，打开淘票票，一通划拉想看的电影排片都在十点以后，等看完都第二天零点了，这个时间的确是有些让人为难了。之前下载的电影也看的差不多了，家里的投影仪也实在是派不上用场，不过今天可以把再看的韩剧《夺命许愿》下载下来用投影仪看。

既然没什么能看的，不如完成每天的步数。换上衣服，准备开始围小区跑步。

八点多出门，小广场上跳广场舞的大姨们依然在翩翩起舞，另外一侧是练太极的老太太们。穿过广场跑出小区，遇到的多数都是从公园往回走的。这个时间，往外跑的反而不多了。

之前小米眼镜白天的效果感觉还行，晚上在光线比较按的地方，的确是看不清楚对面到底是什么。偶尔从路灯下经过的时候，看到一个高挑的身影，让自己的身材显得反而没那么胖了，这拉腿的效果的确不错。

跑完步，离每天的目标一万步还差点，刚好，去公园转一圈应该也就足够了。

晚上漆黑的路上，竟然泛起了点点的绿光。地面上镶嵌的那些特殊的石头，在晚上就发挥作用了。

有时候也不禁会想，现在每天坚持运动的意义到底是什么？以前是为了减肥，现在或许多多少少已经开始习惯，或者喜欢运动了吧。

有的事情一旦开始就注定只有一个结局，出生的瞬间，就已经确定目标是死亡。既然无法改变终点，那就享受过程吧。

不管是天意，还是命运，想做的就去做吧，毕竟来世，谁又知道是什么样子呢。

在不久的以前，写代码还需要大量人力的时候，跨平台框架无疑是最好的选择。不管是uni还是flutter，都是为了这个而生的，当然这不是最早的跨平台框架，在这之前还有很多其他的框架，可能大家都不曾听说过，我简单介绍个我用过的两个：b4a（basic for andorid），我最开始并不怎么喜欢写（再问就是不会）安卓的java代码，想着偷懒，不要去弄安卓那一套，偷懒玩了下b4a，这也是最开始做findu的时候最朴素的想法；另外一个是delphi的firemonkey框架，这个东西体验的更早，刚来青岛的时候，为了查询公交基于这个东西做了个公交查询的app，最后跑在了ios上。

这些框架，不能说生不逢时，只能说基础功能还是稍微有些欠缺，生态不完整，例如地图、Im等组件的支撑缺失，这也是最终为什么直接采用原生oc和java开发了最早版本的findu。

然而，随着ai的发展，跨平台已经不再是一个主要的投入成本了。借助ai的能力可以快速复刻一个app到其他的平台，以前是点子不值钱，现在技术也不值钱了。跨平台唯一的好处仅剩下代码的可维护性，一套代码通吃各个平台，相对来说代码维护和bug修复的一致性会比多平台更加便捷。

可能这个发展偶尔也会有人会高喊暂停：

2026 年 8 月 11 日，美国参议员伯尼·桑德斯（Bernie Sanders）日前致信 OpenAI CEO Sam Altman、Anthropic CEO Dario Amodei 和 Meta CEO Mark Zuckerberg，要求三家公司暂停 AI 开发，并停止继续构建人类无法控制的 AI 系统。

至于暂停或者不暂停，现有的技术能力已经足够解决日常的技术问题和满足开发需求。也基于这种现有的技术能力，最近重新重构了findu，开发了新的portable claw。这里我想说的就是这个portable claw，借鉴之前的开发经验，想着一套代码解决所有问题，采用的架构依然是uniapp，不过不是uniappx。

按照uniapp 官方文档的说法，x其实是下一代，能达到原生的性能。我在开始的时候错误的评估了app在ios上对于性能的消耗，并且初期测试的时候主要也是基于ios模拟器测试，真机测试相对来说比较少，数据量也没有达到日常使用账号的数据量。导致对于app在ios真机上的性能过于乐观，数据量大了之后，会话窗口的绘制就成了一件痛苦的事情。

 uni-app 在 iOS 真机上的瓶颈，不只是「聊天列表用了 WebView」。换成 nvue，只是把聊天 UI 从 WKWebView 换成 Weex 原生控件，业务、流式更新、页面栈、桥接仍在 JS 容器里。所以能减轻长列表掉帧，但到不了 Swift + UITableView 那种原生体验。

uni-app 在 iOS 真机上真正卡在哪

1. 双运行时一直同时活着

本项目 iOS 不是「整 App 都是 nvue」：

• 聊天：pages/chat/ios.nvue（Weex）
• 状态 / 设置 / 登录 / 订阅：仍是 Vue + WKWebView
• 业务宿主：stores/iosChatHost.js 挂在 App.vue 的 JS 服务层

chatRoutes.js 里写得很清楚：Vue 宿主和聊天 nvue 作为 subNVue 同时常驻，Tab 只挪 overlay。真机上等于：

• 一套 WKWebView（设置等）
• 一套 Weex（聊天）
• 一套 5+ Runtime / Pandora

内存、启动、Tab 切换都比单进程 UIKit 贵。Android 用 index.vue 还能凑合，iOS 对 WebView 和后台 WebContent 更狠，真机掉帧、杀进程都更明显。

2. 主路径仍是 JS：解析、裁剪、再塞回 UI

Gateway / Hermes 事件、历史、tool 卡、附件、TTS、权限，全部在 JS 里做。nvue 不能 import gatewayMedia、@noble/* 等，否则 Weex 白屏。于是每条流式更新都是：

JS 宿主算完 → cloneMessage 裁成短摘要 → uni.$emit 整份快照 → nvue 再 v-for 刷 <list>

原生工程则是：SSE 回调直接改 ChatMessage，UITableView 按行刷新。中间没有「整窗 JSON 快照」。

3. 聊天数据本身就重

长会话卡、空会话不卡，文档里已经定性：推给 nvue 的是「当前窗口」的完整 JSON，最后十几条常带着大段 tool 输出和 data: 图。你们被迫：

• 窗口大约 16 条，上限约 48
• 正文截断、不传 toolCards、不传 data: 预览
• 流式尽量 splice 一条，避免整表替换

这是在 迁就 Weex 序列化 + 布局，不是产品想要的完整列表。原生 ChatTableView 可以按 cell 复用、按行测高，不必先把历史砍成摘要。

4. 5+ / Weex 桥是同步税

例如内购注释：不要和 StoreKit 弹窗同时触发 Weex 布局，否则会 同步 调 getSafeAreaInsets 卡住。真机上 plus.*、相册、文件、支付、安全区，都会在 JS 线程和主线程之间来回。原生是直接调系统 API。

5. Weex 不是 UIKit

<list> / <cell> 看起来像原生列表，实际是：

• JS 虚拟 DOM → Weex 原生节点
• 能力子集（布局、富文本、手势冒泡都弱）
• 本页还用了 list-flip 倒序列表 才能贴底，属于 Weex 滚动模型的绕路
• Markdown、代码块、动态高度，Weex 测高和复用远不如 UITableView.automaticDimension

nvue 缓解了什么，为什么仍不够

nvue 确实缓解了「用 webview <scroll-view> 画几百条气泡」这一层：原生 view 绘制、有限回收、少一次 DOM/CSS。

它没有拿掉下面这些，所以仍然不是原生 App：

所以：nvue 是「聊天绘制层换引擎」，不是「App 换成原生」。 瓶颈从「WebView 排版」变成「JS 宿主 + 跨运行时同步 + Weex 列表模型」。对 Agent 聊天这种 高频流式、变高 cell、大 tool 输出 的场景，第二套瓶颈一样会被打满。

和原生工程差在哪（同一产品）

原生 native_ios 是单一 Swift 进程：UITableView + 按条 merge、键盘按窗口算 inset、没有 uni.$emit 快照窗。uni-app 即使用 nvue，也还是「JS 算完再通知另一套 UI」。

一句话： nvue 能让短会话、轻气泡比纯 Vue 页跟手；真机长会话、流式、工具卡、多 Tab 同时在时，瓶颈在运行时架构，不在某一两个 CSS。要到原生手感，只能像现在这样离开 Weex/WebView，用 UIKit/SwiftUI 自己画列表。

以上内容是基于ai的总结，基本也就是这个情况，尤其是对于这种可变cell+列表的绘制，性能就更是问题了，哪怕独立出来nvue页面，js主进程还是会卡住其他的操作。

相反，在andorid设备上就不会存在这个性能瓶颈，虽然都是uniapp框架，在安卓设备上流畅度基本能达到原生的效果。

实际真机效果对比：

上面的视频是 进入app之后，首先点了状态，后续其实又点了其他的tab页，但是此时已经卡死了。

上面的视频是基于swift的ios原生项目。

虽然页面功能一样，但是绘制的效果和性能却是天差地别。

当然，uni框架还有另外一个缺点就是，一些与系统打交道的东西还是需要原生插件支持，例如ios 的定位回调，ios的healthkit（闺蜜圈APP），安卓的各种系统设置等等，多数都是基于现有的uni插件来实现，所以，findu虽然是页面样式基础功能跨平台了，底层依然是基于原生的定位组件，系统操作组件，以及badge组件来堆起来了app的核心功能。

至于portable claw，则是需要tts引擎，很不幸baidu的tts引擎超过了200m，导致无法使用uni的云打包(打包也可以，交钱就行)。

这个问题，其实我之前在其他的文章中也提过。

为了解决云打包的问题，我是用uni的本地打包，基于xcode项目来实现打包，这也是ios版本发布的必经流程，这个操作其实也不算简单，需要配置一系列的东西，包括证书 mp文件等等。

这一系列的操作都是为了能够复用uni的代码，不用重新写。

只是，现实狠狠地给了我一巴掌，告诉我这个东西虽然可行，但是不够完美，或者说达不到自己的心理预期。作为一款app，这个运行效率是无法忍受的，这就有了原生的swift的ios项目：

说了这么多，并不是说uniapp一无是处。

在不需要与系统底层交互app中，uni无疑依然是开发效率和跨平台的最优选择，继承了基础的三方登录、内购、分享、地图等等能力，这些能力对于多终端的适配的确可以减少大量重复的工作。

不过，如果你需要一个高性能的app，那么最好的办法就是直接原生开发（有了ai，一切都简单了），至少目前我这里的优化已经到了自己的能力极限了。

成也UNI，败也UNI。

附简要跨平台框架性能对比（基于cursor总结）仅做参考：

转眼，竟然又快到中秋了。回头看，似乎路上光秃秃的什么也没有，转回头，往前走，路上也是光秃秃的。过去和将来，看不出任何的区别，不过可能是路越来越崎岖不平，愈发难走了。

周五的时候，公司的财务姐妹过来找我让帮忙改个数，我在处理的时候，她抬起手腕说：『感觉我快挂了，你看我现在的心率，99。啥也没干，现在就这个心率，感觉快猝死了。』

是啊，工作使人变态，健康状况也开始变得异常。严重点的猝死了，即使不严重的，也多多少少有些健康问题：甲状腺结节、咽炎、颈椎病、腰椎病、鼠标手等等。

命名平时右手用的更多，这几天自己左手的指头竟然有些疼。贴了几贴膏药，感觉稍微缓解了一点，对象说是转移了。

昨天为了去同学那里拿一个猫砂盆，再次到了许久未曾去过的cbd区域。现在高架桥下来就直接到了理工大学附近。山东路的交通状况，感觉比之前更加的拥堵了。

倒闭的家乐福，门前的停车场有些空旷，多余车位都空着。进入商场，商铺多户都关着门，还有几家正在装修。楼上的家家悦超市的人是最多的，进门就看到了这个东西：奇异莓。

这个东西本质上是猕猴桃的一种，不知道什么时候开始多了一个名字叫做奇异莓，其实猜也能猜到可能跟奇异果有关系，然而，我这小智商第一次看到这个东西还真没跟奇异果关联上，还以为是一种莓，例如：蓝莓、树莓、蔓越莓等等。

转悠到万达，吃了个大渔铁板烧。他们家真的是爱鱼籽，几乎所有的菜上都会带点鱼籽。199的家庭套餐，吃到最后也不知道到底吃了些啥，连菜单有啥都不清楚，稀里糊涂吃完饭，还剩下半份牛排和一份炒饭，打包带走。

人吃饱了，还得给猫猫准备吃的，昨天早上最后的一口猫粮给猫猫倒进碗里之后，就一点余粮也没有了。从万达直奔乐客城，当然，还有另外一个目的就是去给手机贴个膜。毕竟送了个贴膜次数，不用白不用。然而，贴完了回家就后悔了，贴的膜明显比手机屏幕小一圈，边缘滑动都剌手，这坑爹玩意儿。

好在之前买手机还有送的一张膜，果断把送的那破玩意儿撕下来，重新自己换上一张。

然鹅，这个曲面钢化膜也有问题，就是可见区域明显小于屏幕区域，尤其是四个角，可见范围明显变小了。

不知道bilibili为什么选了这个名称，现在这个语境下，我老觉得大好人这个东西多少带点比较诡异的味道。一说到好人，感觉就是大怨种。

前段时间沸沸扬扬的『走个面』，在之前的美美的红十字会，各种所谓的公益，有时候难免让人真的觉得自己是个怨种。

最近又出了月捐停了之后，不断的打电话追问为什么停了的事件。

你觉得你贡献了爱心，而他们觉得，你贡献的还不够。至于国际的，嗯，还不如国内的。

希望，自己不是怨种。

如果自己真的是怨种，我也只能画个圈圈诅咒他（她）。

自从猫猫来到家里之后，所有长叶子，不长叶子的东西，多多少少都经受过了数轮摧残，首当其冲的就是那盆十几年的文竹。

从郁郁葱葱的一人多高，吹下来还能在耷拉到地上的高度，硬生生的被咬成了光杆司令。

为了防止猫猫再去要其他的植物，对象该猫猫买了所谓的猫草，当然，多数人可能不知道哪个所谓的猫草其实就是麦子，对，你想的没错，就是我们平时吃的磨成面粉的麦子。

然而，猫猫对于这种植物并不感兴趣，连吃都不吃。对象说，你把猫草剪下来放到猫粮里看他吃不吃。理想很丰满，现实很骨感，事实证明他连闻都不闻。

『或许，等哪天麦子，长出关节来，硬邦邦的可能他就会吃了。』我说，然而，谁知道哪天这一盆麦子才能长大呢，挤在这么一个小盆里。

长方形的花盆里，撒下去的一包龙葵种子，也已经发芽，开始长出枝干，虽然大小不一，倒也是一片欣欣向荣的样子。住在楼上，最大的好处就是，不管什么时候，总是能保持一个相对来说温暖的温度，跟温室一样。

在这种环境下，植物也可以不在那么依赖于季节，春播秋收也可以不再严格遵守时节的规律。

文竹在备受璀璨之后，我把它挪到了洗衣机上面。那个高度虽然对猫猫来说没有什么难度。不过也算是暂时给了一个栖身之所，哪怕能躲过一时，也算是躲过了一时。至于什么时候躲不过了，那再提躲不过的事情也为时不晚。对象说，你可以买一盆新的放上。

只是，我觉得他还有救，之前也经历过枯萎，消亡。

之前挺过来了，这次，应该也可以。