agent develop paradigm

这篇文章的目的就是记录结合llm coding的有效方法论。我其实不是很喜欢描述一些“漂浮”的方法论，因为他们没有强有力且直接的手段去向观众证实，所以我记录的内容会尽可能的简单，直接，并且能够复现。

我会考虑项目的从0到1，以及从1往后迭代两个过程使用的方法。

以"引导"作为主线

如果你在编程的过程中丧失了对程序的理解，你对“整个开发流程”就丧失了理解，从而导致开发过程偏离轨道。你必须将自己对程序的“关键链路”的understanding提供给AI。换一句话说，你自身必须能够解释你和llm共同开发的东西：

• 你可以写一段简洁地描述项目的动机和基本组成部份（“组件”本身就是一种抽象的概念，我的理解是把你设计的目标想成一个系统，你可以将系统分解成几个在运行时状态下不断进行数据交互的单元，单元内部或者多个单元复用的库如果也能够提取出来成为一个公共工具集就更好了）以及基本组成部份在典型case中的数据交互方式
• 你可以找一个同事/有技术能力的朋友，跟他描述你脑中这个项目的概览，要解决的问题，技术手段。可以让他们随时提出疑问并尝试跟他们解释清楚，如果这个过程是不流畅的，就得自己找时间将问题捋清楚再逐个思考

足够细致的拆解

一般来说：

• 一个复杂且完整的项目的内容很难被一个AI的上下文所完整包含（目前是这样，就算使用有1～2M上下文的AI强行将内容吃进上下文，其回撤表现也比较差）
• 一个复杂的系统在一定程度上能够被分解为多个相对独立，之间通过接口交互的个体

基于上述假设，尽可能地将开发过程分解，将一个职责按照侧重点分解这两点都很重要：

• 使用TDD结合细粒度过程分解能够保证一个模块/一个功能的质量达标，此外开发过程中暴露出的问题可以辅助你修正整个开发过程，从而你不需要（一般也不能）在一开始就确定整个计划的链路
• 职责按照侧重分解是一种技术，将一个任务分派给被赋予两种不同类型+赋予不同上下文（比如系统中的A part和B part，但两者有重合部分）的LLM，他们会有不同的看法，让他们交流，最终收敛的技术方案更加可靠

TDD

测试驱动开发

架构阶段

项目从0到1，我会做：

• 明确需求，直到：
  • 可以为这个不存在的应用做一个介绍其功能的视频，并让至少3个人明白应用“是什么”
• 明确开发工具，部署形态，每一种部署形态下的相对独立组件以及交互序列（为了快，不一定需要）

红色阶段

开发者用自然语言描述需求（如用户故事或代码注释），然后提示LLM生成一个失败的测试用例。LLM甚至可能提出一些开发者未曾考虑到的边缘情况，丰富测试的覆盖面。开发者只需审查和微调LLM生成的测试代码 。

绿色阶段

开发者将失败的测试及其错误信息一同提供给LLM，并给出指令：“编写最少的代码让这个测试通过”。LLM会生成相应的实现代码 。

重构阶段

开发者可以提示LLM：“在保证所有测试通过的前提下，重构这段代码以提高可读性和效率”。LLM会提出重构建议，供开发者采纳 。

反馈循环

这个过程形成了一个紧密的“修复循环”（remediation loop），测试失败的反馈被自动送回LLM，直到生成正确的解决方案 。这极大地缩短了从需求到可验证实现的时间。