期末回望：那些我曾提出的问题，如今我已能作答 #

这篇博客回应我的第一次作业，记录一个学期后我对这些问题的重新思考。

一、学期初的五个问题，如今的答案 #

问题1："做中学"是否加剧两极分化？ #

当初的看法：我担心"做中学"会让强者愈强、弱者愈弱，形成"信心缺口→不敢提交→得不到反馈→更不敢提交"的死循环。

如今的回答：不完全准确。两极分化确实存在，但"做中学"不是罪魁祸首，缺少"安全网"才是。电梯调度项目中，我和搭档都是初次接触API驱动开发，前三天几乎天天报错。但我们建立了"每日15分钟站立会议"机制，互相展示失败，把"踩坑"变成共享经验。这种透明化的脆弱性展示，反而让基础弱的同学敢于暴露问题、获得即时反馈。

真正的解决之道不是放弃"做中学"，而是在课程中嵌入"失败复盘"环节。当失败被正常化、公开化，两极分化才会从"能力差距"转化为"学习资源"。

问题2：专与精是否对立？ #

当初的看法：我认为专与精是"先广后深"的两个阶段，全栈是设计时的鸟瞰图，专精是交付时的施工图。

如今的回答：这个理解基本正确，但我忽略了时间维度的残酷性。AI厂房项目中，我作为核心工程师，前期负责微服务拆分（全栈视角），后期深耕鉴权模块（专精）。问题在于，16周的课程周期太短，刚完成"广"的铺垫，就必须立即转向"深"，没有给我在专精领域"反复打磨"的时间。

专精需要"冗余时间"来沉淀——写三遍、重构两遍、优化一次。课程节奏让这种"奢侈"无法发生。所以我的修正答案是：专与精不矛盾，但"快速切换"会削弱深度。理想状态应是"一学期全栈，一学期专精"，而非"16周内既要又要"。

问题3：代码规范是否会限制创造力？ #

当初的看法：我认为规范是"把个人灵感转译成他人可感知的信号协议"，早期可以"非法"，后期再"重采样"。

如今的回答：这个比喻很美好，但现实是——你永远不会有"后期"。电梯调度项目中，我为赶进度，前期写了大量"非法"变量名和硬编码，想着"Alpha后再重构"。结果Alpha后人员变动，新成员直接在我的"技术债"上开发，规范再也无法统一。

规范不是"后期约束"，而是第一行代码就存在的债务管理工具。我现在认为：创造力应该在规范框架内爆发，而非在框架外裸奔。规范不是天花板，而是地板——它决定了你的代码能否被他人安全地继承。

问题4：敏捷的尽头是"敏捷免疫"？ #

当初的看法：我认为当敏捷变成制服，就应该定期让团队"脱离Scrum"，用任何方法交付，数据说话。

如今的回答：这个想法太理想化了。AI厂房项目后期，团队确实尝试"脱离站会，各自为战"，结果不是"更高效"，而是 "更沉默的灾难" 。三天后，我作为核心工程师才发现前端接口已经改了一版，后端还按旧协议对接，导致整整一天的时间浪费。

敏捷的尽头不是"逃离敏捷"，而是让敏捷仪式变成"肌肉记忆"。当站会、故事点变成"不得不做"的形式，恰恰说明你从未真正理解它们的价值。真正的免疫应该是：即便没人要求，你也会自发地每日同步、小步提交、频繁集成。仪式可以废除，但习惯必须留下。

问题5：伦理责任是底线还是天花板？ #

当初的看法：我认为伦理是护栏，限制技术冲动，换来公众信任。

如今的回答：这学期让我意识到， "伦理责任"正在从静态底线变成动态天花板 。在AI厂房项目中，我们使用开源模型进行租客信用评估。起初只关注准确率，后来发现模型对特定地域有隐性偏见。修复这个偏见需要重写特征工程，导致项目延期一周。从商业视角看，"底线"已满足（不违法）；但从职业尊严看， "天花板"被抬高了 ——你必须主动追求公平，而非被动避免违法。

更复杂的是，伦理责任正在从个人选择变成系统成本。

二、AI时代的新困惑 #

困惑1：责任真空 #

当Copilot生成的鉴权代码存在SQL注入风险，而我在Code Review时未发现，最终导致AI厂房项目的数据泄露——责任链条在哪里断裂？

是AI工具的提供者（OpenAI）？是代码的直接作者（我）？还是审查者（我的搭档）？传统软件工程有清晰的"作者-审查-测试"责任链，但AI的介入让 "创作意图"与"代码实现"分离 。困惑在于：在《IEEE软件工程职业道德规范》中，"仅按被授权方式使用数据"这条原则，是否要求我必须向下游用户披露"本代码30%由AI生成"？

困惑2：协作边界模糊 #

结对编程中，我和搭档都使用AI辅助。Code Review时，我们发现彼此生成的代码风格高度相似（都用了AI推荐的工厂模式）。这让我们失去了思维碰撞的价值——AI成了我们的"共同导师"，导致解决方案趋同。

更严重的是，如何区分"AI的思考"和"人的思考"？ 当我在电梯调度项目中设计SAGA算法时，核心成本函数是我手写的，但异常处理是AI生成的。如果系统出bug，我该如何证明"这部分逻辑我充分理解"？

三、本学期教学方法的NCL视角点评 #

千帆竞发图：公开透明但动能不足 #

NCL理想强调"自然、社区、学习"。千帆竞发图确实构建了可视化社区，让我直观看到团队项目的位置。但它的动能不足——图是静态的，只能展示"进度"，无法展示"挣扎"。如果能在图上标注"当前阻塞问题"，让其他团队主动认领帮助，才能真正激活社区价值。

结对编程：API驱动下的思维透明 #

NCL倡导"协作中学习"。电梯调度项目中，我和搭档严格践行"驾驶员-领航员"模式，API契约成了我们的共同语言。设计接口时，我们必须把模糊的想法（"电梯要智能"）转化为清晰的JSON字段（direction、load_factor），这个过程本身就是隐性知识显性化。但NCL理想中"跨角色对话"的广度还不够——我们没有机会和产品经理、真实用户对话。

pq问答与现场测试：即时反馈但缺乏容错 #

NCL理想中的"安全网"在此体现：现场测试让我立即知道自己的UX设计哪里反直觉。但问题在于，反馈是单向的——老师告诉我们"错了"，却没有时间让我们"再试一次"。如果能给每个学生3次修改机会，这才是真正的"做中学"。

自行组队+强制变动：模拟现实但过于温柔 #

AI厂房项目团队是我私下召集的，这确实模拟了"自发组建创业团队"的真实场景。但Alpha后的强制变动影响太小——我们只走了一个人，补充了一个新人，没有发生"核心工程师被挖走"的剧烈变动。现实职场中，团队重组往往伴随知识断层，而课程中的变动更像是"微调"，没能充分演练知识沉淀与交接的残酷性。

业界专家讲课：拓宽视野但难以内化 #

专家分享了行业最佳实践，确实让我见识到"生产级平台"的标准。但NCL理想强调"研产互促"——如果专家能持续跟踪我们的项目，在Alpha阶段给出针对性反馈，而非一次性讲座，从"知道"到"做到"的转化率会更高。

天使投资评选：多维度但形式大于内容 #

确实要考虑"商业价值"、"团队持续性"等课堂作业无需考虑的因素，这很好。但评选时间太短（每组10分钟），更多变成"演讲技巧"比拼。NCL理想中"真实用户参与"缺失了——如果评委里真有厂房租赁公司CTO，他的质疑会让我们真正理解"市场"与"技术"的差距。

四、能力提升自评：从2分到4分的跨越 #

根据《软件工程师能力自我评价表》，我快速评估提升最大的两个维度：

维度2：AI原生架构与沟通设计 #

学期初：2分（结构设计者）——能划分模块，但接口定义模糊，文档只有函数名。

学期末：4分（认知对齐专家）——在电梯调度项目中，我撰写了完整的架构决策记录，用"JSON契约"让搭档理解SAGA算法；在AI厂房项目中，我设计了微服务接口规范，并通过RACI矩阵明确各服务负责人。关键突破是学会 "用代码本身沟通" ——接口即文档，类型即约束。

维度6：工程领导与系统权衡 #

学期初：1分（问题识别者）——只能模糊感知"项目太慢"，无法拆解。

学期末：3分（方案架构师）——在AI厂房项目Alpha阶段，我将"完成鉴权系统"拆解为"JWT实现→Redis缓存→网关集成→安全测试"四个可衡量任务，估算各任务ROI，优先级排序，并向团队清晰同步。虽然还没达到4分，但已学会 "在有限时间内做减法" ——放弃完美主义，交付可用版本。

五、结语：从提问者到解答者，再到新的提问者 #

学期初，我是站在岸边的观察者，抛出5个疑问。学期中，我是跳进水里的实践者，在结对编程中学会沉默的默契，在团队项目中经历"人员变动"的阵痛。学期末，我是带着新困惑的反思者——AI时代的软件工程，不仅需要回答"怎么做"，更要回答"谁负责"。

感谢这门课让我明白：工程不是写代码的艺术，而是"在约束下为模糊不清的问题找到可衡量的解决方案"的艺术。NCL的理想环境或许难以完全实现，但"做中学"至少让我触碰到了真实问题的粗糙表面——这已经足够。

"现代软件工程"的终点，不是成为一名完美的工程师，而是成为那个"当问题出现，知道自己该问什么，该找谁，该承担什么"的人。