术子米德｜边干边学：如何开启LLM探索之旅
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="46" height="20"><rect fill-opacity="0"/></svg>)
术子米德｜边干边学：如何开启LLM探索之旅
术子米德 · 徐昊 · AI时代的软件工程
课程介绍
讲述：术子米德
时长21:49大小19.93M
你好，我是术子米德，是一名边干边学、边学边想、边想边干的码农。如今工龄 20+，依然在代码一线奋战。
最近几个月，我在探索基于 AIGC 的代码开发，采用 GitHub 的 Copilot 结合 TDD 方法，在实践中摸索代码助手的效果。在得出自己的初步结论，并冒出更多问题的时候，和这门徐 8 叉老师的课不期而遇。
于是，我边干边学、边学边想、边想边干的劲头更足了。现在还在兴奋状态，特别想把我的探索经验和课程带来的启发分享一下，期望也能激发你的兴趣。
老“码农”遇到新局面
先展示一个采用 Copilot 写测试代码的阶段性成果。在我探索用 Copilot 进行代码开发，多轮迭代改进之后，总结了一个注释型提示词模板，你有兴趣的话，不妨打开文稿看一眼。
按这个模版把注释写完整，看到 Copilot 生成整个用例代码时，一种恍惚感油然而生：“大模型都能这么快生成有用的代码了，那要我有何用？”基于这些探索、业界几篇相关 Paper 以及自己多年实践的经验，我得出这个结论：未来 TDD 必定会结对大模型，并发挥出无穷的力量。
如果你还不熟悉 TDD，可以看看维基百科的示意图，图里对 TDD 的精髓把握得非常准确。当然，也可以学习极客时间里徐 8 叉老师的 TDD 课程，据说那门课跟 Github 的 Copilot 生日是在同一天。
图片来源：https://en.wikipedia.org/wiki/Test-driven_development
我稍微对这个模版做点解释。
首先，要给用例取个能沟通的名字，用一句话概括：验证哪个行为符合什么预期，通过什么样的动作进行该验证。比如：
这是一个“验证什么结果，通过做什么动作（verifyWhatResult_byDoWhatAction）”的句式。
至于这个句式为什么效果好，我暂时还回答不了。不过目前验证下来这种总分式的注释，应该有助于让模型理解我的意图。
其次，要写清楚用例的目的，在用例名字外，补充更多的信息和必要上下文。毕竟一句总述携带的用例名字能携带信息有限，也不可能写个超级长的名字，念完都要憋口气，那就有点为难了。
补充的信息可以包括：这个用例是为了验证需求规格中的哪部分，为何要通过这样的动作序列去验证预期的行为，类似 As a Role/$Who，I want $What，So I can ……$Why。
我的理解是，这个部分的信息，有助于让大模型知道我的更多意图，当然也只是推测。能够确定的是，写了这部分注释，可以让自己的意图更清晰表达出来。实践中也发现，想要把“为何设计这个用例”表达清楚，这件事儿本身就要花点思考力。
然后，把步骤写出来，包括每个步骤做的主要动作，以及每个动作的属性是设定（Setup）、行为（Behavior）、验证（Verify）还是清理（Cleanup）。
之后，明确用例的预期结果，即哪些条件达到，就会满足用例的验证预期。
最后，用例的额外信息放在备注里，包括当前用例可以参考之前的哪个例子。需要注意，在注释里写清当前的例子参考了哪部分代码，就像告诉学生参考答案在哪里一样，这样会让“作业”质量直线上升。
另外，模板里 “@[Name]、@[Purpose]” 这样的特殊符号，并没有遵守什么特定规范，只是为了更显眼，容易阅读，实际证明这并不妨碍大模型理解。
下面是一段示例代码，有兴趣可以看一眼，不看影响也不大，关键点是这样略显复杂的代码，Copilot 能够生成其中 80% 的代码。
00:00 / 00:00
1.0x
- 3.0x
- 2.5x
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.75x
- 0.5x
我的问题也由此而来，谁来负责写出这么完备的注释，让大模型看了以后生成代码呢？毕竟就算用了这套规范和模版，写注释的人还是要花费不少功夫。
再者，如果自己已经想得这么清楚，直接把代码敲出来不是更直接吗？从没见过这么“绕弯弯”写代码的过程。除非，不写注释拿不到工程款。那只能乖乖在代码写完后，硬着头皮补充注释。
不过，换个思路想，转身 180 度想，扎着马步想，倒立着想……如果有工具能生成这样的注释，那代码生成这件事，是否如业界领头羊说的那样，未来就是代码开发的常态呢？也就是说，只要能有这样的注释，代码生成就是能用大模型完成，写代码这事儿不再非程序员不可。
于是，我调整了思路，不纠结于我现在的开发习惯、我所在团队的开发模式和流程。我想尽办法，用上各种手段，多个方向去尝试、去摸索大模型写代码的能力约束和边界。这可能比简单回答，当下的大模型工具生成代码的效果是否足够好，更加有探索的意义。
盯着这个目标，我反复摸索了几个月，得到的初步答案就是——让大模型生成代码，而且代码能够编译通过、直接可用，的确可行，但难点在于怎么去把准备工作做好。
这里的准备初看好像是写注释，不管是开发人员、设计人员来写，或者什么工具或 Agent 生成。但深究还是得往回倒，也许是从设计开始，也许是从需求分析开始。
对照软件开发的 V 模型图，我的探索在谷底，仅仅在代码实现部分有一点探索的心得而已，还得往上爬，继续扩展探索的思路和范围。
图片来源：https://en.wikipedia.org/wiki/V-model_(software_development)
恰当时刻遇到的好课
正是在这样的困惑时刻，我看到徐 8 叉老师的新课——《AI 时代的软件工程》。
看过课程目录就发现，这个课程比我的探索更加体系化、结构化。尤其是第三部分，赫然写着“测试驱动 AI 开发”，这不正好跟我在探索的 TDD 合上拍了嘛。
这让我内心有点小激动，看样子，我探索的方向没错。同时，也更加期待课程的第一、二部分，会给我点出哪些方向，帮我解开哪些困惑，甚至直接能给到我问题的答案。
两记当头棒喝
带着这样的期待，课程一上线，我就立刻跟着学习了，结果却迎来两记当头棒喝，概括起来就是“两清”——讲清楚和想清楚。
1. 讲清楚：只有大模型能讲清楚干活的步骤时，它才能真正把内容生成出来。
意思是说，在给大模型布置任务的时候，需要先问大模型，要完成这个任务要有哪些步骤。如果生成的步骤都不行，那自然无法得到理想结果。
2. 想清楚：只有我脑子里想清楚时，大模型才能跟我一起“灵清地干活”（条分缕析）。
这里的意思是说，面对问题，只有我的脑子里能想得足够清楚，那么大模型才能跟我一样条分缕析地干活。当我在做开发们常做的调试程序（也就是 debug）这个动作时，已经说明脑子不灵清了，这时候找大模型帮忙，除了添乱，啥也帮不了。
吃到这两记棒喝，略微有点懵。感觉这两条好像是对的，但不知道背后的原因。只是，心里隐约有些嘀咕声：“如果有这样灵清的思路和清楚的步骤，我都能说清楚，我都已经想清楚，那我还要大模型来做啥？”
如果你已经学完课程，可能会困惑课程里好像并没明确提到这些点，至少没那么明显。如果你还没学完课程，你可能更困惑，得出这样结论的课程，还值得听嘛？别急，先听我说完，我自己是怎么得到这两记棒喝的。
对应到课程里，第一记棒喝是老师讲到，软件工程（Software Engineering）在大模型时代，更应该叫知识工程（Knowledge Engineering），整个软件过程里的瓶颈，是知识的生成、传递和应用。
知识分为两类，一类是就像套用公式那样的显性知识；还有一类是不可言说的知识，就像做小学应用题，要先分析题目的含义，准确理解问题后，才能确定套用哪个公式。这个分析题目含义的思考过程，就是典型的不可言说的知识。
这个不可言说的知识，特别像令人讨厌的学霸，他为啥看着题目，就能想出来要用这个公式去解答？而我看到公式的时候，就算知道公式用对了，也不知道学霸想到用这个公式的分析思路，也就是学霸的不可言说知识。
再比如，我们敲代码时，确定这里用二分法来搜索，性能表现会更好，这就是显性知识；而对于一个需求，把问题转换到可以用二分法解决之前，那些分析、设计、拆解、转换过程里用到的知识，大部分都是不可言说的知识。
让我印象最深的也正是这个不可言说的知识。和只是没有写出来的隐性知识不同，不可言说的知识即使直接写出来，也无法直接使用。
不过，不可言说的知识，却能以思考或推理步骤的形式呈现出来。就像分析需求时采用 5W1H 的方法，按顺序写出每个 W 的内容，并考虑哪个 W 要详细展开，要做更多分析讨论。对于这个步骤式的不可言说知识提取，就像把老警察的办案过程提取出来。就像课程里提到的，对于不可言说知识的提取和使用，是开发团队利用大模型，最终提效的关键所在。
我们要关注团队里的不可言说知识在哪些地方，思考如何提取这些知识为思维链（CoT），再利用好大模型来反复使用这些思维链，从而提高团队里知识提取、传递和应用的效率。这是课程带给我的第一大收获。
对应开始提到的“说清楚”，并不是指我们平时说的显性知识（那些知识一直很清楚，不同的只是知识组织和呈现方式而已），而是如何把不可言说的知识提取出来、变成思维链，以及把思考和分析的步骤说清楚。现在我已经被敲醒，需要说清楚的是不可言说的知识的过程。
第二记棒喝是老师引入 Cynefin 的认知框架。这个框架可以帮我们判断，当我面对要解决的问题，采取的行为处于清晰（Clear）、庞杂（Complicated），还是复杂（Complex）的认知模式。夸张点的话，还会处于混乱（Chaotic）或迷糊（Confused）的认知模式。
这忽然让我明白，为何上文展示的、我琢磨出来的代码注释，能够让 Copilot 生成可用的测试代码。因为无论是明确的手写注释，还是清晰的任务列表，都要先经历“想清楚”的过程，自己头脑清晰了，才能“教会”大模型。
按照认知模型来分析，起初我处在复杂认知模式，跟大模型的聊天是为了对齐思路，通过探索逐步理清问题，明确方案。一步步改进后，我才从复杂模式转向了庞杂，这时再和大模型聊，目的就变成了把我掌握的不可言说知识提取为思维链，让大模型理解它，并能够据此生成清晰的任务列表。
学完课程第一部分，我也逐渐明白了开发的不同阶段应该处于怎样的模式。
在需求分析时，处在复杂模式比较正常。因为需求并非显而易见，要探索后才能感知到，真正的需求点在哪里。
在架构设计时，处在庞杂模式比较合理。因为它符合感知到需求后，通过分析寻找合适的方案，最后拿出设计出的架构作为响应。这时候如果还用复杂模式来探索架构设计的话，也就是说心里还是“试试再看效果”的想法，那就要提醒自己回头审视需求清晰度了。
在真正编码时，理想模式自然是清晰，架构设计拆解到任务列表，符合感知到任务项、进行归类并做出实现的响应。
反而我们常做的调试（debug）动作，实际处于复杂模式，我们的行为是打断点（探测），看看程序跑到那个位置的样子（感知），此时我们脑子里对程序的运行情况并没有清晰预期。
这就是学习这门课程，给我最大的两记棒喝。有了初步的领悟，我也计划在实际项目里去尝试，期待自己之后会有更深刻的理解，到时候还可以来跟大家分享。
这里说点题外话，开篇词里徐老师的观点“健身🏋️教练只能提供练习法，得靠自己刻意练习，才能练到期望的样子”，这点也是非常受用。
为此我甚至找了张图片，放在工位的显眼位置，时刻提醒自己，自己下场练起来，自己的手感热起来，才会有真正的启发和更多的问题。否则的话，学多少遍课程，自己也只会在复杂 Complex 和庞杂 Complicated 之间徘徊，永远无法抵达清晰 Clear 的彼岸。
种树最好十年前，其次就是在今天
这门课适合谁？我的回答是，如果以软件开发为志业，如果想跟上最新的、基于大模型的软件开发技术，那这门课程就值得关注。
至于课程学习带来什么效果，更多要看你处于什么样的状态。我按自己的经验，分成了这三类。
如果你正在尝试把大模型引入到软件开发，在探索时冒出了很多问题。带着问题去听课，这当然是最佳时刻，也必定有最大的收获。即使不同意老师的部分理论和观点，也会启发思考、产生新感悟，更新自己对大模型时代软件开发的认知。
如果你感受到了大模型改变软件开发的趋势。那么不妨听听，边探索、边练习，问题自然会在过程里冒出来，这是次佳时刻。
如果你仅仅是被标题吸引，也可以做个初步了解，大致看看课程的范围。试读几篇课程里的配图以及课程的留言，觉得吸引力越来越大，那就开始。感觉还欠缺点心动的东西，先做个标记，这里可有个大矿，改天需要时想起来，再来学习不迟。
总之，只要大模型助推软件开发这个趋势，一直处于正反馈的状态，那么这门课程就不会过时。
留遗憾一点和新问题一堆
接下来，我还想分享学习这门课程留下的一点遗憾，以及产生的更多新问题。
我原本的想法是，课程名字都是“AI 时代的软件工程”，所以很期望看到大模型应用到软件工程里的“通关型”实践。也就是有一个样板工程贯穿整个课程，来展示如何基于大模型进行需求分析、架构设计、代码实现、测试验证。实际没有看到这样贯穿的案例，算是留了点遗憾吧。
不过，这倒是给了我启发，我已经开始捣鼓一个软件模块，就算是我自己的 Agile LLM Kata（基于大模型的敏捷开发空手道项目）吧。我想做一个样板工程，把整个软件开发流程覆盖住，尝试把课程里的所学，与自己的探索结合起来。
这件事情已经启动，自己行动起来后才会切实感受到，没那么容易。不过，课程已经给我很多信心，激励我继续探路前行。
还有就是，听完课后冒出更多的新问题。比如：
我如何能把我学课程得到的认识，分享给身边的小伙伴，
在大模型与软件工程结合提效方面，如何跟大家一起产生更多知识与认知上的共识？
如何能够找到机会，把 LLM 引入到实际项目开发，在真实场景里去边学、边想、边干？
还有，我自己做的是嵌入式产品软件开发，课里描绘的那种动不动就能跟客户一起探讨需求的场景，只发生在产品交付后，出了问题去排查，去向客户道歉的时刻，而不是产品开发前期，跟客户讨论需求的时刻。实际上，我们只是做到开个晨会，名曰“敏捷开发模式”。
学了课程，感觉到自己在使用大模型方面，还有很大的改善空间，有很多方面值得去尝试。在解决具体的问题过程里，才能知道老师的这套训练法，放到自己这方水土里，到底服不服。
面对照相机的画家会咋想
最后，我想分享点我遇到大模型，在多次讨论和反思之后，想明白的一个隐喻。
结合业界《黑客与画家》这本书名气巨大的书，其中讲到程序开发与画家创作之间存在相似之处。
当今这个时代，会写代码的程序员遇到会生成代码的大模型，就好像达·芬奇发挥他的全部才气，创作出蒙娜丽莎，还没来得及讨到尾款，就有哪个不知名的家伙，扛着摄像机给蒙娜丽莎“咔嚓咔嚓”好几张，张张美若天仙。
也难怪达·芬奇后半辈子跑到哪里，都拿着蒙娜丽莎这幅画，一方面是没收尾款而耿耿于怀；另一方面，更是要时刻把自己带入反思状态。
会写代码这件事情，未来只是电费问题，不再是研发人员雇佣费问题。那么，我们作为与大模型共存的程序员，就像跟照相机共存的画家一样，我们的创造性要去哪里发挥呢？
课程给出了一些答案，这里也给你分享一句我写给自己的话——人有人的好处，机器有机器的用处，人要好好想，机器要好好用。
感谢你看到这里。如果意犹未尽，想继续交流，欢迎在留言区建立联系，一起探讨学习，互相启发思考，再会！
1. 码农在探索基于AIGC的代码开发，采用GitHub的Copilot结合TDD方法，得出结论：未来TDD必定会结对大模型，并发挥出无穷的力量。 2. 码农展示了采用Copilot写测试代码的阶段性成果，发现大模型能够快速生成有用的代码，引发思考：未来是否只需大模型生成代码，而非程序员。 3. 码农提出了一个注释模板，包括用例的名字、目的、步骤、预期结果和备注，探讨了写注释的必要性和难点。 4. 课程《AI时代的软件工程》带给码农新的认知，包括知识工程的重要性、不可言说的知识、Cynefin认知框架等。 5. 老师提出软件工程在大模型时代更应该叫知识工程，强调知识的生成、传递和应用是软件工程的瓶颈。 6. 不可言说的知识以思考或推理步骤的形式呈现，提取和使用这些知识是开发团队利用大模型的关键。 7. Cynefin认知框架帮助码农理解问题解决时所处的认知模式，指导不同阶段应该处于何种认知模式。
分享给需要的人，Ta购买本课程，你将得29元
生成海报并分享2024-05-28
赞 5
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
直播专场（三）｜如何理解测试策略与测试工序
下一篇
26｜知识过程下的团队管理
全部留言(2)
- 最新
- 精选
zhsky2024-06-07 来自广东米德大哥分享的太棒了，争取一起坐上AI这辆时代的列车，抵达软件开发更美好的彼岸
Y0242024-05-28 来自福建空手道项目，蹲个 github 链接，哈哈哈，好不好？共 1 条评论