新年快乐，愿平安顺遂

要看你对于原生的技术和产品理念的了解有多少。

1 、工作量上的区别。虽然有 AI 辅助，但是一个需求你需要改两遍也是实打实的。

2 、双端使用习惯、系统工具、设计理念的差异如何求同存异。Flutter 更大的优势是极大程度的缓解了双端 UI 、操作逻辑不一致的问题。


当你使用原生时，你就不得不面对相同功能，如何权衡用户使用习惯、厂商最佳实践、以及你的产品设计本身三者的取舍问题。

举个最简单的例子。回退。
你是放弃双方的推荐设计，自己做一个效果一致的回退呢？
还是双端各用符合官方最佳实践的方式做一个回退呢？
还是尊重双端用户的习惯做一个回退呢？

你需要思考的维度就复杂了很多。

有两种情况：
1 、因为非理性原因（情怀等人文因素）坚持小众语言。那这个小众语言就应该消亡。
2 、因为理性原因（性能、环境、设计等），某些垂直领域不可替代。那在统计学 AI 的视角下，这个垂直领域依然是强势的。

btw：一个实际的产品决定使用什么编程语言，编程能力从来不是高权重的考虑因素。

没什么诀窍，无非就是照本宣科：不要硬编码。通过服务获取。

btw ，即便是最高风亮节的 Anthropic ，也只是声明了不会用用户的数据再训练。
也就是说，他只能保证你的代码、数据不会被“自己的新模型”吐露给其他用户。但也仅此而已了。

@ktyang
有没有一种可能，垂直形态的工作分工才是 AI 驱动编程的更好方式？（逻辑复杂度低，上下文长度小，成果人工审核难度不大）

没有上下文边界（比如有详尽文档就不要直接接触代码），半自动没有开发介入，且横向分工的结果就是最后就是压到后面的工序积累的误差爆炸。导致整个项目的正确产出没有任何的统计学优势。

最终结果必然就会不稳定。

1 、扮演角色有什么目的吗？
2 、是否有节省上下文的针对性设计？
3 、期待的交互模式是什么？全自动？半自动？还是开发人员驱动？
4 、“大型项目”有多大？
5 、你用的什么 AI 模型与工具？

你负责“前端”指的是什么前端？
是脚本的操作界面，还是对客系统（下单、支付、结单）？

如果是脚本操作界面，那破坏计算机信息系统的从犯是肯定的。
如果是对客系统，还能辩护一个不知情。

总体上而言，风险收益不对等。

从我的个人经验来讲，目前我工作的重心，已经从程序设计与架构，转向了如何最大化的给 AI 提供合理的上下文。以方便 AI 能够最大可能的生成我需要的代码。

所以我认为，AI 时代，其实对于程序员自身的知识面宽度以及素质要求，其实是更高了。
过去可能需要的更多是孔乙己，现在需要你是鲁迅了。

想了想，还是忍不住想延展一下，细说一下“有价值的东西，不一定被所有人欢迎”这块。

1 、以机器学习为主干，Transformer 为主导的统计学 AI 的可怕之处在于，颠覆了很多垂直领域的既有规则。

因为人类大脑的“缓存”太小，导致人类不擅长统计学，也就让人类无法通过大量的数据来自我修正与找到更优解。
而目前的统计学 AI 恰巧弥补了这一点。统计学 AI 做到哪个领域，哪个领域的玩法就要被颠覆（因为统计学 AI 总是可以找到更优路径）。

颠覆的同时，当前领域的既得利益者就会失去自己赖以生存的护城河。
很大程度上，这就是他们“不欢迎”，乃至“愤怒”的来源。这是人之常情。

2 、现阶段的 AI 无论如何改进（推理也好，引入激励也罢，乃至从零开始的强化学习），最终依然是依赖统计学原理的，这就导致其一定和真实情况有一定的偏差。
也就是所谓的统计学解只是最大概率解，统计学只能最大限度的贴近事实，但不能成为事实。

所以无论如何精进，面对 AI 的输出依然会有信任危机。
这也是“不欢迎”的一个方面。

3 、人是有风险厌恶的，总会依赖既有的成功路线。

首先，反感 AI 内容 ≠ 认为 AI 内容没有价值。
反之亦然，有价值的东西，不一定被所有人欢迎。
当然，原因有很多方面。

然后，我看了楼主转发的链接。貌似抱怨的是 AI 评论了他的工作内容，这让他感到冒犯？
我觉得这个从某些角度上讲也是说得通的。

就像是柯洁被 alpha zero 气哭，认为 alpha zero 在戏耍他一样。

最后，至于说 V 站不允许 AI 回复这块。
这个规定是 GPT3.5 时代的产物，那时候的 AI 幻觉严重，如果允许一个社区出现 AI 内容，基本上这个社区就会迅速失去价值。因为读者会对社区中的内容瞬间失去信任度。

就像是你怎么看待 CSDN 一样。

如果只讨论快手这一次的话，
只能说他们的审核机制环境与真实 C 端不一致，才会出现如此长时间的失控与击穿的情况。

1 、没有人，或者说没有权限够高的人第一时间了解 C 端实际的现象。
2 、C 端（实际客户端）与 B 端（管理平台端）出现不一致时，没有机制能够快速对齐不一致的直播间，导致无法单点修正或封禁。

这就导致最终是直接把整个直播功能下架才解决问题。

垂直细分领域有很多，而且很多都是无感的。

比如天气预报领域。

你作为一个商业产品，入驻一个平台总要有个理由。
要么图流量，要么图功能，要么图便捷。

1 、chat 场景不是所有应用的终极答案。
2 、现在大模型的 api 众多，没必要绑死 OpenAI 。
3 、chatGPT.com 目前也不是统治级的流量入口。

所以厂商没有理由入驻。

1 、可以每次对话都手动强调一遍。防止上下文过长注意力机制忽略前置信息。
2 、控制每次生成的代码规模，阻止过大的上文检索。

本质上就是，大模型的 token 有限，AI coding 产品处于成本考虑，会对你的提示词以及既有代码进行再加工，几个工序下来，信息损失是必然的。

btw：JWT 是一种 token 的实现形式。
和“是否采用双 Token”、“是否遵循 OAuth 2.0”等话题风马牛不相及。

所以，“ jwt 续签为什么要使用双 token”严格来讲是个错误命题。

至于说，为何不每次请求都验证 token 对应的用户合法性，这是基于性能的妥协。

Refresh Token 的存在，就是因为要验证其“续签 token 的合法性和合理性”

你可以把 Refresh Token ，看成是自动重新登录的“用户名+密码”。

当 token 对应的账户被封禁、密码修改等操作时，对应的 Refresh Token 也会同时作废。也就是当前用户的操作权限也就到这个 token 生命周期结束为止。

至于说为什么自动登录不使用用户名+密码作为参数。
因为，用户名+密码是最高级别的用户信息，不应该被保存和频繁录入、传输。

你想给别人差评，先得追着对方问，“大哥，求求你，告诉我你的账号是多少？”
或者说，“大哥，抽烟，麻烦你在这个 app 注册一下，我好给你差评”
你觉得这合理吗？

另外，“用户自己输入别人微信号”这个功能是不成立的。
小程序再非用户手动授权的前提下，只能拿到脱敏的用户唯一凭证。也就是 openID 。
也就是，即便对方是用户，你也很难把微信号、真人、和小程序会员，三者一一对应。

所以你自己就回答了你的疑问。一个对产品只有负面作用的功能，除非产品设计脑子抽了，否则怎么可能做。