跳到主要内容

AI 时代下的开发工作流程：团队实操指南(Odoo篇)

本文面向已经在使用 Cursor、Claude 和 skills 的团队开发人员，目标是把 AI 辅助开发从个人习惯沉淀为团队可复用流程。

AI 可以帮助我们更快地理解需求、阅读代码、生成方案、实现功能、检查风险和编写文档，但最终判断仍然由开发人员负责。本文按常见开发任务拆分流程，说明每个场景应该准备什么、如何向 AI 提问、适合使用哪些 skills、以及人工必须检查什么。

使用原则​

  • AI 负责加速信息整理、方案生成和重复性工作，开发人员负责业务判断、技术取舍和最终验收。
  • 需求不清时先澄清，不直接进入编码。
  • 重要任务先形成设计或计划，再实施。
  • 每次改动都要阅读 diff，确认是否符合需求和现有风格。
  • 涉及权限、数据、接口、账号、文件、secret 的内容必须额外检查安全风险。

标准操作模板​

本文每个场景都按以下结构说明：

  • 适用场景：什么时候使用这套流程。
  • 输入材料：开始前需要准备的信息。
  • 推荐 AI 提问方式：可以复用的 prompt 方向。
  • 执行步骤：开发人员和 AI 如何分步配合。
  • 适合使用的 skills：优先推荐与该场景直接相关的 skills。
  • 人工检查点：开发人员必须亲自确认的内容。
  • 输出物：该流程完成后应留下什么结果。

需求理解 / 任务拆解 / 功能设计​

适用场景​

  • 新功能需求不够清晰，需要先确认范围和验收标准。
  • 任务涉及多个模块，需要拆分开发步骤。
  • 需要在多种方案之间做取舍。

输入材料​

  • 原始需求描述
  • 业务背景和目标用户
  • 已知限制、截止时间、相关模块
  • 已有设计、截图、接口说明或旧实现

推荐 AI 提问方式​

请先不要写代码。请帮我复述这个需求，指出不清楚的地方，并提出需要确认的问题。

需求背景：
[填写业务背景]

目标：
[填写希望达成的结果]

限制：
[填写技术、时间、兼容性或业务限制]

执行步骤​

  1. 让 AI 复述需求，检查是否理解一致。
  2. 让 AI 提出澄清问题，开发人员逐项确认。
  3. 对较复杂需求使用 brainstorming 形成设计。
  4. 设计确认后使用 writing-plans 生成实施计划。
  5. 对重要架构取舍记录原因，必要时使用 architecture-decision-records。

适合使用的 skills​

  • brainstorming：用于需求澄清、方案比较和设计确认。
  • writing-plans：用于把已确认的设计拆成实施计划。
  • karpathy-guidelines：用于控制范围、避免过度设计。
  • ECC architecture-decision-records：用于记录重要架构决策。

人工检查点​

  • 需求目标是否被正确理解。
  • 范围是否过大，是否需要拆分。
  • 权限、数据边界、业务规则是否明确。
  • 方案是否引入不必要的抽象。

输出物​

  • 需求澄清结果
  • 功能设计方案
  • 实施计划
  • 必要时的 ADR

代码阅读 / 熟悉模块​

适用场景​

  • 接手不熟悉的 Odoo 模块或历史功能。
  • 需要定位入口文件、模型、视图、控制器、定时任务或前端组件。
  • 修改前需要确认现有调用链、扩展点和业务边界。

输入材料​

  • 模块名称、功能名称或用户操作路径
  • 相关菜单、模型、字段、接口或错误现象
  • 已知入口文件、日志、截图或复现步骤
  • 需要验证的具体问题

推荐 AI 提问方式​

请先帮我阅读代码，不要修改文件。请从入口文件开始，找出这个功能的主要调用链，并说明每个关键文件的职责。

模块或功能：
[填写模块名或功能名]

我需要确认的问题：
[填写要理解的业务或技术问题]

请引用真实存在的文件、类和函数，并区分源码事实与推测。

执行步骤​

  1. 先让 AI 搜索入口文件，例如 __manifest__.py、模型目录、控制器、视图 XML、静态资源和测试文件。
  2. 根据入口文件追踪调用链，确认模型方法、按钮动作、菜单、路由、计算字段和前端组件之间的关系。
  3. 要求 AI 对关键结论给出源码依据，避免只根据文件名或经验推测。
  4. 对复杂模块使用 codebase-onboarding 形成模块概览。
  5. 需要向团队讲解时使用 code-tour 生成阅读路径。
  6. 需要把源码整理成文档时使用 odoo-source-to-doc。

适合使用的 skills​

  • codebase-onboarding：用于快速建立模块结构和主要职责的整体认识。
  • code-tour：用于生成按阅读顺序组织的代码导览。
  • odoo-source-to-doc：用于把 Odoo 源码行为整理为可维护文档。
  • karpathy-guidelines：用于保持理解聚焦，避免过度延伸到无关模块。

人工检查点​

  • AI 引用的文件、类、函数是否真实存在。
  • 调用链是否经过源码验证。
  • 是否混淆新旧架构、适配层和事实来源。
  • 是否遗漏关键边界条件。

输出物​

  • 模块入口和关键文件列表
  • 经源码验证的调用链说明
  • 关键业务规则和边界条件记录
  • 后续开发或文档任务的上下文材料

功能开发​

适用场景​

  • 已经确认需求和设计，需要开始实现功能。
  • 修改会影响业务逻辑、权限、数据结构、接口或文档站展示。
  • 需要让 AI 协助编码，但希望控制改动范围和风险。

输入材料​

  • 已确认的需求说明和验收标准
  • 实施计划或任务拆分
  • 相关源码文件、现有风格和测试入口
  • 构建、测试或文档预览命令

推荐 AI 提问方式​

请按现有实施计划执行。每一步先阅读相关代码风格，再做小范围修改。不要引入无关重构。

计划：
[粘贴已确认计划]

验收标准：
[填写必须满足的结果]

验证方式：
[填写构建、测试或预览方式]

执行步骤​

  1. 先确认计划，再进入编码；需求或设计未确认时不要直接实现。
  2. 修改前阅读相邻文件和现有实现风格，优先复用项目已有模式。
  3. 使用 executing-plans 按计划逐步推进，保持每次 diff 尽量小。
  4. 对高风险逻辑先补测试或设计验证用例，必要时使用 test-driven-development 或 ECC tdd-workflow。
  5. 每完成一个可检查步骤，运行对应构建、测试或文档预览。
  6. 完成前使用 verification-before-completion 或 ECC verification-loop 做收尾验证。
  7. 人工阅读最终 diff，确认实现只覆盖本次需求。

适合使用的 skills​

  • executing-plans：用于按已确认计划分步实施。
  • test-driven-development：用于高风险逻辑的测试先行开发。
  • verification-before-completion：用于完成前检查验证是否充分。
  • karpathy-guidelines：用于控制改动范围，避免过度抽象。
  • ECC tdd-workflow：用于按测试驱动流程组织实现。
  • ECC verification-loop：用于循环执行验证、修复和复查。

人工检查点​

  • 修改是否严格对应需求。
  • 是否引入无关重构或风格漂移。
  • 是否破坏现有业务规则。
  • 是否已验证构建、测试或文档站预览。

输出物​

  • 小范围、可审查的代码或文档 diff
  • 对应测试、构建或预览结果
  • 已知风险和未覆盖项说明
  • 可用于评审的变更摘要

代码评审 / 安全评审​

适用场景​

  • 功能开发完成，需要在合并前检查质量和风险。
  • 改动涉及权限、数据访问、接口、文件处理、账号、配置或 secret。
  • 收到评审意见，需要判断是否真实、是否需要修复。

输入材料​

  • 本次变更 diff
  • 需求、设计和验收标准
  • 测试结果、构建结果或预览截图
  • 需要重点关注的风险区域

推荐 AI 提问方式​

请以代码评审角度检查这次变更，优先指出可能导致错误行为、安全风险或回归的问题。请基于 diff 和需求判断，不要只给风格建议。

需求摘要：
[填写需求摘要]

重点关注：
[填写权限、数据、接口或兼容性风险]

执行步骤​

  1. 开发人员先自行阅读 diff，确认没有明显遗漏和无关改动。
  2. 使用 requesting-code-review 请求 AI 从评审角度给出第二意见。
  3. 涉及安全敏感内容时使用 ECC security-review，或 Cursor Bugbot / 安全评审相关能力进行专项检查。
  4. 对 AI 反馈逐条验证，区分真实问题、误报和可接受风险。
  5. 使用 receiving-code-review 组织修复步骤，修复后重新验证。
  6. 对需要后续处理的问题记录原因和责任人，避免评审意见丢失。

适合使用的 skills​

  • requesting-code-review：用于发起聚焦风险的 AI 代码评审。
  • receiving-code-review：用于处理评审反馈并安排修复。
  • ECC security-review：用于检查权限、注入、数据泄漏和 secret 风险。
  • Cursor Bugbot / 安全评审相关能力：用于对本地变更做额外自动化检查。

人工检查点​

  • AI 指出的风险是否真实存在。
  • 是否存在业务语义错误。
  • 是否存在权限、数据泄漏、注入或 secret 泄漏风险。
  • 是否需要补充测试或文档。

输出物​

  • 已审查的 diff
  • 评审问题列表和处理结果
  • 安全风险检查结论
  • 修复后的验证记录

文档编写 / 文档翻译​

适用场景​

  • 需要把 Odoo 模块、组件、功能或最佳实践整理成文档。
  • 需要把已有英文或中文文档翻译为另一种语言。
  • 文档需要遵循现有目录、模板和侧边栏组织方式。

输入材料​

  • 源码、现有文档、截图或业务说明
  • 目标读者，例如开发人员、实施顾问或最终用户
  • 目标语言、术语要求和文档路径
  • 现有模板、侧边栏文件和示例页面

推荐 AI 提问方式​

请先阅读相关源码和现有文档模板，再编写文档。请面向指定读者说明用途、配置、操作步骤和注意事项。

目标读者：
[填写读者类型]

文档路径：
[填写目标路径]

术语要求：
[填写需要保留英文原文的 Odoo 术语]

执行步骤​

  1. 编写前先阅读事实来源，区分源码行为、产品约定和推测内容。
  2. 明确目标读者，决定文档深度、示例粒度和操作步骤。
  3. 对齐现有文档模板，包括标题层级、列表、代码块、提示语和链接格式。
  4. 涉及 Odoo 专业术语时保留关键英文原文，例如 model、view、field、action、controller、wizard。
  5. 翻译时保护 Markdown 结构、代码块、路径、API 名称、参数名和命令。
  6. 需要从源码生成说明时使用 document-odoo-component 或 odoo-source-to-doc。
  7. 需要翻译时使用 translate-odoo-docs，并人工复核术语一致性。
  8. 文档需要出现在导航中时，使用 register-widget-doc 或按项目规则更新侧边栏。
  9. 需要外部库或框架最新用法时，使用 ECC documentation-lookup 查询官方资料。

适合使用的 skills​

  • document-odoo-component：用于编写 Odoo 组件或模块说明。
  • odoo-source-to-doc：用于根据源码生成准确文档。
  • translate-odoo-docs：用于翻译并保护 Odoo 文档结构。
  • register-widget-doc：用于在需要时登记组件或文档入口。
  • ECC documentation-lookup：用于查询外部库、框架和 API 的最新资料。

人工检查点​

  • 技术含义是否准确。
  • Odoo 专业术语是否保留英文原文。
  • Markdown 结构、代码块、路径和 API 名称是否未被破坏。
  • 多语言文档之间是否内容一致。

输出物​

  • 可直接发布或评审的 Markdown 文档
  • 已核对的术语和结构
  • 必要时的侧边栏或索引更新建议
  • 来源材料和未确认内容说明

Skills 速查表​

  • brainstorming：需求澄清、方案比较和设计确认。
  • writing-plans：把设计拆成可执行计划。
  • executing-plans：按计划分步实施并跟踪完成情况。
  • test-driven-development：为高风险逻辑建立测试先行流程。
  • verification-before-completion：完成前确认验证是否充分。
  • requesting-code-review：请求 AI 进行聚焦风险的代码评审。
  • receiving-code-review：处理评审意见并组织后续修复。
  • codebase-onboarding：快速理解代码库或模块结构。
  • code-tour：生成面向团队的代码阅读路径。
  • document-odoo-component：编写 Odoo 组件或模块文档。
  • odoo-source-to-doc：根据 Odoo 源码生成文档说明。
  • translate-odoo-docs：翻译 Odoo 文档并保护结构。
  • register-widget-doc：在需要时登记文档或组件入口。
  • karpathy-guidelines：控制范围、保持实现直接、减少过度设计。
  • ECC architecture-decision-records：记录重要架构决策。
  • ECC tdd-workflow：组织测试驱动开发流程。
  • ECC verification-loop：循环执行验证、修复和复查。
  • ECC security-review：检查安全敏感变更。
  • ECC documentation-lookup：查询外部库、框架或 API 的最新资料。

团队协作检查清单​

必须做​

  • 在需求不清时先澄清问题，再开始编码。
  • 重要任务先产出设计或实施计划。
  • 修改前阅读相关代码和现有文档风格。
  • 每次改动后阅读 diff，确认只覆盖本次需求。
  • 涉及权限、数据、接口、账号、文件或 secret 时进行安全复查。
  • 完成前执行可用的构建、测试或文档站预览。

建议做​

  • 把常用 prompt、计划模板和评审模板沉淀到团队文档。
  • 对复杂模块保留代码导览或源码说明。
  • 对重要架构取舍记录 ADR。
  • 让 AI 评审输出聚焦风险、回归和业务语义，而不是只看格式。
  • 对文档翻译建立术语表，保持多语言一致。

禁止做​

  • 不读 AI 输出直接合并。
  • 让 AI 大范围重构无关代码。
  • 把账号、密码、token、内部敏感信息直接写进 prompt 或文档。
  • 在没有验证的情况下宣称功能已完成。
  • 让 AI 修改不理解的业务规则。

常见误区​

  • 把 AI 当成最终决策者，而不是辅助整理信息和生成候选方案的工具。
  • 需求还没有澄清就直接要求 AI 写代码，导致返工和隐性范围扩大。
  • 只看 AI 的总结，不核对源码、diff、测试结果和业务规则。
  • 为了显得“架构完整”引入当前需求不需要的抽象。
  • 忽略权限、数据边界、secret 和内部敏感信息的检查。
  • 文档翻译时破坏 Markdown、代码块、路径、API 名称或 Odoo 术语。