为什么你的 AI 写的代码越来越难维护

如果你已经用过一段时间 AI 写代码，大概率经历过这样一个阶段。

第一周，你觉得它像开挂。

第三周，你开始发现它越来越会“补丁式修复”。

第六周，你看着项目里那些能跑但不敢改的代码，突然意识到一个问题：AI 并没有帮你减少复杂度，它只是帮你更快地制造了复杂度。

这篇文章不谈工具安装，不谈 workflow，也不急着推荐任何方案。先把问题说透。

适用场景

• 正在使用 ChatGPT、Codex、Claude 等 AI 工具写代码的开发者
• 独立开发者、一人团队、小型项目维护者
• 已经感受到“开发速度变快了，但代码越来越难改”的人
• 想把 AI 从“代码生成器”升级成“工程协作对象”的人

这篇文章读完之后，你会获得三样东西：

1. 一套理解 AI 开发失控问题的认知框架
2. 一个区分“AI 写代码”和“AI 做工程”的判断标准
3. 后续整套专栏的方法论起点：如何约束 AI，而不是放任 AI 自由发挥

核心内容

你以为你在让 AI 写代码，其实你在让它连续下注

很多人给 AI 的指令是这样的：

帮我做一个任务管理命令行工具，支持新增、删除、列表查看。

这类 Prompt 的问题不在于“太短”，而在于它只描述了结果，没有定义过程。

AI 会立刻给你一份看起来很完整的输出：

• 一个 main.py
• 几个命令分支
• 一个 JSON 文件存数据
• 顺手再加一点“贴心”的错误处理

第一次看，挺好。

第二次你说“再加一个截止日期”。

第三次你说“顺便支持中文”。

第四次你说“能不能把存储改成 SQLite”。

到这里，问题就出现了：前面的代码并不是按可演进的方式设计出来的，它只是为了“回答上一个问题”而临时拼起来的。AI 的每一次后续修改，本质上都是基于一个未经验证的旧状态继续下注。

下注次数越多，项目越难维护。

一个很典型的对比：普通 Prompt 和工程化 Prompt 的差别

同样是让 AI 做一个任务管理 CLI，下面两种问法会把项目带向完全不同的方向。

普通 Prompt

帮我写一个 Python 命令行任务管理工具，支持 add/list/done。

这类提问通常会得到什么？

• AI 直接开始写代码
• 默认把 CLI、存储、展示逻辑揉在一起
• 没有测试
• 没有需求边界
• 没有后续扩展考虑

它看起来很快，但其实跳过了所有真正影响长期质量的步骤。

工程化 Prompt

我们要做一个个人任务管理 CLI。先不要写实现。
先输出：
1. 需求边界
2. 用户场景
3. 命令设计
4. 数据模型
5. 测试策略
6. 潜在风险
确认后再进入实现。

这次 AI 的行为会完全不同：

• 它先澄清边界，而不是直接开写
• 它把需求拆成结构化问题
• 它会暴露不确定性
• 它会留下后续实现的依据

这就是“AI 写代码”和“AI 做工程”的本质差异。

前者关注“这次回答能不能交差”，后者关注“这个项目能不能持续演进”。

真正让项目失控的，不是 AI，而是缺少约束

很多人说 AI 最大的问题是幻觉。

我不完全同意。

在日常开发里，更常见的问题不是它编了一个不存在的 API，而是它做了下面这些“表面正确”的事：

• 默认替你做技术选型
• 偷偷省略测试
• 用重构包装临时修补
• 为了让当前问题看起来解决，顺手改掉一堆你没要求的东西
• 输出一个可以运行但没有演进空间的初始版本

这些行为单次看都不致命，但连续叠加，项目会进入一种很糟的状态：

• 可以跑
• 可以演示
• 但是不敢改

这才是独立开发者最危险的陷阱。

因为你会误以为自己“进度很快”。

为什么 AI 越用越难维护

归根结底，是因为大多数人把 AI 当成“更快的代码生成器”，而不是“需要流程约束的协作对象”。

你让一个没有边界、没有记忆纪律、没有验证要求的系统持续修改同一套代码，结果一定是：

1. 局部最优越来越多
2. 全局一致性越来越差
3. 隐性技术债累积越来越快

传统团队里，这些问题会被角色分工部分抵消：

• PM 控边界
• 设计做抽象
• 开发写实现
• QA 校验行为
• Reviewer 卡质量

但你一个人 + 一个 AI 时，这些角色默认全部消失了。

如果你不主动补回流程，AI 只会把“没有流程”这个问题放大。

工程化到底在解决什么

很多人一听“工程化”，就以为是在讲大公司流程。

其实独立开发者更需要工程化。

因为你没有团队兜底，没有额外的人帮你发现问题。今天写下去的每一个妥协，都是未来的你自己来买单。

AI 工程化至少要解决四件事：

1. 让 AI 在写代码之前先想清楚
2. 让修改有依据，而不是靠上下文碰运气
3. 让每一步都有验证，而不是“看起来像对了”
4. 让项目可以持续迭代，而不是只能做一次性演示

这四件事，本质上都不是模型能力问题，而是工作方式问题。

这也是为什么“再试一次”不是办法

很多人遇到 AI 输出不好，会继续说：

• 再优化一下
• 再试一次
• 这次不要那么复杂
• 重新写一个更好的版本

这类交互的核心问题是：你没有引入新的约束，只是在重复碰运气。

如果过程没变，结果通常不会本质变好。

你可能会获得一份“不同的代码”，但不会获得一份“更可维护的系统”。

从下一篇开始，我们不再让 AI 自由发挥

接下来这组文章，会围绕一个真实项目展开：

TaskCLI，一个个人任务管理命令行工具。

它不复杂，但足够真实：

• 有命令行交互
• 有持久化
• 有测试
• 有后续迭代需求
• 后面还可以自然扩展到 API 和前端

我们不会用它做“AI 一把梭”的演示，而是拿它完整走一遍真正的工程流程：

• 需求分析
• 架构设计
• TDD 实作
• Debug
• Review
• 多 Agent 协作
• CI/CD 自动化

到最后，你拿到的不只是一个小项目，而是一整套能复用到别的项目里的方法论。

补充说明

为了让这套方法真正落地，这个系列不会停留在“概念讨论”层面，而会逐步把约束 AI 的方法，落实到真实的项目文件和实际协作流程中。

后续你会看到的，不只是文章内容，还会包括这些非常具体的东西：

• 项目目录应该怎么设计，才能让 AI 不容易写乱
• Prompt 应该如何分层，避免每一次都从零开始碰运气
• 什么内容应该放进 AGENTS.md
• 什么约束应该固定在仓库里，而不是每次手写一遍
• 为什么测试、Review、上下文文件，对 AI 协作比对人协作更重要

换句话说，这个系列最终要解决的，不是“怎么让 AI 多写一点代码”，而是“怎么让 AI 少制造一点未来的麻烦”。

结论

这篇文章最重要的结论只有一句：

AI 的问题不只是“写得不对”，而是“在没有工程约束的情况下，它会稳定地产生越来越难维护的代码”。

你需要的不是一个更会写代码的 AI。

你需要的是一套能约束 AI 行为的工程方法。

本篇交付物

• 一套问题认知框架：AI 写代码 != AI 做工程
• 一组可直接复用的工程化 Prompt 骨架
• 接下来整套专栏的项目主线：TaskCLI

与上一篇/下一篇的衔接

这是开篇，没有上一篇。

下一篇我们把环境真的搭起来，把“约束 AI”这件事落到文件、目录和项目上下文里。你会看到，同一个模型，一旦工作方式变了，输出质量会像换了一个人。