对学校现存教育方式的反馈
对学校现存教育方式的反馈：很多老师的教育不讲为什么，就灌输一些死记硬背的知识，学过就忘，也不理解为什么，难以真正应用实践。
在学校中碰到的师生关系：一些老师就是为了完成教学任务，学生就是为了学分任务，两个人为了各自的任务随便水一水课程就结束了。
我期待的师生关系：老师把课程和实践结合起来，能够真正让学生理解并应用所学的知识；另一方面期待老师可以利用自己对知识的融会贯通把知识有体系的，生动形象的传授给学生。
对《构建之法》的一些思考
问题一：AI 是否真的能“驯化”而不是“取代”软件工程师？书中对“提示词工程师”的否定是否过于乐观？
引用章节：第3章《软件工程师的成长》3.5.3节（第457–482行）
原文节选：“成为软件工程师，而不是提示词工程师……AI不是来抢我们饭碗的，而是来……能驾驭AI、去解决真正复杂问题的软件工程师。”
我的问题：在当前大模型能力快速演进的背景下，是否真的存在一条清晰的界限，让“提示词工程师”无法胜任“真正复杂问题”？如果一个工程师能通过精准的提示词组合、上下文控制和迭代反馈，稳定产出高质量、可维护、可测试的系统级代码，他是否仍算“非专业”？
支持资料：
- 网上有一些不懂编程的人，仅仅依靠提示词完成了一个很受欢迎的应用，实现月入百万。
我的困惑是：如果“驾驭AI”本身就需要深厚的系统理解、调试能力和架构判断，那“提示词工程师”和“软件工程师”的区别是否只是工具链不同，而非能力层级？
问题二：结对编程中“Driver/Navigator”角色，在AI作为“永恒Navigator”时是否还有意义？
引用章节：第4章《两人合作》4.5节（第292–450行）
原文节选：“Driver负责敲代码，Navigator负责思考整体结构、指出潜在错误……不间断地复审。”
我的问题：如果AI能7×24小时担任Navigator（如实时代码审查、架构建议、边界条件提醒），人类结对编程的价值是否被削弱？是否应转向“人+AI结对”而非“人+人结对”？
支持资料：
- Cursor、CodeWhisperer等工具已实现“AI结对编程”，能实时解释代码、建议重构、检测安全漏洞。
- Google 2024年内部实验显示，在简单模块开发中，人+AI组合的缺陷率低于人+人结对。
问题三：书中强调“代码是写给人看的”，但在AI时代，是否应转向“代码是写给AI看的”？
引用章节：第4章《两人合作》开头引用（第6行）
原文：“Programs must be written for people to read, and only incidentally for machines to execute.”（SICP）
我的问题：当AI成为主要的代码阅读者、调试者甚至协作者时，我们是否应重新定义“可读性”？例如，是否应优先使用AI更容易理解的命名、结构或注释风格（如显式类型、无缩写、线性控制流），而非人类偏好的简洁或隐喻式表达？
支持资料：
- GitHub Copilot 研究表明，AI对上下文窗口内代码的“理解”高度依赖变量名的语义清晰度（如 use
user_id而非uid）。- 2024年Google内部实验显示，在AI辅助审查中，结构化、冗余但语义明确的代码比“优雅但紧凑”的代码更容易被AI正确推理。
- 有团队开始采用“AI-first coding style”，如强制每行只做一件事、避免三元运算符、函数参数带类型注解等。
我的困惑是：书中仍将“人类可读”作为黄金标准，但若AI已成为日常开发的“第一读者”，我们是否应建立“AI可读性”新规范？这是否会削弱人类工程师的表达自由？
问题四：对“专家们对于颠覆性技术的预测往往是错误的”的原因的不同观点
引用章节：第16章《IT 行业的创新》（第17页）
原文：专家们对于颠覆性技术的预测往往是错误的一因为颠覆性技术的市场还不存在！
否认及理由：我否认这种观点，因为我觉得颠覆性技术的市场还不存在只是预测错误的表面原因，根本原因我觉得是专家们固守于传统的自己擅长的领域，思维固化或不愿面对新的技术；另一方面也可能是专家对原有的技术很熟悉但对于颠覆性技术并不很了解。
问题四：对第16章的一个例子的不同观点
引用章节：第16章《IT 行业的创新》（第29页）
原文：卖电脑的还会宣传CPU的速度么？还有显示器的尺寸、分辨率？
否认及理由：这里确实需要一些例子来论证“每个阶段有不同的关注点”这一论点，但我觉得这个例子不太妥当。因为我觉得2013年宣传cpu的速度没有过时，宣传显示器的尺寸和分辨率没有过时。现在我觉得 cpu的速度对于电脑，尺寸和分辨率对于显示器都还是很重要的参数。或许这里可以换成更合适的例子？