16｜任务划分与测试驱动AI开发
徐昊
你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
上一节课，我们展示了直接使用大语言模型（Large Language Model，LLM）辅助进行软件开发的例子，我们看到虽然在速度上 LLM 有惊人的提高，但是质量堪忧。而且在与 LLM 一起开发的时候，我们的关注点更多集中在测试上，通过测试提炼需要给予 LLM 的反馈，而不是编码。
可能有同学会说，那是因为你擅长测试驱动开发（Test Driven Development，TDD），有路径依赖。那么今天这节课，我们就从根本上讲一讲，使用 LLM 辅助软件开发的核心思路。
从任务划分开始
我们都知道，LLM 存在技术限制，每一次 LLM 只能处理有限数量的 token 以及产生有限数量 token 的结果。因而 LLM 能够理解的上下文规模，以及能够生成的应用规模都是有限的。对于大型系统，我们无法一次性将上下文传递给 LLM，也无法从 LLM 中一次性获取整个应用。
那么使用 LLM 辅助软件交付的关键就在于将需求分解成足够小的任务，然后将这个任务转化为 LLM 的提示词，交由 LLM 处理，最后我们再将 LLM 的生成结果组合成生产或测试代码。
那么如何把任务划分成 LLM 易于处理的形式，就成为了使用 LLM 辅助软件开发的关键。而对于任务的划分，通常需要考虑两个维度，即软件的架构与测试策略。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 使用LLM辅助软件开发的核心思路是测试驱动的方法与LLM进行结对编程，以验证LLM生成结果是否正确，满足质量诉求，并最大化LLM的效用。 2. 在团队开发中，LLM可以辅助任务分解，利用思维链（CoT）提高不可言说传递的效率，从而提升团队效率。 3. 不同类型的 LLM 需要管理不同的知识，如任务分解的LLM需要了解架构和测试策略的知识，测试Driver的LLM需要了解测试策略和测试技术栈的知识，生产代码Driver的LLM需要了解架构和技术栈的知识。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《徐昊 · AI 时代的软件工程》，新⼈⾸单¥98
《徐昊 · AI 时代的软件工程》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
术子米德🤔☕️🤔☕️🤔 【R】限制：LLM每次能处理的输入与输出token数量。 关键：从架构设计和测试策略两个维度，将需求分解到足够小的任务。 LLM：任务分解 + 测试代码 + 生产代码。 架构：指导每日工作的任务划分。 测试：TDD + PP with LLM。 PP = Pair Programming 【.I.】LLM的Context Token数量，似乎是它的缺点，看到那个谁已经整得很大，眼看着能把整个代码仓扔进去，貌似很好的样子。可是，我倒认为，这样的限制，实际上可以利用起来，发挥出局部性的聚焦优势。无论我在多大的代码仓里干活，我实际要做的事情，越是在局部，越是能够做得干净利落，越是跟其它耦合，那就拖泥带水踩坑前行。 【.I.】架构，这个词写出来，总有点看似高级又不明所言感。实际上，还不是手头有怎样的兵，就会演化出怎样的架构，无论写在纸上还是落进代码仓里。如今，LLM作为新兵入队，自然会变成影响演化的力量，差别在于，LLM凭自己的生命力，见空就座，还是听话就座，我猜测是前者，而且我相信我的猜测是对的，LLM的力量在于，只要坐下来，就会黏住。 【Q】团队是否也有Clear、Complica、Complex的认知状态？如果有的话，怎么能判断出来当下团队整体处于什么样的认知状态？ — by 术子米德@2024年4月12日作者回复: 实际上 llm并不能保证在大context下的准确推理 目前（2024）来看 给的context越多 llm的推理准确度是下降的
2024-04-12归属地：日本1
收起评论