@leokun #8 请不要重新发明 cloudflare waf ，免费的

抓包，逆向协议，dump 出资源文件，拦截客户端请求到第三方服务器，自行实现每个 api 的服务器逻辑。
我研究过一点，想打造自己玩的私服，可惜那个小众游戏死得太早，官服关停后理论上已经无法实现了。

anti - 反对/对立
patriotic - 爱国的
cursor 没问题，你有问题

老生常谈的话题，“峰值”200M ，跑多了平均也就 3-5M ，不过对用量小(每月几十 G)的服务还是很划算的。

已经做出成绩、在行业/垂直领域有深厚积累的 toB ，是等需求上门，然后产品经理根据需求制定细节，直到客户满意，顺利地承接需求与产品之间的桥梁。客户也不会要求你搞什么快速交付，不会让你造一个百度/淘宝，只需要按部就班地实现合理的需求，一单的采购价足以养活公司好几年，这形成了一个对所有人有益的良性循环，产品越做越好，是大部分 toB 的最终幻想。
而没需求、没市场的 toB ，就得主动调研市场，上门推销，广撒网全都试一遍，有点苗头就快速出产第一个版本，这经常导致生产出一些奇形怪状的玩意。
所谓的快速交付、敏捷开发，是出资方承受不住高昂的用人成本，快进快出是很常见的模式，可以平摊风险。还有个常见模式是需求定下来扔给外包，中间商风险更低。混吃等死的小作坊则是瞎搞，碰运气做产品，碰运气找客户。想要做到健康的模式，内外阻力太大，市场没这么理想。
以上我都经历过，很多人把 toB 与外包画上约等号，挺合理，toB 出产垃圾的概率太高了。不过这也不是一个人或者几个人能改变的现状。

婚姻不只是两个人的事，看起来你和她不太合适，至少她没有对抗家长的勇气，以后破事少不了。

C 端肯定是先有项目才有产品，这个没必要讨论，反过来有 99.999%的概率是赚不到钱的。
产品经理在这里的定位，是要正确理解受众的需求，需求早已存在，不要重新发明，要把它找出来。

在一些以 B 端为主的低水平开发团队中，产品经理被要求凭空变出来一个项目是很常见的事。
他们会被上面的人要求：
"接下来我们要做一个 OA/ERP/MES 系统，功能你看着办吧，先做第一版试看看，不要让开发闲下来"
"把之前项目 A 和 B 合一下，优化一下不合理的地方"
"上次的项目 C 客户反馈有点臃肿了，你看看把没用的砍了，再加点新东西进去"
"最近大屏有点火，你参考一下别人的产品，和设计讨论下先给几个页面看看"
此时下一个客户还未出现，也许还未出生，销售在千里奔袭，实施在客户机房百度 linux 命令，人事在跟过了二面的砍工资，开发在旧屎山上拉新屎，产品经理背负着全公司的希望输入 seed 执行 random() :)

这间接导致了世界上存在很多不合理、怪异、意义不明、反人类、不应存在于这个世界的软件，因为它们逆转了需求->产品的方向，近乎是随机生产出来的。时间和人力成本决定了无法被需求匹配的它们无法返工，幸运的话它们会以相对廉价的价格被倒霉蛋买走，安静地在一些中小工厂、商户、个人的电脑上运行至今。

软件脱胎于产品原型，产品决定了软件能达到的上限，而设计、开发朝着这个上限努力，产品的重要性应该是排第一的。但产品无法凭空变出来，产品经理不是魔法师，就算是普通人眼中无所不能的 LLM ，也需要一段 prompt 。

B 端的痛点是，需求并非平稳连续、可预知的，忙的时候加班到死，闲的时候会有空窗期。
标准且低级的资本主义思想是尽量让所有人员继续运转，即使是在无意义的空转。
于是产品开始施展 random 魔法，设计、销售、前端、后端、甚至运维跟在后面瞎忙活，他们就像凌晨一点刚看完小说的我一样空洞且迷茫。

1. 我司 B/C 都有，通常由 PM 主导，PM 是开发转过去的。
2. 项目基本都是成功的，主要我们这个方向的竞品大多不堪一击，页面和功能看着 10 年没迭代过了。市场难以预知，决策不重要，运气成分占比太高，个人甚至团队的努力与风口相比不值一提。决定性的作用是任何一方都没有拖后腿。

无解，OSS 想要防止被盗刷流量只能后端调接口，否则无论如何都防不了被刷。
几年前我用蓝奏云零费用解决这种场景的文本分发，现在不知道行不行。
不行的话发公告让用户多捐点，攻击者成本太低了，除了加钱硬抗没有办法。

道与碳基猴子饲养守则
没钱修什么仙
执法者手册

@op351 #4 Claude-4-sonnet 模型影响不大

@TimePPT #3 executeautomation 版本是以测试工程师视角开发的 MCP ，与 MS 官方没有关系，提供的工具更多
MS 家的维护更频繁，不局限于测试，有可能在未来完全覆盖当前功能，看自己选择吧

只在 web 端实践过，效果还行
https://github.com/executeautomation/mcp-playwright
或者用 playwright 写也是一样的，反正是 AI 写

@tcper #35 大厂的大部分服务可用性自称是 3.5 个 9 (99.95%)，5 个 9 的服务没几个，听销售说的，但不知为何到处都在说 5 个 9
关于赔付，基本要经过多次扯皮才能拿到全额代金券。
如果是真正赚钱的核心业务，这点赔偿九牛一毛。
只上一个云不能保证不出问题，但多云运维不是小公司玩得起的，大多数小厂还是绑定在其中一家，出了问题自认倒霉。
可用性说实话没啥用，跟保险差不多，只是赔的没有保险多。绝大部分公司的故障基本与 SLA 无关，是自己的破烂代码出问题，是某个云服务配置出错，真的有秒级恢复也得等他们定位到错误代码在哪，这一般都是几十分钟到几十小时，1 秒恢复和 10 秒恢复没有任何区别。

@wph95 #19 金融支付平台一般都是 5 个 9 ，但遇到故障家常便饭。

@testcgd #87 单体确实相对更考验素质，更考验 review 。我们几乎不会直接使用 ai 生成的代码，它只是个提效工具，开发人员提交 pr 之间必须完全理解逻辑。借助 ai 可以生成一大堆废话直接提交，也可以严肃且优雅地组织代码，这取决于人，不取决于 ai ，它仅仅是个工具。
说到测试，我们的单元测试很少，更偏向基于 playwright 的 e2e 测试。当然如果写 java 大量单元测试还是必不可少的。

@Kirkcong #86
>上面也有人和你说过各种微服务的好处，以及各种现实的例子
我写了 5 年微服务，我确实明白微服务的好处
>从这个观点提出来到现在已经很多年了
时代在变，人也在变
>大家都知道当前 ai 代码的质量有多差
我不知道，可能是那些人没办法定制 MCP ，没制定良好的 rules
>有这吹毛求疵的时间不如去招点和你一样吹毛求疵的人
实际上公司就是这么做的
>大厂中厂不会出现人不够用的情况的
你的公司太好了，我们正在经历的裁员、砍 HC 肯定是假新闻
>好的算法确实会让时间复杂度下降
时间复杂度是用空间复杂度换来的，计算机理论决定了复杂度不会凭空消失

笑麻了
但这本质上不是外包的问题，是请了外包以及没做好验收的问题

1. 有
2. 确实有用
3. 编得太离谱
4. 一定程度上是的
5. 不知道

其实这些都是细枝末节，代码写得好，100%。
在追求锦上添花的东西之前，先把简单的代码写好，就像 v2 的“好好说话”那样，程序员要做的仅仅是"好好写代码"，这就够了。
我说个实际情况，提供 5 个 9 服务的云厂商，自己的业务达不到 5 个 9 。

@Kirkcong #80 人不够用是很现实的问题，要么放弃，要么解决这个问题，这是绝大部分大中小厂在今天都会遇到的问题。公司内部探讨了很久，最终决定是将目前主要业务以单体形式编写，预估代码量超过 50 万行，随着业务扩张不知道最终会膨胀到多少，这个决定在我入职前就已定下来。面试时与面试官探讨了单体架构细节实现、预演各种场景，最终我选择加入并成为主要负责人之一。
我是个吹毛求疵的人，而目前运行中并且不断迭代的项目我很满意其整体质量。

还是那句话，复杂度不会消失，只会转移，最终还是要整个团队完美地处理好一切细节。
如果一个团队能处理好微服务产生的各种问题，那么同样不会在单体中出现上述任何问题。反之在单体中出现上述问题，那么在微服务也好不到哪去，最终只会转移变成另一个问题。
微服务有好处，也有坏处，而现实是我们无法承受其坏处。