探讨Agent Coding工作流及Skills插件实用性
速览
本文讨论在使用Codex等Agent进行编程时的常见痛点，如目标设定过大导致结果不佳。作者建议MVP应聚焦基础骨架，并询问高效的工作流。同时，帖子也探讨了Skills和Plugins的实际应用价值及必备推荐。
AI 深度解读
背景
随着 AI 编程助手（如 OpenAI Codex、Llama 等模型驱动的工具）的普及，开发者社区正在经历从“辅助代码补全”向“自主 Agent 编程”的范式转变。在这一过程中，许多资深开发者发现，尽管社区中充斥着关于使用 Goal（目标）模式或 Plan（规划）模式即可一键生成高质量代码的“神话”，但实际落地时，许多用户仍感到困惑。
本文基于 LINUX DO 社区中关于 Agent Coding 的讨论，聚焦于开发者在使用 Codex 等 AI 编程工具时遇到的核心痛点：如何在新项目初期搭建框架、如何避免 AI 生成代码的“幻觉”与偏离，以及 Skills 和 Plugins 的实际价值。这反映了当前 AI 辅助开发中，理想化的自动化流程与现实工程复杂性之间的巨大落差。
核心内容
原文作者主要表达了对当前 AI 编程工作流（Workflow）的质疑，并分享了自己在使用 Codex 时的实际体验与反思。
首先，作者指出目前社区中流行的“Goal 模式”虽然看似高效，能写出令人满意的效果，但这可能是一种幸存者偏差或特定场景下的特例。作者自述仍停留在“对话时代”，即需要人工一步步抓取细节并进行测试。如果不进行这种细粒度的控制，AI 很容易“跑偏”，导致最终产出质量低下（“一坨屎”），甚至耗费一整天时间却一无所获。
其次，作者强调在定义 MVP（最小可行性产品）时，切忌目标过于宏大。如果试图一次性将所有功能点和架构细节塞入 Codex，即便使用了 Plan 模式或撰写了极其详细的 Spec 文档，最终生成的代码往往也不符合预期。这是因为大模型在处理复杂、长链条的任务时，容易出现上下文丢失或逻辑断层，且一旦生成结果错误，“大船难掉头”，后期修正成本极高。
此外，作者提出了两个具体的疑问：
- 新项目框架搭建的最佳实践：对于目标和功能点明确、实现思路清晰的新项目，是否存在一种更好的方式来使用 Codex 或其他 Agent 进行初期框架搭建？
- Skills 和 Plugins 的实用性：尽管 Skills 和 Plugins 概念上很有用，但在实际工作中能真正派上用场的寥寥无几。社区中是否有被广泛认可的必备 Skills 或 Plugins？
关键要点
- 警惕“自动化幻觉”：社区中关于 Goal 模式一键生成高质量代码的案例可能具有误导性，实际工程中仍需人工深度介入。
- MVP 定义需极简：避免将宏大目标和完整架构一次性输入 AI。应优先构建最基本的骨架功能，以降低 AI 出错的风险。
- 细粒度控制优于宏观指令：在缺乏有效约束的情况下，AI 容易偏离预期。开发者需通过逐步抓取细节、自行测试来确保代码质量，而非完全依赖 AI 的自主规划。
- Spec 文档并非万能：即使使用 Plan 模式或提供详细的技术规格说明书（Spec），也不能保证 AI 输出的代码完全符合开发者意图，尤其是对于复杂架构。
- 修正成本高：AI 生成代码一旦偏离方向，后期重构和修正的难度极大（“大船难掉头”），因此在初期搭建阶段需格外谨慎。
- Skills/Plugins 落地难：尽管 AI 编程工具强调扩展性（Skills/Plugins），但实际高频使用的工具极少，开发者需自行甄别真正有价值的扩展功能。
意义与影响
这段讨论揭示了当前 AI 辅助编程领域的一个关键矛盾：工具能力的快速迭代与开发者工程方法论滞后之间的不匹配。
- 工作流的重构需求：传统的“提示词工程”可能不足以应对复杂的软件工程任务。开发者需要建立新的工作流，例如“分步生成 + 即时验证 + 局部迭代”，而非“一次性生成 + 后期修补”。
- 对 AI 能力的理性认知：AI 目前更适合作为“高级代码助手”或“样板代码生成器”，而非完全自主的“软件工程师”。在架构设计和复杂逻辑实现上，人类的把控依然不可或缺。
- 社区知识沉淀的价值：此类来自一线开发者的真实反馈，比官方文档更具参考价值。它提醒后来者不要盲目追求“无代码”或“全自动”，而应关注如何将 AI 融入现有的敏捷开发流程中，特别是在 MVP 阶段和框架搭建环节。
- 工具选择的启示：对于 Skills 和 Plugins 的冷淡反应，暗示了开发者更倾向于核心模型的稳定性，而非过度依赖外部扩展。未来 AI 编程工具的成功，可能取决于其核心模型对复杂上下文的理解能力，而非插件生态的丰富程度。