我们先来探讨两个开放性问题：

为何要将AI编程经验沉淀为方法论？
AI编程工具，层出不穷，仅仅会使用就足够了吗？经验无法迁移怎么办？

AI编程方法论如何落地？
方法论很好，但不同的人执行起来，往往千差万别，如何消除或减少这种gap呢？

---

一、什么是PDTAC循环？（What）

PDTAC循环，可以把它理解为，是一个经过强化的PDCA循环，专门为AI编程场景量身打造。

PDCA循环，最初是由管理大师戴明提出的质量管理工具，它以其简洁而高效的特点，在全球范围内广受推崇。

这个工具之所以被称为「循环」，是因为它像一个永不停歇的螺旋，推动项目不断向上攀升。

每一圈螺旋都包含四个关键步骤：Plan（计划）、Do（执行）、Check（检查）和Action（行动）。

那么，PDTAC有什么不同呢？它保留了PDCA的精髓，但增加了两个关键的新机制：

1. 首先，将「Check」升级为「Test」，这不是简单的文字游戏，而是赋予了全新的内涵——强调自动化测试和全量测试的重要性。
2. 其次，在最后增加了「Commit」环节，确保每一个改进都能及时保存，每一个改进都留下足迹。
3. 没有了

PDCA

PDTAC

规划阶段

• Plan（需求描述）
• 把任务拆分为小任务，然后生成一个文档，让AI编程工具可以跟踪（如Cursor/Trae等）

行动阶段

• Do（生成代码）
• Test（测试）
• Action（Bug修复）
• Commit（代码提交）

通过PDTAC循环，让 AI 进行自我纠正，持续提高开发效率和效果。

---

二、为什么PDTAC循环重要？（Why）

我们先来讨论一个问题：AI编程目前处在什么阶段？

现在的AI编程，还处在早期蹒跚学步的阶段，就像一个聪明的新手程序员，它已经能够漂亮地完成一些中低难度的编程任务，但在面对复杂的业务需求时，还会显得有些力不从心。

那么，面对这样的局面，我们该如何应对？
第一条路，就是选择等待。我们可以安静地等待，直到AI模型成长得足够强大，完全胜任我们的业务需求。
第二条路，则是主动出击：改变我们的工作流程，去适配当前的AI模型。

如何让我们的工作方式与AI模型的能力更好的适配？
为了让我们的工作流程更好地适配AI模型，我们需要遵循三个核心原则：

1. 一次只处理一个任务，避免思维混乱；
2. 将任务规模控制在上下文窗口范围内，确保模型能够充分理解；
3. 对于大型项目，善用检索增强，让AI能够精准定位并利用关键信息。

面对复杂的业务需求，我们应该如何驾驭AI的能力，将其转化为实实在在的生产力？

即使在了解了以上原则，面对复杂的业务需求，我们依然会感到困惑：我们的业务是一个庞大而复杂的整体，如何让它适配AI模型的能力限制呢？这个问题的答案，就藏在本文讨论的强化版的循环工具中——PDTAC循环。

有了这个强化版的PDTAC循环工具作为指导方法，我们就能够将庞大的业务需求，优雅地拆解成一系列小型任务。确保我们能够专注地处理单一任务，从而获得最优的输出结果。

一句话总结： PDTAC循环，这种循环往复、稳步前进的方法，让我们能够以一种可控的方式驾驭AI的能力，将其转化为实实在在的生产力。【它正是我们在AI编程早期，需要掌握的核心工作方式】

---

三、PDTAC循环，如何融入日常开发工作？（How）

懂得一个道理很简单，难的是如何把它用起来。

在面对一个复杂任务时，一般都可以拆为以下四步：确认需求、确认方案、代码开发、测试验证。

AI编程工具的到来，对程序员来说，最大的改变是什么？
人机结合的对话式编程：从以前开发阶段的如何编写代码，到现在需求阶段的如何与 AI 沟通。

1、Plan（需求描述）

「Plan」阶段，对应AI编程中的需求描述。

AI 很强，他像是一个无所不能的大师，但是他不知道你脑子里到底想要什么。

当我们说的，不能表达真正想做的事时，AI是无能为力的。让人意外的是，清晰地描述需求，对于很多人来说，可能是一个困难的任务。

我们先来讨论一个问题：什么样的语言，AI更容易理解？

核心的原则是：结构化表达+足够的上下文。

结构化表达：就是在描述需求的时候，尽量使用markdown格式，这种格式天然会对内容“分块”，AI 更容易理解；
足够的上下文：大多数场景，可以使用“人设+任务+上下文+案例+方案”的组合
结合一下，就是把足够的上下文，记录到 markdown 中，然后喂给 AI。

1. 从 “想清楚” 到 “说清楚”

能够精准用语言表达需求的能力，正在变得越来越稀缺。

需求描述越清楚，AI理解需求就越精准，生成的代码就更符合期望。

那么，我们如何进一步提升需求描述的精准度呢？

1、让 AI 逼迫你思考：反向费曼学习法
对于 AI 来说，当你提出了一个问题，想想：他真的懂了吗？让 AI 反述一遍，你听听如何？但是光这个就够了吗？
不够，你还需要让 AI 具有质疑精神，让他对你的问题提出质疑，而不是全盘接受！
反向逼迫你去思考，什么是“真需求”，让 AI 变成你思维的“延展”。
我把这种模式称之为：反向费曼学习法。

2、使用代码和伪代码
如果需求包含相对复杂的逻辑，用文字难以清晰表达时，可以将代码或伪代码作为需求描述的一部分。

使用伪代码的优势是什么？
伪代码的格式灵活，我们可以通过定义变量、使用循环和条件语句等方式，描述复杂的逻辑。
语法错误、中文英文混杂都没有关系，只要能够清楚地传达逻辑结构，都能达到良好的效果。

// 检查是否登录
if(未登录){
   // 跳转到登录页   
} else {
  // 跳转到设置页  
}

3、善用图片
当前很多AI编码工具已经可以支持图片描述（其实主要是模型支持了）。
在很多情况下，尤其是和界面相关的业务中，「一图胜千言」并不夸张。

2. 分而治之+小步验证

AI 的优势是，它懂得多懂的广，但是它很难了解全部上下文。

当我们定义好了“问题”后，可以采用《领域驱动设计》中提到的一个解决问题的通用模式：分而治之。
再难的问题，也可以拆分为无数个简单的小问题，把每个小问题解决好了，大的问题也就不是问题了。

如何拆解问题？

• 先使用上述的方式，进行需求澄清+疑点确认，
• 然后使用 Ask / Chat 模式，先让 AI 给出不同的解决方案以及优劣，
• 由人去权衡并选择方案，而不是 AI 去选择（人去权衡选择，其实就是在变相的补充上下文）

如何拆解方案？

• 让 AI 去拆分方案，拆分成 AI 可以执行的步骤。
• 两个小技巧
  • 对AI生成的方案，不妥或不符合你预期的地方，通过多轮对话，让AI进行优化
  • 把拆分的结果，记录到 Notepad 中（如：Cursor 提供的轻量化记录工具）
• 目的，一个是给自己看，帮自己理清思路（对于上生产的代码，你必须知道方案的思路），也方便后续在此基础上做调整；另一个是作为上下文给到 Agent 模式，Notepad 在两种模式之间起到了很好的桥梁作用。

---

2、Do（生成代码）

「Do」阶段，对应AI编程中的代码生成。

按照拆分的任务计划，逐步执行、逐步验证。
切记不要一次生成几千行代码，再验证，不然可能会越改越乱。

AI 编程的一些小技巧。

1. 手动控制上下文

在生成代码时，除了你输入的文本和当前打开的文件，AI编程工具本身还提供了一个上下文选择功能。可以选择与当前问题相关的文件，这些文件会被作为上下文使用。
例如，你可以选择一个目录、一个文件，或者选择特定的Git版本作为参考。

2. 代码生成工具

以 Cursor 为例 ，在代码生成方面，目前 Cursor 提供了两种工具：一种是 Ask，另一种是 Agent。
Ask模式：如果你的任务只是修改少量内容，这种方式非常简单高效。当任务变得更复杂，比如需要创建多个文件、执行多个命令或同时修改多个文件时，Ask工具就显得有些繁琐。因为你需要进行一系列手动操作，效率会受到一定的影响。
Agent模式：为了更高效地处理复杂任务，智能体会自动执行任务，并监测结果，用于判断是否需要进一步操作。如果任务没有完全完成，智能体会继续执行后续操作，直到完成为止。这种方式非常方便，它可以帮助你完成绝大部分工作，而你只需关注结果的输出。

---

3、Test（测试）

「Test」阶段，对AI编程生成的代码，进行单元测试、自动化测试或全量测试。

开发者对最终结果负责。
对话式编程，是人机协同，但归根结底，你必须验证你的工作，我们有责任核实自己的工作。

1. 当简单变得不再简单，AI开发的应用可能随时崩塌

想象你正在搭建一座乐高城堡。刚开始时，放几块积木很容易，城堡看起来也很稳固。但随着建筑越来越高，每加一块新积木，都可能让某个角落松动，甚至导致整座城堡倒塌。这正是我们在用AI开发复杂应用时面临的挑战。

现在，只要会打字的人都能用AI写出简单的应用程序。但当我们想要建造更宏伟的「城堡」时，问题就出现了：加一个新功能，可能会破坏三个已有的功能。渐渐地，我们的应用就会变成一个「问题集合体」，就像一座摇摇欲坠的积木城堡。

2. 为什么AI会犯错？

• 黑箱的不确定性：AI就像一个才华横溢但有些任性的艺术家。即使你给它相同的指令，它每次创作出的作品都可能略有不同。这是因为AI本质上是一个「黑箱」，它通过大语言模型进行创作，而不是按照固定的逻辑运行。就像人类艺术家的灵感，有时会特别出众，有时则可能略显平庸。
• 上下文的重要性：想象你在给朋友讲一个故事，如果漏掉了关键的背景信息，朋友很可能会理解错误。AI完全依赖我们提供的上下文来进行创作。如果我们忘记提供某些重要信息，或提供了错误的参考资料，AI自然会得出不准确的结果。
• 人类也会犯错：有趣的是，这些问题并不是AI独有的。想想看，人类在疲劳时可能会把简单的单词都打错，更不用说编写复杂的代码了。实际上，在某些方面，人类可能比AI更容易出错——毕竟AI不会感到疲劳，也不会因为心情不好而影响工作质量。

3. 工程化质量保障

软件开发本质上是一个工程问题，需要系统化的方法来保证质量。通过将质量控制融入开发流程的每个环节，我们能够构建出稳定可靠的系统

• 自动化测试的持续集成
• 标准化的开发流程
  通过将AI的智能与严谨的工程实践相结合，我们既能保持快速迭代的节奏，又能确保系统的可靠性。
  在AI时代，提升质量的成本低得难以置信，你只需要告诉AI：「请为这个新功能创建自动化测试」。

自测类型

• 单元测试：【仅关注自身代码的准确性】
  • 针对某一部分代码进行测试，会mock掉依赖的服务或接口
• 集成测试：【关注整个调用链路的准确性】
  • 从暴露的接口开始进行完整功能的测试，依赖其他服务或接口

---

4、Action（Bug修复）

「Action」阶段，对发现的问题进行修复和优化。

1. 一般Bug的修复

通常来说，如果我们使用 Cursor 的Agent工具，在生成和修改代码后，它会自动检查静态语法分析的错误。一旦发现Bug，Cursor 会自动尝试修复，这是非常便捷的功能，因此我们推荐大家尽可能使用它。

2. 顽固Bug的修复

在实际使用过程中，我们也可能会遇到一些顽固的Bug，这些问题，就需要我们手动介入处理了。

如何识别顽固Bug？

• 问题识别：我们需要识别 Cursor 是否已经陷入了无法解决的问题。
• 手动终止：如果发现 Cursor 提出的解决方案开始重复，先要终止这个循环，避免继续在这个循环中浪费时间。
• 帮助理解：尝试为 Cursor 提供更多的上下文信息，帮助它理解问题。检查一下是否有资料没有提供，或者是否遗漏了关键的代码库部分，尤其是那些与我们要解决问题直接相关的内容。
• 禁止追加新问题：不要将新的问题，在原有问题的后边，进行追加讨论。这样做可能导致上下文过长，或者会违反「每次只做一件事」的原则。更好的做法是，开启一个新的聊天（Ask）或编排（Agent）窗口，将新的问题单独提出来，然后观察新的结果。
• 更换模型：目前 Cursor 使用的模型是Cloud 3.5 sonnet，虽然它较为智能，但对于一些复杂任务，我们也可以尝试使用O1模型。O1模型通过多次思考来提升其智能，尤其在面对复杂任务时，可能会提供不一样的解决方案。而且，两个模型有不同的思维维度，换个角度思考，可能就能找到问题的突破口。
• 借助外部：如果上述方法仍然无法解决问题，可以借助外部帮助。我们可以将问题提取出来，送到其他大模型中进行询问，或者根据实际情况，进行人工干预，手动修正问题。

---

5、Commit（代码提交）

「Commit」阶段，确保每一个改进都能及时保存。

避免在「Commit」阶段，多次使用AI进行问题修复时，将原本好的代码给改坏了，而无法回退。

将Commit作为循环的一大阶段只有一个原因 —— 防止忘了它。
请记住作为一个专业程序员的常识：
1、git commit
2、git push

---

四、PDTAC循环，具体如何落地？

懂得一个道理很简单，难的是如何把它用起来。

步骤	核心内容	具体案例（提示词）
第一步：与AI对话 （Chat模式）	• 目标：你要知道你要完成什么功能 • 内容：写这段代码需要知道的背景知识 • 技巧： 　○ 任务拆分的越小，实施的难度就越低 　○ 鼓励AI向我提问，完成这个功能，我还需要考虑什么 　○ 让AI给几个不同的方案，然后让AI自己评估 　○ 人工权衡并选择最佳方案	任务： 我要用Java实现一个通用的调用不同大模型平台api的路由功能，以便我可快速无感的接入新的大模型平台的api 功能要求如下： 1、对外暴露一个通用的接口，该接口可通过传入的参数，找到对应的大模型平台和对应的api，也就是路由的能力 2、设计一个高可扩展方案，实现不同大模型平台下不同api的快速开发和对接，且要求符合开闭原则 请按照如下步骤，逐步帮我分析和解答我的问题： 1、完成这个功能我还需要考虑什么 2、请设计3种方案，并给出优劣势
第二步：制定计划 （Chat模式）	• 技巧：任务足够小时，可以忽略该步骤 • 制定完整代码实施计划，可以输出MarkDown格式 • 计划内容：应包括代码示例、引用相关资源文件或相关代码片段 • 判断标准：要让一个新来的程序员看懂这个计划，直接就可以写代码	任务： 1. 基于上面的对话内容，整理并输出一个MarkDown格式的代码实施计划 2. 该计划应包括需求背景、功能点、关键注意点、项目结构(含controller和test)、代码示例(含单元测试)、实施步骤(含单元测试)、相关代码片段或引用的相关资源文件 要求： 1. 要让一个新来的程序员看懂这个计划，直接就可以写代码 2. 该计划要对AI编程工具友好，以便我使用该计划，直接生成高质量代码 3. 将计划写入 d:\workspace\gitee\study-ai\study-ai-route-ai\note\实施计划.md 4. 代码的存放模块路径：d:\workspace\gitee\study-ai\study-ai-route-ai 注意： 可以让 AI 检查和改进这个计划
第三步：实施计划 （Builder模式）	• 技巧： 　○ 要启动一个新窗口，将制定的计划输入 　○ 编码测试一体化，让AI生成单元测试或集成测试，将测试和优化融入日常开发流程 • 说明：随着上下文变大，模型性能变差	分为多个步骤（循环执行） • 生成代码：基于markdown实施计划生成代码 • 执行测试：生成单元测试并执行 • BUG修复：引导AI修复执行单元测试的报错 • 代码提交：将测试通过的功能代码进行提交

---

五、最后

纸上得来终觉浅，绝知此事要躬行。

第一遍阅读：过年期间看过一遍，觉得内容很好，但体感不强。
第二遍阅读：年后AI编程的实践，再次阅读时，对遇到的一些问题，以及对AI编程有了更深的理解。
第三遍阅读：大量的信息输入，再结合实践，总结沉淀经验。