AI 辅助编码：基于预Prompting 和相关思想实现 AI 写代码的流程

引言

AI 辅助编码（AI Coding）是指利用大型语言模型（LLM）或其他 AI 工具来生成、优化或重构代码的过程。这种方法可以显著提升开发效率，但需要科学地引导 AI 以避免低质量输出。基于提供的概念和思想——包括“stack-driven coding”（一种被批判的代码组织方式，推荐转向实体风格或领域驱动设计 DDD）、DSL（领域特定语言，用于高效解决特定领域问题）、ADR（架构决策记录，用于记录设计决策）和预Prompting（预设提示来引导 AI 行为）——我们可以构建一个逻辑严谨的 AI 写代码流程。

这些思想的核心在于：通过预Prompting “先定规矩”，避免 stack-driven coding 的弊端（如低内聚、高耦合），融入 DSL 的专注性和 ADR 的决策记录，确保生成的代码结构清晰、可维护，并贴合业务领域。以下流程以步骤形式呈现，强调逻辑清晰、迭代优化，确保输出具体且实用。

核心思想整合

在 AI 编码中，这些概念不是孤立的，而是相互支撑的框架：

• 预Prompting：作为流程核心，提前设定 AI 的角色、思维链和输出格式，确保 AI 生成的代码符合预期（如避免 stack-driven 结构）。
• Stack-Driven Coding 的警示：AI 容易生成按技术层分组的代码（如所有控制器集中），这会分散业务逻辑。流程中需引导 AI 采用实体风格（按业务实体分组），提升内聚性。
• DSL：鼓励 AI 生成或使用 DSL 风格的代码（如嵌入式 DSL），使代码更专注、声明式，提高特定领域的效率（如配置或查询）。
• ADR：在流程末尾记录决策，保留 AI 生成代码的背景、备选方案和影响，便于团队协作和未来维护。

通过这些整合，AI 编码从“随意生成”转向“结构化协作”，类似于导演指导演员，确保代码高质量。

AI 写代码的流程

以下是基于上述思想的完整流程，分步骤展开。每个步骤包括具体操作、逻辑 rationale 和示例提示，确保语言流畅、内容具体。假设场景：使用 AI 生成一个酒店预订系统的后端代码（参考 stack-driven 示例）。

步骤 1: 预Prompting 设置（塑造 AI 行为）

• 逻辑 rationale：预Prompting 是起点，通过系统提示或用户提示开头，定义 AI 的角色、规则和输出约束。这避免 AI 默认生成 stack-driven 结构，转而强调 DDD 和 DSL 原则。同时，设定思维链（Chain-of-Thought），让 AI 先推理再输出，提高准确性。
• 具体操作：
  • 设定角色：AI 作为“资深软件架构师，擅长 DDD 和 DSL”。
  • 定义边界：禁止 stack-driven 组织，优先按业务实体分组；要求使用 DSL（如内部 DSL）简化复杂逻辑。
  • 约束格式：输出代码需包含注释、结构说明，并以 Markdown 呈现。
  • 思维指令：要求 AI “一步步思考”——先分析需求，再设计结构，最后生成代码。
• 示例提示：

  【角色设定】你是一位资深软件架构师，精通领域驱动设计（DDD）和领域特定语言（DSL），讨厌 stack-driven coding 的低内聚问题。
  【规则与边界】生成的代码必须按业务实体组织（如 /booking 模块包含控制器、服务和仓库），避免技术层分组。优先使用内部 DSL（如 Python 的 fluent API）简化逻辑。代码需简洁、可读，并避免上帝类。
  【思维指令】在输出前，一步步思考：1. 分析业务需求；2. 对比 stack-driven vs 实体风格；3. 考虑 DSL 应用；4. 设计模块结构。
  【输出格式】使用 Markdown，包括：1. 需求总结；2. 架构说明；3. 代码片段（Python 示例）；4. 潜在改进。
  【正式任务】生成一个酒店预订系统的核心模块代码，包括预订创建和查询功能。
  

步骤 2: 需求分析与问题定义（融入 DDD 思想）

• 逻辑 rationale：基于 stack-driven 的批判，这里强调按业务实体（如“预订”）分析需求，而不是技术栈。这确保 AI 聚焦领域概念，提高代码内聚性。同时，考虑 DSL 的专注性，识别是否需自定义 DSL（如一个声明式预订查询语言）。
• 具体操作：
  • 拆解需求：列出业务实体（e.g., Booking, Room）、操作（e.g., 创建预订、查询可用房间）和约束（e.g., 数据库交互）。
  • 对比风格：明确避免 stack-driven（e.g., 不要把所有服务放 /services/），采用实体风格（e.g., /booking/ 内含所有相关类）。
  • 如果适用，规划 DSL：如用 Python 的类方法链创建内部 DSL（e.g., Booking.query().filter_by_date()）。
• 示例输出片段（AI 响应中的思考链）：
  • 思考：需求涉及“预订”实体，包括创建（需检查房间可用）和查询。Stack-driven 会分散代码到 controllers/ 和 services/，增加变更难度；实体风格将一切聚合在 booking/，提升维护性。DSL 可用于查询逻辑，使其声明式。

步骤 3: 生成代码（核心执行阶段）

• 逻辑 rationale：AI 根据预Prompting 生成代码，确保结构清晰。融入 DSL 使代码高效（如声明式 API），避免 stack-driven 的高耦合。通过迭代，如果首次输出不理想，可追加提示优化。
• 具体操作：
  • 生成模块：按实体分组，包含控制器、服务、仓库。
  • 应用 DSL：使用嵌入式 DSL 简化复杂部分（e.g., 查询链）。
  • 验证：要求 AI 自检代码（e.g., “检查内聚性和潜在风险”）。
• 示例代码片段（Python Flask 示例，按实体风格）：

  # booking/module.py (实体风格：所有预订相关代码聚合在此)
  from flask import Blueprint, request, jsonify
  from datetime import datetime  # 假设数据库如 SQLAlchemy
  
  booking_bp = Blueprint('booking', __name__)
  
  class BookingRepository:
      def create(self, data):
          # DSL 风格：声明式插入
          return Booking.insert().values(**data).execute()  # 假设 ORM
  
      def query(self, filters):
          # 内部 DSL 示例：链式查询
          q = Booking.select()
          if 'date' in filters:
              q = q.where(Booking.date == filters['date'])
          return q.execute()
  
  class BookingService:
      def __init__(self, repo):
          self.repo = repo
  
      def create_booking(self, data):
          # 业务逻辑：检查可用性
          if not self.check_availability(data['room_id'], data['date']):
              raise ValueError("Room unavailable")
          return self.repo.create(data)
  
      def check_availability(self, room_id, date):
          # 简化逻辑
          return True  # 实际查询数据库
  
  @booking_bp.route('/create', methods=['POST'])
  def create():
      data = request.json
      service = BookingService(BookingRepository())
      result = service.create_booking(data)
      return jsonify(result)
  

步骤 4: 审查与迭代（确保质量）

• 逻辑 rationale：AI 输出可能有瑕疵，通过预Prompting 的自洽要求进行审查。参考 stack-driven 问题，检查是否分散逻辑；评估 DSL 使用是否提升效率。
• 具体操作：
  • 手动/AI 审查：运行代码，检查内聚性。
  • 迭代提示：如果不满意，追加“优化为更 DSL 化”。
  • 工具辅助：使用代码执行工具验证输出。

步骤 5: 记录 ADR（决策固化）

• 逻辑 rationale：ADR 确保流程不只是生成代码，还记录为什么选择实体风格而非 stack-driven，为什么用 DSL 等。这提升可维护性，符合软件工程最佳实践。
• 具体操作：
  • 模板：标题、状态、背景、方案、结果、影响。
• 示例 ADR：

  **标题**：采用实体风格组织酒店预订模块
  **状态**：已采纳
  **背景**：需求需高效生成预订代码，避免 stack-driven 的分散问题。
  **方案**：备选1 - Stack-driven（废弃，因低内聚）；备选2 - 实体 + DSL（采纳）。
  **结果**：代码内聚，提高维护效率。
  **影响**：开发更快，但需熟悉 DDD。
  

示例 Prompt 用于 AI 写代码

以下是一个基于先前讨论的预Prompting 思想的示例 Prompt，用于引导 AI 生成代码。这个 Prompt 整合了 stack-driven coding 的批判（避免技术层分组，转向实体风格）、DSL（使用领域特定语言风格简化代码）、ADR（在输出中记录决策），并通过预Prompting 设定角色、思维链和输出格式，确保生成过程逻辑清晰、可控。

示例场景

假设任务是生成一个简单的用户管理系统后端代码（使用 Python 和 Flask），包括用户注册和查询功能。Prompt 设计为引导 AI 避免 stack-driven 结构，转而按业务实体组织代码，并融入内部 DSL 风格的 API。

示例 Prompt

【角色设定】你是一位资深软件架构师，精通领域驱动设计（DDD）和领域特定语言（DSL）。你讨厌 stack-driven coding 的低内聚和高耦合问题，总是优先采用实体风格代码组织，以业务实体（如“用户”）为中心分组代码。

【规则与边界】
- 代码组织：必须按业务实体分组，例如在 /user 模块下包含所有用户相关的控制器、服务和仓库。严禁 stack-driven 风格（如把所有控制器放在 /controllers/）。
- DSL 应用：优先使用内部 DSL 风格，使代码更声明式和专注，例如使用方法链（如 User.query().filter_by_name()）简化查询逻辑。
- 代码质量：确保代码简洁、可读，避免上帝类。使用 Python 3 和 Flask 框架，假设使用 SQLAlchemy 作为 ORM。
- 决策记录：输出中必须包含一个 ADR（架构决策记录）部分，记录为什么选择实体风格而非 stack-driven，以及潜在影响。

【思维指令】
在生成最终输出前，一步步思考：
1. 分析需求：识别业务实体（如用户）和操作（如注册、查询）。
2. 对比风格：解释为什么 stack-driven 不合适（e.g., 业务逻辑分散，变更困难），实体风格的优势（e.g., 内聚性高）。
3. 规划 DSL：考虑在哪里应用 DSL 以提高效率（e.g., 查询部分）。
4. 设计结构：列出模块和类。
5. 自检：检查代码是否符合规则，无逻辑错误。

【输出格式】
使用 Markdown 格式，结构如下：
1. **需求总结**：简述任务。
2. **架构说明**：解释设计选择，包括实体风格和 DSL 使用。
3. **代码片段**：完整 Python 代码，按实体分组呈现。
4. **ADR 记录**：使用表格或列表格式记录决策。
5. **潜在改进**：建议进一步优化。

【正式任务】
生成一个用户管理系统后端的核心模块代码，包括用户注册（需检查用户名唯一）和查询功能（支持按名称过滤）。数据库使用 SQLite。

使用说明

• 为什么有效：这个 Prompt 通过预Prompting “先定规矩”，引导 AI 的行为，确保输出符合 DDD 原则，避免常见问题。同时，思维指令促进 Chain-of-Thought，提高生成质量。
• 预期输出：AI 会先在内部思考，然后输出结构化的响应，包括代码和 ADR。
• 自定义建议：你可以根据具体语言（如 Java）或框架（如 Spring）调整 Prompt 中的细节。如果需要更多示例（如数学问题或前端代码），请提供更多上下文！

优势与注意事项

• 优势：流程逻辑清晰，融入预Prompting 使 AI 输出更精准；避免 stack-driven 弊端，提升代码质量；DSL 提高专注性；ADR 便于团队协作。
• 注意事项：预Prompting 需具体，避免模糊；始终验证 AI 代码（e.g., 安全漏洞）；适用于复杂任务，对于简单代码可简化步骤。

结论

通过这个基于预Prompting 的 AI 写代码流程，你可以将 AI 从“工具”转化为“协作伙伴”，生成符合 DDD、DSL 原则的高质量代码。实际应用中，可根据项目规模调整步骤。如果需要具体示例代码或工具集成（如 GitHub Copilot），我可以进一步扩展。