别让 AI 把你的项目变成“自动生成的屎山”

AI编程使用路程

时间线

先来说下我目前使用 AI 的情况：

• 2022年底 从 ChatGPT 3.5 出来的时候开始使用网页问答的方式问一些有趣的问题。当时还是测试 AI 智力的心态，当作一个玩具。

• 2023年 ChatGPT 4 已经从浏览器搜索问题开始逐渐转到 AI 问答解决一些日常开发的问题。

• 2024年尝试使用文心一言、通义千问、Kimi、豆包等国产化问答工具。

• 2025年

  • 3月 开始使用 Trae AI 海外版、Windsurf、Cursor。
  • 11月 开始使用 Qoder（AWS Kiro）。

• 2026年开始使用 Trae 中文版（免费） + Qoder。

代码产出率

当前所参与项目为高复杂度全栈系统，涵盖客户端与服务端，整体代码规模超过80万行。不同阶段AI生成代码在项目中的占比呈现显著增长趋势：

• 2024年 使用国产化问答工具，主要解决单个工具的方法实现。AI 产出代码比例为15%--20%。

• 2025年尝试使用各类AI编程工具：

  • 3月产出比例为20%--30%；
  • 11月产出比例提升至30%--40%。

• 2026年开始使用 Trae 中文版 + Qoder，AI产出比例达到60%--90%。

  具体取决于业务复杂度。对于逻辑清晰、边界明确的简单需求，常可实现"一次生成即合入"。

  这一跃升主要得益于"Spec + Plan"模式的成熟应用，以及底层大模型在代码理解与生成能力上的实质性突破。

潜在风险分析

在AI生成代码占比持续攀升的背景下，若干系统性风险逐步显现，若缺乏有效管控机制，将对软件工程的长期可维护性与交付稳定性构成威胁。

• 代码掌控力缺失风险：当AI生成代码占比超过60%，开发者往往难以对海量自动生成代码形成深度理解。多数场景下仅依赖冒烟测试验证功能可用性，缺乏对核心逻辑设计合理性、算法效率及耦合结构的深入审查，导致对系统行为的掌控能力显著弱化。
• 缺陷隐匿与放大风险：AI生成的代码通常能通过基础功能测试，看似正确，但在边界条件、异常处理、资源释放和性能关键路径上常存在隐蔽缺陷。尤其在多模块协作时，因缺乏对跨模块业务语义的整体理解，生成的代码在集成后容易引发深层次兼容性问题。这类问题随项目规模扩大而快速累积，不仅持续劣化代码质量，还会触发"隐性技术债 → 破窗效应 → 系统复杂度失控"的恶性循环，严重削弱交付稳定性。
• 线上故障排查效率下降风险：由于开发者对AI生成代码的实现细节缺乏充分掌握，一旦线上发生故障，问题定位与根因分析过程将显著延长。典型表现为：开发阶段交付高效、体验流畅，但故障发生时难以快速还原执行路径或理解异常传播链，造成响应延迟与运维成本上升。
• 效率与质量失衡风险："Spec驱动"的高效交付模式在加速需求响应的同时，也容易诱使团队简化代码评审流程。实践中，部分团队仅验证核心功能是否满足Spec要求，而忽略对可读性、可测试性、扩展性等非功能性属性的审查。这种短期效率导向的做法，长期将加剧质量债务，形成效率提升与系统健壮性之间的结构性矛盾。
• 开发者专注力碎片化风险：在多项目并行环境下，AI生成代码的"黑盒属性"显著增加认知负荷。开发者需在不同项目的生成逻辑间频繁切换上下文，每次切换均需重新解析陌生代码结构与隐含假设，导致深度工作状态难以维持，反而降低整体研发吞吐效率。

尝试解决方案

为系统性应对上述风险，需构建覆盖需求、生成、验证、演进全生命周期的AI协作治理框架。

前置方案治理：

• 业务目标要可衡量，不能模糊描述
  比如"支持用户导出模型"必须细化为："普通用户最多导出包含 500 个节点的流程图，VIP 用户上限 2000 节点；导出 SVG 在桌面端需在 2 秒内完成，超时需提示'内容过大，建议简化后重试'"。没有这些具体业务规则，AI 只能按通用逻辑生成代码，无法覆盖真实用户场景。
• 业务边界和失败策略必须提前对齐
  例如："分享链接有效期为 7 天，过期后访问应展示友好提示而非报错；协作编辑时若两人同时修改同一节点，以后保存者为准，并记录冲突日志"。这些不是技术细节，而是产品与用户之间的契约。只有在 Spec 阶段由产品、开发、测试共同确认清楚，AI 生成的逻辑才真正可用，而不是上线后才发现漏了关键业务规则。

自动化测试要覆盖真实业务路径

• 单元测试不能只跑通 happy path，必须针对业务关键逻辑设计用例。比如模型坐标换算、节点序列化等核心函数，要覆盖 空模型 超大节点数 非法输入 等边界场景，确保 AI 生成的代码在异常情况下不会静默失败或崩溃。
• E2E 测试要模拟真实用户操作流，例如创建流程图 → 添加 1000 个节点 → 导出 SVG → 分享链接 → 另一用户打开并编辑 。只有在这种端到端链路中验证，才能发现 AI 生成代码在集成上下文中的行为偏差。

代码审查

当 AI 能自动生成 60%--90% 的代码，代码审查非但不能弱化，反而成为整个研发流程中最关键的质量控制节点。它不再是"查错"，而是"验真"------验证生成逻辑是否真正对齐了业务意图与系统契约。

• 自动化工具守住工程基线

  SonarQube、ESLint 等可高效拦截重复代码、安全漏洞、空指针等通用问题，确保 AI 输出达到基本可维护标准。

• 人工审查

  AI 不理解"为什么这样设计"，只执行"怎么写"。因此，开发者必须通过 Review 回答以下问题：

  • 导出失败时，提示文案是否符合产品定义的用户引导策略？
  • 协作冲突处理是否遵循团队约定的"后保存胜出 + 日志留痕"规则？
  • 分享链接是否包含租户 ID 和追踪参数，以支撑权限控制与增长分析？
  • 是否在主线程同步处理千级节点序列化，导致 UI 卡死？

  这些问题无关语法，却直接决定功能是否"可用、可信、可持续"。

• 代码审查

  AI 生成的代码往往"看起来能跑"，但可能在边界、权限、降级、一致性等维度悄然偏离业务预期。若无人工介入核验，这些偏差将随合入主干而固化，最终演变为难以追溯的线上故障或技术债。

  因此，在 AI 高比例参与开发的今天，严格的人工代码审查不是成本，而是对系统长期健康最高效的投资。

把业务经验变成可复用的AI上下文

• 将项目中反复出现的业务规则沉淀下来，比如"SVG 导出最大支持 2000 节点""分享链接 7 天过期""VIP 用户可跳过队列限制"。这些不是文档归档，而是未来写 Spec 时的"标准答案"。
• 这些资产可直接用于增强 AI 的输入上下文（如通过 RAG），让模型在生成代码时自动继承团队已验证的业务逻辑，减少"重新发明轮子"或"凭空猜测规则"的风险。

开发者不可替代的核心能力

AI 能高效生成代码，但无法替代开发者在复杂系统中对业务本质的理解、全局风险的预判以及协作规则的设计。

从模糊诉求中还原真实业务目标

• AI 只能响应明确指令，而真实需求往往藏在用户反馈或产品直觉背后。
  例如，当产品说"希望提升模型导出成功率"，表面是技术问题，实则源于用户抱怨："我画了两个小时的图，点导出直接卡死，啥都没了"。
  开发者需识别其真实诉求：不是"导出更快"，而是"操作不丢失、失败有退路" 。
  由此推导出技术方案：
  • 导出前自动保存草稿；
  • 大模型导出走后台任务，前端展示进度与取消选项；
  • 失败时保留原始数据并提示"可重试或简化后导出"。
    这种从情绪化反馈到可执行技术策略的转化，依赖对用户行为、产品目标与系统能力的综合理解，AI 无法独立完成。

在局部功能与系统稳定性之间做架构权衡

• AI 生成的代码通常满足单点功能，但难以评估其在整体系统中的长期影响。
  以"多人实时协作编辑流程图"为例，AI 可实现"节点拖动后同步位置"，但无法判断：
  • 是否应限制单次操作的节点数量，防止恶意刷屏导致服务雪崩；
  • 客户端是否需本地回滚机制，应对网络中断时的操作一致性；
  • 服务端是否要为高频写入设计独立队列，避免阻塞读请求。
    这些决策涉及性能、成本、可用性与安全的多维平衡，必须由开发者基于业务规模和 SLA 主动设计，而非事后修补。

主导 AI 协作的质量规则

• 高效使用 AI 的关键不在工具本身，而在人制定的协作规则：
  • Spec 必须包含业务约束：如"VIP 用户导出上限 2000 节点，普通用户 500，超限时引导升级而非报错"；
  • 质量门禁必须覆盖业务路径：自动化测试验证边界，人工 Review 聚焦权限、冲突、降级等核心逻辑；
  • 技术债需主动管理：定期清理 AI 生成的冗余分支、硬编码配置或重复逻辑，防止"快交付"演变为"难维护"。

未来演进建议

以可控交付作为核心指标

• 不再追求"AI 写了多少行"，而是关注"需求是否被正确理解、生成结果是否经过验证、关键路径是否有人兜底"。
  建议在每个功能启动前，强制进行三方对齐（产品+开发+测试），明确：
  • 用户在什么条件下触发该功能；
  • 成功/失败/异常时的预期表现；
  • 系统如何降级或引导。
    只有形成共识的 Spec，才能成为 AI 可靠的输入源。

让每一次 AI 协作都沉淀为团队资产

• 将 AI 协作嵌入业务演进循环：
  1. 拆解真实场景：如"用户 A 分享模型给 B，B 在手机上打开并评论"；
  2. 提取可执行规则：链接有效期 7 天、移动端自动降级渲染、评论需登录；
  3. 驱动 AI 生成 + 自动化验证：E2E 测试覆盖该完整链路；
  4. 沉淀为上下文资产 ：将验证通过的规则存入知识库，用于后续 RAG 或 Spec 模板。
     如此，AI 不再是孤立的编码工具，而是团队经验的执行延伸。

让 AI 继承团队共识，而非重复试错

• 系统化积累"已验证的业务规则"，例如：
  • "导出 SVG 超 2000 节点时，前端禁止发起请求并提示"；
  • "协作编辑冲突以后保存者为准，但需记录操作日志供审计"；
  • "分享链接过期后不返回 404，而是展示引导注册页"。
    这些资产反向赋能Spec生成与RAG检索，使AI不仅能写代码，更能继承并扩展开发者的历史经验，真正成为智能生产力的倍增器。

总结

AI 编程不是"要不要用"的问题，而是"如何用对"的问题。

当生成代码占比突破 60%，效率的红利背后，隐藏着掌控力流失、缺陷隐匿、质量失控等系统性风险。真正的破局点，不在于工具本身，而在于建立以业务为中心、以质量为闭环的协作机制：

• 用充分讨论的 Spec 替代模糊指令，
• 用聚焦业务的人工 Review 守住最后防线，
• 用可沉淀的规则资产 让 AI 继承团队经验。

开发者的价值，正从"写代码"转向"定规则、控风险、保一致"。唯有如此，AI 才能从"提效工具"真正进化为"可靠协作者"，而非"技术债加速器"。