Home

Learning to Build Agentic Apps with Azure AI Foundry

Building agentic applications with Azure AI Foundry can feel like stepping into a new world for a solution architect. The promise is huge, an entire ecosystem for creating, deploying, and managing AI agents at enterprise scale, but it requires rethinking how we design architectures, plan adoption, and integrate security and governance. Coming from a background of traditional solution design, I quickly realized that approaching this space with the right framework makes all the difference.

I began with Microsoft’s Cloud Adoption Framework, which breaks down the journey into familiar stages. Defining the strategy helped me clarify why the business wanted to adopt agentic AI in the first place and what value we expected. Planning translated those motivations into actionable steps, and preparing the environment with Azure landing zones gave me confidence that the foundations were solid. Adoption meant actually building and deploying workloads, and the final piece, securing them, was a reminder that AI systems must follow the same rigorous governance standards as any enterprise platform.

The next learning curve was understanding AI landing zones. These act as the enterprise-scale foundation for AI adoption and can be deployed with or without a broader platform landing zone. With a platform landing zone, services like networking and identity are centralized, offering scalability and compliance. Without one, you can start faster, but consistency suffers. As I came to see it, landing zones are the equivalent of a data center for AI agents, and they form the baseline that everything else plugs into.

Once the infrastructure was clear, I had to choose how to actually build agents. Azure AI Foundry makes it possible to experiment in multiple ways: low code or no code tools for fast prototyping, and pro code environments with VS Code extensions, REST APIs, or Semantic Kernel SDKs for full customization. At first I leaned on low code tools to get hands-on experience, then gradually moved into pro code scenarios as integration needs and complexity grew. The key lesson was to start simple and deepen over time, carefully selecting models and balancing cost versus performance while deciding which tools the agent should integrate with, such as Azure AI Search, Bing grounding, or Logic Apps.

Another critical design decision was whether to rely on single agents or adopt multi-agent systems. Single agents are predictable and easier to debug, making them a good starting point. Multi-agent setups, however, shine in dynamic or decomposable workloads where specialized agents collaborate, such as combining HR, IT, and compliance agents for employee onboarding. Semantic Kernel provides the orchestration layer for this coordination, allowing workflows to scale as complexity grows. The approach that worked for me was to start with single agents and only move to multi-agent orchestration once the use cases demanded it.

One of the biggest mindset shifts was recognizing that observability and evaluation are not optional. Unlike traditional apps where metrics are straightforward, agents can feel like black boxes unless you design for visibility. Azure AI Foundry’s traceability features log tool calls and agent interactions, while its evaluation metrics check groundedness, fluency, and relevance. Combined with AI safety tooling, these capabilities help ensure outputs remain safe, reliable, and aligned with organizational goals. For me, it was the equivalent of application performance monitoring in conventional systems: without visibility, improvement is impossible.

Of course, none of this matters if the system isn’t secure. Foundry layers governance and security controls across the stack. Managed identities and login protect users, while prompt and content filters ensure responsible AI practices. Virtual networks, NSGs, and VPN gateways provide network security, and Defender for Cloud adds threat protection. Purview further enhances data governance and compliance. I realized that while agents may feel like futuristic AI entities, architecturally they must be treated as microservices that adhere to the same enterprise-grade security principles as any other system.

Looking back on my early steps with Azure AI Foundry, several lessons stand out. Choose your building approach based on the maturity of your use case, whether no code, low code, or pro code. Pick models and tools carefully, weighing cost against performance. Start small with single agents, and scale into multi-agent orchestration when the complexity justifies it. Bake in observability, evaluation, and responsible AI practices from day one. And finally, leverage AI landing zones for enterprise-ready deployments that bring security, scalability, and governance to the forefront.

For me as a solution architect, Azure AI Foundry has become more than just a platform for deploying language models. It is a bridge between experimentation and enterprise readiness, providing the frameworks, tools, and safeguards needed to build agentic applications responsibly. The journey can feel daunting at first, but with a structured approach and focus on architectural principles, agentic AI quickly becomes less of a mystery and more of the next natural step in modern system design.

學習使用 Azure AI Foundry 建構 Agentic 應用程式

對一位解決方案架構師來說，使用 Azure AI Foundry 來建構 agentic 應用程式，就像踏入一個全新的世界。這是一個龐大的承諾——一整套可用於建立、部署與管理 AI 代理的生態系統，能在企業規模下運作，但同時也需要我們重新思考如何設計架構、規劃採用方式，以及整合安全與治理。來自傳統解決方案設計背景的我，很快就發現，用正確的框架來面對這個領域會帶來完全不同的效果。

我從微軟的雲端採用框架開始，它將這段旅程拆解為熟悉的階段。首先是定義策略，幫助我釐清企業為何要導入 agentic AI，以及我們期望獲得的價值。接著是規劃，將這些動機轉化為可執行的步驟；準備環境則是利用 Azure 登陸區，讓我對基礎建設有了信心。當進入採用階段時，代表真正開始建構與部署工作負載；最後的安全階段提醒我，AI 系統必須遵循與任何企業平台相同的嚴格治理標準。

接下來的學習曲線是理解 AI 登陸區。它們是 AI 採用在企業規模下的基礎，可以選擇有或沒有更廣泛的平台登陸區來部署。有了平台登陸區，像是網路與身分服務會集中化，能帶來可擴展性與合規性；沒有的話，雖然能更快開始，但一致性會受到影響。對我而言，登陸區就像是 AI 代理的資料中心，成為其他一切元件的基礎。

當基礎設施清楚之後，我需要決定實際如何建構代理。Azure AI Foundry 提供了多種嘗試方式：低程式碼或免程式碼工具可以快速原型設計，而專業程式碼環境則透過 VS Code 擴充套件、REST API 或 Semantic Kernel SDK 提供完全自訂的能力。一開始我依靠低程式碼工具來獲得實作經驗，隨著整合需求和複雜度提升，逐漸轉向專業程式碼的場景。最重要的教訓是從簡單開始，隨時間加深，並謹慎挑選模型、在成本與效能之間取得平衡，同時決定代理需要整合的工具，例如 Azure AI Search、Bing grounding 或 Logic Apps。

另一個關鍵的設計抉擇是要依賴單一代理，還是採用多代理系統。單一代理可預測且容易除錯，是很好的起點。然而在動態或可分解的工作負載中，多代理更能發揮優勢，不同專業的代理可以協作，例如在人員入職過程中結合 HR、IT 與合規代理。Semantic Kernel 提供了這種協作所需的協調層，讓工作流程能隨著複雜度增加而擴展。對我來說，最有效的方法是先從單一代理開始，只有在需求出現時才轉向多代理協調。

其中一個最大的思維轉變，是意識到可觀測性與評估並非選項，而是必須。不同於傳統應用程式的指標相對直觀，若沒有設計可視性，代理就像黑盒子。Azure AI Foundry 的追蹤功能能記錄工具呼叫與代理互動，其評估指標則檢查回應的依據性、流暢度與相關性。結合 AI 安全工具，這些能力能確保輸出安全、可靠，並符合組織目標。對我來說，這就像傳統系統的應用程式效能監控：缺乏可見性，就不可能改善。

當然，如果系統不安全，其他一切都沒有意義。Foundry 在整個堆疊中加入治理與安全控制。受控身分與登入保護使用者，提示與內容篩選確保負責任的 AI 實踐。虛擬網路、NSG 與 VPN 閘道提供網路安全，而 Defender for Cloud 則新增威脅防護。Purview 進一步強化資料治理與合規性。我意識到，雖然代理看似未來感十足的 AI 實體，但在架構上，它們必須被視為微服務，遵循任何其他企業系統相同的安全原則。

回顧我在 Azure AI Foundry 的早期探索，有幾個教訓特別清晰。根據使用案例的成熟度來選擇建構方式，無論是免程式碼、低程式碼，或專業程式碼。謹慎挑選模型與工具，仔細衡量成本與效能。從小規模的單一代理開始，當複雜度增加時再擴展到多代理協調。從第一天起就將可觀測性、評估與負責任 AI 實踐納入基礎。最後，善用 AI 登陸區來進行企業級部署，確保安全性、可擴展性與治理。

對我而言，Azure AI Foundry 已不僅僅是部署語言模型的平台，而是連結實驗與企業就緒之間的橋樑。它提供了必要的框架、工具與防護措施，讓我們能以負責任的方式建構 agentic 應用程式。這段旅程起初可能令人望而生畏，但只要採用有結構的方法並專注於架構原則，agentic AI 很快就不再神祕，而是邁向現代系統設計的下一個自然步驟。

How to Develop Breakthrough Core Banking Products and Services

Banks must develop major innovations to prosper, but they don’t know how to. Many still try to build them with an old producer model. In that model, vendors publish roadmaps, banks write long requirement documents, and system integrators deliver projects after months of work. Academic research and field practice point to a different path. Important innovation often come from users. These users share and improve ideas in communities. Breakthroughs scale when a platform gives them simple tools that turn designs into live products without friction. In banking, many “new” services begin as user workarounds before they become official. The next growth line is often being tested by customers and frontline teams already.

Core-banking innovation should shift from vendor-led requirements to bank- and user-led creation. The shift rests on three building blocks. First, find lead users whose needs are ahead of the market. Second, build communities so good solutions spread and improve. Third, embed toolkits inside the core banking platform so teams can design, test, and ship safely. Done well, idea to launch time drops from months to days, while first time right releases increase.

Lead users feel the pain first and have strong reasons to solve it. In core banking, these may be cross border SMEs juggling FX and instant refunds, collections teams that live in exception queues, and treasury teams reconciling real time flows. Sitting with these users reveals spreadsheets, excel macros, and policy rules that already express the product logic the bank will need. Treat these artifacts as a map of the real solution space. Rates, tiers, holiday calendars, schedules, tolerance windows, dispute timers, and end of day modes become a shared vocabulary for product design.

Communities turn isolated fixes into reusable patterns. Instead of long documents passed between teams, share recipes that others can copy and adapt. A clear path for dormancy and reactivation with notices, timers, and fee reversal rules. An instant refund path that handles partial reversals and time limits. An end of day mode with guardrails for delayed posting. In practice, once a strong recipe lands, local variants appear quickly across markets, and duplication drops.

Toolkits make the shift repeatable. Start with a user friendly product language and libraries. Teams configures rates, tiers, holiday calendars, schedules, posting order, and dispute timers in one place. Add a simulation ledger that replays real events from the past and compares balances, fees, and accounting between a baseline product and a new variant. Finish with one click translation from the product language to production artifacts, with strict checks on schemas, limits, liquidity, and audit. This turns intent into predictable behavior and gives risk and finance evidence they trust.

Governance becomes stronger by moving controls earlier and automating them. The core banking platform enforces accounting balance, limits, liquidity buffers, and rule checks at run time. The simulation verifies business results on real traffic before release. The pipeline signs and versions every change and links it to approvals and tests. Separation of duties is the default. Developers propose configurations, risk and finance approve, platform teams deploy, and a successful simulation replay is a hard gate. Controls run early and often with clear artifacts, which reduces surprises late in the process.

Measurement keeps the system honest. Track time to ledger from approved idea to ready configuration. Track iterations per week to show learning speed. Track first time right rate to capture clean releases without rollback. Track accounting differences between baseline and variant on real traffic. Add engineering signals such as build success rate and change failure rate. When these indicators improve together, the shift is working.

This paradigm shift changes the operating model. Less time goes into static product specifications. More effort goes into shaping the solution space, sharing patterns, and enforcing guardrails in code. The core banking becomes a programmable platform. The bank becomes a learning community that improves by building and testing, not by office politics. Once interest logic, holiday calendars, and other core behaviors are modular, and once the simulation catches edge cases before regulators do, teams stop fearing product change. That confidence is the real unlock. It turns innovation into steady, reliable breakthroughs driven by users and scaled by the bank.

如何開發突破性的核心銀行產品與服務

銀行必須持續推出重大創新才能成長，但許多機構並不清楚該如何著手。許多銀行仍停留在傳統「生產者（Producer）」模式：供應商發布產品路線圖，銀行撰寫冗長的需求文件，系統整合商歷經數月才交付專案。學術研究與實務經驗指出，真正有效的道路不同：重要的創新往往來自「使用者」。這些使用者在社群中分享並改進點子；當平台提供簡單且好用的工具組，便能把設計無阻力地轉成可上線的產品。在銀行業，許多所謂的「新」服務其實先源於使用者的權宜作法，之後才被正式產品化。也就是說，下一條成長曲線往往已在客戶與前線團隊之間悄悄驗證。

核心銀行的創新應從「供應商主導需求」轉向「銀行與使用者共同創造」。這個轉變建立在三個基石之上。第一，找到「領先使用者」，也就是需求走在市場前面的客群。第二，建立社群，讓優秀解法可以擴散並持續精進。第三，將工具組嵌入核心銀行平台，使各團隊得以安全地設計、測試與發佈。若執行得當，從構想到上線的時間可由數月縮短到數天，而且「一次到位」的發佈比例將明顯提高。

領先使用者最先承受痛點，也最有動機去解決問題。在核心銀行情境中，這類使用者可能是同時處理外匯與即時退款的跨境中小企業、長期處理例外案件的催收團隊，或需即時對帳的財資團隊。貼身觀察這些使用者的日常，往往能看到反映產品邏輯的試算表、Excel 巨集與政策規則。把這些產物視為「真實解決空間」的地圖：利率、分層、假期行事曆、排程、容差窗口、爭議計時器與日終模式，會成為產品設計的共同語彙。

社群能把零散的修補轉化為可重用的模式。與其在團隊間傳遞冗長文件，不如共享可複製、可調整的「配方（recipe）」。例如：包含通知、計時與費用回沖規則的休眠／再啟用流程；支援部分沖銷與時限控制的即時退款流程；具備延後入帳護欄的日終模式。實務上，只要有強韌的配方落地，各市場的在地化變體便會快速出現，重工也隨之下降。

工具組讓轉型可複製、可擴張。首先是「使用者友善」的產品語言與元件庫，讓團隊能在同一處定義利率、分層、假期行事曆、排程、入帳順序與爭議計時器。再來是「模擬帳本」，可重播歷史事件，將基準產品與新變體在餘額、費用與會計處理上逐一比對。最後是「一鍵轉譯」：把產品語言編譯為可上線的產物，並嚴格檢查資料結構、限額、流動性與稽核要求。這能把設計意圖轉成可預期的系統行為，並提供風險與財務部門可信賴的證據。

將控制前移並自動化，可讓治理更強健。核心銀行平台需在執行期強制檢查會計平衡、限額、流動性緩衝與規則；模擬環境在發佈前以真實流量驗證業務結果；變更管線對每一項調整進行簽署與版本管理，並串連核准與測試證據。權責分離成為預設：開發人員提出設定，風險與財務核准，平台團隊部署，而通過模擬重播則是必備關卡。控制因此能更早、更頻繁、且以清晰工件運作，減少後期意外。

度量指標能讓系統保持誠實。追蹤「上帳時間」——從核准的點子到可部署設定的前置期；追蹤每週迭代次數以衡量學習速度；追蹤「一次到位」發佈比率；以真實流量比對基準與變體的會計差異；並加入工程訊號，如建置成功率與變更失敗率。當這些指標同步改善，代表轉型正在奏效。

這場典範轉移也重塑了營運模式。與其把時間投入在靜態產品規格，不如把力氣放在界定解決空間、共享模式，並把護欄固化在程式碼中。核心銀行成為可程式化的平台；銀行成為以「構建與測試」驅動學習的社群，而非被辦公室政治牽動的組織。當利息邏輯、假期行事曆等核心行為模組化，且模擬能在監管機關之前攔截邊界情境，團隊便不再畏懼產品變更。這份信心正是關鍵啟動器——讓創新從口號變為由使用者驅動、由銀行擴大的穩健突破。

The Stoic Brainhack

Life often feels like a crab bucket. The moment you try to climb higher, someone pulls you back down with criticism, doubt, or even envy. It’s exhausting to fight against this invisible weight. The Stoics, philosophers who lived more than two thousand years ago, left us with a timeless brainhack that can help us rise above not only the crab bucket but almost every obstacle life throws our way.

The Stoics taught that our suffering doesn’t come from the world itself, but from the gap between our expectations and reality. We expect fairness, kindness, and recognition, but reality doesn’t always deliver. And when it doesn’t, we feel frustrated and hurt. The Stoic answer is not to rage against life but to accept it as it is, to stop wasting energy on wishing the world were different and instead focus on how we respond.

Imagine someone yelling at you. Your instinct might be to fight back or dwell on how unfair it is. The Stoic path says: accept that people sometimes yell. If a friend betrays you, acknowledge that betrayal exists in human nature. If tragedy strikes, don’t deny it or curse fate, instead face it with courage and grace. Even in moments of deep injustice, such as Nelson Mandela’s decades in prison, Stoicism offers strength. Mandela drew on this philosophy to rise above bitterness, preparing himself not for revenge but for reconciliation and ultimately healing a nation.

That is the power of Stoicism: calm in the chaos, strength in the storm. Gene Roddenberry even modeled Spock in Star Trek on the Stoics, showing how logic and composure can triumph over emotional turmoil.

Now bring this mindset back to the crab bucket. When others try to hold you down, understand that it’s human instinct. People fear change, and sometimes your growth makes them uncomfortable. Instead of wasting energy on anger, meet it with clarity. If it’s a friend, sit them down and explain your dreams. Ask for their support. If it’s others trying to drag you down, accept their behavior for what it is, just noise, and don’t let it define your journey.

Acceptance is not weakness. It is freedom. When you stop fighting against what “should be” and embrace what is, you gain the power to choose your response. You can redirect your energy away from bitterness and into action, growth, and purpose. The Stoic brainhack is simple yet transformative: reduce the gap between reality and expectations, and you’ll reclaim your peace.

In life’s crab bucket, you don’t need to claw at others or waste your strength battling those who try to pull you back. You can simply climb out calmly, steadily, and with unshakable focus. Accept the world as it is, rise above the noise, and become unstoppable.

斯多噶的心智技巧

生活常常像一個螃蟹桶。當你試圖往上爬時，總有人把你拉回去，帶著批評、懷疑，甚至是嫉妒。與這種無形的壓力對抗令人筋疲力盡。兩千多年前的斯多噶學派哲人，留下了一個永恆的心智技巧，不僅能幫助我們擺脫螃蟹桶效應，更能應對生活中幾乎所有的挑戰。

斯多噶派認為，我們的痛苦並非來自世界本身，而是來自於「現實」與「期待」之間的落差。我們期待公平、善意與肯定，但現實往往並不如意，而當它沒有如願發生時，我們便感到挫折與受傷。斯多噶的答案不是憤怒地對抗，而是如實地接受現實，不再浪費精力去抱怨世界應該如何，而是專注於我們如何回應。

想像有人對你大吼大叫，你的本能可能是反擊或陷入不公平的念頭。斯多噶的態度則是：接受人有時會大吼。若朋友背叛你，承認背叛是人性的一部分。若遭遇不幸，不要否認或詛咒命運，而是以勇氣與優雅面對。即便是極端的不公，例如納爾遜·曼德拉長年的牢獄生活，斯多噶也能給予力量。曼德拉正是藉由這種哲學超越了苦澀，準備自己不是為了報復，而是為了和解，最終治癒了一個國家。

這正是斯多噶的力量：在混亂中保持冷靜，在風暴中依然堅強。星艦迷航記的創作者金·羅登貝瑞甚至以斯多噶為靈感，塑造了史波克這個冷靜理智、超越情緒的角色。

當我們把這種心態帶回螃蟹桶的情境時，便能看見人的行為其實源於本能。人們害怕改變，有時你的成長會讓他們不安。與其浪費精力在憤怒上，不如用清晰的頭腦去面對。如果是朋友試圖拉你下來，與他們坐下來解釋你的夢想，請求他們的支持。若是其他人試圖拖累你，接受這就是現實中的雜音，別讓它決定你的方向。

接受並不是軟弱，而是一種自由。當你不再與「應該」對抗，選擇擁抱「現實」時，你便重新掌握了選擇的力量。你可以把精力從苦澀轉向行動，從憤怒轉向成長與使命。這個斯多噶的心智技巧雖然簡單，卻能帶來徹底的轉變：縮小現實與期待的差距，你就能找回內心的平靜。

在生命的螃蟹桶裡，你無需與他人爭鬥，也不必浪費力量對抗那些試圖拖累你的人。你只需冷靜而堅定地往上爬，帶著不可動搖的專注。接受世界如其所是，超越雜音，成為無可阻擋的自己。

Why We Get Stuck in Self-Criticism

We’ve all experienced it: that inner voice that won’t let up, the one that criticizes, doubts, and questions our every move. Sometimes it whispers, sometimes it shouts, but its message is always the same: you’re not enough. Ironically, even though research shows that self-criticism fuels stress, anxiety, and depression, many of us keep falling back into it as if it were helping us. The truth is, self-criticism is not a weakness. It is a survival mechanism that our brain and culture have trained us to adopt. But here’s the good news: what’s learned can also be unlearned.

Our brains evolved to keep us safe. They cling to negative experiences like Velcro, while letting positive ones slip away like Teflon. This negativity bias once helped us survive in dangerous environments, but today it means we’re more likely to replay an embarrassing comment at work than to savor a compliment from a friend. We turn this instinct inward, mistaking self-criticism for protection. We convince ourselves that if we point out our flaws first, others won’t have the chance to hurt us. Yet what really happens is that we exhaust ourselves with anxiety, shame, and self-doubt.

On top of that, society loves comparisons. From grades in school to performance reviews at work, from beauty standards in magazines to the perfect lives on social media, we are constantly told we don’t measure up. Slowly, these external voices become internal ones. We inherit cultural habits of self-deprecation, and for some, the scars of criticism or neglect in childhood deepen the pattern. Over time, self-criticism becomes second nature, an automatic reflex that feels impossible to resist.

But let’s pause here. Just because self-criticism has roots in our survival doesn’t mean it’s the best path forward. In fact, the idea that self-criticism motivates us is one of the biggest myths we tell ourselves. Think about it: when was the last time you felt creative, energized, and fully alive because you scolded yourself? Real motivation doesn’t come from a harsh inner critic. It comes from encouragement. Studies show that people who practice self-compassion are not only happier, but they are also seen as more capable, responsible, and resilient by others.

Imagine treating yourself the way a great coach treats their team. Golden State Warriors coach Steve Kerr doesn’t spend halftime tearing down his players. Instead, he highlights what they’ve done well and inspires them to do more of it. The result? His team comes back stronger, more confident, and ready to win. If positive reinforcement can transform professional athletes under pressure, imagine what it could do for your own life.

Of course, not all criticism is harmful. Constructive self-reflection has its place. The difference is in tone and focus. Healthy self-talk addresses behaviors you can change—“I should manage my budget better this month”—without attacking your worth—“I’m terrible with money.” The first empowers. The second destroys.

Breaking free from self-criticism is not about silencing your inner voice. It’s about retraining it. Like any habit, it takes practice. At first, being kind to yourself will feel unnatural, maybe even lazy. But stick with it. Over time, encouragement becomes the new reflex. The inner critic fades, and a supportive inner coach takes its place. That’s when you’ll notice not only a lighter heart, but also greater strength, resilience, and joy in everything you do.

So the next time that harsh voice tries to drag you down, remind yourself: self-criticism doesn’t make you stronger, it makes you smaller. Compassion, encouragement, and love are what fuel real growth. You already carry within you the ability to be your own best coach, your own most reliable ally. All it takes is the courage to start listening.

You are not your mistakes, and you are not defined by self-criticism. Be the voice that lifts you higher, not the one that drags you down. Choose encouragement over judgment, and watch yourself rise.

為什麼我們總陷入自我批判

我們都曾經歷過——那個不斷在腦中出現的聲音，挑剔、懷疑、質疑我們所做的一切。有時它低聲耳語，有時它大聲咆哮，但訊息始終如一：你不夠好。 矛盾的是，儘管研究顯示自我批判會加劇壓力、焦慮與憂鬱，我們卻仍然習慣依賴它，好像它能幫助我們一樣。事實上，自我批判不是一種弱點，而是我們大腦與文化長期塑造出來的生存機制。但好消息是：既然它是習得的，那麼它也能被改變。

我們的大腦是為了保護自己而演化的。它會緊緊抓住負面經驗，就像魔鬼氈一樣，卻讓正面經驗像特氟龍一樣滑走。這種「消極偏見」在危險環境中曾經幫助我們存活，但如今卻讓我們更容易反覆咀嚼那些尷尬、羞恥的時刻，而不是細細品味別人的讚美。當我們把這種本能轉向自己時，就會誤以為自我批判能保護我們。我們告訴自己：只要先挑出自己的缺點，別人就沒辦法傷害我們。然而，現實是，我們因此被焦慮、羞恥與自我懷疑壓得筋疲力竭。

除此之外，社會更推波助瀾。從學校的成績單，到職場的績效評估，從雜誌裡的完美身材，到社交媒體上的理想生活，我們總被告知自己還不夠好。這些外在的聲音，逐漸變成了內心的聲音。我們繼承了文化中的自我貶低習慣，而對某些人來說，童年遭受的批評、忽視，甚至霸凌，讓這個模式更加根深蒂固。久而久之，自我批判成了一種自然而然的反射行為，讓人感覺難以抗拒。

但停下來想一想：就算自我批判有它的生存根源，也不代表它是推動我們前進的最好方式。事實上，認為自我批判能激勵自己，正是我們最深的迷思之一。想想看，你上一次因為罵自己而感到創意湧現、充滿能量、全神貫注，究竟是什麼時候？真正的動力從來不是來自苛刻的自責，而是來自鼓勵。研究指出，懂得自我慈悲的人，不僅更快樂，還更容易被他人視為有能力、有責任感、並且更具韌性。

試著把自己想像成一位教練。金州勇士隊的總教練史蒂夫·科爾在中場休息時，並不會對球員大肆批評，而是強調他們做得好的地方，並鼓勵他們再接再厲。結果呢？球隊在下半場往往能更有信心、更具戰力，甚至掌控比賽。若正向的回饋能在高壓環境下改變職業運動員的表現，想像一下它對你的人生會帶來多大的轉變。

當然，並不是所有的批評都是壞的。建設性的自我反思仍有其價值，關鍵在於語氣與焦點。健康的自我對話會針對行為去調整，例如：「這個月我要更好地管理預算」，而不是攻擊自我：「我很爛，根本不會理財」。前者能賦予力量，後者只會摧毀信心。

擺脫自我批判，並不是要消滅內心的聲音，而是要重新訓練它。就像改掉任何壞習慣一樣，這需要時間與練習。剛開始，對自己好一點可能會覺得彆扭，甚至會被誤解成懶惰。但只要堅持下去，鼓勵最終會取代批判，成為新的反射行為。當內在的嚴厲批評聲逐漸淡去，一個支持性的「內心教練」就會出現。那時候，你會發現自己不僅心情更輕盈，也會在生活中展現出更大的力量、韌性與喜悅。

所以，下次當那個嚴厲的聲音再次出現時，提醒自己：自我批判不會讓你更強大，它只會讓你變得更渺小。真正的成長來自慈悲、鼓勵與愛。你已經擁有成為自己最好教練、最可靠盟友的能力。你只需要鼓起勇氣，開始傾聽那個支持你的聲音。

你不是你的錯誤，也不是由自我批判所定義的。選擇成為那個鼓舞自己的人，而不是那個拖累自己的人。當你選擇鼓勵而非批判，你會驚訝自己能飛得多高。

The Common Pitfalls of Entrepreneurship

When many entrepreneurs first start their journey, they face the same dilemma: no money. The seemingly easy solution is to take on outsourcing projects to generate cash flow. On the surface, it feels like a practical way to survive, but beneath that surface lies a dangerous trap. Outsourcing is not about selling technology; it is about selling time. The painful truth is that time can only be sold once. Unlike building a product that scales, outsourcing leaves you with nothing more than hours traded for dollars.

In outsourcing, the client’s perception is stacked against you. Deliver 100 points of output, and the client sees 60. Go above and beyond with 120 points, and it is perceived as 80. But if you fall short with 60 or 80 points, they might see it as 20. The game is unwinnable. Then there is seasonality. During peak periods, the company may look profitable, but slow seasons eat away at everything. Employees only see the boom, not the bust. And when billing hours become transparent, they wonder why the boss profits while they get little share.

Employees in outsourcing firms often feel disconnected as well. They are constantly building new projects without ever seeing growth or evolution in a single product. As a result, once they have gained enough skills to stand on their own, they leave. Turnover soars, and the company is left spinning in circles. At its core, outsourcing builds no long-term assets. You are essentially training engineers for someone else’s company while your own remains hollow. That is why I eventually realized: if the choice is between this treadmill and a stable job, a job is the better option. There is an old industry rule: unless your startup is earning at least three times your previous salary, you are losing money. The real moment to step into entrepreneurship is when you are confident you can create a product with true value, not when you are just scrambling to survive.

Another misconception among founders, especially those with engineering backgrounds, is believing that technology alone can solve business challenges. Agile development, for example, emerged as a reaction against the inefficiencies of the waterfall model. Instead of writing exhaustive specifications, agile uses lightweight user stories to speed up development. But deciding feature priorities based on story points is misguided. Market needs, not estimation games with poker cards, should drive feature decisions. Early in my career, I thought SCRUM was brilliant. But after real-world startup experience, I saw it for what it often is: a greenhouse experiment, disconnected from the brutal realities of the market.

The same applies to growth hacking. Instrumenting apps with tracking points and running endless experiments might help identify trends, but no amount of data can replace listening to real users. Conversion metrics may highlight where things drop off, but they do not tell you why. Engineers often avoid facing users directly, preferring the comfort of dashboards over uncomfortable conversations. But building a product in isolation, guided only by numbers, is irresponsible. In my experience, I insisted every engineer understand both the business and the technnology world itself. Only by living the same experience as our users could we build features that truly resonated.

Technology is a powerful tool, but it is not a magic bullet. Growth does not come from clever frameworks or endless tracking points. It comes from solving the right problem for the right market. The truth is simple: outsourcing may keep the lights on, but it builds no lasting foundation. Agile methods may improve efficiency, but they must be grounded in business reality. Data can inform decisions, but it cannot replace direct user feedback. Entrepreneurship is not about selling time or chasing methodologies. It is about building value, something that outlives the hours you put in, and something that connects deeply with the people you serve.

創業常見的誤區

當許多創業者剛開始他們的旅程時，往往面臨同樣的困境：沒有資金。看似最容易的解決辦法，就是接外包案來產生現金流。表面上這是一種務實的生存方式，但在這背後卻隱藏著危險的陷阱。外包的本質並不是「賣技術」，而是「賣時間」。而殘酷的事實是，時間只能被賣一次。不同於可以規模化的產品，外包帶給你的只不過是用時間換來的一點收入。

在外包行業裡，客戶的認知永遠與你對成果的評價存在落差。你交付 100 分的成果，客戶只覺得是 60 分。即使你做到 120 分，客戶也可能只視為 80 分。但如果你只做到 60 分或 80 分，他可能會認為只有 20 分。這場遊戲註定不可能公平。除此之外，外包還有淡旺季之分。旺季時公司看起來很賺錢，但淡季卻把一切都吞噬掉。員工只看到繁榮的時候，卻忽略了蕭條的時候。而當工時與收費透明後，他們往往會質疑：老闆明明在賺錢，為什麼沒有與員工分享。

外包公司的員工也常常感到疏離。他們不斷地重複開發新的專案，卻從未真正參與一個產品的成長與積累。結果就是，當這些員工好不容易被培養到能獨當一面時，他們選擇離開。人員流動率居高不下，公司也就陷入惡性循環。從本質上來說，外包無法建立長期資產。你只是幫別人公司訓練工程師，而自己的公司卻空空如也。這也是我後來領悟到的：與其陷在這樣的輪迴裡，不如選擇一份穩定的工作。行業裡有句老話：如果創業賺不到你原本薪水的三倍，那麼你其實是在虧錢。真正適合創業的時機，是當你確定自己能打造出有價值的產品，而不是在手忙腳亂求生存的時候。

另一個創業者常見的誤區，特別是有工程師背景的人，就是認為技術可以解決所有的商業難題。敏捷開發的興起，就是為了反擊傳統瀑布式開發的低效。敏捷放棄了繁瑣完整的規格文件，改用輕量化的用戶故事來提升開發效率。但問題在於，把功能優先順序建立在「故事點數」之上，本質上是錯誤的。決定優先順序的，應該是市場需求，而不是工程師用撲克牌比工時。剛接觸敏捷時，我曾覺得 SCRUM 很厲害。但真正創業之後，我才發現這種方法往往像是在溫室裡做實驗，與現實市場完全脫節。

Growth Hacking 的興起同樣帶來了類似的誤解。很多人以為只要在網站或 App 裡埋點收集資料，就能帶來成長。沒錯，數據確實能幫助行銷決策，但它絕不能取代使用者回饋。轉換率數據或許能指出問題在哪裡，但卻無法告訴你為什麼。許多工程師選擇逃避面對使用者，寧願依賴數據儀表板，也不願意聽客服的回饋。但這種閉門造車、只靠數據驅動的做法，是一種不負責任的態度。

在我自己的公司，我們要求每位工程師都要懂業務，也要會技術。唯有如此，他們才能寫出真正符合市場使用者心理的功能。功能開發必須根據使用者的回饋來調整，數據只是輔助工具，幫你找出轉換率下降的原因。但「成長」從來不是單靠數據分析就能找出來的，它必須來自於真正擊中市場痛點，滿足使用者需求。

技術是一個強大的工具，但它不是萬能的解藥。成長不來自於花俏的框架或無止境的數據實驗，而是來自於解決正確的問題，服務正確的市場。事實很簡單：外包或許能暫時維持生計，但無法建立長久的基礎。敏捷方法或許能提高效率，但必須回歸市場現實。數據能夠幫助判斷，但永遠不能取代使用者的聲音。真正的創業不是在賣時間，也不是在追逐方法論，而是去創造價值——一種超越你付出的時間，並能與使用者建立深刻連結的價值。