开发者探讨AI工作流最佳实践：追求高效与精准

背景

随着人工智能技术的飞速发展，AI 辅助开发的工作流（Workflow）也在不断迭代。对于一线开发者而言，寻找一套“舒适”的 AI 协作方案已成为常态。这种“舒适”并非指操作上的随意，而是指在最少对话轮次和最低成本的前提下，实现最大化、高质量且高准确度的输出结果。

然而，许多开发者在探索过程中发现，很难找到一套真正完美的通用方案。从早期的 agent.md 配置，到后来的 skill（技能）编写，再到近期流行的 OpenSpec、Superpowers、GStack 以及 Trellis 等框架，各种工具各有千秋，但也存在明显的局限性。作者作为一名一线开发人员，核心诉求在于能够最快、最准、最稳地获取开发结果，从而释放精力去处理更具创造性的工作。

核心内容

作者深入探讨了当前 AI 辅助开发工作流中的痛点与探索方向，主要围绕以下几个维度展开：

1. 对“理想工作流”的定义 作者认为理想的工作流应具备极高的效率与准确性，同时控制成本。这要求 AI 能够直接提供可信赖的结果，减少反复修正和上下文确认的开销。

2. 主流工作流工具的对比与局限

   • Spec 沉淀型工作流：作者倾向于采用能够沉淀 spec（规格说明）的工作流，因为这对于长期维护和准确性至关重要。
   • Trellis：这是作者近期重点体验的工具。虽然它在某些方面表现良好，但在 brainstorm（头脑风暴/创意发散）环节的表现不如其他方案理想。
   • TDD（测试驱动开发）：在实际体验中，作者发现完全遵循 TDD 模式的 AI 工作流效果并不特别理想，可能因为 AI 在生成测试用例与实现代码的同步性上存在偏差或效率瓶颈。
   • 其他工具：OpenSpec、Superpowers、GStack 等工具虽然各有优势，但尚未形成统一的“最佳实践”。

3. 自定义 Skill 的干扰效应 作者在 Trellis 框架基础上，编写了针对自己项目的专属 skill。这引发了一个关键的技术疑问：是自定义的 Skill 干扰了框架本身的能力，还是框架本身存在架构或逻辑上的问题？ 这种不确定性使得工作流的优化变得复杂，开发者难以判断性能瓶颈或错误来源究竟来自自定义配置还是底层框架。

4. 社区讨论的发起 基于上述困惑，作者发起讨论，询问社区其他开发者当前采用的主流工作流方式，旨在通过交流找到更优解，并澄清是否存在因个人配置不当导致的问题。

关键要点

• 效率优先原则：最佳工作流的核心指标是“最少对话、最少成本、最大产出”，且结果必须高质、高准。
• Spec 沉淀的重要性：一线开发更倾向于能沉淀 spec 的工作流，以确保开发过程的规范性和结果的可追溯性。
• 现有工具的短板：
  • Trellis 在创意发散（brainstorm）阶段表现较弱。
  • TDD 模式在实际 AI 协作中体验不佳，未达预期理想状态。
• 自定义配置的副作用：开发者在框架基础上添加专属 skill 后，面临“配置干扰”与“框架缺陷”难以界定的困境，这反映了当前 AI 开发工具链在可解释性和稳定性上的不足。
• 缺乏统一标准：尽管有 agent.md、skill、OpenSpec 等多种尝试，但目前尚无一套被广泛认可的、真正“舒适”的终极工作流方案。

意义与影响

这篇讨论揭示了 AI 辅助开发从“尝鲜”向“深度集成”过渡阶段的核心矛盾：工具的复杂性增加与开发者对确定性需求的提升之间的不匹配。

1. 推动工作流标准化：作者对 spec 沉淀的偏好，暗示了未来 AI 开发工具可能需要更强调结构化输出和规格管理，而不仅仅是代码生成。
2. 暴露框架设计的盲区：Trellis 在 brainstorm 环节的不足以及自定义 skill 带来的干扰问题，提示框架设计者需要更好地平衡“通用能力”与“个性化扩展”，并提高框架的可观测性，以便开发者区分配置问题与框架缺陷。
3. 促进社区知识共享：在缺乏官方最佳实践的情况下，社区层面的经验交流（如 LINUX DO 上的讨论）成为开发者优化工作流、规避陷阱的重要途径。
4. 重新定义人机协作模式：开发者不再满足于简单的问答式 AI，而是寻求一种能像资深同事一样稳定、高效、低维护成本的协作伙伴，这对 AI 模型的推理能力、上下文理解以及工具链的稳定性提出了更高要求。