软件工程
研究以系统化、规范化、可度量方法开发和维护软件的工程学科，涵盖需求分析、领域建模、架构设计、集成、调试与长期维护，核心职责是管理复杂系统的熵增与结构退化
核心事实
时间轴 (近 90 天)
软件工程发展经历了三个阶段：手写代码时代（价值在语言、算法和系统细节）、框架与云服务时代（价值转向架构设计与服务编排）、AI编程工具普及时代（差异化优势向问题定义、系统约束设计和质量判断转移）。
编码（coding）和软件工程（software engineering）是两件事：前者是把逻辑翻译成可执行代码，后者是在约束条件下做取舍。
决定“构建什么”以及“为谁构建”仍然是人类的部分。
软件工程缺乏像国际象棋那样快速、客观的胜负信号（记分牌），因此难以验证高级开发者的干预是否让系统变得更好或更糟。
与棋类不同，软件工程的价值判断更模糊，取决于需求、可维护性、用户体验等多维因素，且反馈周期长。
现代软件系统的复杂度早已不是单靠语言层面的控制力就能解决的，工程化协作和内存安全才是当前更紧迫的问题。
软件工程黄金法则：永远不要存储能从已有数据推导出来的信息。
Dry-run（空运行）是软件工程中常见的预演模式：程序完整执行逻辑但不产生副作用，只输出将要发生的变化。
重复性的CRUD开发、模板化的前端页面、简单的脚本任务正在快速被AI压缩。
Pocock认为软件工程基本功在AI时代变得更重要，因为Agent的运行环境就是代码库本身，垃圾代码库会导致垃圾产出。
还有 40 条时间轴事件
全部知识事实 (20)
AI生成的代码在功能逻辑上可能正确，但在性能优化、异常处理、安全加固等工程细节上往往存在不足
80%已验证AI代码审查工具正从一刀切的自动化走向更精细的可控性方向演进
80%已验证研究表明错误在需求和设计阶段被发现的修复成本仅为代码阶段的1/10到1/100
75%已验证AI 生成的应用应经过仔细审查和测试，尤其涉及客户信息或业务交易时；身份验证、数据库权限、安全性、可访问性、错误处理和数据验证仍然不可省略。
65%已验证可观测性意味着系统从用户输入、意图识别、工具调用到最终输出的每个环节都可追踪、可度量
65%已验证代码审查（Code Review）是指在代码合并到主分支之前，由团队成员对代码变更进行系统性检查的实践
65%已验证斯坦福大学、MIT等机构的研究显示，在AI辅助编程场景中，需求描述的精确性比技术背景更显著地影响最终代码质量
65%已验证边界条件测试（Boundary Value Analysis）是软件工程中质量保障的核心方法论之一
65%已验证软件工程师的核心价值将从代码编写转向需求理解、架构设计和系统权衡等上游决策工作
70%待验证大量软件故障发生在输入值处于极端情况时，例如空字符串、零值、最大整数溢出等场景
90%待验证软件工程领域的经典研究表明，代码编写仅占软件总生命周期成本的约20%，而维护占据了剩余的80%
80%部分验证开发者与AI的协作模式正在从逐行辅助向项目级理解演进
80%待验证某些长期运行的企业级系统维护成本可达初始开发成本的4-5倍
60%待验证这六个维度对应软件工程中需求分析的经典框架：用户故事、业务上下文、问题定义、迭代范围、非功能性需求、技术约束
60%待验证工程师在棕地项目（Brownfield project）中约60-70%的时间花在理解现有代码上，而非编写新代码
60%待验证软件工程发展经历了三个阶段：手写代码时代（价值在语言、算法和系统细节）、框架与云服务时代（价值转向架构设计与服务编排）、AI编程工具普及时代（差异化优势向问题定义、系统约束设计和质量判断转移）。
50%待验证编码（coding）和软件工程（software engineering）是两件事：前者是把逻辑翻译成可执行代码，后者是在约束条件下做取舍。
50%待验证与棋类不同，软件工程的价值判断更模糊，取决于需求、可维护性、用户体验等多维因素，且反馈周期长。
50%待验证软件工程缺乏像国际象棋那样快速、客观的胜负信号（记分牌），因此难以验证高级开发者的干预是否让系统变得更好或更糟。
50%待验证决定“构建什么”以及“为谁构建”仍然是人类的部分。
50%