[推广] 芒果 ai 最新套餐来咯 80 元=800 刀额度， [附带一些吐槽和心酸]
也发过很多次帖子了
也有很多朋友支持进群，都给大伙儿整了兑换码，让大伙儿体验
现在市场上 ai 中转多如牛毛，但是你可以相信芒果 ai ，因为我也是程序员，并且之前也折腾过开源项目
也在开源项目上付出了很多精力，现在 ai 时代也深深体会了各种 ai 以及 ai 中转
cursor 我应该是第一批充 pro 的，还是没有 codex 和 claude code 好用
现在 ai 中转鱼龙混杂，但是芒果 ai 在这里绝对保真保质量，甚至我多次在群里面公开芒果 ai 的利润和计算公式以及成本如何计算
芒果始终保持：大伙儿都有好用，便宜的 token
希望大伙儿能在这个时代解放双手创造更多更好的内容
如果有使用量很大的朋友，请私聊我，我们一起来解决
站点： https://ai.mggoo.com/
也发过很多次帖子了
也有很多朋友支持进群，都给大伙儿整了兑换码，让大伙儿体验
现在市场上 ai 中转多如牛毛，但是你可以相信芒果 ai ，因为我也是程序员，并且之前也折腾过开源项目
也在开源项目上付出了很多精力，现在 ai 时代也深深体会了各种 ai 以及 ai 中转
cursor 我应该是第一批充 pro 的，还是没有 codex 和 claude code 好用
现在 ai 中转鱼龙混杂，但是芒果 ai 在这里绝对保真保质量，甚至我多次在群里面公开芒果 ai 的利润和计算公式以及成本如何计算
芒果始终保持：大伙儿都有好用，便宜的 token
希望大伙儿能在这个时代解放双手创造更多更好的内容
如果有使用量很大的朋友，请私聊我，我们一起来解决
站点： https://ai.mggoo.com/
[分享创造] 做了一个 Rust 内核的 pandas-like DataFrame，用来实时计算 K 线技术指标
我做了一个开源 Python 包：
一个 4 年、15 分钟级别的交易数据回测，单个标的大约就是 14 万根 K 线。50 个标的就是约 700 万行。跑这还没开始扫参数，也还没开始训练模型。经常一个回测个把小时，还没跑模型光数据处理就花掉半小时也是常有的事情。
很多时候真正先把人卡住的不是策略逻辑，而是数据处理：读数据、拼特征、算 RSI 、MACD 、ATR 、Bollinger Bands ，一跑就是好几分钟。模型还没开始训练，回测还没真正跑起来，特征表已经先变成瓶颈。
如果是在实时循环或者逐根 K 线回测里，这个问题会更明显：K 线每新增一根，pandas 流水线就可能把整列指标重算一遍。但从数据依赖上看，新来的只是最后一根 K 线，前面大多数指标值其实已经稳定了。
我之前做了个 https://github.com/kaelzhang/stock-pandas ，但后来发现它是真的太慢了，哪怕后来我把部分内容用 pyO3 换成了 rust ，但发现很大的瓶颈发生在 pandas 本身。最后无奈之下，只好把整个全部用 rust 重写了。
● API 尽量保持 pandas 手感；
● 内置 250+ 个交易指标 （非常多了，我没有专门做过对比，但搞不好是相关类库里最多的，让 AI 来做因子异动的研究会很有用）；
● 指标用指令列表达，例如
● 指标列可以缓存；
● 追加新 K 线后，下一次读取只刷新受影响的尾部窗口；
● 底层用 Rust kernel ；
● 可以导出 NumPy / Torch 。
一个最小例子：
我现在最想收集三类反馈：
1. 这个指标指令 API 是否符合大家写指标流水线的习惯；
2. 还有哪些常用指标或市场惯例缺失；
3. benchmark 方法是否有偏差，是否有真实场景里
它不是交易信号服务，也不是通用 pandas 替代品；普通表格分析继续用 pandas / polars 就好。
GitHub: https://github.com/kaelzhang/volas
在很多场景下是非常的快了，不少场景下快了几百倍。这里也有个性能对比: https://volas.ost.ai/
我做了一个开源 Python 包：
volas。一个 4 年、15 分钟级别的交易数据回测，单个标的大约就是 14 万根 K 线。50 个标的就是约 700 万行。跑这还没开始扫参数，也还没开始训练模型。经常一个回测个把小时，还没跑模型光数据处理就花掉半小时也是常有的事情。
很多时候真正先把人卡住的不是策略逻辑，而是数据处理：读数据、拼特征、算 RSI 、MACD 、ATR 、Bollinger Bands ，一跑就是好几分钟。模型还没开始训练，回测还没真正跑起来，特征表已经先变成瓶颈。
如果是在实时循环或者逐根 K 线回测里，这个问题会更明显：K 线每新增一根，pandas 流水线就可能把整列指标重算一遍。但从数据依赖上看，新来的只是最后一根 K 线，前面大多数指标值其实已经稳定了。
我之前做了个 https://github.com/kaelzhang/stock-pandas ，但后来发现它是真的太慢了，哪怕后来我把部分内容用 pyO3 换成了 rust ，但发现很大的瓶颈发生在 pandas 本身。最后无奈之下，只好把整个全部用 rust 重写了。
volas 的思路是把 OHLCV 指标计算这层做好：● API 尽量保持 pandas 手感；
● 内置 250+ 个交易指标 （非常多了，我没有专门做过对比，但搞不好是相关类库里最多的，让 AI 来做因子异动的研究会很有用）；
● 指标用指令列表达，例如
df["rsi:14"]、df["macd"]；● 指标列可以缓存；
● 追加新 K 线后，下一次读取只刷新受影响的尾部窗口；
● 底层用 Rust kernel ；
● 可以导出 NumPy / Torch 。
一个最小例子：
df["rsi:14"]
df.append(new_bar)
df["rsi:14"] # 只刷新受影响的尾部窗口
我现在最想收集三类反馈：
1. 这个指标指令 API 是否符合大家写指标流水线的习惯；
2. 还有哪些常用指标或市场惯例缺失；
3. benchmark 方法是否有偏差，是否有真实场景里
volas 明显输给 TA-Lib / pandas-ta / 自己实现。它不是交易信号服务，也不是通用 pandas 替代品；普通表格分析继续用 pandas / polars 就好。
volas 只想把 OHLCV 技术指标这层做快、做全、做得适合实时追加。GitHub: https://github.com/kaelzhang/volas
在很多场景下是非常的快了，不少场景下快了几百倍。这里也有个性能对比: https://volas.ost.ai/
[量化交易] 看到的量化公司数据分析的 jd，感觉我之前学的还不到位（本人不是数学和物理相关专业的）
可以进行程序开发量化开发测试；具有深厚的 AI 与机器学习功底，掌握从经典模型到前沿深度学习的理论与实践能力。具备强大的代码工程能力；具有较强的“物理-数学"思维模型，能将市场波动抽象为物理过程，从“作用力”和“能量”角度分析多空力量对比；能够运用知识理论评估交易策略或投资组合在极端条件下的概率；能够将计算机科学、物理学中的成熟理论、模型和方法，创造性地应用于金融交易与数据分析领域。
我自己平时交易的时候也没有想到物理学理论也能用来做交易。“物理-数学"思维模型，从“作用力”和“能量”角度，这些词汇看起来蛮高大上的，但是我依旧找不到我自己交易体系中对应这些词汇的概念知识。这应该就是我的盲区了，如果有大神能指点指点这 jd 对应平时交易的哪些知识就好了。
可以进行程序开发量化开发测试；具有深厚的 AI 与机器学习功底，掌握从经典模型到前沿深度学习的理论与实践能力。具备强大的代码工程能力；具有较强的“物理-数学"思维模型，能将市场波动抽象为物理过程，从“作用力”和“能量”角度分析多空力量对比；能够运用知识理论评估交易策略或投资组合在极端条件下的概率；能够将计算机科学、物理学中的成熟理论、模型和方法，创造性地应用于金融交易与数据分析领域。
我自己平时交易的时候也没有想到物理学理论也能用来做交易。“物理-数学"思维模型，从“作用力”和“能量”角度，这些词汇看起来蛮高大上的，但是我依旧找不到我自己交易体系中对应这些词汇的概念知识。这应该就是我的盲区了，如果有大神能指点指点这 jd 对应平时交易的哪些知识就好了。
[程序员] Kimi K3 这波真的爆了，你们用着感觉怎么样？
这几天被 Kimi K3 刷屏了，X 上在吹，HN 上在吹，都说是国产之光，deepseek 时刻 2.0 来了。
我也试了一下，浅浅分享自己的体验吧。
先说好的地方：
● 前端能力很强。
Kimi K3 前端能力这块，算是跻身全球第一梯队，真要个人排名的话，目前我给它排第二，还超越不了 Fable 5--LMArena 人类盲投榜上它前端甚至排第一，但我实测体感，Fable 5 还是更稳。
不过比 GPT-5.6 强得多，这是 GPT 系列家族的通病，前端能力一直很弱。
特别是那个刷屏的 3D 建模，我不知道设计圈怎么看，我觉得挺牛的。
● 长时复杂任务处理能力也很不错。
比如要做一个复杂的系统，定好一份计划，扔给它，/goal 模式让它自动处理，出错的概率，以及最后交付的结果非常不错。
● 原生多模态能力。
K3 可以直接理解视频，比如语气，音效，转场之类的，比普通的只能理解文字和图片的 CC/Codex 好多了。喂给 K3 一个视频，让它帮你生成同样风格的 seedance 的提示词，它可以生成得很精准。
● 开源。
Kimi 是开源的，权重 7 月 27 日就放出来，这意味着以后任何一家 AI 公司都可以直接拿去用，拿去蒸馏，而 Fable 5 和 GPT-5.6 都是自家闭源的旗舰大模型。
然后再讲讲不好的地方吧。（轻喷）
● 国产最贵。
目前 K3 价格是国产最贵，如果你和国产对比，你一定会不习惯，甚至说它想钱想疯了，但是和国外对比不算贵，成本和 GPT-5.6 差不多，约是 Opus 4.8 的一半。不过考虑到能力嘛，一分钱一分货，我觉得有道理。
● 速度稍慢。
感觉它比 CC + Fable 5 慢得多，比 Codex + GPT-5.6 也一样慢不少。
● 幻觉率偏高。
这个你瞎编一个问题去问它，你就知道了。幻觉率高的模型会给你一个答案，并且瞎编一个理由。
但是幻觉低的模型，它遇到它不知道的知识，会诚实地告诉你它不知道，甚至可以反问你。
最后，综合评价一下，我觉得它确实能跻身世界前三，但跟 CC + Fable 5 和 Codex + GPT-5.6 还有点差距。
但这毕竟是国产模型第一次敢跟 Anthropic 和 OpenAI 掰手腕，所以我觉得，还是未来可期啊。
你们试了没？
这几天被 Kimi K3 刷屏了，X 上在吹，HN 上在吹，都说是国产之光，deepseek 时刻 2.0 来了。
我也试了一下，浅浅分享自己的体验吧。
先说好的地方：
● 前端能力很强。
Kimi K3 前端能力这块，算是跻身全球第一梯队，真要个人排名的话，目前我给它排第二，还超越不了 Fable 5--LMArena 人类盲投榜上它前端甚至排第一，但我实测体感，Fable 5 还是更稳。
不过比 GPT-5.6 强得多，这是 GPT 系列家族的通病，前端能力一直很弱。
特别是那个刷屏的 3D 建模，我不知道设计圈怎么看，我觉得挺牛的。
● 长时复杂任务处理能力也很不错。
比如要做一个复杂的系统，定好一份计划，扔给它，/goal 模式让它自动处理，出错的概率，以及最后交付的结果非常不错。
● 原生多模态能力。
K3 可以直接理解视频，比如语气，音效，转场之类的，比普通的只能理解文字和图片的 CC/Codex 好多了。喂给 K3 一个视频，让它帮你生成同样风格的 seedance 的提示词，它可以生成得很精准。
● 开源。
Kimi 是开源的，权重 7 月 27 日就放出来，这意味着以后任何一家 AI 公司都可以直接拿去用，拿去蒸馏，而 Fable 5 和 GPT-5.6 都是自家闭源的旗舰大模型。
然后再讲讲不好的地方吧。（轻喷）
● 国产最贵。
目前 K3 价格是国产最贵，如果你和国产对比，你一定会不习惯，甚至说它想钱想疯了，但是和国外对比不算贵，成本和 GPT-5.6 差不多，约是 Opus 4.8 的一半。不过考虑到能力嘛，一分钱一分货，我觉得有道理。
● 速度稍慢。
感觉它比 CC + Fable 5 慢得多，比 Codex + GPT-5.6 也一样慢不少。
● 幻觉率偏高。
这个你瞎编一个问题去问它，你就知道了。幻觉率高的模型会给你一个答案，并且瞎编一个理由。
但是幻觉低的模型，它遇到它不知道的知识，会诚实地告诉你它不知道，甚至可以反问你。
最后，综合评价一下，我觉得它确实能跻身世界前三，但跟 CC + Fable 5 和 Codex + GPT-5.6 还有点差距。
但这毕竟是国产模型第一次敢跟 Anthropic 和 OpenAI 掰手腕，所以我觉得，还是未来可期啊。
你们试了没？
[酷工作] [广州] SHEIN 内推： Java 、算法、AI 视觉、供应链研发、测试、运维、网络、安全、架构， 15-70k
整理了一批 SHEIN 当前广州 base 的全量 16 个技术类岗位。目前 SHEIN 招聘官网或者 BOSS 直聘没办法一下子全部筛选出来，我就手动一个个筛选出来广州这部分技术岗位+各自对应的公开薪资。
这批岗位方向覆盖 Java 、算法、AI 视觉、供应链研发、测试、运维、网络、安全、架构等，薪资范围最高可达 70K （薪资范围上下限主要看简历情况、最终职级定级，供大家谈薪参考）：
1️⃣ AI 视觉 / 算法方向｜ 20K-45K+
包括高级测试工程师-AI 视觉、算法工程师/算法专家-AI 视觉、JAVA 工程师-AI 视觉等。偏 AI 视觉落地、模型/工程协同、视觉质量评估和业务系统建设。
2️⃣ 供应链 / Java 后台方向｜ 20K-40K
包括高级/资深 Java 工程师（品类自营）、高级 JAVA 工程师-供应商研发、高级 JAVA 工程师-供应链等。适合有供应链系统、交易履约、采购/供应商系统、复杂业务后台经验的同学。
3️⃣ 架构 / 核心系统方向｜ 40K-70K
如架构师（商家备货&结算），更看重复杂系统设计、业务抽象、稳定性和跨团队技术方案推动能力。
4️⃣ 运维 / 网络 / 数据库基础设施｜ 15K-35K
包括资深 IT 系统运维工程师、高级/资深网络工程师等，偏基础设施稳定性、网络架构、系统运维和故障处理。
5️⃣ 安全方向｜ 25K-60K+
包括资深安全工程师、网络安全 NTA 、移动安全、合规治理、专家安全工程师等。适合有攻防、安全体系、数据/合规治理、移动端安全经验的候选人。
具体岗位清单，可以复制下面 moka 链接到微信打开：
https://app.mokahr.com/su/pltieo
如果看完岗位 jd 有信心满足要求，可以直接在链接内内推投递（链接内无需填内推码）。或者官网投递，填我的内推码。
官网：careers.shein.cn/
内推码：NTA1yhF
如果不确定适合哪个方向，可以填一下匹配收集表，我来帮忙判断匹配度：
https://doc.weixin.qq.com/forms/APMA2QcuAAkATMAFgYMAEYCNtftbo7jpf?page=1
补充说明：
我是 SHEIN 员工，不是 HR ，这帖只是内推信息整理，不代表官方招聘口径。
SHEIN 不同部门、团队、业务线差异比较大，我不能给所有团队背书。
建议大家面试时重点确认团队业务、汇报线、加班节奏、人员稳定性和 HC 背景。
内推不保证面试或 offer ，也不保证 HR 回复时效，最终还是以 HR 和业务筛选为准。
如果已经明确匹配岗位，建议直接官网投递并填写内推码；表单只是给不确定方向的人做初步匹配用，不是必填。
有问题评论区我会一一解答，保证回复真实有效（会跟对应 HR 咨询确认）。
我也把整理逻辑、技术方向说明、投递方式和常见问题放在 GitHub ，后续如果岗位方向有变化，会优先更新这里： <https://github.com/andy-shein-referral/shein-tech-referral-notes>
整理了一批 SHEIN 当前广州 base 的全量 16 个技术类岗位。目前 SHEIN 招聘官网或者 BOSS 直聘没办法一下子全部筛选出来，我就手动一个个筛选出来广州这部分技术岗位+各自对应的公开薪资。
这批岗位方向覆盖 Java 、算法、AI 视觉、供应链研发、测试、运维、网络、安全、架构等，薪资范围最高可达 70K （薪资范围上下限主要看简历情况、最终职级定级，供大家谈薪参考）：
1️⃣ AI 视觉 / 算法方向｜ 20K-45K+
包括高级测试工程师-AI 视觉、算法工程师/算法专家-AI 视觉、JAVA 工程师-AI 视觉等。偏 AI 视觉落地、模型/工程协同、视觉质量评估和业务系统建设。
2️⃣ 供应链 / Java 后台方向｜ 20K-40K
包括高级/资深 Java 工程师（品类自营）、高级 JAVA 工程师-供应商研发、高级 JAVA 工程师-供应链等。适合有供应链系统、交易履约、采购/供应商系统、复杂业务后台经验的同学。
3️⃣ 架构 / 核心系统方向｜ 40K-70K
如架构师（商家备货&结算），更看重复杂系统设计、业务抽象、稳定性和跨团队技术方案推动能力。
4️⃣ 运维 / 网络 / 数据库基础设施｜ 15K-35K
包括资深 IT 系统运维工程师、高级/资深网络工程师等，偏基础设施稳定性、网络架构、系统运维和故障处理。
5️⃣ 安全方向｜ 25K-60K+
包括资深安全工程师、网络安全 NTA 、移动安全、合规治理、专家安全工程师等。适合有攻防、安全体系、数据/合规治理、移动端安全经验的候选人。
具体岗位清单，可以复制下面 moka 链接到微信打开：
https://app.mokahr.com/su/pltieo
如果看完岗位 jd 有信心满足要求，可以直接在链接内内推投递（链接内无需填内推码）。或者官网投递，填我的内推码。
官网：careers.shein.cn/
内推码：NTA1yhF
如果不确定适合哪个方向，可以填一下匹配收集表，我来帮忙判断匹配度：
https://doc.weixin.qq.com/forms/APMA2QcuAAkATMAFgYMAEYCNtftbo7jpf?page=1
补充说明：
我是 SHEIN 员工，不是 HR ，这帖只是内推信息整理，不代表官方招聘口径。
SHEIN 不同部门、团队、业务线差异比较大，我不能给所有团队背书。
建议大家面试时重点确认团队业务、汇报线、加班节奏、人员稳定性和 HC 背景。
内推不保证面试或 offer ，也不保证 HR 回复时效，最终还是以 HR 和业务筛选为准。
如果已经明确匹配岗位，建议直接官网投递并填写内推码；表单只是给不确定方向的人做初步匹配用，不是必填。
有问题评论区我会一一解答，保证回复真实有效（会跟对应 HR 咨询确认）。
我也把整理逻辑、技术方向说明、投递方式和常见问题放在 GitHub ，后续如果岗位方向有变化，会优先更新这里： <https://github.com/andy-shein-referral/shein-tech-referral-notes>
[程序员] OpenPencil v0.8.0:全面 Rust 化，跨平台稳定性提升；设计能力大幅提升，针对 GLM、DS 等模型特别优化
久等了，经过 2 个月苦战，OpenPencil 的 v0.8.0 终于来了
这次带来全新的体验，彻底解决一些跨平台问题，尤其针对国产模型做了很多特别优化，提升了设计审美的底线！
v0.8.1 地址： https://github.com/ZSeven-W/openpencil/releases/tag/v0.8.1
欢迎兄弟们继续体验、继续拍砖～
久等了，经过 2 个月苦战，OpenPencil 的 v0.8.0 终于来了
这次带来全新的体验，彻底解决一些跨平台问题，尤其针对国产模型做了很多特别优化，提升了设计审美的底线！
v0.8.1 地址： https://github.com/ZSeven-W/openpencil/releases/tag/v0.8.1
欢迎兄弟们继续体验、继续拍砖～
[分享发现] [自荐开源] vlaina - 没错就是那个 Catime 作者的新作笔记软件
vlaina.com https://github.com/vladelaina/vlaina
没错没错，你没看错，就是那个写纯 C 的Catime的作者的新作，也是 Catime 半年迟迟没有发布一直在做的事情
这个是个什么？
一. 传统的 markdown 编辑器，这块也是打磨最多的一个地方
这块是对着友商打磨的，底层是独立从milkdown(可以理解为是 Typora 的开源实现)分叉出来开始打磨的，然后添加大家一些常用的功能
1. 选中文本之后的工具栏，可以实时预览效果 😋
2. / 调出快捷命令 - 这个块是独立实现的（哈哈哈哈，这块折磨了好久 🤯）
3. 右侧 ai 对话侧边栏，可以 @选择当前的文件总结，还可以选中内容拖动放到笔记中，非常适合让 ai 总结然后手动维护，这里你可能会问，为啥不是让 ai 直接修改原文呢？我的想法是笔记是一个有私人意义的地方，你不会希望自己所有的笔记全是 ai 的，然后下回再看的时候还需要再去理解一次
4. 左侧侧边栏
右键左侧侧边栏
大纲
----------------------
双链
白板，这块做棒的是支持数位板，之前买数位板是为了学习板绘，结果一直都在吃灰，没想到居然在这里用上了，哈哈哈哈哈哈哈 🥰
ai 对话部分，基本好用的点都给支持上了
所以为啥不是 tauri
很简单，vlad 用的是 Arch ，如果你有尝试过就会发现......(投降投降)
----------------------
如果喜欢的话点个 star 吧:>
https://github.com/vladelaina/vlaina
当前这也是第一次推广，打磨的也有很快存在不到位的地方，哈哈哈哈哈哈哈但是感觉还是比Catime第一版要好，那个时候 6000 行所有的代码都写到一个 main.c 中
vlaina.com https://github.com/vladelaina/vlaina
没错没错，你没看错，就是那个写纯 C 的Catime的作者的新作，也是 Catime 半年迟迟没有发布一直在做的事情
提前猜个你会好奇的点： 这个使用什么做的？原生？Electron,没错，既不是原生，也不是 tauri ，而是大家都在抱怨体积大的 Electron ，相信你一定好奇为啥我这把 Catime 之前做到 200kb 的原生开发者为啥不选 tauri 而是 Electron 吧，答案就留到文章的末尾吧 😏
这个是个什么？
一. 传统的 markdown 编辑器，这块也是打磨最多的一个地方
这块是对着友商打磨的，底层是独立从milkdown(可以理解为是 Typora 的开源实现)分叉出来开始打磨的，然后添加大家一些常用的功能
1. 选中文本之后的工具栏，可以实时预览效果 😋
2. / 调出快捷命令 - 这个块是独立实现的（哈哈哈哈，这块折磨了好久 🤯）
3. 右侧 ai 对话侧边栏，可以 @选择当前的文件总结，还可以选中内容拖动放到笔记中，非常适合让 ai 总结然后手动维护，这里你可能会问，为啥不是让 ai 直接修改原文呢？我的想法是笔记是一个有私人意义的地方，你不会希望自己所有的笔记全是 ai 的，然后下回再看的时候还需要再去理解一次
4. 左侧侧边栏
右键左侧侧边栏
大纲
----------------------
双链
白板，这块做棒的是支持数位板，之前买数位板是为了学习板绘，结果一直都在吃灰，没想到居然在这里用上了，哈哈哈哈哈哈哈 🥰
ai 对话部分，基本好用的点都给支持上了
所以为啥不是 tauri
很简单，vlad 用的是 Arch ，如果你有尝试过就会发现......(投降投降)
----------------------
如果喜欢的话点个 star 吧:>
https://github.com/vladelaina/vlaina
当前这也是第一次推广，打磨的也有很快存在不到位的地方，哈哈哈哈哈哈哈但是感觉还是比Catime第一版要好，那个时候 6000 行所有的代码都写到一个 main.c 中
[程序员] 毕业数年，有和我一样学不下去的同行么
因为 AI 的缘故现在有很多现成的聚合网站做教程，知识都触手可得。 但即便减少了个人检索知识的时间，看书依然是个很苦闷的过程，看不懂看不透，代码放那儿了也看不进去。 已经怀疑自己适不适合做程序员这一行了，人在没有天赋的事情上投资，不仅仅是时间成本，还有耗费的精力和情绪。 每每想到有那么几个天纵奇才的人物就觉得自己是否应该换一条赛道----譬如王若度、王永强、詹恩贵、庞众望。强的人我认为就是文曲星下凡，学啥会啥。太糟心了
因为 AI 的缘故现在有很多现成的聚合网站做教程，知识都触手可得。 但即便减少了个人检索知识的时间，看书依然是个很苦闷的过程，看不懂看不透，代码放那儿了也看不进去。 已经怀疑自己适不适合做程序员这一行了，人在没有天赋的事情上投资，不仅仅是时间成本，还有耗费的精力和情绪。 每每想到有那么几个天纵奇才的人物就觉得自己是否应该换一条赛道----譬如王若度、王永强、詹恩贵、庞众望。强的人我认为就是文曲星下凡，学啥会啥。太糟心了
[OpenAI] 网站才开发到一半， AI 额度就用完了，只能先暂停一下 😅
网站才开发到一半，AI 额度就用完了，只能先暂停一下 😅
半成品放在这里：Magical Meow Meow Cartoon
等补充额度后再继续完善。
网站才开发到一半，AI 额度就用完了，只能先暂停一下 😅
半成品放在这里：Magical Meow Meow Cartoon
等补充额度后再继续完善。
[程序员] Vibe Coding 副业四个月：成本超出收益，要放弃吗？
楼主本身是一名程序，Vibe Coding 流行后，我一直觉得，开发的技术门槛会越来越低，每个程序员或许都应该做一个自己的独立项目，放到市场上试一次水。
于是从今年 3 月开始，用业余时间做了一个 A 股新闻事件分析工具“新闻雷达”。
四个月以后，我最大的感受是：技术反而是最容易解决的部分，真正困难的是运营、推广和收费。
做了一个复盘。
项目做了什么
我平时会关注财经新闻。新闻本身很多，费时间的是判断它影响哪些行业和公司，这种关联是否有真实业务依据，以及类似事件过去发生后市场如何表现。
新闻雷达会抓取新闻、过滤噪音，通过 AI 和本地股票及公告数据分析相关公司，再记录事件后的市场表现。3 月 24 日开始开发，5 月 4 日上线第一版。在 V2EX 发了帖子： https://www.v2ex.com/t/1210161
上线后我又不断增加历史事件、自选股、概念、投研和会员等功能。工程越做越完整，功能越来越多。现在回头看，我可能是犯了一个错误：用持续开发代替产品验证。
四个月数据
● 注册用户 384 人；
● 当前会员用户 29 人（含赠送）
● 累计会员收入 1600 元；
● 流量最近日天约 1000 访客
● 最近 30 天流量如图
https://i.imgur.com/cmQmY69.png
成本侧:
● 服务器一年 4000 元；
● DeepSeek Flash 累计费用接近 2000 元，近期约 100 元/天；
● 股票数据相关 API 累计约 2000 元。
想法
如果看成本和收入，项目目前没有跑通：收入没有覆盖成本，近期模型费用推算每个月至少要 3000 ，但每个月收入都达不到。
但是另一方面，项目并不是完全没有反馈：已有 384 位注册用户，出现了真实付费，也积累了约 4.1 万条事件及后验数据。
我感觉目前还是运营推广的不太够？尝试过在很多股票社区推广，效果都不好，统计了一下来源网址，Twitter/X 和 V2EX 的流量是最多的
我目前的动作是停止了功能的更新，开始做用户的增长，但是这块确实不太擅长，想听听大家的建议，下一步应该怎么做？
项目地址：新闻雷达
楼主本身是一名程序，Vibe Coding 流行后，我一直觉得，开发的技术门槛会越来越低，每个程序员或许都应该做一个自己的独立项目，放到市场上试一次水。
于是从今年 3 月开始，用业余时间做了一个 A 股新闻事件分析工具“新闻雷达”。
四个月以后，我最大的感受是：技术反而是最容易解决的部分，真正困难的是运营、推广和收费。
做了一个复盘。
项目做了什么
我平时会关注财经新闻。新闻本身很多，费时间的是判断它影响哪些行业和公司，这种关联是否有真实业务依据，以及类似事件过去发生后市场如何表现。
新闻雷达会抓取新闻、过滤噪音，通过 AI 和本地股票及公告数据分析相关公司，再记录事件后的市场表现。3 月 24 日开始开发，5 月 4 日上线第一版。在 V2EX 发了帖子： https://www.v2ex.com/t/1210161
上线后我又不断增加历史事件、自选股、概念、投研和会员等功能。工程越做越完整，功能越来越多。现在回头看，我可能是犯了一个错误：用持续开发代替产品验证。
四个月数据
● 注册用户 384 人；
● 当前会员用户 29 人（含赠送）
● 累计会员收入 1600 元；
● 流量最近日天约 1000 访客
● 最近 30 天流量如图
https://i.imgur.com/cmQmY69.png
成本侧:
● 服务器一年 4000 元；
● DeepSeek Flash 累计费用接近 2000 元，近期约 100 元/天；
● 股票数据相关 API 累计约 2000 元。
想法
如果看成本和收入，项目目前没有跑通：收入没有覆盖成本，近期模型费用推算每个月至少要 3000 ，但每个月收入都达不到。
但是另一方面，项目并不是完全没有反馈：已有 384 位注册用户，出现了真实付费，也积累了约 4.1 万条事件及后验数据。
我感觉目前还是运营推广的不太够？尝试过在很多股票社区推广，效果都不好，统计了一下来源网址，Twitter/X 和 V2EX 的流量是最多的
我目前的动作是停止了功能的更新，开始做用户的增长，但是这块确实不太擅长，想听听大家的建议，下一步应该怎么做？
项目地址：新闻雷达
[分享创造] 假到位
写了一篇关于锁的东西。不长。
关于弹子锁里一种叫假到位的状态——弹子卡在差一点的位置，手上的感觉跟到位了一模一样，但锁没开。
从锁写到了人。从人写回了锁。
https://xiaoni.liahuas.top/false-set/
写了一篇关于锁的东西。不长。
关于弹子锁里一种叫假到位的状态——弹子卡在差一点的位置，手上的感觉跟到位了一模一样，但锁没开。
从锁写到了人。从人写回了锁。
https://xiaoni.liahuas.top/false-set/
[NAS] 关于更换操作系统后 TimeMachine 无法备份的解法
最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示"备份失败"。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。
实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。
症状
● Time Machine 永远备份失败，系统通知只有一句"备份失败"，提示的是这个：
●
● 在 Finder / 终端里用
● NAS 的 Samba 日志里看不到任何来自 Mac 的认证尝试——失败发生在 Mac 本地，认证包根本没发出去。
环境
● macOS 15.7 (Sequoia)，备份目标为 SMB 共享（本文案例：绿联硬件刷飞牛 OS 后的 Samba ，开启了
● 路由器做了 IP-MAC 绑定，NAS 重装系统后 IP 不变。
排查过程（可直接复用的诊断路径）
1. 拿到真正的报错
注意：很多人的 shell 里
典型输出：
错误 29 只是外层包装，真身是 NetAuth 的 **EAUTH (80)**。
2. 排除 NAS 端
用内嵌密码手动挂载：
能挂上 = 网络/SMB/凭据/共享全通。再去 NAS 上看 Samba 日志（
3. 盯住真正的认证代理 NetAuthSysAgent
Time Machine 以 root 运行，认证走
关键日志：
4. 找到"已知服务器"名单
用
会发现它读取：
打开一看（需要 sudo ）：
只有旧系统的主机名，没有重装后的新主机名，也没有 IP 。
根因
macOS 的 NetAuth 框架维护一份"已知服务器"标记（ ServerMarkers ）。对不在名单里的服务器，
NAS 重装系统后，尽管 IP 没变，但 Bonjour 主机名、Samba 服务标识全变了——在 Mac 眼里这是一台全新的、从未信任过的服务器。而 GUI （系统设置/Finder ）添加凭据的流程不知为何没有把新主机名写进标记（这在重装 NAS 的场景下似乎不会自动发生），于是形成死锁：
● 钥匙串里有正确密码 ✓
● 服务器一切正常 ✓
● NetAuth："这服务器我不认识，不试。" ✗
修复
第一步：把新服务器加进已知名单（键名必须全小写！）
三个坑：
1. 键名全小写——主机名比较是小写的，
2. **用 PlistBuddy 而不是
3. 三个名字（ IP 、Bonjour 服务名、mDNS 主机名）都加上，因为 Time Machine 目的地 URL 可能用其中任意一种。可用
第二步：重新添加备份目的地
系统设置 → 通用 → 时间机器 → 选择备份磁盘 → 选中 NAS 上的 TimeMachine 共享 → 输入账号密码。
然后触发备份验证：
看到
顺手清理（可选）
● 旧 NAS 的标记（本例中的
● 钥匙串里指向旧 NAS 身份的残留条目：钥匙串访问.app 搜 NAS 名字/IP 删掉即可。
● 如果之前用命令行折腾过
深层定性：这是 macOS 的锅，而且能从机制反推出一个惊人结论
三层状态，各自为政
macOS 实际维护三套互相同步不良的认证状态：
最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示"备份失败"。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。
实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。
症状
● Time Machine 永远备份失败，系统通知只有一句"备份失败"，提示的是这个：
●
tmutil destinationinfo 正常，defaults read /Library/Preferences/com.apple.TimeMachine 里 RESULT = 29。● 在 Finder / 终端里用
mount_smbfs //user:password@nas/Share 挂载备份共享完全正常——网络、账号、密码、共享配置、NAS 端 Samba 全部无辜。● NAS 的 Samba 日志里看不到任何来自 Mac 的认证尝试——失败发生在 Mac 本地，认证包根本没发出去。
环境
● macOS 15.7 (Sequoia)，备份目标为 SMB 共享（本文案例：绿联硬件刷飞牛 OS 后的 Samba ，开启了
fruit:time machine）。● 路由器做了 IP-MAC 绑定，NAS 重装系统后 IP 不变。
排查过程（可直接复用的诊断路径）
1. 拿到真正的报错
注意：很多人的 shell 里
log 被别名/函数占用，会直接静默失败。统一日志工具请写全路径：tmutil startbackup # 手动触发一次备份
/usr/bin/log show --last 5m --info --debug --style compact \
--predicate 'process == "backupd"' | grep -iE 'error|fail|mount'
典型输出：
[Mounting] Attempting to mount 'smb://app@pdnas._smb._tcp.local./TimeMachine'
[Mounting] NAConnectToServerSync failed with error: 80 (Authentication error)
[BackupDispatching] Backup failed: BACKUP_FAILED_AUTHENTICATION_ERROR (29)
错误 29 只是外层包装，真身是 NetAuth 的 **EAUTH (80)**。
2. 排除 NAS 端
用内嵌密码手动挂载：
mkdir /tmp/tm && mount_smbfs '//user:password@192.168.x.x/TimeMachine' /tmp/tm
能挂上 = 网络/SMB/凭据/共享全通。再去 NAS 上看 Samba 日志（
/var/log/samba/log.*），失败时间点一条记录都没有 → 客户端本地失败。3. 盯住真正的认证代理 NetAuthSysAgent
Time Machine 以 root 运行，认证走
NetAuthSysAgent：/usr/bin/log show --last 2m --info --debug --style compact \
--predicate 'process == "NetAuthSysAgent"'
关键日志：
[Keychain] isKnownServer 0
[MechTypes] CredentialsStage set to 5
[MechTypes] There are no user credentials to add to the MechType session
[NetFS] OpenSession failed 80
isKnownServer 0 —— NetAuth 认为这台服务器"不认识"，直接跳到第 5 阶段，连钥匙串都不查就放弃了。4. 找到"已知服务器"名单
用
fs_usage 跟踪 agent 读的文件：sudo fs_usage -w -f filesys NetAuthSysAgent
# 另一个终端触发 tmutil startbackup
会发现它读取：
/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist
打开一看（需要 sudo ）：
"ugreen-cd13.local" => 1
"ugreen-cd13-2.local" => 1
_migrationVersion => 2
只有旧系统的主机名，没有重装后的新主机名，也没有 IP 。
根因
macOS 的 NetAuth 框架维护一份"已知服务器"标记（ ServerMarkers ）。对不在名单里的服务器，
NetAuthSysAgent 在无交互权限的系统上下文中（ Time Machine 正是如此）直接判定 isKnownServer = 0，跳过钥匙串查询、不发出任何认证包，向上层返回 EAUTH 。NAS 重装系统后，尽管 IP 没变，但 Bonjour 主机名、Samba 服务标识全变了——在 Mac 眼里这是一台全新的、从未信任过的服务器。而 GUI （系统设置/Finder ）添加凭据的流程不知为何没有把新主机名写进标记（这在重装 NAS 的场景下似乎不会自动发生），于是形成死锁：
● 钥匙串里有正确密码 ✓
● 服务器一切正常 ✓
● NetAuth："这服务器我不认识，不试。" ✗
修复
第一步：把新服务器加进已知名单（键名必须全小写！）
PL="/private/var/root/Library/Group Containers/group.com.apple.NetworkAuthorization.ServerMarkers/serverMarkers.plist"
sudo cp "$PL" "$PL.bak" # 先备份
sudo /usr/libexec/PlistBuddy -c "Add :192.168.x.x integer 1" "$PL"
sudo /usr/libexec/PlistBuddy -c "Add :your-nas._smb._tcp.local. integer 1" "$PL"
sudo /usr/libexec/PlistBuddy -c "Add :your-nas.local integer 1" "$PL"
三个坑：
1. 键名全小写——主机名比较是小写的，
PDNAS.local 写了等于没写（对照名单里原有的 ugreen 条目，全是小写）。2. **用 PlistBuddy 而不是
plutil -insert**——plutil 把键名里的 . 当作嵌套路径分隔符，含点的主机名会静默失败； PlistBuddy 的路径分隔符是 :，点号是安全的。3. 三个名字（ IP 、Bonjour 服务名、mDNS 主机名）都加上，因为 Time Machine 目的地 URL 可能用其中任意一种。可用
tmutil destinationinfo 看你的 URL 用的是哪种。第二步：重新添加备份目的地
系统设置 → 通用 → 时间机器 → 选择备份磁盘 → 选中 NAS 上的 TimeMachine 共享 → 输入账号密码。
然后触发备份验证：
tmutil startbackup && sleep 15 && tmutil status
看到
Running = 1、BackupPhase = Copying 即修复完成。此时再回头抓 NetAuthSysAgent 日志，会看到流程变成：[Keychain] isKnownServer 1
[MechTypes] Next CredentialsStage set to 4
[MechTypes] MechTypes were acquired for the MechType session using credentials
顺手清理（可选）
● 旧 NAS 的标记（本例中的
ugreen-cd13*）：留着无害，想删可以用 PlistBuddy -c "Delete :ugreen-cd13.local" "$PL"。● 钥匙串里指向旧 NAS 身份的残留条目：钥匙串访问.app 搜 NAS 名字/IP 删掉即可。
● 如果之前用命令行折腾过
tmutil setdestination -ap，注意它写的是旧式 /Library/Keychains/System.keychain，而 macOS 15 的 NetAuthSysAgent 查的是新式 system-keychain-2.db——命令行加的条目它可能根本看不到，以 GUI 添加的为准。深层定性：这是 macOS 的锅，而且能从机制反推出一个惊人结论
三层状态，各自为政
macOS 实际维护三套互相同步不良的认证状态：
V2EX
[NAS] 关于更换操作系统后 TimeMachine 无法备份的解法 最近给 NAS 重装了系统，把绿联刷飞牛 OS ，macOS Time Machine 突然无法备份，提示"备份失败"。密码绝对正确、手动挂载完全正常，但 Time Machine 就是连不上。 实际上，飞牛社区某个不起眼的楼中楼回复给出了下面 AI 耗时 2 个小时自行探索修复的结论，只不过写得不太清楚。 症状 ● Time Machine 永远备份失败，系统通知只有一句"备份失败"，提示的是这个： ● tmutil destinationinfo…
在系统设置里输入密码时，GUI 真实连接了 NAS 并验证成功（ NAS 日志有访问记录）、也写入了钥匙串——但没有写信任标记。后端 daemon 只认标记。UI 的"成功"和后端的"信任"是两套语义，这是字面意义上的脱钩。而整个失败链条最终坍缩成一句"备份失败 / 错误 29"，用户能做的所有常规操作（重输密码、删了重加、换 IP 换域名）都够不到真正出问题的那层状态。
时间线复盘：两个诱因叠加
●
● 刷入新 NAS 系统（飞牛 OS ）后，主机名/Samba 身份变更，但 IP 因路由绑定没变——新身份从未进入信任名单（埋雷）；
● 备份在新系统上正常跑了一段时间，直到一次 macOS 更新（机器重启时间吻合）后突然全挂——很可能是该更新引入了 marker 迁移（
反推结论："第一台服务器定律"
把上面的事实拼起来，可以得出一个可检验的强推论：
1. 首次配置 TM 时，某个 onboarding 流程在验证凭据成功后会写入
2. 此后这个文件再无任何面向用户的流程会更新它（实测：设置 UI 里重输密码、删除磁盘再添加、命令行
3. 于是第二台服务器（换 NAS 、NAS 重刷系统、改主机名都会让 Mac 认为是"新服务器"）永远卡在
4. 唯一出路就是手动编辑那个没有文档、不在任何官方排障流程里的 plist 。
限定条件：本结论基于 macOS 15.7 上一次可完整复现的案例 + 完全自洽的机制解释，样本量为 1 。如果你手上有"换 NAS 后第二台 TM 服务器直接从设置里配成功"的反例，欢迎打脸——那至少说明 Apple 在新版本里修了。
实操推论：标记是按主机名字符串匹配的。所以换新 NAS / 重刷系统时，把新主机名（ Bonjour 名）设置成和旧的完全一致，老标记直接命中，大概率可以无感迁移、免疫此坑。
Apple 应该怎么做（三条任选其一即可治本）
1. TM 设置 UI 验证凭据成功时同步写入 serverMarkers ；
2. NetAuthSysAgent 把"钥匙串中存在该服务器的有效凭据"视为 known 的兜底条件；
3. 至少把 "untrusted/unknown server" 作为独立错误暴露给用户，而不是笼统的"备份失败 / 错误 29"。
三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。
诊断工具箱（收藏备用）
注意：
总结
一句话：NAS 重装/更换后，把新主机名（小写）和 IP 加进
时间线复盘：两个诱因叠加
●
serverMarkers.plist 的文件修改时间停留在首次配置旧 NAS 的那天，此后再未被任何流程更新；● 刷入新 NAS 系统（飞牛 OS ）后，主机名/Samba 身份变更，但 IP 因路由绑定没变——新身份从未进入信任名单（埋雷）；
● 备份在新系统上正常跑了一段时间，直到一次 macOS 更新（机器重启时间吻合）后突然全挂——很可能是该更新引入了 marker 迁移（
_migrationVersion = 2）或收紧了 isKnownServer 校验（引爆）。反推结论："第一台服务器定律"
把上面的事实拼起来，可以得出一个可检验的强推论：
在一台 macOS 设备上，只有它这辈子连接的第一台 Time Machine 服务器，能够从系统设置里顺利完成备份。推理过程：
1. 首次配置 TM 时，某个 onboarding 流程在验证凭据成功后会写入
serverMarkers.plist——所以第一台服务器永远顺利；2. 此后这个文件再无任何面向用户的流程会更新它（实测：设置 UI 里重输密码、删除磁盘再添加、命令行
tmutil setdestination，全部不会写标记）；3. 于是第二台服务器（换 NAS 、NAS 重刷系统、改主机名都会让 Mac 认为是"新服务器"）永远卡在
isKnownServer = 0——钥匙串里密码再正确也不会被使用；4. 唯一出路就是手动编辑那个没有文档、不在任何官方排障流程里的 plist 。
限定条件：本结论基于 macOS 15.7 上一次可完整复现的案例 + 完全自洽的机制解释，样本量为 1 。如果你手上有"换 NAS 后第二台 TM 服务器直接从设置里配成功"的反例，欢迎打脸——那至少说明 Apple 在新版本里修了。
实操推论：标记是按主机名字符串匹配的。所以换新 NAS / 重刷系统时，把新主机名（ Bonjour 名）设置成和旧的完全一致，老标记直接命中，大概率可以无感迁移、免疫此坑。
Apple 应该怎么做（三条任选其一即可治本）
1. TM 设置 UI 验证凭据成功时同步写入 serverMarkers ；
2. NetAuthSysAgent 把"钥匙串中存在该服务器的有效凭据"视为 known 的兜底条件；
3. 至少把 "untrusted/unknown server" 作为独立错误暴露给用户，而不是笼统的"备份失败 / 错误 29"。
三条一条都没做，于是唯一的解法落在用户手动编辑内部状态文件上。
诊断工具箱（收藏备用）
# 看 TM 配置和最近一次结果码
tmutil destinationinfo
defaults read /Library/Preferences/com.apple.TimeMachine
# 抓 backupd 报错（/usr/bin/log 全路径，避开 shell 别名坑）
/usr/bin/log show --last 10m --info --predicate 'process == "backupd"'
# 抓 NetAuth 认证流程
/usr/bin/log show --last 2m --info --debug --predicate 'process == "NetAuthSysAgent"'
# 跟踪 NetAuthSysAgent 读了哪些状态文件
sudo fs_usage -w -f filesys NetAuthSysAgent
# 验证"密码本身没问题"（内嵌密码挂载）
mkdir /tmp/t && mount_smbfs '//user:pass@nas-ip/Share' /tmp/t
注意：
mount_smbfs 不带密码在非交互终端下不会查钥匙串，会以空凭据被服务器拒绝（ exit 77 ），不要用它来判断钥匙串条目是否有效——这是排查时最容易踩的假线索。总结
一句话：NAS 重装/更换后，把新主机名（小写）和 IP 加进
serverMarkers.plist，再走一遍系统设置添加备份磁盘，即可恢复。 更深层次上，这是 macOS 设置 UI 与后端认证体系脱钩的 bug——一台 Mac 这辈子只有第一台 TM 服务器能从设置里配成功，换服务器身份后必踩此坑。[分享创造] 做了个支持多级跳板的 SSH 会话中间件，让 AI Agent 能操作堡垒机后面的服务器
为什么做这个
最近工作里，写代码、改文档、点网页这类事，基本已经可以交给 AI Agent 了。但一碰到服务器操作就卡住：
公司一般都有跳板机 / 堡垒机，Agent 没法直接连后面的机器，自动化就断了。
更头疼的是排查问题：经常得先登录服务器，把线上日志拷到本地，丢给 Agent 分析，再拿着它给的步骤回到线上执行。来回倒腾，特别耗时间。
所以做了 Shellink：把「多级跳板之后的那台机器」收成一个稳定会话，让 AI Agent （和人）能直接在上面执行命令、传文件、看历史。
仓库： https://github.com/jie123108/Shellink
中文文档： https://github.com/jie123108/Shellink/blob/main/README.zh-CN.md
Web UI 实时会话（经跳板到达目标机）：
----------------------
Shellink 是什么
一句话：面向 AI Agent 和人类的会话中间件（ session middleware ）。
本地跑一个 daemon ，持有 SSH / 本地 PTY 会话；外面用统一的 CLI （也有 TUI 、Web UI 、HTTP/WebSocket ）去操作这些会话。
不是又一个 SSH GUI ，重点是：
● 会话状态可查询（ CONNECTING / WAITING_INPUT / IDLE …），方便 Agent 决策下一步
● CLI 有稳定的
● 需要人插手时可以切到 MANUAL 模式（比如输入 OTP ）
会话 Dashboard （活跃会话列表）：
----------------------
主要能力
1. 多级跳板 / 复杂登录
很多环境不是一次
说明一下边界：Shellink 本身不负责自动登录。多级跳转、堡垒机菜单、OTP 等交互认证，建议用
2. 跨跳板文件传输
上传/下载走已有的 PTY ，不额外要求 SFTP 。复杂跳板链路上也能把日志拉下来、把脚本推上去——正好对应「拷日志到本地再问 Agent 」那个痛点。
3. 远程编辑
4. 审计与人机协同
会话输入输出可留历史，方便回看 Agent 干了啥；敏感步骤可以人工接管。
5. 给 Agent 准备的 skill
仓库里有
安装二进制（ macOS / Linux ）：
或让 AI 助手直接按文档装：
CLI/TUI 会话视图：
Web UI 默认在本地：
----------------------
安全提醒（重要）
●
● 让 Agent 直连生产有真实风险：建议只读/排查类操作，或先指向非生产环境
----------------------
求试用 & 反馈
欢迎有跳板机 / 堡垒机场景的同学试试。登录脚本本身用 expect 就行；我更想听的是登录之后这块好不好用：
1. 会话与操作：状态是否清晰、命令执行是否稳、跨跳板传文件/远程编辑有没有坑
2. 和 Agent 一起用：接 Cursor / Claude Code 等时，CLI/
3. 人机协同：OTP 等需要人插手时，MANUAL 模式、审计历史是否够用
有问题直接回帖或去 GitHub 提 issue 都行，谢谢。
为什么做这个
最近工作里，写代码、改文档、点网页这类事，基本已经可以交给 AI Agent 了。但一碰到服务器操作就卡住：
公司一般都有跳板机 / 堡垒机，Agent 没法直接连后面的机器，自动化就断了。
更头疼的是排查问题：经常得先登录服务器，把线上日志拷到本地，丢给 Agent 分析，再拿着它给的步骤回到线上执行。来回倒腾，特别耗时间。
所以做了 Shellink：把「多级跳板之后的那台机器」收成一个稳定会话，让 AI Agent （和人）能直接在上面执行命令、传文件、看历史。
仓库： https://github.com/jie123108/Shellink
中文文档： https://github.com/jie123108/Shellink/blob/main/README.zh-CN.md
Web UI 实时会话（经跳板到达目标机）：
----------------------
Shellink 是什么
一句话：面向 AI Agent 和人类的会话中间件（ session middleware ）。
本地跑一个 daemon ，持有 SSH / 本地 PTY 会话；外面用统一的 CLI （也有 TUI 、Web UI 、HTTP/WebSocket ）去操作这些会话。
不是又一个 SSH GUI ，重点是：
● 会话状态可查询（ CONNECTING / WAITING_INPUT / IDLE …），方便 Agent 决策下一步
● CLI 有稳定的
--json 输出，适合脚本和 Agent 调用● 需要人插手时可以切到 MANUAL 模式（比如输入 OTP ）
会话 Dashboard （活跃会话列表）：
----------------------
主要能力
1. 多级跳板 / 复杂登录
很多环境不是一次
ssh user@host 就结束，而是菜单、OTP 、多跳。说明一下边界：Shellink 本身不负责自动登录。多级跳转、堡垒机菜单、OTP 等交互认证，建议用
command 类型的 profile 挂 expect 脚本处理；简单场景也可以用 sshpass（仅密码）或 ssh 的 ProxyJump / ProxyCommand。Shellink 负责把登录完成后的会话管起来（执行命令、传文件、状态、审计）。2. 跨跳板文件传输
上传/下载走已有的 PTY ，不额外要求 SFTP 。复杂跳板链路上也能把日志拉下来、把脚本推上去——正好对应「拷日志到本地再问 Agent 」那个痛点。
3. 远程编辑
shellink session edit 做精确替换，适合改配置一类操作。4. 审计与人机协同
会话输入输出可留历史，方便回看 Agent 干了啥；敏感步骤可以人工接管。
5. 给 Agent 准备的 skill
仓库里有
shellink-cli skill ，Agent 按 CLI 接口操作即可，不必自己实现 SSH/跳板逻辑。安装二进制（ macOS / Linux ）：
curl -fsSL https://raw.githubusercontent.com/jie123108/Shellink/main/install.sh -o /tmp/shellink-install.sh
cat /tmp/shellink-install.sh
sh /tmp/shellink-install.sh
或让 AI 助手直接按文档装：
请帮我安装 Shellink 及其 skills ，参考这份文档： https://raw.githubusercontent.com/jie123108/Shellink/main/AGENTS_INSTALL.md装好后：
shellink cli # TUI ，会按需拉起 daemon
shellink agent-doc # 给 Agent 看的接口说明
CLI/TUI 会话视图：
Web UI 默认在本地：
http://127.0.0.1:7070/shellink/ui/----------------------
安全提醒（重要）
●
command 类型的 profile 会以 daemon 进程用户身份执行你配置的命令，请只在受信任环境跑，并保护好 SHELLINK_TOKEN● 让 Agent 直连生产有真实风险：建议只读/排查类操作，或先指向非生产环境
----------------------
求试用 & 反馈
欢迎有跳板机 / 堡垒机场景的同学试试。登录脚本本身用 expect 就行；我更想听的是登录之后这块好不好用：
1. 会话与操作：状态是否清晰、命令执行是否稳、跨跳板传文件/远程编辑有没有坑
2. 和 Agent 一起用：接 Cursor / Claude Code 等时，CLI/
--json/skill 哪里别扭、缺什么3. 人机协同：OTP 等需要人插手时，MANUAL 模式、审计历史是否够用
有问题直接回帖或去 GitHub 提 issue 都行，谢谢。
[问与答] 3d 打印进阶玩法咨询
目前 p2s, 网站上的模型也都打了遍，大概打了几百个各种的生活用品； 现在有了新的需求，想自己扫描 3d 模型，打印； 请问有啥工具可以用来 3d 扫描的，苹果手机的 lidar 似乎精度不够？
目前 p2s, 网站上的模型也都打了遍，大概打了几百个各种的生活用品； 现在有了新的需求，想自己扫描 3d 模型，打印； 请问有啥工具可以用来 3d 扫描的，苹果手机的 lidar 似乎精度不够？
[分享创造] 做了一个文档解析与记忆工具，专门辅助给传统行业做 AI 落地的老哥
现在 AI+的工作还挺常见的，就像大佬们说的，“所有行业的产品可能都会用 AI 重新做一遍”。最常见的就是各种 agent ，说要用 AI 赋能传统行业啥的，代替人类专家去处理海量的复杂资料、进行深度分析并做出决策。
举个例子，金融行业的“智能审计与尽调 Agent”。
过去，银行或投资机构想要给一家企业贷款或投资，需要人类审计师去读几十份、每份几百页的招股书和财务报表。现在虽然有了 AI ，但把文件一股脑全丢给它是不现实的，且不说烧 token 的问题，这些文档里有无数的跨行、跨列单元格表格，普通工具一拉，表格数据全串行了。如果 AI 把“第一季度利润”和“第二季度支出”的信息碎在一块，那得出的财务分析就完蛋了。
所以，现在要真想开发出一个能干活，还确保正确率的 agent ，就需要一个专业的、AI-native 的解析工具，把复杂的表结构和章节层级完整还原出来。我做的工具 Knowhere 就是干这个的： https://knowhereto.ai/?utm_source=v2ex
它能把复杂量大的文件，解析成按章节、按次序分类的 JSON ，尤其是令 AI 头大的 PDF 、PPT 、图片、表格等格式文件。其次它会把解析好的文档进行结构化，重建文档的标题树，从一级标题到二级、三级，每一块文本都会被挂载到对应的章节路径上。表格和图片也不是单独抽出来当独立附件，而是和内联的上下文文本牢牢绑定，确保 AI 能看到“这张表格是属于哪一段话”。
最后它还会构建一个包含章节树、文本块、摘要、图像描述以及跨文档链接的轻量级记忆图谱，方便 AI 检索和查找。
装了这个插件之后，agent 的表现会比使用原始文档的时候“正常”很多，我们亲测准确度是有提升 25%以上。
之后再给审计 Agent 分配财务分析任务的时候，它就会自己调用 Knowhere 进行对账了，如果它发现某些数据对不上，还能顺着 Knowhere 提供的记忆图谱返回去重新查验证据，确保交出来的审计报告，每个数据都是可追溯、可查验的。
当然，不只是做金融行业的 agent ，像法律、医疗、企业内网等历史问题比较多，资料比较复杂的场景的 AI 应用，都可以用得上。无论历史文档有多么稀奇古怪、排版脏乱差，Knowhere 都能帮 AI 解析得井井有条，在节省 token 的同时，帮 AI 把活干好。
如果有在做 agent 开发的老哥，欢迎使用，我们现在已经开源了，大家多多评论反馈哈，我会及时改进的： https://github.com/Ontos-AI/knowhere
现在 AI+的工作还挺常见的，就像大佬们说的，“所有行业的产品可能都会用 AI 重新做一遍”。最常见的就是各种 agent ，说要用 AI 赋能传统行业啥的，代替人类专家去处理海量的复杂资料、进行深度分析并做出决策。
举个例子，金融行业的“智能审计与尽调 Agent”。
过去，银行或投资机构想要给一家企业贷款或投资，需要人类审计师去读几十份、每份几百页的招股书和财务报表。现在虽然有了 AI ，但把文件一股脑全丢给它是不现实的，且不说烧 token 的问题，这些文档里有无数的跨行、跨列单元格表格，普通工具一拉，表格数据全串行了。如果 AI 把“第一季度利润”和“第二季度支出”的信息碎在一块，那得出的财务分析就完蛋了。
所以，现在要真想开发出一个能干活，还确保正确率的 agent ，就需要一个专业的、AI-native 的解析工具，把复杂的表结构和章节层级完整还原出来。我做的工具 Knowhere 就是干这个的： https://knowhereto.ai/?utm_source=v2ex
它能把复杂量大的文件，解析成按章节、按次序分类的 JSON ，尤其是令 AI 头大的 PDF 、PPT 、图片、表格等格式文件。其次它会把解析好的文档进行结构化，重建文档的标题树，从一级标题到二级、三级，每一块文本都会被挂载到对应的章节路径上。表格和图片也不是单独抽出来当独立附件，而是和内联的上下文文本牢牢绑定，确保 AI 能看到“这张表格是属于哪一段话”。
最后它还会构建一个包含章节树、文本块、摘要、图像描述以及跨文档链接的轻量级记忆图谱，方便 AI 检索和查找。
装了这个插件之后，agent 的表现会比使用原始文档的时候“正常”很多，我们亲测准确度是有提升 25%以上。
之后再给审计 Agent 分配财务分析任务的时候，它就会自己调用 Knowhere 进行对账了，如果它发现某些数据对不上，还能顺着 Knowhere 提供的记忆图谱返回去重新查验证据，确保交出来的审计报告，每个数据都是可追溯、可查验的。
当然，不只是做金融行业的 agent ，像法律、医疗、企业内网等历史问题比较多，资料比较复杂的场景的 AI 应用，都可以用得上。无论历史文档有多么稀奇古怪、排版脏乱差，Knowhere 都能帮 AI 解析得井井有条，在节省 token 的同时，帮 AI 把活干好。
如果有在做 agent 开发的老哥，欢迎使用，我们现在已经开源了，大家多多评论反馈哈，我会及时改进的： https://github.com/Ontos-AI/knowhere
[程序员] 为什么“节省 90% Token”不等于 Coding Agent 总成本降低 90%
最近把几个“Token 节省”插件放到完整仓库任务里做了一个小型配对实验，结论和常见宣传口径差异很大。
任务不是单轮代码补全，而是把 Rust eza 仓库重写成行为兼容的 Python 实现，并通过 52 项 harness 检查。模型、推理档位和 Codex CLI 版本保持一致，每组目前只有 2 次运行：
无插件：78.85% 通过率，平均 666 万 Token ，约 5.28 美元，62.5 轮
Ponytail：通过率 80.77%，Token -7.56%，成本 -8.87%，但耗时 +13.51%
RTK：通过率 76.92%，Token +13.20%，成本 +7.18%，轮次 +44%
更值得注意的是组内波动：无插件两次运行的成本极差/均值是 43.25%，Ponytail 是 51.69%，RTK 是 30.78%。所以 n=2 不能证明插件有因果效果；所谓 8.87% 节省本身还小于自然运行波动。
另一个 140 次 Codex 运行的数据里，缓存输入占总 Token 的 96.46%、总成本的 63.91%；模型输出只占 Token 的 0.38%。因此压缩某段输出 90%，并不能直接外推成完整任务成本降低 90%。RTK 可识别的 shell 返回内容只占全部任务 Token 的 0.1618%，即使完美压缩 90%，直接成本上限仍不到 1%。
我觉得更合理的基准单位应该是“每个成功完成任务的总成本”，同时至少报告重复运行方差、轮次、耗时和最终验证结果，而不是只报局部压缩率。
完整方法、逐次数据和限制：
https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea
https://github.com/Tura-AI/tura
披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。
最近把几个“Token 节省”插件放到完整仓库任务里做了一个小型配对实验，结论和常见宣传口径差异很大。
任务不是单轮代码补全，而是把 Rust eza 仓库重写成行为兼容的 Python 实现，并通过 52 项 harness 检查。模型、推理档位和 Codex CLI 版本保持一致，每组目前只有 2 次运行：
无插件：78.85% 通过率，平均 666 万 Token ，约 5.28 美元，62.5 轮
Ponytail：通过率 80.77%，Token -7.56%，成本 -8.87%，但耗时 +13.51%
RTK：通过率 76.92%，Token +13.20%，成本 +7.18%，轮次 +44%
更值得注意的是组内波动：无插件两次运行的成本极差/均值是 43.25%，Ponytail 是 51.69%，RTK 是 30.78%。所以 n=2 不能证明插件有因果效果；所谓 8.87% 节省本身还小于自然运行波动。
另一个 140 次 Codex 运行的数据里，缓存输入占总 Token 的 96.46%、总成本的 63.91%；模型输出只占 Token 的 0.38%。因此压缩某段输出 90%，并不能直接外推成完整任务成本降低 90%。RTK 可识别的 shell 返回内容只占全部任务 Token 的 0.1618%，即使完美压缩 90%，直接成本上限仍不到 1%。
我觉得更合理的基准单位应该是“每个成功完成任务的总成本”，同时至少报告重复运行方差、轮次、耗时和最终验证结果，而不是只报局部压缩率。
完整方法、逐次数据和限制：
https://turaai.net/blog#token-saving-plugins-are-mostly-stupid-idea
https://github.com/Tura-AI/tura
披露：我是 Tura 的维护者，也是这篇分析的作者。这次发的是 benchmark/方法讨论，不是产品发布。也想听听大家认为这类工具最合理的评估分母应该是什么。
[Claude] 一年多没用过 Claude，当初用的时候仅用过 mac 客户端和网页，号被封了
上次用还是 DeepSeek R1 刚出的时期，没用过 Claude Code ，账号没付过费
绑的是英国的 giffgaff 手机号
严重怀疑这家公司会在网络上搜索你的用户名前缀进行身份识别（也可以说是盒），或者对同一个节点的注册账号采取连坐机制，或者是跟谷歌有信息共享（港区谷歌账号）
只是感觉有点搞笑，连发两条消息，搞得像是多稀罕一样
希望能够给大伙分析风控机制提供点信息
上次用还是 DeepSeek R1 刚出的时期，没用过 Claude Code ，账号没付过费
绑的是英国的 giffgaff 手机号
严重怀疑这家公司会在网络上搜索你的用户名前缀进行身份识别（也可以说是盒），或者对同一个节点的注册账号采取连坐机制，或者是跟谷歌有信息共享（港区谷歌账号）
只是感觉有点搞笑，连发两条消息，搞得像是多稀罕一样
希望能够给大伙分析风控机制提供点信息