期末回看：我能回答学期初提出的问题了吗？——从 Cax 的 Alpha/Beta 到课程方法的反思
https://blog.csdn.net/RNA12345/article/details/152977972?spm=1001.2014.3001.55011) 回到学期初：我当时提出了哪些问题？
我在学期初阅读《构建之法》后，提出了 5 个核心问题，分别围绕沟通、需求、计划、领导、AI 时代的竞争力展开。
2) 经过大半学期实践：我对这 5 个问题的“现在答案”
问题一：为什么多数软件团队不是输在技术，而是输在沟通？
现在我的答案更具体了：沟通失败不是“没说话”，而是“没有形成可执行的共识与反馈回路”。
在 Cax 的 Alpha/Beta 里，我们最明显的体感是：只要缺少“每日对齐 + 明确验收标准 + 可追溯记录”，沟通就会退化成“各自以为对方懂了”。这也对应课程里提到的需要建立更明确的验收标准，避免“写完代码就算完成”。
问题二：需求分析是不是最容易被忽视却最致命的环节？
现在我的答案是：需求不是文档，而是“典型用户在典型场景下能否顺利完成关键任务”的可验证假设。
我们在 Beta 回头看新闻稿/愿景时，发现最容易走偏的是：做了很多“看起来有用”的功能，但没有把“用户第一次跑通”的路径当作第一优先级。只要把需求改写成“30 分钟内跑通一次示例、失败可恢复、结果可复现”，团队决策会清晰很多。
问题三：为什么很多项目“看起来要完美”，却失败得最快？
现在我的答案偏工程化：完美主义常常意味着把风险拖到最后爆炸。
我们经历了人员变化导致的计划被打乱、需求缩减后重启，这迫使我们接受一个现实：先交付“可用且可验证”的最小闭环，再迭代优化。课程期中反馈里也点到了“建立 MVP 思维、停止无效的完美追求”。
问题四：Leader 到底该“指挥”还是“引导”？
现在我的答案是：在学生项目/小团队里，Leader 的价值更多体现在**“让系统持续运转”**，而不只是“拍板”。
具体就是把不确定性变成机制：
- 每日同步把风险前置；
- 把任务拆成可验收的交付物；
- 用文档/Issue/测试来让共识“落地”。
这更接近“构造一个自然的、有批判精神的学习环境，让大家一起提问、尝试、反馈、总结”的思路。
问题五：AI 盛行时，程序员的核心竞争力是什么？
现在我的答案是：提出正确问题 + 设定验收标准 + 组织证据链（测试/数据/复现）。
期中反馈里提到的“假借 AI 之手的虚假繁荣”非常准确：如果只让 AI 生成、自己不理解、不验证，后期维护会反噬个人成长。
所以我的结论是：AI 让“写代码”更便宜，但让“定义问题、证明正确、保障质量”更重要。
3) 仍未完全解决、甚至更困惑的部分
我仍然没有彻底解决的，是如何用最小成本获得足够真实的外部用户反馈：
- 在真实科研/HPC 环境里，部署、数据规模、资源调度都更复杂；
- “同学试用”能发现一部分 UX 问题，但未必代表目标用户的真实工作流。
我现在至少更清楚：这不是靠“多做功能”解决的，而是靠更早、更频繁、更贴近真实场景的验证解决。
4) AI 时代带来的新问题（本学期结束时我新增的困惑）
- AI 生成代码的责任边界：出了线上问题，如何追溯决策与变更理由？如何写出“可审计”的工程记录？
- 质量与速度的再平衡：当产出速度提高后，测试、CI、发布流程反而会成为主要瓶颈。
- 个人能力如何被衡量：当“能写”不稀缺时，个人价值更像是“能把事情做成”：需求澄清、拆解、验证、交付与运营。
5) 我对 NCL 理想教学环境与本课程方法的评价
我理解的 NCL（Natural Critical Learning Environment）核心是：让学生在真实任务与挑战中，通过质疑、尝试、反馈与总结来学习，而不是只接收结论。
对应到本学期的教学方法，我的感受是：
- 公开博客交作业、过程追踪：强制把过程暴露出来，促使我把“想法”变成“证据与交付物”，这是最接近 NCL 的部分。
- 结对编程、API 驱动、现场 UX 测试：把“写代码”变成“对用户负责”，也逼迫我面对真实的不确定性。
- 学生自组队选题、Alpha 后（部分团队）人员变动：非常贴近真实软件团队的组织复杂度（虽然我们团队因人数少免于变动，但旁观也能学到教训）。
- 专家讲课 + demo、天使投资式评选：把“讲道理”拉回到“用结果说话”，对建立工程直觉很有帮助。
差距也很明显：当任务密度上来后，我仍然会出现“文档/复盘堆到最后”的倾向；而期中总结也指出了这种“把工程习惯当作临时任务而非日常系统”的问题。
如果课程能进一步把“CI、发布、质量门禁、验收标准”的示范做成更强的默认路径，可能会更接近我理想中的 NCL：不是靠提醒，而是靠环境本身推动。
6) 对照自我评价表：我提升最大的几项能力
我参考了课程提供的“软件工程师能力自我评价表（2025 AI-Native 版）”，它强调通用工程能力与 AI 时代的权衡、沟通与工程化。
我自认为提升最明显的 3 点是：
- 需求到交付的转化能力：能把“想做的功能”改写成“可验收的用户任务”。
- 工程化习惯：开始重视 DoD、回归测试、发布与复现材料，而不只关注功能实现。
- AI 的正确用法：从“让 AI 写代码”转向“让 AI 辅助澄清需求、生成测试用例、做代码审阅与文档草稿”，同时自己承担验证责任。
结语
学期初我提出的问题，现在大多能给出“可落地的答案”，而不是停留在概念层面；少数问题仍未解决，但我至少知道接下来要用什么方式继续验证。对我来说，这门课最大的价值是：把软件工程从“道理”变成了“亲身体验过的代价与方法论”。
)
)
)