科学
言论
- 过去25年，互联网的操作入口一直是搜索。你想要什么，就要去搜索。谷歌主宰着搜索。为了自己的利益，它有动机推动互联网发展。互联网越多样化，越混乱，对谷歌越有利，因为人们就会离不开搜索，来处理混乱的信息。所以，谷歌一直激励人们为互联网创造内容。只有源源不断的内容，才能提升搜索的价值。作为回报，它为内容生产商提供流量，并帮助生产者将流量货币化（主要方法是为内容配上广告）。谷歌是世界最大的搜索引擎，也是世界最大的广告商，这绝非偶然。实际上，谷歌是过去25年互联网最大的赞助商。如果没有像谷歌这样的公司来创造流量激励机制，让内容生产商可以把流量变成金钱，互联网就不会是今天蓬勃发展的样子。情况现在发生了变化。互联网的操作入口，正从搜索引擎变成答案引擎。以前，谷歌给你一张藏宝图，你需要自己去访问链接找出答案。现在，大模型直接给你答案，省去了藏宝图。甚至就连谷歌都有单独的 AI 模式，只有答案，不需要访问链接。这确实方便了用户，但这样就无法产生流量了，整个基于流量的互联网模式就开始崩溃。一旦没有了流量，内容生产商就没有了货币化方式。他赚不到钱，只能减少或放弃内容生产。现在互联网上，人类生产的内容已经萎缩了，根本原因就是传统的”流量变现”模式行不通了。未来有两种可能。一种是大模型公司和平台公司，自己雇人来生产内容；另一种是它们分出一部分收入给内容生产者，换取后者向它们提供内容。无论是哪一种可能，都意味着我们熟悉的互联网形态将不复存在。 – Frank谈Matthew Prince流量变现正在崩塌
- 许多人，尤其是新工程师，错误地认为使用复杂的工具和语言会做出更强大、更具创新性的产品。事实恰恰相反。最有效的组件是简单、可预测、枯燥无趣的成熟技术。它们为我们提供了进一步开发复杂项目所需的基础。你不是要建造一座有趣的桥梁，你要建造的是人们以后要充满信心走在上面的坚固桥梁。 – Choose boring and flexible, not malleable
- 软件业悄然兴起一种新的工作”氛围清理”（Vibe Coding cleanup），专门解决”氛围编程”导致的问题。这真是 AI 时代最大的讽刺：人类被雇来清理 AI 的垃圾。 – Vibe Coding Cleanup as a Service
- 今天的计算机是响应者（responder）：你让它做某事，它就会去做。下一阶段的计算机是”代理”（agent），它就像一个盒子里的小人，开始预测你想要什么。它不是帮助你，而是引导你处理大量的信息，就像你在盒子里有一个小伙伴。 – 乔布斯1984年的采访
- Modern processors have advanced to the point where an entry-level, 6-core CPU is all that most users need, whether they’re gaming, streaming, or dabbling in video editing. Even in 2025, the difference in gaming performance between a 6-core and 8-core CPU isn’t worth paying the premium for the latter. – It’s happened — high-end CPUs are overkill in 2025
- If you’re building a new PC in 2025, you should think thrice before splurging on a high-end CPU. Unless you know you need all that extra performance, the ROI just isn’t there. It’s much better to allocate most of your budget to the graphics card, which will net you the most performance gains. Whether you’re building a PC for gaming, productivity, or AI computing, it might be more practical to avoid CPUs with over 8 cores. – It’s happened — high-end CPUs are overkill in 2025
- 微观粒子可分为费米子和玻色子，两者对立统一，又分别代表了对立与统一。Every elementary particle falls into one of two categories. Collectivist bosons account for the forces that move us while individualist fermions keep our atoms from collapsing.好比“易有三易”：变易、不易、简易。 变易指事物不断地变化发展，不易指变化背后稳定的规律和道理，简易则指事物本质上或核心的简单道理。 这三个概念共同构成了《易经》深刻的哲学思想，描述了宇宙的普遍规律。 – Matter vs. Force: Why There Are Exactly Two Types of Particles
- 交朋友，轻松付出 + 清晰边界。
观点
The 70% problem: Hard truths about AI-assisted coding
根据我的观察，公司里面的高级程序员和低级程序员，使用 AI 的方式是不一样的。
高级程序员并不完全信任 AI 的输出，只是用 AI 加速项目。他们一般会审查和重构 AI 生成的代码，对于 AI 的架构决策也是抱着怀疑的态度。
初级程序员更倾向于跳过审查和重构，全盘接受 AI 的输出，从而导致”纸牌屋式”的代码：看起来能发挥作用，一旦投入使用就会崩溃。
我不知道，AI 未来会不会替代程序员，但是现阶段，AI 编程还不能解决100%的软件问题，但已经可以解决70%的问题。这相当于，AI 可以减轻高级程序员70%的工作量。
剩下的30%，依然需要依靠程序员的经验和专业知识，而初级程序员恰恰缺少的是这30%。
所以，听起来可能违反直觉：AI 对高级程序员比对初级程序员帮助更大，更容易产生工作成果。
现阶段的 AI，更像团队中的一个非常有干劲的初级程序员，可以快速编写代码，但需要不断的监督和纠正。你知道的越多，你就越能指导它。
所以，AI 的正确用法是，高级程序员用它来加速他们已经知道如何做的事情，初级程序员用它来学习该做什么。
The Amusement Park for Engineers
这篇文章是Adnan Esmail在2025年6月发表的，主要介绍了他在Anduril公司的工作经历以及该公司如何从一个小型创业公司扩展25倍发展成为一家价值280亿美元、拥有4000名员工的大型国防技术公司。
文章很长，但完整读下来，感觉作者无论是从作为一个技术人员、管理人员、父亲、师父、还是创业者，都一定程度上是成功的。
文章详细描述了Anduril在产品开发、技术创新、团队建设和组织管理等方面的经验和策略，以及作者离开Anduril创立Physical Intelligence公司的原因和愿景(PI致力于开发一种能够使机器人和自动化设备实现真正自主性的通用智能模型。这一技术突破将重新定义人类与体力劳动的关系，引发一场类似工业革命的生产力变革。)。
1.When I joined Anduril in the fall of 2018, I was employee #20, the company was valued at $250 million, and we had lofty, but hypothetical, ambitions of reinventing the defense ecosystem. Less than six years later, the 4,000-person, $28 billion company has deployed 30-plus products with thousands of fielded systems, and changed the arc of American defense technology. It’s worth looking back now at those years of explosive growth, in order to give other founders, engineers, investors, operators, and everyone else a glimpse of what zero-to-one at Anduril was actually like.
- I’ve always been drawn to the kind of science that translates into strategic impact, and to problems too dangerous to ignore. After studying at MIT, I worked on flood disaster relief in Pakistan, then became a founding engineer at a biotech startup developing affordable genome sequencing technology. When the company was acquired, I left for Tesla, where I worked on projects from the Falcon wing doors in the Model X to electromechanical architectures, autopilot sensors and advanced technologies enabling future vehicle platforms. It was cutting-edge work with one of the most innovative companies in the world, and I was genuinely happy there.
- A coffee in July 2018 with Anduril’s founder Palmer Luckey changed everything. What was supposed to be a quick 30-minute chat turned into a six-hour conversation that made it impossible for me to go back to Tesla. These were the days when supposedly bleeding-edge work in Silicon Valley was still largely dominated by consumer apps and services. By contrast, the picture of the world that Palmer drew kept me up at night.
- On my first day, I found myself back at MIT, on stage beside Palmer, explaining our vision to skeptical engineering students confused why anyone would work in the defense sector. By the end of that same week, I was on the southwest border installing one of our pilot systems, a surveillance tower. It wasn’t the polished product defense contractors typically wait to unveil—in fact, our first tower was literally a telephone pole with a gaming PC housed in a weatherproof box, a pan-tilt unit normally used as stage lighting, with spikes on it to prevent bird shit from blocking the sensors. A lot of it came from Home Depot.
- It was primitive, but it worked, and reflected our approach: get to a minimum viable demonstrator, something that creates end-to-end capability, then iterate ruthlessly. By then I understood that Anduril would be the fastest, most intense environment I’d ever experienced. A few days each week, we’d pile into vehicles and drive to our test site in Apple Valley—a remote California desert location where temperatures reached 110 degrees on summer days, then dropped to 30 at night. We stayed in the cheapest hostel-like accommodations we could find and worked 16- to 18-hour days in complete isolation from distractions. We operated out of dusty trailers with minimal equipment. If something broke, we couldn’t just order a replacement part—someone had to drive 200 miles back to Santa Ana, rebuild the component, then drive 200 miles back.
- Brian Schimpf, Anduril’s co-founder and CEO, functioned as our chief engineer, with an intuitive understanding of how every component fit together. Brian shaped our strategy and had a remarkable knack for pulling together engineering pieces and connecting them to business outcomes. When obstacles appeared, the other founders would come up with a strategy to unblock the engineering so Brian could focus on solving technical challenges—like the time co-founder and COO Matt Grimm chartered a plane in order to fly oversized batteries across the country for a critical demo.
- Even in those early days, the company was single-minded and self-selecting. No one cared about meetings or performance management or building a well-rounded company. We lived and died by our ability to quickly fire a “tracer bullet” through the heart of each problem, illuminating a clear path to the full solution.
- Like diamonds, all great products are born from heat and pressure. Consider the Tesla Model 3: The battery engineers pushed for maximum energy density; the chassis team insisted on minimal weight and thickness; and the safety team required uncompromising crash resilience. Each group had conflicting demands, yet this friction ultimately yielded an exceptional battery pack—powerful, efficient, and safe. No stakeholder was completely satisfied, but through that creative rigor and tension, something extraordinary emerged.
- The same was true at Anduril, where an additional layer of pressure came from the international political reality. America’s adversaries evolve tactics in weeks, and the company had to operate with that same urgency. We couldn’t deliver solutions in years—we needed to prototype, test, and deliver in months or weeks. Each product therefore had to embody our chief working principles: move fast with purpose; question everything; take ownership; keep it simple; hold high standards; and design with deployment in mind.
- As Elon would often say at Tesla, “If the schedule is long, it’s wrong; if it’s tight, it’s right.” Speed was our weapon. Even our recruitment process reflected this: We’d openly talk to candidates from defense contractors and show them around our facilities, confident that we were moving faster.
- We paired speed with another key principle: question everything. This meant engineering from first principles—breaking down every problem into physics, math, and operational reality, then building solutions from there.
- In 2019, the US Air Force wanted to explore new solutions for detecting low-altitude cruise missiles—a critical capability with threats from Russia and China that could penetrate our borders. The official requirements for the Advanced Battle Management System (ABMS) program called for a radar with high azimuth and elevation accuracy and full hemispherical coverage, which would mean multimillion-dollar systems.But no air defense radar manufacturer wanted to sell to us—some because we were a small no-name company, others because they wanted to capture the full value of delivering their own systems, still others because they saw Anduril as a potential future competitor. We needed to create our own solution, but traditional radar development takes years.Instead of taking the Air Force’s brief at face value, we asked: “Why do they need hemispherical coverage? What’s the actual threat?” The primary concern was low-altitude cruise missiles coming across unprotected territory, which meant we only needed to cover the first few degrees above the horizon, not the entire sky.We modified a $5,000 commercial boating radar—the spinning “candy bar” type you see on fishing vessels. Boat radars are designed to detect small objects far away on water, but not in the air. By modifying the waveguide assembly to create a narrower beam, we concentrated more energy in a specific direction and extended the range by about 10x.When we showed up to the bake-off with our cheap modified boat radar mounted on a rickety welded truck, competing against traditional defense contractors with multimillion-dollar systems the size of a shipping container optimized for 360-degree hemisphere coverage, the other attendees laughed.Yet we won. We understood what the customer needed to accomplish, but mostly ignored what they thought they wanted in their requirements. Our system could be scaled along any border as a true cruise missile detection network at a cost that was orders of magnitude lower than traditional solutions.
- The highlight came on the evening before the last day of the bake-off, when US government officials asked if we could take down a far bigger Group Three aircraft—much larger than our system was designed for. With our existing approach, the V2P would simply bounce off such a large target. But we had a potential solution: radar firmware that could identify propellers through micro-Doppler signature and target them specifically. The night before the upcoming test round, we needed to finish writing the updated firmware and flash all of our drones with it.At 3am, the same lead engineer who built 53 vehicles in two weeks went down to the hotel room where the drones were stored and proceeded to disassemble 18 birds. He took apart each radar, separated the processor and RF boards, hooked them up to his computer, flashed them with the new firmware, verified the changes, and reassembled everything. At 7am, he casually walked out as if he’d just woken up like everyone else, as the competing teams came down the elevators.
- In engineering, simplicity is strength. At Anduril, we continuously asked what we could eliminate or simplify.
- The concept seemed absurd at first, even to our team—the overmatch appeared too extreme. But we stripped the problem again to its fundamentals. Cruise missiles are fast, but they follow predictable flight paths. If we could accurately determine that flight path using two ground-based IR passive sensors (what we called Wide-Area Infrared System for Persistent Surveillance, or WISPs), we wouldn’t need expensive targeting systems on the interceptor itself.
- We were scrappy to the core, but we also had a very clear understanding of what “deployability” meant for each system. We were uncompromising about those standards while tolerating rough edges elsewhere. A disciplined approach to trade-offs allowed us to deliver capabilities that competitors with 10 times our resources couldn’t match. The key was attention to detail. Teams without a painfully clear understanding of what’s important have a bias toward frills, whereas we went after the aspects that delivered the most value to the warfighter—avoiding the classic mistake that sales-led organizations often make by building pretty products that fall short in functionality or usability.
- Like diamonds, all great products are born from heat and pressure.
- This was part of Anduril’s secret sauce, and antithetical to how traditional defense contractors operate. The defense primes typically optimize for high-margin, low-volume production with expensive maintenance contracts. Anduril brought Silicon Valley’s mindset of scalable technology to defense—solutions that could be mass-produced and widely deployed.When designing hardware, we broke the product development process into three distinct stages. In the conceptual phase, the most important metric was lead time—how quickly we could get the components needed to build a prototype. In the new product introduction phase, when building 10 to 100 units, we focused on ramp time—how quickly we could work with vendors to reach the rates required for a pilot. In the third stage, full-rate production, the focus shifted to scrap rate and cycle time. Traditional defense programs often fail because they create exotic systems that are too hard to produce or too expensive to deploy at scale. We were determined not to make that mistake.By designing with scale in mind from day one, we aimed to create a virtuous cycle: our products could be deployed more widely because they were affordable, which generated more data and experience, which improved the next generation of products.These core principles guided our product development. But principles alone aren’t enough. To apply them consistently across hundreds of engineers and dozens of products, we needed to design an organization that could sustain this approach at scale.
- Building a high-performance organization was as important as solving technical problems. Throughout my time, I had to maintain this dual identity—an engineer on the frontlines driving design and development, and also a leader responsible for creating the organizational structure that would enable others to do the same. I needed to build a leadership team that could own full lifecycle product development and deliver world-class systems at the pace and precision demanded by our mission. Every hire was made with this blueprint in mind.
- The first priority was to anchor the organization with deep technical credibility. “Badass engineers want to work for badass engineers,” as the saying goes—the best will only work for leaders they can learn from and respect technically. We needed to avoid the common mistake made by organizations which fail by promoting or hiring managers without the technical skills to understand problems, build strong teams, or avoid making flawed engineering decisions. 1.Products were our mission-focused integrated systems. Core technologies were our standardized building blocks—our LEGO pieces—that could be rapidly assembled into new products. Instead of starting each drone from scratch, we created reusable components like flight computers and propulsion systems. Key capabilities were our internal engineering services, like a machine shop that could transform digital concepts into physical prototypes within hours, or teams that could “shake, bake, and shock” components to ensure reliability.
- What made this work was our matrix organization. Instead of creating dedicated teams for each product, we built functional organizations (across electrical, mechanical, and embedded systems) with deep expertise that could surge resources toward critical projects when needed. When we began developing Roadrunner, we pulled engineers from electrical and mechanical pools for intensive development, then shifted them to other projects when those phases ended.
- With this foundation, we maintained small, focused teams while leveraging the broader ecosystem around them. But structure alone wasn’t enough—achieving this level of performance required recruiting the right people and building strong leadership capable of operating in a dynamic environment.
- The leadership approach at Anduril centered on a few core principles.First, we prioritized relentlessly through a daily red-light/green-light system based on the Objectives and Key Results (OKRs) we set. Every product and project had clear metrics that we reviewed constantly. When something showed red, we’d immediately assemble the team to identify root causes. This consumed 60–70% of my time—figuring out the biggest obstacles and eliminating them alongside the team. I was notorious for being chronically late to scheduled meetings because I wouldn’t cut short work on critical problems.Second, we maintained technical credibility through hands-on involvement. By day, I’d handle the corporate aspects—meeting with leaders across the company to drive product and technology development, and continuing a constant discussion about what was slowing us down, what was blocked, and what was broken. But after 5pm, my engineering work began. I’d return to the building at 7:30pm after dinner and wander the labs until the early hours, sitting with teams debugging problems. I’d whiteboard calculations, write Python scripts, and sometimes even solve structural dynamics questions. Engineers knew leadership understood their challenges at a fundamental level because we were there doing the work with them.Third, many of us deliberately stayed out of the spotlight. If you look through photos of our major victories in those days, you won’t find me in them. This wasn’t false modesty; it was strategic. I wanted teams to own their achievements completely. By giving them full credit, they grew more confident and capable for the next challenge.
- As Steve Jobs illustrated with his rock tumbler story, ordinary rocks become polished gems through friction against each other—just as talented teams polish each other through productive conflict to create something exceptional.
- We created a quarterly performance coaching program that identified the bottom 10% who needed support. We established clear OKRs so everyone understood their metrics for success. With transparent expectations, underperforming engineers often recognized on their own when they weren’t the right fit, leading to more respectful separations. This avoided the toxic alternative, common in other companies, where managers undermine struggling employees behind their backs rather than addressing issues directly.
- Preventing organizational bloat proved equally critical. B-players who don’t understand product requirements tend to inflate headcount needs. When business lines claimed they needed 50 people for a project, we evaluated the engineering requirements and often found half were unnecessary. Our hiring estimates typically ran at half of what stakeholders requested and a third of industry standards. I reviewed every engineering hiring proposal personally, rejecting many while we still grew rapidly.
- Building this culture was like coding our organizational DNA—you need the right sequences at the start. The legendary stories from Anduril’s early days became the foundational code, continuously retold and refreshed with new chapters, embedding traits that transformed new engineers into problem-solvers capable of the impossible.
- I thought then of my son, and the innumerable times he accompanied me, often at strange hours and with curious equipment in tow, to desert test sites, landing strips, and hotel rooftops. The best problems, I’ve always told him, are the ones everyone else avoids, until they become impossible to ignore. When he tells me he wants to build things like me when he grows up, I feel the weight of the work I did at Anduril, and what I still have left to do.
SLAM算法工程师每天都在干什么
无论AR,机器人，自动驾驶，或许是同一套模板。
- 研发人员会先跑通一个开源框架，我们耳熟能详的svo,vins,loam等，选其中之一进行算法移植，产品落地。
- 开源框架应用的过程中肯定会存在各种bug及环境适应性，针对环境及需求修复相关bug或者增加新的feature。
- bug和feature修复完毕，一个开源框架才算真正应用到产品，也就是我们说的，第一步跑通了代码。此时，应用但手机硬件cpu或者车载硬件工控机上，软件或测试人员会提出功耗及内存，性能的问题，比如功耗过大导致产品过热，内存过大导致运行卡顿，性能较慢导致启动时间过长等。
- slam研究人员针对功耗，性能，内存的问题进行相关优化，前端主要考虑cv匹配的加速，后端主要考虑求解器的重构，或者求解库的改写，或者自行实现一个求解器。
- 待以上步骤完成后，可以实现一个简单的产品demo，要求不高的话就可以拿这个给三方提供解决方案了。当然，出售之前需要测试各种环境的适配性，对不适配的环境也要重新进行改写，直到达到标准的稳定运行程度。
- 后期产品迭代及预研下一代产品，slam研究员会考虑不同框架的结合，拿出各自的优点进行组合，比如orb和vins，svo和orb的结合，结合的目的当然是创造更好的用户体验。
- slam算法工程师也会打破开源框架的约束，从头开始实习一个新的框架，一步一步往新框架里面添加idea及feature，或者发个论文，写个专利都可。 每个公司的运行模式及人员安排不同，或许更有差异：
有的公司slam算法直接对接三方需求，有的算法与三方中间隔着一层本公司的软件集成
各有各的考虑：
算法直接对外，解决问题的效率自然提升。 算法对接集成，集成对接三方，主要考虑内部算法的隐私性。 毕竟，一个公司，活着，主要靠算法挣钱，尤其是初创企业。
职场语录
- 强势领导别硬刚
- 与人相处，顺应人性和利益
- 只夸不踩
- 任何时候都少提建议
- 说话不要让别人抓住把柄
- 不要别人问你什么你就答什么
- 不喜欢的人，就默默疏远，不必大张旗鼓，再不喜欢的人也要保留表面善意
- 凡事留一手，大事留证据
- 不知道该不该讲的，就不讲
- 勿露底牌
- 看不清时不入局
- 看清别人说话做事的目的
- 不说硬话，不做软事
- 人际交往的本质是利益交换
有趣
荐书
杂谈
手机版“神探玺洛克”请扫码
