垂直开发-AI Coding 在复杂工程中的失效与解法
对AI coding来讲，新项目 / 新功能阶段，是效果最优解区间。
一旦进入中后期（项目复杂度上升、架构膨胀），AI Coding 的生成速度、准确率、问题解决能力都会出现显著衰减（non-linear degradation）。这是 LLM 工作机制的底层弊端，我们通过工程系统设计可以尽量去改善。
1. AI coding 仍逃不过是“看你给它的那点东西”
作为 LLM 模型，它不是在理解你的项目，而是在“根据输入的上下文生成输出”。在 coding 领域，我们给模型喂得输入不是简单问题，而是一段被拼接后的输入，拼接来自于你的当前对话、历史对话、检索到的一部分代码、编辑器帮你塞进去的提示词，也就是大家常说的 context。
注意context是有上限的，我们没法无限制的全部塞进去，当项目很小的时候，这些信息是够的。但一旦项目变复杂：哪些信息该传？哪些是关键？怎么不超 token？这些都变成问题。结果就是：AI 看起来“知道你在干嘛”，但其实理解是断裂的。
对这部分context应该如何设计的问题研究，也是很多公司的核心价值，如claude、cursor他们都会研究如何将需求转化为更有效的context传递。
2. 最烦的不是错，而是“差一点点”
AI 很少完全错，大多数时候是，逻辑基本对，但缺边界，或者和现有代码对不上
于是你开始：让它改一点，再改一点，再调一次 prompt，在小项目里，这没问题。但在复杂项目里，这个过程会变成：
修改成本 ≈ 重写成本
而且结果还不稳定。
3. 慢慢就掉进“效率黑洞”
当你发现：调 AI 的时间，debug AI 的时间，反复生成的时间，加起来已经比自己写还久，那其实已经进入一个状态：
AI 不再是加速器，而是阻力。
4. 项目越大，这种问题越严重
到了团队或者复杂项目阶段，还会出现：Code review 很难（AI 代码不太“可预测”）CI/CD 风险变高，出问题不好定位，再加上时间一长：技术债开始堆、模块越来越耦合、代码越来越难看
最后变成一种很尴尬的状态：
人写不好，AI 也救不了
如果问题在“太复杂”，那解决方法可以让它变简单：
每个功能都是闭环，从需求到实现，是自洽的、完整的、可以单独理解的。
闭环里需要有：
需求描述：用来记录功能的目的、必要的基本信息
开发路线：用来记录开发的细节，比如模型字段、实现方式等细节
单元测试：用来保证开发功能的有效性，也是重构功能的有效保证
自动评审：用来评价功能的缺陷记录等
后期维护：可以记录功能迭代的版本及相关实现目标等
日志记录：可分为 progress 日志、error_development 日志 等
这些信息要在一个地方，要能被 AI 一次性看到，或者相关检索到
开发人员需要给功能进行明确细粒度的划分，尽量保证功能的独立性，可控的复杂程度。
基于LLM的原理，我们可以通过上述对每个功能的闭环，将每个功能开发限制在一个可控的、可连续的、可理解的文档集内，是一种文档驱动开发的方式，可以从被复杂项目混乱中解放出来。
我们当做每次开发一个小项目