他盯着屏幕上的架构图，眉头皱了起来——线条歪歪扭扭，配色像是随机生成的，旁边还堆着一堆笑脸表情和空话。这是他的AWS架构助手交上来的作业。

几周后，同一个助手开始输出可直接发给客户的图纸。变化不是换了个模型，而是换了一套反馈机制。

打开网易新闻 查看精彩图片

问题诊断：为什么AI图纸总像草图

作者复盘了两个顽固症状。一是过度设计，方案里塞满用不到的组件；二是输出质量滑坡，回复冗长、表情泛滥、填充词密集——那种让人一眼认出"这是AI写的"的质感。

根源在于系统缺陷：之前的架构师代理没有自我改进能力。它生成内容，但从不回顾自己产出的问题，也不积累团队共识。

正方观点：知识库反馈能解决质量顽疾

解决方案是引入结构化知识库作为反馈回路。作者选用arc42架构模板，公开可用且原生支持Markdown格式。这份文档同时承担双重角色：对外是规范的架构说明，对内是代理的行为校准参照。

具体操作上，代理生成的每一份图纸和方案，都要与知识库中的标准比对。模板里预设的章节——从上下文边界到部署视图——成为自动检查清单。不符合结构的内容会被标记，迫使代理在下一轮迭代中修正。

组件分解图也经过重新设计。AWS图表的MCP服务器调用被压缩到两次：获取图表示例、列出图标清单。作者发现，让代理在正式调用DrawIO生成前完成这两步预习，输出质量显著提升。

技术前提需要满足：本地安装npx，建议用Node Version Manager管理版本。

反方观点：工具链简化会不会牺牲灵活性

质疑的声音指向另一个方向。把MCP服务器调用从多轮交互砍到两次，是否过度限制了代理的探索空间？毕竟，复杂架构往往需要反复查询图标语义、调整布局规则、验证AWS服务兼容性。

作者的实际测试给出了回应。预加载示例和图标库后，代理在生成阶段的"犹豫"明显减少——不再频繁发起试探性调用，而是基于已获取的上下文一次性输出合规图纸。效率提升的同时，最终图纸的专业度反而更高。

真正的瓶颈不在工具调用次数，而在上下文窗口的有效利用。精简前置步骤，把token预算留给生成环节，是更优的资源配置。

我的判断：可交付性才是代理的分水岭

这次升级的核心洞察在于区分"能跑通"和"能交付"。很多AI演示停在前者：功能实现，但产出物需要人工二次加工才能见人。

作者的路径是逆向工程专业标准。arc42模板定义了"什么算一份合格的架构文档"，DrawIO的浏览器直连确保了图纸的可编辑性和视觉规范性。代理不再只是生成内容，而是生成符合组织契约的内容。

配置细节值得借鉴。在OpenCode环境中，DrawIO MCP的定义写入opencode.jsonc的mcp段落，类型设为local，命令指向npx @drawio/mcp。环境变量FASTMCP_LOG_LEVEL设为ERROR，减少噪音。

权限管控采用白名单模式。全局配置中先禁用awslabs*和drawio两类工具，仅在aws-architect.md的frontmatter里为特定代理显式开启：bash命令拒绝，c4-documentation和drawio技能允许，读写、搜索、通配工具全开，awslabs.aws-diagram-mcp-server和drawio标记为true。

验证命令很简单：opencode mcp status，确认指定服务器状态正常。

最终效果体现在一个细节：代理现在能直接在浏览器里打开标准draw.io文件。不是导出图片，而是生成可继续编辑的源文件。这意味着客户收到图纸后，架构师团队仍能快速响应变更——从一次性交付转向可持续协作。

作者提到这对团队帮助很大。我猜他的同事终于不用在收到AI图纸后，默默打开设计软件重画一遍了。