软件工程——随笔，剖析与展望

第一次的随笔，剖析与展望

---

一、技能树和技术偏好

技能树

• Python 熟练程度 7.5/10 —— 目前的主力语言，做过一些demo级别的项目，熟悉语法用法，和一些常见库与框架如Numpy,Pandas,Pytorch等，现在主要使用在深度学习等科研领域
• C/C++ 熟练程度 5/10 —— 熟悉其语法，常见的STL以及一些常见用法，大部分算法和数据结构也是在这个体系下学习的
• Git 熟练程度 5/10 —— 熟悉基本的版本控制，分支管理等，在实验中搭建了一套基本的worktree的流程
• Neo4j 熟练程度 4.5/10 —— 熟悉基本的增删改查，了解其作为图数据库的应用场景，在一个问答系统项目中使用过
• HTML / CSS 熟练程度 4/10 —— 并不算熟悉，只是能读，能做到对着文档接口去改一些属性
• Go 熟练程度3.5 / 10 —— 最近开始系统学习，主要面向后端开发，目前处于语言基础和Web的入门
• 相关科研 —— 科研方面跟着导师的方向是知识图谱补全相关的方向，对扩散模型，深度学习相关方面有所涉猎，从知识图谱的实体嵌入到，对实体的训练与推理策略有一定的了解，自己也在相关数据集上优化相关的模型基线

技术偏好

1. 后端与 AI 相关技术栈

目前看来，自己更倾向于后端相关的技术栈。相比之下，前端确实有些吃力，可能多少有点 缺乏艺术细胞。

在 Agent 蓬勃发展的现在，我感觉“前端 / 后端 / AI”之间的边界也在慢慢变淡。以后很多开发者可能都需要对不同技术栈有所涉猎，而不是只会自己的一小块。

科研方面我也希望同步推进。在生成式人工智能快速发展的背景下，知识图谱或许仍然能作为一种重要的结构化先验知识，在 Harness 工程、Agent 前置知识库等场景中发挥作用。

2. AI 辅助开发与 Agent 工程

对于 AI 的落地，以及如何驾驭 AI 辅助工作，我现在比较感兴趣的是 Auto-Loop、Agent 工作流以及 Harness 工程。

在实际使用 Agent 的过程中，我逐渐体会到：让 Agent “写出代码”并不是最难的，真正重要的是如何建立一套可靠的工作流程，包括：

• 如何拆分任务；
• 如何给出清晰的约束；
• 如何进行代码 Review；
• 如何设计检查与测试；
• 如何让 Agent 能够持续迭代，而不是一次性生成完就结束。

从以前的提示词工程，到后来的上下文工程，再到现在的 Harness 工程，我们或许越来越需要探索对于AI的使用和落地了

自我评估

1.工程能力欠缺

实际项目经验实在有些缺乏，大部分也只是demo级别的项目，或者课程实践，尚且称得上大的问答系统也只是能跑，也没有参与太多的工作，对软件还是缺乏系统性的认知

2.团队能力的缺乏

几乎都是在单打独斗，哪怕少有的和同学合作的东西，也是大家各干各的然后提交成果拼装就完事了，没有合理的分析，讨论与团队合作

3.创新能力的不足

不管是科研领域或者开发方面，缺少一些出现idea的时机，并且没有持续推进的动力，或许是缺乏对第一性原理的探究，也或者是缺少持续的毅力吧

二、代码量

并没有系统算过真正有多少代码量，从收集了之前的项目以及课程的小demo来说，大概有6000行，同时有很多工作其实是Agent的代劳，大概有10亿token左右

希望这次课程之后代码量能到10000行吧，不过在AI时代的当下或许编码越来越少才是常态

三、对这门课最期待什么

希望能系统接触需求分析、项目设计、Git 协作、测试、部署和维护这些过去比较薄弱的内容，也希望真正参与一次完整的软件项目，而不是停留在“能跑就行”。

另外，在 AI / Agent 越来越普及的现在，我也希望学会怎么更合理地和 AI 协同开发：不仅让它帮我写代码，更重要的是能判断它写得对不对、项目该怎么设计，以及什么时候该信它，什么时候不该信。

如果这门课结束后，我能少一点“先写了再说”，多一点“为什么要这样设计”，以及正确的团队合作，这就是最大的收货了。

四、软件工程学习指南

以下内容由GPT-6 Astra生成

🤖 GPT-6 生成内容

以下是结合这些侧重点整理的学习路线，适合已经掌握一门编程语言和基本数据结构的学生。

1. 理解开发过程与需求分析

   先了解软件生命周期，以及瀑布、迭代和敏捷开发的适用条件。练习区分功能需求与性能、安全、可用性等质量要求，通过用户故事明确“谁需要什么，以及为什么”。

   选择一个小项目，如图书借阅系统，写出核心需求及验收条件。例如，“支持借书”应进一步明确：库存不足如何处理、同一用户能否重复借阅、借阅成功后哪些数据发生变化。

2. 学习规格说明与程序正确性

   借鉴 MIT 6.031，把接口约定作为编码前的重要步骤。掌握前置条件、后置条件、异常行为，以及可变数据与不可变数据的区别；理解抽象数据类型和表示不变式——即内部数据必须始终满足的条件。

   练习为关键函数写清输入、输出和边界行为，并思考：调用者需要知道什么？实现者可以自由改变什么？不合法状态能否通过类型或接口设计提前排除？

3. 掌握模块设计与可维护性

   学习高内聚、低耦合、信息隐藏和职责划分。能把系统拆成边界清晰的模块，并说明它们如何交互。UML 和设计模式按实际需要学习，优先理解它们解决的问题。

   在项目中加入一次需求变更，例如增加预约功能，检查修改是否集中在少数模块。记录设计取舍：为什么这样划分，带来哪些便利，又增加了哪些成本。

4. 把测试融入日常开发

   掌握单元测试、集成测试和系统测试，练习等价类划分、边界值分析及异常场景测试。借鉴 CS169 的测试驱动开发：先为一个小行为写测试，再实现功能，最后在测试保护下重构。

   每修复一个缺陷，都补充能够复现它的回归测试。把覆盖率作为发现遗漏的线索，同时检查测试断言是否真正验证了需求。

5. 练习团队协作与持续交付

   熟练使用 Git 提交、分支、合并和冲突解决，通过任务看板拆分工作，通过代码审查交流设计与发现问题。建立简单的持续集成流程，让每次提交自动执行构建和测试。

   以一至两周为一个迭代周期，每轮交付可运行的小版本，再根据反馈调整。同步维护运行说明、接口文档和关键决策记录，让其他人能够接手项目。

6. 用证据评价工程效果

   借鉴 CMU 17-803，学习提出可研究的问题、选择合适指标，并认识样本偏差、混杂因素及相关与因果的区别。入门阶段可先掌握基础统计和简单研究设计。

   例如研究“代码审查能否减少缺陷”，应明确缺陷如何计数，并考虑任务难度、团队经验等影响。可分析项目记录或开展小规模访谈，形成有数据支持、同时说明局限的结论。

对这份指南的看法

整体看下来我觉得还是比较合理的，至少它抓住了几个我现在确实比较欠缺的点：需求分析、模块设计、测试和团队协作。以前做项目更多还是“先跑起来再说”，对于接口约定、边界条件、后续维护这些东西考虑得并不多，所以这几部分对我还是有帮助的。

尤其是团队协作和测试，我之前几乎没有完整经历过。很多时候所谓合作其实就是大家各做各的，最后拼起来能跑就算成功；测试也基本停留在“点两下没报错”。所以如果这门课真的能让我把这些流程走一遍，我觉得还是挺有价值的。

不过这份指南也有点太理想化了。像规格说明、测试驱动、持续集成、工程实证这些东西都很合理，但如果按顺序一项一项系统学，感觉更像一门完整的软件工程培养方案，不太像一学期能全部吃透的内容。

所以对我来说，这份指南更适合当一个方向参考。真正有用的应该还是在项目里遇到问题，再回头理解这些方法为什么要存在。

五、写在最后

作为第一次的随笔，虽然是作业的随笔，但也让我静下来重新看了一遍自己，居然让我的内心平静了不少，至少没有那么浮躁和焦虑了

过去的两年或许确实没有做出太多东西，也没有参与太多东西，无法做到知行合一才是真正的痛苦，总是想得太多，做的太少。现在或许应该更多的行动起来而不是只是想想，不要想做了有没有意义，大胆去做就是了

希望软件工程这门课，又或是借着当前的氛围，真正的去做一些事情吧