端到端代码生成摸底_什么是端到端代码生成-优快云博客

背景

因为一直受困于人少事多没hc，我对提效是有执念的。claude3.7和最近疯狂的投资情况，似乎意味着ai coding是个正解。加之之前有过相关的思考1 2，最近沉迷AI coding无法自拔。一方面是要摸清楚边界（但是这个边界会随着模型能力提升急剧变化），另一方面是在差不多的边界下找到一个尽可能好的端到端生成方案。

任务分类

知识属性

按核心信息来源来分：技术实现（公域）、业务规则（私域）、技术债务（隐性）

复杂度象限

按真实复杂度归属层级来分：逻辑复杂度、交互复杂度、数据复杂度

演进模式

按新老代码占比来分：绿地开发、棕地开发、重构演进

讲道理这些分类都需要各自有各自合理的workflow。做任务前要先把这些flag都摸清，然后做一层路由，就像chatbot要做一个前置意图识别模块一样。

端到端

一句话需求到最终产品的路径。在这个路径下，我尝试了几个workflow，除了复杂度象限（需求本身特点）没试之外，上面的分类特征都遇到了。
会交叉使用qwen.ai、元宝、cursor和trae（主）。其中chatbot是为了做分析部分，ide是为了尽可能简单的做index和文件修改。需求固定为”一个消消乐“，pc的web版本。

尝试1

一句话需求丢给trae的builder模式（claude 3.7）。能产出一个可以玩的东西，有bug、没有任何需求细化的过程，连POC都不算。

尝试2

端到端产品，除了heyboss都没有需求细化。实现效果都比trae差（纯模型能力问题）。

尝试3

一个相对瀑布流的原始开发过程：

(qwen.ai)下做需求拆解，拆解过程中给反问和搜索工具。
(qwen.ai)细化的需求做模块拆分，但不给任何拆分的指到原则。
(qwen.ai)拆分后的模块再做细化。
(qwen.ai)技术设计，这里主要要求的是mermaid的类图、流程图等。
(trae)只提一嘴TDD，然后所有东西放到一起，让trae写代码。
效果上看基本完成了原始需求，但是细节差了很多。还会有很多bug，需要反馈做修改。TDD的模式根本没理解。速度也很慢。
这里有几个核心发现：上下文长度会很影响细节还原。反馈太多太杂，指令很快就不跟随了，而且文件也改的不对了。有的东西需要重写，而不是一直改。

尝试4

在3的基础上优化TDD相关prompt，先test case后代码。用prompt让模型做增量生成。
TDD本身问题解了，但是增量和ut验证还是很不好。增量粒度太小（似乎是trae system prompt规定的？），很晚才有poc的demo。出现了大量对于需求的幻觉，一直在发明新需求。

尝试5

Scrum是一个很适合端到端生成的过程：利用各种backlog做todo list，可以模仿manus的planner做好规划的记录和更新。每个sprint都必须有可以展示的产物，这样反馈周期和复杂度要降低很多，修改成功率也会高。拆解是有机的，粒度是更好的可控的。
步骤：

(qwen.ai)product backlog，拆解过程中给反问和搜索工具。
(qwen.ai)sprint backlog，是要求在技术经理视角做，保证是实现上的合理拆分。
(qwen.ai)sprint backlog细化。因为backlog粒度相对合理，这时候细节度可以做的很高了。
Code as Architect。qwen和trae都试了一下，感觉都差强人意。
(trae)开发。sprint backlog要拆成独立task给进去，一下子都进去会有lost in context的问题。
(trae) code review。重点关注需求完成度，很意外的效果不错。
效果上看基本完成了原始需求，细节还原度会好不少。bug和反馈周期变短后，修复速度变快了，心情也更舒畅，但是整个流程变慢了。架构和分层是真不好。还是会有上下文长度问题。

尝试6

在5的基础上，每个sprint backlog结合TDD的思路，做进一步拆解。即5.开发拆成先用sprint backlog生成test case，再根据sprint backlog+test case+ut做生成循环。
效果上看细节还原度进一步提升，感觉差不多能用了。ut会过滤掉很大的问题，反馈周期比demo+人肉要快两个数量级。ut完备度还是不够。trae的交互模式偏傻，经常会不知道该改test还是实现。单case的修复效率比suite修复要高很多。一定要在ut之后人肉看一下运行后的产物，会出现拆模块之后没办法整合的问题。

结论

端到端是可行的，目前最大的问题还是模型可用上下文长度受限带来的各种问题。
需求文档角度，是比一般产品经理写的好的。
代码如果是指定好上下文范围和行为特征，能做的很不错。
分层和分模块是重灾区，需要加few shot。

模型反馈

https://chat.qwen.ai/s/ce65ce9b-50a9-47b4-9ea3-53b3d88a95fd
提到了几个非常关键的优化技术：

BDD（Behavior Driven Development），这种结构化需求描述可能在边界条件梳理、ut和实现部分有大提升。而且这里的Test都是面向需求的，而非面向实现的，做主流程的验证非常合理。
ADR（Architecture Decision Record），但不是原生态的用，而是将决策背景和决策前瞻尽可能的记录下来，作为上下文或者RAG数据库传给模型，以尽可能简单有效的做串联。