@nananqujava speckit 或者 openspec ，选他们教程，选最下面通用那个，然后把 agent.md 里的内容作为角色定义复制进对话框，注意不要用 ai 生成

@asd999cxcx 首先不要用国内版，模型垃圾用什么也作用不大，只有 auto 模式还勉强可以（ ps. auto 模式应该不是国内模型，同时含有中英文的请求回复时一般为英文，符合国外模型特点，代码风格也不一样，效果要好一点）

还有 trae 国内版明显存在降智，同样模型无论是响应速度还是质量都比其他 ide 的要差，更不如付费的国际版，怀疑拿其他模型以次充好。而且 trae 的提示词存在明显问题，用默认 solo 模式只能开发前端，一写其他方面的代码就非常差，哪怕是 Gemini 3 pro ，后来我自己定义 agent 用 spec coding 后，效果提升了非常多

想多了，如果你用过就知道，对鸿蒙支持最好的反而是 Claude ，其次是 GPT 和 Gemini ，国内的都基本没更新过鸿蒙的训练资料。而且你都用 react 了，不如直接迁移到 react native 。鸿蒙的生态基本没有，开发难度会很高，而且对于 ai 来说没有 react native 熟悉。

@docx 小绿书早就变味了，现在差不多就这样

只有可以完全离线使用的软件或者开源软件才可以考虑买断，联网会员+国内作者大概率一段时间后跑路

投入更多资源提升体验 ❌
雇佣更多阿三写 bug 画饼 ✔️

鸿蒙更糟糕，你连去广告手段都没有了，当初刚有开发者搞了个 homojump 还在开发阶段，只是展示了下，官方火速禁用辅助功能 API

烂完了，早期连 code diff 都做不好，要么直接把文件内容整没了要么 diff 的代码错行，现在好不容易没这个问题了，问题模型还是烂，当初同样的 Claude 模型比其他家的明显降智，怀疑掺了不少水。最新的 solo 模式更是烂完了，solo code 模式 pro 会员开 max 开 plan ，经常不遵循指令复读，连继续都执行不对，指令修改文件给我直接输出回复里了还不对，要求按照文档来，结果写代码仍然不看文档用的旧 API+编的 API 不看 lint 到处 mock 到处 try catch ，甚至 try catch 还 tm 嵌套好几层！我从来没见过最近的模型写出过这么烂的代码，一年多前的 qwen 都没有！甚至不如最近出的 kat coder pro ，那个模型水平虽然没有其他的好，会写 mock 而且经常 API 对不上或者冗余封装，但是好歹量给足了而且免费啊，trae 这个感觉很多时候就是 7b 十几 b 的水平，然后记忆大一点。这玩意也就 IDE 界面做的好点，个人测试效果远不如 kiro/cursor/codebuddy/qwen 。刚被这玩意折腾了几小时，本来想设定好 plan 开 auto 睡觉起来看成果，结果被这玩意的折腾好几个小时成果还烂的一 p ，早知道不如买 minimax 了

首先，不要使用任何联网的输入法，更别说还是微信输入法这种实时回传数据的输入法

今日笑点

@kaicity
@LittleFox 早几年确实有些运营商定制的低端机是有 NFC 的，甚至是全功能的 NFC ，不过目的不是给老人用的，是给营业厅的工作人员开卡用的

@1una0bserver 你如果要用原生 view 写的话，我建议用 anko ，Contour 之类对 view 的 dsl 封装写，尽量避免用 xml ，一是更加接近声明式的写法，写起来更舒服点，二是避开 xml 中写 UI 的一堆坑。

首先我非常建议用 kotlin ，而且是 full kotlin ，本身 kotlin 经过优化已经和 Java 原生没啥性能差别了，而且 full kotlin 还可以不用考虑 Java 的空安全问题了。Java 你如果用了某些高版本特性或者函数必须 desuger 。而且某些机型魔改 ART ，未实现 JVM 中的某些函数（此处指某国产自研品牌），你用 kotlin stblib 中自己实现的同功能函数就不会遇到这个坑。
至于框架的话，考虑到设备兼容性和性能较低，首先排除 flutter ，在老低端机上性能较差，而且新版本用的 vulkan 和 Impeller 对老设备兼容性很差。uniapp 性能较差，uniapp-x 虽然是编译到原生，但其可用的插件很少，需要根据业务慎重考虑。所以基本就是 compose 和 view 里选。
你提到的 compose 性能问题，在多个版本的优化后，基本是早期才有的问题了。目前最多就是在长列表加载复杂数据这种场景，可能在某些极端场景下不如 recycleview 了，毕竟 recycleview 是优化了很多年的东西了。而且 compose 的一个好处就在于和原生 view 无缝兼容，具体使用中可以和原生 view 混合编写。原生那堆东西写起来非常折磨人，不如 compose 写起来舒服多了，你是前端的话应该更有体会。但是 compose 也不是说没有别的问题了，比如最新版本 1.8.x 我记得在某些 Android p 设备上会闪退，需要一点魔法，太旧的版本性能又太差，我个人建议图稳定先 1.5.x-1.6.x ，等熟悉了再升级。还有就是 compose 最低兼容到 Android 5 ，你要是需要兼容 Android 4.x 这种极老的设备的话，那就只能选择原生 view 了。
原生 view 是兼容性最强的，但也是坑最多的，写起来最折磨人的，上限极高下限极低，完全看你水平了。我反正能不用原生就不用原生写，太折磨人了。原生 view 除了写法折磨人，主要坑点在于不同版本兼容性适配，style 系统，还有不同系统对于 view 的魔改上。其中 style 系统折磨人的地方在于，它会因为你用的不同 SDK 版本，不同真机系统而出现不同的 bug ，还有 IDE 大多时候识别不出来 xml 中的问题，你需要在编译时甚至运行时闪退才知道有问题，而且很不好排查问题出在哪里。还有不同品牌系统多多少少都会魔改 view 系统，你得替他们擦屁股。

@AEnjoyable 有没有一种可能，我自己就是被 pcdn 误伤的受害者🥲
我用的移动流量，无论是镜像下载还是网页访问，都会被 ban ，而用家里的电信宽带就没事。后来我查了下我的出口 ip ，发现 ip 位于 pcdn 较多的 ip 网段内，估计是被识别为疑似 pcdn 了。倒是 ban 的就几个固定的镜像站，好像是 tuna 和 ustc 等几个，索性我就手动编辑了下源不用这几个了。

还有一种可能，你 ip 被识别为 pcdn 了，所以被 ban 了

一眼 kapt 和 dagger2 ，我自己写的应用用这俩的时候编译每次都得等一会，而且经常因为莫名其妙的原因编译卡住，清理缓存能缓解。迁移到 ksp+k2 能缓解一些，但还是慢。后来想想我写的也没多复杂，也不吃性能，研究了下迁移到 kodein 并移除 ksp 后，速度快多了，增量也能秒编译了。不过你这是 systemui ，没法像我那样迁移，无解，最多能清下编译缓存试试。

webdav 好像可以吧？

@WebKit WiFi direct 已经是非常普及的技术了，互传的协议只要系统在 11+就能用...