AI代码生成工作流：Gemini驱动复杂编程任务自动化-开发者社区

1. 项目概述：当代码生成遇上工作流编排

最近在折腾AI辅助编程时，发现了一个挺有意思的项目：Theopsguide/gemini-code-flow。光看名字，你可能会觉得这又是一个简单的代码生成工具，无非是把需求描述扔给大模型，然后等着它吐出几行代码。但如果你真这么想，那就错过了它的精髓。这个项目的核心，在我看来，是“工作流”和“上下文管理”。它试图解决的，不是一个“点”的问题，而是一个“线”甚至“面”的问题——如何让AI在理解复杂、多步骤的编程任务时，能像一位经验丰富的开发者一样，有条不紊地推进，并且每一步都基于充分的项目上下文。

简单来说，gemini-code-flow是一个利用Google Gemini系列大模型（特别是Gemini Pro）来驱动、以工作流方式执行复杂代码生成与迭代任务的框架或工具集。它不满足于生成一个孤立的函数片段，而是旨在处理诸如“为我的Flask应用添加一个用户认证模块，包括数据库模型、路由、表单和前端页面”这类需要多文件协作、前后端联动的复合型需求。它的价值在于，通过结构化的流程设计，引导大模型进行更系统、更可靠的代码创作，减少因上下文丢失或指令模糊导致的“AI胡编乱造”。

适合谁来关注这个项目呢？首先肯定是日常开发中希望用AI提升效率的工程师，尤其是面对重复性脚手架代码、新功能模块开发或者代码重构时。其次，是那些在探索AI编程助手边界的技术爱好者或团队负责人，想了解如何将单次的Prompt互动升级为可管理、可复用的自动化流程。最后，对于DevOps或平台工程师，这个项目在如何将大模型能力“工程化”集成到开发流水线中，也提供了很好的思路借鉴。

2. 核心设计理念与架构拆解

2.1 从单次问答到流程编排的范式转变

传统的AI编程助手交互模式，无论是ChatGPT还是GitHub Copilot，本质上是“单轮或有限轮次”的对话。你描述需求，它生成代码；你指出错误，它进行修正。这种模式在处理简单、独立的问题时很高效，但一旦任务变得复杂，弊端就显现出来了：上下文窗口限制、状态难以维持、决策链路过长导致模型“迷失”。

gemini-code-flow的设计出发点，正是为了解决这些问题。它引入了一个核心概念：将编码任务分解为一系列有序的、可定义的步骤（Step），并构建一个执行引擎（Orchestrator）来驱动这些步骤。每个步骤都是一个独立的、目标明确的子任务，比如“分析项目结构”、“设计数据库Schema”、“实现核心业务逻辑”、“编写单元测试”。执行引擎负责：

为每个步骤准备精准的上下文（当前代码库状态、之前步骤的输出、项目规范等）。
调用Gemini模型执行该步骤。
解析模型的输出，更新项目状态，并决定下一步该执行哪个步骤。

这种设计带来了几个显著优势：

可控性增强：你可以像编写剧本一样，预先定义好整个代码生成的“剧情走向”，避免了模型自由发挥可能带来的架构混乱。
上下文精准投喂：每个步骤只获取完成任务所必需的最小上下文，既减轻了模型负担，也避免了无关信息干扰。
错误隔离与恢复：如果某个步骤（如生成某个函数）失败了，可以定位到具体步骤进行重试或人工干预，而不必推翻整个会话。
可复用性：针对特定类型任务（如“创建CRUD API”、“添加日志中间件”）的工作流可以被抽象为模板，在不同项目中重复使用。

2.2 核心组件与数据流转

基于公开信息和对类似项目的理解，我们可以推断gemini-code-flow可能包含以下核心组件，它们共同构成了一个完整的工作流执行系统：

工作流定义（Workflow Definition）：通常以YAML或JSON格式存在，用于描述一个完整任务。它定义了步骤序列、每个步骤的类型（如code_generation,code_refactoring,test_writing）、所需的输入参数、依赖的前置步骤，以及成功后的输出处理方式。这是整个系统的“蓝图”。
上下文管理器（Context Manager）：这是项目的“大脑”之一。它的职责是根据当前执行步骤，从多个来源收集、筛选、组装上下文信息。来源可能包括：
- 项目代码库：通过文件系统读取相关源代码文件。
- 步骤历史：之前步骤中模型生成的内容或决策。
- 外部知识：项目相关的文档、API说明书、编码规范等。
- 用户输入：工作流启动时提供的初始需求描述和参数。管理器需要智能地决定哪些文件是相关的（例如，通过抽象语法树AST分析导入关系），并将它们以清晰、结构化的格式（如提供文件路径和内容摘要）提供给模型。
提示词工程引擎（Prompt Engineering Engine）：单纯的上下文堆砌不足以让模型很好地工作。这个组件负责将步骤目标和组装好的上下文，构造成一个高效、明确的Prompt。它会应用一系列提示词技巧，比如：
- 角色设定：“你是一个资深的Python后端工程师，擅长编写简洁高效的Flask代码。”
- 任务分解：“首先，请基于以下User模型，设计一个Session模型。然后，编写登录和注销的路由函数。”
- 输出格式约束：“请将生成的代码用Markdown代码块包裹，并注明文件名。”
- 少样本示例（Few-Shot）：提供一两个类似任务的输入输出示例，引导模型遵循特定格式或逻辑。
模型客户端与执行器（Model Client & Executor）：负责与Google Gemini API进行通信。它接收构造好的Prompt，调用合适的Gemini模型（如gemini-1.5-pro），处理API响应（包括处理速率限制、错误重试），并将模型返回的文本或结构化数据传递给下一步。
输出解析器与代码写入器（Output Parser & Code Writer）：模型生成的通常是包含自然语言和代码块的混合文本。解析器需要从中精准提取出代码部分，识别其目标文件路径，并进行语法验证（可选）。随后，代码写入器以安全的方式（例如，先写入临时文件，或提供差异对比）将代码合并到实际的项目文件中。对于修改现有代码的步骤，它可能需要集成类似difflib的库来生成补丁。
状态机与流程控制器（State Machine & Flow Controller）：管理整个工作流的生命周期。它跟踪当前步骤、步骤状态（待执行、执行中、成功、失败）、维护一个共享的“工作内存”来存储步骤间传递的数据，并根据步骤执行结果和预定义规则（如条件分支、循环）决定下一步跳转到哪里。

注意：以上架构是基于常见模式和项目名称的合理推断。实际项目的具体实现可能有所不同，但核心思想——通过编排（Orchestration）来增强大模型在复杂任务中的可靠性和系统性——是确定无疑的。

2.3 为什么选择Gemini？

项目名称直接绑定了Gemini，这背后可能有几个考量：

上下文长度优势：Gemini 1.5 Pro等模型支持超长的上下文窗口（可达百万token），这对于需要摄入大量项目源代码作为上下文的工作流场景至关重要。长上下文意味着可以将更多相关文件一次性提供给模型，减少因分段输入导致的信息割裂。
原生多模态与代码理解：Gemini在设计上对代码有良好的理解能力，并且其多模态特性未来可能扩展为处理图表（如UML）、设计稿生成代码等更丰富的场景。
API生态与可控性：使用Gemini API可以更稳定、可控地集成到自动化流程中，相比依赖于Web界面的ChatGPT，更适合构建无人值守的CI/CD流水线集成。

3. 实战演练：构建一个用户认证模块工作流

让我们通过一个具体的场景，来模拟gemini-code-flow可能的工作方式。假设我们有一个简单的Flask项目骨架，现在需要添加完整的用户认证功能。

3.1 定义工作流YAML

首先，我们需要定义一个工作流。这个YAML文件描述了从零开始构建认证模块的完整步骤。

# workflow_auth.yaml name: "flask_user_authentication" description: "为现有Flask项目添加用户注册、登录、注销及会话管理功能" version: "1.0" parameters: project_path: "./my_flask_app" # 目标项目路径 db_type: "sqlite" # 数据库类型 use_bcrypt: true # 是否使用bcrypt加密密码 steps: - id: "analyze_project" name: "项目结构分析" type: "context_collection" action: "scan_and_summarize" outputs: ["project_structure_summary"] - id: "design_models" name: "设计数据模型" type: "code_generation" depends_on: ["analyze_project"] context: - "{{ project_structure_summary }}" - "file:{{ project_path }}/requirements.txt" prompt_template: | 你是一个Python Flask专家。现有项目摘要如下： {{ context[0] }} 项目依赖包含：{{ context[1] }} 请设计用于用户认证的SQLAlchemy模型。要求： 1. 用户模型(User)应包含id、username、email、password_hash字段。 2. 使用{{ db_type }}数据库。 3. {% if use_bcrypt %}使用`flask-bcrypt`进行密码哈希。{% else %}使用`werkzeug.security`。{% endif %} 4. 生成一个独立的`models/auth.py`文件。 请只输出代码。 outputs: ["auth_models_code"] - id: "implement_forms" name: "实现表单类" type: "code_generation" depends_on: ["design_models"] context: - "file:{{ project_path }}/app/__init__.py" - "{{ auth_models_code }}" prompt_template: | 基于以下User模型： {{ context[1] }} 以及项目主应用文件： {{ context[0] }} 请使用`flask-wtf`创建注册(RegisterForm)和登录(LoginForm)表单类。 表单应包含必要的字段验证（如邮箱格式、密码确认）。 生成文件`forms/auth_forms.py`。 outputs: ["auth_forms_code"] - id: "create_routes" name: "创建认证路由" type: "code_generation" depends_on: ["implement_forms", "design_models"] context: - "{{ auth_models_code }}" - "{{ auth_forms_code }}" - "file:{{ project_path }}/app/routes/main.py" # 参考现有路由风格 prompt_template: | 综合以下组件： 1. 数据模型：{{ context[0] }} 2. 表单类：{{ context[1] }} 3. 现有路由风格参考：{{ context[2] }} 请编写Flask路由，实现以下端点： - `/auth/register` (GET, POST) - `/auth/login` (GET, POST) - `/auth/logout` (POST) 需处理表单验证、用户创建、密码验证、会话管理(`flask-login`)和消息闪现(`flash`)。 生成文件`routes/auth.py`。 outputs: ["auth_routes_code"] - id: "update_app_init" name: "更新应用初始化" type: "code_modification" depends_on: ["create_routes", "design_models"] context: - "file:{{ project_path }}/app/__init__.py" - "{{ auth_models_code }}" prompt_template: | 现有应用初始化文件内容： {{ context[0] }} 需要在此文件中： 1. 导入并初始化`flask-login`的LoginManager。 2. 导入我们新建的auth模型（从`models.auth`导入`User`）。 3. 编写`user_loader`回调函数。 4. 注册认证蓝图（假设蓝图在`routes.auth`中创建，名为`auth_bp`）。 请输出完整的、修改后的`app/__init__.py`文件内容。 outputs: ["updated_init_code"] - id: "generate_templates" name: "生成HTML模板" type: "code_generation" depends_on: ["create_routes"] context: - "file:{{ project_path }}/app/templates/base.html" prompt_template: | 参考现有的基础模板结构： {{ context[0] }} 请创建两个Jinja2模板文件： 1. `templates/auth/register.html`: 包含注册表单。 2. `templates/auth/login.html`: 包含登录表单。 表单样式应与项目现有风格保持一致，使用Bootstrap类（如果项目用了的话）。 outputs: ["register_template_code", "login_template_code"] - id: "final_integration_check" name: "最终集成检查" type: "validation" depends_on: ["update_app_init", "generate_templates"] action: "syntax_check_and_import_verify" # 这一步可能不是调用模型，而是执行静态检查或简单脚本

这个YAML定义了一个线性为主、略有依赖关系的工作流。每个step都有明确的输入（depends_on,context）和输出（outputs），prompt_template中使用了变量插值（{{ ... }}）来动态构建精准的Prompt。

3.2 执行引擎如何运作

当我们运行gemini-code-flow run workflow_auth.yaml时，执行引擎会：

解析与初始化：加载YAML文件，解析步骤和参数。初始化上下文管理器，扫描./my_flask_app目录，生成project_structure_summary。
执行analyze_project：这是一个准备步骤，可能只是收集信息，不调用模型。输出存入共享状态。
执行design_models：引擎发现它依赖analyze_project已完成。于是，它从状态中取出project_structure_summary，并读取requirements.txt文件内容。接着，将这两个上下文片段和prompt_template结合，并替换变量（{{ db_type }},{{ use_bcrypt }}），生成最终发送给Gemini的Prompt。
- Prompt示例：“你是一个Python Flask专家。现有项目摘要如下：（此处是项目结构摘要）...项目依赖包含：Flask==2.3.3, SQLAlchemy==2.0.19... 请设计用于用户认证的SQLAlchemy模型。要求：1. 用户模型(User)... 2. 使用sqlite数据库。3. 使用flask-bcrypt进行密码哈希...”
获取与解析响应：Gemini返回生成的代码。输出解析器识别出这是models/auth.py的内容，将其存入状态变量auth_models_code。
迭代后续步骤：引擎按照依赖关系，依次执行implement_forms,create_routes等步骤。每一步的Prompt都会包含前序步骤的关键产出（如模型代码、表单代码），确保模型是在一个不断丰富的上下文基础上进行创作。
代码写入：在每个代码生成步骤成功后，代码写入器会安全地将内容写入到项目的指定路径。对于update_app_init这种修改步骤，可能会采用差异合并的方式。
完成与报告：所有步骤执行完毕后，引擎生成一份报告，列出每个步骤的状态、生成的文件列表以及可能遇到的警告。

3.3 实操中的关键配置与技巧

要让这样的工作流稳定运行，有几个细节需要特别注意：

上下文裁剪与摘要：直接塞入整个文件的内容很快会耗尽token。上下文管理器必须具备摘要能力。例如，在提供参考路由文件时，不是给全部代码，而是提取路由装饰器和函数签名，或者用自然语言描述其风格（“路由使用@bp.route装饰器，视图函数返回render_template”）。
错误处理与重试机制：模型生成可能不符合预期（如语法错误、未遵循指令）。工作流需要包含验证步骤（如final_integration_check），或为每个步骤设置“重试策略”。例如，当解析器检测到生成的代码有语法错误时，可以自动构造一个修复Prompt（“你生成的代码存在以下语法错误：[错误信息]，请修正”）并重试该步骤，最多3次。
人工审核点（Gates）：对于关键步骤，如生成核心数据模型或修改应用入口文件，可以配置为“手动批准”模式。引擎会在该步骤暂停，将生成的代码差异展示给用户，等待确认后再继续执行或写入文件。这平衡了自动化与可控性。
提示词模板的模块化：像prompt_template这样的部分不应该硬编码在YAML里。最佳实践是建立一个“提示词模板库”，YAML中只引用模板ID和参数。这样便于复用和维护，例如，一个“创建CRUD路由”的模板可以用在多个不同模型的工作流中。

4. 深入核心：上下文管理与提示词工程实战

4.1 智能上下文收集策略

gemini-code-flow的威力一半来自于其上下文管理。一个笨拙的系统会把整个项目目录树都扔给模型，而一个智能的系统懂得“按需索取”。以下是几种关键的策略：

基于依赖关系的文件发现：当任务是为services/user_service.py生成一个方法时，系统应自动分析该文件的导入语句，找到它依赖的模型（models/user.py）、工具类（utils/security.py）等，并将这些相关文件作为高优先级上下文。
最近修改文件优先：在迭代开发中，最近被修改过的文件很可能与当前任务高度相关。上下文管理器可以集成Git，获取git diff信息，将变更涉及的文件纳入上下文。
抽象语法树（AST）分析：通过解析Python代码的AST，可以更精确地理解代码结构。例如，当需要为一个类添加新方法时，AST可以帮你提取出该类的现有方法签名和属性，确保生成的新方法风格一致。
向量检索（高级场景）：对于大型代码库，可以事先为所有代码片段生成嵌入向量（Embedding）。当新任务到来时，将任务描述转换为向量，并从向量数据库中检索出语义最相关的代码片段作为上下文。这实现了“跨文件”的语义关联，即使两个文件没有直接的导入关系。

实操心得：在实现上下文管理器时，切忌“贪多嚼不烂”。一个实用的原则是分层提供上下文：首先提供任务直接相关的1-3个核心文件（完整内容或关键部分），然后提供几个相关文件的摘要（如函数/类列表），最后再以自然语言描述项目整体结构或约定。这样既保证了核心信息的完整，又给了模型一个宏观视野。

4.2 构建高成功率提示词的细节

工作流中的每个prompt_template都是与模型沟通的“微指令”。除了基本的角色和任务描述，还有一些提升生成质量的技巧：

指定“思考过程”：对于复杂逻辑，鼓励模型先“思考”再“输出”。例如，在提示词开头加上：“请按以下步骤思考：1. 分析现有模型的关系；2. 设计API端点参数；3. 编写伪代码；4. 输出最终代码。” 这能显著提高代码的逻辑正确性。
提供负面示例：告诉模型“不要做什么”有时和告诉它“要做什么”同样重要。例如：“避免在路由函数中进行复杂的业务逻辑，请将业务逻辑封装到Service层中。”
固化代码风格：在Prompt中明确代码风格要求，如“使用Google Python风格指南”、“所有导入语句分组并按字母顺序排序”、“使用snake_case命名变量和函数”。甚至可以提供一小段项目中的示例代码作为风格参考。
处理模糊性：当任务描述存在模糊时，提示词应引导模型做出合理假设并明确声明。例如：“如果需要额外的配置，请假设配置项已存在于项目的config.py文件中，并使用current_app.config['CONFIG_KEY']的方式读取。请在代码注释中说明这一假设。”

一个优化后的Prompt示例（用于create_routes步骤）：

你是一个严谨的Flask后端工程师。你的任务是基于提供的组件，编写生产可用的认证路由。 **背景信息**： 1. **数据模型**：[此处粘贴精简后的User模型代码，只保留类定义和关键字段] 2. **表单类**：[此处粘贴RegisterForm和LoginForm的类定义] 3. **项目风格**：现有路由文件显示，它们使用蓝图(`bp`)，视图函数返回`render_template`或`jsonify`，错误处理使用`abort(400)`。 **你的目标**：创建 `routes/auth.py` 文件。 **具体要求**： - 导入必要的模块：`flask, flask_login, your_project.models.auth, your_project.forms.auth_forms`。 - 创建一个名为 `auth_bp` 的蓝图。 - 实现 `/register` (GET/POST): POST请求中，验证表单、创建用户、哈希密码、存入数据库、登录用户、重定向到首页。 - 实现 `/login` (GET/POST): POST请求中，验证表单、验证用户凭证、登录用户、重定向。 - 实现 `/logout` (POST): 登出用户。 - **重要**：必须进行异常处理（如数据库唯一约束冲突、密码验证失败），并使用 `flash()` 向用户反馈友好信息。 - **代码风格**：函数使用`snake_case`，添加清晰的docstring，关键操作处添加注释。 **输出格式**：请只输出完整的`routes/auth.py`的Python代码内容。

5. 进阶应用：集成与扩展场景

5.1 与现有开发流水线集成

gemini-code-flow的价值不仅在于交互式使用，更在于它能嵌入到自动化流程中。

CI/CD中的自动化代码生成：在拉取请求（PR）中，当检测到特定标签（如/generate-auth）或修改了特定配置文件时，可以触发一个GitHub Action或GitLab CI Job。该Job会运行gemini-code-flow，根据预设的工作流生成代码，并自动创建提交或更新现有PR。这可以用于标准化组件的初始化。
项目脚手架生成器：将gemini-code-flow作为cookiecutter或yeoman的增强后端。用户通过CLI选择功能（“需要用户认证”、“需要Redis缓存”、“需要管理员面板”），CLI工具组合对应的工作流并执行，生成一个高度定制化、可直接运行的项目骨架。
遗留代码库的文档与测试生成：设计一个“分析-生成”工作流。第一步，扫描整个遗留代码库，生成架构和模块摘要。后续步骤，依次为每个核心模块生成更新后的文档字符串（Docstring）、单元测试用例甚至集成测试脚本。这能极大加速老旧项目的现代化进程。

5.2 自定义步骤类型与插件化

基础的工作流可能只包含code_generation和code_modification。但我们可以扩展步骤类型，使其能力更强大：

shell_command步骤：在执行完代码生成后，自动运行python -m pytest tests/来验证生成代码的测试通过率，或者运行black .来格式化代码。将AI生成与本地工具链无缝衔接。
human_review步骤：这是一个特殊的“阻塞”步骤。它会在流程中暂停，将前面步骤的生成结果（如代码差异、架构图）通过Slack、钉钉或邮件发送给指定负责人，并等待其批准或反馈。反馈内容可以作为后续步骤的输入。
api_call步骤：调用外部API来获取信息。例如，在生成使用第三方支付网关的代码前，先调用该网关的API文档站点（或内部知识库）来获取最新的SDK使用示例和API密钥配置方式，并将这些信息作为上下文提供给代码生成步骤。

实现插件化：可以设计一个插件接口，允许开发者编写自定义的步骤处理器（StepHandler）。这样，社区可以贡献各种各样的处理器，比如DiagramGenerationHandler（根据代码生成UML图）、DependencyUpdateHandler（分析生成的代码并更新requirements.txt）等。

6. 常见问题、挑战与应对策略

在实际使用或构建类似gemini-code-flow的系统时，你会遇到一些典型的挑战。

6.1 模型生成的不确定性与质量波动

这是最大的挑战。同样的Prompt，模型可能产生语法正确但逻辑有误的代码，或者风格不符合项目要求。

应对策略：

设置严格的输出验证：在每个代码生成步骤后，立即进行静态检查。使用py_compile（Python）或eslint（JavaScript）进行语法验证；使用ast.parse检查基本的代码结构；甚至可以运行简单的逻辑检查脚本。
实施多轮迭代与评分：对于关键步骤，可以采用“生成-评估-重生成”的循环。例如，让模型生成3个版本的解决方案，然后通过另一个Prompt（或一个简单的规则系统）对这三个版本在“正确性”、“简洁性”、“符合规范”等方面进行评分，选择最高分的版本，或者要求模型基于最佳版本进行融合优化。
提供更丰富的“种子”上下文：质量波动常因上下文不足。确保提供的参考代码（如现有的路由文件）是项目中最具代表性、质量最高的范例。劣质的范例会导致模型学到坏习惯。

6.2 复杂任务的工作流设计复杂度

设计一个能正确处理所有边界的YAML工作流本身就很复杂。步骤间的依赖可能形成复杂的图状结构，错误处理分支会让流程定义变得冗长。

应对策略：

从简单线性流开始：不要一开始就设计复杂流程。先实现一个最简单的、线性的三步骤工作流（分析-生成-整合），验证其可行性。
使用高阶工作流：将常用模式抽象为“子工作流”。例如，一个“创建完整CRUD接口”可以作为一个子工作流，它内部包含模型、表单、路由、测试等步骤。主工作流只需调用这个子工作流并传入参数（如模型名、字段）。这降低了主流程的复杂度。
可视化设计器：开发一个图形化的工作流设计工具，通过拖拽节点、连线来定义步骤和依赖，然后导出为YAML。这能极大降低使用门槛。

6.3 安全与成本考量

代码安全：自动生成的代码可能包含安全漏洞（如SQL注入、密码明文存储）。必须在工作流中内置安全审查步骤，例如使用bandit等SAST（静态应用安全测试）工具对生成代码进行扫描，或将安全模式作为硬性约束写入Prompt（“所有数据库查询必须使用参数化查询”）。
API成本与延迟：Gemini API调用按token收费，长上下文和复杂工作流会导致token消耗剧增。需要优化上下文策略，对输出token设置上限，并对非关键步骤使用更小、更便宜的模型。对于内部系统，可以考虑缓存常见任务的生成结果。
依赖管理：生成的代码可能会引入新的Python包依赖。工作流应包含一个步骤，自动检测生成代码中的import语句，并与requirements.txt或pyproject.toml比对，提示用户或自动添加缺失的依赖。

6.4 调试与问题排查

当工作流执行失败或结果不理想时，如何调试？

详尽的执行日志：系统必须记录每个步骤的输入（完整的Prompt）、输出（模型的原始响应）、以及中间状态。这些日志是排查问题的第一手资料。
Prompt与响应的可视化对比：提供一个界面，可以并排查看发送给模型的Prompt和模型返回的响应，直观地分析指令是否被正确理解。
“回放”与“干预”模式：允许用户从任意一个失败的步骤重新开始执行，并且可以在重试前手动修改该步骤的输入（上下文或Prompt），或者直接提供期望的输出结果来跳过该步骤。这种交互式调试能力至关重要。

我个人在探索这类系统的体会是，它们代表了AI辅助编程从“副驾驶”走向“自动驾驶”的早期阶段。最大的收获不是完全替代人工，而是将开发者从重复、模式化的代码编写中解放出来，让我们能更专注于架构设计、业务逻辑和创造性解决问题。同时，它也迫使我们去更严谨地定义开发规范和架构模式，因为只有清晰、一致的规则，才能被有效地编码到工作流和提示词中，教会AI如何为我们工作。