安歌449
行到水穷处,坐看云起时。
  • 注册会员
circle-image
文章总计
0 篇文章
circle-image
获赞数
赞
circle-image
总阅读量
0 阅读
circle-image
主页人气
725 人气
文章 动态 帖子
看起来这里没有任何东西。

加载中...

加载中...

  • 刚刷到这个 说真的第一反应是 又有人给typecho写插件了 不容易啊 typecho这玩意多久没更新了 我那个站还停在1 2 一堆插件早就不维护了 所以看到新的还挺高兴 但是吧 我看到那句 适用于所有Typecho主题 我就笑了 这话我是不太信的 兄弟 我自己用过至少五六个主题 每个主题的css命名习惯都不一样 有的用rem 有的用px 有的把全局字号设成14px 你插件塞进去 界面能不变形 我不信 除非你用了shadow dom 那还行 要是没做 迟早有人去你github提issue 说在他主题上聊天框挤成一坨 作者说基于Xuan's blog改善 我还特意去翻了原地址 原来那个确实只能用在特定主题 所以这个改动能说是有进步 这点得承认 不过我最关心的不是这个 我最关心的是api key存哪 后台配置页填的那个key是不是明文存数据库 我猜大概率是 因为typecho插件的配置就是那么存的 塞在options表里 那问题就来了 你博客但凡被人拖了库 或者你自己手滑把数据库导出来发群里 那个key就跟着出去了 到时候人家拿你的key猛刷gpt4 你第二天起来看账单 人傻了 这种事我真见过 不是我 是我一个群友 他装的一个插件也这么搞 后来账单两百多刀 找谁说理去 平台又不认 只认key是你的 所以我是真心建议作者 至少后台那个key输入框做成密码样式 页面别回显 另外加一句提示 告诉用户 万一泄露赶紧去后台吊销 再狠一点 可以在服务端做个中转 别让前端直接拿key去请求 虽然多一层 但安全多了 还有那个短代码 文章里嵌入 我一开始觉得挺方便 后来一想 不对 typecho的文章内容是走markdown解析的 你把短代码写在正文里 编辑器会不会把它当普通文字 或者你那个hook是在什么时机处理的 如果是在正文输出之后处理 那还好 如果是在markdown解析之前 那段方括号可能就被吃了 或者被转义 显示成一堆乱码 我没测 但我觉得这里容易翻车 而且就算能显示 一个聊天框夹在文章中间 上下都是正文 视觉上有点怪 我要是读者 我滑到一半突然看到个输入框 我会以为我点错了 独立页面那个方式我觉得更靠谱 干净 不跟正文打架 但独立页面又有个问题 它得走主题的header和footer 那些老主题 有的header里塞了一堆全局样式 有的footer里又加载一堆脚本 你这聊天框夹在中间 谁知道会不会被谁覆盖 响应式设计说得好听 但手机上那个软键盘一弹 页面会不会被顶上去 输入框会不会被挡住 这个不实测真不知道 我自己就遇到过 一个移动端聊天框 键盘一弹 输入框直接跑到屏幕外面去了 用户根本看不见自己打啥 气得我当场卸了 游客本地存储 登录用户云端同步 这个设计思路我理解 就是不想逼游客注册嘛 挺好 但云端同步存哪 是新建表还是塞进typecho自带的表里 如果是新建表 卸载插件的时候有没有删干净 我以前装过一个插件 卸了之后数据库里留了两张空表 强迫症看着难受 还得自己手动去drop 还有游客那个localStorage 清一次浏览器缓存就没了 对话记录全丢 用户会不会骂你 要不要给个提示 或者干脆允许导出 零依赖 移除jQuery 这个我要点个赞 真的 老插件十个里有八个依赖jQuery 现在主题都不带jQuery了 一装就报jQuery is not defined 烦得很 用原生js写fetch挺好 又小又快 还能顺手用fetch的流式输出 那个打字机效果 用户看着爽 说到流式 你这插件是流式还是一口气返回的 要是一口气返回 那用户得等好几秒 屏幕一片空白 体验差挺多 流式的话要处理SSE 前端还得拼chunk 稍微麻烦点 但值 温度参数默认0 7 我觉得聊天场景0 7有点飘 你可以调到0 3到0 5更稳一点 尤其是做博客问答 你一飘就开始编 编得比真的还像 我吃过这个亏 之前拿AI回答技术问题 它给我编了个根本不存在的函数 我还当真了 查了半小时文档才发现是它瞎说的 从那以后我调温度都往低了压 宁可它笨一点 也别胡说 最大回复长度2000 token 也算合理 再长用户也懒得看 系统提示词那个框 我觉得可以预设几个模板 比如技术问答一个 闲聊一个 客服一个 直接选 省得新手不知道该写啥 说到编 就得说内容安全 你把AI挂在自己博客上 等于开了个公开接口给全世界用 有人上来问一些奇怪的东西 你的api那边可能会触发风控 轻则警告 重则封号 而且你博客的服务器IP也会被记录 万一出了事 你解释不清 说这是网友问的不是我问的 人家信吗 我不是危言耸听 概率不大但也不是零 建议作者加个简单的频率限制 比如同一个IP一分钟最多几次 再加个词过滤 哪怕就过滤几个关键词也行 挡一挡 还有token用量 最好有个统计面板 让人今天就知道烧了多少钱 不然月底一看账单又傻眼 现在deepseek挺便宜 当默认确实是个聪明选择 但有人非要上gpt4 那就得提醒他一句 你这是拿钱当柴火烧 多模型支持这个点我挺喜欢 所有openai兼容格式 那就是说 ollama 也能接 localhost那个地址填进去就行 还有像one-api这种中转 一个key接一堆模型 特别适合折腾的人 你要是能在文档里提一句 会加分不少 还有个现实问题 你这插件挂在博客上 真的有人用吗 我说句扎心的 现在大部分个人博客 一天访问量能有几十个ip就不错了 文章下面评论都没几条 你放个AI聊天 大概率是零对话 我自己那个站 装过类似的东西 三个月一共三个人跟它聊过 其中一个还是我自己 测试用的 所以我觉得这插件更适合两种人 一种是技术博客 拿来做问答知识库 读者查文档方便 确实有用 前提是你自己把文档喂给它 另一种就是纯粹折腾玩 图个乐 那也行 我也属于这种 明知道没人用还是想装 装完截图发群里 爽 下载地址那个我提一句 有些兄弟网络不好 github打不开 或者clone到一半断了 作者能不能顺手在releases里打个zip包 或者放个别的盘也行 别嫌麻烦 真的有人需要 还有readme最好写清楚 最低php版本是多少 typecho最低多少 有没有依赖curl扩展 别让人装一半报错 然后来评论区问你 你又不在 多尴尬 我自己php 7 4 不知道你这个要求是多少 有空补一句 最后说个版权的事 作者写了基于Xuan's blog改善 原项目地址也贴了 这点做得对 但我建议再明确一下 是fork还是参考 改了哪些 有没有沿用原来的部分 最好在readme里写清楚 免得以后原作者看到了不高兴 开源圈这种事最容易起争议 提前写好 大家都省心 还有插件名 AiChat 这名字太通用了 搜一下能搜出一堆同名的 建议加个前缀 或者作者id 省得跟别人撞 行 我啰嗦完了 总结一下我的看法 插件本身思路没问题 该有的功能基本都有 全主题通用这点我保留意见 得实测 api key安全那块是最大的坑 内容安全和频率限制是必须要加的 不然早晚出事 短代码嵌入我持怀疑态度 独立页面更稳 我回头找个测试站装一下 有问题我再来这贴 😂 对了 忘记说了 你那聊天窗口高度默认450 在手机上是不是有点高 建议给个百分比或者vh 让它自适应 别写死像素 🤔

加载中...

来跟我聊聊吧~