之前的 RIF 我写了个总结，但是因为各种事情，我拖到今天才开始写。也不太想改动当时写的东西——虽然写得非常潦草，但确实是当时的感受，还是留着。Retro of RIF

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

1. 居安思危 — 刷题不能停

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

重点方向：

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

2. 每天提交 CR

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

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

3. 加强沟通，多参与跨团队工作

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

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

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

4. 早起早睡，提高 Visibility

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

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

5. 必须有 AI / LLM Project

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

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

6. 理解 Big Picture

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

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

遇到问题，多问一句：“这是为什么？”

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

7. 安全思路优先

就像驾驶一样——安全驾驶，不冒险。

现在做的是 Payment System，安全是重中之重。在多种技术方案并存时，优先选择更稳健、更安全的路径，而不是追求激进或炫技的方案。

最近读完了 硅谷Python工程师面试指南：数据结构、算法与系统设计。 在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。

内容由 ChatGPT 生成，大纲是我提供的。

👉 书籍链接 (Douban)

一句话总结

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

为什么选材不错

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

制作粗糙

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

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

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

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

系统设计

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

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

总结

非常不推荐，帮助不大。

深刻反思下 RIF，现在还在 wrap up，但是这里先总结下。

居安思危 – “思危、思退、思变”

别人提醒，要时刻反思，居安思危。

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

如果东西有可能出错，就多检查一遍，多打印备份。

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

不要怕备份！

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

不要怕检查，当面检查，交割清楚！

面试时，自信 + relax + 思考后，慢慢说 like Lucas

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

感觉我就是需要联系这种能力，很多时候，你需要慢下来仔细思考才行。

父母最近来美国,已经有 5 年没见过爸妈了。五年时间,不知不觉间父母的鬓角又添了几缕白发，妈妈的腰也弯得厉害。

机票选择

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

机场 WiFi 连接

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

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

准备美元零钱

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

• 五张 $2 的纸币
• 两张 $5 的纸币
• 一张 $10 或 $20 的纸币

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

Gate Pass 服务

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

有了 Gate Pass,你就可以陪同父母通过安检,一直送到登机口。对于不熟悉全英文环境的父母来说,能有人陪伴到最后一刻,会让他们更加安心,你也更加放心。

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.

< Revised and generated with help of Claude >

Original Approach (Inefficient)

SELECT product_id, product_category
FROM products_dim
WHERE region_id = 100
    AND product_id NOT IN (
        SELECT product_id
        FROM products_dim
        WHERE region_id = 200
    )
    AND product_category IS NOT NULL

Optimized Approach (Recommended)

SELECT a.product_id, a.product_category
FROM products_dim a
LEFT ANTI JOIN (
    SELECT DISTINCT product_id
    FROM products_dim
    WHERE region_id = 200
) b ON a.product_id = b.product_id
WHERE a.region_id = 100
    AND a.product_category IS NOT NULL

Why This Works

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

Key Differences

Bottom Line

LEFT ANTI JOIN 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.

这个周末去 Corpus Christ, TX 钓鱼，这里记录一下。

< Revised and generated with help of ChatGPT >

Corpus Christ, TX 简介

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

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

North Packery Jetty

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

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

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

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

🎣 常见鱼种

• Redfish（红鱼）
• Speckled Trout（海鳟）
• Black Drum（黑鼓）
• Sheepshead / Mangrove Snapper（羊头鱼 / 红树林笛鲷）
• Flounder（比目鱼）
• Spanish Mackerel / Kingfish（西班牙鲭 / 王鱼）
• Sharks（小鲨鱼）
• Jacks / Tarpon（季节性）

📍 钓点结构与特点

• Channel 一侧：水深变化明显，潮汐影响大，红鱼和海鳟常驻。
• Jetty 外海一侧：适合追逐 baitfish 的鲭鱼、jack、王鱼、小鲨鱼。
• Jetty 尾端：最容易遇到大鱼，但风浪大时要注意安全。
• 附近沙滩（surf zone）：比目鱼、红鱼、鲨鱼的热点。

📅 最佳钓鱼时间（实用版）

• 涨潮（Incoming tide）：
  • 海鳟、红鱼最活跃
  • Channel 侧强烈推荐
• 退潮（Outgoing tide）：
  • 海侧更好
  • 西班牙鲭、jack、小鲨鱼常追着小鱼冲出来
• 一天中的时间：
  • 清晨（sunrise）：最稳
  • 傍晚（sunset 前后）：活性极高

🪝 推荐钓法与装备

活饵 / Live Bait：

• Shrimp（活虾）+ popping cork
• Mullet（小鲻鱼）
• Cut bait（切饵）适合 drum / shark

路亚 / Artificial：

• Soft plastics（软饵）适合红鱼/鳟鱼
• Silver spoon（金属亮片）适合鲭鱼、jack
• Topwater（早上很有效）

装备建议：

• 7ft–8ft 中到重型竿
• 15–30lb 主线（如果目标是鲭鱼/鲨鱼建议更高）
• 防滑鞋（岩石表面滑）

⚠️ 注意事项

• 岩石滑、浪大时不要站太外侧
• 停车通常需要 Beach Parking Permit
• 退潮末期某些区域水流强，注意脚下与站位
• 周末人多，抛竿和收线要礼让

总体感受

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

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

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

下竿，开钓！

Bait

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

钓鱼证

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

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

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

同时对于鱼的尺寸和种类都有要求，我一般都是现场用 ChatGPT 查，然后判断，也可以上网看图识鱼。

最近升职了，工作内容一下子不太一样了。不再是把自己的项目做好就行，更多时候要负责沟通、协调，还得主动发起和带项目。这里简单写下这段时间的一些体会，后面如果有新的想法我再来更新。

[Revised by ChatGPT]

面对不确定性

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

一些小经验

1. 想想「接下来三步」(next 3 steps)

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

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

2. 慢一点，把事情做对

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

3. 多跟人 Sync，特别是比你更资深的 SDE

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

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

小结

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

后面如果有新的踩坑经历或者更好的办法，再来更新。

最近读完了 Generative AI with Amazon Bedrock: Build, scale, and secure generative AI applications using Amazon Bedrock。 在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。

内容由 ChatGPT 生成，大纲是我提供的。

👉 书籍链接 (Amazon)

一句话总结

不必读，这本书内容已经过时。

为什么说过时？

这本书很好地体现了“时代的眼泪”——AI 领域出版物面临的最大挑战：时效性。 尽管它出版于 2023 年底，但短短几个月内就显得落伍，原因包括：

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

建议阅读方式

与其读书，不如：

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

更大的问题

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

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

仍有价值的部分

• 书中的一些基础概念与设计思路仍具参考意义
• 适合 选择性阅读，聚焦相对稳定的知识点

总结

在 AI 领域，持续学习与实践远比依赖书籍更重要。

2025.08.08 是个值得纪念的大日子，基于此，这里更新下自己的 2025 计划 2024总结 并 2025规划。

New 2025 计划

这里重新列举下自己的2024计划。

Major tasks:

• [ Done ] Write 2 good Designs
• [ Done ] L5
• [ Done ] bb
• [ ] Give GenAI Demo Speech
• [ ] Apply LLM to current project, sync with Edwin/Wtao/Alg/JamesG 2~3 hours per week
• [ ] Work on 2 GenAI / ML paper
  • Gait Speed
  • GenAI for Grocery
• [ ] Keep improving L5 SDE and figure out L6 AS

Accumulating tasks:

• [ ] Wegiths: 190, target 170
• [ ] LeetCode: 613 – > 622, target 1000
• [ ] Reviewer: 137 – > 183
• [ ] CR #: target top 3 in team

很简短的一个博客，推荐下这本书《大规模语言模型：从理论到实践》.

最近读完了这本书，在豆瓣已经必须实名才能记录自己阅读的现在，还是用博客写书评吧。

这本书最好的一点就是有网络版，https://intro-llm.github.io/

事实上，我最先看的是去年的第一版，前几天搜了搜发现更新了第二版，而且作者提供了基于 GitHub 的 Issues 提交页面。

在大预言模型日新月异的现在，基本上，你今天掌握的具体的一些知识点过了六个月可能就过期了，这本书不断更新才是正确的方法。

回过头来说这本书，我觉得是中文领域少有的比较正规的大预言模型学习资料。正规的意思是这本书会按照特定的章法循序渐进地全面介绍一个领域，而不是过于看重细节，防止只见树叶不见泰山的问题。

这本书我推荐大家跳着读，读的时候先想一想如果你自己来写，你会介绍什么。对照着阅读就会发现自己没想道的知识点。不过没必要沮丧，这是完全正常的，学些下就行。

2024 年就这么匆匆的过去，心中感慨万千，这里总结下自己的 2024，规划下 2025 的计划。

这里先写下这个总结，后面我再补充调整。

不停写博客的好处就是，如果你去翻看去年的这个总结，其实开头是一样的，只是改了年份，年年岁岁花相似，岁岁年年人不同。

对照年初计划总结

直接从年初计划 2023总结 并 2024规划 和 2024Q1 总结 那拷贝下任务列表，

Major tasks:

• [ X ] O1
• [ X ] N*W
• [ RFE ] E*A
• [ Done & Project Changed ] Write 2 good Designs, ML4PO
• [ NS ] H*B
• [ Leading Discission WIP ] LLM Reading Group
• [ X ] LLM Hachathon Organizer
• [ WIP ] Write 2 good Designs
• [ WIP ] bb?
• [ X ] SFH
• [ ] L5
• [ ] Give Brown Bag Speech
• [ ] LLM & AI Video up
• [ ] Learning FastAI Courses for AS
• [ ] Apply LLM to current project, sync with Edwin/Wtao/Alg/JamesG 2~3 hours per week

Accumulating tasks:

• [ ] Wegiths: bad
• [ ] Fat Percentage: bad
• [ ] Basal Metabolic Rate(BMR): bad
• [ ] Reviewer: 83 – > 137
• [ ] LeetCode: 613 – > 613
• [ ] LLM Open Source Projects: N/A
• [ ] CR # – > 121

总结

• 健身和体重控制
• Leetcode 中断
• 读论文很多，但是没有总结成文或者视频。这样理解不深刻，也不利于传播和提高自己。

新的 2025 计划

这里重新列举下自己的2024计划。

Major tasks:

• [ WIP ] Write 2 good Designs
• [ WIP ] L5
• [ WIP ] bb
• [ ] Give Brown Bag Speech
• [ ] LLM & AI Video up
• [ ] Apply LLM to current project, sync with Edwin/Wtao/Alg/JamesG 2~3 hours per week

Accumulating tasks:

• [ ] Wegiths: target: 200
• [ ] LeetCode: 613 target 1000
• [ ] Reviewer: 137
• [ ] CR # 121

推荐一个网站，感觉非常有用。

CS 自学 – HackWay

HackWay 非常好的自学网站，主要参考了美国的 6 大名校的课程。

说实话，如果不是为了一个 CS 的学位，很多普通大学的课程即使是任课老师也没有这些课程的授课水平，非常推荐大家按照推荐去学习。

当然，这个是文火出慢工，如果面临面试，Leetcode 这些才是你的选择，毕竟 coding 题要是遇到原题，还是非常加分的，这个比较直接，立竿见影。

最近总结写作的风格问题，发现了一点启示，写一篇博客记录一下。

In today’s fast-paced world, effective communication is crucial. To captivate your audience and convey your message with impact, follow these three essential steps:

• Start with your main argument or key message
• Use assertive topic sentences to strengthen each paragraph
• Provide clear, actionable recommendations for specific audiences

1. Cut to the Chase

Time is precious, and your readers’ attention spans are limited. Eliminate unnecessary preambles and dive straight into your main point. By doing so, you’ll:

• Grab attention immediately
• Respect your audience’s time
• Increase the likelihood of your message being read and understood

Writers should ruthlessly edit their introductions, removing any fluff or filler content.

2. Make Bold Claims, Not Bland Descriptions

Transform your writing from passive to powerful by replacing descriptive sentences with assertive topic sentences. This approach will:

• Strengthen your arguments
• Engage readers more effectively
• Establish your authority on the subject

Editors should review each paragraph, ensuring it begins with a clear, declarative statement that drives the narrative forward.

3. Assign Clear Actions

Don’t leave your readers wondering “So what?” Clearly state who should do what based on the information you’ve provided. This strategy:

• Provides practical value to your audience
• Increases the likelihood of reader engagement and action
• Solidifies your role as a thought leader

Content creators must conclude each section or article with specific, actionable recommendations tailored to their target audience.

By implementing these three steps, writers can transform their content from ordinary to extraordinary, ensuring their message not only reaches but resonates with their intended audience.

工作中经常要用 AWS，有些时候虽然云带来了生产力的解放，但是还是有很多特属于 AWS 的小知识点，这个帖子记录下来。如果有新的体会我也会不断总结到这个帖子。

IAM role 是否设置正确

为了安全，AWS 所有的操作都需要相对的权限，当然这个错误比较好 debug，一般都会报错，XX 账号/ IAM Role 没有操作某某的权限。

mwinit 验证

这个有时候会忘记。

region 设置, us-west OR us-east OR etc.

AWS 为了服务的快捷性和安全性，是分区域的，所有有的时候会出现你没设置对区域从而找不到对应的服务和设备。这个是不太容易 debug 的，因为从 code 角度你设置的是对的，代码也编译了，只是不在同一个 region。

Brazil Workspace 清空

有时候，代码编译突然通不过了，或者出了很多奇奇怪怪的错误，但是你们组的别的组员都没有问题，那就很有可能是 workspace 出了问题。这个时候清空 workspace 是最好的选择，从头开始，往往很多问题也就解决了。

To Be Added

To Be Added

To Be Added

最近刚刚搬家，总结下。基本每次搬家都会总结下，既方便自己查找，也方便大家参考。

• 搬家记录1：麦迪逊搬家地址更新总结
• 搬家记录2
• 搬家记录3: Year2021
• 搬家记录4: Year2022 From Madison to Austin

ToDo List

其实搬家最重要的就是需要记得所有全部需要做的事情的 List，这里总结下我的，基本都是自己确认过有效且有用的。

1. 美国移民局
   • OPT Service Portal From USCIS
   • AR-11
   • Report to UW-Madison ISS using ISS website
2. Company Personal Info
   • PeopleProtal Updates Mail and Home addresses and below updates automatically, e.g. Address changes will be sent to benefits and Payroll within 48 hours of saving the change in PeoplePortal
   • Tax
   • 401k
   • Stock Options
     • Fidelity
     • Morgan Stanley
   • Med Insurance
     • General
     • Dental
     • Vision
3. Car Insurance
   • Address Updates
   • Re-quote
4. DMV
   • adding mailing address
5. Txtag
6. UW-Madison Info
   • Student Center Profile, You will lose access to the MyUW Portal 24 months after your appointment end date, https://kb.wisc.edu/helpdesk/page.php?id=6856&redirect=1
7. Banks Address Update, using Credit Cards to remind yourself
   • Citi
   • Amex
   • Chase
   • Discover
8. Airline
   • UA
9. Costco
10. Set up new utility and autopay
11. USPS Forward Request
12. Closing utility Service
    • internet：return Spectrum equipment
    • water: Apartment takes care
    • electricity: City of Austin Utilities: Stop service request
    • rental insurance: eRenterplan Website
    • etc.
13. Returning Keys

昨天车忽然打不着火了，虽然灯都是正常但是无法打着火，显示灯一片混乱，如下图所示，

还好上网搜索下了，有人和我一模一样的问题，

这里写个博客简单记录下，也提醒自己，汽车电池都是易耗品，一般 3 ～ 4 年就需要更换，我的电池已经用了 5 年了，其实 it did a good job。

不过，修车的时候也再次体会到为什么美国人民都讨厌 dealer。卖给我电池的 dealer 说电池保修 8 年，所以价格贵我也认了。结果去了之后发现他们是前 36 个月 Warranty 是 100% coverage，后面每 6 个月就会有不同比例的缩减 coverage，直到 8 年归零。

真是让人无语。。。

他说的也没错，确实是 8 年 Warranty，不过是这个 Warranty，和一般人的理解都不一样。

当然，也是我 Naive 了，还是要回到基本的物理原理，电池一般只能用 3 ～ 4 年, 这个 8 年 Warranty，他敢说，物理也不保真啊！

最近在忙一个 project ，因为时间比较紧张，所以自己就比较着急反而花了更多时间。今天这个项目大概已经可以收尾了，自己也知道为什么当时 bug 没解决。这里总结下。

Bug 总结

这个 bug 其实是由两个错误设置导致的。我在本地有两个代码分支，每个分支都需要运行四到五个子程序。每个分支还需要两个配套文件，但这两个文件会因为一个数据源的更改而有所不同。结果是，每个分支各自出现了一些错误，导致一个分支成功，而另一个分支失败。

我最初看到的是一个分支成功了，所以误以为数据源没有问题并且已经更新成功了。其实，那个分支之所以成功，是因为它还在使用旧的数据源，而我没有更新它。另一个失败的分支是因为我更改了数据源，而新的数据源没有更新，所以失败了。但是在调试过程中，我一直认为我的数据源已经更新了，因为我不理解为什么另一个分支成功了。

最后，我将数据直接推送到 beta 环境。这时，我确认数据源没有问题，并发现本地失败的分支反而成功了，因为它需要的新数据源已经存在。而本地成功的分支却出现了问题，因为它还在使用旧的数据源。我在检查配置时才发现这个问题。

经验总结

1. 第一性原理

在解决问题时，特别是在调试过程中，不要只头疼医头，脚疼医脚。尤其是当你发现这是一个复杂的调试问题时，更应如此。有时候，简单的 bug 可以通过直接查看错误迅速定位，但对于复杂的调试，一定要保持清醒，假设每一个步骤都有可能出错。即使是成功的部分，也要考虑是否是由于某种巧合而成功，是否存在误打误撞的情况。

2. Local 环境第一问题是数据

通常，local 环境的数据是从 prod 环境复制过来的。然而，S3 Sync 的特性是不会删除已存在的文件，因此，如果多次复制数据，可能会出现同一文件的多份副本。所以，在调试之前，先确认数据的正确性。

3. 如果可以，进行 Shadow Run 还是直接推送到正式环境。有时 local 环境会出现问题，主要是因为配置和数据不同。prod 环境的 shadow run 不会产生 sev-2 的问题。

4. 即使时间紧张，Debug 也不能跳过步骤。按照步骤一步一步来，才是最稳妥的解决方案。这是 debug 是出现了问题，这个时候追求效率反而不是最有效率的。

Natural language interfaces to databases are gaining traction as a way to make data access more intuitive. Text-to-SQL systems aim to automatically translate natural language questions into executable SQL queries. This could allow non-technical users to query databases through conversational interfaces.

However, generating semantically accurate SQL from free-form questions remains challenging. Traditional NLP models struggle to fully understand questions and produce valid SQL code. But the rise of large language models (LLMs) like GPT-3 is changing the landscape. Their few-shot learning capacity shows promise on Text-to-SQL tasks.

Still, LLMs need careful prompt engineering to excel at this specialized domain. As evidenced by results on the Spider benchmark, they lag behind finely tuned models on complex queries. So work is needed to tailor prompting strategies based on query complexity. The DIN-SQL system does this with a decomposed prompt design and achieves state-of-the-art 85.3% execution accuracy on Spider.

Another issue is verifying the accuracy of generated SQL. For language tasks, we care about semantic correctness. But for Text-to-SQL, the SQL must execute and return the expected result set. So additional logic is required to check query accuracy, not just rely on the LLM.

Most research uses open datasets like Spider for development. But performance on real-world business datasets with larger, more complex schemas remains relatively underexplored. Spider queries also tend to use simpler vocabulary than users might. So further work is needed to handle business domains.

Nonetheless, LLMs’ few-shot learning capacity makes them a tantalizing option for Text-to-SQL moving forward. With customized prompting strategies and accuracy verification, they could soon offer conversational SQL querying out-of-the-box. That would greatly expand access to data analytics for non-technical users. The future is bright for natural language interfaces to databases powered by LLMs!