对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 会包含：

markdown 复制代码

## 行为约束

- 严禁自动修改 /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向后兼容性
优先使用现有模式
-不要重构无关模块