构建一个自主模板业务，算是
Source: Dev.to
我最近在做的一个副项目是一个多代理系统，用来自动化创建可直接在 Gumroad 销售的、功能完整的模板。最初它是一个学术练习，用来探索代理、 多代理编排以及 LLM API 集成。随后我转向了更实操的方式，但以下是我在这段短暂的副业尝试中得到的一些经验教训。
代码已公开在 这里，欢迎感兴趣的朋友查看并在此基础上进行二次开发。
Lesson 1 – Spend time on your prompts and configuration documents
无论是用来生成任务和想法的初始提示，还是诸如 AGENTS.md 之类的配置文档，都必须在一开始就花时间根据自己的需求进行定制。我最初投入的时间不足，后来才感受到这种疏忽的影响。除非你的 AI 工具本身或系统内部提供了防护措施，否则提示和配置是唯一可以强力影响代理走向的入口。要明确写出你 想要 的和 不想要 的——后者同样重要，甚至更重要。
Lesson 2 – Context management is a pain
这点对已经使用 AI 工具一段时间的人来说可能已经很明显，并且有很多缓解办法。在多代理场景下尤为棘手，因为人们往往期望从一个交接点到下一个交接点能够保持线性连续性。代理需要共享足够的上下文才能理解当前的问题或任务，但保持 100% 的上下文并不总是可行或必要的。对上下文进行压缩通常已经足以保证可接受的质量，但当交接点必须 放大 上下文而不是压缩时，朴素的做法可能适得其反。
我最初在 Anthropic API 调用时因为硬性 token 限制而引入了分块（chunking）。使用朴素的分块方式导致了重复组件和混乱的集成。随着我转向更具上下文感知的分块策略，输出质量提升，文件之间的一致性增强，所需的人工 QA 工作量也大幅下降。
我尚未完全完善这套流程，但在下一次转型时，我正积极探索更稳健的审查与干预机制。
Lesson 3 – Be very, very explicit
对此有很多不同的观点；有些人乐于把决策权交给代理。我更倾向于保留更多控制权。代理化的工作流可以加速从想法到解决方案的过程，但最终决策仍需由人工操作者做出。
我曾在请求中使用了模糊的表述，如 “follow the latest engineering trends” 或 “stay up to date with 2026 versions”。代理把这解释为 “猜测 2026 年会流行什么并使用它”，于是把实验性的、仅限金丝雀发布的功能也加入了本应是生产就绪的模板中。作为主题专家，操作者能够提出正确的问题并设定合适的防护措施。这次教训让我在后续项目中更加注重明确指示。
Lesson 4 – Pick a tool that works for you
AI 辅助工具发展迅速，容易在它们之间来回切换。我尝试过 Cursor、Windsurf、带 Copilot 的 VS Code、带 Junie 的 JetBrains 以及其他许多工具。有的更适合管理已有的生产或遗留代码库，有的则擅长从零开始创建。Antigravity 这款带有强烈个人风格的 IDE 在我启动新项目时表现尤佳。
我的建议是：忽略炒作，亲自试验可用的选项，打造符合自己风格的工作流。由于操作者的核心职责是提出正确的问题，尽量减少干扰尤为关键。