1. 从“Plan模式”到“工程制度”：为什么你的AI项目总在“跑飞”？

最近和几个做AI应用开发的朋友聊天，发现一个挺普遍的现象：大家兴致勃勃地引入Claude Code、DeepSeek或者各种开源模型，项目启动会上AI的“Plan”能力被吹得天花乱坠，什么自动规划、智能拆解、代码生成，听起来无所不能。但真到了开发中期，问题就全暴露出来了——生成的代码风格五花八门，依赖管理混乱，前后逻辑不一致，甚至同一个功能点，让AI多跑几次能给出完全不同的实现方案。最后，团队不得不花大量时间手动Review和重构，所谓的“提效”变成了“添堵”。

这背后的核心问题，其实就是标题里点出的：我们太容易陷入让AI“自由发挥”的“Plan模式”，却忘了给它套上一套严谨的“工程制度”。你可以把AI想象成一个天赋异禀但缺乏职业训练的新人程序员。你只告诉他“做个电商购物车”，他可能用任何语言、任何架构、任何命名规范给你实现出来，功能或许能跑通，但代码根本没法维护、协作和迭代。 “Plan模式”是AI的“思考能力”，而“工程制度”是我们赋予它的“行为准则” 。没有后者，前者的价值会大打折扣，甚至带来负向作用。

这套“工程制度”，远不止是写几条代码规范那么简单。它是一套从项目初始化、开发流程、质量卡点到团队协作的完整体系，目的是将AI不可预测的“创造力”引导到可控、可预期、可协作的标准化生产轨道上。无论是使用Claude Code这样的IDE智能插件，还是基于Spring AI构建企业级应用，或是用AI Agent自动化工作流，这个原则都适用。接下来，我就结合最近的实践，拆解一下如何为你的AI伙伴建立这套“工程制度”。

2. 制度基石：定义清晰的“工作上下文”与约束

在让AI动手写第一行代码之前，最重要的一步是确立清晰的“上下文边界”和“约束条件”。这相当于给AI划定工作范围和必须遵守的章程。

2.1 创建项目专属的“宪法文件”

不要依赖每次对话时零散的口头要求。你应该为每个项目创建一个核心的、机器可读的“宪法文件”（比如 AI_ENGINEERING_GUIDE.md ），并在每次与AI交互时，优先将这个文件作为上下文喂给它。这个文件应该包含：

1. 技术栈与版本锁死 ：明确指定语言（如Python 3.9+）、核心框架（如FastAPI 0.104+）、数据库（PostgreSQL 14）及其精确版本。禁止AI使用未明确指定的技术或过时的语法。
2. 代码风格与规范 ：直接链接或嵌入项目采用的规范，如PEP 8 for Python、Google Java Style Guide。更关键的是，要定义本项目特有的约定，例如：
   • 命名规范 ：API接口路径前缀必须是 /api/v1/ ；DTO类以 Request / Response 结尾；数据库模型类以 Model 结尾。
   • 目录结构 ：强制遵循 src/ , tests/ , config/ 的固定结构，并说明每个目录的职责。
   • 导入顺序 ：标准库 -> 第三方库 -> 本地模块，并分组用空行隔开。
3. 架构与设计模式约束 ：明确本项目采用的架构模式（如分层架构、清洁架构）。规定哪些层可以相互依赖。例如：“Service层只能调用Repository层和其他的Service，严禁直接操作数据库连接。”

实操心得 ：我发现，将这部分内容做成一个Markdown模板非常高效。每次新项目，复制一份，根据实际情况填空。让AI基于这个文件来“理解”项目环境，其输出的一致性会大幅提升。

2.2 设定AI的“角色”与“职责边界”

在每次任务开始时，通过System Prompt或对话开头，明确AI在本任务中的角色。这能有效引导其思考模式。

• 不好的提示 ：“写一个用户登录的API。”
• 好的提示 ：“你现在是本项目的后端高级工程师，严格遵守项目 AI_ENGINEERING_GUIDE.md 中的规范。你的任务是：基于现有的 UserModel 和 PasswordUtils 工具类，实现一个RESTful登录接口。要求：1. 使用JWT进行身份认证；2. 密码需加盐哈希处理；3. 返回标准化的 ApiResponse 格式；4. 必须包含输入参数验证和异常处理。请先给出实现思路，再生成代码。”

后一种方式，不仅交代了“做什么”，更明确了“以什么身份”、“在什么约束下”、“按什么标准”来做。AI的“Plan”会自然而然地在这个框架内进行。

3. 流程管控：将AI嵌入标准开发流水线

有了制度文件，下一步是让AI在正确的流程节点上工作，而不是随时随地、随心所欲地生成代码。

3.1 需求分析与任务拆解：AI作为“技术顾问”

在接到一个模糊需求时，不要直接让AI生成代码。先让它扮演“技术顾问”或“架构师”，进行需求澄清和任务拆解。

操作示例 ： 你（产品）：“我们需要一个内容推荐功能。” 你（给AI）：“作为技术顾问，请针对‘内容推荐功能’进行需求澄清和技术方案设计。请依次思考并输出：1. 需要哪些输入数据（用户ID、历史行为？）；2. 推荐逻辑可能有哪些（协同过滤、热门排序？）；3. 输出结果的形式是什么（文章ID列表？）；4. 这个功能涉及哪些模块（用户行为收集、推荐算法、内容获取API）？5. 请给出一个初步的、符合本项目架构的模块设计图（用文字描述）。“

通过这一步，AI帮你把模糊想法结构化，形成清晰的技术任务列表（Task List）。这个Task List将成为后续编码的精确输入，避免了AI在“Plan”阶段因理解偏差而跑偏。

3.2 代码生成与审查：AI作为“执行工程师”，人类作为“审查者”

基于拆解后的具体任务，再让AI进入编码模式。这里的关键是 “一次只做一件事” 和 “生成即审查” 。

1. 针对性生成 ：不要给一个“实现推荐系统”的巨无霸指令。而是：“请实现 RecommendationService 类中的 get_collaborative_filtering_recommendations(user_id: int) -> List[int] 方法。假设我们已经有了 UserBehaviorRepository 来获取用户-物品交互矩阵。”
2. 要求附带解释 ：在生成代码时，强制要求AI为关键逻辑、复杂算法或非常规写法添加行内注释。这既是为了后续维护，也是为了让你能快速理解AI的“思考过程”，便于审查。
3. 建立人工审查卡点 ：AI生成的代码 必须 经过人工审查才能进入版本库。审查重点不是语法（AI通常做得很好），而是：
   • 业务逻辑正确性 ：生成的算法是否真的符合业务需求？
   • 安全性 ：有无SQL注入、XSS、敏感信息泄露风险？
   • 性能 ：是否存在N+1查询、未使用索引、循环内复杂计算等问题？
   • 是否符合项目规范 ：对照“宪法文件”逐项检查。

踩过的坑 ：早期我们曾允许AI直接将代码提交到特性分支，结果发现它偶尔会“优化”一些它认为不重要的参数校验或日志记录，导致线上小问题。现在我们的流程是：AI生成代码 -> 开发者本地审查、运行单元测试 -> 确认无误后，由开发者亲手提交。AI是副驾驶，方向盘必须一直在人手里。

3.3 测试与质量保障：AI作为“测试协作者”

AI不仅能写实现代码，更能高效生成测试代码，但这需要引导。

• 单元测试生成 ：在AI生成某个类或方法后，立即追加指令：“请为上面生成的 RecommendationService 类编写对应的单元测试，使用pytest框架。需要覆盖正常场景和至少两种异常场景（如用户不存在、行为数据为空）。”
• 测试数据生成 ：让AI帮你生成符合要求的Mock数据或测试夹具（Fixture），这比手动构造快得多。
• 静态检查 ：将生成的代码用项目的linter（如flake8, pylint）和formatter（如black）跑一遍，让AI根据反馈修正格式问题。这可以自动化集成到你的IDE或Git钩子中。

4. 工具链与环境集成：固化制度的最佳实践

制度不能只停留在文档里，要融入到工具链中，形成肌肉记忆。

4.1 利用IDE插件实现“实时合规检查”

以VSCode中的Claude Code插件为例，你可以通过配置，让它始终“感知”到你的工程制度。

1. 配置项目级提示词 ：在项目根目录的 .claude 或自定义配置文件中，设置全局的System Prompt，指向你的 AI_ENGINEERING_GUIDE.md 。这样，每次在项目内打开新的Claude Code会话，它都会自动加载这些约束。
2. 创建代码片段（Snippets）与模板 ：将项目中常见的、符合规范的代码模式（如标准的CRUD接口、统一响应封装、异常处理块）保存为IDE的代码片段。当你需要AI生成类似代码时，可以先插入片段框架，再让AI填充核心逻辑。这能极大保证代码结构的一致性。
3. 集成Linter和Formatter ：在IDE中配置，让AI生成的代码在保存时自动格式化。你甚至可以写一个简单的脚本，在AI输出代码后自动调用 black --check 和 flake8 ，如果不通过，则要求AI重新生成。

4.2 版本控制策略：管理AI的“创作过程”

AI的迭代过程也需要被管理，避免混乱。

1. 清晰的Commit信息规范 ：要求AI（或使用AI的开发者）在提交代码时，必须遵循 Conventional Commits 等规范。例如： feat(recommendation): add collaborative filtering algorithm 。这能让历史记录清晰可读，便于回溯。
2. 分支策略 ：为AI辅助开发设立明确的分支策略。例如，所有由AI首先生成的代码，先进入 feature/ai-* 分支，经过人工审查、测试和必要的重构后，再合并到主开发分支。这隔离了AI代码的不稳定性。
3. Code Review流程 ：在Pull Request的描述中，必须明确标注哪些部分是由AI生成的，并简要说明生成这些代码的提示词和上下文。这有助于审查者聚焦重点。

5. 团队协作制度：统一人机协作的“语言”

当团队多人同时使用AI辅助开发时，统一的标准就更为关键，否则会陷入“方言”混战的局面。

5.1 建立团队的“提示词知识库”

不要每个人各写各的提示词。团队应该共建一个共享的提示词库，沉淀最佳实践。

• 分类管理 ：可以按用途分类，如“需求澄清模板”、“API生成模板”、“数据库模型生成模板”、“单元测试生成模板”。
• 记录效果 ：每个提示词模板下，可以附上1-2个成功的输入输出示例，以及注意事项。例如：“生成Controller层代码时，此模板最有效，但需注意提前在上下文中提供相关的Service接口定义。”
• 定期复盘优化 ：在团队周会上，可以拿出一些AI生成的“典型问题代码”或“优秀代码”，一起分析提示词哪里可以优化，共同迭代团队的“AI使用手册”。

5.2 定义AI产出的“所有权”与“质量标准”

必须明确： AI生成的代码，其质量责任最终在于使用它的开发者 。不能把AI当“甩锅”对象。 团队需要达成共识的质量红线，例如：

• AI生成的代码，在合并前必须通过所有现有的自动化测试。
• 关键业务逻辑、安全相关代码，无论AI生成得多好，都必须由资深工程师进行二次深度审查。
• 禁止将AI用于生成涉及法律合规、核心知识产权算法的代码。

6. 避坑指南：那些我们曾踩过的“雷”

在实际推行这套“工程制度”的过程中，我们遇到了不少挑战，也总结了一些教训。

1. 制度过于僵化，扼杀创造性 ：初期我们把规范定得太死，导致AI生成的代码千篇一律，在一些需要巧妙设计的场景下反而显得笨拙。 解决方案 ：区分“强制规范”（如安全、架构分层）和“推荐规范”（如某些命名细节）。对于非核心约束，给予AI一定的灵活度，并在审查环节把关。
2. 上下文管理失效 ：当对话轮次变多，AI可能会“忘记”之前设定的制度，或者将不同任务的上下文混淆。 解决方案 ：重要的制度文件，在关键对话节点（如开始一个新功能模块时）需要重新发送或提醒。对于Claude Code这类有上下文长度限制的工具，要有意识地进行“会话管理”，一个会话专注于一个独立任务。
3. 对AI的“幻觉”放松警惕 ：AI可能会引用一个不存在的库版本，或者编造一个API的用法。 解决方案 ：对于AI提供的任何第三方库、API的引用，必须要求它给出官方文档的链接或确切的版本号，并在合并前进行人工验证。这是一个绝对不能省略的步骤。
4. 过度依赖，技能退化 ：团队过度依赖AI生成基础代码，导致年轻开发者对框架底层、设计模式的理解反而变弱。 解决方案 ：建立“学习型任务”机制。对于核心模块或新技术，鼓励开发者先手动实现一遍，再用AI的实现进行对比和学习，将AI作为“参考答案”而非“标准答案”。

为AI建立“工程制度”，本质上是一次人机协作关系的升级。它要求我们从“魔法使用者”的心态，转变为“工程管理者”的心态。这个过程初期会有一些磨合成本，需要编写规范、调整流程，但一旦这套制度运转起来，你会发现AI从一个时不时“闯祸”的聪明孩子，变成了一个高效、可靠、可预测的资深助手。它不再天马行空地“Plan”，而是在你设定的轨道上，稳定地输出高质量、可维护的工程成果。这才是AI编程辅助工具，从玩具变为生产利器的关键一步。