现在有几种情况 1 学生们都开始在没有扎实基础和实践上大量使用AI。我前段时间做了一个大学生全国比赛的评委。作为唯一一个产业界评委，我看到了学生们勇于使用AI的精神。有的学生什么都不会，就靠使用AI从500多支参赛队伍中进入了决赛。在这个过程中也学习到了很多。这是值得可定的。只不过这些是比赛，不是实战。 2 在AI使用上老师可能不如学生的能力。所以老师们无法教很多实战（本来产学研也是脱节的），而理论知识现在AI下的理论都每个月层出不穷，处于一线实际的我们也应接不暇。所以这问题也会导致学生们只能靠天赋异禀了。 3 去年我就说过企业因为经营压力问题，使用AI替代初中级工程师。导致本来学生们出来可以慢慢实战积累经验的途径被中断了。也就是现在所说的无法就业。最终我们是技术上传承出现了断代。 4 也许有企业还能招收应届生，但是快速交付的节奏下，没有心思研究基本功。也是AI代为完成。只有极少数可能深耕。所以还是会断代。 5 有了AI学习自己之前不熟悉的领域的能力增强了。知道了怎么突破边界（因为自己知道边界内的细节也知道为什么自己无法突破边界），但是新生一代没有这种痛苦经历，应该是AI快速完成了。他们不知道细节。（极少数天赋和有异于常人的能去触碰这些传统工艺） 其他非技术原因： 1 当下很多企业或许不需要质量（当然这种想法在我们看来是不对的，所以他们不需要写的好，只要及格能用就行。企业焦虑要生存，要用进度和速度去拼抢市场。这其实是供需不平衡，增加进度不能带来营收，至少为了早一步吃蛋糕把别人饿死） 2 企鹅岛上我们对话，企业很多问题是技术以外的事情。技术部门和保安一个级别，我们也要跳出技术看。别太把自己当回事。除非是技术驱动或者技术为核心竞争力的公司。 3 也许本身我们就是翻译人员（既懂人话，又懂计算机的话）。但是随着AI取代同声传译，以后也不会有太好的同声传译一样。也许以后可能就没有这个专业了。 核心竞争力： 学习能力，通过AI学习各种能力。 沟通是项目管理最重要的能力没有之一。尤其在中国。沟通上在事情成败占比很大。有的需求可以通过沟通不做或者降低预期。比死磕技术难题来的容易。 设计能力。设计一小步的改变可能问题解决了一大半。当然这是基于沟通上说，我们这样改设计可以吗？ 情商。就像同盟几个理事长一样，能融合本部各种技术人才。 心态。包容不同意见。讨论不争吵，冒犯时候也能克制很重要。这么多年我在这里吃了很多亏。很多事情看淡点也没什么不好。 以上胡说八道了一些，江哥多包涵。... 展开详请

每次大模型测试都可以使用不同的 Harness 工程，例如： 不同模型需要不同的 API、鉴权或请求格式； 云端模型、本地模型和推理服务的部署方式不同； 不同团队使用各自的评测框架； 专项测试需要独立 Harness，例如安全、性能、Agent、RAG 测试。 但如果每次都更换整个 Harness 工程，测试结果往往不能直接横向比较。Harness 的提示词模板、采样参数、评分器、重试机制、超时设置和结果解析方式，都可能影响最终分数。... 展开详请

核心交易链路是否升级分布式，关键不在用户量或数据规模，而在单库是否已无法通过优化、拆分和治理满足性能、容量与可用性目标。多数业务应优先采用模块化单体、按订单、支付、库存等领域垂直分库，并结合读写分离、缓存、异步化、归档和分库分表预案。该模式本地事务清晰、一致性强，排障、对账和运维成本较低，尤其适用于支付扣款、库存扣减等强一致场景。 分布式架构可横向扩展存储与写入能力，支持热点隔离、独立扩容和跨地域部署，但会引入跨库事务、幂等重试、消息重复或乱序、补偿对账、全局 ID、跨分片查询及数据迁移等复杂问题。因此，不宜因“技术先进”而过早采用。 一般而言，当核心写入持续达到数万 TPS、热点表增长至超亿级且维护困难、单业务域长期达到多 TB 至数十 TB、必须跨地域多活，或大商家和热点活动需要独立隔离时，应认真评估分布式。但具体还取决于数据是否均匀、是否存在热点账户或库存。 升级前应完成领域拆分、缓存限流、异步削峰、冷热归档、热点治理、幂等与补偿机制，并以压测和故障演练验证单库确实无法达标。最终标准是：在峰值和故障下，仍能保证不重复扣款、不超卖、不丢单、账实一致。... 展开详请

结论：信息化、数字化仍是智能化的基础，但部分旧系统、旧流程正在成为包袱。 个人认为 AI离不开数据、接口、权限和业务规则，这些都来自前两者；没有它们，智能化只能停留在演示。但如果数字化只是把低效流程搬到线上、制造数据孤岛、让人围着系统转，AI只会放大低效。 真正该淘汰的不是数字化，而是“固化流程、堆叠系统”的旧数字化。未来需要的是开放、实时、可调用的数字底座。... 展开详请

说说个人愚见。题目是：中国 To B 交付，现在有了 FDE 加上 AI，到底有没有机会解开？ 这里有几个关键字，中国 to B。好了我们就定语部分进行展开。要知道中国 to B。这和to B不一样。 就像足球和中国足球的区别一样。 FDE在有了成功案例，是客观事实。但是那是在美国。同样我们看微软、甲骨文。一个操作系统，一个数据库。都是美国赚钱的公司。 你再看看中国的操作系统和数据库公司。操作系统的公司是不是赚钱了我没数据。反正巅峰时候中国300多家数据库公司就3家盈利。而且现在健在的都不要巅峰时候一半了。 余窃以为这和文化等诸多因素有关。在欧美高度认同人的服务和知识产权。别说是商用产品，你就是用开源产品，找人服务同样有意愿付费。 而我国是用Oracle都不给钱的，用开源还付费？小兵张嘎中的台词：老子在城里下馆子都不给钱，吃你几个西瓜还要钱？ 你和领导汇报开源不等于免费，这个是可以得到认可的。但是说买个服务？领导也会说开源也不意味着就一定要花钱嘛。 当你会一个开发语言和会5个开发语言薪酬是5倍关系吗？掌握一个技术栈和10个技术栈薪酬是线性关系吗？ 好了基于以上的描述有没有异议？如果没有，那么我们看。 FDE这种在中国 toB能不能走通？可能极少数可以（毕竟国内还是有尊重人和知识的） 还有一点就是虽然基本上大家都不是技术驱动的公司，但是技术人不是别人的附属。先做到对技术人平等对待，才可能解决。 达到了一定条件，FDE是真的可以解决中国的 to B问题。... 展开详请

江总我来说说: 1. 公开的表扬赞许 2. 考核体现 3. 当时是公平公正的现金激励兑现 4. 职位晋升的渠道... 展开详请

必须提到“AI Agent（智能体）” 随着通用大模型基座的模型参数和算力优化等关键技术突破，Agent 目前开始越来越多地直接和业务结合。从原来的单纯生成内容，逐步变成了执行动作并拿到结果，原来是 “你问它答”、现在是 “它帮你完成一个完整的任务事项”。 对技术架构师而言，我觉得有三点特别重要： 1、AI 项目的工程架构学习研究，需要建立起符合自身企业的标准化 AI 工程架构； 2、如果需要 Agent 落地，那必须跟业务流程强绑定，架构师需要深入业务场景，理解 Agent 在业务流程中的角色，即是辅助工具？是自动化代理？还是协同伙伴？ 3、强化数据工程意识，所有的 AI 项目落地，都是在玩串联数据，那 数据输入 -> AI -> 数据输出 整个过程，作为架构师需要有很强的数据工程意识，数据敏感、指标量化敏感（当然也包括现在都在讲的 AI 可观测体系）。 以上。 ... 展开详请

一般都是建议随着业务增长而优化的，称之为演进式架构。 理由是： - 业务哪有百分比成功的，大部分可能没做起来就黄了，成本hold不住了，模式跑不通等等，都有可能导致业务下线，前期投入这么大不划算,而且比较笨重，可能成为业务发展的瓶颈（背锅） - 要看主要矛盾。新业务前期的主要矛盾肯定不是需要一个牛逼的系统，而是要快速验证、快速迭代 当然了，快速迭代嘛，系统也别做的太死了，可拓展性高一些，不然每次迭代都要动作很大，效率低，也是个问题... 展开详请