今年在处理团队技术债的过程中，我开始大规模使用 AI 来辅助项目开发。最近刚完成的一项重要工作，就是将团队内繁杂的 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 累计编写了约 10 万行纯代码，并输出了 7 万行的详细需求与设计文档。我只在 AI 确实遇到瓶颈、无法继续推进时，才会介入查看代码并给予指导。最终，AI 仅耗时不到 5 天就完成了全部工作。这个结果既在意料之外，又在情理之中——它真的搞定了！
整体架构图如下：
哪些事情做对了？
- 合理的项目拆解与 AI 共创：工程师负责提供宏观目标，由 AI 负责拆解具体任务，并与我确认任务边界及验收标准（如何校验是否完成）。
- 引入 TDD（测试驱动开发）模式：为 AI 建立了一个有效的反馈循环，使其能够在设定的最大迭代次数内，不断试错并逼近正确的任务结果。
- 精细化的上下文（Context）控制：
- 彻底的架构分层：每一层模块由 AI 开发完成后，都会要求其生成一份接口文档，仅暴露外部必须感知的核心能力。这有效防止了上下文过载导致模型“幻觉”或逻辑混乱。
- 妥善使用 Rules 按需加载机制：在非必要情况下，避免一次性给模型灌输过多信息，给予模型一定的自行探索空间。
还有哪些改进空间？
- 缺乏主动求助机制：虽然提供了一些 Rules 来帮助 AI 理解公司内部基建的用法，但在多轮 Loop 循环中，AI 在处理某些业务模块时，如果未能挖掘到必要信息，往往会“强行生成”与公司基建不一致的代码。理想情况下，AI 在遇到信息盲区时应该主动跳出循环，向研发人员提问求助。
- 非代码逻辑场景的反馈机制不足：在单测无法完全覆盖的场景下（例如 CSS 配置这种中间状态），让模型自行循环探索的效率很低。此时，提供一个简单项目的 Few-shot（少样本提示）会比盲目探索更有效；或者干脆引入端到端（E2E）的测试反馈循环，效果会更好。
带来的启发
15年刚上班的死后，我的TL Rank第一次见面的中午和我聊的话题就是工程师 (Engineer)的定位问题，他认为不仅仅是“写代码”，名字里面的工程实际上是在现实约束条件下，通过科学的方法解决问题的过程，写代码只是手段不是目的(大意如此)。现在在AI时代下，工程师角色在手段上我感觉会有结构性的迁移，过去的软件工程工程师是生产力，设计、实现、开发、调试、测试——每一个环节的主体都是工程师本人。但是目前 Agent 彻底从根本上重构了这个分工。 这两个例子中，我们可以观察到两个层次的能力重构，最终的目的是工程师负责设计决策路径，Agent 负责拿结果：
从”实际编码”到”工程设计”
当Agent实现不符合预期(采纳率低)，原因不在于 模型能力不够，而在于环境欠缺有效的信息。Agent 缺少完成高层目标所需的工具、抽象和内部结构。这个阶段当 Agent 在某个任务上失败时，有效的应对不应该是”换一个 Prompt 再试”，而是回到根源去问一个问题：缺了什么能力？怎么让这个能力对 Agent 变得可读且可执行（legible and enforceable）？人不写代码，但是很多边界还是需要人来把控。比如把研究与实现分离。先用一个 Session 让 Agent 调研方案，确定技术路线后，再开一个干净的 Session 让 Agent 专注实现。
从”审查代码”到”设计反馈”
人通过 Prompt 下达任务，Agent 执行后需要大量的人工来验证当前PR是否是正确的，产生了较大的瓶颈，在最新的实践中，人已经不需要参与 Code Review了，整个流程由 Agent-to-Agent 完成。
- 通过 Chrome DevTools Protocol 让 Agent 能截图、操作 DOM、重现 Bug；
- 通过 Coonsole 让 Agent 能够查看日志，查看网络请求，从而自主的分析中间过程；
当 Agent 从”辅助写代码的工具”进化为”独立交付软件的生产力”时，工程学科本身也在经历重新定义。构建软件仍然需要一致性，但这种一致性越来越多地体现在工程架构，感知环境和反馈循环的设计上，而非代码本身。这三个要素坑能会成为 Agent-First 时代软件工程的底层范式。而围绕它们的设计能力，应该是后续演进的一个很重要的方向；
