夜雨聆风看完这一篇，你就能听懂程序员在说什么
上期我们讲了「软件开发就像开餐厅」的比喻，这期来填坑——把你在职场/会议上最常听到的 8 个词，用生活化的方式讲清楚。
不讲代码语法，只讲「这个词是啥意思、为什么重要、你会在什么场合听到它」。
看完这期，你就能在技术开发会议上「听得懂、插得上话」。
PRD = Product Requirements Document，中文叫「产品需求文档」。
它就是产品经理写给开发团队看的「详细说明书」——在这个文档里，产品经理要把「我们要做一个什么软件、有哪些功能、每个按钮点进去是什么效果」写得清清楚楚。
你可以把它理解成：建筑工地上的「施工图纸」。没有图纸，工人不知道房子要盖成什么样；没有 PRD，程序员不知道软件要写成什么样。
你要装修房子，会找设计师出一份图纸：哪个房间放床、哪个位置装插座、柜子用什么颜色——都要写清楚。
PRD 就是软件项目的「装修图纸」。如果设计师只跟工人说「给我装得漂亮一点」，工人做出来的效果肯定跟你想要的不一样。PRD 的作用，就是让「漂亮一点」变成「客厅北墙装 3 个五孔插座，距地 30cm」这种谁看了都知道怎么做的明确指令。
- 需求评审会上
：产品经理投影 PRD 文档，一页一页讲给开发团队听：「这个功能要做成这样，大家看看有没有问题？」 - 项目延期时
：开发说「这个需求 PRD 里没写啊！」——意思是产品经理没在说明书里提到这个场景，现在要做就得加钱/加时间。 - 验收阶段
：测试人员拿着 PRD 一条一条核对：「 PRD 说这个按钮要点了弹出确认框，现在没有，这是 Bug。」
如果你是公司业务人员/管理人员：PRD 就是你跟开发团队之间的「合同附件」。PRD 里写了的功能，开发必须做；没写的，他们可以拒绝做（或者要求加钱）。
所以，如果你有需求要提给开发团队，一定要让产品经理写到 PRD 里，光口头说「帮我加个功能」是不可靠的——三个月后没人记得你说过什么。
API = Application Programming Interface，中文叫「应用程序接口」。
你可以把它理解成：软件系统之间互相传递信息的「窗口」或「插座」。
最常见的是「前端和后端通过 API 通信」：
前端（你在手机屏幕上看到的界面）要把数据发给后端（藏在服务器里的程序），或者从后端拿数据，都是通过 API 来完成的。
前厅服务员 = 前端｜后厨厨师 = 后端｜出餐窗口 = API
你在餐厅点菜：
1. 你（用户）告诉服务员（前端）要什么菜
2. 服务员把点菜单从出餐窗口（API）递给后厨（后端）
3. 后厨做好菜，通过出餐窗口（API）递出来
4. 服务员把菜端到你桌上（前端展示数据）
没有出餐窗口会怎样？服务员只能自己冲进厨房拿菜（不安全、容易乱）；或者后厨直接把菜端到大厅（后端直接操作界面，不安全）。
API 就是这个「出餐窗口」——它规定了：只能在这里递菜单、只能在这里取菜，其他地方不能乱窜。
- 前端抱怨时
：「后端 API 还没好，我这边没法调！」——意思是后端同事还没把数据接口做完，前端没法继续写界面。 - 测试出问题时
：「这个 API 返回的数据不对」——意思是后端接口给出的数据跟 PRD 写的不一样，要改。 - 跨系统对接时
：「我们需要提供一个 API 给他们的系统调用」——意思是两个软件系统要互相传递数据，需要约定一个「接口规范」。
如果你是公司管理人员：API 就是你们公司不同软件系统之间「交换数据的管道」。
比如你们公司既有 CRM（客户管理）系统，又有 ERP（财务）系统——如果它们之间没有 API 对接，你就要手动把客户数据从 CRM 导出 Excel，再导入 ERP，费时费力还容易错。
懂了 API，你就能跟技术团队提需求时说：「这两个系统能不能通过 API 打通？」——这显得你很懂行。
Bug 就是指「软件有毛病」——点按钮没反应、数据算错了、页面显示乱了、系统崩溃了……任何「跟 PRD 写的不一样的行为」，都叫 Bug。
为什么叫 Bug？ 据说最早是因为一台计算机里钻进去一只虫子（moth），导致机器失灵——从此就用「Bug」来称呼程序缺陷。
你收了一栋新房子，检查发现：
卧室的灯开关按了没反应（功能缺陷） 卫生间的地砖铺歪了（界面问题） 厨房的水龙头出热水很慢（性能问题）
软件 Bug 也是一样：不一定是大崩溃，任何「跟设计图纸（PRD）不符」的地方，都是 Bug。
- 你试用新系统时
：「哎呀，这个地方有点问题」——你说的「问题」，在开发团队那里就叫「Bug」。 - 开发团队周会上
：「上周修了 12 个 Bug，还有 5 个没修完」——他们是在汇报测试阶段发现的问题的修复进度。 - 上线后用户投诉时
：「你们系统有 Bug，把我数据弄丢了！」——这是最严重的 Bug（数据丢失），必须立刻修复。
Bug 是软件项目的「常态」，不是「意外」。任何稍微复杂的软件，上线时一定有 Bug——就像任何新房子收房时一定有质量问题一样。
所以，不要因为软件有 Bug 就觉得开发团队不专业。重要的是：他们有没有系统地发现 Bug、记录 Bug、修复 Bug。
如果你要评估一个软件团队是否靠谱，问他：「你们用什么工具管理 Bug？」——靠谱的团队一定有专门的 Bug 跟踪系统（比如 Jira、TAPD）。
敏捷开发是一种「不追求一次性做完所有功能，而是分批交付、快速验证、持续调整」的开发方式。
传统开发方式（叫「瀑布模型」）是：
需求 → 设计 → 开发 → 测试 → 上线（一次性全部完成，周期 6-12 个月）
敏捷开发是：
需求（第一批） → 设计 → 开发 → 测试 → 上线（2 周后） → 需求（第二批） → ……（持续循环）
瀑布模型 = 上满一桌菜的正餐
你点完菜，厨房一次性做完，全部上桌你才能开始吃。如果有一道菜很难做，你就要等很久；如果端上来发现味道不对，也没法改了。
敏捷开发 = 火锅
你先点几道菜（第一批需求），厨房做好一盘就端上来（2 周交付一次），你边吃边调整：「这个好吃，再加一份；这个不好吃，后面不点了」。
敏捷开发的核心优势：快速验证、快速调整，不会等到最后才发现「做偏了」。
- 项目启动会上
：「我们这次用敏捷开发，2 周一个 Sprint」——意思是他们打算分批交付，每 2 周给你看一次进度。 - 进度汇报时
：「这个 Sprint 完成了 8 个需求，还有 3 个没做完，挪到下个 Sprint」——意思是这 2 周原计划做 11 个功能，只做完了 8 个。 - 需求变更时
：「这个需求我们放到下个 Sprint 做」——意思是虽然你现在提出了新需求，但他们这个周期已经排满了，要等 2 周后的下一周期才能做。
如果你是公司管理人员/业务人员：敏捷开发对你的最大意义是「你可以更早看到成果、更早提出调整意见」。
如果是瀑布模型，你要等 6 个月才能看到第一版软件；如果是敏捷开发，2 周后就能看到第一批功能，你可以试用了告诉开发团队：「这个方向不对，我们要调整」。
这能大幅降低「做完后发现不是自己想要的」的风险。
Sprint 就是敏捷开发里的「一个工作周期」。
通常 1-2 周为一个 Sprint：团队在这段时间里集中精力完成一批预先约定好的功能，到周期结束时必须交付「可以给用户试用的版本」。
Sprint 的核心规则：
Sprint 开始后，不允许中途加新需求（要加就等下个 Sprint） Sprint 结束时，必须交付可用的功能（不能说到做不到） 每个 Sprint 结束后，团队要开反思会：这次哪里做得好？哪里可以改进？
你要搬家，计划用 2 天时间打包：
- 第 1 天（Sprint 1）
：打包客厅 + 厨房。目标：这两块区域全部装箱完毕。 - 第 2 天（Sprint 2）
：打包卧室 + 卫生间。目标：全部打包完，可以搬家了。
如果中途你妈说「帮我顺便把书房也打包了吧」——这就是「中途加需求」，在 Sprint 里是不允许的，要等到下个 Sprint（下个 2 天周期）才能做。
敏捷开发的 Sprint 就是这个逻辑：每个周期集中精力做完一批事，不要中途被打断。
- 每日站会上
：「今天是 Sprint 第 5 天，还剩 4 天，我现在进度是……」——团队每天同步「我们离这个 Sprint 的目标还有多远」。 - 需求提出时
：「这个需求排不进这个 Sprint 了，我们放到下个 Sprint 吧」——意思是这个周期工作量已经满了，新需求要等 2 周。 - Sprint 结束时的演示会
：「这是我们这个 Sprint 做完的功能，请大家试用提意见」——团队向产品经理/业务方展示这 2 周的成果。
如果你是公司业务人员：懂了 Sprint，你就知道「为什么我的需求不能马上做」。
开发团队不是不想做，而是他们用 Sprint 的方式管理工作——每个周期开始时就承诺了要做哪些功能，如果中途加需求，就会打乱整个计划。
正确的提需求方式：「这个需求大概什么时候能排进 Sprint？」——让他们给你一个预计的周期编号（比如「Sprint 8」），这样你就有明确的预期。
Git 是管理代码版本的工具。
你可以把它理解成：Word 文档的「审阅 → 修订 → 接受/拒绝修订」功能的「超级加强版」——但它不是针对 Word 文档，而是针对程序员写的代码文件。
Git 的核心能力：
记录每一次改动：谁改了哪一行代码、什么时候改的、为什么改 多人协作时不冲突：张三改了 A 文件，李四改了 B 文件，Git 能自动合并 出问题时能回退：如果新版本有 Bug，可以一键回到上一个正常版本
你们团队 5 个人要一起写一份 Word 报告：
- 没有版本管理（不用 Git）
：大家轮流编辑同一个文件，张三改了第一段，李四改了第二段，最后发现张三的改动被李四覆盖了——谁改了什么根本说不清。 - 有版本管理（用 Git）
：每个人改完自己的部分，Git 会自动记录「张三改了第一段，改的时间是今天 14:00，改动内容是……」。如果出问题，可以精确找到是哪次改动引入的 Bug，并且一键回退到改动之前的版本。
- 代码丢失时
：「没关系，用 Git 回退到昨天的版本就好了」——Git 能拯救因为误操作丢失的代码。 - 两人改了同一处代码时
：「这里有冲突（Conflict），要手动合并一下」——Git 无法自动判断该保留谁的改动，需要程序员手动解决。 - 询问代码改动历史时
：「用 Git 查一下，这段代码是谁写的？」——Git 记录了每行代码的作者和修改时间。
Git 是专业软件团队的「标配」。如果一个开发团队说他们「不用版本管理，直接拷文件来回传」——快跑，这不专业。
你可以问技术负责人：「你们用 Git 管理代码吗？有没有代码审查（Code Review）流程？」——这两个问题的答案能帮你判断团队是否专业。
（代码审查 = 程序员 A 写完代码后，程序员 B 要先检查一遍有没有问题，才能合并到主版本——这是保证代码质量的重要流程。）
部署（Deploy）= 把程序员在自己电脑上写好的代码，「搬」到真正的服务器上，让真实用户可以通过互联网访问。
你可以把它理解成：厨师在厨房里做好菜（开发环境），然后通过传菜窗口把菜端到客人桌上（生产环境）。
为什么不能直接用开发环境？
程序员的电脑（开发环境）配置跟真实服务器（生产环境）不一样——就像厨师在厨房里试菜用的是小火，但餐厅里的大灶火候不一样。所以代码写完后，必须经历一个「部署」过程，确保它在真实环境里也能正常工作。
工厂生产（开发环境） → 质量检验（测试环境） → 运送到超市上架（部署到生产环境）
你在工厂里生产了一批饼干（程序员写代码） → 质检员检查饼干合不合格（测试工程师找 Bug） → 把合格的饼干装车运送到超市上架（部署到服务器） → 消费者可以买了（用户可以使用）。
「部署」就是「把饼干从工厂运到超市上架」这个过程。
如果运输过程中饼干碎了（部署出错），超市里就只能下架——这就是「上线后系统崩溃」，必须立刻修复（重新部署）。
- 项目即将上线时
：「我们计划下周三部署，到时候可能会有 10 分钟访问不了」——部署过程中系统会暂时不可用，要提前通知用户。 - 上线后出现问题时
：「先回滚到上一个版本」——如果新版本有严重 Bug，就「部署回旧版本」，让用户至少能用旧的。 - 询问上线计划时
：「你们部署的频率是？」——专业团队通常每个 Sprint 都部署一次（2 周一次），而不是半年才部署一次。
「部署频率」是衡量软件团队成熟度的重要指标。
初级团队：几个月才部署一次（风险高，每次上线都像「大考」） 成熟团队：每个 Sprint 都部署（2 周一次，风险分散，出问题影响小） 顶尖团队：一天部署好几次（像 Netflix、腾讯，每天多次上线新版本）
DevOps = Development（开发） + Operations（运维）的合体。
它的目标是：让「代码写完 → 自动测试 → 自动部署上线」整个过程尽可能自动化，减少人工操作，降低出错概率，加快上线速度。
你可以把它理解成：工厂里的「自动化流水线」——饼干生产出来后，自动装袋、自动装箱、自动运送到超市，不需要人工搬运。
没有 DevOps（手工搬运）：
程序员写完代码 → 手动打包 → 发给运维同事 → 运维手动登录服务器 → 手动停掉旧版本 → 手动上传新版本 → 手动启动 → 手动检查有没有问题
（10 个手动步骤，每个步骤都可能出错）
有 DevOps（自动化流水线）：
程序员写完代码、点击「提交」 → 系统自动运行测试 → 测试通过后自动部署到服务器 → 自动检查上线后有没有问题
（程序员只需要点一次，后面全自动）
DevOps 的核心价值：快 + 稳。快 = 代码写完几分钟内就能上线；稳 = 自动化流程减少了人工操作，大幅降低出错概率。
- 团队说「我们要搭建 CI/CD 流水线」
：CI/CD = Continuous Integration / Continuous Deployment（持续集成/持续部署），是 DevOps 的核心实践——代码一提交，就自动跑测试、自动部署。 - 上线出问题时
：「我们的 DevOps 流程没配好，部署脚本有问题」——自动化流程本身也可能有 Bug，需要专人维护。 - 招人时
：「我们正在招 DevOps 工程师」——这是专门负责搭建和维护自动化流水线的岗位，薪资通常比普通开发高。
DevOps 是区分「业余团队」和「专业团队」的分水岭。
业余团队：部署靠人工，每次上线都提心吊胆，出了问题要花几小时排查。
专业团队：部署全自动化，几分钟内完成，出问题自动回滚，不影响用户。
如果你要外包软件开发，问承包方：「你们有 DevOps/CI-CD 流程吗？」——如果对方答不上来，说明他们可能还在「手工部署」阶段，质量和效率都堪忧。
我们会走一遍软件项目从想法到上线的完整过程
你会看到：立项会上大家在争论什么、需求评审时产品经理最怕什么、为什么测试要花这么长时间
用「你作为××角色会经历什么」的方式来讲，保证你能代入
课程 1/5 ｜ 基本概念篇
预计阅读时间：10 分钟
下期：课程 2/5 ｜ 项目流程篇