LLM 在遗留代码中为何频频失效？
Domain-Driven Agents
我在软件工程中重度使用 LLM，发现它在绿色项目中表现优异，但在充满技术债务的遗留系统中却频频出错。问题不在于模型能力不足，而在于代码库缺乏统一的领域语言和清晰的边界。我提出将工作拆分为战略与战术两部分：由人类负责阅读系统、制定变更策略，而将机械性的代码实现交给 AI 代理。通过引入 Domain-Driven Design（DDD）理念，我为每个仓库建立 `.workflow.json` 清单和 `CONTEXT.md` 术语表，明确界定上下文边界与术语所有权。这种结构化的领域定义让 AI 能准确理解系统意图，从而在复杂系统中也能高效协作，逐步偿还技术债务。
需要升级的不是模型，代码本身尚未准备好，而准备度是我们可以逐步构建的。
HN 评论区
20- stephen
我也一直是个小写 DDD（little-d DDD）的拥趸，我们尝试过为每个实体维护一个 `md` 文件，用来记录与语言无关的领域行为、怪癖和用法。
比如 `Author.ts` 对应一个 `Author.md`，`Book.ts` 对应一个 `Book.md`。
对于 Agent，我们赋予了它们读写这些 `md` 文件的技能：
https://github.com/joist-orm/joist-orm/blob/main/packages/co...
因此，Agent 生成的 `md` 更新已经出现在 PR 中了。目前看来效果不错（我们主仓库是一个 35 万行代码的 TypeScript 单体应用）。
诚然，这比 OP 提到的“每个边界上下文进出的边图”要简单得多（也复杂得少得多），但这大概又回到了我偏爱“小写 DDD”的原因：在我看来，某些“大规模 DDD”的模式往往会导致过度设计。
- owaiswiz
我在文章前几段读到关于 LLM 在绿地项目（greenfield projects）中更容易上手的内容……
我的经验恰恰相反。它们在现有项目中表现良好，但在新项目中就不那么出色了（除非你只是在凭感觉写一些简单的代码）。
我觉得这可能与它们能够依赖现有项目中多年建立的结构和约定有关，这使得它们在现有项目中表现更好，至少就我的经验而言（IME）。
- theahura
很遗憾地说，除了第一段，这篇文章大部分内容都是 AI 生成的垃圾（AI slop）。我以为我们基本上不允许在 HN 上发布 AI 写的内容？（@dang 这里的政策是什么？）
除此之外，我觉得这篇文章把原本更简单的想法过度复杂化了。你应该让 Agent 在代码库中留下文档，这些文档应与你的代码结构本地化，但你不需要任何花哨的格式或清单。
我们让 Agent 在每个文件夹中编写并维护一个 `docs.md` 文件，并要求它们在对该文件夹进行任何更改时，都必须读取并更新该文件，这种做法取得了很大成功。