desperado

三十岁以前，我第一次读弗雷德里克·布鲁克斯（Frederick P. Brooks, Jr.）的《人月神话》，只觉得 1975 年写下的例子有些遥远。什么「向进度落后的项目中增加人手，只会使进度更加落后」、什么「没有银弹」、什么「概念完整性只能来自极少数人的头脑」……那时我在香港的初创公司，每天敲代码到深夜，靠着新框架和搜索就能快速堆功能。项目总延期，但最后往往还能勉强上线。我心想：这些老一辈的「神话」，早就被现代工具打破了吧？ 现在我 34 岁，在一家中型科技公司带一个小团队。头发里多了白丝，肩膀也因久坐开始隐隐作痛。2025 年底到 2026 年初，我亲手跟了几个真实项目，才像被当头棒喝一样读懂这本书。它不是在恐吓年轻人，而是在提醒：软件开发的本质，往往不是和机器搏斗，而是和人类自身的局限性搏斗——乐观主义、沟通成本、概念的脆弱，以及对「再完美一点」的执着。 亲手验证「人月神话」的那一次2019 年，我负责一个企业级后台系统。客户催得急，原本估算要 6 个月，我们乐观地压到 4 个月。两个月过去，第一个里程碑彻底卡住：接口定义模糊、需求反复变动、几个核心模块互相踩脚。我的本能...

2024 年前后，英文技术圈里常把 Python 依赖生态戏称为 dumpster fire（垃圾桶大火）。Niels Cautaerts 在 Python dependency management is a dumpster fire 里用「露营篝火失控」的叙事把问题讲透：脚本长成项目、别人机器上复现不了、一次 innocuous 的升级整锅端掉——默认工作流容易「随手 pip install」、锁文件与构建元数据各说各话，传递依赖又像开盲盒。到了 2026 年，规范面（pyproject.toml、依赖分组、标准化锁文件）和 工具面（以 Rust 实现的高性能解析/安装器）已经能把「可重现」从口号变成日常操作。我按「原则 → 工具地图 → 工作流 → 选型」整理这篇笔记，并穿插两篇写得极好的英文原文里的分层与分类图（已下载到本站、保留署名），方便和站内其它 Python 与工程化文章对照：全栈开发技术选型、FastAPI 学习笔记、GitHub Actions 部署。 读完你可以带走这些结论： 可重现 = 声明（direct deps）+ 锁定（全依赖...

上一篇 FastAPI 学习笔记：从 ASGI 到异步 API 的生态梳理 把协议栈和迷你案例跑通之后，很自然会遇到下一层问题：用户是谁、能不能访问这条接口、凭证存哪。这篇把「常见登录与认证」放在一张表里对照，再单独说清楚 OAuth2、SSO（单点登录） 在工程里各自指什么；仍以官方文档为锚，代码只写到能指导你拆模块的程度。 与 浏览器里 Cookie、Token、Session 的载体辨析，可配合 cookie、token、session、JWT 你们是不是在讨论同一件事。 Python 侧依赖锁定与 CI 可复现见 2026 年 Python 包管理与依赖选择。全栈里接口层与身份对接可与 全栈开发技术选型 对照；前端包管理与锁文件可与 前端包管理机制笔记 对照——运行时不同，「声明依赖 + 锁文件 + CI 装包」 仍是同一条习惯。 读完你能带走： 401 / 403、认证与授权 在接口设计里怎么区分最省事。 Bearer、JWT、OAuth2、OIDC、SSO 各解决哪一段，避免把「OAuth2 密码流教程代码」直接当生产方案。 fastapi-sso...

如果你打算用 Python 写现代 HTTP API，多半会碰到 FastAPI：类型注解驱动、自动生成交互式文档、性能口碑也不错。但文档里常出现 Starlette、Pydantic、ASGI 等名词——它们各自解决什么问题、和 FastAPI 怎么叠在一起，初学者容易晕。这篇笔记按「协议 → 服务器 → 框架 → 业务层」的顺序，把主线捋直，并记下我整理时的常用结论与链接，方便以后回看。 认证、登录与 JWT 见站内 FastAPI 登录与认证：OAuth2、SSO 与常见方式。若你还关心 Python 侧锁文件与 uv、CI 装依赖再构建、全栈接口层怎么拆，可交叉阅读 2026 年 Python 包管理与依赖选择、GitHub Actions + Hexo 博客自动部署、全栈开发技术选型。 读完你能带走： ASGI 在请求链里处在哪一层，为什么需要 Uvicorn 这类进程。 Starlette / Pydantic / FastAPI 各自负责的边界，以及 OpenAPI 与校验怎么对齐。 lifespan 里接数据库、async 路由里 await...

开会时白板画了半天，对方还是问「所以依赖关系在哪」——多半不是画得不够细，而是图形类型和当下问题不匹配。下面按「先定范围、再排时间与依赖、再看流动与资源、最后做分解与归因」的顺序，整理九种常见可视化；每种配本地保存的示意图和一句示例说明，便于你对照选用。若你也在梳理工作流与可复用交付，可顺带对照 Agent Skills：AI 时代的可复用能力封装；技术栈与协作形态若在变，脉络可参考 AI 技能大爆发：VibeCoding、Agent、MCP、OpenClaw 与 Skills 的发展史。 读完可以带走： 九种图形各自对应的「核心问题」与典型视觉特征。 每张图下有一条可套到自己项目里的示例说明（软件、建筑、营销、预算等常见场景均可类比）。 文末组合建议：简单项目与复杂/不确定项目分别优先哪些图。 文中示意图均为教学/产品公开素材。 思维导图（Mind Map）——项目范围与脑暴思维导图常用于项目启动时的脑暴和范围分解：中心主题向外放射，一层层展开子项，适合把「大而空」的目标拆成可讨论的分支，再导出为 WBS、清单或排期。 图：项目范围/日程类思...

Sora：高算力、高预期，却难抵营收与版权双重压力，最终整体下线视频能力。 Seedance 2.0：贴近短视频与广告场景，靠生态与定价跑通试用，但同样在欧美陷入 IP 风暴。 读完带走：AI 视频胜负不只取决于画质，更取决于单位经济、场景黏性与法务响应速度。 2026 年 3 月，OpenAI 宣布关闭旗下 AI 视频产品 Sora 的消费者 App、API，以及 ChatGPT 内的视频生成入口，并取消与迪士尼等方的高额合作意向。一度被视作「电影级生成」标杆的 Sora，就此退出面向大众的产品形态。几乎同一时期，字节跳动旗下的 Seedance（尤其 Seedance 2.0）在国内仍保持高热度，被不少创作者和中小商家当作「可批量出片」的工具。两条路径的分叉，很难只用「技术好坏」解释——更关键的是商业化是否跑得通，以及版权与监管压力来临时能否快速收口。下面先看商业化，再看法律法规与公开报道中的争议时间线。 若把「模型能力」和「产品化」分开看，可先对照本站 Agent 工具链与 Skills 脉络，以及 Agent Skills 作为可复用能力封装——视频生成同样是能力...

MCP：把「接什么工具」从各家自研接口，收敛成可复用的开放协议，Agent 才有稳定的「手脚」。 Vibe Coding：用自然语言指挥生成与迭代代码，把门槛从「写每一行」挪到「说清楚要什么」。 Agent：在 MCP + 强模型之上，做多步规划、调用工具、执行工作流；和单次问答不是同一类游戏。 OpenClaw / Skills：本地或自托管的 Agent 运行时 + 可分发、可组合的 Skill 包，把能力做成「装插件」。 若你更关心「Skill 目录长什么样、和 GitHub 上同名课程有啥区别」，可先看站内这篇：Agent Skills：AI 时代的可复用能力封装。 2024 到 2026 年，大家聊 AI 时，「技能」越来越常指一件具体的事：模型不只生成文字，还能按步骤调用工具、读写环境、把事办完。下面按时间先后，把 MCP、Vibe Coding、Agent、OpenClaw 与 Skills 串成一条线；例子侧重能想象的用法，方便你对照自己的场景。 MCP（Model Context Protocol）：先把「接线」标准说清楚Anthropic ...

这份笔记把产品经理需要掌握的基础知识串成一条逻辑链：从文档规范起步，再到产品从无到有的过程。每个理论尽量按「定义 → 为什么重要 → 怎么做」展开，并配有案例（背景、问题、做法、启发），便于零基础反复阅读与练习。 一、产品文档撰写规范（PRD 的基本功）PRD 全称 Product Requirements Document（产品需求文档）。产品文档（尤其是 PRD）是产品经理与开发、设计、测试沟通的「合同」。写得规范，执行就顺；写得模糊，容易返工和伪需求。 1. 命名规范 定义：标题准确、简洁、无歧义；常见格式为「描述对象 + 版本号」。 为什么重要：团队每天浏览大量文档，命名混乱会找错文件或用旧版。 怎么做：对象细化到模块或功能；版本号便于追踪迭代。 示例：《CRM（Customer Relationship Management，客户关系管理）系统 - 用户注册模块产品需求文档 V1.2.3》。 小贴士：若已是终版且不再改，可省略版本号。 2. 表达规范 定义：通篇使用客观、书面化专业表述。 为什么重要：口语化显得不专业，也易引发误解。 怎么做：避免「我觉得」「咱们下周」...

如果你在 Nuxt 全栈项目里纠结「业务 API 继续放 Nitro，还是拆一个 Python 服务」，这篇把取舍拆成三件事：你现在主要做什么、哪些能力必须靠 Python、架构上怎么演进而不推翻重来。下面结论会先给，再展开场景与可选架构。与「把编排与接口稳定下来、把重能力外包给合适运行时」同一思路的，还有 Agent Skills：AI 时代的可复用能力封装 里讨论的 Skill 化交付，可对照阅读。 读完可以带走： 一张维度表，快速对照 Nitro 与 Python 后端。 AI、PDF/PPT、教育类函数图三类需求的落地方式。 三种架构的适用边界，以及「先 Nitro、按需加 Python」的分阶段做法。 Nitro 与 Python 后端：一张总表Nitro 是 Nuxt 的服务端引擎（Node.js）；Python 侧常见组合是 FastAPI 或 Django REST。下表默认对比 Nuxt 4 + Nitro 与 独立 Python API 服务（不与 Nuxt 同仓库时）。 维度 Nuxt + Nitro 纯 Python（FastAPI&#...

一、市场需求（需求度）——确认痛点真实且强烈理论解释：SaaS 成败第一关是「问题是否足够痛」。用户画像 + Y 模型上半部验证「谁、何时、何地、做什么」（场景）→「为什么」（目标/动机）。2026 年 AI 工具可瞬间分析海量数据，但 必须结合临场感（亲自到用户场景观察）。 2026 最新经验：AI 可辅助，但 20+ 深度访谈仍是底线。垂直 SaaS（行业特定）需求更强，增长率远超通用 SaaS。 1.1 关键词与搜索趋势分析 Google Trends：核心关键词 + 目标国家/地区，看约 5 年趋势（上升通常表示需求增长）。 Ahrefs / SEMrush / Similarweb：月搜索量、长尾词、竞争度（KD 值）。 操作：优先高搜索量、中等 KD 的长尾词（如「AI 垂直 SaaS 医疗预约」而非「AI SaaS」）。 1.2 社交媒体与社区调研 Reddit、Quora、Twitter/X、Facebook Groups、Discord、LinkedIn：搜索痛点关键词，统计讨论频率、情绪（抱怨帖多 =...