从2022年 ChatGPT 普及“自然语言编程”开始，AI 已经深度融入到了我们的日常工作中。

根据GitHub 2023年报告，使用Copilot的开发者编码速度提升55%

微软研究数据表面：AI辅助开发的代码bug率降低约40%

Stack Overflow 2024调查，88%的开发者表示AI工具提升了工作体验

对一个软件开发者而言，“会用 AI” 已经从锦上添花变成了基本功，从需求分析 → 方案设计 → 编码实现 → 测试验证 → 灰度发布 → 上线运营，每个环节都可以用 AI 来显著提效。

作为一名业务开发人员，我自己主力 IDE 这两年也经历了从：Vim → Vim+工蜂Copilot → Cursor 的升级过程。在开发过程中，AI 也逐渐从一个提供 Tab 魔法的 Copilot 角色，转为一个更智能的 结对编程 角色。

Anthropic 最新的一篇报告（https://www.anthropic.com/research/anthropic-economic-index-september-2025-report） 也给出了 Claude 的使用模式数据：自动化、指令式的模式占比在显著增多。

既然是结对编程，可以把 AI IDE 看成一个合作伙伴：它知识渊博（训练内化的各类通用知识）、有一定的逻辑推理能力、效率惊人，但同时确定性不太好（概率本质，幻觉）。

但我们大多数需求中追求的是确定性的交付结果，所以要采用一些合适的方法，让 AI 扬长避短，在提效的同时，尽力保证结果稳定。

个人实践下来，发现 PDCA 是个挺有效的方法：

戴明的 PDCA（也称“戴明环”）是持续改进的闭环方法。

定义：PDCA = Plan（计划）- Do（执行）- Check（检查）- Act（处理/标准化），循环往复实现持续改进。

目的：以数据驱动、低风险的小规模试验验证改进行动，沉淀为标准，再进入下一轮升级。

在需求交付中，把目标拆到尽可能小的确定的独立任务，明确达成路径，再基于每个小任务和 AI 结对编程，如此循环，将 AI 的黑魔法变成稳定可靠的生产力。

• Plan 是单次循环中最重要的一步，类似 CoT，但是是人来主导和规划，AI 辅助，以保证达成目标路径的确定性。

• 在每个循环中，通过 D-C 循环来确保符合预期

• Act 是长期改善的关键：

• 从本次需求视角看，可以对不符合预期的结果调整指令、计划、上下文。

• 从全局视角看，可以识别和沉淀规则，分析模式抽象组件（例如：由专用Agent承载），持续改善开发环境。

如果把我们日常开发的项目，按照复杂度和质量要求，大致可以分成以下三大类：

下面针对三种场景分别分享一些实践 PDCA 的要点。

场景特点：生产级代码，需要高稳定性和可维护性。

• 作为业务开发团队，我们绝大部分场景都是这一类。

• 典型例子：一个新的产品特性迭代，重构一段“屎山”历史代码。

协作模式：人主导设计方案，AI辅助代码实现和质量检查。

让 AI 理解上下文：

• 给 AI 提供现有的业务和系统元数据：领域知识、业务建模、领域建模、系统架构、物理模型等。

• 为 AI 指定需要阅读的代码范围，因为上下文窗口限制，代码范围越小越好。

✅TIPS：结构化的元数据，对 AI 友好

✅TIPS：小仓模式，对 AI 友好

让 AI 理解任务目标：

• 阅读需求，理解业务规则和约束条件。

• 费曼学习法之 AI 上下文养成：让 AI 总结目标并结构化描述，人工确认。

✅TIPS：使用 TAPD MCP，可以提高 AI 阅读理解需求的交互效率

✅TIPS：Cursor 支持多模态，涉及界面的需求，可以直接提供截图，效率更高

让 AI 辅助制定计划：

• 生产交付的场景，需要开发人员提前做好概要设计（哪怕是在脑海中）

• 让 AI 辅助详细设计，评估代码修改的细节，基于过往的最佳实践做查漏补缺，并记录到文档

• 让 AI 制定测试计划，便于 TDD 做检查

• 新需求：设计测试剧本，并拆解可测试性（可注入依赖、领域）、写自动化测试脚本等若干任务

• 重构需求：评估是否已经存在自动化回归测试脚本，如缺少也要拆解任务

• 拆解出来的测试任务，可以实施新的 PDCA 循环

✅TIPS：开启 CoT，并让 AI 结构化输出（如 Mermaid 格式的序列图），可以显著提高效率

• 明确的待修改代码：通过指令式的 Prompt，让 AI 执行编码。

• 如果现状代码比较复杂（常见“屎山”祖传代码），需要人来主导编码，AI 辅助补全。

✅TIPS：不要使用 Auto 自动模式，确保每处代码都经过人工检查

Cursor有个很贴心的功能，做完的计划会以 To-dos 的形式列出来，方便对照执行：

• 每轮代码修改，都可以让 AI 再做一次 CR，检查：代码规范、以及否存在可能的遗漏之处。

• 通过已就绪的自动化测试，验证每一轮的改动是否符合预期。

• 每个小任务完成，达成阶段性目标，及时提交 Git Commit。

✅TIPS：TDD 原生适配 D-C 循环

✅TIPS：如果测试或者质量红线不通过，可以直接截图让 Cursor 修改，快速循环

✅TIPS：在 Cursor 中可以直接 @git 来总结 commit 内容

• 对 Check 到的问题做归因：

• 如果是共性约束，例如：代码规范、组件偏好等，可以加到如 Cursor Rules 规则集中。

• 如果是元数据质量的问题（如领域知识不足，导致 AI 无法准确分析思考），需要补充完善元数据。

• 对本轮任务做复盘：

• 不做这个任务行不行？是否可模式化、抽象组件（Agent承载）的可行性。

✅TIPS：在 Cursor 中，可以使用 .cursorrules 文件管理规则，并且纳入版本管理，团队知识共享

场景特点：功能优先，同时兼顾一定代码质量（留一条“做大做强”的路子），但避免过度工程化。

• 典型场景：不确定的产品原型穿刺、搭建个人效率工具

协作模式：人和 AI 系统开发，快速迭代验证。 D-C 循环要快。

聚焦核心产品假设，拆解 MVP，再基于 MVP 进一步拆解任务。

✅TIPS：采用 精益 思维模式，可以帮我们更准确的拆解 MVP。推荐阅读：《持续交付2.0》第六章https://weread.qq.com/web/bookDetail/c9c321c07293508bc9c79df

在小任务的粒度，自己体验是否能跑通，体验是否顺畅。

在MVP的粒度，找产品经理或典型客户体验，收集反馈结果。

基于反馈调整方案或者产品方向，并沉淀可复用的能力，为下轮迭代做准备。

场景特点：能跑就行，只要结果。

• 典型场景：数据探索，技术方案调研等。总之就是试试看，看能不能试出个结果。

协作模式：

• 人负责创意，让 AI 做开发主力，人工检查结果。

TIPS：在这个场景下，AI 占据了大部分的的工作时间，开发者的心智负担显著降低，所以往往可以在处理工作的间隙 并行 开展。

这个场景下只要结果，因此 Plan 是最重要的事：

• 将上下文背景和目标清晰的传递给 AI

• 方案思路要发散有创意，可以让 AI 辅助提供各类思路，充分应用 AI 的知识广度。

组织好提示词，快速执行，重点关注结果有效性。

✅TIPS：在 Cursor 中可以将安全的命令加到 allow list，可以兼顾 agent 模式的效率和安全性。

结对编程是人和 AI 的沟通，就”沟通“本身而言，很大部分开发人员其实就不太擅长，信息在 【想表达】-> 【实际表达】->【LLM获取并理解】每个环节中都存在衰减。

提示词工程的本质就是 好好说话，换位思考，让大模型能理解我们的目的。

可以通过套路化的结构化表达，帮助我们组织提示词：

• 套路的结构化：角色、背景、目标、要求、样例（参考样板代码）

• 把共性的 角色、背景知识、要求写到规则中，如：技术栈要求、代码规范、代码仓库规范、领域知识等等，让提示词尽量 简洁、准确

• 如果实在不知道怎么写，也可以先让 AI 生成一版（例如：https://promptpilot.volcengine.com/home）

Prompt 很有效，但个人建议不必过分追求，随着大模型的推理能力的快速进化，提示词的”技巧性“会被逐渐抹平，最终还是会回归到”上下文背景+目标“的核心诉求。

上下文工程仍然是为了解决和 AI 沟通的问题，比 Prompt Engineering 的范畴更大。

什么是Context（上下文）：LLM生成回答之前所看到的一切信息，包括系统提示词、用户输入的问题、当前对话的历史消息、系统对你的历史记忆、工具返回的信息等。

当上下文token 增长到一定长度时，分散了注意力，大模型推理的准确率大幅下降。

早期的 AI Host 对上下文窗口支持有限，需要想各种技巧来提升信息传递效率，不过现在日子真的已经好起来了：

• 大部分的 AI IDE 支持对历史对话做摘要和压缩，多轮对话后，上下文中真正丢失的信息有限

• 背景知识的 RAG 基建逐步完善，帮助大模型扩展知识体系

• AI 的上下文窗口也支持的越来越大（Cursor 已经支持到 1M，除了贵没毛病）

为了避免 Context Rot，在 PDCA 模式实践中，还可以：

• 一个 D-C-A 循环完成后，启动下个小任务时，就再开一个新鲜的上下文窗口。

• 使用 mcp-feedback-enhanced（https://github.com/Minidoracat/mcp-feedback-enhanced） ，可以有效组织指令，节约 token （但个人不是很建议，至少用 Cursor 时感觉必要性不大，避免潜在的安全风险）

✅TIPS：将日常沉淀的 Checklist 加到 Cursor Rules 中，融入到每次 AI 结对编程中。

推荐配置的两个基础规则：

• 官方 代码规范 rules

• 团队基础库规范，可以结合 iWiki MCP 工具 在 Cursor 中直接生成规则文件，并配置定期同步更新的脚本：

Cursor 从 v0.51 开始提供 Memories 功能，可以帮助我们更方便的管理上下文。

Memories 和 Rules 的使用场景有所区别：

可以把 Memories 当成一个轻量的知识库（和 RAG 的区别是规模小，没向量化，所以不能语义检索，只能基于规则和ID的匹配）

举个一个部署架构的应用案例：

（1） 瓦特 上的原始部署图：

（2）在瓦特上复制出 json 结构化数据，配置到  .cursor 目录下，并补充对应的元数据契约描述。

（3）在 Cursor Memories 中指定应用

至此，Cursor 上下文就可以理解这个部署架构了：

虽然 Scaling Law 的边际递减，但是 AI 在各个场景的应用渗透才刚刚起步，就业务开发场景来说，还有大量的创新、整合、提效的优化空间。

其实过往这些年，已经有许许多多的模式总结提炼、组件抽象、专家系统、低代码平台等等的探索和应用，也有很多不错的效果。 

但是，无论抽象多少组件、平台和系统，还是有很多“特殊”情况无法处理，或者有很多”边界“情况不值得处理。这些提炼的组件/平台/系统只能用于那些特定的任务（主要是容易被模式化，边际收益高的场景）。（姚顺雨在一次访谈中表达过类似的观点） 。

所以当一个系统越来越大的时候，系统中到处充斥着各种“特殊”的逻辑，人的认知负荷越来越重，所以需求越来越难做：我们要花大量的时间来理解业务需求、评估和设计方案、分析影响面、在复杂的代码上继续累代码、在巨量的测试用例上继续累测试，难以快的起来。

但，LLM的推理和泛化能力，带来了新的希望，令人欣喜，甚至是惊喜。

AI 的深入应用，会逐步带来业务开发的范式演进，对人的要求也会变化。

过往的开发实践更依赖人的经验积累：

• 如何选用合理的技术栈、架构模式、组件

• 应用过往沉淀的最佳实践

• Checklist防漏防错

• ……

在 AI 时代，这些终将会被 LLM 训练内化。反而各个领域的元数据、知识沉淀会成为核心竞争力。

基于这些知识预训练的 AI，是经验丰富的领域专家 + 无所不能的全栈开发。

在我们日趋复杂的庞大系统中，饱含了大量的低密度的信息，这些在 AI 时代，会被快速的替换为可复用组件。

新的生产任务，绝大部分会由各个专用 Agent 来负责分析评估、设计、使用组件、编写”边界“和”特殊“场景的代码、测试。

业务开发的工作流，逐渐演进为：人 + Agent矩阵的协同生产。

在工作流的各个环节（分析、设计、编码、测试、验收、部署等等），会涌现出各类专用 Agent，形成矩阵式的组织结构：

作为业务开发人员，一方面需要更多的锻炼自身的能力：

• 系统思考：全局思考、深度思考

• 架构能力：系统设计、宏观规划

• 结构化表达：与 AI 的沟通、反馈

• 创新力：寻找 AI 超能力加持下新的商业价值

另一方面，应当持续投入建设知识工程，在日常研发过程中逐步构建场景化 AI Agent，并持续提升其稳定性（Robustness），大步迈向 100x  大 AI 时代。

每一次技术的跃迁，都是对旧秩序的颠覆，也是对新可能的开启。

写给在 AI 时代的我们，互勉。