跳到主要内容

AI 时代下的开发工作方式：原则、工具与团队规范(Odoo篇)

本文面向已经在团队开发中使用 Cursor、Claude 和 skills 的开发人员。与实操 SOP 不同，本文重点说明团队为什么要规范 AI 使用方式、不同工具分别适合解决什么问题，以及开发人员在 AI 协作中应该保留哪些判断责任。

AI 的价值不只是“更快写代码”，而是帮助团队更快理解问题、更稳定地产出方案、更早发现风险，并把经验沉淀成可复用流程。

AI 时代开发方式的变化​

在 AI 参与开发之后，团队的工作方式会发生几个明显变化：

  • 从单人手写代码，变成开发人员与 AI 协作完成信息整理、方案生成和实现。
  • 从“直接动手写”，变成“先澄清、再设计、再实施、再验证”。
  • 从依赖个人经验，变成把流程、检查点和经验沉淀为团队规范。

这些变化并不意味着开发人员的责任变少。相反，AI 提高了产出速度，也要求团队更清楚地定义上下文、边界、验证方式和交付标准。

团队使用 AI 的核心原则​

团队使用 AI 时，应先统一几条基本原则：

  • 开发人员负责最终判断。
  • 源码和业务事实优先于 AI 回答。
  • 任务越复杂，越需要先设计和计划。
  • AI 输出必须经过场景化检查。
  • skills 用来固化流程，不是替代思考。

这些原则的重点是把 AI 放在“协作工具”的位置上。AI 可以帮助整理信息、提出方案、生成代码和发现风险，但它不能替代开发人员对业务目标、技术约束和交付质量的判断。

Cursor / Claude / skills / MCP 的角色分工​

在团队工作流中，不同工具适合承担不同角色：

  • Cursor：开发环境入口，适合结合代码上下文进行阅读、编辑和验证。
  • Claude：推理、规划、解释、生成和评审的协作对象。
  • skills：把稳定流程固化为可重复调用的工作方式。
  • MCP：让 AI 连接外部工具、浏览器、文档、平台或数据源。

可以把 Cursor 理解为日常开发现场，把 Claude 理解为协作推理对象，把 skills 理解为团队流程模板，把 MCP 理解为连接外部系统的工具接口。团队规范的目标不是让所有任务都使用所有工具，而是让开发人员能根据任务类型选择合适组合。

Skills 分类与使用边界​

skills 的价值在于复用稳定流程。团队可以按使用场景把 skills 分为几类：

  • 流程类 skills：用于任务拆解、计划执行、验证收尾等稳定流程。
  • 评审类 skills：用于代码评审、安全评审、风险检查和质量把关。
  • 文档类 skills：用于文档生成、文档翻译、结构整理和内容维护。
  • 场景增强类 ECC skills：用于特定技术栈、业务场景或工程活动的增强支持。
  • 原则类 Karpathy guidelines：用于提醒开发人员保持清晰、简单、可验证的工程判断。

ECC skills 数量较多，适合按场景选择，而不是一次性全部暴露给团队。对于第一批文章，只建议在每类开发场景中呈现最实用的三个左右，帮助开发人员快速建立使用习惯。等团队形成稳定工作方式后，再逐步补充更多细分 skills。

使用 skills 时也要注意边界：skill 可以定义流程、检查点和输出格式，但不能保证输入上下文完整，也不能自动判断业务取舍是否正确。开发人员仍然需要负责确认目标、边界、事实来源和验证结果。

五类开发场景的推荐使用方式​

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

AI 可以帮助开发人员把模糊需求整理成目标、范围、约束、风险和实施步骤，尤其适合在需求还不够清晰时辅助提问和拆解。常用工具包括 Claude 的规划与解释能力、Cursor 中的代码上下文，以及流程类 skills 中的任务拆解、计划编写或头脑风暴流程。

开发人员需要手动确认业务目标是否真实、范围是否可交付、关键规则是否遗漏、方案取舍是否符合团队约束。对于影响较大的设计，还应让相关模块负责人或业务负责人参与确认。

代码阅读 / 熟悉模块​

AI 可以帮助快速梳理模块结构、调用链、入口文件、关键模型和主要流程，降低阅读陌生代码的启动成本。Cursor 适合结合仓库上下文阅读代码，Claude 适合解释流程和归纳关系，代码阅读类或文档类 skills 可以帮助形成结构化说明。

开发人员必须回到源码核对事实，尤其是入口、依赖、分支逻辑、权限判断、数据写入和异常处理。AI 对代码的解释只能作为阅读辅助，不能替代对实际源码和运行行为的确认。

功能开发​

AI 可以根据已确认的设计生成实现方案、编辑代码、补充测试思路并协助验证错误。Cursor 是功能开发的主要入口，Claude 适合解释实现取舍和处理复杂逻辑，流程类 skills 可以约束“先计划、再实现、再验证”的节奏。

开发人员需要重点检查 diff、业务逻辑、边界条件、测试覆盖和实际验证结果。对于涉及数据库、权限、财务、库存、外部接口或用户数据的改动，应提高检查强度，避免只看 AI 的总结就判断完成。

代码评审 / 安全评审​

AI 可以帮助发现潜在回归、遗漏测试、异常路径、安全风险和可维护性问题。评审类 skills 适合把检查维度固定下来，安全评审相关 skills 适合关注输入校验、权限控制、敏感信息、注入风险和外部调用风险。

开发人员需要判断风险是否真实成立，避免把 AI 的所有提示都当作必须修改的问题。评审结论应回到具体代码、业务场景和可复现路径，必要时补充测试或验证记录。

文档编写 / 文档翻译​

AI 可以帮助整理文章结构、生成初稿、统一术语、翻译说明文字并检查格式一致性。文档类 skills 适合固化文档结构、翻译要求、代码块保护规则和交付检查清单，Cursor 适合直接编辑仓库中的 Markdown 文件。

开发人员需要手动检查术语、代码块、路径、API 名称、标题层级、链接和格式。对于翻译文档，还要确认技术含义没有被改写，示例代码没有被翻译破坏，产品名和模块名保持一致。

AI 输出的人工检查原则​

人工检查按场景区分，不做一刀切。不同任务的风险来源不同，检查重点也应不同：

  • 需求和设计检查目标、范围、业务规则和取舍。
  • 代码阅读检查事实来源和调用链。
  • 功能开发检查 diff、业务逻辑、测试和验证结果。
  • 评审检查风险是否真实成立。
  • 文档和翻译检查术语、代码块、路径、API 名称和格式。

团队可以把这些检查点写入工作流、PR 模板或 skills 输出要求中。这样既能保留 AI 协作的效率，也能避免因为检查方式过于随意而引入质量风险。

团队协作规范​

为了让 AI 协作在团队中稳定落地，建议建立以下规范：

  • 在请求 AI 处理任务前，先说明目标、范围、约束和期望输出。
  • 对复杂任务先要求 AI 生成计划，再确认是否实施。
  • 对代码改动必须查看 diff，并按场景运行必要验证。
  • 对影响业务规则、权限、数据或外部接口的改动，应提高人工检查级别。
  • 对稳定有效的流程，逐步沉淀为 skills、文档模板或团队清单。
  • 对 AI 生成的结论，保留可追溯来源，例如源码位置、验证命令、测试结果或业务确认记录。

这些规范的目的不是增加流程负担，而是让团队在使用 AI 时有共同语言。共同语言越清晰，AI 协作越容易复用，也越容易评审和改进。

常见反模式​

团队在引入 AI 时，常见问题包括：

  • 把 AI 当成最终责任人。
  • 没有上下文就要求 AI 直接实现。
  • 不看 diff、不跑验证就认为完成。
  • 让 AI 顺手重构无关代码。
  • 把工具介绍当成流程规范。

这些反模式的共同问题，是把“工具能力”误认为“工程闭环”。真正可靠的 AI 工作流需要包含上下文、计划、实施、检查和验证，而不只是让 AI 输出一段代码或一份说明。

Skills 速查表​

下面列出的 skill 名称用于帮助团队建立第一批 approved skills 池。它们不是强制每次全部使用，而是按场景选择最贴近当前任务的三项左右，并配合人工判断完成闭环。

类别approved skills / 能力适用重点
流程类 skillsbrainstorming、writing-plans、executing-plans、verification-before-completion、karpathy-guidelines澄清问题、形成计划、执行计划、收尾验证、保持简单清晰的工程判断
评审类 skillsrequesting-code-review、receiving-code-review、ECC security-review、Cursor Bugbot、Cursor 安全评审相关能力发起评审、处理评审意见、发现代码和安全风险、确认风险是否真实成立
文档类 skillsdocument-odoo-component、odoo-source-to-doc、translate-odoo-docs、register-widget-doc、ECC documentation-lookup生成 Odoo 组件文档、从源码整理文档、翻译文档、登记 widget 文档、查询外部文档
场景增强类 ECC skillscodebase-onboarding、code-tour、architecture-decision-records、tdd-workflow、verification-loop、security-review、documentation-lookup熟悉代码库、组织代码导览、记录架构决策、建立测试驱动和验证闭环、补充安全和文档查询能力
场景推荐选择使用重点人工检查重点
需求理解 / 任务拆解 / 功能设计brainstorming、writing-plans、architecture-decision-records澄清目标、拆分任务、形成计划和关键取舍目标、范围、业务规则、取舍
代码阅读 / 熟悉模块codebase-onboarding、code-tour、odoo-source-to-doc梳理结构、调用链、关键事实和文档线索源码事实、入口路径、调用链
功能开发executing-plans、tdd-workflow、verification-loop按计划实现、控制范围、补充测试和验证反馈diff、业务逻辑、测试、验证结果
代码评审 / 安全评审requesting-code-review、receiving-code-review、ECC security-review、Cursor Bugbot / 安全评审能力发现风险、检查回归、补充验证建议风险真实性、影响范围、复现依据
文档编写 / 文档翻译document-odoo-component、translate-odoo-docs、register-widget-doc、ECC documentation-lookup生成结构、统一术语、保护格式、查询文档依据术语、代码块、路径、API 名称、Markdown 格式

速查表只用于帮助开发人员快速选择方向。实际使用时，应根据任务风险和上下文完整度调整检查深度，并避免把 skill 名称本身当成完整流程。