对AI工程问题的一些思考

AI Agent 编程正在重塑软件工程的底层逻辑过去三到五年AI 编程工具经历了从「辅助插件」到「协作主体」的范式迁移。最早以 GitHub Copilot 为代表的产品本质上是一种上下文感知的智能补全引擎——它能根据当前文件的光标位置预测并生成下一段合理的代码片段。但随着大语言模型能力的跃升和工具链的成熟第二代 AI 编程工具——以 OpenAI Codex、Anthropic Claude Code、Cursor Agent、Devin 等为代表——已经展现出完全不同的能力边界。它们不再被动响应输入而是主动参与工程流程全局感知遍历整个代码仓库理解目录结构、模块划分与依赖拓扑跨文件操作同时修改多个相关文件保持接口与实现的一致性环境交互自主执行 shell 命令、启动服务、运行测试套件依赖分析识别循环依赖、冗余引用和版本冲突方案生成基于问题描述自动输出架构选型建议与实现路径这意味着AI 编程已经完成了从「代码补全」到「任务执行」的质变。从片段生成到目标驱动的任务闭环传统工具的输入输出模型可以用一句话概括根据上下文补全下一段代码而 Agent 型工具的运作逻辑则更接近于一个工程执行单元的信息处理闭环理解目标 → 探索系统 → 制定方案 → 分步执行 → 验证结果以一个真实的修复场景为例分析当前仓库中的认证系统定位 JWT 刷新令牌的刷新逻辑识别并发请求下的 token race condition 问题提出原子化更新方案修改相关服务层代码并更新测试用例执行回归测试生成 patch 文件这已经不是简单的代码生成了。它更接近于你给一个有执行能力的资深工程助手下达明确指令然后它带着上下文、工具和判断力去完成。Prompt 的重要性被高估Context Engineering 才是核心很多刚接触 Agent 的开发者会下意识地寻找「万能提示词模板」——期待某一句措辞精妙的指令能释放 AI 的全部潜力。但深度使用后会发现一个反直觉的事实真正决定 AI 输出的质量天花板的不是你怎么问而是你给了它什么上下文。这涉及到几个关键维度仓库结构的可发现性目录是否遵循约定优于配置模块职责是否一眼可辨项目规则的显式化程度编码规范、分层约束、命名约定是写在文档里还是仅存于老员工的隐性知识中上下文的完整度与精度相关的架构决策记录ADR、接口契约、历史变更动机AI 是否能快速定位任务边界的明确性是「改一下认证模块」还是「修复 token 刷新并发问题仅限 service 层保持 API 兼容」工程规范的统一性全仓库是否使用一致的 lint 规则、格式化配置、测试框架约定这引出了一个越来越高频被提及的概念上下文工程其核心理念是与其钻研如何提问不如系统化地设计 AI 能理解的工程环境。这意味着未来的开发者需要掌握一套全新的技能树如何组织代码库使其对机器友好如何撰写让人类和 AI 都能精准理解的设计文档如何维护一套可被自动化工具消费的项目规则体系。为什么开始引入 AI 约束层一个肉眼可见的趋势是越来越多的项目仓库中开始出现这些文件AGENTS.md RULES.md CLAUDE.md ARCHITECTURE.md CONVENTIONS.md它们并非简单的文档而是机器可读的工程约束声明。例如一份典型的AGENTS.md会包含## 行为约束 - 严禁自动修改 /migrations 目录下的任何文件 - Service 层禁止直接访问数据库必须通过 Repository 层 - 重构时禁止改动与当前任务无关的模块 - 所有 API 变更必须保持向后兼容新增字段使用可选类型 - 在修改任何现有代码前必须先阅读并复述目标模式的实现方式 - 生成的代码必须遵循项目现有的 error handling 模式 - 引入新的第三方依赖前需给出充分理由并等待确认为什么这类文件的效果立竿见影因为当前阶段 AI Agent 最大的弱点不是代码生成能力不足而是行为边界感的缺失。它会本能地自创一套与项目风格迥异的架构模式在不需要的地方引入过度抽象「顺便」重构那些它认为不够优雅但实际能正常运行的代码擅自发明不存在的业务规则或数据关系以错误的前提假设推导实现方案这些行为的共同后果是增加 Review 负担、引入隐藏风险、破坏项目一致性。因此越来越多的高质量 Agent 工作流其设计哲学可以浓缩为一句话用清晰的约束驯服 AI 的即兴发挥冲动。日趋成熟的 Agent 协作模式规则、小步、确认、审查经过近两年的实践社区正在收敛于一套相对稳定的 Agent 使用模式。关键洞察是永远不要让 AI 直接执行「宏大模糊的指令」。你不会对 AI 说「重构整个用户模块」。你会将其拆解为结构化的协作流程1. 分析用户模块现有结构输出依赖关系和数据流图 2. 总结当前实现的架构特征和潜在问题点 3. 基于分析结果提出 2-3 个重构方案含风险评估 4. 暂停等待人工选择方案 5. 执行选定方案的第一阶段修改限定文件范围 6. 运行相关测试套件输出通过/失败详情 7. 人工 Review diff确认无误后继续下一阶段这套流程之所以有效是因为它精准匹配了当前 AI 的能力分布擅长在明确约束下针对小范围问题进行快速分析、精准修改、自动测试不擅长承担模糊的全局目标在缺乏规则引导时进行开放式决策被低估的最大价值理解系统而非生成代码大量工程师在深度使用 Agent 后会逐渐收敛于一个共识AI 省下的时间主要不是花在「写代码」上的而是花在「读懂代码」上的。软件开发中真正的认知负荷从来不是敲击键盘而是阅读并理解一个陌生的历史项目追踪一条调用链穿越数十个文件和层级理解一段没有注释的复杂逻辑的原始意图在庞大的依赖网络中定位影响范围为缺乏测试的遗留系统补全测试覆盖在大规模模块中快速定位问题根因整理并结构化散落的设计知识而 AI Agent 恰好是这些任务的天然适配器。它能以远超人类的速度完成广度阅读、模式识别和影响分析将开发者从海量的信息检索和理解成本中解放出来。写代码的成本在降低理解系统的成本才是真正的瓶颈——而 Agent 正在系统性压低这一成本。下一代软件工程基础设施面向 AI 原生的仓库如果我们接受「AI 将成为软件开发的核心参与方」这一前提那么很自然的推演是未来的代码仓库必须同时为人类和 AI 两者设计。这预示着一场新的工程文化变迁其方向可能包括更标准化的目录结构超越传统约定形成 AI 可稳定解析的项目骨架模式更完整的结构化文档模块设计意图、接口契约、架构决策记录ADR以统一的 schema 组织更明确的规则系统行为约束、风格指南、分层规则从「团队公约」升级为「可自动执行的配置」更清晰的模块边界通过显式声明如 module boundary files定义公共 API 和内部实现降低 AI 的越界风险更适合 Agent 的上下文格式项目关键信息以摘要、索引、导航等形式存在便于模型快速建立全局心智模型软件仓库正在从一个被动存储代码的容器演变为一个主动参与协作的工程环境。能力不会消失只是重新分配流行的焦虑叙事是「AI 会不会让程序员失业」但更准确的描述或许是AI 正在替代软件开发中的「实现」环节同时大幅抬高了「治理」环节的价值。那些正变得愈发稀缺和重要的能力包括架构能力在更大的设计空间中做出合理的技术决策系统治理能力定义模块边界、管理技术债务、维护架构一致性任务拆解能力将模糊的产品需求转化为 AI 可执行的精确指令序列风险控制能力预判 AI 修改的边界效应设置安全的变更范围上下文组织能力持续维护让 AI 高效运转的工程环境工程规范设计能力制定约束让团队与 AI 在同一规则下协作未来的软件开发画面开始浮现人负责定义「做什么」和「不能做什么」AI 负责探索「如何做」并执行。高质量开发流程的重心将从「如何写出更好的代码」逐渐转向「如何设计更好的协作系统」。结语新工程素养的崛起AI Agent 编程不是「更强的代码补全工具」。它在从根本上改变软件工程的组织方式与能力模型未来的高效开发者未必是键盘输入最快的那个人。更大概率是最善于拆解复杂问题的人——能将模糊目标转化为精确定义的可执行任务最善于组织工程上下文的人——能维护一套让 AI 稳定产出的信息环境最善于定义规则和边界的人——能用约束激发 AI 的精准度最善于设计人机协作流程的人——能编排 AI 的探索、执行与验证步骤因为 AI 真正的价值从来不只在于生成更多代码。而在于系统性地降低理解复杂系统的成本让人类的注意力回归到更高层次的创造与决策。这也是为什么Agent 型 AI 不再只是玩具或 demo 工具而是正在成为工程领域的基础设施。但是其内核还是人人决定了这个方向我们要的是更好的把握他然后给大家一些常见的工程约束方法# Architecture Rules - Service layer cannot access DB directly - Never modify migrations automatically - Keep API backward compatible - Prefer existing patterns - Do not refactor unrelated modules架构规则 -服务层不能直接访问数据库 -不要自动修改迁移 保持API向后兼容性 优先使用现有模式 -不要重构无关模块