Meta 与 Hugging Face 推出 OpenEnv：共享的智能体环境中心！

本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！

• 🚀 魔都架构师 | 全网30W技术追随者
• 🔧 大厂分布式系统/数据中台实战专家
• 🏆 主导交易系统百万级流量调优 & 车联网平台架构
• 🧠 AIGC应用开发先行者 | 区块链落地实践者
• 🌍 以技术驱动创新，我们的征途是改变世界！
• 👉 实战干货：编程严选网

关键要点

• 为AI编程过程设定结构化目标：运用“计划-执行-检查-行动”（PDCA）原则，为每次AI编码会话设定清晰且可观察的成功标准，并根据结果及时调整方向。
• 在任务层面进行结构化规划：让AI代理分析代码库，将大型功能拆解为小型、可测试的单元，通过短周期迭代完成，避免范围失控。
• 运用红-绿单元测试循环：让AI先编写会失败的测试，再编写使测试通过的生产代码，形成结构化反馈循环，减少回归和意外问题。
• 设置验证检查点：在进入下一轮之前，让AI回顾成果与最初计划的差距，进行“完成度分析”。
• 实施每日微回顾：每次编码结束后，用5-10分钟与AI一起分析效果，改进提示语和互动方式。

AI代码生成工具能加快开发速度，但常常引发质量下降、集成困难和交付延迟等问题。本文介绍了我在过去六个月中不断改进的“PDCA框架”，它帮助我在充分利用AI能力的同时保持代码质量。通过制定合作约定、结构化提示词和持续回顾，我在与AI协作时始终对提交的代码质量负最终责任，并引导AI生成可测试、可维护的软件。

AI代码生成未能充分发挥潜力

AI代码生成的快速普及提高了产出，但尚未稳定地带来交付和成果质量的提升。Google《DORA DevOps 2024报告》指出，AI采用率每提升25%，交付稳定性反而下降7.2%。这可能是因为输出规模超过了组织对结果进行定义、审查、测试、部署和维护的能力。

更令人担忧的是质量问题。GitClear 2024年对2.11亿行代码的分析显示，重复代码块数量增加了10倍，首次超过“移动代码”比例。重复代码不仅增加维护负担，还存在约17%的缺陷率（Wagner等，2017），其中约18.42%的缺陷会被复制到其他代码片段中（Mondal等，2019）。

为什么需要结构化的PDCA循环？

当前AI代码生成之所以未能带来生产力与质量的双重提升，原因在于工具和使用方式都还不够成熟。开发者需要可复用的方法，将自身经验融入AI生成过程，确保变更可测试、可验证，并利用现有代码模式。这需要引入结构化提示工程。

研究表明，结构化提示比临时提示方法的表现高出1%到74%，视任务复杂度而定（Sahoo等，2024）。 PDCA是一种成熟的软件工程实践框架，强调持续改进和迭代交付，与敏捷开发的核心原则一致。Ning等（2010）的研究表明，应用PDCA可减少61%的软件缺陷。

PDCA框架概述

以下是我为AI编码交互设计的PDCA循环。我在团队项目管理体系（如Jira）中应用这一流程，以透明、低成本的方式记录分析与检查成果。

该循环适用于1至3小时的编码任务，也可将大型任务拆分为此类小单元。这个时间长度既符合人类注意力范围，也契合模型上下文容量。

整个框架包括“协作约定”和结构化提示语，引导人机协作按步骤推进。每个环节相互衔接，最后的“行动（Act）”步骤通过回顾实现持续改进。

• 工作约定（Working Agreements）开发者承诺遵循既定质量标准引导AI，仅需约1分钟阅读确认。
• 规划分析（Planning Analysis）让AI分析业务目标、现有代码模式及可行方案，形成可追踪的分析成果（2-10分钟）。
• 任务分解（Planning Task Breakdown）指导AI制定实现目标的分步方案，使输出更聚焦，约2分钟完成。
• 执行（Do）采用测试驱动开发（TDD），让AI在迭代中实现代码，并要求AI解释其思路以便人工介入。执行阶段不超过3小时。
• 检查（Check）让AI审查代码实现、文档和README是否符合最初目标，形成检查记录（约5分钟）。
• 行动（Act）通过回顾会议改进提示语和协作方式（2-10分钟）。

框架所用的提示语均在实际编程中经多次回顾优化，并已在GitHub仓库公开。

工作约定：AI协作中的人类责任

“工作约定”源自团队协作实践，旨在维持一致性与代码质量。这一方法同样适用于个人开发者与AI协作的场景，帮助开发者保持主导地位。

在与多代AI编程工具合作两年后，我总结出维持代码质量的最低行为标准：保持小批量提交、减少耦合、提升一致性、避免代码重复。

这些约定包括测试驱动开发（TDD）、增量改动、遵循既有架构等原则，并配以干预问题示例，如：“失败测试在哪？”、“你一次修改了多个问题，能否聚焦于一个？”等。

以下为我的分析提示片段示例：

分析前需提交：

• 找出2-3个具有相似模式的实现
• 记录已建立的架构层次（命名空间与接口）
• 绘制集成触点（需修改的方法）
• 列出可复用抽象层（FileProvider、接口、基类）

计划（Plan）

计划阶段分为高层分析和详细规划。

高层分析：明确业务问题

前期分析能帮助厘清业务问题与技术方案，避免AI在上下文不足时盲目实现，导致重复或回归。 我会要求AI在代码库中搜索相似实现、依赖关系与配置模式，提出可选方案，并只输出“做什么”和“为什么”，而非直接写代码。

示例提示：

规划阶段根据分析结果，制定一个清晰可执行的方案，用于后续的测试驱动实现。执行背景：实现阶段将遵循TDD原则，在人类监督下逐步完成。

详细规划：拆解为可观察、可测试的步骤

确认方向后，AI需列出带有停止条件和验证标准的执行清单。 详细规划能防止AI在长会话中迷失方向或偏离架构。 我要求AI在每个步骤前先编写失败测试，并在连续三次失败后暂停请求协助。

如遇测试失败或思路偏差，我会要求AI重新规划当前阶段。

执行（Do）：人工监督下的TDD实现

执行阶段的提示语要求AI严格遵守TDD，并按批次并行实现相关功能。 这种“红-绿-重构”循环能防止AI跳过测试或生成过于复杂的方案。 研究显示，有结构的TDD在AI辅助下成功率更高（Piya & Sullivan, 2023）。

示例规则：

TDD实施要点

• ❌ 不测试接口，只测试具体实现
• ❌ 编译错误不算红阶段，需行为失败
• ✅ 创建能编译但行为不符的桩代码
• ✅ 优先使用真实组件代替Mock

检查（Check）：完成度分析

完成度分析要求AI回顾整个会话和代码，确认目标是否实现、流程是否合规。 输出内容包括测试状态、文档更新、回归检查、待办项等，并以叙述+清单形式呈现。

示例提示：

完成度检查

• 所有测试通过
• 必要的手动测试完成
• 文档已更新
• 无回归问题
• 无未完成的TODO项

流程审计

• 是否始终遵循测试优先
• 测试覆盖率是否充分
• 是否存在未测试的提交

行动（Act）：回顾与持续改进

回顾环节旨在总结关键决策、发现协作模式中的改进点，并提出下一次最有价值的优化方向。

示例提示：

关键时刻分析

• 哪2-3个时刻最影响成功或失败？
• 哪些决策或干预起了关键作用？

技术与流程洞察

• 哪些模式提升了效率？
• 哪些地方可以更快推进？

成功衡量

我通过GitHub自动化脚本监测5个质量指标：

• 大提交率（>100行，目标<20%）
• 扩散提交率（修改>5文件，目标<10%）
• 测试优先率（同时修改测试和代码文件，>50%）
• 平均修改文件数（<5个）
• 平均修改行数（<100行）

相关GitHub Actions配置已公开。

实验结果（Experimental Results）

为了比较 PDCA 方法 与 无结构方法 的差异，我在 Cursor 中使用 Anthropic 模型，用两种不同的方式实现了同一个开发故事。我收集了定量和定性两类数据，包括：token 消耗量、代码行数、开发体验主观评价和代码质量评估。 该实验的开发任务涉及较复杂的系统交互：

总体目标是让 @Tracer.cs 支持以类、方法或文件作为入口点； 并根据配置文件中的 @TracerOption.cs 设置来确定执行路径； 而不是走原本基于 Rosalyn 的代码追踪路径。 新逻辑应检查 kuzu 数据库 中是否已分析目标 DLL， 如果是，则通过 @KuzuDepedencyGraphReader.cs 和 @DatabaseDependencyGraphBuilder.cs 从 kuzu 中检索出子图（**@ScoredOutputNodeGraph.cs**）， 使生成的映射结果在功能上等同于通过类或方法追踪获得的结果。

无结构方法的 Token 消耗

PDCA 方法的 Token 消耗

从结果可以看出，两种方法在“前期规划投入”和“后期排错效率”之间存在权衡。 在无结构方法中，80%的 token 消耗都发生在 AI 声称任务已完成之后，这些额外的token主要用于后续排查——包括调试失败、补全遗漏实现、修正对代码结构的错误假设等。 尽管这种极端情况不算常见，但在复杂系统集成任务中也并非罕见。

代码输出指标

PDCA 方法生成的生产代码更少、测试更充分、提交更细粒化。 文件数量增加的原因是 PDCA 倾向于将改动拆分为多个聚焦的小变更，而不是在少数文件中做大范围修改。 两种方法都能实现目标功能，但无结构方法在初步实现后需要更长的调试时间； PDCA 的测试驱动式增量迭代则能更早发现并修正问题。

定性对比：开发者体验

从开发体验角度看，PDCA 方法显著更佳。 在 PDCA 模式下，人机互动贯穿规划与编码全程； 而无结构方式下，大部分互动集中在最后阶段，主要用于复查和排错。

我也意识到，这些结果基于单一实验样本。 因此，这并非定论，而是一组具有方向性参考意义的数据， 支持我在实践中继续改进并验证该方法。

进一步发展方向（Areas for Further Development）

目前我使用的协作约定、提示模板和成效衡量指标仍处在不断演进阶段，AI 工具本身也在持续升级。以下是我正在探索和优化的两个重点方向：

1. 将流程正式程度与任务复杂度匹配

PDCA 的结构化方法非常有价值，但需要根据任务的复杂性和风险进行调整。 例如，规划分析步骤会消耗大量 token， 对于那些改动范围明确、上下文清晰的任务（如在现有模式下实现新接口）， 我正在尝试简化分析和规划流程。 此类任务已有足够代码示例可供AI参考，无需冗长的前期分析。

在敏捷发展早期，Alistair Cockburn 提出了 Crystal 方法论， 主张根据项目的重要性与团队规模调整流程严谨度。 这一思想启发我为低复杂度场景开发更轻量的规划与执行提示模板， 同时仍保留必要的模式分析、透明性与回顾机制。

而对于涉及架构设计、跨系统集成或新问题领域的复杂改动， 则更需要完整的 PDCA 流程。 在这些高复杂度任务中，前期分析与规划的投入能显著减少后期返工、回归和技术债。

2. 引入模型选择策略

结构化的分析与规划阶段还提供了优化成本的机会：可根据任务复杂度动态切换AI模型。

我已在规划流程中加入“复杂度评估”， 要求AI预估不同方案的实现难度、模式清晰度和任务范围， 并让它推荐在各阶段应使用的模型（如 Anthropic Claude 系列中的 Sonnet 与 Haiku）。 这些推荐标准具有启发意义，尽管尚未有充分的实证数据支撑。 我也计划在更小模型发布后尝试不同模型组合。

一般而言：

• 分析与规划阶段需要能力更强的模型，因其涉及模糊需求与架构推理；
• 实现阶段可在明确规范的前提下使用成本更低的模型，尤其当代码库结构清晰、模式稳定时。

在“人类在环”流程中，开发者可主动降级模型、观察其表现，并在困难时及时介入，这正是该策略的价值所在。

结论（Conclusion）

研究表明，AI 代码生成尚未实现其应有的生产力潜能，主要受限于质量下降与集成困难。 PDCA 框架通过为人机协作引入结构化流程，既能维持代码质量，又能充分利用AI能力。

该框架包含五项关键实践：

1. 通过分析与规划阶段设定结构化目标；
2. 在任务层面进行细粒度规划，形成原子化提交；
3. 采用红-绿测试循环提前捕获问题；
4. 在“检查”阶段进行完整性验证；
5. 借助“微回顾”实现持续改进。

实验结果显示，PDCA 在增加前期规划投入的同时，显著降低了后期排错与维护成本，并带来了更好的开发者体验。

对于想要规模化采用AI代码生成的组织来说， 需要一种既系统化又可灵活适配个人偏好的方法。 PDCA 提供了这种结构化但可调整的框架。 随着AI能力的快速提升，有纪律的人机协作方法将成为可持续软件开发的关键。