AI时代软件工程变成了知识工程这个提法真是精辟，照这么说，感觉领域驱动设计之类的技术可能还是会继续有用的？

在学习 Android Jetpack Compose 时借助 Copilot AI 插件确实提升了知识传递的及时性、准确性 两周周学习过程： 1. 「无 AI 介入」在官网阅读入门文档、观看入门视频解了 Jetpack Compose 的基本概念：如何创建一个页面、页面布局有哪些主要控件、控件在页面的位置如何调整 2. 「无 AI 介入」运行了最先发现的示例代码 3. 「无 AI 介入」按自己的想法开始了一个项目：点击按钮随机生成卦象、数字、十二星座、十二生肖 4. 「AI 介入」通过和 AI 对话进行开发功能：添加一个 Jetpack Compose Button；选中 Button 代码后，要求将 Button 变成圆形、改个颜色；画一条线；添加一个 Drawer 控件等 5. 「AI 介入」通过和 AI 对话添加了一个 codecov 插件在 Github Workflows 中上报测试覆盖率 6. 「无 AI 介入」开发到一周时，发现因严重缺乏 Android 基础知识，导致开发进度缓慢，买了一本《Head First Android 开发（第三版）》准备学习，此时还没看，硬和 AI 聊天完成了第一版功能 7. 「AI 介入」和 AI 聊天也没能解决的问题：测试 Compose 布局，运行时需要借助 Android 模拟器，自己写的测试代码，运行后的报错信息 AI 也不能帮助解决 8. v1.0.0 版本已发布，源码地址 https://github.com/aoeai/aoeai-qigua-android

获取不可言说知识的关键是分享思维的过程，而不是消费最终的结果。 因此，llm要提炼不可言说知识，就是要让llm通过上下文输出思维的步骤step，我们根据step去fine tune上下文，不断反馈。

就是怕失业，赶紧冲一下电。

老师多更新一些啊，意犹未尽

我们做事情常常希望能找到第一性原理，这样就能认识到事物的上限和边界，也就不会产生妄念，指望通过低效的方法达到高效的结果。我不知道老师将认知模式运用到软件工程算不算真理，是不是软件工程的本质，但我觉得这个理论至少提供了一个很好的思维框架，帮助我们去理解软件工程的本质。 软件工程在我看来就是为了去解决日益增长的软件规模和逐渐复杂的人员分工之间的矛盾，这个矛盾又集中体现在知识传递的过程。也就是我们常常会发现，一个功能需求，其实不是技术实现上有多难，而是因为软件规模过于庞大，以至于个人不能掌握全部的上下文信息，而复杂的分工，又导致开发者很难串联起全流程，站在客户的使用场景，去开发一个完美解决客户问题的软件产品。 认知模式的分类，给了我们一个很好的认识视角。首先，知识传递的效率，很明显是清晰模式 > 庞杂模式 > 复杂模式 > 混乱模式。回到开发场景，清晰模式就像搜索答案，它效率应该是分钟级的；庞杂模式就像一个老手接到需求，他能很快知道要做什么事情，并分析清楚各个业务场景和边界条件，效率是小时级的；而复杂模式就类似一个新手接到需求，完全是懵的，需要不断的问别人，不断的探测，它的效率常常是按天来算的；混乱模式就更别提了，效率基本未知，完全无法预测需要多长时间，甚至花了很多时间都无法认识到问题的原因。 所以软件工程要做什么，就是尽量把复杂模式变为庞杂模式，把庞杂模式变为清晰模式。我猜老师后续就是要回答，AI时代如何升级认知模式，如何让认知效率产生质变，期待后续的内容^-^

这一课像是个捧哏，勾的我贼期待下一篇～

收获：作为软件工程师不能只停留在编码环节，也不要被 LLM 的出现搞得自己没有未来了一样。实际情况是我们需要将关注点放到更有价值的地方，因为知识本身是为了解释世界、解决问题，软件是知识的载体，那么他们的目的都是一样，有了 LLM 之后，软件工程师能够有更多的精力去改造世界🥳。

之前的“数字化”好像是技术未成熟阶段的种种费劲的努力，包括“软件是知识的封装”这类精彩观点。 现在 LLM 来了，“数字化”和“知识经济”的真正春天才到了～～ 从图灵机到此刻，好像那些都是前戏。。。感谢徐昊老师带来产业高潮中的认知高潮 ：）

老师最后的特别说明很重要：Cynefin 框架主要帮助我们识别 应对问题的行为模式。同样的问题，不同段位的人会采取不同的行为模式。这让我联想到更早的一位大师 温伯格（Gerald Weinberg）关于问题复杂度的评估体系和在软件开发和系统设计方面的应对策略。 好像感觉 温伯格的评估体系更偏客观性，Cynefin 框架更主观性一些？ 这个理解对吗？ 这种差异背后，有一些更深层次的缘由吗？时代的问题品味？