没啥技巧的。。现在 AI 编程的短板显而易见的。。所以最常用的场景还是局部用 AI 编写，尤其是细节不需要那么多的、比较通用化的地方，让 AI 可以辅助写。其他地方还是老老实实自己手撸吧，再配合一下 tab 补全。

要说一个完整项目让 AI 写，那么这个项目肯定是骗投资人的、非生产级的、规模过小的

为啥又要搞个 n8n 做知识的导入？当时是出于啥原因考虑的？ fastgpt 不能完成吗？

最后的问答模式是什么意思？你的 RAG 应用要嵌入在 OUTLINE 文档页面中使用是吗？

@JustRuning Enio 用下来感觉如何啊？我们也是医疗相关，且也是 Gopher ，也在调研相关 agent 框架

还是产品定位问题

定位为工具站，目标人群其实都是散客，说白了都是公司的一些执行员工可能为了工作所需或者纯玩体验的人。但这部分人群早已被大厂免费的产品割走了。而且对于这部分人，付费意愿与产品功能存在很大关系，你这产品功能如 V 友所说，类似纯套壳，没好好打磨。

但除了工具站还能做什么？需要了解到市场需求。但了解市场需求的渠道对于个人开发者来说太少了，就以我所了解的来说，现在一般都需要与企业自身的产品需求、内部需求来做结合，结合 AI 来为企业提供更大价值。单纯的通用型的工具在 V 站见过太多了，竞争压力不仅大，与大厂来比直接被碾压。

权限常见的两大类做法，一类是在技术层面、资源层面做的，例如 1 楼所说的，对 api 路径、rpc 路径做权限控制，还有一类是在业务层面的，例如 xx 操作只允许 xx 级别的会员用户才能操作。。。不过这两类做法不是相互代替的，可以同时兼有。。具体问问 AI 吧

AI 范围很广啊，只是近几年火起来的是语言模型，token 消耗量作为计费项也只针对语言模型。。以前的机器学习还可能还会用在风控（爬虫检测等）、产品质检等各种应用方向，那些可能会按次数、时间等其他维度作为消耗量的指标。而且针对企业自身独有领域的 AI 应用，更是需要掌握算法的人的

你的问题核心应该是知识检索吧，用户提问，但你不知道去拿哪些数据来喂给大模型？
看你的描述像是围绕个人画像数据方面做的检索，身高、体重、血糖，如果个人的数据量不大、字段不多的话，考虑整体扔给大模型。。。
如果个人数据量比较大，那么就要考虑你的问题了，如何抽取出所需的信息给大模型。。

我目前有两种想法：
1. 将个人画像数据做简单处理，将大量维度数据按小维度扔进向量库，然后根据用户提问做相似性检索取出扔给大模型。
2. 调整应用编排，多次调用大模型，每次调用针对不同关注点做处理。例如首次调用主要是引入意图识别，让大模型根据用户问题帮你识别出可能需要什么 category 下的哪个 key 的个人信息，然后你再去 es 检索。这种缺陷可能会增加响应时间。

这要是发到小某书我还以为是起号的。。。

用 whois 命令查也行吧，不知道限不限制频率，而且你的客户也不多，查询间隔时间长一点，然后存储起来就行

root@localhost:~# whois nmc.cn
Domain Name: nmc.cn
ROID: 20030310s10001s00013947-cn
Domain Status: ok
Registrant: 国家气象中心（中央气象台）
Registrant Contact Email: [email protected]
Sponsoring Registrar: 北京国科云计算技术有限公司（原北京中科三方网络技术有限公司）
Name Server: ns1.sfn.cn
Name Server: ns2.sfn.cn
Registration Time: 2003-03-10 19:14:55
Expiration Time: 2026-12-08 13:45:51
DNSSEC: unsigned

@liuleixxxx 完了你，举报了

You got 6 out of 25 correct!

这玩意儿运营商管的很严。。要看使用场景的。。大多数都是用来做陌拜的。。全是骚扰电话

你这个慢你有没有分析大概是慢在哪些环节？服务器上创建新环境、应用启动初始化慢？还是服务器处理用户请求的复杂逻辑的慢？还是服务器响应后返回到终端用户的网络慢？

另外你这“下载 5M 的 js 文件”，指的是你临时环境中拉取这个 js 到你服务器上？还是用户从你服务器拉这个 js 到他们自己电脑上？

才发现 dromara 社区有那么多熟悉的项目..这是个什么神奇的组织

你这要是发在小某书，我还以为是起号的。。

这玩意儿容易被封吧。。

@lasuar 有个问题想咨询下大佬。。有的 db migration 迁移工具中，提供的都是基于.sql 文件方式去做数据库表结构变更的。这样对于纯 DDL 基本是有效的，但是不知有没有这样的场景，例如在做了 DDL 之后还要做一些数据处理工作，如原有 A 字段可能因早期设计不合理，现在需要新增一个 B 字段，这是 DDL 部分，但是还需要将 A 字段中已有的数据通过脚本提取、处理、转换并更新到 B 字段上。这时数据处理的逻辑就不太好放在.sql 中编写了吧。

我的做法都是引入第三方工具库，然后自己写脚本的，在脚本中调用库的 DDL 方法，然后再写一些额外的数据处理逻辑的。不知大佬这种抛开第三方工具独立维护的方案中，如何处理这样的需求的