@Immortal 没用过 Java 。而且我感觉那套一堆框架、配置堆在一起的东西熟悉起来挺慢了。

Go 的话，一些基础代码要仔细设计接口，实现了扔到公共库。然后业务代码直接交给 AI 写，很多时候还挺快的。

@lujiaxing 我一直没 get 到为啥 java 写业务要比 go 快得多，能介绍一下么

我怎么感觉有了 AI ，go 写啥业务都行。。。

甚至你那竞争对手还过来炫耀，奖金拿了多少……

我看了楼主你的帖子，你老婆遇到的事情不也就是这么一票子事儿么。

你就代入，你的小组和公司其他小组竞争做一个项目，A/B 组，本来你们小组一直内部评价领先的，临门一脚你队友拉了坨大的，最后公司绩效、奖金、甚至晋升都泡汤了。你作何感想

你老婆工作焦虑了吧。人工作焦虑的时候是听不得别人拿到了自己没有的成果的。

我觉得和市场状态也一样。

国外有不少 toB 机会，toC 市场也不像国内 14 亿那么大，没必要在互联网 toC 市场移动端里面打生打死，各有各的活法。大不了做个界面长什么都无所谓的程序呗。国内 toB 根本没啥油水，14 亿市场又辣么大，赢家通吃，所以 UI 还不得卷上天，一个按钮精确到渐变的方向是多少度都要扣半天。

引擎一样没有解决问题。

手机端的屏幕尺寸、触控方式，和平板的，和网页的用鼠标和键盘的，根本不一样。试图写一套代码跑三端，那只能是三端的用户体验都会打折扣。

当然，外网这种用户体验打折扣的 App 我觉得也挺多的，解决的道路就是干脆 App 变简单、元素少一点。但是国内手机端竞争太激烈了，基本都是用户体验要精确到间距到底多大才舒服。

所以国内 App 不可能写一遍、三端（手机、平板、网页）都能用。因为 App 复杂度摆在这里。无论是不是用同一套技术栈，反正都得单独写。

@myqonnt 对，如果让我对整个项目里面 ai 的产出印象最深的，就是那个 TypeScript 版本的通达信语法解析器。因为它真的超预期。

简单来说就是，我用以下流程让它做了个很常用的炒股软件里面，指标公式的解析器。

1. 给一点例子，开始对话总结文法。（当然我学过编译原理，知道怎么描述什么是文法）
2. 构造抽象文法树的类型定义
2. 让它根据我的需求，和 ast 类型定义，写 Tokenizer
3. 写 Tokenizer 单测
4. 根据 Tokenizer 和 ast 类型定义，写 Parser
5. 写 parser 单测
6. 开始写各种算子的实现，比如 MA 。我需要先给几个标准例子，然后 AI 越写越会写。

其实我最近也有感觉，我虽然 AI 用的很舒服，但我小弟用起来总是不得劲。

我在想是不是得写个案例教程才能让他们弄明白怎么用 AI 。

@myqonnt 另外我现在集群 ansible 运维脚本也有 AI 参与。不过我这套运维代码的时间比较久，所以 ai 介入不多。不过新的 role 写起来也很丝滑。

@myqonnt 我最近几个月做的项目是 A 股实时行情接入、处理（ go ）；通过 redis 发布到多个 go websocket 前端服务器；前端服务器 1:N 发送给客户端（ ts ）。小程序端 TypeScript 自绘 K 线显示行情和因子。

随着这半年 AI 越来越好用，我大部分代码都有 AI 协助了。特别是那个 K 线自绘，我用 AI 辅助做了 canvas 绘图，和通达信语法解析（编译器）

还有就是 go 方面最近我重写了 websocket 服务器部分（脱离业务的抽象层），单独这个抽象层 每秒转发一个 100B 消息的配置，根据压测，每秒可以支持 5w 客户端 = p90 = 500ms 延迟。

整个项目里面 AI 辅助不多的时 A 股实时行情接入，因为 AI 这方面看过的代码太少了。。。

====

所以这个例子足够复杂吧？

@heeeeeem https://www.cursor.com/cn/dashboard

↑我写文档也是零零碎碎叙述完成，让 AI 帮我写 markdown 。

yysy ，过去 30 天 Cursor 给了我 15w 行代码。不过我的接受率没 100% 那么离谱，看曲线可能只有 60~70%。

https://imgur.com/a/a7ImusL

我是做全栈的，从 TS 到 Go 服务器，到算法（ Python/C++）。

====

我写代码 AI 一般不是无脑，一般是按模块、类一点点写：

1. 叙述我的需求、设计（方案、类型接口定义）之类的，总结成文档
2. 然后让 AI 按照我审阅通过的文档去写。期间我觉得不合理的表述，结合 AI 一起改。
3. 写完让 AI 根据接口和实现
4. 然后写单元测试。接着就是 我审阅单侧、利用 AI 一起调 BUG 。
5. 功能性单元测试完事以后让 AI 帮我写性能测试。然后循环调优性能。
6. 最后将得到的模块和类提交。

等我需要的模块和类都就绪了，我开始写集成方案、写文档、让 AI 写实现，重复上述流程。

最后让 AI 帮我写集成测试脚本（比如让 AI 写 Python 测 Go 服务器）。重复上述流程。

这样就能得到一个能落地的项目。

楼主只要把 go 里面所有


if err := xxx(); err != nil {
return err
}

的地方全换成朴素的 xxx() 就对了。

====

然后当然也不需要

if err := xxx(); err != nil {
log.Formatf("xxx: %v", err)
return err
}

因为 python err 自动带堆栈信息。

====

总结来说就是，只要不是需要对 err 进行恢复的地方，一律就不要做 try ... catch ...

web3 伪需求吧，真正面向消费者的产品几乎没有。

你还不如做做看 iOS 程序、做做小程序，加点 AI 。如果用户觉得好用，就顺势加 ApplePay / WechatPay 。

大模型的上下文是内部的某种 embedding 输出啊。。。

====

这个 embedding 不同模型都不一样，同一个模型的不同版本都不一样。只有精确到某个版本、某个模型，才有可能存储这个真正的上下文。你调用的是通用接口，所以没办法拿到这个真正的上下文，那你只能把 history 再喂给它一遍，让它重新构造出这个内部上下文。

有些模型有 streaming api ，一个合理的实现方法是客户端只存某个 id ，让服务器去存储这个上下文 context 。用 id 去关联 context 。但用户啥时候弃用这个 context ？多长时间过期？这些问题都很麻烦，特别是互联网场景，用户很多的情况下。所以很多 api 不支持 streaming 也很合理嘛。

更何况如果你用着某个上下文，服务器那边模型更新了，瞬间原来的 context embedding 废了，进去就是一堆乱码，用户这不得骂娘，还不如浪费些算力让大模型重新看一遍历史。

====

当然不得不存储 embedding 的场景也是有的，那种就叫做 rag 。这也算是一种折中：让大模型每次都看一遍整个资料库显然计算开销太大了，但是让大模型每次都把所有对话的 embedding 都存下来那存储（和检索）开销又太大了。那么不得已，就采用资料库的 embedding 存起来、对话不存 embedding 。这不是很合理么