不对啊
1. 路径是实体相关的，例如 path 中有<userid>部分，这样可以检测被利用后追究到账户
2. 签名是后端生成的，可以对请求鉴权和限流

所以我想不通被利用的点在哪，如果黑产知道你随时可以将它们连根拔除，那么它就不会来利用你的 OSS

## “使用 AI” 不是选择题。

全托管我也认为确实不合适，现在还没到时候。

会用、用得好就多用，不会用，就少用，但是放弃一定是不对的，因为 AI 是未来。

未来不需要刀耕火种的人工敲代码。

就像现在的裁缝可以手工缝纫，但肯定不会不懂缝纫机。

1. 聊天记录每次变动，属于动态内容，CDN 的缓存失效，但是网络加速效果还是有的。
2. CDN 不会有写入并发量的瓶颈，人家本身就是对象存储级别的写入性能。

建议：将历史聊天记录以块形式储存为静态不变的内容，例如聊天记录存为 index.json 往里面放第 201 条记录时候，即将 1-100 条内容另存为 page1.json, 然后 index.json 的第一行指向 page1.json ，后面是 101-201 行聊天记录。
这样就实现了仍然能利用到 CDN 的缓存特性，并不会频繁刷新缓存。

再下一步应该是读写分离，读总是从 CDN 读，但是写可以先缓存本地或者其他储存，有变化则定时同步到 OSS ，减少 OSS 写入。

但是总的来说，建议别折腾，CDN+OSS 没有你想的那么脆弱，除非你进行了并发测试证明性能真的达不到你的要求（可能性很低）

竟然能在这里看到 TiDB 的话题，最后我选了阿里云瑶池数据库，也支持自部署，默认云服务开箱即用

https://imgur.com/aiQ7XXI

我不知道这个 V2EX 发个图片为什么这么难


我不知道这个 V2EX 发个图片为什么这么难

我不知道你的并发量多大 oss 都扛不住


我不知道你的并发量多大 oss 都扛不住

https://s3.bmp.ovh/imgs/2025/03/26/8563a5c7cbd7f437.png

我不知道你的并发量多大 oss 都扛不住

澎拜 OS 不更新不也养老吗？

“上述也许可以归因为个人 Prompt 姿势不对，但之所以觉得其“闭合”，还有一个原因是大模型的上下文限制：对于一个解耦且不同人负责不同模块的项目，Cursor 无法很好将别人的变更同步到上下文中，在新代码里容易根据已有上下文在犄角旮旯里去用 @deprecated 的东西。（除非你把相关的 commit/文件都找出来显式地 @给它）
”
针对这一点，给出一点心得，当你手动改完代码后，告诉它：
“我已修改 XXX ，在后续工作时，请先检查已有代码”
“我已修改 XXX ，使用 git diff 查看我的修改，然后继续做 XXX”

我在做的是`文档驱动开发` 其中文档也是 AI 写的。
反驳一下楼上认为没必要的理由：
1. AI 健忘，所以必须有固定不会遗忘的参考点，例如文档或单元测试。
2. AI 会的太多，它不知道自己应该在编码员，还是主程还是架构师层面来帮你完成你的想法，所以你需要明确它应该怎么做，如果你让它完成这些测试用例的开发，那么它就是编码员，如果你用需求文档作为参考点，它就工作在架构师层面，如果你用 API 文档，它可能工作在主程层面。

对于复杂的功能点，我也选择用测试用例去固化接口行为，然后优化修改实现代码。虽然不太符合楼主说的 TDD ，但实践证明，测试用例在 AI 编程中具有现实意义。
（温馨提示：1AI 会在无法跑通用例时修改用例，2AI 有事会偷懒用 Mock 实现来跑通用例，所以监督开发在当前阶段还是必须项，这也是我们大部分程序员暂时还没失业的原因，偷着笑吧）

使用 AI 一定是有方法有策略的，绝不是一些人说的怎么用都一样，全靠大模型能力。

参考： https://zhuanlan.zhihu.com/p/29042557398

一句话总结: TDD 用于 AI 编程是有利无害的技巧。

各有优缺
<img src="https://pan.star-lock.cn/f/YJTA/%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_20250319174016.png">

cursor+SSH 大赞，我全天都在这样开发。说远程桌面的那些，你们不知道 VNC 和 Linux 的桌面多难用吗，而且只是用来跑环境的机器，给它装个桌面，不是很多余吗？

相对来说，剪映识别效果最好，人工修正必不可少的。