<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Nguyen Le Phong：博客</title>
    <link>https://nguyenlephong.github.io/zh/blog</link>
    <description>关于软件架构、AI 以及软件团队工作方式的文章。</description>
    <language>zh</language>
    <lastBuildDate>Thu, 12 Mar 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://nguyenlephong.github.io/zh/blog/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AI Agent 全解析：它是什么、如何运作、能为你做什么</title>
      <link>https://nguyenlephong.github.io/zh/blog/ai/ai-agents-explained</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/ai/ai-agents-explained</guid>
      <pubDate>Thu, 12 Mar 2026 00:00:00 GMT</pubDate>
      <description>所有人突然都在谈论“AI agent”——一种不只回答问题、而是真正去完成工作的软件。但 agent 究竟是什么？它和你已经在用的 chatbot 有何不同？它真正有帮助的地方在哪里，又在哪里会悄悄制造麻烦？这是一份面向所有人的友好、轻术语指南——无论你是否懂技术：每个 agent 运行的简单循环、构成它的五大要素、从 co-pilot 到 auto-pilot 的自主程度层级、工作与生活中接地气的示例、需要注意的失败模式，以及本周就能让第一个实用 agent 运转起来的具体方法。</description>
      <category>AI 与未来</category>
      <category>AI</category>
      <category>AI Agent</category>
      <category>Agentic AI</category>
      <category>自动化</category>
      <category>未来工作</category>
    </item>
    <item>
      <title>从 Prompt 到 Workflow：设计每周为你省下数小时的 AI Workflow</title>
      <link>https://nguyenlephong.github.io/zh/blog/ai/ai-workflows-that-save-hours</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/ai/ai-workflows-that-save-hours</guid>
      <pubDate>Wed, 11 Mar 2026 00:00:00 GMT</pubDate>
      <description>大多数人每次只用一个问题来使用 AI——也因此把它的大部分价值留在了桌面上。真正的杠杆不是一句巧妙的 prompt，而是一个可重复的 AI workflow：你设计一次、便永远复用的一小串步骤，把每周两小时的重复杂活变成两分钟的审阅。这是一份面向所有人（无论是否懂技术）的实用、案例丰富的指南：prompt 与 workflow 的区别、每个 workflow 都共有的简单结构、可直接照搬到办公室与日常生活的 workflow、从手动到全自动的三个层级、自己动手设计的六个步骤，以及一个用来证明你真正省下多少时间的简易估算法。</description>
      <category>AI 与未来</category>
      <category>AI</category>
      <category>AI Workflow</category>
      <category>自动化</category>
      <category>生产力</category>
      <category>未来工作</category>
    </item>
    <item>
      <title>2026 年真正值得你关注的 AI 趋势——以及如何把它们变成实实在在的价值</title>
      <link>https://nguyenlephong.github.io/zh/blog/ai/ai-trends-2026-into-value</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/ai/ai-trends-2026-into-value</guid>
      <pubDate>Tue, 10 Mar 2026 00:00:00 GMT</pubDate>
      <description>每周都冒出又一个“这将改变一切”的 AI 头条，想从噪音里分辨出信号，实在令人疲惫。这是一趟冷静、有据的导览，带你看清 2026 年真正重要的 AI 趋势——agentic AI、多模态（multimodal）、嵌进你已在用的 app 里的 AI、设备端 AI，以及判断力与核查作为人类优势的崛起——再配上几乎所有文章都略过的部分：一套把任何趋势变成工作与生活中真实价值的实用框架。你会得到一个“炒作还是价值”的过滤器、价值阶梯、一个简单的价值方程、一个具体例子，以及一份 30 天计划——好让你不再追逐新闻，而开始累积复利般的收益。</description>
      <category>AI 与未来</category>
      <category>AI</category>
      <category>AI 趋势</category>
      <category>Agentic AI</category>
      <category>未来工作</category>
      <category>生产力</category>
    </item>
    <item>
      <title>Ports &amp; Adapters（六边形架构），简单讲清楚</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/ports-and-adapters</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/ports-and-adapters</guid>
      <pubDate>Sat, 07 Mar 2026 00:00:00 GMT</pubDate>
      <description>一篇友好、示例驱动的六边形架构指南：ports 和 adapters 到底是什么、让它运转的那条核心规则，以及究竟该用多少——无论你是独立创业者还是企业级团队。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>Hexagonal Architecture</category>
      <category>Ports and Adapters</category>
      <category>Clean Architecture</category>
      <category>系统设计</category>
    </item>
    <item>
      <title>Clean、Onion 与 Hexagonal 架构：同一颗北极星，三个名字</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/clean-vs-onion-vs-hexagonal</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/clean-vs-onion-vs-hexagonal</guid>
      <pubDate>Fri, 06 Mar 2026 00:00:00 GMT</pubDate>
      <description>它们看起来像是三种相互竞争的架构，实则是同一个思想——依赖指向内部，框架置于边缘——用三种方式画出来。本文讲清楚每种方案真正增加了什么，以及应该选哪一个。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>Clean Architecture</category>
      <category>Onion Architecture</category>
      <category>Hexagonal Architecture</category>
      <category>系统设计</category>
    </item>
    <item>
      <title>Dependency Injection 与 Inversion of Control，去掉魔法讲清楚</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/dependency-injection-and-ioc</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/dependency-injection-and-ioc</guid>
      <pubDate>Thu, 05 Mar 2026 00:00:00 GMT</pubDate>
      <description>DI 容器看起来像魔法，直到你看清楚它背后的朴素思想：不要让代码自己创建依赖，而是从外部传进来。一篇从零开始的指南，配上真实示例和测试收益。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>Dependency Injection</category>
      <category>Inversion of Control</category>
      <category>SOLID</category>
      <category>测试</category>
    </item>
    <item>
      <title>代码库结构：按层、按功能，还是按领域？</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/structuring-code-feature-vs-layer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/structuring-code-feature-vs-layer</guid>
      <pubDate>Wed, 04 Mar 2026 00:00:00 GMT</pubDate>
      <description>顶层文件夹应该叫 controllers/services/models，还是 orders/billing/auth？这个选择悄悄地影响代码库的成长方式。一篇关于按层、按功能和尖叫式架构的实用指南——附上各公司规模下的权衡取舍。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>项目结构</category>
      <category>Screaming Architecture</category>
      <category>Modularity</category>
      <category>代码组织</category>
    </item>
    <item>
      <title>单体、模块化单体、微服务：一份诚实的决策指南</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/monolith-to-microservices</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/monolith-to-microservices</guid>
      <pubDate>Tue, 03 Mar 2026 00:00:00 GMT</pubDate>
      <description>微服务是你为组织规模支付的代价——而不是起点。一篇不炒作地从单体到模块化单体再到微服务的完整导览，附上告诉你何时（以及是否）该拆分的信号。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>Microservices</category>
      <category>Modular Monolith</category>
      <category>系统设计</category>
      <category>分布式系统</category>
    </item>
    <item>
      <title>微前端：何时值得，以及它们真正的代价</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/micro-frontends-when-why-and-cost</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/micro-frontends-when-why-and-cost</guid>
      <pubDate>Mon, 02 Mar 2026 00:00:00 GMT</pubDate>
      <description>将前端拆分成独立可部署的模块可以解放团队——也可能把你埋在复杂性中。本文来自在规模化场景下落地 Angular 宿主 + React 模块的实战经验：微前端何时有回报，以及它带来的账单。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>Micro-Frontends</category>
      <category>前端架构</category>
      <category>Module Federation</category>
      <category>可扩展性</category>
    </item>
    <item>
      <title>代码审查的艺术：如何批评代码而不打击人</title>
      <link>https://nguyenlephong.github.io/zh/blog/culture/how-to-review-code-kindly</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/culture/how-to-review-code-kindly</guid>
      <pubDate>Sun, 01 Mar 2026 00:00:00 GMT</pubDate>
      <description>代码审查是团队文化成败的关键所在。这是一份实用指南，教你如何在让代码更好的同时，也让作者越来越强——具体的措辞、审查者清单，以及那些悄悄让审查变成毒药的习惯。</description>
      <category>工程文化</category>
      <category>工程文化</category>
      <category>代码审查</category>
      <category>Pull Requests</category>
      <category>反馈</category>
      <category>团队协作</category>
    </item>
    <item>
      <title>善意工程：为什么善意让你成为更好的工程师</title>
      <link>https://nguyenlephong.github.io/zh/blog/culture/how-to-be-a-kind-engineer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/culture/how-to-be-a-kind-engineer</guid>
      <pubDate>Sat, 28 Feb 2026 00:00:00 GMT</pubDate>
      <description>善意不是温和，也不是软弱，而是力量倍增器——更清晰的反馈、更安全的事故响应、成长更快的队友。“善意工程”真正的含义，以及如何在代码审查、事故处理和日常工作中实践它。</description>
      <category>工程文化</category>
      <category>工程文化</category>
      <category>Kind Engineering</category>
      <category>心理安全</category>
      <category>同理心</category>
      <category>团队协作</category>
    </item>
    <item>
      <title>如何写一个让人真正乐于审查的 Pull Request</title>
      <link>https://nguyenlephong.github.io/zh/blog/culture/how-to-write-a-great-pull-request</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/culture/how-to-write-a-great-pull-request</guid>
      <pubDate>Fri, 27 Feb 2026 00:00:00 GMT</pubDate>
      <description>一个出色的 pull request 是给审查者的礼物：简小、描述清晰、容易说是。可审查 PR 的解剖学——大小、标题、描述、提交卫生和自审——附具体的前后对比示例。</description>
      <category>工程文化</category>
      <category>工程文化</category>
      <category>Pull Requests</category>
      <category>代码审查</category>
      <category>Git</category>
      <category>团队协作</category>
    </item>
    <item>
      <title>有效的反馈：作为工程师给出和接受批评</title>
      <link>https://nguyenlephong.github.io/zh/blog/culture/giving-and-receiving-feedback</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/culture/giving-and-receiving-feedback</guid>
      <pubDate>Wed, 25 Feb 2026 00:00:00 GMT</pubDate>
      <description>大多数工程师从未被教过如何给出反馈——或者如何接受反馈。这是一本关于具体、善意、可操作反馈的实战手册，以及如何在接受批评时保持开放——附即可使用的对话脚本。</description>
      <category>工程文化</category>
      <category>工程文化</category>
      <category>反馈</category>
      <category>沟通</category>
      <category>心理安全</category>
      <category>指导</category>
    </item>
    <item>
      <title>指导工程师：如何把初级工程师培养成资深工程师</title>
      <link>https://nguyenlephong.github.io/zh/blog/culture/mentoring-engineers</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/culture/mentoring-engineers</guid>
      <pubDate>Tue, 24 Feb 2026 00:00:00 GMT</pubDate>
      <description>优秀的团队是培养出来的，不只是招聘来的。来自领导工程团队的实战经验：如何通过结对编程、代码审查、恰当的拉伸任务，以及那些把初级工程师变成你愿意托付一切的人的思维转变，让人快速成长。</description>
      <category>工程文化</category>
      <category>工程文化</category>
      <category>指导</category>
      <category>职业成长</category>
      <category>领导力</category>
      <category>团队协作</category>
    </item>
    <item>
      <title>上下文工程：区分优秀 AI 用户与普通用户的关键技能</title>
      <link>https://nguyenlephong.github.io/zh/blog/ai/context-engineering</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/ai/context-engineering</guid>
      <pubDate>Sun, 22 Feb 2026 00:00:00 GMT</pubDate>
      <description>大多数 AI 结果令人失望，不是因为模型不好，而是因为上下文太薄。上下文工程实用指南——模型窗口中有什么、优质上下文的五大支柱、常见反模式，以及能持续产出更好结果的可复用模板。</description>
      <category>AI 与未来</category>
      <category>AI</category>
      <category>上下文工程</category>
      <category>提示词工程</category>
      <category>LLM</category>
      <category>开发者生产力</category>
    </item>
    <item>
      <title>分层架构与 Vertical Slice Architecture</title>
      <link>https://nguyenlephong.github.io/zh/blog/architecture/layered-vs-vertical-slice-architecture</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/architecture/layered-vs-vertical-slice-architecture</guid>
      <pubDate>Wed, 11 Feb 2026 00:00:00 GMT</pubDate>
      <description>分层架构在一开始很整洁，Vertical Slice 则把变化放回真实功能附近。本文平静地比较两者的价值、代价，以及团队何时该调整结构。</description>
      <category>源码与架构</category>
      <category>软件架构</category>
      <category>Vertical Slice Architecture</category>
      <category>Layered Architecture</category>
      <category>代码组织</category>
      <category>Modularity</category>
    </item>
    <item>
      <title>健康的 1-on-1 长什么样</title>
      <link>https://nguyenlephong.github.io/zh/blog/culture/anatomy-of-a-healthy-one-on-one</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/culture/anatomy-of-a-healthy-one-on-one</guid>
      <pubDate>Sun, 08 Feb 2026 00:00:00 GMT</pubDate>
      <description>健康的 1-on-1 不是语气更柔和的 status meeting，而是一个稳定的小空间，用来处理 context、信任、feedback 和职业方向。</description>
      <category>工程文化</category>
      <category>工程文化</category>
      <category>One-on-One</category>
      <category>Management</category>
      <category>Feedback</category>
      <category>Leadership</category>
    </item>
    <item>
      <title>Prompt Engineering 本质上只是清晰沟通</title>
      <link>https://nguyenlephong.github.io/zh/blog/ai/prompt-engineering-is-just-communication</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/ai/prompt-engineering-is-just-communication</guid>
      <pubDate>Sat, 07 Feb 2026 00:00:00 GMT</pubDate>
      <description>好的 prompt 不是魔法句子，而是清楚地提供 context、意图、constraints、examples 和 feedback。</description>
      <category>AI 与未来</category>
      <category>AI</category>
      <category>Prompt Engineering</category>
      <category>沟通</category>
      <category>LLM</category>
      <category>AI Literacy</category>
    </item>
    <item>
      <title>开发者如何学习说不</title>
      <link>https://nguyenlephong.github.io/zh/blog/perspectives/learning-to-say-no-as-a-developer</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/perspectives/learning-to-say-no-as-a-developer</guid>
      <pubDate>Fri, 06 Feb 2026 00:00:00 GMT</pubDate>
      <description>说不不是难相处，而是为了保护 focus、quality 和 trust，把 tradeoff 讲清楚。</description>
      <category>Perspectives &amp; Field Notes</category>
      <category>Personal Growth</category>
      <category>Software Engineering</category>
      <category>边界</category>
      <category>Career Growth</category>
      <category>沟通</category>
    </item>
    <item>
      <title>Daily standup：status report 还是今天的 strategy？</title>
      <link>https://nguyenlephong.github.io/zh/blog/ways-of-working/daily-standup-status-report-or-strategy</link>
      <guid isPermaLink="true">https://nguyenlephong.github.io/zh/blog/ways-of-working/daily-standup-status-report-or-strategy</guid>
      <pubDate>Thu, 05 Feb 2026 00:00:00 GMT</pubDate>
      <description>Daily standup 可以变成汇报昨天的仪式，也可以成为关于 flow、risk 和今日注意力的短策略会。</description>
      <category>Ways of Working</category>
      <category>Agile</category>
      <category>Daily Standup</category>
      <category>Scrum</category>
      <category>Team Collaboration</category>
      <category>Delivery</category>
    </item>
  </channel>
</rss>
