个人博客

从“赛博松鼠”到“优先级工程”：用一学期回答我对软件工程的五次追问（以及更多新问题）

学期初提问原文链接：https://ld246.com/article/1760237997810

0. 我这一学期最重要的“转变”：从问“理论是什么”到问“我怎么做决策”

学期初读《构建之法》时，我的困惑集中在“软件工程到底能不能成熟”“AI 时代‘足够好’怎么算”“复杂性是不是宿命”“CS/SE 谁指导谁”“SE 是不是本质上人的工程”。

而这一学期真正改变我的，是课程把我从“读书提出宏大问题”拽进了“每周都要做决策”的现实：选题、组队、写接口、对齐需求、做 UX 测试、发博客、做演示、经受评价……最后我发现：很多问题并不是靠一句理论回答，而是靠一套能持续做权衡的机制来回答。

也正是在这种语境下，我写了那篇“标题党”宣传帖：我一直不理解为什么没人做本地文档/笔记的优先级管理与推荐系统——因为那其实是“权衡机制”的一个缩影：信息爆炸下，最难的不是“有没有材料”，而是“下一步做什么最划算、最不痛苦”。
（项目仓库： https://github.com/ebAobS/roaming-mode-incremental-reading ）

1. 学期初的五次追问：现在我能回答了吗？

Q1：软件行业的“成熟阶段”是伪命题吗？

现在的回答：不是伪命题，但它是“局部成熟、整体周期性返祖”。

这一学期让我更确信：软件业不像航空那样整体线性成熟，而是会在“平台/范式”切换时整体回到探索期；但在每个稳定平台内部（某套架构、某类应用、某个行业场景），工程化程度又确实能不断成熟。

我自己的体感来自两件事：

• 课程项目的推进，让我看到：哪怕需求变动、人员变化，工程化流程（接口约定、代码评审、演示节奏、测试反馈）依然能“托底”。
• 而我做“渐进阅读插件”时，也同样经历了：想法很探索，但只要把问题拆成“优先级管理 + 推荐算法 + 可视化看板”，就能在本地知识库这个小环境里形成稳定迭代。

结论是：软件工程的成熟不是“行业终态”，更像一种可迁移的能力——当范式变了，我们带着能力重新成熟一遍。

Q2：AI 时代“足够好”的标准要重定义吗？

现在的回答：要，而且重定义的核心不是“多加几个指标”，而是把“人类监督”做成工程系统。

学期初我担心 AI 会带来“质量幻觉”。现在我更具体地理解了“监督”是什么：

• 不是一句“人审一下”，而是把监督落实为可检查的工件：需求说明、接口契约、测试用例、演示脚本、用户反馈记录、上线回滚预案。
• AI 生成代码能很快，但它最擅长的其实是“局部最优输出”；而“足够好”取决于上下文、边界、代价——这些必须由团队通过流程把控。

所以我现在更愿意把“足够好”拆成三层：

1. 可用性：功能跑得通、体验不劝退（UX 测试非常关键）
2. 可控性：错误可观测、问题可回滚、风险可沟通
3. 可解释的责任链：出了问题能追溯是谁在何时做了什么决策（这点在 AI 参与后更重要）

Q3：复杂性是宿命，还是工程方法不足？

现在的回答：本质复杂性存在，但最值得打的仗永远是“人为复杂性”。

这学期我更清楚地感受到：很多“难”，不是技术本身，而是：

• 需求没对齐 → 返工
• 接口没写清 → 扯皮
• 任务没拆好 → 卡住
• 文档没同步 → 新人无法接手

这就是典型的人为复杂性。

我做渐进阅读时也有同样的感受：信息量巨大并不等于复杂；真正让人崩溃的是你不知道下一篇该看什么、看不完还内疚。所以我把“渐进阅读的核心”定义为“稍后阅读”，而稍后阅读的核心是优先级管理 + 推荐算法。这本质上是在用系统对抗人为复杂性（心理压力、决策疲劳、路径依赖）。

Q4：CS 与 SE 的关系会变成“实践催生理论”吗？

现在的回答：在 AI 相关领域，“实践领先”是常态；但这并不贬低理论，而是在改变学习顺序。

课程的价值在于：它强迫我先“做出来”，哪怕粗糙；再用理论解释与修正。
这跟 AI 领域很像：先堆数据算力做出效果，再补理论解释。

因此我对自己的学习顺序也改了：

• 先做可运行的最小闭环（MVP）
• 再用理论校正边界与优化方向
• 最后沉淀可复用的方法（文档、规范、组件）

Q5：软件工程的本质是“人的工程”吗？

现在的回答：是，而且 AI 越强，越是“人的工程”。

AI 会把“写代码”这件事越来越像“调用能力”，但它不会自动解决：

• 谁负责定义问题？
• 谁对风险买单？
• 谁协调冲突与优先级？
• 谁对用户体验负责？

这一学期最让我信服的一点是：所有关键节点都是人与人的协作与决策。
甚至我做“推荐系统”这种看似技术味很浓的东西，最后真正要解决的也是“让人更愿意开始、不会被卡住、不会有压力”——仍然是人的问题。

2. 哪些问题没被回答，甚至困惑更大了？

有两个困惑变得更大：

1. AI 时代的“责任归属”怎么工程化？
   当需求、设计、代码、测试中都有 AI 参与时，出了事故到底如何追责、如何复盘、如何改流程？我现在觉得这会成为软件工程的新主线之一。
2. “效率”是否会反过来吞噬“质量”？
   AI 让产出速度飞涨，但团队是否会因为“做得太快”而跳过必要的讨论、测试和用户验证？如果节奏被加速到来不及思考，软件工程反而可能退化。

3. 对 AI 时代的软件开发，我新增了哪些问题？

我目前新增的三个问题更偏“工程落地”：

1. Prompt / 规范 / 测试用例，谁是新的“源代码”？
   当 AI 生成代码越来越容易，真正稳定可复用的资产可能是：接口契约、测试集、需求与约束、评审标准。那我们应如何版本化、评审、复用这些“上游资产”？
2. 如何设计“抗幻觉”的开发流水线？
   比如：强制验收清单、对关键模块做双实现比对、属性测试、变更影响分析……哪些机制最划算？
3. 团队能力结构会怎么变？
   未来的“强工程师”更像产品/架构/质量的综合体：懂业务、懂边界、懂风险、懂协作。那我们训练的重点是不是也要迁移？

4. 对 NCL 理想教学环境的点评：本学期方法的价值与差距

老师学期初传递的 NCL 理想教学环境：
https://www.cnblogs.com/xinz/archive/2011/12/29/2306652.html#ncl

我的体感是：本学期很多方法确实在逼近 NCL 的关键精神——公开、反馈、真实、迭代、协作。下面逐条点评：

4.1 公开博客交作业 + 千帆竞发图跟踪

价值很大：

• 公开发布迫使我把“脑中想法”变成“可读的工件”；
• 同学之间天然形成对标与借鉴；
• 进度可视化（千帆竞发图）把“拖延”变成可被看见的事实。

差距：

• 公开写作对内向同学压力更大；
• 有时会为了“可展示”而牺牲“真实探索的混乱过程”。

4.2 结对编程的 API 驱动编程

价值：

• 强迫我们用“接口”对齐协作，而不是口头约定；
• 很贴近真实工程：先定义契约，再并行开发。

差距：

• 如果前期需求不稳定，API 定得太早会导致返工；
• 对初学者来说，接口设计的门槛偏高，需要更细的脚手架示例。

4.3 pq-问答的当堂测试、对软件 UX 的现场测试

价值：

• 把“好不好用”从主观争论变成现场证据；
• pq 让人保持学习密度，避免“只做项目不长知识”。

差距：

• 现场测试时间短，容易测到“第一印象”，但测不到“长期留存”；
• 需要更结构化的指标模板（例如可用性问题分类、严重度分级）。

4.4 学生自行组队并选择项目

价值：

• 强烈的 ownership：项目是我选的，所以我愿意扛；
• 更接近真实创业/真实团队生态。

差距：

• 自由度越高，资源差距越显著：有人有经验/有人很新；
• 更需要“最低保障机制”（比如需求模板、迭代节奏、角色分工建议）。

4.5 alpha 后强制团队人员变动

价值：

• 非常真实：工程里人员流动是常态；
• 强迫团队把“知识”写下来，而不是只存在某个人脑子里。

差距：

• 如果文档与交接机制不足，会造成短期效率大幅下滑；
• 需要更明确的交接清单（代码结构、部署方式、关键决策记录、风险列表）。

4.6 业界专家/老师/工程师来讲课 + demo

价值：

• 给了“真实标准”的参照系，避免闭门造车；
• demo 能快速建立直觉：什么叫成熟的工程呈现。

差距：

• 如果能把专家反馈与项目里程碑绑定（例如“专家评审前必须准备哪些材料”），效果会更强。

4.7 “天使投资”式评选成功团队项目

链接（老师提供）：https://alidocs.dingtalk.com/document/edit?docKey=jP2lRYjaAy5zAO8g&dentryKey=7G8B2mrGsrq587rx&type=d

价值：

• 把“价值叙事”拉进来：不仅要能做，还要能讲清楚为什么值得做；
• 迫使团队思考用户、市场、差异化与路径。

差距：

• 容易让团队在后期过度追求“故事好听”，而忽视工程基本功；
• 需要一个平衡：投资视角 + 工程质量视角双评分。

4.8 对期中反馈的补充

同学期中反馈（老师给的入口）：
现代软件工程 - 2025 年秋 - 期中学生总结和反馈 - SoftwareTeacher - 博客园

我想补一句：这门课最像真实世界的地方，恰恰是它“不舒服”。
不舒服来自公开、来自不确定、来自协作成本、来自迭代压力。但软件工程本来就不是“舒服的考试学科”，它就是在约束里做权衡。

5. 基于“软件工程师能力自我评价表”的快速自评：我提升最大的部分

（我这里不逐项照抄表格，因为每个人表格版本可能略不同；我挑我自己变化最大的几个维度。）

1. 需求澄清与范围控制（提升最大）
   从“想到什么做什么”，变成“先写清楚做什么、不做什么、验收标准是什么”。
2. 团队协作与沟通
   更能接受分歧与不确定，学会用文档/接口/任务拆分来降低沟通成本。
3. 以用户为中心的验证意识（UX/反馈）
   以前我会默认“功能实现=成功”，现在更在意“用户是否能顺利完成任务、是否愿意继续用”。
4. 工程化表达能力（写作/演示/复盘）
   博客写作、公开展示、阶段总结，让“能做”变成“能被理解、能被接手、能被评估”。

6. 我把“渐进阅读/优先级管理”当成软件工程的一种隐喻

我在宣传帖里说：渐进阅读的核心不是对抗遗忘，而是无压力的稍后阅读；稍后阅读的关键是优先级管理 + 推荐算法。

回头看，这几乎就是软件工程项目管理的同构问题：

• 需求/任务像文章一样无限增长；
• 你不可能一次性学完/做完；
• 你需要一个系统持续告诉你：下一步做什么最合理，并允许你随时调整权重而不崩溃。

所以我现在更相信：软件工程的很多“宏大理论”，最终要落到一个很朴素的问题上——如何让团队在信息爆炸与不确定中，持续做出相对正确的下一步。

7. 结语：我现在更少纠结“答案”，更在乎“机制”

学期初我想要的是五个问题的标准答案。
学期末我得到的是一种更实际的收获：把问题转化为机制，把机制落实为工件，把工件放进迭代。

当然，AI 让一切都变得更快、更强，也更危险。
但我目前的信心来源于：无论技术如何变，软件工程最核心的能力仍然是——在约束里做权衡，并且让权衡变得可沟通、可验证、可复盘。