Vibe coding的概念比较抽象化，发一发指令，AI就照着指令去分析执行。但实际过程中，如果方法不得当，AI总会与实际预期有较大偏差。Claude code的计划模式以及其他工具的计划功能是开启每一个创意的绝佳起点。
先通过给予AI一些基础的需求背景、目标、目标用户、用户故事和需求说明，计划模式下的AI便会充分的分析，然后针对一些疑问再与你讨论。这是一次非常典型的计划模式使用方法。在我学习AI编程的初期，对此过程并没有太多思考与想法，与AI讨论完后即开始执行开发。
在我多次实践以后，现在我把相同的需求背景等说明发给Chatgpt、Gemini等多个大模型一同收集信息，而后汇总，再在Claude code中与AI进行讨论。这个过程中可以让整个技术方案更加成熟，且设计得更加合理。因为综合不同AI获取的信息会更加全面，且不同的AI大模型能力不同，也可以形成一定的能力互补。作为一个非技术型的产品经理，对于技术架构的设计以及技术选型并不是我所长，此时AI便可以弥补这个不足。在AI整理完技术方案以后，我还会请教AI一些问题，给予我解释。为什么这么做，一来是更深入的了解为什么这么做，二来也是从实践中学习，更好的进行开发，三来如果发现问题便可以进一步与AI进行讨论而后完善
文档驱动行动
Claude code在计划讨论通过以后，会整理一个完整的计划文档，包含技术架构、整个开发计划的组成。Claude code整理的计划文档是一个值得学习开发实践内容。我总结下来，这个文档的以下几点非常值得效仿与学习。
1. 总结需求概况与背景，并基于概况整理核心的解决方案
2. 提供技术架构、技术栈以及计划的步骤
3. 给出每个步骤的完成标准、交付物以及预计完成时长
4. 针对可能的风险、问题提出相应的解决方案
这是一个非常完整的技术方案模板，而在此基础上Claude code还可以总结一个Claude.md文档，这个文档总结了项目的概况、技术架构、技术栈以及注意点。后续开发迭代过程中，可以不断地更新这个文档，提升AI理解项目背景的效率。
对比传统的软件开发流程，产品经理的需求文档在此过程中被大幅简化了，但是仍然是必需品。可以简化的内容是零碎而细节的交互，这方面可以让AI发挥或是提出一些具体要求后在实现初步可行的版本后再进行优化。但是需求文档中的功能说明、功能结构、核心流程依然需要详细说明，在提交给AI讨论的过程中还可以进一步进行完善。
待诸多讨论过程完成后，便有3份文档作为核心依据，此后便可以持续更新这3份文档不断迭代，3份文档分别是：
1. Claude.md，有Claude code总结的项目说明文档，使用其他AI编程工具也可以生成一个类似的文档；
2. 每次计划模式讨论后的计划文档
3. 每个功能需求的需求说明文档
不仅是使用Claude code，使用其他工具时依然可以参考这种思路来进行方案整理。
目前大模型都有上下文规模限制，为了避免大模型在了解需求的过程中出现偏差，在提供详细的文档的基础上，更要注意充分的利用上下文。一个非常值得去做的事情就是一个对话处理一个任务，也可以理解为一个对话处理一个需求。需求的大小和粒度设计则是考验设计者的地方。
我的经验是将一整个需求拆分为多个部分，在第二部的文档整理好，与大模型讨论确认完成阶段后分阶段完成。或者是以此文档为基础，不同的任务拆分为不同的对话来执行，每次通过文档来记录更新进度，避免编程工具忘记进度以及背景，也避免超过上下文之后需要重复的让大模型回顾背景等内容。
目前的AI大模型还没有完全达到充分“理解”自然语言的程度，所以很多时候依然需要尽可能详尽的说明问题。这点更依赖的是好的提示词，充分的问题分析，开发测试过程中可以借助MCP、Skill等工具帮助提升效率，但是最终的结果检验依然需要人工。比如说视觉效果、交互细节这种前端功能，复杂的接口设计、数据交互与验证，还需要和大模型一起检验与验证。
使用AI编程会给我一种幻觉，我好像什么都能做了。然而现实时目前的AI编程对于技术掌握程度不同的人来说实际的结果以及效果并不同。如果是拥有良好技术知识以及架构思维的高级技术工程师，他们使用AI编程更偏于与大模型一同设计技术方案与架构，而后再交由大模型分模块实现功能，或是补全一些相对简单的模块，复杂且核心的工作还是靠人。他们的工作流程会更偏向于传统的软件研发流程。
而像我一样缺少技术储备的实践者，更多时候是把整个技术设计环节完全交给大模型，无法客观地确认方案优劣好坏。由于缺少客观的评估，也没有能力进行客观的评估，会更加偏向于关注结果。
从一个项目的发展角度来说，前者的代码健壮性、拓展性会优于后者。为了更好的使用好AI编程这项工具，缺少技术知识储备对我而言只能是阶段性的，在此过程中我依然需要通过与大模型交流实践来学习更深入的技术设计，否则大多时候只能停留在较为初级简单的功能开发。
（二）从优秀的工具中借鉴思路
在Agent设计上，我觉得目前AI编程领域的Agent设计是显著优于其他领域的。不论是刚发布的Kimi2.5的Agent集群，还是Claude code计划模式的工具调用、使用Agent进行分析代码等等，都是实际的提升了编程的效率。
仅从AI编程这个领域来说，对于如何实践AI大模型应用，是一个非常值得学习的方向，从中可以发现一些Agent设计思路：
1. 通过上下文或者额外提供的内容，了解任务目标后，基于任务调用不同的工具，工具可以是脚本也可以是其他程序，还可以是其他Agent；
2. Agent是一个能够自主决策判断的流程的统称，一个Agent也可由多个子Agent组成，通过协作达成任务的最终目的；
3. 针对任务，是否要执行Agent，执行哪些Agent均可由Agent自行决策，作为设计者更需要的考虑是针对一个任务，要定义哪些Agent和工具。所以Agent的设计与传统的软件不一样的地方就是，基于AI大模型的底层能力，要去决定在AI大模型自主决策的过程中要赋予它什么能力；
4. 为了让Agent能够更高效的自行决策，需要有足够充分的上下文或是类似记忆之类的内容，这样AI大模型就可以更客观的划分任务，执行Agent达成目标；
以上是我在使用AI编程工具过程中学习到的思路，从中可以看到AI大模型作为大脑，已经可以开始借助额外的工具开始自行执行任务了。如果只是停留在给AI发号施令，靠感觉编程，结果也许并不会特别让人满意。尤其是软件项目发展过程中，会越来越复杂，更需要合理的功能模块化，这里更加考验的是产品经理的功能规划能力以及技术理解能力。
这个过程中我更大的感受是，越想用好AI编程这个工具，越需要使用者有更充足的知识储备，AI编程的结果即是使用者能力呈现。
（三）借助AI大模型回顾和重构
由于我对软件研发的技术了解并不深入，此时便可以借助大模型帮助我分析项目的代码质量，从安全性、扩展性以及健壮性等角度进行分析，提出优化改进建议。
这些建议未必需要全部执行，此时可以寻求自身技术工程师的建议，充分评估，而后再结合大模型的建议进行优化总结。
这个过程中便可以借助优秀的工具和优秀的工程师思维完善项目，更是高效的帮助自己学习技术思维。
不要让AI大模型替代自己进行思考，这是我时刻警醒自己的一句话。仅从Claude code这种AI编程工具来说，对工具的使用者就提出了一定的要求。
举个例子，如果一股脑的把复杂的需求交给AI大模型，它也会划分阶段和功能模块，但是AI大模型是没有实际运营视角的，它更多的是结合训练的知识客观的分析。此时对于产品经理的考验就是如何结合实际运营需求去划分需求优先级，如何告诉AI下一步的计划是什么，预留好拓展的空间。
仅以此例而言，更需要的是产品经理作为需求负责人的宏观角度分析任务，AI编程始终只是帮助自己判断的工具，这依赖的还是产品经理本身的项目管理、需求分析能力。
AI编程在现阶段还无法完全替代一个成熟的研发团队，更合理的使用方式还是借助AI大模型来学习，先从提升效率和质量的角度实践起来，而非让技术理解不足、技术知识不足的使用者直接替代成熟技术工程师。但结合大模型的能力进化速度来看，初级的编程工作，诸如简单的前端页面设计、基础的增删改查已经可以被AI大模型替代，同样的简单的需求分析以及需求设计也可以用AI大模型实现。在这样的背景下，产品经理更需要做的事是聚焦功能的规划、需求的效果分析和评估，这更需要的是强大的逻辑分析、数据分析能力。
1. 不要让AI替代自己进行思考
2. 学习成熟优秀产品的设计思路，从Claude code的编程工具设计思路中可以看出非常成熟且使用的技术设计思路与方案
3. 合理利用大模型的上下文，使用文档作为总结与背景，可以提升与大模型交流的效率
4. 产品经理需要与时俱进的学习，对于技术理解与分析也需要随之提升
5. 从更宏观的角度分析功能和需求，借助AI大模型可以提升效率，但最终的效果分析与决策依赖的还是人
6. 先去开始做，干就完了
请克服恐惧，去找到内心的秩序。
10个月宝宝每天需要喝多少奶粉？
