引言
2025年，AI编程工具的能力边界持续拓展。过去我认为AI仅适用于单文件原型或语法辅助，难以支撑复杂业务系统的迭代；如今在特定条件下------如提供清晰的上下文、明确的架构约束和规范的代码风格------AI已能在部分场景中生成结构较合理、逻辑基本正确的多文件代码，并经人工审查后用于生产环境。
我们的业务属于高复杂度工业软件：基于Electron的桌面端建模工具，前端需高性能SVG交互渲染，后端依赖Node.js进行几何计算、拓扑分析与约束求解，系统横跨渲染、计算与业务规则三层。受限于领域专业性与逻辑耦合度，此前AI仅能解决零散单点问题，难以参与系统级开发。当前，我们正尝试在可控范围内将其引入模块重构、样板代码生成与测试用例辅助等环节，逐步探索其在复杂工程中的实用路径。
一、早期阶段的主要问题
在年初尝试将 AI 编程引入日常开发流程时，以下三类问题显著限制了其在真实项目中的可用性：
1. 无法自动处理模块依赖
当在组件中使用未显式导入的函数或类型（如 useRouter、axios、自定义 Hook），AI 生成的代码通常不会自动添加对应的 import 语句。这导致代码无法直接运行，需人工补充依赖，破坏了端到端交付的可行性。
2. 功能实现与需求存在偏差
例如，要求实现"带防抖的搜索输入框"，AI 可能仅返回基础输入控件，遗漏防抖逻辑；或错误引用项目未使用的第三方库（如用 lodash.debounce 而非项目统一的 utils/debounce）。此类偏差需多次交互修正，整体效率低于手动编码。
3. 多文件协同能力薄弱
即使是简单的跨文件需求（如新增一个页面需同步修改路由配置、API 层和视图组件），AI 也难以保证各文件间的命名一致性、引用正确性及逻辑完整性。常见问题包括：
- 路由路径与组件文件名不匹配；
- API 方法未被视图层调用；
- 状态管理模块缺失对应字段。
此时的结论是：AI 适用于孤立代码片段生成，但无法独立完成端到端业务功能开发。
二、当前能力验证：AI 可交付真实业务功能
进入下半年后，随着提示工程方法的成熟和模型上下文理解能力的提升，AI 在以下场景中表现出可靠的业务交付能力。
场景 1：多文件联动的常规功能开发
需求 ：在后台系统中新增"公告管理"模块，包含列表页、详情页、新增/编辑表单，并对接权限控制（notice:write）。
实现方式：提供模块名称、字段定义（标题、内容、状态、发布时间）、权限标识及项目目录结构规范。
结果：AI 一次性生成以下内容：
src/views/notice/index.vue（列表）src/views/notice/form.vue（表单）src/api/notice.ts（封装 CRUD 接口）src/router/modules/notice.ts（路由注册）- 权限指令自动注入（如
v-permission="notice:write"）
各文件间引用关系正确，命名符合项目约定，无需手动调整即可联调。
场景 2：具体交互逻辑的快速实现
需求 ：在画布坐标 (x=200, y=150) 处绘制一个模块，点击后变为高亮状态。 
结果：AI 输出基于 SVG 的完整实现，包含：
- 理解服务端创建图形的业务逻辑，创建指定类型图形
- 使用封装好的一套流程确保服务端推送消息给客户端
- 客户端基于服务端的消息类型正确绘制图形，并选中新绘制的图形
代码一次运行成功，无语法或逻辑错误。 
场景 3：基于文档生成复杂功能
输入：
- 接口文档；
- 功能流程图（用户选择 → 分片计算 → 并发上传 → 合并通知）。
输出：
- 前端分片逻辑；
- 上传进度处理；
- 合并请求触发逻辑。
验证结果：生成代码零修改即可运行，上传流程完整通过测试。
三、辅助能力的实质性改进
除核心编码外，以下辅助功能显著提升了开发体验：
- 自动翻译：选中文本可一键翻译为中文，适用于错误日志、英文文档等场景。
- Key-Value 双向补全 ：在 i18n 或配置对象中，输入值（如
"提交订单"）可反向推导出合理键名（如order.submit），此前仅支持由键推值。 - 注释驱动代码生成 ：在函数体内编写注释（如
// 校验手机号格式），AI 可自动插入对应校验逻辑，无需触发问答模式。 - 代码注释自动生成：对已有函数，可生成符合 JSDoc 规范的注释。
- 简单逻辑自动生成: 甚至不需要注释等，AI 会根据你的代码上下文推断出你的业务逻辑代码。特别是在你有些相同代码逻辑操作时。
这些改进降低了人机交互的认知成本，使 AI 更自然地融入编码流程。
四、当前仍存在的工程问题
尽管能力显著提升，但在以下场景中仍存在明显瓶颈：
1. 环境依赖配置易陷入死循环
AI 生成的终端命令（如 npm install sharp）在本地执行时，若缺少系统依赖（如 Python、libvips），会报错。后续 AI 提供的修复建议（如"安装 build-essential"或"升级 Node 版本"）可能引发新的依赖冲突，最终导致环境配置卡死，无法继续开发。
建议：涉及系统级依赖的操作，应由开发者手动执行并验证。
2. 长任务缺乏中断与局部修正机制
当 AI 执行包含多个步骤的复杂任务（如"重构权限系统"），若中途发现某一步骤存在设计缺陷（如权限粒度不合理），当前工具链不支持：
- 修改中间步骤
- 从指定节点继续执行。
只能选择完全中断（丢失已生成内容）或强行继续（增加返工成本）。
期待：未来工具应支持任务分解视图与节点级编辑能力。
3. 面对复杂任务及多项目时只处理部分需求
我将前后端项目放在一起，向 AI 提问时，我提出同时生成前后端的接口定义以及相关逻辑时，并描述清楚对应的需求，指定对应的 rules。但是 AI 编辑器却只生成了两行代码。后面我又尝试了几次，
- 有一次任务拆解了五分钟，token 消耗了两次，没有生成任何代码。
- 有一次任务拆解了五分钟，只生成了服务端的部分代码。
最终我只好在各自的项目中去通过 AI 生成代码。
五、开发者角色的转变：从编码者到规则定义者
过去：AI 仅用于原子任务
典型用法包括：
- 生成单个组件模板；
- 补全 CSS 样式；
- 解释错误堆栈。
面对跨模块需求，必须由开发者手动拆解为多个独立子任务，再逐个交由 AI 处理。
现在：AI 可处理端到端业务流
前提是开发者持续沉淀并维护项目的 工程规则（Rules），例如：
- 文件命名规范（
api/user.tsvsservices/user.api.js）； - 状态管理结构（Vuex/Pinia 模块划分）；
- 错误处理统一策略（全局拦截 + 用户提示）；
- 权限控制集成方式。
当这些规则通过提示词或项目上下文显式传递后，AI 能自主协调多个文件，完成完整业务功能，无需人工干预拆解。
核心变化：开发者的工作重心从"如何写代码"转向"如何定义项目规则"。
六、AI 对开发者能力的实际赋能
1. 跨领域开发成为可能
前端开发者可通过 AI 快速生成后端接口逻辑（如 Express 路由、数据库查询）、部署脚本（Dockerfile、CI 配置），降低跨栈门槛。AI 在此过程中充当"即时知识源"，通过问答辅助理解实现细节。
2. 核心精力聚焦高价值环节
基础编码（表单、列表、加载状态、错误处理）可交由 AI 完成，开发者得以将时间投入：
- 业务流程合理性分析；
- 用户体验优化；
- 系统架构演进规划。
价值迁移：从"实现功能"转向"定义问题与验证方案"。
学习路径：从线性积累到问题驱动
- 传统路径：先学习语言语法 → 框架原理 → 工程实践（周期长，易中断）。
- 当前路径：直接通过 AI 生成可运行项目 → 在调试中识别知识盲区 → 针对性查阅文档 → 补充理论。
学习效率提升：以实际产出为锚点，形成"用---问---学"闭环。
结论
AI 编程工具已具备接管真实业务开发的能力，但其有效性高度依赖于开发者对项目上下文的结构化表达。未来，优秀的工程师将不仅是代码编写者，更是工程规则的设计者与人机协作流程的优化者。
这场变革并非取代人力，而是重新定义开发工作的核心价值：从重复实现转向系统思考，从语法掌握转向业务建模。
我们正处于这一转型的早期阶段。持续优化提示工程、沉淀项目规则、建立验证机制，将是释放 AI 编程潜力的关键。
欢迎在评论区分享你的实践经验：你在哪些业务场景中成功使用 AI 完成端到端开发？遇到了哪些工程挑战？