今年处理团队技术债时，我开始大规模使用 AI 辅助项目开发。最近完成的一项工作，是将团队内多套 Web 基础设施整合为一套方案。
Web 基础设施的技术债
由于历史原因，团队内部的 Web 项目同时使用 Vue 2、Vue 3 和 React，每套技术栈依赖的底层基础设施也不同。 同时，微前端有两套实现：基于 iframe 的主子应用方案，以及基于 qiankun（乾坤）的方案。 渲染模式同时包含 CSR（客户端渲染）和 SSR（服务端渲染）。 整个工程体系还需要依赖 Node.js 10、14、16、20 等多个版本才能运行，维护范围较大。
统一基础设施的目标
1. 成本视角
- 统一基建：将现有多套基础设施整合为一套，降低长期维护成本。
- 平滑迁移：让已有的老旧方案能够迁移到新的统一方案。
2. 易用性视角
- 现代化工具链：引入现代前端工具链，统一开发环境。
- 降低门槛：优化配置流程，让新成员更容易完成环境配置和项目开发。
3. 可演进性视角
- 可扩展性：架构需要支持未来多样化的业务需求，并保持基础架构的稳定性。
- 跨框架复用：底层能力同时支持 Vue 2、Vue 3、React 等前端框架，避免重复实现。
- 工具解耦：工程化工具不深度绑定某个构建工具，以便后续替换或演进。
项目约束与工具链选择
推进统一基建时，需要控制架构复杂度和改造成本。团队同时在跟进优先级更高的业务需求，因此无法在这项工作上持续投入较多精力，计划从年初搁置至今。主要限制包括：
- 历史方案的迁移成本：需要处理大量遗留问题。直接采用任一现有方案，都会让其他业务线承担较高迁移成本。
- 自研工具链的成本：完全自研工具链时，开发和试错成本难以控制。
AI 完成工具开发和验证的方式
参与其他 AI 项目后，我判断当前大模型已能承担部分工程开发任务，因此在这个基建项目中进行了实验。
整体分工是：AI 完成工程工具的开发与验证；我负责整体架构设计、详细需求方案和关键决策。
AI 累计编写约 10 万行代码，并输出 7 万行需求与设计文档。当 AI 无法继续推进时，我会介入查看代码并提供指导。全部工作在不到 5 天内完成。
整体架构图如下：
项目拆解、测试和上下文控制
- 项目拆解与 AI 协作：工程师提供总体目标；AI 拆分具体任务，并与我确认任务边界及验收标准。
- TDD（测试驱动开发）：测试为 AI 提供反馈，使其能在设定的最大迭代次数内根据失败结果调整实现。
- 上下文（Context）控制：
- 架构分层和接口文档：AI 完成每层模块后，需要生成接口文档，只暴露调用方必须了解的能力。这减少了单个任务需要加载的信息量，避免上下文过载引发不一致的实现或逻辑错误。
- Rules 按需加载：非必要信息不一次性加载，保留 AI 在代码库中检索和探索的空间。
需要补充的反馈与求助机制
- 主动求助机制：Rules 可以帮助 AI 理解公司内部基建的用法。但在多轮 Loop 中，AI 处理某些业务模块时如果没有找到必要信息，可能生成与公司基建不一致的代码。遇到信息缺口时，AI 应退出当前循环并向研发人员提出具体问题。
- 非代码逻辑的反馈机制：单测无法完全覆盖 CSS 配置等中间状态时，AI 自行循环探索的效率较低。此时，提供一个简单项目的 Few-shot（少样本提示）更有帮助；也可以引入端到端（E2E）测试作为反馈来源。
工程师职责从实现转向决策和反馈设计
2015 年刚工作时，我的 TL Rank 在第一次见面时谈过工程师（Engineer）的定位：工程的含义是在现实约束下用科学方法解决问题，写代码只是其中一种手段。AI 参与开发后，工程师在流程中的职责发生了变化。过去，设计、实现、开发、调试和测试主要由工程师完成；现在，Agent 可以承担其中部分执行工作。
这项实践涉及两类职责变化：工程师设计决策路径和反馈机制，Agent 根据这些约束完成任务。
Agent 需要可读取、可执行的工程信息
当 Agent 的实现不符合预期、采纳率较低时，原因可能是它缺少完成高层目标所需的环境信息、工具、抽象或内部结构。此时需要检查缺少的能力，以及如何让 Agent 能读取并执行这些能力，而不是只更换 Prompt。
工程师仍需定义边界。例如，可以将研究和实现分开：先用一个 Session 让 Agent 调研方案，确定技术路线后，再使用干净的 Session 完成实现。
用自动化反馈验证 Agent 的交付结果
人通过 Prompt 下达任务后，Agent 的执行结果仍需要验证。人工确认 PR 是否正确会形成瓶颈，因此可以由 Agent-to-Agent 流程承担部分验证工作。
- 通过 Chrome DevTools Protocol 让 Agent 截图、操作 DOM、重现 Bug；
- 通过 Console 让 Agent 查看日志和网络请求，分析中间过程。
软件构建仍需要一致性。使用 Agent 后，这种一致性更多依赖工程架构、环境感知和反馈循环的设计，而不只依赖人工编写和审查代码。这些能力会影响 Agent 能否在既定约束内完成任务，也是后续工程实践需要持续验证的方向。
