首先附上入门链接：Vibe Coding 入门教程 | 菜鸟教程
今天正式接触到软件工程这门专业课时，对于之前全部依赖ai写代码的我进行了启发。
初步接触各种ai大模型，因为基础薄弱，问题全部依赖ai去完成。但是深入使用发现，总会遇到一些问题，如：
1.一直增加新的功能，ai自己测试自己迭代导致代码出现越来越多的bug，功能不能达到预期要求
2.做出的项目逻辑混乱，可能存在执行效率低下的情况，反复要求ai提升效率收获甚微
3.出错后让ai检查修复时，当逻辑复杂时自然语言可能无法清晰表达出所在问题
4.如果工程量大，需要短时间内开发出成品，团队其他成员较难并行开发
5.新的ai跟进项目开发较为费时费token
今天学习软件工程第一章内容，对于软件生存期模型这个概念有了新的认识和运用的想法
软件生存期模型完整对照总表
| 发展时期 | 模型名称 | 提出年份 | 核心特点 | 适用场景 |
|---|---|---|---|---|
| 概念萌芽期 | 分段模型 | 1956 | 最早的有记录过程模型，划分明确阶段，阶段间有固定输出 | 早期大型军用系统，结构相对简单 |
| 迭代模型（雏形） | 1950年代末 | 允许反复修改和完善，最早实践于SAGE防空项目 | 技术风险高、需逐步验证的复杂国防系统 | |
| SDLC概念确立 | 1960年代 | “系统开发生命周期”术语正式出现，为后续模型奠基 | 大型计算机系统开发的宏观管理 | |
| 经典模型时代 | 瀑布模型 | 1970 | 严格线性顺序，阶段间强依赖；强调前期文档，变更困难 | 需求明确稳定、技术成熟的项目（如政府报表、小型管理系统） |
| 增量模型 | 1971 | 分批次交付独立功能模块（增量），用户可较早看到成果 | 大型项目需快速交付核心功能，需求逐步明确（如电商分期上线） | |
| 演化模型 | 1976 | 从粗糙版本开始，通过用户反馈不断改进，迭代开发早期风范 | 需求模糊、需探索性开发（如科研软件、原型系统） | |
| V模型 | 1978 | 瀑布变体，呈V字形，左侧开发右侧测试一一对应，强调验证与确认 | 质量要求极高、需求稳定（如航空航天、医疗设备、安全关键系统） | |
| 螺旋模型 | 1988 | 风险驱动，四象限迭代（目标→风险→开发→评估），结合瀑布与原型优点 | 大型、复杂、高风险项目（如NASA航天系统、军事指挥系统） | |
| 面向对象与快速开发时代 | 喷泉模型 | 1990 | 面向对象专用，各阶段（分析/设计/编码）重叠且迭代，“无间隙”开发 | 采用面向对象技术（如C++/Java）的项目（如企业级图形界面系统） |
| 基于构件的开发模型 | ~1990 | 复用预制标准化构件进行组装，强调构件库管理 | 需快速搭建、大量复用已有模块（如ERP系统、中间件平台） | |
| RAD模型（快速应用开发） | 1991 | 极短周期（60-90天），大量使用可视化工具和可复用组件，用户深度参与 | 时间紧迫、需求较明确且可模块化的业务系统 | |
| W模型 | 1993 | V模型的发展，强调测试贯穿整个生命周期，开发与测试并行 | 对质量要求高，希望尽早发现缺陷的规范化企业级项目 | |
| 敏捷与DevOps时代 | Scrum | 1995 | 固定周期冲刺（Sprint），三大角色（PO/SM/团队），每日站会与评审 | 需求变化频繁的互联网产品、移动APP开发 |
| 极限编程（XP） | 1996 | 强调工程实践（TDD、结对编程、持续集成），简单设计，小版本发布 | 需求极不稳定、风险高的小型团队（如初创项目、创新产品） | |
| RUP（Rational统一过程） | 1998 | 用例驱动、架构为中心，分四阶段（初始→细化→构建→移交），比敏捷更正式 | 大型企业级项目，需规范又保留灵活性（如银行核心系统、大型政务平台） | |
| 敏捷宣言（统称） | 2001 | 个体互动 > 流程工具，可工作软件 > 详尽文档，客户协作 > 合同谈判，响应变化 > 遵循计划 | 所有需求易变、交付速度要求高的场景（是Scrum/XP等框架的指导思想） | |
| 看板方法 | 2004-2007 | 可视化工作流（看板墙），限制在制品数量（WIP），持续交付，不强制迭代 | 运维支持、维护类项目，需求随时插入、优先级动态变化的场景 | |
| DevOps | 2009 | 开发运维一体化，强调自动化CI/CD流水线，持续监控与反馈 | 云原生应用、微服务架构，需高频部署（每日甚至多次）的生产环境 |
对于学校的各种软件设计类比赛，我们常常面临着开发时间短（往往从报名到交稿在1个月左右），需要因寻找创新点而不断改动。可以采用敏捷开发。敏捷开发模式_百度百科 中的Kanban (看板)方式
看板方法（Kanban Method）完整知识整理
一、起源与演化
1.1 起源：丰田生产方式（TPS）
看板方法起源于日本丰田汽车公司，是支撑其“准时化生产”（Just-in-Time，JIT）的核心管理工具。它由丰田生产之父大野耐一（Taiichi Ohno）在20世纪40年代末至50年代初创立，灵感来源于美国超市的补货机制——货架上的商品被买走多少，就补充多少。
1.2 演化：进入软件开发领域
2004年，大卫·安德森（David J. Anderson）首次将看板概念引入IT和软件开发领域，并在2006-2007年间在Corbis公司得到大规模运用。他将看板从一套物理车间的操作规则，演变为一套适用于知识工作（如软件开发、创意设计）的管理流程与渐进式变革方法。
1.3 两套规则的关系与区别
| 维度 | 丰田生产方式（原始看板） | 大卫·安德森（软件看板方法） |
|---|---|---|
| 本质 | 物理生产现场的操作规范 | 知识工作领域的管理思想与原则 |
| 核心目标 | 实现零库存、准时化生产 | 实现流程顺畅、持续改进 |
| 规则形式 | 六条强制性操作规则 | 四大原则 + 六大实践 |
| 适用领域 | 汽车制造、供应链管理 | 软件开发、创意设计、知识工作 |
二、原始版本：丰田看板的六条规则
这是看板方法最原始、最底层的规则，至今仍在制造业中被严格遵守。
2.1 六条原文规则
| 序号 | 规则原文 | 核心含义 |
|---|---|---|
| 1 | 下游工序仅在需要时，到上游工序领取所需数量的零件 | 后工序拉动前工序，杜绝过量生产 |
| 2 | 上游工序仅生产被下游工序领取走的数量 | 按需生产，不生产多余库存 |
| 3 | 没有看板（请求），就不生产或移动任何物品 | 看板是唯一的生产授权信号 |
| 4 | 看板必须始终与实物在一起 | 看板作为实物标签，确保信息与物料一致 |
| 5 | 绝不将缺陷品传递给下游工序 | 质量内建，不合格品不流向下游 |
| 6 | 看板的数量应逐步减少，以暴露问题并持续改进 | 通过降低库存水位，迫使团队解决问题 |
2.2 核心理念：拉动系统（Pull System）
这六条规则共同构建了一个由下游需求驱动的拉动系统，彻底颠覆了传统的“推动式”生产（即按计划生产，不管是否需要）。其逻辑链条是：
下游需求 → 领取零件 → 上游生产 → 看板循环 → 库存减少 → 暴露瓶颈 → 持续改进
三、演化版本：大卫·安德森的看板方法
当看板进入软件开发领域后，安德森对其进行了适应性改造，形成了一套完整的管理方法论。
3.1 四大基本原则
| 原则 | 核心含义 | 实践要点 |
|---|---|---|
| 原则一：从既有的流程开始 | 不推翻现有体系，在其基础上进行改良 | 尊重团队现有的工作方式，以看板暴露问题而不是强制革命 |
| 原则二：同意持续增量、渐进的变化 | 以小步快跑的方式推行变革 | 每次只改一个环节，验证效果后再推进下一步 |
| 原则三：尊重当前的流程、角色、职责和头衔 | 认可现有组织和人员 | 不强行改变组织结构，减少推行阻力 |
| 原则四：鼓励各层级的领导行为 | 任何人都可以主动发现并推动改进 | 鼓励自下而上的改进，不依赖“领导”指令 |
核心理念：尊重现状，渐进改良，而非“一刀切”式的变革。
3.2 六大核心实践
| 序号 | 实践名称 | 核心含义 | 具体操作 |
|---|---|---|---|
| 1 | 可视化工作流 | 将工作流程和任务状态可视化 | 建立看板墙（物理或电子），用卡片代表任务，在不同列之间移动 |
| 2 | 限制在制品数量（WIP Limits） | 为每个阶段设定并发任务上限 | 为每列设置最大卡片数量，达到上限即停止拉入新任务 |
| 3 | 管理工作流程 | 主动监控和优化整个价值流 | 关注任务在各个阶段的停留时间，主动消除瓶颈 |
| 4 | 让规则明确 | 将工作规则明文化 | 明确写出“完成的定义”（Definition of Done）和进入下一阶段的条件 |
| 5 | 落实反馈循环 | 通过定期回顾来持续改进 | 定期召开回顾会议，分析流程数据，讨论改进点 |
| 6 | 由协作改善，经实验演进 | 团队共同参与，科学推动变革 | 鼓励提出改进建议，通过小范围实验验证后推广 |
四、实施步骤：从零建立看板系统
4.1 五步启动法
| 步骤 | 行动内容 | 输出物 |
|---|---|---|
| 第一步：记录并可视化当前流程 | 画出团队现有的工作流程，不要急于改变 | 当前流程图 |
| 第二步：构建看板墙 | 根据流程图在看板工具上建立对应的列 | 可用的看板墙（物理白板或Trello/Notion等电子工具） |
| 第三步：设定WIP限制 | 为每一列设定初始的在制品数量上限 | 各列的WIP限制数值（可从宽松开始，逐步收紧） |
| 第四步：定义完成规则（DoD） | 明确写出任务进入下一阶段的条件 | “完成的定义”文档或看板上的规则说明 |
| 第五步：运行并持续改进 | 正式使用看板，定期回顾调整 | 定期会议记录、流程优化措施 |
4.2 关键技巧
| 技巧 | 说明 |
|---|---|
| 定义服务类别 | 为不同类型的任务使用不同颜色卡片（如红色=紧急修复，蓝色=新功能，绿色=调研） |
| 建立服务级别协议（SLA） | 与团队约定不同类型任务的期望完成时间 |
| 聚焦系统整体优化 | 目标是让整个工作流更顺畅，而非让某个人更忙 |
| 从宽松WIP开始 | 初期可设置较大的WIP限制，熟悉后再逐步收紧 |