本周要闻
1. Linear 创始人分享盈利创业的经验
我最初并没有打算创办一家盈利的初创公司。但当我真正做到之后，我意识到我不会想用其他任何方式来创办公司。
这篇文章分享了 Linear 团队在无意中走向盈利路径的真实经历。作者坦诚地讲述了从「不惜一切代价追求增长」到「专注于可持续盈利」的思维转变。文章深入探讨了几个关键观点：
- 盈利带来的自由：当你不需要依赖外部资金时，你可以真正专注于用户需求而不是投资人期望
- 产品驱动的增长：Linear 通过打造出色的产品来吸引付费用户，而不是依赖激进的营销策略
- 团队规模的重要性：小而精的团队更容易保持高效和盈利
- 长期思考的优势：盈利模式让公司能够进行长期规划，而不必担心下一轮融资
这篇文章对于正在考虑创业道路的创业者提供了宝贵的参考视角。
2. Fly.io：写一个 AI Agent 原来如此简单
Everyone Should Write An Agent
这篇文章是一份写给技术人的实用指南，作者用亲身经历说明了构建 AI Agent 的真实复杂度。文章的核心论点是：「要理解 LLM Agent，必须亲手写一个」。
技术精髓解析：
1. Agent 的本质架构
Agent 的核心只有两个部分：(1) LLM 调用循环 和 (2) 工具调用机制。作者用实际的代码示例展示了，一个可运行的 Agent 只需要十几行代码：
// 核心循环伪代码
context = [];
while (true) {
response = await llm_call(context, tools);
context.push(response);
if (response.tool_calls) {
for (call of response.tool_calls) {
result = await execute_tool(call);
context.push(result);
}
}
}2. 工具调用的力量 文章展示了工具调用（function calling）是 Agent 的真正能力放大器。Agent 会：
- 自行决定是否调用工具
- 自行选择调用顺序
- 自行决定调用多次（例如 ping 多个域名）
开发者无需写决策逻辑，模型会基于意图自动编排工具调用。
3. Context Engineering 的挑战 Prompt Engineering 在 Agent 构建中并不重要，真正的硬核问题是 Context Engineering：
- 每个 token 都消耗上下文窗口
- 工具描述、历史消息、工具输出都会占空间
- Token 上限决定了 agent 的复杂度
4. 子 Agent 架构的工程实践 文章指出，完全可以轻松实现类似 Claude Code 的 sub-agent 架构：
- 给每个子 agent 一个独立 context
- 给定不同工具
- 互相总结/汇总
- 构建树状结构/map-reduce 式分析
总结：LLM Agent 不是黑魔法，而是一种新的软件工程架构：一个可组合的、有上下文的函数调用编排器。理解它的唯一方式，就是动手构建一个。
3. 重新定义财富：你能调动多少资源？
这篇文章挑战了我们对财富的传统认知。作者提出了一个发人深省的衡量标准：
因此，更合适的衡量标准应该是：一个人在必要时能够调动多少资金来解决问题。如果他们所爱的人身患重病，但治疗费用巨大，他们在一个月或两个月内能筹集到多少钱？他们能借到多少钱？向谁借？借款条件是什么？
核心观点：
財富不是你擁有的，而是你能調動的 傳統的財富觀關注銀行帳戶餘額、房產、股票等靜態資產。但文章認為，真正的財富應該是動態的——在你最需要的時候，能夠動員多少資源來解決問題。
社會資本的價值 文章強調了個人關係網絡在財富定義中的重要性：
- 你有多少真心願意幫助你的朋友？
- 你的專業能力是否能為他人創造價值？
- 人們在多大程度上信任你，願意在你困難時伸出援手？
流動性的關鍵 一個月或兩個月內能籌集到的資金，這個時間框架很有深意。它強調了：
- 快速變現能力的重要性
- 緊急情況下的資源調配效率
- 信任和關係的即時價值
這篇文章讓我們重新思考：也許真正的財富不是數字，而是你在危機時刻的生存和解決問題的能力。
4. 維護開源項目的誠實現狀
Maintaining Open Source Project
這是一篇來自資深開源維護者的真誠分享，揭開了開源項目維護的神祕面紗。
誠實的真相：
「the honest truth」維護一個開源、自架項目的目的是：
- 「more work than building it」比建造還要費勁
- 「different fun than building it」和建造它不同
- 「more rewarding than you’d expect」比你想像的更有成就感
- 「harder than you’d expect」比你想像的還要難
- 「worth it」值得
維護階段的真实挑戰：
技術技能的深度成長 維護一個項目需要面對建造時未曾考慮的問題：
- 遷移挑戰：如何在保持向後相容的同時升級依賴和架構
- 安全責任：每個
PR都可能是潛在的安全漏洞 - 可擴展性壓力：用戶量增長帶來的性能和架構挑戰
- 技術債務管理：決定何時重構、何時接受現狀
人際交往能力的磨練 開源項目本質上是社區項目，維護者需要：
- 溝通的藝術：清楚解釋技術決策，處理不同意見
- 無限的耐心：重複回答同樣的問題，引導新貢獻者
- 設立界限：學會說「不」，保護自己的時間和精力
產品思維的覺醒 從純技術思維轉向產品思維：
- 優先級判斷：平衡功能請求、
bug修復和技術改進 - 範圍控制：避免功能膨脹，保持項目聚焦
- 長期願景：思考項目的未來方向和生態建設
最大的收穫 作者強調，維護開源項目讓他學會了如何珍惜每一份貢獻，以及如何打造人們真正想要的東西。這種滿足感，遠超最初的預期。
5. 人類從不吸取教訓：IT 項目失敗的根本原因
IT Management Software Failures
這篇文章通過 Phoenix 等失敗項目的深入分析，揭示了 IT 行業幾十年來重複犯錯的系統性問題。
行業的自我欺騙
「The IT community has striven mightily for decades to make the incomprehensible routine.」
IT行業幾十年來一直努力讓這種難以理解的日常化。
作者指出，IT 行業一直在試圖將複雜的項目管理簡單化、標準化，但這種努力往往掩蓋了問題的本質。
重複錯誤的荒謬性
「Repeatedly making the same mistakes and expecting a different result is not learning. It is a farcical absurdity.」 反覆犯同樣的錯誤，卻期待不同的結果，並不是學習。這是一種荒謬至極的荒謬。
文章借用亨利·彼得羅斯基（Henry Petroski）在《工程師是人類：失敗在成功設計中的角色》一書中的觀點：我們或許學會了如何計算因風險導致的軟體失敗，但還沒有學會如何計算消除心智的失敗。
專業管理的幻覺 作者提出了一個尖銳的觀察：
有大量像
Phoenix這樣的項目部分因管理失誤而失敗，但要找到專業管理的軟體項目仍然失敗，實在極為困難。尋找可以稱為「IT英雄式失敗」的例子，就像第歐根尼尋找一個誠實的人一樣。
這意味著：
- 成功案例被過度宣傳：我們聽到的都是成功故事，失敗的案例往往被掩蓋
- 歸因偏差：失敗總是歸咎於「管理不當」，而不是系統本身的問題
- 學習機制的缺失：行業缺乏有效的失敗經驗分享和學習機制
深層問題分析 文章指出，真正的挑戰不在於技術或方法論，而在於：
- 認知局限：項目管理涉及太多變數，超出了人類認知能力
- 組織慣性：大型組織的決策流程往往阻礙了有效的項目管理
- 期望錯位：客戶、管理層、開發團隊之間的期望往往不一致
結論
人類會吸取的教訓，就是人類從不吸取教訓。
這句悲觀的總結提醒我們，也許需要全新的思維方式和組織模式，才能真正解決 IT 項目管理的根本問題。
訂閱與反饋
如果你喜歡這份週刊，歡迎：
- ®️
RSS訂閱 - 🔄 分享給朋友
- 💬 在評論區留下建議和
reactions
下期見！👋