<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://iphyer.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://iphyer.github.io/" rel="alternate" type="text/html" /><updated>2026-08-11T04:08:24+00:00</updated><id>https://iphyer.github.io/feed.xml</id><title type="html">桑弧蓬矢射四方</title><subtitle>iphyer&apos;s Blog Website</subtitle><entry><title type="html">工作总结 7</title><link href="https://iphyer.github.io/blog/2026/08/10/workingSummary7/" rel="alternate" type="text/html" title="工作总结 7" /><published>2026-08-10T20:54:00+00:00</published><updated>2026-08-10T20:54:00+00:00</updated><id>https://iphyer.github.io/blog/2026/08/10/workingSummary7</id><content type="html" xml:base="https://iphyer.github.io/blog/2026/08/10/workingSummary7/"><![CDATA[<p>最近在年中总结刚刚发下来，总结下并且提高改进。</p>

<p>[Revised by ChatGPT]</p>

<!--more-->

<h1 id="工作方式的两个变化deadline-与-ai-demo">工作方式的两个变化：Deadline 与 AI Demo</h1>

<p>最近在工作中有两个比较明显的体会：<strong>一是要更加重视 Deadline 和项目节奏，二是要更加重视 AI Demo 带来的影响力。</strong></p>

<p>这两个事情看起来比较独立，但背后其实反映的是同一个变化：现在的工作越来越需要通过<strong>跨团队协作、对外合作和技术影响力</strong>来推动事情落地。</p>

<h2 id="1-设置并管理-deadline">1. 设置并管理 Deadline</h2>

<p>现在的组工作方式和以前有一个比较大的不同。</p>

<p>以前主要是和 Amazon 内部的其他组合作。如果两个组之间出现 timeline 或者 priority 上的冲突，通常两个组的 manager 沟通一下，就比较容易达成一致。</p>

<p>但现在的情况不太一样。我们越来越多地需要和 <strong>partner</strong> 合作，而这已经不完全是一个内部协作关系。既然涉及外部合作，就需要更加尊重双方已经约定好的 timeline，并按照共同的计划推进项目。</p>

<p>因此，<strong>Deadline 不再只是一个项目管理上的时间点，而是合作关系中的一个重要承诺。</strong></p>

<p>这也意味着，在项目开始的时候，就需要更加主动地围绕 Deadline 进行 planning，而不是等到 deadline 快到了才开始推动。</p>

<p>几个比较重要的原则：</p>

<h3 id="11-backward-planning">1.1 Backward Planning</h3>

<p>拿到一个最终 Deadline 后，应该 <strong>backward working</strong>，从最终交付时间反推整个项目的时间安排。</p>

<p>例如：</p>

<blockquote>
  <p>Final Deadline → Final Review → Integration → Development → Design → Initial Discussion</p>
</blockquote>

<p>这样可以比较早地发现时间是否足够，也能够避免所有工作都堆积到最后一周。</p>

<h3 id="12-limit-the-key-squad-team">1.2 Limit the Key Squad Team</h3>

<p>项目初期不要把太多人拉进来。</p>

<p>一个过大的 team 往往意味着更多的沟通成本、更多的 dependency，以及更慢的 decision-making。</p>

<p>应该尽可能明确：</p>

<ul>
  <li>谁是真正的 core team</li>
  <li>谁负责关键技术决策</li>
  <li>谁负责具体 implementation</li>
  <li>谁只需要在特定 milestone 参与</li>
</ul>

<p><strong>小而明确的 core team，通常比一个很大的 working group 更有效率。</strong></p>

<h3 id="13-setup-milestones-and-regular-checks">1.3 Setup Milestones and Regular Checks</h3>

<p>一个大的 Deadline 不应该是唯一的时间节点。</p>

<p>应该提前设置几个 milestone，并在 milestone 到达之前进行 check：</p>

<ul>
  <li>是否按照计划推进？</li>
  <li>有没有新的 blocker？</li>
  <li>有没有 dependency 没有解决？</li>
  <li>当前 scope 是否仍然合理？</li>
  <li>是否需要调整资源？</li>
</ul>

<p>这样做的好处是，可以把一个“大问题”拆成几个“小问题”，而不是等到最后才发现项目已经无法按时完成。</p>

<h3 id="14-go--no-go-decision">1.4 Go / No-Go Decision</h3>

<p>在一些关键节点，需要提前定义 <strong>Go / No-Go decision point</strong>。</p>

<p>到了这个时间点，不应该继续无限讨论，而应该明确决定：</p>

<blockquote>
  <p><strong>Go：继续按照当前方案投入资源。</strong>
<strong>No-Go：及时停止、调整方向，或者重新定义 scope。</strong></p>
</blockquote>

<p>尤其是在时间比较紧、又涉及外部 partner 的项目中，及时做 decision 往往比继续等待更多信息更加重要。</p>

<hr />

<h2 id="2-重视-ai-demo-time">2. 重视 AI Demo Time</h2>

<p>另外一个最近越来越明显的体会是：<strong>AI Demo 是获得关注度和建立个人影响力的一个非常好的机会。</strong></p>

<p>一个好的 Demo，不只是展示一个技术结果。</p>

<p>当你真正花时间去准备一个 Demo，把复杂的技术内容整理清楚，并且能够让别人快速理解：</p>

<blockquote>
  <p><strong>你做了什么 → 为什么重要 → 和实际工作有什么关系 → 能带来什么价值</strong></p>
</blockquote>

<p>别人其实很容易感受到你的投入。</p>

<p>而一旦大家开始关注你的 Demo，你在团队中的 <strong>visibility</strong> 也会自然提高。</p>

<p>所以，<strong>不要低估一次 Demo 带来的影响力。</strong></p>

<h3 id="21-平时就要积累">2.1 平时就要积累</h3>

<p>Demo 不是在需要分享的时候才临时准备的。</p>

<p>平时应该有意识地积累一些值得分享的东西，例如：</p>

<ul>
  <li>最近读到的一篇有意思的 paper</li>
  <li>一个新的 AI/ML 方法</li>
  <li>一个工作中遇到的问题</li>
  <li>一个自己尝试过的小实验</li>
  <li>一个可以真正解决业务问题的技术方案</li>
  <li>一个值得进一步探索的 idea</li>
</ul>

<p>这样到了需要 Demo 的时候，就不会出现：</p>

<blockquote>
  <p>“最近好像也没什么东西可以分享。”</p>
</blockquote>

<p>如果平时确实没有太多可以直接分享的项目，那么<strong>多读一些 paper 也是一种积累方式</strong>。</p>

<p>读 paper 的目的不一定是为了马上发表论文，而是不断增加自己对新技术、新方法和新方向的理解，然后思考：</p>

<blockquote>
  <p><strong>这个东西和我们现在的工作有没有结合点？</strong></p>
</blockquote>

<p>真正有价值的 Demo，往往不是单纯介绍一个新技术，而是能够把<strong>新技术和实际工作结合起来</strong>。</p>

<hr />

<h3 id="22-4-minute-video-更需要思考">2.2 4-Minute Video 更需要思考</h3>

<p>现在组里比较常见的一种方式，是提前准备一个 <strong>4 分钟以内的 AI Demo Video</strong>。</p>

<p>我其实觉得这种形式非常好。</p>

<p>因为时间只有 4 分钟，所以你不可能把所有细节都讲完。这反而迫使你思考：</p>

<blockquote>
  <p><strong>什么是最重要的？</strong></p>
</blockquote>

<p>一个好的 4-minute Demo，应该让观众在很短的时间内理解：</p>

<ol>
  <li><strong>Problem：</strong> 我们要解决什么问题？</li>
  <li><strong>Approach：</strong> 我们用了什么方法？</li>
  <li><strong>Result：</strong> 得到了什么结果？</li>
  <li><strong>Impact：</strong> 为什么这个结果值得关注？</li>
</ol>

<p>因此，不能为了 Demo 而 Demo。</p>

<p>如果只是把一个技术结果展示出来，却没有和实际工作产生联系，那么即使做得很漂亮，长期来看带来的价值也比较有限。</p>

<p>相反，如果一个 Demo 能够把 <strong>AI 技术、实际工作和业务价值</strong>连接起来，那么它的影响力会大很多。</p>

<hr />

<h2 id="3-一个简单的节奏">3. 一个简单的节奏</h2>

<p>如果让我总结一个比较实际的节奏，我觉得：</p>

<blockquote>
  <p><strong>大约每两个月准备一次有质量的 AI Demo，是一个比较合适的频率。</strong></p>
</blockquote>

<p>不需要追求每周都有 Demo，也没有必要为了保持曝光度而强行制造内容。</p>

<p>更重要的是保持一个持续的节奏：</p>

<p><strong>平时积累 → 发现问题 → 尝试技术 → 形成结果 → 总结 → Demo</strong></p>

<p>这样做下来，Demo 就不再是一个额外的工作，而会逐渐成为自己工作的一部分。</p>

<p>最终，我觉得这两件事情——<strong>Deadline Management 和 AI Demo</strong>——其实分别对应了工作的两个重要能力：</p>

<blockquote>
  <p><strong>Deadline 帮助你把事情真正落地。</strong>
<strong>Demo 帮助别人看到你做的事情以及它的价值。</strong></p>
</blockquote>

<p>一个是 <strong>Execution</strong>，一个是 <strong>Visibility</strong>。</p>

<p>两者可能缺一不可。</p>]]></content><author><name></name></author><category term="生活" /><category term="工作" /><summary type="html"><![CDATA[最近在年中总结刚刚发下来，总结下并且提高改进。]]></summary></entry><entry><title type="html">工作总结 6</title><link href="https://iphyer.github.io/blog/2026/06/16/workingSummary6/" rel="alternate" type="text/html" title="工作总结 6" /><published>2026-06-16T20:54:00+00:00</published><updated>2026-06-16T20:54:00+00:00</updated><id>https://iphyer.github.io/blog/2026/06/16/workingSummary6</id><content type="html" xml:base="https://iphyer.github.io/blog/2026/06/16/workingSummary6/"><![CDATA[<p>最近在新的组工作了一段时间，总结下最近的进展并且记录下来。</p>

<p>[Revised by ChatGPT]</p>

<!--more-->

<h2 id="1-坚持高标准并且每日记录">1. 坚持高标准，并且每日记录。</h2>

<p>亚马逊有一个非常重要的 Leadership Principle：</p>

<blockquote>
  <p>Insist on the Highest Standards</p>
</blockquote>

<p>很多团队的问题并不是不努力，而是默认接受了较低的质量标准。</p>

<p>高标准不是等到上线前再检查，而是体现在每一个日常环节：</p>

<ul>
  <li>Code Review</li>
  <li>Design Review</li>
  <li>Technical Proposal</li>
  <li>Operational Excellence</li>
  <li>Postmortem</li>
</ul>

<p>我越来越相信：</p>

<p>质量不是测试出来的，而是在整个开发过程中设计出来的。</p>

<p>当团队对于代码质量、文档质量、设计质量都有明确要求时，长期来看反而能够提升开发速度。</p>

<p>因为技术债务减少了，返工减少了，团队成员之间的信任也更高。</p>

<p>高标准短期看似更慢，长期却是最快的路径。</p>

<h2 id="2-快速交付但不要一次做太多">2. 快速交付，但不要一次做太多</h2>

<p>很多项目失败并不是因为方向错误，而是因为交付周期太长。</p>

<p>亚马逊强调：</p>

<blockquote>
  <p>Deliver Results</p>
</blockquote>

<p>但优秀团队的特点并不是一次性交付一个巨大的项目，而是持续不断地交付价值。</p>

<p>我的经验是：</p>

<p>与其规划一个 6 个月后才能看到结果的大项目，不如拆分成多个两周或者一个月就能验证价值的小阶段。</p>

<p>例如：</p>

<ul>
  <li>第一阶段验证可行性</li>
  <li>第二阶段验证用户价值</li>
  <li>第三阶段扩展规模</li>
  <li>第四阶段优化体验</li>
</ul>

<p>这样既降低风险，也能够更快获得反馈。</p>

<h2 id="3-保持每周都有可见产出">3. 保持每周都有可见产出</h2>

<p>其实你会发现 1 和 2 是有一定矛盾的，高标准很可能拖慢速度。所以我们需要可行的方法，我现在个人感觉最好的方法就是</p>

<blockquote>
  <p>每周是否有看得见的输出？</p>
</blockquote>

<p>我越来越重视一个简单指标：</p>

<p>每周是否有看得见的输出？</p>

<p>这里的输出可以是：</p>

<ul>
  <li>一个上线功能</li>
  <li>一个设计文档</li>
  <li>一个实验结果</li>
  <li>一个技术分享</li>
  <li>一个自动化工具</li>
</ul>

<p>如果连续几周都没有可见成果，往往意味着：</p>

<ul>
  <li>工作目标不够清晰</li>
  <li>项目粒度过大</li>
  <li>决策链条过长</li>
</ul>

<p>而持续输出能够形成正反馈：</p>

<p>输出 → 获得反馈 → 调整方向 → 继续输出</p>

<p>久而久之，团队会形成一种健康的执行文化。</p>

<p>相比年度规划，我更关注：</p>

<blockquote>
  <p>本周创造了什么新的价值。</p>
</blockquote>

<h2 id="4-ai-first-不只是工具而是一种思维方式">4. AI First 不只是工具，而是一种思维方式</h2>

<p>今年最明显的变化，是 AI 已经从一个辅助工具变成了一种新的工作模式。</p>

<p>过去的思考顺序通常是：我该怎么做？</p>

<p>现在更应该先问：AI 能帮助我完成哪些部分？</p>

<p>例如：</p>

<ul>
  <li>文档撰写</li>
  <li>数据分析</li>
  <li>代码生成</li>
  <li>测试用例设计</li>
  <li>知识检索</li>
  <li>Root Cause Analysis</li>
</ul>

<p>哪些部分可以用 AI 来辅助，我个人体会几乎所有任务 AI 都可以完成了，当然质量如何取决于你的任务复杂度，需要你提供 context 和 review。</p>

<p>AI First 并不是让 AI 替代工程师。相反，它让工程师把更多时间投入到：</p>

<ul>
  <li>架构设计</li>
  <li>业务理解</li>
  <li>技术判断</li>
  <li>创新探索</li>
</ul>

<p>这些真正高价值的工作上。</p>

<p>未来几年，人与 AI 协作的能力，很可能会成为工程师的重要竞争力之一。</p>

<h2 id="5-主动展示成果让影响力被看见">5. 主动展示成果，让影响力被看见</h2>

<p>很多工程师习惯埋头做事，却忽略了成果传播。</p>

<p>亚马逊另一个重要原则是：</p>

<blockquote>
  <p>Earn Trust</p>
</blockquote>

<p>而建立信任的重要方式之一，就是让别人看到你的成果。</p>

<p>过去一段时间里，我越来越重视：</p>

<ul>
  <li>Monthly Sync</li>
  <li>Demo Session</li>
  <li>Leadership Review</li>
  <li>Tech Talk</li>
</ul>

<p>这些活动的价值不仅是汇报工作。</p>

<p>更重要的是：</p>

<ul>
  <li>获取反馈</li>
  <li>对齐方向</li>
  <li>建立影响力</li>
  <li>获得资源支持</li>
</ul>

<p>很多时候，一个优秀的 Demo 所带来的组织影响，甚至超过几个月的默默开发。</p>

<p>好的工作需要被完成。</p>

<p>优秀的工作需要被看见。</p>

<h2 id="总结">总结</h2>
<p>回头看，这些原则其实都不复杂：</p>

<ul>
  <li>坚持高标准</li>
  <li>小步快跑</li>
  <li>每周持续输出</li>
  <li>AI First 思维</li>
  <li>主动展示成果</li>
</ul>

<p>它们共同指向一个目标：</p>

<p>在保证质量的前提下，加快反馈循环，并不断扩大个人和团队的影响力。</p>

<p>对于工程团队而言，真正的竞争优势往往不来自某个单独的技术突破，而来自一套能够长期复利的工作方式。</p>

<p>而高标准、快速反馈和持续学习，正是这套工作方式的核心。</p>]]></content><author><name></name></author><category term="生活" /><category term="工作" /><summary type="html"><![CDATA[最近在新的组工作了一段时间，总结下最近的进展并且记录下来。]]></summary></entry><entry><title type="html">Retro of Q1 2026</title><link href="https://iphyer.github.io/blog/2026/04/05/retroQ12026/" rel="alternate" type="text/html" title="Retro of Q1 2026" /><published>2026-04-05T22:54:00+00:00</published><updated>2026-04-05T22:54:00+00:00</updated><id>https://iphyer.github.io/blog/2026/04/05/retroQ12026</id><content type="html" xml:base="https://iphyer.github.io/blog/2026/04/05/retroQ12026/"><![CDATA[<p>之前的 RIF 我写了个总结，但是因为各种事情，我拖到今天才开始写。也不太想改动当时写的东西——虽然写得非常潦草，但确实是当时的感受，还是留着。<a href="https://iphyer.github.io/blog/2026/01/30/retroRIF/">Retro of RIF</a></p>

<p>这篇 Blog 重新总结下自己最近的感悟和体会，既是总结复盘，也是对未来重新计划。总结这七点，既是对 Q1 的复盘，也是对 Q2 乃至全年的行动指南。与其焦虑变化，不如主动适应。</p>

<!--more-->

<h2 id="1-居安思危--刷题不能停">1. 居安思危 — 刷题不能停</h2>

<p>AI 替代的趋势越来越明显，刷题不能停。你需要达到的水平是：<strong>如果今天被 impact，明天去面试，要有把握能拿到 offer。</strong></p>

<p>重点方向：</p>

<ul>
  <li><strong>LeetCode</strong> — 算法与数据结构</li>
  <li><strong>System Design</strong> — 大规模系统设计</li>
  <li><strong>Object-Oriented Design (OOD)</strong> — 面向对象设计</li>
</ul>

<h2 id="2-每天提交-cr">2. 每天提交 CR</h2>

<p>虽然不一定喜欢这种节奏，但按照现在 AI coding 的趋势，将来每个 SDE 每年的 CR 数量可能超过 365 条——也就是说，<strong>每天提交 CR 将成为默认预期</strong>。</p>

<p>现在开始养成这个习惯，是为将来做准备。</p>

<h2 id="3-加强沟通多参与跨团队工作">3. 加强沟通，多参与跨团队工作</h2>

<p>最近公司甚至要求 manager 也要提交 CR。这意味着 SDE 不能再固步自封：</p>

<ul>
  <li>你需要<strong>加强沟通和协调能力</strong></li>
  <li>未来的模式可能是：<strong>一个人带领一支 AI Agent Army 协同完成工作</strong></li>
</ul>

<p>你的 <strong>Domain Knowledge</strong> 会越来越值钱。AI 干活比你快、比你好，它们干不好的唯一原因是<strong>缺乏 Context</strong>。所以提升领域知识深度，是你最核心的护城河。</p>

<h2 id="4-早起早睡提高-visibility">4. 早起早睡，提高 Visibility</h2>

<p>过去四年，manager 在 Irvine，上班节奏相对自由。但现在不同了——<strong>manager 就在 Austin</strong>。</p>

<p>让别人记住你、了解你，比单纯埋头干活更加重要。调整作息，提高在团队中的存在感和影响力。</p>

<h2 id="5-必须有-ai--llm-project">5. 必须有 AI / LLM Project</h2>

<p>你必须有自己的 AI / LLM 相关项目，并且<strong>能够清晰地追踪和展示它的进展</strong>。</p>

<p>这是 Leadership 当前最关注的重点，也是证明自己与时俱进的最直接方式。</p>

<h2 id="6-理解-big-picture">6. 理解 Big Picture</h2>

<p>很多时候我们只关注手头的任务，但在 AI 时代，<strong>提升看问题的视角</strong>变得越来越重要。</p>

<p>Big Picture 不会带来立竿见影的提升，但它能帮助你更准确地理解问题的本质。</p>

<blockquote>
  <p>遇到问题，多问一句：<strong>“这是为什么？”</strong></p>
</blockquote>

<p>现在需要的不只是某个领域的 Expert，而是一个<strong>能够领导 AI、协调全局的多面手</strong>。</p>

<h2 id="7-安全思路优先">7. 安全思路优先</h2>

<p>就像驾驶一样——安全驾驶，不冒险。</p>

<p>现在做的是 Payment System，安全是重中之重。在多种技术方案并存时，<strong>优先选择更稳健、更安全的路径</strong>，而不是追求激进或炫技的方案。</p>]]></content><author><name></name></author><category term="生活" /><category term="工作" /><summary type="html"><![CDATA[之前的 RIF 我写了个总结，但是因为各种事情，我拖到今天才开始写。也不太想改动当时写的东西——虽然写得非常潦草，但确实是当时的感受，还是留着。Retro of RIF]]></summary></entry><entry><title type="html">[书评]《硅谷Python工程师面试指南：数据结构、算法与系统设计》</title><link href="https://iphyer.github.io/blog/2026/02/02/SliconVallaySDEInterviewGuide/" rel="alternate" type="text/html" title="[书评]《硅谷Python工程师面试指南：数据结构、算法与系统设计》" /><published>2026-02-02T20:54:00+00:00</published><updated>2026-02-02T20:54:00+00:00</updated><id>https://iphyer.github.io/blog/2026/02/02/SliconVallaySDEInterviewGuide</id><content type="html" xml:base="https://iphyer.github.io/blog/2026/02/02/SliconVallaySDEInterviewGuide/"><![CDATA[<p>最近读完了 <em>硅谷Python工程师面试指南：数据结构、算法与系统设计</em>。
在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。</p>

<p>内容由 ChatGPT 生成，大纲是我提供的。</p>

<!--more-->

<p><a href="https://book.douban.com/subject/37253395/">👉 书籍链接 (Douban)</a></p>

<hr />

<h2 id="一句话总结">一句话总结</h2>

<p><strong>不必读，这本书内容选材不错，但是制作粗糙，帮助不大。</strong></p>

<hr />

<h2 id="为什么选材不错">为什么选材不错</h2>

<p>这本书的角度还是不错，编程基础，算法，系统设计都有讨论到。</p>

<h3 id="制作粗糙">制作粗糙</h3>

<p>但是，制作非常粗糙。很多时候，结合和 Leetcode 题目来讨论，本来是非常好的思路，但是作者明显用心不足。</p>

<p>算法的解释，很多就是简单的copy来的，或者看着 Leetcode 答案编写的，还是暴力英译中。你越看越糊涂。</p>

<p>更重要的是，很多代码格式错误，对于 Python 缩进如果错误，那就是非常致命的错误。</p>

<p>还有，如果可以，是不是可以给题目，添加一个 Leetcode 链接？ 很多题目的描述，我作为中文母语读者都无法理解。</p>

<h3 id="系统设计">系统设计</h3>

<p>还是可以读一读，但是大概就是半小时那种。</p>

<p>非常的浮光掠影，蜻蜓点水，帮助不大</p>

<h2 id="总结">总结</h2>

<p>非常不推荐，帮助不大。</p>]]></content><author><name></name></author><category term="学习" /><summary type="html"><![CDATA[最近读完了 硅谷Python工程师面试指南：数据结构、算法与系统设计。 在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。]]></summary></entry><entry><title type="html">Retro of RIF</title><link href="https://iphyer.github.io/blog/2026/01/30/retroRIF/" rel="alternate" type="text/html" title="Retro of RIF" /><published>2026-01-30T22:54:00+00:00</published><updated>2026-01-30T22:54:00+00:00</updated><id>https://iphyer.github.io/blog/2026/01/30/retroRIF</id><content type="html" xml:base="https://iphyer.github.io/blog/2026/01/30/retroRIF/"><![CDATA[<p>深刻反思下 RIF，现在还在 wrap up，但是这里先总结下。</p>

<!--more-->

<h2 id="居安思危--思危思退思变">居安思危 – “思危、思退、思变”</h2>

<p>别人提醒，要时刻反思，居安思危。</p>

<p>“思危、思退、思变”是需要每周都做的必修课。</p>

<h2 id="如果东西有可能出错就多检查一遍多打印备份">如果东西有可能出错，就多检查一遍，多打印备份。</h2>

<p>最近打印照片，需要在背后写点东西，我想到了可能写错，当时还测试了好久，还是错了。其实多打印两张照片没多少钱，我却没想到，还是傻傻打印了固定份。</p>

<p>不要怕备份！</p>

<p>寄快递也是，地址 UPS 人员少打了 Building A，虽然东西后来也送到了，但是如果是真是十分重要的文件，还是一模一样的复用别人给的地址最好。我是后来检查发现的，但是更好的方法应该是当场让他们改进，这是最好的！</p>

<p>不要怕检查，当面检查，交割清楚！</p>

<h2 id="面试时自信--relax--思考后慢慢说-like-lucas">面试时，自信 + relax + 思考后，慢慢说 like Lucas</h2>

<p>Lucas 是我的一个同事，说话非常慢，但是就是给人很可靠的感觉。</p>

<p>感觉我就是需要联系这种能力，很多时候，你需要慢下来仔细思考才行。</p>]]></content><author><name></name></author><category term="生活" /><category term="工作" /><summary type="html"><![CDATA[深刻反思下 RIF，现在还在 wrap up，但是这里先总结下。]]></summary></entry><entry><title type="html">父母来美机场 checklist</title><link href="https://iphyer.github.io/blog/2026/01/15/Parent2US/" rel="alternate" type="text/html" title="父母来美机场 checklist" /><published>2026-01-15T22:54:00+00:00</published><updated>2026-01-15T22:54:00+00:00</updated><id>https://iphyer.github.io/blog/2026/01/15/Parent2US</id><content type="html" xml:base="https://iphyer.github.io/blog/2026/01/15/Parent2US/"><![CDATA[<p>父母最近来美国,已经有 5 年没见过爸妈了。五年时间,不知不觉间父母的鬓角又添了几缕白发，妈妈的腰也弯得厉害。</p>

<!--more-->

<h2 id="机票选择">机票选择</h2>

<p>给父母购买机票时,建议优先考虑直飞航班,比如上海到达拉斯的直飞航班,可以避免转机的麻烦。如果确实需要转机,香港是一个很好的选择——中文环境下沟通无障碍,父母也更容易适应。相比之下,首尔或东京等非中文机场可能会给父母带来语言不通的困扰。</p>

<h2 id="机场-wifi-连接">机场 WiFi 连接</h2>

<p>美国机场普遍提供免费 WiFi 服务。务必提前查询好机场的 WiFi 连接方式,并详细告知父母如何操作。连上 WiFi 后,父母就可以通过微信随时保持联系,这对于缓解他们的紧张情绪非常有帮助。</p>

<p>中国机场的 WiFi 通常需要手机号验证,不过父母来美国时会保留国内手机号,这点不用担心。</p>

<h2 id="准备美元零钱">准备美元零钱</h2>

<p>建议提前为父母准备一些美元零钱,比如:</p>

<ul>
  <li>五张 $2 的纸币</li>
  <li>两张 $5 的纸币</li>
  <li>一张 $10 或 $20 的纸币</li>
</ul>

<p>这样父母在机场可以方便地购买咖啡、瓶装水,或者在需要时打电话,不必为找零或使用大额纸币而烦恼。</p>

<h2 id="gate-pass-服务">Gate Pass 服务</h2>

<p>如果是在美国机场送机,强烈建议在值机时申请 Gate Pass。我在美国办理过这项服务,至少美国航空(AA)是免费提供的。</p>

<p>有了 Gate Pass,你就可以陪同父母通过安检,一直送到登机口。对于不熟悉全英文环境的父母来说,能有人陪伴到最后一刻,会让他们更加安心,你也更加放心。</p>]]></content><author><name></name></author><category term="生活" /><summary type="html"><![CDATA[父母最近来美国,已经有 5 年没见过爸妈了。五年时间,不知不觉间父母的鬓角又添了几缕白发，妈妈的腰也弯得厉害。]]></summary></entry><entry><title type="html">NOT IN vs LEFT ANTI JOIN: A Performance Comparison</title><link href="https://iphyer.github.io/blog/2025/12/27/LeftAntiJoinVSNotIn/" rel="alternate" type="text/html" title="NOT IN vs LEFT ANTI JOIN: A Performance Comparison" /><published>2025-12-27T22:54:00+00:00</published><updated>2025-12-27T22:54:00+00:00</updated><id>https://iphyer.github.io/blog/2025/12/27/LeftAntiJoinVSNotIn</id><content type="html" xml:base="https://iphyer.github.io/blog/2025/12/27/LeftAntiJoinVSNotIn/"><![CDATA[<p>When filtering data based on exclusion criteria, the choice between <code class="language-plaintext highlighter-rouge">NOT IN</code> and <code class="language-plaintext highlighter-rouge">LEFT ANTI JOIN</code> can significantly impact query performance. This post demonstrates why <code class="language-plaintext highlighter-rouge">LEFT ANTI JOIN</code> is typically the better choice.</p>

<p>&lt; Revised and generated with help of Claude &gt;</p>

<!--more-->

<h2 id="original-approach-inefficient">Original Approach (Inefficient)</h2>

<div class="language-sql highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">SELECT</span> <span class="n">product_id</span><span class="p">,</span> <span class="n">product_category</span>
<span class="k">FROM</span> <span class="n">products_dim</span>
<span class="k">WHERE</span> <span class="n">region_id</span> <span class="o">=</span> <span class="mi">100</span>
    <span class="k">AND</span> <span class="n">product_id</span> <span class="k">NOT</span> <span class="k">IN</span> <span class="p">(</span>
        <span class="k">SELECT</span> <span class="n">product_id</span>
        <span class="k">FROM</span> <span class="n">products_dim</span>
        <span class="k">WHERE</span> <span class="n">region_id</span> <span class="o">=</span> <span class="mi">200</span>
    <span class="p">)</span>
    <span class="k">AND</span> <span class="n">product_category</span> <span class="k">IS</span> <span class="k">NOT</span> <span class="k">NULL</span>
</code></pre></div></div>

<h2 id="optimized-approach-recommended">Optimized Approach (Recommended)</h2>

<div class="language-sql highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">SELECT</span> <span class="n">a</span><span class="p">.</span><span class="n">product_id</span><span class="p">,</span> <span class="n">a</span><span class="p">.</span><span class="n">product_category</span>
<span class="k">FROM</span> <span class="n">products_dim</span> <span class="n">a</span>
<span class="k">LEFT</span> <span class="n">ANTI</span> <span class="k">JOIN</span> <span class="p">(</span>
    <span class="k">SELECT</span> <span class="k">DISTINCT</span> <span class="n">product_id</span>
    <span class="k">FROM</span> <span class="n">products_dim</span>
    <span class="k">WHERE</span> <span class="n">region_id</span> <span class="o">=</span> <span class="mi">200</span>
<span class="p">)</span> <span class="n">b</span> <span class="k">ON</span> <span class="n">a</span><span class="p">.</span><span class="n">product_id</span> <span class="o">=</span> <span class="n">b</span><span class="p">.</span><span class="n">product_id</span>
<span class="k">WHERE</span> <span class="n">a</span><span class="p">.</span><span class="n">region_id</span> <span class="o">=</span> <span class="mi">100</span>
    <span class="k">AND</span> <span class="n">a</span><span class="p">.</span><span class="n">product_category</span> <span class="k">IS</span> <span class="k">NOT</span> <span class="k">NULL</span>
</code></pre></div></div>

<h2 id="why-this-works">Why This Works</h2>

<p>Both queries return exactly the same result: products from region 100 that don’t exist in region 200.</p>

<h3 id="key-differences">Key Differences</h3>

<table>
  <thead>
    <tr>
      <th>Aspect</th>
      <th>NOT IN</th>
      <th>LEFT ANTI JOIN</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>Performance</strong></td>
      <td>Slower, less optimized</td>
      <td>Faster, better optimized by Spark</td>
    </tr>
    <tr>
      <td><strong>Broadcast Risk</strong></td>
      <td>Can trigger unwanted broadcasts</td>
      <td>Better control, prevents large broadcasts</td>
    </tr>
    <tr>
      <td><strong>Execution Plan</strong></td>
      <td>Subquery execution</td>
      <td>Efficient join strategy</td>
    </tr>
    <tr>
      <td><strong>NULL Handling</strong></td>
      <td>Unpredictable with NULLs</td>
      <td>Predictable behavior</td>
    </tr>
  </tbody>
</table>

<h3 id="bottom-line">Bottom Line</h3>

<p><code class="language-plaintext highlighter-rouge">LEFT ANTI JOIN</code> prevents broadcast errors while delivering the same results faster. When working with large datasets, this optimization can make a substantial difference in query execution time and resource utilization.</p>]]></content><author><name></name></author><category term="工作" /><category term="SQL" /><summary type="html"><![CDATA[When filtering data based on exclusion criteria, the choice between NOT IN and LEFT ANTI JOIN can significantly impact query performance. This post demonstrates why LEFT ANTI JOIN is typically the better choice.]]></summary></entry><entry><title type="html">USA印象22: 德州海钓记</title><link href="https://iphyer.github.io/blog/2025/12/07/Fishing/" rel="alternate" type="text/html" title="USA印象22: 德州海钓记" /><published>2025-12-07T22:54:00+00:00</published><updated>2025-12-07T22:54:00+00:00</updated><id>https://iphyer.github.io/blog/2025/12/07/Fishing</id><content type="html" xml:base="https://iphyer.github.io/blog/2025/12/07/Fishing/"><![CDATA[<p>这个周末去 Corpus Christ, TX 钓鱼，这里记录一下。</p>

<p>&lt; Revised and generated with help of ChatGPT &gt;</p>

<!--more-->

<h2 id="corpus-christ-tx-简介">Corpus Christ, TX 简介</h2>

<p>Corpus Christi 位于德州南部海岸，是一个面向墨西哥湾的港口城市，有“德州海滨城市（Sparkling City by the Sea）”的昵称。城市以绵长的海滩、观鸟地、以及便利的海上活动闻名，也是通往 Padre Island National Seashore 的主要门户。</p>

<p>Corpus Christi 对钓鱼爱好者来说非常友好，最大的特点是 <strong>鱼种丰富、钓点多、全年基本都能钓</strong>。</p>

<h3 id="north-packery-jetty">North Packery Jetty</h3>

<p>当然我这次其实是在 North Packery Jetty 钓鱼的，看下面的地图，这是一片海岸离岛，而 North Packery Jetty 是伸出海岸的一段大堤。</p>

<p>Corpus Christ, TX 离奥斯汀大概四个小时车程。</p>

<p><img src="/images/Fishing/CorpusChristTX_MAP.PNG" alt="Corpus Christ, TX" /></p>

<p>但是钓鱼地点，图上箭头所示，其实在离岛上。</p>

<p><img src="/images/Fishing/NorthPackeryJetty.PNG" alt="North Packery Jetty" /></p>

<p>North Packery Jetty 属于 Packery Channel 的北侧码头/防波堤 — 是当地最受欢迎的公共钓鱼／海滨区之一。North Packery Jetty 是 Corpus Christi 最热门、最容易上手、鱼种最丰富的岸钓点之一。结构是 <strong>岩石防波堤 + 海湾出入口（Packery Channel）</strong>，因此同时具备 <strong>channel 钓点</strong> 和 <strong>jetty/海边钓点</strong> 的优势。</p>

<h4 id="-常见鱼种">🎣 常见鱼种</h4>
<ul>
  <li><strong>Redfish（红鱼）</strong></li>
  <li><strong>Speckled Trout（海鳟）</strong></li>
  <li><strong>Black Drum（黑鼓）</strong></li>
  <li><strong>Sheepshead / Mangrove Snapper（羊头鱼 / 红树林笛鲷）</strong></li>
  <li><strong>Flounder（比目鱼）</strong></li>
  <li><strong>Spanish Mackerel / Kingfish（西班牙鲭 / 王鱼）</strong></li>
  <li><strong>Sharks（小鲨鱼）</strong></li>
  <li><strong>Jacks / Tarpon（季节性）</strong></li>
</ul>

<h4 id="-钓点结构与特点">📍 钓点结构与特点</h4>
<ul>
  <li><strong>Channel 一侧</strong>：水深变化明显，潮汐影响大，红鱼和海鳟常驻。</li>
  <li><strong>Jetty 外海一侧</strong>：适合追逐 baitfish 的鲭鱼、jack、王鱼、小鲨鱼。</li>
  <li><strong>Jetty 尾端</strong>：最容易遇到大鱼，但风浪大时要注意安全。</li>
  <li><strong>附近沙滩（surf zone）</strong>：比目鱼、红鱼、鲨鱼的热点。</li>
</ul>

<h4 id="-最佳钓鱼时间实用版">📅 最佳钓鱼时间（实用版）</h4>
<ul>
  <li><strong>涨潮（Incoming tide）</strong>：
    <ul>
      <li>海鳟、红鱼最活跃</li>
      <li>Channel 侧强烈推荐</li>
    </ul>
  </li>
  <li><strong>退潮（Outgoing tide）</strong>：
    <ul>
      <li>海侧更好</li>
      <li>西班牙鲭、jack、小鲨鱼常追着小鱼冲出来</li>
    </ul>
  </li>
  <li><strong>一天中的时间</strong>：
    <ul>
      <li><strong>清晨（sunrise）</strong>：最稳</li>
      <li><strong>傍晚（sunset 前后）</strong>：活性极高</li>
    </ul>
  </li>
</ul>

<h4 id="-推荐钓法与装备">🪝 推荐钓法与装备</h4>
<p><strong>活饵 / Live Bait：</strong></p>
<ul>
  <li>Shrimp（活虾）+ popping cork</li>
  <li>Mullet（小鲻鱼）</li>
  <li>Cut bait（切饵）适合 drum / shark</li>
</ul>

<p><strong>路亚 / Artificial：</strong></p>
<ul>
  <li>Soft plastics（软饵）适合红鱼/鳟鱼</li>
  <li>Silver spoon（金属亮片）适合鲭鱼、jack</li>
  <li>Topwater（早上很有效）</li>
</ul>

<p><strong>装备建议：</strong></p>
<ul>
  <li>7ft–8ft 中到重型竿</li>
  <li>15–30lb 主线（如果目标是鲭鱼/鲨鱼建议更高）</li>
  <li>防滑鞋（岩石表面滑）</li>
</ul>

<h4 id="️-注意事项">⚠️ 注意事项</h4>
<ul>
  <li><strong>岩石滑、浪大时不要站太外侧</strong></li>
  <li><strong>停车通常需要 Beach Parking Permit</strong></li>
  <li><strong>退潮末期某些区域水流强，注意脚下与站位</strong></li>
  <li><strong>周末人多，抛竿和收线要礼让</strong></li>
</ul>

<h2 id="总体感受">总体感受</h2>

<p>总体来说，这次在海钓还是挺愉快的。下次可以组织起来。</p>

<p>North Packery Jetty 是一条防波堤，所以直接停车后沿着大堤向前走就行。</p>

<p><img src="/images/Fishing/t0.JPG" alt="t0" /></p>

<p><img src="/images/Fishing/t5.JPG" alt="t5" /></p>

<p><img src="/images/Fishing/t1.JPG" alt="t1" /></p>

<p>风景还是挺好的，动物也挺多，还不怎么怕人。</p>

<p><img src="/images/Fishing/t3.JPG" alt="t3" /></p>

<p><img src="/images/Fishing/t4.JPG" alt="t4" /></p>

<p>下竿，开钓！</p>

<p><img src="/images/Fishing/t2.JPG" alt="t2" /></p>

<h3 id="bait">Bait</h3>

<p>海钓还是推荐 Live Bait 路上有很多鱼饵店。比如这家，一般买点活虾就行，我们选了 11 刀 的基础款，基本上正好满足，如果不是特别专业的，只是想娱乐体验下。因为如果整个虾挂上去，很容易被小鱼咬掉一部分而不上钩，所以大部分情况都是把虾切成一段段的挂在鱼钩上。</p>

<h3 id="钓鱼证">钓鱼证</h3>

<p>一般如果只是体验下，推荐买 One Day All Water Permit。</p>

<p>我推荐去 Bass Pro 店里面办理，直接去他们的 Customer Service 办理，现场就可以办理。也可以网上办理，但是不知道为什么网上办理要额外多收 5 刀的手续费。 Bass Pro 估计是希望吸引你来消费，不收取任何手续费，就是直接给钓鱼证的费用。</p>

<p>如果是德州居民需要提供 SSN，驾照，价格大概是 11 刀。如果是父母或者没有德州驾照，可以用护照，但是价格就是非居民价格，贵了 5刀，需要16 刀。</p>

<p>同时对于鱼的尺寸和种类都有要求，我一般都是现场用 ChatGPT 查，然后判断，也可以上网看图识鱼。</p>]]></content><author><name></name></author><category term="生活" /><summary type="html"><![CDATA[这个周末去 Corpus Christ, TX 钓鱼，这里记录一下。]]></summary></entry><entry><title type="html">工作总结 5</title><link href="https://iphyer.github.io/blog/2025/12/05/workingSummary5/" rel="alternate" type="text/html" title="工作总结 5" /><published>2025-12-05T20:54:00+00:00</published><updated>2025-12-05T20:54:00+00:00</updated><id>https://iphyer.github.io/blog/2025/12/05/workingSummary5</id><content type="html" xml:base="https://iphyer.github.io/blog/2025/12/05/workingSummary5/"><![CDATA[<p>最近升职了，工作内容一下子不太一样了。不再是把自己的项目做好就行，更多时候要负责沟通、协调，还得主动发起和带项目。这里简单写下这段时间的一些体会，后面如果有新的想法我再来更新。</p>

<p>[Revised by ChatGPT]</p>

<!--more-->

<h2 id="面对不确定性">面对不确定性</h2>

<p>现在接到的很多项目，往往只有一个“大方向”或最终目标，但中间要怎么做没人告诉你。通常我拿到的只有一句话：某个时间点之前要把项目做到什么状态。至于怎么把坑填满，只能自己不断找上下游聊，试、问、补，慢慢把路径摸出来。</p>

<h2 id="一些小经验">一些小经验</h2>

<h3 id="1-想想接下来三步next-3-steps">1. 想想「接下来三步」(next 3 steps)</h3>

<p>做项目的时候，不能只盯着眼前这一小步，不然很容易走成局部最优，或者后面发现埋了技术债。随时在脑子里模拟一下“如果我现在这样做，下一步、再下一步会发生什么”。当然不要求每次都完美看清，但多想几步真的能少踩坑。</p>

<p>提前想到后面两三步，很多时候能让你提前准备，也让你的当下决策更稳更安心。</p>

<h3 id="2-慢一点把事情做对">2. 慢一点，把事情做对</h3>

<p>升职之后明显感觉：不能再张口就给答案了。很多时候需要先缓一下，想清楚了再说。<br />
“慢一点”其实不是效率变低，而是把质量放在更前面。你需要靠“把事情做对”来建立信任，而不是靠“做得快”。</p>

<h3 id="3-多跟人-sync特别是比你更资深的-sde">3. 多跟人 Sync，特别是比你更资深的 SDE</h3>

<p>要做到“慢下来”，一个很有效的方法就是多跟人聊。<br />
多跟 team 里的同事 sync 一下，尤其是那些更资深的 SDE。聊多了你自然会放慢节奏，很多想法能被快速校正，还能从别人那里听到你没想到的点。</p>

<p>功利一点讲，多跟资深 SDE 合作，也有助于你找到未来升职时能帮你背书的人。</p>

<h2 id="小结">小结</h2>

<p>从“把事情做好”到“把项目带好”，是完全不一样的体验。<br />
想清楚 next 3 steps、适当慢下来提高质量、多向厉害的人请教，这三点对我现在挺重要。</p>

<p>后面如果有新的踩坑经历或者更好的办法，再来更新。</p>]]></content><author><name></name></author><category term="生活" /><category term="工作" /><summary type="html"><![CDATA[最近升职了，工作内容一下子不太一样了。不再是把自己的项目做好就行，更多时候要负责沟通、协调，还得主动发起和带项目。这里简单写下这段时间的一些体会，后面如果有新的想法我再来更新。]]></summary></entry><entry><title type="html">[书评]《Generative AI with Amazon Bedrock》</title><link href="https://iphyer.github.io/blog/2025/09/17/GenAIWithAmaznBedrock/" rel="alternate" type="text/html" title="[书评]《Generative AI with Amazon Bedrock》" /><published>2025-09-17T20:54:00+00:00</published><updated>2025-09-17T20:54:00+00:00</updated><id>https://iphyer.github.io/blog/2025/09/17/GenAIWithAmaznBedrock</id><content type="html" xml:base="https://iphyer.github.io/blog/2025/09/17/GenAIWithAmaznBedrock/"><![CDATA[<p>最近读完了 <em>Generative AI with Amazon Bedrock: Build, scale, and secure generative AI applications using Amazon Bedrock</em>。
在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。</p>

<p>内容由 ChatGPT 生成，大纲是我提供的。</p>

<!--more-->

<p><a href="https://a.co/d/fQSyhOj">👉 书籍链接 (Amazon)</a></p>

<hr />

<h2 id="一句话总结">一句话总结</h2>
<p><strong>不必读，这本书内容已经过时。</strong></p>

<hr />

<h2 id="为什么说过时">为什么说过时？</h2>
<p>这本书很好地体现了“时代的眼泪”——AI 领域出版物面临的最大挑战：<strong>时效性</strong>。
尽管它出版于 <strong>2023 年底</strong>，但短短几个月内就显得落伍，原因包括：</p>

<ul>
  <li>技术迭代过快</li>
  <li>Amazon Bedrock 持续推出新模型和功能，书中部分 API 已经更新</li>
  <li>GenAI 生态系统变化频繁，新的集成方案与最佳实践层出不穷</li>
  <li>社区实践经验丰富，真实案例与通用模式不断涌现</li>
</ul>

<hr />

<h2 id="建议阅读方式">建议阅读方式</h2>
<p>与其读书，不如：</p>

<ul>
  <li><strong>参考 AWS 官方文档</strong> 获取最新信息</li>
  <li><strong>关注 AWS 博客与技术社区</strong> 的动态</li>
  <li><strong>参与线上讨论</strong> 获取实时反馈</li>
</ul>

<hr />

<h2 id="更大的问题">更大的问题</h2>
<p>这不仅是本书的问题，而是整个 <strong>AI 技术书籍领域</strong>的困境。
在快速演进的技术环境下，传统出版模式可能需要改变，例如：</p>

<ul>
  <li>采用 <strong>在线更新</strong> 的形式</li>
  <li>提供 <strong>配套的在线资源</strong></li>
  <li>转向更注重 <strong>原理与设计思路</strong> 的写作方式</li>
</ul>

<hr />

<h2 id="仍有价值的部分">仍有价值的部分</h2>
<ul>
  <li>书中的一些基础概念与设计思路仍具参考意义</li>
  <li>适合 <strong>选择性阅读</strong>，聚焦相对稳定的知识点</li>
</ul>

<hr />

<h2 id="总结">总结</h2>
<p>在 AI 领域，<strong>持续学习与实践远比依赖书籍更重要</strong>。</p>]]></content><author><name></name></author><category term="学习" /><summary type="html"><![CDATA[最近读完了 Generative AI with Amazon Bedrock: Build, scale, and secure generative AI applications using Amazon Bedrock。 在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。]]></summary></entry></feed>