iintothewind

@freekindom #29 确实是个不错的思路.

去中心化网络的内容类产品除了数据上链以保证不可更改这一种安全需求, 还有隐私控制(私有信息和共有信息可见性), 权限, 加密(端到端 vs 明文), 或者让 CCP 无法看到内容或者即使能看到也封不了, 另外还有数据同步传输效率.
上面很多非功能需求其实是互斥的, 只能做取舍. nostr 的很多 NIP 就是在不同的场景下的取舍, NIP 之间甚至在打架, 没办法满足所有场景的技术要求.

其实 nostr 已经很成熟了,
可是即使这样, nostr 也因为分布式网络的高门槛(数据安全自己负责,丢 Key 无法找回,relay 安全性和权限配置)等原因, 使用者很少

自己发明轮子也只能自娱自乐了.

我觉得这样的用法有点太消耗服务器资源了.

薅羊毛还是文明的薅, 羊毛才能薅的久啊.

每个月为了翻墙, 要花四五百, 这还不算宽带费用?
这也太贵了吧?

其实, 你所说的"古法编程"才是人类去"编程".
你所说的"不靠 AI", 不是你"编程", 是你"动嘴"或者输入需求,Coding Agent 去"编程"

--------

这就好比是汽车领域的"智驾", "L2.99999 循环的遥遥领先", Autopilot, 当你手离开了方向盘时,
你不是在驾驶, 你这是在坐车, 不是在开车.

其实 coding agent 在设计的时候, 上下文管理有很多不同的设计思路, 其整体思想就是如何构建一个相对稳定的上下文:
- 如何构建稳定前缀(stable prefix)
- 消息如何分类
- 追加日志(appendOnly), 哪些才能追加到不变区
- 温区如何定义(大小, entry 分类, 读写次数如何决定热度, 多长时间过期)
- 修剪机制
- 压缩水位线(上水位, 下水位)线如何划分
- 换模型带来的窗口抖动
这些都是需要在设计阶段考虑的事情.....

pi 在设计的时候是故意简化设计的, 只有一条 compact 高水位线, 其实很多时候没有做优化.
没做优化就是朴素的任其增长, 然后到水位线做有损压缩,经历一次信息失真.
但是无论如何优化, 最终上下文还会被占满, 关键信息不能做到永远保证不丢, 所以还是需要在访问关键信息的时候有调用外部记忆存储的能力, 让 agent 可回溯超出上下文的记忆.

可是最关键的 Gemini API 竟然不提供?

35 岁即将失业 + 英语差 => 想去报班 ????
----------
这个思路是错的, 因为:
1. 你没看外部环境确认你自己假设英语好能否帮你改变现状.
2. 报班能否帮你把英文变好.

你单纯想去报班, 在我看来就是去交智商税.