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 万行，随着业务扩张不知道最终会膨胀到多少，这个决定在我入职前就已定下来。面试时与面试官探讨了单体架构细节实现、预演各种场景，最终我选择加入并成为主要负责人之一。
我是个吹毛求疵的人，而目前运行中并且不断迭代的项目我很满意其整体质量。

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

@gl3081 #78 微服务有传染性，单体有排他性。兼容时期一般存在于单体架构慢慢演变为微服务架构，八股文称之为渐进式重构，最后会彻底变成微服务。

AGI 时代，人类劳动价值由剥削 AI 劳动价值衡量。
资本主义中，一个劳动者产出 100 元，资本家剥削了 60 元，劳动者获得 40 元，劳动者最终获得的金钱与被剥削价值大多数情况下是线性关系。
AGI 时代，一个劳动者通过剥削 AI 产出 200 元，AI 成本 70 元，资本家剥削了 90 元，劳动者获得 40 元。如果劳动者能更大程度地剥削 AI ，就能获得更多的回报。而在以前，劳动者可以通过学习各种技能、总结经验达到一样的效果，但在 AGI 时代效率太慢，资本主义会强迫一切事物向着更快获利的方向前进，它会强迫一切劳动者利用 AI 榨取出更多价值。
时代一直在变，但好像有些东西永远不会变，只是这个时代劳动者手里的工具名字叫做 AI 而已。