Marico's space
最近折腾了AI辅助开发这件事，在团队里搞了场实战工作坊，踩了几个坑，也摸索出一套还算实用的方法论。这篇把核心内容梳理清楚，不整虚的。
生成式AI正在快速改变软件开发的方式。很多团队都在用AI编程工具，但真正的挑战不在于生成代码，而在于建立一套可重复的流程，能持续产出可靠、高质量的成果。
这次工作坊没有用那些玩具级别的示例，而是围绕一个真实的业务问题展开，全程应用结构化的AI辅助开发流程。最终的产出不只是能跑的软件，更重要的是我们提炼出了一套实用框架，帮助工程师与AI agent高效协作、提升效率的同时保持工程质量。
在动手写代码之前，有一点反复强调：先理解，再动手。
参与者被要求提前熟悉业务需求和问题域，而不是上来就让coding agent开干。目标不是更快地生成代码，而是：
工作坊强化了一个关键原则：AI可以加速开发，但理解业务意图的责任永远在人这边。
很多人讨论AI时，焦点都在"怎么写出完美的提示词"。这次工作坊让我们意识到，更重要的是"上下文工程"（Context Engineering）。
效果最好的案例中，工程师提供的是：
团队没有上来就让AI agent生成代码，而是先提供全面的上下文，要求agent充分理解问题后再行动。比如这样：
"我想创建一个新的Spring Boot应用，用于销售平台。请先review需求、理解验收标准，在创建实现计划之前，先向我追问所有问题。"
业务需求描述了一个场景：卖家需要一个流畅的方式服务客户，同时依赖现有系统作为数据权威来源，避免跨平台的不必要数据重复。
提供这种级别的上下文后，AI生成的计划、测试用例和实现建议质量明显提升。
工作坊中有一个非常实用的概念，我称之为"追问法"（Grill Me Technique）。
核心思路是：不急着给出解决方案，而是指示AI agent挑战假设、追问后续问题，直到彻底理解需求。
这让agent从一个代码生成器转变成了业务分析师。AI不再靠猜，而是主动提问：
目标是消除所有歧义，再开始规划或实现。这个过程经常能在开发启动前就发现需求中的缺口。
工作坊采用了一套可重复的工作流程，目的是最大化AI效能，同时保持工程纪律。
步骤一：需求发现
向AI agent提供业务需求，要求它在提出解决方案之前先充分理解请求。Agent应该review可用的上下文并提出澄清问题，直到需求被充分理解。
产出：对问题的清晰理解。
步骤二：实现规划
需求理解清楚后，AI生成：
产出：可执行的实现计划。
步骤三：人工审查
开发者review提议的计划并挑战假设。这是整个流程中最关键的阶段之一。
目标不是盲目批准计划，而是验证：
产出：经过验证的实现策略。
步骤四：测试驱动开发（TDD）
在写代码之前，让AI生成测试用例。结构化的TDD方法鼓励工程师在实现开始前就定义系统的预期行为。
好处包括：
产出：与业务需求对齐的全面测试覆盖。
步骤五：审查测试用例
开发者review生成的测试，确保：
高质量的测试用例往往能在实现开始前就暴露需求缺口。
产出：可靠的验证标准。
步骤六：代码实现
在需求、计划和测试都经过验证后，AI生成实现代码。由于前面几个阶段建立了强有力的防护栏，实现质量显著提升。
产出：更快、更准确的开发。
步骤七：验证和优化
AI生成的代码绝不能默认视为可投产状态。工程师仍然需要执行：
产出：达到生产质量的软件。
工作坊让我们收获了几个重要教训。
需求质量决定AI输出质量。输出的质量直接取决于输入的需求质量。清晰的业务需求一贯能产出：更好的实现计划、更好的测试覆盖、更好的代码质量。
人工监督仍然关键。AI可以加速分析、规划、测试和编码，但它无法替代工程判断。开发者仍然负责：
TDD与AI配合得极好。在实现前生成测试，为开发者和AI agent之间创造了强有力的协作关系。测试提供了结构、定义了预期、减少了歧义。AI生成测试加人工review的组合被证明特别有效。
流程比模型更重要。最令人惊讶的教训之一是，成功更多地取决于围绕AI的工作流程，而不是使用哪个具体的模型。团队往往执着于找到"最好"的模型，但实际上，严格的流程带来的结果持续优于单纯依赖模型能力。
也许最重要的收获是：软件开发正在进化。开发者花在写重复代码上的时间越来越少，更多地花在：
最有价值的工程技能不再是快速敲代码，而是提供正确的上下文、问正确的问题、验证正确的结果。
软件开发的未来不是用AI取代工程师，而是让人类专业知识和AI能力之间形成有效的伙伴关系。工作坊证明，成功的AI采用早在代码生成之前就开始了。它始于理解需求、提供丰富的上下文、挑战假设、review计划、验证测试，并在整个开发生命周期中保持对质量的所有权。
当与严格的流程结合使用时，AI不仅仅是生产力工具——它成为了工程团队的效能倍增器。