@seth19960929 如果 mock 了数据库，建议是把这部分直接和业务逻辑剥离， 还更靠谱些。

巧了， 我手上有个项目有类似的需求， 而且也用上面的方式做了统一处理

然后一年以后我就不再用这玩意儿了。
一个问题是管理员需要操作全量数据， 意味着要维护 selectIgnore
另一个问题是出现了相似的相对含义字段，类比一下就是业务增加了第二个 会计期间，而且要基于这个做逻辑
第三个问题是业务性条件，非显式地填充事实上增加了潜在成本

考虑到 PO 的视野根本看不了这么远， 直接用你的方案 1 算了

所有人都知道这个东西不靠谱， 但是老板就是相信这个


顺便一提， 我现在所在的团队推敏捷， 实际落地的时候一个项目组同时负责两个 sprint 的开发。
再加上潜在的线上问题运维支持的时间，以及随时都会有的 BI 协助要求
就这敏捷总监还说大家估时要准确，不要注水。


不注水就死定了

成年人要明白一个道理， 就是谁承担最大的后果， 就应该承担最大的责任。

你们公司有正经组织工程师培训什么叫优雅吗？
你们公司有愿意为了更优雅的代码付出更多时间成本吗？

没有？又不是你的项目， 老板都不急你急什么

DB-Ranking 前 10 的数据库不能 cover 你的需求吗，非要用这个

RDB 是全量备份，全量备份意味着要比 AOF 更重， 也就意味着你不可能每秒一次 RDB
如果真的要用 Redis 做持久化， 视数据的重要性，可能是要两个都开的

已经绑定了，你再改也没用。建议开一个新账号

黄皮衣能收割为什么不收割
给你开新生产线没涨价已经是很给面子了

@burymme11 解决不了的， 产品设计和业务架构是产品部门的护城河，怎么可能容你置喙

等业务功能一多，很多业务细节完全没人控的住的

比起 code review ， 还不如有意识地推动领域驱动设计， 减少心智成本

@redchamber 这个场景最麻烦的问题在于铁罐子要恰到好处地帮裸猿考虑既有的业务模型的潜在风险点， 事无巨细就不乐意看，有疏漏就要骂娘，感觉也只能靠反复对话来引导裸猿把自觉理所当然不用讲的部分，所谓"知识的诅咒"的部分说出来

能实现多轮交互确实是很赞的，容我期待一个

一个模块能用的功能描述估计是要写上千个字的小作文，
如果项目不追求文档完备，这功能我觉得不太会有人乐意掏钱

实际上用户的痛点是产品经理 自己觉得自己知道是怎么回事
但是就是写不下来。


大概试了一下， 看起来确实是有模有样的，但是严重依赖用户输入。
能好好说话这个还得专门学提示词工程，还得每次都细致地考虑业务场景的细节

太吃产品经理的配置了

不考虑传输中的攻击，你担心数据泄露问题应该包括两个层面

1. 你的数据被任何人获悉， 这个只能靠自建来解决
2. 你的数据被某些能搞你的人获悉， 这个可以考虑选择使用那些不会搞你的中间人

说到底，做出选择实际上是成本，收益和风险之间的权衡

另外一般情况下你发送暴力色情内容，是有可能会导致人账号违规被封的，为了这个的话肯定是得自建的

正经高效工作能有俩小时已经很可以了
特别是已经有上线项目，需求又被产品部门设计得很反人类的情况