问春秋(用动态年龄和时代背景看历史)
apps.apple.com
ruler.im

🐶我的产品观
聊聊前东家豆瓣 m.okjike.com
做自己成长路上的栽灯人 m.okjike.com
抽象并不贯通 m.okjike.com
观测与坍缩 m.okjike.com

🐥探索Ai增量需求：
回归业内常识看国内大模型-七分数据三分算法 m.okjike.com
选品探索 m.okjike.com
说说我理解的Ai产品经理m.okjike.com
后知后觉对涌现的新理解 m.okjike.com
Ai与创新 m.okjike.com
不适合这轮Ai做的业务1 m.okjike.com
不适合这轮Ai做的业务2:Agent m.okjike.com

clawdbot skills 能力全览/分类

ClawdBot 之后，好像缺一个服务于本地环境的数据库作为中枢？

又看到一个17万赞的，下版我在底角加个水印不过分吧

AI Coding 之我看

25夏天尝试了拆了下vscode，觉得AI写代码是大而正的事，我是为数不多先做产品后会写代码的人，知道很多学代码的knowhow，试了三个星期，功能太复杂了没拆动，一个人搞不定。现在还有做到cursor的机会吗？大可能是有的，至少有这几个产品空间在

一、基础设施可复用（一个中型项目，70%工程量都在写基础设施，好的coding工具，完全可以让用户在day one就完成这部分，只需要写自己的业务代码就好了，他们包含但不限于
用户与权限 | 登录注册、绑定注销 | 支付订阅 | 消息通知 | websocket 通信|协议、about页面|log记录

二、工程目录与职责分离(好的目录本就是给AI的极简说明和结界)
产品目录合理职责分离也是在说上下文清晰，AI可以快速定位问题，用更小的上下文理解业务，也在避免AI视野盲区，原来你的xxxx功能藏在一个不显眼的文件，咱不要这么捉迷藏啊
好的目录本就是结界，避免AI大范围的影响代码
避免真假李逵的问题，代码debug半天发现，原来你在b文件也写了个同样的功能，两个混淆了啊
同时可以为AI设计框架，让AI清晰的串通前后端
比如限制api只承担桥梁的作用，业务在service进行，解耦|降低不确定性|
前后端实例、目录、service页面尽可能一一对应
让AI维护一个网页面板，初始化面板可以立马使用基础设置

三、代码的产品化
可视化面板：有个页面直接解耦产品功能，它不追求ui，定位在前后端衔接和中间数据debug，汇集api和功能的极简实现，可复制中间的json数据
业务功能的代码标准化，比如列表的筛选，比如筛选豆瓣书籍，用 request(apixxx,json={'word':'',type:'','rang_star':[]}) 要比
filter={'word':'',type:'','rang_star':[]) request(apixxx,json={'filter':store.filter}}
差很多，后者不用频繁修改api，后端api可以把filter直接发给service，增减filter只需要改前端的store、和后端service，AI修改的文件从>=5个减少到2-3个
代码检查脚本，比如检查定位哪些没有多语言的硬文字等等

最近心劲一般，有没有搞类似业务的，拉上我顾问参与下

HistoryEcho Overview